84 lines
7.6 KiB
Markdown
84 lines
7.6 KiB
Markdown
# 如何评价当前的 AI Agent 落地效果普遍不佳的问题？
|
||
|
||
我第一次被Agent坑，是在凌晨两点。
|
||
|
||
不是我自己熬夜，是PM打来电话说线上客服Agent把所有用户导流到了同一个错误页面，客诉已经爆了。我一边重启服务一边想：上周演示的时候明明一切正常，PPT里那个Agent能说会道，对话流程顺滑得像真人。
|
||
|
||
结果一上线，用户的真实表达方式跟Demo里预设的台词差了十万八千里。
|
||
|
||
这是我在大厂做AI应用开发的第六年，也是我踩过的Agent落地坑里最典型的一个。后来我跟行业里十几个做Agent的同行聊，发现大家的经历惊人地相似：Demo一片光明，上线一片狼藉。
|
||
|
||
今天不聊那些云里雾里的技术架构，聊点真实的——**为什么你公司的Agent项目，上线前和上线后是两码事。**
|
||
|
||
---
|
||
|
||
先说一个反常识的结论：Agent落地效果差，**八成不是模型不够聪明，是我们对Agent的设计思路本身就跑偏了。**
|
||
|
||
我在公司带过三个Agent项目，最早那个，我们调了个当时最强的模型，Prompt写了二十多版，Demo给领导看的时候效果很好。后来真正接进来业务流程，第一周就崩了——不是Agent能力不行，是它太”能”了，自己发明了一套执行路径，我们的业务流程根本兜不住它。
|
||
|
||
说白了，我们设计Agent的时候，默认它会”听话”。但真实场景里，大模型有个本质特性：**它会尽一切努力完成你给的目标，只要目标稍微模糊一点，它就自己补全。** 补全的方向未必是你想要的。
|
||
|
||
这就是第一个坑：**目标定义与业务场景的颗粒度不匹配。**
|
||
|
||
做Agent的人普遍有个习惯，喜欢把场景定义得很宽。”做一个能处理售后问题的Agent”，听起来很美好，但”售后问题”在真实业务里可能是退货、换货、维修、投诉、赔偿、催物流等二十多种情况，每种的流程、数据源、处理方式完全不一样。你给Agent一个宽泛的目标，它要么频繁调用错误工具，要么在多个目标之间反复横跳。
|
||
|
||
真正跑得稳的Agent，场景都卡得很死。我在内部推行过一个做法：**先把一个高频低复杂的场景做到90分，再扩场景。** 比如”查询物流状态”这个场景，用户问法稳定，输出格式固定，后端接口明确，做扎实了之后再叠加”退换货指引”。这个方法听起来慢，其实是最快的——因为任何一个场景做到60分就急着扩，积累的全是技术债。
|
||
|
||
---
|
||
|
||
第二个坑更隐蔽：**我们以为在训练Agent，实际上只在调Prompt。**
|
||
|
||
Prompt调优是每个Agent项目的入门动作，但很多人做完了Prompt优化就以为”模型已经适配好了”。其实大模型从娘胎里带来的推理方式，是基于概率预测下一个token，而不是基于业务逻辑做决策。
|
||
|
||
这两种方式的差别在哪里？你给模型说”如果用户说想退货，就查订单状态”，模型可能会把”我看看能不能申请一下退货”当成”想退货”，因为它们的语言概率接近。但业务逻辑要求的是精确匹配意图，而不是语义近似。
|
||
|
||
我在项目里踩过一个特别有代表性的坑：客服Agent需要识别用户是否”确认退货运单”，我们写了Prompt说”当用户明确表示同意寄回商品时，记录为确认”。结果线上有个用户说”好的那我就寄回去啦谢谢”，Agent判断为”确认”，但用户只是在礼貌回应，根本没填退货单。后端系统等了一天没收到物流信息，才发现这个case。
|
||
|
||
问题的根源不是Prompt写得不精准，而是**Agent缺乏对”业务状态”的理解能力**。它不知道在”确认退货”和”用户说谢谢”之间，还有一个必须执行的”填写退货单”动作。
|
||
|
||
解决这个问题的办法，是在Agent的外层加一层**状态机**。让Agent的每一步操作都对应一个明确的业务状态，而不是让它自己判断”现在该干什么”。这种架构在学术上叫”Agentic Workflow”，听起来高大上，其实就是在Agent外面套个规则引擎，让它的行为边界清晰可见。
|
||
|
||
---
|
||
|
||
第三个坑，也是我认为Agent落地最核心的问题：**缺乏对错误的感知和修正机制。**
|
||
|
||
人做错了事会停下来想一想哪里不对，然后调整行为。但大多数Agent没有这个能力——它在一条错误的路上走到黑，直到撞墙才停。
|
||
|
||
具体表现是什么？我见过最夸张的一个case，Agent调用客服知识库搜索答案，搜出来的内容有误，它直接把错误信息当成正确答案返回给了用户。更离谱的是，这个回答让用户去申请一个根本不存在的优惠政策，用户操作了三天才发现Agent说的是错的。
|
||
|
||
事后复盘，我们发现Agent在返回答案之前，没有任何校验环节。它默认”搜索到的内容 = 正确内容”，但这两者之间差了十万八千里。
|
||
|
||
后来我们加了一套”Agentic Critic”机制：Agent每生成一个回答，都要过一遍校验层——这个回答里的关键事实，跟业务系统里的数据能不能对上？有没有明显的逻辑漏洞？有没有可能让用户产生误解的表述？这套机制让Agent的响应时间增加了30%，但错误率降了70%。
|
||
|
||
**慢一点，但别出错。这是在C端场景里Agent能活下去的基本前提。**
|
||
|
||
---
|
||
|
||
说完了三个坑，再聊一个更根本的问题：为什么我们明知这些坑存在，还是会踩进去？
|
||
|
||
因为行业的节奏太快了。
|
||
|
||
2023年大家追Agent概念，2024年大家追Agent落地，今年大家已经开始焦虑Agent的商业化了。每一步都在赶，每一步都来不及想清楚。但Agent恰恰是一个**需要花时间打磨”确定性”的工程**，它不像推荐算法那样可以靠数据量弥补，它的核心能力边界必须靠人工设计来划定。
|
||
|
||
我见过很多公司投入几十个人月做Agent，上线之后发现效果不及预期，然后降级成规则引擎。也有公司直接买第三方Agent能力，发现接进来之后和自己的业务流程完全不兼容，绕来绕去还是回到原点。
|
||
|
||
这背后有一个行业共识正在形成：**Agent不是万能药，它本质上是一种”在确定性场景里替代人工”的工具。** 你让它做客服对话，它能做；你让它做24小时无人直播，它能做；你让它做跨系统的自动化运维，它也能做。但如果你给它一个模糊的目标，说”帮我提升用户体验”，它会给你一个让你后悔的答案。
|
||
|
||
---
|
||
|
||
回到开头那个凌晨两点的电话。最后那个线上事故，我们花了四个小时才把客诉全部处理完。第二天复盘的时候，老板问了一个问题：这套Agent我们还要不要继续投入？
|
||
|
||
我想了想，说：继续，但先收窄场景。
|
||
|
||
半年之后，那个客服Agent只保留了”物流查询”和”退换货政策查询”两个场景，每天的对话量反而比之前全量上线的时候高了40%，客诉率降到了原来的十分之一。
|
||
|
||
不是Agent不行，是我们一开始就想让它做太多。
|
||
|
||
**一个Agent能做的事，决定了它的上限；一个Agent不该做的事，决定了它的下限。** 把下限守住了，上限才有意义。
|
||
|
||
---
|
||
|
||
如果你也在推进Agent项目，有一个最小可行方案可以先试：**找一个日均上百次、月均问题分布稳定的场景，用状态机+校验层的架构，先做到错误率低于1%再扩。** 别一上来就想做一个”能回答用户所有问题”的Agent，那个目标听起来很美，但它会让你在凌晨两点接到电话。
|
||
|
||
你说，你们公司的Agent现在卡在哪个环节了？
|