A2A与MCP：多Agent系统中语义通信与上下文治理双范式

1. 项目概述当AI不再单打独斗而是组成“作战小队”“Architecting Intelligent Multi-Agent AI Systems: A2A vs MCP”——这个标题一出现我就知道这不是又一篇泛泛而谈的AI概念文而是一份面向真实工程落地的系统设计说明书。它直指当前大模型应用落地中最棘手、也最具潜力的瓶颈如何让多个AI智能体像人类团队一样分工协作、信息共享、动态决策而不是各自为战、互相幻觉、结果不可控核心关键词“A2A”Agent-to-Agent和“MCP”Model Context Protocol不是新造的营销术语而是两种正在被一线团队反复验证、踩坑、重构的底层通信范式。我过去两年带过7个跨Agent项目从金融风控链路到工业设备故障推演几乎每个项目都卡在“怎么让Agent之间说人话、不扯皮、不重复劳动”这个环节。A2A强调的是Agent之间的点对点、语义级对话能力它解决的是“谁跟谁说话、说什么、怎么确认听懂了”的问题而MCP则更像一套标准化的“AI会议纪要协议”它不关心具体聊什么而是强制规定所有对话必须附带上下文快照、角色声明、意图标签和可信度锚点。这两者不是非此即彼的替代关系而是“战术执行层”与“组织治理层”的配合。适合谁看如果你正面临以下任一场景需要把多个专业模型比如一个法律条款解析Agent、一个合同风险评估Agent、一个客户沟通话术生成Agent串成一条服务流水线或者你的Agent系统开始出现“前一个Agent输出的结果后一个Agent完全理解错还自信满满”的幻觉级错误又或者你发现调试一个多Agent流程80%的时间花在翻日志、猜状态、手动补上下文上——那这篇就是为你写的。它不讲空泛的“未来已来”只讲今天下午三点你打开IDE时该删哪行代码、该加哪个中间件、该在哪个环节埋监控点。2. 系统设计思路拆解为什么必须放弃“单Agent思维”转向“组织架构设计”2.1 从单体Agent到多Agent系统的根本性跃迁很多人初看多Agent系统下意识把它当成“多个ChatGPT连起来用”。这是最危险的认知偏差。单体Agent的本质是状态封闭的函数调用输入Prompt输出Token中间过程黑箱失败了重试就行。而一个健康的多Agent系统其核心挑战早已从“模型好不好”转移到“组织稳不稳”。我拿一个真实案例说明去年帮一家物流平台做运单异常协同处理系统。最初方案是让一个超级Agent读取全部运单数据、识别异常、生成处理建议、再模拟客服外呼——结果上线三天90%的“建议”都是基于过期库存数据生成的幻觉结论。后来我们彻底重构拆成三个Agent数据哨兵Agent只负责实时拉取并校验T0库存与GPS轨迹、规则裁判Agent只接收哨兵发来的结构化异常事件按预设SOP匹配处理路径、执行协调Agent只接收裁判发来的带ID的处理指令调用对应API并反馈执行结果。关键变化在哪不是模型换了而是通信契约变了。旧方案里所有信息都塞在一个Prompt里模型自己“脑补”关联新方案里每个Agent的输入/输出都被严格定义为JSON Schema且每次通信都强制携带event_id、source_timestamp、confidence_score三个元字段。这看似增加了开发量但上线后误判率下降76%平均问题闭环时间从47分钟压缩到6.3分钟。这印证了一个硬道理多Agent系统的可靠性不取决于单个Agent的智商上限而取决于Agent间通信的确定性下限。A2A和MCP正是为这个“确定性下限”提供不同维度的保障。2.2 A2A构建Agent间的“语义级对话能力”A2AAgent-to-Agent协议的核心诉求是让Agent具备主动发起对话、理解对方意图、协商共识、处理异议的能力而非被动响应API调用。它解决的是“人机协作”中“人”的那一半缺失。举个反例很多团队用LangChain的SequentialChain串联Agent表面看是“先A再B”实则A的输出只是B的输入字符串B对A的推理过程、置信依据、知识边界一无所知。这就导致B可能把A的低置信度猜测当作事实来加工错误被指数级放大。真正的A2A实现必须包含三个刚性组件意图声明层Intent Declaration每个Agent在发起通信前必须明确声明本次交互的目的类型如query、verify、delegate、escalate和预期响应格式如{status:success,data:{...}}或{status:error,code:DATA_STALE,suggestion:retry_with_timestamp2024-05-20T14:22:00Z}。我们曾给一个医疗问诊Agent增加intent: verify_diagnosis字段强制下游药剂师Agent必须返回{verification_result:confirmed|rejected|insufficient_data,evidence_refs:[guideline_2023_v4#section3.2]}直接杜绝了模糊应答。上下文锚定层Context AnchoringA2A通信绝不能脱离上下文快照。我们要求每次消息体必须嵌入context_snapshot对象包含relevant_knowledge_ids引用的知识库片段ID、active_constraints当前生效的业务规则ID列表、temporal_window本次决策依赖的时间范围。例如当风控Agent向征信Agent发起查询时context_snapshot会明确标注temporal_window:last_7_days征信Agent若发现数据延迟超48小时会直接返回code: DATA_STALE而非强行计算。协商反馈环Negotiation Feedback LoopA2A必须支持异步协商。典型场景是Agent A请求Agent B执行某任务B评估后认为资源不足不应简单返回503而应触发协商{intent:negotiate,proposal:{alternative_task:summarize_risk_factors,deadline:2024-05-20T15:00:00Z}}。A可接受、拒绝或提出新提案。我们在线上系统中观察到引入协商机制后因资源冲突导致的流程中断下降了92%。提示A2A不是银弹。它显著提升系统鲁棒性但代价是通信开销增加约18%-25%实测数据且对Agent的“自我认知”能力要求极高——Agent必须能准确评估自身能力边界否则协商会陷入无限循环。我们内部有个铁律没有经过至少3轮“能力自检测试”的Agent禁止接入A2A网络。2.3 MCP为Agent协作建立“组织级治理框架”如果说A2A是Agent间的“外交辞令”那么MCPModel Context Protocol就是整个AI组织的“宪法”。它的设计哲学完全不同不试图让Agent更聪明而是通过强制性的上下文规范让愚蠢的Agent也能被安全使用。我们最早接触MCP是在处理一个政府公文智能核稿项目。当时遇到一个致命问题政策解读Agent基于最新法规微调和格式审查Agent基于历史公文模板训练经常“打架”——前者坚持某条款必须删除后者坚持该位置必须保留固定格式。根源在于两个Agent看到的“上下文”完全不同解读Agent看到的是2024年新规PDF格式Agent看到的是2019年模板Word。MCP的解决方案极其朴素所有Agent的输入必须是一个标准化的Context BundleCB对象且CB的生成、分发、验证由独立的Context ManagerCM统一管控。一个典型的CB结构如下{ cb_id: cb_20240520_142200_abc123, version: 1.2, sources: [ { type: regulation, id: gov_reg_2024_05_v3, timestamp: 2024-05-15T08:00:00Z, digest: sha256:abcd1234... }, { type: template, id: gov_doc_template_v2019, timestamp: 2019-03-10T12:00:00Z, digest: sha256:efgh5678... } ], constraints: [ {type: compliance, rule_id: gov_compliance_rule_2024}, {type: format, rule_id: gov_format_spec_v2023} ], provenance: { generated_by: cm_service_v2.1, generated_at: 2024-05-20T14:22:00Z, valid_until: 2024-05-20T15:22:00Z } }关键点在于CB是只读的、不可篡改的Agent只能读取CB不能修改其内容。任何对上下文的“补充”或“修正”都必须通过CM发起新的CB版本。CB自带时效性与来源认证valid_until强制Agent在过期前重新获取digest确保内容未被污染。我们曾发现一个Agent缓存了过期CB长达3天导致批量公文审核全部失效CM的日志告警直接定位到该实例。约束Constraints是CB的刚性组成部分不是可选配置而是CB的必填字段。Agent在处理前必须校验自身是否满足所有constraints不满足则必须拒绝处理并上报。这从根本上杜绝了“用错规则”的问题。MCP的价值在于它把“上下文一致性”这个软性要求变成了可审计、可追踪、可强制的硬性基础设施。它不解决Agent能不能干而是确保所有Agent都在同一套规则下干。2.4 A2A与MCP的协同战术执行与战略治理的黄金配比把A2A和MCP对立起来是常见误区。它们不是选择题而是不同抽象层级的必需品。我们可以用一个制造业设备预测性维护系统来具象化它们的协同关系MCP层战略治理由中央Context Manager统一发布设备全生命周期CB。该CB包含设备IoT传感器实时流type: iot_stream、维修工单历史type: maintenance_log、备件库存状态type: inventory、以及强制约束{type:safety,rule_id:iso_13849_sil3}要求所有决策必须满足SIL3安全等级。所有Agent启动时必须加载此CB且CB每15分钟自动刷新。A2A层战术执行当振动分析Agent检测到异常频谱时它不直接报警而是向故障诊断Agent发起A2A请求intent: diagnose并附上context_snapshot指向当前CB的cb_id及sources[0].id即本次分析所用的具体传感器流片段。诊断Agent完成分析后向维修调度Agent发起intent: schedule_maintenance并携带诊断结论及constraints中safety规则的符合性证明如{safety_compliance:verified_by_simulator_v2.4}。协同效果MCP确保所有Agent看到的“设备现状”和“安全红线”绝对一致A2A确保各Agent在一致的前提下能高效、精准、可追溯地完成专业分工。我们实测该架构下从异常检测到维修工单生成的端到端延迟稳定在2.1秒内P95且100%的维修决策日志均可回溯至原始CB和每一次A2A协商记录。注意过度依赖MCP会导致系统僵化。我们曾在一个项目中将所有业务规则都写死在CB的constraints里结果一次临时政策调整需要重启全部Agent。教训是MCP管“不变的底线”A2A管“变化的策略”。像合规性、安全性等强约束放MCP像优先级排序、资源分配等柔性策略应通过A2A动态协商。3. 核心细节解析与实操要点从协议文档到可运行代码的关键跨越3.1 A2A协议栈的轻量化实现不造轮子只焊接口很多团队一上来就想自研A2A通信框架结果半年过去还在纠结序列化格式。我的经验是用好现有成熟协议聚焦在“语义层”的胶水逻辑上。我们目前生产环境采用的A2A栈是“HTTP/REST JSON Schema 自定义Header”的极简组合而非gRPC或WebSocket。原因很实在HTTP的调试友好性、工具链成熟度、防火墙穿透性对快速迭代至关重要。关键不在传输层而在消息体的设计与校验。一个标准的A2A请求消息体Request Payload必须包含以下最小字段集{ a2a_version: 0.3, message_id: msg_20240520_142200_abc123, sender: { agent_id: risk_analyzer_v2, role: analyst }, receiver: { agent_id: compliance_checker_v1, role: auditor }, intent: verify_compliance, payload: { document_id: doc_789012, proposed_clause: The vendor shall deliver goods within 5 business days. }, context_snapshot: { cb_id: cb_20240520_140000_xyz789, relevant_knowledge_ids: [legal_guideline_2024#section4.2], temporal_window: 2024-05-20T00:00:00Z/2024-05-20T23:59:59Z }, metadata: { priority: high, timeout_ms: 15000, trace_id: trc_20240520_142200_abc123 } }为什么这样设计逐条解释a2a_version强制版本控制。我们规定任何Agent升级A2A协议版本必须同时提供向下兼容的转换器否则禁止上线。这避免了“版本碎片化”导致的通信雪崩。message_idtrace_id这是调试的生命线。我们所有Agent日志都强制注入trace_idKibana里输入一个ID就能串起从发起、转发、处理到响应的全链路。没有这个排查多Agent问题就是大海捞针。sender/receiver的role字段这是意图理解的关键。role: analyst意味着发送方期望接收方提供专业判断而非简单事实查询role: auditor则暗示接收方需提供可审计的证据链。我们在合规Checker Agent里根据receiver.role动态切换输出模板——给auditor的响应必须包含evidence_refs数组。context_snapshot.cb_id这是A2A与MCP的握手点。A2A消息不携带原始上下文数据只携带CB的唯一ID由接收方自行向CM服务拉取。这保证了上下文的一致性也避免了消息体膨胀。实操心得别在序列化上过度优化。我们曾用Protocol Buffers压测相比JSON仅节省12%带宽但调试成本飙升300%。现在所有开发环境强制用JSON生产环境才开启gzip压缩。工程师的时间永远比12%的带宽更昂贵。3.2 MCP Context BundleCB的生成与分发CM服务的核心职责MCP的落地成败系于Context ManagerCM服务。它不是简单的键值存储而是一个具备版本管理、一致性校验、策略分发能力的有状态服务。我们采用“双写最终一致”的架构确保高可用CB生成Write Path业务系统如ERP、CRM或数据管道如Flink作业产生新数据后不直接写入CM而是先写入Kafka Topiccb_events。CM服务作为消费者监听此Topic对每条事件进行来源校验检查数据源签名如JWT token from data_producer_service。内容哈希计算sources数组中每个源数据的SHA256并存入CB。约束注入根据事件类型如regulation_update动态注入对应的constraints如{type:compliance,rule_id:gdpr_art17}。版本递增CB的version字段遵循语义化版本SemVer主版本号MAJOR表示约束规则变更次版本号MINOR表示数据源更新修订号PATCH表示元数据修正。CB分发Read PathAgent通过HTTP GET/cb/{cb_id}获取CB。CM服务在此处实施关键策略缓存穿透防护对不存在的cb_id返回404并记录但不穿透到后端存储。时效性强制响应头中必须包含X-CB-Valid-Until: 2024-05-20T15:22:00ZAgent SDK会自动在到期前10秒发起预刷新。灰度分发新版本CB发布时先以canary: 0.055%流量分发监控错误率达标后再全量。一个血泪教训最初我们让CM直接存储原始PDF/Word文件结果存储成本暴增且检索缓慢。后来改为只存储结构化摘要如PDF的OCR文本关键段落坐标元数据和原始文件的CDN URL。Agent需要原文时再按URL下载。这使CM存储成本降低83%CB获取P95延迟从320ms降至45ms。3.3 Agent SDK让开发者专注业务逻辑而非协议细节再好的协议如果开发者每次都要手写context_snapshot、拼接trace_id、处理intent路由必然失败。我们为所有Agent开发了统一SDKPython/Java/Go三版核心封装了A2A Client提供send_intent(sender, receiver, intent, payload, context_snapshot)方法。内部自动注入message_id、trace_id、a2a_version并处理HTTP重试指数退避、超时熔断timeout_ms、错误分类5xx重试4xx直接抛出A2AValidationError。MCP Client提供get_context_bundle(cb_id)和refresh_context_bundle()方法。内部自动处理缓存、预刷新、X-CB-Valid-Until校验并在valid_until临近时触发on_context_expiring回调方便Agent优雅降级。Intent RouterAgent只需注册handle_intent(verify_compliance)装饰器SDK自动将收到的A2A请求路由到对应函数并注入context_snapshot和metadata。SDK的杀手锏功能是“本地上下文沙盒”当Agent收到一个CB IDSDK会自动在本地内存中创建一个只读沙盒将CB内容解构为强类型对象如ComplianceContext类并提供.get_source(regulation)、.check_constraint(safety)等便捷方法。开发者永远不用手动解析JSON也不用担心CB结构变更——SDK升级即可。实操心得SDK必须提供“协议合规性自检”命令。我们在CI/CD流水线中加入agent-sdk check-compliance --agent-id risk_analyzer_v2它会自动检查Agent是否实现了所有必需的Intent Handler、是否正确注入了Context Snapshot、是否在on_context_expiring中做了降级处理。不通过自检的Agent禁止打包部署。这是保障协议落地的最后一道防线。4. 实操过程与核心环节实现从零搭建一个可验证的A2AMCP系统4.1 环境准备与最小可行系统MVP搭建别一上来就搞全链路。我们的标准MVP只包含3个组件1个CM服务、2个Agent一个Sender一个Receiver、1个CLI测试工具。所有组件均用Docker Compose编排5分钟内可启动。以下是docker-compose.yml核心片段version: 3.8 services: cm-service: image: our-registry/cm-service:v2.1 ports: - 8080:8080 environment: - CM_STORAGE_TYPEredis - REDIS_URLredis://redis:6379/0 depends_on: - redis risk-analyzer: image: our-registry/agent-risk:v1.0 environment: - CM_SERVICE_URLhttp://cm-service:8080 - AGENT_IDrisk_analyzer_v1 - AGENT_ROLEanalyst depends_on: - cm-service compliance-checker: image: our-registry/agent-compliance:v1.0 environment: - CM_SERVICE_URLhttp://cm-service:8080 - AGENT_IDcompliance_checker_v1 - AGENT_ROLEauditor depends_on: - cm-service redis: image: redis:7-alpine command: redis-server --save 20 1 --loglevel warning关键配置说明CM_SERVICE_URL所有Agent必须通过此环境变量知晓CM地址避免硬编码。AGENT_ID/AGENT_ROLE用于A2A消息中的sender/receiver字段也是CM服务进行访问控制的依据。Redis作为CM的后端存储轻量、高性能、支持Pub/Sub用于CB变更通知。启动后用CLI工具发送第一条A2A消息验证通路# 1. 先向CM注册一个测试CB curl -X POST http://localhost:8080/cb \ -H Content-Type: application/json \ -d { version: 1.0, sources: [{type:test_data,id:test_001,timestamp:2024-05-20T00:00:00Z}], constraints: [{type:test,rule_id:always_pass}] } # 2. 触发A2A通信risk_analyzer - compliance_checker curl -X POST http://localhost:8080/a2a \ -H Content-Type: application/json \ -d { a2a_version: 0.3, message_id: test_msg_001, sender: {agent_id:risk_analyzer_v1,role:analyst}, receiver: {agent_id:compliance_checker_v1,role:auditor}, intent: verify_test, payload: {test_input: hello_world}, context_snapshot: {cb_id: cb_20240520_000000_test_001} }如果compliance_checker日志中出现Received verify_test intent for cb_idcb_20240520_000000_test_001且返回了正确响应则MVP通路打通。这一步必须手工验证不能跳过。我们见过太多团队跳过MVP直接上复杂场景结果卡在DNS解析或端口映射上浪费两天。4.2 A2A Intent路由与处理的完整代码实现以Python SDK为例展示compliance_checkerAgent如何实现verify_testIntent。重点看SDK如何将协议细节隐藏让开发者只关注业务# compliance_checker/app.py from agent_sdk import A2AHandler, MCPClient, get_logger import json logger get_logger(__name__) mcp_client MCPClient() # 初始化MCP客户端 # 注册Intent处理器 A2AHandler(intentverify_test) def handle_verify_test(sender, payload, context_snapshot, metadata): 处理来自risk_analyzer的测试验证请求 :param sender: dict, 发送方信息 :param payload: dict, 业务载荷 :param context_snapshot: dict, 上下文快照 :param metadata: dict, 元数据含priority, timeout_ms等 try: # 1. 从context_snapshot获取CB ID并拉取完整CB cb_id context_snapshot.get(cb_id) if not cb_id: raise ValueError(context_snapshot missing cb_id) cb mcp_client.get_context_bundle(cb_id) logger.info(fRetrieved CB {cb_id}, version {cb.version}) # 2. 验证CB的约束是否满足MCP治理层 if not cb.check_constraint(test): raise RuntimeError(fCB {cb_id} violates constraint test) # 3. 执行业务逻辑A2A执行层 # 这里是真正的业务基于CB中的test_data做验证 test_data cb.get_source(test_data) result _do_verification(payload[test_input], test_data) # 4. 构建标准化响应符合A2A协议 return { status: success, result: result, evidence_refs: [ftest_data#{test_data.id}], # 满足auditor角色要求 confidence_score: 0.98 } except Exception as e: logger.error(fFailed to handle verify_test: {e}) # A2A协议要求错误必须返回标准化结构 return { status: error, code: VERIFICATION_FAILED, message: str(e), suggestion: Check test_data source in CB } def _do_verification(input_text, test_data_source): 真实的业务验证逻辑 # 示例简单字符串匹配 return input_text in test_data_source.get(content, )代码背后的关键设计A2AHandler(intentverify_test)SDK自动将HTTP请求路由至此函数无需开发者写Flask路由。mcp_client.get_context_bundle(cb_id)SDK自动处理缓存、刷新、超时开发者只管用。cb.check_constraint(test)SDK自动解析CB的constraints数组找到匹配项并执行校验逻辑。错误处理无论发生什么异常都必须返回A2A协议规定的{status:error, ...}结构这是协议互操作性的基石。4.3 MCP CB的动态更新与Agent热重载真实世界中CB不可能一成不变。政策更新、数据源漂移、规则调整都是常态。MCP必须支持CB的平滑更新且Agent能无感热重载。我们的方案是“双CB心跳探测”CM服务在发布新CB时同时保留旧CB默认保留最近3个版本并在新CB的provenance中添加replaces_cb_id: cb_old_id字段。Agent SDK内置心跳机制每隔heartbeat_interval默认30秒向CM发送GET/cb/{current_cb_id}/health。CM响应中包含status: valid或deprecated或invalid若为deprecated响应体中包含new_cb_id和grace_period_secondsAgent SDK根据心跳响应行动status: valid继续使用当前CB。status: deprecated启动后台线程预加载new_cb_id并在grace_period_seconds后如300秒自动切换。status: invalid立即切换到new_cb_id并触发告警。实操现场记录在一次金融监管新规上线前我们提前24小时发布了新CBcb_20240520_new并将旧CB标记为deprecatedgrace_period_seconds180030分钟。所有Agent在30分钟内完成平滑切换期间无一笔交易因上下文不一致而失败。而旧方案Agent定期轮询CB版本号导致部分实例在切换窗口期读取到新旧混合的CB引发严重合规风险。4.4 监控与可观测性让多Agent系统“看得见、管得住”没有监控的多Agent系统就像没有仪表盘的飞机。我们为A2AMCP系统建立了三层监控监控层级关键指标采集方式告警阈值作用A2A通信层a2a_request_total{intent, status_code}a2a_duration_seconds{intent, status_code}Prometheus Client SDK自动埋点a2a_duration_seconds{intentverify_compliance} 5s(P95)发现通信瓶颈、慢请求、高频错误MCP治理层mcp_cb_load_total{cb_id, status}mcp_cb_age_seconds{cb_id}CM服务暴露/metrics端点mcp_cb_age_seconds{cb_id~.*} 3600(CB超1小时未刷新)发现CB分发失败、数据源中断、CM服务异常Agent业务层agent_intent_handled_total{agent_id, intent, result_status}agent_context_validity{agent_id}Agent SDK自动上报agent_context_validity{agent_idrisk_analyzer_v1} 0.95(95%请求使用有效CB)发现Agent配置错误、CB加载失败、业务逻辑缺陷一个关键实践所有告警必须附带trace_id。当a2a_duration_seconds告警触发时运维人员在PagerDuty点击告警直接跳转到Jaeger中该trace_id的全链路追踪5秒内定位到是哪个Agent的get_context_bundle()调用卡在了Redis连接池耗尽。监控的价值不在于知道“坏了”而在于知道“哪里坏、为什么坏、怎么修”。5. 常见问题与排查技巧实录那些只有踩过才知道的坑5.1 “Agent收不到A2A消息”——90%的问题出在配置而非代码这是新手最常遇到的“黑洞”问题。现象Sender日志显示Sent message to compliance_checker_v1但Receiver日志一片空白。排查清单网络连通性docker exec -it risk-analyzer ping compliance_checker。别笑我们真遇到过Docker网络驱动配置错误导致同网段容器无法互通。服务发现检查Receiver Agent的HTTP服务是否真的在监听0.0.0.0:8000而非127.0.0.1:8000。用netstat -tuln确认。A2A路由配置Receiver Agent的SDK必须显式注册A2AHandler且intent字符串必须与Sender发送的完全一致大小写、下划线。我们曾因Sender发verify_complianceReceiver注册verifyCompliance驼峰而排查3小时。防火墙/Security Group云环境务必检查安全组规则确保Sender所在节点能访问Receiver的端口。排查技巧在Receiver的HTTP入口处如FastAPI的app.middleware(http)加一行日志logger.info(fRaw request: {request.method} {request.url} {await request.body()})。如果这里没日志问题在网关或网络如果有日志但A2AHandler没触发问题在SDK路由配置。5.2 “CB加载失败context not found”——MCP的上下文漂移陷阱现象Agent启动时报错ContextBundle with id cb_20240520_000000 not found。原因往往不是CM没数据而是CB ID生成逻辑不一致。典型场景时间戳精度不一致Sender生成CB ID时用datetime.now().strftime(%Y%m%d_%H%M%S)秒级CM服务生成CB时用datetime.now().isoformat()微秒级导致ID不匹配。时区混乱Sender在UTC8生成IDcb_20240520_142200CM服务在UTC时区生成CBcb_20240520_062200。命名空间冲突多个环境dev/staging/prod共用一个CM服务但CB ID未加环境前缀。根治方案强制所有CB ID生成走CM服务的/cb/generate_id端点该端点返回全局唯一、时区无关、带环境前缀的ID如prod_cb_20240520_062200_abc123。Sender和Receiver都调用此端点彻底消灭ID生成歧义。5.3 “A2A协商陷入死循环”——意图声明不清晰的恶果现象A2A日志里反复出现intent: negotiate的来回请求持续数分钟