凌晨一点，一位朋友在群里发问：为什么让 AI Agent 帮忙订一张第二天的高铁票，它先信誓旦旦说“已为您查询”，接着打开浏览器，在几个页面之间转了三圈，最后给出一张并不存在的车次信息。
这个场景几乎概括了当下 AI Agent 的处境。它被描述成能替人完成多步任务的东西，但真正落到带验证、带支付、带异常处理的流程里，表现往往不如一次普通的表单提交。问题不在于它不够“聪明”，而在于我们对“做事”这件事的复杂度估计不足。
从会说话到能交付，中间是什么
把模型能力比作一个人，聊天大致相当于他坐在你对面回答问题；而 Agent 要求他站起来，找到工具，按顺序操作，并在出错时自己回头。这中间至少有三件事要额外成立。
- 工具调用：模型要知道在什么时刻该调用哪个接口，并且把参数拼对。参数错一位，后续全盘作废。
- 状态记忆：多步任务里，前面拿到的结果要能稳定地带到后面。上下文一长，早期信息容易被稀释，Agent 就会重复问同一个问题。
- 失败恢复：网页结构变了、接口超时了、验证码弹出来了，它需要识别“这里不对”，而不是硬把流程走完。
这三件事都不属于语言能力本身，而是工程问题。于是出现一个现象：模型在演示视频里行云流水，一放进真实系统里就磕磕绊绊。演示环境是精心修剪过的温室，真实环境里每个环节都可能长刺。
它最擅长的，可能不是“全自动”
很多讨论默认 Agent 的终点是全自动：人只提需求，剩下交给它。但从实际使用看，更稳妥的落点往往是半自动，也就是人来设定检查点，Agent 负责把连续的、机械的环节串起来。
比如处理一批格式不一的文件，人先确认提取字段，Agent 完成批量读取和整理；或者在做资料梳理时，由 Agent 先行打开页面、摘取要点，人再判断哪些可用。这类任务有个共同点：中间步骤多但可逆，错了能撤回，不需要签字盖章。
反过来，涉及不可撤销动作的环节——提交、支付、对外发送——交给 AI Agent 独自完成，目前更像一种风险配置，而不是效率配置。多数团队在实践里会把这类动作放在人工确认之后，不让它自己按下那个按钮。
成本账并没有想象中便宜
另一个容易被忽略的点是试错成本。单次调用看起来便宜，但一个多步任务要跑十几次甚至几十次调用，每次都消耗时间和额度。如果中途失败还要重来，整体开销可能超过人工直接操作。
更麻烦的是排查。人会看日志，会问“你当时为什么点了这个链接”，而 Agent 的决策路径往往是一串自然语言推理，读起来像自我辩解。要让它变得可运维，就得把每一步的输入输出记录下来，这本身又是一层工程投入。
所以在评估一个 AI Agent 是否值得上，我会先问三个具体问题：任务的中间状态能不能被观察到？出错之后能不能快速定位到是哪一步？失败重来的代价是否低于人直接做？三问里有两个答不上来，通常说明还没到可以上线的时机。
边界之外，人的位置反而更清楚
有意思的是，Agent 越往前走，人的职责反而越具体：定义什么叫“完成”，划定哪些动作不可逆，以及在信息不全时做判断。这些恰恰是它不擅长的部分。
回到开头那位朋友，他最后自己打开了购票软件，两分钟订完。这不代表 Agent 没有价值，而是说明它擅长的区间还没覆盖到这个场景。把边界看清楚，比反复追问“它什么时候能完全替代人”更有用。技术落地往往不是一步跨过去，而是在一堆不够漂亮的半自动流程里慢慢往前挪。