清晨的办公区还没完全热起来，屏幕上的一条指令先到了：“把这批反馈整理一下，能处理的先处理。”如果执行者是人，多半会先追问：哪批反馈、处理到什么程度、能不能直接回复客户。换成智能体，它可能立刻检索、归类、起草回复，动作很快，却在某个不该越过的边界前没有停。
很多人对智能体的想象，是一个能自己拆任务、调用工具、连续行动的“数字同事”。这个想象不算错，但它省略了一个关键部分：行动之前，系统是否知道自己被允许做什么。以前是人把流程写死，现在是把判断交给模型；以前担心脚本出错，现在还要担心它“太会变通”。
先别问能做什么，先问哪里不能做
一个可用的智能体，未必要在每一步都抢着行动，它需要能在模糊处收住。收住不等于无能。它可能表现为发起确认、请求补充信息、把任务退回给人，或者在权限不够时说明原因。这些动作看起来降低了自动化程度，却把系统从“演示”拉回到“日常”。错误成本往往不来自不会做，而来自做了不该做的事。
这背后是权限设计。工具调用越丰富，边界越要清楚：哪些数据可读，哪些可写，哪些操作必须二次确认，哪些结果只能作为建议。把这些规则放在提示词里不够稳，放在系统层更可靠。模型可以理解意图，但权限应由外部约束兜底。换句话说，智能体可以有自己的判断，但不能有自己的“例外”。
停顿不是卡住，是流程的一部分
有人把等待确认视为体验缺陷，觉得不够顺滑。可如果把所有确认都拿掉，流程会顺滑得让人不安。真正需要观察的，是停顿发生在哪里：读取敏感信息之前，对外发送之前，不可逆操作之前，还是仅仅因为模型不确定。前几种停顿是设计，最后一种意味着系统没把握。两者混在一起，用户就会觉得系统时灵时不灵。
所以，评估这样一套系统，不能只看任务完成率。还要看它能否解释为什么停下、把上下文交给谁、接手的人是否看得懂。可观察性在这里承担基础作用，花哨能力并不能替代它。日志里如果只有“成功”和“失败”，没有中间状态，人就无法判断该修规则还是换模型。把停顿记录下来，是让自动化可信的一步。
把它当同事之前，先把它当流程中的角色
我倾向于把它看作流程里的一个新角色，而不是一个独立员工。角色有职责，也有禁区；有交接，也有复核。它可以承担检索、整理、初稿、提醒这些动作，但需要知道什么时候把结果放到人面前。人不必事事盯着，只需在关键节点保留决定权。这样的分工不新鲜，只是过去由人来衔接，现在多了一层模型判断。
这也解释了为什么一些看似“不够自动”的系统反而可能被长期使用。它们不追求一次说完所有话，而是在该问的时候问一句。用户第一次可能嫌慢，第二次会开始信任，因为它没有替自己做主。自动化难的地方，不是把每一步都交给机器，而是找出哪一步必须留给人。
回到开头那条含糊指令。稳妥的处理方式，也许不是让系统继续猜，而是让它先停一下，问清楚“这批”指什么、“处理”包括哪些动作。停顿几秒，换来的是一次可控的执行。对这类系统来说，知道何时等一等，是成熟度的一部分，和加速能力并不在同一维度。