AI Agent 为什么试了上不了生产：卡点在哪

AI Agent 的演示很容易做得漂亮：给一个目标，它自己拆步骤、调工具、把结果交回来。难的是第二周，换一批输入，它开始漏步骤、重复调用、把失败当成功。上不了生产的卡点几乎都不在模型会不会想，而在几件工程上的事：误差怎么累积、权限怎么收、失败怎么重试、效果怎么量化。

演示只跑一次，生产要跑一万次

演示挑的是一条顺利的输入，生产面对的是分布。同一句需求，有人写全，有人只写三个字，有人夹着错别字和截图。它在顺利路径上表现好，不代表在长尾上站得住。

能不能往下走，先建一个小评测集：从真实工单或操作记录里抽 50 条任务，覆盖常见类型和明显边界，每条写清什么算完成。这个动作花不了多少时间，却能挡住后面大部分争论——改一版提示词，跑同一套题，通过率是升是降一目了然。

误差会沿着步骤相乘

Agent 每一步的输出都是下一步的输入，错误会被当成事实继续用。单步准确率 95%，串十步就只剩六成左右，这还是每步独立、错误不放大时的乐观估计。它和工作流的差别不在有没有工具调用，而在下一步由谁决定，这个区别在工作流与 Agent 的对比里拆得更细。

能做的有三件：缩短链路，把能合并的步骤合并；在关键节点加校验，工具返回为空就停，不要继续往下编；把决定和执行分开，让模型只负责提议，真正的写操作交给确定性代码。链路长度比单步的聪明程度更影响最终结果。

权限放开之后，风险不再由模型承担

Agent 的能力等于它能调用的工具之和。给它浏览器，它就能点页面上任何一个按钮；给它数据库账号，它就能执行任何一条语句。模型不会为误操作负责，责任落在给它权限的人身上。

可落地的做法是三层：按任务发凭据，一次一用，用完即失效；读和写分开，读放开，写要求二次确认；所有调用留审计记录，能还原它看过什么、改过什么。边界怎么划，可以参考Agent 安全边界的划法，顺序是先定不许做什么，再谈能做什么。

评测集比提示词更值得先做

提示词能改的地方很多，改完却常常说不清是好是坏。评测集解决的就是这个：固定题目、固定判分口径，每次只动一个变量。

指标别只盯完成率，至少看四个：任务完成率、平均步骤数、人工接管率、单次成本。步骤数突然变多，通常意味着它在某个环节反复试错；接管率上升，说明它遇到了自己处理不了的情况。四个数一起看，才知道是变好了还是只是更啰嗦。这些数来自执行记录，前提是每一步都有痕迹，具体做法见Agent 可观测性怎么落。

有了这四个数，灰度才有依据：先影子运行，只记录不执行，拿真实流量比对它和人做的差别；再放一小部分流量，关键动作要人点确认；最后才全量，同时保留抽检。每道闸门都要写清退出条件，否则会永远停在试点。

重试和幂等要写在工具层

Agent 调工具会超时。超时之后它不知道对方到底执行了没有，重试一次就可能下一次单、发两条消息、扣两次款。这类问题在演示里不会出现，在生产里一定会出现。

解法不在提示词，在工具封装：每次调用带一个业务幂等键，服务端按键去重；写操作先查状态再执行；失败要分确定没执行和不确定两种，前者可重试，后者转人工核对。工具层不做这件事，Agent 越聪明，重复副作用越多。

四类场景的卡点对照

浏览器那一条还有个额外变量：页面会改版。视觉定位和结构定位各有软肋，思路与浏览器 Agent 怎么点页面里讲的一致，关键是失败要能立刻报错，而不是点错位置继续走。

什么情况下它必然失效

四种情况基本无解。目标没法用可验证的标准描述，比如让内容更有感染力，它只能猜；环境高频变动，今天能点的按钮明天改名；错误代价不可逆，比如对外发公告、动生产数据；需要的权限横跨多个部门，没人愿意签字。

还有一种更隐蔽的：任务本身需要人承担责任。它可以给出建议，签字的还是人。这类场景硬上，最后会退化成让人替它复核每一步，省下的时间被复核吃掉。

上生产前速查

• 有没有 50 条真实任务组成的评测集，每条写清什么算完成
• 链路能不能再短一步，关键节点有没有校验
• 凭据是否一次一用，写操作是否二次确认
• 工具是否支持幂等键，失败能否区分执行与未执行
• 灰度顺序：影子运行、小流量确认、全量抽检

三个会被追问的问题

问：小团队没有资源做评测集怎么办？答：从最近二十条人工处理记录里抄，每条补一句什么算完成，一小时就能用。规模不重要，稳定才重要，同一套题反复跑才有可比性。

问：多 Agent 协作是不是更容易上生产？答：不是。Agent 之间要交接、要汇报、要处理对方失败，每多一层就多一处出错点。先把单个 Agent 跑稳，再考虑拆分。

问：模型升级后要不要重跑评测？答：要。同一套题、同一判分口径跑一遍，重点看步骤数和成本有没有变化。风格漂移往往先在步骤数上露头，不在最终答案上。