1
00:00:00,100 --> 00:00:02,105
你好，欢迎收听。

2
00:00:02,055 --> 00:00:09,411
前面几集我们一直在打磨单个智能体的能力，怎么推理，怎么调工具，怎么管上下文。

3
00:00:09,411 --> 00:00:15,961
这一集换个角度，讲当智能体要跟外面的世界打交道的时候，靠什么把话说通。

4
00:00:15,961 --> 00:00:23,497
本内容改编自 Datawhale《Hello-Agents》，采用 CC BY-NC-SA 4.0 授权，为二次演绎配音版。

5
00:00:23,497 --> 00:00:27,800
这一集对应教材第十章，讲智能体通信协议。

6
00:00:27,800 --> 00:00:40,552
出场的三个主角，一个是给智能体接工具用的 MCP，一个是给智能体之间对话用的智能体对智能体协议，还有一个是给大规模智能体网络做服务发现的 ANP。

7
00:00:40,552 --> 00:00:48,125
听上去有点抽象，但你只要先记住一句话就够了，协议解决的是连接问题，不是智能问题。

8
00:00:48,125 --> 00:00:49,783
顺序是这样。

9
00:00:49,783 --> 00:01:07,299
先说为什么单个智能体再强也绕不开协议，再拆三种协议各管哪一段，然后重点讲生态最成熟的 MCP，包括三层架构、工作流程和五种传输方式，接着讲智能体之间怎么对话，最后收一批能带走的判断依据。

10
00:01:07,299 --> 00:01:08,910
我们开始。

11
00:01:09,052 --> 00:01:13,809
回头看我们前面搭起来的那个会推理会行动的智能体。

12
00:01:13,759 --> 00:01:17,209
它已经能想能调工具，看起来挺完整。

13
00:01:17,209 --> 00:01:20,129
但它身上有三个绕不开的限制。

14
00:01:20,129 --> 00:01:22,629
第一个是工具集成的困境。

15
00:01:22,629 --> 00:01:29,997
每接一个新服务，不管是代码仓库、数据库还是文件系统，都得写一个专门的工具类。

16
00:01:29,997 --> 00:01:35,778
工作量是一方面，更要命的是不同开发者写的工具互相之间不认。

17
00:01:35,778 --> 00:01:39,552
你写的搜索工具，我这边没法直接拿过来用。

18
00:01:39,552 --> 00:01:42,281
第二个是能力扩展的瓶颈。

19
00:01:42,281 --> 00:01:50,658
智能体的能力被死死限制在预先定义好的工具集里面，运行时没法发现新服务，更没法临时用起来。

20
00:01:50,658 --> 00:01:55,045
你上线那天它能干什么，它就永远只能干什么。

21
00:01:55,045 --> 00:01:57,173
第三个是协作的缺失。

22
00:01:57,173 --> 00:02:08,230
当任务复杂到需要多个专业角色配合，比如一个负责查资料，一个负责写，一个负责改，我们只能靠手工编排去协调它们之间的关系。

23
00:02:08,230 --> 00:02:11,800
教材里把传统做法的毛病说得很直白。

24
00:02:11,800 --> 00:02:23,098
每个工具都要自己处理网络请求、错误处理、认证这些事，代码重复，难以维护，别人写的又用不了，加一个新服务就要写一大堆代码。

25
00:02:23,098 --> 00:02:25,646
那协议到底带来什么改变。

26
00:02:25,646 --> 00:02:26,872
四个词。

27
00:02:26,872 --> 00:02:31,247
标准化接口，让不同服务用同一种方式被访问。

28
00:02:31,247 --> 00:02:35,466
互操作性，让不同开发者的工具能拼在一起。

29
00:02:35,466 --> 00:02:42,281
动态发现，让智能体在运行时才知道有什么新能力可用，而不是写死在代码里。

30
00:02:42,281 --> 00:02:46,151
可扩展性，让系统加新模块变得轻松。

31
00:02:46,151 --> 00:02:51,812
打个比方，它有点像互联网里传输控制协议和网际协议那一层。

32
00:02:51,812 --> 00:02:58,110
不是它替你干活，而是它让所有设备不用为彼此单独写一套通信代码。

33
00:02:58,252 --> 00:03:03,682
智能体通信协议不是一个东西，而是一组针对不同场景的标准。

34
00:03:03,632 --> 00:03:06,529
教材拿业界主流的三种来举例。

35
00:03:06,529 --> 00:03:12,022
第一种，MCP，全称模型上下文协议，由 Anthropic 团队提出。

36
00:03:12,022 --> 00:03:17,803
它的定位是智能体与工具之间的桥梁，设计哲学叫上下文共享。

37
00:03:17,803 --> 00:03:21,889
注意这个词，它不只是一个远程过程调用协议。

38
00:03:21,889 --> 00:03:34,089
当智能体访问一个代码仓库时，服务器不光能给文件内容，还能给代码结构、依赖关系、提交历史这些上下文，让智能体做判断的时候有更多依据。

39
00:03:34,089 --> 00:03:38,344
第二种，智能体对智能体协议，由 Google 团队提出。

40
00:03:38,344 --> 00:03:43,284
它关心的是智能体之间怎么对话，设计哲学叫对等通信。

41
00:03:43,284 --> 00:03:52,274
在这个网络里，每个智能体既是服务的提供者，也是服务的消费者，既能主动发请求，也能响应别人的请求。

42
00:03:52,274 --> 00:03:55,904
这种对等设计绕开了中心协调器的瓶颈。

43
00:03:55,904 --> 00:04:04,882
第三种，ANP，也就是智能体网络协议，目前还是一个概念性的协议框架，由开源社区维护，生态还不成熟。

44
00:04:04,882 --> 00:04:12,226
它要解决的问题是，在一个有成千上万个智能体的网络里，怎么找到你需要的那个服务。

45
00:04:12,226 --> 00:04:21,373
设计哲学叫去中心化的服务发现，提供服务注册、发现和路由的机制，智能体不需要预先配置好所有连接关系。

46
00:04:21,373 --> 00:04:22,971
一句话区分。

47
00:04:22,971 --> 00:04:33,103
MCP 解决怎么访问工具，智能体对智能体协议解决怎么跟别的智能体对话，ANP 解决怎么在大规模网络里发现和连接智能体。

48
00:04:33,103 --> 00:04:34,245
怎么选。

49
00:04:34,245 --> 00:04:36,505
教材给的判断很直接。

50
00:04:36,505 --> 00:04:41,457
要访问外部服务，文件、数据库、接口，选 MCP。

51
00:04:41,457 --> 00:04:46,505
要多个智能体协作完成任务，选智能体对智能体协议。

52
00:04:46,505 --> 00:04:50,459
要构建大规模的智能体生态，考虑 ANP。

53
00:04:50,459 --> 00:05:03,488
另外提醒一句，这几种协议目前都还在发展早期，MCP 的生态相对成熟一些，但各种工具的时效性取决于维护者，更推荐选择有大公司背书的 MCP 工具。

54
00:05:03,488 --> 00:05:05,627
框架侧怎么落地呢。

55
00:05:05,627 --> 00:05:08,777
HelloAgents 把通信协议做成三层。

56
00:05:08,777 --> 00:05:19,594
最底下是协议实现层，MCP 基于 FastMCP 库，智能体对智能体协议基于官方开发工具包，ANP 是自研的轻量级实现，只做概念模拟。

57
00:05:19,594 --> 00:05:28,320
中间是工具封装层，三种协议统统封装成统一的工具接口，继承同一个基类，提供一致的方法名。

58
00:05:28,320 --> 00:05:36,216
最上面是智能体集成层，所有智能体都通过工具系统用协议工具，不用关心底层细节。

59
00:05:36,364 --> 00:05:39,439
现在把镜头拉近，细看 MCP。

60
00:05:39,389 --> 00:05:41,636
这一节是整集的重点。

61
00:05:41,636 --> 00:05:43,102
先说架构。

62
00:05:43,102 --> 00:05:47,165
MCP 采用宿主、客户端、服务器三层设计。

63
00:05:47,165 --> 00:05:50,338
教材拿一个很生活化的场景来拆。

64
00:05:50,338 --> 00:05:54,557
假设你在桌面端问一句，我桌面上有哪些文档。

65
00:05:54,557 --> 00:06:01,720
宿主层就是那个桌面应用，它负责接收你的提问，跟模型交互，管理整个对话流程。

66
00:06:01,720 --> 00:06:13,018
客户端层是宿主里面内置的 MCP 客户端，当模型判断需要访问文件系统时，它被激活，负责跟合适的服务器建立连接，发请求收响应。

67
00:06:13,018 --> 00:06:22,273
服务器层就是那个文件系统服务器，它执行真正的扫描动作，访问桌面目录，把找到的文档列表返回回来。

68
00:06:22,273 --> 00:06:24,160
完整链路是这样。

69
00:06:24,160 --> 00:06:36,215
用户提问，宿主接住，模型分析，判断需要文件信息，客户端发起连接，服务器执行操作，结果返回，模型生成回答，最后显示在界面上。

70
00:06:36,215 --> 00:06:39,485
这套设计的价值在于关注点分离。

71
00:06:39,485 --> 00:06:45,350
宿主专注用户体验，客户端专注协议通信，服务器专注具体功能。

72
00:06:45,350 --> 00:06:50,831
开发者只需要专心写自己的服务器，不用管宿主和客户端怎么实现。

73
00:06:50,831 --> 00:06:53,367
再看它的三大核心能力。

74
00:06:53,367 --> 00:06:57,297
第一是工具，这是主动的，用来执行操作。

75
00:06:57,297 --> 00:07:01,107
第二是资源，这是被动的，用来提供数据。

76
00:07:01,107 --> 00:07:06,648
第三是提示模板，这是指导性的，用来给模型提供现成的模板。

77
00:07:06,648 --> 00:07:10,374
三者合起来构成完整的工具访问框架。

78
00:07:10,374 --> 00:07:13,523
然后是工作流程，一共五步。

79
00:07:13,523 --> 00:07:23,812
第一步工具发现，客户端连上服务器之后，先调用列工具的方法，拿到所有可用工具的描述，包括名称、功能说明、参数定义。

80
00:07:23,812 --> 00:07:30,987
第二步上下文构建，客户端把工具列表翻译成模型能理解的格式，塞进系统提示词里。

81
00:07:30,987 --> 00:07:41,119
第三步模型推理，模型分析用户问题和可用工具，决定要不要调、调哪个，这个判断基于工具描述和当前对话上下文。

82
00:07:41,119 --> 00:07:47,165
第四步工具执行，客户端通过服务器把选定的工具跑起来，拿到结果。

83
00:07:47,165 --> 00:07:53,331
第五步结果整合，结果回到模型手里，模型结合它生成最终回答。

84
00:07:53,331 --> 00:07:56,408
这里有个很容易被忽略的关键点。

85
00:07:56,408 --> 00:08:03,151
整个过程是完全自动的，模型是根据工具描述的质量来决定用不用、怎么用。

86
00:08:03,151 --> 00:08:08,523
所以写清楚工具描述这件事，优先级比很多人想的高得多。

87
00:08:08,523 --> 00:08:12,994
描述写得含糊，再好的工具模型也不会用。

88
00:08:13,132 --> 00:08:16,351
搞清楚心智模型，再看怎么用。

89
00:08:16,301 --> 00:08:22,707
很多开发者会问一个很实在的问题，我已经在用函数调用了，为什么还要 MCP。

90
00:08:22,707 --> 00:08:27,154
教材的回答是，这俩不是竞争关系，是互补的。

91
00:08:27,154 --> 00:08:37,407
函数调用是模型自身的一项能力，体现的是模型内在的智能，它知道什么时候该调函数，也能把调用参数生成准确。

92
00:08:37,407 --> 00:08:47,959
而 MCP 扮演的是基础设施协议的角色，它在工程层面解决工具跟模型怎么连的问题，用标准化的方式去描述和调用工具。

93
00:08:47,959 --> 00:08:50,459
书里有个比方我很喜欢。

94
00:08:50,459 --> 00:08:58,224
函数调用相当于你学会了怎么打电话这项技能，什么时候拨号，怎么跟对方沟通，什么时候挂断。

95
00:08:58,224 --> 00:09:05,327
而 MCP 就是那个全球统一的电话通信标准，保证任何一部电话都能拨通另一部。

96
00:09:05,327 --> 00:09:07,142
再看传输方式。

97
00:09:07,142 --> 00:09:13,801
MCP 有个重要特性叫传输层无关性，协议本身不绑定某一种传输通道。

98
00:09:13,801 --> 00:09:16,830
基于 FastMCP 的实现一共五种。

99
00:09:16,830 --> 00:09:20,916
内存传输，适合单元测试和快速原型。

100
00:09:20,916 --> 00:09:27,995
标准输入输出传输，适合本地开发、调试和脚本型服务器，也是最常用的一种。

101
00:09:27,995 --> 00:09:33,152
HTTP 传输，适合生产环境、远程服务和微服务架构。

102
00:09:33,152 --> 00:09:37,743
SSE 传输，适合实时通信、流式处理和长连接。

103
00:09:37,743 --> 00:09:42,118
流式 HTTP 传输，适合需要双向流式通信的场景。

104
00:09:42,118 --> 00:09:43,885
选型不用纠结。

105
00:09:43,885 --> 00:09:51,649
本地调试用标准输入输出，上生产用 HTTP 或者流式 HTTP，写测试用内存传输。

106
00:09:51,649 --> 00:09:55,988
再讲一个框架里的实用特性，工具自动展开。

107
00:09:55,988 --> 00:10:06,601
你把一个 MCP 工具加到智能体上，它会自动把服务器提供的所有工具展开成一个个独立工具，智能体可以像调普通工具一样调它们。

108
00:10:06,601 --> 00:10:16,060
教材里的例子是个计算器服务，展开之后变成加法、减法、乘法、除法、问候、获取系统信息六个独立工具。

109
00:10:16,060 --> 00:10:18,236
这里有个坑要记一下。

110
00:10:18,236 --> 00:10:29,113
当你同时接多个 MCP 服务器时，务必给每个工具指定不同的名字，这个名字会作为前缀加到展开后的工具名前面，避免撞车。

111
00:10:29,113 --> 00:10:34,931
比如名字叫 fs，展开出来就是 fs 读文件、fs 写文件这样。

112
00:10:34,931 --> 00:10:38,921
最后是社区生态，这是 MCP 最大的优势之一。

113
00:10:38,921 --> 00:10:47,142
已经有大量现成的服务器摆在那儿，覆盖文件系统、数据库、各类接口服务，你不用从零写适配器。

114
00:10:47,142 --> 00:10:58,104
教材给了三个资源库，社区维护的精选列表、官方的服务器目录网站、还有官方组织直接维护的服务器仓库，后者质量和文档最完善。

115
00:10:58,104 --> 00:11:10,604
书里还举了几个组合案例，浏览器自动化工具做网页测试，笔记软件加搜索工具做智能笔记助手，项目管理工具和代码仓库串起来做自动化。

116
00:11:10,756 --> 00:11:16,258
MCP 解决的是智能体跟工具的交互，那智能体跟智能体之间呢。

117
00:11:16,208 --> 00:11:19,502
这就是智能体对智能体协议的地盘。

118
00:11:19,502 --> 00:11:21,100
动机很直接。

119
00:11:21,100 --> 00:11:30,511
在一个需要研究员、撰写员、编辑一起干活的任务里，它们得通信，得委托任务，得协商能力，得同步状态。

120
00:11:30,511 --> 00:11:35,487
传统的做法是搞一个中央协调器，也就是星型拓扑。

121
00:11:35,487 --> 00:11:37,795
这个方案有三个硬伤。

122
00:11:37,795 --> 00:11:41,689
单点故障，协调器一挂整个系统瘫痪。

123
00:11:41,689 --> 00:11:46,353
性能瓶颈，所有通信都过中心节点，并发上不去。

124
00:11:46,353 --> 00:11:52,290
扩展困难，每加一个智能体或者改一个智能体，都要动中心的逻辑。

125
00:11:52,290 --> 00:12:01,040
智能体对智能体协议改用点对点架构，也就是网状拓扑，让智能体直接通信，从根上避开这三个问题。

126
00:12:01,040 --> 00:12:07,579
它的核心是两个抽象概念，任务和工件，这也是它跟 MCP 最大的区别所在。

127
00:12:07,579 --> 00:12:18,288
为了让协作过程可管理，协议给任务定义了标准化的生命周期，包括创建、协商、代理、执行中、完成、失败这些状态。

128
00:12:18,288 --> 00:12:24,273
有了这套状态机，智能体才能做任务协商、进度跟踪和异常处理。

129
00:12:24,273 --> 00:12:31,509
请求的一次生命周期分四步，代理发现、身份验证、发送消息接口、发送消息流接口。

130
00:12:31,509 --> 00:12:35,896
在框架里的用法也不复杂，有统一的工具包装器。

131
00:12:35,896 --> 00:12:39,442
教材给了一个完整的智能客服系统案例。

132
00:12:39,442 --> 00:12:48,720
系统里有三个智能体，接待员负责分析客户问题类型，技术专家负责回答技术问题，销售顾问负责回答销售问题。

133
00:12:48,720 --> 00:12:54,285
接待员接住问题，分派给对应的专家，专家回答之后再汇总回来。

134
00:12:54,285 --> 00:13:01,569
协议还支持智能体之间的协商机制，遇到边界模糊的任务可以互相讨价还价。

135
00:13:01,708 --> 00:13:03,448
最后是 ANP。

136
00:13:03,398 --> 00:13:05,958
它着眼的是更远的问题。

137
00:13:05,958 --> 00:13:16,475
当一个网络里存在大量功能各异的智能体，有做自然语言处理的，有做图像识别的，有做数据分析的，系统会面临三个挑战。

138
00:13:16,475 --> 00:13:21,860
服务发现，新任务来了，怎么快速找到能处理它的智能体。

139
00:13:21,860 --> 00:13:30,309
智能路由，好几个智能体都能干这活，怎么按负载、按成本挑最合适的那个并把任务派过去。

140
00:13:30,309 --> 00:13:35,466
动态扩展，新加入的智能体怎么被其他成员发现和调用。

141
00:13:35,466 --> 00:13:37,737
它的主体流程分三步。

142
00:13:37,737 --> 00:13:40,261
第一步是服务的发现与匹配。

143
00:13:40,261 --> 00:13:48,446
智能体通过一个公开的发现服务，基于语义或者功能描述去查询，定位到符合需求的另一个智能体。

144
00:13:48,446 --> 00:13:57,076
这个发现服务会预先爬取各智能体对外暴露的标准描述端点，建立索引，实现供需双方的动态匹配。

145
00:13:57,076 --> 00:14:14,460
第二步是基于去中心化身份标识的身份验证，请求发起方用自己的私钥对包含自身标识的请求签名，接收方解析这个标识拿到对应的公钥，用公钥验证签名的真实性和请求的完整性，这样双方就建立起可信通信。

146
00:14:14,460 --> 00:14:24,424
第三步是标准化的服务执行，验证通过后，双方按预先定义好的标准接口和数据格式做数据交换或者服务调用。

147
00:14:24,424 --> 00:14:35,253
这个机制的核心价值在于，用去中心化身份标识搭了一个不需要中央机构的信任根基，再配上标准化的描述协议实现服务的动态发现。

148
00:14:35,253 --> 00:14:42,477
智能体可以在没有中央协调的前提下，安全高效地在开放网络上形成协作网络。

149
00:14:42,477 --> 00:14:44,736
现在说代价和边界。

150
00:14:44,736 --> 00:14:46,647
这一节请认真听。

151
00:14:46,647 --> 00:14:50,277
第一，协议解决的是连接，不是智能。

152
00:14:50,277 --> 00:14:55,181
工具描述写得再标准，模型该判断错还是会判断错。

153
00:14:55,181 --> 00:14:58,486
别指望引入协议就自动提升效果。

154
00:14:58,486 --> 00:15:01,780
第二，别在协议早期阶段造轮子。

155
00:15:01,780 --> 00:15:11,948
教材明确说了，这一章以应用为主，目标是拥有在自己项目里应用协议的能力，不需要花太多精力去重复实现协议本身。

156
00:15:11,948 --> 00:15:15,902
第三，MCP 服务器的时效性取决于维护者。

157
00:15:15,902 --> 00:15:22,044
生态里工具质量参差不齐，越是有大公司背书的实现，越值得优先选用。

158
00:15:22,044 --> 00:15:26,828
第四，ANP 目前还处在概念阶段，生态还不成熟。

159
00:15:26,828 --> 00:15:33,883
你要是真要在生产里做大规模服务发现，得想清楚自己愿不愿意承担踩坑成本。

160
00:15:34,012 --> 00:15:37,423
最后收一批能直接带走的判断依据。

161
00:15:37,373 --> 00:15:40,967
第一，先用场景反推协议，不要反过来。

162
00:15:40,967 --> 00:15:48,755
你的智能体是要接外部服务，还是要跟别的智能体协作，还是要在一个大规模网络里找服务。

163
00:15:48,755 --> 00:15:51,748
这三个问题分别对应三种协议。

164
00:15:51,748 --> 00:15:55,510
把场景说清楚，选型基本就没有悬念了。

165
00:15:55,510 --> 00:15:59,260
接文件、数据库、接口，用 MCP。

166
00:15:59,260 --> 00:16:03,274
多智能体分工协作，用智能体对智能体协议。

167
00:16:03,274 --> 00:16:06,784
大规模开放网络的服务发现，看 ANP。

168
00:16:06,784 --> 00:16:13,070
第二，判断一个 MCP 集成做得好不好，看工具描述，不看工具数量。

169
00:16:13,070 --> 00:16:17,686
因为模型是完全依据描述来决定用不用、怎么用。

170
00:16:17,686 --> 00:16:21,375
描述写得含糊，工具堆一百个也是摆设。

171
00:16:21,375 --> 00:16:24,500
这条是投入产出比最高的一条。

172
00:16:24,500 --> 00:16:28,395
第三，传输方式按环境选，不要凭手感。

173
00:16:28,395 --> 00:16:37,229
本地开发调试用标准输入输出，生产远程服务用 HTTP 或者流式 HTTP，单元测试用内存传输。

174
00:16:37,229 --> 00:16:42,625
五种传输方式各有一个明确的适用场景，没有哪个是万能的。

175
00:16:42,625 --> 00:16:46,171
第四，多服务器接入一定要起前缀名。

176
00:16:46,171 --> 00:16:52,181
每个 MCP 工具指定不同的名字，展开后自动加前缀，避免工具名撞车。

177
00:16:52,181 --> 00:16:57,397
这是那种不出问题没人记得、一出问题排查半天的细节。

178
00:16:57,397 --> 00:17:00,750
第五，分清协议和模型能力的边界。

179
00:17:00,750 --> 00:17:08,551
函数调用是模型内在的能力，MCP 是工程层的连接标准，两者互补而不是替代。

180
00:17:08,551 --> 00:17:13,960
把协议当成放大模型能力的杠杆，而不是替代模型能力的方案。

181
00:17:13,960 --> 00:17:21,303
生态里已经有覆盖文件系统、数据库、各类接口的现成服务器，能复用就别自己写。

182
00:17:21,303 --> 00:17:23,118
这一集就到这里。

183
00:17:23,118 --> 00:17:25,546
下一集我们继续往下走。

184
00:17:25,546 --> 00:17:27,265
感谢收听。