8.2 个人助理与自动化：最普适的落点

8.2 个人助理与自动化：最普适的落点

本节摘要：个人助理是智能体最普适也最挑剔的场景——普适在人人都要管日程、邮件、报销，挑剔在它接触的是个人最私密的数字生活。本节讲清这类产品的三条工程主线：权限的克制设计、任务的可中断恢复、与既有工作流的嵌入方式，并用一个报销助理的完整落地过程串起全部要点。

个人助理类产品有一个悖论式的成功标准：做得好没人注意，做错一次人人皆知。它订对了十次会议室，无人称赞；订错一次重要会议，信任清零。这个特性决定了它的工程重心不在"多聪明"，而在"多可靠、多克制"。

权限：克制是第一设计原则

助理接触的是个人数字生活的全部：日历、邮件、文件、聊天记录。权限设计的目标是让用户敢于授权，而不是让功能最大化：

读宽写窄。读取类权限可以相对慷慨（日历、文档的读权限是理解上下文的基础），写入与外发类权限逐项申请且默认最小——助理可以读日历来理解你的日程语境，但替你发邮件需要单独授权，替你接受会议邀请默认要过确认。

动作分级沿用 7.3 节的三级风险：纯读取直接执行；个人范围内的写入（新建备忘、草稿箱存邮件）执行后可撤销；对外可见的动作（发出邮件、接受邀请、提交单据）默认走确认。分级让确认弹窗集中在真正需要的地方——这正是护栏"不被绕开"原则在个人场景的回响。

授权可审计。用户要能随时看到"助理最近做了什么、动用了哪些权限"，并且一键收回。审计界面不是合规装饰，是用户信任的储蓄罐。

中断恢复：长任务的日常形态

个人场景的任务天然碎片化：订票订到一半用户来电话，处理邮件处理到一半用户追加新要求。助理的任务必须设计成可暂停、可恢复、可放弃的状态机——4.3 节 Plan-and-Execute 的计划结构在这里多一个字段：

@dataclass
class TaskState:
    plan: dict                  # 4.1 节的步骤计划
    done_facts: dict            # 已完成步骤的结论（4.3 节）
    status: str                 # running / paused / awaiting_input / done / aborted
    pending_input: dict | None  # 缺什么信息（need_clarify 的步骤断在这里）
    checkpoint_at: str          # 最近一次落库时间——恢复点

def resume(task_id: str, user_reply: dict | None):
    t = load_task(task_id)
    if user_reply and t.pending_input:        # 用户补上了当初缺的信息
        t.done_facts[t.pending_input["step"]] = user_reply
    if stale(t.checkpoint_at):                # 恢复时先核对事实是否过期
        t.plan = replan_from(t.done_facts)    # 过期部分重排（4.3 纪律）
    continue_execution(t)                     # 从断点继续，已完成步骤不重跑
​

三个细节决定体验。断点要带上下文：恢复时助理的第一句话应当是"接着上次的事——还差你确认同行人"，而不是让用户重新描述任务。过期要重验：跨天恢复的任务，机票价、会议室状态都要重查（2.4 节的时效原则在产品层的体现）。放弃要体面：用户说算了的时候，已产生的副作用要能回滚（草稿删除、临时占位释放），并给一句交代。

案例：报销助理的完整落地过程

背景：某公司要为三百名员工上线报销助理：收集票据、填单、跟踪进度、提醒补料。

操作：按本节的三条主线设计——权限上，读权限覆盖邮件附件与票据图片，写权限只开放报销草稿，提交动作走 7.3 节的人工确认（金额超标强制，正常金额抽样确认）；中断恢复上，"缺发票"的任务进入 awaiting_input 状态，用户拍照上传后从断点续跑；嵌入方式上，助理不另起 App，嵌在员工已有的聊天工具里，任务通知以消息形式推送。

结果：上线首月，报销单平均处理时长从三天缩到一天内；确认弹窗的日均触发率为每用户不到一次（分级设计的直接收益）；一次票据系统故障导致的中断任务全部在恢复后正常续跑，无重复提交。

解读：三个结果各自验证一条主线——处理时长证明嵌入既有工作流降低了使用摩擦，弹窗频率证明动作分级保住了确认的严肃性，故障恢复证明了中断恢复机制不是纸面设计。个人助理的竞争力就是这三个"小事"的总和。

变式：家庭场景的个人助理（智能家居、日程管家）把"多用户共享权限"变成新命题——家人的日程互相可见吗？访客指令的权限边界在哪？多租户隔离（3.3 节变式）在家庭语境下重新出现，且情感接受度比企业场景更苛刻。

⚠️ 常见坑：以"主动"之名越界。助理未经询问就替用户回复邮件、整理并删除"过期文件"——即便判断正确率高，越界本身就是信任事故。个人场景的主动性必须有开关、有范围、有事后交代。

本节要点回顾

• 信任是唯一硬通货：读宽写窄、动作分级、授权可审计，三项加起来构成"敢于授权"的基础。
• 中断是常态不是异常：任务状态机化，断点带上下文，恢复时重验时效，放弃时体面回滚。
• 嵌入既有的工作流：助理活在用户已有的工具里，而不是让用户搬家——摩擦每低一分，留存多一分。
• 主动性要克制：有开关、有范围、有交代；越界的"贴心"是信任事故。

下一节转向高并发、强 SLA 的对立场景：客户服务与销售——当助理从服务一个人变成服务一百万个会话，工程重心如何迁移。

冷启动：新用户的第一周

个人助理产品的流失高发在第一周——用户授权意愿低、不知道它能干什么、试错一两次后搁置。工程上能做三件事：最小授权启动——首日只申请读日历与读通知两类低敏权限，让用户以零心理负担完成第一次成功体验，写权限按需逐项后补；能力示范而非罗列——引导流程里让助理真的完成一件该用户日历上的小事（比如把明天的会议与航班时间对齐提醒），比罗列十项功能更能建立"它懂我"的预期；可解释的主动性——助理提出的每条主动建议附带一句"因为你上周说过……"式的依据（来自 3.3 的记忆），主动性有出处，才不会滑向越界的观感。这三件事的共同底色还是本节的主题：信任是逐步储蓄的，功能可以迭代，透支信任没有第二次机会。