1. 从一次“Agent 又忘了规矩”说起Agent Skills 这个词最近在智能体圈子里出现频率很高但很多人第一次听到会把它和提示词、MCP、Subagent 混在一起。简单说Agent Skills 是给大模型 Agent 安装的“工作手册”它规定遇到某类任务时该走什么流程、能用哪些工具、哪些动作必须先确认、失败时怎么退出。它解决的不是“这次怎么说”而是“这类任务以后都怎么做”。适合谁适合已经在用 Coding Agent、Claude Code、Cursor 这类工具并且开始遇到“多人共用同一个 Agent行为不一致”的团队和个人。我试过在一个三人协作的仓库里让 Agent 修 CI结果三个人得到的修复方案风格完全不同有人先跑全量测试有人只盯报错文件有人直接改代码不确认影响范围。问题不在模型而在于我们把工作习惯留在了各自脑子里没有沉淀成可安装、可触发、可迁移的能力单元。这篇就围绕 Agent Skills 与 MCP、Subagent 的协同拆解工具调用链路并给出可复制的 settings.json 与 config.toml 骨架演示通过 TaoToken 统一 Key/API 通道接入 AI 工具最后给出 Subagent 注册与 MCP 服务连通性验证动作。先厘清四个概念的关系不然后面配置会乱。提示词偏“这一次的指令”MCP 偏“工具插座”把 GitHub、数据库、浏览器接进来Hook 偏“事件触发”在某个动作前后自动执行Subagent 偏“分工执行”把一部分任务交给独立上下文去跑Skill 偏“可复用能力包”把流程、工具约束、边界规则打包。一个 Skill 可以调用 MCP 工具可以触发 Hook也可以把子任务交给 Subagent。理解这条链路配置才有意义。2. TaoToken 前置统一 Key 与 API 通道在配 Skill 之前先把模型通道固定下来。否则每个工具各配一套 KeySkill 迁移时又要重配一遍。TaoToken 在这里的角色是统一入口官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址 https://taotoken.net/api 。你可以在控制台创建 Key然后在不同 AI 工具里复用同一套通道。操作顺序建议这样先打开控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建一个项目级 Key再到 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 复制 Key 并保存到本地环境变量。不要直接把 Key 写进会提交到 Git 的配置文件用环境变量引用。# 写入 shell 配置按需替换成你自己的 Key export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api验证通道是否通先用一条最小请求探活不要一上来就接 Agentcurl -s https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ | head -c 400返回模型列表就说明 Key 和通道都正常。如果这里就报 401先别往下配 Skill回到 API Keys 页面确认 Key 是否复制完整、是否被禁用。通道通了再进入工具配置。3. 可复制配置settings.json 与 config.toml 骨架不同工具读取的配置文件名不一样。Claude Code 一类工具常用 settings.json部分 CLI Agent 用 config.toml。下面给两份骨架重点是通道字段和 Skill 目录字段你按自己工具的实际字段名微调。先看 settings.json把模型通道指向 TaoToken并声明 Skill 与 Subagent 的加载路径{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, modelName: claude-sonnet-4-5 }, skills: { enabled: true, directories: [./skills, ~/.agent/skills], autoTrigger: true }, subagents: { enabled: true, registry: ./subagents/registry.json }, mcp: { serversFile: ./mcp/servers.json } }再看 config.toml适合偏 CLI 的 Agent字段含义与上面一致[model] provider openai-compatible base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY model_name claude-sonnet-4-5 [skills] enabled true directories [./skills, ~/.agent/skills] auto_trigger true [subagents] enabled true registry ./subagents/registry.json [mcp] servers_file ./mcp/servers.jsonSkill 本体建议一个目录一个 Skill目录里放 SKILL.md把触发条件、输入边界、执行步骤、工具约束、输出格式、失败出口写清楚。下面是一个修 CI 的 Skill 骨架--- name: fix-ci description: 当用户要求修复 CI 失败时启用 trigger: [修 CI, fix ci, 流水线失败] tools: [mcp__github, mcp__shell] --- ## 输入边界 - 需要失败流水线链接或仓库名 - 需要最近一次失败日志 ## 执行步骤 1. 拉取失败日志定位首个失败任务 2. 判断是代码问题还是环境问题 3. 代码问题给出最小修复补丁先不提交 4. 环境问题列出需要人工确认的配置项 ## 工具约束 - 允许读取仓库与日志 - 禁止直接 push必须等用户确认 ## 失败出口 - 日志缺失或权限不足时停止并说明缺什么Subagent 注册文件 registry.json 用来声明可调用的子代理每个子代理有独立上下文和职责{ subagents: [ { name: log-analyzer, description: 只负责解析 CI 日志并输出失败点, model: claude-sonnet-4-5, tools: [mcp__shell] }, { name: patch-writer, description: 根据失败点生成最小补丁不执行提交, model: claude-sonnet-4-5, tools: [mcp__github] } ] }MCP 服务声明放在 servers.json把工具插座接进来{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_TOKEN: ${GITHUB_TOKEN} } }, shell: { command: npx, args: [-y, modelcontextprotocol/server-shell] } } }配置写完后链路是用户请求 → Agent 匹配 Skill → Skill 按步骤调用 MCP 工具 → 需要分工时交给 Subagent → 结果回到主 Agent 汇总。这条链路里TaoToken 负责模型通道Skill 负责流程MCP 负责工具Subagent 负责分工各司其职。4. 验证请求与成功结果配置写完必须验证否则你无法判断是通道问题、Skill 没触发还是 MCP 没连上。分三步验证每步都有明确的成功标志。第一步验证模型通道。用一条带工具调用的请求确认模型能返回结构化调用意图curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 列出当前目录文件}], tools: [{ type: function, function: { name: list_files, description: 列出目录文件, parameters: {type: object, properties: {}} } }] } | head -c 600成功标志返回体里出现 tool_calls 或等价的工具调用字段说明模型通道和工具调用能力都正常。第二步验证 Skill 触发。在 Agent 里输入“帮我修 CI”观察它是否加载了 fix-ci 这个 Skill。成功标志Agent 输出里出现 Skill 名称或日志里出现 skill loaded: fix-ci。如果没触发检查 SKILL.md 的 trigger 字段是否包含你输入的关键词以及 settings.json 里 skills.enabled 是否为 true。第三步验证 MCP 连通性。单独跑一次 MCP 服务确认它能启动并响应npx -y modelcontextprotocol/server-github --help成功标志输出帮助信息且无报错。如果这里失败先解决 Node 环境和依赖问题再回到 Agent 里测试。三步都通过后再跑一次完整任务让 Agent 修一个真实的 CI 失败观察它是否按 Skill 步骤先拉日志、再定位、再给补丁并且没有直接 push。成功标志Agent 给出补丁并等待你确认而不是自作主张提交。5. 本篇常见错排查配置过程中最容易踩的坑集中在通道、Skill 触发和 MCP 权限三块。下面按现象给排查路径。现象一请求返回 401 或 403。先确认 TAOTOKEN_API_KEY 是否在当前 shell 生效用 echo $TAOTOKEN_API_KEY 检查。如果为空说明环境变量没加载重新 source 一下 shell 配置。如果 Key 有值仍报错回到 API Keys 页面确认 Key 状态必要时重新生成。现象二Skill 不触发。先看 SKILL.md 的 trigger 是否覆盖了用户说法中文和英文关键词都写上更稳。再看 settings.json 的 skills.directories 路径是否正确相对路径是相对于 Agent 工作目录不是相对于配置文件。最后确认 autoTrigger 为 true否则需要手动指定 Skill。现象三MCP 服务启动失败。常见原因是 npx 拉包超时或 Node 版本过低。先升级 Node 到 18 以上再手动跑一次 npx 命令看报错。如果是权限问题检查 servers.json 里 env 引用的变量是否已导出比如 GITHUB_TOKEN。现象四Subagent 不生效。检查 registry.json 路径是否与 settings.json 里 subagents.registry 一致以及每个 Subagent 的 name 是否唯一。如果主 Agent 没有把任务分出去可能是 Skill 步骤里没写“交给 Subagent”在 SKILL.md 的执行步骤里显式写明分工。现象五模型返回了工具调用但 Agent 没执行。这通常是工具名不匹配MCP 暴露的工具名和 Skill 里 tools 字段写的不一致。对照 MCP 服务实际暴露的工具名改 Skill 配置。排查顺序建议从通道到 Skill 再到 MCP因为通道不通后面都白搭。每解决一层用对应的验证命令确认一次不要跳步。6. 把通道和技能都固定下来Agent Skills 的价值不在于给 Agent 多塞几段提示词而在于把可复用的工具习惯、领域流程和安全边界封装成可安装、可触发、可迁移的能力单元。判断一个 Skill 值不值得沉淀只看一件事它能不能减少下一次同类任务里的重新解释。能就写进 Skill 库不能就继续留在提示词里。配置层面先把模型通道固定下来再写 Skill 和 Subagent最后接 MCP。通道固定用 TaoToken控制台建 Key、API Keys 页面复制、环境变量引用三步走完再动 Skill。需要长期跑编码和 Agent 任务的可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 想先验证模型对话效果的用模型对话 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 接入细节和字段说明看接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。Claude Code 相关配置参考 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。最后留一个实用习惯每沉淀一个 Skill就在 SKILL.md 顶部写清楚失败出口。Agent 变强以后真正稀缺的不是提示词而是团队把经验封装成能力的速度。而速度的前提是每次失败都知道该停在哪里。