Agent Team 實戰（九）：A7——不是再多一個 Agent，而是讓團隊開始被看見

一句話： A7 不是再多一個 Agent，而是讓 Agent Team 開始有能力看見自己的錯。

前一篇說到 OS IPC 能教我什麼、不能教我什麼，講到最後有一個問題被留在檯面上：如果 Agent Team 裡每個 Agent 都是異構的 specialist、產出都不一樣，這表示 completion report 不能真正代表結果本身，那麼，誰來判斷這個團隊有沒有在正常運作？

在一開始，我以為 GM 可以做這件事，GM 是唯一的人類接口、是 coordinator、也是整個 Agent Team 的中樞，當 Em 做完 ingest，GM 去看 wiki，當 Dm scaffold 完一個新 Agent，GM 去看目錄結構，當 C7 provision 完 skill，GM 去看 catalog，這就是當初我期望 GM 進行的事情，同時也是我之前的工作模式，GM 就是依照這些模式建立的，GM 發派任務，Agent 在自己的 context 裡執行，GM 再用獨立 context 回頭檢查，相當符合 cross-audit principle。

延續之前在 Agent 建立時的討論與概念，Agent 最好由另外一個 Agent 稽核，但我一直在思考這個 Auditing Agent 應該長什麼樣子，我做過 ERP 的 Governance agent，也經手過 Website 的 QA-Agent，他們各自有不同的長相，那 Agent Team 的 Auditing Agent 應該又是什麼樣子？我也沒有答案，所以我想先用 GM 作為資料蒐集者，來看看會怎麼發展，而進行一陣子之後，我開始發現一些 Pattern 跟 Pain Point，比如 GM 可以檢查一個結果，檢查一條 pipeline，甚至可以在幾個 Agent 之間做 sense-making，但 GM 無法一直盯著所有事情、在每次 hook silent fail 的當下就發現，他也無法在每個 dispatch 的五分鐘後自動回頭看 inbox，在每個 skill 被覆寫時立刻判斷那是不是破壞了 catalog 的 read-only contract，更無法在整個團隊的 correction 越堆越多時問自己：這是不是某個 Agent 開始退化了？

這看起來似乎是 Auditing Agent 進場的時間了，而且這些問題並不是單純的監控或是稽核，而是「當一個 Agent Team 開始像團隊一樣運作時，哪些事應該開始獨立，而不是仰賴人類和 GM 順手做？」

A7 最早不是監控器，而是一個 validation gap

A7 最早出現的時候，名字還沒有那麼明確，他只是 Em wiki 裡一個 future validation agent 的概念，原因也很簡單：所有 Agent 都在自我驗證。

Dm 建 Agent，然後 Dm 自己用 validator subagent 檢查 scaffold；C7 管 skill catalog，然後 C7 自己跑 /validate-skill 檢查 skill；Em 管 wiki，然後 Em 自己跑 /lint 檢查 wiki，大家都有驗證，但用 cross-audit principle 的角度來看，產出和驗證標準都在同一個 context 裡，Agent 當然會覺得自己的產出符合自己的標準， 因為他本來就是用同一套框架產出、也用同一套框架檢查。

這不是說 Agent 偷懶，也不是說他不可靠，而是模型的結構限制，你要一個模型檢查自己剛剛推理完並生成的東西，它只會看見一致性、看不見盲點，因為這是個雞生蛋、蛋生雞的難題，那個盲點本來就是讓他生成錯誤的原因，如果他看得見，就不會生成錯誤。

所以一開始我只是很簡單的希望 A7 做一個任務：專門做 cross-agent validation 的 L2 agent。

但我沒有立刻創建他，原因就是上面說的：團隊還小，我自己就是 cross-auditor，GM 的 context 跟其他 Agent 的 context 也有天然隔離，這件事暫時還不需要一個 Agent，先看看 Pattern 跟 Scenario，記錄整個過程再來歸納設計就好。

「先記錄，不急著建」這個邏輯其實蠻重要的，因為如果我在那個時候就把 A7 建出來，大概只會是一個很普通、標準的 QA Agent：讀結果、打分數、寫報告，看起來很完整，但不會解決真正的問題。

真正推動 A7 成形的不是需求，是事故

Agent Team 跑久了之後，問題開始變得具體。

第一類是 silent failure。

在 dispatch 那篇我提過各種的 silent failure，hook 格式錯誤、從錯誤目錄啟動、stop-hook 沒有寫 inbox 等等，因為任務看起來完成、Agent 有回覆、檔案也有改、session 也正常結束，一切都正常，但是後續事件沒有發生，這種錯誤很麻煩，因為它不是「紅燈」，它是「燈沒亮」，而且你還要先知道這個燈應該要亮才會發現問題。

第二類是 chain debug ownership。

當一條 pipeline 是 Em → C7 → Dm 這樣跑的時候，如果 Em 完成了但 C7 沒被觸發，這到底是 Em 的錯、C7 的錯、GM 的錯、hook 的錯、還是 task file schema 的錯？每個 Agent 都只看到自己的局部，GM 可以回頭查，但 GM 並沒有被設計成守著每條工作鏈，所以這裡出現了一個「沒有人負責的區塊」。

第三類是團隊退化。

一個 Agent Team 不會只在單次任務裡壞掉，他是慢慢壞掉的，completion report 越來越稀疏，某個 Agent 的 correction 越堆越多，某個 skill copy 跟 catalog master 越差越遠，某個 external service 的錯誤訊號反覆出現但還沒有嚴重到讓人注意，這些 operational drift 並不是會讓人警醒的 bug。

所以，這些問題加起來，A7 的角色開始從「驗證者」變成「稽核者」，超過原本的「監控者」的 Scope，「監控者」聽起來像是看 process、看 log，紅了就叫你，這當然是他的一部分工作，但 A7 要做的事比這更麻煩，我需要他看 Agent Team 的行為有沒有偏離設計意圖，這包含了很多 AI 判斷：這個 dispatch 是否真的完成？這個完成是不是符合原本的 intent？這個 deviation 是 execution defect，還是 spec 本身寫得不完整？這個 Agent 產出的東西是不是有 cross-agent implication？這些沒有辦法單純仰賴 shell script 來完成。

我怎麼拆 A7？從一條線到三個軸

一開始我把 A7 拆成幾個功能，像一般 spec 會寫的那樣：Log Audit、Cross-Agent Validation、Health Monitoring，這些我都剛好剛剛做過，沒有錯，但不夠。

回到方法論的三層，缺了場景跟情境(Playbook)，你就只是還沒有落地的方法論，因為功能只回答「看什麼」，沒有回答「什麼時候跑？」、「被誰觸發？」、「結果要去哪？」，這些問題如果混在一起，A7 就會變成一個萬用稽核怪物，什麼都看、什麼都報、什麼都混在同一個 report 裡，最後 GM Context 被塞滿，人類也不會看。

所以我把 A7 被拆成三個軸

第一個軸是 capability，也就是他能偵測什麼：

• Log Audit：看執行紀錄、hook、dispatch、inbox/outbox，找 operational problem。
• Cross-Agent Validation：用獨立 context 檢查其他 Agent 的產出，特別是 Dm、C7、Em 這些原本容易自我驗證的地方。
• Health Monitoring：看跨時間的退化，比如 correction trend、skill drift、completion report 品質、dispatch volume spike。

第二個軸是 lifecycle，也就是他怎麼跑：

• Long-running daemon：常駐在 Overmind 裡，看即時訊號，抓 chain break、hook failure、process crash、dispatch spike。
• Periodic auditor：由 /team-review 或固定 cadence 觸發，做比較深的統計和趨勢稽核。

第三個軸是 operational role，也就是這件事最後被整理成的 Three Roles：

• Role 1：Continuous Dynamic Detection，常駐偵測，抓 live dispatch / inbox / hook event，輸出到 live operations queue。
• Role 2：Periodic / Manual Static Audit，定期或手動檢查 architecture / methodology artifacts，輸出成報告和 wiki knowledge。
• Role 3：Dispatched Event Monitor，由 GM 或其他 Agent 主動 dispatch，去旁邊觀察某一個正在進行的 work unit，輸出自己的 work-log。

這三個軸很重要，因為它讓 A7 從一個概念模糊的「稽核 Agent」，變成一個可以被拆解、被局部建造、被局部驗證的系統。

A7 的方法論第一步，就是把「他要看什麼」和「他怎麼運作」拆開， 否則你會把 capability、lifecycle、trigger、output channel 全部混成同一個設計，最後每個功能都看似合理，但整體跑不起來。

A7 解決的不是錯誤，而是「誰知道錯誤發生了」

A7 的核心並不是「防止錯誤」，而是「縮短錯誤變成知識、再變成機制的距離」，也同時縮短了「錯誤到修復的時間」。

比如 hook failure，A7 沒辦法保證 hook 永遠不壞，但他可以看到 task archived 卻沒有對應 inbox JSON。

比如 chain break，A7 不能保證下一個 Agent 一定會被觸發，但他可以看到 task 裡有 chain，卻在時間界限內沒有下一個 task file。

比如 skill override anti-pattern，A7 不一定阻止某個 Agent 改 SKILL.md，但他可以看到 override fence 出現在一個 read-only master 應該被保護的區塊。

比如 external-service footgun，A7 不會自己去修 OAuth，不會重發 token，不會把 Telegram bot 接回來，但他可以在多個 Agent 的 stop-hook output 裡看到 unauthorized、token expired、refresh failed 這些反覆出現的症狀，先把它升級成一個候選問題。

這些事情如果靠我來抓，通常是出事才會回頭考古、翻 log、找 commit、對時間、猜 Root Cause，所以我設計 A7 在發生時就捕捉上面的訊號，先留下痕跡，就算當下沒有時間修，也能在 /team-review 的時候被看見。

所以 A7 的 observe-only scope 很簡單：觀察、回報、建議，但不 dispatch 其他 Agent、不修檔、不碰其他 Agent 的產出。

這聽起來保守，但其實是故意設計的安全邊界，如果 A7 一邊稽核一邊修正，他就又變成另一個 self-validation loop，稽核者和行動者共享同一個 context，最後他又會開始合理化自己的修正，這剛好是 A7 原本要解決的問題。

A7 不是裝潢、設計團隊裡的設計師甚至屋主，他比較像外聘的驗屋驗收團隊， 指出牆腳有水痕、電箱裡頭電線接法不對、天花板有縫隙，但要不要重拉線、要不要拆牆、要不要停工，還是 GM 和人類決定。

這篇先停在這裡：A7 從 validation gap 開始，最後變成一個 observe-only 的 Auditing Agent。它要解決的不是「讓團隊不犯錯」，而是讓錯誤有人看見、有人分類、有人知道下一步該進 live repair、team-review，還是方法論修正。

但這也留下另一個問題：如果 A7 的完整 spec 還沒成熟，可是 Role 3 的現場需求已經出現，我應該等完整 A7，還是先建一個能承擔 production duty 的前身？下一篇就是 A7sus4。

參考資料

^[1] OpenAI — How we monitor internal coding agents for misalignment（2026-03-19；支持「coding agent 需要獨立 monitoring infrastructure」）

^[2] OpenAI Agents SDK — Tracing（官方文件；Agents SDK 內建 LLM generation、tool call、handoff、guardrail 與 custom event tracing）

^[3] Microsoft Open Source Blog — Introducing the Agent Governance Toolkit（2026-04-02；支持「agent 自主性提高後，governance / runtime security 變成獨立問題」）

^[4] OWASP GenAI Security Project — OWASP Top 10 for Agentic Applications for 2026（2025-12-09；支持 memory/context poisoning、insecure inter-agent communication、cascading failures、rogue agents 等 agentic failure mode）

^[5] arXiv — AgentTrace: A Structured Logging Framework for Agent System Observability（2026-02-07；支持「agent observability 需要 continuous, introspectable trace capture」）

^[6] arXiv — AgentHallu: Benchmarking Automated Hallucination Attribution of LLM-based Agents（2026-01-10；支持「agent failure attribution 本身很難，不能只看最終結果」）