OumaeKumiko
V2EX  ›  Claude

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

  •  
  •   OumaeKumiko · Jul 24 · 1952 views

    想法

    正在从单纯使用 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 等)。

    21 replies    2026-07-28 15:04:27 +08:00
    MonkeyD1
        1
    MonkeyD1  
       Jul 24
    试试这个吧 https://pi.dev
    OumaeKumiko
        2
    OumaeKumiko  
    OP
       Jul 24
    @MonkeyD1 #1 还是不习惯在终端里操作,感觉用 GUI 更方便 而且我看说连 claude 只能用 api 付费,这太可怕了😰
    yuangui
        3
    yuangui  
       Jul 24
    试试我搞的这个,协同开发: https://github.com/xyva-yuangui/agent-bridge
    gynophobia
        4
    gynophobia  
       Jul 24
    orca / herdr
    zeyangstudies
        5
    zeyangstudies  
       Jul 24
    proma 感觉挺好用,基于 pi 的,可以切换模型
    musi
        6
    musi  
       Jul 24   ❤️ 1
    如果 CCR 使用过程中有问题可以站内艾特我,另外后面 CCR 也会有 agent 路由的功能
    OumaeKumiko
        7
    OumaeKumiko  
    OP
       Jul 24
    @musi #6 大佬回复了🐮 想请教一下 CLIProxyAPI+CCR 路由 codex 老哥收到的封号比例如何😂
    musi
        8
    musi  
       Jul 24   ❤️ 1
    @OumaeKumiko 没有遇到过有反馈封号的,另外我自己在用 CCR 代理 codex ,没有接到 cpa 中
    OumaeKumiko
        9
    OumaeKumiko  
    OP
       Jul 25
    @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
        10
    OumaeKumiko  
    OP
       Jul 25
    @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 自己引入的概念,现在用不上。
    musi
        11
    musi  
       Jul 25 via iPhone   ❤️ 1
    @OumaeKumiko #8 gpt 的 models catlog 不代表实际的上下文长度,只是官方在 codex 这个场景会有些取舍,你可以查看实际的 api 的上下文长度,这些模型在 openrouter 的的上下文都是 1M
    musi
        12
    musi  
       Jul 25 via iPhone   ❤️ 1
    @OumaeKumiko #10 ,ai 分析的还是有问题
    ccr 作为一个网关是可以聚合不同的上游和模型的,你可以直接导入本地的 cc 认证,然后在你需要的时候切换就行
    OumaeKumiko
        13
    OumaeKumiko  
    OP
       Jul 26
    @musi #12 折腾死了,从下午折腾到现在,还没整完😂claude opus/fable 一直在帮我研究,现在进入到了,在 TUI 里面是可以正常用第三方模型以及 claude 直接连订阅,但是在 GUI 里面还是不行。他就说搜了半天也没找到现成的方案,就只能自己试。我也不知道它到底搜的对不对。
    OumaeKumiko
        14
    OumaeKumiko  
    OP
       Jul 26
    @musi #12 opus 跟我说,「作者本人建议的替代路是「把本机 Claude Code 的登录态导入成一个供应商」——这条在你这台机器上直接死:它的 readClaudeCodeOauth() 只遍历 ~/.claude/.credentials.json 这类磁盘文件,只要第一个能解析就直接 return ,永不走钥匙串。而本机磁盘那份当时已经过期四天(打接口 401 ),活的那份在钥匙串里。」请教一下这个说法对么,它现在跟我说 CCR 没用了,就只需要 CPA+它自己写的插件和脚本


    ----

    ## 先纠正一个前提:你现在用的**绝大部分就是现成方案**

    | 层 | 是什么 | 自建成分 |
    |---|---|---|
    | 第三方全部模型( GPT/DeepSeek/千问) | **CLIProxyAPI 原封不动** | 零。账号池、协议翻译、出海代理全是它干的 |
    | Claude 订阅那一支 | 一个约 200 行的插件 | 自建,但它是**为 CCR 的插件接口写的**,今天没动 |
    | 进程宿主 | 150 行 Node | 今天才自建,**替换的只是 CCR 这一个角色**,端口和插件都没变 |

    所以不是「大费周章重造轮子」,是**在现成方案上补了一块它们都不提供的东西**。

    ## 那一块是什么:「 Claude 走订阅计费」

    这是你定死的需求,也是唯一逼出自建代码的那一条。两个工具各自的**源码级结论**(当初核对的是与本机版本精确一致的源码,CCR v3.0.15 / CPA v7.2.95 ):

    **CPA 单独用 → 只能按量付费,或者被判第三方**

    它服务 Claude 模型只有两条路:填官方 API key (按量计费,跟你的订阅无关),或者用 Claude OAuth 登录(就是那种会被判成第三方壳的模式)。**两条都保不住订阅。** 它那个 `passthrough-headers` 名字唬人,实际是「把上游的**响应头**转发给下游」,跟凭据无关。

    **CCR 单独用 → 凭据透传这个能力它没有**

    - 它的 `passthrough` 是**协议格式**透传(格式一致时不翻译 body ),跟凭据无关;`provider_auth` 阶段**永远执行**,一律用 provider 自己配的 key 去认上游。也就是说客户端自己的订阅 token 根本到不了 Anthropic 。
    - 社区有**四个 PR**想加这个能力(#1219 passthrough_auth 、#1295 、#1333 、#1408 ),到 2026-07-25**全部还是 open ,一个都没合并**。
    - 作者本人建议的替代路是「把本机 Claude Code 的登录态导入成一个供应商」——**这条在你这台机器上直接死**:它的 `readClaudeCodeOauth()` 只遍历 `~/.claude/.credentials.json` 这类磁盘文件,只要第一个能解析就直接 return ,**永不走钥匙串**。而本机磁盘那份当时已经过期四天(打接口 401 ),活的那份在钥匙串里。

    所以要「 Claude 走订阅」,必须有一段自己的代码做三件事:**正文一字不改地转发、装上长期订阅 token 、把 `anthropic-beta` 合并进去(合并不是覆盖)**。这三件现成工具都不给。

    **至于今天为什么连 CCR 这个宿主也换掉**——不是嫌它路由做得不好,是它会自作主张改桌面 App 的配置。你今天早上 GUI 进不去网关模式,根因就是我退出 CCR 时它把 `deploymentMode` 还原成了 `1p`;它还有孤儿进程问题,制造过「我明明改了插件、也重启了、行为却没变」的假象。换成 150 行宿主后,插件和端口一个没动。
    musi
        15
    musi  
       Jul 26
    @OumaeKumiko 你现在的问题是什么?我现在已经看不懂你的问题了
    OumaeKumiko
        16
    OumaeKumiko  
    OP
       Jul 26
    @musi #15 啊.....应该没啥问题了,折腾两天 claude 帮我实现了在 claude.app 里,claude 订阅的请求原样透传+gpt 等其它模型在列表里面,最后说只需要 CPA 加几个脚本,CCR 用不到😂
    musi
        17
    musi  
       Jul 26   ❤️ 1
    @OumaeKumiko 可以,还是建议下次不要用 ai 回复了,分析问题太累了
    OumaeKumiko
        18
    OumaeKumiko  
    OP
       Jul 26
    @musi #17 okok
    OumaeKumiko
        19
    OumaeKumiko  
    OP
       Jul 28
    @musi #11 我自己测着 gpt 的订阅是 368k 上下文,再多就爆了
    musi
        20
    musi  
       Jul 28
    @OumaeKumiko #19 这样,原来订阅一直给的是阉割版的?我还以为只是在客户端上限制了,真该死啊
    OumaeKumiko
        21
    OumaeKumiko  
    OP
       Jul 28
    @musi #20 嗯,openai 官方文档里就写的 付费额度才是 1m
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5569 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 40ms · UTC 03:39 · PVG 11:39 · LAX 20:39 · JFK 23:39
    ♥ Do have faith in what you're doing.