DSH plugin 多智能体团队怎么用？DeepSeek Harness 智能体团队编排上手

dsh-agent-teams 把当前 DeepSeek Harness 会话变成「队长」：它组建一个持久子代理团队，把目标拆成带依赖关系的任务，再用共享调度器自动派活（来源）。 上手只要三步——装上、把大目标交给它、用面板看进度。它自带团队协议、14 个协调工具、持久状态与实时 Web 面板，不需要另装工作流引擎。想知道社区里还有哪些智能体 / 子代理类插件，可以到 DSH Plugin Hub 按用途筛选核对。（这里的插件，中文也常写作 DSH插件、DeepSeek插件。）

dsh-agent-teams 这个 DSH plugin 是什么：把当前会话变成队长

它的角色分工很明确：队长拆目标，成员干活，调度器按依赖发任务（来源）。 四个关键机制：

1. 队长委派：当前会话创建团队、给成员分配角色，最后汇总成一份结果；
2. 持久成员：成员是可续跑的子代理（sub-agent），闲下来能被再次唤醒做后续回合，不是一次性用完就丢；
3. 依赖感知任务：任务有显式状态，依赖没完成的任务不能被认领，避免抢跑；
4. 直接消息与实时面板：成员之间、成员与队长之间直接发持久消息，不必经你中转；Web 面板把分段进度、成员名册与可交互的任务依赖图放在一起。

状态是文件为真相的：团队数据存在工作区的 .agent-teams/ 目录下，Web 面板读这份磁盘状态再叠加实时的子代理活动。

DSH plugin 的团队状态存在哪：一份磁盘记录，面板只是窗口

理解「状态在磁盘、面板只是窗口」，很多行为就顺了（来源）。 一次组队会产生几类记录：

结论有三条：第一，关掉面板不等于停掉团队——状态在磁盘上，从对话里可以重新打开；第二，面板显示的是已持久化的状态，模型偶尔干完活没更新任务状态，面板就如实显示旧状态；第三，同一时刻只有一个队长带一个活跃团队，状态文件在单个进程内串行，多个进程同时改同一个团队不会被协调。

DSH plugin 上手三步：装上、派活、看进度面板

装 → 派活 → 看面板，三步之间只隔一次重启（来源）。 按这个顺序走：

1. 装上。CLI / Web 用：

dsh plugin --profile web add --save-exact @nanmicoder/dsh-agent-teams@0.1.23

--profile 换成你实际使用的 profile 名。装完重启该 profile 的进程并刷新浏览器——装插件不会顺带升级宿主，插件与宿主各有自己的 latest 通道。桌面端则在侧边栏打开 Plugins → Add plugin，填入包规格 @nanmicoder/dsh-agent-teams@0.1.23，安装后选择 Enable now，如果宿主提示重启就重启桌面端。注意要填的是包规格，不是 npm 或 GitHub 的网页地址。

2. 派活。它注册了 /agent-teams 命令，无需任何「请使用 AgentTeams」这类话术：

/agent-teams 从性能、安全、产品三个角度评审 v0.5.3 之后的提交，汇总成一份报告

自然语言直接说明需求也能触发。默认流程是计划先行：先给你一份还没启动的成员名单与任务依赖图，只有点了 Approve & Run 才真正开始调度，每个成员从自己第一个就绪任务开始。

3. 看进度。在当前对话头部或回复下方的团队卡片点 View team，打开原生的 Team collaboration 标签页。宽窗口分栏、窄窗口堆叠；点任务能定位到负责人，点成员图标能打开他的会话。关掉这个标签页不会停掉团队，从对话里可以重新打开；已完成的团队保留完整归档。

DSH plugin 什么任务值得组队，什么任务反而更慢

判断标准只有一条：任务能不能拆成彼此独立、可以同时推进的子任务（来源）。 先看一张速判表：

值得组队的典型：

1. 多角度评审：同一批改动交给不同角色的成员（性能 / 安全 / 产品）并行看，最后合并成一份报告；
2. 多来源调研：几个互不依赖的调研分支同时跑，成员各自带回结论；
3. 跨模块并行改造：模块边界清晰、改动互不冲突的工程任务。

不值得组队的典型：

1. 改一个文件的小活：拆出来的协调开销比干活本身还大；
2. 串行强耦合：每一步都要等上一步结果，依赖图会退化成一条线，组队没有任何加速；
3. 需要频繁来回确认：队长还要先出计划等你确认，小任务走这条路是绕远。

DSH plugin 与官方子代理机制的关系和成员边界

成员就是子代理：成员后端走的是 DeepSeek Harness 的 subagent 机制，memberProvider 指的是子代理运行时后端（spawn / fork），不是 LLM 提供商（来源）。 几条边界要清楚：

1. 默认成员零交互：成员默认沿用队长当前的模型路由，自动快照 provider、model 与推理强度；只有你明确要求异构团队时，才需要给成员指定 provider + model；
2. 默认可“换模型后端”但不换 LLM 源：memberProvider 只切换子代理的运行方式；要跨模型提供商路由，用成员级可选字段；
3. 嵌套默认关闭：memberMaxDepth 默认 0，成员不能再建嵌套子代理，设 1 才放行一层；
4. 工具策略是可见性而不是沙箱：toolPolicies 的 allow / deny 剪裁的是模型能看到的全局工具，属于策略层，不等于操作系统沙箱或授权边界；
5. 一个队长一个活跃团队：队长同时只带一个团队；状态文件在单个进程内串行，多个进程同时改同一个团队不会被协调；
6. 面板如实呈现持久状态：模型偶尔可能干完活却没做任务状态更新，面板显示的是已持久化的状态。

想更深入配置 subagent 委派本身（提供方如何注册、怎么按名称挑后端），见《怎么配置 subagent 委派》；日常装 / 卸插件的命令细节见《dsh plugin remove 怎么卸载插件》。

DSH plugin 组队真的跑起来了吗：三步核对一遍

别只看面板「有没有东西」——分三层核对：装上了、被加载、状态在写盘（来源）。

# 1) 插件是否进入了该 profile 的依赖清单
grep -A5 '"dependencies"' "$DSH_HOME/profiles/web/package.json"
# 应看到 "@nanmicoder/dsh-agent-teams"

# 2) 该 profile 的加载清单里是否引用了它
grep -R "agent-teams" "$DSH_HOME/profiles/web/cordis.patch.yml"
# 应有命中（宿主重启后由加载清单拉起）

# 3) 团队状态目录是否已生成
ls -la .agent-teams/
# 应看到本次团队的成员与任务记录

预期：三处都能对上，说明「装上 → 被加载 → 团队状态在写盘」这条链路是通的。若第 1 步没有而第 2 步有，多半是装到了别的 profile，--profile 要和你实际运行的一致；若第 3 步为空，通常是还没点 Approve & Run，或团队尚未开始调度。

关于 dsh-agent-teams 这个 DSH plugin 的注意事项

一句话总结：它适合能拆的并行活，装完记得重启宿主进程。

1. 装的是包规格：@nanmicoder/dsh-agent-teams@0.1.23，不是网页地址；Git 安装要用带构建产物的提交；
2. 宿主版本要对：该插件推荐搭配的宿主是 0.2.0-rc.2，宿主仍是 RC 版本，两者各有独立的 latest 通道；
3. 装完要重启：改完插件不重启，进程里还是旧的一套；
4. 小任务别组队：协调开销与计划确认会拖慢简单任务；
5. 默认不嵌套：成员默认不能再建子代理，需要时显式开一层；
6. 先计划后执行：默认要给计划点 Approve & Run 才会调度，这是有意的确认闸门；
7. 同类插件到市场核对：DSH Plugin Hub 里能对比智能体 / 子代理类插件与来源仓库。

关于 DSH plugin 多智能体团队的常见误解

五个高频误判，逐条纠正（来源）：

1. 「装上就会自动开跑」——不会。默认计划先行，你点了 Approve & Run 才真正开始调度。
2. 「成员是另开的模型账号」——不是。成员默认沿用队长的模型路由自动快照；memberProvider 换的是子代理的运行后端（spawn / fork），不是 LLM 提供商。
3. 「关掉面板就把团队停了」——不会。状态存在工作区 .agent-teams/ 里，关标签页不停团队，可随时重新打开。
4. 「toolPolicies 是安全沙箱」——不是。它剪裁的是模型能看到的全局工具，属模型侧可见性与调用策略，不构成操作系统级隔离或授权边界。
5. 「成员可以无限套娃」——不行。memberMaxDepth 默认 0，要显式设为 1 才允许一层下级子代理。

来源：DeepSeek Harness 官方文档 - Subagent 子系统、DeepSeek Harness CLI 官方 README、社区插件仓库 - dsh-agent-teams、dsh-agent-teams 插件条目。