KechuAI

Agent Orchestrator：把"一队编码 Agent"管成一张看板的开源桌面工作台

AI Agent
编码代理
开源
DevTools
工作流
Git
2026/10/3
·

阅读时间: 大约 8 分钟

Agent Orchestrator：把”一队编码 Agent”管成一张看板的开源桌面工作台

Agent Orchestrator 的实时看板：Working / Needs you / In review / Ready to merge 四列（官方截图）

当单个编码 Agent（Claude Code、Codex、Cursor 这类）能干完一个任务后，真正难的变成了另一件事：在一个项目上同时跑好几个 Agent——什么任务重要、怎么拆干净、给每个 Agent 什么样的上下文、防止分支互相打架、以及盯着每一个的产出。Agent Orchestrator（下文简称 AO）就是冲着这个”多 Agent 管理岗”来的。它是一个本地桌面工作台，核心理念写在 README 第一句：“给每个编码任务配它自己的 Agent、工作区和反馈回路”。

需要先说明一个事实：该仓库 koala 条目里挂的是 ComposioHQ/agent-orchestrator，但目前已迁移到 Untrivial-ai/agent-orchestrator，Apache-2.0 协议，仍在高速迭代（笔者调研时看到约 403 个 open issues、332 个 open PR）。

一、它解决的问题

AO 把”跑单个 Agent”和”协调一队 Agent”明确分成两层：

  • Worker（执行单元）：一个 Worker = 一个任务 + 一个编码 Agent + 一个隔离工作区。对 Git 类工程，AO 会给这个 Worker 单独开一条分支；
  • Project Orchestrator（规划单元）：一个常驻的规划/协调 Agent，工作在单个任务之上——它管产品方向、技术策略、优先级和整个项目里工作的先后顺序，再把大目标拆成一个个可下发的 Worker。

也就是说，你既可以把一个已经很明确的小任务直接丢给某个 Worker，也可以只给一个大目标，让 Orchestrator 自己拆计划、自己起 Worker。

AO 的 Project Orchestrator 在多个 Worker 之上做规划与分派（官方截图）

二、核心机制

  1. 本地桌面 App + 本地 daemon：AO 是一个下载即用的桌面应用（自动检查更新），背后跑一个本地 daemon，持续监听 Agent 活动与源码控制状态。你不需要先配 CLI；App 会帮你把 daemon 跑起来。
  2. 实时 Kanban：这是 AO 的主界面。它把整个项目聚成一张共享看板，而不是一堆互不相干的终端、分支和浏览器标签页。看板分四列：
看板列官方定义（在跟什么）
Working正在实现、或还能接下一条指令的 Worker
Needs you被阻塞、缺输入、CI 失败、被要求改、或”信号丢失”的会话
In review等待检查或评审的 open / draft PR
Ready to merge已批准或可合并的工作；已合并的会话归档前仍可见
  1. PR / CI / 评审闭环：把 CI 结果、可合并性、评审人状态、以及交互式 Agent review 都挂在对应 Worker 旁边；当评审提出修改要求时，可以把这条反馈原路发回同一个 Worker，而不是另起炉灶。
  2. 隔离的浏览器与预览：可以在 Worker 界面旁边直接预览它跑起来的本地应用；浏览器 profile 按 Worker 隔离，并行做 UI 任务的多个 Agent 不会共享状态、互相污染。

三、支持面：“Any harness, +25”

AO 主打的一个卖点是不绑死某一家编码 Agent。README 标称支持 Claude Code、Codex，以及”另外 25+“harness。从仓库前端资源里能数到的适配包括：Cursor、opencode、Aider、GitHub Copilot、Grok、Kimi、Amp、Cline、Goose、Qwen、Continue、Devin、Kiro、Kilo Code、Gemini CLI、DeepSeek 等，桌面/Web/移动/云端 Agent 都能接。

这里必须点出口径偏差：“支持 25+ harness”不等于”25+ harness 都被一等公民对待”。这个数字里大量是适配器式接入，集成深度（能否完整接管终端、能否回灌 CI/评审信号）因 harness 而异；真正打磨最深的显然是 Claude Code、Codex 这类原生 CLI。选型时应以”你主力用的那 1–2 个 harness 在 AO 里闭环是否顺滑”为准，而不是看总数。

四、客观评价

优势：

  1. 把”多 Agent 并发”从人肉终端管理变成看板管理：四列状态机（尤其 “Needs you” 把失败 CI、阻塞、被要求改自动收拢）直击多 Agent 最大的运维痛点——信号散落；
  2. harness 中立：不逼你从 Claude Code 换到别家，自带的 Agent 与模型可按任务挑；
  3. 隔离做得细：一人一分支、一 Worker 一浏览器 profile，并行 UI 开发不串状态；
  4. Apache-2.0 开源 + 本地运行：代码与工程数据留在本地，门槛低。

局限：

  1. 成熟度风险：约 403 open issues、332 open PR、仓库刚从 ComposioHQ 迁到 Untrivial-ai，说明项目极年轻、变动快、所有权也在迁移期，生产依赖前要接受快速 churn；
  2. 它是本地桌面 App：需要你在本机开着 daemon，团队级/云端长期调度不是它的定位；
  3. 价值强绑定 Git + PR + CI 工作流：如果你的工程流不是”起分支—提 PR—过 CI—评审”，看板的很多列就空转；
  4. harness 深度参差：如上所述，“25+“是数量，不是深度。

五、适合谁用

  • 已经在用 Claude Code / Codex 等 CLI、开始同时跑好几个编码 Agent、被分支和 PR 管理搞得焦头烂额的个人或小团队；
  • 想要一个harness 中立的多 Agent 指挥台、而不是绑定某一家云厂商的人；
  • 希望把”起任务—拆计划—提 PR—追 CI—合并”全程在一个本地界面闭环的工程团队。

不适合：需要纯云端、无人值守、跨团队长期编排，或工程流不在 Git/PR 模型里的场景。

参考来源