📌 本文重點
- 多 Agent 可複製「多人分工」開發流程
- Runtime 設計比單純換更大模型更關鍵
- 用開源工具就能打造迷你版 Antigravity
用一群 Agent 代替「一個工程師慢慢寫」，解決的是：複雜專案要靠多人分工，AI 也可以用 Runtime + 多代理系統做到同樣的協作和自動化。
核心觀念先講白：模型戰爭差不多打完了，現在比的是誰的 Agent Runtime 能把「模型能力」變成可落地的、多步驟的自動化工作流。
Google 在 I/O 上展示的 Antigravity 2.0 + Gemini 3.5 Flash 是一個很極端的例子：
- 96 個子代理分工
- 12 小時寫完一套從零開始的作業系統
- Token 成本不到 1,000 美金
- OS 還能跑《Doom》
💡 關鍵： 多代理 + 強 Runtime 已經能在「12 小時、不到 1,000 美金」內完成從零開發 OS，顯示關鍵瓶頸不再是模型本身，而是協作與流程設計。
這不是叫你明天也去做一個 OS，而是提供一個「如何設計多 Agent 開發流程」的範本。下面我們拆成三件你可以直接抄的事：
- 多代理分工設計：任務 → 子任務 → Agent 編隊
- 強健 Runtime：重試、檢查點、錯誤恢復
- 平價版本實作：在你自己的專案做一個「迷你 Antigravity」
核心功能：Antigravity 2.0 給開發者的三個啟示
1. 多代理分工：任務 → 子任務 → Agent 編隊
Antigravity 的做法，其實很像你帶一個遠端工程團隊：
- 架構師 Agent：決定 OS 的模組切分（檔案系統、排程、驅動、UI…）
- 模組作者 Agent：各自負責某一個模組的程式碼生成
- 測試員 Agent：寫測試、跑測試、收斂錯誤
- 整合者 Agent：把各模組組合、處理相依性、打包成可啟動的系統
對你來說，可直接套用成一個通用流程：
-
寫一個頂層任務描述
例：建立一個 RESTful CRUD 服務，管理任務（待辦事項），含 API、DB schema、簡單前端。 -
讓「架構師 Agent」自動拆解：
-
API 設計與 OpenAPI spec
- 後端框架與資料庫層
- 前端 UI
-
測試與 CI script
-
為每個子任務設計 Agent 角色：
-
api-architect-agent：只產出 API spec backend-agent：根據 spec 產生程式碼frontend-agent：負責 UItester-agent：生成並執行測試-
integrator-agent：檢查專案結構、跑build/lint -
在 Runtime 中定義工作流：
-
任務圖（DAG）：
架構師 → 模組作者 → 測試員 → 整合者 - 每個節點定義輸入/輸出檔案、工具（Git、DB、HTTP client）
可行動步驟：
- 選一個你熟的框架（例如
FastAPI/Next.js） - 用自然語言寫清楚「最終可交付物」
- 為這個專案定義 3–5 個 Agent 角色，明確限制各自輸入輸出
2. Runtime 比模型重要：90% 成功率在多步任務會變災難
多步任務有一個殘酷數學：
- 假設每一步成功率 90%
- 要跑 20 步，整體成功率 ≈ 0.9^20 ≈ 12%
💡 關鍵： 即使單步有 90% 成功率，20 步工作流成功率只剩約 12%，所以不加 Runtime 管控，多步任務幾乎註定失敗。
這就是為什麼像 Forge 這種開源 guardrails 會被重視：作者實測，一個 8B 模型在多步代理任務上，從 53% 提到 99% 成功率，完全不改模型，只改 Runtime。
你在自己的「迷你 Antigravity」裡，要做三件事：
-
重試與 nudging
-
為每個步驟設
max_retries（例如 3 次） -
失敗時自動加上「修正提示」，例如：
上一步測試失敗，錯誤訊息如下，請修正而不是重寫整檔。 -
檢查點（checkpoint）
-
每完成一個重要子任務，就把中間產出存到 Git / DB
-
失敗時從最近的檢查點重跑，而不是重頭來
-
錯誤恢復流程
-
專門的
debug-agent：只看錯誤訊息 & log，產出修復建議 - Runtime 層做：自動建立 bug report、開 issue、指派給對應 Agent
如果你用 Forge，它已內建：
- Tool-agnostic 重試策略
- 步驟執行強制與錯誤恢復
- VRAM-aware context 管理（對本地模型很重要）
- 評估套件與 Dashboard，可量化成功率
可行動步驟：
- 先把現有「單 Agent 自動流程」改成有重試與 checkpoint
- 對每個任務記錄：總步數、失敗點、重試次數，在 Dashboard 裡看瓶頸
3. 平價版本：你也能做一個「迷你 Antigravity」
你不需要 Gemini 3.5 Flash + Google 內部 Runtime 才能玩多 Agent。下面這些工具可以在自家專案做一個縮小版：
| 名稱 | 核心功能 | 免費方案 | 適合誰 |
|---|---|---|---|
| Forge | 多步代理 guardrails、重試、Dashboard | 開源 | 想提升本地 / 自架 LLM 可靠性的工程師 |
| llama.cpp + Qwen 本地 Agent | 在個人電腦跑本地模型 + 簡易工具調用 | 開源 | 想省雲端費用、在內網跑 Agent 的團隊 |
| MCP 生態（如 OpenAI MCP、各種 server） | 統一的工具協議，讓 Agent 調用資料庫、API 等 | 多數開源 / 免費 | 想把既有系統暴露為 Agent 工具的後端工程師 |
一個實用組合示例：
- 模型：
Qwen 2.5 7B/14B（透過llama.cpp或Ollama跑） - Runtime：
Forge當 guardrails - 工具層：一組 MCP server（例如 PostgreSQL、HTTP、Filesystem）
你可以先做一個「自動搭建 CRUD 服務」的迷你 Antigravity：
- 使用者輸入需求（自然語言）
architect-agent產出設計 + 任務拆解backend-agent+frontend-agent寫程式碼tester-agent自動開發 & 執行測試integrator-agent跑build並回報狀態
適合誰用：三種典型場景
1. 後端 / 全端工程師：自動化 CRUD 小專案
你可以把「打造新微服務」變成一個表單：
- 輸入資料模型 + 幾個業務規則
- 多 Agent 流程負責 scaffold、API、測試、
docker-compose
行動：從一個只需要 3–5 小時就能手刻完的小服務開始，先讓多 Agent 幫你做到 70–80%，你只負責 code review。
2. 資料團隊：資料管線與 ETL 任務
planner-agent：解析需求、拆成抽取/轉換/載入步驟sql-agent：產生查詢與 viewcheck-agent：比對 row count、品質指標
行動：挑一個每天都在重複手動跑的 ETL 任務，做成標準流程，讓 Agent 幫你自動生成 SQL + 驗證報表。
3. 產品 / PM：快速驗證 Side Project
- 搭配 Gemini 3.5（雲端）或本地 LLM
- 定義一個「最小可行功能」（例如 landing page + 簡單 API）
- 用多 Agent 完成第一版，再丟給工程師接手
行動：每次新點子，給自己一個規則：「先讓多 Agent 寫一版 Demo，我只在最後 2 小時調整。」
怎麼開始：一個最小可行範例
這裡給一條「3–5 小時內可完成」的路線，你可以直接照做：
步驟 1：選模型 + Agent 框架
- 模型：
- 想省錢／本地：
Qwen 2.5 7B（透過 llama.cpp 或Ollama） - 想雲端無痛：
Gemini 3.5 Flash（透過 Google AI Studio） - Runtime / 框架：
- 想要 guardrails：裝 Forge
- 想用現成 MCP：選一個支援 MCP 的 Agent 框架（如 OpenAI 官方 Agent SDK）
步驟 2：挑一個小系統
條件：
- 單服務、沒有第三方整合
- 你自己寫大約 3–5 小時能完成
例：任務管理 CRUD API + 簡單 React 前端
步驟 3：設計任務拆分與 Agent 角色
- 任務描述寫成一個
markdown檔（會給architect-agent看） - 在 Runtime 中註冊 4 個 Agent：
architectbackendfrontendtester/integrator- 為每個 Agent 明確：
- 可用工具（Git、Filesystem、HTTP…）
- 輸入（上一個 Agent 的輸出 / 檔案）
- 必須產出什麼檔案
步驟 4：加上監控 Dashboard
- 如果用
Forge：直接啟用它的 Dashboard，看每次工作流的步驟成功率 - 若自己實作：
- 為每個步驟記錄：開始時間、結束時間、是否重試
- 每次失敗時存 log + 輸入輸出到一個資料夾
步驟 5：只做一件事的迭代
- 第一版只要求「能跑起來」，不追求漂亮結構
- 每次失敗，你只調整：
- 任務拆分是否太粗/太細
- Agent 提示是否太模糊
- 重試與 checkpoint 是否設太少
等到這個小系統穩定後，你才讓 Runtime 去碰更大的專案。
小結：Runtime 是你的「AI 開發主管」
Antigravity 2.0 用 96 個 Gemini Agent 寫出一套能跑《Doom》 的 OS，看起來很遠，但背後用到的概念其實都可落在你今天的 side project 上：
- 把任務拆成 Agent 可接手的小單位
- 用 Runtime 管控流程，而不是寄望模型每次都猜對
- 利用開源工具（Forge、llama.cpp、MCP）做出自己的「迷你 Antigravity」
💡 關鍵： 關鍵不是再換一個更大的模型，而是把現有模型放進可靠的 Runtime，讓它真的「交付」可用產物。
關鍵不是再換一個更大的模型，而是先把你手上的模型，放進一個可靠的 Runtime 裡，讓它真的幫你「交付」東西。
🚀 你現在可以做的事
- 在 GitHub 上看看 Forge 專案，了解多步代理的 guardrails 怎麼設計
- 挑一個 3–5 小時能手刻完的 CRUD 小服務，照文中的 4 個 Agent 角色拆任務實作一次
- 把既有的單 Agent 自動化腳本，加上
max_retries和簡單 checkpoint 機制，量化成功率變化
發佈留言