Skip to content

能否新增对traecli的支持 #655

Closed
Closed
能否新增对traecli的支持#655
Labels
enhancementNew feature or request

Description

@ZouDongj
ZouDongj
opened on Sep 9, 2026

如题，公司只提供traecli的额度，能否新增对traecli的支持

Activity

  1. ranxianglei commented on Sep 9, 2026

    @ranxianglei
    ranxianglei
    on Sep 9, 2026
    Owner

    ework 接单

  2. ranxianglei commented on Sep 9, 2026

    @ranxianglei
    ranxianglei
    on Sep 9, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    先按仓库规范做了查重 + 审核（这是 feature request，按规矩先评估、给建议，不直接开工）。

    查重：全仓库（含已关闭）搜 trae / 新增支持 / support for，只有本条，无重复。

    结论先行：用你公司的 traecli 额度 + bili 压缩，今天就能跑，不用改 bili 一行代码——走 /bili/ 前缀 + 一个本地 trae 桥接。至于"原生 bili trae 启动器"，我判断不是合适的架构，理由如下。

    为什么"原生 launcher"不合适
    bili 现有的 bili codex/claude/pi/… 本质是"把能配置模型端点的长驻 agent 指向代理"（HTTPS_PROXY+CA，或 /bili/ base-URL 改写）。但 traecli 不是这种形态：它闭源、自带登录态/额度，模型走字节私有后端（…/api/ide/v2/llm_raw_chat，用你自己的 traecli 会话鉴权）。从社区所有集成方式看，traecli 不暴露一个可指向代理的标准 base URL——现有集成（dsh-trae-api、opencode-trae-cli-auth 等）全是"把已登录的 traecli 额度桥接成本地 OpenAI/Anthropic 兼容 API"：要么把 traecli 当子进程按请求驱动（spawn(traecli, [prompt, --config model.name=…, --session-id …])），要么复刻鉴权直连私有接口。所以"让 traecli 自己指向代理"这条路走不通，能落地的形态就是"桥接 + /bili/"。

    今天就能用（零改动）

    1. 起一个本地 trae 桥接，把登录态的 traecli 额度暴露成本地 OpenAI/Anthropic 端点，如 http://127.0.0.1:<port>/v1（dsh-trae-api 一类）。
    2. 把你写码用的 agent（claude / codex / opencode 任选）的模型 base URL 指到 http://127.0.0.1:8787/bili/http://127.0.0.1:<port>/v1。
    3. 流量：agent → bili 压缩 → 桥接 → 你的 traecli 额度。

    我的建议

    • 目标若是"用 traecli 额度写码时有长上下文压缩" → 上面这套现在就够用，不用等发版。
    • 若想要一条命令 bili trae 自动拉起"桥接 + 代理" → 是个合理的后续 feature，我可以做，但本质是"包一层桥接"而非原生集成。要做的话告诉我三件事：用哪个桥接（dsh-trae-api / opencode-trae-cli-auth / 其它）、实际用哪个 agent 写码、什么系统，我据此定方案再开分支。

    需要你确认一点：你是用 traecli 本身当写码 agent，还是拿它当别的 agent 的模型额度来源？这决定我下一步是给你精确的落地步骤，还是直接开 bili trae 的分支。

  3. ranxianglei commented on Sep 9, 2026

    @ranxianglei
    ranxianglei
    on Sep 9, 2026
    Owner

    否定你的判断，你看项目里面有类似 qoder 相关的 issue 都看看 是可行的

  4. ranxianglei commented on Sep 9, 2026

    @ranxianglei
    ranxianglei
    on Sep 9, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    你是对的，我收回上一轮"不可行"的判断。我用错了判据——我拿"有没有可配置的 base URL"来判可行性，但 qoder（#653/#654）恰好证明这是伪判据：qoder 模型端点 scheme 硬编码 https、同样没有 base URL 覆盖，却照样支持了。真正的判据是客户端是否尊重 HTTPS_PROXY + NODE_EXTRA_CA_CERTS——是的话代理就对白名单模型 host 做 TLS 终结、token 不透明原样转发，跟 base URL 无关。claude/dsh/qoder 全是这个路子（cert-MITM + proxy mode）。

    我按 qoder 的调研方法重新查了 traecli，结论：它和 qoder 结构同型，bili trae 可行。

    traecli = TraeX / TRAE CLI（同一运行时）

    • 本机登录的 Node CLI agent（traex login status → "Logged in using Trae"，SSO）；版本基线 traecli 0.201.1 (internal edition)；命令 traex/trae-cli/traecli 可互换。
    • 连自己的认证/推理/更新/遥测服务，模型端点无 base URL 覆盖（同 qoder）。
    • 候选模型 host：api.enterprise.trae.cn（企业版/PAT 场景）；wire 两条：专有 POST /api/ide/v2/llm_raw_chat（body 带 base_url: /trae-cli/api/v1/llm/proxy）+ OpenAI 兼容 POST /chat/completions；认证走 OAuth/SSO（/cloudide/api/v3/trae/oauth/ExchangeToken），token 对代理不透明。
    • 附带：它自己还暴露 ACP server（traex acp serve，identity traex-acp）——但那是"把额度当后端"的方向（宿主当 ACP client），跟 launcher 相反，首版不用。

    实现计划（对齐 #654，cert-MITM + proxy mode）

    • src/client-config.ts：resolveTraeHome（~/.trae）/ readTraeConfig（traecli.yaml/trae_cli.yaml，只读）。
    • src/launcher.ts：bili trae——buildTraeEnv()（HTTPS_PROXY + NODE_EXTRA_CA_CERTS + BILLION_CONTEXT_PROXY，继承代理变量全剥离，hermes/qoder 同款契约）；discoverRoutes trae 分支：默认模型 host 进 MITM 白名单，无 /bili/ rewrite；resolveClientCommand（traecli→trae-cli→traex）。
    • src/discover.ts：trae host 进 MITM 自动发现 + 配置 mtime 监听。
    • src/cli.ts HELP / README / AGENTS.md 同步；测试仿 qoder。

    真机要核实的 3 点（qoder 是从 npm bundle 核实的；traecli 无公开 npm bundle（internal edition）+ 要 ByteDance 登录，我这边核不了）：

    1. traecli 是否尊重 HTTPS_PROXY + NODE_EXTRA_CA_CERTS（承重项）；
    2. 确切模型 host + wire（专有 /api/ide/v2/llm_raw_chat 还是 OpenAI /chat/completions）——决定用哪个 adapter，是首版最大风险；
    3. 有没有预算对齐 env（类似 QODER_AUTOCOMPACT_WINDOW）。

    我的建议：先核实再动手，尤其 wire——它是承重项，猜错就白做。给我 traecli 的 bundle 或一台登录过的机器，我把上面 3 点核掉再实现。如果你现在不方便提供，我就先按 qoder 同构把脚手架 + v1 假设（默认 host api.enterprise.trae.cn、OpenAI adapter、proxy-env 注入）实现出来，wire 标成 v1 开放问题、真机验证后收敛——和 qoder 当年带 QODER_MODEL_TRANSPORT=http 上线一个套路。你定方向，我就开工。

  5. ranxianglei commented on Sep 9, 2026

    @ranxianglei
    ranxianglei
    on Sep 9, 2026
    Owner

    你下载一下研究下 反编译

  6. ranxianglei commented on Sep 9, 2026

    @ranxianglei
    ranxianglei
    on Sep 9, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    下载 + 反编译完成。traecli v0.120.52（linux/amd64，从官方 install.sh → lf-cdn.trae.com.cn 拉的）。是个 stripped Go 二进制（78MB），不是 Node——这点很关键，直接改变了 CA 注入方式。

    反编译结论（对齐我上一轮列的 3 点）：

    1. 代理 env：支持 ✅
    用了 Go 标准库 net/http.ProxyFromEnvironment → 尊重 HTTPS_PROXY/HTTP_PROXY/NO_PROXY（二进制里还内嵌了一份 help 文档专门列了这几个 env）。代理路由这条路通。

    2. CA 注入：走系统证书池，不是 NODE_EXTRA_CA_CERTS ⚠️（和 qoder 的唯一代码差异）
    Go 不读 NODE_EXTRA_CA_CERTS（Node 专属）。它用 x509.SystemCertPool → 尊重 SSL_CERT_FILE / SSL_CERT_DIR（能看到标准系统 CA 路径 /etc/ssl/certs/ca-certificates.crt 等）。所以 buildTraeEnv() 的 CA 注入要改成 SSL_CERT_FILE=<系统 CA + bili CA 的 bundle>；HTTPS_PROXY + BILLION_CONTEXT_PROXY + 剥离继承代理变量这部分和 qoder/hermes 同款。

    3. host + wire：

    • host 可用 env 覆盖：TRAE_CLI_API_HOST（+ chatmodel.resolveBaseURL）。默认企业 host console.enterprise.trae.cn，CDN lf-cdn.trae.com.cn。
    • wire 主路径：POST /api/ide/v2/llm_raw_chat（SSE），body 是 OpenAI 风格（messages/model/stream）+ Trae 扩展字段（tenant_id/session_id/metadata/base_url/api_host）；另有 /chat/completions（OpenAI）+ /api/v1/llm/proxy。
    • 关键证据：chatmodel.convertOpenAIResponseToMessage —— 响应按 OpenAI 格式转，bili 的 OpenAI adapter 能接。
    • 预算 env：没有（TRAE_CLI_* 只有 TRAE_CLI_API_HOST 一个）。CLI 内部自己管 context window（AutoCompactThreshold/effectiveContextWindow 是内部字段，服务端驱动），没有类似 QODER_AUTOCOMPACT_WINDOW 的 env 覆盖 → 预算对齐走 best-effort（bili configured limit / models.dev，trae 模型名大概率不在里面），和 qoder 开放问题 Use kernel renderTags:"text-only" + forbid tag echoing in prompt #3 一样。

    残留风险（1 个，静态核不到，需真机抓 1 个请求确认）：
    chatmodel.decryptAK / chatmodel.decryptMessage 存在。但证据指向 body 是明文：convertOpenAIResponseToMessage（响应是 OpenAI JSON）+ 社区 bridge（opencode-trae-cli-auth）能直接读 /api/ide/v2/llm_raw_chat 的 SSE 文本。所以 decryptMessage 大概率是解某个特定字段（签名 metadata / 一次性 token），不是整个对话 body。这是唯一我没法纯静态 100% 确认的点——真机抓一个 raw_chat 请求看 body 是否明文即可收敛。

    结论 + 计划： 可行，cert-MITM + proxy mode，照 qoder #654 抄。代码上和 qoder 的唯一实质差异是 CA 注入用 SSL_CERT_FILE（Go 系统池）而非 NODE_EXTRA_CA_CERTS（Node）。

    • src/client-config.ts：resolveTraeHome（~/.trae）/ readTraeConfig（traecli.yaml/trae_cli.yaml，只读）。
    • src/launcher.ts：bili trae——buildTraeEnv()（HTTPS_PROXY + SSL_CERT_FILE + BILLION_CONTEXT_PROXY，剥离继承代理变量）；discoverRoutes trae 分支：模型 host 进 MITM 白名单，无 /bili/ rewrite；resolveClientCommand（traecli→trae-cli→traex）。
    • src/discover.ts / src/cli.ts HELP / README / AGENTS.md 同步；测试仿 qoder。

    你确认方向我就开工。想把这个残留风险也消掉的话，真机抓一个 /api/ide/v2/llm_raw_chat 请求确认 body 明文即可，其余我已从二进制核实。

  7. ranxianglei commented on Sep 9, 2026

    @ranxianglei
    ranxianglei
    on Sep 9, 2026
    Owner

    确认开始

  8. ranxianglei
    added
    enhancementNew feature or request
    on Sep 9, 2026

  9. ranxianglei commented on Sep 9, 2026

    @ranxianglei
    ranxianglei
    on Sep 9, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    已完成，PR：#669

    实现：bili trae 启动器（cert-MITM + proxy 模式）

    按 qoder（#654）的模板实现。核心结论：Trae CLI 是闭源 Go 二进制、无 base-URL 覆盖，所以 /bili/ 路径重写够不到它，唯一可行的是 cert-MITM——Go 运行时认 HTTPS_PROXY，launcher 把它的模型流量引到 bili 代理并注入 CA。

    反编译（v0.120.52）确认：

    • 认 HTTPS_PROXY（Go net/http.ProxyFromEnvironment）
    • CA 走 Go 系统信任库 → SSL_CERT_FILE（用合并 CA bundle，因为它替换 Go 的信任库，和 codex 同形）
    • 模型 host 可用 TRAE_CLI_API_HOST 覆盖；默认 host console.enterprise.trae.cn / www.trae.cn
    • wire 是私有 POST /api/ide/v2/llm_raw_chat（SSE，OpenAI 形态 body）

    改动

    • src/client-config.ts：TraeConfig / resolveTraeHome（~/.trae）/ readTraeConfig（读 TRAE_CLI_API_HOST）/ TRAE_DEFAULT_MODEL_HOSTS
    • src/launcher.ts：bili trae（proxy 模式）——HTTPS_PROXY + SSL_CERT_FILE + BILLION_CONTEXT_PROXY，MITM 白名单模型 host，解析 traecli/trae-cli/trae 二进制。无 budget/transport env（Trae 自己管理上下文窗口）
    • src/server.ts：把 /api/ide/v2/llm_raw_chat 识别为 OpenAI。安全：body 不可解析时（非 JSON/加密）走既有 gate 透传——不压缩、不破坏
    • src/discover.ts / src/cli.ts / README / AGENTS / CONFIGURATION（en + zh-CN）
    • 测试：镜像 qoder 的 launcher + discover 用例

    验证

    • typecheck 干净；npm test 1242 通过（1 个失败是本沙箱预存的 codex/claude resolveClientCommand 用例，与本改动无关——它硬编码 PATH=/usr/bin 假设 codex 不存在，本沙箱恰好有；CI 里通过）；build 成功

    残留风险（需真机抓一次包确认）

    反编译看到 chatmodel.decryptMessage/decryptAK。证据（有 OpenAI 响应转换器 + 社区 bridge 直接读 SSE）表明对话 body 是明文，decryptMessage 大概率只覆盖签名元字段而非整个 body。如果 body 确实加密，代理会原样透传（不压缩、不破坏）——最坏是"没价值"，不是"坏了"。你这边有公司 traecli，跑一次 bili trae 就能确认。

    如果公司租户 host 不是默认那两个，设 TRAE_CLI_API_HOST 或 --mitm-domain 即可。

    中文一句话：新增了 bili trae 启动器（cert-MITM 路线，Go 二进制走 SSL_CERT_FILE 注入 CA、私有 /llm_raw_chat 接口识别为 OpenAI），typecheck/测试/构建全过，PR #669 已开，待合并；唯一残留风险是 wire 是否加密，需真机跑一次确认。

  10. ranxianglei commented on Sep 10, 2026

    @ranxianglei
    ranxianglei
    on Sep 10, 2026
    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: #669

  11. ranxianglei commented on Sep 10, 2026

    @ranxianglei
    ranxianglei
    on Sep 10, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    收到。已核查 batch 分支 2026-09-11_client-batch-641-654-669：trae 的完整改动都在 #693 里——launcher.ts（buildTraeEnv / TRAE_DEFAULT_MODEL_HOSTS / resolveTraeHome）、server.ts（/llm_raw_chat 识别）、client-config.ts（TraeConfig / readTraeConfig），所以 #669 确实被完全取代。

    按你说的"合并后再关"：#693 目前还是 open（未合并），所以我现在不动 #669，留它作安全网；等 #693 合并后我再把 #669 关掉（并留一句指向 #693）。在那之前两个 PR 都保持 open。

  12. ranxianglei
    closed this as completedin c115efbon Sep 10, 2026
  13. ranxianglei
    added a commit that references this issue on Sep 10, 2026

    Merge pull request #693 from ranxianglei/2026-09-11_client-batch-641-…

    194b2d7
  14. antclt
    added 2 commits that reference this issue on Sep 11, 2026

    feat: add Trae CLI client support (bili trae)

    c115efb

    merge pr669 (trae, ranxianglei#655): cert-MITM client support

    e60fa7d
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