第3章 MCP + Skills，Agent“工具+技能”的双轮驱动

3-1 大模型困境: 数据获取与整合上 的“抓瞎

语言大模型之所以能够推断出用户输入的意图，是因为语言大模型能够在用户的输入中找到关键的词语。然后通过这些关键词语在向量空间里面所处的位置，并且找到哪些物品或者哪些事件，跟这些关键词语靠的比较近的。 那么语言大模型就是通过概率运算来推理出用户的意图，很大概率就会跟这些物品或者事件相关联。这个就是我们觉得语言大模型非常智能的一个原因。

就是语言大模型它所有的运算都是在向量空间里面进行的。如果向量空间没有唯一的一个点去指代这个事件或者这个物品，语言大模型是根本推理不出来的。所以现在我问深圳当前的气温是多少？ 当前的深圳的气温这个数值在语言大模型的向量空间里面是没有唯一的一个向量，只带这个气温值。所以语言大模型是回答不上来这个问题，这个是原因。这就揭示了我们所认为很智能的语言大模型，它有一个很致命的缺陷，就是无法获取时效性的问题。

问题很多的小明又很不知趣的问了语言大模型这个问题。就是他想让语言大模型帮他将他自己公司的客户订单数据来整理成季度的销售报告。那么这个问题语言大模型能完成的了吗？ 同样的语言大模型它完成不了这个问题，为什么？因为语言大模型它的向量空间里面没有任何的一个向量指向这个用户私人的客户订单数据。所以语言大模型它的另外一个致命的缺点就是它无法拥有用户的个人数据。

这就是语言大模型的两个致命的缺点。第一个就是它无法获取实时性的数据。 第二个就是语言大模型无法拥有用户的私人数据。

3-2 困境解决方案: 函数调用( Function Calling )

语言大模型它能够获取实时数据的关键的地方是在于他能够自己根据API文档来编写这个API调用的函数。这个过程我们就称为function calling，也就是函数调用。 中文意思是函数调用。这个程序它是能够调用外部的API的。

第一个弱点就是刚才我们所说的不能够获取实时的数据。这个弱点就是通过函数调用方式calling来调用外部的API，解决不能够获取实时数据的缺点。

它能够帮助语言大模型去自主的调用外部的API，以及能够帮助语言大模型自主的调用本地文件。这些文件包括了excel文件、PDF文件、word文档，甚至是markdown文档。 也能够帮助语言大模型去查询数据库查询mysql数据库查询access数据库、查询hadoop这些数据库，以及甚至是云端的数据库，好像是阿里云、腾讯云这样子。这个就是函数调用function calling。

3-3 Function Calling就是大模型的跑腿小弟

本视频讲述了大模型无法直接回答实时数据问题的原因，以及其通过function calling机制调用外部工具函数（而非直接调用API）来获取实时信息的完整逻辑，强调大模型的核心价值在于语义理解与需求推理，而执行调用由开发者编写的专用工具函数完成。

大模型无法回答实时问题的根本原因

• 实时性知识缺失 大模型仅存储训练截止前的历史知识，对训练后发生的实时变化数据（如深圳今日气温）无感知能力。
• 直接回答失败的后果 若无法作答却直告“不知道”，将损害用户体验与模型可信度。

**实时数据获取的技术路径：API调用依赖第三方应用 **

• 调用必要性 大模型必须借助外部服务提供的API接口获取实时数据。
• 典型应用场景与对应API提供方
  • 天气数据：墨迹天气API。
  • 股票信息：同花顺API。
  • 交通信息：高德地图API。
• 整体流程本质 大模型整合第三方API返回的实时数据后，再结构化输出给用户。

**核心疑问一：谁真正调用了第三方API？ **

• 常见误解澄清 并非大模型本身直接发起HTTP请求调用API。
• 实际调用链路
  • 大模型识别需求后，触发内部模块 function calling（函数调用）。
  • function calling 模块接收大模型生成的参数（如地点“深圳”、日期“今日”）
  • function calling 将参数传递至大模型外部的工具函数（如“墨迹天气API工具函数”）
  • 该工具函数由开发人员编写，封装了对墨迹天气API的具体请求逻辑
• 执行主体定位 真正执行网络请求、调用第三方API的是开发者编写的外部工具函数，function calling 仅为参数中转与调度模块

**核心疑问二：为何不令大模型直接调用API？ **

• 职责分离原则
  • 大模型的核心能力是语义理解、意图识别与逻辑推理
  • 编写安全、健壮、符合协议的API调用代码属于工程实现范畴，非大模型设计目标
• 类比说明 大模型如企业“老板”，专注战略决策与需求判断；function calling 如“前台”，负责传递指令；外部工具函数如“打印机”，执行具体操作。
• 价值重申 投入巨资训练大模型，是为了使其精准理解用户输入（如“深圳今天气温”隐含地理位置+时间+气象维度），并推理出应调用“天气类工具函数”，而非替代工程师写代码 。

**工具函数的来源与注册机制 **

• 开发者主动构建 针对高频实时需求（天气、交通、股票），开发人员在大模型外部编写专用工具函数。
• 大模型认知建立方式 工具函数需经手动投喂（manual registration） 至大模型，使其知晓可用工具的存在、功能描述及参数规范 。
• 参数协同流程 大模型生成结构化参数（地点、时间等）→ function calling 封装为函数调用请求 → 外部工具函数解析参数并发起真实API请求 。

**全流程逻辑闭环总结 **

• 第一问答案 第三方API由大模型外部的开发者编写的工具函数调用，function calling 是参数传递与调度中枢。
• 第二问答案 大模型不直接调用API，因其核心价值在于需求语义解析与工具匹配推理，执行层交由专业化工程代码承担，实现能力解耦与系统可靠性保障。

3-4 更优的困境解决方案

**Function Calling的两大局限性 **

• 单点瓶颈问题: 单一Function Calling实例难以并发响应海量异构需求（如同时处理气温查询、股票分时图、交通路况等不同API调用请求）。
• 生态割裂问题: 不同厂商大模型（OpenAI、DeepSeek、豆包、通义千问）各自实现互不兼容的Function Calling协议，缺乏跨平台统一标准，显著增加开发者集成成本

MCP协议：标准化工具调用的解决方案

• MCP协议的双组件架构： 由MCP服务端（提供可执行工具集）与MCP客户端（作为大模型与服务端的中间协调层）构成。
• 工具列表（Tool Registry）机制： MCP服务端显式声明其能力范围，例如仅支持“调用墨迹天气API”，不支持“读取苹果电脑本地文件”，所有能力以结构化列表形式暴露。
• 客户端主动发现与委托流程： MCP客户端首先拉取并缓存MCP服务端的完整工具列表；当大模型提出需求（如“获取实时气温”），客户端据此列表匹配可用工具，并向服务端发起委托调用。

MCP三节点协同工作流程

• 节点定义
  • MCP Host：指代任意大语言模型（如OpenAI、DeepSeek、通义千问）；
  • MCP Client：大模型调用的轻量级代理，负责工具发现与请求转发；
  • MCP Server：实际执行工具逻辑的服务端，承载全部业务代码与外部连接。
• *初始化与通信建立 MCP Host初始化MCP Client → MCP Client向MCP Server发起工具列表请求 → 完成三方握手，建立稳定通信通道。
• 典型调用链路（深圳气温查询）
  1. OpenAI（Host）向MCP Client询问：“能否返回实时气温？”；
  2. MCP Client查工具列表确认“调用墨迹天气API”存在 → 向MCP Server发起委托；
  3. MCP Server执行API调用，获取原始气象数据；
  4. MCP Server将结果返回MCP Client → MCP Client回传至OpenAI。
• 跨模型通用性保障： 所有大模型（无论厂商）均遵循同一MCP协议与Client/Server交互范式，只要MCP Server工具列表中声明某能力，任意Host均可复用该能力，彻底解耦模型与工具实现。

3-5 对比Function Calling, MCP的不同

• **回顾MCP上下文协议 **
  • MCP协议的核心价值 ：MCP通过上下文协议连接数据库、浏览器、API等外部系统，弥补大模型无法访问实时变化数据和用户私人数据的两大缺陷。
  • MCP系统三节点架构 ：包含大模型（节点一）、MCP服务端（节点二）、MCP客户端（节点三）。
  • MCP服务端功能 ：提供一系列工具，如调用墨迹天气API、调用用户本地文件大模型。
  • MCP客户端功能 ：从MCP服务端获取工具列表，使大模型知晓可用工具集合。
  • 工具调用全流程 ：大模型语义分析用户输入 → 发现需调用本地文件 → 查工具列表确认存在对应工具 → 向MCP客户端发送调用指令及参数（如文件名）→ MCP客户端将指令与参数转发至MCP服务端 → MCP服务端执行工具完成请求。
• **回顾function calling机制 **
  • function calling定位：是大模型内部的函数调用模块（corning工具），属于模型原生能力。
  • function calling触发逻辑 ：当大模型判断用户需求涉及实时数据或私人数据时，主动触发function calling模块。
  • function calling执行路径 ：function calling作为“中间人”，向开发人员编写的外部工具函数发起请求，由外部函数实现具体功能。
• MCP与function calling的共同点
  • 共同目标：借助外部工具补足数据短板：二者均通过大模型外部工具实现获取实时变化数据或用户私人数据。
  • 共同机制：依赖中间代理层调用 ：大模型不直接调用工具，而是通过中间角色转发请求：MCP中为MCP客户端+服务端；function calling中为function calling模块本身。
• **MCP与function calling的核心差异 **
  • 差异一：中间代理的归属位置： function calling是大模型内部模块；MCP客户端与服务端均为大模型外部独立节点。
  • 差异二：工具发现方式 ：function calling中，工具函数由开发人员手动投喂给大模型；MCP中，大模型通过MCP客户端动态获取MCP服务端提供的工具列表 。
  • 差异三：工具开发主体与生态开放性 ：function calling工具由各厂商自有开发团队编写（如OpenAI工具仅OpenAI可用，阿里千问工具仅阿里可用）；MCP工具由第三方开发人员编写，任意大模型厂商均可复用同一套工具（如墨迹天气API调用工具可被OpenAI、阿里千问、字节豆包共同使用）09:09。
  • 标准化动因：解决工具重复建设与标准割裂： function calling导致同功能工具（如天气API调用）在不同厂商间重复开发、接口不一；MCP通过统一工具注册与发现机制，实现跨厂商工具标准化与互操作

3-6 体验MCP: Jmanus配置MCP服务

**MCP基本概念与价值定位 **

• MCP的核心作用 ：MCP通过提供标准化工具，使大模型能够调用外部系统能力。
• 典型应用示例 通过百度地图MCP服务器提供的工具，可实现路线规划查询与交通状况查询。
• 支付场景延伸 通过支付宝MCP服务器提供的工具，大模型可直接调用付款功能。
• MCP解决的关键问题 避免不同大模型（如千问、DeepSeek）重复开发适配同一外部API（如支付宝接口）的功能函数，实现工具能力的跨模型复用。
• MCP服务器与MCP服务的关系 MCP服务器是运行载体，MCP服务是其上部署的一组可调用工具；例如高德地图MCP服务器运行高德地图MCP服务工具集，支付宝MCP服务器运行支付宝MCP服务工具集。

**j-manners框架环境准备 **

• 框架导入与启动： 课程前期已导入基于Java的多智能体开发框架j-manners。
• 启动类路径说明 ： 启动类位于dream-manners/src/main/java/openmanner/springboot/OpenMannerSpringBootApplication.java。
• 技术栈确认： 框架基于Spring Boot开发。
• 默认界面与工作台入口： 运行启动类后打开默认页面，点击“进入工作台”进入three-mins工作台。

MCP配置与服务接入流程

• MCP设置入口 工作台右上角双横杠为设置入口，含基础设置、智能体设置、大模型设置、MCP设置及Prompt设置。
• 默认大模型标识 当前默认使用千问Plus大模型。
• MCP服务器列表初始状态 初始为空，需手动导入。
• 现成MCP服务获取渠道 通过魔塔社区（ModelScope MCP广场）获取开源MCP服务。
• MCP广场页面功能 提供多种MCP服务，如高德地图、支付宝、how to cook等。

**MCP服务实操：how to cook接入 **

• 服务选型依据 选用轻量级个人开发者MCP服务“how to cook”，无需申请第三方API密钥。
• 服务功能说明 该服务通过内置工具生成一日三餐菜单。
• 配置信息关键项 魔塔社区页面右侧显示三项配置：传输协议（HTTP/SSE/STDIO）、有效期、生成地址。
• 传输协议选择说明 SSE（Server-Sent Events）可简化理解为WebSocket类流式传输协议。
• 协议与地址配置操作 MCP配置中连接类型选SSE；有效期设为24小时后点击“生成链接”，复制生成的URL。
• j-manners中新建MCP服务器 在MCP服务器列表点击“+”新建，填写三项：名称（如“How To Cook”，首字母大写）、连接类型（SSE）、URL（粘贴前述地址）。
• 服务启用验证 保存后，“How To Cook”即出现在MCP服务器列表中。

MCP服务调用与结果解析

• Prompt示例与发送 参考魔塔社区提示词示例“今天吃什么？”，或指定场景如“制作四人晚餐菜单”，在对话框中发送。
• 响应机制说明 大模型输出的菜单并非自主生成，而是调用how to cook MCP服务工具后返回的结果。
• 数据源溯源 how to cook MCP服务的数据来源于GitHub仓库（页面中可点击跳转）。
• 数据调用逻辑 j-manners框架中的大模型通过MCP协议调用该服务工具，从GitHub菜单库中提取、整理并结构化输出菜单清单。

3-7 具有专业知识的Agent Skills

• MCP协议的提出背景与核心功能
  • 传统API调用方式的问题 每个语言大模型需依据API文档独立编写调用方法，不同模型间调用逻辑不统一。
  • MCP协议的定义与价值 MCP协议提供统一工具层，使任意语言大模型均可通过MCP标准接口调用同一第三方API，无需重复开发调用逻辑。
  • MCP协议的核心优势 实现语言大模型对外部数据的可访问性，并建立通用、标准化的API调用方法。
• **MCP协议的固有缺陷：工具过载与交互低效 **
  • 工具全量返回机制 MCP服务器将所支持的全部工具一次性返回给智能体。
  • 工具选择困境 智能体无法自主判断任务所需工具，需依赖语言大模型决策。
  • 类比说明 以“挖地”任务为例，MCP返回铲子、锄头、扫把等无关工具，智能体缺乏判别依据。
  • 决策依赖路径 智能体大脑为语言大模型，须向其询问“应使用哪个工具”。
  • 语言大模型的响应角色 语言大模型基于语义理解返回最优工具名称，智能体据此执行调用。
  • 两大效率瓶颈
    • 工具列表全量注入占用大量上下文窗口；
    • “提问—响应”双向交互导致token冗余消耗。
• 优化路径：赋予智能体领域专业知识（agent skills）
  • 领域能力的定义 向智能体注入特定专业领域的结构化知识。
  • 领域能力的实例化 如种地专家型智能体，具备农具功能、适用场景、操作逻辑等深度知识。
  • 自主工具选择机制 面对MCP返回的种地相关工具集，智能体无需询问语言大模型，可直接判定：挖地用铲子、松土用锄头。
  • 双重效益
    • Token节约 ：消除“询问—反馈”轮次，避免无效token消耗；
    • 上下文精简：MCP服务端按需返回工具（即仅返回当前任务所需工具），而非全量推送。
• agent skills的实现方式与技术形态
  • 知识注入形式 领域专业知识以结构化文件形式加载至智能体本地。
  • 工具配置形式 所有可调用工具亦以本地文件形式配置，脱离服务端实时供给。
  • 调用行为变革 智能体直接解析本地工具定义并触发执行，无需向MCP服务端发起工具元信息请求。
  • 术语定义 此机制称为 agent skills，代表智能体自主调用工具的新范式。
• **智能体工具调用的三种范式总结 **
  • 第一种：Function Tools（函数式工具） 开发者手动编写具体功能函数实现工具调用。
  • 第二种：MCP Server（中心化节点） 依赖MCP服务器统一分发工具列表，智能体从中选择调用。
  • 第三种：Agent Skills（领域自治） 智能体内置领域知识与本地工具配置，实现感知—决策—执行闭环，具备工具选择自主性与执行高效性。

3-8 工具调用最强组合: Agent Skills+MCP

回顾与问题引出：MCP协议的局限性

• **MCP协议的提出背景 ** 为统一不同大模型（如OpenAI、DeepSeek）调用外部API的差异，避免重复开发，引入MCP服务端作为标准化工具枢纽。
• **MCP协议的第一大缺陷：上下文爆炸 ** MCP服务端一次性返回全部注册工具的完整描述，导致大量无关工具信息挤占有限的上下文窗口。
• MCP协议的第二大缺陷：工具选择低效) 智能体缺乏领域知识，无法自主判断适配工具，必须反复依赖语言大模型进行工具推荐，造成token浪费与响应延迟。
• **复合任务挑战 ** 多工具协同任务需多次向语言大模型咨询组合策略，进一步加剧效率低下。

**解决方案提出：Agent Skills的核心思想 **

• 赋予智能体领域专业知识能力 例如赋予“农民”角色，使其天然掌握农业耕地场景下的任务分解逻辑与工具语义关联。
• 实现自主工具识别与组合优化 智能体不仅可精准匹配单工具，更能预判多工具级联使用的最优路径，提升执行效率。
• **按需调用，规避冗余 ** 拒绝全量工具加载，仅向MCP服务端请求当前任务必需的1–2个工具，彻底消除无效上下文。

Agent Skills的实现机制：三阶段渐进式加载

• 第一阶段：元数据预加载（启动时） ** 将领域知识文件与工具索引**（非工具本体）以原数据形式注入智能体，构建初始专业能力基座。
• 第二阶段：工具本体按需加载（任务触发时）) 智能体基于元数据索引定位所需工具后，动态向MCP服务端请求该工具的完整文档、调用接口定义及参数规范。
• 第三阶段：辅助资源运行时加载（执行中） 若工具依赖外部脚本、数据库或配置文件，智能体仅在实际调用该工具的瞬间加载对应辅助资源。

**Agent Skills的核心价值总结 **

• 专业化自主决策 ** 智能体内化领域专业知识**，无需语言大模型介入即可完成工具选择、组合规划与执行路径设计。
• 资源高效利用 渐进式加载机资源制严格遵循“最小必要”原则，显著压缩上下文占用与网络传输开销。

MCP与Agent Skills的协作关系

• **非替代性定位 ** 明确否定二者互斥，强调其本质是互补共生。
• MCP的角色：工具供给侧基础设施 作为标准化协议，屏蔽底层模型差异，确保同一工具可被OpenAI、DeepSeek等任意大模型无缝调用，杜绝重复造轮子。
• Agent Skills的角色：工具消费侧智能引擎 将工具调用从“被动查询”升维为“主动认知”，使智能体具备工具语义理解、场景化适配与动态编排能力。
• 业务分割线确立 ** 形成清晰职责边界：MCP负责“提供什么工具”（What），Agent Skills负责“何时用、如何用、组合用”（When/How/Combine）**。
• 未来范式 智能体工程实践将统一采用“MCP + Agent Skills”双栈架构，实现工具生态的标准化与智能调用的专业化深度耦合。

3-9 搞定复杂活儿，得靠多个Agent协作

• **回顾上一节课内容：MCP工具的定位与调用方式 **

  • MCP的本质与作用 MCP是一个工具，用于增强语言大模型自身能力，使其能查询第三方信息（如天气、股票），而该能力是语言大模型自身不具备的，必须依赖第三方工具实现。
  • MCP的可用性与调用形式 阿里魔塔社区已提供大量现成MCP服务器，用户可像调用API接口一样直接调用这些第三方MCP工具。

• 智能体（Agent）的核心能力与必要性

  • Agent的定义与类比 Agent是一个机器人、一个“超人”，语言大模型仅是其“头脑”。
  • Agent的三大能力：Agent除具备语言大模型的超强推理能力外，还拥有感知能力和行动能力。
    • 感知能力的具体体现 ： Agent能查询用户私人数据信息，掌握用户的过去、现在及偏好喜好。
    • 行动能力的具体体现： Agent能代替用户执行操作，例如浏览器操作、调用API接口，无需用户手动干预。
  • 单靠语言大模型的局限性 语言大模型仅是推理机器，只能与用户进行对话式交互（如“OK”），无法形成实际生产力。
  • Agent作为生产力核心的不可替代性 只有Agent才能成为真正帮用户“干活”的工具。

• **语言大模型、Agent与MCP三者的相互成就关系 **

  • 语言大模型与Agent的关系 语言大模型是Agent的“大脑”，赋予其超强推理能力与意图洞察力；但仅靠此不足以解决问题。
  • Agent与感知能力的深化逻辑 Agent能感知用户偏好信息，因其可查询用户个人信息、数据库、文档；结合语言大模型，可进一步洞察用户真实需求。
  • Agent与行动能力的实践价值 Agent不仅能给出答案，更能“上手”解决问题：查询文档、编写PPT、上网检索并总结资料——这才是真正的生产力。
  • MCP作为工具层的关键支撑 MCP即第三方服务的API接口（如高德地图API）；Agent通过调用MCP服务端，获取地图、交通等外部信息。
  • 三者缺一不可的辩证关系
    • 无Agent，语言大模型仅为聊天工具，无法形成生产力；
    • 无语言大模型，Agent仅为无思想的自动化工具，无法理解用户真实需求；
    • 无MCP，Agent无法获取高德地图等第三方内部信息，功能严重受限。

• **复杂任务的挑战与多智能体协作范式 **

  • 行程规划任务的复杂性 行程规划需综合用户偏好设定路线与景点、预定酒店、依据消费习惯选择交通工具（火车/飞机）等多步骤。

  • 单智能体效率瓶颈与社会分工启示 单靠一个智能体完成全流程效率低下；类比社会分工，“专业的人做专业的事”更优。

  • 多智能体专业化分工设计

    设想多个智能体协同完成行程规划：

    • 智能体一：MCP工具调用专家 专职调用高德地图MCP服务，获取交通信息与路线规划。
    • 智能体二：用户分析专家 专职查询数据库、分析用户偏好与消费习惯，据此设定景点与交通工具方案。
    • 智能体三：文档生成专家 专职将路线、交通等信息整理为表格，交付用户确认。

  • 总控智能体（智能体系）的统筹职能

    • 角色定位：主管，称为“智能体系”。
    • 核心职责：将复杂任务（如行程规划）拆解为子步骤，并分派给专业智能体执行；汇总各模块结果，生成最终交付文档。

• 多智能体协作作为未来生产力演进方向的结论性判断

  • 生产力形成的层级递进 单靠语言大模型 → 不行；单靠单一Agent → 不行；语言大模型+Agent+MCP → 仍不足；因现实任务高度复杂。
  • 任务分解与专业化执行的普适原理 任何复杂任务均可被拆解为简单子任务，交由专业智能体处理，从而实现分工明确、准确高效。
  • 行业趋势印证 多智能体协作已是当前（2025年10月）主流框架构建的明确方向。

3-10 多Agent跨部门协作: A2A协议

语言大模型的能力局限

• 目标拆解能力缺失 用户提出“购买商品”需求时，语言大模型无法自主将其拆解为确定商品清单、比价、加入购物车、付款等步骤。
• **自主思考与决策缺失 ** 无法基于用户购物习惯与当前场景推断潜在需求，仅能被动询问用户明确指令。
• **根本原因：缺乏具身能力 ** 语言大模型如同仅有“脑袋”的人，缺少眼睛（感知）、耳朵（接收信息）、双手（执行）、双脚（移动），无法主动行动，依赖用户轮询式对话触发响应。

**智能体（Agent）的核心价值 **

• Agent = 大模型 + 感知与行动能力 语言大模型作为Agent的“脑袋”，负责推理与知识存储；Agent自身配备“眼睛和耳朵”实现对外部环境的感知，“双手双脚”实现对外部事物的操作。
• **典型购物任务全流程 ** Agent可主动观察用户购物偏好 → 推断购物清单 → 提交用户确认 → 自主比价 → 下单付款，全程闭环执行。
• **单一模型无法实现通用AI ** 必须结合具备多模态感知与物理/数字世界操作能力的Agent，方能解决真实复杂需求。

**多智能体系统的必要性与分类 **

• 多Agent是必然架构 现实任务需分工协作，不可能仅靠单个Agent完成全部功能。
• Agent的两种类型
  • 远程Agent：部署于不同节点、基于不同大模型（如千问 vs. OpenAI），属异构系统。
  • 同模型多Agent：同一节点、同一大模型下派生的多个专业化Agent，协同完成单一任务（如购物场景中分别负责清单生成、比价、支付的Agent）。

多Agent通信与协作的核心要求

• 双重需求并存
  • 通信：可靠、结构化数据交换。
  • 协作：有条不紊的任务协同与状态同步。
• **状态同步的关键性 ** 协作必须确保各Agent对任务进度、中间结果、执行状态保持一致认知。

**A2A通信协议的设计定位 **

• 协议定义与命名 “A2A”即Agent-to-Agent，由谷歌提出，专为智能体间通信设计。
• 生态现状对比
  • MCP协议生态成熟：支付宝、百度地图已提供MCP工具，大模型可直接调用实现支付、查路线等功能。
  • A2A生态尚弱：当前主要用于学术与前沿探索，生产落地较少，仅需了解其原理。

**A2A协议的适用场景与架构 **

• 核心适用场景：远程Agent通信 因远程Agent分布于不同物理节点（如深圳vs.上海），需强一致性协调，故必须依赖A2A。

• 协调者（Coordinator）的强制角色

  A2A协议必须包含中心化协调者（A2A Server），统一管理：

  • 数据交互路由；
  • 全局状态同步（如任务进度、资源占用）。

• **同模型多Agent的轻量替代方案 ** 同一节点内Agent间通信可采用gRPC协议；状态同步可直接通过共享内存或本地文件实现，无需重型A2A。

**A2A协议的工作流程 **

• **服务端初始化 ** A2A Server作为中心协调节点启动并注册。
• Agent发现与连接建立
  • Agent 1查询Agent卡片库，选取合适Agent 2；
  • 将Agent 2卡片提交至A2A Server；
  • A2A Server据此发现并通知Agent 2，三方（Agent 1、Server、Agent 2）建立逻辑连接。
• 任务分发与执行
  • Agent 1将任务发送至A2A Server（非直连Agent 2）；
  • A2A Server进行任务管理后，转发至Agent 2执行。
• 进度查询与格式协商 Agent 1所有进度查询均经A2A Server中转；
  • Agent 1通过Server向Agent 2指定输出格式，Agent 2依规调整。
• 结果交付 Agent 2将格式化结果返回A2A Server，Server最终交付Agent 1并呈现给用户。

3-11 主流的多Agent开发框架

语言大模型与智能体的本质区分

• 核心概念对比
  • 语言大模型：具备超强推理能力，但不能作为生产力调用工具解决实际应用问题。
  • 智能体 ：借助语言大模型推理能力，将复杂任务切分为多个步骤进行解决。
  • 关键能力突破：通过MCP调用并执行外部工具，真正帮用户解决问题。
  • 生产力定位 ：智能体才是真正的生产力。

多智能体协作的必要性与发展演进

• 单智能体的局限性：复杂问题需多步骤解决，单智能体效率低下。
• 类比社会分工逻辑： 单打独斗效率低 → 专业事交专业人 → 合理社会分工模式。
• AI发展三阶段演进
  • 第一阶段：语言大模型（对话模型）；
  • 第二阶段：单智能体（可调用并执行工具）；
  • 第三阶段：多智能体协同操作 。
• 行业趋势印证
  • 当前主流AI框架均强调多智能体能力；
  • 本课程聚焦Manus多智能体框架；
  • 其他主流框架如LangChain（原称Lam Trip）、Graph（Python框架）同样支持多智能体。

**国外主流多智能体开发框架 **

• AutoGen（微软） 突出特点：多Agent协作能力，且支持人工干预 。
• GroupAI
  • 优势一（传承性） ：无需人工干预；
  • 优势二（协作范式）：完全仿照人类团队合作模式：
    • 主管角色智能体：负责任务拆分、分发、协调与监管全流程；
    • 争议处理机制 ：主管组织相关智能体讨论争议点，自主达成解决方案；
    • 角色专业化 ：每个智能体具备专属专业角色；
    • 统筹主管智能体：专责任务分发、争议组织及全流程协同；
    • 自主通信协作：智能体间通过通信协同完成任务；
    • 争议解决机制：智能体讨论后投票得出最优解。
• LangChain（原Lam Trip）
  • 基于Python开发的智能体框架，被广泛用于企业级自定义开发；
  • 与Spring AI同属高自由度框架，优于拖拽式框架（如Define、N8N） ；
  • 支持单智能体与多智能体开发 ；
  • 优势 ：模块化设计、代码级自定义能力；
  • 缺点：学习门槛高，需手动配置参数（如部署方式等）。

**国内主流多智能体开发框架 **

• Manus / J-Manners
  • 本课程主讲框架；
  • 框架层级关系：
    • J-Manners（Java开发）基于Open Manus；
    • Open Manus基于Manus；
    • 核心思想继承自Manus ；
  • Manus核心思想：需求驱动的任务自动分解；
    • 示例：制定旅行计划
      • 步骤一：获取用户偏好、景点筛选 ；
      • 步骤二：调用高德地图查询路线；
      • 步骤三：购买车票、确定日期、查询天气 ；
    • 突出能力：将简单需求自动切分为多步骤，并交由不同智能体自动执行。
• JoyAgent（京东）
  • 新兴框架（2025年10月），基于SpinDB开发；
  • 优势一：工具原子化；
  • 优势二 ：支持本地部署、模块复用。
• MU-Agent（蚂蚁集团）
  • 新兴框架（2025年10月）；
  • 核心特点一 ：基于知识图谱；
  • 核心特点二 ：融合知识图谱与语言大模型，增强Agent决策支持能力。

3-12 多Agent的核心执行流程

**多智能体团队协作模式概述 **

• 核心思想 复杂需求可切分为多个简单需求，由专业化智能体分工完成，提升执行效率。
• 主管智能体职能 负责复杂任务的切割、任务分派及全局统筹。
• 主流框架共识 当前主流多智能体开发框架均采用该团队协作模式。

**单个智能体执行流程 **

• 第一步：接收任务 智能体首先接受分配的任务。
• **第二步：任务步骤规划 ** 对任务进行结构化拆解：明确第一步、第二步、第三步等执行顺序，以及所需调用的工具。
• 第三步：按规划执行步骤严格依照规划的步骤序列逐项执行。
• 第四步：步骤结果评估 每完成一个步骤，即对其输出结果进行评估，判断是否符合预期。
• **第五步：评估反馈与动态调整 ** 将评估结果反馈给智能体，驱动其决定是否调整后续步骤或调用新工具。
• 最终输出 全流程执行完毕后生成最终答案。
• **执行循环结构 ** 第三步（执行）、第四步（评估）、第五步（反馈与调整）构成闭环循环，每步执行后均触发该三步循环。

**多智能体团队核心执行流程 **

• **第一步：用户意图识别 ** 基于大模型推理能力，准确识别用户真实意图。
• 第二步：任务初始化 在意图识别基础上，对用户任务进行初始建模与状态设定。
• 第三步：复杂任务规划与划分 由主管智能体主导：将复杂需求切割为若干可并行/串行执行的简单子任务，并确定各子任务执行优先级。
• **第四步：分布式任务执行与协同 ** 主管智能体将子任务分派至对应专业智能体；各专业智能体依据单体五步流程独立执行；关键在于多智能体间的信息交互与协同机制。
• **第五步：结果整合 ** 主管智能体汇总各专业智能体产出的中间结果，进行融合、校验与最终答案生成。

**多智能体协作两大核心挑战 **

• 智能体间通信机制 解决智能体非隔离状态下的信息交换问题；对存在冲突的结论，需由主管智能体组织多智能体投票决策。
• 中间结果存储机制 明确各智能体执行产出的中间结果存放位置，确保主管智能体可统一访问、调度与整合；该机制是结果整合的前提。
• **框架实现印证 ** 主流多智能体开发框架（含后续课程聚焦的 j manner）均设置独立模块专门处理上述通信与中间结果存储问题。
• **双层骨架结构 ** 多智能体系统整体骨架为：意图识别 → 任务初始化 → 任务划分 → 协同执行 → 结果整合； 每个智能体内部骨架为：接收任务 → 步骤规划 → 执行 → 评估 → 反馈调整。