子代理无上限派生且嵌套会把整个 web 服务端拖死（56个）

[noone89A]

环境：dsh 0.1.0-rc.6（dsh web），Windows 11，Node 24，PTC模式

现象：一次任务中模型并行派生了约 56 个子代理（spawn + fork，continuable后台会话），且子代理还在继续派生子代理。dsh 进程涨到 ~2.2GB 内存、单核满负载持续约 20 分钟，:3080 的 web UI 完全无响应（请求排队超时），只能手动杀进程。重启后键入“继续”同样现象可复现——这不是偶发，是确定性行为。

检查：

• 全程只有一个重 node 进程（2.2GB / 1362s CPU），没有任何按子代理隔离的进程；子代理是进程内的 continuable 后台会话（dsh-subagent-spawn-in-process等 provider），全部共享一个堆和一个事件循环。
• ~/.dsh/sessions/ 下一次运行产生 56 个 session.jsonl.zstd，每个子代理一个完整 agent 会话；观测到 5 秒内 33 个会话文件同时写入——大量叶子层子代理同轮并发产出。

代码调查：

• tool-subagent 有 maxDepth 配置，默认 3，spawn provider 支持该capability（depthLimit: true）。子代理嵌套超过 3 层会抛SubagentDepthError——深度是有上限的。
• 但整个 dsh-subagent 代码里没有任何数量/并发上限（搜不到 maxTotal / maxConcurrent / 并发限制）：同一层可以无限开兄弟子代理， 3 层深度完全挡不住广度爆炸（1 → N → N²）。观察到的 56+ 个子代理是"深度合法、广度无限"的正常结果。
• fork provider 继承父上下文，同样受深度 3 限制，但广度同样无限制； 所有子代理与 web 服务端共享同一事件循环，几十路会话同时做 compaction、 zstd 压缩落盘、LLM 流式请求，主线程饱和 → UI 最先死。

建议：

1. 希望增加全局并发/总数上限（如 maxConcurrent、maxTotal），并给standard preset 内置合理默认值；
2. 或者在全局 cap 落地前，为 spawn/fork provider 提供进程级隔离或独立的线程池/事件循环，避免失控会话拖死 web 服务端；
3. 文档中明确"仅限深度、不限数量"的行为，便于用户配置防护。

如果需要，我可以提供 session 文件、进程观测数据或复现步骤。

[noone89A]

补充一点代码层面的发现：

1. 仓库 .agents/notes/implemented/feature/2026-08-09-parallel-subagent-delegations.zh.md
   记录了 8/9 把子代理从串行改成并行的决策，原文明确写了：

   "maxParallelToolCalls 限制单个步骤中未结算的工具调用数量……而后台和可继续
   调用在启动时即结算并释放池位，它们留下运行的子代理不受该上限约束。
   LLM 提供方负责自身的容量控制。"

   也就是说"后台子代理不受并发上限约束"是文档化的设计，不是 bug。但文档把
   容量控制交给了 LLM 提供方——提供方只管 API 配额，管不了本地进程的内存和事件
   循环，这个假设在本地运行时不成立。实测：continuable 启动微秒级结算、秒放池位，
   我一次消息里 14 个后台子代理全部通过 10 的上限，两批 28 个直系子代理都是
   "合法"启动的。

2. packages/subagent/tool-subagent/src/index.ts 的系统提示词还会注入这样一段：
   "Use subagent in the background by default. Start independent delegations
   together in one assistant message and continue useful work while they run."
   ——官方提示词主动鼓励"一条消息全开"，模型照做没有任何闸门。

子代理跑在后台好处是主线程还可以继续推进别的，这点是比其他Agent工具有优势的。但问题是没有并发数量上限，比如opencode，他会把子代理分组，一次只派部分，而且默认一层深度，没见过出问题。一般先让他阅读我的或者他人复杂工程就会止不住开子代理，然后就导致网页UI卡死

[sah1234567]

这个有点离谱啊，一般agent工具都是禁止subagent下面继续派生subagent的

[pingg241]

这个有点离谱啊，一般agent工具都是禁止subagent下面继续派生subagent的

cc貌似也会子代理下面排子代理

[Nunchakus888]

这个案例直接暴露了 Agent 平台缺少资源预算边界的问题。基于 Harness 的公共扩展点，我发布了 dsh-turn-budget（npm），可以作为全局 cap 落地前的一层 circuit breaker。

它通过 tools/pre-execute 为每个 Agent turn 设置工具调用上限，spawn / fork 作为工具调用会在执行体前被拒绝；同时可用 agent/pre-step 限制模型迭代步数和 provider-reported tokens：

dsh plugin --profile web add dsh-turn-budget

- update:
    id: turn-budget
    config:
      maxStepsPerTurn: 16
      maxToolCallsPerTurn: 8

边界需要明确：这是 per-turn 保护，不是进程级 maxConcurrent / maxTotal。它能限制单个父节点的分支因子与持续迭代，但跨子代理层级仍可能出现 N²，因此这里提出的全局并发和总数上限仍需要内核支持。插件主要提供可立即部署、fail-closed 的止损层。