devgo.cn你在演示时看着那个智能体（Agent，能自主理解问题、调用工具、完成任务的程序）流畅地跟用户对话、推荐产品、发短信链接，感觉很酷。但真要把它放进生产环境，第一个被老板问住的问题往往是：“你怎么证明它足够可靠？”这不是拍脑袋的顾虑——在这场面向工程实践的分享里，讲者（哥伦比亚大学教授、Arklex AI 联合创始人）直接抛出了一个扎心的数据：**目前95%的Agent都停在Demo阶段**，它们能演，但很难真正变成改变业务流程的“生产力”。
为什么？他用两个例子讲清楚了这条“从demo到生产”的鸿沟。
第一个是电商场景里的对话式Agent。像Walmart的Sparky（那个黄色笑脸）和Amazon的Rufus，已经在生产环境跑了超过一年。这类Agent不是简单的“文字进文字出”，它们能做多轮问答、理解上下文、调用库存和推荐工具，甚至能把结果渲染成产品卡片。比如用户问“这个吸尘器多大”，Agent不仅给答案，还能基于上下文（这是吸尘器）继续推荐配件、展示商品卡。这背后本质是把传统客服的销售话术，变成可编程的交互流。你说“推荐一下”，它就能从数据库拉实时库存并给出报价——这已经超越了聊天机器人，是真正的“任务型”交互。
第二个例子更花哨：语音Agent。他放了一段模拟客服给用户办信用卡的对话演示：用户说“我经常用Uber Eats点外卖、Amazon购物、偶尔订旅行”，Agent立刻推荐“Emerald Preferred Card”，并精准报出积分规则（Uber Eats 3倍积分、旅行5倍积分、$50酒店额度、$750欢迎奖励），还能在用户同意后发短信申请链接，甚至一周后再主动通知“卡已批准”，提醒旅行积分用法。这个交互有语音、有文本、有工具调用（发链接）、有数据库操作（开卡状态），每一步都像真人客服。但注意：这只是一个Demo，没有真正上线。
为什么这么丝滑的东西不上线？讲者点出了核心瓶颈：**合规**。尤其在金融、医疗这类强监管行业。传统流程里开信用卡要用户亲手点击授权链接，这是硬性监管要求；Demo里Agent“代劳”了，就需要证明它每一步都符合规则，还得处理个性化数据。另一个更基础的问题是——你怎么评估它？
这就引出了这篇分享的真正主角：**Agent测试与评估**。传统机器学习评估是怎么做的？拿问答任务举例，你攒一个有标准答案的静态基准（比如“我的余额是多少？”对应一条SQL查询），跑一遍模型，报个准确率95%就完事了。但Agent是**多轮、动态、带工具调用**的，用户可能会问“如果我买这个然后退掉，运费怎么算？”，也可能中途改主意。单轮静态基准根本测不出真实行为——它测的是“答得对”，而不是“做得对”。更糟糕的是，每次Agent调用工具都会改变系统状态（比如发了短信、改了数据库），这种副作用很难在离线基准里复刻。
讲者提到了“仿真驱动”的思路（他在实验室和创业公司主攻的方向）：用模拟环境去测试Agent，让它在接近真实的用户交互流里跑，然后自动评判产出。但这只是他给出的方向，具体方法在原有内容里没展开——但这反而点醒了一个关键：**评估不是事后补的，它和Agent本体一样需要工程化设计**。
对开发者来说，这分享最直接的启发有两点。第一，如果你的Agent要落地，别只看“能答对几道题”，要设计**多轮场景、带工具副作用、含异常处理**的测试用例，最好能自动生成和回归。第二，合规不是法务部门的事，评估体系本身就是合规的一部分——你拿不出可靠的评估报告，就永远过不了上线审批。想想那些还在纸面表格里的业务流程（比如纸质信用卡申请单），Agent自动化节省的资源是实打实的，但前提是你把评估做到位。
这分享也提醒我们一个容易忽略的现实：Demo很炫，是因为它只演示“顺利路径”；生产环境里却充满了用户中途改主意、工具超时、合规拦截这些支线。你的Agent在Demo里是主角，在生产里是流程里的一环——把它从主角变成靠谱的螺丝钉，中间那条路，就叫自动化测试与评估。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/presentations/ai-agent-testing-evaluation/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global