1. 从一次 tool_use 报错说起Skills、MCP、Rules 到底谁在调用谁先还原一个真实场景。你给项目配了.claude/rules/*.md又装了两个 MCP Server还从社区抄了一个SKILL.md放进.claude/skills/。跑起来之后模型该遵守的规范没遵守该调的工具没调日志里只有一行tool_use的 JSON。你开始怀疑是不是 Rules 没生效是不是 MCP 没连上是不是 Skill 描述写得太短我试过把这三样东西拆开单独测最后发现一个反直觉的结论Skills、MCP、Rules 在 Claude Code 里根本不是三个平行的功能模块它们最终都收敛到同一套 tool_use 协议和 messages 注入机制上。你看到的区别大部分是信息被塞进了 API 请求的不同位置而不是底层能力有什么本质不同。这篇文章面向正在给多个 AI 工具配接入方式、被多套 Key 和 Base URL 搞烦的开发者。我会从调用链角度拆开三者给出可复制的settings.json与 Base URL 配置片段把 endpoint 统一改到 TaoToken并附一次 tool_use 触发验证动作让你亲眼看到 Skills、MCP、Rules 在统一通道下的实际行为差异。核心检索词先摆出来Claude Code 的 Skills 是可复用提示词、MCP 是标准化工具协议、Rules 是项目级行为规范三者都通过 tool_use 或 messages 注入参与推理。先建立一个最小认知模型。每次 Claude Code 调用模型本质是一个 HTTP 请求请求体三个核心字段system你是谁、你该怎么做、tools你能做什么、messages对话发生了什么。Rules 走的是messages最前面的system-reminder注入MCP 同时占tools[]和system动态区两个位置Skills 则是先注册一个叫Skill的工具模型触发后把 Markdown 文本作为isMeta的 user 消息塞回messages。三者最终都变成模型上下文里的一段文本或一个工具定义模型本身不执行任何东西它只输出结构化 JSON真正干活的是 Claude Code 客户端。理解这一点后面所有区别都能自己推出来。下面按原问题 → 前置 → 配置 → 验证 → 排障 → 收口的顺序展开每一步都给可复制的片段。2. 前置认知tool_use 是三者共同的底层协议在动手改配置之前必须先把 tool_use 的多轮协议讲清楚否则你会在排障时把模型没触发和客户端没路由混为一谈。Claude 的工具调用是一个结构化的多轮对话。用户发消息后模型推理并输出一个tool_use块形如{type:tool_use,id:toolu_xxx,name:工具名,input:{...}}。注意模型到这里就停了它没有执行任何操作。调用方也就是 Claude Code 客户端拿到这个块去执行对应工具然后把结果作为tool_result追加回对话{type:tool_result,tool_use_id:toolu_xxx,content:执行结果}。下一轮模型读到结果继续推理。这个循环就是 Agent 的全部秘密。Rules 的特殊之处在于它不走 tool_use。它是被动注入每次 API 调用前Claude Code 把 CLAUDE.md 和.claude/rules/*.md的内容格式化后通过prependUserContext()塞到messages最前面用system-reminder包裹role是user带isMeta: true。isMeta只是客户端 UI 标记消息仍完整发给 API只是终端不展示。注入时还会带一句强制指令头大意是以下指令覆盖默认行为必须严格遵守。所以 Rules 不需要模型主动调用模型在推理时自然看到。MCP 是 tool_use 最直接的应用。每个 MCP 工具通过toolToAPISchema()转成tools[]格式命名是mcp__serverName__toolName。模型输出tool_use后Claude Code 识别mcp__前缀路由到对应 MCP Client发 JSON-RPC 到 Server 进程拿到真实结果回填tool_result。这是名副其实的远程过程调用。Skills 最容易被误解。它注册了一个名为Skill的工具模型触发后Claude Code 读取本地SKILL.md文本包装成isMeta: true的 user 消息注入对话历史而tool_result只返回一句Launching skill: commit。真正的能力来自那段被注入的 Markdown 指令模型读到后按步骤调用 Read、Edit、Bash 等已有工具完成任务。所以 Skills 是提示词注入机制tool_use 只是触发器。三者对比可以这样记Rules 是每次自动注入的短文本MCP 是注册进 tools 并真实执行的外部函数Skills 是注册进 tools 但只注入文本的伪工具。它们的共同点是——最终都影响模型下一轮推理时能看到什么。这里有个关键推论既然 Skills 注入的就是一段 Markdown那你手动commit-rules.md引用一个同等内容的 Rules 文件模型看到的也是一段自然语言指令效果几乎一样。Skills 多绕的tool_use → 读文件 → 注入几步价值在于工程便利可发现、可分发、可 Fork 隔离而不是能力本身。这个结论后面验证环节会用日志坐实。3. 可复制配置把 Base URL 统一到 TaoToken多工具接入最烦的就是 Key 和 Base URL 满天飞。Claude Code、Cline、Codex 各一套改一个忘一个。我的做法是全部收敛到 TaoToken 一个 endpointKey 也只维护一份。下面给可直接复制的片段。先拿 Key。打开https://taotoken.net/api-keysdeep link 带归因?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite创建一个 Key复制备用。注意 API 根地址是https://taotoken.net/api不要加 UTM。Claude Code 的配置走~/.claude/settings.json把模型请求指向统一通道。可复制片段如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-5-20250929, ANTHROPIC_SMALL_FAST_MODEL: claude-haiku-4-5-20251001 }, permissions: { allow: [Bash(gh:*), Read, Edit], deny: [] } }如果你用 Cline 或 Roo Code 这类 VS Code 插件配置在插件的 settings 里三件套必须写全Base URL 填https://taotoken.net/apiAPI Key 填上面那个Model ID 填claude-sonnet-4-5-20250929。少任何一个都会在请求时炸。Codex 用户走~/.codex/auth.json同样三件套{ OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: sk-你的TaoTokenKey, model: gpt-5-codex }注意 Codex 的字段名和 Claude Code 不同别把ANTHROPIC_前缀抄过来。踩过的坑就是字段名混用报错却是 401看起来像 Key 错其实是变量名没被识别。MCP Server 的配置在~/.claude.jsonuser scope或项目根.mcp.jsonproject scope。一个最小 stdio 传输示例{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /Users/you/project] } } }Rules 不需要额外配置放在项目根CLAUDE.md或.claude/rules/*.md即可。条件规则用 frontmatter 的paths字段限定生效范围--- paths: - src/components/**/*.tsx - src/hooks/**/*.ts --- 在 React 组件中始终使用函数式组件和 hooks禁止 class 组件。Skill 放在.claude/skills/name/SKILL.md描述要精准因为 Skill 列表有严格 token 预算——只占上下文窗口的 1%默认 8000 字符每个描述最多 250 字符。描述模糊的 Skill模型大概率不会自动触发。配置改完先别急着跑复杂任务。下一步用一次最小 tool_use 验证通道是否真的通了。4. 验证请求一次 tool_use 触发看穿三者行为差异验证的目标不是能不能聊天而是tool_use 有没有真的走通、三者行为差异能不能在日志里看到。我建议分三步。第一步验证 Base URL 和 Key 通不通。在项目目录下启动 Claude Code输入一句会强制触发工具的话比如列出当前目录下所有 .md 文件并读取第一个。如果通道正常你会看到模型输出一个tool_usename是Bash或Read然后客户端执行并回填tool_result。这一步能过说明ANTHROPIC_BASE_URL和 Key 都对了。第二步验证 Rules 注入。在CLAUDE.md里写一条极显眼的规则比如所有回复开头必须加[RULES-OK]。重启会话后随便问一句如果回复带了这个前缀说明 Rules 通过prependUserContext()注入成功。注意 Rules 是每次调用自动注入不需要模型主动调用所以它生效与否和 tool_use 无关。第三步验证 Skills 和 MCP 的差异。给一个 Skill 写SKILL.md描述里明确触发条件同时配一个 MCP Server。然后输入一个同时可能命中两者的任务。观察日志MCP 工具触发后tool_result.content里是外部 Server 的真实输出比如文件列表、API 返回Skill 触发后tool_result只有一句Launching skill: xxx真正的指令文本以isMetauser 消息出现在下一轮messages里。这个差异是三者中最本质的——MCP 回传真实数据Skill 回传的是接下来该怎么做的文本。如果你想更直观可以在 TaoToken 的模型对话页https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite手动构造一次带 tools 的请求观察返回的tool_use块结构。这能帮你确认模型侧输出的 JSON 长什么样和客户端日志对照。验证通过后你会得到一个清晰结论Rules 影响的是模型看到什么规范MCP 影响的是模型能调什么真实函数Skills 影响的是模型被喂了什么流程文本。三者都在同一套 tool_use 协议和 messages 注入机制下工作区别只是信息位置。5. 常见报错排查401、local proxy failed、reading choices、OAuth配置统一通道后最容易撞的几类报错我按真实日志对照给你排。401 Unauthorized。最常见但原因不止一种。先确认 Key 有没有复制全有时尾部空格再确认 Base URL 是不是写成了https://taotoken.net/api/带尾斜杠某些客户端会拼出双斜杠导致鉴权失败最后确认字段名——Claude Code 用ANTHROPIC_AUTH_TOKENCodex 用OPENAI_API_KEY混用会 401。三件套Base URL Key Model ID缺任何一个都可能报 401别只盯着 Key。local proxy failed。这个报错通常出现在客户端尝试走本地代理但代理没起来或者环境变量里残留了HTTP_PROXY/HTTPS_PROXY指向一个不存在的端口。检查 shell 配置里有没有遗留的代理变量清掉后重启终端。注意这里说的是清理本地无效代理配置不是让你去配什么网络工具。reading choices 相关报错。多出现在 OpenAI 兼容格式的响应解析上典型是cannot read property choices of undefined。原因通常是 Base URL 指向了一个返回非标准 JSON 的 endpoint或者 Model ID 写错导致服务端返回错误结构。确认 Base URL 是https://taotoken.net/apiModel ID 用文档里列出的有效值。OAuth 相关报错。Claude Code 某些版本会尝试 OAuth 流程如果你已经用 Key 鉴权需要在 settings 里确保没有残留的 OAuth token 字段否则会优先走 OAuth 然后失败。清掉~/.claude/下的凭据缓存再重启。MCP 连不上。先看~/.claude.json里mcpServers的command路径对不对npx能不能在非交互环境跑。stdio 传输的 Server 如果启动就退出Claude Code 会标记为 disconnected此时它的工具不会出现在tools[]里模型自然调不到。用npx -y modelcontextprotocol/server-filesystem /tmp手动跑一次看有没有报错。Skill 不自动触发。这是最高频的假故障。源码里 Skill 列表 token 预算只有上下文 1%每个描述最多 250 字符模型判断是否触发依赖这点信息和whenToUse字段。描述写得模糊模型就不会自动调。解决办法是把触发条件写具体或者干脆让团队成员手动/skill-name调用——手动触发和自动触发最终注入的文本是一样的。排障时记住一个原则先确认通道Base URL Key Model再确认工具注册tools 里有没有最后确认触发模型有没有输出 tool_use。三层分开查比一股脑改配置高效得多。6. 收口把三者当同一套协议的不同入口走到这里你应该能自己回答开头那三个问题了。Rules 和 Skills 的区别没有想象中大因为 Skills 执行后注入的就是一段 Markdown和你手动一个 Rules 文件模型看到的都是messages里的一段 user 文本。真正的工程差异只有两点触发方式Rules 自动注入Skills 需模型判断后调 tool_use和执行隔离Skills 可配context: fork在独立上下文跑Rules 没有这层隔离。MCP 和内置 Tools 对模型来说也没区别tools[]里格式一样区别纯粹在客户端执行路由。MCP 的价值不在能调外部系统Bash 也能而在持久化连接、复杂操作原子封装、权限隔离这三个点。简单 CLI 操作直接让模型用 Bash别折腾 MCP。Skills 的标准化流程不是代码层面的流程化源码里没有任何 if-else 控制执行步骤所谓流程就是一段结构化的 Markdown靠模型的指令遵循能力跑。Skill 的质量等于提示词的质量换个弱模型流程可能就乱。实际落地建议项目级短规范用 Rules长指令、有明确触发时机、需要隔离的用 Skills需要持久连接或权限约束的用 MCP。别迷信 Skills 自动触发把核心 Skill 的快捷命令告诉团队比指望模型识别靠谱。最后给一个实用技巧把 Base URL 和 Key 统一到 TaoToken 后你可以在一个地方管理所有工具的接入改一次全生效。长期跑编码和 Agent 任务的话Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite比按量更省心接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite遇到字段名不确定时直接查比猜快。