[Feature] spawn_teammate 无法为 Agent Teams 成员选择模型与推理档位

[chjien1917]

摘要

list_agents 报出每个成员的 model，但 spawn_teammate 不接受任何模型参数——Lead 能看见成员的模型，却永远无法选择它。同一个组件在输出侧暴露了这个值，在输入侧没有对应入口。

对照面已经存在：subagent 工具已带 provider / model / reasoning_effort 三个可选参数。

现状

spawn_teammate 的入参（packages/experimental/tool-agent-team/src/index.ts:178-187）：

name, description, prompt, context

没有任何路由入参。成员路由只能来自插件 Config：

provider: context === 'fork' ? config.forkProvider : config.freshProvider
— packages/experimental/tool-agent-team/src/index.ts:208

而两个默认值都是 continuable-subagent 的通道名 spawn / fork（:26-27）。

对照之下，roster 会解析并输出成员的实时模型：

const model = live?.options.model ?? root.options.model
— packages/experimental/agent-team/src/roster.ts:142，于 :155 输出

model: { type: 'string' }
— packages/experimental/tool-agent-team/src/index.ts:57（MEMBER_VIEW_SCHEMA）

为什么这是结构必然，而不是缺陷

本插件里的 provider 指的是委派通道，不是 LLM 路由。Config 注释原文即写明：

/** Continuable-subagent provider used for fresh teammates. */
/** Continuable-subagent provider used for completed-prefix fork teammates. */
— packages/experimental/tool-agent-team/src/index.ts:18, :20

TeamMemberSnapshot.provider 存的也是同一个通道名
（packages/experimental/agent-team/src/types.ts:51）。因此"成员一律继承 Lead 路由"
是这个设计的必然结果，不是疏漏。本报告不要求改变这一点。

关于命名的一处提醒：list_agents 也输出一个 provider 字段（:55），但它承载的是
通道名、不是 LLM 路由——同一个词，两个概念。本报告论证的不对称只落在 model 上。

对照面

subagent 把这三个参数作为可选的、模型可见的工具参数暴露出来：

provider, model, reasoning_effort
— packages/subagent/tool-subagent/src/index.ts:400-419

参数的确切形态（供实现直接照抄）：

• 工具入参名是 reasoning_effort（下划线），落到子代理 agentOptions 时是 reasoningEffort（驼峰）
• provider 与 model 必须成对提供，否则报错
  （packages/subagent/tool-subagent/src/model-selection.ts:113）
• 三者都受当前 Session 的路由白名单约束
  （model-selection.ts:152：child LLM route "…" is not allowed for this Session）
• 可选路由与档位由 list_subagent_models 列出
  （packages/subagent/tool-subagent/src/list-models.ts:88）
• 缺省语义：provider/model/reasoning_effort 全部省略时用配置的默认值，
  兼容的缺项从父 Agent 继承

诉求（纯增量）

spawn_teammate 接受与 subagent 相同的三个可选参数：provider、model、
reasoning_effort。

省略 → 现状完全不变，成员照今天一样继承 Lead 路由。
提供 → 成员在指定路由上启动。

不改变任何现有调用者的行为，因此不存在需要评估的兼容性问题。

实现会遇到的一个岔口（请顺带记录决定）

在 subagent 里这三个参数是有条件的，不是无条件展开——只有
modelSelectionEnabled 为真时才展开
（packages/subagent/tool-subagent/src/index.ts:400），而它是
modelSelectionPolicy !== undefined（:361），即装了模型选择策略才有。
内置 preset 里是开着的：standard / ptc / cordis 三个 preset 的 tool-subagent
行都带 modelSelectionSettings: true（如
packages/bundle/web-app/presets/standard.patch.yml:95）。

也就是说先例不是"subagent 一直有这三个参数"，而是"装了模型选择策略才有"。

两种处理都可以，我们只希望决定被记录：

• (a) 对齐同一个开关；或
• (b) 对 teammate 无条件暴露。

产物侧锚点

构建产物中的同一组位置：

• packages/experimental/tool-agent-team/lib/index.js:16-18 — Config 默认值
  freshProvider: "spawn" / forkProvider: "fork"
• packages/experimental/tool-agent-team/lib/index.js:271 — ctx.agentTeams.spawnTeammate(agent, { ... }) 调用点
• packages/experimental/tool-agent-team/lib/index.js:290 — provider: context === "fork" ? config.forkProvider : config.freshProvider

subagent 侧的产物锚点（可一并对照）：
packages/subagent/tool-subagent/lib/index.js:46（判定是否声明了路由）、
:67-68（reasoning_effort 非空校验 + provider/model 成对校验）、
:79（映射为 reasoningEffort）、:96-97（Session 路由白名单）。

同题报告

#8589 下由 @snmtg1008 追加的回复「附：Team 面缺"模型 / 思考档"参数」报告了同一
缺口，并给出了产物级锚点（lib/index.js:16-18、:271、:290）。

建议两条互引、保留一条作为主贴，避免同一诉求分散在两个线程里。

相关上游讨论（同属"已知未实现"）：#8324（提案；并指出 continuation seam 已具备条件——
startContinuable 接受 agentOptions，路由随子代理描述符持久化）、#7054（roster 里的
model 是创建时快照）、#8035、#6985、#8373。

版本

锚点在 HEAD dsh-v0.2.1-alpha.1 上成立（见下方回复的独立核对），本地 0.2.0-rc.2
亦同形。

[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,

⇒ 这里的 provider 是"走哪条委派通道"（spawn/fork）的通道名，不是模型（:18/:20 的注释原文即写明 "Continuable-subagent provider"）⇒ 所以你说的"成员一律继承 Lead 的路由"是结构必然。

而你要的对照面确实存在：subagent 工具已暴露 provider / model / reasoning_effort 三个可选参数。

2. ⇒ 诉求可以写成纯增量（这是最容易通过的形式）

spawn_teammate 应当接受与 subagent 工具相同的 provider / model / reasoning_effort 三个可选参数；缺省时保持现状（继承 Lead 路由）。

"缺省保持现状"这一句很重要：它把改动变成"不改变任何现有行为"，维护者不必评估兼容性。

3. ⭐ 你写的"看得见、但指定不了"——请把它放到摘要

list_agents 的 roster 行已经带 provider/model（:55），而 spawn_teammate 没有对应入参 ⇒ 同一个组件输出侧暴露了它、输入侧没有。⇒ 这个不对称是你这条最有说服力的一句，它让"这是设计取舍"的解释站不住。

4. 请与另一条同题报告合并

同在 Q&A 区、同期另有一条报告（#8589 的补充部分）说的是同一件事，并给出产物侧行号（lib/index.js:16-18、:271、:290）。⇒ 两条合并后证据最完整：你这条有动机与对照面，那条有产物级锚点。⇒ 建议互引，由一条作为主贴。

5. 版本

你写"对照面已具备"；我在当前最新 HEAD 上核到上述四处仍是如此 ⇒ 这条无需重测即为当前项。

[chjien1917]

已按你的四点重写：诉求写成纯增量（缺省保持现状）、⭐ 那句提到摘要、产物锚点并入、版本注明。

两点补充：

provider 我没拿它当证据。 它在 list_agents 里是委派通道名（:18/:20 注释、TeamMemberSnapshot.provider），而 subagent 的 provider 是 LLM 路由——同名不同义，拿它论证会被驳回。所以我在正文里主动说明了这点，只留 model 承载这个不对称。
subagent 那三个参数是带条件暴露的（:400 的 modelSelectionEnabled，即 :361 的 modelSelectionPolicy !== undefined；内置 preset 里 modelSelectionSettings: true）。先例不是"一直有"，而是"装了模型选择策略才有"。我把这个岔口列出来并表明无偏好，免得评审再问一轮。
同题报告即 #8589 下 @snmtg1008 的那条追加回复，已互引。