ccg-workflow：一个命令把 Codex、Gemini、Claude 编排进同一场开发

它解决的问题：让 Claude 不再单打独斗

大多数 AI 编程工具是单模型闭环。你开一个 Claude Code 终端，所有代码生成、审查、重构都交给同一个模型。ccg-workflow 想打破这个闭环。它的定位是 Claude Code 的工作流引擎，让 Claude 留在指挥位置，把具体任务分派给 Codex、Grok、Kimi Code 和 Antigravity。文档里给了一个典型场景：你对它说「给这个 API 加上 JWT 认证」，引擎会先读项目上下文，判断这是功能需求、复杂度是 L、属于后端、风险较高，然后选择 full-collaborate 策略，让 Codex 和 Gemini 并行分析，最后产出计划并停下来等你批准。这个项目的目标用户很明确：已经在用 Claude Code、但觉得单模型能力不够或者想对比不同模型输出的开发者。它不是给普通终端用户准备的，它假设你已经熟悉 AI 辅助编程的基本流程。

机制拆解：Hook Engine 与 codeagent-wrapper 的分工

架构上分成两层。Claude Code 是总指挥，负责意图分析、策略选择和整个工作流的推进。为了让 Claude 在对话被压缩后仍然不丢失上下文，项目引入了一个 Hook Engine，每一轮对话都会注入当前状态。另一层是 codeagent-wrapper，一个用 Go 编译的二进制程序，它的作用是桥接 Claude 和外部模型。这个桥接不是走什么标准协议，而是直接调用各家模型的 API。README 特别强调，在 DeepSeek Harness 的集成版本里，每一步都是 provider API 请求，没有额外的 CLI 或二进制桥接，也没有冷启动开销。这个对比暗示了原版 ccg-workflow 的代价：Go 二进制本身就是一个需要维护的额外组件。文档没有说明这个二进制如何与 Claude Code 通信，但从架构图来看，它应该是被 Claude 通过某种工具调用机制触发的。

执行流程：从意图到任务文件的七步路径

README 给出了一个具体的执行流程示例。你输入 /ccg:go add JWT authentication to this API，引擎先读取 git status、技术栈、文件结构，然后做分类，判断是 feature、复杂度 L、后端、高风险。接着选择策略，这里提到的是 full-collaborate。然后创建 .ccg/tasks/add-jwt-auth/task.json 文件，这个文件应该是整个任务的持久化状态。之后启动双模型分析，Codex 和 Gemini 并行工作，产出计划后进入 HARD STOP，等你批准。批准后才生成 Agent Teams Builders 进行并行实现。这个流程的关键点是 HARD STOP，它把决策权留给了人，而不是让模型一路自动执行到底。任务文件的存在意味着工作流可以中断和恢复，但 README 没有说明如果 task.json 损坏或者模型输出格式不符合预期会怎样。

安装与启动：一条 npx 命令的利与弊

安装方式非常直接：运行 npx ccg-workflow。文档说 60 秒内完成安装。这个包同时发布在 npm 上，npm 版本号是 ccg-workflow，而仓库的 release 里有一个名为 preset 的发布，内容是 Pre-Built Binaries (codeagent-wrapper)。这意味着你需要同时拿到 npm 包和 Go 二进制。npx 命令在首次运行时应该会自动处理依赖，但如果你在一个没有网络或者 npm 源受限的环境里工作，这条命令可能不会那么顺畅。README 还提到可以选择 DeepSeek Harness 作为运行环境，命令是 npx ccg-workflow dsh install，可以为每个 profile 安装，或者用 --profile <name> 指定单个。安装后，你在 Claude Code 里输入 /ccg:go 加上你的需求描述即可。配置方面，文档提到在第一步可以选择 API provider，比如 APIMart 提供的 Anthropic 兼容端点，这意味着你需要准备至少一个模型的 API key。

DeepSeek Harness 变体：模型面板与常驻队友

项目还捆绑了一个针对 DeepSeek Harness 的版本，叫 dsh-ccg，它直接打包在 npm 包里，不需要二次安装。这个版本有七个角色固定的委派工具，每个角色绑定一个模型和一套专家人设。它提供了两个原版 Claude Code 不容易实现的功能。第一个是模型面板，你可以给一个角色分配多个模型，它们会独立回答同一个任务，结果并排显示在对话里，不投票、不取平均，分歧本身就是结论。第二个是常驻队友，ccg_team 可以雇佣一个角色作为同事，它在多轮对话中保持存活，拥有自己的文件，而且如果发生冲突，雇佣会被拒绝而不是警告。每次雇佣都要求你先批准。这个设计把多模型协作从一次性任务变成了持续的团队关系，与主版本的一次性任务文件模式形成对比。

真正的局限：编排开销与上下文依赖

ccg-workflow 最大的问题在于它把简单的事情变复杂了。如果你只需要 Claude 写一个函数，引入 Codex 和 Gemini 并行分析是多余的。文档里提到的分类、策略选择、任务文件这些步骤，对小型任务来说都是延迟。另一个隐患是它对 Claude Code 的深度依赖。Hook Engine 注入状态这个机制，意味着 Claude Code 的版本更新可能破坏兼容性。项目没有提供任何回退方案，如果 Hook Engine 失效，整个工作流就失去了记忆。还有一点，多模型并行意味着你需要同时为多个 API 付费，成本是单模型的数倍。APIMart 赞助商提供的低价端点可以缓解这个问题，但那是第三方服务，稳定性不在项目控制范围内。最后，README 没有提及任何失败恢复机制，如果 Codex 的 API 在分析中途超时，task.json 里记录了什么状态，引擎如何重试，这些都没有说明。

替代方案：从单模型到自定义编排的光谱

如果你不想引入 ccg-workflow，最简单的替代是直接在 Claude Code 里手动切换模型，或者用多个终端分别运行 Codex CLI 和 Gemini CLI，自己复制粘贴结果。这样做的好处是零额外依赖，坏处是你失去了上下文注入和任务文件管理。另一个替代是 DeepSeek Harness 本身，它是一个插件化的 AI 编程环境，dsh-ccg 就是构建在它之上的。DeepSeek Harness 的模型面板功能让多个模型并排输出，不需要 Go 二进制桥接，因为所有调用都是直接的 provider API 请求。如果你更看重模型间的对比而不是自动编排，DeepSeek Harness 可能更轻量。ccg-workflow 的独特之处在于它把编排逻辑放在了 Claude Code 内部，让 Claude 做决策者，而其他方案要么让你自己做决策，要么让单一模型做所有事。

维护成本与许可证现实

项目使用 MIT 许可证，这意味着你可以自由使用、修改和分发，甚至闭源商用，只要保留版权声明。这对企业用户比较友好。但维护成本不低。项目同时维护 npm 包和 Go 二进制两个发布渠道，release 页面显示 preset 发布包含 codeagent-wrapper 的预编译二进制，这意味着每次更新都要同步两个产物。npm 包的版本号是 ccg-workflow，而仓库名是 ccg-workflow，两者一致，减少了混淆。不过，代码托管在 GitHub，主页是 ccg.fengshao1227.com，文档站和代码仓库分离，长期维护取决于作者的个人投入。README 中大量篇幅给了赞助商和作者的其他项目，这暗示项目可能依赖外部资金支持。如果你要把它集成到生产环境，需要自己跟踪 Claude Code 的更新是否影响 Hook Engine，以及 Go 二进制是否需要重新编译。文档没有提供升级指南或变更日志的链接，这是评估长期成本时的一个不确定因素。

编辑结论

ccg-workflow 适合已经在 Claude Code 里工作、且手上同时有 Codex 和 Gemini API 额度的人，尤其是那些任务经常跨越前端、后端和运维多个技术栈的独立开发者。它把多模型协作从手工切换终端变成了一个可重复的工作流，这是它最实在的卖点。不适合的人包括：只用单一模型就能完成任务的人，以及不愿意为一条 CLI 命令额外维护 Go 二进制和 npm 包两个发布渠道的团队。在采纳之前，先确认三件事：你的 Claude Code 版本是否支持 Hook Engine 注入，Codex 和 Gemini 的 API key 是否允许并行调用而不触发限流，以及 .ccg/tasks/ 目录下的任务文件是否符合你现有的版本控制习惯。若这三项都过关，ccg-workflow 值得作为你多模型实验的起点，否则它带来的编排收益可能被配置成本抵消。

官方来源

1. fengshao1227/ccg-workflow on GitHub
2. License: MIT
3. Project website
4. README
5. Releases