dsh workflow 不触发怎么排查：DeepSeek Harness 工作流插件的触发器、队列与权限

晚上九点，那条每天定时跑的 DeepSeek Harness 工作流没有动，日志里连一行「开始执行」都没有。 我先检查了流程画布，节点没动过；又重装了工作流插件，仍然没有反应。真正的问题在画布之外——触发器、队列和审批，这三处任何一处没放行，流程都看起来像「不触发」。

晚上九点，那条本该自动跑的 DeepSeek Harness 工作流没有动

那是一条很简单的流程：每天固定时间读取一个目录，生成摘要，写回另一个文件。 前一天晚上它跑得好好的，第二天晚上什么都没有发生。没有报错弹窗，没有失败标记，任务板上一片安静。

人的第一反应是怀疑流程本身。我打开画布，节点连线都在，变量名也没改，保存时间还是上周。于是我又怀疑工作流插件（DSH插件、DeepSeek插件 都试过），去 DSH Plugin Hub 对过版本，又卸载重装，重启客户端，等到九点半，依然没有动静。这段时间基本白花，因为重装把现场清掉了，后面反而更难查。

更麻烦的是「不触发」这个说法本身就很模糊。它可能指没有开始、没有入队、没有执行、没有完成，四种状态在界面上长得几乎一样。你越急着修，越容易把不同层的现象混成同一个问题。

后来我才把注意力从画布移开。工作流的执行链其实分三段：先有东西把流程叫醒，再有一个位置让它排队，最后有一道闸门决定它能不能真的动手。任何一段断了，画布上都看不出来，因为它们都不属于流程定义。

这条经验值得先说清楚：画布只描述「要做什么」，不描述「为什么没开始」。 排查必须去画布之外找证据。

触发器没有收到事件，DeepSeek Harness 的节点写得再好也没用

触发器是整条链的入口；它没收到输入，流程连第一行日志都不会写。 常见触发器有三类，但排查方式完全不同。

定时触发器最容易被时区骗。界面上写的是每天二十一点，实际调度可能按另一个时区计算；夏令时切换、服务器时区变更，都会让「每天一次」变成「今天没有」。我当时检查了调度是否注册、下一次触发时间是什么，这两项在任务板的调度信息里能看到。如果下一次触发时间根本不显示，说明调度压根没注册成功，问题在插件加载或配置保存。

事件触发器看的是订阅有没有命中。事件名、来源、过滤条件是三个独立的失败点：名字差一个前缀、来源不在白名单、过滤条件写得太窄，都会让事件从旁边走过去。有的插件会把未命中的事件静默丢弃，日志里什么都没有，这种设计让人误以为「事件没发生」。比较可靠的做法是临时把过滤条件放宽，发一条测试事件，看触发器层有没有记录，再逐条加回条件。

手动触发器最简单，也最容易被忽略：入口按钮在，但当前用户没有权限，或者当前 profile 里根本没加载这个插件，按钮就是灰的。点不动的时候不要怀疑鼠标，先看插件状态。

还有一个常见误区：手动能跑，就以为触发器没问题。手动触发走的是另一条入口，它不经过调度和事件订阅。手动成功只能证明执行链后半段是通的，不能证明定时或事件真的会来。

三类触发器的共同点是：你要找的是「触发层有没有收到」的证据，而不是「流程跑没跑」的结果。 触发器日志、调度信息、手动入口状态，这三样至少要有一样能回答这个问题。

有触发记录却一直排队：DeepSeek Harness 的问题往往不在流程本身

第二段是队列；触发记录出现了，任务却一直停在等待，说明流程还没轮到执行。 这时候改节点是徒劳的。

最常见的原因是前一个任务卡住了。并发上限通常默认不高，一个长时间运行的任务会把唯一的执行位占住，后面的任务只能排队。表面上看是「新任务不触发」，实际是旧任务没结束。任务板里找运行时间最长的那个，往往一眼就能看到。

第二种原因是执行器没起来。有的工作流插件把执行器做成独立进程或后台服务，界面能打开不代表执行器在跑。队列会安静地堆积，没有任何报错。检查执行器状态、进程和日志，比反复点「运行」有用。

第三种是重试风暴。一个失败任务按固定间隔重试，每次重试都占一个队列位置，几分钟后队列全是同一个任务的副本，新任务永远排不上。日志里会看到同一个任务 ID 反复出现，这种模式很好认。

队列问题的判断标准很朴素：触发时间、入队时间、开始执行时间，三个时间戳能不能对上。 如果只有前两个，说明执行器或并发有问题；如果三个都有，问题在更后面的审批层。

平时可以留意队列的正常水位。一个健康的工作流，入队到开始通常只差几秒；某天突然变成几分钟，即使最终跑完了，也说明并发或执行器已经开始吃力。这种提前量比故障后的补救更值钱。

停在等待确认不是故障：DeepSeek Harness 的审批闸门在等人

第三段是审批；任务已经执行到工具调用，停住是在等一个明确答复。 很多人把它当成卡死或超时，其实是闸门在等确认。

闸门拦下的通常是越界操作：写工作区之外的路径、启动子进程、访问网络、读取敏感目录。审批提示里会给出工具名和完整参数，这两样东西比「任务失败」四个字有用得多。先看参数是不是你预期的，再看工作区边界是不是设得太宽或太窄。

这里有一个容易混淆的点：审批等待没有超时，或者超时时间很长，所以从外面看就是「一直不动」。如果日志只记录到工具调用开始，没有结束记录，基本可以判定停在闸门。

处理方式有两种。能缩小范围就改流程，比如把写入路径限制在工作区内，把网络访问换成预先取数；确实需要越界，再给这一次操作授权。不要为了让它跑起来就全局放开审批，那等于把风险从可见变成不可见。

审批记录通常不在主日志里，而是在任务详情的单独标签页。找错地方，会误以为流程根本没走到审批这一步。

我怎么用二十分钟把 DeepSeek Harness 工作流的范围缩小到一个节点

现场清掉之后，我按顺序重走了一遍，二十分钟定位到问题节点。 步骤不复杂，关键是每一步都要拿到证据再往下走。

1. 先手动触发最小流程：只保留一个触发器和一个无害动作，确认执行器、队列、审批这条链本身是通的。手动能跑，说明问题不在插件安装。
2. 再看触发层日志：把定时改成一分钟后触发一次，看调度信息里有没有「已注册」和「下一次触发时间」。没有，就停在这一层。
3. 然后看队列：触发记录出现后，对比入队时间与开始执行时间。只入队不开始，查执行器和并发；两个时间都没有，回到触发层。
4. 接着做节点二分：把完整流程从中间切开，前半段单独跑。能跑就说明问题在后半段，逐段缩小到具体节点。
5. 最后看审批记录：定位到节点后，检查它调用的工具是否越界，参数是否超出工作区。是，就改流程或授权；不是，再查插件版本。
6. 验证：最小流程、完整流程、审批记录三处结论一致，才算定位完成。

这套顺序的价值在于「每步都能排除一层」。我一开始跳过了前两步，直接重装，等于把证据全删了。

最后定位到的不是插件 bug，而是调度注册。配置保存成功了，界面也显示「已启用」，但调度信息里的下一次触发时间是空的——保存动作没有触发重新注册。把调度关掉再打开，下一次触发时间立刻出现，一分钟后流程自己跑了。

这个结论听起来很轻，但它解释了为什么重装没用：重装恢复的是插件文件，不会重新注册那条调度。也解释了为什么画布看起来一切正常：流程定义本来就没坏。

下次再遇到 DeepSeek Harness 工作流不动，我会先看这三样东西

现在再遇到「不触发」，我不会先打开画布，而是先看三样证据。 调度信息里有没有下一次触发时间，任务板里有没有入队记录，日志里有没有审批等待。三样对应三段链，缺哪样就查哪段。

这三样东西最好平时就打开着。工作流跑得正常的时候，它们的形态是稳定的；一旦某天不一样了，你一眼就能看出来。事后才去找日志，往往已经被轮转或覆盖。

还有一个小习惯：每次改流程之前，先手动触发一次，确认基线是通的。改完再手动触发一次，对比两次的日志差异。这样即使出问题，你也知道是哪一个改动引入的，而不是面对一个「昨天还好好的」的黑盒。

如果三段都查过、都没有异常，流程仍然不动，那就把范围缩到插件版本：确认工作流插件与本体版本匹配，再看看任务板和调度是不是同一个插件在管。有些组合里，设计器和执行器是两个插件，升级了其中一个，另一个还停在旧协议上。这种情况日志通常很少，只能靠版本对照发现。

来源：dsh-workflow-designer 插件条目、dsh-taskboard-flow 插件条目、插件与生命周期。