2. V2EX
  3. 想尝试 Claude + Codex + DeepSeek/Qwen/... 协同多子代理，大家目前用的什么方案？

想尝试 Claude + Codex + DeepSeek/Qwen/... 协同多子代理，大家目前用的什么方案？

OumaeKumiko 2026-07-24 15:38 1

想法


正在从单纯使用 claude/codex 干活，额度用完切到另一边，发展到协同使用，因为 Fable 和 gpt5.6sol 确实太贵了。


而且我非常讨厌 GPT 的说话风格（充满伪人感🤮），5.6 系列还有强烈的过度完成、简单任务被复杂化的倾向。


其他模型说话风格都还不错，尤其是 Claude ，Fable 做规划也确实好用，但就是贵。所以想着能不能让强模型当大脑，指挥 DeepSeek / Qwen / GLM 等便宜模型去干活，省下一大截钱。


最终目标就是，只在一个对话窗口里操作，不换窗口、不手动切模型。让窗口里的 Fable/GPT 自动分配「规划 / 质疑 / 执行 / 检查」等任务给其它模型，干完活自动反馈，我就在这个窗口里处理。


方案列表


目前搜到几种方向，让大模型查了一番进行对比如下，但是心里也没底，想问问大家真实在用哪套、体验如何、稳不稳定：




  1. Claude Code + CCR （ Claude Code Router ）


    内部把 DeepSeek / Qwen / Kimi / GLM / 本地模型路由进去，再用 /agent 或 agent 定义文件指定不同模型当 sub-agent 。


    另外，前段时间 openai 的 Tibo 提过 CLIProxyAPI （ https://x.com/thsottiaux/status/2076119366647894371 )，评论区有人说因为这个被封，但被封的好像是极少数，很多人长期在用没问题，所以有点犹豫……




  2. Claude Code + headless OpenCode / OpenCode MCP / Codex CLI


    或者用插件/MCP 在 Claude Code 里直接调用 Codex 或 OpenCode 当 worker 。




  3. Codex 为主 + 插件/路由联动其它大模型。我看官方没有插件，都是第三方的实现。




  4. 其它方案（ OpenCode 原生多模型 Agent Teams 、Claudexor 类统一工作区、CLIProxyAPI 等）。



最新回复 (10)
  • MonkeyD1 07-24 15:44
    1楼
    试试这个吧 https://pi.dev
  • OumaeKumiko 楼主 07-24 15:52
    2楼
    @MonkeyD1 #1 还是不习惯在终端里操作，感觉用 GUI 更方便 而且我看说连 claude 只能用 api 付费，这太可怕了😰
  • yuangui 07-24 15:58
    3楼
    试试我搞的这个，协同开发： https://github.com/xyva-yuangui/agent-bridge
  • gynophobia 07-24 16:26
    4楼
    orca / herdr
  • zeyangstudies 07-24 16:27
    5楼
    proma 感觉挺好用，基于 pi 的，可以切换模型
  • musi 07-24 16:52
    6楼
    如果 CCR 使用过程中有问题可以站内艾特我，另外后面 CCR 也会有 agent 路由的功能
  • OumaeKumiko 楼主 07-24 21:00
    7楼
    @musi #6 大佬回复了🐮 想请教一下 CLIProxyAPI+CCR 路由 codex 老哥收到的封号比例如何😂
  • musi 07-24 23:01
    8楼
    @OumaeKumiko 没有遇到过有反馈封号的，另外我自己在用 CCR 代理 codex ，没有接到 cpa 中
  • OumaeKumiko 楼主 07-25 19:22
    9楼
    @musi #6 我正在让 claude 给我研究怎么配，发现一个问题捏（站长不要封我，只是在反馈问题😂）


    ----


    报个模型元数据的问题。我用 CCR 网关接 CLIProxyAPI 的 Codex 模型，在 Claude Code 的 /model 里看到所有 GPT 模型后面都带 [1m]，显示名还写着「(1M context)」。

    抓了一下网关的 /v1/models ，返回里 capabilities.context_management.max_input_tokens 是 1050000 。但查 Codex 官方下发的模型清单（~/.codex/models_cache.json ），实际是：gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna / gpt-5.5 / gpt-5.4-mini 都是 context_window: 272000 、max_context_window: 272000 ； gpt-5.3-codex-spark 只有 128000 ；只有 gpt-5.4 和 codex-auto-review 的 max_context_window 到 100 万（默认也仍是 272000 ）。同一个模型直接问 CLIProxyAPI ，它报的 max_input_tokens 也是 272000 ，跟官方清单一致。

    看代码像是 packages/core/src/gateway/model-catalog.ts 里 GPT-5.6 那条 catalog 写死了 contextTokens: 1_050_000 / inputTokens: 1_050_000 / supports1MContext: true ，于是 model-discovery.ts 走 oneMillionContext 分支给 ID 加了 [1m]。gpt-5.6-codex 可能确实有 1M （ CLIProxyAPI 那边有个 issue #4195 就是要求报 1050000 ），但 sol/terra/luna 这几个不是。

    后果是 Claude Code 以为有 100 万上下文，就不会及时触发压缩，超过 27.2 万之后要么上游报错、要么静默截断，界面上看不出发生了什么。

    建议优先采用上游报的真实值（ CLIProxyAPI 的 /v1/models 里有 max_input_tokens ； models_cache.json 里有 context_window / max_context_window ），或者至少别把 gpt-5.6 那条 catalog 套到名字不同的 sol/terra/luna 上。
  • OumaeKumiko 楼主 07-25 19:33
    10楼
    @musi #6
    我是想着，在 Claude Code 里，既要接第三方的大模型，又要把 Claude 本身的请求原样透传给 A\，让 Claude 调研了一番，他说目前 CCR 官方这几个月就没有接这个请求，是官方不好实现吗？ Claude 说如果官方不实现的话，他自己能照着这些写一个，给我自己用的。😂


    -----------

    Claude Code 只能配一个后端地址。 所以「 Claude 模型 + 第三方模型都要」这件事，必须由站在那个地址上的东西来分。
    现成的网关都会把你的凭据换成自己的。CCR 的请求链路里 provider_auth 这一步是必经的——它一定用它自己配置的 key 去认证上游。而你的 Claude 订阅计费，前提恰恰是你自己的凭据原样到达 Anthropic 。
    所以那个站在地址上的东西必须会做一件现成工具都不做的事：对 Claude 的请求「不作为」。 这就是插件存在的全部理由。


    一、四个 PR 核实为真，都没合并
    用 gh 逐个查了，标题就是我们要的东西：

    PR 提交日 状态 标题
    #1219 2026-02-18 OPEN 未合并 add passthrough_auth option for OAuth bearer token forwarding
    #1295 2026-03-25 OPEN 未合并 multi-auth routing, security patches, and bypass fix
    #1333 2026-04-15 OPEN 未合并 skip redundant Authorization header in bypass mode
    #1408 2026-05-24 OPEN 未合并 add OAuth support to the built-in Anthropic transformer
    五个月里四个人独立提了同一件事，维护者一个都没合。 顺带查实：v3.0.15 源码里没有 bypass mode ，那个词是这些未合并 PR 自己引入的概念，现在用不上。
* 帖子来源V2EX
附近帖子
返回
飞读
随机推荐