设想一个再普通不过的办公场景：一份资料需要在几个系统之间流转，有人打开页面、复制字段、核对附件、发送通知。把这些动作交给自动化工具，演示往往很顺畅。可一旦缺少某个字段，或者附件名称和记录对不上，流程就会停在半空。此时真正需要回答的，不是“能不能继续点下一步”，而是“该不该由它继续”。
停顿不是故障，而是设计的一部分
谈论智能体时，人们容易把注意力放在它能完成多少步骤。步骤当然重要，但企业环境里的任务很少是封闭的。页面会改版，权限会收紧，输入会缺失，上下游的约定也可能临时变化。一个只会向前执行的流程，遇到这些情况时容易把错误放大。相反，能在关键节点停下来、把问题交回给人的系统，反而有可能被长期使用。
这里的停顿并不等于低效。它更像一种确认机制：当动作涉及权限变更、对外发送、不可逆操作，或者输入信息存在缺口时，系统先暂停，把上下文整理清楚，再由人判断。这样的设计不炫目，却决定了自动化能否进入真实业务。
权限边界比“聪明”更难处理
智能体要执行任务，通常需要接触账号、数据与操作入口。能力越往下游走，权限问题越具体：它能读到哪些字段，能不能代发消息，出现误操作后如何追溯。这些问题无法靠一句“模型会理解”解决。更稳妥的做法，是把权限切成小块，把高风险动作留给人工确认，把可回滚的动作交给系统执行。
换句话说，智能体的价值不只在替人完成动作，也在暴露流程里原本模糊的责任边界。哪些步骤必须留痕，哪些判断不能外包，哪些异常需要升级处理，都会在落地时被迫说清楚。对编辑或运营人员来说，这种“被迫说清楚”未必轻松，但它比一个看似全能的演示更接近可用状态。
把演示效果放回真实流程里看
评估一个自动化流程，不妨先看它在异常情况下如何收场。输入缺失时，它能否指出缺什么；权限不足时，它能否停下来而不是反复尝试；任务完成后，它能否留下可核对的记录。这些问题不够热闹，却直接影响日常使用。演示环境里的顺滑，常常来自被提前清理过的输入；真实环境里的稳定，则来自对不顺滑部分的处理。
我的判断是，智能体短期内不会取代对流程的理解。它更像一个需要被约束的执行者：边界清楚时，它能减少重复劳动；边界模糊时，它也会把模糊放大。企业真正要建设的，可能不是一路向前的自动化链条，而是清晰的停顿点、细分的权限划分和可追溯的确认记录。把这些基础工作做在前面，这类系统才不至于停留在展示屏里。