下午的会刚散，录音、聊天记录和待办散在三个窗口里。设想让一个智能体把纪要整理出来，再按讨论结果建日程、发提醒。它很快做完，却把一句玩笑当成承诺，把两个同名项目并在一起，还在没确认时按模板发出了通知。问题并不神秘：它会调用工具，却不知道什么时候该停下来。
聊天框出错，改一句话就好；一旦接手浏览器、日历、文档和邮件，动作会留下痕迹。多步计划、工具调用、状态保存，让软件从“回答问题”变成“推进事情”。这也意味着，提示词写得再细，也替代不了流程里的权限和刹车。
先设计停手点，再谈自动化
真实工作流里，先要问的是：哪些动作可以自动做，哪些必须等人点头。读取公开资料、生成草稿、在沙箱里试运行，风险相对可控；对外发送、删除覆盖、改动共享权限、跨系统修改身份信息，应该设置确认点。确认点不是弹窗数量问题，而是位置问题：放在后果不可逆的地方。每次确认最好带上前因后果：它准备改什么、依据是什么、失败后怎么恢复。
权限也要分层。能读不一定能写，能写一个文档不意味着能碰整个目录。工具清单需要白名单，运行环境需要隔离，关键操作要有日志和回滚路径。对智能体的验收，不妨看它失败时是否暴露得清楚：有没有说明缺哪条信息，有没有把不确定项标出来，有没有在越界前停住。完成率能说明一部分问题，恢复成本同样值得记录。
它需要知道“不知道”
任务边界不该只藏在提示词里。提示词像临时口头交代，流程才是长期约束。把可接受的输入、不可触碰的数据、必须确认的动作写进工具协议和审批规则，比反复叮嘱“谨慎一点”有用。记忆也是同理：记住偏好可以省事，记住过期结论会带来麻烦。哪些内容进入长期记忆，哪些只保留在当前任务，需要明确策略。
所以，智能体适合接手的，往往是流程清楚、反馈及时、错误可回滚的任务；边界模糊、责任无法拆分的环节，交回人处理。这不是保守，而是把自动化放在能解释的位置。先谈刹车，再谈油门，才可能让它在真实工作里待得久一点。