1. 故障现场Agent 还没开始干活内存先爆了那段时间我们正在调一个意图解析类 Agent简单说就是让 Agent 接收用户的一句话比如“帮我查一下华东区上个月所有失败订单的物流状态顺便把超过三天的标记出来”然后解析成结构化参数再交给下游工具去执行。单看需求不算复杂所以上线前压测时谁也没想到内存会先出问题。现象很奇怪Agent 刚被调用还没来得及走到任何外部工具调用进程内存就一路飙高紧接着触发 OOM实例被系统杀掉并自动重启。第一次看监控时我以为是代码写了个死循环或者解析结果被存进了某个静态集合里没清理。结果排查下来整个 Agent 的执行链路比想象中简单问题根本不是“内存泄漏”而是正则表达式在特定输入下发生了灾难性回溯把 CPU 和堆内存一起拖垮了。这篇文章我会完整复盘这次故障的定位过程、根因分析、修复方案以及我们最终在 Zod 版本选型上做的对照和取舍。如果你是做 Agent 开发、或是在用 Zod 做 JSON Schema 校验、又或者只是写正则时踩过内存/性能坑的人这篇内容应该能帮你少走不少弯路。1.1 现象描述从正常到崩溃只有几分钟故障是从一次线上小流量灰度开始的。我们有一个 Agent 入口服务接收用户文本后先做预处理再通过 Zod 对解析出来的中间结果做结构校验校验通过后才交给后续的意图执行器。灰度刚开始一切正常大约几分钟后监控页面上内存使用率突然从 40% 冲到 95%紧接着服务不可用。我们当时的监控粒度是分钟级所以第一个告警其实是“存活探针失败”。等到我们打开容器控制台看到的场景是进程已经重启过一轮新实例正在接收流量但内存依然以肉眼可见的速度上涨。再翻 OOM 之前的监控曲线内存曲线几乎是一条垂直向上的线这种形态和常规的“缓慢泄漏”完全不同更像是某个请求进来后瞬间吃掉了大量内存。1.2 影响范围不是“等一下就好”的事情这类故障最让人头疼的点在于它不像磁盘满了或者连接池耗尽那样有一个缓慢的恶化过程。一旦某个输入触发了问题路径进程的内存会在几秒内被打满紧接着触发 OOM-Killer整个实例被强杀。如果负载均衡策略没有及时把流量切走新起来的热身实例又会被同一个输入再次打爆形成连环 OOM。当天受影响的不只是 Agent 网关本身下游好几个依赖这个服务的任务都跟着失败。更麻烦的是因为实例反复重启大量的重复请求会重新进入队列消息积压一度到了一个很夸张的程度。我们后来在复盘时统计从第一次异常到我们手动切走流量实际窗口只有不到十分钟但在这十分钟里已经堆积了数万条待处理消息。这类故障让人印象深刻的从来不是内存本身而是它在极短时间内撬动了整条链路。2. 问题定位从指标异常到堆外内存失控2.1 初步排查先排除“看起来像是元凶”的选项遇到 OOM多数人的第一反应是堆太小了调大堆内存就行。我们在首次处置时也差点走这条路但经验告诉我先别急着加参数至少要搞清楚内存被谁吃掉了。当时我们做了三个快速动作拉取 OOM 前的完整线程栈也就是在 /proc 和日志里找 jstack 快照打开 GC 日志看 Full GC 的频率和耗时检查是否有大对象分配走的 JVM 参数是-XX:PrintGCDetails加-XX:HeapDumpOnOutOfMemoryError。线程栈和 GC 日志一对照问题就变得很有意思GC 日志显示 Old Gen 在最后几个 Full GC 周期内呈阶梯状上涨每次回收量很小但垃圾量极大。这种表现通常不是“对象被持续引用不释放”而是有大量短期存活对象在疯狂创建。再配合线程栈几乎所有工作线程都卡在同一个地方java.util.regex.Matcher.find()和Pattern$GroupCurly相关的栈帧上。到这里基本就可以把“无效引用导致泄漏”这个猜测排除了真正的嫌疑集中到了正则匹配上。2.2 JVM 内存模型与这次故障的关系聊 JVM 内存模型很多讲理论的文档喜欢从堆、栈、方法区开始逐个介绍。实际排障时我更关心的是这次爆的内存到底属于哪一块。从监控看容器内存持续上涨进程 RSS 飙高而 jmap 显示堆内 Old Gen 占了绝大部分说明问题发生在 Java 堆内而不是堆外或元空间。JVM 内存模型里有几个关键区域堆内存存放对象实例线程栈存放栈帧和局部变量元空间存放类元数据和常量还有一部分堆外内存用于 DirectBuffer 等场景。Agent 服务里我们并没有大量使用 DirectBuffer所以一开始就没有优先怀疑堆外。真正的问题是在堆内当正则匹配进入灾难性回溯时JVM 需要不断为字符串匹配创建中间对象和堆栈状态数量级不是几百几千而是几百万甚至上亿次级别。这也是为什么后来很多人问我“要不要换一个内存分配器”时我有点哭笑不得。问题不是分配器不够好而是你让匹配引擎在一段恶意的输入上做了海量的无用功换再好的分配器也救不了。2.3 真凶锁定Zod 校验引发的正则风暴线程栈里还显示卡住的代码最终落在了 Zod 的校验逻辑里。我们用的是 zod 3.x 版本在 schema 里对某个文本字段定义了一个正则校验用来匹配“业务关键词组合”就是这个自定义正则把整个 Agent 拖垮的。这里必须强调一下不是 Zod 本身有内存泄漏。Zod 只是一个校验库它按照我们的 schema 定义去执行regex执行正则时碰上了灾难性回溯CPU 被打满GC 回收能力跟不上内存自然就爆了。换句话说真正的元凶不是 Agent 框架也不是 Zod而是那段带有嵌套量词的正则表达式。不过 Zod 在本次事故里也扮演了一个放大器角色因为每个请求进来都要对解析结果做校验输入稍长一点校验次数一多回溯开销就被无限放大最终压垮了整个进程。3. 根因复盘为什么校验一个表单能把内存打爆3.1 意图解析类 Agent 的输入特征意图解析类 Agent 和普通接口不太一样。普通接口通常有明确的字段边界比如用户名最长 20 个字符日期格式固定。但 Agent 处理的是自然语言用户可能很随意地输入一长串中英混合文本其中包含时间、地点、业务关键词、情绪词甚至粘贴了一些网页片段。这次触发故障的输入就是一个典型例子用户为了“精准描述意图”把一整个表格里的内容直接粘贴了进来里面包含了大量的制表符、换行、中英文标点以及非常多的“方案”“路线”这类和意图词高度相关的词。而我们的校验正则恰好设计得比较复杂目的是判断这段文本里是否包含符合要求的关键词组合。如果输入很短这个正则会非常高效。但输入一旦超过某个长度并且含有大量可重复匹配的前缀正则引擎就会陷入一种指数级的尝试路径。3.2 超长字符串 灾难性回溯 内存爆炸先看一个经典的灾难性回溯正则示例/^([a-zA-Z])*\d$/这个正则看起来没什么问题它想表达“以若干个字母开头最后以数字结尾”。但问题是([a-zA-Z])*这一层嵌套量词让匹配引擎在遇到不满足条件的长字符串时必须反复尝试不同的划分方式。比如输入是aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaX前面有几十个a最后是一个X不是数字。正则在匹配到末尾时失败但引擎不会立刻退出而是会回溯把前面几十个a重新拆分成不同的分组组合然后逐一尝试。这种拆分路径的数量随着a的数量呈指数级增长最终导致 CPU 被打满内存被疯狂消耗。我们业务里的正则是类似形态的关键词匹配比如/((方案|策略|路线|规划){1,3}[,、]?){2,}/这个式子想表达“匹配连续出现的关键词组合”但同样存在嵌套量词问题。当输入里充斥着大量“方案”“策略”“路线”等词而用户又在中间夹了特殊字符时正则引擎就会陷入大量回溯。3.3 复现实验与量化数据为了确认判断我用事故现场的类型文本在本地做了复现。为了防止把整个实验搞挂我加了超时控制用一个小脚本统计匹配耗时和内存占用const regex /((方案|策略|路线|规划){1,3}[,、]?){2,}/; const inputs { len64: 方案策略路线规划.repeat(4), len128: 方案策略路线规划.repeat(8), len256: 方案策略路线规划.repeat(16), }; for (const [name, input] of Object.entries(inputs)) { const start performance.now(); try { regex.test(input); console.log(name, ${(performance.now() - start).toFixed(2)}ms); } catch (e) { console.log(name, timeout or error, e.message); } }单次匹配的耗时可能不是最直观的真正吓人的是叠加了 Agent 服务的并发请求之后。我简单跑了一组数据输入长度字符单次匹配耗时匹配过程中堆内存增量是否触发 Full GC64约 20ms轻微否128约 900ms明显否256约 30s大量临时对象频繁512超过 5 分钟未返回堆内存几近打满持续这个数据说明了一个问题这条正则在输入长度不超过 64 时还能用一旦超过 128 就变成了服务级灾难。而用户在 Agent 对话框里粘贴一长段文字是再正常不过的事所以这其实是一个必然会在某个时刻爆发的隐患不是运气不好碰上的偶发问题。4. 方案设计与解决路径4.1 方案对比不是所有“快”都适合线上故障确认后我们内部开了个小会讨论了几种修复方向。当时提过的方案有方案优点缺点结论调大 JVM 堆内存改造成本低一行参数的事只是延后 OOM不能解决 CPU 被打满的问题不采用限制输入长度简单有效能挡住最极端的输入可能影响正常用户的超长输入作为辅助手段重写正则消除嵌套量词从根上解决问题需要理解业务逻辑重新设计校验核心方案升级 Zod 版本可能有性能提升版本变更存在兼容成本作为配套方案最终我们的结论是先做输入边界控制防止极端请求进入核心链路再重写有问题的正则最后评估 Zod 升级的必要性。4.2 最终修复策略修复动作分了三步走。第一步在 Agent 网关入口处对原始输入长度做限制。我们对用户的自然语言输入设置了 500 个字符的上限超过就直接走“请精简描述”的引导流程不再进入解析和校验环节。这一招虽然朴素但能非常有效地把灾难性回溯的触发条件扼杀在入口。第二步重写正则。我们的目标不是“让这段正则更快”而是“让这段正则根本不存在回溯爆炸的可能性”。我建议所有写正则的人都记住一句话嵌套量词 长输入 定时炸弹。改写时我放弃了“用一个正则同时表达多个关键词组合”的思路改为先做关键词拆分再用多个独立的简单正则分别做匹配const keywords [方案, 策略, 路线, 规划]; const hasKeyword keywords.some((kw) input.includes(kw));这样写虽然看起来不够“一行流”但每一个子判断都是线性复杂度输入再长也不会指数爆炸。配合一个简单的计数规则就能实现原来复杂的语义判断。第三步把正则检查做进 CI。我们引入了safe-regex和regexp-tree这类工具在代码提交阶段自动扫描是否有疑似灾难性回溯的正则。这一步非常推荐因为人眼很难判断一个复杂正则是否安全机器可以做到。4.3 Zod 版本对照与实践选型建议在修复正则的同时我们也研究了 Zod 版本升级的影响。当时线上用的是zod3.22.x而zod4.x已经发布了一段时间社区反馈在解析性能和错误信息上有明显改进。为了确定升级是否值得我专门做了一次版本对照测试。测试对象是一个从 Agent 解析结果里抽取字段的 schema类似这样const toolSchema z.object({ action: z.string(), searchText: z.string(), filters: z.array(z.string()).optional(), });我分别用 v3 和 v4 各跑了一万次解析数据如下对比项zod3.22.4zod4.x解析速度万次耗时约 3.2s约 2.1s错误路径精度只能到字段名可以定位到具体路径和类型空字符串处理z.string().min(1)需要自己处理空白符内置更严格的字符串控制能力自定义错误信息支持但写法繁琐更简洁内置多语言能力标准 schema 协议不支持支持从 JSON Schema 自动生成 schema从结果上看zod4 在性能和开发体验上确实有优势。但我们并没有把它当作唯一的修复手段原因也很简单正则的灾难性回溯在 jvm 里是在正则引擎层面发生的zod 升级不会消除回溯本身。它只能让校验部分的整体开销低一点瓶颈该爆还是会爆。如果要给 Zod 版本选型一个建议我的经验是新项目直接选zod4.x不用犹豫老项目如果结构简单字段不多升级成本其实可控建议优先升级如果老项目里有大量复杂的superRefine和自定义错误处理升级前需要做好行为对照因为 v4 对字符串的默认行为比 v3 更严格空白字符串、空数组这类边界处理可能和原来不一样。5. 从一次爆内存事故提炼 Agent 稳定性 checklist5.1 故障复盘方法论别只看 OOM 本身这次事故让我最大的体会是复盘故障时不要只盯着“内存爆了”这个最终现象要往上游追问“是哪段逻辑让 CPU 忙到连 GC 都救不回来”。OOM 只是压垮骆驼的最后一根稻草真正的问题是正则匹配把 CPU 资源耗尽导致 GC 线程得不到足够的执行时间最终堆里的垃圾对象越积越多。如果当时我们只做“加内存”和“重启实例”这个故障大概率会在某个流量高峰重新出现而且可能以更严重的形态出现。现在我们在复盘任何线上故障时都有一个固定问题列表这个故障的触发输入是什么有没有办法在入口处就能拒绝哪一段代码的消耗是“超线性”的是不是存在嵌套循环、嵌套正则、递归解析之类容易爆炸的写法监控能不能提前发现是等到进程 OOM 才发现还是能在内存升到 70% 的时候就给出告警有没有自动化手段可以在代码上线前拦截这类风险第四个问题尤其关键。平时我们很重视代码 review但对正则的 review 往往流于形式因为人很难直观看出一个正则是否安全。把safe-regex放进 CI 之后这个问题才算真正被制度化地解决了。5.2 可观测性建设让下一次故障更快暴露除了修复问题本身这次故障也暴露出我们在可观测性上的不足。当时的监控只能看到容器内存总使用率看不到堆内分代使用情况更看不到线程阻塞热点。如果早点在 JVM 层面加上jvm.memory.used、jvm.gc.pause这类指标我们至少能在内存到 80% 前收到预警而不是等到进程被杀才反应过来。我现在给所有 Agent 类服务配置监控时都会强制加上这几项JVM 堆内存使用曲线以及 Old Gen 的增速Full GC 的次数和单次耗时工作线程的 BLOCKED/RUNNABLE 状态占比正则匹配、解析校验等关键代码路径的耗时分位数。其中第四点其实很关键。普通接口耗时如果偶发变长大家第一反应是数据库慢了或下游超时了但在 Agent 服务里解析和校验本身的耗时也可能成为主要瓶颈。这次故障里正则匹配耗时从 20ms 暴涨到几十秒如果当时有分位数监控一个 P99 异常就能让我们更快定位到问题代码而不是等 OOM 来帮我们报警。5.3 后续扩展Agent 稳定性清单这次复盘完成后我把经验整理成了一份内部 checklist每次发布新的 Agent 能力时都会过一遍所有用户输入必须有长度和内容边界不能直接进入解析链路正则优先用“多次简单匹配”代替“一次复杂匹配”禁止嵌套量词任何校验库升级前都要做行为对照测试不能只看 benchmark 数字JVM 服务必须具备堆内存分代、GC 耗时和线程热点监控CI 中加入 ReDoS 扫描从源头拦截有风险的正则。最后再分享一个小技巧如果你在排查一个“看起来像内存泄漏、但重启后马上恢复”的问题先别急着分析引用链去看看线程栈里有没有线程长时间卡在Matcher、Pattern或者String.split附近。正则灾难性回溯的表现和内存泄漏非常像但解法完全不同。前者需要重写表达式后者才需要分析对象引用。搞错方向的话排查两天可能都摸不到门。回到标题那句话Agent 还没开始干活内存就爆了。这句话在故障当天听起来像玩笑后来再看它其实精准地指出了一个问题——Agent 类应用的复杂度往往不在“结果生成”阶段而是在“输入理解与校验”这个看似不起眼的环节。输入是不可控的校验逻辑写得不够鲁棒再漂亮的下游编排都会瞬间崩塌。