DSH 子代理（Subagent）实操教程
八个截图验证的步骤：在 spec 中定义子代理角色、并行启动子代理小队、读懂每份报告，并为每个子代理指定模型。
最近更新: 2026-09-15
DeepSeek Harness 里的子代理（subagent）是主会话用内置 subagent 工具派生出来的子智能体：它在自己的上下文窗口里后台完成一件被指派的任务，然后向调用它的主 Agent 回报。这种分工正是社区常说的 Agent Teams / 多智能体玩法——主 Agent 负责规划和汇总，便宜而专注的子代理去读代码、写代码、做验证。
本教程跟随一支真实录屏（来源见文末）逐步操作：用双 verifier 子代理设定构建一个小型书签应用，用 5 个空转子代理压力测试机制，再试验给子代理指定不同的模型供应商。每张截图都对照视频逐帧核验，并深链到取帧的精确秒数。
八步跑通 DSH 子代理
- 1
把子代理角色写进 spec
在 vault/spec.md 里加一段 subagents 小节，写清楚每个子代理的名字和职责。视频里加了两个：一个 mobile verifier，用 Chromium 确认视觉效果和 UX；一个 verifier，自行检查每个功能。同一份 spec 还要求每个功能带两个复选框——一个给初始实现，一个给单独的子代理验证——这样每个子代理只专注自己的任务，和主会话互不干扰。
子代理角色从 spec 里的几行大白话开始：谁验证什么、怎么验证。视频 30:48 处 - 2
让主 Agent 把角色细化成契约
让 DSH 细化这些子代理，并保持简单。它会把你的笔记改写成契约驱动的代理：verifier 跑纯函数单元测试、启动 API、检查每个接口契约和数据库状态（docker exec psql），输出 PASS 或 FAIL；UI verifier 用 Playwright 走移动端视口、深色模式和拖拽持久化。DSH 还会在这里追问技术选型、拖拽实现方式等澄清问题，然后才动笔。从这一步起，主 Agent 负责派发子代理并整理它们的报告。
DSH 把粗略角色变成带 PASS/FAIL 的契约，动笔前还会追问细节。视频 31:48 处 - 3
生成可直接实现的 spec，然后交出去
提示 DSH 把 spec 写得尽量完整，让普通子代理都能照着实现。回复是一份 11 节的定稿计划：技术栈、前置条件、仓库结构、环境与命令、数据模型、API 契约、前端行为（每个功能带实现/验证复选框）、纯逻辑、验证方案、构建顺序和完成定义。视频里的常用套路：对话、写 spec、做规划用更强的模型，机械执行交给便宜且容易验证的子代理。
$commit, then implement with subagents
spec 已达到可直接实现的标准——每个决定都敲定，便宜的子代理照做即可。视频 36:40 处 - 4
先跑一支空转小队，看懂 subagent 工具
先别急着上真活，用一条一次性提示词看懂机制。主会话会连续调用 5 次 subagent 工具——每个子代理一次——它们全部在后台运行（这里是 sleep 60），各自有自己的子代理 ID。聊天里会打印一张状态表：5 个并行运行，无需轮询，每个结束时运行时会通知主 Agent。
$Create 5 subagents that all have to wait 60 seconds
一句提示词、五次 subagent 工具调用——每个子代理都在后台带着自己的任务启动。视频 34:35 处 
5 个子代理、5 个 ID、一张状态表——并行运行，无需轮询。视频 34:42 处 - 5
在会话头部监控小队
子代理运行期间，会话头部会出现一个子代理计数器。点开可以看到每个子代理的名字、提示词、各自的 token 消耗和已运行时间。成本权衡就在这里一目了然：每个子代理单独计费，但每个都保持自己的上下文干净，主会话更专注，整体 token 往往反而更省。
每个子代理单独计费——在头部下拉里逐个查看 token 消耗。视频 34:52 处 - 6
阅读回传的报告
每个完成的子代理会以 subagent-report 上下文注入的形式回报给调用它的主 Agent，聊天里汇总结论：演示中 5 个子代理全部以退出码 0 完成 60 秒等待。点开头部下拉里的任意子代理，可以查看它收到的输入和它报告的内容。想看更完整的执行轨迹，去会话的 Trajectory 标签页。
完成的子代理以 subagent-report 注入回传给主 Agent，由聊天汇总。视频 35:05 处 - 7
给子代理指定不同模型
默认情况下子代理继承会话的供应商和模型——subagent 工具本身没有按次指定模型的参数。所以当视频要求两个子代理分别用 Claude Opus 和本地 Ollama 的 Qwen 3 时，DSH 给出了三个选项：推荐路线是带模型覆盖的 workflow 工具，它的 agent() 钩子接受每个子代理独立的 provider/model 设置；或者在部署配置里添加按模型区分的 subagent 工具实例后重启；也可以就让两个子代理都用继承的模型。
$Create two subagents both waiting 1 minute. One using opus, one using qwen3
想让一个子代理跑 Opus、另一个跑本地 Qwen？DSH 推荐 workflow 工具的按子代理模型覆盖。视频 42:10 处 - 8
读运行总结——收获时刻
长时间的自主构建会以一张 outcome 卡片收尾：spec → 构建 → 验证全流程由后台子代理一次跑完，产出一个可运行、已验证的应用——Express + Prisma + Postgres 的后端子代理、Vite + React 的前端子代理，以及执行检查清单的验证子代理——工作树已提交、干净。然后像视频里那样，点开团队构建出的应用，亲手确认 spec 里的功能真的能用。
收获卡片：spec 到构建到验证，由后台子代理端到端完成。视频 43:32 处 
团队的交付物：一个能亲手点验的可用书签应用。视频 44:13 处
DSH 子代理常见问题
关于子代理、成本、模型和监控的快速解答。
DSH 里的子代理（subagent）是什么？
主会话用内置 subagent 工具派生的子智能体：它在自己的上下文窗口里后台完成一件被指派的任务，然后向调用它的主 Agent 回报。主 Agent 始终负责派发子代理、整理它们的报告。
子代理会不会更费 token？
会——每个子代理都有自己的 token 消耗，在头部下拉里可以逐个查看，5 个子代理就是 5 次独立计费。换来的是干净得多的上下文：主会话只收每份报告而不是全部中间步骤，视频的结论是效果更好、整体 token 反而更省。
不同子代理能用不同模型吗？
原生 subagent 工具不行——它的参数里没有按次指定模型这一项，子代理继承会话的供应商和模型。正规做法是带模型覆盖的 workflow 工具：agent() 钩子接受每个子代理独立的 provider/model；也可以在部署配置里添加按模型区分的 subagent 工具实例后重启。
用子代理前必须先写 spec 吗？
不用。像「创建 5 个都等 60 秒的子代理」这样一句话的提示词就能做实验。spec 是为真实工作准备的：把验证角色和实现/验证复选框写进 vault/spec.md，才能像视频里那样一次性得到经过验证的成品。
Workflow 和 Agent Teams 有什么区别？
两者都在标准模式下使用。Workflow 是一支临时专家小组：执行前生成脚本、并行派生子代理、结果汇总给主 Agent，子代理之间互不可见。Agent Teams 则是一支可持续存在的团队：先建任务看板、分配成员，成员之间可以互发消息、多轮推进，最后由领队的主 Agent 汇总。一次性的并行验证选 Workflow，需要协作推进的大任务选 Agent Teams。
在哪里查看子代理做了什么？
三个地方：会话头部下拉列出每个子代理的提示词、token 消耗和运行时间；每个子代理的结果以 subagent-report 注入落在聊天里；Trajectory 标签页记录整个会话的完整执行轨迹。
相关 DeepSeek Harness 攻略
继续深入：预设、规划和 harness 的其余玩法，一次一篇。
来源与致谢
本页截图取自以下视频，版权归原作者所有——每张图都链回源视频中的精确时间点。中文《Agent Teams 实测》一期仅作事实参考，未取用任何画面。