一句话，拉起来一支完整技术部
专家团是装在 DeepSeek Harness（dsh）上的插件。它给中小团队与个人接单者一支「完整技术部」： 12 个角色按 9 阶段门控流水线协作，实现者直接改你工作区的代码，全过程留痕成可复核的工件。
$ dsh plugin --profile web add @yangdcm/dsh-expert-team # 第二步：重启一次 dsh web # （插件加载时自动铺好「专家团模式」预设） # 第三步：开新会话 → 切到「专家团模式」 /team 做一个带登录的支付模块
01数字
六个数字，说清它的量级
只列包内 README（1.3.32）口径的数字，不新增、不外推。
toolFilter / maxDepth: 1npm run test:all，零依赖、无需 install，CI 跑的就是它dependencies: {}prepare/postinstall 钩子0230 秒看懂
一条 9 阶段门控流水线
你只给一句话，团队按流水线推进；每次交接都走「结构化返回值 + 工件文件」双通道，状态不靠聊天记录传递。 两道门卡在关键位置：规格评审硬门与方案确认门。
SPEC.mdprefers-reduced-motion: reduce 下停止自动播放，只留静态全展现。
你只出两样东西
一句话目标 + 关键决策。其余由团队按角色分工推进，lead（你）只拍板产品级与范围级决策。
工件是唯一真源
每个工件由产出它的角色自己写进 run 目录；lead 只读工件做门控与裁决。浮层只是它的视图。
门是代码强制的
状态机一致性由插件代码强制，不是提示词请求：未完成任务不能标 completed。
03动机
为什么不是「一个 agent 硬做」
长任务上反复出现的三个固定失败模式，以及四件对策。
失败模式一 · 上下文漂移
长任务越做越偏，早期定下的边界在几十轮之后已经不在模型的有效视野里。
失败模式二 · 自己批自己
同一个执行者既写代码又宣布「没问题」，没有独立验证环节。
失败模式三 · 返工不收敛
同一个问题来回改，没有超轮次返工判定，收不了口。
四件对策
1 · 角色分工
12 个角色各带独立人设、工具边界 toolFilter、委派深度 maxDepth: 1。
产品 / 架构只读写计划工件，审查 / 安全只读，实现者才动代码。
2 · 阶段门控
9 个阶段，每次交接走「结构化返回值 + 工件文件」双通道；状态不靠聊天记录传递。
3 · 质量门禁
状态机一致性由插件代码强制，不是提示词请求；未完成任务不能标 completed；
质量问题必须由 qa/reviewer 裁决；覆盖率缺口与超轮次返工当场判出并实时显示在浮层与
/team status；写侧归属门禁：非负责人覆写他人工件当场拒绝，创建放行。
4 · 收敛与记账
每 run 记 token / 耗时 / 首产物时间 / 收尾预算；/team learn 跨 run 蒸馏经验，并在下次开工前回注。
04产品界面
浮层与画布长什么样
常驻状态条、live 团队浮层、全屏画布都只是工件的视图，工件才是真源。 下面这个界面是按真实浮层结构用 HTML/CSS/SVG 自绘的仿制品（不是截图、不加载任何图片）， 它把「阶段 / 成员与逐角色模型 / 任务依赖图 / 门禁违规 / 工件预览」放在同一屏里。
TASKS.json
11 节点 · 含返工闭环
05角色
12 个角色，各带独立边界
每个角色有自己的代码标识与一句话职责。关键约束：只有实现者动代码
（backend / frontend 各改自己那份文件），reviewer 不能自批自过。
| 标识 | 角色 | 一句话职责 |
|---|---|---|
| pm | 产品 | 澄清需求、写 SPEC.md，把边界与禁止项前置。 |
| architect | 架构 | 方案与模块划分、依赖 DAG、AUTHORITY.md 单源。 |
| researcher | 技术调研 | 取舍与出处，给结论不给流水账。 |
| ui | UI/UX | 界面结构与交互。 |
| backend | 后端 | 只有实现者动代码，改自己那份文件。 |
| frontend | 前端 | 只有实现者动代码，改自己那份文件。 |
| dba | 数据 | schema / 迁移 / 查询。 |
| sec | 安全审计 | 越权、注入、密钥与依赖风险。 |
| reviewer | 代码评审 | 独立评审，不能自批自过。 |
| qa | 测试 | 覆盖缺口、边界用例、验收判据。 |
| devops | 运维 | 构建、发布、环境与配置。 |
| docs | 技术文档 | README / 手册 / 变更记录。 |
另有 lead（你）
只拍板产品级与范围级决策，其余由团队推进。lead 只读工件做门控与裁决，不替角色写工件。
06架构分层
三层结构，两道真实存在的拦截
你（lead）在第 0 层，只读工件做门控裁决；12 个角色在第 1 层，
各带人设 / toolFilter / maxDepth: 1（角色不能再往下委派）；
宿主工具面在更下层。角色与工具之间的每一次调用都要穿过宿主钩子：
写侧门禁挂在 tools/pre-execute，规格硬门挂在 tools/post-execute。
写侧归属门禁
挂在 tools/pre-execute：创建放行、覆写他人工件当场拒绝。残余绕过面：持 bash 的角色仍可能绕过（见 lib/artifact-ownership.js）。
规格评审硬门
挂在 tools/post-execute：SPEC.md 的「边界与禁止项」章节没填就不放行进实现，由 lib/interception.js 当场判出并顶回。
为什么必须有这两道钩子
门是代码强制，不是提示词请求：它拦在宿主工具调用的路径上，模型无法「忘了」它。工件是唯一真源，浮层只是它的视图。
07门控
9 阶段流水线 + 三道门
阶段顺序固定：clarify 澄清 → research 调研 → design 设计 →
spec-review 规格评审（硬门）→ 方案确认（确认门，默认开、可关）→
implement 实现（按依赖 DAG 并行扇出）→ review 审查 → test 测试 → deliver 交付。
门一硬门
规格评审硬门
SPEC.md 的「边界与禁止项」章节没填就不放行进实现，
由 lib/interception.js 挂在宿主 tools/post-execute 上当场判出并顶回。
—— 不是提示词提醒，是拦截。
门二确认门
方案确认门
默认开启，可在设置关掉（identity.keepPlanGate）。
开着的时候，方案要你点头才进实现。
门三写侧
写侧归属门禁
挂 tools/pre-execute：创建放行、覆写他人工件当场拒绝。
诚实边界：持 bash 的角色仍可能绕过它（见 lib/artifact-ownership.js）。
质量门禁的几个具体判据
- 状态机一致性由插件代码强制（不是提示词请求）：未完成任务不能标
completed。 - 质量问题必须由
qa/reviewer裁决，执行者不能自己宣布通过。 - 覆盖率缺口与超轮次返工当场判出，并实时显示在浮层与
/team status。
08流程档位
三档位：每次新建 team 都要选一次
口径：档位只裁「角色与独立环节」，不裁验收面 —— 任何档位都必须做 clarify 与交付前真实校验；
通过率红线永远 100%；不允许降档。
| 档位 | 适用 | 阶段 | 角色上限 |
|---|---|---|---|
| 快速档 quick | 单页工具 / 单模块 / 原型 / 一次性脚本 | clarify → implement → test → deliver |
≤ 3 |
| 标准档 standard | 常规功能开发、中等重构 | 全流水线 | ≤ 6 |
| 严格档 strict | 安全 / 支付 / 权限 / 数据迁移 / 跨模块重构 | 全流水线 | ≤ 12 |
档位只裁角色与环节
裁的是「要几个角色、跑几个独立环节」，不裁验收面：任何档位都要做 clarify，也要在交付前做真实校验。
通过率红线 100%
红线不随档位下降；不允许降档。档位是开工前的一次选择，不是中途的逃生门。
每次新建 team 都要选一次
可用 /team --tier <档位> 指定；不选则由 lead 按任务性质定档。
09过程可见
你在界面上能看到什么
常驻状态条、live 团队浮层、全屏画布、设置页。浮层只是工件的视图，工件才是真源。
常驻状态条 · 有子代理在跑
琥珀色横幅，显示最多 3 个角色名 + 跳动圆点，点击直接打开团队面板。位置在输入框上方。
常驻状态条 · 空闲
没在跑时只剩一行暗灰字，不占视觉注意力。
live 团队浮层
阶段 / 成员与逐角色模型 / 工件预览 / 人工决策按钮。
全屏画布 · /team canvas
四视角：人 / 事 / 料 / 盘，含任务依赖图与返工闭环。
设置页
官方 设置 →「专家团」，中文标签，改动即保存并即时生效： 上限 / 轮次 / 档位门 / 振荡检测在进程内重算。
10命令
常用命令表
全部是 host 平面命令；下方命令块可一键复制（键盘 Tab 到按钮后按 Enter 同样可用）。
| 命令 | 作用 |
|---|---|
| /team <一句话目标> | 一句话组队。 |
| /team --persist | 持久化活团队（可反复指挥、跨会话恢复）。 |
| /team --one-shot | 反向覆盖（回到一次性组队）。 |
| /team --no-code | 只出工件不改代码。 |
| /team --code | 反向覆盖（允许改代码）。 |
| /team --confirm | 先建 run、浮层点「执行」才开工。 |
| /team --tier <档位> | 指定档位（quick / standard / strict）。 |
| /team status | 所有 run 的阶段 / 成员 / 模型计划 / 实时违规。 |
| /team models | 逐角色成本与模型计划。 |
| /team canvas | 可视化画布。 |
| /team learn | 聚合 → METRICS.md + 蒸馏经验。 |
| /team resume <run-id> | 跨会话恢复。 |
| /team uninstall | 回收副本。 |
# 1) 装插件（profile web） $ dsh plugin --profile web add @yangdcm/dsh-expert-team # 2) 重启一次 dsh web（插件加载时自动把「专家团模式」预设铺好） $ dsh web # 3) 开新会话 → 切到「专家团模式」 → 一句话组队 /team 做一个带登录的支付模块
要求
dsh web（验证基线 0.1.5-rc.1）、Node.js ≥ 20、profile web（浮层需要；无浮层场景 /team 与工件协议照常可用）。
推荐依赖 · Hindsight
跨项目记忆，推荐但不装也能跑：不装不报错、团队照常交付，只是跨项目记忆那一环不生效，团队自身跨 run 学习走本地 LEARNINGS.md。
可选依赖
dsh-cost-meter（会话费用视图，可选）；dshmarket（只在用插件市场安装 / 备份恢复时需要）。
11产物落盘
工件是唯一真源
每个工件由产出它的角色自己写进 run 目录，lead 只读工件做门控与裁决；浮层只是它的视图。
run 目录
其它位置
- 本机偏好与跨项目经验：
$DSH_HOME/expert-team/ - 聚合快照：
METRICS.md在team/根，由/team learn产出
聚合与记账
- 每 run 记 token / 耗时 / 首产物时间 / 收尾预算。
/team learn跨 run 蒸馏经验，并在下次开工前回注。
12实测性能
真机实测（数字带条件）
以下均为真机实测；机器负载会影响绝对值。
| 指标 | 实测 | 条件 |
|---|---|---|
| ?section=summary 响应 | 中位 3.5–5.8 ms | 真机（1.3.20 起）；95 个子代理 / 13 条 STATE.members / 104 个任务 |
| ?section=people,feed 响应 | 4–13 ms（1.3.19 为 ~280 ms/次，约 70×） | 同上；提速没有靠丢成员 |
| 历史最差（1.3.5 已修） | 热态 7.1–9.8 s、冷态 283.6 s | 1.3.5 之前 /state 逐条全量读 75 个子会话日志，并堵住 dsh web 事件循环 |
必须附注：以上是真机实测，机器负载会影响绝对值，不同负载下的数字不可直接比；
state-perf-guard.test.mjs 守着性能不许回退。
13适用性与边界
如实写清的残余风险
这一节用独立视觉区分，因为它讲的是「不保证什么」，和上面讲能力的部分不是一回事。
01本机来源守卫已就位，但不是鉴权
- 浮层路由统一校验 Host（挡 DNS rebinding）、写方法 Origin（挡跨站写入）、客户端地址（挡局域网），写方法还要求
application/json。 - 残余风险如实说明：本地非浏览器进程本来就能自造任意请求头，而 dsh 插件没有鉴权模型，别把
dsh web暴露到不可信网络。
02profile 与写侧门禁的残余绕过面
- 浮层需要
webprofile；其它 profile 下/team与工件协议照常可用。 - 写侧门禁的残余绕过面：持
bash的角色仍可能绕过（见lib/artifact-ownership.js）。
03装上后会改宿主 GUI 一处展示顺序
- 子代理列表「最新在上」，默认开、可关
display.subagentListNewestFirst。 - 它只改展示顺序，服务端契约与模型侧结果原样不动；宿主结构不匹配时自动退回默认并如实显示「未生效」。
04未接线项不装作可用
- 设置项要么真的生效，要么标为「暂未生效」，由
settings-consumers.test.mjs盯着（目前该表为空）。
0589 个测试文件是可复现的验证面
npm run test:all零依赖、无需 install，CI 跑的就是它；但它是可复现的验证面，不等于「所有真实环境组合都被覆盖」。
163 条变异目录 · 诚实边界
CI 校验的是形状：id 唯一、每条变异体的 find 串在目标文件恰好命中一次、条数与常量一致；
变异体本身需手动注入，CI 目前不执行变异体 ⇒ 它是「防呆 + 防漂移」，不是「自动证明测试能抓错」。
89 个测试文件的边界
npm run test:all 零依赖、无需 install，CI 跑的就是它 —— 这是可复现的验证面，但它不等于「所有真实环境组合都被覆盖」。
14FAQ
常见问题
答案按包内 README 口径照抄，不加工。summary 是原生可聚焦元素，Tab 到后按 Enter 即可展开。
它到底是什么？
装在本机 dsh 上的插件；/team <一句话目标> 拉起 12 角色 subagent 团队，
按 9 阶段门控在你的工作区交付。
必须再装别的插件吗？
不必，零运行时依赖。
支持哪些 dsh 版本？
engines.dsh: >=0.1.5-rc.1（验证基线），Node.js ≥ 20。
数据放在哪？
工件在 <workspace>/team/<run-id>/；本机偏好在 $DSH_HOME/expert-team/。
怎么卸载？
/team uninstall 回收铺到 $DSH_HOME 的副本（skill 走运行时注册、本就不落地），
再从命令行或插件市场移除；注意 LEARNINGS.md 等是你的数据，卸载不会删。
会自己联网吗？
不会主动联网，只调用宿主提供的工具；能不能联网取决于你给会话的工具面。
不切「专家团模式」preset 也能用吗？
能，/team 是 host 平面命令，任何预设下都能跑；此时退回通用 subagent（角色人设写进 prompt），
少的是配置层边界保证（toolFilter / maxDepth: 1）。