[bug] Agent Teams 会话下 send_message 无法按 id 寻址子代理，但 subagent 工具描述声称可以，这个bug之前修复过一次，但没有修好

[qq5671]

send_message cannot address subagents by id in Agent Teams sessions, but the subagent tool description says it can

中文版见下方

Summary

In a session where Agent Teams is enabled, the send_message tool exposed to the model accepts only teammate names (target parameter). Passing the agent_id returned by the subagent tool fails with a misleading error:

Error: active teammate "79557625-e036-4217-97bd-b157672f2ecd" not found

This contradicts the subagent tool's own description, which instructs the model to "use send_message to steer it while running or continue its conversation after it finishes".

The dsh-tool-subagent-control package already implements id-based messaging correctly, but in an Agent Teams session its tool is shadowed by the Team-scoped send_message, so the model never gets access to it.

Environment

• @deepseek-ai/dsh 0.2.1-rc.2 (latest on npm at the time of writing)
• Live-reproduced on 0.2.1-alpha.2 and 0.1.7-rc.2 as well. On 0.2.0-rc.2 the same code path (resolveActiveMember in dsh-experimental-agent-team) is byte-for-byte identical, so the same failure applies.
• Windows 11, Node.js, dsh web GUI session with Agent Teams enabled
• Session role: Team Lead

Steps to reproduce

1. In an Agent Teams session (Team Lead), call the subagent tool with run_in_background: true.
2. Read the returned subagent id, e.g. 79557625-e036-4217-97bd-b157672f2ecd.
3. Send it a message:

send_message({
  target: "79557625-e036-4217-97bd-b157672f2ecd",
  message: "please continue with step 2"
})

Expected

Per the subagent tool description, the message should steer the running child (or start a new turn in it).

Actual

Error: active teammate "79557625-e036-4217-97bd-b157672f2ecd" not found

The child itself has no trouble reporting back to the parent — the up-channel works:

Agent 79557625-e036-4217-97bd-b157672f2ecd sent a message: READY-RC2

So the failure is asymmetric: child → parent works, parent → child does not.

Root cause

Two different tools register the same model-facing name send_message, with different schemas and semantics:

Package	Parameter	Accepts
@deepseek-ai/dsh-experimental-tool-agent-team	target	teammate names from list_agents (or "lead")
@deepseek-ai/dsh-tool-subagent-control	agent_id	agent ids (UUIDs)

dsh-tool-subagent-control is a dependency of dsh-base (node_modules/@deepseek-ai/dsh-base/package.json), so it is part of the base bundle. The Agent Team plugin then registers its own send_message through agent.ctx (per-agent scoped tools), which overrides the base tool for that agent. The result is that a Team Lead sees only the target-based tool.

Code references (0.2.1-rc.2 compiled output):

• dsh-experimental-agent-team/lib/types/roster.js:18-27 — resolveActiveMember() resolves strictly by name and throws the generic error:

  const member = state.members.find(candidate => candidate.name === name);
  if (member === undefined || member.phase !== 'active') {
      throw new TeamError(`active teammate "${name}" not found`, 'TEAM_MEMBER_NOT_FOUND');
  }

• dsh-experimental-tool-agent-team/lib/index.js:292-306 — Team-scoped send_message with target only. It does not carry the adjacentAgentSendMessageTool marker.
• dsh-tool-subagent-control/lib/index.js:22-36 — the id-based tool with agent_id.
• dsh-tool-subagent/lib/index.js:384 — the subagent description that promises the capability.

Additional notes:

• list_agents returns only Team members, not plain subagents, so the Lead cannot discover an addressable name for a subagent child — the child has no name at all.
• The error text says "teammate … not found", which steers the model toward list_agents and name-based retries, not toward the actual cause (an id handed out by subagent).

A previous fix attempt exists, but it does not cover Agent Teams

Commit 43840d6ece — "fix(subagent): harden adjacent message guidance" (2026-08-31) already tried to address this class of problem:

• Added the adjacentAgentSendMessageTool marker in packages/subagent/subagent/src/internal.ts:

  export const adjacentAgentSendMessageTool = Symbol.for('dsh.subagent.adjacentAgentSendMessageTool')
  export function markAdjacentAgentSendMessageTool(definition: ToolDefinition): ToolDefinition { … }
  export function isAdjacentAgentSendMessageTool(definition: ToolDefinition | undefined): boolean { … }

• Marked the send_message definition in dsh-tool-subagent-control with it.
• Used it in packages/subagent/subagent/src/manager.ts:463 to decide whether to inject withContinuableReturnGuidance into a child's initial prompt:

  spec.delivery !== 'caller' && isAdjacentAgentSendMessageTool(this.ctx.get('tools')?.get('send_message', child))
    ? withContinuableReturnGuidance(parent.id, request.prompt)
    : request.prompt

• Clarified the subagent description wording.

The gap: dsh-experimental-tool-agent-team never calls markAdjacentAgentSendMessageTool. Verified in the compiled 0.2.1-rc.2 package: the Team send_message definition carries no such marker. So when the Team tool shadows the control tool, the runtime cannot recognize it as the standard adjacent-message tool, and the guidance/description mismatch persists.

The wording of the description has also changed across releases without resolving the underlying tool-availability question:

Release	subagent description (relevant sentence)
0.2.0-rc.2	"It runs in the background by default and returns a subagent id you can continue with send_message; you are notified when the run settles."
0.2.1-alpha.2 / 0.2.1-rc.2	"The child reports results with send_message; use send_message to steer it while running or continue its conversation after it finishes."

Both promise id-based steering; neither is achievable in an Agent Teams session.

Suggested fixes

1. Avoid the name collision (preferred). Give the two tools distinct names (e.g. keep send_message for Team members and expose the control tool as send_subagent_message / message_agent), so both can be visible at once.
2. Fall back to ids in the Team tool. Let the Team send_message fall back to ctx.subagents.sendMessage() when target is not a known member name but is a live continuable child of the caller.
3. Mark the Team tool. Have dsh-experimental-tool-agent-team mark its definition with markAdjacentAgentSendMessageTool so the runtime recognizes it (this fixes the guidance gating, but not the missing agent_id capability).
4. At minimum, fix the messaging. Detect UUID-like input in resolveActiveMember and report that an agent id cannot be addressed by the Team tool, pointing to the correct mechanism. Likewise, make the subagent description conditional on which send_message variant is actually installed.

Minimal repro harness (if useful)

The whole failure is observable without any domain code:

1. Enable Agent Teams, open a session as Lead.
2. subagent({ description: "probe", prompt: "reply READY", run_in_background: true })
3. Take the id from the result and pass it to send_message({ target: id, … }) → the error above.
4. list_agents({}) lists neither the subagent nor any name that could address it.

---

Verified against installed @deepseek-ai/dsh@0.2.1-rc.2 on 2026-10-20. Happy to test a patch or provide additional traces.

---

【中文版】Agent Teams 会话下 send_message 无法按 id 寻址子代理，但 subagent 工具描述声称可以

概述

在启用 Agent Teams 的会话中，模型拿到的 send_message 工具只接受队友的名字（target 参数）。把 subagent 工具返回的 agent_id 传进去，会得到一个极具误导性的报错：

Error: active teammate "79557625-e036-4217-97bd-b157672f2ecd" not found

这与 subagent 工具自身的描述相矛盾——它明确让模型"用 send_message 引导正在运行的子代理，或在它结束后继续对话"。

dsh-tool-subagent-control 包其实已经正确实现了按 id 投递，但在 Agent Teams 会话中，它的工具被 Team 作用域的 send_message 遮蔽，模型根本没有机会用到。

环境

• @deepseek-ai/dsh 0.2.1-rc.2（撰写时 npm 上的最新版本）
• 另在 0.2.1-alpha.2 与 0.1.7-rc.2 上实测复现。在 0.2.0-rc.2 中，同一代码路径（dsh-experimental-agent-team 的 resolveActiveMember）逐字节完全相同，因此同样会失败。
• Windows 11、Node.js、启用 Agent Teams 的 dsh web GUI 会话
• 会话角色：Team Lead

复现步骤

1. 在 Agent Teams 会话（Team Lead）中，调用 subagent 工具并设置 run_in_background: true。
2. 从返回值中取出子代理 id，例如 79557625-e036-4217-97bd-b157672f2ecd。
3. 向它发送消息：

send_message({
  target: "79557625-e036-4217-97bd-b157672f2ecd",
  message: "please continue with step 2"
})

预期结果

按 subagent 工具描述的承诺，消息应当能够引导正在运行的子代理（或在它空闲时开启新一轮对话）。

实际结果

Error: active teammate "79557625-e036-4217-97bd-b157672f2ecd" not found

子代理反过来向父代理汇报则完全正常——上行通道是通的：

Agent 79557625-e036-4217-97bd-b157672f2ecd sent a message: READY-RC2

也就是说，故障是不对称的：子 → 父可用，父 → 子不可用。

根因

两个不同的工具注册了同一个模型可见的名字 send_message，但 schema 与语义都不相同：

包	参数	接受值
@deepseek-ai/dsh-experimental-tool-agent-team	target	来自 list_agents 的队友名字（或 "lead"）
@deepseek-ai/dsh-tool-subagent-control	agent_id	代理 id（UUID）

dsh-tool-subagent-control 是 dsh-base 的依赖（node_modules/@deepseek-ai/dsh-base/package.json 的 dependencies 段），因此属于基础 bundle。Agent Team 插件随后通过 agent.ctx（按代理作用域的工具）注册自己的 send_message，覆盖了该代理上的基础工具。结果就是 Team Lead 只能看到基于 target 的那个。

代码引用（0.2.1-rc.2 编译产物）：

• dsh-experimental-agent-team/lib/types/roster.js:18-27 —— resolveActiveMember() 严格按名字解析，找不到就抛通用错误：

  const member = state.members.find(candidate => candidate.name === name);
  if (member === undefined || member.phase !== 'active') {
      throw new TeamError(`active teammate "${name}" not found`, 'TEAM_MEMBER_NOT_FOUND');
  }

• dsh-experimental-tool-agent-team/lib/index.js:292-306 —— Team 作用域的 send_message，只有 target。它没有携带 adjacentAgentSendMessageTool 标记。
• dsh-tool-subagent-control/lib/index.js:22-36 —— 基于 id 的工具，参数为 agent_id。
• dsh-tool-subagent/lib/index.js:384 —— 承诺了该能力的那句 subagent 描述。

补充说明：

• list_agents 只返回 Team 成员，不返回普通 subagent。因此 Lead 无法为 subagent 子代理解析出可寻址的名字——它根本没有名字。
• 报错文案写的是 "teammate … not found"，会把模型引向 list_agents 和基于名字的重试，而不是真正的成因（这是个由 subagent 发出的 id）。

此前已有一次修复尝试，但未覆盖 Agent Teams

提交 43840d6ece —— "fix(subagent): harden adjacent message guidance"（2026-08-31） 已经尝试处理过这一类问题：

• 在 packages/subagent/subagent/src/internal.ts 中新增 adjacentAgentSendMessageTool 标记：

  export const adjacentAgentSendMessageTool = Symbol.for('dsh.subagent.adjacentAgentSendMessageTool')
  export function markAdjacentAgentSendMessageTool(definition: ToolDefinition): ToolDefinition { … }
  export function isAdjacentAgentSendMessageTool(definition: ToolDefinition | undefined): boolean { … }

• 用它给 dsh-tool-subagent-control 中的 send_message 定义打了标记。
• 在 packages/subagent/subagent/src/manager.ts:463 用它决定是否向子代理的初始提示注入 withContinuableReturnGuidance：

  spec.delivery !== 'caller' && isAdjacentAgentSendMessageTool(this.ctx.get('tools')?.get('send_message', child))
    ? withContinuableReturnGuidance(parent.id, request.prompt)
    : request.prompt

• 澄清了 subagent 的描述文案。

缺口在于： dsh-experimental-tool-agent-team 从未调用 markAdjacentAgentSendMessageTool。已在 0.2.1-rc.2 编译产物中验证：Team 的 send_message 定义上不存在该标记。因此，当 Team 工具遮蔽 control 工具时，运行时无法把它识别为标准邻接消息工具，指引与描述不一致的问题便一直存在。

描述文案在各版本之间也改过，但都没有解决"工具到底可用不可用"这个根本问题：

版本	subagent 描述（相关语句）
0.2.0-rc.2	"It runs in the background by default and returns a subagent id you can continue with send_message; you are notified when the run settles."
0.2.1-alpha.2 / 0.2.1-rc.2	"The child reports results with send_message; use send_message to steer it while running or continue its conversation after it finishes."

两者都承诺了按 id 引导子代理，但在 Agent Teams 会话里都做不到。

修复建议

1. 避免重名（推荐）。 让两个工具使用不同的名字（例如 send_message 继续用于 Team 成员，把 control 工具暴露为 send_subagent_message / message_agent），使两者可以同时可见。
2. 让 Team 工具回退到 id。 当 target 不是已知成员名、但确实是调用方的一个存活的可继续子代理时，让 Team 的 send_message 回退到 ctx.subagents.sendMessage()。
3. 给 Team 工具打标记。 让 dsh-experimental-tool-agent-team 用 markAdjacentAgentSendMessageTool 标记自己的定义，以便运行时识别（这能修好指引的判定条件，但补不上缺失的 agent_id 能力）。
4. 至少修正提示信息。 在 resolveActiveMember 中识别 UUID 形态的输入，明确报告"代理 id 无法通过 Team 工具寻址"并指向正确机制；同时让 subagent 的描述依据实际安装的 send_message 变体来决定措辞。

最小复现

整个故障不需要任何业务代码即可观察：

1. 启用 Agent Teams，以 Lead 身份打开一个会话。
2. subagent({ description: "probe", prompt: "reply READY", run_in_background: true })
3. 从结果中取出 id，传给 send_message({ target: id, … }) → 出现上述报错。
4. list_agents({}) 既不会列出该 subagent，也不会给出任何可用于寻址它的名字。

---

基于 2026-10-20 已安装的 @deepseek-ai/dsh@0.2.1-rc.2 验证。乐意配合测试补丁或提供更多 trace。

[VitorRodi]

Thanks for the detailed reproduction and for tracing the tool-name collision to the two separate send_message implementations.

I agree that exposing separate tool names is the cleanest long-term solution. One additional consideration is preserving backward compatibility while making the model-facing capabilities unambiguous.

I would suggest introducing an explicit send_subagent_message tool while keeping the existing team-scoped send_message behavior unchanged.

This would avoid changing how existing Agent Teams sessions resolve teammate names and prevent UUID-based routing from accidentally targeting an unrelated team member.

The regression tests should cover at least these scenarios:

1. Agent Teams disabled: a background subagent can receive a follow-up message by its ID.
2. Agent Teams enabled: send_message continues addressing teammates by name.
3. Agent Teams enabled: send_subagent_message addresses a background subagent by ID.
4. An unknown subagent ID returns a clear error rather than falling back to teammate resolution.
5. A completed, non-continuable subagent returns an explicit lifecycle error.
6. A child belonging to a different parent or session cannot be addressed without appropriate authorization.

I would also add a contract test that checks the model-visible tool descriptions against the tools actually registered in the active context.

That last test matters because the original issue is not only a routing failure: the model is explicitly instructed to use a capability that becomes unavailable after tool shadowing.

For the immediate fix, it may be worth separating two changes:

• Restore access to the ID-based messaging capability under a distinct tool name.
• Update the subagent description so it refers to the correct tool for the active runtime.

The adjacentAgentSendMessageTool marker should also be reviewed as part of that migration, since correcting the description alone would not restore the missing routing capability.

A useful acceptance criterion would be that the minimal reproduction succeeds with Agent Teams enabled, while existing teammate-name messaging continues to work without modification.

This should make the fix verifiable across both execution modes and help prevent future regressions when additional tools are registered with overlapping names.

[steve02081504]

Independent reproduction + workflow impact on 0.2.1-rc.2 (Agent Teams session)

Confirming this on a fresh install of @deepseek-ai/dsh@0.2.1-rc.2, dsh web GUI on Windows, Agent Teams available, session role Team Lead, model deepseek-flash.

Same asymmetry as reported: the child's messages arrive fine (Agent <uuid> sent a message: ...), but both steering tools reject the same id:

send_message({ target: "064bf921-42e4-4a41-b86f-9cf211a19496", ... })
Error: active teammate "064bf921-42e4-4a41-b86f-9cf211a19496" not found

interrupt_agent({ target: "91ae25e7-b3fa-497b-82a3-16cd40b43c30" })
Error: active teammate "91ae25e7-b3fa-497b-82a3-16cd40b43c30" not found

list_agents({}) only ever returns the Lead, so there is no name to fall back to.

Why this is not just a wording problem

This came up during a deadline-bound session (the user imposed a hard 20-minute end). Two subagent children were running long optimization runs; the Lead had to tell them to stop, save drafts and wrap up. Since both send_message and interrupt_agent are unreachable, the only available lever was killing the OS processes the children had spawned (cl.exe, elc-seed.exe). That did not stop the children either — one of them recreated its deleted git worktree and kept rebuilding. The user eventually had to copy-paste the stop instructions to each child by hand.

So the practical failure mode is: a parent cannot stop or steer a subagent child in an Agent Teams session, and killing child processes is not a substitute (the child turn continues and may restart work). This matches #9056 (no addressing) and #9764 (cannot terminate), and it is more serious than the description mismatch because hard-stop semantics are unavailable exactly when a deadline forces them.

Additional data point

The error text also makes the model retry with list_agents and name-based targets, which cannot succeed for subagent children since they have no name — the misleading-error suggestion in the original report is worth prioritizing even if the id fallback takes longer.

[Muguett-DBY]

There is an existing rc.2 configuration option for the interruption part of the latest reproduction. The Team tool plugin only registers its interrupt_agent when interrupt is enabled.

For a temporary setup that exposes the ordinary child-ID interrupt tool, apply these overrides in the affected profile's cordis.patch.yml:

- id: tool-subagent-control
  disabled: false

- id: tool-agent-team
  config:
    interrupt: false

Both entries matter: the shipped Team profile explicitly disables the legacy controller. Disabling only the Team interrupt registration can therefore leave no interrupt tool.

After the change has loaded, check that the visible interrupt_agent schema expects agent_id, then use the id returned by the ordinary subagent call:

{"agent_id": "<child-session-id>"}

This replaces the Team name-based interrupt entry point. send_message still resolves to the Team tool and expects target; the message-routing collision remains. An accepted interrupt request also does not establish that the child's turn has already stopped.

I checked the published rc.2 plugins on Node 24 and 26 using the real Cordis tool registry and scoped contexts. With both overrides, the child-ID request reaches the original controller with its ancestor-caller authorization unchanged; without restoring the controller, the tool is absent. The domain services were test doubles: I have not tested a live Desktop child interruption or an active-profile reload. This is a limited routing workaround, not the complete mixed-tool fix proposed above.