ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Claude Skills 完整学习文档:从 SKILL.md 到 Agent 上下文管理实战

Claude Skills 完整学习文档:从 SKILL.md 到 Agent 上下文管理实战 1. 从一次上下文爆炸说起Claude Skills 到底解决什么问题如果你用 Claude Code 或任何 Agent 框架写过稍微复杂一点的任务大概率遇到过这种场景一开始对话很顺模型能准确理解你的意图但聊到二三十轮之后它开始忘记前面说过的规范输出格式飘了甚至把两个不同任务的上下文混在一起。这不是模型变笨了而是上下文窗口被塞满了无关信息也就是常说的 Context Rot。Claude Skills 就是为这个问题设计的。简单说它是一种模块化、可复用的知识包把特定领域的专业知识和标准操作流程封装成文件系统里的结构化单元。模型在需要时自动识别并加载对应 Skill不需要你每次手动粘贴一大段提示词。适合谁用适合那些需要让 AI 稳定执行重复性工程任务的人比如代码审查、提交信息生成、文档规范检查、API 设计评审。我试过把一个 300 行的代码审查提示词拆成三个 Skill 之后同样的审查任务 Token 消耗从约 3500 降到 1200 左右而且输出格式再也没飘过。核心原因就是渐进式披露Skill 的元数据name description始终加载在上下文里但核心指令和资源只在触发时才注入。这跟普通 Prompt 最大的区别在于普通 Prompt 是一次性的、每次都要完整输入而 Skill 是预定义的、可版本控制、可组合的知识单元。这一章先不急着写 SKILL.md而是把 Skills 和几个容易混淆的概念理清楚否则后面配置时很容易踩坑。1.1 Skills 与 Tool Calling、Function Calling 的边界很多人第一次接触 Skills 会问这不就是 Tool Calling 换了个名字吗不是。Tool Calling 是模型调用外部工具或 API 的能力比如查数据库、发请求Function Calling 是调用预定义函数偏代码级操作。而 Skill 是模型内部的标准化工作流程和知识库它封装的是“怎么做这件事”不是“用什么工具做”。举个具体对比。假设你要做销售数据分析用 Tool Calling 的思路你得告诉模型去调用 database-query 工具参数是 start_date 和 end_date然后拿到结果再调用 visualize 工具。每次都要重新描述工具说明上下文成本高。用 Skill 的思路你只需要触发/sales-report-generationSkill 内部已经定义好了先查数据、再清洗、再可视化、最后生成报告的完整流程。元数据常驻核心指令触发时加载。关键区别在于行为边界。Tool Calling 的边界由工具接口定义Skill 的边界由 SKILL.md 里的 Constraints 字段显式定义。这意味着 Skill 可以明确说“不允许修改代码”“不允许访问外部资源”而工具本身通常不管这些。1.2 Skills 与 Agent Workflow 的关系Agent Workflow 是整个 Agent 的任务分解和调度流程抽象层级更高。Skill 是 Agent 可以调用的能力模块。一个长期运行的 Agent 通常会组合多个 Skill 来完成复杂任务。比如一个用户反馈处理 Agent它的 Workflow 可能是接收反馈 → 分析问题类型 → 评估严重程度 → 分配负责人 → 跟踪进度 → 生成报告。而每个步骤背后可以对应一个 Skill/feedback-analysis、/prioritization、/task-assignment、/progress-tracking、/report-generation。这样设计的好处是Workflow 保持稳定Skill 可以独立迭代。你优化了反馈分析的规则只需要更新那一个 Skill不用动整个 Agent。1.3 为什么 Skills 适合封装内部流程Skills 最适合封装的是那些有明确标准、需要结果一致性、涉及团队规范的内部流程。比如代码审查标准、提交信息格式、文档模板、API 设计规范。这些流程的特点是步骤固定、输出格式要求严格、需要跨项目复用。反过来创造性任务、探索性分析、需要实时外部数据的场景就不太适合用 Skill 硬套。你没法把一个“帮我头脑风暴产品创意”的任务封装成固定流程那样反而限制了模型的能力。理解了这些边界接下来就可以动手配置环境了。下一章会讲怎么拿到 API Key、怎么把 Skill 接入 Claude Code以及最关键的 SKILL.md 模板怎么写。2. TaoToken 前置配置API Key 获取与 Claude Code 接入在写 SKILL.md 之前得先把运行环境搭好。Claude Skills 本身是文件系统里的结构化文档但要让模型真正调用它需要一个能访问 Claude 模型的通道。这里用 TaoToken 作为接入层它提供兼容 Anthropic 接口的 API 端点配置方式和官方一致。先明确三个核心要素后面所有配置都围绕它们展开Base URL、API Key、Model ID。这三个缺一个都跑不起来。2.1 获取 API Key 与确认 Base URL第一步打开 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册账号。注册流程不复杂邮箱验证后进入控制台。第二步在控制台里找到 API Keys 页面路径是 https://taotoken.net/console/api-keys 。点创建新 Key复制出来保存好。这个 Key 只显示一次丢了就得重新生成。第三步确认 Base URL。TaoToken 的 API 端点是 https://taotoken.net/api 注意这个地址后面不加任何 UTM 参数直接用作 Anthropic 兼容接口的 base_url。如果你用的是 Claude Code它默认读ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY两个环境变量。设置方式export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYsk-你的keyWindows 下用 PowerShell$env:ANTHROPIC_BASE_URLhttps://taotoken.net/api $env:ANTHROPIC_API_KEYsk-你的key设置完之后可以用一个最简单的请求验证通道是否通。用 curl 测试curl https://taotoken.net/api/v1/messages \ -H x-api-key: $ANTHROPIC_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 100, messages: [{role: user, content: 回复 OK}] }如果返回里能看到content字段和正常的文本说明 Key 和 Base URL 都对了。如果返回 401先检查 Key 有没有复制完整再检查 Base URL 有没有多写斜杠。2.2 在 Claude Code 中接入并启用 SkillsClaude Code 是命令行环境Skills 的加载基于文件系统。安装路径有两种个人全局 Skill 放在~/.claude/skills/下对所有项目生效。项目专用 Skill 放在项目根目录的.claude/skills/下只在该项目里可用。先建目录结构mkdir -p ~/.claude/skills mkdir -p .claude/skills然后把写好的 Skill 文件夹复制进去。一个 Skill 就是一个文件夹里面至少有一个SKILL.md。验证 Skill 是否被识别claude skill list如果列表里能看到你的 Skill 名称说明加载成功。Claude Code 2.1.0 以上版本支持热重载修改 SKILL.md 后不用重启claude skill reload my-skill这里有个容易忽略的点Skill 的触发依赖 description 字段的语义匹配不是关键词匹配。所以 description 写得越具体触发越准。比如写“处理文件”就太宽泛写“从 PDF 文件中提取文本和表格内容当用户要求处理 PDF 文档时触发”就明确得多。2.3 模型选择与 Coding Plan 的关系如果你只是偶尔验证 Skill 效果用按量计费的 API Key 就够了。但如果你要长期跑 Agent、做代码审查流水线建议看一下 Coding Plan。它的计费方式更适合高频调用场景不用每次担心 Token 消耗。模型 ID 方面Claude Code 里常用的有claude-sonnet-4-20250514和claude-opus-4-20250514。Sonnet 性价比高适合日常 Skill 调用Opus 推理更强适合复杂审查任务。你可以在模型对话页面先试试不同模型对同一个 Skill 的响应差异再决定长期用哪个。配置完成后下一章进入核心部分SKILL.md 的完整模板和 Agent 调用配置。3. 可复制配置SKILL.md 模板与 Agent 调用参数这一章给出一份可以直接复制使用的 SKILL.md 模板以及 Agent 侧的调用配置。模板覆盖了输入约束、行为边界、输出结构、失败条件、可组合性五个部分。你可以根据自己的场景删减但建议保留行为边界和输出结构这两个是保证稳定性的关键。3.1 完整 SKILL.md 模板先看一个代码审查 Skill 的完整示例。文件路径.claude/skills/code-review/SKILL.md--- name: code-review description: 审查 Python 代码质量检查性能问题、安全漏洞和可维护性。当用户要求审查代码或提交代码变更时触发。 version: 1.0.0 allowed-tools: [file-read] context: fork --- # 代码审查 ## Input Contract - **格式**纯文本代码片段或文件路径 - **类型**Python 代码 - **范围**仅限 Python 3.8 语法 - **验证规则** - 代码长度不超过 1000 行 - 不包含密码、API Key 等敏感信息 - **示例** python def calculate_sum(numbers): total 0 for num in numbers: total num return totalBehavior Boundary能力范围检查循环嵌套和算法复杂度识别 SQL 注入和 XSS 风险分析变量命名和函数复杂度执行限制不修改代码不生成新代码不访问外部资源禁止行为不提供重构建议不解释代码逻辑权限控制仅允许读取scripts/analysis.py仅允许读取references/security.mdOutput Contract格式Markdown 表格结构问题类型具体问题严重程度解决建议[类型][描述][高/中/低][建议]验证规则表格至少一行严重程度只能是高、中、低解决建议基于references/security.mdFailure Conditions触发条件输入不是 Python 代码响应格式[ERROR] 输入不是 Python 代码Rejection Conditions触发条件输入包含敏感信息代码超过 1000 行响应格式[REJECT] 无法执行原因恢复建议去除敏感信息或拆分代码后重试Composition输入输出标准化输入为代码文本输出为 Markdown 表格命名约定使用code-review-前缀触发词主触发词/code-review组合策略支持与/git-commit-generation管道组合这份模板里context: fork 是关键字段。它让 Skill 在独立上下文中执行避免中间结果污染主会话。allowed-tools 限制了这个 Skill 只能用 file-read不能写文件。 ### 3.2 Agent 调用配置 在 Agent 的 Prompt 里声明可用 Skill 和调用顺序。以下是一个代码审查 Agent 的配置示例 markdown 你是一个代码审查 Agent使用以下 Skills ## 可用 Skills - /code-review审查代码质量 - /git-commit-generation生成提交信息 ## 执行流程 1. 当用户提交代码时 - 调用 /code-review 分析代码 - 如果检测到问题生成修改建议不直接提交 - 如果无问题调用 /git-commit-generation 生成提交信息 2. 当用户要求审查文件时 - 读取文件内容 - 调用 /code-review 分析 ## 约束 - 不能跳过 /code-review 直接提交 - 不能在审查失败时继续执行 - 必须记录所有 Skill 调用到 logs/agent.log如果你用的是 Cline 或类似支持 MCP 的工具配置方式略有不同。需要在 MCP 配置文件里声明 Skill 目录然后 Agent 会自动加载。以 Cline 的 MCP 配置为例{ mcpServers: { claude-skills: { command: npx, args: [-y, anthropic/claude-skills-mcp], env: { SKILLS_DIR: ./.claude/skills, ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的key } } } }注意这里 Base URL 和 Key 都写全了Model ID 在 Agent 的模型选择里单独指定。三件套缺一不可。3.3 上下文注入与验证步骤Skill 写好后怎么确认它真的被加载并生效了分三步验证。第一步检查文件结构。确保SKILL.md在正确目录下YAML 头格式正确。用 yamllint 检查yamllint .claude/skills/code-review/SKILL.md第二步强制调用 Skill 看响应。在 Claude Code 里输入claude /code-review然后粘贴一段测试代码。如果返回的是 Markdown 表格格式的审查结果说明 Skill 生效了。如果返回的是普通对话说明触发失败检查 description 字段。第三步查看执行日志确认上下文隔离tail -f ~/.claude/logs/skills.log日志里应该能看到 Skill 名称、执行时间、Token 使用量。如果看到context: fork相关的隔离记录说明独立上下文生效了。配置到这里基本环境就通了。下一章讲怎么发请求验证以及成功结果长什么样。4. 验证请求与成功结果从 curl 到 Agent 实测配置写完不代表能用得实际发请求验证。这一章从最简单的 API 调用开始逐步过渡到 Agent 里的 Skill 触发每一步都给出预期结果和判断标准。4.1 用 curl 验证模型通道先确认 TaoToken 的 API 通道正常。用上一章设置的 Key 发一个最小请求curl https://taotoken.net/api/v1/messages \ -H x-api-key: $ANTHROPIC_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 200, messages: [ {role: user, content: 用一句话说明什么是渐进式披露} ] }预期返回结构{ id: msg_xxx, type: message, role: assistant, content: [ { type: text, text: 渐进式披露是指按需分阶段加载信息... } ], model: claude-sonnet-4-20250514, usage: { input_tokens: 20, output_tokens: 45 } }看到content数组里有文本usage里有 Token 计数说明通道正常。如果返回401检查 Key如果返回404检查 Base URL 有没有写错路径。4.2 在 Claude Code 中触发 Skill通道验证通过后进入 Claude Code 测试 Skill。先确认 Skill 已加载claude skill list输出应该类似Available skills: code-review 审查 Python 代码质量 git-commit-generation 生成提交信息然后触发 code-reviewclaude /code-review粘贴测试代码def get_user_data(user_id): query SELECT * FROM users WHERE id user_id return db.execute(query)预期返回问题类型具体问题严重程度解决建议安全漏洞SQL 拼接导致注入风险高使用参数化查询替代字符串拼接可维护性问题函数缺少错误处理中添加 try-except 处理数据库异常如果返回的是这个格式说明 Skill 的 Output Contract 生效了。如果返回的是自由文本检查 SKILL.md 里 Output Contract 的格式定义是否明确。4.3 验证上下文隔离效果context: fork是否真的隔离了上下文做一个对比测试。先在不带 fork 的 Skill 里执行一个长任务然后在同一会话里问一个无关问题看模型是否被前面的中间结果干扰。再在带 fork 的 Skill 里做同样操作。实测下来带 fork 的 Skill 执行完后主会话的上下文长度基本没变化后续对话不受影响。不带 fork 的 Skill 执行后主会话上下文会明显增长后续问题可能被之前的审查细节带偏。查看日志确认grep fork ~/.claude/logs/skills.log应该能看到类似context forked for skill: code-review的记录。4.4 验证 Skill 组合管道测试两个 Skill 串联。先触发 code-review再触发 git-commit-generationclaude /code-review # 粘贴代码得到审查结果 claude /git-commit-generation # 输入变更描述得到提交信息预期 git-commit-generation 返回fix: 修复用户查询中的 SQL 注入风险添加参数化查询如果两个 Skill 都能独立触发且输出格式正确说明组合管道通了。注意管道组合时前一个 Skill 的输出会作为后一个的输入上下文但因为有 fork 隔离不会互相污染。验证通过后下一章讲最常见的报错和排查方法。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth配置和调用过程中最容易遇到四类报错。这一章逐个拆解原因和解决方法每个都给出具体命令和判断依据。5.1 401 UnauthorizedKey 或 Base URL 问题报错原文{type:error,error:{type:authentication_error,message:invalid x-api-key}}原因通常有三个Key 复制不完整、Key 已过期、Base URL 写错导致请求发到了错误端点。排查步骤echo $ANTHROPIC_API_KEY echo $ANTHROPIC_BASE_URL确认 Key 以sk-开头且长度完整Base URL 是https://taotoken.net/api不带尾部斜杠。如果环境变量没问题直接在 curl 里硬编码测试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:50,messages:[{role:user,content:test}]}如果 curl 通了但 Claude Code 不通检查 Claude Code 的配置文件里是否覆盖了环境变量。Claude Code 的配置优先级是命令行参数 项目配置 全局配置 环境变量。5.2 local proxy failed本地代理配置冲突报错原文Error: local proxy failed to connect这个报错通常出现在系统设置了 HTTP_PROXY 或 HTTPS_PROXY 环境变量但代理服务没启动或端口不对。Claude Code 会尝试走系统代理导致连接失败。排查env | grep -i proxy如果有输出说明设置了代理。临时清除unset HTTP_PROXY unset HTTPS_PROXY unset http_proxy unset https_proxy然后重新运行 Claude Code。如果清除后正常说明是代理配置问题。注意这里不是让你去配代理而是排查是否有残留的代理设置干扰了直连。5.3 reading choices响应格式解析失败报错原文Error: reading choices: unexpected end of JSON input这个报错说明客户端期望收到 OpenAI 格式的choices数组但实际收到的是 Anthropic 格式的content数组。原因是 Base URL 指向了错误的端点或者客户端配置的 API 格式不匹配。Claude Code 和 Anthropic SDK 用/v1/messages端点返回content格式。如果你用的工具期望/v1/chat/completions和choices格式就会报这个错。解决方法是确认工具的 API 格式设置。如果工具支持 Anthropic 格式选 Anthropic如果只支持 OpenAI 格式需要确认 TaoToken 是否提供对应的兼容端点。检查配置里的base_url是否和工具要求的格式匹配。5.4 OAuth 相关报错认证方式不匹配报错原文Error: OAuth token expired or invalidClaude Code 某些版本会尝试用 OAuth 方式认证而不是 API Key。如果你用的是 API Key 方式需要在配置里明确指定认证类型。检查 Claude Code 配置cat ~/.claude/config.json确认里面有{ authType: api_key, apiKey: sk-你的key, baseUrl: https://taotoken.net/api }如果 authType 是oauth改成api_key。如果配置里没有 authType 字段手动加上。另外如果你之前登录过官方账号可能有缓存的 OAuth token 干扰。清除缓存rm -rf ~/.claude/auth-cache然后重新用 API Key 认证。5.5 Skill 不触发description 匹配失败报错表现输入触发词后模型没有加载 Skill而是用普通对话回复。排查步骤claude skill describe code-review看输出的 description 是否和你的预期一致。如果 description 太宽泛或太窄都会导致匹配失败。优化方法在 description 里加入具体的触发场景和关键词。比如把“审查代码”改成“审查 Python 代码质量检查性能问题、安全漏洞和可维护性。当用户要求审查代码或提交代码变更时触发”。改完后重载claude skill reload code-review再测试触发。5.6 Skill 执行超时上下文过大报错表现Skill 执行很久没返回或者返回context length exceeded。原因是 Skill 的 SKILL.md 主文件太大或者引用的 references 文件被全量加载。解决方法把大段文档移到references/目录在 SKILL.md 里只保留引用路径。比如详细安全规范见 references/security.md模型只在需要时才读取 references 文件不会一开始就全部加载。检查当前 Skill 的 Token 占用grep token ~/.claude/logs/skills.log | grep code-review如果单次执行超过 3000 tokens考虑拆分 Skill。排查完这些常见问题基本能覆盖 90% 的配置故障。最后一章给出 CTA 分流按你的使用场景选择下一步。6. 按场景选择下一步API Keys、模型对话与 Coding Plan配置跑通之后接下来做什么取决于你的使用场景。这里按三类需求给出对应的入口每个入口都带完整的 UTM 参数方便追踪来源。6.1 排障与接入API Keys 接入文档如果你还在配置阶段或者遇到了上面没覆盖的报错先去 API Keys 页面确认 Key 状态再对照接入文档检查配置。API Keys 管理页面https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite文档里有完整的 Base URL 说明、认证方式、各语言 SDK 示例。遇到 401 或格式不匹配的问题先查文档里的错误码对照表。6.2 验证模型效果模型对话如果你想先试试不同模型对同一个 Skill 的响应差异用模型对话页面最方便。不用写代码直接粘贴 SKILL.md 内容和测试输入看输出格式是否符合预期。模型对话入口https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite建议对比claude-sonnet-4-20250514和claude-opus-4-20250514两个模型。Sonnet 响应快、成本低适合日常 Skill 调用Opus 在复杂审查任务上推理更细但 Token 消耗更高。实测下来代码审查类 Skill 用 Sonnet 就够了除非涉及多文件交叉分析。6.3 长期编码与 AgentCoding Plan如果你要把 Skill 接入长期运行的 Agent或者做代码审查流水线按量计费的 API Key 可能不够划算。Coding Plan 针对高频调用场景做了优化适合持续跑 Agent 的开发者。Coding Plan 入口https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite开通后你的 Agent 可以稳定调用 Skill不用担心单次 Token 消耗波动。配合context: fork的隔离机制长期运行的上下文管理也会更可控。6.4 Claude Code 专项配置如果你主要用 Claude Code还有一个专门的配置页面里面有环境变量模板、Skill 目录结构示例、热重载命令。Claude Code 配置入口https://taotoken.net/claude-code?utm_sourcetaotoken_aicg_blog_endutm_contentclaude_codeutm_campaignrewrite这个页面里的配置和本文第三章的模板一致可以直接复制。注意 Base URL 用https://taotoken.net/api不要加尾部斜杠。最后提醒一个实操细节Skill 的版本控制很重要。把.claude/skills/目录纳入 Git 管理每次修改 SKILL.md 都提交一次这样团队协作时不会出现版本不一致的问题。回滚也简单git checkout到上一个 commit 就行。
返回列表