MCP 与 Skill 的边界与成本

MCP 用于动态能力发现和跨客户端生态，稳定副作用用类型化服务工具；Skill 不是文档，安装它会改变未来任务的操作规程。

MCP 用于动态能力发现和跨客户端生态，稳定业务操作和副作用应该用类型化服务工具。Skill 不是文档——安装一个 Skill 会改变未来所有匹配任务的操作规程，它的风险等级接近引入一个依赖，而不是收藏一篇文章。

MCP 解决的是发现，不是调用

适用：跨进程或跨语言复用工具、接入第三方工具生态、多个 Agent Host 共用同一套能力、需要标准化的资源与提示发现。

该避免的场景同样清楚：同一进程里的普通函数、只服务一个项目的内部业务逻辑、低延迟核心路径、无法建立清晰授权边界的高风险操作。稳定业务操作和副作用用类型化服务工具；批量、可重跑、CI、编译、测试、迁移、健康检查用 CLI 和脚本。

判断标准只有一句：你要的是「运行时动态发现未知能力」，还是「可靠地执行一次已知操作」。前者是 MCP，后者不是。

MCP 的安全基线没有可选项

HTTP MCP 走规范授权流程并做 token audience 校验；禁止 token passthrough，禁止把 token 放进 URL；全程 HTTPS；本地 MCP 安装要显示完整命令并拿到明确同意；每个 MCP Server 是独立信任域；按 Skill 或任务按需连接，不默认连接所有 Server。

「每个 Server 是独立信任域」最常被忽略。接了三个 MCP Server，等于把三段外部代码拉进你的信任边界，其中任何一个被攻破或行为异常，影响范围就是你给它的全部权限。本地安装那条同理——用户看到的是一行友好描述，实际执行的是一条完整命令。

MCP 的成本是常驻的

工具成本不只是执行，它包括 Schema 常驻 token、选择推理、参数构造、执行、结果注入，以及后续历史里反复携带。接满 Server 之后，光是 Schema 就能吃掉一大截窗口。

这个「一大截」有量级可查：仅仅 5 个 MCP Server 就可能引入数万 token 的工具定义，在 200K 窗口里还没开始对话就用掉近三成。Cursor 的缓解做法是把工具描述同步到本地文件夹，Agent 默认只看一份名称索引，需要时再查具体定义——A/B 测试显示，MCP 相关任务的总 token 消耗因此减少 46.9% ai-agent-book。

形态和数量是两个独立决策，别把它们混成一个。一条能力做成专用工具还是 Skill，决定的是每条常驻多少 token、参数怎么传、谁能改；一次把多少条摆在模型面前，是披露策略 ai-agent-book。两边的定价差得很远：接一个 MCP Server 是在运行时建连，它暴露的全部工具定义进入每一次会话的上下文；装一个 Skill 只是往磁盘拷一个文件夹，常驻的只有目录里的 name 和 description，便宜一到两个数量级。也正因为便宜，「全量常驻 Skill 目录」的可行边界比工具远得多——但那只放宽了披露这一侧，没有替你做出披露策略的选择。

所以必须为每个 Agent 设 Server 和工具白名单，统计每个 Schema 和结果的 token，把大结果存进 Artifact Store，绝不把所有已连接的 MCP 工具默认暴露给所有 Agent。反过来也成立：不能以成本为理由绕过权限、确认和审计要求。

Skill 是供应链，不是文档

供应链有四个阶段，各自需要独立的权限与审计：发现、安装、激活、执行。生产级 Skill 要有固定版本与 digest、明确的 owner、兼容矩阵、可执行脚本的审查签名、trigger eval 和回滚方案。

少任何一项，你都无法回答「线上这次行为变化是哪个 Skill 的哪个版本引起的」。

还有一层风险不在供应链而在语义：Skill 的本质是把外部内容当作指令加载的制度化形式。网页里的隐藏文本至少还要骗过一轮摘要，Skill 的内容是直接按指令生效的——第三方 Skill 里藏一条恶意指令，比藏在网页里有效得多。所以来源不明的 Skill 在安装前必须逐行读它的正文和脚本，像审查一段将要执行的代码那样审查它 ai-agent-book。

渐进式加载，以及什么值得做成 Skill

加载分三步：初始只加载名称和描述；任务匹配后加载完整 SKILL.md；需要时再读 references、scripts 和 assets。描述必须写清何时触发、何时不触发，并且要测误触发和漏触发。

写法上要把 description 当路由条件，不要当功能介绍——「何时该用我」比「我能做什么」重要得多。写成 "help with backend" 这类宽泛措辞，等于任何后端工作都能触发，路由必然失准；书里的建议是在描述里明确写出使用与不使用的边界，并附几条典型反例来压误触发 ai-agent-book。

规模是这套机制的硬约束：Skill 描述常驻 system prompt 的数量一多，即使前沿模型的质量也会开始退化，所以选择必须在加载之前发生，而不是把所有 Skill 平铺进去再让模型自己挑 langchain-stripe。

腾讯云用一个 Skill 撑起 C++ 到 tRPC-Go 的全量重构，是这套分层的完整样本：无注释的历史补丁、10 多个状态机分支散落在跨 4–5 个项目的调用链里，可以信的只有代码本身。他们把知识压成三层——Rule 限 100 行（编辑指定目录时自动注入规范）、SKILL.md 限 200 行（只写五阶段流程）、references 不限行数按阶段按需加载；把只有业务经验能定的取舍整理成选择题，每轮最多问 5 个，决定记进 clarifications.md 跨会话可还原；再加熔断阈值——同一错误连修 3 次不过就交人，测试自动修复循环最多 5 轮。结果是把依赖历史经验、动辄几天的重构变成可复现的流程 tencent-skill-refactor。

价值分层也由此清楚：通用公开技巧迟早被模型权重吸收，围绕它做的 Skill 贡献会退化到零。长期价值在 procedure、当前信息源、工具、策略、校验器、恢复路径和出处——需要持续更新、有组织归属或真实权限的 Skill 才是资产。

Skill 的四层验证

• 对照实验：没有这个 Skill，模型也会做——那它的贡献是零
• 难度校准：太简单测不出差异，太难则两边都失败
• 轨迹追踪：Skill 在上下文里，但模型真的 follow 了吗
• 路径验证：结果正确，但有没有绕过关键校验步骤

后两层最容易被跳过，也最容易骗人。只看最终结果，会把「模型本来就做得对」记成「Skill 起作用了」。