一句話： 我沒有直接建 A7，因為 Role 3 需要的不是更好的 monitor prompt，而是一個真正持久的稽核身份。
A7sus4：我沒有直接建 A7
既然 A7 的 spec 已經清楚了，那…直接來？並沒有。
我先建了 A7sus4。
A7sus4 在和弦裡是 A7 的 suspended 4th，一個還沒解決、等著回到主和弦的狀態，所以 A7sus4 不是 throwaway prototype，也不是玩具，他是 production-precursor，意思是：他會先在 production duty 裡承擔 A7 的某一部分能力，等 A7 1.x 真的具備那個能力並且跑過實際 audit cycle 之後，他才退休。
為什麼要這樣做？
因為 Role 3，也就是 dispatched event monitor，已經有很明確的需求和資料，但完整 A7 的 Role 1 daemon 還卡在 long-running crash policy、rate-limit checkpoint、heartbeat、watchdog 這些基礎問題上，如果我硬要等 A7 全部想清楚才做，Role 3 會一直停在紙上，可是 Role 3 的問題已經在現場發生了。
更麻煩的是，Role 3 的原型一開始是用 Agent-tool ephemeral spawn 做的，也就是臨時叫一個 monitor subagent 出來看某個工作，結果連續幾次出現同一類問題：這個 monitor 很容易把自己理解成「等的人」。
他看到 prompt 裡有 sleep N && stat，看到短時間內沒有明顯 filesystem signal，就進入一種 wait-mode，回覆裡開始出現 passive idiom，像「wait」、「let me do nothing and wait」、「watcher running, waiting for completion notification」，甚至有時候直接 spawn-and-exit，像是他把「監督」理解成「我等你們搞完再看」。
兄弟，這樣不對吧？
明明我們要的是一個主動稽核者，但 prompt 的形狀讓他變成一個等待者，而這不是寫一句「請你不要等」就能解決的事，因為根因不是文字，而是身份沒有錨點。
臨時 subagent 沒有自己的工作目錄，沒有自己的 CLAUDE.md，沒有自己的長期 state，沒有持續的 lifecycle，他只是一段 prompt 裡被叫出來的短暫角色，所以當任務訊號不夠密集時，他最穩定的心因模型就是：等。
A7sus4 的核心修正就是把這個角色變成 persistent process，放進 Overmind，讓 process 本身就是 Agent，讓他有自己的 agent-A7sus4/、自己的 CLAUDE.md、自己的 audit-cycle skill、自己的 state、自己的 work-log，換句話說，A7sus4 解決的不是「monitor prompt 怎麼寫」，而是「建立並且實驗一個持久身份」。
Signal density：不是所有任務都值得 live monitor
A7sus4 建出來後，另一個 Learning 是 signal-density precondition，一開始我想要 A7sus4 觀察所有任務，後來發現不行。
如果目標任務本身只是一個 GM-direct single-file edit，可能只有一個 file delta，沒有 dispatch archive、沒有 outbox、沒有 done JSON，這種任務拿去 live monitor，就像叫人坐在空房間裡聽海聲，然後叫他聽到一個大浪時紀錄下來，他當然會開始懷疑自己到底要做什麼。
所以 A7 Role 3 必須有 preflight：這個被觀察的 work unit 在 audit window 裡至少要有兩個以上預期 filesystem signals，比如 task archive、outbox、done JSON、primary artifact，才值得啟動 live monitor，如果低於這個 signal floor，A7 應該拒絕 spawn 或標記 degraded-confidence，好過硬上，這件事看起來雖然很小，但它是方法論上的轉折。
因為它承認了一件事：不是每個工作都適合被同一種監督方式觀察， 有些工作適合 live monitor，有些工作適合 post-hoc static audit，有些工作只需要 GM inspection，有些工作甚至只是人類看一眼就好。
這跟前面 dispatch mode 的判斷很像：不是選一個最強模式打天下，而是建立判斷標準，讓系統知道什麼情境該用什麼。
A7sus4 第一次真的抓到東西
A7sus4 scaffold 完、跑起來之後，他很快就不只是「看起來能跑」。
第一個 live audit cycle 是 PASS，三個 cycle、沒有 self-alert，驗證了 persistent monitor 的基本框架可行，而後面連續多次 audit 也產生了更細緻的訊號：有些是 PASS-with-deviation - 產出長度低於或高於 spec；有些是 PASS-with-anomaly - spec 本身不完整但 execution 滿足了列出的要求；也有 FAIL-silent-completion - stop-hook fired，但 primary artifact 沒有出現，這些都是 A7 要抓的那種「看起來完成了，但實際結果不在」的問題，同時，A7sus4 不只是判斷 pass/fail，他也開始把 deviation 分類。
如果一個任務沒有產出 artifact，那是 execution failure；如果 artifact 有產出，但 word cap 超過，是 deviation；如果 spec 說 6-section 但其實列了 7 個項目，Agent 滿足了 7 個列舉項，那問題不是 Agent 沒做好，而是 spec 寫得不一致；如果某個 wave 的長度一直偏離，但後來被修正，A7sus4 可以看到 streak broken。
這些都不是一般監控者會做的事，監控者通常會回報紅燈、黃燈、或綠燈，A7 回報的是：紅在哪？是執行錯誤、規格不完整、任務邊界模糊、還是系統性趨勢？需要現在修，還是進 team-review 變成方法論修正？
這就是我說 A7 是稽核者，不只是監控者的原因。
從 A7 發展出來的方法論
A7 的演化可以整理成一套建稽核 Agent 的方法論。
第一，不要從角色名稱開始建，從失敗資料開始建。
如果一開始說「我要做一個 auditing agent」，你很容易寫出一個抽象 spec：負責監控、負責驗證、負責報告，這些都沒錯，但離落地還有距離。A7 會變清楚落地，是因為累積了 silent failure、self-validation、SAA wait-mode、completion report 不足、skill drift、external-service footgun 這些實際案例，每一個案例都讓他多一個邊界、多一種判斷、多知道一件 Agent 不該做的事。
第二，把 capability、lifecycle、trigger/output 分開。
Log Audit / Cross-Agent Validation / Health Monitoring 是 capability，daemon / periodic 是 lifecycle，Role 1 / Role 2 / Role 3 是 operational mode，這三個軸一分開，設計就從「一個很大的 Agent」變成「一個可以分階段驗證、上線的系統」。
第三，稽核者必須 observe-only。
一旦 A7 直接修正被稽核的 Agent，他就失去了獨立性，除非你再建一個 A9 來稽核 A7，然後再建一個 A13 來稽核 A9，很快你就從輕快的曲風變成藍調爵士了的 Agent 疊疊樂了，所以 A7 的邊界要很清楚：observe、report、recommend，修正由 GM 和 Dm 做。
第四，Live monitor 要有 signal-density preflight。
不是所有任務都值得現場監督，訊號太少時，monitor 會變成等待者，等待者會開始編故事，或者直接退出，這不是 prompt engineering 可以完全解掉的問題，這是任務場景不適合那個監督模式。
第五，可以先建 production-precursor，不要假裝 prototype 沒有生產責任。
A7sus4 最漂亮的地方不是它先建了 Role 3，而是它承認自己不是 throwaway prototype，它會真的執行 audit duty，真的累積 lessons，真的有 retirement clause，等 A7 1.x 能接手且跑過 production audit cycle 才退場(我猜還要一個 A7sus2)，這比「先做個 prototype 看看」誠實得多，因為很多所謂 Prototype 最後都會活很久(把 Prototype 當做 Production 是另外一個問題，我們擇期再議)。
A7 想解決哪些事？
如果把 A7 用更落地的語言收斂，它想解決的是下面這五件事。
第一，讓 silent failure 變成 visible failure。
hook 沒觸發、inbox 沒產生、chain 沒接上、primary artifact 沒出現，A7 要把「沒有發生的事」變成可以被看見的訊號，因為看到做錯相對簡單，但是要看到原本該看到、卻沒看到的東西，有點難。
第二，讓自我驗證變成跨 context 驗證。
Dm 不應該永遠只由 Dm 驗證，C7 不應該永遠只由 C7 驗證，Em 不應該永遠只由 Em lint，至少在關鍵方法論、Agent scaffold、skill contract、wiki consistency 這些地方，需要有另一個 Agent 帶著另外一組 context 回頭看。
第三，讓團隊退化有趨勢資料。
跟第一項說的一樣，單次任務失敗容易看見，但慢慢變差很難看見，A7 要看這些慢慢的變化，correction 越來越多、completion 越來越薄、dispatch 越來越常重試、skill copy 越來越舊，這些趨勢是一個應該要注意的訊號。
第四，讓 GM 不用把所有監督責任扛在 context 裡。
GM 還是決策者，但 GM 不應該是唯一的檢查器。當 GM 既要對話、又要派工、又要讀產出、又要稽核趨勢，他的 context 會滿、會漏東西，而 A7 就是負責把觀察責任 artifact 化 讓 GM 做判斷，而不是搶著取代 GM 的眼睛。
第五，讓方法論可以從操作現場回流。
A7sus4 的 audit-history 裡每一次 PASS-with-deviation、每一次 anomaly、每一個 design lesson range，最後都會回到 Em wiki、Dm plan、A7 baseline dataset，這樣 Agent Team 的改進才不是靠人類記憶，而是靠現場的操作不斷把問題轉換成知識、然後變成機制。
不是把人移出 Loop，而是讓人看對地方
A7 最容易被誤解的地方，是它看起來像是把人類從 Human in the loop 裡移出去。
但其實剛好相反。
沒有 A7 的時候，人類要看所有東西，但是當所有東西混在一起，人類看起來很有掌控感，但其實只是被大量雜訊淹沒，所以 A7 的目標不是替人做判斷，而是讓人類不用在雜訊裡找訊號。
他把低階事件整理成 anomaly，把 anomaly 變成 finding，把 finding 送到正確的 channel：live bug 進 team-status，方法論洞察進 Em wiki，特定 dispatch 的觀察留在 work-log，這樣 GM 和人類看到的不是一片 log 海或 Finding 海，沒有厚度跟重要性，而是一組有分類、有證據、有來源的判斷入口。
所以 A7 不是「監督自動化」，而是「監督結構化」。
這其實也回到整個 Agent Team 系列最早的命題：我建的不是一群會自動做事的 Agent，而是一套讓 AI 協作可以被理解、被交接、被檢查、被修正的工作系統。
A7 是這套系統裡相對後期才長出來的 Agent，因為他需要前面所有東西先存在：要有 Agent 身份，才有身份載入錯誤；要有 dispatch，才有 chain break；要有 hook，才有 silent failure；要有 wiki，才有 knowledge drift；要有 Dm/C7/Em/G7 各自的產出，才有 cross-agent validation 的必要。
也因此 A7 不是 Agent Team 的起點更不是終點，而是 Agent Team 跨過 1.0、開始成熟後、才會需要的眼睛，因為一個真正會運作的 AI 團隊，不是看它能不能把任務做完，而是看它出錯的時候，系統裡有沒有人、或有沒有一個角色，能夠說出「這裡怪怪的，而且我知道怪在哪裡」，我相信 AI 的自動化，各個大廠都會有自己的答案卷，OpenAI 最近也持續把 Agents SDK 往 handoff、tracing、sandbox execution 這些生產化基礎設施推進，但找到中間的邏輯跟漏洞，你才能知道套用這些框架時，你該怎麼依照你的需求調整。
一個 Agent Team 的成熟，不是它不再犯錯，而是它開始有能力看見自己的錯。
而 A7，就是我為這件事留出來的位置。
參考資料
[1] OpenAI — The next evolution of the Agents SDK（2026-04-15；支持 Agents SDK 往 harness、sandbox execution、state rehydration 等生產基礎設施推進）
[2] OpenAI Agents SDK — Handoffs（官方文件；handoff 的 context / guardrail 邊界，支持「chain 不是有 handoff 就自然安全」）
[3] LangChain — AI Agent Observability: Tracing, Testing, and Improving Agents（2026；支持「single trace 不夠，production agent 需要 thread-level / multi-turn evaluation 與 continuous improvement loop」）
[4] arXiv — TraceSIR: A Multi-Agent Framework for Structured Analysis and Reporting of Agentic Execution Traces（2026-02-28；支持「raw trace 太長且難以直接診斷，需要結構化 trace analysis / report」）
[5] arXiv — AgentCollab: A Self-Evaluation-Driven Collaboration Paradigm for Efficient LLM Agents（2026-03-27；作為反面補充：self-evaluation 可作為 escalation signal，但不等於可以取代 cross-context audit）
[6] CrewAI Docs — Observability Overview（官方文件；支持 production agent 需要 monitoring、evaluation、debugging、cost 與 degradation tracking）
支持這個系列
如果這系列文章對你有幫助，考慮請我喝杯咖啡
請我喝杯咖啡
