dsh workflow、定时任务与子代理怎么分工：DeepSeek Harness 三种自动化边界

dsh workflow、定时任务与子代理经常被放进同一个“自动化”抽屉里，但在 DeepSeek Harness 里它们回答的是三个不同问题。工作流关心步骤怎么连，定时任务关心什么时候开始，子代理关心活由谁分头做。先把问题分开，再谈组合，误用会少很多。

DeepSeek Harness 里，工作流解决的是步骤与依赖

工作流的价值不在于自动执行，而在于把顺序、分支和回滚点固定下来。

在 DeepSeek Harness 里，dsh workflow 首先是一张可执行的步骤图。每个节点做什么、依赖哪个上游、失败后走哪条分支，都要在开始跑之前写清楚。执行只是照着这张图走，真正的设计工作发生在运行之前。也正因为如此，工作流适合那些步骤明确、但人工每次都要重复判断的任务。

当任务存在先后依赖时，工作流几乎是最自然的选择。比如先拉取数据、再校验、然后生成报告，后一步必须等前一步完成。流程里还可能需要条件分支：校验失败就通知，成功才继续。把这些关系写进编排，比留在人的记忆里可靠。

工作流也有成本。节点越多，维护和排错越费劲，中间产物的存放与清理也需要设计。一个几十个节点的大流程，如果没有清晰的命名和日志，出问题时很难判断卡在哪。所以流程应该按职责切分，而不是把所有动作都塞进同一条链路。

常见的误用是把简单的重复动作包成工作流。每天复制一份文件、发一条通知，本来用定时任务就能解决，却做成多节点流程，结果维护成本远高于收益。工作流应该留给那些确实存在依赖与分支的任务，简单动作保持简单。

DSH plugin 的定时任务只解决什么时候开始

定时任务管的是触发时机，它不关心启动之后流程内部发生了什么。

定时任务在 DeepSeek Harness 里扮演闹钟的角色。到了约定的时间，它把某个动作拉起来，然后就可以退场了。至于这个动作是运行 dsh workflow、调用脚本还是给子代理派活，定时任务本身并不参与。把触发与执行分开看，很多关于“定时任务能不能做流程”的疑问就会消失。

配置定时任务时，时间语义要先说清楚。每天九点是指哪个时区，周末是否跳过，上一次没跑完时要不要允许重叠，这些细节都会影响结果。跨时区团队尤其容易在这里出错，因为同一个表达式在不同地区含义不同。写清楚时区和跳过规则，比事后解释省事。

另一个容易忽略的点是失败通知。触发成功只代表闹钟响了，不代表任务执行成功。如果没人接收执行结果，任务可能连续几天静默失败，而团队还以为一切正常。把成功、失败和超时都纳入通知，定时任务才算真正可用。

定时任务最典型的误用，是让它承担流程编排的职责。有人把多个条件判断塞进触发脚本，试图用 cron 表达式表达业务分支，最后既难读也难改。触发层只做触发，复杂逻辑交给工作流或子代理，边界会清楚很多。

子代理在 DeepSeek Harness 里解决的是分工与并行

子代理适合把可以独立推进的工作拆出去，而不是把一件事切成更多步骤。

子代理是由主会话派生的独立执行单元，它有自己的上下文，可以并行处理子任务。在 DeepSeek Harness 里，这意味着多个方向可以同时探索，主会话不必被单个长任务占住。它解决的是“谁来做”和“能不能同时做”，不是步骤之间的先后关系。

适合交给子代理的任务通常边界清楚、输入输出可以描述。比如同时调研几个方向、分别检查多个目录、用不同模型对同一段内容给出意见。只要子任务之间不需要频繁交换中间状态，拆开就有收益。上下文隔离也让子代理不容易被无关信息干扰。

子代理的代价集中在汇总环节。多个结果回来之后，谁负责去重、比对和裁决，需要在派活之前就想好。如果输出格式不统一，汇总者还要花时间理解每个子代理的表达方式。并行省下的时间，可能又被汇总消耗掉。

误用通常有两种。一种是任务本身不可拆，却硬拆成几个子代理，最后还要花大量精力拼回整体。另一种是没有输出契约，子代理各说各话，主会话无法判断哪份结果可信。拆之前先确认可拆，派活之前先约定格式，这两个动作能避免大部分问题。

DSH plugin 三者放在一起时怎么分工

三者不是替代关系，各自站在触发、编排和执行的位置上。

组合方式其实很朴素，三者各管一段：

• 定时任务负责把流程叫醒，决定什么时候开始。
• 工作流负责决定先做什么、后做什么，以及失败后走哪条分支。
• 子代理负责处理其中可以并行的节点，把可以独立推进的工作拆出去。

这样每一层只做自己擅长的事，出问题时也能按层定位。DSH plugin 的价值，往往体现在这些层之间的接口是否清楚。

失败隔离需要在设计时就考虑。定时任务触发失败，不应该影响已经跑完的流程；某个子代理失败，也不应该让整条工作流失去结果。每一层都要有自己的超时、重试和状态记录。没有这些，组合起来的系统会比单层更难排查。

判断要不要组合，可以先画一条时间线：谁在什么时刻触发，触发之后按什么顺序走，哪些节点可以同时进行。这条线画不出来，说明分工还没想清楚，此时叠加能力只会增加不确定性。画得出来，再决定用几个组件去实现。

在 DeepSeek Harness 里怎么选第一种自动化

选型从最小可用开始，而不是从能力最强开始。

先看任务形态，再看失败代价。固定时间做同一件事，优先考虑定时任务；步骤之间有依赖和分支，才需要 dsh workflow；任务能拆成互不依赖的小块，才轮到子代理。这个顺序不是规定，而是让复杂度随着需求逐步增加。插件条目可以在 DSH Plugin Hub 里对照能力。

选型的顺序其实和任务形态一一对应：先问触发时间是否固定，再问步骤之间有没有依赖，最后问工作能不能拆开。答案只落在第一问，定时任务就够了；落到第二问，才需要 dsh workflow；三问都成立且各块互不依赖，才轮到子代理。每往下一步，复杂度都会上升，需求没到就不必提前买单。

反向的克制同样重要。只有触发、没有流程时，不要给定时任务硬加编排；只有流程、没有并行时，也不要为了显得先进而拆子代理。工具被拉去做它不负责的事，维护成本会立刻显现。

准备组合时，先确定日志落在哪一层，再要求任何一层失败都能单独重跑而不影响其它层。这两件事在画架构图时容易被跳过，却是事后能不能定位问题的分水岭。日志与重跑能力最好在设计阶段一并定下，等到出事再补，通常只能补到表面。

小团队通常从定时任务开始，因为它最容易验证，也最容易回退。等重复动作稳定下来，再判断是否值得写成工作流。子代理可以更晚引入，等任务量和并行需求真的出现，再承担它的汇总成本。顺序对了，投入就不会浪费。

引入第二种能力时，先补监控和回滚，再谈效率提升。没有日志分层，组合后的失败会被笼统归因成“没跑”，排查时间反而更长。每增加一层，都要能回答它失败时留下什么证据。证据齐全，扩展开关才是可逆的。

DSH plugin 自动化误用的常见信号

误用往往不是选错工具，而是让工具承担了它不负责的那部分。

一个明显信号是定时任务里塞满条件判断。脚本越来越长，分支越来越多，触发时间反而成了最不重要的事。这说明业务逻辑已经溢出触发层，应该收回工作流里。继续在定时任务里打补丁，只会让下次修改更危险。

第二个信号是工作流里硬做并行汇总。流程图画得很复杂，实际上是在用节点模拟同时执行，结果既慢又难维护。如果任务确实可以并行，交给子代理会比在流程里绕更直接。工作流擅长顺序与分支，不擅长充当调度器。

第三个信号是所有任务都派给子代理。子代理数量一多，汇总、去重和冲突处理就会变成新的瓶颈。并行不是免费的，它把复杂度从执行阶段转移到了汇总阶段。任务量不大时，单会话顺序处理往往更划算。

版本差异也值得注意。不同 DSH插件 对工作流节点、调度精度和子代理上限的支持并不一样，DeepSeek插件 生态里的实现也各有取舍。升级之后，原本能跑的组合可能表现变化。遇到异常时先对照插件说明，再用一个最小任务复现，比凭经验猜测可靠。