1. 从单体到集群这次改造到底在解决什么问题去年下半年我接手了一个已经跑了三年多的智能体系统。它最初的设计很简单一个中心调度进程下面挂几个功能模块所有请求都走同一条主链路。刚开始日请求量几千的时候这套架构跑得挺舒服部署简单、日志集中、排查问题也方便。但到了今年年初日请求量涨到几十万问题就全冒出来了。最直观的表现是响应延迟从平均 200 毫秒一路飙到 2 秒以上高峰期甚至出现大面积超时。更麻烦的是每次上线一个新功能哪怕只是改一个很小的逻辑都得把整个系统重新部署一遍。一个模块的内存泄漏能把整个进程拖垮。这种“牵一发而动全身”的感觉做过单体架构的同学应该都懂。所以这次改造的核心目标就是把原来那个“什么都管”的单体调度中心拆成一组各自独立、又能协同工作的智能体集群。我把它叫做“主权智能体集群”——每个智能体对自己的任务域有完整的决策权不需要事事向中心请示但整体上又能通过一套轻量的协调机制保持一致。这个思路听起来有点像微服务但又不完全是。微服务拆的是业务功能而智能体集群拆的是“决策单元”。每个智能体有自己的感知、规划、执行闭环能独立完成一类任务比如意图识别、工具调用、结果校验、异常恢复。它们之间通过消息总线通信而不是直接 RPC 调用。为什么要这么拆因为智能体系统的负载特征和传统 Web 服务很不一样。传统服务的请求是短平快的而智能体的任务往往是有状态的、长链路的。一个用户请求可能触发十几个智能体的协作中间任何一环卡住整个链路就堵了。如果所有智能体都跑在同一个进程里一个慢任务就能把线程池占满后面的请求全部排队。拆成集群之后每个智能体可以独立扩缩容。意图识别这种 CPU 密集型的多开几个实例工具调用这种 IO 密集型的用少量实例加异步队列就够了。资源利用率一下子就上去了实测下来整体吞吐量提升了大概 3.5 倍P99 延迟从 2.1 秒降到了 480 毫秒。但拆开只是第一步真正的难点在于拆开之后怎么保证它们还能像一个整体一样工作。这就是后面要详细聊的协调机制、状态管理、故障隔离这些事。2. 主权智能体的边界划分怎么拆才不打架2.1 按决策域拆分而不是按功能模块拆分很多人一提到拆分第一反应是按功能模块来用户模块、订单模块、支付模块。但智能体系统不能这么拆因为智能体的核心是“决策”不是“功能”。一个智能体可能同时涉及用户意图理解、上下文检索、工具选择这几个功能但这些功能是围绕同一个决策目标组织的。我最后采用的拆分原则是按决策域拆分。具体来说每个智能体负责一类完整的决策闭环从输入感知到最终输出中间不需要其他智能体介入就能完成。比如意图解析智能体负责把用户输入转成结构化的意图表示包括槽位填充、歧义消解、多轮上下文合并。规划智能体根据意图和当前环境状态生成一个可执行的任务计划决定调用哪些工具、按什么顺序调用。工具执行智能体负责实际调用外部 API 或本地函数处理超时、重试、结果格式化。结果校验智能体对工具返回的结果做一致性检查、格式校验、异常检测。异常恢复智能体当某个环节失败时决定是重试、降级还是回滚。这五个智能体各自有独立的决策逻辑但它们之间又需要传递状态。比如规划智能体需要知道意图解析的结果工具执行智能体需要知道规划智能体给出的调用参数。2.2 边界划分的三个硬性标准在划分边界的时候我给自己定了三条硬性标准后来证明非常有用第一条一个智能体内部的状态变更不能依赖另一个智能体的内部状态。换句话说智能体之间只能通过明确定义的消息来通信不能直接读对方的数据库或内存。这条标准逼着我把所有跨智能体的数据依赖都显式化虽然前期麻烦但后期排查问题的时候省了大事。第二条每个智能体必须能独立启动和停止不影响其他智能体的正常运行。这意味着智能体之间不能有强启动依赖。比如工具执行智能体启动的时候不需要等规划智能体先启动。它们通过消息总线异步通信谁先谁后都行。第三条单个智能体的故障不能导致整个集群不可用。这条标准直接决定了后面的故障隔离策略。如果一个智能体挂了其他智能体应该能感知到并且有降级方案而不是跟着一起挂。2.3 边界划分的常见坑这里分享一个我踩过的坑。最开始我把“意图解析”和“规划”放在同一个智能体里理由是它们逻辑上很接近放在一起可以减少一次消息传递。结果上线后发现意图解析的负载波动很大高峰期 CPU 跑满导致规划逻辑也跟着变慢。而规划逻辑本身并不需要那么高的计算资源被意图解析拖累了。后来我把它们拆成两个独立的智能体意图解析单独扩容规划智能体保持少量实例问题就解决了。这个教训是不要因为逻辑上接近就把它们放在一起要看它们的资源特征和负载模式是否一致。另一个坑是边界划得太细。我一开始把“工具选择”和“参数填充”也拆成了两个智能体结果消息传递的开销比实际计算还大。后来合并成一个“工具执行智能体”内部用同步调用完成选择加填充效率反而更高。所以拆分的粒度要适中不是越细越好。3. 协调机制没有中心调度它们怎么知道该找谁3.1 消息总线的选型与踩坑拆成集群之后第一个要解决的问题就是智能体之间怎么通信。我评估了三种方案方案优点缺点适用场景直接 RPC 调用延迟低、实现简单强耦合、故障传播快智能体数量少、调用关系固定中心消息队列解耦、支持异步中心节点成为瓶颈中等规模、允许一定延迟分布式消息总线高可用、可扩展运维复杂、一致性难保证大规模、高吞吐场景最后我选了第三种但做了一些简化。没有用完整的分布式消息总线而是基于发布订阅模式自己搭了一套轻量级的消息层。每个智能体启动时向注册中心登记自己的订阅主题消息发送方只需要把消息发到对应主题不需要知道具体有哪些订阅者。这里有个关键设计消息总线只负责传递消息不负责保证消息的顺序和恰好一次投递。顺序和幂等性由每个智能体自己保证。为什么这么设计因为如果消息总线要保证全局顺序那它自己就变成了一个中心化的瓶颈违背了“主权智能体”的初衷。3.2 智能体之间的三种通信模式在实际运行中智能体之间的通信可以归纳为三种模式第一种请求-响应模式。一个智能体发消息给另一个智能体然后等待回复。比如规划智能体向工具执行智能体发送调用请求然后等待执行结果。这种模式用同步消息实现但设置了超时时间超时后走异常恢复流程。第二种事件广播模式。一个智能体发出事件所有订阅了该事件的智能体都会收到。比如“任务完成”事件结果校验智能体和异常恢复智能体都会订阅。这种模式用异步消息实现发送方不等待回复。第三种状态同步模式。智能体之间需要共享一些全局状态比如当前任务的整体进度、已消耗的资源配额。这种状态通过一个轻量的共享存储来同步每个智能体定期拉取或订阅变更通知。这三种模式在实际系统中是混合使用的。一个典型的任务链路可能是意图解析智能体发出“意图解析完成”事件广播模式规划智能体收到后开始规划然后向工具执行智能体发送调用请求请求-响应模式同时把规划状态写入共享存储状态同步模式。3.3 消息格式的设计细节消息格式的设计直接影响到系统的可维护性。我最后采用的格式是这样的{ message_id: 唯一标识, correlation_id: 关联 ID用于追踪同一任务链路, source_agent: 发送方智能体标识, target_topic: 目标主题, timestamp: 发送时间戳, payload: { type: 消息类型, data: 实际数据 }, metadata: { priority: 优先级, ttl: 存活时间, retry_count: 重试次数 } }其中correlation_id是最重要的字段。一个用户请求可能触发几十条消息分布在不同的智能体之间。有了correlation_id我可以在日志系统里把整条链路串起来排查问题的时候非常方便。ttl字段也很关键。有些消息如果超过一定时间还没被处理就说明下游智能体可能出问题了这时候应该触发异常恢复而不是让消息一直堆在队列里。4. 状态管理每个智能体怎么记住自己该记的东西4.1 有状态与无状态的混合策略智能体系统和传统无状态服务最大的区别就是智能体是有状态的。意图解析智能体需要记住多轮对话的上下文规划智能体需要记住当前任务的执行进度工具执行智能体需要记住哪些调用已经完成、哪些还在进行中。但把所有状态都放在智能体内存里是不行的因为智能体可能会重启、扩容、迁移。所以我的策略是热状态放内存温状态放本地缓存冷状态放共享存储。热状态是当前正在处理的任务状态访问频率极高放在智能体进程的内存里用 LRU 缓存管理。温状态是最近一段时间内处理过的任务状态访问频率中等放在本地磁盘的嵌入式数据库里。冷状态是历史任务状态访问频率低放在共享的对象存储里需要的时候再加载。这个策略的关键在于状态的迁移时机。当一个任务从“进行中”变成“已完成”它的状态就从热状态变成温状态再过一段时间变成冷状态。迁移过程是异步的不阻塞主流程。4.2 状态一致性怎么保证拆成集群之后状态一致性是最头疼的问题。比如规划智能体认为任务已经进入“执行中”阶段但工具执行智能体还没收到调用请求这时候如果用户查询任务状态应该返回什么我的解决方案是引入一个状态版本号机制。每个任务有一个全局版本号任何智能体修改任务状态时都必须带上当前版本号并且版本号只能递增。如果两个智能体同时修改同一个任务版本号小的那个会被拒绝需要重新读取最新状态后再修改。这个机制类似于乐观锁但比数据库的乐观锁更轻量因为状态存储在内存里版本号比较是纯内存操作开销很小。另外对于跨智能体的状态同步我采用了最终一致性而不是强一致性。也就是说允许短时间内不同智能体看到的状态不一致但保证在一定时间窗口内会收敛到一致。这个时间窗口我设置的是 500 毫秒实测下来用户完全感知不到。4.3 状态恢复的实操步骤智能体重启后怎么恢复状态这是实际运维中经常遇到的问题。我的做法是智能体启动时先从共享存储加载自己的元数据包括上次处理到哪个任务、当前有哪些进行中的任务。然后向消息总线发送“智能体上线”事件其他智能体会把与该智能体相关的未完成消息重新投递过来。智能体收到这些消息后根据消息中的correlation_id从温状态存储中加载对应的任务状态继续处理。如果温状态存储中找不到对应的任务状态说明该任务已经超时或被其他智能体接管智能体会发送“任务状态查询”消息等待其他智能体回复。这套恢复流程实测下来一个智能体从重启到完全恢复服务平均需要 3 到 5 秒。对于大多数场景来说这个时间是可以接受的。5. 故障隔离一个智能体挂了怎么不让整个集群陪葬5.1 故障传播的三种路径在单体架构里一个模块出问题整个进程都会受影响。拆成集群之后理论上故障应该被隔离在单个智能体内。但实际运行中我发现故障还是会通过三种路径传播第一种消息积压。一个智能体处理变慢它订阅的主题消息就会积压。如果上游智能体不感知下游的积压情况继续往这个主题发消息积压会越来越严重最终导致消息总线内存溢出。第二种资源竞争。多个智能体跑在同一台机器上一个智能体内存泄漏会导致其他智能体被 OOM Killer 杀掉。或者一个智能体疯狂写磁盘把 IO 打满其他智能体的读写也受影响。第三种级联超时。智能体 A 调用智能体 BB 因为某种原因变慢A 等待超时后重试重试又超时A 的线程池被占满A 也开始变慢。如果 A 的上游还有智能体 C故障就会继续向上传播。5.2 针对性的隔离策略针对这三种传播路径我分别设计了隔离策略针对消息积压每个主题设置最大积压阈值超过阈值后消息总线会拒绝新的消息并向发送方返回“背压”信号。发送方收到背压信号后可以选择降级、排队或者直接返回错误。同时智能体在处理消息时会定期检查自己的积压情况如果积压过多会主动降低处理速度避免把下游压垮。针对资源竞争每个智能体跑在独立的容器里设置 CPU 和内存配额。容器之间通过 cgroup 隔离一个智能体内存泄漏不会影响其他智能体。另外智能体内部也做了内存使用监控超过阈值会主动触发 GC 或者重启。针对级联超时引入了熔断器机制。当智能体 A 调用智能体 B 的失败率超过一定阈值时熔断器打开A 不再直接调用 B而是走降级逻辑。熔断器打开一段时间后会进入半开状态允许少量请求通过如果这些请求成功熔断器关闭恢复正常调用。5.3 故障排查的完整链路这里分享一个真实的故障排查案例。某天下午监控系统报警任务平均延迟从 400 毫秒涨到了 3 秒。我按照下面的链路一步步排查看整体指标先看消息总线的积压情况发现“工具执行”主题的积压量在持续增长其他主题正常。定位到具体智能体工具执行智能体有 8 个实例逐个查看它们的处理速率发现其中 2 个实例的处理速率明显低于其他实例。查看实例日志登录到这两个实例发现日志里有大量“等待外部 API 响应超时”的记录。原来是它们调用的某个外部服务变慢了。确认外部服务状态联系外部服务的负责人确认对方确实在做扩容部分请求会超时。临时处理把这两个实例下线让其他实例接管流量。同时调整工具执行智能体的超时时间从 5 秒降到 2 秒避免长时间等待。长期修复给工具执行智能体加上熔断器当外部服务失败率超过阈值时自动降级到备用方案。整个排查过程大概用了 15 分钟如果没有这套隔离和监控机制可能要花几个小时才能定位到问题。6. 改造后的实测数据与经验总结6.1 性能对比改造前后的关键指标对比如下指标改造前改造后变化平均延迟1.2 秒380 毫秒下降 68%P99 延迟2.1 秒480 毫秒下降 77%最大吞吐量800 QPS2800 QPS提升 250%部署时间15 分钟2 分钟下降 87%故障恢复时间30 分钟以上3 到 5 秒下降 99%这些数据是在相同的硬件资源下测得的。改造后并没有增加机器只是把原来的单体进程拆成了多个智能体容器资源利用率反而更高了。6.2 几条用血泪换来的经验第一条不要为了拆而拆。拆分是有成本的消息传递、状态同步、故障排查都比单体复杂。如果系统规模不大单体架构反而是更优选择。我这次改造是因为日请求量已经到了几十万单体确实撑不住了。第二条消息格式要尽早定好。我一开始消息格式设计得太随意后来加字段、改字段名导致上下游智能体不兼容不得不做了一次全量升级。如果一开始就设计得规范一些后面会省很多事。第三条监控要跟上。拆成集群之后问题定位比单体难得多。如果没有完善的监控和日志系统一个故障可能要排查很久。我在改造的同时搭了一套基于correlation_id的全链路追踪系统这是最值得投入的部分。第四条降级方案要提前设计。不是所有智能体都能保证 100% 可用。当某个智能体不可用时系统应该能自动降级而不是直接报错。比如工具执行智能体不可用时可以返回缓存结果或者提示用户稍后重试。第五条定期做故障演练。我每个月会随机杀掉一个智能体实例观察系统是否能自动恢复。这种演练能发现很多平时注意不到的问题比如某个智能体的恢复流程有 bug或者某个降级逻辑没有生效。6.3 后续还可以优化的方向目前这套集群已经稳定运行了几个月但还有一些可以优化的地方。比如智能体的自动扩缩容目前是基于 CPU 使用率的但有些智能体的瓶颈不在 CPU 而在 IO 或内存后续可以引入更细粒度的扩缩容指标。另外智能体之间的消息传递目前是明文传输的后续可以考虑加上轻量级的加密和认证机制。还有一个比较有意思的方向是让智能体具备一定的“学习”能力。比如工具执行智能体可以根据历史调用记录自动调整超时时间和重试策略。这个目前还在实验阶段等有成熟结果了再单独写一篇分享。整个改造过程大概持续了三个月中间踩了不少坑但也积累了很多经验。如果你也在做类似的架构改造希望这篇手记能帮你少走一些弯路。