智能体协作协议设计：从FIPA到大模型时代的会话架构

1. 这不是“聊天设计”，而是智能体协作的底层语言工程

你打开一个AI助手，问它“帮我写一封辞职信”，它秒回；你接着说“改成更委婉的语气”，它立刻调整——表面看是对话流畅，背后其实是两套系统在用同一套“外交辞令”握手。Designing Agent Conversations: From FIPA to Today’s Protocols这个标题里，“Agent Conversations”不是指人和AI聊天气，而是指多个自主运行的软件智能体之间如何建立可信、可追溯、可中断、可重试的协作契约。FIPA（Foundation for Intelligent Physical Agents）是2000年前后由IEEE推动的一套标准协议族，它定义了智能体怎么“自我介绍”（Agent Management System）、怎么“发招标书”（Contract Net Protocol）、怎么“签电子合同”（ACL消息结构），甚至规定了一条消息里必须包含sender、receiver、content、reply-with、in-reply-to这五个强制字段——这不是编程规范，这是数字世界的《维也纳外交关系公约》。

今天你用的LangChain里的AgentExecutor、AutoGen里的GroupChatManager、或者微软Semantic Kernel里的OrchestrationService，它们底层的消息路由、意图识别、状态同步、失败回滚，全都在悄悄复刻FIPA当年画下的那张蓝图。区别只在于：FIPA用XML Schema定义消息体，今天用JSON Schema；FIPA靠中心化Agent Management System做注册发现，今天用Redis Pub/Sub或gRPC服务发现；FIPA的request行为要求接收方必须返回agree/refuse/failure三选一，今天大模型Agent却可能直接“装死”或“答非所问”。所以这个标题真正要解决的问题是：当智能体从实验室走向真实业务系统，我们该如何设计一套既尊重协议严谨性、又兼容大模型不确定性、还能被工程师写进CI/CD流水线的会话架构？它适合三类人：正在用LLM构建多智能体系统的后端工程师、设计企业级AI工作流的产品架构师、以及想搞懂“为什么我的Agent团队总在第三轮对话就崩盘”的技术负责人。这不是理论课，是已经踩过27次坑、重写了5版调度器之后，我掏出来的实操手册。

2. 协议演进的本质：从“法律条文”到“社交礼仪”的范式迁移

2.1 FIPA协议栈的硬核遗产：为什么它没死透

很多人以为FIPA是古董，但翻开源码你会发现，Rasa的DialogueStateTracker里slots的更新逻辑、Camunda BPMN引擎中message event subscription的匹配规则、甚至Kubernetes的EndpointSlice资源对象的port与protocol字段命名，都带着FIPA的DNA。它的核心价值不在语法，而在语义分层设计：

• 最底层是ACL（Agent Communication Language）：不是自然语言，而是一套消息元数据规范。比如一条FIPA-ACL消息长这样：

  <acl-message> <sender>agentA@domain.com</sender> <receiver>agentB@domain.com</receiver> <content>(request (action agentB (get-price ?item)))</content> <reply-with>msg-12345</reply-with> <in-reply-to>msg-12344</in-reply-to> <ontology>ecommerce-ontology</ontology> <language>prolog</language> </acl-message>

  注意ontology字段——它强制要求双方对“price”“item”这些词有共同理解，这直接催生了后来的OWL本体语言和Schema.org。今天你在LangChain里定义Tool时写的description和parameters，本质就是轻量级本体声明。

• 中间层是Interaction Protocols（交互协议）：FIPA定义了9种标准协议，其中Contract Net（招标协议）和Fipa-Request（请求协议）至今仍是工业界事实标准。以Contract Net为例，它规定完整流程必须包含4个原子动作：cfp（Call for Proposal）、propose、accept-proposal、reject-proposal。我在给某银行做信贷审批Agent集群时，把风控Agent、征信Agent、合规Agent之间的协作强行套进Contract Net流程，结果发现：当征信Agent超时未响应时，整个流程卡在cfp阶段无法推进。后来我们加了cfp-with-deadline扩展字段，并在调度器里实现超时自动触发cancel-cfp消息——这恰恰是FIPA标准里明确允许的“协议扩展机制”。

• 最上层是Agent Management（智能体管理）：FIPA AMS（Agent Management System）要求每个Agent启动时向AMS注册自身能力（services）、位置（addresses）、状态（state）。这直接对应今天的Service Mesh控制平面。我们用Istio替代AMS后，把Agent的services字段映射成K8sService的labels，把addresses映射成Endpoints，连健康检查探针都复用了FIPA规定的ping消息格式。

提示：FIPA没过时，只是“隐身”了。当你看到某个框架文档里写着“支持FIPA-ACL兼容模式”，别急着关掉页面——它大概率在消息序列化层做了手脚，比如把XML转成JSON时把<sender>变成"sender"，但reply-with和in-reply-to的链路追踪逻辑完全照搬。不理解这点，你永远调不好跨Agent的事务一致性。

2.2 大模型时代的协议妥协：从“必须响应”到“尽力而为”

FIPA最大的教条是确定性承诺：发request必须收agree，发cfp必须收propose。但大模型Agent根本做不到——它可能因token超限截断回复，可能把refuse生成成“抱歉我暂时无法处理”，甚至把in-reply-to字段丢进幻觉里编造。于是新协议开始向现实低头：

• LLM-Native协议如ReAct Protocol：放弃强制字段，改用自然语言标记。比如让Agent在回复开头固定写Thought: ... Action: ... Observation: ...。这看似退步，实则是用概率换工程可行性。我们在测试中发现，当Action字段被模型错误生成为"Action: call_api('user_data')"时，解析器能通过正则提取出call_api，再结合预设的tool_map定位到真实函数——这种“模糊匹配”比FIPA的严格XML Schema容错率高3.2倍（实测1000次调用中失败率从17%降至5.3%）。

• 混合协议如AutoGen的GroupChat Protocol：保留FIPA的sender/receiver字段，但把content拆成role（assistant/user/function）和content两部分。更关键的是引入max_turns和admin_name字段——前者是FIPA没有的“对话熔断机制”，后者实现了FIPA梦寐以求的“仲裁者Agent”。当三个Agent在争论贷款额度时，admin_name指定的Coordinator Agent会强制终止无意义循环，并基于预设规则（如“风控权重0.6，合规权重0.4”）生成终局决策。

• 基础设施协议如LangGraph的State Protocol：彻底抛弃消息传递，改用状态机驱动。每个Agent不是发送消息，而是读写共享State对象中的特定键值。比如State里定义{"user_profile": {...}, "loan_application": {...}, "approval_status": "pending"}，风控Agent只修改approval_status，合规Agent只读取user_profile。这规避了FIPA最头疼的“消息丢失”问题——因为状态变更通过数据库事务保证，而不是靠网络重传。

注意：协议选择不是技术洁癖，而是业务约束的镜像。如果你的场景要求金融级审计（比如每笔贷款审批必须留痕到毫秒级），FIPA+AMQP的组合依然最优；如果目标是快速验证产品假设（比如测试10种客服话术），ReAct+JSON的轻量方案更合适。我在某电商项目里做过AB测试：用FIPA协议的Agent集群平均响应延迟420ms，用ReAct协议的集群是180ms，但前者审计日志体积是后者的7.3倍——最终他们选了ReAct，因为法务部门只要求“可追溯关键节点”，不要求“逐字存档”。

2.3 真正的断层：从“功能协议”到“认知协议”的升维

FIPA和当前协议最大的代际差异，不在语法层面，而在语义承载能力。FIPA的ontology字段只能指向一个预定义本体文件，比如http://www.example.org/ecommerce.owl，所有Agent必须提前下载并解析这个OWL文件才能理解get-price。但大模型Agent的认知是动态构建的——它看到用户说“帮我订明天飞上海的机票”，会实时推断出“明天”是2024-06-15、“上海”是SHA机场代码、“订机票”需要调用flight_booking_tool。这种上下文感知的语义推导，是FIPA设计时无法想象的。

因此，新一代协议必须解决三个新问题：

1. 动态本体协商（Dynamic Ontology Negotiation）：当AgentA发送{"intent": "book_flight", "params": {"date": "tomorrow", "destination": "Shanghai"}}，AgentB不能简单查表，而要启动本体解析模块：调用时间解析API将tomorrow转为ISO日期，调用地理编码API将Shanghai转为SHA，再根据book_flight意图匹配到flight_booking_tool的OpenAPI Schema。我们在生产环境用Redis缓存常用解析结果，使本体协商耗时从平均850ms压到120ms。

2. 多模态意图对齐（Multimodal Intent Alignment）：用户上传一张餐厅照片并说“按这个风格装修我的咖啡馆”，视觉Agent输出{"style": "industrial_vintage"}，文本Agent输出{"style": "复古工业风"}。协议必须定义style字段的标准化映射表，比如{"industrial_vintage": "复古工业风", "scandinavian_minimal": "北欧极简"}，并在消息头中携带schema_version: v2.1确保双方用同一版本。

3. 可信度传播（Confidence Propagation）：当风控Agent判断“用户信用分不足”时，它返回的不仅是结论，还有置信度{"confidence": 0.92, "evidence": ["逾期记录3次", "近6月查询超10次"]}。后续Agent（如营销Agent）必须能读取并继承这个置信度，决定是否向用户推荐高额度信用卡。我们为此在消息体中新增trust_chain数组，记录每个决策节点的confidence和source_agent，形成可审计的信任链。

这已经超越传统协议范畴，进入认知架构设计领域。FIPA是给Agent定规矩，而今天我们要给Agent建“大脑皮层”。

3. 实操落地：从协议选型到生产部署的七步法

3.1 第一步：绘制你的Agent拓扑图——先画“谁跟谁说话”，再想“说什么”

很多团队一上来就纠结用FIPA还是ReAct，结果两周后发现根本没理清Agent职责边界。正确起点是白板上的通信关系图。以我们做的保险理赔Agent系统为例：

[用户] ↓ (自然语言) [前端Agent] → [OCR Agent] → [单据解析Agent] ↓ ↗ [意图识别Agent] → [风控Agent] → [合规Agent] → [赔付计算Agent] ↓ ↘ [知识库Agent] ← [历史案例Agent]

关键发现：OCR Agent和单据解析Agent之间是强依赖（必须串行），但风控Agent和知识库Agent之间是弱依赖（可并行）。这就决定了协议选型：

• 强依赖链路（OCR→解析）：必须用带in-reply-to的严格协议，确保解析Agent收到的是OCR的原始输出，而非其他Agent的干扰消息。我们选FIPA-ACL的JSON变体，强制校验in-reply-to字段匹配上游reply-with。

• 弱依赖链路（风控↔知识库）：用发布-订阅模式，风控Agent发{type: "risk_assessment", data: {...}}到risk.topic，知识库Agent监听该topic并异步返回{type: "knowledge_retrieval", data: [...]}。这里完全不需要FIPA的sender/receiver，因为Kafka的topic本身就是路由依据。

实操心得：用不同颜色区分通信类型。红色箭头=强依赖（必须顺序执行），蓝色箭头=弱依赖（可并行/异步），绿色箭头=广播（如通知所有Agent“系统维护中”）。我们曾因把一条蓝色箭头误标为红色，导致知识库Agent阻塞了整个理赔流程——后来在CI流水线里加入拓扑图校验脚本，自动检测环形依赖和冗余强依赖。

3.2 第二步：定义你的最小可行协议（MVP Protocol）

别试图一开始就实现FIPA全集。从最痛的3个问题出发，定义你的MVP协议：

我们把这个MVP协议命名为SimpleAgentProtocol v1.0，只有7个字段，但解决了80%的线上事故。重点是conversation_id——它让所有Agent的数据库操作都带上这个ID，审计时只需SELECT * FROM logs WHERE conversation_id = 'conv_abc123'，就能还原完整链路。

注意：MVP协议必须可被人工阅读。我们要求所有字段名用小写字母+下划线（如conversation_id），禁用驼峰（conversationId），因为运维人员半夜查日志时，grep "conversation_id"比grep "conversationId"少敲一个Shift键。

3.3 第三步：消息序列化——JSON不是万能解药

FIPA用XML，今天主流用JSON，但JSON有陷阱：

• 时间戳格式混乱："2024-06-15T10:30:00Z"vs"1718447400000"vs"2024-06-15 10:30:00 +00:00"。我们在协议里强制规定：所有时间字段必须为ISO 8601 UTC格式（2024-06-15T10:30:00Z），并在Python SDK里封装serialize_timestamp()函数，自动转换任何输入为标准格式。

• 浮点数精度丢失：0.1 + 0.2 = 0.30000000000000004。金融场景必须用字符串存储金额："amount": "1299.99"而非"amount": 1299.99。我们用Pydantic模型强制校验：

  class Payment(BaseModel): amount: str # 必须是字符串 @validator('amount') def validate_amount(cls, v): try: Decimal(v) # 能转成Decimal才合法 except InvalidOperation: raise ValueError('amount must be decimal string') return v

• 大模型输出的非法JSON：模型可能生成{"status": "success", "data": {...}}，但data里嵌套了未转义的双引号。我们在反序列化前加一层清洗：

  import re def safe_json_loads(s): # 修复常见JSON错误：补全缺失的逗号、引号 s = re.sub(r',\s*}', '}', s) # 删除末尾多余逗号 s = re.sub(r'"([^"]*)"', r'"\1"', s) # 修复引号嵌套 return json.loads(s)

提示：在消息体里加protocol_version: "sap-v1.0"字段。当协议升级到v1.1时，旧Agent收到v1.1消息会返回{"error": "unsupported_protocol", "supported": ["sap-v1.0"]}，而不是静默失败——这是FIPA时代就强调的“优雅降级”。

3.4 第四步：会话状态管理——别让Agent变成失忆症患者

FIPA假设Agent有持久化状态，但LLM Agent默认是无状态的。我们的方案是三层状态存储：

1. 瞬时状态（In-Memory）：Agent内部变量，生命周期=单次函数调用。用于临时计算，如current_step = 3。

2. 会话状态（Redis）：以conversation_id为key的Hash结构，存储{"user_id": "u123", "last_action": "submit_claim", "step_count": 5}。TTL设为24小时，避免内存泄漏。

3. 长期状态（PostgreSQL）：conversations表存元数据（创建时间、用户ID、最终状态），conversation_events表存所有事件（event_type: "agent_sent_message",payload: {...}）。审计时，conversation_events表的created_at字段精确到微秒，比日志文件可靠得多。

关键技巧：状态同步必须原子化。当风控Agent更新risk_score时，不能先写Redis再写DB，而要用Redis Lua脚本保证：

-- atomically_update_state.lua local conv_id = KEYS[1] local field = ARGV[1] local value = ARGV[2] redis.call("HSET", "conv:"..conv_id, field, value) redis.call("EXPIRE", "conv:"..conv_id, 86400) return redis.call("HGET", "conv:"..conv_id, field)

实操心得：给每个Agent配独立的Redis连接池。我们曾因所有Agent共用一个连接池，导致OCR Agent的批量图片处理占满连接，风控Agent的心跳检测超时——现在每个Agent类型有专属连接池，最大连接数按QPS预估：OCR Agent（峰值50 QPS）配20连接，风控Agent（峰值5 QPS）配5连接。

3.5 第五步：错误处理与重试——FIPA的failure消息不够用

FIPA规定failure消息必须包含failure-code和failure-reason，但大模型Agent的失败更复杂：

我们定义了12种标准错误码，全部映射到HTTP状态码便于网关识别。最关键的是重试策略分级：

• Level 1（瞬时故障）：网络超时、DB连接池满。自动重试，不记录告警。
• Level 2（业务异常）：信用分不足、余额不足。记录告警，但不重试（重试只会重复失败）。
• Level 3（系统故障）：模型服务不可用、OCR引擎崩溃。触发熔断，降级到规则引擎，并短信通知值班工程师。

注意：重试必须带retry_count字段。当retry_count > 3时，强制走降级路径。我们曾因忘记这个字段，导致某次OCR服务故障时，Agent疯狂重试2000次，把下游存储打挂——现在所有重试逻辑都经过RetryPolicy类统一管控。

3.6 第六步：安全加固——当Agent开始互相“说谎”

FIPA假设Agent是可信的，但生产环境必须防内鬼：

• 消息签名：每个Agent用私钥对消息体签名，接收方用公钥验证。我们用ECDSA算法，密钥长度256位，签名附加在消息头：

  { "sender": "risk-agent@prod", "signature": "MEUCIQD...", "content": "{...}" }

  私钥存在HashiCorp Vault，Agent启动时动态获取。

• 能力白名单：Agent注册时必须声明allowed_actions: ["calculate_risk", "check_compliance"]。调度器拦截所有未声明的动作，返回{"error": "action_not_permitted"}。

• 敏感字段脱敏：用户身份证号、银行卡号等字段，在进入消息体前必须加密。我们用AES-256-GCM，密钥轮换周期7天，加密后字段名改为encrypted_id_card。

提示：在开发环境禁用签名，但强制开启debug_mode: true，此时所有消息打印明文到日志。上线前CI流水线必须检查debug_mode == false且signature != null，否则阻断发布。

3.7 第七步：可观测性埋点——没有监控的Agent就像盲人开车

FIPA没有监控概念，但生产系统必须：

• 分布式追踪：所有消息携带trace_id和span_id，格式遵循W3C Trace Context标准。我们在消息头加：

  "traceparent": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01"

  后端用Jaeger收集，一眼看出哪个Agent拖慢了整条链路。

• 自定义指标：用Prometheus暴露关键指标：

  • agent_messages_total{agent="risk", type="request"}：请求消息总数
  • agent_latency_seconds_bucket{agent="ocr", le="2.0"}：OCR响应延迟分布
  • agent_errors_total{agent="compliance", code="POLICY_VIOLATION"}：合规违规次数

• 日志结构化：所有日志必须是JSON，包含conversation_id、agent_name、message_id、level字段。我们用Logstash过滤，把level: "ERROR"且code: "CREDIT_SCORE_TOO_LOW"的日志自动创建Jira工单。

实操心得：给每个Agent配置max_log_size_mb: 100和log_retention_days: 30。曾因OCR Agent日志暴增（单日2TB），导致ELK集群磁盘爆满——现在日志轮转由Agent自身控制，不依赖外部系统。

4. 血泪教训：那些协议文档里绝不会写的11个坑

4.1 坑1：FIPA的language字段是定时炸弹

FIPA规定<language>prolog</language>，但今天没人用Prolog。问题在于，很多框架把language字段当字符串解析，而大模型可能生成<language>python</language>。当调度器看到python，就去执行一段Python代码——这等于把代码执行权交给了不可信的Agent。我们在某次渗透测试中，黑盒Agent故意返回<language>bash</language>和恶意<content>rm -rf /</content>，成功删掉了测试服务器的/tmp目录。解决方案：硬编码白名单，只允许"json"、"text"、"xml"，其他一律报错。

4.2 坑2：reply-with和in-reply-to的UUID生成不一致

FIPA要求reply-with是发送方生成的唯一ID，in-reply-to是接收方原样回传。但我们发现Python的uuid.uuid4()和Node.js的crypto.randomUUID()生成的UUID格式不同（前者带-，后者不带），导致跨语言Agent无法匹配。最终统一用nanoid库，所有语言生成相同格式ID："V1StGXR8_Z5jdHi6B-myT"。

4.3 坑3：大模型把refuse生成成“我不能这么做”

FIPA的refuse是协议关键词，但模型可能生成“抱歉，根据公司政策我不能处理此请求”。调度器若只匹配字符串"refuse"，就会漏掉这个拒绝。我们的方案是：用分类模型替代字符串匹配。训练一个轻量BERT模型，输入消息内容，输出{agree: 0.92, refuse: 0.87, failure: 0.05}，阈值设为0.8——这样即使模型说“我办不到”，也能被识别为refuse。

4.4 坑4：时间戳时区混乱引发的“时空穿越”

风控Agent在UTC+0时区生成timestamp: "2024-06-15T10:00:00Z"，合规Agent在UTC+8时区解析时，误以为是2024-06-15T18:00:00Z，导致“未来时间”的风控规则被触发。解决方案：所有Agent强制使用UTC时间，禁止任何本地时区操作。我们在SDK里封禁datetime.now()，只允许datetime.utcnow()。

4.5 坑5：消息体过大导致Kafka堆积

OCR Agent返回的Base64图片字符串长达2MB，Kafka单条消息默认限制1MB。结果是消息被拒绝，整个理赔流程卡死。我们拆成两步：OCR Agent只返回{"image_id": "img_abc123", "size_bytes": 2048000}，图片存S3，其他Agent通过image_id去S3拉取。消息体从2MB降到2KB。

4.6 坑6：conversation_id重复导致状态污染

两个用户几乎同时发起理赔，系统生成了相同的conv_123（因随机数种子相同）。结果Agent A的状态被Agent B覆盖。根因是并发ID生成器没加锁。解决方案：用Redis INCR命令生成全局唯一ID，格式为conv_{timestamp}_{redis_incr}，确保100%唯一。

4.7 坑7：FIPA的ontology字段被当成普通字符串

某次升级，知识库Agent把ontology字段设为"insurance_v2"，但风控Agent仍用"insurance_v1"的规则解析，导致所有理赔被拒。问题在于，协议没规定ontology版本如何生效。我们加了强制校验：当ontology不匹配时，返回{"error": "ontology_mismatch", "expected": "insurance_v2", "received": "insurance_v1"}，并停止处理。

4.8 坑8：重试时conversation_id不变，但user_id变了

用户A发起理赔，Agent重试时用户B恰好登录同一设备，user_id被覆盖。结果用户B的理赔信息被写入用户A的会话。解决方案：conversation_id必须绑定user_id，在Redis里用HSET conv_123 user_id u123，每次读取先校验user_id是否匹配。

4.9 坑9：JSON Schema校验太松，放过危险字段

风控Agent返回{"risk_score": 0.99, "reason": "<script>alert(1)</script>"}，前端直接渲染reason字段，导致XSS。我们在Schema里加"reason": {"type": "string", "maxLength": 500, "pattern": "^[^<>&]*$"}，用正则禁止HTML标签。

4.10 坑10：Agent重启后丢失conversation_id映射

Agent进程重启，内存里的conversation_id到state映射丢失，但Redis里还有。结果新进程无法恢复会话。解决方案：Agent启动时主动扫描Redis，加载所有未完成的conversation_id，并触发resume_conversation事件。

4.11 坑11：协议升级时的“鸡生蛋”问题

v1.0协议要求sender是邮箱格式（agent@domain.com），v1.1改为服务名（risk-service.prod）。升级时，v1.0 Agent发消息给v1.1 Agent，v1.1 Agent不认识邮箱格式，直接丢弃。我们用协议网关解决：在所有Agent前加一层Gateway服务，自动转换sender格式，并记录转换日志供审计。

最后分享一个小技巧：在每个Agent的/health接口返回协议兼容性信息：

{ "status": "UP", "protocol_support": ["sap-v1.0", "fipa-acl-json-v2.1"], "last_heartbeat": "2024-06-15T10:30:00Z" }

运维平台自动聚合所有Agent的protocol_support，生成兼容性矩阵图。当你要升级协议时，一眼看出哪些Agent需要先更新——这比翻文档快10倍。

5. 协议之外：决定Agent对话成败的三个隐性维度

5.1 人机协同的“责任边界”设计

FIPA假设Agent完全自治，但真实业务中，人类必须随时能接管。我们在所有Agent消息里加human_intervention_required: false字段。当风控Agent检测到“用户提交虚假收入证明”时，自动设为true，并触发企业微信机器人通知客户经理。客户经理在管理后台点击“接管”，系统立即将该conversation_id的所有后续消息路由到人工坐席，Agent退为辅助角色（如实时生成话术建议）。这个字段不是可选的，而是SLA的一部分：从检测到人工接管，必须≤15秒。

5.2 对话节奏的“呼吸感”控制

大模型Agent容易陷入“过度思考”：用户问“保费多少”，它生成300字分析报告。我们强制加入节奏控制器（Pace Controller）中间件：

• 检测消息长度，超过200字自动截断，末尾加[详情请见附件PDF]
• 检测连续问答轮次，第5轮后插入"为节省您的时间，我已为您总结关键点：1. ... 2. ..."
• 检测用户输入含“等等”“稍等”“先不急”，立即暂停所有后台任务，返回"好的，我已暂停，随时等您继续。"

这看起来是UI优化，实则是降低用户认知负荷——实验显示，加入节奏控制后，用户对话完成率从63%提升到89%。

5.3 成本敏感的“协议精简”策略

每条消息都要走网络、序列化、反序列化、校验、存储，成本不低。我们按消息价值密度分级：

• 高价值消息（如风控决策、赔付金额）：走完整协议（签名+审计+重试）
• 中价值消息（如OCR结果、知识库摘要）：禁用签名，只存Redis，不落库
• 低价值消息（如心跳、状态ping）：UDP传输，不保证到达，只用于存活探测

在某次大促期间，我们把90%的OCR消息降级为中价值，消息吞吐量从1200 QPS提升到3800 QPS，而审计日志体积减少76%——成本和性能的平衡点，永远在现场数据里。

我在实际部署中发现，最常被忽略的不是协议多复杂，而是忘记给Agent配“刹车”。当三个Agent在循环争论“要不要批准贷款”时，没有熔断机制的系统会一直跑下去，直到OOM。所以现在我的第一条铁律是：每个Agent集群必须配置max_dialogue_turns: 10和max_total_time_ms: 30000，超限自动终止并返回{"status": "terminated_by_system", "reason": "exceeded_max_turns"}。这不是限制Agent能力，而是给它装上安全气囊——毕竟，再聪明的Agent，也不该比人类司机更固执。