2026 年 AI 编码多代理协作全景：Claude Code + Codex CLI 7 个开源工具深度评测

文章目录

- 前言：单代理为什么开始不够用了
- 一、先理解两个主角的定位差异
- [二、MCP 和 git worktree](#二、MCP 和 git worktree)
- - [MCP（Model Context Protocol）是什么](#MCP（Model Context Protocol）是什么)
  - [git worktree 是什么，为什么多代理必须用它](#git worktree 是什么，为什么多代理必须用它)
  - [一个不容忽视的成本变量：API 费用](#一个不容忽视的成本变量：API 费用)
- [三、7 个项目总览](#三、7 个项目总览)
- 四、逐个项目深度分析
- - [1. agor --- 定位最高，像"多代理操作系统"](#1. agor — 定位最高，像"多代理操作系统")
  - [2. claude-squad --- 最均衡，最适合先跑起来](#2. claude-squad — 最均衡，最适合先跑起来)
  - [3. myclaude --- 工作流设计最有方法论](#3. myclaude — 工作流设计最有方法论)
  - [4. codexmcp --- 双代理桥接方向最直接，但需谨慎评估](#4. codexmcp — 双代理桥接方向最直接，但需谨慎评估)
  - - 架构亮点
  - [5. ccmanager --- 支持最广，最务实的 session 管理器](#5. ccmanager — 支持最广，最务实的 session 管理器)
  - [6. codexia --- 唯一正经做 GUI 的工作台](#6. codexia — 唯一正经做 GUI 的工作台)
  - [7. claude-code-tools --- 工具箱定位，补强而非替代](#7. claude-code-tools — 工具箱定位，补强而非替代)
- 五、横向对比
- - 能力维度评分
  - 选型快查
- 六、按场景的具体推荐路线
- - [场景 A：个人开发者，想尽快跑通多代理](#场景 A：个人开发者，想尽快跑通多代理)
  - [场景 B：小团队，想建立多代理协作基础设施](#场景 B：小团队，想建立多代理协作基础设施)
  - [场景 C：最关心 Claude × Codex 直接协作的实现](#场景 C：最关心 Claude × Codex 直接协作的实现)
  - [场景 D：不习惯命令行，需要 GUI 或 Windows 环境](#场景 D：不习惯命令行，需要 GUI 或 Windows 环境)
- 七、什么时候不需要多代理工具
- 八、总结
- 参考资料

前言：单代理为什么开始不够用了

2025 年以前，AI 编码工具的核心问题是"能不能用"------Claude Code 和 OpenAI Codex CLI 让这个问题的答案从否变成了是。

但 2025 年下半年起，先行者遇到了下一层瓶颈：

一个任务让 Claude Code 跑着，另一个任务只能干等
多个代理同时改同一个仓库，git 冲突反复出现
架构设计和代码生成应该分开做，但两个 agent 没法"交接"
团队每个人单独跑代理，没有共享状态也没法互相看进度

这些问题都指向同一个方向：单代理工作流触及了上限，多代理协作是下一个演进阶段。

GitHub 上随即出现了一批专门解决这些问题的开源工具，大多以 Claude Code + Codex CLI 协作为核心场景。本文整理其中最值得关注的 7 个项目，做一次横向评测。

一、先理解两个主角的定位差异

Claude Code 和 Codex CLI 并不是替代关系，它们的能力互补。

维度	Claude Code	Codex CLI
发布方	Anthropic	OpenAI
实现语言	TypeScript	Rust（性能优先）
核心优势	架构设计、长上下文推理、任务拆解	代码生成、细粒度优化、自主执行
GitHub Stars	约 70k+	约 75k+（2026 年 4 月）
月 npm 下载量	---	1450 万次
设计哲学	协作优先、过程可控	自主执行优先（fire-and-forget）

Claude Code 更擅长"想清楚"，Codex CLI 更擅长"做出来"。把两者放进同一个工作流接力，理论上能覆盖从规划到交付的完整链路------这正是下面 7 个工具要解决的问题。

二、MCP 和 git worktree

后面的项目分析会频繁提到这两个概念，先集中解释清楚。

MCP（Model Context Protocol）是什么

MCP 是 Anthropic 主导、现已成为行业标准的开放协议，允许 AI 模型通过标准接口调用外部工具、读取上下文或与其他服务通信。

简单理解：MCP 让一个 AI agent 能"调用"另一个 agent 或外部系统，就像函数调用一样。在多代理场景里，MCP 是实现"Claude 把任务交给 Codex 去做"的底层通道。

git worktree 是什么，为什么多代理必须用它

git worktree 允许你从同一个 git 仓库签出多个独立的工作目录，每个目录对应一个分支，共享同一份 .git 历史，但文件状态完全隔离。

bash 复制代码

# 为一个新任务创建隔离的工作树
git worktree add ../feature-auth -b feature/auth-refactor
# 这个目录可以独立地被一个 agent 操作，不影响主工作区

# 查看当前所有工作树
git worktree list

没有 worktree，多代理就无法并行：当两个 agent 共享同一个工作目录时，它们可能同时修改同一个文件，结果是冲突、覆盖和不可预期的状态混乱。worktree 隔离的原则是：

一个任务 → 一个分支 → 一个 worktree → 一个 agent

磁盘成本参考 （来源：Upsun 技术文章）：在约 2GB 的代码库里，自动创建 worktree 会额外消耗约 9.82GB 磁盘。现代笔记本上，5～7 个并行 agent 是性价比最优的上限------超过这个数字，磁盘消耗、API Rate Limit 和合并审查的综合开销会抵消并行收益。

一个不容忽视的成本变量：API 费用

多代理并行运行时，token 消耗是乘法增长，不是加法。如果同时跑 5 个 Claude Code 实例，API 费用约是单个实例的 5 倍。在引入多代理工具之前，建议先评估自己的 API 预算边界。

三、7 个项目总览

项目	定位	Stars	核心机制	成熟信号
agor	多代理协作平台	~1.1k	空间画布 + worktree + MCP + scheduler	1,469 commits，持续演进
claude-squad	终端多代理管理器	~7k	tmux + git worktree + TUI	本组最高 Stars，社区验证充分
myclaude	多后端工作流框架	~2.6k	/omo 路由编排 + /sparv 规格门控	328 commits
codexmcp	Claude × Codex MCP 桥接	~1.9k	MCP 协议 + session 持久化	⚠️ 仅 35 commits，关注度远超代码量
ccmanager	session/worktree 管理器	~1k	TUI + 多 agent 统一调度	696 commits，实干型工具
codexia	GUI 桌面工作台	~562	Tauri v2 + task scheduler + IDE 视图	release 节奏稳定
claude-code-tools	CLI 工具箱	~1.7k	会话辅助 + 检索增强	补强定位，非独立框架

关于 codexmcp 的特殊提示：1.9k Stars 配合仅 35 commits，意味着这个项目靠话题热度吸引了大量关注，但代码深度仍然有限。建议在正式引入前先在低风险场景里验证稳定性。

四、逐个项目深度分析

1. agor --- 定位最高，像"多代理操作系统"

GitHub ：preset-io/agor
Stars ：~1.1k ｜ Commits ：1,469 ｜ License：BSL 1.1（非 MIT，商用需注意）

定位原文

Orchestrate Claude Code, Codex, and Gemini sessions on a multiplayer canvas.

架构亮点

空间化画布（Multiplayer Canvas）：类 Figma 的 2D 视图，每个 agent 占据画布一个区域，团队成员可以实时共同查看任务状态
Worktree 隔离：每个 agent 工作在独立的 git worktree，变更不互相污染
会话树（Session Tree）：可以 fork 会话来探索替代方案，不丢失原始路径
内建 MCP Server：agent 之间可以通过 MCP 协议暴露和调用内部状态，支持真正的 agent 间通信
Zone Trigger + Scheduler：支持区域触发和任务调度，接近自动化编排
Extended Thinking 支持：2025 年 1 月起支持 Claude 的扩展思考模式，通过关键词自动分配更多推理 token

适合谁

想把多代理协作做成团队基础设施的小团队
有真实多任务并行需求、希望可视化管理 agent 状态的场景
愿意接受较高上手成本换取长期扩展上限的用户

潜在不足

上手成本是这 7 个里最高的，更像平台，不适合"今天就想多开两个 agent"的轻量需求
BSL 1.1 不是 MIT，商业化场景下需要单独确认许可证条款
真实体验高度依赖部署质量和团队是否真的愿意使用工作台

总结：天花板最高，但它的价值需要靠"把多代理当成基础设施来建设"的决心来兑现，不适合作为第一个试点工具。

2. claude-squad --- 最均衡，最适合先跑起来

GitHub ：smtg-ai/claude-squad
Stars ：~7k（本组最高）

定位原文

Manage multiple AI terminal agents like Claude Code, Codex, OpenCode, and Amp.

架构亮点

tmux 会话管理：每个 agent 运行在独立的 tmux 会话里，断了可以重连，不丢状态
git worktree 隔离：每个 agent 自动在独立分支的 worktree 里操作，避免相互污染
TUI 实时监控：可以在一个界面里看到所有 agent 当前在做什么
Yolo 模式：全自动接受模式，让 agent 在后台无人值守地跑完任务
安装极简：一行命令搞定

bash 复制代码

# macOS 安装
brew install smtg-ai/tap/claude-squad

# 或者通用安装脚本
curl -fsSL https://raw.githubusercontent.com/smtg-ai/claude-squad/main/install.sh | bash

# 启动（自动管理 tmux + worktree）
cs

适合谁

个人开发者和小团队，想最快跑通多代理并行工作流
习惯在终端工作、不需要 GUI 的开发者
把 claude-squad 作为多代理协作的第一个试点

潜在不足

更像"高级管理器"而非"编排平台"，缺少 agor 那种 agent 间主动协作的能力
自动化编排逻辑较基础，复杂任务的分解和接力需要手动设计
Windows 用户注意：依赖 tmux，在 Windows 上需要 WSL 环境才能使用

总结：7k Stars 是最好的信用背书。如果只推荐一个"今天就能开始试"的项目，优先选 claude-squad。

3. myclaude --- 工作流设计最有方法论

GitHub ：stellarlinkco/myclaude
Stars ：~2.6k ｜ Commits：328

定位原文

Multi-agent orchestration workflow (Claude Code Codex Gemini OpenCode)

架构亮点

/omo 路由编排：基于风险信号的多代理路由系统，不同任务被自动分发给不同专属 agent（oracle、librarian、frontend-engineer、develop 等角色），而不是让一个 agent 做所有事
/sparv 规格门控：在交付前强制检查规格，确保 agent 输出满足预定义质量标准，防止"做出来了但不对"的情况
codeagent-wrapper：统一执行层，管理跨多个 AI 后端（Claude、Codex、Gemini、OpenCode）的任务调度
按需安装：模块化设计，可以只安装需要的 skill

bash 复制代码

# 查看所有可用 skill
npx github:stellarlinkco/myclaude --list

# 交互式安装选择
npx github:stellarlinkco/myclaude

适合谁

Claude Code 重度用户，希望把 AI 协作流程规范化、制度化
比起"多开 agent"，更关心"怎么让 AI 过程可控、可审计"的团队
有方法论意识、愿意让团队遵守工作流规范的负责人

潜在不足

本质上是"Claude 主导的工作流系统"，Codex 是被调用的后端之一，不是对等协作者
如果团队不认同其工作流哲学，落地摩擦会很大------规范化工具在抵制规范化的团队里效果最差
328 commits 说明代码深度仍在积累阶段

总结：流程设计最完整，但它的价值需要团队集体认可其方法论才能兑现。Claude 单栈团队更适合它，混合工具栈团队可能会觉得偏重。

4. codexmcp --- 双代理桥接方向最直接，但需谨慎评估

GitHub ：GuDaStudio/codexmcp
Stars ：~1.9k ｜ Commits：35

定位原文

Enable seamless collaboration between Claude Code and Codex, transforming from a single agent to multiple agents for significantly enhanced productivity!

架构亮点

MCP 协议桥接：利用 Model Context Protocol，Claude Code 可以直接把任务"调用"给 Codex 执行，两者分工明确：Claude 负责架构和规划，Codex 负责代码生成
Session 持久化：支持会话续接，Codex 执行结果可以回传给 Claude 继续处理
并行执行：支持多个 Codex 实例同时处理不同子任务
推理轨迹追踪：记录 Codex 的执行推理过程，便于审查和调试

相比 OpenAI 官方 Codex MCP 实现，codexmcp 声称引入了 session 持久化、并行执行等企业级特性。

适合谁

明确想做 Claude 规划 + Codex 执行 双代理接力的开发者
不需要完整平台，只需要一个专用桥接层的场景
想用最小成本验证双代理协作可行性的人

潜在不足

1.9k Stars 配合仅 35 commits，是这组里最需要谨慎对待的组合：Stars 增长可能来自话题热度而非实际使用验证，commit 数量说明代码体量仍然很小
功能边界较窄，不包含 worktree 管理、session 调度等完整工作台能力
真实稳定性和复杂场景表现需要自行实测验证

总结：目标方向准确，适合作为轻量验证工具，但不建议在对稳定性有高要求的场景里直接引入生产流程。

5. ccmanager --- 支持最广，最务实的 session 管理器

GitHub ：kbwo/ccmanager
Stars ：~1k ｜ Commits：696

定位原文

Coding Agent Session Manager for Claude Code / Gemini CLI / Codex CLI / Cursor Agent / Copilot CLI / Cline CLI / OpenCode / Kimi CLI

支持的 agent 数量是本组最多的，它的目标是做所有 coding agent 的统一调度入口。

架构亮点

TUI 界面：可视化地列出、启动、停止、切换各 agent 会话，状态一目了然
跨 worktree 上下文复制：创建新 worktree 时，自动复制 Claude Code 的会话历史，在新分支里保持上下文连续性
智能自动审批：使用 Claude Haiku 分析提示词，自动判断哪些操作需要人工确认、哪些可以直接放行，降低重复确认的摩擦
Devcontainer 支持：agent 在容器里运行，ccmanager 在宿主机管理，兼顾安全隔离和宿主机侧的通知/自动化能力
Hooks 机制：agent 状态变化时触发自定义脚本，可以接入桌面通知、日志系统或外部服务

适合谁

个人开发者，不想引入复杂平台但需要多 agent 统一管理
同时使用多种 AI coding 工具（Cursor、Copilot、Cline 等）、希望统一管理入口的用户
需要在 devcontainer 隔离环境里运行 agent 的开发者

潜在不足

协作深度较浅：更偏"管理和调度"，缺少 agor 那种 agent 间主动通信和任务编排的能力
在可视化和平台化能力上明显弱于 agor
696 commits 说明它一直在迭代，但 Star 数相对低说明传播度有限

总结：工程质量最踏实的工具之一（696 commits 不会说谎），696 次提交说明它在被认真维护。如果你同时在用多种 AI 工具，ccmanager 能省掉很多切换成本。

6. codexia --- 唯一正经做 GUI 的工作台

GitHub ：milisp/codexia
Stars ：~562 ｜ License：AGPL-3.0 / Commercial（开源使用免费，商业闭源需购买）

定位原文

Agent Workstation for Codex CLI + Claude Code --- with task scheduler, git worktree & remote control, skills management

基于 Tauri v2 构建的跨平台桌面应用，把 Codex CLI + Claude Code 的工作流做成了类 IDE 的图形界面。

架构亮点

IDE 风格界面：文件树、提示词记事本、Git diff 视图，视觉上接近轻量 IDE
内置查看器：支持直接预览 PDF、CSV、XLSX，不需要切出去打开其他应用
Task Scheduler：可以为 agent 任务设置定时执行
Remote Control：通过内置 Web Server 远程触发 agent，适合需要在另一台机器上管理任务的场景
Skills Management：管理和组合不同的 agent 技能模块
跨平台：支持 macOS、Windows、Linux（x86_64 和 ARM64）

适合谁

不习惯纯终端操作、偏好图形界面的个人开发者
需要在本机做定时任务调度或从外部设备远程控制 agent 的场景
Windows 用户：这是本组里对 Windows 最友好的方案（不依赖 tmux）

潜在不足

Stars 最少（~562），社区验证程度是这组里最低的
AGPL-3.0 许可证：如果你要把它嵌入到公司产品里，需要注意开源传染性条款
GUI 方案天然引入更多跨平台兼容性和产品维护复杂度
团队协作能力有限，更像个人工作站

总结：形态独特，是 Windows 用户在本组里最友好的选项。如果你一直觉得命令行工具"用不进去"，codexia 是值得试试的方案。

7. claude-code-tools --- 工具箱定位，补强而非替代

GitHub ：pchalasani/claude-code-tools
Stars：~1.7k

定位原文

Practical productivity tools for Claude Code, Codex-CLI, and similar CLI coding agents.

架构亮点

会话辅助工具：增强 Claude Code / Codex CLI 的会话管理能力
检索与上下文增强：帮助 agent 在大仓库里更好地定位相关文件和上下文
工作流辅助脚本：常见重复性任务的封装脚本
跨 agent 集成：提供 Claude Code 与 Codex CLI 之间的轻量集成脚本

适合谁

已经在用 Claude Code 或 Codex CLI、想做局部增强而不是换框架的人
不需要引入复杂平台，只是想让现有命令行工作流更顺手

潜在不足

没有独立的 session 管理、worktree 隔离或可视化能力
功能分散，更像工具集合而非有统一架构的系统
如果你在做"选主框架"，它不应该出现在候选名单的前几位

总结：不适合作为主选型对象，但如果你已经选定了主框架（比如 claude-squad 或 agor），claude-code-tools 可以作为日常补强组件叠加使用。

五、横向对比

能力维度评分

项目	协作深度	成熟度	个人友好度	团队友好度	上手难度
agor	★★★★★	★★★★	★★★	★★★★★	高
claude-squad	★★★★	★★★★★	★★★★★	★★★★	低
myclaude	★★★★	★★★	★★★	★★★★	中高
codexmcp	★★★	★★	★★★★	★★★	中
ccmanager	★★★	★★★★	★★★★★	★★★	低~中
codexia	★★★	★★★	★★★★	★★	中
claude-code-tools	★★	★★★	★★★★	★★★	低

评分基于公开资料判断，不代表实测结果。

选型快查

需求	首选	备选
团队多代理协作平台	agor	myclaude
个人快速跑通多代理	claude-squad	ccmanager
Claude × Codex 直接桥接	codexmcp	agor
AI 开发流程规范化	myclaude	---
Windows 或 GUI 用户	codexia	---
现有工作流轻量增强	claude-code-tools	---

六、按场景的具体推荐路线

场景 A：个人开发者，想尽快跑通多代理

推荐路线 ：claude-squad → ccmanager → （可选）codexmcp

第一步：用 claude-squad 验证多代理并行工作流（一行安装，worktree 自动管理，7k Stars 保证了基本可靠性）
第二步：如果你同时在用 Cursor、Copilot 等多种工具，用 ccmanager 做统一管理入口
第三步：当你确定要做 Claude 规划 + Codex 执行的接力流程，再接入 codexmcp 做桥接

场景 B：小团队，想建立多代理协作基础设施

推荐路线 ：claude-squad（试点）→ agor（平台化）

试点阶段：先用 claude-squad 跑通 2～3 个并行任务，让团队成员适应 worktree 工作流
平台化阶段：当团队认可多代理协作价值后，再迁移到 agor，获得可视化、团队共享和调度能力
流程化阶段：如果团队需要对 AI 协作过程做更强的质量管控，同步引入 myclaude 的 /sparv 规格门控

场景 C：最关心 Claude × Codex 直接协作的实现

推荐路线 ：codexmcp（验证）→ agor（规模化）

先用 codexmcp 低成本验证双代理桥接是否符合你的工作流
如果验证有效且需要规模化，迁移到 agor（它内建 MCP Server，支持更完整的多代理通信）

场景 D：不习惯命令行，需要 GUI 或 Windows 环境

直接看 codexia。它是本组唯一的桌面 GUI 方案，支持 Windows，不依赖 tmux。

七、什么时候不需要多代理工具

这个问题比"用哪个工具"更先需要回答。

以下场景里，单代理通常就够了，引入多代理工具反而增加复杂度：

你的任务是线性的，下一步依赖上一步的输出，没有可以并行的子任务
你的代码库很小（< 1 万行），单 agent 能在几分钟内处理完整个上下文
你的团队还在学习如何有效使用单个 AI 编码工具
你的 API 预算有限，无法承受多 agent 并行的 token 成本

引入多代理工具最有价值的场景：

有明确可并行的子任务（前端/后端/测试可以同时进行）
需要架构设计和代码生成分离执行
团队有多人需要共享 agent 状态

八、总结

如果只根据公开资料做判断：

想要长期最高天花板 ：选 agor，但做好接受高上手成本的心理准备
想要最均衡、最快开始 ：选 claude-squad，7k Stars 是最好的社区背书
想要最强流程规范 ：选 myclaude，适合有方法论意识的 Claude 深度用户
想要 Claude + Codex 直接桥接 ：先试 codexmcp，但关注它 35 commits 的成熟度风险
个人开发者务实首选 ：ccmanager，696 commits 说明有人在认真维护
Windows / GUI 用户 ：codexia，本组里对非 macOS 用户最友好

最终建议 ：先从 claude-squad + codexmcp 这条低摩擦路线开始，验证自己的真实需求后再决定是否升级到 agor 这类平台。

很多团队以为自己需要"最先进的多代理协作平台"，最后发现真正需要的只是：稳定的 worktree 隔离、好用的 session 管理，和一个让 Claude 和 Codex 能接力的最小闭环。这三件事，往往比界面有多漂亮更先决定工具能否真正落地。

参考资料

GitHub 项目

技术文章

Claude Code 官方文档 - Agent Teams
Git Worktrees for Parallel AI Coding Agents - Upsun（worktree 磁盘消耗数据来源）
Codex vs Claude Code - builder.io
2026 年最佳并行 AI 代理工具 - Nimbalyst
ccmanager 实践 - Zenn
Claude Code Worktree 并行开发指南