# 策展 · X (Twitter) 🔥🔥🔥

> 作者：Saito (@SaitoWu) · 平台：X (Twitter) · 日期：2026-05-11

> 原始來源：https://x.com/SaitoWu/status/2053423773332947153

## 中文摘要

軟體工程瓶頸轉為注意力不足，Luke 分享 Agent 團隊解複雜任務。

Luke 在演講中強調，軟體工程的瓶頸不再是模型智慧不足，而是人類注意力有限；頂級工程師一天僅能推進少數任務，卻面臨 50 個功能、20 個 bug、10 個 migration 及遺留系統清理等龐大 backlog。他從 Block 孵化 Goose 項目（現捐給 Agentic AI Foundation），現於 Factory 負責核心 Agent harness，目標讓軟體開發生命週期逐步走向自治。聽完 20 分鐘演講，使用者應能組裝 Agent 團隊，運行數天完成單 Agent 無法勝任的複雜軟體工程任務。

**多 Agent 協作五種模式**  
多 Agent 框架混亂，Luke 先提出分類 taxonomy，將協作拆為五種典型模式：  
- Delegation：父 Agent 派生子 Agent，例如主 Agent 發現需資料庫設計，即派子 Agent 專責 schema 設計，這是最常見模式。  
- Creator-Verifier：一 Agent 寫程式碼，獨立 Agent 審查，解決 sunk cost bias（寫碼 Agent 易為自身實現辯護，獨立驗證者無此心理負擔，更易發現問題）。  
- Direct Communication：Agent 間直接聊天，但易致狀態碎片化，無單一真相來源，導致「每個 Agent 都以為自己知全局，實則無人知曉」情況。  
- Negotiation：多 Agent 圍繞共享資源（如同一 API、模組、程式碼段）協商，非互相阻塞，而是尋正和解。  
- Broadcast：一 Agent 向全體推送新約束、狀態更新、計劃變更，對長期任務關鍵，避免上下文漂移。  
Factory 的 Missions 系統即組合這些模式，形成長期運行閉環。

**Missions：Agent 生態系統而非單一 Session**  
Missions 非延長 Agent Session 或硬擴上下文視窗，而是多角色、共享狀態、結構化交接及驗證機制的 Agent 生態系統。包含三核心角色：  
- Orchestrator（指揮官）：在對話中 scope 需求、提戰略問題，將模糊目標轉為可執行計劃；在寫碼前輸出 Plan（執行方式）及 Validation Contract（Done 定義）。  
- Workers（工人）：獲乾淨上下文實現具體特性，完成後提交 Git Commit，下 Worker 繼承乾淨程式庫，而非混亂聊天記錄。  
- Validators（驗證者）：嚴格驗證任務完成，不幫圓場。  
關鍵創新：Validation Contract 於規劃階段提前定義，可能含數百條獨立斷言，每特性綁定對應斷言；里程碑須證明斷言覆蓋，而非「看起來差不多」，避免傳統 Agent 寫完碼再補測、測驗遷就實現。

**驗證體系防長期任務漂移**  
Agent 寫碼最大問題非首步失誤，而是長期任務漂移：初始正確，漸偏離，測試遷就實現，最終忙碌卻遠離目標。Missions 驗證體系解決此問題，分兩類：  
- Scrutiny Validator：跑測試、類型檢查、Lint，為每特性 spawn 獨立 Code Review Agent（全新上下文，未參與實現，如真外部 reviewer）。  
- User Testing Validator：如 QA 用 Computer Use 真實點擊頁面、填表、走完整流程，非僅看碼，而是驗證產品可用性。  
兩類驗證皆對抗性，無 sunk cost，不偏向實現者。Luke 指出，驗證佔大部分 wall clock time，但換取長期正確性；最長 Mission 已跑 16 天，目標 30 天。

**結構化 Handoff 取代記憶依賴**  
長期任務（數天至十數天）最大風險為資訊遺失，Missions 強調結構化 Handoff：Worker 完成特性後須填交接單，記錄完成內容、遺留項目、運行命令及 exit code、發現問題、是否遵守 Orchestrator 流程。此繁瑣流程解決致命問題：系統靠結構化記錄而非記憶運行。里程碑邊界檢查所有 handoff，未解問題自動創 Follow-up Features，拉回正軌，形成自癒機制。Luke 強調，核心非更大 prompt，而是強交接與驗證紀律。

**Serial 主幹 + 局部並行策略**  
早期全並行嘗試失敗，因衝突、重複勞動、架構不一致，合併修復成本爆炸。Missions 採克制策略：  
- 特性層串行：同一時間僅一 Worker 及 Validator 推進主幹，確保程式庫演化連續、可理解。  
- 只讀操作並行：如程式碼搜尋、API 調研、Code Review，不改主幹，收益高風險低。  
類似真實工程團隊：核心架構順序開發，調研審查並行；追求長期正確性復利，而非表面最大併發。

**Mission Control 儀表盤支援多天任務**  
傳統聊天視窗不適多天任務，Factory 建 Mission Control 儀表盤，顯示即時 Worker 動作、Handoff 摘要、下步計劃、完成度、token 預算消耗。支援完全非同步，使用者可睡覺、社交、開會，系統續跑；回來見結構化狀態：當前位置、完成項目、卡點、下步，而非長聊天記錄。此區別 Agent harness（任務運行系統）與普通 Chatbot（對話介面）。

**模型選擇：Droid Whispering**  
Luke 稱模型選擇為 Droid Whispering（形象比喻調教機器人）。無萬能模型：Planning 需慢思強模（戰略拆解、約束設計）；Implementation 需碼流暢、創造力強模（快速落地）；Validation 需精準遵指令模（嚴格依驗收契約）。建議角色用不同 Provider 避同源偏差；結構化架構讓開源模表現佳，因 Validation Contract、里程碑檢查、Handoff 提供紀律，非全靠模型「自觉」。

**真實案例：從 0 建 Slack Clone**  
從零建 Slack Clone，60% 時間與 token 花 Implementation，但 Validation 罕一次通過，自動創 Follow-up Features 修復推進。最終程式碼 50% 為測試，覆蓋率超 90%；Agent 非產更多碼，而是驗證驅動下產可維護程式庫。大量用 Prompt Caching 控成本。企業用法：一夜原型新特性、大型 Refactor 或 Migration、現代化老程式庫，讓後續 Agent 易接手。此類任務單 Agent 最易崩（週期長、依賴多、上下文複雜、驗證難），Missions 拆為可交接、可驗證、可恢復長期執行流。

**架構哲學：擁抱 Bitter Lesson**  
Luke 取捨未硬編複雜狀態機，大量邏輯寫於 Prompt + Skills，全系統僅約 700 行文本。因擁抱 Bitter Lesson：模型升級時系統自動變強；若智能寫死碼中，模型強化無紅利。保留薄硬邏輯（如 Handoff 檢查、阻塞條件、里程碑邊界），智能留給模型。此為未來 Agent harness 方向：確定邏輯管邊界紀律，模型管判斷執行。

**改變軟體工程經濟學**  
Missions 變團隊吞吐模型：5 人團隊原推 10 工作流，今可推 30，非人類 3 倍努力，而是從執行解放，轉高槓桿：架構判斷、產品決策、驗收標準、優先排序。執行、驗證、交接、自癒交系統；人類定方向與關鍵判斷。產出程式庫非越髒越亂，反更乾淨，因留測試、結構、Skills、Handoff、驗證契約，形成正向飛輪，後續 Agent 易續。

**一句話總結與建議**  
Missions 組合 Delegation、Creator-Verifier、Broadcast、Negotiation、結構化 Handoff 及 Validation Contract，將「人類定義需求」與「系統自主多天執行」徹底解耦；人類管 scope、計劃、驗收、決策，Agent 團隊管實現、驗證、交接、修復。此為 multi-agent 真價值：非 Agent 聊天室閒聊，而是可運行、可驗證、可恢復生產系統。Luke 建議試 [Open Droid](https://opendroid.ai)/missions，先與 Orchestrator 爭 Scope、審 Plan，即可放手；未來直覺「不同模型長期高压任務協同」者，將領創新。

## 標籤

Agent, 產業趨勢, Harness, Goose, Factory, Agentic AI Foundation