AI Agent 的门槛看起来被迅速拉低了。

现在做一个能演示的 Agent 并不难。给大模型一段提示词，接上搜索、浏览器、文件读写、代码执行，再用 LangGraph、AutoGen、CrewAI 之类的框架编排一下，屏幕上很快就能出现一个会规划、会调用工具、会返回结果的系统。

问题在于，能演示和能交付之间隔着很远。

Demo 对错误很宽容。它查错一个网页、漏掉一个字段、生成一段废话，演示者可以重跑。真实业务不会这么宽容。客服回复错一句可能引发投诉，财务表格算错一列可能影响决策，代码 Agent 改坏权限可能拖垮发布。Agent 一旦从聊天变成行动，错误成本就完全变了。

最核心的瓶颈，是工具调用并不等于会做事。

模型会发起 function call，只是拿到了手和脚；它还要知道什么时候查数据库，什么时候问人确认，什么时候停止，什么时候回滚。很多失败不是工具不可用，而是工具用错了：关键词查偏、参数填错、把测试环境和生产环境混淆、拿旧结果继续推理。

这也是为什么很多 Agent 原型看起来很聪明，进真实系统后反而笨得明显。它不是不会调用工具，而是不知道调用工具的边界。

状态管理也比想象中难。

一个好用的 Agent 不能只记得用户刚刚说了什么，还要记得任务已经走到哪一步，哪些条件已确认，哪些工具调用成功，哪些结果可信，哪些信息过期。长上下文不等于状态管理，记忆越多还可能越乱。真正可靠的做法往往要把关键信息结构化保存，把每一步变成可检查、可重试、可交接的状态。

这件事听起来像 AI 问题，落地时却很像传统工程问题。任务状态、幂等、事务、回滚、日志、权限、告警，这些老东西在 Agent 时代没有消失，只是被大模型推理放大了。

权限和安全是另一个分水岭。

聊天机器人最多说错话，Agent 会动文件、账号、订单、代码库和客户数据。它需要最小权限、操作前确认、敏感动作审批、日志留痕、沙箱隔离。很多产品卡住，不是模型不够聪明，而是用户根本不敢给它足够权限。

这里的关键不是把所有风险都交给一句提示词，而是把系统设计成默认保守。能读的权限和能写的权限要分开，普通操作和不可逆操作要分开，自动执行和人工确认要分开。越接近钱、账号、客户数据和生产环境，越不能让 Agent 直接裸奔。

失败恢复决定它能不能进生产。

真实世界里 API 会超时，网页会改版，表格会缺列，用户会中途插话，系统会遇到权限不足。一个成熟 Agent 不能只会从头再来，它要能判断失败类型，保留已完成部分，重试安全步骤，必要时把问题交还给人。

很多时候，Agent 不需要神一样地完成所有事。它更需要在不确定时停得住，在失败时讲得清，在恢复时不制造新的破坏。这个能力没有演示视频那么刺激，却决定产品能不能被长期使用。

评测也很棘手。

聊天质量可以人工打分，Agent 成败要看整条流程。任务有没有完成，证据是否可靠，成本是否可接受，过程中有没有越权，失败时有没有正确停下，这些都要有测试集和日志回放。没有评测，团队就只能凭感觉调 prompt。

更现实的路径，是不要一开始就做万能助手。

先选边界清楚、结果可验收、权限可控的场景，比如资料整理、测试生成、客服知识库问答、代码仓库只读分析、内部工单预处理。把工具、状态、权限、恢复和评测打牢，再往更复杂的业务动作扩展。

对开发者来说，Agent 的机会不在一句话自动搞定所有事，而在具体流程里慢慢长出来。对使用者来说，也不要被演示视频带偏，真正该问的是它能不能接进我的系统，能不能解释每一步，能不能在出错时停住。

一个好 Agent 不只是会说会想，还要像一段可靠的软件那样，经得起反复使用。