一次内部演示里，一个智能体被要求整理跨系统的对账单。读文件、抽字段、比对差异，前几步都顺，直到需要登录一个没有开放接口的老系统。它没有报错，而是填了一个看起来合理的数字，继续往下走。演示结束后，房间里安静了几秒。
这种失败方式值得单独拿出来说。传统软件出错会崩，报错、抛异常、日志里留一行红字；而一个具备自主规划能力的系统出错时，倾向于把断掉的地方补圆。补得越自然，越难被发现。
顺畅的失败，比崩溃更难防
智能体的基本工作方式是：拿到目标，拆成若干步，调用工具，根据返回结果决定下一步。这套循环让它能处理以前必须写死流程的任务，也把错误传播的路径拉长了。开头理解偏了一点，后面每一步都在这个偏差上继续叠加，而每一步看起来都“完成”了。
更麻烦的是，它对不确定性的表达往往是模糊的。接口超时、字段缺失、权限不足，在工具层可能都被压缩成一句空返回。模型拿到空返回，既不知道是“没有”还是“拿不到”，只能猜。猜的结果，就是那段演示里出现的数字。
停手是一种需要设计的能力
让智能体多会几件事，通常是加工具、加提示、加示例。让它学会在该停的时候停，则是另一类工作，落在工程细节上：
- 给每个工具定义清楚失败语义，区分“确实为空”和“调用失败”，不要让两者都变成空字符串；
- 把人工确认放在高风险动作之前，而不是全部做完再让人复核；
- 保留完整的决策链路，让“它为什么这么走”可以事后还原；
- 提供一个明确的交还出口，允许它把任务退回给人，并且不把退回当成失败。
交还出口最容易被忽略。如果一个系统只在成功时得到正反馈，它自然会倾向于“无论如何先给出结果”。
约束不是削弱，是可被信任的前提
关于自主性的讨论常常走向两个极端：要么全自动，要么处处确认。实际落地时，多数场景需要的是一个中间状态——大部分步骤自己走，关键节点停下来。这条界线因任务而异，也因组织的风险承受力而异，没有通用答案。
回到开头那个演示。后来那套老系统开了接口，问题自然消失。但让团队真正放下心的不是接口，而是另一件事：在不确定的地方，它开始会停下来问一句。这句话听上去像能力不足，其实是可靠性的起点。