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

7 月 24 日
 OumaeKumiko

想法

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

2833 次点击
所在节点    Claude
21 条回复
MonkeyD1
7 月 24 日
试试这个吧 https://pi.dev
OumaeKumiko
7 月 24 日
@MonkeyD1 #1 还是不习惯在终端里操作,感觉用 GUI 更方便 而且我看说连 claude 只能用 api 付费,这太可怕了😰
yuangui
7 月 24 日
试试我搞的这个,协同开发: https://github.com/xyva-yuangui/agent-bridge
gynophobia
7 月 24 日
orca / herdr
zeyangstudies
7 月 24 日
proma 感觉挺好用,基于 pi 的,可以切换模型
musi
7 月 24 日
如果 CCR 使用过程中有问题可以站内艾特我,另外后面 CCR 也会有 agent 路由的功能
OumaeKumiko
7 月 24 日
@musi #6 大佬回复了🐮 想请教一下 CLIProxyAPI+CCR 路由 codex 老哥收到的封号比例如何😂
musi
7 月 24 日
@OumaeKumiko 没有遇到过有反馈封号的,另外我自己在用 CCR 代理 codex ,没有接到 cpa 中
OumaeKumiko
7 月 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
7 月 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
7 月 25 日
@OumaeKumiko #8 gpt 的 models catlog 不代表实际的上下文长度,只是官方在 codex 这个场景会有些取舍,你可以查看实际的 api 的上下文长度,这些模型在 openrouter 的的上下文都是 1M
musi
7 月 25 日
@OumaeKumiko #10 ,ai 分析的还是有问题
ccr 作为一个网关是可以聚合不同的上游和模型的,你可以直接导入本地的 cc 认证,然后在你需要的时候切换就行
OumaeKumiko
7 月 26 日
@musi #12 折腾死了,从下午折腾到现在,还没整完😂claude opus/fable 一直在帮我研究,现在进入到了,在 TUI 里面是可以正常用第三方模型以及 claude 直接连订阅,但是在 GUI 里面还是不行。他就说搜了半天也没找到现成的方案,就只能自己试。我也不知道它到底搜的对不对。
OumaeKumiko
7 月 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
7 月 26 日
@OumaeKumiko 你现在的问题是什么?我现在已经看不懂你的问题了
OumaeKumiko
7 月 26 日
@musi #15 啊.....应该没啥问题了,折腾两天 claude 帮我实现了在 claude.app 里,claude 订阅的请求原样透传+gpt 等其它模型在列表里面,最后说只需要 CPA 加几个脚本,CCR 用不到😂
musi
7 月 26 日
@OumaeKumiko 可以,还是建议下次不要用 ai 回复了,分析问题太累了
OumaeKumiko
7 月 26 日
@musi #17 okok
OumaeKumiko
7 月 28 日
@musi #11 我自己测着 gpt 的订阅是 368k 上下文,再多就爆了
musi
7 月 28 日
@OumaeKumiko #19 这样,原来订阅一直给的是阉割版的?我还以为只是在客户端上限制了,真该死啊

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1229576

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX