1. 轨迹评测第一原则结果对不等于 Skill 被调用你给 Claude Code 配好ANTHROPIC_BASE_URL也把 Skill 塞进了上下文最终答案对了但翻tool_calls轨迹才发现Skill 要求的关键校验步骤根本没被调用——这是轨迹评测里最贵的假阳性。要复现这条链路可以先用 TaoToken 发一个 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentskill_trace_intro Base URL 填 https://taotoken.net/apiKey 占位YOUR_API_KEY。很多团队做 Skill 评测时只看最终输出是否通过。这个习惯在普通 Prompt 调优里勉强够用放到 Skill 轨迹评测里会直接失真。因为 Skill 的价值不在于“答案看起来对”而在于 Agent 在运行时是否真的走了 Skill 定义的关键步骤先查什么、再调哪个工具、参数怎么填、后置条件有没有校验、遇到异常是否回滚。最终答案正确可能只是模型自身能力强也可能只是这次数据格式碰巧没问题。轨迹评测要回答四个问题如果去掉 Skill模型本来能不能做对当前评测 case 是否太简单导致有 Skill 和无 Skill 看不出差异运行时tool_calls里是否出现了 Skill 定义的关键工具和顺序最终结果对了但关键校验、必要参数、后置条件是否被绕过这四个问题对应四类产出tool call轨迹、关键步骤检查表、路径判定结果、路径不对回滚记录。没有这四类证据Skill 评测就只是在看结果不是在验证 Skill 是否被真实使用。更麻烦的是错误的正反馈会继续污染后续链路。一次“结果对、路径错”的执行如果被当成好经验写入记忆或 Skill 更新池下一轮 Agent 会更自信地走捷径。最终不是没有进化而是朝错误方向进化。所以轨迹评测的第一原则很朴素先证明 Skill 真的被调用再谈它有没有效果。TaoToken 在这里的角色很明确只发 Key。它不替你做轨迹采集也不替你判断 Skill 是否被 follow。你拿到 Key 和 Base URL 之后仍然要在自己的 Agent Harness 里记录 tool call、工具参数、中间结果、后置校验和最终输出。路径追踪本身会烧 Token因为你要跑对照实验、要抽样评估、要在失败 case 上做深度归因。接入之前先接受这个成本再谈怎么把成本压下来。2. TaoToken 只发 KeyClaude Code、Codex、CC Switch 三套接入别混用先把入口统一到 TaoToken 官网获取 Key链接带 UTMhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentskill_trace_config 。Base URL 固定为https://taotoken.net/apiAPI Key 用YOUR_API_KEY占位。接完之后不同客户端要按各自协议配置尤其不要把 Claude Code 的ANTHROPIC_*套到 Codex 上。Claude Code用 settings.json 或环境变量Claude Code 走 Anthropic 兼容配置核心是ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY和模型 ID。可以在settings.json里写{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }如果你用 shell 临时验证也可以export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYYOUR_API_KEY export ANTHROPIC_MODELYOUR_MODEL_ID配置完成后先在本地跑一条最小 tool call 测试比如让 Agent 调用一个天气查询工具然后检查轨迹里是否出现tool_calls。这一步不是验证模型聪不聪明而是验证 Key、Base URL、模型映射是否通。Codex用 config.toml不要套 ANTHROPIC_*Codex 的配置体系不同常见做法是config.toml里定义 model provider。示例model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses然后在本地设置export TAOTOKEN_API_KEYYOUR_API_KEY注意两点第一Codex 不读取ANTHROPIC_*把 Claude Code 的环境变量复制过去通常无效第二wire_api要根据服务端兼容层选择若当前接口只兼容 chat completions就改成chat不要硬套responses。排障时优先看 401、404、模型不存在三种错误401 查 Key404 查 Base URL 是否多写了/v1或路径模型不存在查模型 ID 是否来自实际可用列表。CC Switch三件套必须一致如果你用 CC Switch 这类切换工具切换供应商时检查三件套provider: TaoToken base_url: https://taotoken.net/api api_key: YOUR_API_KEY model: YOUR_MODEL_ID三件套里最容易被忽略的是模型映射。同一个会话里如果前半段用 A 模型后半段切到 B 模型轨迹中的工具调用风格会变化Skill 命中率也会漂移。做轨迹评测时建议在 trace 里记录provider、base_url、model、skill_version四个字段。否则你看到一条路径失败都不知道是 Skill 写错了还是切换配置导致的。TaoToken 只发 Key所以客户端配置本身不产生轨迹数据。你必须在 Agent 侧埋点每次 run 生成一个trace_id把消息、工具调用、参数、返回、最终答案、Token 用量写入本地 JSONL。路径追踪烧 Token但埋点本身不烧 Token把证据先留下来后面才能做低成本筛选。3. Skill 轨迹检查表从 tool call 序列识别“真调用 / 假调用 / 绕路”Skill 评测不能靠感觉。要把 Skill 里“必须做什么”翻译成机器可检查的协议。一个最小检查表可以长这样{ skill: refund_policy_check, must_call: [ {tool: get_order, position: 1}, {tool: check_refund_policy, position: 2}, {tool: format_validation, position: 3} ], required_args: { get_order: [order_id], check_refund_policy: [order_id] }, post_conditions: [ policy_version ! null, refund_decision in [yes, no] ], forbidden_shortcuts: [ 跳过 format_validation, 直接使用默认 refund_decision ] }对应轨迹数据至少包含{ trace_id: trace-20260611-001, skill: refund_policy_check, skill_version: v7, provider: taotoken, model: YOUR_MODEL_ID, tool_calls: [ {name: get_order, args: {order_id: A1001}}, {name: check_refund_policy, args: {order_id: A1001}}, {name: format_validation, args: {schema: refund_result}} ], final_answer: 可以退款, token_usage: {input: 1200, output: 180} }有了这两份数据路径判定可以分三类真调用关键步骤按顺序出现参数满足 schema后置条件满足。假调用最终答案通过但关键tool_calls缺失说明 Skill 只是躺在上下文里没被使用。绕路出现了相关工具但跳过了关键校验或者用替代 API 碰巧得到正确结果。绕路最危险因为这次结果对下次数据一变就翻车。本地可以用一个很短的 Python 脚本先做规则校验不调用模型成本接近零import json from pathlib import Path trace json.loads(Path(trace.jsonl).read_text(encodingutf-8).splitlines()[0]) expected [get_order, check_refund_policy, format_validation] observed [c[name] for c in trace.get(tool_calls, [])] hit 0 for exp in expected: if exp in observed[hit:]: hit observed.index(exp, hit) 1 else: print(路径偏离缺少, exp) break else: print(关键步骤按顺序命中) if observed and observed ! observed[:len(expected)]: print(存在绕路或额外调用进入人工/LLM复核)规则引擎负责把明显假调用和明显绕路筛出来。只有模糊 case 才交给 LLM Judge。LLM Judge 要做三件事分离生成模型和评估模型评估 temperature 设为 0输出结构化 JSON。不要让同一个模型实例既生成答案又评判自己是否 follow Skill自洽偏差会让你误判。一个可操作的检查表应该包含五列检查项问题证据来源判定失败动作对照实验无 Skill 时能否做对两组 trace都能对则 Skill 贡献存疑标记低价值 Skill难度校准case 是否太简单失败率分布全对或全错都无效调整 case 难度轨迹追踪关键工具是否出现tool_calls缺失即假调用回滚/重写路径验证顺序/参数/后置条件检查表绕路即高危记入回滚记录预算公平是否同 Token 预算token_usage多花数倍不算进化重跑对照这张检查表的目的不是增加流程而是让“Skill 真的有用”变成一个可复现的判定。4. 路径追踪烧 Token用分层评测把预算压回可控路径追踪为什么烧 Token因为一次完整验证往往要跑多组有 Skill 组、无 Skill 组、候选 Skill 组再加 LLM Judge 检查路径。如果每个候选都跑全量 case再对每条轨迹做细粒度语义评估成本会指数上升。更现实的是很多团队不是不知道要评路径而是评一次太贵最后只能退回只看最终结果。分层评测是唯一可行解。把轨迹校验拆成三层层级触发条件模型调用用途L0 规则校验所有 trace零检查工具名、顺序、参数 schema、后置条件L1 抽样语义L0 可疑或失败 case少量LLM Judge 判断绕路、幻觉、低效L2 全量深挖发版前/重大变更较多完整对照实验和路径归因日常迭代只跑 L0失败 case 自动进入 L1发版前才跑 L2。线上每天抽 5% 到 10% 的 trace 进种子池失败 case 100% 进池。这样路径追踪仍然烧 Token但烧在真正需要语义判断的地方而不是每条轨迹都过一遍大模型。还要做预算公平性检查。很多所谓“进化”只是多采样、多重试、多花 Token 换来的。正确的对照是有 Skill 和无 Skill 在相同 Token 预算下比较。如果新方案多花 3 倍 Token 才比旧方案高 10%这不是 Skill 进化是预算堆出来的分数。轨迹评测里必须同时看final_result和token_usage。缓存也能省一大截。相同 prompt、相同工具返回、相同 Skill 版本可以缓存评估结果。评估器 temperature 设为 0保证可复现。生成模型和评估模型分离避免“自己评自己”。这些原则不复杂但能决定轨迹评测是可持续工程还是一次性烧钱实验。另外轨迹日志落本地不要让 Agent 直连生产库。你可以把脱敏后的tool_calls、参数、结果写入本地 JSONL再用脚本离线分析。SQL 和命令由读者本地执行Agent 只负责产生轨迹不负责查生产数据。5. 路径不对的回滚记录把假阳性变成下一轮评测种子路径不对时不要只回滚版本要留下回滚记录。因为“结果对、路径错”是极好的评测种子它告诉你 Skill 在什么场景下会被绕过模型倾向于走哪条捷径哪个后置条件最容易被忽略。一个回滚记录可以写成 JSONL{trace_id:trace-20260611-001,skill:refund_policy_check,skill_version:v7,expected_path:[get_order,check_refund_policy,format_validation],observed_path:[get_order,format_validation],final_result:pass,path_verdict:shortcut,action:rollback,rollback_to:v6,seed_case:seed-20260611-001,evidence:trace.jsonl line 1}关键字段包括trace_id能回放到原始轨迹。skill_version定位是哪个版本引入的。expected_path和observed_path路径差异一目了然。path_verdict真调用、假调用、绕路、低效。action和rollback_to自动回滚还是人工介入回到哪个版本。seed_case这条失败进入下一轮评测集。evidence证据位置便于复核。自动回滚条件要写死关键步骤缺失、后置条件不满足、回归 case 失败、预算异常暴涨。满足任一条件先回滚到上一个稳定版本再人工确认。灰度阶段建议 10% 流量跑 7 天监控成功率、Token 消耗、延迟、路径命中率。路径命中率是新指标——最终答案通过率可能没掉但路径命中率掉了说明 Agent 正在绕路。版本化也要跟上。Skill、Prompt、记忆写入都要有版本号、变更日志、来源标记、关联评测结果。出问题时排查链路才清晰线上异常 → 定位版本 → 查看 diff → 查看关联 trace → 决定回滚到哪个版本。没有版本化回滚记录只是一堆散落日志。回滚记录还会进入记忆系统作为“反例/陷阱”沉淀。下次遇到类似任务时Agent 可以召回这条反例不再走捷径。这样轨迹评测就不只是发现错误而是把错误变成下一轮评测和记忆的燃料。6. 从 50 条 trace 到飞轮闭环Skill 评测落地路线与 CTA如果你现在就要落地不要一上来搭全自动平台。先跑通最小轨迹评测闭环Phase 1准备 50 条带工具调用的评测 case手动跑有 Skill / 无 Skill 两组记录tool_callsJSONL填写关键步骤检查表。目标不是自动化而是验证你能不能稳定抓到“结果对但路径错”。Phase 2把 L0 规则校验接进 CI。每次 Skill 变更先跑规则校验和核心回归 case失败自动生成回滚记录。目标是不让假调用和绕路进入主分支。Phase 3接灰度与回流。线上抽 5% 到 10% 轨迹进种子池失败 case 自动回流成下一轮评测样本。再加异步巡检每周看一次跨会话模式哪类工具总被跳过哪类后置校验总被绕过哪类 Skill 经常被模型忽略。这三步跑通后你才真正拥有 Skill 评测飞轮评测发现路径问题记忆沉淀反例落地生成修复控制门控回滚下一轮评测再验证。它不需要一开始就全自动但每一步都要留下可复现证据。最后给一个高转化路径。先到 TaoToken 官网获取 Key官网链接https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentskill_trace_cta 。拿到 Key 后按顺序做四件事模型对话验证 Key 和 Base URL 是否通https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentskill_trace_chat查看 Coding Plan规划轨迹评测和对照实验的 Token 预算https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentskill_trace_plan创建和管理 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentskill_trace_keys对照 Claude Code 文档完成 settings.json / ANTHROPIC_* 配置https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentskill_trace_claude_codeBase URL 始终是https://taotoken.net/apiKey 用YOUR_API_KEY占位。TaoToken 只发 Key路径追踪烧 Token但只要你把轨迹、检查表、回滚记录三件套跑起来Skill 评测就不再是看最终答案猜效果而是有证据、能回滚、能进化的工程闭环。先跑通第一圈再谈飞轮转得快不快。