Kerwin AI Information

標籤: Gemini 3.5

  • 96 個 Gemini Agent 幫你寫系統？

    96 個 Gemini Agent 幫你寫系統？

    📌 本文重點

    • 多 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 開發流程」的範本。下面我們拆成三件你可以直接抄的事：

    1. 多代理分工設計：任務 → 子任務 → Agent 編隊
    2. 強健 Runtime：重試、檢查點、錯誤恢復
    3. 平價版本實作：在你自己的專案做一個「迷你 Antigravity」

    核心功能：Antigravity 2.0 給開發者的三個啟示

    1. 多代理分工：任務 → 子任務 → Agent 編隊

    Antigravity 的做法，其實很像你帶一個遠端工程團隊：

    • 架構師 Agent：決定 OS 的模組切分（檔案系統、排程、驅動、UI…）
    • 模組作者 Agent：各自負責某一個模組的程式碼生成
    • 測試員 Agent：寫測試、跑測試、收斂錯誤
    • 整合者 Agent：把各模組組合、處理相依性、打包成可啟動的系統

    對你來說，可直接套用成一個通用流程：

    1. 寫一個頂層任務描述
      例：建立一個 RESTful CRUD 服務，管理任務（待辦事項），含 API、DB schema、簡單前端。

    2. 讓「架構師 Agent」自動拆解：

    3. API 設計與 OpenAPI spec

    4. 後端框架與資料庫層
    5. 前端 UI

    6. 測試與 CI script

    7. 為每個子任務設計 Agent 角色：

    8. api-architect-agent：只產出 API spec

    9. backend-agent：根據 spec 產生程式碼
    10. frontend-agent：負責 UI
    11. tester-agent：生成並執行測試

    12. integrator-agent：檢查專案結構、跑 build / lint

    13. 在 Runtime 中定義工作流：

    14. 任務圖（DAG）：架構師 → 模組作者 → 測試員 → 整合者

    15. 每個節點定義輸入/輸出檔案、工具（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」裡，要做三件事：

    1. 重試與 nudging

    2. 為每個步驟設 max_retries（例如 3 次）

    3. 失敗時自動加上「修正提示」，例如：上一步測試失敗，錯誤訊息如下，請修正而不是重寫整檔。

    4. 檢查點（checkpoint）

    5. 每完成一個重要子任務，就把中間產出存到 Git / DB

    6. 失敗時從最近的檢查點重跑，而不是重頭來

    7. 錯誤恢復流程

    8. 專門的 debug-agent：只看錯誤訊息 & log，產出修復建議

    9. 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：

    1. 使用者輸入需求（自然語言）
    2. architect-agent 產出設計 + 任務拆解
    3. backend-agent + frontend-agent 寫程式碼
    4. tester-agent 自動開發 & 執行測試
    5. integrator-agent 跑 build 並回報狀態

    適合誰用：三種典型場景

    1. 後端 / 全端工程師：自動化 CRUD 小專案

    你可以把「打造新微服務」變成一個表單：

    • 輸入資料模型 + 幾個業務規則
    • 多 Agent 流程負責 scaffold、API、測試、docker-compose

    行動：從一個只需要 3–5 小時就能手刻完的小服務開始，先讓多 Agent 幫你做到 70–80%，你只負責 code review。

    2. 資料團隊：資料管線與 ETL 任務

    • planner-agent：解析需求、拆成抽取/轉換/載入步驟
    • sql-agent：產生查詢與 view
    • check-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 角色

    1. 任務描述寫成一個 markdown 檔（會給 architect-agent 看）
    2. 在 Runtime 中註冊 4 個 Agent：
    3. architect
    4. backend
    5. frontend
    6. tester/integrator
    7. 為每個 Agent 明確：
    8. 可用工具（Git、Filesystem、HTTP…）
    9. 輸入（上一個 Agent 的輸出 / 檔案）
    10. 必須產出什麼檔案

    步驟 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 機制，量化成功率變化