平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“DeepSeek Harness多Agent实践：4个内置工具+1个社区……”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。
在这个场景下，DeepSeek Harness（DSH）内置了 subagent、subagent_fork、workflow、ralph 四个多 Agent 编排工具，以及 list_agents、send_message、interrupt_agent 三个子 Agent 管理工具，全部开箱即用无需额外安装，是 DSH "一切皆插件"理念中少数内置于核心框架的能力之一。subagent 以完全独立的上下文运行子 Agent 同时在完成后得到结果，subagent_fork 则会将父会话历史一并传递，workflow 用来并行执行固定结构的批量任务，ralph 以"每轮换新 Agent + 结构化交接报告"的机制防止单 Agent 在同一思路上钻牛角尖；进阶场景可安装社区插件 @nanmicoder/dsh-agent-teams 获得任务依赖管理和持久化状态能力。本文给出每种工具的触发指令模板、选型速查表和常用踩坑，帮开发者在正确的场景用对多 Agent 工具。
为什么要用多 Agent
单 Agent 跑长任务有三个硬伤：
上下文污染：任务跑到一半，早期的上下文（包括已经完成的步骤、中间产物、错误信息）全部堆在同一个会话里，模型越来越难分清哪些信息是当前最重要的。
无法并行：单线程按顺序跑，审查代码、收集资料、写初稿这三件事只能排队，一件没完成就等着。
越跑越偏：长任务里模型容易在一个方向上钻牛角尖，反复尝试同一个失败的路径，浪费大量 token。
DSH 的多 Agent 方案核心是上下文隔离：每个子 Agent 只持有自己任务相关的上下文，主 Agent 负责拆解任务、派发、收集结果。整个过程 token 消耗可控，结果可追溯。
4 个内置派活工具
DSH 开箱即用，不需安装额外插件，直接对话就能调用这四个工具。
subagent：最常用的独立子 Agent
子 Agent 在完全独立的上下文里运行，不继承父会话的历史记录，任务完成后结果得到给主 Agent。
适合场景：任务之间相互独立、不需知道彼此的情况。
触发示例：
并行启动三个 subagent，分别完成：
1. 搜索「DeepSeek Harness 插件安全」的最新资料，整理成摘要
2. 搜索「DSH 多模态使用」的最新资料，整理成摘要
3. 搜索「DSH RC.8 更新内容」，整理成摘要
等三个都完成后，把结果合并给我。
指令需包含三个要素：任务拆分规则 + 等待机制（等都完成后）+ 输出要求（整理成摘要），缺少任何一个都容易出现任务遗漏或结果格式混乱。
subagent_fork：带父会话记忆的子 Agent
与 subagent 的区别：subagent_fork 会把父会话中已经完成的对话内容一同时传给子 Agent，子 Agent 知道"之前发生了什么"。
适合场景：子任务需基于主会话前期的分析结论继续推进，而不是从零开始。
基于我们刚才分析的这份代码仓库结构，
用 subagent_fork 启动两个子 Agent：
- 一个针对认证模块写单元测试
- 一个针对 API 层写集成测试
两个都完成后给我合并结果。
workflow：并行多任务，统一汇总
workflow 用来在脚本层面定义多个任务并行执行，全部完成后统一汇总。它比 subagent 更适合任务数量多、结构固定、需精确控制执行顺序的场景。
适合场景：批量处理（比如同时分析 10 篇文档）、多维度评测（同时跑 5 个基准测试）。
用 workflow 并行执行以下 5 项任务：
- 任务1：分析 auth.py 的安全风险
- 任务2：分析 api.py 的性能瓶颈
- 任务3：分析 db.py 的 SQL 注入风险
- 任务4：检查 tests/ 目录的覆盖率缺口
- 任务5：审查 README 的准确性
5 项全部完成后，生成一份综合报告。
ralph：防止钻牛角尖的迭代工具
ralph 的逻辑完全不同：它不是"多个 Agent 同时行"，而是每轮换一个新 Agent 来推进同一个目标落到代码里，。每轮结束后，当前 Agent 写一份结构化交接报告，下一轮新 Agent 读报告继续推进。
落到代码里，这解决了单 Agent 长任务中最常用的问题：在同一个错误思路上反复打转。新 Agent 不背历史包袱，从交接报告出发，更容易找到新路径。
适合场景：需多轮迭代、反复改进的复杂任务，比如逐步优化一篇文章、调试一个棘手的 Bug。
用 ralph 帮我把这份技术方案写好。
每轮结束后记录已完成的部分和下一步方向，
直到方案完整且逻辑自洽为止。
3 个管理工具：随时掌控子 Agent 状态
从实现思路看，派出去的子 Agent 不是"放出去不管了"，DSH 内置三个管理工具：
| 工具 | 用途 |
|---|---|
list_agents | 查看当前所有子 Agent 的运行状态 |
send_message | 给某个指定子 Agent 补充新要求，无需重新启动 |
interrupt_agent | 中断某个子 Agent 的任务（不销毁，可随时继续） |
interrupt_agent 的设计特别值得注意——它是暂停而非销毁落到代码里，。如果发现某个子 Agent 跑偏了，能够中断它，用 send_message 补充修正指令，再让它继续，不需从头再来。
Agent Teams：进阶多 Agent 协作
在这个场景下，若内置工具满足不了需求，DSH 官方提供了实验性扩展包 @deepseek-ai/dsh-experimental-tool-agent-team，在标准模式之外提供更完整的多 Agent 协作管理层。它默认禁用，需借助 Agent Teams profile patch 启用。
启用后，当前会话自动成为 Team Lead结合项目来看，（负责拆分和分配任务），能够借助 spawn_teammate 新建多个持久 Teammate 同时行工作，并借助 team_task_create、team_task_get、team_task_update 管理任务状态。核心工具：
| 工具 | 用途 |
|---|---|
spawn_teammate | 新建持久 Teammate Agent |
team_task_create | 新建带依赖关系的任务 |
team_task_list / team_task_get | 查看任务状态 |
followup_task | 追加后续任务 |
wait_agent | 等待指定 Teammate 完成 |
落到代码里，Agent Teams 是多 Teammate 协作拓扑，与内置的 subagent 星型拓扑不同。灵活性更高，但 token 消耗更多，适合需 Agent 之间反复协商、任务有依赖链的复杂场景。
工具选型速查
| 场景 | 建议工具 |
|---|---|
| 独立任务并行，互不干扰 | subagent |
| 子任务需基于前期分析继续 | subagent_fork |
| 固定结构的批量并行任务 | workflow |
| 需多轮迭代、防止钻牛角尖 | ralph |
| 长期协作 + 任务依赖 + Teammate 管理 | Agent Teams 扩展包 |
90% 的日常场景用 subagent 就够了。 workflow 适合批量操作，ralph 适合需反复打磨的创作或调试，Agent Teams 是重型武器，token 消耗和复杂度都更高，不建议随手用。
常用踩坑
并行写操作容易冲突：多个子 Agent 同时修改同一个文件，结果互相覆盖。多 Agent 最适合读操作在这个场景下，（搜索、分析、审查），写操作建议主 Agent 收到所有子 Agent 的结果后统一处理。
指令缺少等待机制：触发多个子 Agent 后没有写"等全部完成后再汇总"，主 Agent 可能在子 Agent 还在跑的时候就开始处理不完整的结果。
任务拆分太细：每个子 Agent 都有自己的启动成本，把一个 5 分钟任务拆成 10 个子 Agent 反而更慢。一般建议单个子 Agent 的任务量不低于"独立完成一件有意义的事"。
FAQ
Q：多个子 Agent 同时跑，API 费用会翻倍吗？
A：基本上是的——3 个子 Agent 同时发，消耗的 token 约等于 3 倍单 Agent。但总完成时间更短，适合对时间敏感、对成本相对不敏感的任务。用七牛云 AI 大模型广场（qiniu.com/ai/models）接入 DSH 时，能够按用量统一计费，便于对比多 Agent 和单 Agent 的实际成本差异。
Q：子 Agent 能够再派生子 Agent 吗（多级嵌套）？
A：技术上兼容，但强烈不建议。多级嵌套的任务链路难以追溯，出错后几乎无法定位是哪一级出的问题。保持星型结构（主 Agent → 子 Agent）是最稳的方案。
Q：subagent 和 subagent_fork 哪个更省 token？
A：subagent 更省，因为子 Agent 没有父会话的上下文包袱。如果子任务不需了解前期过程，优先用 subagent。
Q：DSH 的多 Agent 和 Claude Code 的 SubAgent 能互相调用吗？
A：RC.8 版本更新后，Claude Code 和 Codex 都能够作为 Profile Bundle 安装进 DSH，同时被 Harness 当作子代理调用。也就是说，DSH 能够在需时把某些子任务委托给 Claude Code 执行，再把结果收回来。
总结
结合项目来看，DSH 的多 Agent 体系由 4 个派活工具（subagent / subagent_fork / workflow / ralph）和 3 个管理工具（list_agents / send_message / interrupt_agent）构成，全部内置开箱即用。核心价值是上下文隔离落到代码里，——让每个子 Agent 只处理自己的任务，主 Agent 统一调度，避免单线程长任务的上下文污染和死胡同问题。进阶需求能够启用官方实验性 Agent Teams 扩展，获得任务依赖管理和持久 Teammate 协作能力。从同时行信息收集到多维代码审查，多 Agent 真正让"招一队黑色鲸鱼帮你干活"变成可操作的现实。
从实现思路看，以上就是DeepSeek Harness多Agent实战：4个内置工具+1个社区插件的详细内容，更多关于DeepSeek Harness多Agent的资料请关注脚本之家其它相关文章！