多Agent点对点通信：hermes peer协议解析与订单履约落地实践

做了几年多Agent系统，我踩过最深的坑不是模型能力不够，而是Agent之间怎么说话。早期团队把一个订单履约拆成了六个Agent，所有通信都走中心化事件总线，结果消息一多总线先崩，问题排查要从几千条Event里捞一条关键消息，线上环境常驻三个运维盯日志。后来接触了hermes peer这个方向，思路一下子打开了：Agent之间不经过中心Broker，互相直接建立可信点对点通道，各聊各的，把通信压力打散到每一条边上，这个设计直接改变了我们后续所有Agent项目的架构。

这篇就当一次偏底层的复盘。我会把hermes peer这类协议的核心设计拆开讲清楚，包括身份认证怎么免中心化、消息可靠投递怎么保证、动态发现怎么做，然后结合一个完整的全栈协作案例，从握手到消息流转全流程过一遍。内容更适合已经在做Agent工程化、或者准备从单人Agent升级到多Agent协作体系的朋友；如果你刚接触Agent开发，前面的基础概念也能帮你先把地图拼出来。

1. 为什么Agent之间需要点对点通信

1.1 中心总线模式的问题在规模变大后非常明显

现在很多Agent平台的做法是引入一个Message Broker，所有Agent都把自己的消息发给Broker，Broker再按路由规则转给目标Agent。这套模式在小规模Demo里很省事，写路由规则也简单，但一旦Agent数量多起来、消息频率高起来，问题就一个个冒出来。

第一是单点压力。所有消息都过一个Broker，流量峰值来时Broker就是瓶颈，下游Agent全部等着转发。我们当时上线大促压测，总线CPU直接拉满，积压消息堆到百万级，业务Agent在那干等。第二是语义过载。Bus上同时跑着订单、库存、支付、物流的消息，接收方要把不相关的消息全部过滤一遍，业务逻辑里塞满了消息类型判断。第三是链路太长。一条消息从A到B经过了Publish、Store、Route、Deliver四跳，每一跳都是延迟和故障点，排查问题要从Broker日志、消费日志、业务日志三处对时间线，效率非常低。

不是说总线模式一无是处，它适合广播、事件通知这类“一对多”的场景，但Agent之间的调用，本质上是“我知道目标是谁、我们之间要做一次明确的往返交互”，这种语义用总线去承载，其实是在给问题绕路。

1.2 点对点通信的适用形态

点对点通信适合的形态，简单说就是“已知对端、直达目标、高频往返”。多Agent协作里有很多这样的场景：编排Agent直接问库存Agent“SKU-10086还有多少货”，支付Agent直接通知订单Agent“支付成功，回执编号是PAY-20240412-001”，这些交互不需要经过第三方转手。

点对点的直接收益有三个层面。延迟上少了两跳中转，交互效率明显提升；可靠性上每一对Agent之间的通道质量可以单独监测单独治理，不会因为一条链路抖动拖累整个系统；安全上两端可以直接做双向身份认证和加密，不需要把敏感数据放到共享Broker里过一遍。

从工程实现上看，点对点不代表没有协调者。Agent的注册、能力发现、路由表下发仍然需要一个轻量协调层，但业务消息不再全部经过协调层，只在启动和拓扑变化时交换控制信息。这个“控制面集中、数据面分散”的设计，和SDN的思路一脉相承，后面讲hermes peer的架构时会具体展开。

1.3 hermes peer在这张图里的位置

hermes peer不是一个业务框架，也不是消息中间件，它更像是一层Agent间通信的协议规范加一套参考实现。协议层定义消息格式、握手流程、认证方式、可靠投递语义；实现层把这套协议封装成SDK，你只需要给Agent配置一个身份标识（peer id）和自己的私钥，注册上能力列表，它就能和其他hermes peer节点直接通信。

全栈协作在这里是一个非常有价值的验证场景。一个完整业务系统里，前端交互Agent、业务编排Agent、数据服务Agent、外部系统对接Agent各自承担不同职责，它们之间既有短平快的查询类消息，也有长事务的确认类消息，还有定时性的同步消息。这些不同类型的交互在点对点通道上用统一协议承载，就是全栈Agent化协作最典型的落地模式。

所以hermes peer解决的核心问题可以一句话概括：让Agent像人加微信一样，通过一次可信握手建立关系，之后直接对话，而不是每次都要跑到大厅前台喊话让人转达。

2. hermes peer协议设计的核心思路

2.1 身份层：基于公钥指纹的Peer ID

点对点通信的第一关是身份互认。在中心化架构里，身份由注册中心颁发和管理，Agent拿着Token就能证明自己；去掉中心化之后，需要一套分布式可信的身份方案，hermes peer用的是公钥体系。

每个Agent在初始化时生成一对Ed25519密钥对（也可以由部署平台统一签发后分发），Peer ID就是公钥经过哈希之后的一段编码。假设一个Agent的Peer ID是12D3KooWExampleHash，通信的对方只要持有这个ID和公钥，就能验证消息的签名，确认消息确实来自声称的那个Agent。这个过程不需要一个中心化的认证服务器。

握手阶段双方做的事情就是交换公钥、校验对方Peer ID和公钥是否匹配、各自签名一个随机挑战值发给对方。校验通过后，这个通道就是可信的。这个设计解决了一个很隐蔽的问题：在Agent系统里，冒充身份的攻击一旦成功，整个自动化的信任链条就断了。基于公钥指纹的互认方式让“你是谁”这件事不依赖于任何第三方，泄露私钥是唯一的泄露途径。

2.2 消息信封：每个包都自带完整的上下文

hermes peer的消息不是裸业务数据，而是一个带完整信封的结构。信封分Header和Payload两层，Header负责网络传输和路由所需的信息，Payload承载业务数据。

一个典型的Header大概长这样，字段设计有讲究：

重点说一下trace_id和message_id这两个字段。trace_id是全链路追踪的关键，一次订单请求从进入编排Agent开始生成，后续所有Agent间消息都带上同一个trace_id，出问题时把所有相关节点日志按trace_id拉出来就能还原整条链路。message_id则承担幂等控制，接收方缓存最近处理过的message_id，重复消息直接丢弃，这个机制在QoS=2的“恰好一次”投递里是必需品。

信封设计上还有一个容易被忽略的点：签名是对“Header + Payload”整体做的，不只是对Payload。否则中间节点有可能篡改路由信息把你的消息转到别的地方去。

2.3 四种基本消息与通道生命周期

hermes peer的通道生命周期可以拆成四个阶段：发现、握手、使用、关闭。围绕这四个阶段，协议定义了四种基本消息。

• HELLO/HELLO_ACK：发现阶段，发起方主动联系对端，带上自己的Peer ID和协议版本，对端回应自己的Peer ID和版本。这步相当于两个人初次见面互报家门。
• AUTH/AUTH_ACK：握手阶段，双向挑战签名验证。发起方生成一个随机Nonce发给对端，对端用自己的私钥签名后返回，发起方用对端公钥验签；同一流程反向再做一次。双方都验证通过，通道进入认证状态。
• READY：确认阶段的收尾信号，表示本端已完成初始化，可以接收业务消息。这里有一个实际工程经验：一定要等READY之后再发业务请求，否则可能出现“你以为对方在线，其实对方资源还没初始化完成”。
• MESSAGE/ACK/NACK：使用阶段的业务消息和确认。QoS=1时收到MESSAGE后回ACK，处理失败回NACK并附错误码；QoS=2则在此基础上做两阶段确认。
• BYE：关闭通道，释放资源。不带BYE直接断开连接的话，对端要等TCP超时才能感知，在长连接场景下这个时间差会影响Agent的可用性感知。

通道状态机看起来很简单，但有一个容易搞混的点：连接层（Connect）和认证层（Authenticated）是两个不同状态。搞过WebSocket开发的朋友可能有体会，TCP连接建立不等于对方就是你要找的人。hermes peer把“能连上”和“可信”分开处理，所有的业务消息只能在AUTHENTICATED及之后的状态下发送。

2.4 QoS语义与幂等控制

点对点通信里最毁数据的两种场景是消息丢和消息重。shemeres peer参考了MQTT的QoS模型，但做了一层适配：Agent间消息不是主题订阅模式，而是明确的目标路由，所以确认逻辑更直接。

• QoS=0（至多一次）：发完即忘，适合日志上报、状态通知这类可容忍丢失的消息。性能最好，但业务上要注意可丢性评估。
• QoS=1（至少一次）：发送方发出消息后等待ACK，超时未收到ACK就重发，直到收到确认。接收方需要按message_id做去重，否则重发机制可能造成业务重复执行。
• QoS=2（恰好一次）：使用两阶段确认。第一阶段发送方发MESSAGE，接收方收到后返回RECEIVED；第二阶段发送方发COMMIT，接收方确认后返回COMPLETED，此后不再接受相同message_id。这个级别用于支付、订单创建等绝对不能重复执行的场景。

聊一个实际案例。我们曾经在订单Agent和支付Agent之间使用QoS=1，网络抖动时消息重发，结果同一笔订单进去了两次支付流程。排查的过程非常痛苦，因为业务日志里看不到底层重传。后来把支付确认为改成QoS=2并加幂等表，问题才彻底解决。所以选择QoS级别不应该只看“哪个级别更可靠”，要先问一句“这件事重复执行一遍后果有多严重”。扣款、发券、创建订单这类有副作用的事，一律QoS=2；状态上报、日志流这类丢了也无妨的，QoS=0就够了。

2.5 节点发现：不依赖中心注册表的动态路由

Agent之间要通信，前提是知道对方在哪里。中心化架构里这个信息在注册中心查一下就有；hermes peer走的是去中心化的发现策略，按部署规模分三档。

• 局域网内：使用mDNS，Agent启动时广播自己的Peer ID和端口，其他节点自动发现。适合开发环境和小规模部署。
• 跨网段、节点规模几百个以内：配置几个Bootstrap节点，新节点启动时先连Bootstrap，通过Bootstrap拿到其他节点的地址列表，再主动发起P2P连接。
• 大规模部署：引入DHT（分布式哈希表），每个节点负责一部分Peer ID -> 地址的映射，查询时通过哈希路由找到负责节点获取地址。

这里有个隐藏的工程问题：NAT穿透。生产环境里很多Agent跑在不同VPC或容器网络里，没有公网IP，点对点连接建立不起来。常规解法是STUN做UDP打洞，打不通就走TURN中继，但hermes peer的做法更务实——如果两个节点无论如何都连不通，就在它们之间架一个轻量Relay节点做转发，转发后的消息仍然保持端到端加密和签名校验，Relay只管搬运，无法读取业务内容。这个设计让我们在混合云部署时省了很多事。

另外，动态发现不等于没有拓扑规划。生产环境我给每个Agent的Peer ID都起有语义的名字，比如inv-svc-01、ord-core-02，再配合能力表做路由，否则排查问题的时候看到一屏无意义的哈希ID，脑壳疼。

3. 全栈协作案例：六Agent订单履约系统

3.1 角色拆分与拓扑设计

拿一个电商订单履约系统举例。这个系统拆成六个Agent，各管一段：

拓扑设计上有一点大家可能容易忽略：不是所有Agent都直接连编排Agent。比如库存Agent和物流Agent之间就有业务关联（发货要扣减可用库存），如果这两者只能通过编排Agent中转，编排Agent就成为事实上的通信瓶颈，和中心化架构没区别。hermes peer的做法是让有高频直接交互的Agent之间建立直连，编排Agent只看全局状态，不做消息搬运。

3.2 从零开始建立可信通道：一段典型的握手流程

启动阶段，六个Agent按顺序拉起，核心是让每个Agent都完成身份初始化。用一个简化版配置说明关键参数：

agent: name: ord-orchestrator peer_id: 12D3KooWOrchestrator listen: 0.0.0.0:9101 private_key: /run/secrets/ord_ed25519 bootstrap: - 12D3KooWBootstrap@10.0.0.2:9000 capabilities: - "order.create" - "order.query" - "order.cancel"

ord-orchestrator启动后，依次执行：

1. 从本地私钥文件加载Ed25519私钥，根据公钥确认自己的peer_id与配置一致。
2. 连接Bootstrap节点，上报自己的peer_id、地址、端口和能力列表，同时从Bootstrap拉取当前在线的Agent列表。
3. 解析fe-gateway、inv-core、pay-core、logi-core的地址，发起TCP/WebSocket连接。
4. 对每个连接执行握手协议：先发HELLO、再走AUTH双向签名验证、最后双方就绪后互发READY。
5. 握手完成后注册心跳定时器，默认15秒一次，超过45秒无心跳判定对端离线，触发重连逻辑。

这段流程里最值得打磨的是重连机制。网络抖动导致连接断开后，Agent不能简单地原地重连，而是要重新走一遍完整握手流程。第一次做的时候我图省事只做了TCP层的重连，结果断线重连后对端还按旧连接处理，业务消息进不来。后来统一改成“重连必重握手”，虽然多了一点握手开销，但状态一致性好了很多。

3.3 一次订单履约的完整消息流转

用户在前端说了一句“帮我下单一个智能手表，地址用默认地址”，fe-gateway把这句话转成结构化意图，开始走履约链路。

第一步，创建订单。fe-gateway构造一个order.create请求发给ord-orchestrator：

{ "header": { "version": "1.0", "message_id": "msg_fegw_0001", "trace_id": "trace_ord_20240412_001", "from": "12D3KooWFeGateway", "to": "12D3KooWOrchestrator", "type": "REQUEST", "qos": 1 }, "payload": { "method": "order.create", "data": { "user_id": "u_1024", "sku_id": "sku_watch_001", "quantity": 1, "address_id": "addr_default" } } }

ord-orchestrator收到后先查幂等表，确认msg_fegw_0001没处理过；再验签、校验消息格式；然后启动履约流程。它先做的是库存预占，于是构造一条inv.preorder消息发给inv-core：

{ "header": { "version": "1.0", "message_id": "msg_ord_0001", "trace_id": "trace_ord_20240412_001", "from": "12D3KooWOrchestrator", "to": "12D3KooWInventory", "type": "REQUEST", "qos": 2 }, "payload": { "method": "inv.preorder", "data": { "sku_id": "sku_watch_001", "quantity": 1, "order_id": "pre_ord_20240412_001" } } }

这里QoS=2的用意很清楚：库存预占是会占用库存量的操作，重复执行等于双重扣减库存，必须保证恰好一次。inv-core收到消息后校验自己库存充足，做预占，返回成功响应。之后ord-orchestrator再调用pay-core创建支付单，等用户支付成功后pay-core通过回调通知编排Agent，编排Agent再通知logi-core发货，发货后inv-core正式扣减库存。

整条链路下来，六个Agent之间一共产生了十几条点对点消息，但没有任何一条消息经过中心转发节点。每一跳的延迟理论上就是一次网络RTT加对端处理时间，比总线模式至少省了两次中间状态持久化的开销。

3.4 全栈联调时值得关注的三类配置

案例能跑通，除了业务逻辑对，还要处理好网络与运行时配置。我挑三个最容易出错的说。

一是端口规划。hermes peer默认一个端口承载所有连接，但我建议每个Agent把监听端口固定下来，并且写入部署清单。端口随机分配在本地调试没问题，一旦上到容器编排环境，负载均衡和防火墙规则会变得不可控。我们当时把端口规划做成了一份表格按环境分类：开发环境从9100起、测试环境从19100起、生产环境从29100起，一眼就能看出来哪个Agent在哪个环境。

二是心跳超时参数。系统默认15秒心跳、45秒超时，这个参数在跨地域部署时太激进。深圳节点和北京节点之间一次RTT差不多40毫秒，心跳没问题；但如果是跨国链路，长尾延迟可能到几百毫秒，需要把心跳调宽到30秒、超时调到90秒。我见过的Agent掉线事故里，有相当一部分就是心跳超时设太短，网络稍微抖一下就把Agent标记成离线，触发无意义的重连。

三是日志追踪配置。每一条出入消息都要记录header里的关键字段，尤其是trace_id、message_id、from、to、type、qos。我们用结构化日志，每条消息一行JSON，对接告警系统时按trace_id聚合就能还原一条完整链路。没有这个基础，后面任何排查都会变成大海捞针。

4. 故障排查与实操经验

4.1 握手卡在HELLO阶段

现象：Agent启动后日志停在HELLO sent, waiting for HELLO_ACK，对端就是不应答。

排查步骤：先确认网络通不通，nc -vz <peer_ip> <port>能通说明链路没问题；再确认对端Agent是否真的起来了，有些Agent依赖数据库初始化，库没就绪不会监听端口；最后看防火墙。我们踩过的实际坑是安全组规则只放行了TCP，hermes peer的握手数据包分段后有些走UDP相关机制，导致TCP端口通、协议却一直卡在HELLO。这个在云环境尤其常见。

4.2 Qos=2的消息“永远确认不完”

现象：MESSAGE发出去后一直收不到COMPLETED，消息积压在发送队列里。

原因有两种可能：接收方处理消息时抛了异常，没有走完确认逻辑；或者COMMIT阶段的消息因为某种原因丢失了，接收方没收到COMMIT，自然不会回COMPLETED。排查时要看接收方的业务日志，确认是处理异常还是链路丢消息。处理异常的话要在接收方加“失败也回NACK并附错误信息”的保护逻辑，不能什么都不回；链路丢消息的话检查两边的心跳和重传窗口，必要时调大QoS=2的重试间隔。

我在这个坑上吃过亏后，给每个Agent都加了一条规则：任何业务消息的处理函数，必须try-catch包住，成功走ACK/COMPLETED，失败走NACK并明确携带错误码。没有任何一个消息可以被静默忽略，没有结果的等待是最难排查的问题。

4.3 节点发现成功却连不上

现象：在Bootstrap的节点列表里能看到目标Agent的peer_id和地址，但发起连接时失败。

这类问题九成是指标和路由的问题。容器环境里最常见的是Agent上报了自己容器内网IP（比如172.17.0.5），其他Agent在另一个网段，拿这个IP根本连不上。解决思路是部署时明确指定对外的advertise地址：

agent: listen: 0.0.0.0:9101 advertise_addr: 10.0.0.12:9101

advertise_addr控制的是这个Agent对外宣告的地址，listen控制的是实际绑定的地址。容器场景下两者必须分开配置。类似的问题在Kubernetes里还要考虑Pod重建后IP变化，所以生产环境建议在advertise地址上用稳定的域名而不是IP。

4.4 幂等失效导致重复处理

现象：明明配置了QoS=2，消息ID也带了，业务上还是出现了重复执行。

排查后发现是幂等表清理太早。我们的幂等表最初设置24小时过期，但有一条订单消息因为支付回调延迟，业务链路走了三天才走完，幂等记录已经清理了，重发时被当成新消息处理。这个教训告诉我们：幂等保留时间和业务最大处理时长绑定，不确定的话宁可多留几天。内存有限的话可以把幂等记录落到Redis并设一个比较长的过期时间，稳定很多。

4.5 全链路追踪的实操建议

Agent间排障最怕的是“日志分布在六个节点，各说各话”。用了hermes peer之后，我们把每一条出入消息都打了结构化日志，字段就是Header里的那套。排查问题时直接按trace_id聚合，过程大概是：

1. 在监控平台搜索trace_id，拿到整条链路所有节点的消息记录。
2. 按时间排序，找到第一个错误日志。
3. 看错误日志所在节点的消息状态，是收到了没处理、还是处理了没回确认。
4. 结合QoS级别判断重发策略是否生效。

这个流程看起来简单，但前提是从第一天起就要坚持把所有消息的关键字段打到日志里。不少团队一开始为了省日志量，只打业务摘要不打消息ID，后来出了问题根本没法定位，再补日志再复盘，成本高出好几倍。

5. 踩过几次坑之后，我现在的搭建习惯

做hermes peer这套体系有一年多了，团队现在不管新老项目，只要是多Agent协作架构，默认就走点对点通信这套。结构上已经形成一个相对固定的模式：Agent之间是工作伙伴关系，每次通信都是建立信任后的直接对话，协调者只管理全局状态，不干预具体通信路径。

如果给刚开始尝试的人一个最直接的建议，我会说：先别急着把六个Agent全部接进来，先跑通两个节点再说。在一个干净的网络环境里，两个Agent完成握手、互发一条业务消息、看ACK正常回来，这个看起来没什么信息量的实验，其实已经把身份体系、消息格式、QoS语义、日志追踪这四件事全部验证了一遍。这两个节点通了，再逐步把更多Agent接入，每一步都有清晰的验证点，问题出现时范围也能控制在最小。

还有一个执行细节大家容易忽略：版本兼容。hermes peer的消息Header里有version字段，但真正联调时不同语言的Agent可能用的SDK版本不一致，握手时只校验大版本一致是不够的。我们的做法是在HELLO阶段交换一个features字段，双方都支持的协议子集才会启用，比如传输层加密、压缩、批量确认这些扩展功能，都要在握手时协商确认，避免一侧以为开了加密、另一侧还在发明文。

最后分享一个正向收益的观察。系统改成点对点通信之后，最明显的变化不是性能指标，而是出问题时的排查效率大幅提升。以前总线模式查一次消息链路要三个人三个系统对时间线，现在一个人按trace_id拉一遍所有Agent日志，半小时就能还原完整链路。这个效率红利，在Agent数量超过五个之后会体现得越来越明显。如果你也在做多Agent协作，我建议认真研究一下hermes peer这类点对点协议，值得投入。