智能体面试准备三十七多智能体通信协议与互操作A2A本文是 B 系列在三十六篇核心完结之后的前沿延伸第一篇。B14 讲了智能体怎么连工具MCPB15 讲了多智能体怎么协作B34 讲了编排与流程引擎——但都默认智能体是我们自己写的、接口我们说了算。真实企业里智能体来自不同团队、不同厂商、不同框架它们互不认识、格式各异根本组不成网。让这些异构智能体互相发现能力、交接任务、协同完成跨系统目标就是互操作协议Agent Interoperability的主题代表是 Google 的 A2A 协议。这是智能体从玩具 demo 走向企业级网络的关键一跃。一、为什么需要互操作协议现状痛点每个智能体是信息孤岛能力描述、调用方式、消息格式各自一套无法组合。价值有三能力复用A 团队写的研究智能体B 团队的客服智能体可以直接委派深度调研不用重写。跨厂商协作一个流程里能同时编排开源智能体和商业智能体按性价比组合。动态组网运行时发现新能力、按需委派而不是把所有逻辑写死。关键区分MCP 解决智能体怎么连工具A2A 解决智能体怎么连智能体。两者分工清晰不是替代关系。两类协议分工 ┌──────────────┐ ┌──────────────┐ │ MCP │ │ A2A │ │ Agent→Tool │ │ Agent→Agent │ │ 连数据库/API │ │ 连另一个智能体 │ └──────────────┘ └──────────────┘二、协议分层一个完整的互操作协议通常分四层层职责例子传输层怎么发消息HTTP / gRPC / 消息队列消息层任务消息结构JSON / Protobuf含输入输出 schema能力层我是谁、能做什么Agent Card机器可读能力名片任务层任务生命周期submitted/working/completed/failed能力名片Agent Card是核心一个机器可读的 JSON声明名字、能做的技能、输入输出格式、鉴权方式、端点。别人拿到它就能知道能不能委派、怎么调。{ name: Researcher, capabilities: {streaming: true}, skills: [ {id: deep_search, input: query, output: report} ], endpoints: {url: https://agent.host/a2a}, auth: oauth2 }三、任务交接与状态机委派handoff是协作的原子操作主管智能体把子任务连同上下文与约束交给专家智能体。任务有标准生命周期状态机submitted → working → (input-required ↔ working) → completed ↓ failedinput-required专家智能体需要补充信息反向向主管要主管补完再回到 working。失败要能回滚或重派给其他专家呼应 B34 的 Saga 补偿。# 委派一次研究任务伪代码 task client.send(agent_card.endpoint, { skill: deep_search, input: 对比 A 与 B 的推理优化方案, constraints: {max_steps: 5, timeout_s: 120} }) while task.state input-required: task client.send(task.id, provide_missing_info()) if task.state completed: report task.output四、消息总线与事件驱动当智能体数量变多点对点调用会变成网状混乱。引入消息总线做解耦事件溯源任务状态变更发事件订阅者更新自己的视图。扇出与广播一个事件同时通知多个关心方监控、计费、审计。与编排的关系编排是控制流谁调谁总线是数据流状态怎么流转B34 的编排引擎通常坐在总线上方。五、安全与信任跨厂商智能体本质是不可信的外部服务安全不能省身份认证与授权Agent 间用 OAuth、mTLS最小权限能力白名单。调用审计每次委派留痕出事可追。沙箱隔离高危操作放进沙箱呼应 B16/B32。注入防御收到的任务指令可能是恶意智能体借协作通道投毒要做间接注入检测。六、落地架构与坑注册发现智能体注册到中心调用方按能力检索。负载均衡与超时重试网络不可靠必须设最大委派深度防循环。常见坑schema 漂移升级不兼容、版本错配、循环委派风暴、能力描述虚标。选型自建消息格式看似快实则要把注册、鉴权、重试、版本全重写性价比低优先用开放标准。深度延展互操作协议落地的工程现实把多智能体互操作真正跑起来难的不是协议规范本身而是工程里的脏活。第一能力描述的真实性。能力名片写得好看没用实际能力虚标是最大隐患一个标称能做深度研究的智能体可能只是个带搜索的摘要器。落地要靠运行时探针和评测集持续校验能力声明把自称能做变成实测能做否则上层编排会基于错误假设做委派错误被放大到整个网络。校验可以做成注册时的自动化冒烟测试每次智能体上线或升级自动跑一组最小任务记录真实成功率能力名片附带这份实测数据。第二版本与结构漂移。智能体升级后输入输出结构变了调用方没同步就会静默失败。需要像管理接口一样管理智能体的接口版本带版本号、做兼容期、变更要通知订阅方对关键智能体还要有契约测试结构一变就报警。这是把智能体当服务而非脚本来治理的起点。更进一步要为能力做向后兼容承诺新增可选字段可以改必填字段或改语义必须升主版本并保留旧版一段时间。第三循环依赖与委派风暴。多智能体协作最怕甲委派给乙、乙又委派回甲或因为路由策略错误引发广播风暴瞬间打爆整张网。要在协议层强制最大委派深度、设超时与熔断、用主管智能体做仲裁并保留每只任务的调用链可追溯。这把问题从多智能体协作上升到了系统可靠性层面也是生产级多智能体网络与玩具 demo 的分水岭。调用链可追溯还要求每次委派都带全局追踪标识方便事后复盘风暴根因。第四信任边界。跨厂商智能体本质是不可信的外部服务必须最小权限、调用审计、沙箱隔离并对收到的任务指令做注入检测防止恶意智能体借协作通道越权或窃取数据。这一点和多智能体安全主题一脉相承只是攻击面从单智能体扩展到了网络。还要防范能力借用风险一个被攻陷的智能体可能借合法协作名义调动其他高权限智能体因此权限要按任务临时授予、用完即收。第五发现与治理。企业里智能体数量会膨胀需要服务注册中心做能力发现与负载均衡需要统一的调用审计看板否则网络变成黑盒、出问题无从追查。治理还包括调用配额、优先级、降级策略高优任务优先调度超载时低优任务排队或降级到更弱但更稳的智能体。这和智能体生产化的可观测、灰度、熔断是同一套工程纪律在网络层面的延伸。第六和一个经典架构的对比。很多人把互操作想成微服务确实相似智能体像服务、能力名片像接口描述、委派像远程调用、消息总线像事件总线。区别在于智能体是概率性的、会出错、会编造所以不能照搬同步强一致假设必须容忍失败、支持重试与补偿、并把不确定性显式传回调用方。这个类比能帮面试官快速建立心智模型也能体现你做过分布式系统。最后给选型建议自建一套消息格式看似快实则要把注册发现、鉴权、重试、版本全部重做性价比低优先采用开放标准做智能体间通信、用工具协议做智能体与工具通信二者分工清晰、生态在成形。能讲清为什么不用自己造轮子、两类协议各管什么说明他真在生产里组过网而不是只在单智能体原型里转圈。把互操作当成系统的接入总线而不是又一组接口是智能体走向企业级的分水岭。面试里能把单智能体的灵活和网络的可靠这两件事同时讲明白的人才真正懂生产。补一个能力名片的更完整字段清单帮你在面试里讲出工程细节。一份合格的能力名片至少包含名字与版本、所支持技能列表每个技能含输入输出 schema、是否流式、是否幂等、鉴权方式、网络端点、超时与配额、维护者与状态灰度中或稳定、调用示例。这些字段不是文档摆设而是上层编排做自动委派的依据编排器读名片里的输入输出 schema就能判断某个技能能不能接住当前子任务而不必硬编码。缺少任一场字段自动化编排都会退化回人工配置。再讲任务生命周期的几个边界情况。其一断点续跑长任务中途失败要不要从零重来生产里通常要支持部分结果返回与可恢复句柄呼应 B22 长时任务与断点续跑。其二取消与级联用户取消一个任务要能顺着调用链取消下游所有子任务否则资源泄漏。其三部分结果与流式研究类任务可能先返回大纲再返回全文调用方要能处理中间态。其四失败语义要区分任务本身不可解如权限不足和暂时故障如超时前者快速失败、后者重试。这四类边界是把玩具多智能体变成生产系统的关键。最后落到可观测与事故。多智能体网络一旦出问题定位比单体难十倍因为错误可能跨三个智能体、经过两次委派才暴露。因此必须让每次委派都带全局追踪标识并把谁委派了谁、耗时多少、花了多少钱、返回什么全部进看板。一个真实事故案例某主管智能体因路由配置错误把本该给研究智能体的任务反复委派给自己引发循环十分钟内烧掉整日预算事后靠调用链追踪十分钟内定位并用最大委派深度加熔断根治。能讲出这种从事故到根因到防护的闭环面试官会认定你真在生产里扛过多智能体。把多智能体网络和微服务的类比再推深一层帮助建立系统心智。微服务里服务通过接口描述互相发现、通过远程调用协作、通过服务网格做鉴权限流追踪多智能体网络里智能体通过能力名片互相发现、通过委派协作、通过消息总线与治理层做鉴权限流追踪。但关键差异在于微服务的接口是确定性的同一输入必得同一输出智能体的接口是概率性的同一任务可能给出不同结果还可能编造能力。因此微服务那套强一致加同步调用的假设不能直接照搬必须改成容忍失败、显式传不确定性、支持补偿与重试。能把这套异同讲清面试官会认定你既有分布式系统底子、又有智能体特殊性认知。治理层面要落一组可观测指标建议记这几类每智能体的调用量、成功率、平均时延、成本、被委派深度分布、循环委派次数、注入拦截次数。其中循环委派次数和注入拦截次数是多智能体网络特有的健康度单体智能体完全没有。把这组指标进统一看板网络一有异常比如某智能体突然被高频委派、循环次数飙升立刻能看见。这把 B20 可观测性从单智能体扩展到了网络是生产级多智能体的基本功。迁移策略也值得讲一句别一上来就把所有智能体联网。建议从中心主管加少量专家的小网络起步验证委派与回滚可靠后再逐步接入更多异构智能体新智能体先以影子模式接入只观测不实际委派跑通实测成功率再转正。这种渐进式接入和 B30 生产化的灰度纪律一脉相承能极大降低一上来就全网炸裂的风险。一个真实排障例子某次网络抖动导致专家智能体超时主管没有熔断反而疯狂重试瞬间打满配额根因是缺了委派超时熔断加上最大委派深度限制后就根治了。能讲出这种从事故到根因到防护的闭环比任何架构图都值钱。把多智能体网络和单智能体编排B34的关系点明避免两套知识割裂。单智能体编排解决一个智能体内部怎么把规划、工具、记忆、人工节点串成可控流程多智能体互操作解决多个智能体之间怎么发现能力、交接任务、协同完成跨系统目标。两者是正交的一个编排良好的主管智能体恰恰是通过互操作协议去委派给专家智能体的而专家智能体内部也可能有自己的编排。理解这层嵌套关系你就能把 B34 的编排范式和本篇的协议范式拼成一张完整的智能体系统工程地图。从安全红队的视角再补一层。单智能体时代红队主要测提示注入、工具滥用多智能体网络时代攻击面扩大到智能体之间的信任。设想一个被攻陷的低权限智能体借合法协作名义向高权限智能体发起委派诱导它去读敏感数据或执行危险操作——这是传统单智能体安全里没有的攻击路径。因此网络的权限模型必须按任务临时授权、最小权限、调用链审计来设计并默认任何下游智能体都可能是被污染节点。这和 B32 安全对抗实战一脉相承只是把战场从单点扩展到了拓扑。给一个面试答题框架把本篇收口。被问怎么设计多智能体系统时别急着画架构先问清智能体来自同一团队还是跨厂商、要不要动态组网、失败怎么补偿、安全边界在哪。约束决定架构。然后按四层作答能力层用名片做发现、任务层用状态机做委派、数据层用消息总线解耦、治理层用注册中心加看板做可观测。最后补一句循环委派和注入要当可靠性与安全的一等公民来防。能按这个顺序、这套分层、这组边界去答面试官会认定你是真在生产里组过网而不是只在单智能体 demo 里转圈。收口给一句组织层面的提醒把技术落回管理。多智能体网络一旦建起来就需要有人对它负总责谁登记、谁审计、谁在能力虚标时问责、谁在循环委派烧钱时熔断。很多团队技术选型很热闹却没人运营这张网三个月后智能体列表膨胀、调用链混乱、成本失控最终又退回单体脚本。这和 B30 生产化、B35 落地运营是同一课的重复能上线只是开始能持续运营才是本事。把互操作当成需要专人养的系统而不是一次集成项目是它能不能长期活下来的分水岭。最后再补一句关于演进节奏的提醒多智能体网络不要追求一步到位。先让两个智能体能可靠互委派再把第三个接进来每接一个都跑一遍实测成功率与循环检测网络规模和能力一起长。这种小步快跑的节奏能把绝大多数全网炸裂事故消灭在萌芽也是工程上最稳的扩网方式。能讲出这个节奏感面试官会认定你不是只在白板上画过大网络而是真把它一步步养起来的。面试速答 高频追问清单面试速答- 互操作解决异构智能体组网MCP 管工具、A2A 管智能体分工不同。- 四层传输、消息、能力Agent Card、任务状态机。Agent Card 声明能力。- 委派带上下文与约束任务有 submitted→working→completed/failed 生命周期失败可重派。- 消息总线解耦控制流与数据流支持扇出与事件溯源。- 安全最小权限、审计、沙箱、注入防御坑在 schema 漂移与循环委派。高频追问清单1. A2A 和 MCP 什么关系——前者智能体间、后者智能体连工具互补。2. Agent Card 必须包含什么——名字、技能、输入输出、端点、鉴权。3. 任务状态机有哪些态——submitted/working/input-required/completed/failed。4. 循环委派怎么防——最大委派深度、超时熔断、主管仲裁。5. 怎么防能力虚标——运行时探针评测集校验能力声明。6. schema 漂移怎么治——版本号、兼容期、契约测试。7. 不可信智能体怎么隔离——最小权限、沙箱、注入检测。8. 消息总线解决什么——解耦点对点网状调用支持扇出与溯源。9. 和 B34 编排的关系——编排是控制流总线是数据流。10. 为什么不建议自建协议——注册/鉴权/重试/版本都要重写性价比低。 
长河君 · 2026/8/18 21:28:12 · 阅读 1.2k 智能体面试准备（三十七）：多智能体通信协议与互操作（A2A）
智能体面试准备三十七多智能体通信协议与互操作A2A本文是 B 系列在三十六篇核心完结之后的前沿延伸第一篇。B14 讲了智能体怎么连工具MCPB15 讲了多智能体怎么协作B34 讲了编排与流程引擎——但都默认智能体是我们自己写的、接口我们说了算。真实企业里智能体来自不同团队、不同厂商、不同框架它们互不认识、格式各异根本组不成网。让这些异构智能体互相发现能力、交接任务、协同完成跨系统目标就是互操作协议Agent Interoperability的主题代表是 Google 的 A2A 协议。这是智能体从玩具 demo 走向企业级网络的关键一跃。一、为什么需要互操作协议现状痛点每个智能体是信息孤岛能力描述、调用方式、消息格式各自一套无法组合。价值有三能力复用A 团队写的研究智能体B 团队的客服智能体可以直接委派深度调研不用重写。跨厂商协作一个流程里能同时编排开源智能体和商业智能体按性价比组合。动态组网运行时发现新能力、按需委派而不是把所有逻辑写死。关键区分MCP 解决智能体怎么连工具A2A 解决智能体怎么连智能体。两者分工清晰不是替代关系。两类协议分工 ┌──────────────┐ ┌──────────────┐ │ MCP │ │ A2A │ │ Agent→Tool │ │ Agent→Agent │ │ 连数据库/API │ │ 连另一个智能体 │ └──────────────┘ └──────────────┘二、协议分层一个完整的互操作协议通常分四层层职责例子传输层怎么发消息HTTP / gRPC / 消息队列消息层任务消息结构JSON / Protobuf含输入输出 schema能力层我是谁、能做什么Agent Card机器可读能力名片任务层任务生命周期submitted/working/completed/failed能力名片Agent Card是核心一个机器可读的 JSON声明名字、能做的技能、输入输出格式、鉴权方式、端点。别人拿到它就能知道能不能委派、怎么调。{ name: Researcher, capabilities: {streaming: true}, skills: [ {id: deep_search, input: query, output: report} ], endpoints: {url: https://agent.host/a2a}, auth: oauth2 }三、任务交接与状态机委派handoff是协作的原子操作主管智能体把子任务连同上下文与约束交给专家智能体。任务有标准生命周期状态机submitted → working → (input-required ↔ working) → completed ↓ failedinput-required专家智能体需要补充信息反向向主管要主管补完再回到 working。失败要能回滚或重派给其他专家呼应 B34 的 Saga 补偿。# 委派一次研究任务伪代码 task client.send(agent_card.endpoint, { skill: deep_search, input: 对比 A 与 B 的推理优化方案, constraints: {max_steps: 5, timeout_s: 120} }) while task.state input-required: task client.send(task.id, provide_missing_info()) if task.state completed: report task.output四、消息总线与事件驱动当智能体数量变多点对点调用会变成网状混乱。引入消息总线做解耦事件溯源任务状态变更发事件订阅者更新自己的视图。扇出与广播一个事件同时通知多个关心方监控、计费、审计。与编排的关系编排是控制流谁调谁总线是数据流状态怎么流转B34 的编排引擎通常坐在总线上方。五、安全与信任跨厂商智能体本质是不可信的外部服务安全不能省身份认证与授权Agent 间用 OAuth、mTLS最小权限能力白名单。调用审计每次委派留痕出事可追。沙箱隔离高危操作放进沙箱呼应 B16/B32。注入防御收到的任务指令可能是恶意智能体借协作通道投毒要做间接注入检测。六、落地架构与坑注册发现智能体注册到中心调用方按能力检索。负载均衡与超时重试网络不可靠必须设最大委派深度防循环。常见坑schema 漂移升级不兼容、版本错配、循环委派风暴、能力描述虚标。选型自建消息格式看似快实则要把注册、鉴权、重试、版本全重写性价比低优先用开放标准。深度延展互操作协议落地的工程现实把多智能体互操作真正跑起来难的不是协议规范本身而是工程里的脏活。第一能力描述的真实性。能力名片写得好看没用实际能力虚标是最大隐患一个标称能做深度研究的智能体可能只是个带搜索的摘要器。落地要靠运行时探针和评测集持续校验能力声明把自称能做变成实测能做否则上层编排会基于错误假设做委派错误被放大到整个网络。校验可以做成注册时的自动化冒烟测试每次智能体上线或升级自动跑一组最小任务记录真实成功率能力名片附带这份实测数据。第二版本与结构漂移。智能体升级后输入输出结构变了调用方没同步就会静默失败。需要像管理接口一样管理智能体的接口版本带版本号、做兼容期、变更要通知订阅方对关键智能体还要有契约测试结构一变就报警。这是把智能体当服务而非脚本来治理的起点。更进一步要为能力做向后兼容承诺新增可选字段可以改必填字段或改语义必须升主版本并保留旧版一段时间。第三循环依赖与委派风暴。多智能体协作最怕甲委派给乙、乙又委派回甲或因为路由策略错误引发广播风暴瞬间打爆整张网。要在协议层强制最大委派深度、设超时与熔断、用主管智能体做仲裁并保留每只任务的调用链可追溯。这把问题从多智能体协作上升到了系统可靠性层面也是生产级多智能体网络与玩具 demo 的分水岭。调用链可追溯还要求每次委派都带全局追踪标识方便事后复盘风暴根因。第四信任边界。跨厂商智能体本质是不可信的外部服务必须最小权限、调用审计、沙箱隔离并对收到的任务指令做注入检测防止恶意智能体借协作通道越权或窃取数据。这一点和多智能体安全主题一脉相承只是攻击面从单智能体扩展到了网络。还要防范能力借用风险一个被攻陷的智能体可能借合法协作名义调动其他高权限智能体因此权限要按任务临时授予、用完即收。第五发现与治理。企业里智能体数量会膨胀需要服务注册中心做能力发现与负载均衡需要统一的调用审计看板否则网络变成黑盒、出问题无从追查。治理还包括调用配额、优先级、降级策略高优任务优先调度超载时低优任务排队或降级到更弱但更稳的智能体。这和智能体生产化的可观测、灰度、熔断是同一套工程纪律在网络层面的延伸。第六和一个经典架构的对比。很多人把互操作想成微服务确实相似智能体像服务、能力名片像接口描述、委派像远程调用、消息总线像事件总线。区别在于智能体是概率性的、会出错、会编造所以不能照搬同步强一致假设必须容忍失败、支持重试与补偿、并把不确定性显式传回调用方。这个类比能帮面试官快速建立心智模型也能体现你做过分布式系统。最后给选型建议自建一套消息格式看似快实则要把注册发现、鉴权、重试、版本全部重做性价比低优先采用开放标准做智能体间通信、用工具协议做智能体与工具通信二者分工清晰、生态在成形。能讲清为什么不用自己造轮子、两类协议各管什么说明他真在生产里组过网而不是只在单智能体原型里转圈。把互操作当成系统的接入总线而不是又一组接口是智能体走向企业级的分水岭。面试里能把单智能体的灵活和网络的可靠这两件事同时讲明白的人才真正懂生产。补一个能力名片的更完整字段清单帮你在面试里讲出工程细节。一份合格的能力名片至少包含名字与版本、所支持技能列表每个技能含输入输出 schema、是否流式、是否幂等、鉴权方式、网络端点、超时与配额、维护者与状态灰度中或稳定、调用示例。这些字段不是文档摆设而是上层编排做自动委派的依据编排器读名片里的输入输出 schema就能判断某个技能能不能接住当前子任务而不必硬编码。缺少任一场字段自动化编排都会退化回人工配置。再讲任务生命周期的几个边界情况。其一断点续跑长任务中途失败要不要从零重来生产里通常要支持部分结果返回与可恢复句柄呼应 B22 长时任务与断点续跑。其二取消与级联用户取消一个任务要能顺着调用链取消下游所有子任务否则资源泄漏。其三部分结果与流式研究类任务可能先返回大纲再返回全文调用方要能处理中间态。其四失败语义要区分任务本身不可解如权限不足和暂时故障如超时前者快速失败、后者重试。这四类边界是把玩具多智能体变成生产系统的关键。最后落到可观测与事故。多智能体网络一旦出问题定位比单体难十倍因为错误可能跨三个智能体、经过两次委派才暴露。因此必须让每次委派都带全局追踪标识并把谁委派了谁、耗时多少、花了多少钱、返回什么全部进看板。一个真实事故案例某主管智能体因路由配置错误把本该给研究智能体的任务反复委派给自己引发循环十分钟内烧掉整日预算事后靠调用链追踪十分钟内定位并用最大委派深度加熔断根治。能讲出这种从事故到根因到防护的闭环面试官会认定你真在生产里扛过多智能体。把多智能体网络和微服务的类比再推深一层帮助建立系统心智。微服务里服务通过接口描述互相发现、通过远程调用协作、通过服务网格做鉴权限流追踪多智能体网络里智能体通过能力名片互相发现、通过委派协作、通过消息总线与治理层做鉴权限流追踪。但关键差异在于微服务的接口是确定性的同一输入必得同一输出智能体的接口是概率性的同一任务可能给出不同结果还可能编造能力。因此微服务那套强一致加同步调用的假设不能直接照搬必须改成容忍失败、显式传不确定性、支持补偿与重试。能把这套异同讲清面试官会认定你既有分布式系统底子、又有智能体特殊性认知。治理层面要落一组可观测指标建议记这几类每智能体的调用量、成功率、平均时延、成本、被委派深度分布、循环委派次数、注入拦截次数。其中循环委派次数和注入拦截次数是多智能体网络特有的健康度单体智能体完全没有。把这组指标进统一看板网络一有异常比如某智能体突然被高频委派、循环次数飙升立刻能看见。这把 B20 可观测性从单智能体扩展到了网络是生产级多智能体的基本功。迁移策略也值得讲一句别一上来就把所有智能体联网。建议从中心主管加少量专家的小网络起步验证委派与回滚可靠后再逐步接入更多异构智能体新智能体先以影子模式接入只观测不实际委派跑通实测成功率再转正。这种渐进式接入和 B30 生产化的灰度纪律一脉相承能极大降低一上来就全网炸裂的风险。一个真实排障例子某次网络抖动导致专家智能体超时主管没有熔断反而疯狂重试瞬间打满配额根因是缺了委派超时熔断加上最大委派深度限制后就根治了。能讲出这种从事故到根因到防护的闭环比任何架构图都值钱。把多智能体网络和单智能体编排B34的关系点明避免两套知识割裂。单智能体编排解决一个智能体内部怎么把规划、工具、记忆、人工节点串成可控流程多智能体互操作解决多个智能体之间怎么发现能力、交接任务、协同完成跨系统目标。两者是正交的一个编排良好的主管智能体恰恰是通过互操作协议去委派给专家智能体的而专家智能体内部也可能有自己的编排。理解这层嵌套关系你就能把 B34 的编排范式和本篇的协议范式拼成一张完整的智能体系统工程地图。从安全红队的视角再补一层。单智能体时代红队主要测提示注入、工具滥用多智能体网络时代攻击面扩大到智能体之间的信任。设想一个被攻陷的低权限智能体借合法协作名义向高权限智能体发起委派诱导它去读敏感数据或执行危险操作——这是传统单智能体安全里没有的攻击路径。因此网络的权限模型必须按任务临时授权、最小权限、调用链审计来设计并默认任何下游智能体都可能是被污染节点。这和 B32 安全对抗实战一脉相承只是把战场从单点扩展到了拓扑。给一个面试答题框架把本篇收口。被问怎么设计多智能体系统时别急着画架构先问清智能体来自同一团队还是跨厂商、要不要动态组网、失败怎么补偿、安全边界在哪。约束决定架构。然后按四层作答能力层用名片做发现、任务层用状态机做委派、数据层用消息总线解耦、治理层用注册中心加看板做可观测。最后补一句循环委派和注入要当可靠性与安全的一等公民来防。能按这个顺序、这套分层、这组边界去答面试官会认定你是真在生产里组过网而不是只在单智能体 demo 里转圈。收口给一句组织层面的提醒把技术落回管理。多智能体网络一旦建起来就需要有人对它负总责谁登记、谁审计、谁在能力虚标时问责、谁在循环委派烧钱时熔断。很多团队技术选型很热闹却没人运营这张网三个月后智能体列表膨胀、调用链混乱、成本失控最终又退回单体脚本。这和 B30 生产化、B35 落地运营是同一课的重复能上线只是开始能持续运营才是本事。把互操作当成需要专人养的系统而不是一次集成项目是它能不能长期活下来的分水岭。最后再补一句关于演进节奏的提醒多智能体网络不要追求一步到位。先让两个智能体能可靠互委派再把第三个接进来每接一个都跑一遍实测成功率与循环检测网络规模和能力一起长。这种小步快跑的节奏能把绝大多数全网炸裂事故消灭在萌芽也是工程上最稳的扩网方式。能讲出这个节奏感面试官会认定你不是只在白板上画过大网络而是真把它一步步养起来的。面试速答 高频追问清单面试速答- 互操作解决异构智能体组网MCP 管工具、A2A 管智能体分工不同。- 四层传输、消息、能力Agent Card、任务状态机。Agent Card 声明能力。- 委派带上下文与约束任务有 submitted→working→completed/failed 生命周期失败可重派。- 消息总线解耦控制流与数据流支持扇出与事件溯源。- 安全最小权限、审计、沙箱、注入防御坑在 schema 漂移与循环委派。高频追问清单1. A2A 和 MCP 什么关系——前者智能体间、后者智能体连工具互补。2. Agent Card 必须包含什么——名字、技能、输入输出、端点、鉴权。3. 任务状态机有哪些态——submitted/working/input-required/completed/failed。4. 循环委派怎么防——最大委派深度、超时熔断、主管仲裁。5. 怎么防能力虚标——运行时探针评测集校验能力声明。6. schema 漂移怎么治——版本号、兼容期、契约测试。7. 不可信智能体怎么隔离——最小权限、沙箱、注入检测。8. 消息总线解决什么——解耦点对点网状调用支持扇出与溯源。9. 和 B34 编排的关系——编排是控制流总线是数据流。10. 为什么不建议自建协议——注册/鉴权/重试/版本都要重写性价比低。