never ask 的语义与团队插件下的 subagent 交互限制：是否为预期设计？

[YUANZHI2009]

关于 never ask 的语义，以及团队插件启用后的 subagent 行为

使用 DSH 时有两点疑问，想确认是否属于有意设计。

1. Full Access 下的 never ask 是否仅指操作审批？

Full Access 下，运行时注入的提示词大意是：

The policy to ask user has changed to never.

这里的 ask user 似乎有歧义：是仅指不再请求操作权限，还是也希望模型减少需求澄清等正常提问？

实际使用中，我感觉模型很少调用 ask_user_question，但偶尔仍会调用，暂时不能确定是否与这句提示词有关。这种减少提问的行为是预期设计吗？如果这里只指权限审批，是否可以用 approval/permission 限定范围，避免被理解为禁止正常提问？

2. 启用智能体团队插件后，普通 subagent 的交互是否受限？

按我的观察，启用团队插件后，leader 仍能创建普通 subagent，但后续交互工具似乎被面向团队成员的工具替换，无法用于普通 subagent，形成了“可以创建，却缺少配套交互工具”的情况。

同时，当前规则要求使用 agent team 需用户明确许可，普通 subagent 则没有这一要求，因此模型仍可能走普通 subagent 这条路径。

这是启用团队插件后的有意限制，还是两套机制在工具暴露上存在衔接问题？这种情况下，普通 subagent 的预期使用方式是什么？ 如果我对工具的理解有误，也请指正。

[PerryLink]

两个都问在点子上，先把 never 的范围说清：它只管审批，不管提问。

1. 那句提示词只作用于审批

你在系统提示里看到的那句当前不在树里。我在 master fcc0ad46 和 dsh-v0.2.1-rc.5（b830ec95）两个 ref 上搜 "has changed to"，都是 0 命中。现在的模型侧文案是 packages/interaction/user-approval/src/index.ts:74 的 NEVER_SENTENCE：

Approval prompts are disabled in this session: actions that require approval are rejected automatically — do not request sandbox escalation (do not set sandbox_permissions).

它的作用域写在 :59-68 的注释里：policy 决定的是"一个 ApprovalService 的 ask 在交给应答方之前怎么处理"，never = 每个 ask 直接判 rejected。ask_user_question 是交互工具，不走 approval seam，所以不受它影响。

但你的担心成立：切换通知的名字就是 "never ask the user for approval"（:77-81 的 POLICY_NOTICE_NAMES），模型看到 never ask the user 这种措辞，把它读宽到"别问用户"是可能的。所以"模型少问"如果真和它相关，那是措辞副作用，不是设计意图。这句是模型可见文案，没有配置项能限定范围；要改只能改文案（例如明确写 approval prompts）。

2. 团队不再替换普通 subagent 的工具——恰恰是被改掉了

docs/upgrade-guide/v0.2.1-rc.2/agent-team-subagents/guide.md 开头就是这句话：

Agent Teams uses the standard subagent tools and Session ids; Team-specific creation, messaging, listing, interruption ... are removed.

具体是 spawn_teammate 和 team 作用域的 send_message/list_agents/interrupt_agent 被移除，标准工具改用 agent_id 认人。所以你看到的"能创建、但缺配套交互工具"，在 0.2.1-rc.2 及以后不应该出现。

两个可能：版本还在 rc.2 之前；或者 profile 里有旧 patch 行还禁着 tool-subagent-control——迁移指南第 1 条就是让人删掉这类行。

自查：看 list_agents 是不是无参数、send_message 是不是吃 agent_id。是旧形状就查上面两条。把 profile patch 里跟 tool-agent-team / tool-subagent-control 相关的行贴出来，我能直接判是哪一种。

版本坐标：master fcc0ad46；npm latest=0.2.1-rc.5、next=0.2.2-rc.1。只读了源码和文档，没在你的环境里跑。

[Misaka10548]

我委托的我朋友写的这个discussion，现在有点时间了，我来补充一下，用gpt写的稿子：

1.设计确认：approval policy = never 与 ask_user_question 的边界，是否需要在模型提示中明确？

背景

在 Web GUI 中切换权限设置后，模型上下文会收到这样的策略变更通知：

The user changed the approval policy from "ask the user for approval" to "never ask the user for approval".

对应的 runtime-context 还会说明：

Approval prompts are disabled in this session: actions that require approval are rejected automatically — do not request sandbox escalation (do not set sandbox_permissions).

与此同时，ask_user_question 的工具描述是：

Ask the user a concise question when you need confirmation, a choice, or missing information before proceeding.

我想确认这里的预期语义，尤其是：“不再请求工具执行审批”是否应与“仍可询问需求、偏好或缺失信息”明确区分？

这是一次设计与文案层面的咨询，不是已复现的运行时 Bug。目前没有通过受控实验验证模型会因为上述通知而停止使用 ask_user_question。

阅读源码后的理解

以下以 f3803c96974ad4a94195fb97e5c637e9c2a3afe3（0.2.2-alpha.2 发布提交）为参考基线。

1. never 自动拒绝的是审批请求。

   ApprovalService.decide() 在分发审批应答者之前，根据有效策略返回 rejected。这不是自动批准，也不代表获得更宽的执行权限。

   参考：审批判断。

2. ask_user_question 使用另一个交互机制。

   工具执行调用 ctx.userQuestions.ask()，没有直接读取 approval policy。

   参考：提问工具入口。

3. 这种机制分离似乎是有意设计。

   Approval seam 的设计说明在 “Alternatives considered” 中明确讨论了不使用通用 user-questions 机制的原因，包括封闭的审批结果、关联具体工具调用、默认拒绝和审计要求，并指出：

   an elicitation form is not a permission prompt, and a free-text answer is not a closed outcome

   参考：设计说明。

4. 这不意味着 ask_user_question 无条件可用。

   它仍受通用工具执行策略、guards、应答通道可用性，以及独立的子代理调用限制影响。如果通用执行策略要求对这次工具调用进行审批，never 也可能间接阻止它。

   参考：工具执行检查、提问调用者检查。

因此，我目前的理解是：

approval policy = never 并不等于“禁止一切用户交互”，也不等于“无需授权即可执行所有操作”。它控制的是特定的工具审批流程。

如果这个理解不准确，希望维护者指出。

想确认的问题

1. 对于普通交互式会话，在提问工具及应答通道可用、调用者满足要求、且没有其他执行策略拒绝的情况下，never 下继续使用 ask_user_question 澄清需求或获取选择，是否属于预期支持的行为？

2. 模型侧是否也应明确区分以下两类行为？

   • “输出应使用 JSON 还是 Markdown？”——普通澄清或选择。
   • “刚才的沙箱操作被拒绝了，能否同意让我扩大权限重试？”——工具权限审批，不能改用普通提问绕过。

3. 是否值得在策略通知、runtime-context 或工具描述中补充一句作用域说明？还是目前的文案已经是经过权衡的设计，并有相关测试或推荐的提示词约定？

文案方面的顾虑与建议

虽然原句包含限定词 “for approval”，runtime-context 也明确提到了 sandbox escalation，但 ask_user_question 的说明同时使用了 “confirmation”。我担心模型在自然语言层面可能把两者泛化为同一类“向用户确认”，从而不必要地省略澄清问题。

这只是潜在的模型理解风险，不是在声称代码禁用了提问工具，也不是在声称这种误读已经稳定复现。

如果普通澄清仍然是预期行为，是否可以考虑类似这样的补充说明：

The approval policy applies to tool-permission requests, not to ordinary clarification questions. It does not by itself disable ask_user_question; tool availability, caller restrictions, and other execution policies still apply. A user answer does not override a sandbox restriction or an approval denial.

这里的建议仅希望明确语义边界，不要求放宽权限、不要求自动批准，也不要求为 ask_user_question 绕过现有执行检查。

我正在考虑通过插件注入一段简短提示来明确这个边界，因此想先确认官方设计意图，避免注入与框架预期相冲突的指导。

感谢！

2.设计与迁移确认：Agent Teams 与普通 subagent 共存时，同名控制工具覆盖及通信不对称

背景

我在一个同时暴露普通 subagent 与实验性 Agent Teams 工具的 Web 会话中，测试了两套能力能否共同使用。

当时模型同时可以看到：

• subagent / subagent_fork
• spawn_teammate
• send_message / list_agents / interrupt_agent
• wait_agent 和 team_task_*

两类代理都能创建并完成工作，但创建之后的发现、消息和控制入口并不一致。我想确认：

这属于旧版有意限制的组合，还是工具组合应当避免出现的状态？上游统一 subagent / Team 的重构是否已经覆盖了这些问题？

版本与证据范围

• 本地源码参考：f3803c96974ad4a94195fb97e5c637e9c2a3afe3（0.2.2-alpha.2 发布提交）。
• 下表是先前会话中的实际观察，本次整理没有重新进行通信或中断实验。
• 尚未确认当时运行中的全部插件构建与该源码提交完全一致，因此不把历史观察等同于该提交或最新版的完整行为。
• 本次还查看了上游 fcc0ad462172522aaf5c93a7b2e01f6b9f0b0159 的设计说明和控制工具实现，发现已有相关重构。

当时观察到的现象

场景	观察
Lead 与 Team 队友通信	双向正常，使用 Team 版 send_message({ target, message })
普通 subagent 向其父代理汇报	正常，子代理使用普通版 send_message({ agent_id, message })
Lead 向自己创建的普通 subagent 追加消息	Lead 当前可见的是 Team 版工具；把子代理 id 传给 target 后，得到 active teammate "..." not found
发现与等待普通 subagent	Team 版 list_agents 面向 Team 名册；wait_agent 在没有活跃 Team 同伴时返回 no-active-peer，不能据此判断普通子代理的工作状态
普通版 interrupt_agent 的确认语义	对一个不存在的 UUID 也返回 interrupt requested for agent ...；该文本不能证明目标存在或已经停止

我关注的不是“两个插件同时加载就崩溃”，而是：

父代理能够创建普通子代理，子代理能够回报，但父代理当前可见的同名控制工具却无法用同一身份继续控制它。

这也使得统一的协作提示词比较难写：工具名称相同，但参数、发现范围和可达对象取决于代理所在作用域。

旧版源码和文档提供的解释

1. Team 工具会遮蔽同名普通控制工具

旧版文档明确说明，Team 工具注册在成员作用域，同名注册会遮蔽普通全局控制工具。

Team 版 send_message 接受 target，按 Team 成员名称解析；它并不是一个同时识别普通子代理 Session id 的通用入口。

参考：

• 作用域遮蔽说明
• Team 消息与列举工具
• Team 名称解析

2. 标准 Team profile 原本会禁用普通委派入口

旧版 profile patch 禁用了 tool-subagent-control、tool-subagent 和 tool-subagent-fork。

不过，该 bundle 的文档也说明，preset 仍可能在自己的作用域挂载 subagent 控制工具，顶层 bundle 不会替换这些注册。

因此，我不确定当时同时看到两套工具，是预期支持的扩展组合，还是 profile / preset 叠加后暴露了不完整的控制路径。

参考：

• Team profile patch
• Preset-scoped child controls 限制说明

3. 中断返回值表示的不是“已经停止”

旧版普通控制工具在调用中断服务后返回 accepted: true；底层对非 resident 的目标存在直接返回的路径。

因此，“请求被接受”“命中了正在运行的目标”“目标已经停止”是不同状态。这里可能属于刻意设计的幂等语义，但模型侧容易把确认文本理解得更强。

参考：

• 普通中断工具
• 底层中断逻辑

我看到上游已有相关重构

新的设计说明直接指出，Team-scoped 控制工具遮蔽标准 subagent 工具，会迫使 profile 禁用普通委派，并导致 fork 前后的工具 schema 不同。

后续设计改为：

• Team 建立在同一棵 subagent 树之上；
• 普通控制工具负责身份、发现、消息、中断和等待；
• Team 主要提供共享任务板和协作策略；
• 同一棵树内支持通信，中断仍保持祖先权限约束；
• wait_agent 改为等待调用者自己的下一步收件箱，而不是旧版 Team 状态变化。

参考：统一设计说明。

另外，我注意到迁移说明展示的是 agent_id，而该提交的当前控制工具实现已使用 agent 参数并解析 agent name。设计说明开头也提到了后续 catalog names 的演进。

因此，我不想把旧版的 target / agent_id 规则直接固化到新的插件提示词中。

希望确认的问题

1. 旧版支持边界
   在仍有 spawn_teammate 和 Team-scoped 控制工具的版本里，同时保留普通 subagent 委派入口是否属于受支持组合？如果不是，是否应由组合层阻止这种状态，或在工具提示中明确说明？

2. 旧版的父子通信不对称
   如果允许混用，Team Lead 应通过哪个明确入口向自己创建的普通 subagent 追加指令、查询或中断？还是该版本推荐只使用 spawn_teammate 进行需要持续协作的委派？

3. 新版迁移基线
   上述统一重构是否已经作为这些问题的正式解决方向？应以哪个发布版本和哪份迁移说明为准，尤其是 target → agent_id → agent 的寻址变化，以及旧会话 / preset 配置如何迁移？

4. 中断确认语义
   对不存在、非 resident 或已结束的目标返回接受确认，是否是预期的幂等设计？是否建议在工具描述或结果中更明确地区分“请求处理完成”与“目标已停止”？

我的目标是为协作代理编写可靠的提示词，可能通过插件自动注入。希望先确认官方支持的组合与版本边界，而不是仅靠提示词补偿一个已经被新架构替代的旧行为。

感谢！

[PerryLink]

先纠正我自己：上一条我跟着迁移说明写了"标准工具改用 agent_id"，按当前代码这是错的。packages/subagent/tool-subagent-control/src/index.ts:49 的 send_message 参数名是 agent，描述是"another agent in your subagent tree, as shown by list_agents"——吃的是名字，不是 id。迁移说明（rc.2 的 guide）第 14 行和第 28 行还写着 agent_id，它落后于代码；以工具 schema 为准。

下面按你四个问题回。

1. 旧版混用不是受支持组合——它是被禁掉的

packages/experimental/agent-team-profile/cordis.patch.yml（在 f3803c96 上）开头就是：

- id: tool-subagent-control
  disabled: true
- id: tool-subagent
  disabled: true
- id: tool-subagent-fork
  disabled: true

也就是说那个 profile 里普通委派入口是关掉的，不存在"两套并存"。你看到的并存，应该是 preset 在自己作用域里又挂了一遍（README 的 known limitations 说的就是这个），属于叠加出来的状态，不是官方组合。

2. 那个版本没有推荐的父子通信入口

这正是统一设计说明里写的 problem（.agents/notes/implemented/architecture/2026-10-15-agent-teams-as-subagents.md）：

Team-scoped messaging and control tools shadow the standard subagent tools, forcing profiles to disable ordinary delegation and making fork tool schemas diverge from their parent.

所以旧版的答案是：要么全用 spawn_teammate，要么别用 team profile。没有第三条受支持的路径。

3. 新版基线：设计说明 + 当前工具 schema，别照抄迁移说明的寻址

那份设计说明状态是 implemented，但它自己列了后继：2026-10-16 的 tree-wide communication、2026-10-19 的 task-board inbox、2026-11-02 的 catalog names（后者明确取代了"创建不接受成员名/拒绝唯一名"那句，所以现在才有名字可寻址）。packages/experimental/agent-team-profile 在当前 master 上已经不存在了。

结论：版本边界按 dsh-v0.2.2-rc.1（66491b05）算；寻址以 list_agents 的输出 + agent 参数为准；旧会话的 roster 记录只能解码，不会投递。

4. 中断确认是幂等的，不是"已停止"

packages/subagent/subagent/src/manager.ts:207-208：目标不在 resident 表里就直接 return，不报错；:218 对正在关闭的目标也直接 return。所以工具返回的 accepted 只代表"请求被受理"，不代表目标停了。你的提醒是对的：描述里应该把"请求受理"和"目标已停止"分开写，但那是文案改动，不是行为改动。

一句总建议：给协作代理写提示词时，别把"accepted"当状态用，状态只从 list_agents 读。

参考基线：master fcc0ad46，tag dsh-v0.2.2-rc.1=66491b05；旧版行为按 f3803c96（alpha.2）核。