让一支 agent 团队挺过崩溃重启
2026-09-12 · 10 分钟阅读
Team 插件把一个编码会话变成小型工作团队：会话里的 agent 成为 Lead，创建具名 teammate 处理委派工作，在公共任务板上跟踪共享任务。
和 subagent 的根本区别
表面上都是「派个助手去干活」，但设计目标不同。Team 的核心特性是消息与任务状态能挺过崩溃、reload 与中断——离线的 teammate 会在恢复后收到排队的消息。
这意味着它依赖持久会话存储。没有这个前提，Team 不会激活。
最小工作配置
对现有组合来说，最小增量是持久会话存储加两个 Team 包：
- name: '@deepseek-ai/dsh-session-persistence-jsonl'
- name: '@deepseek-ai/dsh-experimental-agent-team'
- name: '@deepseek-ai/dsh-experimental-tool-agent-team'注意分工：agent-team 本身不提供任何工具，必须配上 tool-agent-team，模型才能创建 teammate、给它们发消息、使用任务板。
包名里的
experimental 不是装饰——它以实验性名称公开发布，明确不承诺稳定性。生产环境用之前想清楚。装上之后怎么用
工具装好后，模型按请求完成其余工作。比如先让它「创建一个名为 reviewer 的 teammate 检查 diff」，再「把变更摘要发给 reviewer」。不需要额外配置。
资源限制
所有限制都是可选的，在启动时校验：
| 字段 | 默认值 | 含义 |
|---|---|---|
maxMembers | 16 | 最多可创建的 teammate 数，包括失败的 |
maxTasks | 256 | 任务板上最多的活动任务数 |
maxPendingMessagesPerMember | 64 | 单个成员最多可排队的消息数 |
maxMessageBytes | 65,536 | 单条发送消息的最大尺寸 |
disposalTimeoutMs | 5,000 | 关闭清理允许的时间 |
maxMembers 那条值得留意：失败的创建也占名额。如果 teammate 频繁创建失败，你会比预期更早撞到上限。
它有意不支持的场景
这部分比功能列表更重要，因为硬凑会浪费时间：
- teammate 需要独立工作目录 — 不支持。团队共享同一个工作区。
- 跨进程协调同一支团队 — 不支持。发起方归因只存在于进程内。
- 任务 owner 自动释放 — 不支持。
- 一个会话里跑多支团队 — 不支持。一个会话变成一支团队。
文档写得很直白：当多个 agent 必须在同一个共享工作区协作、且 roster、消息与任务状态需要挺过崩溃与重启时，才选它。
一个容易忽略的细节
发起方归因仅存在于进程内。跨 worker、进程、持久队列与重启时，它必须被显式传递。如果你依赖「谁发起了这个任务」来做权限或审计，重启后这个信息不会自动恢复。
小结
Team 适合那种「一个会话里几个角色长期协作、中间可能被打断」的场景。它的价值全在持久化上——如果不需要挺过重启，普通 subagent 更轻。