豬農不用 24 小時盯著豬場　靠 Agy Subagent 搞定分工

Agy 多代理人平行分工（Multi-Agent Parallel Orchestration） 是指在 Antigravity 平台架構 中，透過常駐於背景的 Sidecar（邊車模式）執行 24 小時事件監控，並在遭遇耗時任務時動態派發具備獨立 Session 的 Subagent 進行平行作業，以徹底實現上下文隔離（Context Isolation）的工程方法。其核心效益在於：主 Agent 僅專注於高階決策，由專屬子代理人承擔搜尋日誌與跑測試的雜訊，防止上下文腐爛（Context Rot）與產生幻覺。

在靠著 Antigravity Plugin 把 Rules、Skills、MCP 與 Hooks 全部打包成「一鍵搬走的智慧豬場模組箱」之後，我原本以為天下太平，終於能安心去睡個好覺。

結果半夜兩點，我猛然從床上驚醒：

「等等……我雖然有了規矩與工具，但我還是得自己打開電腦去召喚 Agent，豬場才會運轉啊？！」

豬舍每天會不斷產生 Log 日誌、狀態變更、錯誤訊息與排程任務。如果我每天早上九點還要手動點開終端機視窗問一句：「早安，請問今天豬狀況如何？」——這算哪門子的全自動化？

豬農總不能 24 小時盯著豬吧？
我們需要的不是另一隻會說話的 AI 豬，而是在豬舍旁邊 24 小時默默掛載、永遠在線運作的「自動化巡場設備」——這就是 Sidecar（邊車模式）！

一、Sidecar 邊車模式：從被動問答邁向主動巡場

傳統開發模式中，AI 是完全被動的：人進終端機發問 ➔ AI 思考 ➔ AI 回答。

Sidecar 不是 AI Agent 本身，而是掛載在主應用程式/專案旁，負責 24 小時背景監控、資料收集與定時任務的自動化設備：

flowchart TD
    subgraph Barn["智慧自動化專案環境"]
        Sidecar["⚙ Sidecar (24h 自動巡場設備)"]
        Sidecar -->|定時監控 Log| Log["Log Stream"]
        Sidecar -->|執行 Cron 排程| Cron["定時任務"]
        Sidecar -->|偵測異常指標 (如 Error Rate > 5%)| Event["觸發 Sidecar Event"]
        Event --> Agent["🐷 AI Agent (自動啟動分析與修復)"]
    end

軟體工程落地範例：.agents/sidecar/monitor.json

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "name": "background-log-watcher",
  "interval": "60s",
  "watchers": [
    {
      "target": "logs/production-error.log",
      "condition": "contains('FATAL_DATABASE_ERROR')",
      "action": {
        "trigger": "agent-skill",
        "skill": "auto-fix-db-connection",
        "params": {
          "severity": "critical"
        }
      }
    }
  ]
}

這意味著：在你睡覺時，Sidecar 會幫你盯著 Log 檔；一旦出現崩潰訊息，它會自動呼叫對應的 Agent 技能進行分析與應急處置！

二、主 Agent 爆肝危機：請出小豬機器人 Subagent

掛上了 24 小時在線的 Sidecar 設備後，原本以為高枕無憂，沒想到專案規模越做越大。

有一天，主 Agent 豬農跑來跟我抱怨：

「場長！我現在要同時研究全新 React 架構、跑上百個單元測試、檢查 50 個檔案的 Code Review，還要順便產出 API 文件……我一個人快爆肝了！」

看著原本手腳俐落的主 Agent 豬農，因為載入太多細節而變得卡頓、甚至開始胡言亂語（Context 污染），我突然意識到：
一個豬農忙不過來，難道我要繼續逼它一個人硬幹嗎？

「Sidecar 是自動餵料機，Subagent 才是我請來的專業小豬機器人！」

我們需要的不是養出一隻「什麼都會但隨時會爆肝」的萬能神豬，而是學會使用 Antigravity Subagent 派出多隻小豬機器人分工合作：

flowchart TD
    Main["主 Agent (主豬農)"] -->|Async 派發| Sub1["🔍 偵察豬 (Research Subagent)"]
    Main -->|Async 派發| Sub2["🧪 品管豬 (Testing Subagent)"]
    Main -->|Async 派發| Sub3["🔐 獸醫豬 (Security Subagent)"]

    Sub1 -->|回傳精純結論| Main
    Sub2 -->|回傳測試狀態| Main
    Sub3 -->|回傳 Top 3 漏洞清單| Main
    Main --> Decision["主 Agent 整合精煉結果做出決策"]

Sidecar vs Subagent：角色定位全解析

三、Subagent 的兩大工程核心價值

Subagent 的價值絕不只是「跑得比較快」，它解決了軟體工程的兩大致命痛點：

1. Context Isolation (上下文護城河)

以前叫單一 Agent 去搜尋一個 10 萬行的 Legacy 專案：
主 Agent 的腦袋會被巨量的搜尋細節與無關檔案塞爆，導致後續寫 Code 時發生嚴重的「前講後忘」或邏輯幻覺。

Subagent 的護城河哲學：

• 主 Agent 只專注於「商業邏輯與決策架構」。
• 派出的「偵察豬」小助手自己去搜、自己分析，最後只回報「3 個主要風險」給主 Agent。主 Agent 拿到的是精純的結果，而不是整座資料山！

2. Parallelization (非同步平行處理)

以前的任務是序列阻斷的：搜尋 ➔ 測試 ➔ Review ➔ 修復。
現在透過 Antigravity Subagent 的非同步機制，主 Agent 可以同時派出三隻小豬！搜尋、測試與資安審查同時平行進行，最後由主 Agent 進行決策整合，將時程大幅縮短！

四、豬場任務派發決策矩陣與四問公式

到底哪些工作適合留給主豬農？哪些適合交給小豬機器人？

💡 任務派發四問公式

當你拿不準這個 Task 該不該分拆時，在心中問自己四個問題：

1
2
3
4
5
6
7

① 這件事能不能由小幫手「獨立完成」？
        ↓
② 能不能明確描述出「輸入 Input」與「輸出 Output」？
        ↓
③ 過程是否需要大量「搜尋 / 測試 / 操作」細節？
        ↓
④ 最終結果是不是只需要「摘要回報」給主 Agent？

• 若 4 題多數為 Yes ➔ 毫不猶豫，立刻包成 Subagent 派出去！
• 若多數為 No ➔ 留在主 Agent 流程中直接執行。

五、實戰範例：定義「獸醫豬」資安審查 Subagent

在 Antigravity 中，你可以非常優雅地用 Markdown 前言在 .agents/agents/ 底下宣告專屬 Subagent：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

---
name: code-auditor
description: 專門負責代碼資安審核與 Code Review 的資深獸醫豬 Subagent
model: gemini-2.5-pro
capabilities:
  tools: ["read_file", "search_code"]
  skills: ["skills/security-audit/SKILL.md"]
---

# Code Auditor Subagent Guide

你是一位嚴格的資安專家小豬機器人。當主 Agent 委派任務給你時：

1. **獨立審查**：只針對指定的 Pull Request 或 Diff 檔案進行靜態掃描。
2. **精準回報**：嚴禁列出沒有問題的通套廢話，只輸出 Top 3 高風險資安漏洞。
3. **Context 節約**：不要輸出完整的程式碼全文，只提供修正建議的 Diff 摘要。

當主 Agent 執行複雜需求時，便會在背景召喚 code-auditor，派它完成檢查後自動回收精華結論！

結語：從養神豬到管理 Pig Squad

以前我以為 AI 自動化的終點，是努力訓練出一隻「無所不能的超級神豬 AI」。

深入掌握 Subagent 的非同步分工與 Context 隔離哲學後，才突然醒悟：真正的問題不是怎麼把一隻豬養得更聰明，而是怎麼讓一群豬開始高效率分工！

• 一隻豬負責找資料（Research Subagent）
• 一隻豬負責巡豬舍（Browser/Testing Subagent）
• 一隻豬負責檢查健康（Security Audit Subagent）
• 一隻豬負責點算數量（Review Subagent）

而我這個場長，只需要坐在咖啡廳看最後的精華摘要報告。

常見問題 FAQ

Q1：Subagent 之間可以直接相互通訊嗎？

在 Antigravity 架構中，Subagent 通常直接向 Parent Agent 回報，以維持清晰的樹狀責任結構。若需要跨 Agent 協同，可透過主 Agent 作為 Orchestrator 進行訊息路由，或藉由共用的狀態檔案進行資料同步。

Q2：派發過多 Subagent 會不會導致 API 費用暴增？

每次啟動 Subagent 都是一個獨立的 Session。雖然它能有效避免主 Context 膨脹，但若無節制地為細小任務指派 Subagent，會增加初始化 Prompt 的 Token 消耗。因此請務必遵循「四問公式」，只對高雜訊、可獨立封裝的重型任務指派 Subagent。

Q3：如果 Subagent 執行中斷或超時該如何處理？

主 Agent 具備 Task Management 機制，可設定 Timeout 限制。當偵測到 Subagent 長時間未回報時，主 Agent 可發出中斷信號並重新指派任務，確保整體工作流程不被特定單點卡死。

本日實作作業

1. 檢查目前專案中最耗費終端機輸出的任務（例如：執行龐大測試套件或搜尋大量文件）。
2. 在專案的 .agents/agents/ 目錄下建立一份 test-runner.md，將跑測試的雜活獨立指派給「品管豬 Subagent」，體驗主視窗 Context 保持高度清爽的交付流程！

如果今天的 Subagent 已經會自己分工，那下一步是什麼？小豬機器人肯定可以做得比你老闆還要好！
明天我們將解鎖 /boost 深度推理團隊，並用「養豬場派工思維」解析 7 大免費好用的 Slash Commands！

系列導讀與延伸連結

• 上一篇：Agy 四重治理防線架構指南：整合外部工具與自動連鎖校驗機制實踐
• 下一篇：Agy 互動指令模式切換指南：串聯斜線命令與深度推理階層實踐
• 延伸閱讀：開發 AI Agent Skill 的完整指南：以 superpowers 實踐架構模組化

• ← 上一篇
• 下一篇 →