演示视频里，一个任务三步就完成了：读需求、调接口、写回结果。真正接进公司系统之后，第一周通常最难看——同一张表单提交了两遍，卡在某个权限页面上不动，或者把三个月前的旧版本当成最新的填了进去。围观的人会问：它不是挺聪明的吗？
它不是一个更聪明的模型
把智能体理解成“升级版聊天框”，是大部分误解的来源。它更像是给模型套了一圈循环：看当前状态、挑一个动作、调用工具、读回结果、再决定下一步，直到某个条件成立就停下来。模型决定这一步“想干什么”，循环决定它“能不能干成”。工具的参数描述写得含糊，它就会传错；工具失败时返回一句空话而不是明确的错误，它就会以为成功了继续往前走。
差距藏在返回值和终止条件里
演示环境和生产环境的区别，往往不在模型，而在几个很朴素的地方：
- 工具返回的是结构化结果，还是一段需要再猜的自然语言；
- 失败时是明确报错，还是静默返回空值；
- 有没有超时、步数和调用次数的上限；
- 跑到一半的状态，人能不能看见、能不能接管。
这四件事没有一件属于“模型能力”，全都属于工程。也正因为如此，同一个模型在不同团队手里表现可以差很远，而外行看到的只是同一段演示视频。
“自主”是个需要打折的词
步数一多，早期读到的那条关键信息会在上下文里被逐渐稀释；某一步的小偏差，会在后面被当成既定事实继续推演。所以真正能稳定跑起来的做法，常常是反直觉的：把任务切小，在中间加检查点，把不可逆的动作——删除、提交、对外发送——留给人确认。听起来不够酷，但它把“出错”从一次事故变成一次可以回滚的操作。
我更愿意把现阶段的智能体看成一个执行力不错但需要交底的同事：你交给它的活，它愿意一板一眼地推进，但它不会主动告诉你“我这一步是猜的”。
判断它值不值得留，看三件事
- 出错时，能不能说清是在第几步、因为什么错的；
- 同样的输入，走的路径是否大致稳定，而不是每次都不一样；
- 停止的条件是否明确，会不会在该收手的时候还在折腾。
如果一个东西失败之后你完全看不出原因，那不是能力问题，是观测问题。观测做不好，再换更强的模型也只是把不可解释的失败推迟几天发生。
所以评估一个智能体，先别急着问它一天能替你干多少活。先问一句更笨的问题：它做错的时候，你看不看得见。