MCO - 让多个 AI coding CLI 互相审查同一个仓库
AI coding CLI 正在变多。一个团队可能同时有人用 Claude Code、Codex、Gemini CLI、OpenCode，也可能在不同任务上偏好不同模型。问题是，当这些工具都能读仓库、改文件、跑命令时，工作流很容易变成“谁先改完算谁的”。这对个人试验还可以，对团队代码来说就不够稳。
今天推荐的 mco-org/mco 处理的是另一个角度：不要把一个 AI CLI 当成唯一执行者，而是把多个 CLI 放进同一个本地编排流程，让它们分工运行、互相审查，并把输出整理成可以人工 review 的结果。
发布时 GitHub 页面显示项目约 366 stars、31 forks，主要语言是 Python，许可是 MIT。仓库最早提交在 2026-02-26，最近一次提交在 2026-05-23，最新 Git tag 是 v0.9.1；GitHub Releases 页面显示的最新 release 是 v0.8.0，发布于 2026-03-17。README 顶部也说明，团队的新工作已经迁往 successor 项目 Hive，MCO 仍然作为可用的早期实现保留。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | mco-org/mco |
| 定位 | 本地多 AI coding CLI 编排器 |
| Stars | 约 366 |
| Forks | 31 |
| 主要语言 | Python |
| 许可 | MIT |
| Latest tag | v0.9.1 |
它解决的不是“再做一个 agent”
MCO 有意思的地方在于，它没有试图替代 Claude、Codex、Gemini 或 OpenCode。它更像一个本地协调层：把这些已经存在的 CLI 当成 provider，然后用统一的任务协议安排它们跑代码、读结果、给 review。
这类工具的价值来自一个现实问题：单个 agent 很容易在自己的上下文里变得自洽。它能解释为什么这么改，也能跑出看似合理的测试，但它未必会主动从另一个模型、另一个提示结构、另一个工具习惯去质疑自己。
MCO 把流程拆成 run 和 review 两类角色。一个 agent 可以负责提出 patch，另一个 agent 可以只看改动、日志和约束，再指出风险。这和人类团队里的“作者”和“reviewer”更接近，而不是让一个工具自问自答。
本地优先，而不是云端控制台
README 的设计倾向很清楚：MCO 运行在本地，调用的是本机已经安装和授权的 CLI。它并不要求你把仓库上传到一个新的 SaaS 控制台，也不把所有 provider 都包进一个封闭平台。
这对开发团队有几个好处。
第一，权限边界更容易理解。Claude Code、Codex、Gemini CLI 原本怎么登录、怎么读仓库、怎么运行命令，MCO 只是把它们纳入编排流程。你仍然可以沿用本机、CI 或开发容器里的安全设置。
第二，迁移成本低。团队不需要一次性选边站。某些任务可以交给 Claude，某些任务让 Codex 审，另一些任务让 Gemini 或 OpenCode 参与比较。MCO 关心的是流程，而不是替每个 provider 重新实现一套能力。
第三，它更适合实验。你可以先在一个小仓库里跑一次“生成补丁 + 交叉审查”，观察不同 provider 的输出差异，再决定是否把它放进更正式的开发流程。
从“一个提示词”变成“一个评审流程”
很多 agent 工具的默认入口是 prompt。用户写一句“修复这个 bug”，工具开始读文件、改代码、跑测试，然后给出总结。这个模式直接，但也容易把太多责任压在一次对话里。
MCO 的思路更像 workflow。你可以把任务描述、provider、reviewer、输出目录、失败处理和日志留存放到同一个流程里。这样做的重点不是让 agent 更神奇，而是让每一次 AI 修改更可复盘。
对团队来说，可复盘比“看起来聪明”更重要。一次 AI 生成的 patch 如果出问题，真正要追的是：
- 哪个 provider 生成了它；
- reviewer 有没有看过；
- reviewer 质疑了什么；
- 哪些测试被执行；
- 哪些命令失败过；
- 最后进入人工 review 的文件是什么。
MCO 这类编排器的价值就在这里。它把 agent 输出从一段聊天记录，推进到更接近工程流程的 artifact。
适合代码审查，也适合方案比较
MCO 最直接的场景是 code review。比如让一个 CLI 生成修复，让另一个 CLI 只看 diff 和约束，要求它关注测试缺口、边界条件、错误处理和安全风险。这样可以减少“同一个模型为自己的修改辩护”的问题。
第二个场景是方案比较。对一个非平凡需求，你可以让多个 provider 给出不同实现，再让 reviewer 汇总差异。人类最后不是盲选某个 agent 的输出，而是看几个候选方案在复杂度、风险和测试成本上的差别。
第三个场景是回归检查。已经有人类提交的 patch，也可以让 MCO 调用一个或多个 CLI 做审查。它不能替代正式 code review，但可以在进入人工 review 前先找出显眼问题。
这几类任务都有一个共同点：输出不应该直接合并。MCO 更像审查和比较工具，而不是“全自动合并机器人”。它适合把 AI 的建议压成结构化材料，让人更快判断。
Provider 中立是关键
如果一个编排器只绑定某个模型或某个公司，它的长期价值会受限。MCO 的设计是 provider-neutral：它关心 CLI provider 是否能执行、返回结果、参与 run/review 流程，而不是要求所有人使用同一个底层模型。
这点在 2026 年尤其重要。AI coding 工具更新很快，不同模型在代码理解、长上下文、测试修复、前端细节、命令执行习惯上经常互有强弱。团队很难提前押中唯一赢家。
Provider 中立的编排层，可以让团队把“工具选择”从“流程设计”里拆开。流程可以固定：先生成、再审查、再汇总、再人工确认。底层 provider 可以随着模型能力和团队偏好变化。
需要注意：MCO 已经进入过渡状态
MCO 不是一个没有边界的新玩具。README 顶部已经说明，新方向转向了 Hive，MCO 作为早期实现继续保留。这意味着，如果你要做长期投入，应该同时观察 Hive，而不是只看 MCO。
但这不等于 MCO 没价值。相反，它是一个很好的轻量样本：你可以从它看到多 CLI 编排、run/review 分工、provider 中立和本地 agent 流程这些概念如何落到代码里。对于想评估“多个 AI CLI 能不能组成团队流程”的开发者来说，它比纯概念文章更有用。
采用时我会注意几件事。
- 不要把 agent 输出直接合并到主分支。
- 先在小仓库或低风险任务里跑。
- 明确记录每个 provider 的权限和可执行命令。
- 把 reviewer 的输出当成辅助审查，不当成最终结论。
- 如果要生产化，顺手评估 successor Hive 的协议、许可和活跃度。
小结
mco-org/mco 值得关注，不是因为它发明了新的 AI coding agent，而是因为它把多个已经存在的 agent CLI 放进了一个更像工程流程的结构里：运行、审查、比较、汇总，再交给人判断。
这类工具的方向很明确。随着 AI CLI 越来越多，真正的问题不会只是“哪个模型最强”，而是“如何把多个工具的输出变成可审计、可比较、可回滚的开发流程”。MCO 是这个方向上的一个小众但有代表性的项目。