玩命加载中...

从 ChatGPT 到 MCP、A2A

本文首发于微信公众号：呼哧好大枫。原作者与本文作者是同一人。

摘要：

本文从比较浅显的角度介绍了当前主流的利用 AI 大模型解决复杂问题的几种技术方案，包括工作流、Function Call、Agent 和最近新出现的 MCP 协议与 A2A 协议。列举了几种实现方案的原理与优劣点，不涉及到具体的代码实现和实际应用。旨在从一个较为宏观的角度理解近几年人们为了将 AI 大模型应用于复杂任务所做的努力和取得的成就。

本文适合那些对 AI 应用开发领域了解不多的用户阅读。通过对比不同方案的设计哲学与适用场景，帮助他们对相关技术方案有一个大致的了解，以在实际应用开发中选择最适合自己的方案。

技术背景

自从 2022 年 OpenAI 推出 ChatGPT，市场上不仅涌现出各类通用基础大模型，还出现了大量经过领域适配优化的垂直行业模型。与此同时，将大模型与传统软件系统深度融合的技术探索日益活跃，这种融合为各类软件应用注入了智能化的新动能。然而在技术实践中，开发者主要面临以下挑战：
  1. 大模型本身存在认知边界。其能学习到的知识被限制在训练数据集之中，比如训练数据集中的数据截取自 2024 年以前，那么大模型难以结合 2024 年之后发生的事情回答用户的请求，有时甚至会因此引发严重的错误；
  2. 大模型能执行的任务单一，难以支持复杂任务。虽然大模型能出色完成简单问答（如"秦始皇兵马俑的历史背景"），但在处理多模态、多步骤的复杂任务时仍显不足。例如用户请求："下周我准备前往西安市参观秦始皇兵马俑，请你根据下周的天气推荐最适合到达西安的时间，并根据我的预算（1500 元）安排届时的行程"，该任务需要实时调用天气API、整合本地生活服务数据（美团/大众点评）、路径规划（高德地图）等外部系统能力，这些均超出传统大模型的固有功能范畴。

为突破这些限制，业界提出了若干创新解决方案：通过工作流引擎实现任务拆解、采用RAG（检索增强生成）更新知识库、利用 Function Calling 对接外部服务、构建智能体（Agent）系统进行任务编排等。这些技术的综合应用有效弥合了大模型的能力鸿沟，使得终端用户几乎感知不到底层技术限制。

值得注意的是，当前大模型百花齐放式的增长使得各厂商的模型接口、提示词工程范式、智能体框架存在显著差异。开发者对接不同服务商时需要进行复杂的 API 适配和参数调优，这种碎片化现状正在成为行业发展的新瓶颈。在此背景下，MCP（Model Collaboration Protocol，大模型上下文协议）和 A2A（ Agent-to-Agent ）协议的出现并逐步走向标准化，为构建统一的大模型服务生态带来了曙光。

接下来，我们针对上述提到的“复杂问题”。简单地聊一聊常见的大模型技术是如何解决这个问题的。

下周我准备前往西安市参观秦始皇兵马俑，请你根据下周的天气推荐最适合到达西安的时间，并根据我的预算（1500 元）安排届时的行程。

工作流结合大模型

上面提到，仅靠单一的大模型很难完成上面的复杂任务。原因是大模型并不知道当前（用户提问的时间）西安市近一周的天气、兵马俑周边的景点、酒店价格；也不知道其他网友在社交平台上（如小红书）发布的去西安旅游经验帖子。这些信息在模型的训练数据中本就不存在，因此对于这样实时性的问题，大模型无从参考，也就不能做出决策（或者就算做出决策，也不可采用。这也是大模型的一个缺点之一，称为幻觉或凭空捏造）。

“工作流+大模型”方案的解决办法是：通过工作流，将大模型所需要的信息提前获取到，组成提示词传递给模型。再由大模型生成完整的决策报告返回给用户。

这里以 Dify 为例，可以构建一个简单的解决此问题的工作流，如下图：

需要说明的是，Dify 的代码执行采用的是代码沙盒，不可发送 http 请求。上图中的代码执行其实是代码执行+http 请求的结合。

图片过长，可能看不清楚。下面是文字解释：

  1. 用户提问输入到工作流，工作流开始；
  2. 参数提取。从用户的输入文本中提取参数：用户需要游玩的景区（sys_user_scenic）、用户去的城市（精确到区县一级，sys_address）、用户的预算（sys_money，单位元）、游玩时间（n，单位天）
  3. 获取天气信息。使用python代码调用天气API获取天气数据，输入地点sys_address和时间长度n（单位天）。输出近n天对应地点address的天气数据，存入全局数据（sys_weather）。
  4. 获取周边酒店信息。输入用户的游玩的景区（sys_user_scenic），调用高德API，查询附近的酒店及价格信息。输出全局变量（sys_hotel）。
  5. 获取经验帖子。调用类似于小红书平台等API，获取网上旅游的经验帖子，输出JSON值全局（sys_jingyan）。
  6. 调用 LLM。根据上述获取的全局信息，组成提示词，调用大模型获取输出
  7. 回复用户，工作流结束。

通过参考其他工具/代码获取到的信息，大模型可以方便的做出去指定地点旅游的攻略。但是工作流方案的缺陷也随之凸显出来：虽然能处理较为复杂的任务，但是任务的类型仍然较为单一，工作流的输入输出都已经被完全定死。比如上面这个实现旅游攻略的工作流对于另外的复杂任务（如获取用户电脑上的指定文件，并根据文件内容给指定用户发送邮件）完全束手无策。

Function Call（函数调用）

什么是 Function Call ?

Function Call 是一种机制，允许大语言模型动态调用外部函数或API，以完成特定任务。例如，当用户提问“今天的天气如何？”时，模型可以通过调用天气API获取实时数据并返回结果。这种方式不仅提升了模型的实用性，还使其能够处理复杂的多步骤任务。

函数调用的本质也是基于工作流，其原理也和工作流解决问题的原理大致相同，都是利用外部的工具获取信息，然后提供给大模型。不同之处在于支持函数调用的模型可以自己分析需要使用哪些工具（接口），然后利用厂商实现的接口代理或 API 去调用这些接口。这大大增强了理想情况下支持函数调用的模型处理复杂任务的能力，原先由用户手动设计的工作流只能处理一种类型的复杂任务，现在交给大模型自己分析外部工具需求，自己调用外部工具，可处理的任务类型大大增加，回复的准确率也有所上升。Function Call 的原理可简易地如下图所示。

从上图可以看出，函数调用总共有一下几个阶段：

  1. 用户提出问题，作为提示词（Prompt）输入给大模型；
  2. 大模型首先分析用户输入，从中提取出需要从外部接口（工具）中获取的信息，生成固定格式（不同厂商实现方式不同，主要是 JSON、XML 等格式）的函数调用请求；
  3. 大模型通过执行代理层（包括本地客户端代理如 Claude Desktop，或云端 API 网关），或者大模型自己的服务端，发送函数调用请求；
  4. 本地客户端/模型服务端返回函数调用的结果，作为用户提示词的补充，输入给大模型；
  5. 大模型根据上述获取到的全部信息，生成问题答复，返回给用户。

从上述实现原理也不难看出，函数调用方案存在以下几点缺陷：

  1. 大模型调用能调用的工具仍然有限。大模型只能调用自家厂商已经实现并部署后的 API，如果用户请求所需要的信息在厂商云端 API 库中没有对应的工具可以获取，那么大模型可能不能顺利完成任务；
  2. 不同厂商之间互不兼容，已造成性能瓶颈。各家大模型厂商在生成函数调用请求、云端 API 调用等技术上的实现方式各有不同。开发者难以综合多个大模型的优点。
  3. 上下文管理成本巨大。多次调用云端 API 可能会让模型消耗的 token 成指数级增长，对大模型上下文管理、token 扩充及数据缓存提出了更高要求。

Agent（智能体）

什么是智能体？

AI智能体（Agent）是一种基于大语言模型（LLM）的智能系统，它通过整合感知、规划、记忆和执行四大核心能力，实现“自主完成任务”的目标。具体来说，智能体的大脑是LLM（如GPT-4），负责推理和决策；感知模块（如文本/图像识别）实时获取环境信息；记忆系统（短期上下文+长期知识库）存储任务数据；工具调用接口（如API、搜索引擎）则赋予其执行能力。与传统AI辅助工具（如Copilot）不同，智能体无需人类逐步指导，只需设定目标即可自主拆解任务步骤、调用工具并迭代优化。

例如针对上面的“西安旅游推荐”的问题，它能自动实现天气等信息查询，整理信息，返回用户全过程。

从上面的介绍看起来，似乎 Agent 只是在上述工作流或者 Function Call 的基础上做了一层封装。但是它标志着大模型解决复杂问题的能力更加成熟，尤其是应对突发信息时的重新响应与重新规划，使大模型变得更加“类人”；而且，其自带的记忆系统联系练习上下文和知识库，让 RAG 技术触手可得，进一步降低了垂直领域模型落地的难度。 同时，Agent 相关技术可以应用于更多终端，例如应用于移动端（手机）的 Mobile Agent，也使 Agent 的技术前景更加广阔。从技术层面，Agent 通过引入以下关键组件实现了质变突破：

  • 动态规划器：支持实时任务分解与路径调整（如遇天气突变自动重排行程）
  • 记忆中枢：整合短期对话上下文与长期知识库（实现RAG无缝衔接）
  • 反思机制：通过ReAct等框架实现"思考-行动-验证"的闭环迭代

现在大模型应用中普遍具备的“联网搜索”功能，其技术方案类型可以大致地归类于 Agent 技术。其原理可以简述为：

  1. 大模型通过微调获得工具选择能力，判断何时触发联网搜索。当用户查询涉及时效性信息（如天气、新闻）或超出预训练知识边界时，模型生成搜索指令。
  2. 然后调用调用外部搜索引擎（如Bing/Google API）或定制爬虫工具，实现数据获取。
  3. 最后再将搜索结果注入模型上下文窗口，结合预训练知识进行推理。

在利用智能体技术处理更为复杂的任务时（如城市交通调度），多智能体（Multi-Agent）技术得到了广泛应用。2024 年 11 月在成都举行的“2024中国多智能体应用大会”，汇聚了来自复旦、北大等众多知名高校的多智能体实际应用解决方案，进一步证明了多智能体技术发展前景广阔。

但是，智能体技术（包括多智能体技术）也并非银弹，其在实际应用中的表现令人惊喜，但是仍然存在着与上述方案相似的资源消耗、厂商之间互不兼容等问题，同时，随着智能体数量的增多，多智能体之间协调、通信的技术复杂度成指数级增长，给相关技术方案的落地实现带来了巨大挑战。

工作流、函数调用、智能体三种方式对比总结

类别 典型特征 主要局限性
工作流+大模型 固定流程手工编排 无法处理动态数据和需求
Function Call API调用，无上下文决策 缺乏意图识别与结果评估能力
Agent 自主决策+工具协同+动态规划 需解决延迟与成本优化问题

MCP 和 A2A 协议

上述方案都或多或少地存在着不同实现之间相互不兼容的问题。在技术实现日新月异的今天，互不兼容已成为了限制各家厂商之间取长补短，构建产品生态，压缩成本的主要瓶颈。同时，从计算机技术的发展历程不难看出，解决此类问题最常见的办法就是制定并选举出大家都公认的协议，各家产品开发都遵照相同的协议规范，从而使下游可以共用一个开发框架。

MCP 协议

全称为 Model Context Protocol，模型上下文协议。其核心是模型上下文，即 LLM 在运行过程中所需的所有外部信息和工具。MCP 中文文档：https://mcp-docs.cn/introduction。

MCP 是一个开放协议，它为应用程序向 LLM 提供上下文的方式进行了标准化。你可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 模型连接各种数据源和工具提供了标准化的接口。

不难看出，其所采用的原理同我们上述讨论的基本一致。但是突出贡献在于它制定了 LLM 使用外部工具应该遵守的标准，并且这个标准得到了主流大模型厂商（包括竞争对手）的认可。

在官方网站中，MCP 提供了包括 Java、Python、TypeScript 和 C# 在内的多种语言的 SDK。这便是协议的强大之处，一旦协议被确定成功，开发者只需要导入对应的 SDK，即可快速让自己的应用或服务联接所有支持这些协议的外部大模型提供商（主要是通过自己搭建 MCP 服务器 MCP server）。与之前推出的 OpenAI 请求 SDK 和 Function Call 相比，MCP 更注重需跨模型、多工具协作或长任务场景。

MCP 的出现可以类比于互联网从专有 API 到 RESTful 的升级。

MCP 的技术原理，来自中文站文字：

开发者通过自己搭建 MCP Server，并参考 MCP 官方示例设计外部工具（即上图中的 tools），然后批准 LLM 获取并分析需要使用的 tools。

目前，Github 上已经出现了很多基于开源的 MCP server 可供使用。

仓库地址：https://github.com/punkpeye/awesome-mcp-servers（39k+ star）

A2A 协议

全称是 Agent-to-Agent 协议，**开放通信协议**。从名字上就看出，A2A 协议是主要是为了解决智能体之间的协作和通信。中文文档：https://agent2agent.info/zh-cn/docs/introduction/

A2A 是一种开放协议，是对 Anthropic 的模型上下文协议 （MCP） 的补充，后者为 agents 提供了有用的工具和上下文。A2A 协议借鉴了 Google 在扩展代理系统方面的内部专业知识，旨在解决在为客户部署大规模多 agents 系统时遇到的挑战。

A2A 协议处理复杂任务的流程大致可以分为以下几步：

  1. 每个智能体启动时生成 JSON 格式的智能体名片（Agent Card），描述其能力、输入输出格式、通信端点及安全认证方式。并将 Agent Card 提交至注册中心，验证格式合规性后存入能力数据库，并通过周期性心跳检测维持活跃状态；
  2. 主智能体（协调者）将复杂任务拆解为子任务（将西安旅游拆解为天气查询->酒店查询->网上经验贴查询等），生成任务规范（Task Spec）。主智能体通过注册中心查询匹配子任务需求的智能体列表，基于能力描述选择最优执行者，并通过tasks/send接口分配任务；
  3. 主智能体通过 GET /tasks/{id}/status 轮询或订阅 SSE 流获取智能体执行任务的实时状态；
  4. 主智能体获取到其他智能体的输出之后，以artifact对象封装任务输出，支持文本、结构化数据（JSON/CSV）、音视频流等格式。

MCP 与 A2A 对比总结

A2A 协议与 MCP 协议是当前 AI 生态中互补性极强的两大通信标准：

MCP协议（Model Context Protocol）由 Anthropic 提出，核心是构建"模型与工具的统一接口"，通过标准化API调用规范让单个AI模型（如大语言模型）能够安全、动态地连接数据库、API等外部资源，如同为AI配备"万能工具插槽"；

A2A协议（Agent-to-Agent Protocol）由谷歌主导，则专注于"智能体间的外交规则"，通过定义任务分配、状态同步等交互标准，使不同供应商开发的AI智能体能够像团队般协作，解决跨平台、跨系统的多智能体协同难题。

二者本质上形成分层协作关系——MCP为智能体提供"兵器库"（工具调用能力），A2A则制定"作战指挥体系"（多智能体协作机制），在复杂任务中常嵌套使用：例如医疗诊断场景中，影像分析智能体通过A2A接收任务后，可调用MCP协议连接医学数据库完成专项分析，最终结果再通过A2A同步给主控智能体。这种"工具层+协作层"的分工体系，共同推动AI系统从单体智能向群体智能演进。

参考资料：

  1. https://mp.weixin.qq.com/s/fpUbnxLhX5EgX8cX0rew3g
  2. https://zhuanlan.zhihu.com/p/29005204534
  3. https://mp.weixin.qq.com/s/xQrvNj3g5dCKvGzPSxsWRA

❣️温馨提示

由于笔者水平有限，文中难免出现错漏之处，读者藏龙卧虎，敬请斧正。

欢迎关注微信公众号：呼哧好大枫

posted @ 2025-04-18 15:26  spcodhu  阅读(164)  评论(0)    收藏  举报