给 AI 编程团队配个“项目经理”:Agent Orchestrator 能拆任务、派 Agent,还能跟进 PR

摘要：Agent Orchestrator 把项目规划、任务分派、独立工作区和 PR 跟进放在一个桌面工作台里。多个编程 Agent 一起开工时，开发者能集中查看进展，处理测试失败和审查反馈。

同时让 Claude Code 写接口、Codex 改页面，代码在往前走，你却得来回找分支、盯测试、转发审查意见。Agent Orchestrator 把这些工作放进一个桌面工作台：项目级 Agent 规划和分派任务，执行 Agent 各自在独立目录里干活。如果你已开始并行开发，可以用它集中跟进任务，判断哪里还需要自己介入。

Agent Orchestrator 简称 AO，是一个开源项目。官方把它的用途概括为：在同一个地方规划、运行和监督编程 Agent。标题里的“项目经理”，对应的就是它的项目级编排 Agent。

先把任务拆明白，再让 Agent 开工

假设你准备给现有网站加一个数据看板：后端要补接口，前端要做筛选和图表，还得覆盖异常情况。把同一句需求发给几个 Agent，它们可能各自做出一套字段定义，等到联调时才发现对不上。

AO 的项目编排 Agent 可以先参与需求讨论，结合仓库内容和当前任务状态，梳理目标、约束、优先级和实现顺序。它有项目范围的持续对话，能保留之前讨论过的决定，后续规划也能参考正在工作的 Agent、PR 和审查状态。

计划明确后，它可以创建执行任务，把相关上下文和分工传给对应的 worker。worker 可以理解为一条独立的执行任务：由选定的编程 Agent 负责实现、测试、提交代码和创建 PR。规划与协调有自己的位置，每项改动也有可追踪的负责人。

官方演示里，编排 Agent 一次创建了 5 个 worker，分别负责接口契约、持久化、界面集成、测试和文档，并传递了彼此的依赖约定。下图截取了创建结果，附上各项分工的中文说明；5 是这次演示的任务数。

这里的价值在于把依赖关系一起交代清楚。例如，接口定义还没确定时，前端可以先做页面骨架，测试先围绕约定准备。任务已经很明确的小修复，也可以直接新建 worker，省去项目级讨论。

每个任务都有自己的分支和工作区

对于 Git 仓库里的任务，AO 会为 worker 建立独立分支和 Git worktree。worktree 可以理解为同一仓库下的另一份工作目录：各个 Agent 在自己的目录中改文件，你能分别查看每项任务的改动。

任务对话、终端、文件变更、PR 和审查状态都跟着这条会话走。发现页面任务有问题，可以打开对应 worker 继续讨论；后端任务做到哪一步，也有自己的记录。相比在几个终端窗口间靠记忆找负责人，这种组织方式更容易跟进。

AO 提供结构化聊天和 Agent 原生终端两类界面，具体能用哪一种，要看接入的 Agent 和版本。它也提供按 worker 隔离的浏览器环境，便于分别预览各自的界面改动。

独立目录解决的是并行编辑时相互干扰的问题。两条分支最终改到了同一段逻辑，合并时仍可能冲突；两个功能依赖同一份接口约定，也仍然需要协调。合理拆任务这一步不能省。

PR 提交之后，失败和修改意见交给谁

Agent 生成代码后，常常还有一段收尾工作：CI，也就是自动构建和测试，可能失败；审查者可能要求修改；分支也可能出现合并冲突。AO 会把这些状态与任务放在一起，方便判断哪条任务可以继续推进，哪条需要处理。

根据项目架构文档，后台服务会观察 GitHub 上的 PR 和检查状态。发现需要处理的评论、CI 失败或合并冲突后，生命周期管理模块会形成反馈，再通过会话对应的消息通道交给 Agent。原生终端和结构化聊天使用不同的发送方式。

这让返工可以回到原来的执行任务里：负责接口的 Agent 接着处理接口测试，负责页面的 Agent 接着修改页面。看板展示任务活动、PR 和审查状态，开发者可以打开卡片检查具体改动，再决定下一步。

反馈送回去了，还要检查修改结果。 Agent 是否理解了意见、测试是否覆盖了问题、代码是否适合合并，仍需要按项目的审查要求判断。AO 提供的是跟进这些工作的工具。

适合谁用，开始前要准备什么

如果你经常在同一仓库里并行推进几个任务，而且已经在用 Claude Code、Codex 等工具，AO 值得试一轮。它的收益主要来自任务组织、工作区隔离和提交后的跟进；只偶尔让一个 Agent 改几个文件时，先沿用熟悉的工具也很合理。

官方推荐直接安装 macOS、Windows 或 Linux 桌面版。旧 npm 包 @aoagents/ao 已冻结在 0.10.0，新用户按桌面版安装说明开始即可。

机器上仍需准备 Git，安装并登录至少一种编程 Agent。处理 GitHub 项目时，还要配置 GitHub CLI 的登录状态。AO 使用你已有的工具与认证，不随应用附送各家模型账号；各 Agent 的聊天、审批和恢复能力也要分别看支持情况。

第一次可以选一个验收标准明确的小功能，先拆成两项边界清楚的任务，走完“分派—修改—PR—反馈—审查”这一轮。再看自己花在寻找任务、传递上下文和转发修改意见上的时间，是否真的减少了。