DeepSeek Harness 智能体、子代理与团队怎么分：配置、并发与适用场景完整对比

智能体、子代理与团队是三个层级，不是三个同义词。 主代理做决策，子代理做分工，团队做协作；混着用，最常见的结果是并发过高、任务互相等待。

三层对象

先看清谁负责什么，再谈怎么配。

主代理是决策中心，子代理是执行单元，团队是组织方式。 主代理理解你的目标，决定要不要派子代理、派几个、什么时候收结果（来源）；子代理拿一个明确子任务，在自己的上下文里跑，最后把结果交回主代理，隔离带来并行，也带来汇总成本；团队定义角色、任务与推进顺序，适合需要分工与依赖的复杂任务（来源）。

子代理：分工与隔离

子代理的价值是「并行」和「隔离」，不是「更聪明」。

1. 把任务拆成互不依赖的子任务：检索、审阅、生成、校验。
2. 为每个子任务写清输入、输出与完成标准。
3. 由主代理派发，等待结果并汇总。
4. 检查子代理是否越界：改了不该改的文件、调了不该调的工具。
5. 结果冲突时，回主代理裁决，不要让子代理互相协商。

隔离是双刃剑，子代理也不适合强依赖任务。 子代理看不到主会话全部上下文，减少干扰，也可能缺少关键约束；任务说明要自带前提。后一步依赖前一步结果时，串行更快；并行只会增加等待与合并成本。

团队：角色、并发与协调

团队解决「多角色怎么一起干」，核心是分工与顺序。

1. 定义角色：谁负责方案、谁负责实现、谁负责审阅。
2. 定义任务与依赖：哪些能并行，哪些必须等前置完成。
3. 设置并发上限：按模型配额与机器能力定，不要一次拉满。
4. 定义交接物：每个角色交付什么格式，下一角色才能接。
5. 设置终止条件：什么情况下停止、回退或交给人。

团队的成本在协调，并发也不是越高越好。 角色越多，交接与等待越多；两三个角色能解决的任务，不要上五个。并发高会排队、超时、互相等待；先串行跑通，再逐步提高。

agent 预设：把配置固定下来

预设解决「每次配置都不一样」。 它把模型、提示词与工具固定成模板。

1. 选一个稳定可用的配置作为基线。
2. 固定模型与关键参数，避免每次漂移。
3. 写清适用场景与不适用场景。
4. 给预设起可识别的名字，团队与子代理引用它。
5. 变更预设时记录版本，避免历史任务无法复现。

预设是「怎么配」，团队是「怎么协作」，预设也不要频繁改。 两者一起用，才能既一致又可控。改一次，所有引用它的任务行为都会变；需要试验时新建一个，而不是改基线。

对照表

按任务形态选层级，比按习惯选更稳。

能用主代理解决就不要拆，团队也不是「更高级」，是「更重」。 拆分带来上下文隔离、汇总与协调成本；收益不明确时，单代理更快。只有在分工与依赖确实存在时才用团队。

配置入口

三层配置的位置不同，先找对入口。

1. 主智能体： 会话级配置，模型、工具与提示词在会话或设置里。
2. 子代理： 由主代理派发，任务说明与工具范围在派发时确定。
3. 团队： 团队类插件或配置定义角色、任务与并发。
4. 预设： agent 预设管理入口，固定模型与提示词模板。
5. 并发： 在团队或运行配置里设置上限，不在单个任务里硬编码。

配置分散时先画一张关系图，并记录生效版本。 谁引用谁、哪个配置生效，写清楚再改；否则改了一个地方，另一个地方仍用旧值。团队与预设都可能有多个版本，出问题先确认实际用的是哪一个。

常见失败

多代理任务的失败，集中在四类。

1. 并发过高： 排队、超时、配额耗尽；先降并发，再谈优化。
2. 任务互相等待： 设计成环，A 等 B、B 等 A；画依赖图，打破环。
3. 子代理缺上下文： 任务说明没带前提，结果跑偏；把约束写进派发说明。
4. 汇总丢失： 子代理结果没交接物，主代理无法合并；统一输出格式。

四类的共同点是「协调没设计好」。 不是模型能力问题，是任务结构问题；先改结构，再换模型。

选型建议

从轻到重，按需升级。

1. 先试主代理，确认单代理能否完成。
2. 有明确可并行的子任务，再加子代理。
3. 有角色与依赖，再上团队。
4. 任务重复出现，再抽成预设。
5. 每次升级都保留回退路径。

升级的判据是「收益大于协调成本」，不要为了用而用。 并行节省的时间，要大于拆分与汇总的成本；否则不如串行。多代理是工具，不是目标；能简单解决的，保持简单。

下一步

先分清层级，再按任务形态选。 想看团队编排的上手流程，看《DSH plugin 多智能体团队怎么用》；想看 agent 预设，看《dsh agent 预设是什么》；想区分工作流、定时与子代理，看《工作流、定时与子代理怎么分》。

来源：DeepSeek Harness 官方文档、dsh-agent-teams 插件页、dsh CLI README