一个常见的画面：运营人员把智能体接入工单系统，希望它自动分类、回复、转派。头两天顺滑，第三天出现一条描述含糊的投诉，它连续调了三次接口，把工单在两个队列之间来回推。人发现时，不是它做错了什么大事，而是它不知道该在什么时候停。
这类问题不太像模型能力不足，更像流程设计里少了一行约束。它能调用工具、拆解步骤、根据返回结果调整下一步，但它对“完成”和“越界”的判断，并不来自模型本身。它来自你写在它动手之前的规则。
停下来的条件，得写在它动手之前
很多团队把它当成带规划能力的自动化，上线前只写目标，不写约束。目标通常是“处理工单”，可“处理”包含多少动作，没有说清。于是它在模糊指令下会自行补全：查用户、改状态、发通知、再转派。看起来积极，实际在扩大操作面。
稳妥的做法是把停止条件前置。比如：同一工具连续调用超过两次就暂停；任务在两个队列之间往返一次就转人工；涉及修改原始记录的动作必须等人确认；失败重试达到预设次数后不再自行换路径。这些规则不复杂，但需要在接入前写进编排层，而不是等它跑偏后再去日志里找原因。
工具越多，边界越要收窄
智能体通常通过工具调用与外部系统交互。工具越丰富，它能做的事越多，活动空间也越大。问题在于，权限设计常常滞后于工具接入。先把查询、创建、修改、删除一并放开，再指望它在运行时自己判断轻重，风险不小。
务实的顺序是：先给窄工具集，只开放读取和低风险写入；观察它在真实任务里的调用链，再逐项放开。每放开一个写操作，都配一个回滚方式。这不是保守，而是让边界和权限同步生长。它不需要一开始就拥有完整的手脚，它需要的是清楚哪一步不能迈。
人盯的不是结果，是过程里的信号
监控它的运行，只看最终输出对不对，往往太晚。过程里有几个信号能提前暴露问题：
- 重复调用同一工具，说明它可能在原地打转；
- 任务在队列之间来回跳转，说明分类或路由规则存在歧义；
- 步骤数明显超出预设，说明它在勉强拼接动作；
- 请求了未授权数据，说明边界约束没有生效。
这些信号不需要复杂的看板，先落在日志和告警里就能用。关键是有人认领：谁来看、看到之后按什么流程介入。否则监控只是多了一张图。
回到开头那个工单场景。后来团队加了两条规则：同一工单转派超过一次就停，描述置信度低时直接转人工。它还在跑，只是不再被要求“必须处理完”。这个调整没有提升它的自主性，反而让它更像一个知道边界的执行单元。
把智能体放进流程之前，先回答“它什么时候必须停”，比回答“它能做多少事”更实际。前者决定它能不能被放心地留在流程里，后者只决定演示时好不好看。