Agent 速成笔记 · 第 10 章智能体通信协议

源：Datawhale《Hello-Agents》第 10 章｜定位：概念原理 + 工程实现｜一句话：给智能体补上"与工具通信、与同行通信、在大网络里被找到"这三层标准接口

0. 一章速览（30 秒）

一句话：单体智能体能力再强也受限于"手写适配器"，于是需要三层标准化接口——MCP 管智能体与工具、A2A 管智能体与智能体、ANP 管大规模网络里的发现与路由。
本章解决什么问题：把"每个外部服务都要手写一个 Tool 类、多智能体只能手动编排"的困境，替换成"接入协议、自动发现、自动调用"。
必须记住的 4 个点：
- MCP 三件套：Host / Client / Server 三层架构 + Tools / Resources / Prompts 三类能力，传输方式与协议本身解耦（Transport Agnostic）。
- MCP ≠ Function Calling：前者是工程层面的连接标准，后者是模型内在的调用能力，二者互补而非竞争。
- A2A 的核心是 Task 与 Artifact：以点对点（网状）取代中央协调器（星型），解决单点故障、性能瓶颈、扩展困难。
- ANP 的信任根是 DID：靠 .well-known/agent-descriptions 做服务发现，靠 DID 签名做身份验证，实现去中心化服务发现与智能路由。

1. 为什么需要通信协议（10.1）

1.1 单体智能体撞上的三堵墙

第 7 章的 ReAct 智能体已经能推理、能调工具，但把它放进真实工程就暴露三个根本性限制：

工具集成困境——每接入一个新服务（GitHub API、数据库、文件系统、Slack），就要写一个专门的 Tool 类。后果是：代码重复（每个工具都要自己处理 HTTP、错误处理、认证）、难以维护（API 一变要改一圈）、无法复用（别人写的工具装不进来）、扩展性差（加服务等于加编码量）。
能力扩展瓶颈——智能体的能力被预先定义的工具集锁死，无法在运行时动态发现和使用新服务。
协作缺失——任务复杂到需要"研究员 + 撰写员 + 编辑"这类多角色分工时，只能靠手动编排去协调它们。

一句话：问题不在"模型不够聪明"，而在"接口没有标准"。

1.2 协议带来的四个改变

通信协议的价值是提供标准化的接口规范，让智能体以统一方式访问各种外部服务，无需为每个服务写适配器。原文的类比是 TCP/IP：它让不同设备互通，而不必为每种设备写专门通信代码。

具体收益有四条：标准化接口（不同服务统一访问方式）、互操作性（不同开发者的工具无缝集成）、动态发现（运行时发现新能力）、可扩展性（轻松添加功能模块）。

代码层面的差别很直观。传统写法是逐个手写 GitHubTool / DatabaseTool / WeatherTool 再逐个 add_tool；有协议之后变成声明式接入：

mcp_tool = MCPTool()  # 内置服务器提供基础工具
github_mcp = MCPTool(server_command=["npx", "-y", "@modelcontextprotocol/server-github"])
agent.add_tool(github_mcp)   # 无需手写适配器

这段在干什么：用一个通用的 MCPTool 替代了 N 个手写 Tool 类，工具从"自己实现"变成"连接别人实现好的服务器"。

1.3 三种协议的设计理念

协议	提出方	设计哲学	解决的通信关系
MCP	Anthropic	上下文共享	智能体 ↔ 工具 / 资源
A2A	Google	对等通信	智能体 ↔ 智能体
ANP	开源社区（概念性框架）	去中心化服务发现	智能体 ↔ 智能体网络

MCP（Model Context Protocol）：不只是 RPC。它允许智能体与工具共享丰富上下文——例如访问代码仓库时，服务器不只给文件内容，还能给代码结构、依赖关系、提交历史，让智能体做出更聪明的决策。这就是"上下文共享"的含义。
A2A（Agent-to-Agent Protocol）：每个智能体既是服务提供者也是服务消费者，既能主动发起请求也能响应别人；对等设计避免了中心化协调器的瓶颈，网络更灵活可扩展。
ANP（Agent Network Protocol）：定位是"智能体的互联网"。当网络里有成百上千个智能体，问题变成"如何找到需要的服务"。ANP 提供服务注册、发现与路由机制，让智能体动态发现网络中其他服务，而不用预先配置所有连接关系。

三者的层级很清晰：MCP 解决"如何访问工具"，A2A 解决"如何与其他智能体对话"，ANP 解决"如何在大规模网络中发现和连接智能体"。

1.4 协议选型规则（工程结论）

判断标准只有一句：看你缺的是哪一层。

智能体要访问外部服务（文件、数据库、API）→ 选 MCP
需要多个智能体互相协作完成任务 → 选 A2A
要构建大规模智能体生态系统 → 考虑 ANP

补充两条工程提醒：一是协议仍处发展早期，MCP 生态相对成熟；二是各种工具的时效性取决于维护者，更推荐选择大公司背书的 MCP 工具。三者并不互斥，可以组合使用。

1.5 HelloAgents 的三层架构

框架的集成设计目标：让学习者用最简单的方式使用协议，同时保留应对复杂场景的灵活性。从下到上三层：

协议实现层：MCP 基于 FastMCP 实现（客户端 + 服务器）；A2A 基于 Google 官方 a2a-sdk；ANP 是自研轻量实现（官方另有实现，但此处只做概念模拟，便于后续迭代）。
工具封装层：把协议封成统一的 Tool 接口——MCPTool、A2ATool、ANPTool 都继承 BaseTool，提供一致的 run() 方法。这一步是"协议能进智能体"的关键，因为它把三种异构协议抹平成同一种东西。
智能体集成层：所有智能体（ReActAgent、SimpleAgent 等）都通过 Tool System 使用协议工具，完全不感知底层协议细节。

对应的目录结构是 protocols/mcp/（client 支持 5 种传输、server 为 FastMCP 封装、utils 提供 create_context/parse_context）、protocols/a2a/implementation.py、protocols/anp/implementation.py，以及 tools/builtin/protocol_tools.py 里的三个协议工具包装器。

2. MCP：智能体与工具的桥梁（10.2）

2.1 三层架构：Host / Client / Server

MCP 常被比作智能体的 USB-C：统一了智能体与外部工具的交互方式，无论底层是 Claude、GPT 还是别的模型，只要支持 MCP 就能无缝访问同一批工具和资源。

按"我在 Claude Desktop 上问'桌面上有哪些文档？'"这个场景拆解三层：

角色	承担者	职责
Host（宿主层）	Claude Desktop	接收用户提问、与模型交互、管理整个对话流程
Client（客户端层）	Host 内置的 MCP Client	与对应 MCP Server 建立连接、发请求、收响应
Server（服务器层）	文件系统 MCP Server	执行实际的文件扫描，访问目录并返回结果

完整链路是：用户问题 → Host → 模型分析 → 判断需要文件信息 → MCP Client 建立连接 → 文件系统 Server 执行操作 → 返回结果 → 模型生成回答 → 显示在 Host 上。

这套设计的精髓是关注点分离：Host 只管用户体验，Client 只管协议通信，Server 只管具体功能。所以开发者只需要写 MCP Server，不必关心 Host 与 Client 怎么实现——这正是生态能爆发的原因。

2.2 三类核心能力：Tools / Resources / Prompts

这是 MCP 最容易被混淆的地方，区别在于方向性：

能力	性质	作用
Tools	主动	执行操作（模型决定调用）
Resources	被动	提供数据（被读取）
Prompts	指导性	提供提示模板

客户端侧的对应方法：工具用 list_tools() / call_tool()；资源用 list_resources() / read_resource(uri)（资源以 URI 标识，如 file:///path/to/resource）；提示用 list_prompts() / get_prompt(name, args)。

记忆锚点：Tools 做事，Resources 供数据，Prompts 给模板。

2.3 模型是怎么"挑工具"的：五步流程

关键问题：LLM 如何决定用哪些工具？答案是一个完全自动化的五步循环：

工具发现：Client 连上 Server 后先调用 list_tools()，拿到全部工具的名称、功能说明、参数定义。
上下文构建：Client 把工具列表转成 LLM 能理解的格式，塞进系统提示词。形如：

你可以使用以下工具：
- read_file(path: str): 读取指定路径的文件内容
- search_code(query: str, language: str): 在代码库中搜索

模型推理：LLM 结合用户问题、工具描述与当前对话上下文，判断要不要调、调哪个。
工具执行：Client 通过 Server 执行被选中的工具，拿到结果。
结果整合：结果回送给 LLM，由 LLM 生成最终回答。

工程要点：整个决策完全依赖工具描述的质量，所以编写清晰准确的工具描述至关重要——描述写得含糊，模型就选错工具。

2.4 MCP 与 Function Calling：互补，不是竞争

这是高频易混点，必须说清：

Function Calling 是大语言模型的一项核心能力，体现模型内在的智能——理解何时需要调用函数，并精准生成调用参数。
MCP 是基础设施协议，在工程层面解决"工具与模型如何连接"，用标准化方式描述和调用工具。

原文的类比：Function Calling 相当于你学会了"如何打电话"（何时拨号、如何沟通、何时挂断）；MCP 则是那个全球统一的电话通信标准，保证任何一部电话都能拨通另一部。

Function Calling 的工程痛点很具体。同一个"搜 GitHub"工具，OpenAI 格式用 "parameters" 描述参数，Claude 格式用 "input_schema"；响应侧也要分别判断 response.choices[0].message.tool_calls 和 response.content[0].type == "tool_use"。每换一个模型供应商，就要重写一遍定义与解析。换成 MCP 后，连上社区服务器即可：

github_client = MCPClient(["npx", "-y", "@modelcontextprotocol/server-github"])
async with github_client:
    tools = await github_client.list_tools()             # 自动发现
    result = await github_client.call_tool("search_repositories", {"query": "AI agents"})

这段在干什么：用统一的发现 + 调用接口替掉了"每供应商一份 schema + 一套响应解析"，调用方式与模型解耦。

2.5 传输方式：Transport Agnostic 与五种通道

MCP 的重要特性是传输层无关性：协议本身不绑定特定传输方式，可在不同通信通道上运行。HelloAgents 的 MCPClient（基于 FastMCP 2.0）支持五种：

传输方式	适用场景	接入写法要点
Memory	单元测试、快速原型	不传参，用内置演示服务器
Stdio	本地开发、调试、Python 脚本服务	`server_command=[...]` 启动本地进程
HTTP	生产环境、远程服务、微服务	`MCPClient("http://.../mcp")`
SSE	实时通信、流式处理、长连接	`transport_type="sse"`
StreamableHTTP	需要双向流式的 HTTP 场景	`transport_type="streamable_http"`

两条关键工程约束：

MCPTool 主要覆盖 Stdio 与 Memory；要用 HTTP / SSE / StreamableHTTP 这类远程传输，应直接用底层的 MCPClient。
底层通信采用 JSON-RPC 2.0，Stdio 模式即通过标准输入输出做进程间通信。好处是本地部署零网络依赖、天然隔离；代价是不适合跨主机、需要额外机制才能远程化。

2.6 客户端与服务端的最小骨架

客户端侧的三件事：连接、发现、调用。连接用 async with 确保正确关闭，官方提供异步与同步两套 API，推荐异步（更好处理并发与长任务）。

服务端侧更简单——建服务器、注册函数、启动：

from hello_agents.protocols import MCPServer
weather_server = MCPServer(name="weather-server", description="真实天气查询服务")
weather_server.add_tool(get_weather)              # 普通 Python 函数即工具
weather_server.add_tool(list_supported_cities)
weather_server.run()

这段在干什么：把一个普通函数直接登记为 MCP 工具，函数名成为工具名、docstring 成为工具描述——这就是自建 MCP 服务器的全部核心概念。

2.7 在智能体中使用 MCP：自动展开机制

这是本章最实用的机制。MCPTool 的自动展开特性会：当你把一个 MCP 工具加入 Agent 时，它把服务器提供的所有工具展开为独立工具，让 Agent 像调普通工具一样调它们。

内部发生三件事：

MCPTool 连接服务器，发现 N 个工具；
为每个工具创建包装器，并加上 name 前缀——name="fs" 会展开成 fs_read_text_file、fs_write_file …；
注册进 Agent 的工具注册表。

调用时的转换也很关键：Agent 生成的是 [TOOL_CALL:calculator_multiply:a=25,b=16] 这样的文本参数，包装器会把它翻译成 MCP 协议格式：

{"action": "call_tool", "tool_name": "multiply", "arguments": {"a": 25.0, "b": 16.0}}

并且按工具的 JSON Schema 自动做类型转换：Agent 给的 "25" 是字符串，系统转成数字 25.0 再发给服务器。

三条工程要点：多个 MCP 服务器必须指定不同的 name，否则展开后的工具名会冲突；需要显式控制时可用 get_expanded_tools() 手动展开并逐个注册；MCPTool.run() 的动作参数是 action，取值为 list_tools 或 call_tool。

2.8 社区生态

MCP 的最大优势是现成服务器多，不必从零写适配器。三个资源库：Awesome MCP Servers（社区精选列表）、MCP Servers Website（目录网站，可搜索筛选）、Official MCP Servers（Anthropic 官方维护，质量最高、文档最完善）。典型组合场景包括 Playwright 自动化网页测试、Obsidian + Perplexity 笔记助手、Jira + GitHub 项目管理、YouTube + Notion + Spotify 内容创作工作流。

3. A2A：智能体间的点对点协作（10.3）

3.1 设计动机：为什么不要中央协调器

MCP 解决"智能体与工具"，A2A 解决"智能体与智能体"。当研究员、撰写员、编辑需要协作时，它们必须能通信、委托任务、协商能力、同步状态。

传统做法是中央协调器（星型拓扑），它有三个硬伤：

单点故障：协调器一挂，整个系统瘫痪；
性能瓶颈：所有通信都过中心节点，并发被卡死；
扩展困难：增减或修改智能体都要改动中心逻辑。

A2A 改用点对点（网状拓扑），智能体直接通信，从根上消掉这三个问题。

3.2 核心抽象：Task 与 Artifact

A2A 的核心是任务（Task）和工件（Artifact）两个抽象概念，这是它与 MCP 最大的区别。MCP 的交互单位是"一次工具调用"，A2A 的交互单位是"一件有状态、可协商、可交付的任务"。

任务的状态由标准化生命周期管理，包含创建、协商、代理、执行中、完成、失败等状态，使智能体可以任务协商、进度跟踪与异常处理——这是"对话式协作"落到实处的地方。

能力声明方面，服务端在构造时就公开自己的身份与能力，并用装饰器逐条登记技能：

calculator = A2AServer(
    name="calculator-agent",
    description="专业的数学计算智能体",
    version="1.0.0",
    capabilities={"math": ["addition", "subtraction", "multiplication", "division"],
                  "advanced": ["power", "sqrt", "factorial"]}
)

@calculator.skill("add")
def add_numbers(query: str) -> str:
    ...

这段在干什么：name/description/version/capabilities 构成对外的能力自描述，@skill 把函数登记为可被远程调用的技能，最终汇入 calculator.skills 字典。这类"我是谁、我能做什么"的描述，在 A2A 规范中被称为 Agent Card。

3.3 请求生命周期四步

A2A 的请求是一串有序动作，共四步：代理发现 → 身份验证 → 发送消息 API → 发送消息流 API。整条链路涉及三类参与者：客户端、A2A 服务器、身份验证服务器。

对应地，消息模型有两个入口：发送消息 API 用于一次性请求 / 响应，发送消息流 API 用于流式过程；配合 Task 生命周期状态，就能表达"任务已提交、正在协商、正在执行、已完成"的完整过程语义。

3.4 服务端 / 客户端最小骨架

服务端起服务并保持运行：

researcher = A2AServer(name="researcher", description="负责搜索和分析资料的Agent", version="1.0.0")

@researcher.skill("research")
def handle_research(text: str) -> str:
    ...

researcher.run(host="localhost", port=5000)

客户端只需一个 URL 加技能名：

client = A2AClient("http://localhost:5000")
response = client.execute_skill("research", "research AI在医疗领域的应用")
print(response.get('result'))

多智能体网络就是多个服务各占一个端口（如 researcher 5000、writer 5001、editor 5002），协作顺序由调用方串起来：研究员产出结果 → 作为输入交给撰写员 → 撰写员的产出交给编辑 → 返回最终工件。

需要注意的现实约束：A2A 现有实现大部分是 Sample Code，即便有 Python 实现也较繁琐，所以本章采用模拟协议思想的方式、基于 a2a-sdk 继承部分功能来实现。

3.5 集成到 Agent 与协商机制

集成方式与 MCP 一致——用包装器并指定对端地址，让协调者智能体自己去调：

researcher_tool = A2ATool(name="researcher", description="研究员Agent，可以搜索和分析资料",
                          agent_url="http://localhost:5000")
coordinator.add_tool(researcher_tool)

这段在干什么：把一个远端 Agent 变成本地 Agent 的一个工具，协调者无需知道 A2A 协议细节。典型落地是智能客服系统：接待员用 LLM 判断问题类型（技术 / 销售），再分别转发给技术专家或销售顾问，最后整理回复。

A2A 还支持协商：一方提出提案（任务 + 截止时间），另一方评估后返回接受，或拒绝并附带反提案（例如"时间太紧，建议改为 7 天"）。协商能力是 A2A 相对 MCP 独有的一层——因为工具不会跟你讨价还价，但同行会。

4. ANP：大规模智能体网络（10.4）

4.1 三个待解问题

当网络里存在大量功能各异的智能体（NLP、图像识别、数据分析……），会出现新的挑战：

服务发现：新任务到达时，如何快速找到能处理它的智能体？
智能路由：多个智能体都能做同一件事，如何挑最合适的（按负载、成本）并分派？
动态扩展：新加入的智能体如何被其他成员发现和调用？

ANP 的设计目标就是提供一套标准化机制，解决服务发现、路由选择与网络扩展性。

4.2 三步架构流程（ANP 的核心机制）

原文借官方入门指南给出的流程分三步：

服务的发现与匹配：智能体 A 通过一个公开的发现服务，基于语义或功能描述发起查询，定位到满足需求的智能体 B。该发现服务预先爬取各智能体对外暴露的标准端点 .well-known/agent-descriptions 来建立索引，从而实现需求方与提供方的动态匹配。
基于 DID 的身份验证：交互开始时，A 用自己的私钥对包含自身 DID 的请求进行签名；B 收到后解析该 DID 取得对应公钥，据此验证签名真实性与请求完整性，建立可信通信。
标准化的服务执行：验证通过后 B 响应请求，双方按预定义的标准接口和数据格式交换数据或调用服务（如预订、查询）。

整体机制的内核是：用 DID 构建去中心化的信任根基，用标准化描述协议实现服务的动态发现。这使得智能体无需中央协调，就能在互联网上安全高效地形成协作网络——这正是 ANP 与 A2A 的分工差别：A2A 假设"我已经知道要跟谁说话"，ANP 解决"我如何找到该跟谁说话"。

4.3 服务注册、发现与网络构建

ANP 的接口围绕"注册—发现—组网"三件事：

discovery = ANPDiscovery()

register_service(
    discovery=discovery, service_id="nlp_agent_1", service_name="NLP处理专家A",
    service_type="nlp", capabilities=["text_analysis", "sentiment_analysis", "ner"],
    endpoint="http://localhost:8001",
    metadata={"load": 0.3, "price": 0.01, "version": "1.0.0"}
)

nlp_services = discover_service(discovery, service_type="nlp")
best_service = min(nlp_services, key=lambda s: s.metadata.get("load", 1.0))

这段在干什么：注册时声明能力（capabilities）+ 端点（endpoint）+ 元数据（metadata），发现时按 service_type 过滤，再用 metadata 里的指标做选择决策——load、price、version 就是路由依据。

组网则由 ANPNetwork(network_id=...) 承担，通过 add_node(service_id, endpoint) 加入节点、connect_nodes(a, b) 建立连接，最后 get_network_stats() 读取 total_nodes 等统计。

4.4 调度与负载均衡的落地形态

ANP 的价值在多节点场景才显现。典型示例是分布式任务调度：注册 10 个计算节点，每个节点在 metadata 里带 load、cpu_cores、memory_gb、gpu；再建一个 SimpleAgent 作调度器，挂上 ANPTool，让 LLM 依据任务需求（要 GPU？要高内存？）自行挑选节点并给出理由。

负载均衡则是更纯粹的规则式用法：注册 5 个 api 类型服务，每次挑 load 最小的那个，并在派发后把该节点 load 加 0.1 模拟占用。这说明了 ANP 的双重用法——既能喂给 LLM 做智能决策，也能直接当服务注册中心用。

5. 构建自定义 MCP 服务器与发布（10.5）

5.1 为什么还要自己写服务器

即便公开服务很多，四类场景必须自建：

封装业务逻辑：把企业内部特有流程封装成标准 MCP 工具；
访问私有数据：做一个安全可控的接口或代理，访问内部数据库、API 等无法暴露到公网的数据源；
性能专项优化：针对高频调用或严苛延迟要求做深度优化；
功能定制扩展：实现标准服务未提供的功能，例如集成专有算法模型或特定硬件。

5.2 可发布的最小项目形态

服务端本身很薄（建 MCPServer → add_tool(函数) → run()），真正的工程量在测试与打包发布。

测试端用客户端脚本连上本地服务器，逐个 call_tool 验证：先 get_server_info 确认服务活着，再 list_supported_cities 验证数据接口，最后实际查两个城市。在 Agent 中接入时有个细节值得记住：可以显式展开再注册，并对空结果做防御：

weather_tool = MCPTool(server_command=["python", server_script])
expanded_tools = weather_tool.get_expanded_tools()
if not expanded_tools:
    raise RuntimeError("未发现天气 MCP 子工具，请检查服务脚本、依赖和启动日志。")
for t in expanded_tools:
    assistant.add_tool(t)

这段在干什么：在启动阶段就暴露"子工具发现失败"，而不是等到模型调用时才报一个含糊的错误——服务脚本路径错、依赖缺失、启动日志异常都会被这里拦下来。

5.3 发布到 Smithery

Smithery 是 MCP 服务器的官方发布平台，地位类似 Python 的 PyPI 或 Node.js 的 npm：可搜索发现、一键安装、查看使用统计与评价、自动获取更新。

发布需要的文件构成标准包结构：README.md、LICENSE、Dockerfile（推荐但非必须，Smithery 会自动生成）、pyproject.toml（必需，后续会打包成 server）、requirements.txt、smithery.yaml（必需）、以及服务器主文件。

两个配置文件的要点：

smithery.yaml：核心字段为 name（唯一标识符，小写连字符）、displayName、description、version（语义化版本）、runtime、build、startCommand、以及 tools 列表（逐个声明工具名与描述）。
Dockerfile：基础镜像 python:3.12-slim-bookworm，工作目录 /app，端口 8081（Smithery 平台标准端口），启动命令 python server.py。

发布流程是：Fork 源码仓库 → 用自己的 GitHub 建立 weather-mcp-server 仓库并替换署名 → 在 Smithery 用 GitHub 账号登录后点 "Publish Server" 并填入仓库 URL。

发布成功后有三种使用方式，覆盖了 MCP 生态的三类宿主：Smithery CLI（smithery install / smithery run）、Claude Desktop 配置（在 mcpServers 里写 command 与 args）、HelloAgents（把 MCPTool(server_command=["smithery", "run", "weather-mcp-server"]) 交给 Agent）。

6. 三协议层次关系与对比

协议	谁对谁	解决什么	不解决什么
MCP	智能体 ↔ 工具/资源	统一工具描述与调用，模型无关	智能体间协作、大规模发现
A2A	智能体 ↔ 智能体	点对点任务协作、协商、状态同步	工具接入、网络级路由
ANP	智能体 ↔ 智能体网络	服务发现、智能路由、动态扩展	单次工具调用、双边任务语义

层次关系可以这样串起来理解：ANP 提供"找到谁"的网络底座 → A2A 提供"怎么谈"的点对点协作 → MCP 提供"怎么干活"的工具接入。三者面向不同粒度，可叠加使用。

三者的成熟度也有差异，工程上必须知道：MCP 生态最成熟（社区服务器大量可用、有官方发布平台）；A2A 实现多为样例代码，Python 侧较繁琐；ANP 仍是概念性协议框架，由开源社区维护、尚无成熟生态，本章的 ANP 实现是自研轻量版，只做概念模拟。

7. 工程实践要点

先分层再选型：工具接入需求一律走 MCP，智能体协作需求走 A2A，网络级发现需求才上 ANP。不要用 A2A 去做工具适配，也不要为了"架构先进"在三个智能体的小系统里上 ANP。
优先复用社区服务器，减少重复开发；但要注意工具时效性取决于维护者，优先选大公司背书的 MCP 服务。
传输方式按部署形态选：本地开发与调试用 Stdio，测试与原型用 Memory，生产远程用 HTTP，实时流式用 SSE，需要双向流式再上 StreamableHTTP。注意 MCPTool 只覆盖 Stdio / Memory，远程场景必须下沉到 MCPClient。
工具描述就是 Prompt：MCP 的工具选择完全自动，描述的清晰度直接决定调用正确率，这是最常见的"跑不通"根因。
多服务器必设 name 前缀，避免展开后工具名冲突。
在 Agent 里显式展开并做启动期校验，把"子工具发现失败"这类错误提前到启动阶段。

8. 高频考点 & 易错点速查

MCP 三层角色：Host（用户界面 + 对话管理）/ Client（协议通信）/ Server（功能实现），开发者只需写 Server。
MCP 三类能力的方向性：Tools 主动执行、Resources 被动供数据、Prompts 给模板。考"哪个是被动的"就在这里。
MCP 与 Function Calling 互补：FC 是模型内在能力，MCP 是基础设施协议；FC 会因供应商 schema 差异（parameters vs input_schema）而重复劳动。
传输层无关性：五种传输方式对应场景要能对上号；MCPTool 不等于 MCPClient。
自动展开：结果是 前缀_原名，调用时做 [TOOL_CALL:...] → MCP 格式的翻译与类型转换。
A2A 的 Task / Artifact 是与 MCP 的最大区别：MCP 的交互单位是工具调用，A2A 的是有状态任务。
A2A 两种拓扑的取舍：星型（中央协调器）有单点故障、性能瓶颈、扩展困难；网状（P2P）解决之。
A2A 任务生命周期状态与请求生命周期四步（代理发现、身份验证、发送消息 API、发送消息流 API）容易互相混淆，前者是任务状态机，后者是请求动作序列。
ANP 的信任根是 DID：私钥签名、对方解析 DID 取公钥验签；服务发现靠 .well-known/agent-descriptions 索引。
ANP 的合理定位：概念性框架、生态未成熟，本章为概念模拟——不要误记为"可直接用于生产的成熟协议"。
协议可组合不可替代，并注意 ANP 解决的是"发现与路由"，不与 A2A 的双边协作语义重叠。
章末习题考点映射：① 三协议设计理念差异（上下文共享 / 对话式协作 / 网络拓扑）与客服系统场景选型、三协议组合架构设计；② 扩展 MCP 服务器（数据库 / 可视化 / 报表）与工具间协作、Resources 与 Prompts 的设计目的与场景、JSON-RPC 2.0 over stdio 的优势局限与远程化扩展；③ A2A 增加"审稿人"角色的三方协作、冲突解决与协商 / 投票消息类型扩展、A2A 与 AutoGen/CAMEL 等框架的关系；④ 网络拓扑（星型 / 网状 / 分层）的规模演进、智能路由算法、关键节点故障的容错机制；⑤ 安全与隐私——MCP 危险工具的权限控制、A2A/ANP 的端到端加密与身份认证、大规模网络下的信任评估系统。

9. 与前后章节的衔接

本章的输入来自第 7 章的 ReAct 智能体（工具调用）与第 6 章的多智能体协作框架：那些章节解决了"智能体内部怎么想"，本章解决"智能体对外怎么接"。输出的是一层通信基础设施——MCP 让单体智能体的能力边界从"手写工具集"扩展到"整个社区的服务"，A2A 与 ANP 则把多智能体从"同进程内手动编排"推进到"跨主机、可发现、可协商"的网络形态。后续涉及部署、分布式协作与安全治理的内容，都会建立在这一层协议抽象之上。

10. 课后练习

在线试卷：https://md-quiz-online.app.workbuddy.host/

posted @ 2026-09-28 17:09 测试小罡阅读(9) 评论(0) 收藏举报

刷新页面返回顶部

小罡测试笔记

Agent 速成笔记 · 第 10 章智能体通信协议

Agent 速成笔记 · 第 10 章智能体通信协议

0. 一章速览（30 秒）

1. 为什么需要通信协议（10.1）

1.1 单体智能体撞上的三堵墙

1.2 协议带来的四个改变

1.3 三种协议的设计理念

1.4 协议选型规则（工程结论）

1.5 HelloAgents 的三层架构

2. MCP：智能体与工具的桥梁（10.2）

2.1 三层架构：Host / Client / Server

2.2 三类核心能力：Tools / Resources / Prompts

2.3 模型是怎么"挑工具"的：五步流程

2.4 MCP 与 Function Calling：互补，不是竞争

2.5 传输方式：Transport Agnostic 与五种通道

2.6 客户端与服务端的最小骨架

2.7 在智能体中使用 MCP：自动展开机制

2.8 社区生态

3. A2A：智能体间的点对点协作（10.3）

3.1 设计动机：为什么不要中央协调器

3.2 核心抽象：Task 与 Artifact

3.3 请求生命周期四步

3.4 服务端 / 客户端最小骨架

3.5 集成到 Agent 与协商机制

4. ANP：大规模智能体网络（10.4）

4.1 三个待解问题

4.2 三步架构流程（ANP 的核心机制）

4.3 服务注册、发现与网络构建

4.4 调度与负载均衡的落地形态

5. 构建自定义 MCP 服务器与发布（10.5）

5.1 为什么还要自己写服务器

5.2 可发布的最小项目形态

5.3 发布到 Smithery

6. 三协议层次关系与对比

7. 工程实践要点

8. 高频考点 & 易错点速查

9. 与前后章节的衔接

10. 课后练习

公告

小罡测试笔记

Agent 速成笔记 · 第 10 章 智能体通信协议

Agent 速成笔记 · 第 10 章 智能体通信协议

0. 一章速览（30 秒）

1. 为什么需要通信协议（10.1）

1.1 单体智能体撞上的三堵墙

1.2 协议带来的四个改变

1.3 三种协议的设计理念

1.4 协议选型规则（工程结论）

1.5 HelloAgents 的三层架构

2. MCP：智能体与工具的桥梁（10.2）

2.1 三层架构：Host / Client / Server

2.2 三类核心能力：Tools / Resources / Prompts

2.3 模型是怎么"挑工具"的：五步流程

2.4 MCP 与 Function Calling：互补，不是竞争

2.5 传输方式：Transport Agnostic 与五种通道

2.6 客户端与服务端的最小骨架

2.7 在智能体中使用 MCP：自动展开机制

2.8 社区生态

3. A2A：智能体间的点对点协作（10.3）

3.1 设计动机：为什么不要中央协调器

3.2 核心抽象：Task 与 Artifact

3.3 请求生命周期四步

3.4 服务端 / 客户端最小骨架

3.5 集成到 Agent 与协商机制

4. ANP：大规模智能体网络（10.4）

4.1 三个待解问题

4.2 三步架构流程（ANP 的核心机制）

4.3 服务注册、发现与网络构建

4.4 调度与负载均衡的落地形态

5. 构建自定义 MCP 服务器与发布（10.5）

5.1 为什么还要自己写服务器

5.2 可发布的最小项目形态

5.3 发布到 Smithery

6. 三协议层次关系与对比

7. 工程实践要点

8. 高频考点 & 易错点速查

9. 与前后章节的衔接

10. 课后练习

公告

Agent 速成笔记 · 第 10 章智能体通信协议

Agent 速成笔记 · 第 10 章智能体通信协议