Agent Harness 主机资源预算
Agent Harness 资源预算：CPU、内存与进程树
- 作者
- DeepSeekAgent.io 编辑部
- 发布
- 更新
Agent 获得终端与代码执行能力后，Token 预算只覆盖一部分风险。一个任务即使按时停止模型调用，已经启动的测试、编译器、浏览器和后台进程仍可能继续消耗主机资源。2026 年 10 月 25 日的 DeepSeek Harness 社区提案把问题拆成四个维度：归属、测量、预算和强制终止，并建议为主 Agent、Sub-agent、后台任务和 MCP Server 分别建立资源边界。
这篇提案讨论的是 Agent 在主机上启动的工作负载。最危险的场景包括无限分配内存的测试、递归创建进程的脚本、超时后留下的子进程树、无限输出，以及多个 Sub-agent 同时启动相同重任务。
Timeout 管不了哪些资源
单次工具调用超时通常只约束等待时间。它无法天然保证：
- 子进程和孙进程随父 Shell 一起结束；
- 并发任务的总内存低于物理 RAM；
- CPU 时间、进程数量和打开文件数受控；
- 后台进程在 Session 结束后被回收；
- 磁盘写入和日志输出不会耗尽空间；
- 一个失控 Sub-agent 不会拖垮其他正常 Session。
社区提案引用了其他编码 Agent 的真实事故：并行 Sub-agent 留下的 pytest 子进程持续分配内存，单个进程达到 144.9 GB；同名 Shell 函数递归调用触发 fork 风暴；Windows 上超时后的 find、grep 进程树持续运行，并进一步触发安全软件扫描。这些案例共同说明，结束模型回合与结束主机工作负载是两件事。
第一步是建立资源归属
Harness 必须回答“这组进程属于哪个执行单元”。只记录操作系统 PID 不够，因为 PID 会复用，父进程退出后子进程可能被重新托管。更稳定的层次可以是：
Session → Agent → Sub-agent / background job / MCP server → process tree
每次创建可执行工作负载时，Harness 分配执行 ID，并将后续子进程纳入同一个资源容器。用量界面才能展示某个 Agent 的 CPU 时间、峰值内存、进程数、磁盘写入与存活后台任务；强制终止时也能定位整个进程树，而非只杀掉最上层 Shell。
软限制与硬限制承担不同职责
软限制用于反馈和调度。例如内存达到预算的 70% 时，Harness 可以通知模型剩余额度，阻止再启动高并发测试，或要求先结束已有任务。硬限制用于保护主机：达到上限时冻结或终止整个执行单元，并记录触发原因。
一个实用的预算模型可以包含：
| 资源 | 软限制动作 | 硬限制动作 |
|---|---|---|
| 内存 | 降低并行度、停止新任务 | 终止执行单元及其进程树 |
| CPU 时间 | 提醒剩余计算额度 | 暂停或终止 |
| 进程数 | 禁止继续 spawn | 杀死完整进程组 |
| 墙钟时间 | 请求收尾并保存结果 | 截止时间后强制停止 |
| 磁盘/输出 | 截断日志、停止新写入 | 关闭任务并保留诊断摘要 |
| 打开文件 | 提醒关闭句柄 | 拒绝新增或终止异常任务 |
Sub-agent 的预算应该从父 Agent 分配。父任务还剩 4 GB 内存时，不能让四个子任务各自认为拥有 4 GB。并发分支需要共享总预算，并为 Harness、自身界面和用户其他程序预留安全空间。
三个平台的执行机制
跨平台产品可以保持一致的上层预算接口，底层使用各系统的原生隔离能力：
- Linux：cgroup v2 提供 CPU、内存、PID 和 I/O 控制，并能以容器为单位统计和终止；
- Windows：Job Objects 可以把相关进程纳入同一作业，设置内存、CPU 和活动进程限制，并在关闭作业时终止子树；
- macOS：可结合进程组、
proc_pid_rusage、资源限制和持续子树追踪；沙箱或独立执行服务可进一步增强边界。
单靠定期读取进程列表容易发生竞争：进程可能在两次轮询之间创建大量子进程。操作系统级容器应负责硬边界，Harness 的监控器负责解释、展示和策略选择。
强制终止之后仍要留下可继续的信息
资源保护不能只返回“进程被杀死”。一次可恢复的终止至少应写入：
- 哪个 Agent、工具调用或后台任务超过了哪项预算；
- 峰值与限制值；
- 被终止的进程树摘要；
- 已产生的文件与可能不完整的文件；
- 最后一个可用检查点；
- 推荐的重试参数，例如减少并行度、缩小测试范围或提高经用户确认的额度。
这能让模型在下一回合调整计划，也让用户区分代码缺陷、工作量估计错误和预算配置过紧。正常的同级 Session 应继续运行，避免一个失控任务造成整个 Desktop 退出。
与 Token 预算组合使用
Token、工具调用次数、墙钟时间和主机资源应放进同一张任务预算表。一个 Sub-agent 可能模型 Token 很少，却启动高成本本地编译；另一个任务几乎不占 CPU，却在重复验证中消耗大量上下文。只看其中一项会低估真实成本。
可以采用以下执行流程：
- 任务开始前估算模型、工具、时间与主机资源；
- 向子任务分配明确额度，并保留父任务缓冲；
- 在关键阈值处向 Agent 注入剩余预算；
- 超过软限制时先降并发、保存检查点并请求收尾；
- 达到硬限制时终止完整进程树；
- 将 Token 账单与主机资源记录一起复盘。
这套设计与Sub-agent Token 计费审计以及Infinite Agentic Loops 分析互补：前两篇覆盖模型调用和循环，本篇补上本地执行资源。
参考资料
- DSH 社区：按 Agent 分配资源预算与强制执行
- Claude Code：失控子进程耗尽内存案例
- Claude Code：Shell 函数递归触发进程风暴
- Claude Code：Windows 超时后遗留进程树
- Linux cgroup v2 文档
- Windows Job Objects 文档
常见问题
已经设置工具 Timeout，还需要资源预算吗？
需要。Timeout 约束等待时长，无法保证整个进程树退出，也不会自动限制内存、CPU、进程数和磁盘写入。
为什么要给每个 Sub-agent 单独归属？
单独归属才能看到是谁消耗资源、只终止失控分支，并在父任务内正确分配共享总预算。
达到硬限制后应该终止整个 DSH 吗？
通常只终止对应执行单元及其派生进程，并保留其他 Session。Harness 本身需要留有独立的安全资源和恢复通道。