让它整理下周的会议材料，它先翻文件、改日程、再给相关人发消息。屏幕上跳动的不是一句回答，而是一串动作。问题也随之出现：我到底授权了它做什么？
从“回答”到“动手”，中间多了什么
聊天模型主要处理输入与输出，给出的多是文字。AI Agent 的不同，在于它会把任务拆成若干步骤：观察当前状态，决定下一步，调用工具，再根据结果修正。文件检索、日历接口、消息发送，都是工具。连接的工具越多，它能做的事越具体，出错时留下的痕迹也越具体。
这里有个容易被忽略的细节：工具调用不是“更聪明的回答”，而是对外部系统的真实操作。读一份文档和改一份文档，风险并不相同；生成一条消息草稿和把消息发出去，也不是一回事。AI Agent 需要状态记忆来维持任务连续性，但记忆越长，越要回答一个问题：哪些信息可以被记住，哪些动作必须重新确认。
权限不是开关，而是一组可撤回的边界
给 AI Agent 授权时，容易陷入两种极端：要么只让它说、不让它做；要么把账号权限一股脑交出去。更可行的方式，是把权限拆细。读取资料、生成草稿、修改内部状态、对外发送、删除或覆盖，这些动作的后果不同，确认方式也不该相同。
- 只读类操作可以先放行，但要限定数据范围；
- 写操作先落在草稿或沙箱里，保留回滚路径；
- 对外发送、删除、覆盖等不可逆动作，停下来等人确认；
- 任务中途允许暂停和接管，不要等结束才让人看到过程。
可审计，比“聪明”更先被需要
一个能连续执行任务的系统，出问题时往往不是单点错误，而是几步小偏差叠在一起。日志因此不只是给开发看的调试材料，也是使用者的安全感来源：它调用了什么工具，传了什么参数，拿到什么结果，在哪一步停下。没有这些记录，自动化的边界就只能靠感觉。
我更愿意把 AI Agent 放在流程清楚、反馈及时、后果可回收的任务里。它适合做重复但需要判断的中间层工作，比如整理、比对、分发草稿；不适合在责任模糊、动作不可逆的场景里被当成“全能员工”。期待越高，越需要把停止条件写清楚。
回到开头那个场景，我会把“发消息”和“改日程”拆开：前者先出草稿，后者允许执行但保留撤回。自动化的好处是省下连续点击的时间，不是把判断也一并交出去。给它留一个刹车，任务才可能真正交得出去。