DeepSeek Harness 的自动化：定时提醒怎么建，GitHub 有新 PR 自动开评审

DeepSeek Harness 有两种让它“自己动起来”的办法：

办法	什么时候触发	难度
定时提醒	到了你定的时间	在对话里说一句就行
GitHub 评审会话	仓库里的 PR 从草稿转为可评审	要配 Webhook 和反向代理，偏运维

多数人用得上的是第一种，先讲它。

还没装的，先看DeepSeek Harness 安装和上手。

定时提醒

先打开“自动化任务”

官方文档说明，发布的网页版默认不带这个功能。打开侧栏的插件页，在“官方”分组里启用 自动化任务。

它在官方页面上标着“实验性”。按 0.2.1-alpha.1 的版本说明，自动化任务已经改成网页版的内置能力，不过提醒工具只在标准、创造和 PTC 这几种模式下可用，极简模式和子代理里没有。你的版本里入口在哪，以界面为准。

另外要先配好模型，见安装和上手里“配置模型”一节。

用一句话创建

直接对它说就行，比如官方文档里的例子：

每天 Asia/Shanghai 时区 23:00 提醒我查看天气。

它会调用创建提醒的工具。之后想看有哪些提醒、改时间、删掉，也都可以直接说。

也可以从 自动化任务 页面点“新建”，它会开一个新会话，输入框里已经替你写好了请求。

支持哪些时间规则

官方文档列出的：

规则	例子	说明
过一段时间后，一次	30 分钟后	以秒为单位的延迟
指定的日期时间，一次	10 月 12 日 9:00
固定间隔，重复	每 2 小时	最短一分钟
每天	每天 23:00	要带时区
每周	每周一、周五 9:00	要带时区
cron 表达式	`0 9 * * 1-5`	五段式，要带时区

把时区说清楚。 官方文档说明，浏览器会提供它的时区来理解“每天 9 点”这样的说法，但明确写出时区可以避免歧义。在国内就写 Asia/Shanghai。

建完检查一遍。 官方的建议是打开自动化任务页面，选中刚建的提醒，看“频率”显示的是不是你要的规则和时区，而不是“仅一次”。

到点之后发生什么

这一点和手机上的提醒不一样，要先弄明白：

提醒到期时，它会恢复原来那个会话，把这条指令作为后续消息排进去，不会打断那个会话里正在做的事。
同一个会话里同时到期的几个重复任务，可能合成一条消息。
官方写明，不支持每次运行新开一个会话。所以一个每天执行的任务，所有的执行都累积在同一个会话里。

关掉程序会怎样

官方文档的说法：

会话没有打开，提醒照样保存着。
程序关掉之后，调度就停了，直到再次启动。
重新启动后，它会检查存着的任务：过期的一次性提醒会补发；重复的任务，每条只补最近错过的那一次。

所以想让它每天按时跑，程序要一直开着。桌面应用关掉窗口只是隐藏，不影响；真正退出就不跑了。电脑休眠时的情况官方没有写。

发送记录不等于执行结果

在自动化任务页面选一个任务，可以看“规则”和“发送记录”。官方文档对发送记录的定义要看清楚：

已保存的发送记录确认消息已持久化到对话收件箱，不表示模型完成了所请求的工作。

也就是说，记录里有一条，只说明“到点了、指令发进会话了”。它做没做、做得对不对，要点进原来的会话去看。

官方还写明了两个边界：

不保证恰好投递一次。 极端情况下（比如刚发完就崩溃）可能重复发。
它不是外部通知渠道。 不会给你发邮件、推送或者短信，结果只出现在会话里。

管理和修改

在自动化任务页面可以：

按名称、指令搜索，按“全部、已开启、未运行”筛选；
修改活动任务的名称、指令和运行时间，改完点“保存更改”；
删除任务。删除会停止以后的投递，并把这个任务和它的发送记录一起删掉，但不会删除原来的会话。

一次性的提醒发出后会变成“未运行”，仍然留在列表里，直到你删掉它。官方提醒，对话顶部的列表和模型自己列出来的只包含活动的提醒，所以在那里看不到不代表任务被删了。

官方写明不支持暂停。想临时停一个任务，只能删掉，要用时再建。

适合拿它做什么

下面是我们的看法，不是官方的建议：

适合：每天整理一次某个目录下的记录、每周生成一份周报、到点提醒自己看某件事。
不适合：要求严格准点、不能漏也不能重复的事；需要发到手机或邮箱的通知。

另外别忘了权限。定时任务在原来的会话里跑，用的是那个会话的权限。一个会自己定时运行的会话，权限给多大要想清楚，见DeepSeek Harness 的权限怎么设。

GitHub 评审会话

这一部分偏运维，需要一台能被 GitHub 访问到的机器。只是自己本机用的，可以跳过。

它做什么

官方文档的描述：给 dsh web 加一个带签名校验的 GitHub 端点。配置好的仓库里有 PR 从草稿转为可评审（ready for review）时，它会在这个仓库对应的工作区下面开一个带标题的会话，启动一段只读的评审提示词。

官方的规则里写得很明确：这个会话用的是只读的权限预设，提示词里禁止它修改文件、分支、PR 或者 GitHub 上的状态。它只是看代码、写评审意见。

需要准备什么

官方列的前置条件：

一个本地的代码检出，可以注册成工作区；
一个强度足够的 Webhook 密钥，通过环境变量 DSH_GITHUB_WEBHOOK_SECRET 提供；
一个带 TLS 的反向代理或隧道，把一个公网地址转到本机的监听端口；
GitHub 上的 Webhook 订阅 Pull requests 事件，内容类型选 application/json。

启动

生成密钥，之后重启也要用同一个值：

export DSH_GITHUB_WEBHOOK_SECRET="$(openssl rand -hex 32)"

官方把这个功能做成了一份可选的配置，启动时用 --patch 带上：

dsh web --patch /absolute/path/to/github-review/cordis.yml

这份配置在官方仓库的 apps/cli/config/examples/github-review/ 目录下。默认用启动时所在的目录当工作区，监听 127.0.0.1:3081，可以用 DSH_GITHUB_REVIEW_WORKSPACE 和 DSH_GITHUB_WEBHOOK_PORT 改。

只暴露那一个端口

这是最需要小心的地方。官方文档说明：主界面和它的接口仍然在 3080 端口；这份配置另外开了第二个服务，上面只有 POST /github 这一个路径，别的路径都返回 404。

反向代理应该只把 /github 转给 3081，不要顺手把 3080 端口的主界面也暴露到公网。主界面能让它在你的机器上执行命令，要对外发布的话官方另有一篇专门的说明。官方给的 Caddy 配置正是只转这一个路径的写法。

GitHub 上这样填：

项目	填什么
Payload URL	`https://你的域名/github`
Content type	`application/json`
Secret	`DSH_GITHUB_WEBHOOK_SECRET` 的值
Events	Pull requests

要知道的边界

官方文档对它的可靠性说得很保守：

返回 202 只说明收到了。 签名和 JSON 通过了校验、规则已经安排执行，不代表规则匹配上了，更不代表会话已经建好。
不记录投递状态。 GitHub 重复投递同一个事件，就可能再开一个会话。进程崩溃会丢掉还没开始处理的那一次。
默认的规则只认官方自己的仓库。 示例里写死了仓库名，要用在自己的仓库上得改规则文件。规则是一段普通的 JavaScript，官方给了按仓库映射到不同本地目录的写法。
密钥只管进来的数据。 它验证的是 GitHub 发来的请求，不会让规则或者智能体有权限去操作 GitHub。想让它把评审意见发回 PR，要另外配置。

最后一条意味着，按默认配置它只会把评审写在自己的会话里，你要到网页界面上去看。

常见问题

现象	原因和办法
找不到自动化任务页面	在插件页的官方分组里启用“自动化任务”
建的每日提醒变成了“仅一次”	它理解错了。在自动化任务页面改成每天，或者删掉重建，把时区写明
到点没有执行	程序是不是退出了。调度只在程序运行时进行
发送记录有，但事情没做	发送记录只表示指令发进了会话。到原会话里看它做了什么
重启后一下子收到好几条	过期的一次性提醒和每个重复任务错过的最近一次会补发
在对话里看不到某个提醒	一次性提醒发出后变为未运行，只在自动化任务页面的“全部”或“未运行”里
Webhook 返回 202 但没有新会话	202 只表示收到。检查事件是不是“转为可评审”、仓库名和规则里的是否一致
同一个 PR 开了两个评审会话	GitHub 重复投递了。它不做去重