1. 从 Function Call 到 Skill工具调用链路到底变了什么如果你最近在折腾 AI Agent大概率会撞上同一个困惑昨天刚把 MCP Server 配好今天又看到满屏的 Skill标题还写着“MCP 已死”。先别急着删配置。Function Call、MCP、Skill 这三者不是简单的替代关系而是模型上下文协议在不同抽象层上的三次演进。Function Call 解决的是“模型能不能稳定输出结构化调用指令”MCP 解决的是“工具怎么用统一协议暴露给所有 Agent”Skill 解决的是“怎么用最低的上下文成本让 Agent 按需加载能力”。我试过把同一个“查询天气并写入本地文件”的任务分别用三种方式实现差异非常直观。Function Call 需要你在每次请求里塞完整的 tools schema模型每轮都要重新读一遍MCP 把这部分抽到独立 Server但选举时仍要把 Server 信息和工具 Schema 传进上下文Skill 则只传“技能名 一句话描述”内部执行流程根本不进 LLM 上下文。这就是“渐进式信息披露”的实际含义——不是功能变少了而是上下文占用被压到了最低。这篇文章面向正在用 Cline、Claude Code 或类似 Agent 做工具集成的开发者。你会拿到可复制的 settings.json 片段、Skill 触发验证方法、MCP 连接状态排查动作以及一个明确的判断标准什么时候该用 Skill什么时候必须保留 MCP。全程以 TaoToken 作为模型接入层来演示因为它的 API 兼容 OpenAI 与 Anthropic 两种协议方便你在同一套配置里对比两种调用方式。2. TaoToken 前置把模型接入层先跑通在对比 Skill 和 MCP 之前得先有一个能稳定调用的模型端点。TaoToken 在这里的角色是模型接入层它同时提供 OpenAI 兼容接口和 Anthropic 兼容接口这意味着你可以在 Cline 里用一套 API Key 切换不同模型来测试 Skill 触发效果。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。你需要先拿到 API Key。进入控制台后创建密钥建议按用途分多个 Key比如一个专门给 Cline 用一个给 Claude Code 用方便排查问题时隔离变量。创建入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 密钥管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。拿到 Key 之后先别急着配 Agent用一条 curl 确认端点通不通。curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 只回复 ok}], max_tokens: 16 }返回里能看到 choices[0].message.content 为 ok说明接入层没问题。这一步很关键因为后面 Skill 触发失败时你要能快速判断是模型端点的问题还是 Skill 配置的问题。如果你更习惯用 Anthropic 原生协议把路径换成 /api/v1/messages请求体结构按 Anthropic 格式写即可TaoToken 两种协议都兼容。注意API Key 不要写进会提交到 Git 的配置文件里。Cline 的 settings.json 支持环境变量引用后面会给具体写法。3. 可复制配置Cline 的 Skill 与 MCP 骨架Cline 的配置分两层全局 settings.json 管模型接入工作区内的 .cline 目录管 Skill 和 MCP Server 声明。先看全局配置里怎么接 TaoToken。{ cline.apiProvider: openai, cline.openAiBaseUrl: https://taotoken.net/api/v1, cline.openAiApiKey: ${env:TAOTOKEN_API_KEY}, cline.model: claude-sonnet-4-20250514, cline.enableSkills: true, cline.skillDirectories: [ ./.cline/skills, ~/.cline/skills ] }这里 enableSkills 打开后Cline 会扫描 skillDirectories 下的 SKILL.md 文件。一个最小 Skill 的结构是这样的--- name: weather-writer description: 查询指定城市天气并写入本地文件当用户提到天气保存时触发 --- ## 步骤 1. 调用 scripts/fetch_weather.sh 获取天气 JSON 2. 解析 temperature 和 condition 字段 3. 追加写入 ./weather-log.md注意 description 里必须写清楚触发条件这是 Skill 选举的唯一依据。模型只看这一句话来决定要不要加载这个 Skill所以“当用户提到天气保存时触发”比“天气相关”有效得多。MCP 的配置则放在 .cline/mcp.json 或 settings.json 的 mcpServers 字段里{ mcpServers: { filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, ./workspace], env: {} } } }对比一下就很清楚MCP 需要启动一个独立进程Agent 通过 JSON-RPC 和它通信Skill 只是一份 Markdown 加可选脚本没有常驻进程。这就是为什么 Skill 的维护成本低——Server 挂了 Agent 就失去能力而 Skill 文件读不到最多是少一个技能不会拖垮整条链路。如果你用的是 Claude Code配置思路类似但文件位置不同。Claude Code 的 Skill 放在 ~/.claude/skills/ 下MCP 配置在 ~/.claude.json 的 mcpServers 字段。想快速体验 Skill 触发效果可以直接用模型对话页测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 把 Skill 的 description 贴进去问模型“这个任务你会触发哪个技能”能提前验证描述是否够明确。4. 验证请求Skill 触发与 MCP 连接状态怎么查配完之后必须验证否则你永远不知道模型是真的调用了 Skill还是自己编了一个答案。Skill 触发的验证方法是看 Agent 的思考日志里有没有出现 Skill 名称。在 Cline 里发起一个明确匹配 description 的请求比如“查一下杭州天气并保存到文件”然后观察输出面板。成功的标志有三个日志里出现Loading skill: weather-writer脚本被执行且返回了 JSON目标文件被追加写入。如果只看到模型直接回答天气而没有加载 Skill说明 description 的触发词不够具体或者 enableSkills 没生效。MCP 连接状态的排查更直接。在 Cline 里执行 MCP 面板的 refresh或者用命令行手动测echo {jsonrpc:2.0,id:1,method:tools/list,params:{}} \ | npx -y modelcontextprotocol/server-filesystem ./workspace正常返回会列出该 Server 暴露的所有工具。如果卡住不动通常是 npx 首次下载依赖太慢或者路径参数不存在。如果返回 error检查 command 和 args 是否写错尤其是 Windows 下 npx 需要写成 npx.cmd。还有一个容易忽略的点MCP Server 的工具 Schema 会占用上下文。你可以在 TaoToken 的请求日志里看到每次调用的 token 消耗对比开启 MCP 和只用 Skill 时的差异。实测下来同一个文件操作任务MCP 方式的输入 token 通常是 Skill 方式的 3 到 5 倍因为每次选举都要传完整 Schema。5. 本篇常见错排查Skill 不触发模型直接自己回答。九成是 description 写得太泛。把“处理文件”改成“当用户要求读取、写入或追加本地 Markdown 文件时触发”触发率会明显上升。另一个原因是 skillDirectories 路径写成了相对路径但工作区不对改成绝对路径先验证。MCP 连接超时或反复重连。先确认 Server 进程能不能独立跑起来。把 mcp.json 里的 command 和 args 复制到终端手动执行能跑通再放回配置。如果手动能跑但 Agent 里不行检查 env 字段是否漏了必要的环境变量很多 Server 依赖 PATH 或特定 token。Skill 和 MCP 同时开启时上下文爆炸。这是最常见的组合坑。MCP 的 Schema 是常驻上下文的Skill 是按需加载的。如果你挂了五个 MCP Server每轮对话都要带上所有工具定义token 消耗会非常快。建议只保留必须常驻的 MCP Server其余能力封装成 Skill。模型返回的调用格式不对。如果你用的是 OpenAI 兼容协议但模型实际是 Claude偶尔会出现 function call 格式和预期不符。这时候切到 Anthropic 原生协议路径 /api/v1/messages 通常能解决。TaoToken 两种协议都支持切换成本很低。Skill 脚本没有执行权限。Linux 和 macOS 下 scripts 目录里的 .sh 文件需要 chmod x否则 Agent 调用时会静默失败。Windows 下建议用 .bat 或直接让 Skill 描述里写清楚用 python 执行。6. 什么时候用 Skill什么时候留 MCP判断标准其实就一条这个能力需不需要和外部服务保持实时规范同步。线上服务的 API 规范、数据库 Schema、第三方平台的接口定义这些会变的东西最优方式仍然是 MCP因为 Server 端更新后所有 Agent 自动拿到最新规范。如果你把这些写死在 Skill 里版本一更新就对不上。反过来多步业务流程、本地文件操作、固定的脚本调用链这些逻辑稳定、不需要外部同步的能力封装成 Skill 更划算。Token 省、没有常驻进程、跨 Agent 可移植。Skill 没有统一标准协议但不同 Agent 通常能识别彼此的 SKILL.md 格式这就是“一次封装多端复用”的实际含义。如果你正在做长期编码或 Agent 工作流建议把稳定能力逐步从 MCP 迁移到 Skill只保留必须实时同步的 MCP Server。想系统性地跑这套组合可以看下 Coding Plan 的配置方式https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它把模型接入和 Agent 配置的流程串起来了。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各协议的完整参数说明。Claude Code 相关的 Anthropic 协议配置参考 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite 。最后留一个实操建议先把一个最常用的 MCP 能力改写成 Skill跑一周对比 token 消耗和触发成功率。数据会告诉你答案比任何“淘汰论”都靠谱。