上周日凌晨我在本地起了12个Agent进程跑一个多步骤的资料整理任务它们各自调用大模型、各自写中间结果、各自往同一个目录丢文件。结果毫不意外地失控了三个Agent重复处理了同一批数据、两个Agent在互相等待对方才会生成的文件、还有一个Agent把另一个Agent写了一半的结果当成了最终结果直接拿去做下一步。凌晨四点我盯着满屏的日志第一次认真想一个问题这些Agent之间到底需不需要一套统一的调度和触达机制Agent-Reach就是我在这个背景下用两周业余时间做出来的一套轻量级多智能体调度触达系统。它的核心只做三件事给每个Agent一个可寻址的身份、统一的消息投递管道、以及一套在分布式环境下不会出岔子的任务状态机。Reach这个词我特别想强调一下——它不只是发送而是触达是确认对方收到了、理解了、并且真的开始处理了。如果你也在跑多个Agent协作的任务或者正准备把单Agent脚本升级成多Agent协作流水线这篇文章记录的就是我从需求梳理到落地调参的全过程踩过不少坑也都一并写在里面了。1. 为什么自研Agent-Reach从一场失控的多Agent联调说起很多做Agent开发的人会有个错觉既然每个Agent都用大模型驱动天然懂人话那Agent之间应该也能互相理解、自动协作。但实际上大模型解决的是内容理解不是任务编排。Agent之间的通信、调度、确认、容错全都要基建来兜底。1.1 多Agent协作的第一个错觉Agent之间会天然互相理解我一开始也天真过。设计思路是Agent A把任务结果用自然语言写进一个共享的中间文件Agent B自己去读、自己理解、自己决定下一步。这个方案的毛病在第一次小规模联调就暴露了Agent B确实能读懂Agent A写的文件但它不知道这个文件是写了一半的草稿还是最终结果不知道是最新的还是已经过时的更不知道如果处理出错该找谁重跑。这里我得到一个核心认知Agent之间的协作从来不缺理解能力缺的是通信语义。这是谁的请求、这属于哪个任务、这是第几次尝试、这个结果应该给谁——这些元信息才是多Agent协作真正需要的东西而它们恰恰不会出现在自然语言文本里。1.2 失控的真实场景调度全靠定时器和人肉我回想那次失控本质上是因为没有任何调度者Agent各自为战协调全靠人肉看日志。后来我尝试加了一个中心调度器但又发现只做了分配、没有做投递反馈调度器把任务塞给Agent B的输入目录就完事了Agent B到底有没有拿到、有没有开始跑、卡住了还是崩了调度器一概不知道。结果就是任务积压、重复执行、最终结果错乱。这也是我决定做Agent-Reach的导火索。它需要解决的不是Agent怎么思考而是Agent怎么被别人可靠地找到和调用——也就是服务治理领域的寻址、投递、状态管理三件事只是对象从微服务换成了智能体。1.3 Agent-Reach要解决的三件事寻址、投递、状态拆解下来系统要做的事情非常清晰寻址每个Agent需要有一个稳定、可查询的身份Agent ID而不是一个随机的进程名。调度器要知道当前有哪些Agent在线、各有什么能力、应该把任务发给谁。投递要有统一的消息管道把任务送过去并且要有确认机制。投递不是发出即成功而是对方确认收到并开始处理这一点是整个系统与普通消息队列最本质的区别。状态每个任务从创建到完成要经历明确的状态流转任何一步失败都有据可查可以安全重试不会出现任务其实完成了但状态还挂在中间这种鬼故事。这三个目标听起来简单落地的时候每个都踩了一圈下面按模块拆开说。2. 给Agent一张通讯录注册中心与寻址机制的设计首先要解决的是Agent有哪些、在哪、能干什么。这块我对比了好几种方案最终选了一条轻量路线Redis Hash 心跳上报。很多人会问为什么不用现成的注册中心这个选择背后有不少考量。2.1 这里为什么不能直接用消息队列我评估过用RabbitMQ或者Kafka直接做任务投递的可行性。结论是MQ能解决消息送达但解决不了任务归属和执行者状态。Kafka的消费组虽然能把消息分摊给多个消费者但你不知道这条消息具体被哪个Agent消费了、这个Agent当时是健康的还是已经快崩了、以及这条消息的任务状态是整个流程的哪一步——这些恰恰是Agent调度最需要回答的问题。MQ在技术上是Agent-Reach的地基之一但它只负责传输调度逻辑和状态语义必须自己建。另一个考虑是轻量化。为一个几十上百个Agent的协作场景去部署一套完整的服务网格或者工作流引擎太重了。Agent-Reach最后只依赖RedisAgent节点上连数据库都不用装部署成本几乎为零。2.2 注册信息的最小设计一个含心跳的Agent登记表我给Agent设计的最小注册表结构如下Redis里用Hash存每个Agent是一个fieldvalue是JSON字符串。{ agent_id: agent-parser-v3, host: 192.168.1.24, port: 9801, capabilities: [parse, extract, augment], status: IDLE, in_flight: 3, max_concurrency: 10, last_heartbeat: 1713245672, state_version: 41 }每个字段都有它的用途。agent_id是全局唯一名字命名规则建议用功能-版本格式这样调度日志一眼能看出是哪一类Agent在跑。capabilities是关键它让调度器能做简单的路由判断来一个需要解析的任务只发给有能力处理parse的Agent而不是全体广播。心跳间隔我设的是5秒一次15秒没收到心跳就把Agent标记为UNREACHABLE暂时不派新任务给它等它恢复心跳再重新放回可用池。这个窗口值不能设太短否则Agent一次GC停顿就可能被误判下线——这个坑我后面专门讲。2.3 路由规则的取舍先做固定路由再做语义路由路由策略我分成了两层第一层是硬路由第二层是软路由。硬路由条件包括Agent在线、有能力标签、当前在途任务数小于并发上限这几条不满足直接过滤掉。软路由再在这个基础池里做选择优先选空闲度高的Agent在途任务数少、优先选同机房的Agent。实测下来这套规则已经能覆盖九成以上的场景。大家期待的语义路由——比如根据任务描述让LLM决定派给谁——我特意留到了后期。不是说语义路由没用而是它不稳定还慢每次路由都去调大模型延迟和成本都受不了。更稳妥的姿势是由上层编排层先做语义拆解给任务打上结构化标签Agent-Reach只负责按标签精确匹配各司其职。3. 投递不是发出去就完事超时、熔断与背压设计寻址解决的是发给谁投递解决的是怎么确认它收到了。这一块是我踩坑最密集的地方也是最容易在设计初期被忽略的部分。3.1 最容易被忽视的Agent到底有没有已读我把投递语义定义得很严格。Reach的意思是触达所以一条投递消息的生命周期包含了发送方调度器、传输通道、Agent接收端三个环节的协同确认。在实际实现中我给每条消息增加了唯一ID也就是message_idAgent收到消息后会先把message_id写到本地的已处理集合里再开始执行执行完再回传一个DONE确认。这样即使整个链路有重试Agent端的幂等性也有保证。这里有一个我在第一版遗漏的细节Agent的已收到和已处理完成必须是两个不同的确认。我最初只做了一次确认结果出现了Agent收到任务、开始执行、执行到一半崩溃重启的情况。调度器以为任务还挂在执行中Agent重启后以为自己已经处理完了两边状态就错位了。改成两个确认之后调度器才真正准确掌握每一个任务的进度。建议所有做类似系统的朋友在设计消息协议时一定要区分至少三种回调ACK_RECEIVED收到了、ACK_STARTED开始干了、ACK_COMPLETED干完了否则排查定位问题的时候会痛苦到怀疑人生。3.2 超时重试导致的调度风暴一个亲身踩过的坑我遇到过最典型的故障是下游某个Agent因为一次慢GC处理速度骤降结果调度器不断重试把任务一批批重发过去。下游本来就慢又被新增任务砸中最后直接雪崩。我当时看着监控面板上的重试曲线一路飙升心里只有后悔——怎么没早点做熔断。现在我的重试策略是每个任务的投递重试次数上限为5次重试间隔采用指数退避5秒、10秒、20秒、40秒。与此同时每台Agent节点上增加了在途任务数硬上限一旦在途任务数达到max_concurrency调度器就不再向它派发新任务直接标记为BUSY。这样调度器天然给Agent背压不会出现把对方压垮的情况。3.3 背压让调用方先慢下来比让Agent硬扛更靠谱背压设计是我认为Agent-Reach里最能体现系统工程思维的地方。面对下游Agent过载常见的处理方式是把任务积压在调度器的内存队列里但这样只会把问题转移给调度器自己。我采取的做法是双重背压上游背压任务创建接口在调度器积压超过阈值时直接返回503让真正的任务创建方上层编排器感知到下游拥堵进而放慢节奏甚至触发上游自己的资源降级策略。下游限流每类Agent在Redis注册表中实时上报自己的在途任务数量调度器在做路由时将这个数量作为硬指标。这两个机制配合起来的效果是系统不会给任何节点雪上加霜忙的Agent只会更忙的逻辑不会出现任务最多是在源头排队而不是在某个脆弱环节堆积成灾。我觉得这一点对多Agent系统而言尤其重要——毕竟Agent的执行行为本身有不确定性基建更要确定性。4. 任务状态机从PENDING到DONE中间还有多少种状态状态管理是Agent-Reach的重头戏。事务性、可观测、可恢复这是分布式调度最难的三件事。任务状态机的设计直接决定了整个系统的可靠程度。4.1 状态机的最小完备集合我最终实现的任务状态集合如下状态含义可转移到的状态PENDING任务已创建等待调度SCHEDULED, CANCELEDSCHEDULED已匹配目标Agent等待投递DELIVERING, FAILEDDELIVERING投递中等待ACKRUNNING, FAILED, TIMEOUTRUNNINGAgent已确认开始执行SUCCEEDED, FAILED, TIMEOUTSUCCEEDED执行成功已确认终态FAILED某环节失败PENDING允许重试带retry_countTIMEOUT超时未确认PENDING允许重试或DEAD_LETTERDEAD_LETTER重试耗尽终态这个状态集合特意保持很小的规模每个状态的存在都必须回答一个问题一个运维同学在凌晨三点看到这个状态能不能不用查文档就猜到发生了什么。加了CANCELED和DEAD_LETTER之后整个状态机的表达力就完整了但也没有冗余分支。4.2 状态漂移问题当旧消息比新消息后到分布式系统里最隐蔽的一个问题就是乱序。我在测试中发现Agent A先发出了任务完成信号但因为网络抖动这个完成信号比后发出的另一个信号更晚到达调度器。如果调度器处理完新的信号后又拿旧信号盲目覆盖状态就会出现任务已经完成却被改回RUNNING的错乱。解决方式是在状态变更请求里带上版本号state_version调度器每接受一次状态变更就自增版本号。更新时用条件更新只接受请求版本号等于当前版本号1的变更拒绝过期请求。用SQL的说法就是乐观锁。这个改动实施之后状态错乱的频率从实测的0.7%降到了0.03%而且剩下的0.03%基本是真正的逻辑问题不再是并发覆盖。任何做Agent调度的朋友如果看到任务状态时好时坏先怀疑是不是状态更新少了版本控制。4.3 状态持久化与崩溃恢复SQLite vs Redis的取舍状态不仅存在内存里还要持久化。我试了两套方案。第一套是纯Redis简单快但Redis本身如果重启任务状态就有丢失风险必须配合AOF持久化。第二套是让每个Agent节点本地用SQLite记录自己处理过的任务状态调度器做最终汇总。实际运行之后我发现最稳的组合是Redis保存实时状态 SQLite保存Agent本地执行痕迹。Redis负责热路径查询因为Agent-Reach调度器每次路由都要读状态SQLite负责崩溃恢复和审计日志。一旦Redis丢了数据可以从所有Agent节点的SQLite逐步重建任务全貌。说句实话加了这层冗余之后我晚上再也没被报警电话吵醒过。5. 实测数据与调参记录30个Agent并发触达的真实表现光设计理论没用得跑出真数据。我把Agent-Reach部署到了一台4核8G的测试机上挂了30个Agent进程分别模拟解析、摘要、审核、分发四类任务。压测工具用的是自写Python脚本加Locust跑了整整48小时记录下关键表现。5.1 测试环境与压测工具测试机配置CPU4核Intel i54物理核心内存8GB存储NVMe SSDRedis6.2单机默认配置开启AOFAgent进程30个单进程并发上限5压测端Locust压测机与测试机同内网网络延迟约0.5ms压测模型我设计得比较贴近真实任务每隔50毫秒到500毫秒随机创建一次每个任务会随机经过2到4个Agent接力处理模拟一条流水线。这个模型能较好地反应多个Agent协作触达的链路压力。5.2 三组关键数据吞吐、超时率、状态丢失率48小时的实测结果如下表所示指标实测结果说明调度吞吐量约1850 TPS单机调度器极限CPU成为瓶颈平均触达延迟约230ms从任务创建到首个Agent确认收到投递超时率0.3%默认30秒超时窗口下的超时比例状态错乱率无版本控制0.7%高峰期乱序导致的状态覆盖状态错乱率版本控制后0.03%乐观锁生效后的表现调度器内存占用峰值约1.2GB包含状态缓存和消息缓冲Redis内存占用约800MB含状态表和Agent注册表我对这些数据比较满意的主要是吞吐量——1850 TPS对几十上百个Agent的团队协作场景绰绰有余不必上多实例调度器。状态错乱率从0.7%降到0.03%也验证了版本号方案的有效性。0.3%的超时率不能追求再低因为超时本是设计中的兜底机制设置太激进反而会增加无谓的重试。5.3 调参清单哪些参数先调哪些别乱动最后汇总一份我反复调过的参数清单每个参数都踩过代价参数我的最终设置调参经验HEARTBEAT_INTERVAL5秒不建议低于1秒会引发心跳风暴Agent一卡就被误判UNREACHABLE_THRESHOLD15秒等于心跳间隔的三倍是比较稳妥的窗口DELIVERY_TIMEOUT30秒建议等于常见任务平均耗时的5倍以上宁宽勿窄MAX_RETRY5次超过5次基本意味着一方已经出大问题直接去DEAD_LETTER查RETRY_BACKOFF_BASE5秒翻倍递增第一次重试5秒之后10秒、20秒、40秒INFLIGHT_LIMIT每Agent 50条根据Agent处理速度和内存占用调整别贪大STATE_VERSION_ENABLED开启无论如何不要关血泪教训REDIS_AOFeverysec每秒刷盘平衡性能和数据安全调参是动态过程一定要配合监控数据来做判断。单纯抄参数不结合自己的场景大概率会水土不服。我强烈建议至少跑24小时压测再调优别急着看5分钟的数据就下结论。最后再分享一个我的真实体会做多Agent调度真正的难点往往不在Agent本身的智能而在那些毫不起眼的基建细节——有没有心跳注册、有没有状态版本、有没有背压、有没有超时兜底。这些细节做好了Agent再多也不怕乱做不好两三个Agent就能把孩子折磨疯。Agent-Reach这个项目目前还在持续演进中下一步我计划加入更细粒度的资源配额控制和跨机房的调度策略如果有进展我再来同步。