Tool Calling、MCP 与 Skills：接口、协议和操作手册分别解决什么

“Tool Calling 就是 RPC，MCP 就是 Swagger，Skill 就是提示词。”这些类比让陌生概念容易上手，却把三个不同层次挤进了同一个结论。更有效的拆解，是跟随故障助手的一次真实业务意图：它想读取日志，依据调查规程分析，再提出工单。

Tool Calling：谁决定调用，谁实际执行

本篇已经改编为《Tool Calling 就是 RPC 吗？》图文与录屏成品，包含 8 张卡片、发布文案、完整口播和可操作演示。

假设模型返回如下教学结构：

json

{
  "action": "read_logs",
  "arguments": {
    "service": "orders",
    "window_minutes": 30
  }
}

模型在这里生成调用意图。应用解析、校验和授权之后，才调用本地函数或远端服务，最后把结果交回模型。工具可能根本没有跨进程，所以把所有工具调用都叫 RPC 并不准确。

执行端大量复用旧经验：输入模式、错误码、超时、幂等、访问控制、版本兼容。新增问题集中在调用方：开发者没有直接写死这次调用，模型可能选错工具、误解参数、漏掉前提，甚至根据不可信资料提出动作。

因此接口文档同时面向程序和模型。参数能通过类型检查，只说明结构可执行；window_minutes=30 对用户的故障是否合适，需要任务语义。把模型放在调用方，没有撤销服务端检查的理由。

MCP 的架构包括宿主、客户端与服务器，使用 JSON-RPC 组织消息，并定义工具、资源、提示等能力的交换方式。本文参考访问时解析到的 2026-07-28 架构文档；不同版本的发现、传输和会话细节应按所用实现核对。官方架构说明

它与 API 描述、插件协议、适配层有可比较之处，但不仅是一份接口字段清单。协议还约定通信行为和能力表达，使不同宿主与能力提供方减少重复对接工作。

这种互操作价值可以独立成立：一个系统没有动态规划，也可以受益于统一接入。反过来，接入了很多 MCP 服务，也不代表模型会正确选择它们，或获得了跨系统业务事务。

用一句话划边界：协议规定能力怎样被发现和调用，应用决定当前任务能调用什么、何时调用以及怎样解释结果。

Agent Skills 官方说明将 skill 组织为指令和资源，可包含脚本；常见使用方式是先根据描述识别相关技能，再加载详细内容。它更接近按需提供给 Agent 的操作手册与资源包。

例如“故障调查规程”可以要求先核对服务版本，再查询日志，并附错误码表和格式检查脚本。这里既有自然语言步骤，也可能有确定性代码，不能只看见 SKILL.md 就忽略资源与脚本。

但“写进了规程”与“执行器强制保证”仍不同。规程要求不要读取其他租户，不能代替服务端租户校验；规程说必须先确认，也不能自动创建有效授权。强约束应由运行系统维护，模型遵循规程的效果需要另行评测。

同样，加载一份 skill 不等于训练模型权重，也不意味着安装了任意环境中的执行依赖。宿主如何发现、装载、调用脚本，以及环境是否具备依赖，仍是具体实现责任。

层次	在故障助手中做什么	与后端最接近的东西	不提供的保证
调用意图	选择读取日志并生成参数	命令对象、接口调用方	参数含义必然正确
连接协议	将读取请求送到能力服务	RPC、适配协议、插件接口	业务授权和最终一致性自动成立
操作规程	告诉助手怎样组织调查	Runbook、工作说明、资源包	每项文字要求都被强制执行

设规程要求查最近三十分钟，但模型传入三十天。MCP 可以准确传输这次错误请求，日志服务也可能合法返回数据。三个组件各自“正常”，任务仍然错。需要在任务契约与参数校验之间建立连接，不能把正确性寄托在某一个名字上。

只有少数本地工具时，直接函数适配可能更清楚。多个宿主复用同一能力时，标准协议的维护收益更容易体现。重复出现的领域任务需要共享资料和步骤时，规程包可以降低散落提示的维护成本。

判断依据是减少了哪种重复、明确了哪种契约，以及增加了什么部署和调试成本。不能因为一个框架同时支持这些名词，就认定项目必须全部采用。

本篇判断：工具执行高度复用接口工程；MCP 是互操作协议层的具体工作；Skills 是知识与操作规程的组织方式。模型理解接口和规程的语义效果，是三者接入后仍需解决的问题。