复杂任务一来，最直觉的做法是“多开几个 Agent”。但 Agent 数量不是能力，编排方式才是。拆得不对，常见结果是多个子 Agent 重复读仓库、互相覆盖文件，最后父 Agent 还要花更多上下文整理冲突。
DeepSeek Harness 中最容易混淆的是 Subagent、Workflow、Goal 和 Ralph。它们都能推进复杂工作，却解决不同问题。
一张选择表
| 机制 | 核心用途 | 上下文特点 | 适合任务 |
|---|---|---|---|
| Subagent | 有界委派 | 子任务上下文独立或按 Provider 规则继承 | 调研、审查、局部实现 |
| Workflow | 固定编排 | 由脚本定义步骤、分支与并发 | 可重复的多阶段流程 |
| Goal | 同一会话持续推进 | 保留当前会话连续性 | 普通长任务、阶段性执行 |
| Ralph | 每轮新 Agent 迭代 | 不复制父会话；工作区和有界 handoff 传递状态 | 明确要求的 fresh-agent 循环 |
Subagent：先从有界委派开始
Subagent 最适合“输入清楚、产出清楚、范围有限”的工作。例如让一个子 Agent 只审查数据库迁移，让另一个只核对 API 文档。父 Agent 应给出文件范围、验收标准和返回格式，而不是一句“帮我研究一下”。
并行只适合彼此独立的任务。如果两个子 Agent 同时修改同一文件，调度速度提升很可能被冲突抵消。默认先并行只读调查，再由一个明确所有者落地修改。
Workflow：把流程控制权交给部署
当步骤顺序、并发上限、失败分支和输出 Schema 应由系统决定，而不是让模型临场发挥时，用 Workflow。典型例子是：并行检查前端、后端和依赖风险；汇总结果；只有满足门槛才进入修复阶段。
Workflow 的价值是可重复和可治理。模型提供任务数据，部署控制脚本、路由与资源上限。它比“请模型自己连续调用五次子 Agent”更容易测试。
Goal：同一会话里的长期目标
Goal 适合需要持续规划、执行、验证的普通长任务。它保留会话上下文，因此前面确认过的约束不必每轮重新压缩传递。代价是上下文会增长，错误假设也可能一路带下去。
使用 Goal 时，把目标写成完成条件：哪些测试必须通过、哪些文件不能动、什么情况算阻塞。不要只写“完成重构”。
Ralph：用新鲜上下文反复攻坚
官方 Ralph 工具每轮启动一个新的子 Agent，目标保持不变；新一轮不继承父对话或前一轮完整会话，只接收共享工作区和上一轮有界结构化报告。终止状态包括完成、阻塞或达到预算/轮次上限。
这能减少长对话中的上下文污染，但每轮都要重新理解任务，并且 worker 报告的“完成”不会被自动独立验证。官方明确建议：只有用户直接要求 Ralph/fresh-agent 迭代时才使用；普通长任务用 Goal，有界委派用 Subagent 或 Workflow。
四个工程约束
第一，任何并行写入都要划分文件所有权。第二，子 Agent 的结论必须带证据，父 Agent 不应只收一句“完成”。第三，设置总 Agent 数、轮次、时间和 Token 上限。第四，最终验证必须由独立命令或审查步骤完成。
还要记录模型路由。父 Agent 和子 Agent 可能使用不同 Provider 或 Preset，质量、工具和成本不能默认相同。
一个实用决策顺序
先问任务能否由当前 Agent 完成；能就不要委派。不能时，若只是一个边界清晰的子问题，用 Subagent；若要固定多步执行，用 Workflow；若同一任务要持续推进，用 Goal；只有明确需要每轮清空上下文的迭代，再用 Ralph。
最终建议
多 Agent 的目标不是“更多思考”，而是隔离上下文、并行独立工作、固定流程和控制风险。先从一个子 Agent 和一个可验证交付开始，再逐步增加并行与循环。
当你能回答每个 Agent 为什么存在、读写哪些文件、何时停止、由谁验收，多 Agent 才真正成为工程能力。
继续阅读：沙箱、审批、密钥与插件安全边界。需要回看完整顺序时，返回DeepSeek Harness 专题路线。