企业官网建设流程全解析

业务Agent的评测，这两年从“锦上添花”变成了“生死攸关”。我见过太多团队，模型选型时跑分漂亮得不行，一上生产环境就原形毕露——要么工具调用乱套，要么多轮对话跑着跑着就忘了自己是谁。问题出在哪？出在我们拿评测传统LLM的那套方法去评Agent，就像拿考驾照的笔试成绩去判断一个人能不能跑拉力赛。Agent的核心能力是“在动态环境里做决策并执行”，这跟“根据上下文生成一段通顺的话”完全是两码事。这篇内容我想把业务Agent评测这件事拆开聊透，从为什么难评、评什么、怎么评，到落地时踩过的坑和攒下的经验，尽量说人话、给干货。适合正在做Agent落地、被评测环节卡住的开发者和技术负责人参考，也适合刚接触Agent评测、想建立系统认知的朋友。

1. 业务Agent评测为什么不能照搬LLM那套

1.1 从“说得好”到“做得对”的范式转移

传统LLM评测的核心逻辑是比对。给一个输入，看输出和参考答案的相似度，BLEU、ROUGE、BERTScore这些指标本质上都在衡量“文本像不像”。这套方法在翻译、摘要、问答场景里很成熟，因为那些任务的正确答案相对确定，评价维度也单一。

但业务Agent不一样。一个Agent接到“帮我查一下上个月华东区销售额下滑的原因”这个任务，它可能要调用数据库查询、调取报表工具、做数据对比分析、最后生成结论。这中间每一步都有多种合理路径，最终答案也可能因为数据口径不同而有差异。你没法用一个固定的参考答案去比对，因为“正确”本身就不是唯一的。

更关键的是，Agent的失败模式跟LLM完全不同。LLM答错了，顶多是内容不对；Agent做错了，可能是调用了错误的工具、传了错误的参数、在循环里卡死、或者执行了有副作用的操作。这些问题的严重性远超“文本质量”层面。我经历过一次线上事故，Agent在退款流程里把“确认退款”和“查询退款”两个工具搞混了，直接给用户退了钱。这种错误用文本相似度根本测不出来。

所以评测Agent，首先要转变思维：从“评结果”转向“评过程+评结果”，从“单点比对”转向“轨迹分析”。

1.2 Agent评测的三个独特挑战

第一个挑战是状态空间爆炸。Agent每一步的决策都依赖当前状态，而状态又由历史动作和环境反馈共同决定。一个10步的任务，如果每步有5种可能动作，理论上的轨迹数量是5的10次方，接近一千万条。你不可能穷举所有路径，只能采样评估。

第二个挑战是环境依赖。Agent的能力高度依赖它所能访问的工具和环境。同一个Agent，接不同的API、不同的数据库，表现可能天差地别。这意味着评测环境必须尽可能还原生产环境，否则测出来的分数没有参考价值。

第三个挑战是评估标准的主观性。什么叫“好”的Agent表现？是任务完成率高？是步骤少？是成本低？还是用户体验好？不同业务场景下权重完全不同。客服Agent可能更看重准确率和合规性，而数据分析Agent可能更看重洞察深度。没有一套通用指标能覆盖所有场景。

这三个挑战决定了Agent评测必须是一套组合拳，而不是单一指标能搞定的。

1.3 一个真实的翻车案例

去年我参与过一个电商客服Agent的项目。上线前团队用了一套标准的LLM评测集，准确率92%，大家都很乐观。结果上线第一周，客诉率反而上升了。排查后发现几个典型问题：

• Agent在处理“我要退货”时，有时候会先问“您是什么原因退货”，有时候直接调用退货工具。前者体验好但效率低，后者效率高但显得机械。评测集里没有覆盖这种“交互策略”维度。
• 当用户说“算了不用了”的时候，Agent有30%的概率仍然继续执行退货流程。因为评测集里的“取消意图”样本太少，模型没学好。
• 多轮对话超过5轮后，Agent开始丢失上下文，把之前的订单号搞混。评测集里最长只有3轮对话。

这些问题在传统评测里全是盲区。后来我们重新设计了一套针对Agent的评测方案，才把这些问题逐个暴露出来。这个教训让我深刻认识到：评测集的设计质量，直接决定了你能否发现真正的问题。

2. 拆解业务Agent的评测维度：到底该测什么

2.1 任务完成度：最基础也最容易注水

任务完成度是Agent评测的底线指标，衡量的是“用户交代的事办成了没有”。听起来简单，但实际操作中很容易注水。

比如一个“帮我订明天从北京到上海的机票”的任务，怎么算完成？Agent查到航班算完成吗？还是必须走到下单页面？还是必须支付成功？不同粒度的定义会导致完全不同的完成率。

我的经验是，任务完成度必须按业务动作分层定义。以订机票为例：

这样分层的好处是，你能清楚看到Agent卡在哪一层。如果L1完成率95%但L3只有60%，说明问题出在执行环节，而不是理解环节。

另外要注意，完成度不等于成功率。有些Agent会“假装完成”——比如没查到航班就编一个航班号返回。这种情况必须通过事实验证来识别，不能只看Agent自己说“已完成”。

2.2 工具调用准确性：Agent的命门

工具调用是Agent区别于普通聊天机器人的核心能力，也是评测的重中之重。我一般从四个子维度来评：

工具选择正确率：面对一个任务，Agent是否选了正确的工具。比如用户问“今天天气怎么样”，Agent应该调天气查询工具，而不是调日历工具。这个指标低，说明Agent的意图理解或工具描述有问题。

参数填充准确率：选对了工具，参数填对了吗？比如查询天气需要城市和时间，Agent是否从对话中正确提取了这两个参数。这里常见的坑是参数格式错误，比如日期格式不匹配、城市名用了简称等。

调用顺序合理性：有些任务需要多个工具按特定顺序调用。比如“帮我退掉昨天买的那件衣服”，需要先查订单、再确认退货政策、最后执行退货。顺序错了可能导致失败或副作用。

异常处理能力：工具调用失败时Agent怎么办？是重试、换工具、还是向用户求助？这个维度最能体现Agent的鲁棒性。

我通常会用一张表来记录每次工具调用的详情：

{ "step": 3, "expected_tool": "query_order", "actual_tool": "query_order", "expected_params": {"order_id": "12345", "date": "2024-01-15"}, "actual_params": {"order_id": "12345", "date": "2024-01-14"}, "result": "success", "latency_ms": 320 }

这样逐步骤对比，能精确定位问题出在哪一环。

2.3 多轮对话中的上下文保持能力

业务Agent经常需要多轮交互才能完成任务。用户可能先说“我要退货”，然后补充“就是上周买的那双鞋”，再说“算了换成换货吧”。Agent需要在整个过程中保持对任务目标、已收集信息、用户偏好的追踪。

评测这个维度，我建议设计带干扰的多轮测试用例。比如：

• 第1轮：用户提出任务A
• 第2轮：用户补充任务A的细节
• 第3轮：用户突然问了一个无关问题
• 第4轮：用户回到任务A，并修改了某个条件
• 第5轮：用户确认执行

看Agent在第4轮时是否还记得任务A的原始信息，是否正确处理了修改。很多Agent在第3轮被干扰后就“忘了”任务A，或者在第4轮修改条件时把之前的条件也覆盖了。

这里有个实操技巧：用“信息槽”的方式追踪上下文。把任务需要的关键信息定义为槽位（如订单号、商品、时间、操作类型），每轮对话后检查槽位的填充状态。这样能量化评估上下文保持能力，而不是靠感觉。

2.4 安全性与合规性：不能等出事再补

业务Agent一旦接入生产系统，安全就是红线。评测时必须覆盖以下几类风险：

越权操作：Agent是否可能执行超出用户权限的操作。比如普通用户让Agent“查一下所有用户的订单”，Agent应该拒绝。

敏感信息泄露：Agent在回复中是否可能带出不该带出的信息，比如其他用户的手机号、内部系统地址等。

提示注入抵抗：用户是否可以通过特殊构造的输入，让Agent绕过限制执行非预期操作。这是Agent安全里最容易被忽视也最危险的一环。

副作用控制：对于有副作用的操作（如转账、删除、发送），Agent是否有二次确认机制。

我一般会准备一组“对抗性测试用例”，专门用来试探Agent的安全边界。这些用例不追求覆盖所有攻击方式，但必须覆盖业务场景下最可能出现的风险点。安全评测的通过标准应该是“零容忍”——只要有一个越权操作成功，整个Agent就不能上线。

3. 评测方法论的选型：在线、离线与混合模式

3.1 离线评测：快但容易失真

离线评测是在受控环境里跑测试集，优点是快、可重复、成本低。适合在开发迭代阶段快速验证。

但离线评测有个致命问题：测试集和真实分布的偏差。你精心设计的测试用例，可能跟用户实际会问的问题差很远。我见过一个团队，离线评测准确率90%，上线后真实准确率只有60%。原因是他们的测试集都是“标准问法”，而真实用户会说方言、打错字、用缩写、一句话里塞三个意图。

所以离线评测的定位应该是“回归测试”而非“能力评估”。它用来确保新版本没有把旧功能改坏，而不是用来判断Agent能不能上线。

离线评测的测试集设计，我建议遵循“三三制”：

• 三分之一来自真实用户日志（脱敏后）
• 三分之一来自业务专家构造的边界用例
• 三分之一来自对抗性测试用例

这样能兼顾真实性和覆盖面。

3.2 在线评测：真实但代价高

在线评测是把Agent放到真实环境里，用真实流量来评估。最直接的方式是A/B测试：一部分用户用旧版本，一部分用新版本，对比核心指标。

在线评测的指标设计很关键。不能只看任务完成率，还要看：

• 用户满意度：通过点赞/点踩、追问率、转人工率来间接衡量
• 效率指标：平均对话轮数、平均耗时、token消耗
• 业务指标：转化率、客单价、复购率等

在线评测的代价是可能影响真实用户体验。所以一般会先小流量灰度，确认没有严重问题再逐步放量。

这里有个经验：在线评测一定要设置“熔断机制”。如果某个指标（如转人工率）超过阈值，自动回滚到旧版本。别等出了大事再手动处理。

3.3 混合模式：我的推荐方案

纯离线容易失真，纯在线代价太高。我推荐的是“离线筛选+在线验证”的混合模式：

1. 开发阶段：用离线测试集快速迭代，确保基础能力达标
2. 预发布阶段：用影子模式（Shadow Mode）跑真实流量，Agent只记录不执行，对比它“会怎么做”和人工实际怎么做
3. 灰度阶段：小流量真实执行，重点监控安全和异常指标
4. 全量阶段：持续在线监控，定期用离线测试集做回归

影子模式特别有用，因为它能在不影响用户的前提下，用真实数据评估Agent的决策质量。我一般会对比Agent的决策和资深人工的决策，计算一致率。一致率超过85%才考虑进入灰度。

4. 评测工具链的搭建：从Deepeval到自研

4.1 Deepeval框架的适用场景与局限

Deepeval是这两年比较流行的LLM评测框架，它提供了一套声明式的评测接口，可以比较方便地定义测试用例和评估指标。对于简单的Agent评测场景，它能快速搭起一个可用的评测流程。

它的核心用法是这样的：

from deepeval import evaluate from deepeval.metrics import TaskCompletionMetric from deepeval.test_case import LLMTestCase test_case = LLMTestCase( input="帮我查一下订单12345的状态", actual_output="您的订单已发货，预计明天送达", expected_output="订单已发货" ) metric = TaskCompletionMetric(threshold=0.8) evaluate([test_case], [metric])

但Deepeval的局限也很明显。它主要面向“输入-输出”式的评测，对Agent的多步骤轨迹、工具调用、状态变化支持不够。你可以用它来评最终回复的质量，但很难用它来评“第3步为什么选错了工具”。

我的建议是：Deepeval适合做最终输出的质量评估，但不适合做全链路Agent评测。如果你的Agent逻辑比较简单，只有一两步工具调用，Deepeval够用。如果是复杂多步Agent，还是得自研或组合使用其他工具。

4.2 自研评测框架的核心模块

对于业务Agent，我倾向于自研一套轻量评测框架。核心模块包括：

用例管理模块：管理测试用例的增删改查，支持按标签、场景、难度筛选。用例格式建议用YAML，方便人工编辑和版本管理。

- id: case_001 scenario: 订单查询 difficulty: easy turns: - user: "帮我查一下订单12345" - user: "就是上周买的那双鞋" expected: tools_called: ["query_order"] final_contains: ["已发货", "预计"] assertions: - type: tool_sequence value: ["query_order"] - type: no_forbidden_tool value: ["refund_order", "delete_order"]

执行引擎：负责跑用例，记录每一步的输入、输出、工具调用、耗时、token消耗。执行引擎要支持并发，否则跑几百个用例要等很久。

评估器：对执行结果打分。评估器分两类：规则评估器和模型评估器。规则评估器用代码判断（如工具名是否匹配、是否包含关键词），模型评估器用LLM来判断（如回复是否合理、是否有帮助）。

报告模块：生成可视化报告，展示通过率、失败用例详情、指标趋势。报告要能按维度下钻，比如“工具调用准确率按场景分布”。

这套框架搭起来大概需要一到两周，但后续迭代会非常省力。

4.3 模型评估器（LLM-as-Judge）的使用心得

用LLM来评估LLM的输出，这两年越来越普遍。它的优势是能处理规则难以覆盖的模糊判断，比如“这个回复是否礼貌”“这个解释是否清晰”。

但LLM-as-Judge有几个坑必须注意：

位置偏见：LLM倾向于给第一个出现的选项更高分。解决方案是交换顺序评两次，取平均。

长度偏见：LLM倾向于给更长的回复更高分。解决方案是在prompt里明确“长度不是评分标准”。

自我偏好：用GPT-4评GPT-4的输出，分数会偏高。解决方案是尽量用不同家族的模型来评，或者用人工校准。

评分标准模糊：如果prompt里只说“评1-5分”，不同批次的评分可能不一致。解决方案是给出详细的评分细则（rubric），每个分数对应什么表现写清楚。

我一般会把LLM-as-Judge的评分和人工评分做相关性分析。如果相关性低于0.7，说明评估器的prompt需要优化。这个校准过程通常要迭代两三轮。

5. 评测集设计：决定评测质量的关键

5.1 从真实日志中挖掘高价值用例

评测集的质量直接决定评测的有效性。我见过太多团队随便造几十个用例就开始评，结果评了个寂寞。

好的评测集应该从真实数据中来。具体做法是：

1. 拉取过去3-6个月的真实用户对话日志（脱敏）
2. 按意图分类，统计每类意图的占比
3. 每类意图抽取代表性样本，覆盖高频和低频
4. 对样本做标注，标注内容包括：期望的工具调用、期望的关键信息、可接受的回复范围

这样得到的评测集，分布跟真实场景一致，评出来的分数才有参考价值。

有个细节要注意：真实日志里有很多“脏数据”，比如用户打错字、说半句话、中途放弃。这些恰恰是最能考验Agent鲁棒性的用例，不要过滤掉，反而要重点保留。

5.2 边界用例与对抗用例的构造方法

真实日志覆盖的是“常见情况”，但Agent的很多问题出在“不常见情况”。所以还需要人工构造边界用例和对抗用例。

边界用例的构造思路：

• 参数边界：空值、超长值、特殊字符、格式错误
• 流程边界：中途取消、重复请求、并发请求
• 状态边界：会话超时、工具不可用、数据不存在

对抗用例的构造思路：

• 意图混淆：一句话里包含多个意图，看Agent能否正确拆分
• 提示注入：在正常请求里夹带“忽略之前的指令”之类的内容
• 诱导越权：用看似合理的理由诱导Agent执行越权操作
• 信息套取：通过多轮追问套取敏感信息

这些用例不需要多，但必须精。我一般会保持边界用例和对抗用例各占评测集的15%左右。

5.3 评测集的版本管理与迭代

评测集不是一次性的，需要持续迭代。我的做法是：

• 版本化：每次修改评测集都打版本号，记录修改内容
• 冻结核心集：保留一组“核心用例”不轻易改动，用于跨版本对比
• 动态扩充：每次线上发现新问题，就把对应场景补充到评测集
• 定期清理：过时的用例（如业务已下线）及时移除

核心集和动态集的比例大概是7:3。核心集保证可比性，动态集保证时效性。

另外，评测集要跟代码一起做版本管理。每次Agent版本更新，都要跑一遍完整评测集，记录分数变化。如果某个版本分数突然下降，能快速定位是哪个用例出了问题。

6. 落地实操中的坑与经验

6.1 评测环境与生产环境不一致的代价

这是最常见的坑，也是代价最大的坑。评测环境里工具都是mock的，返回数据都是理想的，Agent表现很好。一上生产，工具超时、返回格式不对、数据缺失，Agent直接懵了。

我的经验是：评测环境要尽可能还原生产环境。具体做法：

• 工具接口用真实接口，但指向测试数据
• 模拟真实的网络延迟和错误率
• 数据要包含脏数据、缺失值、异常值
• 并发压力要接近生产峰值

如果实在没法用真实接口，至少要把各种异常情况都mock出来。我一般会要求mock工具支持“按概率返回错误”，比如10%的概率超时、5%的概率返回格式错误。

6.2 评测指标好看但业务效果差的悖论

这个坑很隐蔽。评测指标都达标了，但业务方反馈“不好用”。原因通常是评测指标跟业务目标脱节。

比如你评的是“任务完成率”，但业务方关心的是“用户满意度”。Agent可能完成了任务，但过程很啰嗦、语气很生硬，用户不爽。或者你评的是“工具调用准确率”，但业务方关心的是“响应速度”，Agent调对了工具但太慢。

解决方案是：评测指标必须跟业务方一起定。在评测开始前，跟业务方对齐“什么算好”，把业务目标翻译成可量化的评测指标。这个过程不能省，否则评了也白评。

6.3 人工评估的组织与质量控制

有些维度机器评不了，必须人工评。比如“回复是否得体”“解释是否清晰”“整体体验如何”。

人工评估的组织有几个要点：

评估员培训：不能随便找个人就评。要给评估员讲清楚评分标准，最好先做一轮校准，确保大家的评分尺度一致。

盲评：评估员不知道哪个是哪个版本，避免先入为主。

多人评：每个用例至少两个人评，取平均。如果两人分歧大，找第三个人仲裁。

抽样复核：定期抽查评估员的评分，确保质量没有漂移。

人工评估成本高，所以要用在刀刃上。我一般只在关键版本发布前做人工评估，日常迭代用自动评估。

6.4 评测频率与迭代节奏的平衡

评测太频繁，浪费时间；评测太少，问题发现不及时。我的建议是：

• 每次代码提交：跑核心集的快速回归（5分钟内）
• 每日构建：跑完整评测集（30分钟内）
• 版本发布前：跑完整评测集+人工评估+对抗测试
• 每月：做一次全面评测，包括在线指标分析

这个节奏能保证问题尽早发现，又不至于拖慢迭代。

7. 从评测到优化：让评测结果真正产生价值

7.1 失败用例的归因分析方法

评测的目的不是打分，而是发现问题并优化。所以失败用例的归因分析比分数本身更重要。

我一般用“五问法”来归因：

1. 失败的直接原因是什么？（如工具调用错误）
2. 为什么会出现这个原因？（如工具描述不清晰）
3. 为什么工具描述不清晰？（如文档没更新）
4. 为什么文档没更新？（如没有维护流程）
5. 根本原因是什么？（如缺少工具变更的规范）

这样一层层问下去，才能找到真正需要修复的地方。如果只停留在第一层，可能只是改改prompt，治标不治本。

归因分析的结果要分类统计。如果80%的失败都是同一类原因，那优先解决这一类。如果失败原因很分散，说明Agent的基础能力还有问题，需要系统性优化。

7.2 评测驱动的Prompt与工具优化

评测结果最直接的用途是优化Prompt和工具定义。

Prompt优化：如果发现Agent经常误解某个意图，就在Prompt里补充该意图的说明和示例。如果发现Agent经常漏掉某个步骤，就在Prompt里强化该步骤的指令。

工具优化：如果发现Agent经常选错工具，就检查工具的名称和描述是否清晰。工具名要见名知义，描述要说明“什么时候用”和“什么时候不用”。如果发现参数经常填错，就在参数描述里给出格式示例。

这里有个经验：工具描述的优化往往比Prompt优化更有效。因为Agent选工具主要看工具描述，描述清晰了，选错的概率就低了。

7.3 建立评测-优化-回归的闭环

评测不是一次性的，要形成闭环：

1. 评测发现问题
2. 归因分析找到根因
3. 针对性优化（Prompt/工具/流程）
4. 回归评测验证优化效果
5. 如果没解决，回到第2步

这个闭环要自动化。每次优化后自动跑评测，自动对比分数。如果分数提升，合并代码；如果下降，回滚。

闭环的周期越短，迭代越快。我见过做得好的团队，从发现问题到验证修复，只需要半天。这需要评测框架、CI/CD、监控告警的紧密配合。

8. 一些关于Agent评测的零散思考

评测这件事，说到底是在回答“这个Agent到底行不行”。但“行不行”的标准是动态的——今天行，明天可能就不行了，因为用户期望在变、业务场景在变、竞争对手在变。

所以评测体系本身也要迭代。我每隔一个季度会重新审视评测指标，问自己：这些指标还能反映业务目标吗？有没有新的风险点没覆盖？评测集的分布还跟真实场景一致吗？

另一个体会是，评测要尽早介入。不要等Agent开发完了再想怎么评。在需求阶段就要想清楚“怎么算成功”，在设计阶段就要把可评测性考虑进去（比如工具调用要打日志、状态变化要可追踪）。评测前置能省掉后面很多返工。

最后说个心态问题。评测分数低不可怕，可怕的是分数虚高。一个真实的60分比一个注水的90分有价值得多。评测的目的是暴露问题，不是证明自己行。抱着这个心态做评测，才能真正从评测中获益。

提示：评测集里一定要保留一组“永远不会删”的核心用例，它们是你跨版本对比的基准。这组用例的分数波动超过5%，就说明有严重问题，必须排查。