Trae Agent 模型配置

先说结论:一个供应商块,一个模型块

Trae Agent 现行配置是 YAML:项目目录下的 trae_config.yaml,三个相关的块。model_providers 定义端点,每个条目带 api_key、provider、base_url,一个 OpenAI 兼容网关就是把 base_url 换掉的 openai 类型供应商。models 定义命名的模型配置,通过 model_provider 引用某个供应商。agents 把 trae_agent 绑定到 models 里的一个名字。 上游 README 就是照这个形状展示经多模型服务路由:一个 openai 供应商条目,base_url 指向服务的 /v1 根路径。经 kkaiapi,这就是 https://api.kkaiapi.com/v1,model 字段可以填目录里任意 ID 作为纯字符串,包括 Claude 和 Kimi 的 ID,因为供应商类型只决定请求格式,不决定厂商。

model_providers:
  kkaiapi:
    api_key: 你的kkaiapi密钥
    provider: openai
    base_url: https://api.kkaiapi.com/v1

models:
  trae_agent_model:
    model_provider: kkaiapi
    model: claude-sonnet-5
    max_tokens: 4096
    temperature: 0.5

Trae Agent 内部是怎么接线的

Trae Agent(GitHub 上的 bytedance,约 1.2 万星标)是字节跳动面向研究场景的命令行软件工程 Agent:给 trae-cli 一个任务,它会用透明的工具循环跑通,内置工具包括 bash、文件编辑、顺序思考,直到一个可配置的 max_steps 上限。它刻意做得模块化,这也是为什么配置要把供应商、模型、Agent 分开:同一个供应商能背后接多个模型配置,换 Agent 跑在什么模型上只是改一处名字引用。 实际有两个模型槽位重要。trae_agent_model 是主循环,做推理、工具调用、编辑的那个模型,max_steps 给到两百意味着一个任务可能是一长串计费调用。lakeview_model 驱动 Lakeview,Trae 的步骤摘要功能,把每一步 Agent 做了什么变成简短易读的总结。Lakeview 触发频繁,输出是可扫一眼的文字,是主循环留旗舰模型、这里放快速模型的教科书场景。 配置不只从 YAML 解析:CLI 每次运行接受 --provider 和 --model 参数,供应商专属的环境变量(OPENAI_API_KEY、OPENAI_BASE_URL 是文档列出的一部分)也会被读取。这些参数是不改文件就 A/B 第二个模型的方式。

完整配置:Agent、Lakeview、跑一次任务

完整配置把 Agent 绑到一个主模型、Lakeview 绑到一个快速模型,两者通过同一个供应商条目。留意这层间接引用:agents.trae_agent.model 指向 models 里的一个条目,每个 models 条目通过 model_provider 指向一个供应商。任何一处名字打错都会在这条链上失败,所以保持三处名字一致。 一个能解释大部分困惑教程的历史遗留问题:Trae Agent 的配置以前是 trae_config.json,仓库现在把这个格式记为历史遗留,YAML 是当前格式。展示 JSON 的教程说的是旧版布局,键名迁移了,概念延续下来了。如果你手头有旧的 JSON 配置,仓库的历史配置文档有对应关系说明。 一个 Key 这一点对这个工具来说尤其值得说清楚。Trae Agent 原生的供应商列表横跨中美两边的厂商,正常情况下意味着按厂商分别开账号、拿 Key,免翻墙统一在一个网关背后,claude-sonnet-5、gpt-5.5、deepseek-v4-pro、glm-5.2、kimi-k2.7-code 全都只是一个模型字符串的距离,一个 Key、一份余额,不用为哪家开海外账户发愁。

agents:
  trae_agent:
    enable_lakeview: true
    model: trae_agent_model
    max_steps: 200
    tools:
      - bash
      - str_replace_based_edit_tool
      - sequentialthinking
      - task_done

model_providers:
  kkaiapi:
    api_key: 你的kkaiapi密钥
    provider: openai
    base_url: https://api.kkaiapi.com/v1

models:
  trae_agent_model:
    model_provider: kkaiapi
    model: claude-sonnet-5
    max_tokens: 4096
    temperature: 0.5
  lakeview_model:
    model_provider: kkaiapi
    model: claude-haiku-4-5-20251001
    max_tokens: 4096
    temperature: 0.5

给 Agent 循环选模型

--provider 和 --model 参数让比较流程变得具体:同一个任务用不同参数各跑一次,读跑到完成的步数和控制台里按模型计价的用量,把赢家提升进 trae_config.yaml。

• 主循环是长程工具工作:读文件、编辑、跑 bash、判断任务是否完成。claude-sonnet-5 和 gpt-5.5 能撑住两百步的计划,这个槽位是最不该省钱的地方
• Lakeview 是高频、低风险的摘要工作,claude-haiku-4-5-20251001 或 deepseek-v4-flash 能让它的花费几乎可以忽略不计
• 带中文注释、提交记录、文档的代码库上,kimi-k2.7-code 和 glm-5.2 是主循环的有力候选,双语仓库是它们凭理解力(而不只是价格)赢过英文优先模型的地方
• deepseek-v4-pro 是批量跑的量级选择,同一个修复在很多仓库上扫一遍,或者在 CI 里跑 Agent,单任务成本会成倍累积
• max_steps 是成本控制阀。一个走神的模型会烧掉很多步,对比候选模型时比的是跑到完成的步数,不是每次请求的 token 数

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

Trae Agent 专属的翻车点

JSON 和 YAML 的混淆是头号问题。从旧教程抄来的 trae_config.json 最好也就被当成历史遗留读取,最差直接被忽略,症状是 CLI 表现得像你从来没配置过一样。新配置属于 trae_config.yaml,迁移旧文件用仓库的历史配置文档,别凭猜测拼键名。 三处名字链会悄无声息地断裂。agents.trae_agent.model 必须指向 models 里的一个条目,那个条目的 model_provider 必须指向 model_providers 里的一个条目。改了一处名字没改另外两处,跑起来会在启动阶段就报解析错误,而不是网络请求错误,这能直接把排查方向指向 YAML,而不是网络。 base_url 要带上 /v1,和上游示例里指向路由服务 /v1 根路径的写法一致。裸域名会在客户端拼接聊天补全路径之后产生 404。 Agent 正常但 Lakeview 失败,意味着 lakeview_model 引用了端点不提供的 ID,容易漏掉是因为你只测了主模型、忘了第二个槽位。环境变量在你以为是文件配置的地方悄悄背书某个供应商,尤其是 OPENAI_API_KEY,鉴权在不同 shell 之间表现不一致时值得检查一下。

验证接入与排查首次任务

开跑前先确认端点提供你要用的 ID:带上 Key 的 /v1/models 列表,是 YAML 里每个 model 字段的权威拼写来源,主槽位和 Lakeview 槽位都一样。 首次跑的失败很规律。任何请求之前就出现的配置解析错误,是三处名字链或者遗留的 JSON 文件。401 是供应商块里的 api_key,或者被环境变量覆盖了。每个请求都 404,是 base_url 漏了 /v1。模型不存在的报错会指名是哪个槽位错了,检查是 Agent 模型还是 Lakeview 模型。开始跑但中途卡住的任务,通常是模型在走神而不是端点故障,这正是 max_steps 和步骤日志存在的意义。 任务跑通之后,kkaiapi 控制台会显示每次请求的模型、token 数和花费。一个任务跑上百步会让一切成倍放大,用量日志是弄清楚每个候选模型上一个任务真实成本的地方。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer $KKAIAPI_KEY" | head -50

常见问题