AI Engineer Europe 2026 · 演講 · 2026-05-06 · 19 分
讓多代理跑上好幾天的 Missions 架構
The Multi-Agent Architecture That Actually Ships · Luke Alvoeiro，Factory
Luke 拆解 Factory 的 Missions：用 orchestrator、worker、validator 三種角色，加上先寫好的驗收條件與結構化交接，讓 agent 團隊連跑數日。
概要
- 瓶頸是人的注意力Luke 認為軟體工程現在的瓶頸不是智慧，而是人能監督的任務數。工程師手上可能有 50 個功能的 backlog，卻只能同時推進幾個，因為每個任務都要人看、每個 commit 都要人審。
- 五種多代理策略Luke 把這個領域整理成 delegation、creator verifier、direct communication、negotiation、broadcast 五種。Missions 組合了其中四種：delegation、creator verifier、broadcast 與 negotiation。
- 三種角色分工orchestrator 負責規劃，worker 負責實作，validator 負責驗證。每個 worker 都從乾淨的 context 開始，做完用 Git commit，下一個 worker 接手一個可運作的程式碼庫。
- 驗收條件先於程式碼validation contract 在規劃階段、動工之前寫好，獨立於實作定義什麼叫正確。Luke 的理由是，實作之後才寫的測試只是在確認既有決定。
- 序列執行，局部平行他們試過讓十個 agent 同時跑，但 agent 會互相踩到修改、重複工作。Missions 同一時間只跑一個 worker 或 validator，只有搜尋程式碼、研究 API、code review 這類唯讀工作才平行。
- 規則寫在提示，不寫死在程式為了不被下一代模型淘汰，大部分 orchestration 邏輯放在 prompt 與 skills 裡，Luke 說拆解功能與處理失敗的邏輯大約 700 行文字。
原話
▶ 00:58“The bottleneck in software engineering nowadays is not intelligence.”
軟體工程現在的瓶頸不是智慧
▶ 06:09“Tests written after implementation don't catch bugs they confirm decisions”
實作之後才寫的測試抓不到 bug，只是在確認既有決定
▶ 07:56“Critically, neither validator has seen the code before.”
兩種 validator 都沒看過這份程式碼
▶ 08:48“Not by hoping that agents remember what happened, but by forcing them to write it down and then actually address issues.”
不是指望 agent 記得發生過什麼，而是逼它們寫下來，再真的處理問題
▶ 10:01“This is serial execution with targeted internal parallelization.”
這是序列執行，加上有針對性的內部平行化
延伸
- Luke 說他們跑過最久的一個 mission 連跑了 16 天，比一個完整的 sprint 還長。
- 各角色的預設模型是做出 Missions 原型的工程師 Theo 定的，但 Luke 鼓勵使用者依專案自己調整，也說靠 validation contract 與里程碑檢查點，用 open weight 模型也能把 mission 跑得很順。
- Luke 在結尾列出還沒解的問題：怎麼讓 Missions 進一步平行化，以及怎麼把 Missions 本身再編排成更複雜的流程。
章節
點時碼直接跳到原片的那一段。
- 開場與背景Luke 說明目標，是讓聽眾學會組出能完成更難任務的 agent 團隊，並簡述自己從 Block 的 Goose 到 Factory 的經歷。
- 瓶頸在人的注意力模型夠聰明，缺的是監督的頻寬，所以他們想做出人只負責決定、系統自己想辦法完成的做法。
- 五種多代理策略領域各說各話，Luke 提出 delegation、creator verifier、direct communication、negotiation、broadcast 五分法並逐一說明。
- Missions 的組成用描述目標、對話釐清範圍、核准計畫三步，把四種策略合成一個能跑數小時到數日的流程。
- 三種角色orchestrator 產出功能、里程碑與 validation contract，worker 以乾淨 context 實作，validator 驗證行為是否端到端可用。
- validation contract實作後才寫的測試會被程式碼牽著走，所以先在規劃階段寫下可能多達數百條的斷言，每個功能都要滿足其中幾條。
- 兩種 validator一種跑測試、型別檢查、lint 並派 code review agent，另一種像 QA 工程師操作實際跑起來的應用；兩者都沒看過程式碼。
- 結構化交接worker 完成後要填寫做了什麼、沒做什麼、遇到什麼問題，錯誤在里程碑邊界被抓到，補做的工作再被排進去。
- 為什麼不平行平行跑 agent 會互相衝突、做出不一致的架構決定；Missions 改成序列，只在唯讀工作上平行。
- Mission Control長時間任務需要看得到進度與已用預算的專屬介面，也看得到目前的 worker 與交接摘要。
- 讓對的模型坐對的位置規劃、實作、驗證各自適合不同特性的模型，Luke 稱這項新技能為 droid whispering，並建議驗證可換不同供應商。
- Slack clone 範例與用途以建一個 Slack 複製品為例：實作佔了 60% 的時間與 token，驗證從來沒有一次就過、幾乎都要補做功能，最後 50% 的程式碼行數是測試、覆蓋率 90%。企業則拿來做原型、內部工具、大型重構與遷移。
- bitter lesson為了讓系統隨模型進步而變強，編排邏輯放在 prompt 與 skills，系統只管 bookkeeping 與紀律。
- 效益與收尾五個工程師的團隊原本能同時推進 10 條工作流，有了 Missions 也許能到 30 條；Luke 回扣五種策略，並邀請聽眾試跑 slash missions。
名詞
- Missions
- Factory 的多代理系統，把目標、計畫、執行與驗證串成可連跑數小時到數日的流程
- orchestrator
- 負責規劃的角色，會對使用者釐清需求，產出功能、里程碑與 validation contract
- worker
- 負責實作的角色，以乾淨 context 做一個功能，完成後用 Git commit 並填交接單
- validator
- 負責驗證的角色，分 scrutiny 與 user testing 兩種，都沒看過程式碼
- validation contract
- 規劃階段、動工之前寫好的驗收斷言集合，獨立於實作定義什麼叫完成
- structured handoff
- worker 完成功能後填的紀錄，含做了什麼、沒做什麼、遇到的問題與是否遵守流程
- Mission Control
- 為長時間任務做的專屬畫面，看進度、預算消耗、目前的 worker 與交接摘要
- droid whispering
- Factory 內部對「在腦中模擬不同 LLM 如何互動與失敗」這項技能的稱呼
- Goose
- Luke 在 Block 發起的開源 coding agent，已捐給 agentic AI foundation
