如何打造長期運行的 Multi-Agent 工程系統 (Building Multi-Agent Engineering Systems)

原始來源與檔名：20260512_2026-05-12T093124+0800-如何打造 Multi-Agent 工程系统.md

來源：[[@SaitoWu]] / X (Twitter) — 2026-05-10 原始檔名：2026-05-12T093124+0800-如何打造 Multi-Agent 工程系统.md

NAPKIN | 餐巾紙

餐巾紙公式

Long-running Agent = Orchestrator (Plan + Contract) + Workers (Implement) + Validators (Adversarial Testing) + Structured Handoff The Bitter Lesson of Agents = Keep orchestration logic in Prompts/Skills, NOT hard-coded in Python.

軟體工程的瓶頸已不再是 AI 的智商，而是「人類的注意力」。單一 Agent 只能做短任務，而 Factory 的 Missions 系統展示了如何讓一個 Agent 團隊連續跑上 30 天來完成大型代碼遷移。核心秘訣在於：在寫代碼前先定義「驗證契約 (Validation Contract)」；用全新的 Agent 來進行對抗性測試；以及強制執行「結構化交接 (Structured Handoff)」來防止上下文在長線任務中漂移。

一句話

本文總結了 Factory 核心開發者 Luke 關於建構 Multi-Agent 系統的深度演講。文章首先梳理了多 Agent 協作的五種模式，接著詳細解剖了 Missions 系統的架構（Orchestrator、Workers、Validators）。其最核心的洞見在於：多天任務不能依賴記憶，必須依賴「結構化交接」與「提前定義的驗證契約」；且系統應採用「串行主幹 + 局部並行」而非全並行，以避免代碼庫衝突。

餐巾紙草圖

[The Missions Architecture for Long-running Tasks]

[ Orchestrator ] -> Creates: 1. Plan  2. Validation Contract (Must exist BEFORE coding)
       |
[ Worker 1 ] -----> Implements feature -> Fills out [ Structured Handoff ]
       |
[ Validator ] ----> (Adversarial) Runs tests & Code Review Agent -> Fails? -> Spawns Follow-up
       |
[ Worker 2 ] -----> Reads Handoff (Clean state) -> Implements next feature

* Avoid Full Parallelism: Keep Trunk Serial, but make read-only tasks (Search, Review) Parallel.

ROUND 1: SKELETON | 骨架掃描

“這篇文章在說什麼”

• 五種協作模式: Delegation (委派), Creator-Verifier (創造者與驗證者), Direct Communication (直接溝通), Negotiation (協商), Broadcast (廣播)。
• Missions 角色:
  • Orchestrator: 不寫代碼，只負責拆解目標，輸出 Plan 和 Validation Contract (驗收標準)。
  • Workers: 拿到乾淨上下文後寫代碼。
  • Validators: 嚴格驗證。
• 提前驗證 (Validation Contract): 這是系統不漂移的關鍵。驗收標準必須在寫代碼前就定好，避免「測試遷就實作」。
• 對抗性驗證: Scrutiny Validator 啟動一個沒參與過實作的 Code Review Agent；User Testing Validator 用 Computer Use 實際點擊頁面。兩者都沒有沉沒成本。
• 結構化交接 (Structured Handoff): 任務交接不能靠歷史對話，必須填寫交接單（做了什麼、exit code 是多少、留下什麼問題）。
• 架構取捨:
  • 不做全並行，採用「Serial 主幹 + 局部並行」避免 Git 衝突。
  • 擁抱 Bitter Lesson：將控制邏輯寫在 Prompt + Skills 裡（僅 700 行文本），而不是硬編碼在系統狀態機裡，這樣模型變強時系統才能跟著變強。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

核心論證鏈

1. 長期任務的致命傷是「狀態碎片化」與「上下文漂移」: 讓 Agent 之間自由聊天 (Direct Communication) 看似智能，實則是災難，因為沒有單一的 SSOT (單一真相來源)。Missions 透過「結構化交接」強制將狀態從對話流中抽離，變成文件。這印證了我們在《Agent Harness Engineering》中學到的：狀態必須落地到檔案系統。
2. 對抗性驗證 (Adversarial Validation) 打破了沉沒成本: 如果讓寫代碼的 Agent 自己寫測試，它會傾向於掩蓋錯誤（Sunk cost bias）。Factory 故意 spawn (生成) 具有全新上下文的 Agent 來擔任 Reviewer 和 QA，這是極致的軟體工程紀律在 AI 領域的投射。
3. 擁抱 Bitter Lesson (苦澀的教訓): 這是整篇演講最具哲學高度的一段。如果你把路由、交接判斷寫死在 Python 的 if-else 裡，當 GPT-6 出來時，你享受不到它的智力紅利。把「協作協議」寫在 Prompt 裡，讓大模型自己判斷邊界，這才是與 AI 共同演化的正確姿態。

關鍵證據

• 講者 Luke 提到最長的 Mission 已經跑了 16 天，目標是 30 天。並在從零構建 Slack Clone 的真實案例中，達到了 50% 的測試代碼比例與 90% 的覆蓋率。這些數據證明了該架構並非紙上談兵。

邊界條件

• 這種架構極度依賴模型的推理與指令遵循能力，且 Token 消耗驚人。講者也承認必須大量依賴 Prompt Caching 技術，否則 16 天的運行成本將無法承受。

ROUND 3: SOUL | 靈魂提取

“還能怎么用”

• 知識連結: 完美融合了《Agent Harness Engineering》(腳手架) 與《從 OpenClaw 到 Hermes》(能力路由與記憶隔離)。這篇文章給出了多 Agent 協作的最佳實踐藍圖。
• 深層洞見: “软件工程的瓶颈已经不再是智能，而是人类注意力。” (The bottleneck in software engineering is no longer intelligence, but human attention.) 人類不該再幫 Agent 擦屁股或 debug 它的中途錯誤。人類的角色應該上升到：定義問題邊界 (Scope)、簽署驗證契約 (Sign Contract)、以及最終驗收。
• 行動呼籲: 在你的下一個 Agent 專案中，實作一個簡單的 Creator-Verifier 模式。不要用同一個對話框讓 AI 寫程式又自己檢查。開兩個獨立的對話框，一個寫代碼，把代碼複製給另一個，並賦予第二個 AI「嚴苛審查員」的角色。你會立刻感受到產出品質的飛躍。