让 Claude 派活儿给 WorkBuddy 里的模型

一、不同的模型有不同的视角

我们在本地电脑上已经打通了不少东西。Claude 的多个账号可以自动调度（见《我把两个 Claude 账号打通了》），GPT 的 Codex 可以跨厂商调用 Claude 的 Opus（见《我的 GPT-6 Astra 也可以调用 Claude 了》），内网部署的 27B 模型也接进了 worker 机制，跑多少都不花钱。不同厂商、不同模型，在同一台机器上协同干活，这条路已经走通了。

走通之后有一个体会越来越深：不同模型审同一段代码，给出的意见确实不一样。GLM 的训练语料偏中文生态，Kimi 在长上下文处理上有自己的一套，DeepSeek 在代码推理上走过不同的技术路线。这些差异反映在 code review 里，有时候能挑出 Claude 自己注意不到的问题。就像找人审代码，找的不一定是比自己强的人，而是跟自己看法不同的人。

手上正好有一个腾讯 WorkBuddy 的账号。每天可以领免费积分，GLM、Kimi、DeepSeek、混元这些模型基本都能用上，其中还有几个是零倍率的。试错代价极低。

那能不能也把这些模型接进来，让 Claude 干活的时候能调它们？

先说清楚预期：日常使用的主力还是 Claude 的 Fable，能力差距是明显的。但拿 WorkBuddy 里的模型来做审查、做交叉验证、跑一些独立的探查任务，多一个视角总比没有好。

二、第一条路是反代，走不通

要接入 WorkBuddy 的模型，第一反应当然是看看社区有没有现成方案。

GitHub 上搜"workbuddy2api"和"codebuddy2api"，出来十几个仓库，Go、Python、Tauri 桌面版都有。做法大同小异：读 WorkBuddy 桌面端存在本机的登录态文件，伪造设备指纹和风控头，把 OpenAI 或 Anthropic 协议翻译成腾讯的私有协议，对外暴露一个兼容接口。

翻了几个项目的 issue 和源码，能反推出腾讯服务端在查什么。系统提示词精确匹配，Claude Code 和 Codex 的固定提示句子碰上就报错。客户端指纹校验，User-Agent 和 IDE 标识不对直接拒绝。频率限制，请求形态异常就触发。所有反代项目都在做"脱敏"和"伪装"，本质上是在跟风控赛跑。

我们的 WorkBuddy 是主力号，不能冒封号的风险。这条路到此为止。

三、腾讯有官方 CLI，而且它长得太眼熟了

反代走不通，我们回头看腾讯官方有没有提供什么正规渠道。

然后就发现了一个东西：npm i -g @tencent-ai/codebuddy-code。

装完敲 codebuddy --help，输出一出来，我们愣了一下。

命令叫 codebuddy，因为 WorkBuddy 和 CodeBuddy 本质上是同一套账号体系、同一份积分，只是面向不同用户群的两个入口（我们单独写过一篇理清这层关系，见《一文讲透 WorkBuddy 和 CodeBuddy 到底有什么区别》）。命令行叫 codebuddy，接的就是 WorkBuddy 的账号和额度。

回到那个 help 输出。-p/--print、--output-format stream-json、--model、--max-turns、--system-prompt、--mcp-config、--resume、--session-id、--permission-mode。这些参数我们每天在 Claude Code 里用，现在一个不差地出现在了腾讯的 CLI 里。

不只是参数名像。用 --output-format stream-json 试了一次无头调用，输出的事件流格式也是同一套结构：system/init → assistant → result，每条事件带 usage、session_id。跟 Claude Code 的 stream-json 输出几乎完全一致。

我们为 Claude Code 写的 stream-json 解析代码，把可执行文件名从 claude 换成 codebuddy，直接跑通了。

这大概率不是巧合。Claude Code 的接口设计正在成为这个领域的事实标准，腾讯的 CLI 团队显然参考了它。对我们来说，这是一个巨大的便利：已有的代码几乎不用改。

四、反代要伪造的一切，官方 CLI 天然就有

发现官方 CLI 之后，前面反代路线里纠结的那些问题一下子全消失了。

反代项目费尽心思伪造客户端指纹、脱敏系统提示词、模拟设备行为，本质上是在冒充官方客户端。而官方 CLI 本身就是官方客户端。合法的指纹、正规的登录流程、腾讯自己的 API 通道，都是自带的，不需要伪造任何东西。

有一个细节值得提一下。CLI 的登录态和 WorkBuddy 桌面端是分开的。CLI 有自己独立的配置目录 ~/.codebuddy，第一次使用需要在终端里跑一次 codebuddy 进入交互界面，输入 /login 完成登录。凭证存在 CLI 自己的目录下，跟桌面端互不干扰。

用官方 CLI 调用模型，跟用官方桌面客户端打开 WorkBuddy 聊天没有本质区别。主力号可以放心用。

五、怎么接的

技术路线跟我们之前打通 Claude 多账号、接 GPT 的思路一脉相承。核心改动是给账号档案加一个 provider 字段标记身份类型。以前只有 anthropic，现在多了一个 codebuddy。worker 脚本看到 codebuddy 类型的账号，就起一个 codebuddy -p 的无头进程，而不是 claude -p。

子代理的安全边界写死了几条：默认只读工作区（只开放 Read、Glob、Grep 三个工具），同一标签内串行执行，超时强制杀掉整棵进程树。

在交互层面，主代理通过一个 MCP 工具 ask_account 来发起调用。Claude 在对话中判断什么时候需要问、问哪个账号的哪个模型、问什么问题，主进程把请求路由到对应账号的子进程，子进程跑完后把结果作为工具返回值交回 Claude 的推理流程。

因为事件流格式同构，解析代码几乎没改。之前为 Claude Code 的 stream-json 写的那套解析逻辑，对 CodeBuddy 的输出一样适用。

六、用 WorkBuddy 的模型写接入 WorkBuddy 的代码

这是当天最有趣的一段经历。

整个实现拆成了四个任务：第一个是给账号档案加 provider 字段和旧数据迁移，第二个是 CodeBuddy 引擎（让系统能起 codebuddy 进程），第三个是 ask_account 工具和主进程的接线逻辑，第四个是账号管理页面的改版。

本来打算用内网 27B 模型当 worker 来跑这四个任务。结果中转服务当天正好挂了（没插网线）。

那就直接让 CodeBuddy 的模型来。

GLM-5.3 跑了前两个任务。第一个任务顺利完成。第二个任务是"CodeBuddy 引擎"本身，GLM-5.3 在实现过程中还主动修了计划里遗漏的一处问题：没有配置目录的 CodeBuddy 档案会被误识别成默认的 Anthropic 档案。这个边界情况任务书里没提到，模型自己发现的。

然后 GLM-5.3 撞了频率限制，429。换 Kimi-K3 接第三个任务，做完之后也撞了 429。换 GLM-5.2 做第四个，收尾完成。

四本任务书全部由 CodeBuddy 的模型跑完，Anthropic 额度零消耗。

把这件事捋一遍会发现一个套娃：GLM-5.3 写了一套代码，这套代码的功能是让 Claude 以后能调用 GLM-5.3。模型写了接入自己的代码。

内网中转挂掉本来是个意外，结果变成了一次真实的压力测试。这些模型到底能不能独立完成有质量的编码任务？四个任务交付后跑了一轮完整验收：888 个单测通过，类型检查零错误，构建通过，两套真机脚本全部通过。当天下午发布了 v3.14.0，随后修了几个小问题，发了 v3.14.1。

七、免费模型的边界在哪

连续跑十几分钟编码任务后 GLM-5.3 撞了 429，提示信息写着 5 小时后重置。换 Kimi-K3 继续，跑了一阵也撞了。连续高强度调用下确实有频率上限。

但有一个关键细节：频率限制是按模型分开的。GLM-5.3 到了上限，切 Kimi-K3 立刻能用。Kimi-K3 也到了，切 GLM-5.2 接着来。模型池本身就是一种天然的限流缓冲。当天四个任务轮流用了三个模型，正是因为这个机制才没有被完全卡住。

所以这些模型的定位很清楚。代码审查、独立验证、单文件探查，这类短平快的任务很合适。当批量编码流水线来用，频率限制会成为瓶颈。它们的价值在于提供不同的视角。

主力号的安全策略最终收敛为三条：用官方客户端、单并发串行、不刷任务不轮账号。

八、试试看

我们自己有多个 WorkBuddy 账号。如果想让 Claude 能调用不同账号下的模型，这些账号都需要在本机完成 CLI 登录。手动管理多个 CodeBuddy 的配置目录和登录状态，操作上比较繁琐。

ClaudeTerminal 从 v3.14.0 开始支持 CodeBuddy 类型的账号，做这件事会方便很多。在账号管理页面可以直接添加和登录多个 WorkBuddy / CodeBuddy 账号，每个账号独立管理配置目录和登录状态，自动探测可用模型。左栏按提供方分组，带状态指示灯；中栏是身份卡片，Claude 账号会显示 5 小时和周额度的进度条与重置倒计时。多个账号的状态一目了然。

登录完成后，在任意对话标签里，Claude 可以通过 ask_account 调用这些账号下的模型，子代理只读保护、串行执行、超时管控这些安全机制都内建在产品里。

ClaudeTerminal 是我们给 Claude Code CLI 套的一个桌面图形壳。引擎是官方的 Claude Agent SDK，会话数据和终端里的 claude 命令完全互通，随时可以回终端，没有迁移成本。

我们还在持续往里面加东西。从最早的续跑和定时任务，到任务队列、多账号调度、跨厂商调用，再到现在接入 WorkBuddy 的模型生态，ClaudeTerminal 能管的东西越来越多，能力也在一个版本一个版本地变强。欢迎一起用，一起提问题。

下载地址：https://github.com/guoy0701/ClaudeTerminal/releases

安装一次，之后有新版本会自动提示更新。目前支持 Windows x64，个人业余项目，闭源。

问题反馈和建议：https://github.com/guoy0701/ClaudeTerminal/issues

也可以在应用内点帮助菜单的"反馈"，或者直接输入 /feedback。