CCG 思路的 Codex 主导改造

5 min read

在真正使用 CCG 思路之前，跨模型协作已经出现。

最早的做法比较笨。Codex 负责工程实现，Gemini 或 Antigravity 负责前端视觉方向。人在中间传话，把一个模型的判断交给另一个模型。这个办法能用，但不稳定。Gemini 有时缺少代码上下文，能提出方向，却不一定能安全动手。临时会话也容易断，做一半就卡住。

看到 CCG 的三 agent 协作思路后，这个问题有了更清楚的组织方式。

吸收的部分

CCG 有价值的地方，不是名字本身，而是它把跨模型协作变成了更清楚的分工。

一个 agent 负责主导和收口，一个 agent 负责补充视角或专项执行，另一个 agent 负责审查、对照或辅助。这样一来，多模型协作不再是把同一段话复制给不同模型，而是让它们在同一个任务里承担不同责任。

这正好能解决当时的前端问题。Codex 在后端、结构、命令执行和严谨收口上更稳，但前端视觉经常出现过度说明、像 PPT 演示稿一样的口吻。Gemini 更适合处理页面气质和视觉方向，但直接让它改代码又容易漏上下文。

保留下来的原则是：Codex 先整理项目上下文和边界，再让 Gemini 理解相关代码，然后再决定是否动手。

CCG 没有被原封不动使用。

原版 CCG 更偏 Claude Code 主导，而实际主工作台是 Codex App。Claude Code 并不是完全不用，但它不是当前主入口。因此这套流程必须改成 Codex 主导。

改造后的关键变化，是主导权和收口权放回 Codex。Codex 负责判断任务边界、喂上下文、检查结果、执行必要命令和最后验证。Gemini 负责它更擅长的设计、视觉、前端审查或第二视角。Claude Code 可以作为对照、审查或某些工作流思想来源，但不强行放成默认中心。

这也是 Gemini CLI 被纳入流程的原因。CLI 让 Codex 可以直接唤起、持续会话、传递上下文和检查结果，不再需要完全手动当传话人。

这套改造让协作方式从“多个模型轮流帮忙”，走向“多个模型被组织起来做事”。

区别不小。前者容易变成意见堆叠，后者才有责任边界。谁负责理解项目，谁负责视觉判断，谁负责实际改动，谁负责验证，都要分清。

这个阶段也自然引出了 Trellis。因为一旦多个 agent 参与，任务状态、上下文、交接材料和长期记忆就变得很重要。没有这些承载层，多模型协作很容易重新退回临时聊天。

参考来源：