安排会议、整理纪要、跟进待办，这些事拆开看都不难。可一旦交给一个自动流程连续执行，问题常常不是“它会不会”，而是“它卡住时谁知道”。比如它读不到某个日历权限，只能把草稿留下，停在半路。任务没有完成，但也没有造成额外麻烦。
这个停顿值得琢磨。演示里的智能体通常沿着顺路径走：理解指令、调用工具、返回结果。真实环境却到处是缺口：字段缺失、权限不够、接口超时、对方改了时间。能把这些缺口显式暴露出来，才算接近可用。
能干活，不等于能收场
讨论智能体时，人们容易把注意力放在它能调用多少工具、能拆多长的任务。工具数量当然重要，但工具越多，越需要一套停止规则。哪些动作只能建议、不能直接执行，哪些操作需要二次确认，哪些异常必须转给人，这些设定不显眼，却决定了流程能不能交给它。
我倾向于把“暂停”看成能力的一部分，而不是失败。一个流程如果只会向前冲，遇到模糊指令也硬着头皮猜，风险会放大。相反，能承认信息不足、把选择权交回来，至少让使用者知道当前发生了什么。对团队来说，这种可回退的停顿有实际价值。
权限给少了走不动，给多了睡不着
这类流程落地时，权限是绕不开的矛盾。给少了，它只能做草稿和提醒，价值有限；给多了，一次误操作就可能碰到不该碰的数据。比较稳妥的做法不是一次放开，而是按任务阶段切分：先读后写，先生成后确认，先小范围试运行再扩大。每一步都留下可查的记录，出了问题能回溯到哪一步。
- 先明确哪些结果只能作为建议呈现，不能直接对外发送。
- 为关键动作设置人工确认点，尤其是涉及删除、覆盖、对外通知的操作。
- 保留中间状态和操作记录，让中断之后可以接着处理，而不是从头再来。
这些做法听起来不新鲜，难的是在产品设计里真正留出位置。很多流程为了追求“一口气跑完”，把确认环节藏得很深，用户看不到它正在做什么，也不知道该在哪里接手。等结果不对再回头查，成本已经上去了。
把失败路径摆到台面上
评估一个智能体，除了看任务完成情况，也该看它如何失败：是安静地停下，还是给出含糊的结果；是把异常吞掉，还是明确告诉使用者缺什么。团队内部可以先用低风险任务磨合，把常见中断场景列出来，再决定哪些交给自动流程，哪些保留人工。这个过程不会一劳永逸，权限和规则需要随着任务变化调整。
说到底，智能体更像一段需要边界感的协作流程，而不是一个无所不能的替身。它越能做事，越需要知道什么时候不做。下一次它说“我做不到”，也许不是能力不够，而是系统终于学会了在正确的位置停住。