多Agent运行时内存失控排查与优雅熔断实践

一、案发现场：32GB 机器上凭空蒸发的 100 多 GB

那是一个普通工作日的上午十点，一台 32GB 内存的开发工作站正“双线作战”：屏幕一侧，一个自动化演练 Agent 正在终端里执行流程编排任务；另一侧，一个视频后期 Agent 正对演示录像逐帧识别画面文字，并将敏感邮箱与路径信息打上马赛克。

突然，界面冻结、风扇狂转，图形系统弹出所有桌面用户最不愿看到的那行字：「系统已没有可用的应用程序内存」。强制退出面板中，负责管理多个终端窗口的宿主程序赫然排在第一位，后面跟着一个离谱的数字：100 多 GB。

第一时间关掉其他无关程序，无济于事。几秒后，系统直接出手，将宿主程序连同它托管的十几个终端会话、两组正在工作的 AI、总控调度进程一并终结。任务进度、会话状态，瞬间归零。

团队的第一反应和大多数人一样：宿主软件存在严重内存泄漏，得连夜修。但当下午翻出系统内核的内存压力诊断日志后，真实数据让所有人目瞪口呆：

进程	内存读数	真实身份
宿主程序本体	不到 1GB（峰值仅 1.25GB）	规规矩矩的终端管理进程
7 个脚本语言解释器子进程	每个约 23GB	真正干坏事的“临时工”
合计虚拟内存	约 160GB	远超 32GB 物理内存

宿主本体一滴内存都没漏。真凶，是它代为拉起的一群 Agent 子进程。

二、复盘：为什么“看到的凶手”不是真凶

2.1 监控只盯着“家长”，看不见“孩子”

多数本地监控与告警方案默认只观察主进程或应用本体。而 Agent 运行时的典型架构恰恰是“一个轻量宿主 + N 个解释器子进程”：宿主负责窗口管理、任务分发与进程编排，真正的计算全部发生在子进程里。用户在进程面板里看到的、系统在强制退出列表里展示的，往往只有宿主一个名字。于是子进程闯的祸，账全部记在家长头上——这是多 Agent 故障排查中最经典的第一重误判。

2.2 内存有三本账：虚拟、驻留与换页

• 虚拟内存（地址空间）：进程申请的地址空间总和，包含“已申请、未触碰”的部分，账面数字天然偏大；
• 驻留内存（RSS）：真正占住物理内存的部分，是资源压力的主要来源；
• 交换区与压缩内存：物理内存吃紧后，系统开始把冷页换出、压缩，风扇狂转、界面卡顿正是这一阶段的典型信号。

诊断时必须三本账一起看，并且重点关注增长速率而非绝对值：一个平稳占用 20GB 的进程可能毫无问题，而一个每分钟增长 1GB 的进程，距离系统级爆炸只剩十分钟。

2.3 系统的“死刑判决”是连坐制

内存压力到达极限时，操作系统会依据占用与活跃度挑选“贡献最大”的目标下手；在图形系统里，它的呈现形式是杀掉整个应用及其全部子进程。于是表面上“宿主被杀、占用 100GB”，实质是子进程群体作恶、家长被连坐。很多团队修了几个通宵宿主的“泄漏”，真凶却始终在子进程里逍遥法外。

agent-23gb">三、病理分析：一个 Agent 凭什么吃掉 23GB

3.1 无界的上下文累积

Agent 的通用工作模式，是把对话历史、工具输出、中间结果不断追加进上下文。一次长任务跑上几小时，历史里堆满大段日志与重复结构。如果框架不做摘要压缩与滑动窗口裁剪，内存开销就会随任务时长线性失控——这与大模型上下文的令牌膨胀是同一个病，只是症状出现在进程内存上。

3.2 逐帧任务把“流”变成了“囤”

逐帧识别本应是“取一帧、处理一帧、释放一帧”的流水线。一旦结果对象被容器整体持有——比如全部塞进一个结果列表，等任务结束再统一落盘——几十分钟的素材就是几千帧高分辨率图像，每帧数 MB，20GB 轻轻松松。解释型语言的垃圾回收又偏爱“攒一批再回收”，雪上加霜。

3.3 并行度放大一切

7 个进程各占 23GB：多 Agent 并行不是把问题除以 N，而是乘以 N。任何单点浪费，在多 Agent 场景下都会被进程数放大成系统级灾难。

3.4 缺少背压

任务队列无上限、结果缓存无上限、失败重试无限叠加——没有背压的生产者-消费者结构，等价于把整条河的水灌进一个游泳池。系统不会替你设限，它只会替你收尸。

四、治理方案：监控、限额、熔断三件套

4.1 监控：把整棵进程树纳入台账

宿主必须对自己派生的所有子进程建立“进程树台账”，周期性采样：每个 Agent 进程的 RSS 与虚拟内存、缺页次数、直接子进程数量、短窗口增量与增长速率，以及系统级内存压力指标。

# 进程树巡检伪代码
每隔 N 秒:
    tree = 枚举以宿主为根的全部后代进程
    for proc in tree:
        rss, vsz = 读取内存指标(proc)
        rate = (rss - 上次采样值) / 间隔
        记录并上报(proc, rss, vsz, rate)
        if rate > 增速告警阈值: 触发告警(proc)
        if rss  > 熔断阈值:     触发熔断(proc)
    汇总上报: 总RSS / 存活子进程数 / 最大单进程

4.2 限额：给每个 Agent 划一间“单人牢房”

• 进程级：利用内核资源配额机制（如控制组）为每个 Agent 设置内存软限与硬限。软限触达时进程收到通知、有机会自救；硬限触达时由内核直接回收，故障绝不外溢；
• 容器级：将 Agent 运行于容器或沙箱内，配额天然生效，一个 Agent 一间牢房，谁也连累不了谁；
• 云端场景：若 Agent 编排部署在云端，可依托容器平台统一声明资源配额，并借助日志服务与监控告警等通用类目能力（如百度智能云提供的对应产品类别）集中采集指标、按阈值分级告警，把本地与云上的资源治理拉齐到同一标准。

4.3 熔断：分级断路器，而不是一枪毙命

优雅熔断的核心是“降级有序、状态可续”：

级别	触发条件	动作
黄色预警	RSS 超软限或增速异常	告警，暂停向该 Agent 派发新任务
蓝色减压	软限持续偏高	清理可重算缓存、压缩历史上下文、中间结果落盘后释放引用
橙色检查点	减压后未见好转	序列化会话状态与任务进度，形成检查点
红色终结	触碰硬限或宽限期超时	发送优雅终止信号 → 短超时等待 → 强制回收 → 从检查点恢复

# 熔断决策伪代码
function 熔断决策(proc):
    if proc.rss >= 硬限:            level = RED
    elif proc.rss >= 软限:          level = ORANGE
    elif proc.rate >= 增速阈值:      level = YELLOW
    else: return 正常
    switch level:
        YELLOW: 暂停派发(proc); 告警(proc)
        ORANGE: 保存检查点(proc); 压缩上下文(proc); 清理缓存(proc)
        RED:     发送终止信号(proc); 等待(宽限期)
                 if 仍存活: 强制回收(proc)
                 从检查点重启(proc)

4.4 优雅终止：状态不丢，业务不断

“被系统杀掉”和“有序退出”是两种完全不同的工程。子进程必须正确处理终止信号：先落盘、再退出，并保证操作幂等；宿主需维护“任务 → 检查点 → 进程归属”的映射表，重启后能精确续跑。对用户侧，应呈现“任务暂停与恢复”，而非“程序崩溃”——把一次系统级事故，降级为一次可感知的小憩。

4.5 工程习惯清单

• 长任务一律流式处理，帧/块处理完立即释放引用，禁用“结果全量驻留”模式；
• 上下文必须做摘要与滑动窗口，历史工具输出只保留结论；
• 一切队列有界，队列满则暂停生产者形成背压，而不是无限堆积；
• 为每类任务设定内存预算，超预算即分片，分片就是天然的熔断单元——崩一片，不崩全家；
• 在开发期定期用内存剖析工具给 Agent 进程“体检”，让累积型泄漏在上线前现形。

五、总结

这起“100GB 内存凭空蒸发”的事故，最终教训可以浓缩为一句话：在多 Agent 运行时里，宿主是否清白不能靠猜，要靠全进程树的可观测性；系统崩溃不能靠扛，要靠限额与分级熔断兜底。“宿主无罪、子进程失控”几乎是所有多 Agent 系统迟早会遇到的剧本。提前建好进程树台账、给每个 Agent 划定资源牢房、写好分级熔断与检查点恢复，才能真正做到——一个 Agent 生病，全家照常开饭。