从一次 Agent 资源失控，重新理解平台的责任

2026-07

这次故障由一个自动执行任务触发。下载接口没找到，Agent 转而探查，在压缩脚本中用正则寻找路由。相关进程资源失控，内存持续增长，同宿主其他服务开始超时，直到内核终止异常进程后恢复。

能确认的是异常执行、内存压力与限制缺口。没有完整分析样本，还不能把全部增长归到某种正则实现。但单个任务为何影响邻居服务，已经暴露了执行环境的问题。

容器隔离不代表资源已经受限

文件和进程视图隔离，与限制内存、CPU、进程数量是不同配置。检查不能停在启动参数，必须找到目标进程实际所属资源组，并查看父级约束。下面只讨论 cgroup v2。

bash

# 只读定位示例：12345 换成实际进程号
cat /proc/12345/cgroup
# 根据上一步结果确定真实目录，不要只猜容器显示名称
cat /sys/fs/cgroup/<actual-group>/memory.current
cat /sys/fs/cgroup/<actual-group>/memory.max
cat /sys/fs/cgroup/<actual-group>/memory.events
cat /sys/fs/cgroup/<actual-group>/cgroup.events

memory.current 是资源组计量，不等于单进程 RSS。memory.events 比较一段时间的增量，历史 oom_kill 非零不能证明本轮刚发生 OOM。宿主可用资源、交换和父组压力也要一起观察。

一个宿主中的资源分组与保留预算 — 资源归属与预算示意，非实际容量配置。还需要检查父级限制与宿主压力。

所有工具子进程应留在受控组内。只限制包装进程，把真实命令交给其他执行域，约束可能完全没有落到目标上。任务也不应具备自行更改资源控制的权限。

调度预算与单任务上限各有职责

可接纳容量从宿主预算扣除系统与常驻服务保留，再比较有效预留总量。预留需要原子更新，两个调度者不能同时花掉同一份余量。

单任务仍受运行时硬限制。预算控制总量，硬限制控制异常个体；缺少任一项，都可能把宿主挤满。memory.high 可用于回收压力，memory.max 给出硬边界，但它们不能代替任务恢复。

调度向执行器传明确规格，示例数值不是线上容量：

json

{
  "workloadId": "run-demo",
  "generation": 4,
  "limits": {"memoryBytes": 1073741824, "cpuQuota": 1, "maxPids": 128},
  "deadlines": {"executionSeconds": 300, "terminationGraceSeconds": 10},
  "filesystem": {"workspaceRef": "isolated-demo", "ephemeralBytes": 2147483648}
}

适配器将平台字段转成运行时配置，启动后读回核对。必需限制无法落实就创建失败，不能忽略字段继续跑。cpuQuota 明确是核数还是时间配额，磁盘也依赖实际运行时或文件系统支持。

限制还包括日志、产出大小和出站访问。任务从内存转去耗尽磁盘，不是故障被解决了。

停止请求和资源释放不能合成一个状态

取消后进入 stopping，禁止新动作，通知执行器终止。宽限期后仍未结束就强制终止，确认对应代次已清理，才写 stopped 并释放预算。

停止确认以后才归还预算 — 运行资源清理与外部业务副作用分别核对。旧代次不得归还新代次的预算。

cgroup.events 的 populated 可以辅助确认组内是否仍有进程，不说明远程任务和已发业务操作的结果。业务副作用单独核对。

执行器失联，预留进入 uncertain。恢复者按 workloadId 与 generation 查询真实实例：不存在则记录终态，有残留则继续清理，无法证明就保持隔离。宁可暂少接任务，也不能把尚在使用的容量再次分出去。

重复恢复不制造新容量

预留仍为 held 或 uncertain、代次匹配，才条件更新为 released；已释放就返回原结果。若余量通过有效预留之和计算，改变状态即可；另存 available 计数，则状态变化与计数更新在同一事务中，且只加一次。

恢复租约只决定谁协调，不证明任务已结束。恢复者自身重启后，仍根据实际证据继续处理，迟到的旧代次清理不能释放新实例预算。

验证用受控负载增加内存、进程和 CPU，检查目标任务得到明确终态、邻居仍可响应。另测清理中退出、重复消息与旧代次请求，确认预算最终且仅释放一次。工具缺失的明确错误能减少触发机会，影响范围仍由这些执行约束负责。