把智能体接进工作流的第一周，通常很安静。它按指令读文件、整理记录、发消息，动作利落。第二周，问题开始冒头：有人发现一份文档的措辞被改了，却说不清是哪一步、哪个指令触发的。团队只好停下来，重新讨论几个看似笨拙的问题——在让它干活之前，是否先问清楚：
- 它改了什么？
- 它为什么改？
- 改错了怎么退回去？
先把边界写短，再谈能力清单
很多演示喜欢展示它能调用多少工具、覆盖多少步骤。真正进入日常，边界往往先于能力被感知。它能读哪些目录，能不能写，写完要不要人确认，这些限制决定了它是帮手还是隐患。能力清单可以很长，边界却必须短而清晰。把权限收窄，不是不信任，而是让每一次动作都有迹可循。
把确认放在动作之前
有人习惯事后审计，觉得日志能兜底。可它的动作往往连着下一步，一次误写可能触发连锁修改。可行的做法是，在关键节点插入确认：写操作前确认，对外发送前确认，删除前确认。确认不是拖慢效率，而是把不可逆的动作变成可逆。对于高频、低风险的操作，可以放开；对于低频、高影响的动作，保留人工闸门。
记忆是便利，也是负担
智能体通常靠上下文或记忆保持连贯，这让多轮任务更顺。但记忆也会把过时的偏好带进新任务。一个曾经有效的规则，换个场景可能就不合适。定期清理记忆、明确哪些信息可以跨任务保留，是容易被忽略的功课。记忆的边界，本质上也是责任的边界。
先让它做可回滚的事
如果一项工作无法回滚，就不适合直接交给它独立完成。可回滚意味着有版本、有备份、有撤销路径。把智能体放在可回滚的环节里试，积累的不只是使用经验，还有对失败模式的了解。等流程稳了，再逐步放宽权限；一开始就追求全自动，往往会把风险藏进细节里。
智能体真正改变工作的地方，可能不是它替人做了多少，而是它迫使人把原本模糊的流程写清楚。权限、确认、回滚，这些词听起来不新鲜，却决定了它能不能长久地待在工位上。下次准备给它开账号时，不妨先问那三个笨问题。