前言¶
2026 年以來，Claude Code、Codex、Cursor 等終端編碼 Agent 迅速普及，開發者開始習慣「讓 Agent 寫代碼、開 PR、跑測試」。但當同一倉庫裏同時跑 3 個、10 個甚至 30 個 Agent 時，問題就不再是「模型夠不夠聰明」，而是分支互相踩、終端窗口找不到、CI 紅了沒人跟進、Review 評論不知道丟給哪個會話。
Composio 團隊在 2026 年 2 月將 Agent Orchestrator（簡稱 AO）開源，定位爲「並行編碼 Agent 的編排層」。項目在 GitHub 倉庫 composiohq/agent-orchestrator 上線後 star 數已突破 8700，官網 aoagents.dev 將其描述爲 meta-harness agent IDE——Agent 仍然負責寫代碼，AO 負責把多路並行工作管起來。
本文基於官方 README、文檔與官網公開信息，梳理 AO 解決什麼問題、架構如何設計、以及它與 Git Worktree、CI 自動反饋循環之間的關係。
它解決的是什麼問題¶
單開一個 Agent 終端並不複雜：切分支、貼 Issue、等它改完。難點出現在規模化並行：
- 每個任務需要獨立分支與工作區，避免文件互相覆蓋；
- 多個 tmux / 終端會話需要統一視圖，知道誰在跑、誰卡住了；
- PR 的 CI 失敗、Review 評論、合併衝突，必須路由回「寫這段代碼的那個 Agent」，而不是人工在 GitHub 和終端之間來回複製日誌；
- 任務結束後還要清理 worktree 和臨時分支。
官方文檔把上述手工協調概括爲 coordination nightmare。AO 的設計目標，是把「多 Agent 並行開發」變成可監督、可迴路的託管工作流：你描述結果，編排 Agent 拆任務、spawn 工人 Agent，只在需要人類判斷時推送通知。
Composio 官方博客提到，AO 最早源於用 bash 腳本管理少量 Claude Code 會話的實驗；穩定版編排器上線後，團隊內部曾達到「日均約 30 個 PR、全部人工 Review」的吞吐。項目本身也有大量代碼由 Agent 在 AO 管理的 worktree 中提交合並——這是其「自舉」敘事的一部分，但對我們讀者而言，更值得關注的是編排層抽象是否可複用。
核心工作流：從任務到合併¶
AO 的高層循環在 README 中寫得很清楚，可以概括爲六步：
- 在桌面 App 或 CLI 中添加要管理的 Git 項目；
- 爲某個 Issue 或任務啓動一個 Session（會話）；
- AO 爲該 Session 創建隔離的 Git Worktree（默認方案，也可切換爲完整 clone）；
- 在選定的 Runtime（默認 tmux，也可 Docker、Kubernetes、e2b 等）中啓動指定的編碼 Agent；
- 本地 Daemon 持續監聽 Session 狀態、終端活動、PR、CI 與 Review 事件；
- 桌面 App / CLI / 移動端 Kanban 展示全局狀態，必要時向對應 Session 發送跟進指令。
每個 Session 對應「一個 Agent + 一個任務 + 一個分支 + 通常一個 PR」，生命週期從 spawn 到 merge 或終止。Session 是臨時的，合併後可銷燬 worktree，避免倉庫裏堆滿陳舊分支。
CLI 側的典型入口（文檔示例）：
ao spawn my-project 123
其中 123 可以是 GitHub Issue 編號。編排器會創建 worktree、拉起 Agent，並把 Issue 上下文注入會話。
插件化架構：八類可替換插槽¶
AO 採用 TypeScript monorepo，核心思想是幾乎所有外部依賴都通過插件接入。官方文檔列出 8 個插槽（Slot）：
| 插槽 | 默認實現 | 常見替代 |
|---|---|---|
| Runtime | tmux | process、docker、kubernetes、ssh、e2b |
| Agent | claude-code | codex、cursor、aider、goose 等 |
| Workspace | worktree | clone、copy |
| Tracker | github | linear、jira |
| SCM | github | GitLab、Bitbucket（文檔稱後續支持） |
| Notifier | desktop | slack、discord、webhook、email |
| Terminal | iterm2 | web |
| Lifecycle | 內置 | 不可插拔 |
這種設計與 Composio 在 Agent 工具集成上的積累一致：編碼 Agent 本身繼續演進，編排層通過統一接口切換底層 CLI，而不綁死某一家模型或 IDE。
架構文檔還強調幾點工程取向：編排器無中心數據庫，用扁平 metadata 文件持久化狀態；Shell 調用走 execFile 而非字符串拼接的 exec；對外部輸入做校驗。對於要在本機長期跑多 Agent 的場景，這些細節直接影響安全與可調試性。
23 種 Worker Agent：Agent 無關的 Meta-Harness¶
AO 目前爲 23 種 Worker Agent Harness 提供適配器，官方 README 完整列表如下：
claude-code、codex、aider、opencode、grok、droid、amp、agy、crush、cursor、qwen、copilot、goose、auggie、continue、devin、cline、kimi、kiro、kilocode、vibe、pi、autohand
Review 環節單獨配置，當前支持的 Reviewer Harness 爲：claude-code、codex、opencode。
官網 slogan 是 If it runs in a terminal, it runs on Agent Orchestrator。對已經深度使用 Claude Code 或 Cursor CLI 的團隊，這意味着不必更換慣用工具，只需把「並行調度、隔離、CI 迴路」交給 AO。
各項目可以指定默認 Worker Agent 與 Orchestrator Agent（官網示例中二者均可設爲 Claude Code）。新 Session 創建時按項目配置拉起對應 CLI，工作流保持一致。
Git Worktree：並行不互踩的關鍵¶
多 Agent 並行最容易出事故的是共享工作目錄。AO 默認使用 Git Worktree 做 Workspace 隔離：
- 與主倉庫共享
.git目錄，創建速度快、磁盤佔用小； - 每個 Session 在獨立 worktree 裏 checkout 自己的 feature branch；
- 適合本地開發場景；若需要更強隔離，可切換爲完整
clone。
這與開發者手動 git worktree add 再開多個終端的思路一致，但 AO 把創建、綁定 Session 元數據、銷燬回收自動化，並與 PR / CI 狀態關聯。當多個 Agent 同時改同一倉庫的不同模塊時，worktree 避免了「A Agent 還沒 commit，B Agent 已經改了同一文件」的典型衝突。
CI 與 Review 的自動反饋循環¶
AO 被頻繁討論的特性，是 Reactions——對 CI 失敗、Review 請求變更、合併衝突等事件的自動化響應。
官方文檔示例（YAML 配置片段）：
reactions:
ci-failed:
auto: true
action: send-to-agent
retries: 2
escalateAfter: 2
changes-requested:
auto: true
action: send-to-agent
escalateAfter: 30m
approved-and-green:
auto: false
action: auto-merge
含義可以概括爲：
- CI 失敗：自動把失敗日誌發回擁有該分支的 Session，Agent 嘗試修復；連續失敗若干次後再通知人類；
- Review 請求修改：把評論路由給對應 Worker Agent；
- Approved + CI 全綠：可選自動合併（默認關閉，需顯式開啓）。
官網演示中的 Observer 流程是：GitHub 上 PR 檢查失敗 → AO 收到事件 → 定位 owning Session → Agent 打開相關測試文件繼續改。這相當於把「CI 紅 → 複製日誌 → 粘貼回 Agent」的手工循環產品化，也是 AO 區別於「單終端 Agent IDE」的核心價值之一。
Kanban 看板把 Session 分爲 Working、Needs you、In review、Ready to merge 等列，卡片上展示 Agent 類型、分支名、PR 狀態，降低並行規模擴大後的認知負擔。
安裝與使用方式¶
截至 2026 年 8 月，AO 推薦通過桌面應用安裝，支持 macOS（Apple Silicon / Intel）、Windows、Linux（AppImage）。安裝後指向本地 Git 倉庫即可，桌面版會自動拉起 Daemon，無需單獨配 CLI。
歷史 npm 全局包 @aoagents/ao 仍可用，但 README 標明 0.10.0 爲 npm 上的最終版本，新用戶應優先下載桌面構建。已有 CLI 用戶執行 ao start 會拉取與桌面版相同的構建。
移動端 App 可通過 LAN 或 Tailscale 與桌面配對，查看 Kanban、打開終端、接收「Needs you」推送——執行與代碼仍在本機，手機側主要是監督入口。
項目採用 Apache License 2.0 開源。Electron 渲染進程會向 PostHog 發送匿名使用事件（可通過構建時清空 VITE_AO_POSTHOG_KEY 關閉），使用前若對 telemetry 有要求可閱讀 docs/telemetry.md。
與 Cursor、Claude Code 等工具的關係¶
不少開發者會問：我已經用 Cursor 或 Claude Code，還需要 AO 嗎？
官方 FAQ 的定位是：單 Agent、單終端場景不一定需要編排層；當你要在同一倉庫並行處理多個 Issue、並希望 CI / Review 自動回到對應 Agent 時，AO 纔有明顯收益。Cursor、Claude Code、Codex 等是執行層；AO 是艦隊調度層，二者是互補而非替代。
2026 年 Agent 工具鏈正在分層：模型與編碼 CLI 在下層競爭，Worktree 隔離、PR 生命週期、事件驅動 Reactions 在上層沉澱爲可複用基礎設施。AO 的 GitHub star 增速，反映的是社區對「並行 Agent 工程化」需求的共識，而不只是又一款 AI 編輯器。
小結¶
Agent Orchestrator 把並行編碼 Agent 的關鍵難題——隔離、可視、迴路、生命週期——收斂到一個開源編排 IDE 中：23 種終端 Agent 通過插件接入，默認 Git Worktree 保證分支互不干擾，Reactions 把 CI 失敗與 Review 評論自動送回正確的 Session。
若你已經在用 Claude Code、Codex 或 Cursor CLI 處理日常開發，但仍在用 spreadsheets 或人肉記「哪個終端對應哪個 PR」，值得本地試跑 AO，評估它能否把你的 Agent 艦隊從「能跑」推到「能合併」。源碼與文檔：
- GitHub：https://github.com/composiohq/agent-orchestrator
- 官網與文檔：https://aoagents.dev/
