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

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

3.1.1 LLM 优势

　　1.LLM 掌握的知识广阔

　　2.LLM 能够推理用户意图

　　3.LLM 根据用户的习惯，返回结果

3.1.2 困境

（1）无法获取时效性

（2）无法拥有用户的个人数据

举例1，提问：今天气温多少度？

大模型能够知识渊博是因为提前把数据已经加载在向量空间中了，比如红楼梦、西游记内容等，在向量空间中有唯一ID，并且与"同类"所在一片区域，便于关联理解，而当询问当前天气多少度？时，当前气温的数值在大模型的向量空间中没有提前记录此ID，所以大模型无法回答此问题，即：无法获取时效性

举例2，提问：根据客户订单生成季度销售报告

当问及私人数据时，大模型无法回答此问题，即：无法拥有用户的个人数据

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

3.2.1 前期方案

以前的解决方案：人工额外编写代码调用外部API

现在的解决方案：由语言大模型分析用户的需求是否需要调用外部信息，如果需要获取外部数据，大模型能够根据外部 API 文档，自己编写 API 函数，从而获取实时数据，进而返回给用户

3.2.2 Function Calling

Function Calling（函数调用）：解决实时数据

1.用户询问语言大模型当前时刻，深圳气温温度？

2.语言大模型没有当前气温温度，需要他能判断出需借助外部工具获取当前气温温度

3.语言大模型向量空间中有能获取实时温度的第三方应用（如：墨迹天气，且有其 API 文档），语言大模型能根据掌握的 API 文档编写 API 函数，将用户深圳的地点作为参数传给墨迹天气

4.语言大模型获取当前深圳的气温温度，整合回复给用户

Function Calling（函数调用）：解决私人数据

1.用户询问语言大模型，根据客户订单生成季度销售报告

2.语言大模型没有客户的私人数据，能够判断出需要调用客户的本地文档，甚至能够查询用户本地或云端的数据库，包括word、pdf、execl 等

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

获取实时数据或私人数据，是由 Function Calling 调用外部API，为什么大模型不自己调用API 呢？

1.LLM 主要专注于语义分析、逻辑推理，根据自身推理能够判断出那个外部工具函数能够满足用户的需求，将参数交给Function Calling，并告诉 Function Calling 调用那个外部函数工具

2.Function Calling 是调用者，调用程序员手动投喂的外部函数工具，执行者是外部函数工具，Function Calling 传参到工具函数

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

问题：1.Function Calling 只有一个，面对多个用户的多个需求，处理请求处理不过来

问题：2.LLM 有多家公司，例如：ChatGPT、通义千问、豆包、Deepseek 等，每家公司有多个 Function Calling，相互之间不通用

基于以上两点，行业规范出了 MCP协议，统一的 Function Calling （跑腿小弟）进化版

MCP协议分为：MCP 服务端、MCP 客户端

MCP 服务端中有工具列表，工具列表中记录 MCP服务端支持调用的工具

MCP 客户端能够拉取到MCP 服务端中的工具列表，从而知道可以调用那些工具的 API

1.LLM（MCP Host）初始化 MCP客户端

2.MCP 客户端向MCP 服务端请求工具列表，MCP 服务端返回工具列表

3.会话建立成功

4.在循环对话中，当用户提问：“深圳天气”

5.LLM 会请求MCP客户端，询问能否返回实时温度？MCP客户端查看工具列表，工具列表中写明可以访问墨迹天气API

6.MCP 客户端调用墨迹天气API的工具资源访问MCP 服务端，请求MCP服务端调用工具

7.MCP 服务端调用对应的工具，将调用后执行的结果返回资源响应给MCP客户端，MCP 客户端将结果返回给 LLM

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

相同点：

　　1. Function Calling、MCP 都是通过 LLM 外部的函数工具实现 LLM 获取实时数据、用户私人数据

　　　　MCP协议（上下文协议）：外部函数工具放在 MCP服务端，由 MCP服务端实现业务逻辑

　　　　Function Calling：外部工具由开发人员自己编写的函数工具

　 2.LLM 并不是直接调用工具函数，通过“中间人”调用函数

　　　　MCP协议：MCP客户端通知MCP服务端，由MCP服务端调用工具函数

　　　　Function Calling：由 Function Calling 调用工具函数

不同点：

　　1.Function Calling 是 LLM 内部的模块，而 MCP 协议中（包括 MCP客户端、MCP服务端）是 LLM 外部的两个节点服务

　　2.Function Calling 中外部工具函数由开发人员编写，LLM 能够知道外部函数工具是由开发人员手动将工具函数“投喂”给大模型，而 MCP 协议中外部的函数工具放在MCP服务端，LLM 能够知道外部的工具函数，是由 MCP客户端从 MCP 服务端中获取MCP 服务端所拥有的工具函数列表

　　3.Function Calling 是由每个 LLM （例如：deepseek、豆包、千问）公司内部开发人员所写，只有自己公司内部知道，而 MCP 协议中，外部的工具函数不止 LLM 所在公司编写，各个公司的 LLM 都可以使用这个由第三方开发人员编写的外部工具函数

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

1.Java IDE 打开 OpenManusSpringBootApplication 并运行

2.本地浏览器访问：http://localhost:18080/ui/index.html#/direct

3.页面设置：直接进入工作台 -> 设置 -> （基础设置、Agent 设置、Model 设置等）

4.魔塔社区（调用不同的 MCP，需要不同的 API Key）：https://modelscope.cn/mcp

5.举例：今天吃什么 MCP -> 服务配置 Remote -> 传输类型 SSE -> 鉴权类型：无鉴权、有效期：24 小时有效 -> 连接

6.复制出现的代码，主要注意其中 url

{
  "mcpServers": {
    "howtocook-mcp": {
      "type": "sse",
      "url": "https://mcp.api-inference.modelscope.net/5a220f7891d44a/sse"
    }
  }
}

7.Tools/MCP配置 -> 新建MCP配置 -> MCP名称 -> 连接类型 -> URL -> 保存

8.对话框：请使用howtocook的MCP服务为4人晚餐推荐菜单，会给出答复

9.数据来源：https://github.com/Anduin2017/HowToCook

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

3.7.1 Agent Skills

1.MCP客户端请求 MCP服务端，MCP服务端返回所有的工具给智能体

2.智能体的大脑LLM要判断使用哪个工具，将能实现的工具名称返回给智能体

3.智能体调用对应工具完成任务

缺点：

　　1.MCP服务端返回所有工具，会大量占用上下文的窗口

　　2.智能体调用合适的工具，需要LLM判断，由LLM给智能体返回工具名称，浪费 Token

解决方式：

4. 智能体（专业知识能力）无需询问LLM，自己知道使用哪个工具

优点：

　　1.智能体无需浪费Token，去请求询问LLM

　 2.智能体无需MCP服务端将所有工具返回，智能体知道不同需求使用对应的工具，让MCP服务端返回能实现需求对应的工具即可，不会占用上下文的窗口

5.智能体拥有专业知识的能力是通过文件配置所赋予的，并且调用的工具函数也是以文件的形式配置在本地，这样不需要向MCP服务端请求工具列表，既 Agent Skills

3.7.2 总结

智能体调用工具的3种形式

　　1.Function Tools 程序员自己开发函数方法，智能体使用Function Calling实现工具的调用

　　2.MCP客户端、MCP服务端，MCP服务端返回所有工具，LLM告诉所使用的工具，智能体选择实现需求对应的工具调用

　　3.Agent Skills，智能体拥有专业知识的能力，自己知道需求所调用的工具一类中最优解或组合工具达成最优解

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

3.8.1 Agent Skills

Agent Skills ：给智能体赋予专业知识的能力，以文件配置的方式赋予。

1.先以元数据形式加载到智能体，智能体启动时，先将元数据加载到智能体，领域类知识以文件形式加载到智能体

2.工具、工具文档及如何调用、周边辅助脚本等并非一次性加载到智能体，智能体启动时先将这些元数据加载到智能体，让智能体先拥有知识、先拥有专业的能力

3.遇到问题时，智能体知道调用那个工具或那几个工具组合起来完成效率最高

　　元数据包括：1.专业的知识、2.所拥有的工具索引

4.智能体知道调用那个工具时，才将工具具体的使用方式、文档、命令加载到智能体内

5.在使用、调用工具时，需要工具涉及的辅助资料（例如：脚本、数据库等），才再次去加载相应的辅助资料

3.8.2 总结

Agent Skills

　　1.领域专业知识（让智能体知道遇到问题调用那个工具，或哪些工具组合能够解决问题）

　　2. 资源渐进式加载（1.加载工具索引、2.加载对应工具等资源、3.加载工具所需其他资源）

Agent Skills 调用的方式不会替代 MCP调用方式，两者合作共赢关系

　　MCP协议：工具的提供者

　 Agent Skills：如何使用工具（智能体的能力与智慧，而不是每次都询问 LLM ，自己应该调用什么工具）

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

3.9.1 协作

LLM：如果没有Agent，LLM 只是一个对话、聊天工具，无法形成生产力

Agent：如果没有 LLM，Agent 只是一个自动化工具，没有思想，不知道用户的真正需求

MCP：如果没有MCP，Agent 无法查询其他第三方内部信息

3.9.2 行程规划

需求：

　　1.根据用户偏好设定行程路线以及参观景点

　　2.根据行程路线预订酒店

　　3.根据用户消费偏好，选择飞机、高铁、火车、大巴、公交

根据社会分工，专业的人干专业的事，效率更高，多 Agent 做行程规划任务，每个智能体有自己的专业技能

1.智能体A 专门调用MCP工具，查询交通信息、路线规划

2.智能体B 查询数据库，对用户进行偏好分析、消费习惯分析

3.智能体C 文档制作，将路线规划、交通信息、用户分析等制作表格

4.智能体D（主管）将用户需求拆分，将每个步骤分给对应的智能体A、B、C，最后将智能体A、B、C的信息汇总，生成一个文档

3.9.3 总结

复杂任务处理：多 Agent 相互协作，是 Agent 发展的明确方向

　　1.交给专业的人，即专业的Agent

　　2.团队分工明确，即多Agent协作

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

3.10.1 举例

LLM 对用户提出的复杂需求无法进行目标拆解及自主思考、决策

例如：用户提出，让语言大模型购买商品

　　1.无法自住思考以及自主决策

　　2.无法进行目标拆解

　　3.只擅长单轮对话，难以处理有步骤的规划

关键：只有 LLM “大脑”，没有感知的 skills “眼睛”，执行的 Agent “手”

3.10.2 A2A通信协议

A2A协议目前生态，没有支付宝MCP、百度地铁MCP 等可以直接调用完成支付与导航等功能完善，了解即可

LLM 之间不同，即不同的模型厂商，例如Qwen、DeepSeek ，只能有一个LLM

每个 LLM 下面会有多个 Agent 共同协作完成用户需求，同一 LLM 内部多个 Agent 通过 gRPC 协议进行数据交互，状态同步（通过内存、本地文件）轻量，主要用于同一 LLM 内Agent之间通信交互

不同 LLM 下多个 Agent 之间通信需要协调者（主要用于数据交互、状态同步），需要使用 A2A通信协议，重，主要用于跨 LLM 远程Agent之间通信交互

3.10.3 A2A协议步骤

协调者：A2A Server

1.建立联系：远程Agent 1 需要知道有哪些工作的协调，需要查询Agent卡片，从卡片中抽取合适远程Agent 交给 A2A Server，A2A Server 通知远程Agent 2 的工作，远程Agent 1 需要你帮忙做

2.任务执行：远程Agent 1 发起任务给 A2A Server，A2A Server 进行任务管理，再将任务交给远程Agent 2，远程Agent 2 接受到任务后，进行任务的执行

3.交互：在执行过程中，远程Agent 1 不断对 A2A Server 询问进度，A2A Server 协作发送给远程Agent 2，远程Agent 2更新进度给A2A Server，A2A Server 再回复远程Agent 1（进度的更新通过A2A Server 传达，反复询问）

4.格式：远程Agent 1 对A2A Server 指定输出格式，A2A Server 通知远程Agent 2输出要求的格式，远程Agent 2调整格式，根据要求生成最终结果给 A2A Server ， A2A Server -> 远程Agent 1，远程Agent 1 将结果呈现

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

目前各大厂商的 Agent开发框架

1.AutoGen：微软：多Agent协调能力、能进行人工干预

2.CrewAI：CrewAI Inc（美国 AI 初创公司）：团队自主协作、Agent角色专业化、任务动态委派、争议解决

　　优势：1.全程无需人员干预、2.智能体间协同合作是仿照团队合作的模式（拥有 leader 、worker 概念）

3.LangChain：LangChain Inc（美国旧金山创业公司）：大规模流程定制、模块化、需要手动配置

　　优势：1.可以根据代码定制、2.模块化，劣势：1.有学习门槛，有些参数需要手动配置

4.Manus：Butterfly Effect（蝴蝶效应，Monica.im）：规划-执行-验证3层分工协作

　　优势：1.将需求切分，再交给不同的智能体

5.JoyAgent：京东：本地部署、复用历史任务经验、工具原子化
6.muAgent：蚂蚁集团：基于知识图谱、LLM + 知识图谱增强决策支持

注意：本视频讲解 JManus 是基于 Java 语言开发 OpenManus ，OpenManus 是基于 Manus 开发

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

3.12.1 单个Agent执行流程

步骤拆解：

　　1.接收任务

　　2.对任务进行步骤规划，规划每步的工作内容

　　3.执行每个步骤

　　4.每个步骤完成后，对结果进行评估

　　5.评估结果反馈给智能体，让智能体根据每个步骤的结果决定是否进行动态调整，以及是否调用工具

　　6.得到最终答案

　　　　其中 3、4、5 步骤是一个循环执行的过程

3.12.2 多个Agent执行流程

步骤拆解：

　　1.意图识别，基于LLM大模型的推理能力

　　2.识别用户真实意图后，对用户意图的进行任务初始化

　　3.任务规划 -> 由主管角色的智能体所执行（将复杂的需求切割为简单的需求，对执行的简单需求排出先后顺序）

　　4.主管角色的智能体将切割好的任务分配给下面专业的智能体“下属”，智能体“下属”进入单个智能体的执行流程（3.12.1 单个Agent执行流程）

　　5.多 Agent执行流程，重点在于多智能体间信息的交互、交换，有些冲突的地方，还需要“主管”智能体决策组织多智能体投票（1.智能体间通信、2.智能体中间结果的存储）

　　6.“主管”智能体结果整合

———————————————————————————————————————————————————————————————————————————

无敌小马爱学习

posted on 2026-07-10 00:00 马俊南阅读(13) 评论(0) 收藏举报

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

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

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

3.1.1 LLM 优势

3.1.2 困境

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

3.2.1 前期方案

3.2.2 Function Calling

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

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

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

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

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

3.7.1 Agent Skills

3.7.2 总结

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

3.8.1 Agent Skills

3.8.2 总结

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

3.9.1 协作

3.9.2 行程规划

3.9.3 总结

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

3.10.1 举例

3.10.2 A2A通信协议

3.10.3 A2A协议步骤

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

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

3.12.1 单个Agent执行流程

3.12.2 多个Agent执行流程

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

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