1. 15 套环境变量各自为政的日子AI Agent 评测沙箱搭到一半最烦的不是评测引擎怎么写而是给 GPT-5、DeepSeek、Kimi 这 15 个大模型分别申请和维护 API Key每个供应商一个后台、一套环境变量、一种计费单位。后来我把沙箱的 Model Adapter 层切到 TaoToken先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿一把 Key把 Base URL 统一填成 https://taotoken.net/api画布 DAG 里改一个 modelId 就能从 GPT-5 切到 DeepSeek中途不用再碰 .env。这篇文章就是把当时的完整改法从头到尾过一遍。1.1 不是模型不行是每换一家都要重填一遍配置最初跑横评的时候providers 目录下面按供应商堆了一排文件走阿里系的要读 DASHSCOPE_API_KEY走字节系的要读 ARK_API_KEYDeepSeek、Kimi、Yi 又各有各的 SDK 和鉴权头。每轮评测要换一组模型流程是这样的先打开 .env 把对应的 Key 粘进去再 docker compose restart backend worker等容器起来之后再跑任务。如果某个 provider 的 SDK 版本升级了接口签名还得先改代码里对应的 fetch 调用才能继续。真正让人心累的是这个问题不是偶发的而是每次评测都会遇到。今天要对比 GPT-5 和 DeepSeek 在代码生成场景的分数明天要换 Kimi 和 Yi 跑同样的 Prompt后天可能又要补一个 Doubao。每换一次上面那套流程就完整走一遍。后来我数了一下光维护这些 Key 和 provider 配置的时间已经快赶上写评测引擎本身的时间了。1.2 手工对账更是雪上加霜跑完评测之后还有第二层折磨账单对不上。各家返回的 usage 字段命名不一样有的叫 prompt_tokens有的叫 input_tokens有的干脆不返回 usage只有响应文本。价格表也五花八门按每千 token 算的、按每百万 token 算的、按次计费的混在一起。原文里账单核算要按模型、场景、日期、时延分位数、业务正确率五个维度聚合这个设计是好的但数据源是各家 provider 各自上报的 usage 字段时聚合出来的数字总是让人心里发虚。当时我最大的感受是横评本身不难真正拖慢节奏的是把 15 个模型安全、稳定、可计费地接进来。这个问题不解决后面画布 DAG 编排做得再漂亮跑出来的结果也让人不敢信。2. 整体架构没变Model Adapter 变成统一通道整套评测沙箱的骨架还是沿用原来那一套前端用 Nuxt 3 加 Antd后端用 Nest 加 Redis Streams 和 BullMQ评测引擎负责拆任务画布负责编排 DAG账单模块负责聚合。这些都不需要动。唯一需要换掉的是最底层那 15 个 provider 实现。2.1 架构图里唯一要动的就是 Model Adapter 层前端 Nuxt 3 Antd ↓ REST / SSE 后端 Nest Redis Streams BullMQ ↓ 评测引擎 / DAG 路由 / 账单核算 ↓ Model Adapter Layer → TaoToken 统一通道 ↓ 基础模型GPT-5 / DeepSeek / Kimi / Yi / GLM / Llama ...原来的 Model Adapter 是 15 个 provider 各写各的请求逻辑现在改成 Model Adapter 层只面对一个端点。这个改动的好处是评测引擎、DAG 路由、账单核算完全不知道底层模型是谁它们只需要知道 modelId 和一次 Chat 请求。2.2 为什么说接入层值得替换而不是继续堆代码15 个 provider 的背后是 15 套 SDK 依赖而每家 SDK 的版本更新节奏完全不同。更麻烦的是有些供应商的接口在版本升级后还会改响应结构导致沙箱的评分器解析失败。把 Model Adapter 收敛成一个统一通道之后这些 SDK 层面的不确定性被挡在沙箱外面评测引擎只需要面对一个稳定的响应格式。这条通道的作用就是兼容各家模型接口、统一鉴权和计费口径让沙箱不用跟着每个模型供应商的版本节奏走。3. docker-compose 里 15 个 Key 变量缩成一个原文用的是 Docker 一键启动六个容器的方式这套方式我保留了只是把环境变量做了大幅删减。改动前的 backend 服务里塞满了各种OPENAI_API_KEY、ANTHROPIC_API_KEY、DASHSCOPE_API_KEY现在只留两个变量。3.1 docker-compose.yml 和 .env 的最终形态# docker-compose.yml version: 3.8 services: postgres: image: postgres:16 environment: POSTGRES_DB: sandbox POSTGRES_PASSWORD: ${PG_PASSWORD} volumes: - ./data/pg:/var/lib/postgresql/data redis: image: redis:7-alpine backend: build: ./backend env_file: - .env environment: DATABASE_URL: postgres://postgres:${PG_PASSWORD}postgres:5432/sandbox REDIS_URL: redis://redis:6379 TAOTOKEN_BASE_URL: https://taotoken.net/api TAOTOKEN_API_KEY: ${TAOTOKEN_API_KEY} depends_on: [postgres, redis] ports: [3001:3001] worker: build: ./backend command: node dist/worker.js depends_on: [redis] deploy: replicas: 4 frontend: build: ./frontend environment: NUXT_PUBLIC_API_BASE: /api ports: [3000:3000] nginx: image: nginx:alpine volumes: [./nginx.conf:/etc/nginx/nginx.conf:ro] ports: [80:80] depends_on: [backend, frontend]对应的.env.example缩减成三行PG_PASSWORDchange_me TAOTOKEN_API_KEYYOUR_API_KEY TAOTOKEN_BASE_URLhttps://taotoken.net/api其中YOUR_API_KEY需要替换成从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建的密钥。注意TAOTOKEN_BASE_URL这一项不要加/v1后缀也不要带上 UTM 参数它只用来接受 API 请求。3.2 启动和验证cp .env.example .env # 编辑 .env把 YOUR_API_KEY 换成实际 Key docker compose up -d docker compose logs -f backend看到后端日志出现Nest application successfully started之后再跑一个简单的接口探测确认后端能通过 TaoToken 通道访问模型。这一步只需要确认一件事backend 容器能拿到TAOTOKEN_API_KEY并且请求能正常到达 https://taotoken.net/api。4. Model Adapter15 套 provider 实现合并成一份原文第四节的核心是ModelProvider接口每种模型实现一个类暴露chat()方法返回文本、用量、成本、时延和模型名。现在不用为每家模型各写一个类了因为所有模型共用同一个接入端点区别只是在请求体里指定不同的model字段。4.1 从官网拿 Key并核对模型 ID改造之前先打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 API Key然后在模型广场里找到你要用的模型 ID。这一步非常关键沙箱 DAG 节点里填的 modelId必须和模型广场里的 ID 完全一致。不要自己去拼供应商的型号名也不要因为某篇文章里见过gpt-5就直接填进去以广场当前展示的值为准。4.2 统一 Provider 实现下面这份taotoken.ts可以直接放到providers目录里替换掉原来那一堆各自为政的 provider// providers/taotoken.ts import { ModelProvider, ChatRequest, ChatResponse } from ../shared/types; const TAOTOKEN_BASE_URL process.env.TAOTOKEN_BASE_URL ?? https://taotoken.net/api; export class TaoTokenProvider implements ModelProvider { name taotoken; // 价格不在代码里写死账单以官网控制台的统计为准 priceTable { input: 0, output: 0 }; async chat(req: ChatRequest { modelId: string }): PromiseChatResponse { const start Date.now(); const resp await fetch(${TAOTOKEN_BASE_URL}/chat/completions, { method: POST, headers: { Authorization: Bearer ${process.env.TAOTOKEN_API_KEY}, Content-Type: application/json, }, body: JSON.stringify({ model: req.modelId, messages: [ ...(req.system ? [{ role: system, content: req.system }] : []), { role: user, content: req.prompt }, ], temperature: req.temperature ?? 0.7, response_format: req.responseFormat json ? { type: json_object } : undefined, max_tokens: req.maxTokens ?? 2048, }), }); const data await resp.json(); if (!resp.ok) { throw new Error(TaoToken request failed: ${resp.status} ${JSON.stringify(data)}); } const usage { promptTokens: data.usage?.prompt_tokens ?? 0, completionTokens: data.usage?.completion_tokens ?? 0, }; return { text: data.choices[0].message.content, usage, costCny: 0, latencyMs: Date.now() - start, model: req.modelId, }; } }4.3 注册表从 15 个类缩成一个工厂原来的providerRegistry.get(modelId)要维护一张模型名到类实例的映射表现在所有模型都走同一个TaoTokenProvider映射逻辑就退化成下面这样// providers/index.ts import { TaoTokenProvider } from ./taotoken; export const providerRegistry { get(_modelId: string) { return new TaoTokenProvider(); }, };这样改完之后DAG 里填什么模型 ID 都不会触发「找不到 provider」的报错。真正决定调用哪个模型的是请求体里的model字段而注册表只负责提供一个稳定的执行入口。5. 画布 DAG 里把 gpt-5 换成 deepseek只动一个字段原文第六节用 reactflow 做了画布 DAGModel 节点的 data 里存modelId拖一个节点到画布上、连线到 Scorer就能跑一轮评测。改造后这个流程没有任何变化唯一不同是 Model 节点的取值来源变成了模型广场上那一份 ID 列表。5.1 切换前后的 DAG 配置对比这是一份简化后的 DAG JSON注意m1和m2两个 Model 节点{ nodes: [ { id: in, type: input, data: { prompt: 把这段评论按意图分类输出 json, examples: [] } }, { id: m1, type: model, data: { modelId: gpt-5 } }, { id: m2, type: model, data: { modelId: deepseek } }, { id: score, type: scorer, data: { type: json-schema } }, { id: agg, type: aggregator, data: { by: [model] } } ], edges: [ { from: in, to: m1 }, { from: in, to: m2 }, { from: m1, to: score }, { from: m2, to: score }, { from: score, to: agg } ] }要把评测目标从 GPT-5 换成 DeepSeek只需要把m1.data.modelId的值从gpt-5改成模型广场上对应的 DeepSeek ID保存画布后重新执行。评测引擎和 Scorer 节点完全不需要改。原来那种「换个模型就要改环境变量、换 provider、重启容器」的操作彻底变成了画布上的一次属性编辑。5.2 评测引擎的队列和 SSE 推送纹丝不动评测引擎的逻辑还是原文那样把任务拆成 N 个子任务每个子任务对应一个模型塞进 BullMQ 队列worker 并行消费每个模型跑完就往前端推一条 SSE 更新。因为底层 provider 收敛成同一个类worker 里providerRegistry.get(modelId)拿到的永远是一个TaoTokenProvidermodelId只是作为一个透明参数传给请求体。这也让重试逻辑变得统一以前不同 provider 的 SDK 报错信息格式不一样woker 里要根据错误类型分别处理现在所有调用失败都返回统一的错误结构重试策略和告警规则可以一套配置覆盖所有模型。6. 账单核算model_call_log 还是原来那张表原文第七节的model_call_log表结构我完整保留下来了。每次 chat 调用仍然会写入trace_id、model_id、scenario_id、input_tokens、output_tokens、latency_ms、cost_cny和created_at。字段一个没删只是model_id的来源更干净了它直接取自 DAG 节点里的配置值而成本数据通过统一通道的记录归集。6.1 表结构保持不变字段类型说明trace_iduuid关联评测任务model_idvarchar实际调用的模型 IDscenario_idvarchar场景 IDinput_tokensint提示 token 数output_tokensint输出 token 数latency_msint时延毫秒cost_cnynumeric单次成本元created_attimestamp创建时间由于所有调用都走同一个接入端点model_call_log里不会出现同一个模型的两种叫法。以前可能 GPT-5 在一家供应商那里叫gpt-5在另一家叫gpt-5-2025xxxx对账的时候还得人工对齐现在以模型广场的 ID 为准日志天然是一致的。6.2 月度趋势和 5 维聚合查询示例想看本月的分模型成本可以在 psql 里执行下面这条 SQL注意由你自己在数据库客户端里运行不要把这个操作交给 AI 工具直接连生产库执行SELECT model_id, COUNT(*) AS calls, SUM(cost_cny) AS total_cost, ROUND(AVG(latency_ms)) AS avg_latency_ms FROM model_call_log WHERE created_at date_trunc(month, now()) GROUP BY model_id ORDER BY total_cost DESC;原来需要每月手工去各供应商后台下载账单再汇总的活儿现在变成一条 SQL。原文里的按场景、按时延分位数、按业务正确率漂移的聚合视图也都能继续用因为底层的trace_id关联关系没有被破坏。7. 切换模型时最容易踩的 4 个坑模型接入方式变了踩坑的地方也跟着变了。下面这四个问题是我在改造过程中真实遇到过的按出现频率排序。7.1 把官网地址当 Base URL 填进代码最常犯的错是把 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 填进TAOTOKEN_BASE_URL或者在https://taotoken.net/api后面又手动补一个/v1。记住一个原则带 UTM 的地址是给人用的用来注册、建 Key、看模型广场和账单https://taotoken.net/api是给程序用的作为 Base URL 填进代码和配置后面不要拼接/v1。两个地址各干各的混用必出 404。7.2 模型 ID 靠猜不看模型广场有人喜欢凭印象填模型 ID比如把 DeepSeek 的 ID 填成deepseek-chat或者给 GPT-5 加个日期后缀。每次切换前先到模型广场复制当前可用的 ID。如果发现之前配置的 modelId 已经不在列表里了说明模型版本有更新重新拉取最新 ID 再跑评测。写死 ID 到代码里是最容易埋雷的做法让 DAG 节点的配置值从模型广场的列表里选择才不容易出错。7.3 Scorer 评委和被评测模型变成了同一家原文提到「千万别用 GPT-5 评 GPT-5 的结果」换成统一通道之后这个问题更容易被忽视。因为所有模型都从一个入口接入Scorer 节点如果选了gpt-5当裁判被测模型也选了gpt-5评测结果会显得虚高。改造后我养成的习惯是被测模型随便切但 Judge 节点固定用另一个不参与本次评测的模型并且每次跑完检查一下 DAG 里的 Scorer 配置有没有被误改。7.4 评测任务失败后静默丢弃统一通道之后模型的偶发限流、网络超时都会返回标准错误格式。如果 worker 里的重试逻辑没配好失败任务会被直接丢进死信队列前端卡片不闪账单表里也没有记录。建议在 woker 消费端对 5xx 错误做指数退避重试重试两次仍然失败的把 trace_id 和错误信息写进告警表。原文那段「失败要落库 告警」的建议在这里同样适用而且因为错误格式统一了实现起来比之前更简单。8. 上线 30 天之后这套接入方式给我省下的时间改造完成后沙箱又跑了 30 天的真实评测。这 30 天里创建了 8000 多个评测任务累计调用次数超过 12 万次。放在以前这 12 万次调用对应的是 15 个供应商后台的账单记录月底对账至少得花半天现在只用在模型广场对应的控制台里看一份统计再回数据库里跑一条 SQL 交叉验证。8.1 模型切换从「半天」变成「几分钟」真实体感是客户说想看看 DeepSeek 在某个场景下的表现我在画布 DAG 里把相应的 Model 节点从gpt-5改成 DeepSeek 的 ID保存后重新运行几分钟后新模型的评分卡就出现在前端页面上。整个过程中没有打开过 .env 文件没有重启过任何容器更没有因为忘换 Key 导致的 401 报错。评测引擎、评分逻辑、账单统计这些模块对模型切换这件事完全无感。8.2 一个需要接受的取舍统一接入通道在带来便利的同时确实会牺牲少数供应商的独占特性。比如某些模型的 tool call 行为比较特殊或者响应里带有额外的审核字段这些信息在统一接口里不一定完整透出。如果你的评测场景需要深入验证某个模型的原生 tool call 能力建议单独保留一个原生 provider 做对照实验如果只是跑常规的 Prompt 效果对比和成本统计统一通道完全够用。回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台翻一下你最近一次评测的调用记录对比 DAG 里跑过的模型节点你会发现自己已经不用再去五六个供应商后台来回切账号对账了。同一把 Key从 GPT-5 切到 DeepSeek 只是画布上的一次属性修改账单自动归集到同一个地方剩下的精力可以全部用来打磨评分标准和评测场景本身。
