DSH 多 Agent 并发：哪些做法真的可行，哪些在烧 token
DeepSeek Harness 是插件化的，很多人搞明白这点之后的第一反应，就是同时拉起一堆 Agent 让它们一起干活。工具层面这确实很容易。但这是不是个好主意，是另一回事——答案几乎完全取决于任务长什么样。
这是一篇实战笔记，不是规格说明。只讲我在真实并行跑多个 DSH Agent 时，哪些东西经得起检验。
DSH 到底是怎么并行跑的
DSH 提供了几种不同的并发原语，行为各不相同：
- **子代理（Subagent）**默认在后台运行。你把一个自包含的任务委托出去，拿回一个句柄，等工作结束会收到通知。子代理有自己的上下文窗口，不会撑爆父会话的上下文，但 token 账单会随着数量叠加。
- **工作流（Workflow）**是大杀器：用一小段脚本把活扇出给大量子代理，分阶段推进。
parallel()是栅栏——等所有分支都跑完才继续；pipeline()让条目流水线式过阶段、没有栅栏，慢条目不会拖住其它。 - Goal 是一个长期目标，跨轮次持续推进，天然是串行的。
- Ralph 每轮开一个全新 Agent，不携带上一轮对话。
真正要分清楚的是：拉起（便宜）和协调（贵）是两码事。绝大多数翻车都发生在协调这一侧。
哪些任务能真正并行
「尴尬并行」的任务——没有共享状态、输入互相独立、输出结构化——扇出效果最好：
- **研究扇出。**把一个问题拆成五个角度，一个子代理管一个，最后合并笔记。五个分支彼此不需要交流。
- **逐文件 / 逐模块审查。**一个子代理读一个模块、返回发现的问题，什么都不写。
- **对抗式验证。**一个 Agent 写方案或补丁，第二个想办法挑刺，第三个拿来源核对结论。张力本身就是价值。
这三类的共同点：每个分支只产出文本、只返回结果，没有共享文件可以抢——这正是它们能跑通的原因。
会在哪里翻车
翻车模式相当一致，值得一条条列出来：
**共享工作区抢文件。**两个 Agent 写同一个文件，就是「后写覆盖先写」的竞态。看起来没事，直到某个 Agent 的修改悄悄消失。解法只有一条：一个写者，多个读者。
**成本是乘法。**十个 Agent 各自背几千 token 的上下文，就是单个的十倍开销。DeepSeek 侧 DSH 还是分时计价——北京时间 09:00–12:00 和 14:00–18:00 更贵。在错误的时间点来一次大扇出，一下午就能烧光余额。
栅栏等最慢的那个。parallel() 阶段要等最后一个分支结束才继续。一个卡住的 Agent——一次抖动、一个没人点确认的审批——就能拖垮整个阶段。
**不确定性。**调度顺序没有保证，两次完全相同的运行可能合并出略有差异的结果。研究场景无所谓，想要可复现就头疼。
**审批没法并行。**每次审批都是一次串行的人工卡点。如果活都卡在你的点击上，扇出帮不上忙，只会排队更多提示框。
值得抄的模式
- **先扇出，再合并。**多个子代理产出结构化结果，只由一个 Agent 做合并。合并步骤串行，但很便宜。
- **限制扇出规模。**三到五个分支就能拿到大部分收益，还不必付协调税。五十个 Agent 通常是在表态，不是策略。
- **一个写者，多个读者。**给每个文件或产物指定唯一的主人，其余分支只返回文本。
- **只在真需要全部结果时才用栅栏。**阶段彼此独立就流水线跑；只有「必须集齐全部再进下一步」时，栅栏才算物有所值。
- **重扇出放到低谷时段。**午间和 18:00 之后是便宜时段，把大并行任务攒到那会儿再跑。
结论
DSH 的并发是真实且有用的——只要任务形状对。瓶颈几乎从来不在「拉起」本身，而在协调、共享状态和成本。先拿两到四个子代理跑一个尴尬并行的任务，量一下 token 消耗和合并质量，再考虑要不要扩。
如果你是第一次搭多 Agent，快速开始 能先把单 Agent 跑起来，最佳实践 覆盖了工程卫生那一侧。目录里也有一批 工作流与自动化插件，不想自己写脚本可以直接组合。要是还在纠结 DSH 到底适不适合这个场景，这篇 和 Claude Code、Codex 等的对比 说得很清楚。