上一篇我们把多 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:00+08: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时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
