上一篇我们把多 Agent 协作拆成了拓扑客服、质检、执行、审批这些角色不应该挤在一个大 Prompt 里互相污染也不应该在一个群聊窗口里自由发挥。拓扑解决的是“谁和谁连接”。但系统真跑起来之后更容易出问题的是另一层客服 Agent 什么时候把草案交给质检质检 Agent 该拿到完整聊天还是只拿到证据包执行 Agent 能不能看到内部争论审批 Agent 的否决意见应该广播给谁一个 Agent 改了工单状态其他 Agent 凭什么知道自己手里的信息已经过期如果这些问题没有协议约束多 Agent 系统很快会退回到一种低级形态所有人共享同一段对话历史谁想说什么就说什么最后由某个“总结者”生成结论。这种做法在 Demo 里很顺在企业工单 / 运营执行场景里却很危险。因为这里的消息不是聊天内容而是会触发后续判断、工具调用、审批流和用户回复的控制信号。Agent 间通信不是把上下文转发给另一个模型而是把事实、意图、约束和责任封装成可路由、可校验、可追踪的消息。多 Agent 一旦开始协作协议就会变成系统稳定性的底座。它决定每个 Agent 知道什么、不知道什么、能请求什么、必须回应什么以及什么时候应该闭嘴。一、不要转发聊天先看一个常见的坏设计。用户发来售后工单我的订单又晚了上次客服说可以补偿现在还没动静。系统里有四个 Agent客服、质检、执行、审批。为了省事开发者把完整工单、历史对话、政策检索结果、工具日志和所有 Agent 的发言都塞进一个共享会话。流程看起来像这样客服 Agent用户比较生气我建议先安抚并查询订单。质检 Agent需要注意补偿政策不要直接承诺。执行 Agent我查到订单延迟 4 天。客服 Agent那可以给用户说我们会补偿。质检 Agent等一下历史里好像已经补偿过一次。审批 Agent这个需要人工审批。执行 Agent我已经把工单状态改成待补偿了。这不是协作这是无协议广播。它会带来几个后果。第一事实和意见混在一起。 “订单延迟 4 天”是事实“可以补偿”是建议“需要审批”是约束“已经改成待补偿”是副作用结果。它们如果都以自然语言堆在同一个上下文里后续 Agent 很难判断哪些是已确认事实哪些只是某个角色的推测。第二权限边界被语言稀释。 执行 Agent 不应该因为看到客服 Agent 的建议就直接改状态。审批 Agent 的意见也不应该只是聊天里的一句话而应该成为明确的授权或否决结果。第三旧消息持续污染新判断。 订单状态、政策版本、用户历史都可能变化。如果系统只靠完整聊天记录往后传后续 Agent 可能继续引用已经过期的信息。第四出了问题很难追责。 最终用户收到错误承诺时我们需要知道错误来自客服草案、政策误召回、质检漏检、审批未触发还是执行动作越权。聊天记录能看到“大家都说过话”却很难变成可测试、可审计的因果链。更稳的做法是让 Agent 之间只交换结构化消息而不是转发完整聊天。每条消息都要回答四个问题我是谁发的我为什么发我携带什么事实或请求接收方应该做什么以及在什么边界内做这四个问题回答不清楚消息就不应该进入协作链路。二、消息信封Agent 间消息可以拆成两层信封和负载。信封负责路由、审计、安全和生命周期负载负责具体业务内容。很多系统一开始只设计 payload后来才发现无法追踪消息从哪里来、给谁看、是否过期、能不能重放、是否包含敏感字段。一个工单协作消息的信封可以长这样{ message_id:msg_01JZ7A9Y8K, trace_id:trace_ticket_T4821, ticket_id:T4821, type:task.request, intent:review_reply_risk, sender:{ agent_id:support_agent, role:support}, recipient:{ mode:direct, agent_id:quality_agent}, causality:{ parent_message_id:msg_01JZ7A8Q2P, step_id:quality_review}, policy:{ visibility:internal, sensitivity:normal, ttl_seconds:900}, requires_response:true, deadline_ms:30000}这里最重要的不是字段数量而是边界意识。message_id让每条消息可追踪。trace_id把一次工单处理里的多条消息串起来。type说明这是任务请求、事件通知、结果返回还是审批决定。intent说明发送方希望接收方完成什么。recipient决定消息是定向、广播还是订阅分发。causality保留因果关系避免后续只看到孤立结论。policy约束可见性、敏感级别和过期时间。deadline_ms让协作有时间边界而不是无限等待某个 Agent 发言。有了信封系统才知道这条消息应该去哪里、能保存多久、谁有权读取、超时后怎么办。对生产系统来说消息信封还应该尽量由控制器生成而不是完全交给 LLM 自由输出。模型可以填业务负载可以建议下一步意图但路由、权限、过期时间、trace 关系这些字段最好由运行时根据状态注入。否则一个 Agent 可能在自然语言里说“请审批 Agent 看一下”但系统没有真正创建审批任务或者模型把高敏感字段发给了不该看的角色。协议字段必须进入控制流而不是停留在文本约定里。可以把信封理解成多 Agent 协作里的交通规则。没有它消息再聪明也只是路上乱跑。三、意图与负载信封解决“怎么送”负载解决“说什么”。Agent 之间最不应该传的是大段未分层上下文。更好的负载结构是把消息拆成意图、事实、证据、约束和期望输出。例如客服 Agent 生成了一个回复草案需要质检 Agent 判断是否有风险。它不需要把完整聊天记录转给质检而是发送一个复核任务{ intent:review_reply_risk, payload:{ draft_reply:我们已经看到订单延迟会尽快为您核实补偿资格。, proposed_actions:[{ action:check_compensation_eligibility, risk_level:medium}], confirmed_facts:[{ key:delay_days, value:4, source:order_api, observed_at:2026-06-24T10:21:0008:00},{ key:previous_contact, value:客服曾承诺查询补偿资格未确认发放, source:ticket_history}], evidence_refs:[policy:shipping_delay:v18,ticket_note:T4821:2026-06-22], missing_facts:[是否已发放过补偿,订单是否属于大促顺延规则], required_output_schema:quality_review_result.v1}}这条消息有几个关键设计。它把草案和动作分开。回复草案是给用户看的文本拟执行动作是系统内部决策两者不能混成一句“我们准备补偿一下”。它把事实和证据引用分开。confirmed_facts是当前判断可以直接使用的事实evidence_refs是可回查来源。质检 Agent 如果要复核可以按引用重新读取政策或历史记录而不是相信客服 Agent 的完整转述。它保留缺失事实。很多风险不是来自错误事实而是来自少了一个关键条件。协议里必须允许 Agent 明确说“现在还不能判断因为缺少这些事实”。它指定输出 schema。质检 Agent 不应该返回一段散文式意见而应该返回可路由的结果。例如{ type:task.result, intent:review_reply_risk, payload:{ risk_level:medium, blocking_issues:[{ code:MISSING_COMPENSATION_HISTORY, message:无法确认用户是否已经获得过补偿。}], allowed_next_actions:[query_compensation_history], forbidden_next_actions:[promise_coupon,close_ticket], review_summary:可先安抚并说明正在核实但不能承诺补偿。}}这才是可执行的通信结果。调度器看到blocking_issues可以让执行 Agent 查询补偿记录看到forbidden_next_actions可以阻止客服 Agent 在最终回复里写“会给您补偿”看到risk_level可以决定是否需要审批。Agent 间消息不需要暴露内部推理链。生产系统真正需要的是结论、证据、置信度、缺失条件、允许动作、禁止动作和责任来源。一个实用的判断是Agent 不要把“我是怎么想的”发给别人而要把“我确认了什么、我请求什么、我禁止什么、我还缺什么”发出去。这句话比“让 Agent 互相沟通”更接近工程现实。四、定向、广播与订阅协议设计不能只关心消息格式还要关心消息分发。多 Agent 系统里常见三种通信模式定向、广播、订阅。它们不是谁更高级而是适合不同场景。定向消息适合明确任务。客服 Agent - 质检 Agent请复核这份回复草案调度器 - 执行 Agent查询补偿历史审批节点 - 执行 Agent允许创建 20 元优惠券定向的好处是责任清楚。发送方知道自己请求谁接收方知道自己必须回应什么超时和失败也容易处理。大多数有状态协作都应该优先使用定向消息。广播消息适合少量全局事件。ticket.closedticket.escalatedpolicy.version_changedrun.cancelled广播不应该用来同步每个中间想法。它更适合发布那些会影响多个角色状态的事实。例如工单已经关闭所有未完成任务都应该取消政策版本更新正在使用旧版本证据的任务需要重新检查。订阅消息适合按条件触发。例如审批 Agent 不需要看到所有工单只需要看到满足条件的事件{ subscriber:approval_agent, topics:[action.proposed,risk.escalated], filters:{ risk_level:[high], action_type:[refund,coupon,close_ticket], amount_gte:10000}, projection:[ticket_id,proposed_action,risk_level,evidence_refs,impact_preview]}这里有一个容易被忽视的字段projection。订阅不等于把完整消息原样推给订阅者。审批 Agent 只需要看到动作预览、风险等级、证据引用和影响范围不需要看到客服润色过程、完整用户画像或底层工具日志。消息分发要配合字段投影。谁能看到哪几个字段应该由角色、权限、任务状态和敏感级别共同决定。可以把三种模式简单区分为模式适合什么最容易出的问题定向明确任务、明确接收者、需要回应接收者选错任务卡住广播全局状态变化、取消、版本更新滥用后上下文噪声爆炸订阅风险触发、异步监听、跨角色关注过滤条件过宽变相广播多数系统失败不是因为没有通信而是因为通信太慷慨。所有 Agent 都能看到所有消息短期开发简单长期成本、泄露和误判都会上来。更稳的原则是默认不发送除非接收方确实需要这条消息完成当前职责。五、什么时候说“何时说”比“说什么”更难。如果 Agent 每生成一个想法就通知其他 Agent系统会变成噪声网络。如果只在最后一步通知又会错过复核、审批和恢复时机。工单生命周期里比较有价值的通信触发点通常有六类。第一任务进入新阶段。ticket.receivedintent.classifiedfacts.collecteddraft.createdreview.completedaction.executedticket.resolved阶段变化适合发事件。它告诉其他节点状态已经推进你们手里的旧任务可能需要继续、取消或刷新。第二出现缺失事实。质检 Agent 如果发现无法判断补偿资格不应该继续写长篇意见而应该发出明确请求{ type:task.request, intent:collect_missing_fact, payload:{ missing_fact:compensation_history, reason:决定是否允许承诺补偿前必须确认是否已发放过补偿。, preferred_tool:query_compensation_history, blocks:[promise_coupon,close_ticket]}}这类消息的价值在于阻断错误推进。它不是“我还有点疑问”而是“这些动作现在被阻塞”。第三风险等级变化。一个工单从普通咨询变成投诉升级从低金额补偿变成高金额退款从标准政策变成例外判断都应该触发通信。风险变化往往意味着拓扑要改变需要质检、审批或人工介入。第四外部状态变化。订单状态、退款状态、政策版本、用户备注都可能在 Agent 协作过程中被外部系统更新。协议里必须有一种方式告诉相关 Agent你刚才基于的事实可能已经过期。{ type:event, intent:fact_invalidated, payload:{ fact_key:order_status, old_value:not_shipped, new_value:shipped, invalidates_messages:[msg_01JZ7A9Y8K], required_action:re_review_plan}}没有事实失效机制多 Agent 很容易在旧世界里继续认真工作。第五副作用动作前后。任何会写外部系统的动作执行前应该有预览消息执行后应该有结果消息。预览用于复核和审批结果用于状态同步和审计。action.previewed - approval.required - approval.granted - action.executed尤其是退款、发券、关单、改派、发送通知这类动作不能只让执行 Agent 在内部完成。其他角色至少要知道动作是否已经发生、有没有失败、是否需要补偿或人工跟进。第六超时和取消。Agent 协作不能无限等。质检超时、审批超时、执行工具超时都应该变成消息而不是停在后台日志里。{ type:event, intent:task.timed_out, payload:{ task_id:quality_review_4821, waiting_for:quality_agent, elapsed_ms:30000, fallback:route_to_human_review}}超时消息的意义不是抱怨某个 Agent 慢而是让调度器有机会选择降级路径。所以Agent 间通信的触发条件应该写进状态机而不是由模型想起来再说。模型可以判断“这里缺少事实”但系统要把这个判断转成阻塞消息模型可以建议“需要审批”但控制器要创建审批任务模型可以发现“政策版本不一致”但协议要让相关消息失效。通信时机如果不受控多 Agent 会在两个极端之间摇摆要么消息洪水要么关键节点沉默。六、可观测与演进通信协议不是一次设计完就不变。上线后我们会不断发现新的消息类型、新的风险字段、新的订阅条件和新的失败模式。如果协议没有版本和追踪能力后续迭代会非常痛苦。至少要保留三类工程能力。第一协议版本。{ schema:quality_review_result.v2, compatible_with:[quality_review_result.v1], payload:{ risk_level:medium, confidence:0.82, blocking_issues:[], allowed_next_actions:[send_safe_reply]}}版本不是形式主义。不同 Agent 可能升级节奏不同质检结果从 v1 增加confidence审批 Agent 不一定立刻理解。协议要允许旧版本继续工作也要让调度器知道哪些字段可以依赖哪些只是增强信息。第二消息日志。一次工单处理不应该只保存最终回复还应该保存关键消息链msg_01 ticket.receivedmsg_02 intent.classifiedmsg_03 draft.createdmsg_04 review_reply_risk requestedmsg_05 quality_review_result returnedmsg_06 collect_missing_fact requestedmsg_07 compensation_history returnedmsg_08 approval.requiredmsg_09 approval.deniedmsg_10 final_reply.created这条链比完整聊天记录更有调试价值。它能回答系统为什么进入审批为什么没有发券为什么最终回复没有承诺补偿哪个事实阻塞了动作。第三协议级评测。多 Agent 系统不能只评测最终答案。通信协议本身也要测。评测点要问的问题消息完整性关键字段是否缺失证据引用是否可回查路由正确性高风险动作是否发给审批普通消息是否避免广播信息最小化接收方是否拿到了不该看的敏感字段时机正确性缺失事实、风险升级、状态失效是否触发消息结果可执行返回值是否能驱动下一步而不只是自然语言建议版本兼容新旧 schema 是否能在同一条链路中共存这类评测听起来不如“多 Agent 智能协作”性感但它决定系统能不能维护。多 Agent 的调试难度通常不是来自某个模型不会回答而是来自消息链路不可见一个 Agent 说过什么、谁看见了、谁没看见、哪条消息导致了哪个动作、哪个旧事实没有失效。协议把这些问题显式化系统才有改进空间。最小可用协议如果从零开始不需要一上来设计一套庞大的消息总线。一个最小可用的 Agent 通信协议可以先覆盖七类消息类型用途task.request请求某个 Agent 完成明确任务task.result返回结构化结果event通知状态变化或事实变化action.preview展示即将执行的副作用动作action.result返回副作用动作结果approval.decision表达授权、拒绝或附条件通过task.cancelled取消过期、冲突或不再需要的任务每条消息至少带上这些字段message_idtrace_idticket_idtypeintentsenderrecipientpayloadcreated_atttlschema_version然后再逐步增加敏感级别、字段投影、幂等键、因果关系、超时策略和订阅过滤。协议设计最怕一开始就追求“大而全”。太复杂团队会绕过它太随意系统又会退回聊天。更好的做法是先抓住少数关键边界任务请求必须结构化执行动作必须有预览和结果高风险动作必须显式审批缺失事实必须阻塞后续动作过期事实必须让相关任务失效敏感字段默认不广播所有关键消息必须进入 trace通信协议听起来像底层细节实际上它决定了多 Agent 能不能变成可靠系统。对企业工单 / 运营执行 Agent 来说好的通信协议不会让 Agent 显得更会聊天反而会让它们少说废话只在需要的时候把足够的信息以正确的格式交给真正需要的人或系统。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】