文章目录Pre一、为什么需要 CCG多视角、低开销的跨模型“咨询室”二、整体架构分解、分发、合成的三阶段流水线2.1 三阶段流程总览2.2 基于产物文件而非 stdout 的设计三、omc ask统一 CLI 路由层的设计与实现3.1 命令签名与提供商枚举3.2 参数解析与 Agent 提示词注入3.3 安全门控控制外部 LLM 是否可用四、run-provider-advisor.js外部顾问适配与隔离4.1 脚本角色唯一转换层4.2 提供商特定参数构建4.3 长提示词与 stdin 管道4.4 环境变量剥离与会话隔离4.5 二进制探测与 Markdown 产物写入五、CCG 编排协议从请求分解到结果合成5.1 阶段一请求分解5.2 阶段二并行分发5.3 阶段三结果合成六、优雅降级在各种异常条件下仍然可用6.1 场景矩阵与行为6.2 对工程实践的意义七、与互操作模式的关系轻量 CCG vs 重量 Interop7.1 互操作模式概览7.2 关键维度对比八、实践场景与使用示例8.1 多视角代码评审8.2 前后端融合与接口设计8.3 方案选择与交叉验证8.4 何时不该用 CCG九、设计启示与落地建议PreOMC - 01 用 19 个 Agent 打造你的 Claude Code“工程团队”oh-my-claudecode 深度解析与实战指南OMC - 02 五分钟起步走向多智能体协作深入解析 oh-my-claudecode 快速开始与架构设计OMC - 03 从 0 到高效Oh My ClaudeCode 安装与实践全指南OMC - 04 用好 Oh-My-ClaudeCode 的 30 个会话技能从“帮我写点代码”到端到端自动交付OMC - 05 从单人到多 AgentOh-my-claudecode 的插件架构解析OMC - 06 从“大模型管家”到“十九人专家团队”oh-my-claudecode 的多 Agent 工程实践OMC - 07 把「选模型」当成一门工程学oh-my-claudecode 的三层模型路由实践OMC - 08 在多 Agent 时代如何优雅地「分工协作」oh-my-claudecode 委托分类体系深度解读OMC - 09 oh-my-claudecode 的多 Agent 编排实战OMC - 10 从创意到“免看管生产力”深入解析 Oh-My-ClaudeCode 的 Autopilot 与 Ralph 模式在多模型协同时代单一 LLM 的视角越来越难以满足复杂工程场景的需求。Claude-Codex-GeminiCCG合成机制提供了一种轻量级但结构严谨的跨供应商协同方式由 Claude 负责编排通过统一的omc ask命令并行调用 Codex 与 Gemini再对多方意见做结构化合成与裁决。面向对象主要包括三类读者需要多模型交叉验证代码与架构决策的工程师和架构师希望理解多模型编排模式的研究者与工具开发者在本地或企业环境中落地 AI 工程工具链的实践者下文将从整体架构、CLI 路由层、外部顾问脚本、三阶段编排协议、降级机制以及与互操作模式的关系几个方面系统拆解 CCG 的设计与实现并给出具体使用场景与实践建议。一、为什么需要 CCG多视角、低开销的跨模型“咨询室”在工程实践里常见的需求包括希望 Codex 从“编译器工程师”视角检查架构、复杂逻辑与测试策略希望 Gemini 从“产品用户体验”视角审视接口设计、文档与易用性希望有人能站在更高一层的位置把两边的意见做出有理由的取舍与合成CCG 的核心目标可以概括为三点利用不同模型的偏好与长板形成互补视角保持单次调用无状态无需 tmux、持久会话与复杂状态管理提供统一 CLI 入口与可审计的产物文件方便调试、追踪与持续集成因此CCG 更像是一次性的“多模型会诊”在秒级时间内完成分解、并行咨询和合成决策非常适合代码审查、方案评估、接口设计讨论等场景。二、整体架构分解、分发、合成的三阶段流水线2.1 三阶段流程总览CCG 的流水线可以抽象为三个阶段分解DecomposeClaude 将用户请求拆解为两个互补的顾问提示词并提前制定合成策略。分发Distribute通过统一的omc askCLI分别调用 Codex 与 Gemini 的 CLI 工具作为外部“顾问”。合成Synthesize从磁盘读取两份产物文件Claude 进行对比分析输出统一且可执行的结果。这三个阶段通过以下几个关键组件串联起来统一入口omc ask命令提供商路由与参数解析ask.ts中的askCommand()和parseAskArgs()外部顾问脚本scripts/run-provider-advisor.js产物存储目录.omc/artifacts/ask/*.md可以把 Claude 看作主治医生通过omc ask把同一病例发给 Codex偏工程、Gemini偏体验再综合两位会诊医生的报告给出最后方案。2.2 基于产物文件而非 stdout 的设计一个重要设计是合成并不是直接读取 CLI 的 stdout而是基于.omc/artifacts/ask/codex-*.md、gemini-*.md这类结构化 Markdown 产物文件来完成。每个产物包含原始任务描述最终提示词包括 Agent 提示词注入后的完整内容原始模型输出退出码与摘要行建议的后续操作项这种设计的好处包括避免 stdout 被截断或多进程交错导致的混乱能以统一结构落地到版本库、CI 报表或审计系统方便后续做二次分析、可视化与统计三、omc ask统一 CLI 路由层的设计与实现3.1 命令签名与提供商枚举omc ask是整个 CCG 的“正门”支持三类 providerclaude、codex、gemini。在 TypeScript 中提供商集合被定义为编译期常量元组constASK_PROVIDERS[claude,codex,gemini]asconst;exporttypeAskProvider(typeofASK_PROVIDERS)[number];CLI 层在src/cli/index.ts中注册ask命令并将具体逻辑委托给askCommand()。3.2 参数解析与 Agent 提示词注入parseAskArgs()支持三种调用风格调用模式示例用例位置参数omc ask codex review this PR快速的单次查询显式提示词omc ask gemini --prompt suggest UX improvements包含特殊字符的复杂提示词Agent 提示词omc ask codex --agent-prompt architect evaluate...以特定角色进行分析其中--agent-prompt会触发resolveAgentPromptContent()从 agents 目录或项目作用域的.codex/prompts/中读取对应的.md文件将整段 Agent 人设拼接到用户提示之前。角色名称需要符合^[a-z][a-z0-9-]*$的严格正则以避免路径遍历等安全问题。这种机制带来的好处是可以将“架构师”、“安全审计员”、“文档工程师”等不同角色预设为 AgentCCG 为每个外部顾问选择不同的 Agent 组合让 Codex/Gemini 从不同视角出发进行分析使用者无需反复手写复杂 prompt只需通过 CLI 选用对应角色即可3.3 安全门控控制外部 LLM 是否可用在调用非 Claude 提供商之前askCommand()会检查isExternalLLMDisabled()。当配置中开启disableExternalLLM策略时只允许claude提供商对codex、gemini请求直接拒绝并返回清晰错误信息这个设计使得企业环境可以在不修改技能配置的前提下一键切断外部云端模型只保留自家或专有部署的 Claude从而满足合规与数据安全要求。四、run-provider-advisor.js外部顾问适配与隔离4.1 脚本角色唯一转换层真正调用各家 CLI 的逻辑集中在scripts/run-provider-advisor.js中它由askCommand()以子进程方式调起。它是统一接口和异构 CLI 之间的唯一转换层负责构建不同 provider 所需的 CLI 参数处理长、多行 prompt 的传输方式剥离敏感环境变量隔离会话状态探测二进制可用性并生成 Markdown 产物4.2 提供商特定参数构建buildProviderArgs()根据不同提供商生成对应的二进制与参数组合提供商二进制文件CLI 参数备注Claudeclaude-p简单打印模式Codexcodexexec --dangerously-bypass-approvals-and-sandbox非交互式执行需绕过审批与沙箱Geminigemini-p --yolo--yolo用于跳过交互式确认对开发者来说这意味着使用omc ask时不需要记住各家 CLI 的细节所有模型调用都走一条统一路径由脚本负责适配。4.3 长提示词与 stdin 管道对于长度超过 500 字符或包含换行符的提示词脚本会判断应通过 stdin 传递而非作为命令行参数。这是为了避免命令行长度限制Shell 转义问题尤其是在 Windows 平台上该判断逻辑集中在shouldPipePromptViaStdin()中对 Codex 和 Gemini 尤其关键可显著减少因为参数转义导致的奇怪故障。4.4 环境变量剥离与会话隔离为了防止外部顾问探测到当前正在运行的 Claude Code 会话从而触发递归调用或污染会话状态buildProviderEnv()会在启动前清理部分环境变量所有提供商统一剥离CLAUDECODE、CLAUDE_SESSION_ID、CLAUDECODE_SESSION_ID、CLAUDE_CODE_ENTRYPOINT对 Codex 额外剥离RUST_LOG、RUST_BACKTRACE、RUST_LIB_BACKTRACE这样每一次顾问调用都在“干净”的环境中执行避免不同工具之间产生隐性耦合。4.5 二进制探测与 Markdown 产物写入执行前ensureBinary()会通过执行binary --version来确认可用性在 Windows 上若失败则回退到where命令。执行后writeArtifact()负责将结果写入.omc/artifacts/ask/provider-*.md包含任务描述、最终 prompt、输出内容、退出码、摘要与后续建议文件名通过slugify()对任务内容进行 URL 安全截断生成这种 Markdown 产物化机制既方便人类阅读也方便上层技能进行解析与合成。五、CCG 编排协议从请求分解到结果合成CCG 技能处在最高的 Level-5 层级通过/oh-my-claudecode:ccg调用时遵循严格的执行协议。5.1 阶段一请求分解Claude 在接收到用户请求后会完成三件事生成 Codex 顾问提示偏重架构设计、正确性、后端逻辑、风险分析与测试策略生成 Gemini 顾问提示偏重 UX、内容清晰度、边缘情况可用性与文档完善度制定合成计划提前思考如果两者出现冲突应如何权衡、优先哪类因素、需要哪些补充信息对比普通“多模型调用”这里的关键区别是提示不是简单复用同一个文本而是刻意拉开侧重点让两个顾问形成“互补视差”。5.2 阶段二并行分发由于 Claude Code 技能体系不支持在一个技能内部再调用另一个技能因此分发阶段必须通过 Bash 直接执行 CLIomc ask codexcodex_promptomc ask geminigemini_prompt这两条命令可以在脚本层面并行执行也可以由调度器进行并发管理其产物会分别落在.omc/artifacts/ask/下对后续合成透明。5.3 阶段三结果合成Claude 从.omc/artifacts/ask/中读取最新的 Codex 与 Gemini 产物按照统一结构生成最终回应共识建议列出两位顾问一致认可的部分冲突建议指出分歧点并附上对各自观点的分析最终选定方向给出裁决及理由例如优先稳定性还是优先用户体验行动清单转化为清晰、可执行的 TODO 项这样的输出结构非常适合落地到工程实践中可以直接作为 PR 审查意见附在评论里可以转换为 issue 或任务列表可以作为技术决策记录存档六、优雅降级在各种异常条件下仍然可用真实世界环境中外部提供商不可用、CLI 缺失、策略禁用等情况非常常见。CCG 提前设计了一整套降级与回退机制。6.1 场景矩阵与行为CCG 的行为逻辑大致如下场景行为说明两个提供商均可用完整三模型合成与冲突解决一个提供商不可用使用可用提供商 Claude 合成并标注缺失视角两个提供商均不可用仅 Claude 作答并说明外部顾问不可用提供商二进制缺失ensureBinary()预先退出并输出诊断信息外部 LLM 被禁用isExternalLLMDisabled()在解析阶段拒绝非 Claude 调用通过这套机制调用方不需要为每种故障额外写条件分支只要依赖 CCG 的统一行为即可。6.2 对工程实践的意义对工程实践者来说这种降级能力可以直接嵌入 CI/CD即便某个云服务短暂故障也能保证流水线有降级结果而非整体崩溃满足合规要求在某些环境中可一键关闭外部 LLM只保留 Claude 结果简化运维负担问题通常可通过产物与日志快速定位到二进制缺失、策略配置或网络问题七、与互操作模式的关系轻量 CCG vs 重量 InteropCCG 并不是跨供应商协作的唯一模式它与“互操作模式”Interop共同构成了 oh-my-claudecode 的跨模型工具箱。7.1 互操作模式概览互操作模式src/cli/interop.ts会启动一个持久化的 tmux 布局左侧是 Claude Code右侧是 Codex CLI中间通过.omc/state/interop/下的共享状态与任务队列进行对话共享状态由shared-state.ts管理用于实现任务传递和消息队列产物交接长时间运行的协作会话互操作模式通过环境变量OMX_OMC_INTEROP_ENABLED、OMX_OMC_INTEROP_MODE、OMC_INTEROP_TOOLS_ENABLED控制支持off、observe、active等模式以适应不同程度的自动化。7.2 关键维度对比维度CCG 合成互操作模式会话生命周期无状态单次调用持久化长时间运行提供商数量Claude Codex Gemini3 个Claude Codex2 个通信方式基于文件的 Markdown 产物双向任务队列 共享状态文件运行时要求仅需 Bash 工具无 tmux 依赖需要 tmux 与 MCP 工具时间开销秒级适合即取即用分钟级会话搭建与持续协作典型场景快速交叉验证、多视角评审、一次性咨询协作开发、长流程任务、持续交互式会话如果把互操作模式比作长期项目中的“跨团队项目群会议”那么 CCG 更像是为单一问题开的一次“专家会诊”省去了长时间管理会话和状态的成本。八、实践场景与使用示例8.1 多视角代码评审典型工作流开发者对某个 PR 运行 CCG请 Codex 从架构完整性和边界情况角度检查实现请 Gemini 从可读性、文档与 API 设计易用性角度进行评审。Claude 汇总输出共识问题例如某模块耦合度过高、缺少关键单元测试分歧点例如Codex 更偏向性能Gemini 更偏向可读性建议的取舍与行动清单通过这种方式可以在一次命令调用内获得多视角、高质量的评审意见适合作为代码评审自动化的一部分。8.2 前后端融合与接口设计当接口改动同时涉及后端 API、数据模型和前端展示逻辑时可以这样使用 CCG对 Codex 的提示词聚焦接口稳定性、兼容性与后端数据流对 Gemini 的提示词聚焦错误信息可读性、表单交互友好性以及文档是否易于前端开发者理解Claude 在合成时可以明确告诉你哪些改动对后端风险较大需要增加回滚方案或灰度发布策略哪些改动从用户体验和协作角度有明显提升值得优先推进8.3 方案选择与交叉验证对于一个重要技术决策例如“是否切换 ORM 框架”或“是否引入新的缓存层”可以使用 CCG 做一次交叉验证Codex 偏向分析实现复杂度、性能与迁移风险Gemini 偏向分析团队学习成本、文档生态与错误诊断体验最终由 Claude 形成决策建议包括推荐方向、风险列表、试点策略和监控指标等。8.4 何时不该用 CCG尽管 CCG 很强大但在以下情况下互操作模式或其他方案更适合需要长时间、多轮的交互式协作例如持续重构一个复杂代码库需要频繁在两个模型之间来回“传球”而不是一次性获取意见需要在会话中维护大量共享状态与中间产物此类场景更适合持久 tmux 共享状态的互操作模式将 CCG 视为补充而非替代。九、设计启示与落地建议从 CCG 的设计中可以总结出几条对通用 AI 工程系统有价值的经验明确的三阶段协议分解、分发、合成让多模型协作变得可测试、可扩展。统一 CLI 抽象层把提供商差异集中到一个脚本处理降低调用方心智负担。产物优先优先依赖结构化文件而非 stdout为审计、CI、二次分析提供基础。安全与隔离优先通过策略门控与环境变量剥离保障会话独立与合规性。降级策略内建把“异常情况”当作常态来设计使得系统在不完美环境中依旧可用。对有意构建多模型协作系统的团队来说可以借鉴的落地方向包括在自家工具链中实现类似的omc ask抽象把不同 LLM 的调用统一封装采用产物化设计用 Markdown 或 JSON 存储所有模型输出设计一套轻量级合成协议在多模型意见中明确“谁说了什么、为什么这么说、要怎么做”通过这类实践可以在保持系统复杂度可控的前提下真正发挥多模型协作的威力。