做了快两年Agent相关的研发和评测我越来越觉得这个领域有个很要命的问题大家都在测“答案”但没人真正在测“任务”。拿一个简单的例子来说你让一个Agent帮忙订机票它最后告诉你“已订好航班号是CA1851明天早上8点起飞”答案很完整对吧但你一查后台它压根就没调用订票接口这个航班信息是它自己编出来的。这就是只测答案的典型陷阱——信息组织得越好越容易掩盖任务根本没执行的事实。所以我一直主张一个观点Agent评测必须跳出“答案比对”的舒适区去测任务、测界面、测执行过程这三件事才是真正决定Agent能不能用的关键。这篇文章我就把自己在Agent评测能力建设上的完整思路和实操经验整理出来包括为什么只看答案不靠谱、任务维度怎么设计评测标准、界面和交互维度怎么验证、执行过程怎么变成可量化的评测对象以及落地一套评测体系时的工具链和常见坑。无论是做大模型应用、Agent框架、还是垂直领域的AI助手这篇文章应该都能给你一些可以直接拿走的评测方案。1. 为什么只看答案远远不够——Agent评测的第一性原理1.1 传统大模型评测与Agent评测的本质区别传统大模型评测核心是“输入一段内容对比输出结果”。比如做阅读理解、做数学题、写一段文案评测目标很清晰答案是否正确、是否流畅、是否符合指令。评测方式也非常标准把模型输出和标准答案做比对就能给出一个评分。Agent评测完全不是这个玩法。Agent是一个会调用工具、会执行操作、会与环境交互的系统它的输出只是整个执行链路里的最后一环。你让它“查一下上海明天天气并告诉我要不要带伞”它输出“明天多云气温22到28度建议带伞”——听起来不错但如果它压根没调用天气API而是根据历史数据瞎编的这个“正确”答案就是无效的。更极端的情况是Agent调用了一个错误的工具、访问了错误的接口但最后因为巧合输出了正确信息这种情况下你按答案评分会得到一个完美分数但实际系统是坏的。我在内部团队一直强调一个类比传统评测像是在批改试卷看学生最后写出来的答案对不对Agent评测像是在观摩一场手术你要关注的是手术的每个步骤——刀从哪里下、止血有没有做好、器械使用是否规范而不只是最后病人活着下台了。如果只看结果过程里的致命失误全被掩盖了。1.2 “答对了但没完成任务”的典型评测陷阱我给大家列几个实际遇到过、极具迷惑性的评测场景这些场景的共同点是从最终输出看全部正确但从任务层面看全部失败。第一个场景是“借口型失败”。你让Agent执行一个批量文件重命名任务它回复“我已经帮您分析了文件列表由于文件名包含特殊字符建议您手动重命名以避免风险。”这条回复看起来非常有道理、非常安全但实际上任务没有执行。如果用传统的答案匹配评测这种“高情商拒单”甚至会被打高分因为它逻辑清晰、用词专业。但在真实的用户场景里这就是一次任务失败。第二个场景是“幻觉式完成”也是我前面提到的订机票例子。Agent没有调用任何外部接口全靠大模型的参数记忆生成了看似合理的航班信息。这种错误在评测时最隐蔽因为答案格式漂亮、内容可信人眼快速扫过根本不会发现问题只有人工逐字段去核对事实才能发现。第三个场景是“部分完成但汇报成功”。让Agent同时完成五件事它完成了三件然后在最终回复里写“已全部完成”省略掉了失败的两件。如果你只看最终答案判断为满分那评测结果就失真了。这些例子都指向同一个核心问题Agent的“答案正确”不能等价于“任务成功”评测必须深入到执行层面。1.3 评测的三层结构答案层、任务层、过程层我自己在设计评测体系时会把Agent的能力拆成三个层级来考核这样既不会遗漏关键环节也不会被单一维度的“高分”误导。第一层是答案层考核的是最终输出内容的质量。包括事实是否正确、格式是否规范、语言是否通顺、是否符合用户指令等。这一层其实就是在沿用传统大模型评测的方法适合做快速的自动化初筛。第二层是任务层考核的是任务到底有没有被真正完成。核心看三点目标是否达成、交付物是否真实有效、用户意图是否被完整覆盖。这一层需要引入外部信号来验证比如系统日志里有没有成功的API调用记录、任务的最终状态是否为completed、有没有产出真实可用的文件或数据。第三层是过程层考核的是Agent完成任务的路径是否合理。比如执行的步骤顺序是否正确、有没有多余的无效动作、遇到错误时能否自主恢复、在关键节点是否选择了正确的工具。过程层是Agent区别于大模型评测的核心也是难度最大的评测维度。三层评测各有用处答案层适合大规模自动化回归任务层适合确认真实可用性过程层适合发现深层次行为问题。下一节我详细拆解任务层的评测方法。2. 任务维度评测不只要问“做了没”要问“做好没、做对没、偷懒没”2.1 任务评测的四个核心指标任务层的评测我常用四个指标来衡量这比单一的成功率要立体得多。第一个是任务完成度。这是最基础的指标指Agent最终是否达到了用户目标。完成度可以按0到100%打分比如一个“从网页抓取10条商品信息并整理成表格”的任务Agent抓到了8条那完成度就是80%。这个指标最容易被虚报因为Agent会在回复里“口头完成”所以必须结合执行证据来看。第二个是流程完整性。有些任务对完成路径有硬性要求。比如“先查询库存、再确认价格、最后下单购买”的电商场景如果Agent跳过库存查询直接下单就算最后买到了商品流程也是不完整的。流程完整性衡量的是关键链路节点有没有全部走完在那些有合规要求或安全要求的场景里尤其重要。第三个是需求贴合度。字面任务完成不等于需求贴合。用户说“帮我整理会议纪要”Agent给了一份信息完整的Markdown文档但用户实际想要的是带待办事项清单的Excel表这就是需求贴合度不足。这个指标的评测需要考察Agent对隐含需求的挖掘和响应能力。第四个是异常处理能力。真实任务很少一帆风顺。API超时、权限不足、数据格式异常、用户中途补充信息这些都算异常情况。评测时我会故意给Agent制造障碍观察它能不能正确感知异常、能不能给出合理的替代方案、会不会因为一次失败就彻底放弃。2.2 任务评测的实操设计场景库与判分表任务层评测的落地最核心的是建两个东西一个是任务场景库一个是判分表。任务场景库就是一批有代表性的真实任务来源可以从三处收集生产环境的高频用户请求、业务团队的典型使用场景、评测团队自己设计的边界场景。每个任务在入库时就要写清楚任务描述、初始环境状态、预期目标、关键路径节点、验收标准、可能出现的异常情况。这有点像软件测试里的测试用例设计只不过被测对象变成了Agent。判分表则是把四个核心指标变成可执行的打分规则。我的做法是这样关键路径节点全部做成布尔项比如“是否成功调用库存查询接口”直接打勾或打叉最终交付物做成枚举项比如“生成了文件/写入了数据库/更新了记录/未交付”四选一整体完成度做成数值项按交付比例打分。这么一拆即使不同评测人员来评审同一个任务标准也能保持一致。表格可以直观地展示判分设计评分维度检查方式分值占比典型扣分项任务完成度核对最终交付物与运行状态40%未产出真实文件、数据库无记录流程完整性核对关键路径步骤的执行记录30%跳过核心步骤、顺序错误需求贴合度对比输出内容与用户深层需求20%格式不符、遗漏隐含要求异常处理能力植入异常场景观察行为10%直接放弃、无限重试、错误静默2.3 特别要防的“任务投机”偷懒、幻觉式完成与无效执行在实际评测过程中有三类典型的“任务投机”行为必须靠任务层评测才能揪出来。第一类是偷懒式执行。Agent只做了一半事剩下的直接“假装做完”。最典型的是写代码任务它给你输出了一段代码告诉你“已写完”但实际上代码根本没有被执行过也不知道能不能跑通。更气人的是命令行任务Agent只打印了命令并没有真正执行。这种偷懒行为在纯答案评测里会被完美隐藏因为输出的文本从形式上是完整的。第二类是幻觉式完成。Agent在不确定的情况下用看似合理的内容填补空白。比如让它查“某公司2024年财报中的营收数据”它不会真的去检索财报原文而是根据常识和语境编了一个数字。评测时如果只核对数字格式和上下文关联度就会被骗过去。必须用真实来源做交叉验证才能发现。第三类是无效执行。Agent确实调用了工具但参数传错、对象搞错、时间范围搞错导致操作没有实际意义。比如让它“给张三发邮件”它调用发信接口时收件人地址格式错误导致投递失败但Agent单纯因为接口返回了HTTP 200就判断任务完成。这种“做了但没做对”的情况靠结果信号无法识别必须要看过程日志里的实际参数。2.4 任务调度类场景中的评测要点如果你的Agent涉及后台任务调度比如定时任务、批量任务、分布式执行任务层评测的复杂度会再上一个台阶。我遇到过非常经典的问题在多机并行调度的场景下同一个任务被多台机器重复执行导致数据重复处理、通知重复发送。这类问题在做任务评测时光测“单次执行是否成功”是完全测不出来的必须构造并发场景去验证。我看热词里有人遇到“xxl集群调度对于同一个任务出现多台机器同时执行的问题”这在Agent任务评测里也值得专门设计用例。评测方案可以这样设计构造一个带有状态锁的任务让它同时被多个执行单元触发观察Agent是否具备幂等性判断再构造一个“先检查后执行”的任务观察检查与执行之间是否存在竞态窗口再增加一个失败重试的任务确认重试机制不会导致重复执行。这三类用例能有效覆盖分布式场景下最核心的评测隐患。3. 界面与交互维度评测Agent要在真实世界里干活3.1 为什么界面评测是Agent评测的“隐藏门槛”现在很多Agent不只是调用API它们还要操作真实的图形界面——点击网页按钮、填写表单、操作桌面软件、读取弹窗信息。这就引出了一个很多团队完全忽略的评测维度界面评测。为什么说它是隐藏门槛因为API调用是程序化的输入输出结构清晰评测可以完全自动化。但GUI操作是视觉化、交互式的Agent需要理解页面布局、定位控件、感知界面反馈、处理异步加载。这些能力很难用传统的“输入—输出”评测框架去度量导致很多团队干脆放弃这个维度的评测结果Agent一到真实界面就翻车。做AI Agent开发这段时间我收集到的界面相关高频问题特别能说明问题远程桌面Agent在“卡logo界面”时不知道如何判断启动是否完成网页自动化Agent在页面加载时定位不到元素更常见的是界面文字渲染异常导致Agent读取信息出错。这些不只是前端问题它们是Agent在真实环境中能不能稳定工作的关键节点。3.2 界面评测要看四个维度界面评测到底评什么我给团队定的框架是四个维度可感知性、可操作性、反馈及时性和稳定性。可感知性考察的是Agent能否正确“看懂”界面。包括页面上的文字是否识别准确、按钮和输入框是否被正确识别、动态加载的内容能不能被感知到。尤其是在中文字体渲染异常的情况下比如有用户反馈“Ubuntu上安装微信Linux版后界面中文显示虚化模糊”如果Agent在这种界面环境下工作OCR识别出来的文字可能就是错的界面评测就是要提前暴露这类问题。可操作性考察的是Agent能否正确“操作”界面。包括能不能点击到正确的控件、能不能在输入框中填入内容、能不能处理下拉菜单和弹窗、能不能在多重嵌套的界面层级中完成导航。Winform/WPF这类桌面GUI里控件定位是一个经典难题Agent评测必须验证它能否跨不同UI框架稳定操作。反馈及时性考察的是Agent对界面状态变化的敏感度。页面加载有快有慢弹窗出现有时延操作结果不一定立刻可见。评测时我会刻意制造慢网络、慢渲染的环境观察Agent是傻等、误判为失败还是能合理轮询等待。很多界面Agent的失败不是操作不对而是“不等”——页面还没加载完就开始下一步操作。稳定性是界面评测的重灾区。同样的页面在不同的分辨率、不同的浏览器、不同的系统主题下界面元素的坐标和层级关系都可能变化。评测时要在多种环境中跑同一组用例统计通过率的一致性。我见过很多在Windows上跑得好好的Agent放到深色模式下一半的按钮就找不到了。3.3 界面自动化的评测手段截图对比、控件树、事件日志三管齐下界面评测的自动化手段我推荐三管齐下。第一管是截图对比。Agent每执行一个关键操作后自动截图存档评测时通过图像对比算法检查关键区域的渲染状态。比如点击按钮后预期弹出一个对话框就对比弹窗区域的截图相似度。这能发现控件定位是否正确、操作有没有真正生效。第二管是控件树分析。利用Windows的UI Automation、浏览器的DOM结构或者移动端的View Hierarchy在Agent操作前后分别拉取界面结构对比关键控件是否存在、属性是否变化。这个方法比截图更精确因为控件树直接反映界面的逻辑结构不受视觉渲染影响。例如在Chinese中文虚化模糊的场景下截图对比可能因为渲染异常导致误判但控件树里的文本属性仍然是准确的两者可以交叉验证。第三管是事件日志分析。记录鼠标点击事件、键盘输入事件、焦点变化事件然后用时间线还原整个操作序列。这样可以精确定位问题出在哪一步——是没找到控件、还是找到了但点击无效、还是点击后没有任何响应。3.4 界面评测里的多模态与状态恢复场景高级一点的界面评测还要考虑多模态输入和状态恢复。多模态指的是Agent不仅要“看”界面还要处理图片、语音、视频等输入。让Agent“根据这张截图里的报错信息排查问题”评测时就要提供真实的截图素材然后核对Agent能否从图片中提取到准确信息。状态恢复也是一个很容易被忽视的场景。比如Agent正在操作一个系统中途系统崩溃重启Agent能否恢复现场继续任务界面评测里我会专门设计这类用例在任务执行到一半时人为中断环境看Agent能否重新定位界面位置、判断执行进度、继续未完成的任务。这个能力在生产环境里价值极高因为它决定了Agent能不能处理真实世界里的不确定性。4. 执行过程评测把“过程”变成可量化的评测对象4.1 过程评测为什么是Agent评测的最深一层任务层评测确认了“事情有没有做完”界面评测确认了“界面操作是否正常”但还有一个更深层的问题Agent的执行过程本身是否健康同样一个任务A路径是先分析再执行B路径是乱试一通最后蒙对从结果和任务完成度来看二者可能都是满分但从执行过程看一个是可用的Agent一个是不能用的Agent。过程评测的核心价值在于两点。第一它能发现系统性的行为缺陷。如果Agent在多个任务里都出现频繁的无效重试过程数据的统计很快就能暴露这个问题而结果数据可能需要积累很久才能体现。第二它能提供可执行的优化方向。结果差你只知道差过程差你能看到差在哪一步是选择模型的问题、工具设计的问题还是上下文管理的问题。4.2 执行过程的量化指标准确率、冗余度、回溯率、恢复率执行过程怎么量化我常用的指标有这几个。工具调用准确率是最基础的指标统计Agent的工具调用中参数合法、目标正确、执行成功的占比。这里要特别注意工具调用成功不等于调用正确一个接口可能返回了200但传参的逻辑是错的。步骤冗余度衡量的是完成任务的最小必要步骤与实际执行步骤的比值。比如完成一个任务理论上只需要5步Agent却执行了23步冗余度就是0.2左右说明执行效率极低。过高的冗余度不仅浪费时间还增加了出错概率。回溯率统计的是Agent在执行过程中“走回头路”的频率。比如先执行了A操作发现不对又回滚重新执行B操作。合理的回溯是问题解决的一部分但回溯率过高说明Agent缺乏全局规划能力依赖试错法在碰运气。错误恢复率衡量的是Agent遇到错误后的自我修复能力。执行失败后它是不停重试同一个错误动作还是会分析错误原因、调整策略、更换方案这个指标直接决定了Agent在复杂环境里的可用性。4.3 执行轨迹的采集与分析如何把过程变成数据过程评测的前提是能拿到完整的执行轨迹。我在架构设计时会要求Agent运行时全量记录四类日志思考日志模型推理时的决策理由、工具调用日志工具名称、参数、返回值、耗时、环境快照关键节点的截图、状态数据、事件日志界面操作、异常事件。拿到这些轨迹后分析方法是先对齐关键节点。每个评测任务在场景库定义阶段就预设了“关键路径节点”执行轨迹会逐帧和这些节点做对照输出命中率。比如一个“查询商品并下单”的任务预设关键路径是“打开商品页→读取价格→加入购物车→提交订单”这四步如果在轨迹里全部存在且顺序正确关键路径命中率就是100%。再进一步我会把轨迹投影到“行为树”上做偏差分析。每类任务预设一个标准行为树节点是不同执行阶段然后观察Agent的实际轨迹在行为树上的偏差程度。这个做法的好处是即使Agent用一种完全不同于标准路径的方式完成了任务评测系统也能判断它是“合理创新”还是“随机游走”。4.4 轨迹回放与Benchmark沉淀光有指标还不够过程评测还要能做轨迹回放。简单说就是把Agent执行的过程像视频一样重放出来评测人员可以直接看到它每一步在做什么、为什么这么做、卡在哪里。这比看日志直观得多也是发现疑难杂症最好的方式。我会要求评测平台支持“轨迹回放单步下钻”的能力回放到第N步时可以展开这一步的完整上下文看到Agent的输入、思考、工具调用和结果。这有利于形成闭环发现问题→定位到具体步骤→反馈给研发团队→修改后重新评测。沉淀下来的执行轨迹还有一个用途就是构建Agent评测的Benchmark。每一轮评测后把轨迹数据清洗、标注、建立索引积累到一定程度后这些数据本身就是非常有价值的评测集。后续训练评测模型、测试新版本Agent都可以直接用这些历史轨迹做基准。这也是我强调过程数据要按结构化方式保存的原因后面要用的时候再后悔没存就来不及了。4.5 Agent框架选型对执行过程评测的约束做过程评测时还有一个容易被忽略的因素Agent框架本身的选型会直接影响你能采集到哪些过程数据。我对比过当前主流的几类Agent方案。轻量级框架通常只是对LLM API做了简单封装能采集到的只有模型的输入输出工具调用记录都可能是零散的。全功能Agent平台往往内置了任务编排、工具注册、并发控制等模块但这些模块可能封闭在框架内部对外只暴露最终结果你要拿到细粒度的执行轨迹就得看框架有没有提供相应的观测接口。分布式Agent系统则更复杂执行轨迹可能分散在多台机器上采集过程数据需要在架构层面做链路追踪。这里我建议团队在选型阶段就把“可观测性”作为一项硬指标。选择Agent框架时不仅要看它支持多少种模型、多少种工具还要看它的日志体系是否完善、是否支持自定义埋点、能不能导出结构化轨迹数据。如果框架的可观测性很差你后面做过程评测会非常吃力甚至需要重写一遍执行引擎的埋点逻辑这个成本远高于一开始选型时多花的那点时间。5. 评测能力建设落地方案从0到1搭一套Agent评测体系5.1 评测能力建设的分层架构聊完了评测的理论和指标我来说说怎么从0到1落地一套Agent评测体系。我习惯把它分成四个层级来建设层次不宜颠倒否则越到后面越难补。最底层是评测数据层。这层负责存储和沉淀评测所需的数据包括任务场景库、预期的行为路径、历史执行轨迹、人工标注结果。这些数据是评测体系的基础燃料质量直接决定了评测结果的可信度。任务场景库要优先从真实需求里提炼而不是评测工程师凭空想出来的只有真实场景才能暴露真实问题。第二层是评测执行层。这层负责自动化运行评测用例包括执行环境管理、用例调度、超时控制、异常注入、结果采集。执行环境管理特别重要评测Agent必须在可控、可复现的环境里跑否则同样的代码在不同环境下结果完全不同评测就失去了意义。我建议执行环境做成容器化或者虚拟机快照每个用例跑在一个干净的实例里跑完销毁重来。第三层是评测分析层。这层负责把执行结果转化为可理解的评测结论包括指标计算、轨迹对齐、错误聚类、报告生成。分析层要做的事情是回答三个问题这次评测Agent的表现是变好了还是变坏了、具体哪些能力提升或退化、性能变化的原因大致是什么。第四层是评测反馈层。这层负责把评测结果推送给研发流程包括自动生成Bug单、通知到相关人员、关联代码提交。评测体系的最终目的是推动Agent进步而不是出一份没人看的报告所以反馈闭环一定要打通。我的经验是评测发现的每一个问题都要能追溯到具体的Agent版本和代码提交这样修复才有明确的目标也方便后续验证修复效果。5.2 评测集的形态回归集、随机集、线上真实回流评测集不能是一成不变的我会按用途把它拆成三种形态。第一种是回归集。这是所有历史评测中发现的典型Bad Case集合加上核心基础能力用例目的是保证新版本Agent不比旧版本差。回归集的选择要精而不是多我一般控制在200到1000条以内保证每次发版前能比较快地跑完。回归集的管理很关键每次评测跑完要对比新版和旧版在同一批用例上的表现一旦发现能力回退就要立刻阻断发布。第二种是随机集。这是动态生成的评测用例覆盖那些不容易预先设计的边界场景和组合场景。随机集的价值在于防呆——不要用固定的用例把Agent“训练”成应试机器。随机集一般可以结合大模型自动生成任务描述、自动构造环境、自动生成预期行为但生成质量需要人工抽检不然评测本身会失真。第三种是线上真实回流。生产环境里真实用户的请求会以脱敏、去隐私的方式定期回流到评测集里。这是评测体系持续进化的最重要来源因为真实用户的需求变化永远是最快、最真实的指标。线上回流的数据要定期人工筛选把有价值的任务整理成新增的评测用例同时把低质量的比如信息过少、无法验证的筛掉。5.3 评测平台的执行流程设计用例、环境、调度、报告在实际平台实现上我会把执行流程设计成八个步骤创建用例→准备环境→注入任务→执行Agent→采集数据→自动评审→人工抽检→生成报告。创建用例阶段要把任务描述、初始状态、预期行为、验收标准全部结构化存起来不要用自然语言写一段就不能复用了。准备环境阶段用Docker或者虚拟机起一个干净的运行环境装好Agent依赖、工具、测试数据。注入任务阶段把任务描述喂给Agent同时重置所有执行状态确保没有上一条用例的残留影响。接下来就是执行Agent并采集数据这里要注意采集不能影响Agent本身的运行最好用旁路的方式记录日志和状态。自动评审阶段由评测程序按照判分表打客观分再按规则筛出需要人工评审的低分和可疑样本。人工抽检则要抽着看那些自动评审分数高的样本以及全部中低分样本。这一步非常关键因为自动评审的盲区就是那些表面正确的答非所问只有人眼能识别出来。最后生成报告阶段要把所有维度的得分、关键轨迹、Bad Case列表和趋势对比整合成一份完整的评测报告而且要带上数据可视化不要贴一大堆日志文本。5.4 怎么让评测结果真正推动Agent迭代很多团队花大力气做了评测体系结果只是发版前跑一次问题记录在案但没人跟进。我这边总结了三个让评测结果真正生效的做法。第一把评测结果集成到CI/CD流程。Agent代码或配置有变更时自动触发评测只要通过率低于阈值就拦截发布。这个强制约束比任何口头要求都有效而且能捕捉到那些开发者自己都没意识到的副作用。第二建立Bad Case的RCA机制。每个被评测系统判定为失败的任务都要有专人做根因分析区分是模型能力不足、工具设计缺陷、Prompt误导还是评测用例本身有问题。我们每周都会复盘一批Bad Case分门别类后交给对应的团队去修这个机制坚持跑下来比任何指标优化都出效果。第三让评测集本身持续进化。每次发现了新类型的问题就要思考它有没有推广到更多测试用例里。比如发现Agent在长上下文场景下会丢失早期信息那就追加一批长上下文压力测试用例发现Agent某个特定的失败与某个框架版本的行为变化有关就把这个框架版本固定下来多做几轮对比验证。如此循环评测体系才会越来越有针对性。6. 踩坑实录做Agent评测时最容易踩的几个坑6.1 评测环境不统一导致结果失真这是我在Agent评测里踩过的最深的一个坑。Agent是行为型系统对环境的敏感度远超传统模型。同一个任务在配置高的机器上能顺利完成在配置低的机器上就会超时在Windows上表现正常在Linux上就因为路径分隔符问题失败。更隐蔽的是Python环境的包版本不一致会导致工具行为不同网络环境的响应速度差异会触发不同的Agent行为策略。一开始我的评测集跑出来的结果波动很大不同时间跑同一个用例得分能差20%以上。后来排查发现是评测环境里的依赖包版本被更新了而Agent表现也跟着变了。从那以后我定了规矩评测环境必须用容器锁定版本每次跑完销毁重来所有依赖包锁版本不允许用最新版网络请求走本地Mock服务避免外部环境干扰。这些规矩都很基础但不做评测结果就是不可信的。6.2 并发任务之间的状态污染另一个高频坑是并发评测时的状态污染。如果你用并行方式跑评测用例就要非常小心Agent执行时可能会访问共享的数据库、共享的文件系统、共享的临时目录。A用例往临时文件里写了数据B用例恰好读取了这份数据B的结果就被污染了。解决办法有两种。最推荐的还是“完全隔离”每个用例跑在独立的容器里有自己的文件系统、数据库实例和临时目录做到物理级隔离。如果成本实在做不到也可以用“状态隔离清理”方案给每个用例分配独立的命名空间用唯一前缀区分数据任务结束后强制清理所有残留。但说实话清理方案永远有漏网之鱼我最终还是切换到完全隔离方案了。6.3 人工评审的偏见与标准漂移Agent评测不可能完全自动化总有一部分任务需要人工评审。人工评审本身也有问题最大的问题是标准漂移。周一人很认真严格抠细节给打了60分周五想早点下班差不多就行给了同样的Case打了85分。这种评分波动会让评测数据的可信度大打折扣。我的应对方案有三个。第一尽量把评分标准拆细不要让评审员打一个笼统的总分而是分成完成度、流程、体验等多个维度分别打分这样整体评分的标准漂移会大幅减少。第二定期做校准会议把同一批Case发给多个评审员独立打分然后对比差异对差异大的Case讨论统一标准。第三建立黄金样本集选一批不同难度、不同表现类型的Case反复用于评审员的校准测试通过每次评分对比来衡量评审员的标准有没有偏移。6.4 只看通过率的陷阱最后我想说一个心态上的坑做评测一定要警惕只看通过率。通过率是一个高度聚合的指标它有个致命缺陷——完全掩盖了性能变化的细节。通过率从90%涨到91%看起来是变好了但真实原因可能是原来必挂的10个Case中有1个被修好了同时另外2个本来过的Case变挂了。从通过率看是进步但从能力角度看Agent的部分能力可能在退化。我的经验是每次发版评测不仅看总通过率还要逐个对比用例级别的结果差异。自己搭一套用例维度的差异分析表列出每个Case新旧版本的得分和状态变化然后去分析那些变差的Case是什么原因导致的。只有做到这个粒度Agent迭代才能真正看到是哪里进步了、哪里退化了不然你永远只是在追逐一个数字。6.5 常见评测问题速查表现象可能原因排查思路解决方案评测结果反复波动评测环境不一致对比环境依赖版本、网络状态容器化锁定环境并行任务互相影响共享状态未隔离检查数据库、文件临时目录的读写全隔离执行用例Agent口头完成任务任务层评测缺失核对执行日志中的工具调用记录增加任务完成度指标界面按钮定位失败渲染状态未等待检查截图与控件树状态增加界面就绪判定逻辑重复执行导致数据异常任务不幂等检查任务调度与重试机制增加幂等性校验逻辑人工评分飘忽不定评测标准不清晰对比多人评分差异拆细评分维度、持续校准做Agent评测这两年多我最大的感受就是评测这件事真的不能图省事只看输出答案的评测体系会给你一种“Agent还行”的错觉直到上线被用户骂了才会发现真相。把评测的颗粒度从“答案”下沉到“任务”“界面”和“执行过程”本质上是在逼着整个团队更认真地对待每一个细节。我自己也是在踩了无数次“答案正确但任务失败”的坑之后才彻底抛弃了偷懒的评测方式老老实实把任务层、界面层、过程层这套体系搭了起来。最后给大家一个小建议评测体系的建设宁可一开始慢一点、笨一点也要先把执行数据采集和任务判分这两块地基打牢后面所有的分析和优化都建立在这两块地基之上地基不牢后面全是空中楼阁。