第一次看智能体跑任务，多数人会觉得顺滑：你给一个目标，它自己拆步骤、调工具、看返回结果、发现不对再改一版。整个过程像有人在替你加班。
用上一周，感觉会变。它确实能做完一大半，但剩下的那一小半，往往不是“做错了”，而是“看起来做完了”。这两种失败完全不是一回事，处理方式也不一样。
它不是更聪明的模型，是一个循环
把智能体理解成“更强的模型”，容易误判。模型负责判断，真正让它动起来的是外面那层循环：想一步、做一步、读反馈、再想下一步。工具是它的手，记忆是它的桌面，权限是它能进的门。判断质量决定它第一步走得对不对，循环结构决定它能不能走回来。
问题也长在循环上。单步正确率再高，几十步连乘下来也会明显下滑。更麻烦的是，错误通常不会以报错的形式出现——它会把一个错误的前提当成既定事实，接着往下推，每一步都合逻辑，整条路径却偏了。等你看出来的时候，中间已经做了一堆动作。
先谈权限，再谈能力
讨论能力容易兴奋，讨论权限容易犯困。但真实部署里，卡住的多数是后者：它能读哪些文件，能改哪些系统，能不能把东西发出去，发出去之后能不能撤回。这些问题的答案，比“它有多自主”更能决定你敢不敢让它跑。
我习惯先问三件事：
- 失败的时候，损失是不是不可逆。可逆的动作可以放开，不可逆的必须单独拎出来，让人点一下。
- 每一步有没有留下人能看懂的东西。不是给机器看的日志，是给下一个接手的人看的记录。
- 中途换人，能不能接得上。如果只有它自己知道做到哪了，那它就不是工具，是单点。
把不可逆动作挑出来，并不是不信任模型，而是承认任何流程里都得有个刹车。
停止键要装在人手边
很多系统其实有停止功能，只是位置不对。有的藏在日志页面深处，有的要先重启服务，有的按下去之后状态说不清楚——停了，但已经发了多少、改了几条，没人知道。这种停止形同虚设。
可用的停止应该满足两个条件：几秒内能掐断，掐断之后能说清停在哪一步、此前做了什么。前者是工程问题，后者是设计问题，后者更难。它要求在系统里从一开始就留出可回读的痕迹，而不是事后去日志里翻。
还有一层容易被忽略：智能体该不该“知道自己被看着”。至少在今天，让每一步有痕、让关键节点需要确认，比让它一路畅通更划算。可见性会改变行为，这一点对人和对系统都一样。
划清边界的地方，才敢放开跑
我的判断是，接下来一段时间，差距不在谁的智能体更自主，而在谁更敢把边界划明白。划清楚的地方，尽管让它连着跑几十步；划不清楚的地方，宁可让它停下来问你一句，也别自作主张。
一个好的智能体，不是永远不需要人，而是知道什么时候该把人叫回来。