早上打开电脑，把一叠散落在聊天记录里的待办事项交给一个智能体，让它整理成清单、补上时间、再发回给自己。演示到这里通常很顺，真正让人犹豫的是下一步：它读过哪些文件，改过哪条记录，发错对象时能不能撤回。会回答问题只是表面，能不能在真实系统里动手，才是分水岭。
这也是近期讨论里容易被忽略的一面。人们盯着它能不能一次完成复杂任务，却很少先问：哪些动作允许自动执行，哪些必须停下来等人确认。
从会聊天到会动手，变化不在“聪明”
对话模型主要输出文字。加上工具调用、状态记忆和任务分解之后，它才更像一个能连续做事的执行者。这个循环大致是：观察当前信息，拆出下一步，调用某个接口，读取结果，再决定继续还是停下。能力边界也随之变化——它不只知道该说什么，还可能要登录系统、修改表格、发送通知。
问题在于，多步任务里的错误会叠加。一步理解偏差，后面可能沿着错误方向走得更远。因此，讨论智能体时，不能只看它完成任务的成功率，还要看它出错时是否容易发现、容易打断、容易恢复。这里不需要神秘化，它更像一段会自己选择路径的自动化流程，只是路径不再完全由人预先写死。
权限给到哪一步，决定它是助手还是风险源
一个稳妥的做法，是把权限拆细。读取和写入分开，草稿和发送分开，可逆操作与不可逆操作分开。涉及对外发送、删除、公开发布等动作，设置人工确认节点；涉及内部查询和整理，可以先在隔离环境里跑。日志也要记到动作层：谁发起、调用了什么工具、传了什么参数、返回了什么结果。否则出了问题，只能看到一句“它自己做的”，却找不到落点。
可追溯，是它落地前的底线
很多任务并不需要复杂的智能体。规则明确的单步操作，用脚本或固定流程就够了。智能体适合信息不完整、步骤会变、需要边做边判断的场景，比如从多份材料里收拢待办、按条件筛选后生成草稿。即便如此，也要给它留刹车：超时停止、异常中止、结果回退、人工接管。把这些机制放在前面，演示才不会变成负担。
把智能体放进业务前，先把它犯错时的样子想清楚。能说清楚“哪里不能碰、出了事怎么查、谁来接手”，才算把演示变成了可用的流程。