凌晨跑完的那件事
早上打开电脑，发现昨晚挂着的任务已经完成：中间调了几次外部接口，失败过一次，自己重试，最后把结果放在了指定位置。整个过程没有人盯着，也没有人逐步点确认。这类画面这两年越来越常见，支撑它的，通常是一个被称作智能体的东西。
值得追问的不是它跑得多快，而是它在这几个小时里，替人做了哪些判断。
它和对话框不是同一类东西
很多人对这类程序的第一印象来自聊天窗口：问一句，答一句。那个形态的局限很明显——每一步都要人推进，人停它就停。而能自主推进任务的程序，核心差别不在回答质量，而在一个循环：它拿到上一步的结果，判断是否达到目标，没达到就换一条路径继续。工具调用只是其中一环，真正撑起这个循环的，是状态的保存和失败之后的处理逻辑。
所以它接管的不只是“生成内容”，还有“决定下一步做什么”。这一点常被演示视频掩盖，因为在演示里，路径总是顺的。
判断权交出去之后
把任务拆开看，里面藏着大量小决定：先查哪个来源，结果不够用要不要换方法，遇到权限错误是重试还是绕路，什么时候该停下来问人。人在做这些时靠经验和上下文，很少意识到自己正在做判断。交给程序执行，这些隐性判断就必须被显式写出来，写成规则、写成条件分支，或者交给模型临场表态。
麻烦出在最后一种。临场表态灵活，也意味着同一件事两次运行可能走出不同路径。顺利时这叫适应性强，失败时就变成难以复现。所以真正需要设计的，不是让它多聪明，而是让它在哪里必须停。涉及对外发送、删除、权限变更这类不可逆动作，多数团队会留一道人工确认；检索、整理、格式转换这类可以回退的操作，放手让它跑问题不大。
另一件容易被低估的事是可观测性。人不在场，日志就成了唯一的现场。哪些步骤发生过重试、哪一步的输入和预期不一致、模型在哪一句上改变了主意，这些如果没留下痕迹，事后复盘几乎无从下手。
边界比能力更值得先说清
一个常被忽略的事实是：执行能力越强，错误的传播也越快。它一步走偏，后面几步可能都建立在这个偏差上，而且表面上一切正常。人在环里的时候，靠的是随时能喊停；人离开之后，靠的只能是事前埋好的检查点。
因此判断一个智能体是否可用，与其看它能完成多少步骤，不如看它出错时的表现：会不会重复同一个失败动作，会不会把不确定的结果当成确定的往下传，会不会在该停下来的时候继续推进。这些细节不写在介绍材料里，只有在真实任务中反复跑才会暴露。
它更像一个被授权的执行者
把它理解成“更聪明的助手”容易走偏。助手等着指令，而它拿到的是目标，外加一片可用的操作范围。范围划得多大，决定了它是省事还是添乱。比较稳妥的做法是先把任务切小，让每一步的失败都能被单独看见；再逐步放开权限，而不是一次性把整套流程都交出去。
回到凌晨跑完的那个任务。它省下的不只是一段等待时间，更是把人的注意力从“盯着流程”挪到了“设计流程”。价值和风险其实集中在同一处：谁来决定下一步。答案清楚的时候，智能体是个称手的工具；答案模糊的时候，它只是把不确定性提前执行了一遍。