做了几年多Agent系统说实话一开始我根本没把通信协议当回事。当年想得很简单Agent之间能发消息、能互相调用不就行了。直到系统从三五个Agent扩展到十几个从单机挪到容器集群我才意识到消息格式、服务发现、RPC这三个环节没做扎实整个协作系统的可靠性和性能会一起崩掉。这篇文章就围绕多Agent协作系统的通信协议讲清楚消息格式怎么设计、服务发现怎么做、RPC调用怎么选型和调优目标是帮你构建一套高效可靠的Agent通信网络。如果你正在搭多Agent系统或者想让现有Agent之间的通信更稳、更快这篇应该对你有用。1. 先把问题拆开多Agent通信到底在难什么1.1 通信协议是整个协作系统的语言中枢多Agent系统的本质是多个独立运行的智能体协同完成任务。既然每个Agent可以有自己的运行环境、生命周期甚至不同的技术栈那一个用Python写的规划Agent和一个用Java或者Go写的执行Agent怎么交换信息只能靠一套双方都能理解和遵守的约定也就是通信协议。我把这套协议拆成三个层面来理解。消息格式解决“怎么说”的问题服务发现解决“找谁说话”的问题RPC调用解决“怎么把话说完并且拿到结果”的问题。这三点不是孤立的而是层层叠加。很多团队把精力全放在Agent的算法和提示词调优上结果一到联调就卡住消息解析不了、服务地址找不到、调用超时到崩溃。说到底是通信这层地基没打好。有个很直观的类比是嵌入式开发里的I2C和SPI。做过单片机通信的朋友都知道I2C的速率虽然只有几百K但胜在协议简单、接线少、多设备挂在同一条总线上也能稳定工作。Agent系统的通信协议其实也一样信息密度高不高是一回事但首先要稳定、可预期、可排查。你连消息格式都没统一就好比I2C总线上一个设备用7位地址、另一个用10位地址谁都找不着谁。1.2 消息格式、服务发现、RPC三者相互牵连三个层面不是先做完A再做B再做C的关系而是设计时要一起考虑。举个例子服务发现返回的实例地址、端口、协议版本要不要带进消息的元数据RPC请求的traceId是不是也要在消息信封里跟着走才能贯穿整条调用链我见过不少系统消息格式用的是简单JSON服务发现用的是固定配置文件RPC则是自己拿HTTP加个路由硬拼。单体跑的时候没问题一旦Agent数量上来、容器频繁重启问题就全暴露了配置文件里的IP早就失效了消息里没有traceId导致链路追踪要人工拼日志RPC超时了也没有统一的重试策略每层各写各的最后故障恢复全靠人肉盯。这一步的核心认知是通信协议是一套整体设计不是三个独立模块。下面三节分别拆开讲但你真正落地时要始终当作一个体系来考虑。2. 消息格式设计Agent之间交换信息的通用语2.1 序列化格式怎么选消息格式最底层的一个问题是序列化。Agent运行时对象在内存里是一堆结构体但通过网络发出去必须变成字节流。序列化格式决定了字节流的体积、解析性能、跨语言能力以及最重要的——两端对字段变更的容忍度。常用的几种格式我基本都在生产环境里折腾过直接说结论。如果团队快、要快速验证想法JSON是起步的选择可读性强、调试方便、任何语言都有库。但JSON的问题也很明显体积偏大、没有强类型约束、协议演进全靠自觉。比如一个Agent把用户意图字段从字符串改成嵌套对象另一端的解析逻辑可能直接挂。MessagePack和CBOR都是二进制化的JSON目标都是在保留动态结构的同时压缩体积、提升解析速度。它们比JSON省流量但一样不强约束字段类型适合对payload大小敏感、但还没到需要强schema的阶段。CBOR有RFC 8949标准在一些IoT嵌入式场景里更常见Agent系统里也能直接用。如果Agent数量多、接口会长期演进Protobuf通常是最稳的选择。它有明确的schema定义文件.proto生成各语言的代码序列化体积小、解析快、强类型校验。代价是要引入编译流程每次改字段都要重新生成代码学习成本比JSON高不少。我个人的习惯是核心服务之间的内部RPC用Protobuf边缘的调试接口和外部对接用JSON。两者不冲突按场景切分就好。做一个简单的对比序列化格式体积解析性能强类型跨语言字段演进适用场景JSON大中等弱极好需人工维护调试、外部对接MessagePack中等较快弱好需人工维护动态负载、嵌入式CBOR中等较快弱好需人工维护标准化IoT场景Protobuf小快强好schema支持内部核心RPC选型的时候我总结了一条原则先想清楚消息的生命周期。如果一个消息只是发出去然后被消费一次怎么便宜怎么来如果它要进消息队列、被多个Agent消费、可能未来还要变更字段那最好一开始就用带schema的格式省得后面再做数据迁移。2.2 消息信封和核心字段序列化格式定了之后接下来要设计消息的整体结构。我习惯把消息分成信封和负载两层。信封是每个Agent都会读的通用部分负载是业务数据。信封装得越规范后面做路由、追踪、限流就越省事。信封里我必带的字段有这么几个。messageId是全局唯一的消息ID用来去重和追踪比如执行Agent结果回调时通过messageId关联任务就非常方便。topic或者type字段表示消息的语义类型比如task_submit、task_result、heartbeat路由和消费者可以靠它做匹配。timestamp是消息产生时间很多排序和分析场景都依赖它。ttl是存活时间尤其消息经过队列或者缓存时超过ttl的消息可以直接丢弃避免旧消息堆积。traceId更是不能少一次完整的Agent协作任务会跨多个服务和网络跳转traceId把整条链路串起来排查问题全靠它。我自己遇到过最典型的翻车早期做Agent系统时偷懒消息体直接塞了个大JSON连版本号都没有更别提traceId。结果生产环境里一个任务从规划Agent到执行Agent再到反馈回路中间出现了循环调用日志刷了几万行但没法定位是哪一条消息触发的。后来补了traceId一条命令就能看完整调用链路效率完全不一样。负载部分倒是相对自由但建议至少包含payload和error两个子段。很多初版设计只考虑正常流程忽略错误返回。结果Agent一旦处理失败另一端面对的是空响应只能瞎猜。显式在负载里带上错误码和错误消息是分布式系统里很便宜的防御性设计。2.3 版本兼容与字段演进消息格式设计得再好挡不住业务调整。需求一变消息字段就要增删改。最痛的是线上有多个版本的Agent同时运行你没办法让所有实例同时升级。这就需要格式在演进过程中保持兼容。几条基本原则值得刻在脑子里。第一只能增加字段不要修改已有字段的类型更不要删除字段。加字段是老客户端解析新消息时容易忽略的但至少不会崩改类型则是直接破坏解析。第二如果是带schema的格式新增字段要标记为可选别在加字段时顺手设置为必填否则旧代码解析时校验不过。第三即便通信双方都是你控制的代码消息里也一定要放版本信息。等线上出了两边代码都是最新的但还是对不上的问题时版本号能救你一命。实际操作里我还会在加载消息schema时做一次前后兼容性检查把新增字段按版本号记录在文档里。虽然麻烦点但当接口超过几十个版本时这套记录就是整个团队的保命文档。3. 服务发现让Agent在集群里找到彼此3.1 集中式注册中心还是去中心化消息格式解决的是消息长什么样但Agent要通信得先知道对方的IP和端口。小规模系统里可以用配置文件写死但Agent是动态的容器重启、水平扩缩容都会让地址漂移。服务发现就是解决动态寻址这件事。常见的方案分两大类。一类是集中式注册中心所有Agent启动时向中心注册自己的地址、端口、能力标签消费者发现服务时去中心里查。etcd、Consul、ZooKeeper都是这类。另一类去中心化方案比如基于DNS、基于gossip协议Agent之间互相通告对方。Agent系统里我建议先上集中式理由很简单一致性容易保证、排查方便、生态成熟。DNS结合Consul也能实现服务发现但TTL缓存带来的更新延迟在某些场景下会影响故障转移速度。集中式里etcd和Consul我用得比较多。etcd的watch机制很适合服务发现Agent监听某个前缀的key变化注册中心有增删时立刻收到通知租约机制则能让宕机的Agent实例在一段时间内自动被清理。Consul的优势是多数据中心、自带健康检查和DNS接口但重一点。ZooKeeper在Java生态里常见不过它的CP模型和会话机制有时候比etcd繁琐非强需求我不会首选。3.2 注册、心跳和健康检查服务发现不能只做一个在线列表它还要保证列表里的地址都是真正能用的。这就是健康检查的作用。最基础的做法是租约加心跳。Agent启动后向注册中心put一个带租约的key比如TTL是10秒Agent每个5秒续约一次。如果Agent进程挂了续约停止租约过期后注册中心自动删除key。这里有个很实际的经验租约TTL不要设太短也别设太长。太短网络抖动或者GC停顿一次Agent就被误杀摘除了太长Agent真的挂了要半天才能从列表里消失调用方会一直往死地址上发请求。我的经验值CP里把TTL设在10到15秒心跳间隔5秒既避免了误杀也能在十几秒内完成故障感知。除了租约注册中心还要做主动健康检查常见三种TCP连通性检查、HTTP健康接口检查、gRPC健康检查。TCP最基础但只要端口通就认为服务健康不够精确。HTTP接口通常是/health或/healthz可以自定义更多检查逻辑。如果用了gRPC直接用标准healthCheck协议省去额外的HTTP端口。我一般组合使用注册中心做TCP加HTTP检查Agent自己内部再做组件级健康状态上报。3.3 容器场景下的服务发现躲不开的几个问题容器化部署几乎成了Agent系统的标配。容器带来便利也让服务发现的坑变多了。第一个问题是IP漂移容器重建后IP就变了服务发现必须能快速感知并更新。用etcd的watch机制通常几百毫秒内能通知到客户端但前提是客户端没缓存太旧的数据。第二个问题是容器编排平台的负载均衡和服务发现是两层概念Kubernetes的Service是给外部流量用的Agent内部的gRPC调用则更推荐直连Pod地址配合客户端负载均衡减少中间转发延迟。这里多说一个坑有些Agent容器是带状态的尤其在消息处理中不能简单重启。这时服务发现不只是找地址还要约定好实例的唯一标识和会话亲和性。不要把容器名当唯一标识用因为重建后名字可能变给Agent实例分配一个持久ID并注册到元数据里比什么都可靠。4. RPC调用让Agent之间的协作像函数调用一样自然4.1 RPC的本质和框架选型消息格式和服务发现都有了Agent之间真正的调用动作靠RPC完成。RPC的目标是让一个Agent调用另一个Agent的能力像调用本地函数一样自然。听起来简单但跨网络、跨进程之后延迟、重试、超时、参数传递、错误处理全都变了。主流的RPC框架我对比过几个。gRPC是当前多Agent系统里最常见的选择基于HTTP/2支持多路复用、流式传输、Protobuf强类型定义生态完善。Thrift在数据交换场景里比较出名但Agent调用这种服务间通信场景使用率相对低。JSON-RPC简单直接跟JSON消息格式同构适合轻量级交互和高频调试。RPC框架传输层序列化流式强类型生态推荐场景gRPCHTTP/2Protobuf支持强极好Agent内部高频调用ThriftTCP/HTTPThrift IDL支持强好跨语言数据服务JSON-RPCHTTP/TCPJSON弱弱中等轻量调试、跨系统对接gRPC的HTTP/2多路复用我很喜欢。传统HTTP/1.1每个请求一个连接并发高时连接数爆炸。HTTP/2是一条连接复用多个流Agent之间如果调用频繁可以显著减少握手开销和端口占用。这在容器集群里特别重要因为每个Pod的连接数上限和文件句柄都是实打实的资源。4.2 同步、异步与流式调用怎么选RPC的调用模式直接决定Agent协作的体验。同步调用是一端发请求阻塞等待结果最简单的模式。如果Agent B需要调用Agent C的规划结果才能继续那就适合同步。同步模式对超时最敏感一旦滞后就会拖慢整条链路。异步调用是一端发完请求立刻返回结果通过回调或者轮询获取返回适合能把任务扔出去就不用管的场景比如定时任务分发。流式调用则是持续的流gRPC单向流和双向流都支持适合大段文本生成、上下文持续交互相这类场景。Agent协作系统里三个模式都会用到。比如执行Agent跑一个耗时的分析任务规划Agent不可能一直傻等这时异步加回调最合适。但如果两个Agent在做紧密的协商式推理需要持续交换中间结果双端流式反而更顺手。选型的核心是别过度设计同步能解决问题就先同步从同步改成异步容易从异步改回同步会让你怀疑人生。4.3 超时、重试与熔断的三重防线RPC调用一旦跨网络失败的维度就变得复杂。网络丢包、服务端过载、处理超时、进程重启每一种都会让调用方处于不确定状态。要用超时、重试、熔断组成三道防线。超时要设置并传播。gRPC里的deadline概念是整条调用链共享的调用方设置一个总超时时间每个中间节点消耗一部分而不是让每一跳各自设一个固定超时。很多系统最初只在最外层设超时结果内部服务各等各的整体延迟直接失控。合理的做法是类似预算分配最外层30秒每层传递时递减形成一条时间预算链。重试不能简单“多打几次”。如果没有幂等保障同一个任务被重复执行可能造成灾难性后果。重试间隔要使用指数退避加随机抖动避免所有客户端同步重试导致服务端雪崩。比如第一次失败等1秒第二次等2秒第三次等4秒再随机加减最多100毫秒。重试次数也要限制一般两到三次就够了不要无限重试。这里有个血泪教训我见过一个Agent调用链因为反复重试把一个本来延迟300毫秒的单查询放大成了后端1分钟的高负载整个集群被打挂。熔断则是把失败控制在源头。连续失败次数达到阈值熔断器打开接下来的请求直接快速失败不再排队等超时给后端恢复的时间。等后端恢复了熔断器再半开放几个试探请求成功后就关闭。这套机制配合超时和重试才算完整的一整套RPC可靠性方案。5. 实战实录一个多容器Agent系统的通信落地5.1 拓扑设计与容器编排前面说的概念落到实际场景里更容易理解。拿一个常见的多Agent部署来说3个容器分别是etcd注册中心、agent-core核心调度容器、agent-executor执行容器。我需要让它们之间通过前面讲的通信协议安全稳定地协作。拓扑很清晰agent-core启动时把自己的能力注册到etcdagent-executor也注册进去。agent-core通过服务发现找到executor实例然后用gRPC把任务分发给它executor处理完通过RPC回调结果。用docker compose来编排一个简单但完整的通信网络就这样搭起来了。docker-compose.yml的核心片段大致是这样services: etcd: image: quay.io/coreos/etcd:v3.5.5 ports: [2379:2379, 2380:2380] command: etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://etcd:2379 agent-core: image: agent-core:latest depends_on: [etcd] environment: ETCD_ENDPOINTS: etcd:2379 AGENT_ROLE: core ports: [8080:8080] agent-executor: image: agent-executor:latest depends_on: [etcd] environment: ETCD_ENDPOINTS: etcd:2379 AGENT_ROLE: executor这里最关键的配置是让所有Agent统一通过etcd这个服务名来发现注册中心而不是硬编码容器IP。容器重建后IP会变但服务名不变这本身就解决了一大半的地址漂移问题。5.2 5条命令验证整张通信网络架构搭好之后可以先不用写业务代码用5条命令把通信网络本身验证一遍非常高效地暴露问题。第一条拉起整个环境docker compose up -d第二条确认三个容器都活着docker compose ps正常输出里3个服务的STATUS都是Up。第三步才是关键验证服务发现是否生效。直接在etcd里看注册了哪些Agent节点docker compose exec etcd etcdctl get /agents --prefix --keys-only如果agent-core和agent-executor都正确注册这里能看到两个带租约的key比如/agents/agent-core和/agents/agent-executor。看不到或者只有其中一个就要查Agent的注册代码了。第四步验证RPC调用。用grpcurl直接调agent-core的接口grpcurl -plaintext -d {task_id:001,type:analysis} agent-core:8080 agentproto.Planner/Plan返回里能看到调用成功的结果。第五步观察执行端日志docker compose logs -f agent-executor这里能看到executor收到了通过etcd服务发现找到并用gRPC调过来的任务请求处理完成后再把结果回调回core。有这套验证方法通信网络是否正常在5分钟内就能判断出来。我每次新加一个Agent容器都会先用这个流程跑一遍确认它注册了、能被找到、能响应RPC然后再开始写业务逻辑。5.3 踩过的坑和排查方法这套架构跑起来之后坑是一点一点填平的。说几个有代表性的。第一个是RPC超时问题。线上出现过“cannot finish rpc call in 30 seconds”的报错一眼看到是RPC调用超过30秒被中断。排查下来发现agent-executor要执行一个耗时分析任务但调用方的deadline是全局30秒后端处理需要40秒所以执行到一半就被取消了。这个问题的根源不是机器慢而是超时预算设置没考虑任务实际耗时。后来我把耗时任务改成异步模式任务接口先返回这次的执行ID真正的结果通过回调或查询方式获取问题就解决了。第二个是连接被服务端关闭。日志里出现类似server closed abruptly的错误字符流读一半连接断了。这类问题在容器环境里极其常见多数是负载均衡器或网络代理的空闲连接超时导致连接被回收客户端还在用同一个连接发请求自然失败。解决方式是让客户端定期重建连接、对断连的RPC做一次安全重试、同时把gRPC的keepalive打开在连接空闲时也发送保活ping。第三个坑在服务发现的缓存上。Agent客户端从etcd watch到变更通知有很大的延迟可能拿到已经失效的地址。后来我在客户端加了定时全量刷新比如每60秒强制重新拉一次节点列表同时保存上一次请求的失败地址短时间内不再把请求发过去。这个改动看着土但效果立竿见影故障转移时间从分钟级降到了秒级。整体来看通信网络的调优是个持续逼近的过程你无法一次做到完美但可以设计出能够快速排查、快速恢复的协议结构这是最值得投入的部分。6. 写在最后通信设计里我最看重的三件事做了这么多Agent系统的通信改造让我挑三件最重要的事一定是这三件。第一件是消息格式的schema化和版本管理尽早做。业务刚起步时多个Agent消息直接传JSON很爽但Agent种类超过三四个、接口开始互相依赖时没有schema的代价就是你改一个字段所有接收方都要人肉排查一遍。Protobuf带来的额外工作会在中后期百倍地赚回来。第二件是可观测性是通信设计的标配不是可选项。traceId从第一天就要打上日志、消息、RPC调用全链路贯穿。我见过太多团队排查Agent协作问题时根本不知道一条消息从哪来、到哪去全凭猜。有一个贯穿的traceId至少能把故障排查时间缩短一个量级。第三件是超时、重试和熔断永远要一起设计。只设超时不设重试临时故障时任务就白白失败只设重试不设熔断后端一抖动整个集群就被重试打垮。这三者是一套互相关联的机制必须在协议设计时就一起考虑而不是上线之后再补救。通信协议是Agent协作系统的骨架虽然不像算法和Agent能力那样光鲜但它是所有上层智能稳定运行的前提。希望这篇整理能帮你把这块骨架搭得更牢靠少走一段我当年走过的弯路。