前言¶
在 DeepSeek Harness（DSH）里写代码，很多工作其实不该绑在当前这段对话上。工作日早上复查一遍本地测试、每周扫一次仓库健康状况、过几小时再验证一次不稳定失败——这些任务需要的是一份写清楚的完整指令，以及一次可以事后检查的运行结果，而不是十分钟后回到同一个 Session 里接着聊。
DSH 自带的 Core Schedule 适合提醒：例如「十分钟后回到这个 Session 继续检查」。另一类需求则不同：任务必须能独立理解，每次执行都要落在明确的工作区和权限边界里，跑完还要留下记录。社区插件 dsh-automation 做的就是这件事：把编码任务按计划丢进全新的 root Agent 与 Session，而不是在旧对话里续跑。
本文按插件目录页、GitHub 仓库 README / package.json 以及 DeepSeek Harness 官方仓库交叉核对后整理。目录站点是社区收录，与 DeepSeek / 幻方没有官方从属关系；安装前仍应自己看源码和许可证。
这是什么¶
dsh-automation 是一款面向 DeepSeek Harness 的工作流与自动化插件，由 titanwings 维护，仓库为 titanwings/dsh-automation，许可证 MIT，主要语言 TypeScript。npm 包名是 @dsh-external/dsh-automation，当前版本 0.1.5。社区目录把它归在「工作流与自动化」分类，收录日期为 2026-08-15；GitHub 仓库创建于 2026-08-13，截至 2026-08-17 约 45 星。
它解决的问题可以收成一句话：把一份自包含的编码任务、运行计划和权限边界保存下来，每次到期都在全新 root Agent 与 Session 中执行，并留下可审计的运行历史。
用户和符合条件的 root Agent 都可以创建、暂停、恢复、立即运行和查看这些规则。真正被调度出去的每一次 occurrence，用的是保存下来的 prompt，而不是创建规则时那段对话的历史。
DeepSeek Harness 官方仓库的核心理念是「一切皆插件」（Everything is a Plugin）。dsh-automation 是独立社区插件，实现基于 DSH 与 Cordis，没有 patch DSH Core。README 说明产品模型受到 Codex Scheduled tasks 的启发，尤其是「回到原对话」和「启动一次独立运行」的区分；实现本身并不复制 Codex 内部代码。
核心功能¶
一个控制面，两种入口¶
安装后不需要再单独跑一个 bot、daemon 界面或第三方调度器，管理入口有两个：
- DSH Web：在对话里，Chat 和 Trajectory 旁边有一个「自动化」Tab，用来创建规则、暂停或恢复、立即运行、删除，以及查看最近运行。
- 符合条件的 root Agent：用自然语言提出要求。插件提供六个限定范围的工具，Agent 只能管理自己当前 canonical workspace 里的规则，不能传入任意路径越界。
六个工具及其用途如下：
| 工具 | 用途 |
|---|---|
automation_create |
创建绑定当前 workspace 的独立规则 |
automation_list |
读取规则、下次 occurrence 和最近历史 |
automation_update |
修改名称、prompt、节奏、权限，或切换 active / paused |
automation_run_now |
按相同边界排队一次手动运行 |
automation_runs |
读取有限数量的运行历史、错误、摘要和 Session ID |
automation_delete |
删除规则定义，同时保留持久化的运行记录 |
Agent 创建或扩大未来无人值守工作时，插件会额外要求人工确认。只读查询，以及仅把规则暂停的更新，不会加这一步。
人能读懂的运行计划¶
规则支持四种节奏：单次、固定间隔、每天、每周。每天和每周使用 IANA 时区（例如 Asia/Shanghai）；界面上的友好表单会规范化成经过校验的 RFC 5545 RRULE，再用于持久化和检查。
间隔调度有两个值得注意的约束：最短间隔是五分钟；创建后不会立刻跑第一次，第一次发生在完整间隔之后。每天 / 每周按该时区的本地 HH:mm 计算；夏令时里不存在的本地时间会跳过，而不会被平移到下一分钟。
每次都是干净的执行边界¶
每次真正 dispatch 的 occurrence 都会拿到：
- 一个新的 Session ID 和全新的 root Agent
- 保存下来的 prompt，而不是来源对话的历史
- 创建时捕获的 workspace、cwd、Agent preset、model target 与 permission preset
- 明确的
automation消息来源，带上 automation ID、run ID 和计划时间 - 从真实 DSH turn 结束状态派生的最终结果，而不是把「消息已经送达」当成成功
权限只有两种：read-only 和 workspace-write。无人值守模式不接受 danger-full-access。每个新 Session 的 approval policy 都是 never：仍需要交互式批准的工具会直接失败，而不是一直等，也不会静默提权。
失败和成功一样可解释¶
一次运行会经历 queued、running，最终进入 succeeded、failed、skipped 或 cancelled。每条记录会保留 definition revision、prompt 与目标快照、计划时间、结果 Session ID、有限长度的摘要，以及结构化错误。
修改规则会递增 revision，所以历史记录仍能说明当时执行的是哪一版定义。删除规则不会立刻抹掉这些运行记录。保留策略只清理最旧的终态记录；仍处于 queued / running 的记录不会被裁掉。
安装与启用¶
社区目录页给出的安装命令是：
dsh plugin add github:titanwings/dsh-automation
dsh CLI 会从 GitHub 解析插件并装进当前配置。目录页同时提醒：如需可复现安装，应固定 commit 哈希：
dsh plugin add github:titanwings/dsh-automation#commit
把 #commit 换成实际审阅过的 commit SHA。
仓库 README 的推荐写法更具体：这个插件带 Web 客户端，需要装进 DSH Web profile，然后重启 dsh web。当前可复现的版本 tag 是 v0.1.5：
dsh plugin --profile web add github:titanwings/dsh-automation#v0.1.5
如果是从 DSH 源码目录运行，把 dsh 换成 pnpm dsh。
从本地 checkout 安装时，需要 Node.js 22.19 或更高版本：
git clone https://github.com/titanwings/dsh-automation.git
cd dsh-automation
pnpm install
pnpm check
cd /path/to/deepseek-harness
pnpm dsh plugin --profile web add /absolute/path/to/dsh-automation
仓库已随附构建好的 Host 与 Web bundle。通过 Git 安装时不会跑包构建脚本，也不需要添加 allowBuilds。
插件以当前 dsh 进程的权限运行，安装时可能执行代码。安装前请检查源代码仓库和许可证。
典型用法¶
从 DSH Web 创建¶
- 打开一个已经连接到目标 workspace 的 Session。
- 在 Chat 和 Trajectory 旁选择「自动化」。
- 填写可以独立理解的任务、schedule、IANA 时区，以及权限边界。
- 正式依赖定时运行前，先点一次「立即运行」，检查结果 Session 和 run record。
让 Agent 创建¶
安装完成后，符合条件的 root Agent 会拿到上面那组管理工具。README 给出的示例是：
给当前工作区创建一个只读 automation，名字是“工作日回归分诊”。
每周一到周五 09:30 在 Asia/Shanghai 运行。检查最新本地测试证据，
识别回归并返回简短报告。不要修改文件。
一条高质量任务应写清：目标、要检查的证据、允许的修改、验证方式、停止条件。不要写「继续我们刚才讨论的内容」或「把所有问题都修好」——定时运行不会继承创建它的那段对话。
调度与恢复时实际会发生什么¶
这些语义来自仓库 README，0.1 版本按 at-most-once 派发，而不是承诺外部副作用 exactly-once：
| 情况 | 行为 |
|---|---|
| 重叠 | 每条规则同时最多一个 active run；前一次仍在 queued / running 时，到期 occurrence 记为 skipped(overlap) |
| Host 延迟重启 | 默认 15 分钟 grace window 内最多补跑最新一次，不会把旧任务重放成写入 backlog |
| 运行超时 | 默认 60 分钟后取消 Agent，并把该次运行记为失败 |
| Host 崩溃 | 恢复时，持久化的 queued / running 会变成 failed(host_interrupted)，不会偷偷重跑 |
| 重试 | 只能手动点「立即运行」；没有可能重复副作用的自动重试 |
任务启动时 DSH Host 必须正在运行。0.1 版本不是操作系统 daemon，也不会协调多个 Host 争抢同一个 storage 目录。
仓库内 cordis.patch.yml 的默认配置是：maxConcurrentRuns 为 2（这是当前 Host 的全局容量，单条规则仍禁止 overlap）、runTimeoutMinutes 为 60、misfireGraceMinutes 为 15、historyLimit 为 200。需要改这些值时，应改 deployment profile 里的 plugin row。提高并发或超时等于扩大无人值守工作量，应把它当成策略决定，而不是纯性能参数。
适用场景与注意事项¶
仓库把「值得定时」的任务写成可重复、有边界、容易验证。官方示例包括：
| 任务 | 建议权限 | 做什么 |
|---|---|---|
| 工作日回归分诊 | read-only |
检查本地测试证据、归类失败，在新 Session 里留下诊断 |
| 每周仓库健康报告 | read-only |
看陈旧 TODO、依赖清单、被忽略的失败和测试缺口，不改代码树 |
| 单次延迟验证 | read-only |
稍后重查一次 flaky failure，留下与当前对话无关的证据 |
| 生成代码刷新 | workspace-write |
重建范围明确的生成产物，跑聚焦检查，报告准确 diff |
| 维护修复窗口 | workspace-write |
复现一个有边界的问题，做经过验证的最小修复，满足验收后停止 |
下面几类目前不适合交给它：任务依赖没有写出来的历史对话；运行中途必须等人批准；应该由文件、HTTP、进程状态而不是时间触发。同对话里的 reminder / heartbeat 仍应使用 DSH Core Schedule。
0.1 版本刻意不提供：raw cron 或任意 shell action、无人值守 full access、对可能已有副作用的自动重试、Git worktree 创建与清理、多 workspace / DAG / 跨 run 隐藏记忆、外部邮件短信或推送，以及外部副作用 exactly-once 保证。当前只实现本机执行。
安全边界需要单独强调一次。无人值守编码的信任范围比交互聊天更小：运行不会继承来源对话的 history、inbox、grant 或历史 approval；fresh Agent 只允许一组精简的编码工具，交互问答、计划、目标、嵌套 Agent、运行时挂载插件、终端 / 后台任务、递归管理 automation，以及未知第三方工具，都会被拒绝；管理 RPC 只接受 loopback。这些约束并不会把所有第三方 DSH 工具自动变成沙箱——前台 Shell 与网络行为仍取决于所选 Agent preset、tool set 和 DSH guards。启用无人值守写入前，务必先用「立即运行」看一遍真实行为。
最后，插件以当前 dsh 进程的权限运行。社区目录和仓库都按 MIT 开源，可以免费查看源码再决定是否安装；安装前应检查仓库与许可证，需要可复现环境时固定 commit 或版本 tag。
小结¶
dsh-automation 把「稍后独立跑完一份编码任务，并留下可检查的结果」收进 DSH 自己的 Web 界面和 Agent 工具里。它不是把旧对话叫醒，而是每次开一个新的 root Agent 与 Session，权限默认收得很紧，运行历史按 revision 保留。
如果你已经在用 DeepSeek Harness，并且手头有可重复、写得清楚、能在只读或 workspace 写入边界内验收的任务，可以从目录页或仓库按上面的命令装进 Web profile，先用「立即运行」验证一次，再打开定时。
- 目录页：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-automation/
- GitHub：https://github.com/titanwings/dsh-automation
- DeepSeek Harness：https://github.com/deepseek-ai/deepseek-harness
