1. 从 NVIDIA 的 300 Skills 实测说起Skill 到底值不值得接Agent Skill 这个词最近出现频率很高。简单说它就是把某个领域的操作说明、示例代码、工具用法整理成一份结构化文档Agent 遇到相关任务时加载对应 Skill就能拿到更具体的任务上下文。听起来很美好但问题也随之而来Skill 写得越细可能帮 Agent 更快找到正确路径也可能增加上下文和 Token 消耗可能提高正确率也可能带来错误引导或多余操作。NVIDIA 最近开源了 SkillEvaluator专门用来评估 Agent Skill 的实际效果同时公布了首批 300 多个 NVIDIA Verified Skills 的测试结果。这次测试覆盖 30 多个 NVIDIA 产品分别在 Claude Code 和 OpenAI Codex 两套 Agent 运行框架上执行。核心方法就是 A/B 测试同一个任务一组启用 Skill一组不启用其他条件完全一致两组得分差值就是 Skill Lift。结果很直观。正确性从 46 分提升到 87 分Skill Lift 41可发现性从 42 到 8240有效性从 39 到 7839效率从 43 到 7835安全性从 97 到 981。所有维度平均 Skill Lift 为 31 分排除基线已经很高的安全性后平均 39 分。但数据好看不代表每个 Skill 都值得接。NVIDIA 自己也提醒85% 的 Skill 每个任务只跑了 1 次15% 跑了 2 次Agent 任务评测本身有随机性单次结果波动可能很大。而且不同产品之间的 Skill Lift 差异从 2 到 46比 Claude Code 和 OpenAI Codex 两套框架之间约 5 分的差距明显得多。这说明 Skill 的效果高度依赖具体任务、领域和评测数据集设计。更值得关注的是 Token 成本。NVIDIA 给了两个单次运行案例jetson-optimize-memory Skill 加入后Token 消耗从 617,306 降到 142,540减少 76.9%执行时间从 474.9 秒降到 220 秒但 cuopt-install 的结果相反Token 从 25,227 增加到 55,582增加 120.3%执行时间从 34 秒增加到 41.1 秒。所以 Skill 不一定更省 Token有些能帮 Agent 少走弯路有些反而增加步骤和上下文。那怎么判断一个 Skill 值不值得接我的思路是先用 SkillEvaluator 的三层评测体系做静态检查和去重再在真实任务里跑 A/B 对照最后看 Skill Lift 和 Token 成本是否匹配你的场景。而要让这套流程跑起来你需要一个稳定的模型调用通道。下面我把 SkillEvaluator 的评测思路接进 TaoToken用统一 Key 在 Claude Code 和 OpenAI Codex 场景下验证 Skill 调用链路的真实收益。2. TaoToken 前置统一 Key 与 API 通道准备在开始配置之前先说明 TaoToken 在这里的角色。它提供统一的 API 通道让你用同一个 Key 访问不同模型省去在多个平台之间切换的麻烦。对于 Skill 评测这种需要反复调用模型、对比不同框架的场景统一通道能减少环境变量和配置文件的维护成本。你需要先拿到 API Key。打开 TaoToken 控制台在 API Keys 页面创建一个新 Key复制保存。注意 Key 只在创建时显示一次丢了只能重新生成。控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsoleAPI Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdocAPI 基础地址是https://taotoken.net/api注意这个地址不加 UTM 参数直接用于代码里的 base_url 配置。提示如果你只是先验证模型对话是否通可以先用模型对话页面测试不用急着写配置文件。模型对话入口https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat拿到 Key 之后建议先做一次最小连通性验证确认 Key 和网络都没问题。用 curl 发一个最简单的请求curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 回复 OK}], max_tokens: 10 }如果返回里能看到choices字段和内容说明通道正常。这一步别跳过后面 Claude Code 和 Codex 的配置都依赖这个基础连通性。3. 可复制配置Claude Code 的 settings.json 与 Codex 的 config.tomlSkill 评测要在 Claude Code 和 OpenAI Codex 两套框架上分别跑所以两边的配置都要准备。TaoToken 的统一 Key 在这里的优势就体现出来了同一个 Key两边配置只改 base_url 和模型名。3.1 Claude Code 的 settings.json 骨架Claude Code 的配置文件通常放在用户目录下的.claude/settings.json。如果你用的是项目级配置也可以放在项目根目录的.claude/settings.json。下面是一个可复制的骨架{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-20250514 }, permissions: { allow: [ Read, Write, Bash ] } }这里的关键是ANTHROPIC_BASE_URL指向 TaoToken 的 API 地址ANTHROPIC_API_KEY填你刚才创建的 Key。模型名按你实际使用的填如果 TaoToken 支持多个模型可以在这里切换。注意Claude Code 读取的是ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY这两个环境变量。如果你在 shell 里已经导出过同名变量settings.json 里的值可能被覆盖建议先检查env | grep ANTHROPIC。3.2 OpenAI Codex 的 config.toml 骨架OpenAI Codex 的配置文件一般在~/.codex/config.toml。下面是一个可复制的骨架[model] provider taotoken name gpt-4o [provider.taotoken] base_url https://taotoken.net/api/v1 api_key YOUR_API_KEY wire_api chat [history] persistence save-all [sandbox] mode workspace-writebase_url这里写https://taotoken.net/api/v1因为 Codex 的 provider 配置通常需要完整的 v1 路径。wire_api设为chat表示走 Chat Completions 接口。sandbox模式建议先用workspace-write方便 Skill 执行过程中读写文件评测完成后再按需收紧。3.3 两套配置的对照配置项Claude CodeOpenAI Codex配置文件.claude/settings.json~/.codex/config.tomlbase_urlhttps://taotoken.net/apihttps://taotoken.net/api/v1Key 字段ANTHROPIC_API_KEYapi_key模型字段ANTHROPIC_MODELname沙箱控制permissions.allowsandbox.mode两套配置都指向同一个 TaoToken Key这样你在对比 Claude Code 和 Codex 的 Skill Lift 时模型通道这个变量就被控制住了差异更多来自框架本身和 Skill 设计。4. 验证请求一次 Skill 触发到结果回传的完整动作配置写好后别急着跑 300 个 Skill 的大评测。先用一个最小 Skill 做端到端验证确认 Skill 能被触发、执行、回传结果。4.1 准备一个最小 Skill在项目里建一个skills/hello-skill/SKILL.md内容如下--- name: hello-skill description: 当用户要求生成一个带时间戳的问候语时使用此 Skill --- # Hello Skill ## 使用场景 用户要求生成带时间戳的问候语。 ## 执行步骤 1. 获取当前时间格式为 YYYY-MM-DD HH:mm:ss 2. 输出[时间戳] Hello from Skill ## 示例 输入生成问候语 输出2026-08-12 14:30:00 Hello from Skill这个 Skill 足够简单但包含了前置元数据、使用场景、执行步骤和示例符合 SkillEvaluator 第一层校验的基本结构要求。4.2 在 Claude Code 中触发启动 Claude Code在对话里输入请使用 hello-skill 生成一个问候语如果配置正确Claude Code 会加载hello-skill按步骤执行返回类似2026-08-12 14:30:00 Hello from Skill这一步验证的是显式用例任务明确点名了 SkillAgent 应该能找到并加载它。4.3 在 Codex 中触发在 Codex 里输入同样的提示词。Codex 会读取config.toml里的 provider 配置通过 TaoToken 通道调用模型然后按 Skill 步骤执行。返回结果应该和 Claude Code 一致。4.4 验证隐式用例和负例显式用例通过后再测两个关键场景隐式用例输入「帮我生成一个带时间的问候」不点名 Skill看 Agent 是否主动加载hello-skill。这对应 SkillEvaluator 的可发现性维度。负例输入「帮我计算 11」看 Agent 是否错误加载hello-skill。如果加载了说明 Skill 的 description 边界不够清晰需要收紧触发条件。4.5 记录 Skill Lift对同一个任务分别在不启用 Skill 和启用 Skill 的情况下各跑一次记录结果。比如任务不启用 Skill启用 SkillSkill Lift生成带时间戳问候输出无时间戳输出带时间戳1计算 11正确正确0生成带时间戳问候隐式输出无时间戳输出带时间戳1这个最小验证跑通后你就可以把同样的流程套用到更复杂的 Skill 上逐步积累自己的 Skill Lift 数据。5. 本篇常见错排查配置和验证过程中最容易卡在几个地方。下面按现象、原因、解决方式整理。5.1 401 或 403 报错现象请求返回 401 Unauthorized 或 403 Forbidden。原因Key 填错、Key 被删除、或者 base_url 写成了带 UTM 的地址导致路径不对。解决检查ANTHROPIC_API_KEY或api_key是否和 TaoToken 控制台里的一致。base_url 用https://taotoken.net/api或https://taotoken.net/api/v1不要带查询参数。如果 Key 刚创建等几秒再试。5.2 Skill 没有被加载现象Agent 直接回答没有按 Skill 步骤执行。原因Skill 的 description 不够明确或者 Skill 目录不在 Agent 的扫描路径里。解决检查SKILL.md的前置元数据description要写清楚「什么时候用」。Claude Code 默认扫描.claude/skills/或项目里的skills/目录确认路径对得上。Codex 的 Skill 加载路径看它的文档通常也是项目级目录。5.3 负例被误触发现象无关任务也加载了 Skill。原因description 写得太宽泛比如「处理所有文本任务」这种。解决把 description 收窄到具体场景加上明确的触发条件。SkillEvaluator 的可发现性维度专门测这个误触发会拉低分数。5.4 Token 消耗异常增加现象启用 Skill 后 Token 反而涨了很多。原因Skill 内容太长或者 Skill 里包含大量示例和重复说明。解决用 SkillEvaluator 的第二层去重检查看看 Skill 内部有没有重复指导以及和其他 Skill 有没有内容重叠。精简 Skill 文本把非必要的示例删掉。NVIDIA 的 cuopt-install 案例就是 Token 增加 120.3% 的典型接入前最好先测一下成本。5.5 Claude Code 和 Codex 结果差异大现象同一个 Skill两套框架的 Skill Lift 差很多。原因框架的 Skill 加载机制、提示词组织方式、沙箱行为不同。解决这其实是正常现象。NVIDIA 的数据也显示不同产品间 Skill Lift 差异比框架间更大。建议分别记录两套框架的基线不要混在一起算平均分。如果差异过大先检查两边的 Skill 版本是否一致。5.6 配置文件不生效现象改了 settings.json 或 config.toml但行为没变。原因环境变量覆盖、配置文件路径不对、或者 Agent 进程没重启。解决先env | grep -E ANTHROPIC|OPENAI看有没有残留环境变量。确认配置文件在正确路径。改完配置后完全退出 Agent 再重新启动不要只开新对话。6. 把 Skill 评测接进日常开发流跑通最小验证后你可以把 SkillEvaluator 的三层思路固化到日常流程里。第一层校验用脚本自动跑检查 Skill 结构和安全项第二层去重用向量相似度定期扫描 Skill 目录第三层真实任务评测按需触发重点看 Skill Lift 和 Token 成本。对于长期做编码和 Agent 开发的场景如果调用量比较大可以看看 Coding Plan 是否适合你的使用节奏https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan如果你主要想先验证模型对话和 Skill 触发效果用模型对话页面就够了https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat配置和接入过程中遇到报错优先查 API Keys 和接入文档https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys 和 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdocClaude Code 相关的接入细节可以参考https://taotoken.net/claude-code?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentclaude-code我自己的做法是每新增一个 Skill先跑显式、隐式、负例三类用例记录 Skill Lift 和 Token 变化连续跑 3 次看波动。波动大的 Skill 先不接入生产流程等 description 和步骤稳定后再评估。这样比一次性跑 300 个 Skill 更可控也更容易定位问题。