企业官网建设流程全解析

一.多Agent

1.什么是多Agent

多Agent系统（Multi-Agent System，简称MAS），是指由多个具备独⽴能⼒的智能体（Agent）通过协作，共同完成复杂任务的计算系统。

可以把它理解为⼀个各司其职的“专家团队”：每个Agent都像⼀个拥有特定技能的专业助⼿，它们通过沟通与协作来解决单个Agent难以应对的复杂问题。

单个Agent就像特种兵⼀个模型处理所有任务，依靠强⼤的记忆和⻓上下⽂。Multi-Agent属于军团作战，多个专精智能体分⼯合作，通过通信协议协同解决问题。

2.为什么会需要多Agent

那肯定因为：单智能体有以下短板

1. 能⼒有边界上限：单个模型难以覆盖所有领域的知识。

单智能体⽆法做到全领域极致精通。

⽐如学校举办“最强⼤脑”全能个⼈挑战赛，要求⼀个⼈连续闯过数学、编程、英语辩论三关。参赛的⼩张数学很强，轻松拿下第⼀关；到了编程环节，磕磕绊绊勉强写出代码但全是bug；最后英语辩论时⼤脑彻底宕机，连“Hello”都说不利索，惨遭淘汰。
⽽隔壁班的三⼈团队赛：数学⼩王负责解题、编程⼩李负责写代码、英语⼩赵负责辩论。三⼈各守⼀关，轻松碾压全场夺冠。
核⼼问题：⼀个⼈可以在某个领域练到极致，但很难同时在三个完全不相关的领域都达到竞赛级⽔平。单兵作战的上限，就是个⼈能⼒的上限；⽽团队作战的上限，是三个⼈各⾃上限的总和。

2. 上下⽂窗⼝与⼯具限制

⼤模型上下⽂窗⼝存在物理限制，单智能体处理⻓任务时，会因信息过载出现上下⽂遗忘、逻辑断裂、幻觉加重。⽐如把⼀篇10⻚英语⽂章浓缩成⼀张思维导图。你⼀个⼈做，读到后⾯忘前⾯，来回翻⻚⼿忙脚乱，最后画出来的图全是乱的。
但四⼈⼩组做：⼀⼈管2⻚，每⼈只记⾃⼰的内容，最后拼起来，⼜快⼜准。

3. 容错性差：单点故障，全盘瘫痪

单智能体⼀旦出现模型崩溃、⼯具调⽤失败、幻觉输出，整个任务直接终⽌，⽆冗余备份机制。

⽐如⼩组⼀起报名参加学校辩论赛。如果是你⼀个⼈扛所有——查资料、写稿、背词、临场发挥——结果⽐赛当天你突然发烧嗓⼦哑了，直接全队弃权，连上台的机会都没有。
但如果是四个⼈组队，你倒了还有三个队友顶上。你嗓⼦哑就换⼈当⼀辩，你打字查资料辅助就⾏。

4. ⽆法模拟⼈类社会决策

单智能体的决策像“⼀⼈拍板”——视⻆单⼀、忽略隐性需求，⽅案往往脱离实际。⽽多智能体通过
⻆⾊扮演与协商博弈，模拟真实世界中的多⽅权衡与妥协，产出的结果更具社会可⾏性与鲁棒性。
班级要决定春游去哪⼉。如果是班⻓⼀个⼈说了算，他喜欢爬⼭就直接定了爬⼭，结果⼀半同学嫌累不想去，最后怨声载道，玩得也不开⼼。
但如果让⼏个代表⼀起商量：爱运动的想爬⼭，爱拍照的想去古镇，预算紧的想就近免费公园。

⼤家讨论⼀下、互相妥协，最后定出⼀个“上午逛古镇拍照、下午公园野餐”的⽅案，所有⼈都勉强满意。

这是2023年斯坦福大学和Google DeepMind合作发表的那篇轰动物理、AI和社会科学界的论文：论文全称《Generative Agents: Interactive Simulacra of Human Behavior》（生成式智能体：人类行为的交互式模拟）斯坦福“AI⼩镇”实验曾⽤25个AI智能体模拟社会⾏为，⼀个“举办派对”的念头就引发完整社交传播，证明⼤模型能模拟⼈类社会。

它为什么经典？

这篇论文构建了一个“AI小城镇”——一个名为Smallville的沙盒模拟环境。

核心实验内容：

• 在虚拟小镇中放置了25个生成式Agent。

• 每个Agent都有自己的身份设定（姓名、职业、性格、关系、记忆）。

• 它们像真人一样生活：起床、做早餐、上班、聊天、互相传播八卦、安排约会、形成社交圈。

• 用户可以用自然语言下达指令（比如“你明天要举办一个情人节派对”），然后观察这些Agent如何自主地规划、记忆、传播信息并采取行动。

Agent VS MAS

3.多Agent的协作模式

a.顺序流⽔线模式 (Sequential / Pipeline)

架构描述：

任务被划分为线性步骤，Agent_1的输出直接作为Agent_2的输入，依次传递，直到最终结果。

优点

• 逻辑极其简单，调试容易

• 适合定义明确的标准化流程

缺点

• 缺乏灵活性

• 中间环节出错，错误会沿链路不断放大（Error Propagation）

• 无法回溯修改

例子

校运动会4×100米接力队，四个队员依次接力完成比赛。

b.交接模式 (Handoffs)

架构描述：
Handoffs是指⼀个智能体将当前会话或任务的控制权完全转移给另⼀个更合适的智能体。交接后，原智能体退出交互，由接⼿⽅继续服务⽤⼾。此过程通常由中央路由智能体或上游智能体基于意图识别、技能匹配或权限边界触发。

优点：⽤⼾体验⽆缝，⽆需重复描述问题；职责边界清晰，便于专业化分⼯.
缺点：交接失败时易造成信息丢失；路由决策错误会导致多级跳转

案例：医院⻔诊的分诊台。你因胸闷挂号，护⼠初步问询后判断可能是⼼脏问题，便把你的病历直接转交给⼼内科诊室，并告诉你“去3号诊室找王医⽣”。之后护⼠不再管你，全程由⼼内科医⽣接诊。
Handoff ≠ Pipeline。Handoff是换⼈，Pipeline是传物。

c.层级主管模式 (Hierarchical / Manager-Worker)

架构描述：⼀个 Manager Agent 负责任务规划（Planning）和任务分发。它根据⼦代理的描述（Descriptions）将任务指派给特定的 Worker Agents，最后汇总结果。
优点：任务分配⾼度专业化，屏蔽了 Worker 之间的复杂通信，系统可扩展性强。
缺点：Manager 成为系统的瓶颈和单点故障，如果 Manager 规划错误，整个任务都会败。

d.路由模式 (Routing Pattern)

架构描述：⼀种由⼀个路由器统⼀接收查询，经过意图分类或领域识别后，并⾏分发给多个垂直领域的专⻔智能体，最后由合成器汇总多⽅结果并⽣成统⼀回复的协作模式。适⽤于⽤⼾问题横跨多个独⽴知识领域的复合场景。
优点：响应快：多路并⾏执⾏，总耗时约等于最慢的那个Agent;覆盖⾯⼴：⼀次查询即可调动多个专家，避免⽤⼾反复提问。扩展性强：新增垂直领域只需在路由表注册，不影响现有Agent。
缺点：合成压⼒⼤：汇总器需处理信息冲突、去重与逻辑连贯，若设计不佳则回复割裂。路由依赖强：路由器若错判领域，会导致⽆关Agent被错误唤醒，浪费资源。
案例：
⽤⼾输⼊：“我买的鞋⼦⼩了，怎么换？还有，赠品发错颜⾊了。”
路由器识别出“换货流程”和“赠品补发”两个垂直领域。
并⾏唤醒：订单Agent查询换货资格与流程；赠品Agent核实库存并登记补发单。
合成器将两路信息整合为⼀条清晰回复：“您的换货申请已提交，赠品补发单号是……”

e.中⼼化协调模式（OrcheAstrator Pattern）

架构描述：系统中存在唯⼀的中央协调智能体，负责任务的接收、分解、分配、监控与结果汇总，所有执⾏智能体仅与中央节点通信，彼此不直接交互。
优点：结构极其简单，易于实现与调试；任务分配全局最优
缺点：中央节点成为性能瓶颈和单点故障源；扩展性受限于中⼼处理能⼒

f.去中⼼化对话模式（Debate / Discussion Pattern）

架构描述：⽆中央协调者，多个智能体围绕同⼀议题展开⾃由辩论或圆桌讨论。每个智能体独⽴发表观点、引⽤证据、反驳他⽅，通过多轮论证与相互质疑，最终收敛⾄共识或形成更全⾯的综合结论。
Agent A 提出初始⽅案。
Agent B（评审员/批评者）寻找漏洞。
Agent A 根据意⻅修改⽅案。
通过“多模型共识（Consensus）”机制，⼤幅提升结果的准确性。
优点：充分激发多元视⻆，结论更客观全⾯；⽆单点故障
缺点：通信开销极⼤；可能陷⼊⽆限争论或⽆法收敛

g.动态图协作模式（Dynamic Graph-based Collaboration）

架构描述：

以"状态"为中心

动态图模式的本质是：节点（Nodes）即Agent，边（Edges）即逻辑跳转，状态（State）即共享内存。

• 节点（Nodes）：每一个节点可以是一个功能函数、一个LLM调用，或者另一个子图。

• 边（Edges）：

  • 普通边：确定性的跳转。

  • 条件边（Conditional Edges）：根据上一个节点的输出内容（如：代码是否报错、安全扫描是否通过），动态决定下一个节点。

• 状态（State）：一个全局共享的数据结构（类似上下文池），所有节点都可以读取并修改它。这是实现"长短期记忆"和"多轮迭代"的关键。

循环与回溯（Loops & Cycles）

• 自我纠错机制：如果Agent B发现Agent A的输出不符合预期，它可以将任务"打回"给Agent A，并附带修改建议。

• 终止条件：开发者可以定义一个END节点。只有当满足特定条件（如：测试通过、达到最大重试次数）时，流程才会退出。

优点：

• 极致灵活性，可以模拟任何复杂的人类工作流，支持多路径分支。

• 高鲁棒性，允许Agent在失败时重试或切换备选路径，而不是直接崩溃。

• 精细化控制，开发者可以手动干预特定节点的逻辑，平衡"自主性"与"可控性"。

缺点：

• 开发复杂度高，需要设计严密的图逻辑，防止Agent陷入无限循环。

• 状态管理难，随着图的增大，全局State的读写冲突和版本追踪会变得复杂。

4.实战 -WorkBuddy召唤内容创作天团

1. 下载WorkBuddy （WorkBuddy - AI Agent 办公新范式）

2. 安装启动

3.登录后，召唤内容创作天团

4.生成效果如下：

二.智能体通信协议

1.为什么需要通信协议

过去的AI，⼤多是单打独⽃，独⽴完成⼀项任务。但现在，智能体要实现真正的⾃动化和智能化，就得学会团队作战。想象⼀下，如果不同的AI智能体都讲⾃⼰的⽅⾔，想合作就会变成鸡同鸭讲，效率低得要命，安全还没保障。
于是，类似翻译官的通信协议就出现了。它们帮AI智能体之间搭桥，让它们能安全、稳定、可扩展地互通有⽆，⼀起做事。

2.MCP

MCP（Model Context Protocol）是Agent和外部⼯具/资源的通信的协议之⼀，其核⼼设计理念是标准化智能体与外部⼯具/资源的通信⽅式。

MCP就像是⼤模型的万能适配器。有了它，各种应⽤可以⽅便地把数据、功能模块插到⼤模型⾥，让AI可以动态调⽤新⼯具、读取实时数据，⽽不⽤每次都重新写代码。MCP的核⼼优势是上下⽂注⼊，不管是⽂件、数据库、还是API的实时响应，都能通过标准接⼝直接喂给AI。

3.A2A

a.什么是A2A协议

A2A（Agent-to-Agent协议），是Google主导的跨平台智能体通信规范。A2A（Agent-to-AgentProtocol，代理间协议）是⼀个开放标准，旨在让不同框架、不同供应商开发的AI智能体（Agent）能够互相通信、协作，共同完成复杂任务。它的⽬标，是成为AI智能体之间进⾏交流的“通⽤语⾔”或“智能体互联⽹时代的HTTP”。
简单来说，A2A解决的是“智能体孤岛”问题。就像⼀个团队⾥，成员需要沟通才能协作，A2A为不同“出⾝”的AI智能体提供了⼀套标准化的“对话规则”

A2A协议⾥⾯每个智能体都有⼀张Agent Card，把⾃⼰的技能、接⼝、认证⽅式等信息⽤JSON描述出来。别的AI只要读这个卡⽚，就知道你能⼲嘛、怎么找你办事。A2A基于HTTP/HTTPS、JSON-RPC2.0等通⽤Web协议，⾮常web-native。
智能体既可以是客⼾机（发起任务），也可以是服务器（接任务），甚⾄可以两者兼有。这样，跨平台、跨团队、跨⾏业的AI协作⽣态系统就有了统⼀的任务语⾔。

简单说：就是两种不同"出身"的AI助手，怎么互相配合干活。

左边：住在大厂云端的Agent

• 用的是谷歌家的云服务（Vertex AI、Gemini API）

• 相当于一个"住别墅的专家"，算力强、啥都有

• 想调用公司内部系统（比如查数据库、发邮件）时，走MCP协议——你可以把它理解为"万能插头"，统一对接各种工具

右边：待在你自家机房的Agent

• 用的是自己部署的开源模型和自己搭的框架

• 相当于"住你家的师傅"，更私密、更可控

• 它想调用内部工具时，同样走MCP这个万能插头

A2A协议在这里是干啥的？

左边那套云上系统和右边那套本地系统，想互相沟通时怎么办？A2A就是它们之间的"翻译官"，让两个不同平台、甚至不同公司的Agent能听懂对方在说啥

总结

MCP = 统一插头（Agent连工具）
A2A = 统一语言（Agent连Agent）

左边和右边可以独立工作，也可以互相配合——相当于"云端军团"和"本地特工队"可以联合作战。

b.为什么需要A2A协议

在 A2A 出现前，智能体协作⾯临三⼤核⼼痛点：

1. 痛点⼀：框架不兼容 —— “鸡同鸭讲”的技术孤岛

想象⼀下，你有⼀个⽤LangGraph写成的智能体，它擅⻓做复杂的决策流程。另⼀个⽤CrewAI写成的智能体，它擅⻓协调多个⻆⾊。还有⼀个⽤Google ADK写成的，它擅⻓调⽤⾕歌的各种API。

• A2A之前的困境：这三个智能体都“说”⾃⼰的“⽅⾔”。LangGraph的智能体发出指令后，CrewAI的智能体完全“听不懂”，因为它没有内置的翻译机制。这就好⽐⼀个中国⼈、⼀个英国⼈和⼀个俄罗斯⼈试图合作，但每个⼈都只会⾃⼰的⺟语，⼯作根本⽆法开展。

2. 痛点⼆：框架锁定 —— “被绑架”的技术选型

这是更隐蔽但同样致命的痛点。当你选择了⼀个框架（⽐如LangChain）来开发你的核⼼智能体⽣态后，你就被“锁定”在这个框架⾥了。

• A2A之前的困境：假设市场上出现了⼀个新的、性能更优的智能体框架，它处理某个特定任务（⽐如医疗影像分析）的效率是你的LangChain智能体的10倍。因为你所有的智能体都是⽤LangChain的通信⽅式构建的，这个新框架的智能体⽆法加⼊你的“团队”。你⾯临着两难选择：要么放弃整个LangChain⽣态，推倒重来（成本极⾼），要么放弃这个优秀的新⼯具（错失竞争⼒）。

3. 痛点三：⼚商壁垒 —— 各⾃为战

这是A2A协议要解决的最宏伟的⽬标。在⼤型企业⾥，不同的部⻔可能使⽤不同⼚商的SaaS服务。

• A2A之前的困境：你的Salesforce（销售部⻔）智能体发现了⼀个重要的客⼾商机，需要Workday（⼈⼒资源部⻔）智能体配合，⽴即为该客⼾组建⼀个专⻔的专家团队。但由于两个系统来⾃不同⼚商，没有统⼀的通信协议，这个跨系统的复杂协作根本⽆法⾃动完成。销售智能体只能⽣成⼀个⼯单，然后由⼈⼯去Workday系统⾥⼿动操作。

最⼤问题：如何让这些⾝怀绝技的 Agent 突破壁垒， 形成⼀个⾼效的协作⽹络？

因此，A2A 协议的本质的是智能体间的 “TCP/IP 协议”—— 它基于 Apache 2.0 开源许可，定义了统⼀的通信、协作与协商规则，让任何智能体⽆论出⾝（⼚商、框架），都能像⼈类团队⼀样分⼯协作，且⽆需暴露内部实现细节。

c.官⽹

A2A Protocol

协议地址

Overview - A2A Protocol

Protocol Definition - A2A Protocol

d.A2A核⼼组件

• A2A Server：访问对端Agent的的⼊⼝，基于Web Server运⾏，提供端点供客⼾端发起各种请求并给予响应；也会通过连接发起主动通知、任务结果给客⼾端。
• A2A Client：访问A2A Server的其他Agent或定制应⽤。所以Client与Server是相对的，⼀个客⼾端Agent同时也可以是其他Agent的服务端。
• Agent Card：这是Agent的“名⽚”，代表“我有怎样的任务完成能⼒“。

• Task（任务）：这是客⼾端交给服务端Agent需要完成的⼯作任务。任务过程可能需要客⼾端的协作；任务结果可以同步等待也可以异步获取。

这是两个Agent之间"递纸条"的格式说明。

三个组成部分

举个例子：

Agent A对Agent B说："帮我查一下明天北京天气，然后把结果整理成报告发给我。"

• Task= "获取天气预报并生成报告"

• Message= 包含指令的文本

• Part= 这一段文字（可能还附带图片或表格）

• Artifact（⼯件）：服务端Agent的最终产出被称为Artifact。⽐如⼀段⽂字、⼀个报告、⼀个图⽚或者视频；⼀次任务可以产⽣多个Artifact。

这是A2A协议中Agent之间“回传结果”的数据结构。

三个组成部分

举个例子：

Agent B 查完天气，回复给Agent A：

• Part= 文字说明（“明天晴天，25℃”）+ 一张气温曲线图 + 一张降雨概率表

• Artifact= 这三个Part打包成的一份《天气报告》

• Response= 把这份Artifact装进响应里，加上状态码（“成功”），一起发回给Agent A

• Messages（消息）：是指的客⼾端与服务端Agent之间的多轮沟通内容，存在两个⻆⾊：user和agent，内容包括各种上下⽂、指令、中间状态等。客⼾端向Agent发送的所有内容都是消息；Agent也可以发送消息给客⼾端传递状态或指令（⽐如要求客⼾端补充信息），但服务端Agent的最终结果则是⽤Artifact来表⽰。
• Part (内容部件): 消息和产出物的基本组成单元，⽤于承载具体内容，如⽂本（TextPart）、⽂件（FilePart）或结构化数据 （DataPart）。这使得 A2A 协议具备了强⼤的多模态能⼒。
• Notifications（通知）：服务端Agent向客⼾端主动推送的信息，⽐如⼀个⻓期任务的中间运⾏状态，⼀个任务有了新的产出等。客⼾端可以设置通知处理回调。

这是A2A协议中Agent之间“主动推送通知”的数据格式。

• Push Notifications= 主动推送通知。不需要对方来问，Agent自己主动发消息过去。

• Notification 1, 2, …, n= 一条通知就是一条独立的消息，可以发多条。

举个例子：

Agent A让Agent B去处理一个耗时任务（比如“生成100页报告”），Agent B不可能让A干等着。

• 等报告生成到第50页时，Agent B主动推一条通知给A：“已经完成一半了，进度50%。”

• 全部完成后，再推一条：“报告已完成，来取吧。”

这两条就是Notification 1和Notification 2。

e.⼯作过程

A2A（Agent2Agent）协议的完整⼯作流程，可以看作是两个AI代理（Agent）从“相识”到“协作”
的标准化过程。整个流程通常分为四个主要阶段：发现 (Discovery)、认证 (Authentication)、通信与任务执⾏(Communication & Task Execution) 以及完成 (Completion)。

这是一份"Agent之间怎么打招呼、派活、跟进、收工"的完整操作手册。

流程图核⼼阶段说明

1. 发现 (Discovery)：寻找与了解合作伙伴

这是所有协作的起点。客⼾端代理（Client Agent） 需要找到能够提供所需服务的 远程代理

• （Remote Agent，即A2A服务器）。

• 机制：远程代理会公开⼀个标准的元数据⽂件，即 “代理卡”（Agent Card）。这是⼀个JSON格式的⽂档，通常位于其域名的 /.well-known/agent-card.json 路径下。
• 关键信息：代理卡详细描述了该代理的⾝份、能⼒（Skills）、服务端点（Endpoint URL）以及连接所需的认证要求。
• 结果：客⼾端代理通过获取并解析代理卡，来判断这个远程代理是否适合执⾏当前任务，并知道了该如何与其通信。

2. 认证 (Authentication)：建⽴安全的连接

在发现合适的代理后，双⽅需要建⽴⼀个安全、可信的连接。

• 机制：客⼾端代理会根据代理卡中指定的安全⽅案，通过标准的⾝份验证流程（如OAuth、APIKey等）向远程代理证明⾃⼰的⾝份。
• 结果：认证通过后，远程代理还会进⾏授权（Authorization），即为该客⼾端授予执⾏特定任务所必需的最⼩权限。这确保了交互的安全性。

3. 通信与任务执⾏ (Communication & Task Execution)：核⼼协作
这是最核⼼的交互阶段。双⽅通过标准化的 JSON-RPC 2.0 格式进⾏通信。

• 发起请求：客⼾端代理向远程代理的端点发送⼀个 SendMessage 或SendStreamingMessage 请求。
• 两种响应模式：远程代理收到请求后，根据任务的复杂度，会选择两种基本⽅式进⾏响应：

a. ⽆状态消息（Stateless Message）：⽤于处理能够⽴即完成的简单、⼀次性交互（如简单的问答）。
b. 有状态任务（Stateful Task）：⽤于处理需要⻓时间运⾏、多步骤执⾏或需要追踪状态的复杂⼯作。远程代理会创建⼀个 Task 对象来管理这个⼯作单元。

深⼊任务⽣命周期 (Life of a Task)

⼀旦进⼊任务模式，⼀个任务会经历其完整的⽣命周期。

• 任务状态流转：⼀个任务会有清晰的状态，例如 submitted （已提交）、 working （处理中）、 input-required （需要更多输⼊）、 completed （已完成）、 failed （失败）或 canceled （已取消）等。
• 上下⽂关联 ( contextId )：多个相关的任务和消息可以通过 contextId 关联在⼀起，形成⼀个连续的会话或⼯作流。例如，⽤⼾可以在同⼀个 contextId 下，多次修改和优化⼀个⽣成结果。
• 获取实时更新：对于⻓时任务，客⼾端可以通过两种主要⽅式获取进度：

流式传输 (Streaming)：通过 message.stream ⽅法建⽴⼀个服务器发送事件（SSE） 连
接，实时接收 TaskStatusUpdateEvent （状态更新）和TaskArtifactUpdateEvent （产物更新）。
轮询 (Polling)：客⼾端定期调⽤ task.get ⽅法来主动查询任务的最新状态。
推送通知 (Push Notification)：对于极端⻓时的任务，远程代理也可以在任务状态变化时，主动向客⼾端配置的Webhook地址发送通知。

4. 完成 (Completion)：交付成果与结束

当任务处理完毕并达到⼀个终态（如 completed 或 failed ）后，交互即告结束。

• 交付产物：对于成功的任务，远程代理会交付 “⼯件”（Artifact），即任务的有形输出，⽐如⼀份报告、⼀张图⽚或⼀个结构化数据⽂件。
• 不可变性：⼀旦任务进⼊ completed 、 canceled 、 failed 等终态，它就不会再被改变或“重启”。任何后续的修改或迭代，都会在同⼀个 contextId 下创建⼀个全新的任务来完成。

f.A2A和MCP的关系

MCP解决的是Agent与外部⼯具/数据之间的集成，是Agent的“内部事务”；A2A解决的是Agent与
Agent之间的集成，属于更⾼层次的集成关系。

二者的核心关系

MCP管"干活"，A2A管"沟通"。两个协议各管一摊，配合使用。

简单比喻一哈

• MCP= 每个专家手里的工具箱（连什么工具就有什么能力）

• A2A= 专家之间的对讲机（互相派活、问进度、传结果）

分工如下：

咱们也可以举一个简单的例子：Agent A接到任务"做一个财报分析"：

1. 通过MCP：Agent A连接本地数据库（MCP Server A），拉取原始数据

2. 通过A2A：Agent A发现这事儿还得画图，于是通过对讲机（A2A）呼叫Agent B

3. 通过MCP：Agent B连接Web API（MCP Server B），获取图表模板

4. 通过A2A：Agent B把画好的图传回给Agent A

5. A2A全程：管理任务状态（进行中/已完成）、安全认证、能力协商

MCP是"手"（干活），A2A是"嘴"（沟通）。Agent通过MCP摸到工具，通过A2A喊来帮手。

4.ANP

a.什么是ANP协议

Agent Network Protocol (ANP) 是⼀个开源的智能体通信协议，旨在成为智能体互联⽹时代的
HTTP。愿景是定义智能体之间如何连接，为数⼗亿智能体构建⼀个开放、安全、⾼效的协作⽹络。

b.官⽹

Agent Network Protocol

协议内容

Agent Network Protocol Technical White Paper: | Agent Network Protocol

c.ANP协议架构

ANP采⽤三层架构设计，允许代理在互联⽹上⾃由安全地进⾏通信：

这是ANP（Agent Network Protocol，智能体网络协议）的三层架构设计，目标是把Agent从"只能跑在本地的小工具"变成"能在互联网上自主找帮手、安全协作的独立个体"。

• ⾝份和加密通信层：基于 W3C DID 标准，实现去中⼼化⾝份和端到端加密，解决“我是谁”和“如何安全通信”的问题。

DID 全称是“去中⼼化⾝份标识符”（Decentralized Identifier）。它是⼀种由⽤⼾⾃⼰创建、拥有和控制的、全球唯⼀的数字⾝份。简单来说，DID 可以理解为你在数字世界⾥完全⾃主的“⾝份证+私章”。
它的核⼼在于⾃主权。传统的数字⾝份（⽐如你的电⼦邮箱、⼿机号）通常由某个中⼼化机构（如微信、电信公司）分配和管理，这意味着你的⾝份是“租⽤”的，该机构可以随时收回或停⽤。⽽DID 不再依赖任何单⼀的中⼼化机构或平台，它建⽴在区块链或分布式账本上，是⼀种由你⾃主⽣成、永久属于你、且可在服务商之间转移的凭证

• 元协议层：解决了“如何协商通信⽅法”的问题，允许代理⾃动协商⽤于交互的协议格式和版本。
• 应⽤协议层：解决“提供哪些功能”和“如何被发现”的问题，包括代理描述和发现机制。

这种架构确保代理能够在互联⽹上⾃主地找到彼此，安全地建⽴连接，并有效地进⾏通信。怎么理解呢，我们来看个例⼦有两个智能体：⼀个是你的 “私⼈旅⾏助理”（叫⼩旅），另⼀个是某家酒店的 “智能预订系统”（叫⼩酒）

有两个智能体：⼀个是你的 “私⼈旅⾏助理”（叫⼩旅），另⼀个是某家酒店的 “智能预订系统”
（叫⼩酒）

身份和加密通信层：两个陌⽣⼈第⼀次通电话，为了安全，他们先互相出⽰了⾝份证，确认了“你是公安局认证的⼩明”，“我是公安局认证的⼩红”。然后，他们⽤⼀部只有彼此才能听懂内容的加密对讲机通话，旁边的⼈即使听到也是⼀串噪⾳。
元协议层：两个⼈⻅⾯后，虽然⾝份没问题，但⼀个只说中⽂，⼀个只说英⽂。于是他们先快速商量好：“我们这次都⽤英⽂”。协商好之后，后⾯的沟通才能顺畅进⾏。
应⽤协议层：⼩酒在⾃⼰的“招牌”（即Agent Description⽂档）⾥写明：我提供 查询房态 和 预订房间 这两个功能；⼩旅通过发现机制（⽐如在酒店联盟的注册表⾥搜索）找到了⼩酒的招牌，读懂了它提供的功能和使⽤⽅法。然后⼩旅按照招牌上的规则，发出“查询房态”的请求，⼩酒返回可预订的房间列表；⼩旅再发“预订房间”请求，完成订房。

三层架构梳理

简单理解就是：每次交互都先过三层——先验明正身（底层），再约定通话方式（中层），最后才说正事（顶层）。

d.ANP 与 MCP 和 A2A 的⽐较

ANP、MCP 和 A2A 是互补的协议，分别解决不同场景下的智能体通信问题：

e.三者如何⼀起⼯作

MCP、A2A 和 ANP 这三个协议并⾮竞争关系，⽽是构成了⼀个 “执⾏-协作-发现” 的分层协作栈，共同为AI智能体从微观到宏观的⼯作提供标准化⽀持。简单来说：

• MCP（模型上下⽂协议） 解决的是“如何动⼿做”的问题，是智能体与外部世界交互的“⼿”。
• A2A（代理间协议） 解决的是“如何找⼈帮忙”的问题，是智能体之间协同⼯作的“嘴”。
• ANP（代理⽹络协议） 解决的是“如何在⼤海中找到对的⼈”的问题，是智能体在开放⽹络中相互发现的“眼睛”

5.实战-A2A协议---创建A2A协议Agent

1. 登录百度智能云平台https://cloud.baidu.com/完成登录注册

2. 选择Agent开发平台

3. 进⼊后台找到Agent开发

4. 我们使⽤模板创建Agent

创建Agent，填写信息，点击确定

点击模板看官方给的：

配置人设：

您好！我是专注营销内容创作的Agent，可为您⼀站式⽣成⼩红书营销⽂案。⽆论是产品推⼴、活动策 划还是品牌曝光，都能结合您的需求精准产出，助⼒提升营销效果〜您可以随时告知具体需求，我来为 您启动创作！

配置内部智能体协作规则：

# 营销⽂案设计任务规划 ## 🎯 ⽬标 完成品牌推⼴内容⽣成，确保⽅案专业、成品⾼质。 --- ## 📌 任务拆解原则 1. 将任务分为 **信息收集 → ⽂案撰写 ** 两个个阶段。 2. 每个阶段由最合适的 Agent 完成，并在需要时调⽤其他 Agent 协作。 3. 输出保持结构化、专业化，确保可直接应⽤于实际场景。 --- ## 🔗 ⼦Agent间的协作⽅式 - 在需要 **收集素材、竞品案例、设计灵感** 时，请调⽤ **{⽹⻚探索Agent}**。 {⽹⻚探索Agent} 具备 **问题分析、信息检索、⽹⻚浏览和内容筛选** 的能⼒。 - 在需要 **⽣成⼩红书⻛格的营销推⼴⽂案** 时，请调⽤ **{⼩红书宣传⽂案⽣成Agent}**。 {⼩红书宣传⽂案⽣成Agent} 具备 **⽣成贴合⼩红书调性的宣传⽂案** 的能⼒。 --- ## 📃 输出格式 最终输出**⼩红书宣传⽂案**（适合社交媒体推⼴）

创建协作智能体+提示词优化：

可以直接使用：

使用结果：

到这里主Agent和子Agent都配置好了

界面测试：

我们输⼊下⾯内容简单进⾏下测试

我想推⼴⼀款主打 “天然⽆添加” 的⼿⼯果酱，⽬标⽤⼾是宝妈和烘焙爱好者，能帮我⽣成对应的⼩红 书⽂案吗？

进行发布：

立即访问：

https://appbuilder.baidu.com/v2/a2a/81b090eb-c08a-4755-8141-035382635e68/.well-known/agent.json?api_key=https://appbuilder.baidu.com/v2/a2a/81b090eb-c08a-4755-8141-035382635e68/.well-known/agent.json?api_key=

点击获取API Key

进行显示：

进行A2A的测试我们要两个链家在一起https://appbuilder.baidu.com/v2/a2a/81b090eb-c08a-4755-8141-035382635e68/.well-known/agent.json?api_key=

bce-v3/ALTAK-nZiai09FPQcxzoEeoQm3Q/2934b7368509ee8d245e35c014b8c82fa8d678da

在介绍A2A我们开始进行下面的实战

6.实战-A2A协议---Postman介绍

下载Postman(Download Postman | Get Started for Free

)Postman可以通过⼀个直观的图形界⾯，轻松构建和发送各种HTTP请求（如GET, POST, PUT, DELETE等），告别了使⽤ cURL 等命令⾏⼯具的复杂操作。你可以在请求中设置参数、请求头和请求体，发送后还能以格式化的⽅式查看响应结果。平时我们⽤⼿机APP（如微信、淘宝），是⼈在操作。但程序员写代码时，需要让软件跟软件对话（这叫“调⽤API接⼝”）。Postman就是充当这个“对话中间⼈”的⼯具。它让你不写代码，也能像软件⼀样给服务器“发⼀封信”，并当场把服务器的“回信”拆开给你看。

7.实战-A2A协议---Postman观察A2A测试

1.打开Postman，输⼊地址信息注意拼接上APIkey，发送AgentCard获取请求

2.同样我们也可以参考完成调⽤Agent调⽤⽅式，完成Agent调⽤

A2A接口文档 - 百度千帆·大模型服务及Agent开发平台