Skip to content

feat: 新增 codebuddy 客户端支持(bili codebuddy) #640

Closed

Description

@ProgramerNoob

背景

codebuddy(CodeBuddy Code CLI,npm 包 @tencent-ai/codebuddy-code)是腾讯的 AI agent CLI。它和 claude 一样是 Node CLI,原生支持用环境变量覆盖 API 端点,接入成本低,值得加入 launcher 列表。

推荐方案:claude 式 /bili/ rewrite,proxy mode

codebuddy 有 CODEBUDDY_BASE_URL 环境变量,启动时注入即可把模型流量打进本地代理。不需要 cert-MITM,也不用碰用户的配置文件:

CODEBUDDY_BASE_URL=http://127.0.0.1:PORT/bili/<真实upstream>

压缩走 proxy mode。codebuddy 不是 ACP-native agent,做 agent 侧薄 plugin 不现实。wire 格式上 OpenAI 和 Anthropic 两种 adapter 都是现成的。

调研确认的配置事实

从本机安装包(dist/codebuddy.js)和内置文档核实:

  • 上游有两个配置面。env CODEBUDDY_BASE_URL + CODEBUDDY_API_KEY(Anthropic 协议);models.json 里每个模型的 url 字段(OpenAI /chat/completions 完整路径)+ apiKey + maxInputTokens,其中 maxInputTokens 可以直接当作 context window 声明。
  • models.json 分两级:~/.codebuddy/models.json 和 <workspace>/.codebuddy/models.json,项目级优先。
  • 平台登录态的默认端点是 https://tencent.sso.codebuddy.cn/v2(国内版)。控制面独立(CODEBUDDY_CONTROL_BASE_URL),rewrite 只影响模型流量,登录和产品配置加载不受影响。
  • 配置根目录可用 CODEBUDDY_CONFIG_DIR 覆盖,默认 ~/.codebuddy。settings.json 有 env 块和 autoCompactWindow 字段。
  • 原生 auto-compact 由 CODEBUDDY_AUTO_COMPACT_WINDOW / CODEBUDDY_AUTOCOMPACT_PCT_OVERRIDE / settings autoCompactWindow 控制,正好对应 REQ: codex 压缩预算协调 + 匿名代理模式拦截伪造(根本解决方案) #321 的 claude 预算对齐模式(env 注入面)。
  • MCP 注入走 --mcp-config <fileOrString>,不带 --strict-mcp-config 时与用户配置合并,对应 mcp.ts 的 spawn 时注入路径。

接入点清单

  1. src/client-config.ts:新增 CodebuddyConfig、resolveCodebuddyHome(env)(读 CODEBUDDY_CONFIG_DIR)、readCodebuddyConfig(),只读发现 settings.json(env 块的 CODEBUDDY_BASE_URL、顶层 model、autoCompactWindow)和两级 models.json(url 收集 + maxInputTokens 转 ModelWindow);挂进 loadClientConfig、ModelWindowScope、collectModelWindows。
  2. src/launcher.ts:LAUNCH_CLIENTS 加 "codebuddy";discoverRoutes 加分支(仿 claude);新增 buildCodebuddyEnv()(仿 buildClaudeEnv);预算对齐复用 claude 的 env 注入路径;runLaunch 和 resolveClientCommand 加分支(binary 名 codebuddy / cbc)。
  3. src/discover.ts:extractHttpsHosts 加 codebuddy 分支;configFilePaths 加 settings.json 和 models.json 路径。
  4. src/cli.ts:HELP 加一行(isLaunchClient 自动识别,无新分支)。
  5. 测试仿 launcher.test.ts、codex-window-align.test.ts 的模式,补发现 / rewrite / 预算对齐用例。
  6. README client 章节和 AGENTS.md 模块表同步更新。

开放问题

  1. 国际版默认端点未确认。本机只核实到国内版 tencent.sso.codebuddy.cn/v2,代码里需要兜底两种。
  2. models.json 里的 per-model url 不经过 CODEBUDDY_BASE_URL,env rewrite 盖不住这部分流量。两个选择:(a) 首版只支持 env / 平台路径并在文档注明;(b) dsh 式持久 overlay,但把 CODEBUDDY_CONFIG_DIR 指向 overlay 目录会隔离用户的 sessions 和记忆,代价太大。建议首版选 (a)。
  3. 纯平台登录场景(无 models.json,模型走平台端点)env rewrite 一条路径即可全覆盖,适合作为首个验证场景。

Activity

  1. ranxianglei commented on Sep 8, 2026

    @ranxianglei
    Owner

    ework 接单

  2. ranxianglei commented on Sep 8, 2026

    @ranxianglei
    Owner

    🤖 Powered by ework · qwen3.8-27b

    已完成,PR: #641

    按 OP 方案实现(claude 式 /bili/ rewrite,proxy mode,wire 注入):

    实现

    • src/client-config.ts:CodebuddyConfig / resolveCodebuddyHome()(CODEBUDDY_CONFIG_DIR ?? ~/.codebuddy)/ readCodebuddyConfig()——只读发现 settings.json(env 块 CODEBUDDY_BASE_URL、顶层 model/autoCompactWindow、shell env 兜底)+ 两级 models.json(项目级按 model id 优先,maxInputTokens → ModelWindow,per-model url 收集为清单)。parseCodebuddyModelsJson() 对容器形状做了容错(顶层 map / models map / 数组)——实际落盘形状未经真机核实,容错读取避免首版踩空。
    • src/launcher.ts:discoverRoutes claude 式分支(默认 https://tencent.sso.codebuddy.cn/v2,CODEBUDDY_BASE_URL rewrite);buildCodebuddyEnv();resolveCodebuddyBudgetEnv()——REQ: codex 压缩预算协调 + 匿名代理模式拦截伪造(根本解决方案) #321 预算对齐走 CODEBUDDY_AUTO_COMPACT_WINDOW(无 model / 用户已设 / shell 已导出 / 解析不到窗口 → 不注入);resolveClientCommand 依次找 codebuddy / cbc。
    • src/discover.ts / src/cli.ts / README / AGENTS.md 同步。
    • 新增 17 个测试(发现、rewrite、预算对齐、命令解析、runLaunch 集成、discover 域名)。

    v1 限制(按 OP 决策 (a),代码注释 + PR 里都注明了)

    1. models.json per-model url 不走代理(绕开 CODEBUDDY_BASE_URL)——首版只覆盖 env/平台路径;纯平台登录(无 models.json)是首个验证场景。
    2. 国际版默认端点未确认——兜底用国内版端点,其他部署需显式设 CODEBUDDY_BASE_URL。
    3. 未做 MCP 注入(纯 wire mode):--mcp-config 兼容性未经真机验证,留作后续;验证过后可像 claude 一样接上。

    Pre-flight:typecheck ✓;test 1251/1252(唯一失败是环境性的既有问题:沙箱里装了 /usr/bin/codex,导致 resolveClientCommand: codex/claude resolve to themselves 在 master 上同样失败,已用 git stash 验证,CI 上通过);build ✓。

    建议真机验证路径:纯平台登录场景跑 bili codebuddy,确认模型流量走 /bili/、压缩循环正常触发、CODEBUDDY_AUTO_COMPACT_WINDOW 对齐日志出现。

  3. ranxianglei commented on Sep 8, 2026

    @ranxianglei
    Owner

    需要确认登录协议是否私有,据我理解,类似qoder的是私有的,不通用.

    需要确认这个软件是否一样.建议下载研究

  4. ranxianglei commented on Sep 8, 2026

    @ranxianglei
    Owner

    继续

  5. ranxianglei commented on Sep 8, 2026

    @ranxianglei
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 已下载 @tencent-ai/codebuddy-code@2.147.0(公网 npm 包,169MB)研究,结论如下:

    1. 登录协议:确实是私有的(你的判断正确)

    product.json → authentication:

    { "id": "Tencent-Cloud.coding-copilot", "type": "cli-external-link", "label": "TencentCloud",
      "attributes": { "tokenHeader": "Authorization", "tokenType": "bearerToken",
        "usernameHeader": "X-User-Id", "usernameEncode": "URLEncode", "prefixPath": "/plugin",
        "iOADomain": ["tencent.sso.copilot.tencent.com", "tencent.sso.codebuddy.cn", ...] } }

    登录 = CLI 拉起外部链接走腾讯 SSO(tencent.sso.codebuddy.cn 等),用户腾讯账号认证后拿 bearer token——和 qoder 同类:私有 SSO,不是标准 OAuth,第三方无法互操作。模型请求携带 Authorization: Bearer <token> + X-User-Id/X-Enterprise-Id 等身份头。

    但这不影响 bili 的方案:登录走 SSO/控制面,bili 完全不碰(rewrite 只作用于模型流量的 CODEBUDDY_BASE_URL);token 对代理是不透明的——codebuddy 发出、代理原样转发给真实上游。决定 bili 能否工作的是模型流量的 wire 协议,不是登录协议。

    2. 重要更正:模型 wire 是 OpenAI,不是 Anthropic

    OP 里"env CODEBUDDY_BASE_URL + CODEBUDDY_API_KEY(Anthropic 协议)"是误判。dist/codebuddy.js 的 ModelProvider 直接用 OpenAI SDK:

    createClient(ei, ea) { return new OpenAI(this.buildOpenAIClientOptions(ei, ea)) }
    // { baseURL, apiKey, fetch: axiosToFetchAdapter(), maxRetries: 0, timeout }

    请求是 POST <base>/chat/completions,标准 OpenAI chat body + SSE。base URL 优先级:models.json per-model url > CODEBUDDY_BASE_URL > <productEndpoint>/v2。

    对 bili 无影响,现有 PR 直接可用:/bili/ rewrite 是 wire-agnostic 的;代理按路径判协议(src/server.ts:983:/chat/completions → openai adapter),codebuddy 流量走的就是现成的 OpenAI 压缩管线。我把注释/README 里的"Anthropic protocol"措辞更正了(commit ab93c77,已推 PR #641)。

    3. 顺带解决了 OP 开放问题 #1(国际版端点)

    • 国际版(公网 npm product.json):endpoint: "https://www.codebuddy.ai" → 模型端点 https://www.codebuddy.ai/v2
    • 国内版(OP 已核实):https://tencent.sso.codebuddy.cn/v2
    • 另有 internal/ioa(copilot.tencent.com)、cloudhosted、selfhosted 变体

    launcher 默认保留国内版(目标用户群),国际版用户需显式设 CODEBUDDY_BASE_URL=https://www.codebuddy.ai/v2(settings.json 或 shell)——现在可以写具体值了。

    4. 其他核实(v2.147.0 bundle)

    • CODEBUDDY_AUTO_COMPACT_WINDOW 确认存在(resolveWindowBase 读它覆盖 base window)→ 预算对齐有效
    • --mcp-config <fileOrString> + --strict-mcp-config 确认存在,语义与 claude 一致 → MCP 注入可作后续(flag 在,MCP client 兼容性未验证)
    • models.json 实际形状确认:{ models: [{id, name, url, apiKey, maxInputTokens, ...}], availableModels: [...] } → 我写的防御式解析恰好覆盖这个形状
    • settings.json env 块确认被尊重(代码里有 "custom CODEBUDDY_BASE_URL is set" 检查)
    • binary 名:codebuddy / cbc / codebuddy-code / cbc-prewarm / codebuddy-lowmem → 我写的 codebuddy→cbc fallback 正确
    • models.json 两级路径:<configDir>/models.json + <cwd>/.codebuddy/models.json(configDir 尊重 CODEBUDDY_CONFIG_DIR)

    结论:登录私有但不挡路;真实 wire 是 OpenAI chat completions,bili 已支持。PR #641 就绪(含另一个 agent 补的 Windows CI 测试修复 b216a0e + 本次协议措辞更正)。

  6. ranxianglei commented on Sep 8, 2026

    @ranxianglei
    Owner

    再提交一个 qoder issue 支持并提供指导

  7. ranxianglei commented on Sep 8, 2026

    @ranxianglei
    Owner

    挂了?继续

  8. ranxianglei commented on Sep 8, 2026

    @ranxianglei
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 没挂,是进程卡住被重启了一次(调研 qoder bundle 时一次大文件扫描挂起)。调研已完成,qoder issue 已提交:

    #653 — feat: 新增 qoder 客户端支持(bili qoder)

    核心结论(下载 @qoder-ai/qodercli@1.1.47 + @qodercn-ai/qoderclicn@1.1.47 从 bundle 核实):

    1. 登录私有(你的判断正确):浏览器 SSO(30 分钟自动刷新)或 PAT(QODER_PERSONAL_ACCESS_TOKEN),token 对代理不透明,不影响 bili
    2. 模型 wire 是 OpenAI chat completions:POST https://<host>/model/v1/chat/completions(标准 OpenAI body + qoder 扩展字段),SSE
    3. 和 codebuddy 的关键差异:scheme 硬编码 https,没有可用的 HTTP base URL 覆盖 env → /bili/ rewrite 走不通,必须 cert-MITM(dsh/claude 式:HTTPS_PROXY + NODE_EXTRA_CA_CERTS + MITM 白名单)。已验证 qoder 内置 undici 带 ProxyAgent、尊重 NODE_EXTRA_CA_CERTS,路线可行
    4. 默认模型 host:api2-v2.qoder.sh(国际/国内相同);区域 api1/2/3.qoder.sh(US/SG/JP);国内全走 gateway.qoder.com.cn
    5. 预算对齐:QODER_AUTOCOMPACT_WINDOW(cap 有效窗口,对应 REQ: codex 压缩预算协调 + 匿名代理模式拦截伪造(根本解决方案) #321 模式)
    6. qodercli 是 gemini-cli 的 fork;bundle 里有 ACP 协议 schema——未来可走 plugin mode,首版不做

    issue 里写了完整接入点清单 + 5 个开放问题(legacy transport wire 待真机验证、body 扩展字段透传、模型窗口服务端驱动、国内站点前缀检测、ACP 后续)。等 owner 拍板方案后再进实现。

  9. ranxianglei commented on Sep 10, 2026

    @ranxianglei
    Owner

    麻烦有空反馈下codebuddy 是否能用哈

  10. ranxianglei commented on Sep 10, 2026

    @ranxianglei
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 能用,已真机验证(真实 @tencent-ai/codebuddy-code@2.148.0 + PR #641 分支构建的 bili + 本地 mock OpenAI 上游,全链路跑通):

    ✅ 验证通过项

    1. 启动/路由:bili codebuddy 注入 CODEBUDDY_BASE_URL=http://127.0.0.1:<port>/bili/...,代理正确 unwrap 并转发到真实上游(forward POST → …/v2/chat/completions)
    2. 免登录认证:自定义端点路径不需要腾讯 SSO——CODEBUDDY_API_KEY=test-key → 请求带 Authorization: Bearer test-key,token 对代理不透明、原样转发。纯平台登录场景同理(token 走原通道,代理只碰模型流量)
    3. wire 兼容:真机发出的就是标准 OpenAI chat completions(stream SSE),body 约 138KB(system + memory 注入 + tools,含 qoder 类似的扩展字段 reasoning_effort/reasoning_summary/verbosity)——bili 的 OpenAI 管线无错误处理,响应流式回传正常,客户端正常输出、退出码 0
    4. 压缩管线全程生效:kernel 分配 mNNNNN refs、prefix-affinity session 建立、出站 wire history 里确认注入了 <acp> 标签(assistant/user 消息头部都有配对标签)——模型后续可以引用这些 ref 做 compress;多轮 -c 续接时历史完整重发(system+首条 user 字节级一致),nudge 计数正常
    5. 预算对齐:settings.json 设 "model":"gpt-4o" → 日志出现 bili: codebuddy budget aligned — CODEBUDDY_AUTO_COMPACT_WINDOW=128000 ✓

    ⚠️ 已知边界(不影响"能用")

    • 平台模型别名(default-model/fast-model…)不在 models.dev registry 里,窗口解析会落到默认 200k 兜底。用平台模型的话建议显式设 CODEBUDDY_AUTO_COMPACT_WINDOW(或 settings autoCompactWindow)拿到精确预算
    • 真实腾讯端点没测(需要你的登录态/凭证)——但 bili 侧机制全部验证过了,剩余风险只在腾讯 auth 细节上。你方便的话用真实账号跑一次 bili codebuddy 交互模式即可最终确认
    • models.json per-model url 仍不走代理(v1 限制,按 OP 决策 (a))
    • 小观察(非阻塞、非 codebuddy 特有):快速连续重启代理进程的场景下,session reattach 有 flush/hydrate 竞态窗口(本沙箱里我自己的 opencode bili 会话还并发写同一个 prefix-affinity.json)。正常使用 = 单个长驻代理 + 交互式 TUI,不受影响。按规则只报告不开单独 issue

    结论:PR #641 可以合并,codebuddy 接入按预期工作。

  11. ranxianglei commented on Sep 10, 2026

    @ranxianglei
    Owner

    Batched into a single PR together with the sibling client-support issues: PR #693 (codebuddy + qoder + trae merged once, conflicts resolved one time, docs unified across zh/EN README + CONFIGURATION tables).

    Superseded PR to close after merge: #641

  12. ranxianglei commented on Sep 10, 2026

    @ranxianglei
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 收到。已确认 #693(feat(#640,#653,#655): client support batch — codebuddy + qoder + trae)当前 open、base master。#641 保持 open 作为回退,等 #693 合并后我立即关闭 #693→#641 这个 superseded PR(收到合并事件即执行,无需再提醒)。

  13. ranxianglei commented on Sep 10, 2026

    @ranxianglei
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 更正上一条笔误:#693 合并后我要关闭的是 #641(被 supersede 的那个),不是 #693。即:#693 照常由你人工合并,合并事件一到我就 close #641。

  14. added a commit that references this issue on Sep 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions