前言¶
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/
