AgentTeams 到底是什么
AgentTeams（@nanmicoder/dsh-agent-teams）把你当前正在使用的 DeepSeek Harness 会话变成一支小型代理团队的队长（captain）。你用自然语言描述目标，插件负责提供团队协议、协调工具、持久化状态与调度器，于是一个会话就能召集可持续的子代理、把目标拆成带依赖关系的任务，并通过直接消息协调工作。
它不是一个独立的工作流引擎，也不是第二套运行时。队员本身就是可继续（continuable）的 DSH 子代理，他们共享的状态写在磁盘上。包里声明了一个 dsh.bundle patch 与一个 Web 客户端半边：dsh.client.platform 为 web，注入七个包——六个 @deepseek-ai/dsh-client-* 入口，外加 @deepseek-ai/dsh-api-session-controller。因此你能看到的界面——活动面板、会话卡片、计划编辑器——属于 Web GUI，而不是终端。
它提供的能力
- 队长主导的委派。 首个会话负责建队、分配角色并汇总最终结果。核心协议已经写在队长的系统指令里，README 称它在历史压缩之后依然保留。
- 持久化的名册。 队员是可继续的子代理，可以被唤醒执行聚焦的后续回合。
- 感知依赖的任务。 任务按显式状态流转，依赖未完成前不能被认领。队长持有 13 个协调工具；队员拿到 4 个团队工具，以及他们原本的编码与研究工具。
- 共享调度器与信箱。 调度器依据真实的
running / idle / ready状态，为每个空闲队员原子性地认领一个就绪任务并唤醒它。无法实时送达的消息留在持久信箱中，在后续的状态边界重试。 - 斜杠命令。
/agent-teams <目标>是一个闭命名空间的宿主命令，因此不需要说「use AgentTeams」这类措辞；命令行本身会作为普通后续消息保留在对话里。 - 实时活动面板。 Web UI 把分段进度、可折叠名册与可交互的任务 DAG 组合在一起；运行中的任务会显示队员所用的模型，归档记录会保留完整的队员与任务历史。
- 先计划、后执行。 普通运行会先暂存一份尚未生成的名册与 DAG——不创建任何子会话，也不认领任何任务。只有点击 Approve & Run 才会启用调度，且每个队员的会话在其首个任务就绪时才创建。
运行要求
包的 engines 字段要求 Node ^22.19.0 || >=24。README 推荐 DeepSeek Harness 0.1.5-rc.1，并在兼容性列表中保留三个更旧的宿主目标：0.1.2-rc.1、0.1.2-alpha.5 与 0.1.2-alpha.2；它建议使用更旧或未列出宿主的用户维持一对可用的版本组合，并参考旧版本与诊断指南。README 明确说明：安装插件不会升级 Harness 本身，而桌面应用内嵌自己的 Harness 内核，升级全局 CLI 并不会升级那个内核。
两份来源都没有提到任何 API Key、模型供应商、账号、操作系统或磁盘空间要求。它们提到的只是：该包没有 dependencies，它需要的宿主包全部声明为 24 个 peerDependencies，且每一个都标记为可选；许可证为 MIT，作者是程序员阿江（Relakkes）。
版本疑问：0.1.18 与 0.1.17
本条目所依据的两份来源彼此矛盾，这里选择把矛盾讲清楚，而不是悄悄挑一个。已发布的 package.json 声明 "version": "0.1.18"；而 README 的整套安装叙事围绕 0.1.17 展开：推荐组合是 Harness 0.1.5-rc.1 搭配 AgentTeams 0.1.17，发布说明写的是 v0.1.17，README 还说明 npm 的默认 latest 标签指向 0.1.17，因此全新 profile 即使不加精确版本也会解析到它。
仅凭这两份文件，读者无法判断今天全新安装实际会拿到哪一个版本。请把 0.1.18 当作清单的声明、把 0.1.17 当作文档的指示；如果这个差异对你重要，请以注册表为准自行核实。
已知限制
memberMaxDepth默认为0，因此队员不能创建嵌套子代理。设为1才显式允许一层后代，README 还指出该限制同样覆盖 runtime 与代码工具的调用。- 一个队长同一时间只带领一支活动团队。
- 状态以文件形式落盘，位于
<workspace>/.agent-teams/，并在单个 DSH 进程内串行化。多个进程同时编辑同一支团队不会被协调——它不是多进程或多用户协议。 - 面板如实反映已持久化的状态。 README 提醒：模型偶尔会在没有执行预期任务状态更新的情况下结束工作，因此 DAG 可能落后于现实。
- 范围控制是完成时的审计，不是宿主层的写入拦截。 可选的质量门在事后检查「需求 → 实现 → 验证 → 评审 → 集成」，并不会在写入发生的那一刻阻止它。
- 没有按队员区分模型或推理提示词。 只有明确的异构团队请求才会提供队员专属的 provider 与 model；与队长同路由的队员继承其快照，后续继续也恢复该快照。
- 没有给出任何成本、token、速率或并发上限。
maxMembers: 8只出现在 README 的一个配置示例里——两份来源都没有把它称作默认值或硬上限，请不要把它当成团队规模的保证。 - 仍然持有未结尝试（attempt）的空闲队员会一直停驻，直到被消息唤醒或被显式重新指派。
- 历史面板需要已保存的团队状态或归档；早期版本中删除团队且未保留归档的会话，无法从日志完整还原面板。
什么时候用它、什么时候不要用
当同一个工作区里的目标确实能按视角拆开——例如一次横跨性能、安全与产品角度的评审，或者调研喂给实现、实现再喂给验证的链路——而你又希望这种拆分能跨回合存续、有可见的 DAG 和谁做了什么事的记录，那就用它。「先计划、后批准」的暂存机制正是它优于随手委派的地方：在你批准之前，不生成任何子会话，也不认领任何工作。
如果你需要跨多个并发 DSH 进程协调工作、需要超过一层的嵌套委派、需要插件强制执行硬性的预算或团队规模上限，或者需要在执行过程中阻止写入（而不只是事后审计），就不要选它——这些它都没有声明。也不要把当作 DSH 原生 sub-agent 工具的替代品：README 说明默认队员只通过团队消息汇报，正是为了避免与原生父级汇报重复，也就是说它的设计前提是与原生工具共存。
这两份来源没有说明什么
遥测、对外网络访问与凭证处理，两份文件在任何方向上都没有提及。两份来源也都没有作出性能或基准测试方面的声明，同样没有任何内容描述云存储、操作系统级沙箱或多用户运行。本条目自身的元数据里带有数字与一个兼容目标，但那些来自目录的策展数据，并不由上面引用的 README 或清单所主张。如果本页与你亲自阅读来源所得的结论不一致，请以来源为准。
FAQ
AgentTeams 会创建嵌套子代理吗？
不会。memberMaxDepth 默认为 0，来源明确说明这是为了阻止队员创建嵌套子代理；README 还指出该限制覆盖 runtime 与代码工具的调用。设为 1 才是显式开启一层后代。
我到底应该安装哪个版本？
来源彼此矛盾，因此本页不替你选择。package.json 声明 0.1.18；README 推荐 0.1.17，并称 npm 的 latest 标签指向 0.1.17。锁定版本前请先向注册表核实。
有团队规模、成本或并发上限吗？
没有给出任何上限。maxMembers: 8 只作为配置示例中的一个值出现，从未被描述为默认值或上限，因此不应被当作上限引用。
活动面板能当作事实依据吗？
它如实反映已持久化的状态。README 提醒模型偶尔会在未执行预期任务状态更新的情况下结束工作，因此把看起来滞后的 DAG 视为一种已知的失效模式，而不是可以排除的偶发故障。
它会取代 DSH 原生的 sub-agent 工具吗？
来源没有作出这样的声明。队员建立在可继续的子代理之上，而 README 说明默认队员只通过团队消息汇报，以避免与原生父级汇报重复——这个插件被设计为与原生的工具并存。