DWS 待办与投递
启用原生待办触发，区分 IM 重试队列和评论发送策略。
DWS 的原生待办触发和消息投递有各自的持久状态。看到结束反应不等于收件方已经收到结果。
原生待办触发
watchTodos 默认 false。在已有 DWS 渠道配置中启用后，每 30 秒检查固定 profile 所在组织中、当前账号作为执行人的未完成原生待办。
{
"watchTodos": true
}第一次成功扫描只建立基线，不执行历史待办。后续新分配、重新打开，或标题、优先级、截止时间、执行人等可执行字段变化，才会启动任务，并把结果作为待办评论。
仅评论元数据和修改时间变化不触发，因此自己的回复不会形成循环。完成或移除会从待处理集合删除，重新打开则形成新触发。
准入身份是待办创建者，遵循 privatePolicy。pairing 下未获准的创建者会收到一次配对码评论，待办保持待处理；本地批准后，后续扫描可执行没有再次修改的待办。启动 IM 消息来源需要权威的自身 openDingTalkId，缺少且无同 profile 的已知身份时会拒绝连接；不能靠评论文本推测账号身份，重连保留既有身份记录。
IM 回复队列
群 @ 或私聊任务的结果在首次发送前写入检查点。发送失败时后台重试回复，不重新执行 agent 任务。
| 条件 | 处理 |
|---|---|
| 传输失败 | 从 5 秒开始指数退避，最多 5 分钟，16 次失败后放弃 |
| 渠道断开或配对记录暂时不可读 | 最多连续 32 次本地延后检查，不消耗传输尝试次数 |
| 发信人、群或私聊权限确定撤销 | 立即丢弃待发送回复 |
| 队列超过 100 条 | 移除最旧条目，不论已经尝试几次 |
| 配置改为另一个 DWS profile | 清空旧回复队列 |
丢弃原因写入渠道 stderr，不通过聊天通知。超过 12000 个 Unicode 码点的排队回复会截断，并在用户看到的内容后追加 [Response truncated for DWS delivery.]。
文档和待办评论不同
文档评论、原生待办评论每轮只调用一次评论发送，不进入上述 IM 队列，也不采用其截断逻辑。结果未知时不继续抛出发送错误；确定失败则交给已有入站轮次重试策略。
排查时应先分清失败发生在任务执行、IM 发送还是评论发送，不要套用同一种重试次数。任务结束的反应只标记执行状态，不能作为评论或 IM 已送达的证明。