DeepSeek Harness 多 Agent 实战：4 个内置工具 + 1 个社区插件，让子 Agent 并发帮你干活
发布日期：2026-09-01 | 话题标签：DeepSeek Harness、多 Agent、SubAgent、Agent 编排
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 内置三个管理工具：
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 管理任务状态。核心工具：
Agent Teams 是多 Teammate 协作拓扑，与内置的 subagent 星型拓扑不同。灵活性更高，但 token 消耗更多，适合需要 Agent 之间反复协商、任务有依赖链的复杂场景。
工具选型速查
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 工具目录文档：https://deepseek-harness.github.io/deepseek-harness/
七牛云 AI 大模型广场（dsh可接入）：https://www.qiniu.com/ai/models
