大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



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 更擅长“做出来”。把两者放进同一个工作流接力，理论上能覆盖从规划到交付的完整链路——这正是下面 7 个工具要解决的问题。

---

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

MCP（Model Context Protocol）是什么

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

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

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

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

# 为一个新任务创建隔离的工作树 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 预算边界。

---

关于 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 在后台无人值守地跑完任务
• 安装极简：一行命令搞定

# 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

# 查看所有可用 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 可以作为日常补强组件叠加使用。

---

能力维度评分

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

选型快查

---

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

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

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

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

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

1. 试点阶段：先用 claude-squad 跑通 2～3 个并行任务，让团队成员适应 worktree 工作流
2. 平台化阶段：当团队认可多代理协作价值后，再迁移到 agor，获得可视化、团队共享和调度能力
3. 流程化阶段：如果团队需要对 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 项目

• preset-io/agor
• smtg-ai/claude-squad
• stellarlinkco/myclaude
• GuDaStudio/codexmcp
• kbwo/ccmanager
• milisp/codexia
• pchalasani/claude-code-tools

技术文章

• 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 并行开发指南