1. 把 Playwright MCP 换成 CLI 之后测试 Agent 依然是账单里最厚的一段上一篇我们复盘了 harness 工作流的成本治理1 个 TL 加 6 个角色子 Agent从需求分析一路跑到视觉还原校验。那轮改造做了几件立竿见影的事Playwright MCP 换成 Playwright CLI、TAPD 与 Figma 的原始 payload 交给短生命周期子 Agent 摘取、SKILL.md 的条件内容外移到资源层。整体账确实降下来了但按 Wave 粒度拆开看自动化测试环节的占比不降反升。原因不难理解测试是全流程里唯一会因为失败而重跑的环节。修复循环的轮次不确定每一轮都要把 spec 文件、上一条断言报错、上一轮改动重新打包进 context。上下文治理解决的是每一轮多贵而测试角色的病灶在轮数多两个问题的解法不一样。所以这篇只讲一个视角模型分层路由。在动手改路由之前先去 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contenttest-agent-glm5v 取一个 Key后续所有客户端配置里的 Base URL 统一写 https://taotoken.net/api这两件事是整个分层方案的前置条件。需要先说明本文的边界下面所有 token 与成本数字都来自我们内部工作流的实测口径比例关系可参考绝对值请以你自己场景的度量结果为准。度量工具用什么不重要重要的是能按角色、按轮次把账拆开。2. 先量再改测试角色的成本花在六个口径上只有一个是模型单价在没有按 Wave 拆分之前我们只知道钱烧得快。用 AgentLens 按 SessionId 聚合之后一次中等需求的全流程消耗可以归到六类来源来源典型占比区间是否随轮次线性增长治理手段子 Agent 系统提示词中否每轮固定稳定前缀、工具裁剪Skill 正文常驻中否渐进式披露MCP / 工具 Schema中否工具白名单工具返回原始内容高是CLI 压缩、子 Agent 化历史消息滚动堆积最高是状态外化、拆分角色模型输出单价乘数项是模型分层路由前五类是每一轮多重第六类是每一轮多贵。最后一行才是本文的主角而且它和轮次是相乘关系单任务成本 ≈ Σ(第 i 轮 context 总长度 × 该轮模型单价) Σ(输出 token × 输出单价)测试角色的特征非常清晰context 长度中等单价原本不低轮数最多。任何作用在单价上的降幅都会被修复轮次放大一次。反过来给 TL 这种调用次数个位数、单次决定全局路径的角色换便宜模型省下的绝对值很小却可能让整条路径走歪产生更多返工轮次。这就是为什么分层必须按角色来不能一刀切。3. 分层的判断标准按「单位轮次推理深度」不是按角色重要性很多团队做模型分层时习惯按这个角色重不重要排优先级结果往往是核心角色用最强模型、边缘角色用最弱模型省得不多还容易出错。我们最后改成三条判断线效果稳定得多。第一条线单次调用是否决定全局路径。tech-leader 判规模、分 Wave、决定是否进入修复循环一次判断错后面所有轮次都在错误路径上烧钱。这类角色不能省。第二条线单次调用是否需要跨文件长链条推理。backend-dev / frontend-dev 要理解代码图谱给出的依赖关系、要保证改动不破坏调用方属于典型的深推理任务保持原来的高推理档。第三条线单次调用是否是规则映射 结构化输出。这是本文的重点。自动化测试角色的工作内容拆开看无非是把自然语言用例翻译成 Playwright spec一次性、读断言失败信息定位最小改动点、比对视觉截图差异。前两件是规则映射第三件是多模态比对都不需要长链条自由推理但每一轮都要做一次。结论就是把推理深度要求低、轮次密度高的角色换成成本更低、支持多模态的 GLM-5v。4. 测试 Agent 的模型映射表写进 Agent 定义的 frontmatter落地方式不复杂。每个角色一个独立的 Agent 定义文件在 frontmatter 里同时声明三件事——工具白名单、MCP 白名单、模型档位。--- name: test-runner description: 解析 spec 用例、执行 Playwright CLI、归因断言失败并输出最小修复建议 model: glm-5v tools: - read_file - write_file - run_cli mcp: [] --- 你负责自动化测试执行。收到 spec 列表后调用 Playwright CLI 批量执行 只在失败时输出失败用例、失败断言原文、最小改动建议不要复述完整日志。对应到整个工作流的模型映射表大致是这样子 Agent任务特征模型档位分层理由tech-leader规模预判、Wave 派发高推理档单次调用决定全局路径backend-dev跨文件改动、依赖推理代码强档深推理轮次可控frontend-dev组件改动、状态流转代码强档同上test-runnerspec 生成、失败归因GLM-5v规则映射为主轮次最多visual-reviewer截图差异比对GLM-5v多模态比对规则性强code-reviewer规则检查、清单核对中档规则性中等这里有两个容易忽略的边界条件我们踩过边界一不要在同一角色的会话中途切模型。模型切换意味着服务端的 prompt cache 命名空间变了之前累积的稳定前缀命中不了缓存那一轮 input token 会按全价重算。分层路由是在会话开始前决定档位不是运行中动态降级。边界二不要把修复循环里的归因也交给最低档。我们最初试过连 spec 生成都压到最低档结果生成的 spec 选择器不稳定失败率上升返工轮次把省下的钱吃回去了。最后的分界线是语义理解把用例翻译成代码留在中高档规则执行与比对跑 CLI、读截图、归因报错走 GLM-5v。5. 从 TaoToken 拿 Key到三套客户端的可复制配置分层路由要生效前提是所有子 Agent 都能拿到同一个可用的模型入口。我们在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contenttest-agent-key 上给每个工作流单独建 Key方便按角色统计用量。取 Key 之后客户端配置只认两件事Base URL 和 Key。5.1 Claude Code写进 settings.jsonClaude Code 走ANTHROPIC_*环境变量族配置写在~/.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: glm-5v, ANTHROPIC_SMALL_FAST_MODEL: glm-5v } }注意ANTHROPIC_BASE_URL结尾不要多加斜杠路径拼接出错时报错信息往往指向鉴权失败很容易误判成 Key 有问题。5.2 Codex写进 config.tomlCodex 用的是完全不同的配置体系不要把ANTHROPIC_*那一套搬过来。配置文件是~/.codex/config.tomlmodel glm-5v model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat然后在本机环境变量里放TAOTOKEN_API_KEYYOUR_API_KEY不要直接把 Key 写进 toml 再提交到仓库。5.3 CC Switch三件套填法如果你用 CC Switch 在多套配置之间切换本质上是填三件套Provider 名称TaoToken-GLM5v Base URLhttps://taotoken.net/api API KeyYOUR_API_KEY命名建议把角色 模型档位带进去比如TaoToken-GLM5v和TaoToken-DeepReason切换时不容易选错。5.4 自建 harness子 Agent 直接调 API我们的测试子 Agent 不跑在 IDE 里而是自建 harness 直接发请求。这种情况只需要把 base_url 指过去import os from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) resp client.chat.completions.create( modelglm-5v, messages[ {role: system, content: 你是测试归因助手只输出最小改动建议。}, {role: user, content: 断言失败expected [data-testidsubmit] visible, got null}, ], ) print(resp.choices[0].message.content)想先用 curl 验证连通性可以这样curl -s https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:glm-5v,messages:[{role:user,content:ping}]}连通性验证通过再往 harness 里接比在复杂工作流里排查网络问题高效得多。6. 修复轮次成本对照把轮次变量单独拉出来算分层路由的收益之所以在测试角色上最明显是因为它和轮次是乘数关系。我们用同一套 spec、同一份代码基线在相同失败注入条件下记录了修复循环的轮次消耗。修复轮次单一高档模型相对成本测试角色走 GLM-5v相对成本差额1 轮一次通过1.001.00约等于 03 轮3.001.72-43%5 轮5.002.80-44%8 轮8.004.42-45%10 轮10.005.50-45%两个必须说明的点第一一次通过时分层几乎不产生收益。第一轮里两种档位都要跑 spec 生成和首次执行语义理解部分的分层边界决定了这部分不能省。分层的收益曲线是随轮次递增的如果你的测试用例大多一次通过优先做上下文治理比换模型划算。第二上表的相对成本已经扣除了返工。我们早期版本把 spec 生成也压到最低档表面单价下来了但选择器不稳定导致平均轮次从 3.2 涨到 5.6反推总成本反而更高。所以这张表的前提是语义理解留中高档、规则执行走 GLM-5v这条分界线。把这张表和上下文治理的收益叠起来看上下文治理让每一轮变短分层路由让每一轮变便宜两者作用在同一批轮次上测试环节的整体降幅明显高于其它角色。这也解释了为什么我们把它放在第二轮优化的第一优先级。7. 分层路由不能单点上线与其它优化的四个咬合点模型分层不是孤立动作它和之前几项优化的耦合比想象中紧。咬合点一稳定前缀决定分层能不能吃到缓存。我们在子 Agent 的派发提示词上做过前缀重排——把稳定指令放前面、动态内容后置。分层的档位一旦确定这个前缀就固定下来了缓存命中率才稳定。如果中途切模型前缀缓存白建。咬合点二CLI 替代 MCP 是分层发挥的前提。Playwright MCP 每个操作都要一次模型推理10 步操作就是 10 轮。换成 Playwright CLI 之后LLM 只负责把用例翻译成 spec和读汇总结果一次调用 一次读结果。轮次先降下来分层的收益才有基数。咬合点三工具白名单才让按角色指定模型成为可能。用 IDE 内置的自动派生子 Agent 机制时你没法给单个子 Agent 指定模型和 MCP 白名单。改成每个角色一个自定义 Agent 定义文件之后model字段和tools字段才有地方写。backend-dev 不需要任何 MCP 工具test-runner 只需要读文件、写文件、跑 CLI这些约束同时降低了 Schema 常驻成本。咬合点四并行化和分层不冲突。没有数据依赖的调用合并到同一轮发起省的是历史被重复打包的那几轮。并行发起时如果两个子 Agent 用了不同档位注意它们的输出长度差异汇总轮要把两份结果一起读进来——这部分成本是固定的不随档位变化。8. 落地检查清单与三个高频坑改完之后我们沉淀了一份 checklist直接照着走[ ] 按角色拆出独立的 Agent 定义文件model字段可写[ ] 确认tools白名单与mcp白名单非空且最小化[ ] 明确分层分界线语义理解留中高档规则执行走 GLM-5v[ ] 同一角色会话内不切模型档位在会话开始前确定[ ] 按角色单独建 Key便于分角色统计用量[ ] 记录每个角色的平均轮次用于反推分层收益[ ] 先跑一次全通过用例确认分层不引入新的失败三个我们实际踩过的坑坑一把ANTHROPIC_*配置套到 Codex 上。两套客户端的配置体系完全独立Claude Code 认settings.json里的 env 段Codex 认config.toml的 provider 段。混用不会报明确的错只会表现为请求发不出去或者走到默认端点。坑二Base URL 多写了斜杠。https://taotoken.net/api/和https://taotoken.net/api在部分客户端里拼出来的路径不一致报错却指向鉴权非常容易误判成 Key 失效。统一不加尾斜杠。坑三只看单价不看轮次。分层最容易犯的错是把所有角色都往下压一档短期账单好看中长期返工轮次上升。评估任何档位调整都要同时记录平均修复轮次这个指标只降单价不降总成本是负优化。9. 从哪里开始动手如果你的工作流里也有一个规则性强、轮次最多的测试角色建议的推进顺序是先按角色把账拆开确认测试环节的轮次密度确实最高再给测试与视觉角色单独建 Agent 定义文件、指定 GLM-5v最后用同一批失败注入用例跑对照记录平均轮次和相对成本两条曲线。工具入口都收在同一个地方按需选一条路径即可想先在网页端把 GLM-5v 的实际效果跑一遍可以走模型对话打算把整个 harness 的子 Agent 都接进来看Coding Plan 的额度结构更直观准备给每个角色单独建 Key直接进API Keys 控制台如果你用 Claude Code 作为测试子 Agent 的运行环境Claude Code 文档里有settings.json的完整字段说明。分层路由本身不复杂难的是先分清哪一档该省、哪一档不能省。把测试角色从单一档位里拆出来是这事儿里性价比最高的一步。