Agent 基础设施演进：Tools、Skills 与 MCP 的工程边界

Wed, 01 Apr 2026 00:00:00 +0000

　　2025 到 2026 年的 Agent 开发历程，最显著的变化是底层基础设施从碎片化走向收敛。在早期，开发者通常直接使用模型厂商提供的 Function Calling 接口。这种模式导致了 M×N 的集成困境：如果系统接入了 M 个不同的大模型，同时需要使用 N 种外部能力，开发者就需要编写大量重复的胶水代码进行格式转换与适配。

　　随着 Agent 应用向深水区演进，系统需要解耦模型本身与外部执行逻辑，标准化协议与能力分层成为架构演进的必然结果。目前，现代 Agent 架构中主要沉淀了三个核心概念：Tools、Skills 与 MCP。厘清这三者的边界，是构建高可复用 Agent 系统的首要前提。

一、概念重塑：Tools、Skills 与 MCP 的边界

　　虽然这三个词语在日常交流中常被混用，但在工程实现上，它们处于完全不同的架构抽象层级。

1. Tools：原子执行单元

　　Tools 是系统中最底层的执行模块。它本质上是具体的代码函数，负责完成单一的、无状态的操作。

特征定义：Tools 只关心输入与输出，不包含任何复杂的业务决策机制。查询数据库、发送 HTTP 请求、读取本地文件均属于 Tools 的范畴。
设计原则：在设计 Tools 时，应当追求极致的单一职责与高内聚。一个合格的 Tool 应当具备明确的 Schema 定义，确保任何外部调用者都能准确识别其所需的参数列表与返回值格式。

2. Skills：场景化的业务编排

　　Skills 建立在 Tools 之上，是面向特定业务场景的能力封装。

特征定义：如果说 Tool 是“执行一条 SQL 语句”，那么 Skill 就是“分析上季度营收数据并生成报告”。Skill 内部通常组合了多个 Tools，并包含了特定的执行流控制、Prompt 模板或上下文状态管理。
价值体现：Skill 的核心价值在于降低大模型在复杂任务中的推理负担。将固定的业务逻辑下沉到 Skill 层执行，可以大幅减少 Token 消耗，并提高输出结果的确定性。

3. MCP：底层的标准化通信机制

　　MCP 全称 Model Context Protocol，它既不是工具也不是技能，而是一套标准化的通信规范。

核心作用：MCP 统一了 Agent 客户端与外部数据、工具服务端之间的双向交互协议。它规定了客户端应如何向服务端请求工具列表，以及服务端应如何将执行结果或上下文资源返回给客户端。
架构意义：引入 MCP 后，模型与工具之间实现了彻底的解耦。只要工具或技能封装为符合 MCP 规范的 Server，任何支持 MCP Client 的大模型或 Agent 框架都可以直接接入并使用，彻底消除了 M×N 的适配成本。

二、架构演进：从散装调用到标准协议

　　在现代的标准化架构下，一次完整的 Agent 任务执行链路呈现出清晰的分层特征。以下是基于 MCP 协议的系统协作架构图：

  sequenceDiagram
    participant LLM as Agent / LLM (MCP Client)
    participant Protocol as MCP 通信层
    participant Server as MCP Server
    participant Skill as Skill (业务编排)
    participant Tool as Tool (原子单元)
    participant API as 外部系统 (DB/API)

    LLM->>Protocol: 请求可用能力列表 (Discover)
    Protocol->>Server: 转发请求
    Server-->>Protocol: 返回 Skills 与 Tools 列表及 Schema
    Protocol-->>LLM: 同步给模型

    LLM->>Protocol: 决定调用特定 Skill (Call)
    Protocol->>Server: 传递 JSON 参数
    Server->>Skill: 触发业务流程
    Skill->>Tool: 按逻辑组合调用 Tool A
    Tool->>API: 执行底层交互 (如 SQL 查询)
    API-->>Tool: 返回原始数据
    Tool-->>Skill: 传递执行结果
    Skill->>Tool: 调用 Tool B (如数据清洗)
    Tool-->>Skill: 返回处理后数据
    Skill-->>Server: 汇总最终业务结果
    Server-->>Protocol: 按照 MCP 规范封装响应
    Protocol-->>LLM: 返回结果，供 LLM 继续推理

　　从上述链路可以看出，MCP Server 作为网关，屏蔽了后端所有复杂的业务实现。模型端（客户端）无需关心后端是简单的单体 Tool 还是复杂的串联 Skill，只需要按照统一的协议发送调用请求并等待标准响应即可。

三、实践思考

　　在实际开发中，理解概念只是第一步，更重要的是在工程实践中做出合理的选型。

1. 粒度划分：写 Tool 还是封装 Skill？

　　在系统构建初期，开发者容易倾向于把所有逻辑都写成巨大的单体 Tool，或者过度碎片化。合理的划分依据应基于“业务复用度”与“推理确定性”。

倾向于 Tool 的场景：当逻辑纯粹是数据获取或状态变更，且对各种上下文均适用时（如 send_email），应当保持其作为独立的 Tool。
倾向于 Skill 的场景：当某项任务需要固定的多步操作，且包含前置条件校验或数据中间态转换时（如 git_commit_and_push），应将其封装为 Skill。这不仅能减少大模型发生“幻觉”导致调用顺序错误的概率，也能提升系统的响应速度。

2. 接入 MCP 的工程折衷

引入成本：对于生命周期极短的单次脚本任务，强行引入 MCP 架构会增加不必要的网络通信开销与服务部署成本（如需要单独维护 MCP Server 进程）。
长期收益：但对于需要长期维护的个人知识库系统或跨应用调用的 Agent 矩阵，MCP 是不可或缺的基础设施。它保证了今天编写的业务能力，在明天切换底层大模型基座时，依然可以被无缝调用。

四、总结

　　从 2025 年到 2026 年初，Agent 技术栈完成了从“手写各类 API 适配器”到“基于标准协议构建基础设施”的蜕变。Tools 提供了手脚，Skills 沉淀了经验，而 MCP 则铺设了统一的轨道。理解并遵循这三者的架构边界，是我们在当下构建健壮、可扩展的 Agent 系统的必经之路。

人工智能 on Jiangwan's Blog