Hello-Agents 第三部分-第十章总结：智能体通信协议
作者：逆境不可逃
技术永无止境
希望我的内容可以帮助到你！！！！！
大家吼 ! 我是 逆境不可逃 今天给大家带来文章《Hello-Agents 第三部分-第十章总结：智能体通信协议》.
Hello-Agents 官方地址:
本章的核心目标，是把前面章节里 “单个 Agent 会推理、会调用工具、会使用记忆” 的能力，推进到 “多个 Agent 和外部系统可以用统一协议协作” 的工程阶段。单体 Agent 可以独立完成任务，但一旦系统需要访问外部服务、复用社区工具、协调多个专业 Agent、在大规模网络中发现服务，就必须引入通信协议。
本章围绕三类协议展开：
MCP：Model Context Protocol，面向 “Agent 与工具 / 资源 / 提示模板” 的标准化通信。A2A：Agent-to-Agent Protocol，面向 “Agent 与 Agent” 的点对点协作。ANP：Agent Network Protocol，面向 “大规模 Agent 网络” 的服务发现、路由和拓扑管理。
一句话概括：MCP 让 Agent 能稳定接入外部能力，A2A 让多个 Agent 能协同完成任务，ANP 让大量 Agent 能被发现、选择和调度。HelloAgents 的设计重点是把这三种协议都封装成统一的 Tool，让 SimpleAgent、ReActAgent 等智能体无需关心底层协议细节。
配套代码建议按下面顺序阅读：
| 文件 | 关注点 |
|---|---|
01_TestConnect.py |
快速体验 MCPTool、ANPTool、A2ATool 的最小用法 |
02_Connect2MCP.py |
使用 MCPClient 连接 MCP 服务器、发现工具、调用工具和异常处理 |
03_GitHubMCP.py |
使用社区 GitHub MCP Server 搜索仓库 |
04_MCPTransport.py |
MCP 的 Memory、Stdio、npx、HTTP/SSE/StreamableHTTP 等传输方式 |
05_UseMCPToolInAgent.py |
把 MCP 服务器自动展开为 Agent 可调用的普通工具 |
06_MultiAgentDocumentAssist.py |
GitHub 搜索 Agent 与文档生成 Agent 的协作案例 |
07_SimpleA2AAgent.py |
创建简单 A2A 计算器 Agent，并通过 skill 暴露能力 |
08_CustomA2AAgent.py |
自定义 A2A Agent 技能 |
09_A2A_Server.py |
创建 A2A 服务端，注册研究员 Agent 的 research 技能 |
09_A2A_Client.py |
使用 A2AClient 调用远程 Agent skill |
09_A2A_Network.py |
研究员、撰写员、编辑三个 Agent 的链式协作 |
09_A2A_WithAgent.py |
把 A2A Agent 封装为 Tool 后接入 SimpleAgent |
10_A2ATool_Simple.py |
使用内置 A2ATool 连接远程 Agent |
10_CustomerService.py |
接待员、技术专家、销售顾问组成的智能客服系统 |
10_AgentNegotiation.py |
Agent 间协商、反提案与任务条件确认 |
11_ANPInit.py |
ANP 服务注册、发现和网络构建 |
12_ANPTaskDistribution.py |
任务调度 Agent 基于服务发现选择计算节点 |
13_ANPLoadBalancing.py |
基于负载元数据的服务选择和请求分配 |
14_weather_mcp_server.py |
自定义天气查询 MCP Server |
14_test_weather_server.py |
使用 MCPClient 测试自定义天气服务器 |
14_weather_agent.py |
将天气 MCP Server 接入 Agent |
weather-mcp-server/ |
发布到 Smithery 的 MCP Server 项目结构 |
1. 为什么需要智能体通信协议
前几章构建的 Agent 已经能调用工具，例如计算器、搜索工具、记忆工具、RAG 工具。但如果没有协议层，系统会出现三个典型瓶颈。
第一，工具集成成本高。 每接入一个外部系统，都要手写一个 Tool 适配器。GitHub、数据库、文件系统、天气 API、企业内部系统都有不同的认证方式、请求格式、错误处理和返回结构。工具越多，重复代码越多，维护成本越高。
第二，能力扩展不够动态。 传统 Tool 是预先写死在代码里的。Agent 只能使用开发者提前添加的工具，无法在运行时发现 “某个服务器现在提供了哪些能力”。这会限制社区工具复用，也会让大型系统的扩展变得很重。
第三，多 Agent 协作缺少标准。 复杂任务往往需要多个角色分工，例如研究员负责检索，撰写员负责组织文本，编辑负责质量控制。没有通信协议时，只能靠中心协调器或业务代码硬编码流程，任务委托、状态同步、失败恢复和协商机制都难以复用。
通信协议的价值是把这些交互标准化：
- 标准接口：外部能力以统一方式暴露，Agent 以统一方式调用。
- 互操作性：不同开发者、不同框架、不同语言实现的服务可以协作。
- 动态发现：Agent 可以先查询 “有哪些工具 / 服务”，再决定如何调用。
- 可扩展性：新增能力时优先新增协议服务，而不是改 Agent 内部逻辑。
- 工程边界：Host、Client、Server、Agent、Tool 各司其职，便于部署、监控和治理。
可以把第 10 章理解为 HelloAgents 的 “连接层”：前面章节解决 “Agent 自己能做什么”，本章解决 “Agent 如何连接外部能力和其他 Agent”。
2. 三种协议的定位
2.1 协议对比
| 协议 | 通信对象 | 核心理念 | 关键抽象 | 典型问题 | HelloAgents 封装 |
|---|---|---|---|---|---|
MCP |
Agent/LLM 与工具、资源、提示模板 | 上下文共享 | Host、Client、Server、Tools、Resources、Prompts | 如何统一接入外部服务 | MCPClient、MCPServer、MCPTool |
A2A |
Agent 与 Agent | 对话式协作、点对点通信 | Task、Artifact、Skill、Agent Card | 多个专业 Agent 如何协商和交付 | A2AServer、A2AClient、A2ATool |
ANP |
大规模 Agent 网络 | 服务发现、路由、拓扑 | Discovery、Service、Network、Routing | 如何在大量 Agent 中找到合适服务 | ANPDiscovery、ANPNetwork、ANPTool |
三者不是互相替代，而是解决不同层次的问题。
MCP是 “工具接入层”：让 Agent 调用文件系统、数据库、GitHub、浏览器、天气服务等外部能力。A2A是 “协作对话层”：让一个 Agent 把任务交给另一个 Agent，并拿回结果、工件或反馈。ANP是 “网络发现层”：当系统里有很多 Agent 或服务实例时，负责注册、发现、选择和路由。
2.2 为什么 MCP 强调上下文共享
MCP 不只是远程过程调用。它除了 Tools 之外，还定义了 Resources 和 Prompts，目标是让外部系统把 “可操作能力” 和 “相关上下文” 一起暴露给模型。
例如代码仓库 MCP Server 不应只提供 read_file，还可以提供：
- 当前仓库结构、依赖关系、文件列表等 Resources。
- 代码审查、测试生成、重构建议等 Prompts。
- 搜索文件、读取文件、写入文件、运行检查等 Tools。
模型是否能正确调用工具，很大程度取决于它是否理解工具语义、参数结构和上下文约束。因此 MCP 的核心不是 “多一个 API”，而是 “以模型友好的方式把外部世界接入上下文”。
2.3 为什么 A2A 强调对话式协作
A2A 的对象不是被动工具，而是拥有目标、技能和状态的 Agent。Agent 之间的交互更像团队协作：一方提出任务，另一方确认能力、执行、返回工件，必要时还要协商范围、截止时间、质量要求或失败处理。
所以 A2A 的重点不是 “函数名和参数”，而是：
- 任务如何描述。
- 任务状态如何推进。
- 结果如何以工件形式交付。
- 多个 Agent 对同一任务有不同意见时如何协商。
- 服务端 Agent 如何暴露自己的能力和身份。
这也是它和 MCP 的关键差异：MCP 调工具，A2A 找同事。
2.4 为什么 ANP 强调网络拓扑
当 Agent 数量从几个增加到几十、几百甚至上千时，问题就不再是 “两个 Agent 怎么通信”，而是：
- 新 Agent 如何被发现。
- 相同能力的多个 Agent 如何选最优。
- 某个节点故障后请求如何切换。
- 不同能力集群之间如何路由。
- 网络如何在规模扩大后仍然可管理。
因此 ANP 更关注服务注册、发现、路由、负载、拓扑结构和身份信任。它更像 Agent 世界里的服务治理层。
3. HelloAgents 的协议架构
HelloAgents 对通信协议采用三层设计：
智能体集成层
SimpleAgent / ReActAgent / 业务 Agent
通过 add_tool(...) 使用协议能力
工具封装层
MCPTool / A2ATool / ANPTool
统一继承 Tool，提供一致的 run(...) 接口
协议实现层
MCPClient / MCPServer
A2AClient / A2AServer
ANPDiscovery / ANPNetwork
对应源码结构可以这样理解：
hello_agents/
├── protocols/
│ ├── mcp/
│ │ ├── client.py
│ │ ├── server.py
│ │ └── utils.py
│ ├── a2a/
│ │ └── implementation.py
│ └── anp/
│ └── implementation.py
└── tools/builtin/
└── protocol_tools.py
上层 Agent 不直接处理协议细节，而是使用统一 Tool：
from hello_agents.tools import MCPTool, A2ATool, ANPTool
agent.add_tool(MCPTool(...))
agent.add_tool(A2ATool(...))
agent.add_tool(ANPTool(...))
这个设计延续了第 7、8、9 章的工具化思想：不把每种能力写进 Agent 内部，而是通过标准 Tool 挂载能力。区别在于第 10 章的 Tool 背后连接的是协议服务，而不只是本地函数。
4. MCP：Agent 与外部工具的标准连接
4.1 MCP 的核心架构
MCP 采用三层架构：
| 组件 | 职责 |
|---|---|
Host |
用户交互入口，例如 Claude Desktop、IDE、Agent 应用 |
Client |
运行在 Host 内或应用内，负责连接 MCP Server、发现能力、发送请求 |
Server |
真正提供工具、资源和提示模板，例如文件系统、GitHub、数据库 |
典型流程如下：
用户提出问题
-> Host 接收请求并调用模型
-> 模型判断需要外部能力
-> MCP Client 连接 MCP Server
-> Client 调用 list_tools/list_resources/list_prompts
-> 模型根据工具描述决定调用哪个工具
-> Client 发送 call_tool 请求
-> Server 执行实际操作并返回结果
-> 模型整合结果生成最终回答
这里最关键的一步是能力发现。Agent 不是靠开发者手写每个工具，而是先从 MCP Server 拿到工具名称、描述和 JSON Schema，再把这些信息转成模型可理解的上下文。
4.2 Tools、Resources、Prompts
MCP 的三类核心能力需要区分清楚：
| 能力 | 含义 | 特点 | 例子 |
|---|---|---|---|
Tools |
可执行操作 | 主动调用，会产生动作或计算结果 | read_file、search_repositories、query_database |
Resources |
可读取上下文 | 被动提供数据，类似只读资料 | 仓库结构、数据库 schema、项目配置 |
Prompts |
可复用提示模板 | 指导模型完成某类任务 | 代码审查模板、SQL 分析模板、报告生成模板 |
初学者最容易只关注 Tools，但 Resources 和 Prompts 在复杂系统中很重要。它们能把背景信息和任务方法标准化，减少每个 Agent 重复拼提示词、重复描述上下文。
4.3 MCP 与 Function Calling 的关系
Function Calling 和 MCP 不是竞争关系。Function Calling 是模型侧能力，解决 “模型如何决定调用函数以及生成参数”；MCP 是工程侧协议，解决 “工具如何被描述、发现、连接和调用”。
| 对比项 | Function Calling | MCP |
|---|---|---|
| 所在层次 | 模型接口能力 | 工具通信协议 |
| 关注点 | 模型生成函数调用参数 | 工具发现、连接、执行和上下文共享 |
| 跨模型复用 | 不同模型格式可能不同 | 协议统一，服务可复用 |
| 工具来源 | 通常由应用开发者手写 | 可使用社区或自定义 MCP Server |
| 工程价值 | 让模型会调用函数 | 让工具生态可以标准化接入 |
在实际系统里，常见组合是：模型通过 Function Calling 或工具调用机制决定要用某个工具，而应用层通过 MCP 把这个工具真正连接到外部服务。
4.4 使用 MCPClient
对应代码：02_Connect2MCP.py
MCP 客户端通常采用异步方式连接服务器：
import asyncio
from hello_agents.protocols import MCPClient
async def discover_tools():
client = MCPClient([
"npx", "-y",
"@modelcontextprotocol/server-filesystem",
"."
])
async with client:
tools = await client.list_tools()
for tool in tools:
print(tool["name"], tool.get("description"))
asyncio.run(discover_tools())
调用工具时只需要提供工具名和参数字典：
async def use_tools():
client = MCPClient([
"npx", "-y",
"@modelcontextprotocol/server-filesystem",
"."
])
async with client:
result = await client.call_tool(
"read_file",
{"path": "my_README.md"}
)
print(result)
工程上需要注意两点：
- 使用
async with client管理连接生命周期，避免进程或连接泄露。 - 对工具调用做异常处理，因为 MCP Server 可能不可用、参数可能不合法、外部服务可能超时。
4.5 MCP 传输方式
对应代码：04_MCPTransport.py
HelloAgents 的 MCP 支持多种传输方式：
| 传输方式 | 适用场景 | 特点 |
|---|---|---|
| Memory | 单元测试、快速原型 | 不启动外部进程，适合本地演示 |
| Stdio | 本地开发、自定义脚本 | 通过标准输入输出与子进程通信 |
| Stdio + Args | 需要启动参数的本地服务 | 可传入配置、调试参数、目录路径 |
| npx | 使用 Node 社区 MCP Server | 自动下载并运行社区包 |
| HTTP/SSE/StreamableHTTP | 远程 MCP Server | 更适合线上服务，但要处理鉴权、网络和流式通信 |
简单示例：
from hello_agents.tools import MCPTool
# 内置演示服务器
mcp_tool = MCPTool()
# 本地 Python MCP Server
mcp_tool = MCPTool(server_command=["python", "my_mcp_server.py"])
# 社区文件系统 MCP Server
mcp_tool = MCPTool(
server_command=["npx", "-y", "@modelcontextprotocol/server-filesystem", "."]
)
实践建议：
- 学习和测试时用 Memory 或本地 Stdio。
- 使用成熟社区服务时用 npx，但要确认包来源、维护状态和权限范围。
- 生产环境中远程 MCP 要补齐认证、TLS、限流、审计、超时和重试。
4.6 MCPTool 的自动展开机制
对应代码：05_UseMCPToolInAgent.py
直接使用 MCPClient 适合写业务代码；接入 Agent 时更常用 MCPTool。它的关键能力是 “自动展开”：当你把一个 MCP Server 加到 Agent 上时，HelloAgents 会连接服务器、获取工具列表，然后把每个 MCP 工具包装成 Agent 工具注册进去。
from hello_agents import SimpleAgent, HelloAgentsLLM
from hello_agents.tools import MCPTool
agent = SimpleAgent(name="助手", llm=HelloAgentsLLM())
mcp_tool = MCPTool(name="calculator")
agent.add_tool(mcp_tool)
response = agent.run("计算 25 乘以 16")
print(response)
如果服务器提供 add、multiply 等工具，展开后可能变成：
calculator_add
calculator_subtract
calculator_multiply
calculator_divide
calculator_greet
calculator_get_system_info
使用多个 MCP Server 时必须注意命名：
fs_tool = MCPTool(
name="filesystem",
description="访问本地文件系统",
server_command=["npx", "-y", "@modelcontextprotocol/server-filesystem", "."]
)
custom_tool = MCPTool(
name="custom_server",
description="自定义业务逻辑服务器",
server_command=["python", "my_mcp_server.py"]
)
agent.add_tool(fs_tool)
agent.add_tool(custom_tool)
name 会成为展开工具名前缀。没有前缀时，不同服务器都提供 read_file、search、query 之类工具，很容易发生冲突。
4.7 MCP 实战：智能文档助手
对应代码：06_MultiAgentDocumentAssist.py
这个案例虽然叫 “多 Agent 协作”，但重点展示的是 MCP 对外部能力的接入：
GitHub 搜索专家
-> 使用 GitHub MCP Server 搜索 AI agent 仓库
-> 返回结构化搜索结果
文档生成专家
-> 接收搜索结果作为输入
-> 生成 Markdown 研究报告
-> 可使用文件系统 MCP Server 保存或读取文件
核心结构：
github_searcher = SimpleAgent(
name="GitHub搜索专家",
llm=HelloAgentsLLM(),
system_prompt="你是一个GitHub搜索专家..."
)
github_tool = MCPTool(
name="gh",
server_command=["npx", "-y", "@modelcontextprotocol/server-github"]
)
github_searcher.add_tool(github_tool)
再创建文档生成 Agent：
document_writer = SimpleAgent(
name="文档生成专家",
llm=HelloAgentsLLM(),
system_prompt="你是一个文档生成专家..."
)
fs_tool = MCPTool(
name="fs",
server_command=["npx", "-y", "@modelcontextprotocol/server-filesystem", "."]
)
document_writer.add_tool(fs_tool)
这个案例的工程启发是：一个 Agent 不必拥有所有能力。可以把任务拆给不同角色，每个角色只挂载自己需要的 MCP Server，降低工具上下文噪声，也降低误调用风险。
4.8 MCP 社区生态与使用原则
MCP 的优势之一是社区 Server 很多，例如文件系统、GitHub、数据库、浏览器自动化、项目管理、笔记系统等。选择时建议遵循：
- 优先选官方或大公司维护的 Server。
- 仅读写必要目录，不把整个磁盘暴露给文件系统 Server。
- 对写文件、删文件、执行命令、访问密钥等危险操作加人工确认。
- 明确区分开发环境和生产环境的权限。
- 给工具写清楚描述和参数 schema，因为模型依赖这些信息做工具选择。
- 对外部 MCP Server 做版本锁定，避免升级后工具名或参数结构变化。
5. A2A：Agent 与 Agent 的协作协议
5.1 A2A 的设计动机
MCP 解决的是 Agent 与工具之间的交互，而 A2A 解决的是 Agent 与 Agent 之间的协作。
如果任务需要研究员、撰写员、编辑、审稿人、客服专家等多个专业角色，只靠一个中心协调器会带来三个问题：
- 单点故障：协调器挂掉，整个协作流程中断。
- 性能瓶颈：所有消息都经过中心节点，并发能力受限。
- 扩展困难：新增 Agent 或修改协作规则都要改中心逻辑。
A2A 使用更偏点对点的方式，让 Agent 可以直接向其他 Agent 发任务、拿结果、协商条件。这使系统更接近 “团队协作” 而不是 “一个主程序调用一堆函数”。
5.2 A2A 的核心概念
| 概念 | 含义 |
|---|---|
| Agent | 可独立提供能力的智能体服务 |
| Skill | Agent 暴露出来的可调用能力 |
| Task | 一次被委托、执行、跟踪的任务 |
| Artifact | 任务产出的工件，例如报告、代码、分析结果 |
| Lifecycle | 任务从创建、协商、执行到完成或失败的状态流转 |
A2A 的重点是任务协作，而不是简单函数调用。一个复杂任务可能经历：
created
-> negotiating
-> accepted
-> running
-> completed
也可能进入：
created
-> rejected
-> revised
-> accepted
-> running
-> failed
所以真实系统里需要记录 task id、状态、发起方、接收方、超时、重试次数、产物和错误信息。
5.3 创建 A2A Agent
对应代码：07_SimpleA2AAgent.py、08_CustomA2AAgent.py
A2A 服务端的基本写法是创建 A2AServer，然后用装饰器注册 skill：
from hello_agents.protocols.a2a.implementation import A2AServer, A2A_AVAILABLE
calculator = A2AServer(
name="calculator-agent",
description="专业的数学计算智能体",
version="1.0.0",
capabilities={
"math": ["addition", "subtraction", "multiplication", "division"]
}
)
@calculator.skill("add")
def add_numbers(query: str) -> str:
parts = query.replace("计算", "").replace("加", "+")
numbers = [float(x.strip()) for x in parts.split("+")]
return f"计算结果: {sum(numbers)}"
自定义 Agent 也是同样模式：
agent = A2AServer(
name="my-custom-agent",
description="我的自定义智能体",
capabilities={"custom": ["greet", "calculate"]}
)
@agent.skill("greet")
def greet_user(name: str) -> str:
return f"你好，{name}！我是自定义智能体。"
需要注意：示例代码里的 eval 只适合教学演示。实际项目中不要直接对外部输入执行 eval，应改用安全解析器或明确的参数结构。
5.4 A2A 服务端与客户端
对应代码：09_A2A_Server.py、09_A2A_Client.py
服务端注册一个研究技能：
from hello_agents.protocols import A2AServer
researcher = A2AServer(
name="researcher",
description="负责搜索和分析资料的Agent",
version="1.0.0"
)
@researcher.skill("research")
def handle_research(text: str) -> str:
topic = text.replace("research", "").strip()
return str({
"topic": topic,
"findings": f"关于{topic}的研究结果...",
"sources": ["来源1", "来源2", "来源3"]
})
客户端调用：
from hello_agents.protocols import A2AClient
client = A2AClient("http://localhost:5000")
response = client.execute_skill(
"research",
"research AI在医疗领域的应用"
)
print(response.get("result"))
这里的关键点是：调用对象不是普通函数，而是一个远程 Agent 暴露的 skill。生产环境要补齐服务发现、鉴权、超时、错误码、幂等性和日志追踪。
5.5 A2A 多 Agent 网络
对应代码：09_A2A_Network.py
研究写作流程可以拆成三个 Agent：
researcher.research(topic)
-> writer.write(research_result)
-> editor.edit(article)
-> final artifact
这个模式适合任务边界清楚、产物可以逐步交接的场景。研究员不需要知道编辑规则，编辑也不需要知道怎么搜索资料，每个 Agent 专注自己的职责。
设计这类流程时，要重点关注：
- 上一个 Agent 的输出是否足够结构化，能被下一个 Agent 稳定解析。
- 每个阶段失败后如何重试或降级。
- 最终结果是否保留来源、修改意见和审批状态。
- 是否需要人工介入，例如编辑不通过时转人工审稿。
5.6 在 Agent 中使用 A2ATool
对应代码：10_A2ATool_Simple.py、10_CustomerService.py
A2ATool 可以把远程 Agent 包装成当前 Agent 的工具。客服系统示例中：
- 接待员是面向用户的入口 Agent。
- 技术专家是 A2A 服务，回答 API、集成、错误排查等问题。
- 销售顾问是 A2A 服务，回答价格、购买、版本差异等问题。
核心代码：
from hello_agents import SimpleAgent, HelloAgentsLLM
from hello_agents.tools import A2ATool
receptionist = SimpleAgent(
name="接待员",
llm=HelloAgentsLLM(),
system_prompt="你是客服接待员，负责分析问题类型并转发给专家。"
)
tech_tool = A2ATool(
agent_url="http://localhost:6000",
name="tech_expert",
description="技术专家，回答技术相关问题"
)
sales_tool = A2ATool(
agent_url="http://localhost:6001",
name="sales_advisor",
description="销售顾问，回答价格、购买相关问题"
)
receptionist.add_tool(tech_tool)
receptionist.add_tool(sales_tool)
这个案例说明 A2A 很适合 “前台分流 + 后台专家” 的系统。接待员不需要包含全部专业知识，只要判断问题类型并转交给合适 Agent。
5.7 Agent 间协商
对应代码：10_AgentNegotiation.py
A2A 不只支持单向委托，也可以支持协商。例如 Agent 2 发起任务提案，Agent 1 根据 deadline 判断是否接受，若不接受则给出反提案：
@agent1.skill("propose")
def handle_proposal(text: str) -> str:
proposal = eval(text.replace("propose", "").strip())
deadline = proposal.get("deadline")
if deadline >= 7:
return str({"accepted": True, "message": "接受提案"})
return str({
"accepted": False,
"message": "时间太紧",
"counter_proposal": {"deadline": 7}
})
真实系统中的协商消息建议结构化，例如：
{
"type": "negotiation",
"task_id": "task-001",
"proposal_id": "proposal-003",
"from": "writer",
"to": "reviewer",
"constraints": {
"deadline_days": 5,
"quality_level": "high",
"budget": 100
}
}
不要依赖自然语言字符串解析来完成关键业务协商。自然语言适合表达意图，关键约束应进入结构化字段。
6. ANP：大规模 Agent 网络的发现与路由
6.1 ANP 解决的问题
MCP 解决工具调用，A2A 解决点对点协作。但当系统里存在大量 Agent 时，还需要回答：
- 去哪里找能处理任务的 Agent。
- 多个 Agent 都能处理时，选哪一个。
- 某个 Agent 负载过高或故障时，如何切换。
- 新 Agent 加入网络后，其他 Agent 如何知道它。
- 网络扩大后，如何避免所有节点都互相直连造成管理混乱。
这就是 ANP 关注的问题：服务发现、智能路由、动态扩展和网络拓扑。
6.2 服务注册与发现
对应代码：11_ANPInit.py
基本流程：
from hello_agents.protocols import ANPDiscovery, register_service
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"}
)
发现服务：
from hello_agents.protocols import discover_service
nlp_services = discover_service(discovery, service_type="nlp")
best_service = min(
nlp_services,
key=lambda s: s.metadata.get("load", 1.0)
)
这里的 metadata 很关键。它让路由策略不只按服务类型匹配，还能考虑负载、价格、版本、延迟、区域、GPU、内存等约束。
6.3 构建 Agent 网络
ANP 可以把注册的服务组织成网络：
from hello_agents.protocols import ANPNetwork
network = ANPNetwork(network_id="ai_cluster")
for service in discovery.list_all_services():
network.add_node(service.service_id, service.endpoint)
network.connect_nodes("nlp_agent_1", "nlp_agent_2")
stats = network.get_network_stats()
网络拓扑会影响系统特性：
| 拓扑 | 适用场景 | 优点 | 风险 |
|---|---|---|---|
| 星型 | 小规模、中心协调明确 | 简单、可控、易监控 | 中心节点可能成为瓶颈 |
| 网状 | 小规模高协作网络 | 点对点灵活，少依赖中心 | 连接数量随规模快速上升 |
| 分层 | 大组织、多业务域 | 可分区治理，扩展性更好 | 层级设计和跨层路由更复杂 |
| 混合 | 大规模生产系统 | 可按业务、区域、能力分层 | 需要更成熟的服务治理 |
从 10 个 Agent 扩展到 1000 个 Agent 时，不应继续依赖全连接网状结构。更合理的演进是按能力、业务域或地理区域分组，每组内部协作，组间通过网关、路由节点或发现服务连接。
6.4 任务调度与负载均衡
对应代码：12_ANPTaskDistribution.py、13_ANPLoadBalancing.py
任务调度案例注册了多个计算节点，每个节点带有负载、CPU、内存、GPU 等元数据：
register_service(
discovery=discovery,
service_id=f"compute_node_{i}",
service_name=f"计算节点{i}",
service_type="compute",
capabilities=["data_processing", "ml_training"],
endpoint=f"http://node{i}:8000",
metadata={
"load": random.uniform(0.1, 0.9),
"cpu_cores": random.choice([4, 8, 16]),
"memory_gb": random.choice([16, 32, 64]),
"gpu": random.choice([True, False])
}
)
一个简单的负载均衡策略是选择负载最低的服务：
def get_best_server():
servers = discovery.discover_services(service_type="api")
if not servers:
return None
return min(servers, key=lambda s: s.metadata.get("load", 1.0))
更真实的路由可以采用打分模型：
score =
capability_match * 0.35
+ (1 - load) * 0.20
+ trust_score * 0.15
+ latency_score * 0.10
+ cost_score * 0.10
+ locality_score * 0.10
然后选择分数最高且健康检查通过的 Agent。这样比单纯按负载选择更稳，因为任务匹配度、可信度和延迟通常同样重要。
6.5 ANP 与 DID
第 10 章也提到 ANP 官方思路中会结合 .well-known/agent-descriptions 和 DID 身份机制。可以这样理解：
.well-known/agent-descriptions：让 Agent 对外暴露标准化描述，便于被发现服务爬取和索引。- DID：为 Agent 提供去中心化身份标识。
- 签名验证：请求方用私钥签名，接收方用 DID 解析出的公钥验证身份和消息完整性。
这解决的是开放网络中的信任问题：不仅要找到 Agent，还要确认 “它是谁”“它是否有权限”“消息有没有被篡改”。
7. 构建自定义 MCP Server
7.1 为什么要自定义 MCP Server
虽然社区 MCP Server 很多，但实际项目经常需要自定义服务：
- 封装企业内部业务逻辑，例如订单查询、库存校验、审批流。
- 安全访问私有数据，例如数据库、内部 API、知识库。
- 优化高频调用，例如缓存、批处理、连接池。
- 接入专有算法、硬件设备或组织内工具链。
自定义 MCP Server 的核心思路是：把业务能力包装成标准 MCP 工具，让 Agent 用统一方式调用。
7.2 天气查询 MCP Server
对应代码：14_weather_mcp_server.py
天气服务的结构很清晰：
from hello_agents.protocols import MCPServer
weather_server = MCPServer(
name="weather-server",
description="真实天气查询服务"
)
定义普通 Python 函数：
def get_weather(city: str) -> str:
"""获取指定城市的当前天气"""
try:
weather_data = get_weather_data(city)
return json.dumps(weather_data, ensure_ascii=False, indent=2)
except Exception as e:
return json.dumps({"error": str(e), "city": city}, ensure_ascii=False)
def list_supported_cities() -> str:
"""列出所有支持的中文城市"""
result = {"cities": list(CITY_MAP.keys()), "count": len(CITY_MAP)}
return json.dumps(result, ensure_ascii=False, indent=2)
注册到 MCP Server：
weather_server.add_tool(get_weather)
weather_server.add_tool(list_supported_cities)
weather_server.add_tool(get_server_info)
if __name__ == "__main__":
weather_server.run()
这个模式很适合封装业务 API。你只要把 “请求外部服务、清洗数据、错误处理” 的逻辑放进函数，再通过 add_tool 暴露给 MCP。
7.3 测试自定义 MCP Server
对应代码：14_test_weather_server.py
用 MCPClient 启动并连接本地脚本：
from hello_agents.protocols import MCPClient
client = MCPClient(["python", "14_weather_mcp_server.py"])
async with client:
info = await client.call_tool("get_server_info", {})
cities = await client.call_tool("list_supported_cities", {})
weather = await client.call_tool("get_weather", {"city": "北京"})
测试阶段建议覆盖：
- 工具列表是否正确。
- 每个工具参数是否符合预期。
- 外部 API 超时或失败时是否返回可理解错误。
- 中文城市名、未知城市名、空参数等边界情况。
- 返回内容是否稳定可解析，例如 JSON 字符串而不是随意自然语言。
7.4 在 Agent 中使用自定义 MCP Server
对应代码：14_weather_agent.py
from hello_agents import SimpleAgent, HelloAgentsLLM
from hello_agents.tools import MCPTool
assistant = SimpleAgent(
name="天气助手",
llm=HelloAgentsLLM(),
system_prompt="你是天气助手，可以查询城市天气。"
)
weather_tool = MCPTool(
server_command=["python", "14_weather_mcp_server.py"]
)
assistant.add_tool(weather_tool)
response = assistant.run("北京今天天气怎么样？")
这一步完成了 “业务函数 -> MCP Server -> MCPTool -> Agent” 的完整链路。
7.5 发布到 Smithery
对应代码目录：weather-mcp-server/
发布一个 MCP Server 通常需要整理成标准项目：
weather-mcp-server/
├── README.md
├── LICENSE
├── Dockerfile
├── pyproject.toml
├── requirements.txt
├── smithery.yaml
└── server.py
关键文件：
server.py：MCP Server 主入口。pyproject.toml：Python 项目元数据和依赖。requirements.txt：运行依赖。smithery.yaml：Smithery 平台识别服务名称、版本、工具列表和启动方式。Dockerfile：用于稳定构建运行环境。
发布流程大致是：
整理项目结构
-> 推送到 GitHub 仓库
-> 登录 Smithery
-> Publish Server
-> 填入仓库地址
-> 等待构建和发布
-> 通过 Smithery CLI、Claude Desktop 或 HelloAgents 使用
发布前要特别注意：
- 不要把 API Key、数据库密码写进仓库。
- README 要写清工具列表、参数、权限范围和示例。
- 工具名、描述、参数 schema 要稳定，避免用户升级后无法兼容。
- 对外部 API 增加超时、重试、限流和错误说明。
8. 三种协议如何组合使用
实际系统通常不会只用一种协议。一个完整智能客服系统可以这样设计：
用户
-> 客服入口 Agent
-> ANP：发现当前可用的专家 Agent 和负载信息
-> A2A：把问题委托给技术专家、销售顾问、投诉处理 Agent
-> MCP：专家 Agent 查询客户数据库、订单系统、知识库、工单系统
-> 客服入口 Agent 整理最终回复
职责划分：
MCP连接订单系统、客户数据库、文档知识库、CRM。A2A让接待员、技术专家、销售顾问、主管 Agent 协作。ANP负责发现可用专家、选择低负载实例、故障切换和扩容。
再看一个智能研究系统：
研究协调 Agent
-> ANP 发现研究员、数据分析员、写作员、审稿人
-> A2A 分派研究、分析、写作、评审任务
-> MCP 访问搜索引擎、GitHub、数据库、文件系统、引用管理工具
-> 聚合 Artifact 形成最终报告
这类组合设计的关键原则是：
- 外部系统接入用 MCP。
- 角色协调用 A2A。
- 大规模选择、调度和容错用 ANP。
- 上层 Agent 保持业务编排，不直接耦合底层服务实现。
9. 工程实践要点
9.1 工具和服务描述要写清楚
模型选择工具高度依赖描述。如果工具描述模糊，例如 “处理数据”“执行任务”，模型很难稳定选择。更好的描述应包含：
- 工具适合什么任务。
- 必填参数和参数含义。
- 返回结果结构。
- 不适合使用的场景。
- 可能的失败原因。
9.2 协议服务要最小权限
MCP Server 尤其要谨慎，因为它可能接触文件系统、数据库和命令执行能力。建议：
- 文件系统只暴露项目目录，不暴露用户主目录或整个磁盘。
- 数据库使用只读账号或最小权限账号。
- 写入、删除、执行命令类工具默认需要人工确认。
- 敏感操作必须有审计日志。
- 对网络访问、路径访问和参数大小做限制。
9.3 多 Agent 协作要结构化交付
A2A 的产物不要只靠自然语言传递。至少应包含：
{
"task_id": "task-001",
"status": "completed",
"artifact_type": "report",
"content": "...",
"sources": [],
"confidence": 0.86,
"warnings": []
}
结构化结果更利于后续 Agent 解析，也更利于日志追踪、错误恢复和质量评估。
9.4 ANP 路由要考虑健康状态
服务发现不等于服务可用。ANP 路由时应考虑：
- 最近心跳时间。
- 最近失败率。
- 平均延迟。
- 当前负载。
- 队列长度。
- 版本兼容性。
- 信任评分。
否则系统可能发现了一个 “注册过但实际不可用” 的 Agent。
9.5 协议版本要可治理
协议服务是跨进程、跨团队、甚至跨组织的接口。必须注意：
- 工具名和参数变更要做版本管理。
- 废弃字段保留兼容期。
- 客户端和服务端都记录协议版本。
- 错误码和错误结构要稳定。
- 关键服务要有回滚方案。
10. 本章核心总结
本章可以压缩成一张选型表：
| 需求 | 优先选择 |
|---|---|
| Agent 需要访问文件、数据库、GitHub、浏览器、业务 API | MCP |
| 多个专业 Agent 要分工、委托、反馈、协商 | A2A |
| 系统有大量 Agent，需要注册、发现、路由、负载均衡 | ANP |
| 要把内部业务能力开放给 Agent | 自定义 MCPServer |
| 要把远程专家 Agent 接入当前 Agent | A2ATool |
| 要让 Agent 根据能力和负载选择服务 | ANPTool |
学习本章时不要陷入 “协议名字很多” 的表面复杂度。真正要掌握的是三层边界：
- 工具层：外部能力如何标准化暴露，重点是 MCP。
- 协作层：多个 Agent 如何交付任务和工件，重点是 A2A。
- 网络层：大量服务如何发现、选择和治理，重点是 ANP。
这三层加在一起，构成了从单体 Agent 到多 Agent 系统、再到开放 Agent 网络的基础设施。
习题解析
习题 1：三种协议的设计理念与组合应用
1. 为什么 MCP 强调上下文共享，A2A 强调对话式协作，ANP 强调网络拓扑？
MCP 面向 Agent 与外部工具 / 资源 / 提示模板的连接。模型要正确使用外部能力，不仅需要函数入口，还需要工具说明、参数 schema、资源背景和提示模板，所以 MCP 强调上下文共享。它解决的核心问题是 “外部能力如何以模型可理解、可发现、可调用的方式接入”。
A2A 面向 Agent 与 Agent 的协作。Agent 不是被动函数，而是有角色、能力、状态和产物的协作主体。任务可能需要委托、拒绝、协商、执行、反馈和返工，所以 A2A 强调对话式协作。它解决的核心问题是 “多个自治 Agent 如何像团队一样协同完成任务”。
ANP 面向大规模 Agent 网络。节点多了以后，最重要的问题变成发现、路由、负载、拓扑和容错，所以 ANP 强调网络拓扑。它解决的核心问题是 “在开放、大规模、动态变化的 Agent 网络中如何找到合适服务并稳定通信”。
2. 智能客服系统中如何选协议？
| 功能 | 协议 | 理由 |
|---|---|---|
| 访问客户数据库和订单系统 | MCP | 数据库、订单 API、CRM 都是外部工具 / 资源，适合封装为 MCP Server |
| 多个专业客服 Agent 协作 | A2A | 接待员、技术专家、销售顾问、投诉处理 Agent 之间需要任务委托和结果返回 |
| 支持大规模并发用户请求 | ANP | 需要服务注册、负载均衡、实例发现、故障切换和弹性扩容 |
3. 三种协议是否可以组合？
可以，而且实际系统通常应该组合使用。示例架构：
用户请求
-> API Gateway
-> 客服入口 Agent
-> ANP Discovery 查询可用专家 Agent
-> A2A 调用技术专家/销售顾问/投诉处理 Agent
-> MCP 查询订单系统、客户数据库、知识库
-> 汇总专家结果
-> 返回用户
协议职责：
ANP：发现专家 Agent、选择低负载实例、故障切换。A2A：入口 Agent 与专家 Agent 通信，传递任务和工件。MCP：专家 Agent 访问数据库、订单系统、知识库和工单系统。
习题 2：MCP 扩展实践
1. 如何设计数据分析 MCP Server？
可以设计三个核心工具：
| 工具 | 参数 | 返回 |
|---|---|---|
query_database |
sql、limit、database |
查询结果 JSON、字段信息、行数 |
generate_chart |
data、chart_type、x、y、title |
图表文件路径或 base64 图片 |
generate_report |
query_result、charts、template |
Markdown/HTML/PDF 报告 |
协作流程：
用户：分析本月销售额变化
-> Agent 调用 query_database 获取销售数据
-> Agent 调用 generate_chart 生成趋势图
-> Agent 调用 generate_report 输出分析报告
简化伪代码：
server = MCPServer(name="data-analysis-server")
def query_database(sql: str, limit: int = 1000) -> str:
...
def generate_chart(data: str, chart_type: str, x: str, y: str) -> str:
...
def generate_report(data: str, charts: list[str], template: str = "default") -> str:
...
server.add_tool(query_database)
server.add_tool(generate_chart)
server.add_tool(generate_report)
server.run()
生产环境中，query_database 不能直接执行任意 SQL。应增加只读账号、SQL 解析、表级权限、行数限制、超时和审计。
2. Resources 和 Prompts 如何与 Tools 配合？
可以这样设计：
Resources：暴露数据库 schema、指标口径、业务术语表、报表模板、历史报表。Prompts：提供 SQL 生成模板、数据分析模板、异常解释模板、经营报告模板。Tools：执行查询、画图、生成报告、导出文件。
示例场景：
Resources:
resource://schema/sales
resource://metrics/revenue_definition
Prompts:
prompt://monthly_business_review
prompt://sql_safety_check
Tools:
query_database
generate_chart
generate_report
这样 Agent 在生成 SQL 前可以先读取 schema 和指标定义，再使用提示模板规范分析方式，最后调用工具完成实际操作。
3. JSON-RPC 2.0 + stdio 的优势和局限是什么？如何扩展远程 MCP？
优势：
- 协议简单，语言无关，适合跨语言工具服务。
- stdio 很适合本地子进程通信，不需要额外开放端口。
- 工具进程和 Host 进程隔离，便于本地开发和调试。
- JSON-RPC 的请求、响应、错误结构清晰。
局限：
- stdio 更适合本机，不适合天然远程调用。
- 连接生命周期和子进程管理需要 Host 负责。
- 权限、认证、限流、负载均衡不是 stdio 本身解决的问题。
- 对长任务、流式结果和多用户并发需要额外设计。
远程扩展方案：
- 使用 HTTP、SSE、WebSocket 或 StreamableHTTP 作为传输层。
- 增加 TLS、OAuth/API Key、请求签名和访问控制。
- 设计 session id、heartbeat、timeout、retry 和 cancellation。
- 对流式任务使用 SSE/WebSocket 返回阶段性结果。
- 在网关层做限流、审计、熔断和服务发现。
习题 3：A2A 扩展实践
1. 给研究团队增加 Reviewer Agent
协作流程：
researcher.research(topic)
-> writer.write(research_result)
-> reviewer.review(article)
-> approved = true：输出最终论文
-> approved = false：把 review feedback 交给 writer 修改
简化实现：
reviewer = A2AServer(name="reviewer", description="审稿人")
@reviewer.skill("review")
def review_article(text: str) -> str:
if len(text) < 800:
return str({
"approved": False,
"feedback": "内容偏短，需要补充背景、方法和结论。"
})
return str({
"approved": True,
"feedback": "结构完整，可以发布。"
})
协调函数：
def create_paper(topic):
research = researcher_client.execute_skill("research", f"research {topic}")
article = writer_client.execute_skill("write", f"write {research['result']}")
review = reviewer_client.execute_skill("review", f"review {article['result']}")
review_data = eval(review["result"])
if review_data["approved"]:
return article["result"]
revised = writer_client.execute_skill(
"write",
f"rewrite {article['result']} with feedback {review_data['feedback']}"
)
return revised["result"]
实际项目中应避免 eval，用 JSON 解析结构化结果。
2. 如何设计冲突解决机制？
可以扩展 A2A 消息类型：
| 消息类型 | 用途 |
|---|---|
negotiation |
发起协商，提出约束和目标 |
counter_proposal |
对原提案给出修改条件 |
vote_request |
请求多个 Agent 对方案投票 |
vote_cast |
某个 Agent 提交投票和理由 |
vote_result |
汇总投票结果 |
arbitration_request |
请求仲裁 Agent 或人工介入 |
推荐消息结构：
{
"type": "vote_request",
"task_id": "task-1001",
"proposal_id": "p-03",
"options": ["方案A", "方案B"],
"deadline": "2026-05-22T10:00:00Z",
"voting_rule": "majority"
}
冲突解决流程：
发现冲突
-> 发起 negotiation
-> 多轮 counter_proposal
-> 若仍冲突，发起 vote_request
-> 按权重或多数投票形成 vote_result
-> 必要时进入 arbitration_request
3. A2A 与 AutoGen、CAMEL 的关系是什么？
A2A 是通信协议，AutoGen、CAMEL 是多智能体框架。它们层次不同：
- A2A 解决跨 Agent、跨框架、跨服务如何通信。
- AutoGen/CAMEL 解决如何组织多 Agent 对话、角色扮演、任务流程和实验范式。
它们不能简单互相替代。更合理的做法是互相接入：
AutoGen Agent
-> A2A Adapter
-> A2A Server/Client
-> HelloAgents A2A Agent
适配方案：
- 把 AutoGen Agent 包装成 A2A Server，对外暴露
execute_taskskill。 - 在 HelloAgents 中用
A2ATool调用 AutoGen 服务。 - 把 A2A 消息转换为 AutoGen 的 message 格式。
- 把 AutoGen 的最终回复转换成 A2A task_result 或 artifact。
习题 4：ANP 网络设计
1. 不同拓扑如何选择？从 10 个 Agent 扩展到 1000 个 Agent 时如何演进？
| 场景 | 拓扑选择 | 原因 |
|---|---|---|
| 3-10 个 Agent，中心流程明确 | 星型 | 简单、可控、方便调试 |
| 10-30 个 Agent，需要频繁点对点协作 | 小规模网状 | Agent 可直接通信，协作灵活 |
| 100 个以上，按业务域分组 | 分层 | 每层职责清楚，减少连接复杂度 |
| 1000 个以上，跨区域、跨能力集群 | 混合拓扑 | 结合注册中心、网关、分区路由和局部自治 |
演进路线：
10 个 Agent：单注册中心 + 星型协调
100 个 Agent：按能力分组 + 分层路由
1000 个 Agent：多注册中心/分片索引 + 区域网关 + 健康检查 + 自动扩缩容
关键是避免所有节点互相直连。全连接在规模变大后会导致连接数量、状态同步和故障传播都难以控制。
2. 设计智能路由算法
输入：
- 任务类型和能力要求。
- Agent capabilities。
- 当前负载、延迟、失败率。
- 成本、区域、版本。
- 信任评分和历史表现。
流程：
1. 根据 service_type 和 capabilities 过滤候选 Agent
2. 剔除健康检查失败或版本不兼容的 Agent
3. 对候选 Agent 计算综合分
4. 选择最高分 Agent
5. 调用失败时降级到下一候选
6. 更新负载和历史表现
打分示例：
score =
capability_match * 0.35
+ health_score * 0.20
+ (1 - load) * 0.15
+ trust_score * 0.10
+ latency_score * 0.10
+ cost_score * 0.05
+ locality_score * 0.05
如果任务强依赖 GPU，则可以先硬过滤 metadata.gpu == true，再打分。
3. 智能城市关键 Agent 故障时如何容错？
以交通管理 Agent 故障为例：
故障检测：
- 心跳超时。
- 连续请求失败率超过阈值。
- 延迟超过 SLA。
- 下游服务报告异常。
备份切换：
- ANP Discovery 中同一 service_type 注册多个交通 Agent。
- 主 Agent 故障后，路由器选择健康的备份 Agent。
- 对关键服务使用热备或温备。
状态恢复：
- 交通状态、任务队列、事件流写入共享状态存储。
- 使用事件溯源记录每次信号灯调整、拥堵事件和调度决策。
- 备份 Agent 接管时从最近 checkpoint 加载状态，并重放未处理事件。
降级策略：
- 若所有智能 Agent 不可用，切换到规则系统。
- 优先保障紧急车辆、主干道和事故区域。
- 向运维和人工调度中心告警。
完整机制：
heartbeat monitor
-> detect failure
-> mark node unhealthy in ANP
-> route traffic to standby
-> restore state from checkpoint/event log
-> replay pending tasks
-> notify operators
-> recover original node after health check passes
习题 5：安全性与隐私保护
1. MCP 客户端可调用任意工具有什么风险？如何做权限控制？
风险包括：
- 文件删除、覆盖、泄露。
- 执行系统命令导致主机被控制。
- 数据库误写、误删或大规模导出。
- Prompt injection 诱导 Agent 调用危险工具。
- 工具返回恶意内容污染上下文。
- API Key、Token、客户隐私被外传。
权限控制建议：
- 工具 allowlist：只允许 Agent 使用明确批准的工具。
- 参数级权限：限制目录、表名、SQL 类型、请求域名。
- 读写分离：默认只读，写操作单独授权。
- 高风险操作人工确认：删除、支付、发邮件、执行命令必须确认。
- 沙箱执行：文件系统、命令执行和浏览器工具放在隔离环境。
- 审计日志：记录调用者、工具名、参数摘要、结果、时间。
- 速率限制和配额：防止循环调用或批量数据外泄。
- 密钥隔离：MCP Server 通过服务端环境变量访问密钥，不把密钥暴露给模型。
2. A2A 和 ANP 如何做端到端加密、身份认证和访问控制？
可采用 DID + 公钥加密 + 消息签名：
Agent A 生成消息
-> 使用随机会话密钥加密 payload
-> 使用 Agent B 公钥加密会话密钥
-> 使用 Agent A 私钥签名消息摘要
-> Agent B 验证签名并解密
消息信封：
{
"from": "did:agent:a",
"to": "did:agent:b",
"timestamp": "2026-05-21T10:00:00Z",
"nonce": "random-value",
"key_id": "key-1",
"ciphertext": "...",
"signature": "..."
}
安全要点：
- 使用 TLS 保护传输通道。
- 使用 DID 或证书验证 Agent 身份。
- payload 端到端加密，避免中间节点读取敏感内容。
- 签名覆盖 timestamp、nonce、task_id、ciphertext，防止重放和篡改。
- ACL 控制不同 Agent 可访问的 skill、资源和任务类型。
- 定期轮换密钥，吊销异常 Agent 的凭证。
3. 如何设计大规模 Agent 网络的信任评估系统？
信任评分可以由多类信号组成：
| 信号 | 含义 |
|---|---|
| 身份可信度 | 是否有可验证 DID、证书、组织背书 |
| 历史成功率 | 任务完成率、失败率、超时率 |
| 协作质量 | 结果是否被下游接受，是否经常返工 |
| 安全记录 | 是否出现异常访问、越权请求、数据泄露 |
| 社区评价 | 其他 Agent 或用户的评分 |
| SLA 表现 | 延迟、可用性、负载稳定性 |
评分示例：
trust =
identity_score * 0.20
+ success_rate * 0.25
+ quality_score * 0.20
+ security_score * 0.20
+ peer_rating * 0.10
+ sla_score * 0.05
根据评分调整通信策略：
- 高信任 Agent：允许自动协作和较高权限工具。
- 中等信任 Agent：限制敏感数据，增加结果校验。
- 低信任 Agent：只能访问公开数据，结果需人工或高信任 Agent 审核。
- 异常 Agent：临时隔离、降权或拉黑。
还应加入异常检测，例如短时间大量请求、频繁失败、请求不相关服务、尝试访问敏感字段等。一旦触发风险规则，ANP 路由层应立即降低该 Agent 权重，必要时停止向其分派任务。
欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！
更多推荐
14
0- 0
已为社区贡献1条内容
所有评论(0)