tool-agent-team：agent/created 时序竞态会随机杀死一次性子代理（TEAM_NOT_MEMBER）

[higekibaka]

症状

挂载 @deepseek-ai/dsh-experimental-agent-team-profile 后，任何一次性
subagents.start('spawn', …) 子代理（我们的是一个只读评审批评者；同样的
路径也服务无状态的顾问子代理）会概率性地在迈出第一步之前死亡。子代理
回合以 stopReason: "error" 结束，错误详情：

agent "<child-session-id>" is not a member of an active Agent Team

卸载 team profile 后，同样的 spawn 恢复稳定。在本地 0.1.3-alpha.1 构建上
复现，spawn 带不带 toolFilter 都会触发。

根因（据我们排查）

packages/experimental/agent-team/src/roster.ts 中，descriptor 发布与
agent/created 观察者之间存在竞态：

1. tool-agent-team 通过 agent/created 上的 maybeInstall 按代理安装
   团队工具（packages/experimental/tool-agent-team/src/index.ts），
   由 roster.tryMembership(agent) 把关。
2. tryMembership 调用 subagentDescriptor(agent)——它折叠子会话自身
   后缀（snapshotEvents(inheritedEventCount)）来识别「服务商拥有的
   子代理 descriptor」。
3. 在 agent/created 这一刻，descriptor 事件在后缀里尚不可见，探针
   返回 false。于是一个父代理存活、但父代理不在团队名册里的一次性
   子代理，落入「隐式 lead」分支，被装上了团队工具和 team:policy
   系统提示节。
4. 等 prompt 装配时，该提示节的 text() 调用的是抛错版
   roster.membership(agent)。此时 descriptor 已可见，tryMembership
   返回 undefined，membership() 抛出 TEAM_NOT_MEMBER——整个回合失败。

即：安装器在创建时刻把子代理误判为 Lead，prompt 节在装配时刻身份翻转后
把它杀死。

修复方向（建议）

• 把隐式 lead 的判定推迟到 descriptor 保证可见之后（例如在首次工具
  发现 / prompt 装配时分类，而不是 agent/created）；或
• 让 team:policy 提示节非抛错（用 tryMembership 解析，成员身份消失
  时渲染为空），使过期的安装无害化；或
• maybeInstall 在 descriptor 出现时复查并卸载。

如需要，我们可以提供复现现场的子会话日志（session.v2.jsonl.zstd）。

附带诉求：spawnTeammate 的路由桥接

我们在做一个spawn一次性子代理的插件时撞上这个问题。目前的绕行方案是
不挂载 team profile——但这也意味着我们无法试用（本来很有前途的）
teammate 邮箱进展通道：SpawnTeammateRequest 不支持按次 pin 模型路由
（其中 provider 字段选择的是 subagent 提供方，LLM 路由活在 team 包的
profile 配置层），而底层 continuable descriptor 明明有
agentProvider/agentModel/agentReasoningEffort 字段。如果
SpawnTeammateRequest 能暴露 agentOptions，我们这边第二个使用场景
（批评者 teammate 化 + 邮箱叙事进展）就能解锁。

[argszero]

源级验证完毕——你的根因分析在 0.1.3-alpha.1 源码上全部成立，我逐行核对如下：

印证链

• packages/experimental/tool-agent-team/src/index.ts:398 — maybeInstall 以非抛错的 tryMembership(agent) 把关，在 agent/created 时调用。
• packages/experimental/agent-team/src/roster.ts:484 — subagentDescriptor 读 snapshotEvents(agent.session.inheritedEventCount)（会话自身后缀）。
• 在 agent/created 时刻，descriptor 事件尚未落入后缀 → 一次性子代理落入 roster.ts:107「隐式 lead」分支，被装上团队工具 + team:policy 提示节。
• tool-agent-team/index.ts:168 — team:policy 节调用的是会抛错的 ctx.agentTeams.membership(agent)（roster.ts:79-83 throw TEAM_NOT_MEMBER）。等 prompt 装配时身份已翻转（descriptor 可见 → tryMembership 返回 undefined），membership() 抛出 → 整回合 stopReason:"error"。

修复方向（我的权重排序）

1. 最小、最直接：把 tool-agent-team/index.ts:168 的 text() 改用非抛错的 tryMembership(agent)，成员身份消失/尚未就绪时渲染空串（或降级为无害说明）。这纯属「过期安装无害化」——安装器即使在 agent/created 误判了，提示节也不会把子代理杀死。改动 1 行，不动 roster/安装时序。
2. 更根本：把「隐式 lead」的判定从 agent/created 推迟到首次工具发现 / prompt 装配时再分类（即把 maybeInstall 的 group 决策延后）。这需要确认 descriptor 在哪个生命周期点保证写入后缀，改动面更大。
3. 你的「maybeInstall 在 descriptor 出现时复查并卸载」也可行，但要处理「已装上的工具在失效后如何安全回收」的回滚路径，复杂度高于方案 1。

我倾向于方案 1 先落地（1 行、可独立提交、立即消除随机死亡），方案 2 作为后续根治。

附带诉求（SpawnTeammateRequest 暴露 agentOptions）：这条我完全赞同。你指出的矛盾点很关键——continuable descriptor 有 agentProvider/agentModel/agentReasoningEffort，但 SpawnTeammateRequest 的 provider 字段选的是 subagent 提供方，LLM 路由活在 team 包 profile 配置层。把 agentOptions 透传到 SpawnTeammateRequest 会让批评者 teammate 化的「按次 pin 模型」路由闭环真正可用。这与我在另一条讨论里做过的 subagent 模型路由/快照家族（per-call agentOptions 被吞、model-route 不走 per-call 参数）是同一类缺口——值得单独开一条，绑定 continuable 的 agentOptions 字段。

需要的话我可以给方案 1 出一份 reference patch（含对齐 tryMembership 返回结构 + 空渲染回归）。

[VillagerUncle02]

只补两点，都是确认性的——你这篇的根因分析我这边独立复现了，机制链条和你写的一致。

1. 版本确认：这个 bug 在 0.1.5-rc.1 上仍然存在（你报的是 0.1.3-alpha.1）。
   我这边用一次性子代理复现，失败会话的 turn/end 里是同一条
   agent "<child-session-id>" is not a member of an active Agent Team。

2. 一个可以直接观察的现场证据（对你说的"安装器在创建时刻把子代理误判为 Lead"
   是个直接印证）：把失败子代理自己的 system prompt 解出来，里面写着

   Your Team role is lead; your Team name is lead; Team id is <child-session-id>.
   

   也就是 team:policy 段在被装上的那一刻，确实把这个一次性子代理当成了 Lead。
   解剖跑的是"跑完 step 1（两次工具调用都成功）→ step/end 正常 → 推进 step 2 时 turn/end 报错"。

另外顺带一个观察，不知道和你那边是否一致：后台调用（run_in_background: true）能正常跑完，
显式 run_in_background: false 的前台调用必挂。 看到 #5550 的标题也是这么写的，
所以这个可能不是"随机"，而是按前台/后台路径确定性地分成两边——你原帖写的是"概率性地"，
如果这个规律更稳定，也许值得写进根因那一节。

影响的能力

• 子代理委派 / 多 Agent 编排：影响的是"能不能用一次性子代理"，与长任务上下文退化没有直接关系。
• 长任务相关：不是。