Agent 核心工作方式
根據 Google 官方 Agent 文件解釋 Antigravity Agent 的組成：reasoning model、tools、artifacts、knowledge、並行 conversations 與刪除邊界。
Antigravity 裡的 Agent 是產品的主 AI 能力。Google 官方文件把它描述成一個由 frontier LLM 驅動的 multi-step reasoning system：它能圍繞現有程式碼推理，呼叫多種工具，包括 browser，並透過 tasks、artifacts 等方式和使用者溝通。
這說明兩件事。第一，Agent 不是一次性回答模型，而是會分步驟理解、執行、驗證。第二，Agent 的質量不只取決於模型，還取決於工具、上下文、artifacts 和許可權策略。
這一篇先建立底層模型：學 Antigravity 的 Agent，不要只問“它用什麼模型”，要同時看 reasoning model、tools、artifacts、knowledge 和 conversation 管理。
閱讀目標：讀完本章，你應該能把一次 Agent 任務拆成目標、上下文、工具呼叫、artifacts、審查反饋和後續執行，而不是隻看模型回覆。
1. Agent 是多步推理系統
普通聊天模型的輸出通常是一次回答。Antigravity Agent 的工作方式更接近工程迴圈：
flowchart LR
Goal["使用者給目標"] --> Context["讀取程式碼和上下文"]
Context --> Reason["reasoning model 推理"]
Reason --> Tools["呼叫工具"]
Tools --> Artifacts["產出 artifacts / tasks"]
Artifacts --> Review["使用者審查和反饋"]
Review --> Reason
style Reason fill:#dbeafe,stroke:#3b82f6,stroke-width:2px
style Tools fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
style Review fill:#dcfce7,stroke:#22c55e,stroke-width:2px這個迴圈決定了你的提示詞要寫成任務說明，而不是寫成“問答題”。一個合格的任務應該包含：
- 目標：要修什麼、做什麼、查什麼。
- 邊界：哪些目錄能改，哪些不能改。
- 驗證：跑什麼測試，交什麼截圖或 walkthrough。
- 審查點：什麼時候停下來等你確認。
2. 四個核心元件
官方 Agent 文件列出四個 core components。
| 元件 | 作用 | 你要怎麼用 |
|---|---|---|
| Reasoning model | 負責理解目標、規劃、判斷下一步 | 根據任務複雜度選擇模型和模式 |
| Tools | 讀寫檔案、終端、瀏覽器等能力入口 | 用許可權和 allow/deny 控制副作用 |
| Artifacts | 任務計劃、實現計劃、截圖、錄屏、diff 等產物 | 用來審查，而不是隻看聊天文本 |
| Knowledge | Antigravity 儲存和呼叫的專案知識 | 讓長期專案不必每次從零解釋 |
新手常見誤區是隻關注第一項：模型。模型當然重要，但如果 tools 沒有限權、artifacts 沒有審查、knowledge 寫進了過時結論，再強模型也會把任務推偏。
3. Tools 包括 browser
官方文件特別提到 Agent 可以使用 wide range of tools，包括 browser。對開發任務來說，這意味著 Agent 不只是“在檔案裡改程式碼”。
它可以圍繞這些現場行動：
- 程式碼檔案：讀專案、修改檔案、看 diff。
- 終端：執行構建、測試、格式化、CLI。
- 瀏覽器：開啟頁面、點選、滾動、填寫輸入、做 UI 驗證。
- Artifacts：把計劃、結果、截圖、錄屏交給你審查。
工具越多，能力越強，風險也越大。第一天的正確做法是從只讀工具開始，逐步放開終端和瀏覽器許可權。
第一步：只读分析 workspace。
第二步：允许单文件修改。
第三步：允许受控 terminal 命令。
第四步：允许 localhost 浏览器验证。
第五步：再考虑真实后台或外部网站。4. Tasks 和 Artifacts 是溝通層
Antigravity 不要求使用者盯著每一步模型輸出。Agent 會透過 tasks、artifacts 等方式和使用者溝通，這正是 agent-first 工具的關鍵。
你應該重點看：
- Task group 是否把任務拆清楚。
- Implementation plan 是否先說明方案再改檔案。
- Diff 是否只覆蓋目標範圍。
- Screenshot / browser recording 是否能證明 UI 或流程真的跑過。
- Knowledge 是否記錄了可長期複用的專案事實。
如果一個任務沒有 plan、沒有 diff、沒有截圖或沒有 walkthrough，卻聲稱“已完成”，不要直接接受。Agent 的結果必須能被 artifacts 審查。
深讀：為什麼 Agent 不是“更長的聊天”
官方 Agent 文件把 Antigravity Agent 描述為 multi-step reasoning system，這個定義會影響你的工作方式。你給它的不是一道問答題，而是一組可以被執行、審查、反饋、再執行的工程任務。
因此，好的提示詞要把目標、邊界、工具、驗證和停頓點寫清楚。否則 Agent 可能會把“我理解了”誤當成“我可以直接執行”，或者把一次複雜任務拆成不可審查的大改動。
5. 可以並行開多個 Agent conversation
官方文件說明，使用者可以啟動多個 Agent conversations，包括並行執行。這個能力很適合把相互獨立的任務拆開：
| 適合並行 | 不適合並行 |
|---|---|
| 一個 agent 查文件，一個 agent 修 UI | 兩個 agent 同時改同一個檔案 |
| 一個 agent 跑排障，一個 agent 寫測試計劃 | 多個 agent 同時改同一個模組介面 |
| 不同 workspace 的獨立任務 | 同一 Git 分支上無邊界大改 |
並行不是為了熱鬧，而是為了讓邊界清晰的任務同時推進。並行前至少要說清楚：
Agent A 只读分析认证模块，不修改文件。
Agent B 只修改 docs 目录，不碰 src。
两个 agent 都不要提交 git。6. 刪除 conversation 的邊界
官方 Agent 文件提到，刪除 Agent conversation 可以在 Agent Manager 中右鍵選擇 Delete Conversation，也可以在 Editor 的 Agent panel 裡點選 trash icon。
這類刪除動作要理解邊界：
- 刪除 conversation 主要影響會話記錄和任務上下文。
- 它不等於自動撤銷已經寫入檔案的程式碼改動。
- 真正的檔案回退仍然要看 Git diff、undo、revert 或手動恢復。
不要把“刪掉 conversation”當成“撤銷任務”。只要 agent 改過檔案，就必須檢查 Git 狀態。
7. 一個安全的 Agent 啟動模板
第一次對真實專案使用 Agent，可以這樣寫：
先只读分析当前 workspace，不要创建、修改或删除文件。
请输出：
1. 你判断这个项目的技术栈。
2. 本任务可能涉及的目录。
3. 你需要调用哪些工具。
4. 你建议的最小执行计划。
5. 哪一步需要我确认后才能继续。如果要讓它繼續執行，再補一條：
按刚才计划执行第一步，只允许修改一个文件。
执行任何 terminal 命令前先请求确认。
完成后交付 diff、验证命令和可能风险。這能把 Agent 的多步能力控制在可審查範圍內。
本章自檢
完成本章後，用這 3 個問題檢查自己是否真正理解：
- Antigravity Agent 的四個核心元件分別是什麼？
- 為什麼 tools 越多，越需要許可權和 artifacts 審查？
- 刪除 conversation 為什麼不等於撤銷已經寫入檔案的改動？
透過標準：你能為真實專案寫出一條只讀啟動 prompt，並明確下一步允許哪些工具、修改哪些檔案、交付哪些證據。
官方來源
- Google Antigravity Agent —— 官方說明 Agent 的定義、核心元件、並行 conversations 和刪除方式。
- Google Antigravity Documentation —— 官方文件入口，用於核對 Agent Manager、Artifacts、Browser 等關聯章節。