多代理系統實戰！揭秘生產級 AI 架構「Missions」
三句話摘要
Factory 工程師 Luke Alvarero 揭示 AI 軟體開發的真正瓶頸是人類注意力，並介紹其 Missions 多智能體架構如何讓 AI 團隊連續自主運作 16 天。 AI 軟體開發的競爭優勢不在模型有多聰明，而在能否設計出一套「乾淨上下文 + 事前驗證合約 + 強制交接日誌」的管理架構，讓 AI 團隊在人類睡覺時也能用比人類更嚴苛的標準自主推進並修復專案。 人類注意力才是 AI 開發的天花板。 Alvarero 指出，AI 變強並不能直接轉化為生產力，因為每個決策仍需人類審核。50 個 AI 同時等待指示，等同於把人類主管壓垮，問題不在 AI 不夠聰明，而在人類管不過來。
重點整理
重點- 1
人類注意力才是 AI 開發的天花板。 Alvarero 指出，AI 變強並不能直接轉化為生產力，因為每個決策仍需人類審核。50 個 AI 同時等待指示，等同於把人類主管壓垮，問題不在 AI 不夠聰明，而在人類管不過來。
- 2
並行執行是陷阱，串行才是正解。 多個工作者同時修改同一程式庫，會導致互相踩踏變更、產生不一致架構決策，後期協調成本遠超速度優勢。Missions 嚴格規定任何時間點只有一個智能體在改變程式碼狀態，讀取操作才允許並行。
- 3
驗證合約在程式碼撰寫前就必須定義。 傳統的「寫完再測試」讓 AI 根據自己寫的錯誤邏輯生成測試，形同包庇。Missions 由協調者在任務開始前依照商業邏輯寫好嚴格斷言，驗證者在完全沒看過原始碼的狀態下執行，實現天生對立的查核機制。
- 4
模型指揮術打破單一模型迷思。 不同角色使用不同廠商的模型：協調者用嚴謹推理型（如 Claude Opus、OpenAI o1）、工作者用高速編程型、驗證者刻意採用不同廠商模型以避免集體盲點，同時規避供應商鎖定風險。
實用技巧與重點
乾貨- 具體數據：
- 複製 Slack 企業通訊軟體，AI 連續自主運作 16 天
- 最終程式庫中 50% 的程式碼專門用於測試
- 整體測試覆蓋率達 90%
- 架構控制邏輯由約 700 行 prompt 驅動
- 新功能實作幾乎從未在第一次驗證階段通過（一次過率接近零）
- 人類 5 人團隊透過此架構可同時管理 30–50 個工作流
- 架構運作時耗時最長的是等待伺服器啟動與界面渲染，非等待 AI 生成
- 工具與模型：
- Factory 公司開源 coding agent：Goose
- 高階規劃推薦模型：Claude Opus、OpenAI o1
- 架構名稱：Missions
- 版本控制工具：Git（工作者透過 Git commit 提交變更）
- 用戶測試驗證環境：無頭瀏覽器（headless browser）
- 五種多智能體互動框架：
- 偽派 — 主管指派跑腿任務
- 點分離 — 獨立驗證者找茬
- 直接溝通 — AI 互發私訊（陷阱，導致狀態碎片化）
- 協商 — 非對立方式協調共享資源修改
- 廣播 — 強制發布全局狀態更新
- Missions 三角色機制：
- 協調者：制定計畫、寫驗證合約、分派任務、根據交接日誌重新規劃
- 工作者：接收單一任務規格、執行完畢後立即銷毀（乾淨上下文）
- 驗證者：從未看過原始碼、執行真實用戶行為測試、寫結構化交接日誌
- 結構化交接日誌必須包含：
- 執行的指令
- 退出代碼
- 具體錯誤訊息
- 嘗試過的修復方法
結論
結論“AI 軟體開發的競爭優勢不在模型有多聰明，而在能否設計出一套「乾淨上下文 + 事前驗證合約 + 強制交接日誌」的管理架構，讓 AI 團隊在人類睡覺時也能用比人類更嚴苛的標準自主推進並修復專案。”
完整解析
詳細現今 AI 開發工具的進步速度讓人不禁幻想，只要下幾個指令就能在睡覺時讓 AI 生出一個完整產品。但 Factory 公司核心智能體基礎設施負責人、開源 coding agent Goose 的開發者 Luke Alvarero，在一場演講中打破了這個幻覺。他指出，問題的根源不在 AI 不夠聰明，而在人類的注意力容量根本追不上 AI 的輸出速度。他用一個比喻說明：你手下突然多了 50 個永不睡覺的天才實習生，聽起來很美，但每個決策、每行關鍵程式碼都要回頭問你，你的大腦在審查幾個之後就徹底癱瘓，剩下的 49 個只能空轉。傳統「一個 AI 搞定一切」的單智能體模式，在稍微複雜的任務前就會這樣崩潰。
Alvarero 將多智能體的演進整理為五種互動框架：偽派（主管指派跑腿）、點分離（引入獨立驗證者）、直接溝通（AI 互傳私訊，但這是陷阱）、協商（共享資源的非對立交易）、廣播（強制同步全局狀態）。Factory 舍棄了最危險的直接溝通，將其餘元素整合成 Missions 架構。架構的核心是三個界線極度分明的角色：協調者負責高階規劃，完全不寫程式碼；工作者負責執行，任務完成後立即銷毀；驗證者負責找茬，且刻意設計成從未看過工作者的原始碼。工作者每次只拿到當次任務的規格，如同剛睡醒的工程師，完全沒有過去失敗的記憶包袱，透過 Git commit 提交變更後立即退場。這種物理上的隔離從根本消除了 AI 對話拉長後「忘記前面說了什麼、鬼打牆」的注意力衰退問題。
驗證環節是整套架構最具突破性的部分。傳統做法是「先寫程式再補測試」，但 AI 寫測試時會順著自己已知的（可能有誤的）邏輯去塑形，形同球員兼裁判。Missions 要求協調者在任何一行程式碼被寫出來之前，就根據人類的商業邏輯寫下嚴格的驗證合約與斷言（例如「點擊此按鈕後畫面必須出現紅色警告框，否則測試直接失敗」）。驗證者拿著合約、在對原始碼毫無感情的狀態下，甚至在無頭瀏覽器中真實點擊按鈕、填寫表單、等待頁面渲染，模擬真實用戶行為。實測數據顯示，整個架構運作時耗時最長的環節，根本不是等待 AI 生成程式碼，而是等待伺服器啟動與界面渲染。此外，Missions 強制要求所有智能體無論成敗都必須留下結構化交接日誌，詳細記錄執行的指令、錯誤訊息與嘗試過的修復方法，讓協調者可以在遇到死胡同時重新評估並分派修正任務，賦予系統自我修復能力。
在模型選用策略上，Alvarero 提出「模型指揮術」：協調者需要嚴謹推理，適合 Claude Opus 或 OpenAI o1 等思考型模型；工作者需要速度，選用高速編程專化模型；驗證者則刻意選用不同廠商的模型，因為訓練資料庫不同、找 bug 的邏輯有微妙差異，能大幅提升抓錯率，同時也避免了供應商鎖定的風險。最讓人驚豔的是抗淘汰設計：整個架構的控制邏輯不寫死在程式碼中，而是由約 700 行 prompt 驅動。當更強的新模型出現，只需接上新的 API，架構自動升級，不會被任何特定模型的時代局限所束縛。實戰中，Missions 連續自主運作 16 天，從零建構出功能完整的 Slack 複製版，最終測試覆蓋率達 90%，且幾乎每個新功能都在第一次驗證時失敗——然而這恰恰證明了系統的強韌：錯誤被即時攔截修復，而非積累到第三天讓專案全面崩潰。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
