# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Factory (@FactoryAI) · 平台：X (Twitter) · 日期：2026-04-10

> 原始來源：https://x.com/factoryai/status/2042671155191173532

## 中文摘要

Factory.ai 推出 Missions 架構，透過拆解任務解決 AI Agent 上下文限制。

Factory.ai 提出的「Missions」架構旨在解決單一 Agent 處理複雜專案時，因上下文視窗過載導致效能下降的問題。透過將大型任務拆解為具備明確目標、獨立 Agent 與嚴格驗證的單元，該系統實現了更可靠的自主開發流程。

**核心痛點與設計哲學**
原文指出，Agent 對上下文高度敏感，且其推理過程是累加的，這導致了兩個關鍵失效模式：
- 無關上下文累積：任務範圍越廣，Agent 的上下文就充斥越多與當前目標無關的資訊，導致效能下降。
- 對抗性上下文累積：Agent 傾向於確認自己先前的工作，這使其在客觀評估自身產出時表現不佳，產生「確認偏誤」。
Missions 的設計核心在於「關注點分離」，確保每個 Agent 的軌跡始終指向單一目標，避免無關資訊干擾，並透過引入獨立的驗證機制來克服自我評估的偏誤。

**系統角色與分工**
為了確保 Agent 不會偏離目標，系統將任務拆解為三種明確角色：
- Orchestrator (編排者)：負責規劃、拆解需求並引導執行，不直接參與細節實作或驗證，僅在里程碑處注入驗證機制。
- Workers (執行者)：負責實作具體功能，遵循「測試優先」原則，直到認為工作正確後交出成果。
- Validators (驗證者)：獨立評估完成的工作，負責發現錯誤與缺漏，但不負責修復，而是將問題回饋給 Orchestrator 進行後續處理。

**測試驅動開發與狀態管理**
Missions 在兩個層級應用測試驅動開發（TDD）哲學：
- 在 Worker 層級：先寫測試再寫程式碼，確保測試反映預期行為而非實作細節。
- 在 Mission 層級：Orchestrator 在定義功能前，先建立「驗證合約」（Validation Contract），即定義成功的行為斷言。
此外，系統採用「外部化狀態」，將完整資訊分佈在驗證合約、功能列表、研究筆記與操作指南等共享資產中，避免單一 Agent 必須承載所有資訊，確保每個 Agent 僅讀取與當前工作相關的內容。

**實際執行流程**
當使用者發起任務後，Orchestrator 會進行需求釐清，建立驗證合約，並將任務拆解為具備里程碑的功能單元。系統透過程式化執行器啟動 Worker，每個 Worker 都在全新的上下文環境中運作。完成後，由 Validator 進行黑箱測試與品質審查，若發現問題，Orchestrator 會生成修復功能，直到通過驗證。

**實際成效與數據分析**
以開發 Slack 複製版為例，Missions 展現了高度的穩定性：
- 歷經 6 個里程碑，驗證環節佔總執行時間的 37.2%。
- 產出 38.8k 行程式碼，其中 52.5% 為測試程式碼，語句覆蓋率達 89.25%。
- 透過 81 次驗證發現的問題，Orchestrator 生成了 21 個修復功能（佔實作工作量的 34.4%），顯示出穩定的修正迴圈。
- 執行軌跡保持在受控範圍內，實作與驗證的中位數長度分別為 51 與 30 個助理回合。

**未來展望**
Missions 代表了軟體開發閉環系統的初步嘗試。隨著模型在推理、規劃與電腦使用能力的提升，這種架構將能處理更具野心的專案，並透過更頻繁的驗證循環，進一步提升自主開發的可靠性。目前該系統已開放使用，使用者可透過在 Droid 視窗輸入 `/missions` 啟動。

## 標籤

Agent, 新產品, Factory.ai