Dots 适合做的是低风险、可回看的准备工作：到点提醒、把散落信息归成一件事、把回复写成草稿。对外发送、删除、支付、授权这类动作一旦执行就难收回，建议留在人手里，由人做最后一眼确认。分界不是让 Dots 少干活，而是让 Dots 的每一步都能在日志里被看到、被撤回或被人工接管，避免常驻智能体替用户做高风险决策。

把 Dots 的任务边界定在“产生草稿和提醒”，把人的确认边界定在“产生外部副作用”。判断标准可以简单到一句话：某个动作执行后能不能低成本撤回。能撤回的交给 Dots，不能撤回的必须人工确认。发送、删除、支付、授权默认进入人工确认队列，Dots 只负责把它们准备好、摆到人面前。

把提醒、归集、草拟列为 Dots 的默认任务

Dots 的默认任务建议只覆盖那些“做完不对外、出错能改”的动作。常见的有四类：提醒（到点或条件触发通知）、摘要（把长消息、邮件线程、会议记录压缩成要点）、草拟（基于上下文写回复初稿、通知初稿）、待办归集（把聊天、邮件、备忘里的散点整理成任务列表）。

这些动作的共同点是只改本地或会话内的状态，不触发外部副作用。需要在配置里把白名单写清楚，让 Dots 只能调这些能力，发送类接口不暴露给它。

# 通用接入骨架，按你的实际工具替换动作名
dots:
  allowed_actions:
    - remind.create
    - summarize.run
    - draft.create
    - todo.collect
  denied_actions:
    - message.send
    - email.send
    - file.delete
    - payment.create
    - auth.grant

验证方式：跑一次任务后查日志，确认 Dots 的调用记录里只有 allowed_actions；denied_actions 出现即视为配置越界，需要回看是谁放开的。边界是：Dots 可以写草稿、可以标记待办、可以提醒，但不能替人按下发送键。

把发送、删除、支付、授权列为人工确认项

下面这些动作建议一律进人工确认队列，不因为“内容简单”或“频率高”就放行：对外发送（消息、邮件、公开评论、群通知）、删除（文件、记录、云资源）、支付或转账、授权与权限变更（加人、改角色、发密钥）。

人工确认前至少过四个检查点：收件人或渠道对不对、正文有没有带不该带的上下文、金额或权限范围是否和预期一致、这个动作撤回成本有多高。撤回成本越高，确认步骤越不能省。

发送前确认清单（逐项打勾再点发送）
[ ] 收件人 / 渠道 / 群组是否正确
[ ] 正文是否包含内部信息、密钥、个人数据
[ ] 附件与链接是否指向正确版本
[ ] 是否有抄送、密送遗漏
[ ] 金额 / 权限范围 / 生效对象是否核对
[ ] 是否已知该动作不可撤回或撤回窗口很短

执行位置建议放在发送动作之前，由人逐项确认，而不是让 Dots 自动勾选。验证方式：抽查确认记录，看每次发送是否都能对应到一次人工确认；如果某次发送找不到确认记录，说明流程有旁路，需要先补上再继续用。

在任务流里插入草稿与待发送两个状态

只靠“Dots 别发”的约定不够，建议把状态机写进任务流，让发送动作在状态上不可能被跳过。可以用三个状态：draft（草稿）、pending_review（待发送）、sent（已发送）。Dots 只能在 draft 里创建和修改内容；人确认后把状态推进到 pending_review；真正的发送只能从 pending_review 触发，且触发者必须是人。

判断标准：处于 draft 时，内容可改、可丢弃，不产生任何对外副作用；处于 pending_review 时，内容冻结，除了人工确认发送或退回草稿，其他自动流程不得修改或触发它。退回时记一条原因，方便后面调整分界。

-- 通用表结构示例，字段名可按你的库调整
task (
  id            text primary key,
  status        text not null,  -- draft | pending_review | sent | rejected
  draft_body    text,
  reviewer      text,
  reviewed_at   timestamp,
  sent_at       timestamp,
  send_channel  text
);

-- 发送动作只允许这个条件成立时执行
-- status = 'pending_review' AND reviewer IS NOT NULL

验证方式：手动尝试从 draft 直接触发发送，应当被拒绝；再查一次日志，确认每次 sent 之前都有一条 pending_review 和一条人工确认记录。边界是：状态字段本身不防越权，接口层也要校验，别只靠前端按钮隐藏。

每天用任务回看检查误发与漏发

分界定完之后要靠回看来验证。建议每天花几分钟过一遍当天的任务记录，至少记录三类：Dots 执行项（提醒、摘要、草稿、归集各做了哪些）、人工确认项（谁确认了什么、确认了几次）、异常项（误发、漏发、该提醒没提醒、该进确认队列却直接执行了）。

回看时重点看两种偏差：该由人确认的动作被 Dots 直接做了，说明 denied_actions 有缺口；该由 Dots 提醒的事没人看到，说明提醒通道或归集规则需要改。按记录调整分界，比如把某一类发送从“自动草稿加人确认”改成“必须人工手动发送”。

# 回看时的日志行格式示例，时间用实际写入值替换
[ts] dots  remind.create   待办：合同续签
[ts] dots  draft.create    回复：询价邮件
[ts] human review.approve  草稿#102 通过
[ts] human message.send    草稿#102 -> 外部联系人
[ts] alert anomaly         草稿#103 未确认却出现发送记录

验证方式：连续回看几天，如果异常项里反复出现同类问题，就调整白名单或状态流转，而不是靠提醒人去注意。边界是：回看记录本身要能查到动作、时间、责任方，缺任一项都很难判断是误发还是漏发。