大模型通识 / 大模型技术演进

21. 模型、工具与任务能力怎样连接起来

本篇目录 · 7 节

来源：大模型技术演进

2024 年 11 月 25 日，Anthropic 发布 Model Context Protocol，简称 MCP。与一次新模型发布不同，这次公告的主角是一种连接标准：它希望让 AI 助手更方便地接触代码仓库、数据库和业务资料。首批配套包括协议、开发工具，以及 Claude Desktop 对本地 MCP 服务的支持。原始公告

这个变化回应了一个越来越明显的落差。聊天窗口里的模型已经能解释复杂代码、分析长篇材料，可一旦用户问“我的项目为什么构建失败”“根据我最近的笔记安排复习”，它需要的资料仍然散落在窗口之外。人得找到文件、复制内容、解释背景，有时还要把模型的建议重新搬回软件执行。

模型越来越会处理任务，应用却还在为“怎样把现场交给它”重复搭桥。MCP 把这个问题推到了行业面前：如果每个助手接每个系统，都重新写一套适配，Agent 的能力就很难随着工具生态一起增长。

后来出现的 A2A、Agent Skills，以及持续演进的插件和连接器，又进一步扩大了讨论范围。我们要连接的，既有可执行的操作，也有独立运行的 Agent，还有完成任务所需的方法和材料。

上一篇讨论框架怎样组织程序。这一篇继续向外看：程序怎样拿到外部能力，又怎样把这些能力交给模型使用？观察截止日期仍为 2026 年 10 月 3 日，以下会区分历史发布节点与后来形成的机制。

从 Function Calling 开始：模型怎样提出一个操作

先回到 2023 年。6 月 13 日，OpenAI 为当时的部分 GPT-4、GPT-3.5 Turbo 模型发布函数调用能力。开发者可以描述函数，模型则根据对话生成相应的调用参数。这是模型 API 走向工具使用的一个重要产品节点，并不意味着此前的研究和应用从未尝试过调用工具。发布说明

第 4 篇已经介绍过它的历史意义。这里需要记住的，是模型与程序之间的分工。

假设我们给复习助手提供一个“搜索笔记”的函数。下面是教学构造的调用示意，不是可以直接复制运行的 API 请求：

用户：找出我关于梯度下降的笔记。
模型提出：search_notes(query="梯度下降")
应用执行搜索，返回匹配的笔记片段。
模型依据返回内容，回答用户或继续请求其他操作。

模型生成调用请求时，搜索还没有发生。对于这种自定义函数，通常由应用执行操作，再把结果交给模型；模型收到结果以后，可以继续回答，也可以提出下一次调用。厂商托管的工具可能由厂商平台执行，不能把所有工具都理解为需要开发者在本地运行。函数调用流程

这解释了两个常见误解。第一，模型输出了一个漂亮的调用参数，不等于任务已经完成。第二，参数格式合法，也不等于业务含义正确：它可能搜错关键词，也可能把应当读取的笔记误当成应当删除的笔记。

Function Calling 建立的是一种协作方式：模型用结构化请求表达操作意图，程序执行具体动作并返回结果。 工具背后可以是本地函数、数据库查询、网页服务，也可以是另一个系统提供的能力。

接下来的问题是：这些工具应该怎样接进来，才能被不同应用复用？

MCP：让外部能力不必为每个助手重新接一次

设想你维护一个笔记服务，希望它同时供桌面助手、代码编辑器和自己的网页应用使用。如果三种应用各有一套接入格式，你就要分别处理工具描述、请求和返回约定。笔记服务增加一个功能时，几套适配也可能一起修改。

MCP 试图减少这部分重复劳动。支持协议的应用与提供能力的服务，按照共同约定交换信息。实际接入仍然需要认证、配置和必要的适配，但双方不必从零协商所有通信细节。

理解 MCP，先分清三个角色。Host 是用户正在使用的 AI 应用；Client 是应用中负责连接服务的组件；Server 是向外提供能力的程序。 这里的 Server 不一定是一台远程机器，也可以是你电脑上的进程。MCP 架构说明

协议里的能力也不只有“执行一个函数”。常见的三类是：

MCP 提供的内容	可以怎样理解	复习助手中的教学示例
Tools，工具	可以请求执行的操作	按关键词搜索笔记
Resources，资源	可供应用读取的内容	某一篇笔记的正文
Prompts，提示模板	可复用的交互或任务模板	根据选定笔记发起一次复习

这些类别来自 MCP 的协议设计；具体服务提供哪些内容、应用支持哪些交互，要看实现。连接成功不会自动让每个功能都出现在用户界面上。MCP 的能力分类

把它与前面的函数调用连起来，流程就清楚了：应用从 MCP 服务获知可用工具，把适合当前任务的工具信息交给模型；模型提出工具调用，应用通过 MCP 请求相应服务执行，再把结果送回模型。模型通常不是自己打开网络连接去操作 MCP 服务。工具发现与调用约定

因此，MCP 与 Function Calling 可以同时出现。前者帮助应用接入外部能力，后者帮助模型表达想使用哪项能力。一个笔记搜索接口可以先是普通 HTTP API，外面再加一层 MCP 服务；这层封装不会重新训练模型，也不会凭空改善底层搜索质量。

2025 年 12 月，Anthropic 宣布将 MCP 捐赠给 Linux Foundation 旗下新设立的 Agentic AI Foundation。这为协议的跨厂商发展提供了新的治理安排，但不意味着所有产品已经实现完全一致的兼容性。治理变化公告

它的产业意义可以这样理解：应用开始有机会共享一部分接入成果。一个服务获得多个助手支持的成本有望降低，个人开发者也更容易利用现成集成，把精力放回自己的应用。

A2A：当你需要交接的是一项任务

工具接入解决了一类问题，却不是全部。

假设复习助手遇到一份扫描讲义。你已经有一个独立运行的资料处理 Agent：它会识别页面、检查段落顺序、发现缺页时提问，最后交回整理后的材料。此时你希望表达的是“请把这份讲义整理好，并告诉我进度”，而不只是调用一次识别文字的函数。

2025 年 4 月 9 日，Google 发布 Agent2Agent，简称 A2A，面向不同厂商和框架构建的 Agent 之间的通信与协作。发布公告

它需要让请求方理解几个问题：对方能做什么，怎样提交请求，任务是否还在运行，是否缺少输入，最后交付什么。A2A 中的 Agent Card 用来描述对方的能力与接入信息；需要持续跟踪的工作可以表示为 Task；完成过程中产生的文档、结构化数据等成果可以表示为 Artifact。简单交互也可以直接返回消息，不必每次都建立长期任务。A2A 核心概念

这里的关键是交接边界。复习助手不必知道资料处理 Agent 内部用了哪个模型、调用了几次识别服务，或者怎样安排步骤。它关心的是约定好的输入、状态与交付物。

这与上一篇的多 Agent 框架也有区别。你在一个程序里创建“规划者”和“执行者”，让它们通过框架交换数据，并不必然需要 A2A。只有当独立系统之间确实需要一种共同的交接约定时，这类协议才会直接回应你的问题。

也不宜把区别简化成“MCP 只能处理短调用，A2A 才能处理长任务”。协议会继续发展，MCP 的现行架构也包含任务扩展。更稳妥的判断是：当前主要在接入可使用的工具和资料，还是在与一个独立承担工作的 Agent 协作？ 两者可以组合，能力范围也会有交集。MCP 当前架构与扩展

Skills：有工具之后，还需要知道怎样完成工作

现在，复习助手能搜索笔记，也能请求其他系统处理资料了。但它仍可能把卡片写得太长，一张卡片塞入五个问题，或者把原文中的猜测写成确定答案。

这些问题并不都需要一个新接口。你可能已经知道正确做法，只是每次都要重新告诉助手：一张卡片只检验一个知识点；答案必须能回到原文；概念解释与练习题分开；保存前检查重复。

2025 年 10 月 16 日，Anthropic 介绍 Agent Skills，把指令、脚本和资源组织成可以按需发现与加载的文件夹；12 月 18 日，该文章更新说明其已作为开放标准发布，面向跨平台移植。Agent Skills 原始介绍及更新

一个 Skill 以 SKILL.md 为核心，声明名称、用途并提供操作指导，还可以配有参考资料、脚本和模板。支持这一机制的 Agent 可以先了解有哪些技能，任务匹配后再读取详细说明，必要时继续加载配套材料。这种按需展开的方式，避免一开始就把所有技能全文塞进上下文。Agent Skills 说明

我们可以给复习助手设计一个制卡 Skill。下面只是教学设计，不是已经测试过的技能包：

make-study-cards/
├── SKILL.md                 # 何时使用、怎样制卡、怎样检查
├── references/examples.md  # 好卡片与坏卡片的示例
└── scripts/check_cards.py  # 检查字段、重复项等确定性问题

指导文字负责说明取舍，示例帮助模型理解要求，脚本则适合处理字段是否缺失等确定性检查。模型仍需根据笔记内容生成合适的问题，不能只靠一个格式检查脚本证明卡片有教学价值。

这也说明 Skill 的作用与模型微调不同。修改指导文件，是给运行中的 Agent 提供方法和材料；它没有因此修改模型参数。Skill 可以教 Agent 使用 MCP 工具，也可以让它调用普通命令行程序，不以 MCP 为必需前提。

开放格式有利于复用，但一个 Skill 换个产品就能正常运行，还取决于所需工具、脚本环境和权限。Agent Skills 规范专门允许声明环境兼容要求；文件格式相同，不代表执行环境相同。Agent Skills 规范

还有一个容易混淆的同名概念：A2A 的 Agent Card 也可以声明 skills，用来描述远程 Agent 的能力。这不意味着它里面存放的就是上述 SKILL.md 技能包。判断含义需要看所在协议和产品，不能只看一个英文单词。Agent Card 的能力描述

插件与连接器：把能力变成用户可以安装和配置的东西

如果你觉得这些概念仍然很多，可以从普通用户的操作入口再看一遍。

用户往往不会先问“我要哪一种协议”，而是问“怎样让助手连接我的笔记”“这个扩展装上之后能做什么”。插件和连接器通常出现在这一层，但它们没有跨所有产品统一的含义。

以 Claude Desktop 为例，Anthropic 在 2025 年 6 月介绍桌面扩展，希望把本地 MCP 服务及相关配置打包，让安装更简单；文章在同年 9 月注明，原来的 .dxt 格式更名为 .mcpb。这说明扩展包可以承担 MCP 能力的分发工作，并不是另一种模型能力。桌面扩展公告及更名说明

Claude Code 的插件又可以组合 Skills、Agent 定义、事件处理以及 MCP 服务等组件。因此，“安装一个插件”有时是安装一组配套能力，不能据此断定底层只有一种机制。IDE 插件则首先是一种编辑器扩展形式，也不等于这里的 Agent 插件。Claude Code 插件文档

连接器通常强调与某个外部服务的集成，例如连接云盘、邮箱或日历。它可能通过 MCP 实现，也可能采用产品自己的接口。不同平台的“连接器”不能直接互换：OpenAI 的相关文档就分别介绍远程 MCP 服务和内置连接器，并对部分连接器接口规定了适用范围。MCP 与连接器文档

第 4 篇讲过的早期 ChatGPT 插件，也要放回当时的产品机制理解。不能因为今天又看到“插件市场”，就认为它与 2023 年的 ChatGPT 插件是同一套接口。

对读者真正有帮助的，是继续追问具体动作：这个扩展提供搜索还是写入？在哪里执行？需要哪个账号？读取结果会交给哪个模型处理？即使 MCP 服务运行在本机，它返回的资料仍可能进入云端模型请求，“本地运行一个连接程序”不等于“所有数据处理都留在本地”。

放到同一个项目里，它们怎样配合

下面把前面的教学设计合起来。用户提出：“根据我本周的笔记，生成一组能追溯原文的复习卡片，先让我检查。”

助手可以先加载制卡 Skill，理解卡片要求；通过已经配置好的笔记集成，获得搜索工具；模型提出搜索请求，应用调用工具取回笔记；接着生成卡片并执行格式检查，最后把草稿交给用户。

如果其中的扫描材料确实需要另一个独立 Agent 处理，才增加 A2A 任务交接。若普通文字提取函数就足够，没有必要为了使用协议而增加一个 Agent。

把各层放在一起，区别就更容易看清。这是理解职责的对照表，不是必须全部采用的架构清单。

名称	主要回答的问题	在这个示例中的位置
Function Calling	模型怎样表达调用什么、传什么参数？	提出搜索笔记等操作请求
MCP	应用怎样按共同约定接入外部能力？	连接笔记服务并使用其工具、资源
A2A	独立 Agent 怎样交接任务与成果？	可选的资料处理任务交接
Agent Skills	完成这类工作应遵循什么方法？	制卡规则、示例与检查脚本
插件	怎样把配套能力安装和分发给用户？	打包相关技能、服务配置等内容
连接器	怎样把特定外部服务接进产品？	笔记账号与服务的集成入口

同一个产品可以占据表里的多个位置，同一个项目也可以只使用其中几层。哪怕你直接写一个函数读取本地 Markdown，再调用模型生成卡片，只要需求得到满足，就是一个合理的起点。

可以用一个问题检查自己是否理解了这些概念：如果助手能读取笔记，却总是生成不符合要求的卡片，换成 MCP 能自动解决吗？通常不能。接入已经成功，接下来应检查任务说明、模型表现和结果验证。反过来，制卡方法写得再好，如果没有读取笔记的工具与权限，Skill 也不能把缺失的资料变出来。

接通之后，新的瓶颈才显现出来

从 2023 年的函数调用，到 2024 年的 MCP，再到 2025 年的 A2A 和 Agent Skills，这条线并不是新名词依次淘汰旧名词。它体现的是应用边界不断向外扩展：模型开始参与操作选择，应用需要共享外部集成，独立 Agent 需要交接任务，成功经验又需要被重复使用。

连接标准与可复用材料有望减少重复开发，但运行成本不会因此消失。工具描述、返回的笔记和加载的指导都可能占用上下文；多次调用增加等待，额外的 Agent 也可能增加模型请求。对一个个人项目，最有价值的往往是恰好够用的连接。

而且，“能连上”“有权限”“做对了”是三件不同的事。服务可以正常返回错误资料，Agent 可以误解任务，技能里的方法也可能不适合当前案例。系统接得越多，越需要知道结果从哪里来、在哪一步产生偏差，以及什么时候该停止或请人查看。

下一篇会把焦点从连接转向工程保障：当模型、资料与工具都已到位，怎样通过上下文管理、评测、追踪、沙箱和执行循环，让一次成功演示变成可以持续使用的应用。

上一篇：20｜应用变复杂之后，开发框架怎样演进

下一篇：22｜更强的模型为什么仍然需要工程保障

返回：第 0 部分大纲