企业官网建设流程全解析

开发 Agent Platform，踩了一次真实的线上超时故障

做 Agent Platform 的时候，最怕的不是功能不够，而是线上莫名其妙地慢下来。那天下午三点，监控大屏的响应曲线突然像心电图一样抖起来，核心接口的 P99 延迟从 120ms 一路飙到 18 秒，错误率从 0.1% 冲到 15%。那是我第一次真正意义上在 Agent 平台这类偏“重调度”的系统里，正面遭遇超时故障。排查完才发现，根子不在数据库，也不在网络，而是在一段看起来人畜无害的上下文拼接逻辑里。这篇文章就是把当时完整的排查过程、根因分析、修复方案以及事后复盘整理出来，给正在做或者准备做 Agent 类平台的同学一个参考。

1. Agent Platform 的整体设计与架构背景

1.1 平台定位与核心功能拆解

先说下这个平台是干什么的。Agent Platform 本质上是一个面向多智能体协作场景的调度与运行平台，上层接业务方，下层接大模型 API 和各种企业内部工具。核心功能可以拆成四个模块：Agent 生命周期管理、任务编排引擎、工具注册与路由、上下文持久化与快照。

生命周期管理负责 Agent 的创建、启动、暂停和销毁，每个 Agent 有独立的运行空间和沙箱约束。任务编排引擎是最核心的模块，它要把用户的一句话拆分成多个子任务，然后按照依赖关系分发给不同的 Agent 执行。工具注册与路由解决的是“这个 Agent 该用哪个工具”的问题，比如查询订单状态和查询物流轨迹，底层调的是两套完全不同的服务，路由层要做参数转换和鉴权透传。上下文持久化模块则负责记录每一轮对话和每一次工具调用的入参、出参，方便随时回溯和续跑。

这个平台的调用链路有点长：用户请求先打到 API Gateway，然后到 Orchestrator 做意图识别和任务拆分，再分发到 Agent Runtime，Agent Runtime 在执行过程中要不断和上下文服务、工具路由、模型代理交互。节点一多，任何一个环节抖动都会被放大。当时在架构选型时就考虑过这个风险，但还是低估了上下文模块在高并发下的性能退化速度。

1.2 技术选型背后的取舍逻辑

技术栈上，主体用的是 Java 17 + Spring Boot 3，RPC 框架选了 gRPC，消息异步化用的 RSocket，Agent 之间的事件通知走了内存消息总线。存储方面，对话消息和历史快照放在 MongoDB，向量检索部分用了一个开源的向量数据库。之所以选 Java 而不是 Go 或者 Python，一个重要原因是团队对 JVM 生态的监控链更熟悉，而且像 Flowable 这类成熟的流程引擎可以直接复用，任务编排的基础功能不用重复造轮子。

分布式追踪接的是 OpenTelemetry，日志统一走 ELK，指标用 Prometheus + Grafana。这套组合在常规业务系统里已经跑得很稳，但 Agent 平台有个特点：单次请求的处理时间远长于普通 HTTP 接口。一次任务编排可能涉及上百次模型调用和工具调用，单请求耗时从几秒到几十秒都很正常。这意味着超时控制不能用传统的“一刀切”策略，必须区分“交互式请求”和“后台任务”两条链路分别设计。当时在架构文档里写得很清楚，但实际落地时，交互式链路上还是混入了不少“重逻辑”。

2. 线上超时故障的完整排障过程

2.1 故障现象与报警细节

故障发生的时间点是在下午三点左右，从监控看，崩溃不是瞬间的，而是花了大约 20 分钟慢慢恶化。最开始是某个特定路由的 P99 延迟从 120ms 涨到 1.2s，我们当时以为是偶发抖动，没太在意。结果 10 分钟后，错误率开始抬头，接着整个交互式链路都开始超时，上游网关大量返回 504。报警群瞬间活跃起来，一堆人开始刷屏问是不是数据库出问题了。

我先做了三件事：第一，看 Grafana 面板确认影响范围，排除了全局限流和机房网络问题；第二，查 ELK 日志里超时请求的分布特征；第三，看 JVM 监控，确认 GC 是否异常。印象很深的一个细节是，初步看下来 GC 表现还算健康，Full GC 没有明显的尖峰，堆内存使用率稳定在 60% 左右。CPU 却出现了异常，四核容器的 CPU 直接打满，而且是完全打满的那种。

CPU 打满但 GC 正常，这个组合很有迷惑性。在 Java 应用里，这种情况要么是死循环，要么是某种激烈的 CPU 自旋，要么是正则回溯，要么是序列化/拷贝开销爆炸。随后我通过 Arthas 的thread命令抓现场，发现大量线程阻塞在一个ContextSnapshotManager.createSnapshot方法上，而且线程状态为 RUNNABLE。用stack命令打印了几组线程栈，确认它们的调用路径完全一致，都是在执行上下文快照创建逻辑。

2.2 从服务链路排查到代码定位

拿到线程栈后，问题范围从“整个平台故障”缩小到了“上下文快照创建异常”。这时候我重新翻了一遍调用链追踪数据，发现超时请求全部集中在多轮对话续跑这个场景，特别是那些上下文数量超过 20 轮的 Agent 任务。看日志里的耗时分布，serializeContext和deepCopyMessages这两个子操作在单次请求里的耗时占比竟然超过了 80%。

为了进一步缩小范围，我在测试环境复现了场景：模拟一个 Agent 执行 30 轮工具调用，每轮写入 5 条消息，然后持续创建连续快照。压测结果显示，第 1 轮快照耗时只有 2ms，第 10 轮是 30ms，到第 20 轮直接跳到 900ms，第 30 轮到了 6 秒以上。这个曲线非常典型，几乎是指数级的上涨。看到这个曲线的时候我基本已经确定了根因方向：存在 O(n) 甚至 O(n²) 级别的复杂度爆炸，而且大概率是数据重复拷贝引起的。

随后我用 JProfiler 挂到测试环境，看createSnapshot方法的内部调用树。内存分配曲线里，byte[] 数组的分配量呈陡增趋势，字符串 char[] 也居高不下。点开堆栈追踪后，看到了一个具体的循环结构：每次创建快照都会遍历整个会话的完整消息列表，并且对每条消息执行一次 JSON 序列化，然后把这些序列化后的字节流再放进一个新的列表——也就是说，从第 1 轮到第 n 轮，每一轮产生的消息都会在后续每一轮被完整拷贝一遍，总工作量是 1 + 2 + ... + n 的累加，复杂度天然就是 O(n²)。

3. 根因剖析与故障背后的技术原理

3.1 问题代码的实际形态

简化还原后的问题代码如下，一段比较典型的“小步快跑但欠考虑”的代码：

public ContextSnapshot createSnapshot(String sessionId) { // 获取该会话的全部消息 List<ChatMessage> allMessages = messageRepository.findBySessionId(sessionId); // 深度拷贝一份，避免后续修改影响快照 List<ChatMessage> deepCopy = new ArrayList<>(); for (ChatMessage msg : allMessages) { ChatMessage copy = new ChatMessage( msg.getSessionId(), msg.getRole(), // 这里对 content 做了一次完整字符串拷贝 msg.getContent(), msg.getTimestamp(), // 又把工具调用的结果也拷贝了一份 msg.getToolCallResult() ); deepCopy.add(copy); } // 序列化成 JSON 存到快照表 String json = objectMapper.writeValueAsString(deepCopy); snapshotStore.save(new Snapshot(sessionId, json)); return new ContextSnapshot(sessionId, deepCopy); }

表面看这个函数没有明显死循环，也没有不合理的锁，但问题就出在“每次创建快照都全量拷贝所有历史消息”这行思路上。平台的产品需求里规定了“每个任务节点执行完成后要记录一份快照，用于流程回放和异常续跑”，这个需求本身没毛病，但当时的实现没做增量处理，导致每执行一个新节点，整个会话的上下文都会像拍全家福一样全部重新拷贝一遍。

如果只有 5 轮工具调用，容量差异还不明显。一旦 Agent 的流程里有循环推导、多轮自我纠错，或者一个任务拆成几十个子步骤，消息列表的长度就会快速膨胀。每个消息里除了用户输入、模型输出，还嵌入了工具返回的完整 JSON 数据，单条消息体积动辄几十 KB。当列表里有几百条消息时，每一次快照就要拷贝几百 MB 的临时对象，CPU 和内存都扛不住。

3.2 为什么这个场景特别容易触发超时

这个故障放在普通 CRUD 系统里可能永远不会发生，但在 Agent 平台里几乎是必然发生的，原因有三个特殊性。

第一个特殊性是“上下文无边界增长”。Agent 的执行模式不像普通 API 那样一次请求一次响应，它是多轮推理和多次工具调用的循环。很多 Agent 框架为了保持“记忆完整”，会把所有历史消息都塞进下一轮的上下文窗口，不做裁剪也不做摘要。产品上为了回放能力又要求每步快照。这两个需求叠加，实际上制造了一个无上限的累积结构。

第二个特殊性是“深度拷贝与序列化的成本被低估”。开发时容易把deepCopyMessages想成一个简单的列表遍历，觉得每轮多拷几百个对象无所谓。但实际运行时，每个对象里都嵌着大字符串和嵌套结构，浅拷贝和深拷贝的差距是数量级的。再加上用 Jackson 做序列化时，反射调用本身有额外开销，字段越多越明显。当时那台机器上，单次快照序列化 200 条消息的耗时已经超过 3 秒，这个时长在一些 RPC 框架里已经足够触发客户端超时。

第三个特殊性是“长请求加剧了连接池和线程池的占用”。Agent 平台的交互式链路本来线程持有时长就比其他系统长，如果其中 80% 的时间都浪费在 CPU 空转和重复拼接上，线程就长期卡在同一个方法里。线程没办法及时归还给 Tomcat 线程池，导致后续请求排队。排队的请求又在等线程，最终入口网关注入超时后开始重试，重试又带来更多请求，雪崩效应就出现了。

4. 修复方案、实施过程与效果验证

4.1 增量上下文与滑动窗口方案

修复思路不是简单地优化拷贝性能，而是从机制上消除重复劳动。第一步，把“全量快照”改成“增量快照 + 基础快照”。每个会话在首次执行时生成一份基础快照，后续每个节点只保存“基于上一个节点的差异数据”。这样单个快照的体积从几百 MB 降到几 KB，创建快照的工作量从 O(n²) 直接降到 O(1)。

第二步，引入“滑动窗口上下文管理”。模型调用时不再每次都拿全量历史消息，而是动态取出最近 W 条关键消息加上一个“前置摘要”。摘要由专门的压缩逻辑生成，比如用摘要模型把前面的长对话浓缩成 200 字以内的核心事实。这个策略在不改变用户可感知的语义质量的前提下，大幅压缩了每次模型请求的 payload 大小。

第三步，也是比较关键的一步，把“快照创建”从请求主链路里剥离出去。之前快照是在任务节点执行完毕时同步完成的，导致响应时间被快照耗时直接拉长。改造后，任务节点只负责把“需要持久化的增量数据”发到一个内存队列，由独立的后台线程异步落库。交互链路本身不再等待快照持久化完成，接口耗时一下子就降下来了。这里需要注意一个边界：异步化之后如何保证数据不丢？我当时的方案是把写队列的确认与节点状态机的“已提交”状态绑定，节点在持久化确认前不会推进到下一个状态，这样即使进程崩溃，也能从上一个已确认节点恢复。

4.2 线程池隔离与熔断降级兜底

机制上消除了重复拷贝，但操作上还需要增加一层防护，避免以后再出类似问题拖垮全局。当时我在 Agent Runtime 内部做了线程池隔离：策略编排、模型调用、工具调用、上下文处理各用独立的线程池，每个线程池的队列长度和最大线程数单独配置。

这个改造的思路和舱壁模式类似。以前所有任务共用 Tomcat 的工作线程，哪个环节出现性能劣化都会抢占公共资源。隔离之后，就算上下文模块再次出问题，也只会打满“上下文线程池”，模型调用和工具调用线程池还能继续处理请求。线程池隔离的代价是线程数量的增加，不能盲目贪大，我压测后得出的经验值是：模型调用池 8 线程、工具调用池 12 线程、上下文处理池 4 线程、编排主线程池 16 线程，整体线上观察下来 CPU 基线还降了 10%。

同时在工具路由层加了一层熔断器。熔断条件有两条：单工具调用的平均耗时超过 2 秒，或者错误率超过 20%。当熔断器打开后，后续请求直接返回一个降级提示，不再真正发起工具调用。熔断恢复采用半开策略，每 20 秒放 1 个探活请求，成功则逐步恢复流量。这个兜底让平台从“完全不可用”变成了“局部功能降级”，对业务的冲击小了很多。

4.3 压测结果与线上优化数据

修复完成后，我在测试环境重新跑了一遍相同的压测场景，优化前后的数据对比如下：

单个快照的创建耗时从最开始的 6 秒降到了 20 毫秒左右，快照存储的磁盘占用也从每会话 50MB 降到了 2MB。上线观察了一周，接口 P99 稳定在 400~800ms 区间，CPU 峰值从打满降到 35% 到 45% 之间，内存分配速率也明显回落。

这里有一个血泪教训必须单独说：任何优化上线前，都一定要回归验证“上下文恢复”这个能力。增量快照虽然写入快了，但恢复时需要把基础快照和所有增量数据合并成一个完整的上下文列表，这个合并逻辑如果写不好，很容易出现消息顺序错乱或者重复。我就在上线后的第二天发现某条 Agent 任务回放时把工具调用的返回结果贴到了用户消息之前，排查半天是因为增量数据里的 timestamp 精度不够，导致排序时把相同时间戳的消息排反了。后来把所有增量快照都增加了一个自增序号，用数据库的自增主键保证顺序，才彻底解决。

5. 常见问题排查速查表与避坑经验

5.1 Agent 平台超时故障排查速查表

这次故障之后，我总结了一张速查表，后续排查同类问题都是先对照这个表格做初步筛选，再决定要不要深入分析。

这些信号之间有重叠，所以最好把几个维度的数据交叉验证。比如线程阻塞等待和数据库连接池耗尽经常同时出现，只看线程栈容易误判为数据库慢查询，其实根因是连接池最大连接数配小了，真正卡住的点是获取连接时的排队等待。

5.2 从这次事故里提炼的三条防范策略

第一，Agent 平台的上下文模块必须单独进行“规模压测”。普通接口用 1000 并发压测就行，但上下文模块要专门压“单请求内迭代次数”。我建议最少覆盖三种模式：单 Agent 30 轮工具调用、双 Agent 协作 20 轮对话、异常恢复场景下 10 次连续快照。这三种模式跑一遍，基本能暴露大多数性能和正确性问题。

第二，超时配置不能全局统一。Agent 平台要区分“短任务”和“长任务”。短任务比如单轮意图识别，超时控制在 1 秒以内；长任务比如多 Agent 协作执行一个复杂的分析报告，可能要几分钟。如果所有请求都用同一个超时时间，短任务会被长任务拖慢重试频率，长任务又容易因为某个下游组件偶发抖动而提前失败。正确做法是在 API Gateway 层按路由分组分别配置超时时间，在 gRPC 调用链上再用带超时传递的 deadline 机制，逐层传递剩余时间，避免每一层都重置超时时钟。

第三，核心链路上的“能力增强”一定要做开关控制。比如上下文压缩、摘要生成、快照异步化这些优化，上线时默认关闭，通过配置中心按 Agent 类型逐步放量。当时我们把上下文压缩功能先在内部测试 Agent 上跑了一周，确认没有影响多轮对话的语义完整性，才逐步放量到生产，整个过程非常稳。

6. 后续规划与个人复盘心得

这次故障之后，我对 Agent 平台的设计有了更强的敬畏心。回头去看，前期的架构评审并不是没人提出过“上下文全量拷贝”的风险，但当时大家普遍认为“单次请求数据量不大、实现简单优先”，把这个问题压后处理了。现在我的观点是，在 Agent 类系统里，凡是和“历史”“累计”“回放”挂钩的逻辑，都要在第一天就按增量思维来设计，因为 Agent 的执行轮数天然是无上限的，它比普通系统更容易踩中复杂度爆炸的陷阱。

我个人在实际操作中最深的一点体会是：故障排查时，宁可先多抓几份线程栈，也不要急着翻日志猜原因。当时如果只盯着监控面板和日志关键词，我可能会在数据库慢查询和网络抖动之间来回打转很久。Arthas 在线打印线程栈这个动作，直接把排查时间从小时级压缩到分钟级。现在我已经养成了习惯，任何 Java 服务上线前都会准备好 Arthas 的启动脚本和常用命令手册，线上出问题第一时间就能介入。

最后再分享一个小技巧：如果你也要做 Agent 平台，建议在开发环境就构造一个“压力火柴人”——一个专门用于搅乱系统的测试 Agent，它会执行超长循环、调用超大数据量的工具、在上下文里塞满重复文本。每次发版前让这个火柴人跑一遍，它比任何静态代码审查都更能暴露系统的性能极限。我这次故障如果能早一周引入这种测试智能体，很可能在上线前就已经把问题抓出来了。希望这篇复盘能帮你在 Agent 平台的建设中少踩一次类似的坑。