1. 为什么 Skill 一多就乱:从手写到工程化
Agent Skill 这个概念在 Claude Code、Codex、OpenClaw、Trae、CodeBuddy 里陆续落地之后,很多人第一反应是「不就是写个 SKILL.md 嘛」。我一开始也这么想,直到本地 skills 目录里堆到三十多个文件夹,才发现问题根本不是「会不会写」,而是「写完怎么管」。
一个 SKILL.md 的结构其实不复杂:frontmatter 里写 name 和 description,正文写触发条件、执行步骤、脚本调用方式。手写三五个还能靠记忆,但数量上去之后,你会遇到几个很具体的麻烦。第一,新建 Skill 时容易漏掉测试环节,写完 frontmatter 就觉得完事了。第二,改完一个 Skill 之后,你没法判断它到底变好了还是只是「看起来更完整」。第三,有些 Skill 格式完全正确,但 Agent 实际调用时要么误触发,要么该触发时不触发。
这就是把 Skill 当 Prompt 写和把 Skill 当工程资产管的区别。Prompt 是一次性指令,Skill 是长期复用的能力包,它需要触发条件、输入输出定义、错误处理、测试用例和版本回滚。本文要交付的是一条完整链路:用 skill-creator 从零生成 SKILL.md 骨架,用 darwin-skill 做评分和迭代,中间所有模型调用统一走 TaoToken 的 Key 和 API 通道。适合已经在用 Claude Code 或类似工具、手里 Skill 超过十个、开始觉得手动维护吃力的开发者。
整条链路里,TaoToken 扮演的是「统一出口」的角色。skill-creator 在生成和测试阶段要调用模型,darwin-skill 在评分阶段要用子 Agent 打分,这些请求如果各自配一套 Key,管理成本会很高。把 base_url 和 api_key 收敛到一处,后面换模型、加并发、做对比测试都省事。
2. TaoToken 前置:Key、通道与配置文件位置
在动手写 Skill 之前,先把模型通道打通。TaoToken 的定位是统一的模型 API 入口,你只需要一个 Key,就能在 skill-creator 的测试环节和 darwin-skill 的评分环节复用同一套配置。
先拿 Key。打开控制台创建 API Key,地址是 https://taotoken.net/api-keys ,创建后复制保存,后面配置文件里要用。如果你还没注册,从官网入口进:https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。API 的基础地址是 https://taotoken.net/api ,注意这个地址后面不加任何查询参数。
这里要区分两个概念。一个是模型对话入口,用来在网页上直接验证模型是否可用,地址是 https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。另一个是给本地工具用的 API 通道,也就是 https://taotoken.net/api 。前者用来快速试,后者写进配置文件。
配置文件分两处。Claude Code 这类工具读的是 settings.json,通常放在用户目录下的 .claude 文件夹里。如果你用的是 Codex 或兼容 OpenAI 接口的工具,配置写在 config.toml。两个文件的字段名不一样,但核心都是 base_url 和 api_key 两项。下面两节分别给出可复制的骨架。
注意:API Key 不要提交到 Git 仓库,也不要写进 Skill 的 SKILL.md 里。Skill 只描述「怎么调用」,凭证放在工具级配置里。
3. 可复制配置:settings.json 与 config.toml 骨架
先看 settings.json。这个文件给 Claude Code 用,核心是把模型请求指向 TaoToken 的 API 地址。下面是一份可以直接改的骨架,把sk-你的Key替换成上一步创建的值。
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的Key", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" }, "permissions": { "allow": [ "Bash(python:*)", "Read", "Write" ] } }这里ANTHROPIC_BASE_URL指向 TaoToken 的 API 根地址,工具会把/v1/messages这类路径拼在后面。ANTHROPIC_MODEL按你实际要用的模型名填,不确定就先留默认。permissions.allow里放的是 Skill 脚本执行需要的权限,比如Bash(python:*)允许跑 Python 脚本,Read和Write允许读写文件。skill-creator 在测试阶段会调用脚本,darwin-skill 在评分时会读测试结果,这两个权限基本够用。
再看 config.toml。如果你用的是 Codex 或走 OpenAI 兼容协议的工具,配置长这样:
model = "gpt-4o" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" [profiles.default] model_provider = "taotoken" model = "gpt-4o"env_key这一项表示 Key 从环境变量读,不直接写进文件。设置环境变量的方式,Windows PowerShell 用$env:TAOTOKEN_API_KEY="sk-你的Key",macOS 或 Linux 用export TAOTOKEN_API_KEY="sk-你的Key"。这样配置文件可以放心提交,Key 留在本地环境里。
两个文件都配好之后,先别急着建 Skill,用一条最小请求验证通道是否通。下一节给验证命令。
4. 验证请求:确认通道通了再建 Skill
验证分两步。第一步用 curl 直接打 API,确认 Key 和地址没问题。第二步在工具里跑一次模型对话,确认配置文件被正确读取。
先看 curl。这条命令发一个最小的 messages 请求:
curl https://taotoken.net/api/v1/messages \ -H "x-api-key: sk-你的Key" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-sonnet-4-20250514", "max_tokens": 64, "messages": [ {"role": "user", "content": "回复两个字:通了"} ] }'如果返回的 JSON 里content数组有文本内容,说明 Key 和地址都对。如果返回 401,检查 Key 有没有复制完整;返回 404,检查 base_url 是不是写成了带路径的形式,根地址就是https://taotoken.net/api,不要自己加/v1。
第二步,在 Claude Code 里直接问一句「你现在用的是哪个模型」,或者跑一次/skill-creator看它能不能正常响应。如果工具报「connection refused」或「invalid api key」,八成是 settings.json 的路径不对,或者环境变量没生效。Windows 上 settings.json 一般在C:\Users\你的用户名\.claude\settings.json,macOS 在~/.claude/settings.json。
通道验证通过之后,就可以进入 skill-creator 环节了。安装 skill-creator 有两种方式,用 npx 的话:
npx skills add https://github.com/anthropics/skills --skill skill-creator或者用 Claude 的安装命令:
claude install anthropics/skills/skill-creator装完之后,本地 skills 目录下会多出 skill-creator 文件夹,里面有 SKILL.md、agents、eval-viewer、references 和 scripts。这说明它不是单纯生成一段 Markdown,而是带了一整套开发工具链。
5. 用 skill-creator 生成 SKILL.md 骨架
skill-creator 的工作方式是一个循环:想清楚需求、起草 SKILL.md、设计测试用例、运行测试、评估打分、根据反馈修改、满意后打包。这个循环里最关键的不是「生成」,而是「测试」。很多人把 Skill 当增强 Prompt,写得越详细越觉得好,但 Agent 的表现取决于触发条件是否清楚、步骤是否可执行、参考资料位置是否正确、错误路径有没有处理。
我试过用它创建一个读取 CSDN 作者公开信息的 Skill,需求描述是这样的:输入一个 CSDN 博客主页地址,读取作者的公开资料。这个需求适合拆成单一职责的 Skill,名字叫csdn-author-info,而不是做成万能爬虫。
生成出来的 SKILL.md 骨架,frontmatter 部分长这样:
--- name: csdn-author-info description: Use when the user provides a CSDN blog homepage URL or asks to read, fetch, extract, or summarize public CSDN author profile details, including author name, avatar, code age, article count, fans, visits, rank, level, score, likes, comments, collections, or shares. ---这里有几个设计点值得注意。name用小写字母加连字符,方便识别。description同时说明「能做什么」和「什么时候用」,这是触发准确率的关键。范围限定在 CSDN 作者公开资料,不扩展成通用网页爬虫。输出字段在 description 里提前列清楚,降低 Agent 自由发挥的空间。
正文部分,skill-creator 会生成 Overview、Input、Workflow、Output、Failure Handling 几个段落。Workflow 里把确定性逻辑交给脚本,比如请求网页、解析字段、输出 JSON,Agent 只负责判断何时调用、如何解释结果。这样比每次让 Agent 临时写爬虫可靠得多。
脚本调用部分,它推荐用环境变量而不是硬编码路径:
python "$env:CLAUDE_SKILL_DIR\scripts\fetch_csdn_author.py" "https://blog.csdn.net/heian_99" --format jsonBash 环境下对应的是$CLAUDE_SKILL_DIR。如果环境变量不可用,再退回相对路径scripts/fetch_csdn_author.py。
生成骨架之后,别急着打包。先设计两三个测试用例,比如「给一个合法 CSDN 主页地址」「给一个非 CSDN 地址」「给一个不存在的作者 ID」,跑一遍看触发和输出是否符合预期。这一步是 skill-creator 和手写最大的区别。
6. 用 darwin-skill 做评分与迭代
skill-creator 解决从 0 到 1,darwin-skill 解决从 1 到 N。它的核心思想是把 Skill 优化当成一个自主实验循环:提出改进方案、实际测试、评分、只保留真正变好的修改。
安装方式:
npx skills add alchaincyf/darwin-skill它最有意思的机制是「棘轮」。棘轮只能向一个方向转,放到 Skill 优化里就是:新版本分数更高就保留,分数更低就回滚。举个例子,当前最优版本 78 分,第一轮优化后 81 分保留,第二轮优化后 75 分回滚,第三轮从 81 分继续。这样能避免一个常见问题:Skill 改着改着,内容加了很多,实际质量却下降了。
darwin-skill 用 8 维度评分,总分 100,其中结构维度 60 分,效果维度 40 分,实测表现单项权重最高,达到 25 分。这个比例很合理,因为 Skill 不是简历,格式规范只是底线,真正决定价值的是它在真实任务里触发准不准、执行稳不稳、输出可不可靠。
它还有五条原则,可以理解成一套优化纪律。单一可编辑资产,每次只改一个 SKILL.md,方便归因。双重评估,结构评分加实际效果验证。棘轮机制,只保留改进。独立评分,用子 Agent 打分,避免自己改自己评。人在回路,每个 Skill 优化后暂停,让用户确认。
评分环节的模型调用同样走 TaoToken 通道。因为 darwin-skill 会起子 Agent 做独立评分,如果每个子 Agent 各配一套 Key,管理会很乱。统一 base_url 之后,评分请求和主流程请求走同一个出口,日志和用量也好统计。
实际操作时,先跑一轮基线评分,记下当前分数。然后针对得分最低的维度改一版,再跑评分。如果分数涨了就保留,跌了就回滚。这个过程可以重复几轮,直到分数不再明显上升。
7. 本篇常见错排查
第一个坑是 base_url 写错。很多人习惯性写成https://taotoken.net/api/v1,结果请求 404。根地址就是https://taotoken.net/api,路径由工具自己拼。如果工具报「unexpected path」,先检查这一项。
第二个坑是 Key 没生效。settings.json 里写了 Key,但环境变量里也有一个旧的,工具优先读环境变量。排查方法是临时清掉环境变量再跑一次,或者直接在配置文件里确认字段名没写错。Claude Code 读的是ANTHROPIC_API_KEY,Codex 读的是env_key指定的那个变量名,两者不通用。
第三个坑是 Skill 触发不准。表现是该调用时不调用,或者不该调用时乱调用。根因通常在 description 写得太宽或太窄。太宽比如只写「处理 CSDN 相关任务」,太窄比如只写「读取 CSDN 作者粉丝数」。修法是让 description 同时覆盖「动作」和「对象」,并且列出典型输入形式。
第四个坑是脚本在 Windows 终端输出乱码。CSDN 页面里有中文,Python 脚本直接 print 到 CP936 终端会花屏。解决办法是 JSON 输出用 ASCII 转义,或者显式指定 stdout 编码。脚本里加一个--stdout-encoding auto参数,自动读 Windows 控制台代码页,能省不少事。
第五个坑是 darwin-skill 评分时子 Agent 超时。评分请求比普通对话长,如果并发开太高容易触发限流。把并发降到 2 到 3,或者给评分请求单独设一个稍长的超时。TaoToken 通道本身支持并发,但子 Agent 数量要按实际配额调。
第六个坑是把 Skill 当 Prompt 写。Prompt 是一次性指令,Skill 是长期资产。Skill 要考虑触发条件、输入输出、错误处理、测试和维护。如果一个 Skill 里塞了「爬取信息」「分析质量」「生成报告」「发布」四件事,触发条件和执行路径会变得混乱,应该拆成多个单一职责的 Skill。
8. 把创建到进化跑成闭环
整条链路跑通之后,日常操作就变成两个动作。新建 Skill 时,用 skill-creator 生成骨架,补上 scripts、references、assets,设计测试用例跑一遍,打包。已有 Skill 需要优化时,用 darwin-skill 跑基线评分,针对低分维度改一版,再评分,涨了保留跌了回滚。
模型通道统一走 TaoToken 之后,skill-creator 的测试请求和 darwin-skill 的评分请求共用一套配置,换模型只需要改一处。如果你主要做长期编码和 Agent 迭代,可以看 Coding Plan 的说明,地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。接入细节和字段说明在文档里:https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。想先在网页上验证模型输出,用模型对话入口:https://taotoken.net/api?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。Key 的管理和创建在控制台:https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。
最后留一个实用习惯:每次 darwin-skill 评分后,把分数和改动点记在一个本地 changelog 里。Skill 数量上去之后,这份记录比 SKILL.md 本身还值钱,因为它告诉你哪些改动真的有效,哪些只是看起来更完整。