子 agent 脱离管理面并持续循环：单 turn 433 步、49 分钟无法中止（0.2.0-rc.1）

[snmtg1008]

子 agent 脱离管理面并持续循环：单 turn 433 步、49 分钟无法中止

环境

• DSH 0.2.0-rc.1 · Windows
• 触发方式：主会话用 subagent 工具一次派出 8 个并行子 agent，其中一个跑偏
• 该子 agent 的 preset 是 ptc（run_code 工具面），模型走一个第三方 OpenAI 兼容通道

现象

8 个子 agent 里 7 个在 3–8 分钟内完成并写盘；第 8 个（会话 2f64f25d-83be-4933-80e5-3c89fa9350a0）没有落盘、没有回摘要、也没有任何失败通知。
它从 23:10:36 一直跑到 23:59:14（49 分钟），最后是用户在 GUI 里手动停掉的。

实测数据

项	值
会话文件	1,627,349 字节（同批其他子 agent 50–360 KB）
停止后 20 秒采样	delta = 0 字节，mtime 停在 23:59:14
会话内容	1802 个 zstd 帧 / 3578 行 / 解压后约 4.09 MB
步数	单 turn 433 步
工具调用	432 次，全部是 run_code
结束方式	最后一行 turn/end，reason = {"kind":"aborted","reason":{"kind":"user"}}

它不是卡死，是跑偏

解压后会看到它一步只做一件小事：

• 第 5 步：glob 某个技能目录
• 第 430 步：read 了一份不在任务清单里的 SKILL.md（offset 45 limit 10）
• 第 431/432 步：grep 两个与任务无关的关键词，看有没有别的技能引用它们

也就是：把一个「读 4 个文件、写 1 份总结」的任务，做成了整个目录的交叉调研，而且每步只推进一点点，所以 433 步还没到头。没有任何报错、没有循环检测、也不会自己收尾。

关键问题：它不可寻址、也不可中止

它还在跑的时候，父 agent 侧的三个面全都查不到它：

手段	结果
list_agents	只返回 lead 自己（没有 role=subagent 的条目）
job_list	空（subagent 不作为 job 管理）
send_message / interrupt_agent	均返回 active teammate "2f64f25d-…" not found

唯一能判断它还活着的办法，是轮询它的会话文件（~/.dsh/sessions/<项目夹>/<会话id>/session.v4.jsonl.zstd 的 mtime 与体积）。
结果是：父 agent 只能看着它烧 token，没有任何中止通道；最终由人在 GUI 里点停。

复现与观测方法（供维护者定位）

• 一次派 8 个并行 subagent，用「目标文件清单」逐个核对落盘情况，就比较容易撞到一个不落盘也不报错的。
• 会话文件是多帧 zstd 拼接：用 node 的流式 createZstdDecompress 解到第二帧会报 Unknown frame descriptor；按 magic 28 B5 2F FD 切帧、逐帧 zlib.zstdDecompressSync 可以全解（本文数据即由此得到）。
• 停止之后，父 agent 依然查不到该会话（not found）——状态面与真实状态不一致。

代价

• 49 分钟墙钟 · 432 次工具调用 · 1.6 MB 会话；该子 agent 的任务零产出（后来拆成两个更小的片重派才补上）。
• 真正的风险不是这一次的浪费，而是：如果没人盯着文件体积，这种循环可以一直跑下去。

期望（按优先级，供权衡）

1. 可列举、可中止：运行中的 subagent 至少要在某个面上可见（哪怕 list_agents 里多一类 role=subagent），并有一个停止入口。
2. 默认预算：给 subagent 一个步数或墙钟上限，超限强制收尾并要求它先把已有结果写盘 —— 现在的循环没有任何刹车。
3. 结束后一致：被停掉的会话，其状态应当同步到父 agent 可见的那一面（现在 stop 之后仍是 not found）。

分层说明

• 实测事实：上面所有数字与 API 返回，均来自本机会话文件与该机 DSH / OpenViking 的只读查询。
• 代码层推断：无。本文不判断是哪一层造成的，也不指认具体提交。

[snmtg1008]

一、补充：这条"管理面看不见"的根因（在 0.2.0-rc.2 上复现）

先说结论：不是"subagent 没有管理面"，而是"管理面被 Team 版的同名工具占住了"。
send_message / list_agents / interrupt_agent 这三个名字在同一部署里有两套实现，
本机实际生效的是 Agent Team 版（只认 spawn_teammate 造出来的 durable teammate），
所以用它去寻址一个由 subagent 工具派出的子会话，必然报 active teammate "<id>" not found。

机制：两层注册，同名冲突

层	做了什么	证据（0.2.0-rc.2 包内文件）
profile 层（Agent Team profile）	把子 agent 版协调工具整组禁用，再插入 Team 版同名工具	@deepseek-ai/dsh-experimental-agent-team-profile/cordis.patch.yml：tool-subagent-control / tool-subagent-list-agents / tool-subagent / tool-subagent-fork 全 disabled: true，随后 insert agent-team + tool-agent-team
preset 层（会话级，首轮前挂载）	内置 preset 又把 subagent 系注册回来	@deepseek-ai/dsh-web-app/presets/standard.patch.yml（ptc/cordis 同）仍含 tool-subagent-control / tool-subagent-list-agents / tool-subagent / tool-subagent-fork；挂载点见 @deepseek-ai/dsh-agent-preset-registry/lib/index.js 的 recompose → mount
抛出点	Team 版只查 durable 成员 roster	@deepseek-ai/dsh-experimental-agent-team/lib/index.js:357（TEAM_MEMBER_NOT_FOUND）

也就是说：上面的 disabled 被同一个部署里的 preset 层撤销了，结果是
subagent 能用（派得出去），但没有任何工具能列它 / 催它 / 停它 —— 与你观察到的三个"查不到"完全对应。

本机对照（同一台机、同一天、同一内核）

会话用的 preset	工具面	结果
standard（内置）	subagent ✅ + spawn_teammate ✅（同名两套并存）	子 agent 派出后失联
自建 preset（不含子 agent 行）	subagent ❌ + spawn_teammate ✅	不会产生这种孤儿

现场原文（父会话日志，standard preset）

Error: active teammate "<子会话 id>" not found
Error: active teammate "<子会话 id>" not found

紧跟其后的模型思考原文是：「send_message 说 "active teammate ... not found" —— 说明这两个 subagent 已经不在活跃状态了」。
这句推断是错的：该报错只说明"没有这个 teammate 名字"，既不能证明子 agent 已结束，也不能证明它没有产出。
建议顺手把这条错误文案改掉 —— 例如区分"No such Team member"与"this session has no addressing channel for one-shot subagents"。

二、与上游已有改动的关系

• fix(agent-team): disable direct subagent tools in Team profiles（commit 41196ae，2026-09-11）
  的意图就是"Team 组合里不要再有直接的 subagent 工具"。但内置 preset 层又把它们加了回来，
  于是 Team 组合里两者同名并存 —— 该 commit 想避免的状态实际仍然存在（master 上同样如此）。

三、建议（按代价从小到大）

1. 让禁用真的生效：Agent Team profile 的 disabled 应当对同会话的 preset 层也成立（或内置 preset 在 Team 部署下不自带那几行）。
2. 让两套实现互斥：若同会话里只能有一套，宁可让 subagent 直接不可见（现在这样"能派不能管"最糟）。
3. 错误文案：把"成员不存在"与"该通道不支持一次性子 agent"分开，避免模型据此判定子 agent 已结束。

四、复现（只读，不改任何配置）

# 1) 某个会话的工具面 + 是否有同名冲突现场
node probe-session-tools.mjs <session-*.jsonl.zstd>
   → tools: { subagent: true, spawn_teammate: true }   ← 并存即中招
   → teammateErrors: [{ seq, text: 'Error: active teammate "<id>" not found' }]

# 2) 两个来源直接对读
@deepseek-ai/dsh-experimental-agent-team-profile/cordis.patch.yml   # 禁用四个 id
@deepseek-ai/dsh-web-app/presets/standard.patch.yml                 # 又注册这四个 id

会话文件是多帧 zstd 拼接，整文件一次解压只出第一帧；按 magic 28 B5 2F FD 切帧、逐帧解压才能取全。

[PerryLink]

"433 步 / 49 分钟 / 无法中止"——这三个数字本身就是这条报告的价值

1. 你给出的三个数字把问题定死了

• 单 turn 433 步 ⇒ 失控的是步进循环，不是某一次调用；
• 49 分钟 ⇒ 它不会自愈；
• 无法中止 ⇒ 没有可达的止损点 —— 这是最重的一条。

建议把诉求按这三层拆开写（它们的修法不同）：

1. 可中止：父侧/界面必须能止住一个进行中的子代理（含其后续步进），并在中止后进入明确状态；
2. 有上限：单 turn 的步数/时长应当有可配置上限，达到后明确失败而不是继续；
3. 可观测：上层应能看到"它还在跑、跑到第几步"，否则"卡住"与"在忙"无法区分。

第 1 条是硬要求：无法中止的自治循环意味着只能杀进程，代价是把无关会话一起带走。

2. 与本周另两条构成同一主题（建议互引）

帖	坏状态	后果
你这条	子代理脱离管理面持续循环	无法中止
#8849	子代理结算期投影失效	整个进程退出（服务下线）
#7869	（我此前核过）无进展熔断未实现	失控时没有刹车

⇒ 特别值得引用 #7869：我在那条里核到 stalled/noProgress/circuitBreaker/loopGuard/repeatGuard/duplicateCall 等关键词在核心包里零命中 ⇒ "无进展熔断"是未实现，而不是没配置。你这条正好是它缺失后的现场。两条合并能把"请加一个熔断"从建议变成有案例的缺口。

3. 请补三样（把这条变成可复现）

1. 它为什么没有停：433 步里是否反复做同一件事（若可辨识，就是"无进展"的直接证据）；
2. 中止尝试的方式与结果（点了停止？发了取消？父侧报了什么？）——这一条决定它是"没有取消入口"还是"有入口但不生效"，修法完全不同；
3. 版本：你写 0.2.0-rc.1；⚠️ 当前最新是 0.2.1-alpha.1（714 个提交），请补确认。

4. 关于可复现性

失控循环通常难稳定复现。⇒ 建议如实写明是"观察到一次"还是"多次"，并附上那次的事件序列（步进记录/日志）。若只有一次，报告仍成立，但请把它写成"现场报告"而非"可复现缺陷"——这两种写法维护者的处理方式不同。

一条边界

我没有核对子代理循环/中止路径的代码。第 2 节引用的是我此前已核实的 #7869（无进展熔断零命中）与 #8849（结算期异常导致进程退出）。你这条的机制以你补的第 3 节为准。

[snmtg1008]

版本与环境
本机内核 @deepseek-ai/dsh = 0.2.0-rc.2；按你提示核了上游最新，dsh-v0.2.1-alpha.1（release 2026-10-03，等于 master 5badb15）。

复测：现象仍在
0.2.0-rc.2 上同一形态照旧：subagent 派出的子代理不在 Team roster，list_agents 看不到、send_message / interrupt_agent 一律 Error: active teammate "<子会话 id>" not found（父会话 tool/result 原文，多条会话复现）。

代码归因
同一个部署里，同一个名字被注册了两遍：

profile 层：dsh-experimental-agent-team-profile/cordis.patch.yml:4-14 把四个 id 禁掉 —— tool-subagent-control / tool-subagent-list-agents / tool-subagent / tool-subagent-fork 全 disabled: true， 随后 :16-33 插入 agent-team / tool-agent-team / ui-agent-team。
preset 层（会话级，首轮前挂载）：内置 standard / ptc / cordis 又把这四个 id 注册回来 —— packages/bundle/web-app/presets/standard.patch.yml:84-88 的 delegation 组（cordis:group + isolate） 内含 :90-131 那四个条目（tool-subagent 的 toolName: subagent、backgroundMode: continuable， 只有 -codex / -claude-code 是 disabled: true）；ptc 89-131、cordis 88-131 同形；minimal 无。
结果是两套同名工具并存，而实际应答的是 Team 版（抛出点 dsh-experimental-agent-team/lib/index.js:357 的 TEAM_MEMBER_NOT_FOUND，它只查 durable teammate roster）—— 所以 subagent 派出去的子代理"派得出去、管不着"。

上游核对
代码：未修。 dsh-v0.2.1-alpha.1（= master 5badb15）上，上面两个位置原样都在。
更新说明：也没有。 0.2.1-alpha.1 的 release notes 通读，无 agent-team / 工具面冲突条目； packages/bundle/web-app/presets/ 最近一次实质改动是 2026-09-29 的 schedule 系列。

关于 ①（跑偏之后为什么没法停）
这条我不展开，只补一句与本次归因相关的：跑偏的子代理在父侧没有任何可达的中止/催问入口（见上）， 只能等它自己结束或从界面动手。护栏缺失那部分属 #7869，请在那边看。

上游已有同族：

编号	时间	与本条关系
#7642	2026-09-23	同根因，且说得更精确：「bundle 的 disabled patch 只落在 host 平面，preset 平面仍暴露 subagent/subagent_fork」，并提到 bundle/web-app/cordis.patch.yml:504-514 已被重新设置且无任何告警
#7087	2026-09-18	跨作用域同名工具遮蔽：Teams 的 send_message 遮蔽 tool-subagent-control 的同名工具，最早从 0.1.6-alpha.2 起；正文含 active teammate "<id>" not found 原文
#8201	2026-09-29	同一注册点的重复注册报错（tool "subagent" is already registered in this scope）
#8547	2026-10-01	profile patch 层无法 override 嵌套 preset 条目 —— 解释了为什么"禁不掉"
#7568	2026-09-23	同一 delegation isolate group 的挂载形状（子代理工具挂在组外会挂不上）
#8643	2026-10-02	Agent Teams 下 subagent 缺 join 原语（互补：等不到 vs 联系不上）

[snmtg1008]

② 中止的方式与结果（现场，有日志）
那次跑偏的子会话日志我这台机上还在：2f64f25d-83be-4933-80e5-3c89fa9350a0
（cwd=G:\DSH、origin=subagent、delegationDepth=1、preset ptc、父会话 session-61d49fcf-…）。可核对的几项：

• step/start / step/end 各 433，全部落在 turn 1 内；tool/call 432 —— 一步一次调用。
• 行为构成：run_code（PTC 层）432 次，内部 grep 1148、read 224、glob 20 —— 就是一直在翻仓库。
• 模型：provider=xiaomi-token-plan-cn、model=mimo-v2.6-pro（subagent/descriptor.agentModel 一致）。
• 时长：turn/start → turn/end = 48 分 37 秒（15:10:36Z → 15:59:14Z）。
• 结束方式：turn/end: {"turn":1,"reason":{"kind":"aborted","reason":{"kind":"user"}}} —— 用户中止。
  父侧当时能拿到的只有 Error: active teammate "2f64f25d-…" not found（寻址落到 Team 版工具，而它只认 durable 成员）。
  所以那次唯一可行的中止路径是：在桌面端打开那个子代理会话、点停止 —— 父侧没有任何可达的停止/催问入口，
  与它有没有跑偏无关。

可以合理怀疑是模型偶发降智，但仍然不接受父agent无法进行任何控制以及team工具与subagent工具配置完全不一致

[snmtg1008]

附：Team 面缺"模型 / 思考档"参数 —— 同一部署里两套委派面不一致
本机 0.2.0-rc.2 实测：spawn_teammate 只接受 name / description / prompt / context， 没有 provider / model / reasoning_effort；成员一律继承 Lead 的路由。
代码层面：dsh-experimental-tool-agent-team 的 Config 只有 freshProvider / forkProvider （默认 spawn / fork，是"走哪条委派通道"，不是模型），spawn 时也只带这个通道名 （本机 lib/index.js:16-18、:271、:290；上游 dsh-v0.2.1-alpha.1 同形 —— packages/experimental/tool-agent-team/src/index.ts:18-27, 208）。
反差在于：list_agents 的 roster 行有 provider / model 字段（同文件 :55、:57）—— 模型看得见、但指定不了。
对照面本来已经具备：subagent 工具带 provider / model / reasoning_effort 三个可选参数 （本机 dsh-tool-subagent/lib/index.js:46, 67-68, 79；provider 与 model 必须成对，且受 Session 路由 allowlist 约束，:96-97），由 Host 的 subagentModelSelection 授权；standard preset 里也开着 modelSelectionSettings: true（packages/bundle/web-app/presets/standard.patch.yml:99）。
后果很具体：同一部署里，"按能力档位分层委派"这套策略在 subagent 面能表达、在 Team 面不能 —— 要么全员跟 Lead 跑高档（机械活白烧钱），要么全员降档（设计活能力不够）。
上游同点讨论（同样属"已知未实现"）：#8324（提案，并指出 continuation seam 已具备条件： startContinuable 接受 agentOptions、路由随子代理描述符持久化）、#8712、#8035、#6985、#8373、 #7054（roster 里的 model 是创建时快照）。

[chjien1917]

同题互引：这条下面的「附：Team 面缺"模型 / 思考档"参数」与我提的 #8712 是同一个缺口。已在 #8712 正文里引用这条回复，并合入了你给出的产物级锚点（lib/index.js:16-18、:271、:290）。

#8712 相对这条回复的增量：

补了 subagent 侧三个参数的确切形态（供实现照抄）：入参名 reasoning_effort → agentOptions.reasoningEffort；provider/model 必须成对提供（model-selection.ts:113）；受 Session 路由白名单约束（:152）；可选路由由 list_subagent_models 列出（list-models.ts:88）
标出了实现会遇到的一个岔口：subagent 那三个参数是带条件暴露的（index.ts:400 的 modelSelectionEnabled，即 :361 的 modelSelectionPolicy !== undefined），先例不是"一直有"而是"装了模型选择策略才有"
两条 issue 主题不同：#8589 是子代理循环 / 无法中止的生命周期问题，#8712 是委派接口缺参数。建议各自保留、互相引用即可，不必合并——后者比前者容易修，混在一条里容易被拖住。

[PerryLink]

你指出的"两套委派面不一致"我核到了逐行证据——而且它比循环问题更容易修

1. 你说的每一处都在源码里（HEAD = dsh-v0.2.1-alpha.1）

packages/experimental/tool-agent-team/src/index.ts
:18  /** Continuable-subagent provider used for fresh teammates. */
:19  readonly freshProvider?: string
:20  /** Continuable-subagent provider used for completed-prefix fork teammates. */
:21  readonly forkProvider?: string
:26  freshProvider: z.string().default('spawn'),
:27  forkProvider: z.string().default('fork'),
:55  provider: { type: 'string' },        ← roster 行（list_agents 的输出）确实有 provider
:208 provider: context === 'fork' ? config.forkProvider : config.freshProvider,   ← spawn 只带通道名

⇒ 逐条证实你的判断：这里的 provider 是"走哪条委派通道"（spawn/fork）的通道名，不是模型；而 roster 行确实带 provider ⇒ 你写的"模型看得见、但指定不了"是准确的，而且这一点很容易被误读成"已经有这个能力了"。

建议你把这句写进报告——它是这条最有说服力的一句：同一个文件里，输出侧暴露了 provider，输入侧没有对应参数。

2. 对照面已经具备（你说得对）

subagent 工具已经有 provider / model / reasoning_effort 三个可选参数 ⇒ 也就是说机制是现成的，Team 面只是没有把它暴露出来。

⇒ 诉求可以写成一句极简的：

spawn_teammate 应当接受与 subagent 工具相同的 provider / model / reasoning_effort 参数（缺省时保持"继承 Lead 路由"的现状）；list_agents 已经显示 provider/model，输入侧应对齐。

"缺省保持现状"这一句很重要：它把改动变成纯增量（不改变现有行为），可采纳度会高很多。

3. 为什么建议把这条与循环问题分开提

你这条附在"433 步无法中止"之下，但两者性质完全不同：

• 循环/无法中止 ⇒ 生命周期与取消的结构性缺陷（难修、影响面大）；
• Team 面缺参数 ⇒ 接口缺口（易修、纯增量）。

⇒ 混在一条里，容易让容易修的那个被难修的那个拖住。建议拆成两条，并在循环那条里引用 #8712（同期另有一条"spawn_teammate 无法为 Agent Teams 成员选择模型与推理档位"）——你们两条说的是同一件事，合并后证据更强。

4. 请补一样

reasoning_effort 在 subagent 工具里的确切参数名与取值（你已给出 subagent 侧的位置）⇒ 有了它，Team 面的诉求就是"照抄这三个参数"，维护者不必再去查。

5. 版本

你写"本机 0.2.0-rc.2、上游 dsh-v0.2.1-alpha.1 同形" ⇒ 我在最新 HEAD 上核到 :19/:21/:55/:208 仍是如此 ⇒ 这条是当前存活项，无需等新版。

一条边界

我确认的是四处代码位置与语义（通道名 vs 模型名、roster 暴露 provider、spawn 只带通道名）。subagent 工具那三个参数的具体形态以你的核对为准。