见过一个挺典型的场面：会议室里，演示用的智能体在屏幕上把一份报销单填完、核对、提交，全程不到两分钟。三个月后同一套东西上线，实际接管率低得让负责人不太想聊。
不是模型变笨了。演示里那张单据是干净的：字段齐、格式对、附件在。真实工位上，一张单子可能缺发票号，可能两张单子的编号撞了，也可能附件是拍照的、歪着、还带反光。它不怕复杂，怕的是“说不清”——没人告诉它这个字段能不能空着，于是要么猜，要么停。
演示省掉的，是那些没人愿意写下来的分支
流程文档通常只写主干。可实际做的时候，人能顺下去的很多步骤，靠的是没被记录下来的经验：这个人上次补过材料，那笔钱超过某个数要先问一句。这些判断零散、含糊、因人而异。人自己操作时不觉得这是规则，交给机器才知道，这些默会信息根本递不过去。
所以很多时候，把智能体推上线，倒逼团队第一次把流程真正写清楚。这件事的价值可能比自动化本身更实在，但也很枯燥，最容易被跳过。
出问题时，先要问的是它被允许做什么
从技术上看，它大致是模型、工具和一段循环的组合：想一步，调一个工具，看结果，再想下一步。能力上限由模型决定，风险下限由工具权限决定。工具给得宽，链路上任何一步判断偏了，后果都会被放大。
比较稳妥的顺序是先只读，再限定写入范围，关键节点留人工确认，日志记到能回溯每一步调用了什么工具、拿到了什么返回。这些听着不新，却常被“先跑起来再说”挤掉。等真出了错，讨论的往往不是模型，而是谁批的权限、谁看的日志、出了事算谁的。
人留在异常那一侧
我倾向于认为，短期内人的位置不在流程中间，而在两侧：一侧是把模糊需求翻译成清晰边界，另一侧是接住它停下来的那些情况。后者听着像兜底，其实需要更强的判断力——要能看出它为什么停，是信息不足、工具报错，还是理解偏了。
哪些任务适合先交出去？我自己的判断有几条：输入格式相对稳定，错误代价可承受，结果可验证，并且有明确的“做完了”的定义。这几条里缺得多了，多半会变成新的负担：人不是省事了，而是多了一件要一直盯着的事。
至于那些边界模糊、需要跟人反复来回确认的活儿，现在做起来还是笨拙的。它不会因为对方语气变了就换一种说法，也不会意识到这封邮件其实不该发。这些不是靠写更长的提示词能补上的。
回到开头那个会议室。真正该问的也许不是“它能做多少”，而是“它做错的时候，我们多久能发现”。这个问题的答案，通常不写在演示里。