企业官网建设流程全解析

1. 为什么Agent评测比模型评测难十倍

做Agent开发的人都有一个共同的感受：模型评测好做，Agent评测难做。模型评测本质上是一个输入输出映射问题——给一道题，看答案对不对，准确率、召回率、F1值一算就完事。但Agent不一样，它是有状态的、多轮交互的、会调用外部工具的、执行路径不唯一的。同一个任务，Agent可能走三条完全不同的路径都能成功，也可能在第三步调错了一个工具就全盘崩溃。

我刚开始接触Agent评测的时候，犯了一个很典型的错误：拿模型评测的那套思路直接套上去。构造一批问答对，让Agent跑一遍，看最终答案对不对。结果跑下来发现两个致命问题。第一，很多任务Agent最终答案是对的，但中间过程完全不可复现，换一个随机种子结果就变了。第二，有些任务Agent答案错了，但排查发现是工具调用超时导致的，跟Agent本身的推理能力没关系。这两个问题让我意识到，Agent评测的核心不是评“结果”，而是评“过程加结果”。

这就是Agent评测的第一个认知门槛：评测对象的边界变了。模型评测评的是模型本身，Agent评测评的是一个系统——包含LLM、提示词、工具集、编排逻辑、记忆机制、错误处理策略。任何一个环节出问题，最终表现都会受影响。所以你不能只盯着LLM的输出去打分，必须把整个执行链路拆开来看。

第二个认知门槛是评测维度的爆炸。模型评测通常看准确率、流畅度、安全性这几个维度就够了。Agent评测至少要覆盖：任务完成度、工具调用准确率、路径效率、错误恢复能力、多轮一致性、成本消耗、延迟表现。这些维度之间还互相牵制——追求路径效率可能导致错误恢复能力下降，追求任务完成度可能成本飙升。怎么在这些维度之间做权衡，是Agent评测最考验功力的地方。

第三个门槛是评测数据的构造。模型评测可以用公开数据集，MMLU、GSM8K、HumanEval这些拿来就能用。但Agent评测几乎没有通用的公开数据集，因为每个Agent的工具集不同、业务场景不同、任务类型不同。你得自己构造评测集，而且构造出来的评测集还得保证覆盖度、难度分布合理、可复现。这件事的工作量远超大多数人的预期。

我见过不少团队在Agent评测上踩坑，最常见的模式是：花两周搭了一个评测框架，跑了一轮发现结果不可信，然后开始怀疑框架有问题，反复改框架，又花了两周，结果还是不可信。问题根本不在框架，在于评测集本身设计得有问题——任务描述有歧义、预期结果定义不清晰、工具调用没有标准答案。所以这篇内容我会从“评什么”开始讲，把评测对象、评测维度、评测集构造这三个基础问题讲透，再讲“怎么评”和“怎么落地”。

2. 评测对象拆解：你到底在评Agent的哪一层

2.1 把Agent拆成五个可独立评测的层

很多人做Agent评测，上来就跑端到端任务，看成功率。这个指标当然要看，但它是一个“结果指标”，出了问题你根本不知道是哪一层出的问题。我的做法是把Agent拆成五层，每层单独设计评测方案，最后再看端到端的综合表现。

第一层是规划层。Agent拿到一个任务后，能不能把它拆解成合理的子任务序列。比如“帮我查一下北京明天天气，如果下雨就提醒我带伞”，规划层要输出的是：先调天气查询工具，拿到结果后判断是否下雨，如果下雨则触发提醒。这一层的评测重点是子任务拆解的完整性和顺序合理性。

第二层是工具选择层。给定一个子任务，Agent能不能选对工具。比如查天气应该调weather API而不是search API。这一层评测的是工具选择的准确率，通常用混淆矩阵来看——哪些工具容易被混淆，混淆的方向是什么。

第三层是参数填充层。选对了工具，参数填得对不对。比如weather API需要city和date两个参数，Agent能不能从上下文里正确提取出“北京”和“明天”对应的日期。这一层评测的是参数提取的准确率和格式合规率。

第四层是执行与错误处理层。工具调用失败了怎么办？超时了怎么办？返回结果不符合预期怎么办？这一层评测的是Agent的鲁棒性。我通常会故意注入一些错误——让工具返回500、返回空结果、返回格式错误的数据——看Agent能不能正确处理。

第五层是结果整合层。多个工具调用的结果拿到之后，Agent能不能正确整合成最终答案。这一层评测的是信息聚合和推理能力。

把这五层拆开之后，你会发现很多端到端失败案例能精确定位到某一层。我做过一个统计，在我们自己的Agent项目里，端到端失败案例中约40%是工具选择错误，25%是参数填充错误，20%是错误处理不当，只有15%是规划或整合的问题。这个分布直接指导了我们的优化方向——优先优化工具选择和参数填充。

2.2 不同Agent架构的评测重点不一样

Agent的架构差异很大，ReAct、Plan-and-Execute、Multi-Agent、Workflow-based，每种架构的评测重点不同。你不能拿一套评测方案套所有架构。

ReAct架构的Agent是“思考-行动-观察”循环，它的核心风险是陷入死循环或者反复调用同一个工具。所以评测ReAct Agent时，除了常规维度，必须加一个“循环检测”指标——统计单个任务的平均步数和最大步数，如果某个任务步数异常高，大概率是循环了。

Plan-and-Execute架构的Agent是先规划再执行，它的核心风险是规划阶段就错了，后面执行再完美也没用。所以评测这类Agent时，规划层的权重应该调高，甚至可以单独把规划结果拿出来人工评估。

Multi-Agent架构的Agent是多个Agent协作，它的核心风险是通信开销和角色冲突。评测时要额外关注Agent之间的消息传递次数、是否有角色重叠导致的重复工作、是否有Agent一直空闲。

Workflow-based架构的Agent是预定义流程，它的核心风险是流程覆盖不全。评测时要重点看异常流程的处理——当输入不满足任何预定义流程时，Agent能不能优雅降级。

我自己的项目用的是ReAct加部分Workflow的混合架构，所以评测方案也是混合的：常规任务走ReAct评测流程，高频确定性任务走Workflow评测流程，两套结果分开统计再合并。

2.3 评测的粒度选择：步骤级还是任务级

步骤级评测和任务级评测各有优劣，我的建议是两者都要，但用途不同。

步骤级评测是在Agent执行的每一步都打分，比如每一步的工具选择对不对、参数对不对。这种评测的优点是定位精准，缺点是标注成本极高——一个任务如果有10步，你就要标10个步骤的预期结果。而且有些步骤本身没有唯一正确答案，比如先查A还是先查B可能都合理。

任务级评测是只看最终结果，中间过程不管。优点是标注成本低，缺点是出了问题不知道哪一步错了。

我的做法是：用任务级评测做日常回归，用步骤级评测做问题定位。日常跑回归的时候，只统计任务级指标，快速发现有没有退化。一旦发现某个任务失败了，再单独对这个任务做步骤级评测，精确定位问题。这样既控制了标注成本，又保证了排查能力。

具体操作上，我会维护两套评测集：一套是“回归集”，任务级标注，规模大，跑得快；一套是“诊断集”，步骤级标注，规模小，但每个任务都有详细的步骤预期。回归集每天跑，诊断集按需跑。

3. 评测维度设计：从任务完成度到成本效率的完整指标体系

3.1 任务完成度：不能只看成功率

任务完成度是最核心的指标，但“成功率”这个单一数字太粗糙了。我通常会把任务完成度拆成四个子指标。

完全成功：Agent输出的结果完全符合预期，包括格式、内容、附加信息都正确。

部分成功：核心结果正确，但有一些小瑕疵，比如格式不对、多了一些无关信息、少了一些非关键字段。

可修复失败：Agent输出的结果不对，但错误是可修复的，比如参数差一点、工具选错了但换一个就能对。

不可修复失败：Agent完全跑偏了，或者陷入了死循环，或者输出了完全无关的内容。

这四个子指标的分布比单一成功率有信息量得多。如果完全成功率是60%，部分成功率是30%，那说明Agent基本能用，主要问题是输出不够精确。如果完全成功率是60%，但不可修复失败率是30%，那说明Agent的稳定性有严重问题。

计算方式上，我通常用加权得分：完全成功得1分，部分成功得0.7分，可修复失败得0.3分，不可修复失败得0分。最终的任务完成度得分就是所有任务得分的平均值。这个加权方案可以根据业务需求调整——如果业务对格式要求极高，那部分成功的权重可以调低。

3.2 工具调用准确率：混淆矩阵比准确率更有用

工具调用准确率不能只看一个百分比，要看混淆矩阵。我举个例子，假设Agent有五个工具：search、weather、calendar、email、calculator。跑完评测集后，我统计出这样一个混淆矩阵：

从这个矩阵能看出几个问题。第一，search和email之间有明显的混淆——有5次该调search的时候调了email，有6次该调email的时候调了search。这说明这两个工具的描述可能有重叠，或者Agent对“查找信息”和“发送信息”的意图区分不够清晰。第二，calendar的准确率相对较低，有4次该调calendar的时候调了search，说明Agent可能倾向于用search来“查日程”而不是用calendar。

有了这个矩阵，优化方向就很明确了：要么改工具描述，要么加few-shot示例，要么在提示词里明确区分这几个工具的适用场景。这比只看一个“工具调用准确率88%”有用得多。

3.3 路径效率：步数和token消耗要一起看

路径效率衡量的是Agent完成任务用了多少步、消耗了多少token。这个指标直接关系到成本和用户体验。

我通常统计三个数字：平均步数、P95步数、平均token消耗。平均步数看整体效率，P95步数看长尾情况——如果P95步数远高于平均步数，说明有一部分任务Agent绕了远路。平均token消耗直接对应成本。

但路径效率不能孤立地看。有些任务步数多是因为任务本身复杂，有些任务步数多是因为Agent在绕路。怎么区分？我的做法是引入一个“最优步数”的概念——对于每个任务，人工标注一个理论上的最优步数（或者用规则自动计算）。然后看Agent实际步数和最优步数的比值。这个比值我称之为“路径膨胀率”。

路径膨胀率在1.0到1.5之间算正常，1.5到2.0之间算有优化空间，超过2.0就说明Agent的规划或执行有明显问题。我自己的项目里，优化前路径膨胀率平均是1.8，优化后降到了1.3，token成本直接降了35%。

3.4 错误恢复能力：故意注入错误来测

错误恢复能力是Agent评测里最容易被忽略的维度，但它在生产环境里极其重要。因为生产环境的工具调用失败率远高于测试环境——网络抖动、API限流、数据格式变化，什么都有可能发生。

我的测试方法是故障注入。具体来说，在Agent调用工具的时候，按一定概率注入以下几种故障：

• 超时故障：让工具调用延迟5秒以上再返回。
• 错误码故障：让工具返回500或429。
• 空结果故障：让工具返回空数据。
• 格式错误故障：让工具返回不符合schema的数据。
• 部分失败故障：如果Agent一次调了多个工具，让其中一个失败。

然后看Agent能不能正确处理这些故障。正确的处理方式包括：重试、降级到备用工具、向用户说明情况、跳过该步骤继续执行。错误的处理方式包括：直接崩溃、无限重试、忽略错误继续用错误数据、输出错误结果但不告知用户。

我通常会统计一个“错误恢复成功率”——在注入故障的情况下，Agent仍然能完成任务的比例。这个指标在生产环境里比正常情况下的成功率更有参考价值。

3.5 成本与延迟：不能忽略的工程指标

Agent评测不能只看效果，还要看成本和延迟。一个Agent如果效果很好但每次调用要花5块钱、等30秒，那在生产环境里是不可接受的。

成本指标我通常统计：单任务平均token消耗、单任务平均工具调用次数、单任务平均费用。延迟指标我通常统计：端到端延迟P50、P95、P99。

这两个指标要和效果指标一起看。我见过一些团队为了提升5%的成功率，把token消耗翻了一倍，这在大多数业务场景下是不划算的。正确的做法是画一条“效果-成本曲线”——横轴是成本，纵轴是效果，看当前方案在曲线上的位置，以及有没有更优的点。

4. 评测集构造：从零搭建一套可复现的Agent评测数据

4.1 评测集的三个来源

Agent评测集没有现成的公开数据集可用，必须自己构造。我通常从三个来源构造评测集。

第一个来源是真实用户请求。这是最宝贵的来源，因为真实请求的分布就是生产环境的分布。我会从日志里采样一批真实请求，然后人工标注预期结果和预期执行路径。这个来源的评测集最贴近实际，但标注成本最高。

第二个来源是人工构造的边界案例。真实请求往往集中在常见场景，边界场景很少出现。所以需要人工构造一批边界案例，比如：输入包含歧义的任务、需要多步推理的任务、工具调用可能失败的任务、输入格式不规范的任务。这个来源的评测集能覆盖真实请求覆盖不到的地方。

第三个来源是自动化生成。用LLM来生成评测任务，然后人工筛选和修正。这个来源的评测集规模可以做得很大，但质量参差不齐，需要严格筛选。我的做法是用LLM生成10倍于目标规模的任务，然后人工筛选出质量最高的那10%。

三个来源的比例我通常是：真实请求50%，人工构造30%，自动化生成20%。这个比例可以根据项目阶段调整——项目早期真实请求少，可以多用人工构造；项目成熟期真实请求多，可以多用真实请求。

4.2 评测集的结构设计

一个评测任务的数据结构至少包含以下字段：

{ "task_id": "task_001", "task_description": "帮我查一下北京明天天气，如果下雨就提醒我带伞", "expected_tools": ["weather"], "expected_params": {"city": "北京", "date": "2024-01-16"}, "expected_final_answer": "北京明天有雨，记得带伞", "optimal_steps": 2, "difficulty": "easy", "category": "weather", "tags": ["单工具", "条件判断"] }

其中expected_tools和expected_params是步骤级标注，expected_final_answer是任务级标注，optimal_steps用于计算路径膨胀率，difficulty和category用于分层统计。

对于复杂的多步任务，expected_tools和expected_params可以是数组，表示每一步的预期：

{ "task_id": "task_002", "task_description": "查一下我明天有没有会议，如果有就帮我发邮件提醒参会人", "expected_steps": [ {"tool": "calendar", "params": {"date": "2024-01-16"}}, {"tool": "email", "params": {"to": "参会人列表", "subject": "会议提醒"}} ], "expected_final_answer": "已发送会议提醒邮件", "optimal_steps": 2, "difficulty": "medium", "category": "calendar+email", "tags": ["多工具", "条件触发"] }

4.3 难度分层与覆盖度检查

评测集构造完之后，必须做难度分层和覆盖度检查。难度分层是为了保证评测集里简单、中等、困难任务的比例合理。我通常按3:5:2的比例分配——30%简单任务、50%中等任务、20%困难任务。简单任务用于快速回归，中等任务是主力，困难任务用于压力测试。

覆盖度检查是看评测集有没有明显的盲区。我通常从几个维度检查：

• 工具覆盖：每个工具至少出现在10个任务里。
• 工具组合覆盖：常见的工具组合（比如search+calculator、calendar+email）至少出现在5个任务里。
• 任务类型覆盖：查询类、操作类、推理类、多步类任务都要有。
• 边界情况覆盖：歧义输入、缺失参数、工具失败等情况都要有。

覆盖度检查可以用一个简单的脚本自动统计，输出每个维度的覆盖情况，缺哪个补哪个。

4.4 评测集的版本管理

评测集不是构造一次就完事了，它会随着Agent的迭代不断更新。所以必须做版本管理。

我的做法是：评测集用Git管理，每次修改都提交，打上版本标签。每次Agent发版，都记录用了哪个版本的评测集。这样当评测结果出现异常时，可以回溯是Agent变了还是评测集变了。

另外，评测集要分“稳定集”和“演进集”。稳定集是固定的，不随Agent迭代而修改，用于跨版本对比。演进集是可以修改的，用于覆盖新场景。稳定集保证了你有一个不变的基准，演进集保证了评测集能跟上Agent的发展。

5. 评测方法选型：LLM-as-a-Judge到底靠不靠谱

5.1 规则评测、人工评测、LLM评测的适用边界

Agent评测有三种主流方法：规则评测、人工评测、LLM评测。它们各有适用边界，不能互相替代。

规则评测适合结果确定性强、格式固定的场景。比如工具调用是否选对、参数是否填对、最终答案是否包含某个关键词。规则评测的优点是快、便宜、可复现，缺点是只能评“硬指标”，评不了“软指标”。

人工评测适合主观性强、需要专业判断的场景。比如最终答案的质量、推理过程的合理性、错误处理的优雅程度。人工评测的优点是准，缺点是慢、贵、不可复现。

LLM评测（LLM-as-a-Judge）适合介于两者之间的场景。比如判断两个答案哪个更好、判断答案是否包含了预期信息、判断推理过程是否合理。LLM评测的优点是比人工快、比规则灵活，缺点是稳定性差、有偏见。

我的做法是三者结合：规则评测做日常回归，LLM评测做质量评估，人工评测做最终验收。日常回归跑规则评测，快速发现硬指标退化。每周跑一次LLM评测，看软指标有没有变化。发版前做人工评测，确保关键场景没问题。

5.2 LLM-as-a-Judge的常见偏见与缓解方法

LLM-as-a-Judge有几个已知的偏见，用的时候必须注意。

位置偏见：LLM倾向于选择第一个或最后一个选项。缓解方法是随机打乱选项顺序，或者做双向评测（A vs B和B vs A都跑一遍，取平均）。

长度偏见：LLM倾向于选择更长的答案。缓解方法是在提示词里明确说明“长度不代表质量”，或者对答案做长度归一化。

自我偏好：LLM倾向于选择自己生成的答案。缓解方法是不要用同一个模型做生成和评测，或者用多个模型交叉评测。

格式偏见：LLM倾向于选择格式更规范的答案。这个偏见有时候是好事有时候是坏事，取决于你的业务需求。

我自己的做法是用三个不同的模型做评测，然后取多数投票。如果三个模型的结果分歧很大，就转人工评测。这样虽然成本高一些，但可靠性提升明显。

5.3 评测提示词的设计要点

LLM-as-a-Judge的提示词设计直接决定评测质量。我总结了几个要点。

第一，给出明确的评分标准。不要只说“请评分”，要说“请从1到5分评分，1分代表完全错误，3分代表部分正确，5分代表完全正确”。评分标准越具体，LLM的评分越稳定。

第二，给出参考示例。在提示词里放几个评分示例，让LLM知道什么样的答案对应什么分数。示例要覆盖不同的分数段。

第三，要求给出评分理由。让LLM在给出分数之前先说明理由，这样一方面能提升评分的可解释性，另一方面能提升评分的准确性——LLM在写理由的过程中会重新审视答案。

第四，控制输出格式。要求LLM输出结构化的结果，比如JSON格式，方便后续解析。

一个典型的评测提示词模板：

你是一个Agent评测专家。请根据以下标准对Agent的输出进行评分。 评分标准： - 5分：完全正确，格式规范，无多余信息 - 4分：核心正确，有小瑕疵（如格式不规范、有多余信息） - 3分：部分正确，核心信息有缺失或错误 - 2分：大部分错误，但有少量正确信息 - 1分：完全错误或无关 参考示例： [示例1] 任务：... 输出：... 评分：5分 理由：... [示例2] 任务：... 输出：... 评分：3分 理由：... 任务：{task} Agent输出：{output} 预期结果：{expected} 请先说明理由，再给出评分。输出格式： {"reason": "...", "score": 5}

5.4 评测结果的一致性校验

LLM评测的结果必须做一致性校验。我通常做两种校验。

第一种是重测一致性。同一个评测任务，用同样的提示词跑两次，看两次评分是否一致。如果一致率低于80%，说明评测提示词不够稳定，需要优化。

第二种是交叉一致性。用不同的LLM跑同一个评测任务，看评分是否一致。如果一致率低于70%，说明评测标准有歧义，需要细化。

一致性校验不通过的时候，不要急着用结果，先优化评测提示词。我见过太多团队直接拿不稳定的LLM评测结果做决策，最后发现优化方向完全错了。

6. 落地实践：把评测嵌入Agent开发流程

6.1 评测驱动的开发闭环

Agent评测不是一次性的工作，而是要嵌入到日常开发流程里。我自己的做法是建立一个“评测驱动”的开发闭环。

具体流程是：每次修改Agent（改提示词、改工具、改编排逻辑），先跑一遍回归评测集，看核心指标有没有退化。如果退化了，分析原因，修复后再跑。如果没有退化，再跑一遍诊断评测集，看有没有新的问题。如果都没问题，再上人工评测做最终确认。

这个闭环的关键是自动化。回归评测集必须能一键跑完，结果自动生成报告。我通常用CI/CD工具来做这件事——每次代码提交触发回归评测，结果发到群里。这样任何退化都能第一时间发现。

6.2 评测报告应该包含什么

评测报告不是简单地把指标列出来，而是要能指导决策。我通常的评测报告包含以下几部分。

第一部分是核心指标概览。包括任务完成度、工具调用准确率、路径膨胀率、错误恢复成功率、平均成本、平均延迟。每个指标都跟上一个版本对比，标出变化。

第二部分是分层统计。按难度分层、按任务类型分层、按工具分层，看每个分层的指标。这样能发现“整体指标没变但某个分层退化了”的情况。

第三部分是失败案例分析。列出所有失败案例，按失败原因分类，每个类别给几个典型例子。这部分是排查问题的关键。

第四部分是趋势图。把最近10个版本的指标画成趋势图，看整体趋势是向好还是向坏。

6.3 常见落地坑与应对

坑一：评测集和生产分布不一致。评测集跑得很好，上线后效果很差。应对方法是定期从生产日志采样，更新评测集。

坑二：评测指标和业务指标脱节。评测指标提升了，但业务指标没变。应对方法是把业务指标（比如用户满意度、任务完成率）也纳入评测体系，看两者是否相关。

坑三：评测成本失控。LLM评测和人工评测都很贵，跑一次评测花几千块。应对方法是分层评测——日常回归用规则评测，每周用LLM评测，发版前用人工评测。

坑四：评测结果不可复现。同样的Agent，跑两次评测结果不一样。应对方法是固定随机种子、固定评测集版本、固定评测提示词版本。

坑五：过度优化评测指标。为了让评测指标好看，针对评测集做特殊处理，导致泛化能力下降。应对方法是保留一个“黑盒评测集”——不参与日常优化，只在发版前跑，用于检测过拟合。

6.4 从评测到优化的最后一公里

评测的最终目的是优化。评测报告出来之后，怎么把评测结果转化为优化动作？

我的做法是建立一个“问题-原因-方案”的映射表。每个失败案例都归因到一个具体原因，每个原因对应一个优化方案。比如：

这个映射表积累多了之后，你会发现很多问题是重复出现的，对应的优化方案也可以复用。我自己的项目里，这个映射表已经积累了50多条，新问题出现时先查表，80%的情况能直接找到方案。

7. 我踩过的几个评测坑和最后的经验

第一个坑是过早追求自动化。刚开始做Agent评测的时候，我想一步到位搞全自动评测，结果花了两周搭框架，跑出来的结果完全不可信。后来退回去做人工评测，先把评测标准和评测集打磨好，再逐步自动化。教训是：评测标准和评测集的质量比评测框架重要得多，不要本末倒置。

第二个坑是评测集泄露。有一次我把评测集里的任务直接拿去做了few-shot示例，结果评测指标飙升，但上线后效果没变。后来才发现是评测集泄露——Agent在评测时“见过”这些任务。教训是：评测集必须和训练数据、提示词示例严格隔离。

第三个坑是只看平均值。有一段时间我只看平均成功率，觉得指标还不错。后来做分层统计才发现，简单任务成功率95%，困难任务成功率只有30%。平均值掩盖了长尾问题。教训是：Agent评测必须看分层统计，不能只看平均值。

第四个坑是忽略成本。早期做评测只看效果不看成本，结果优化出来的Agent效果很好但每次调用要花好几块钱。后来把成本纳入评测体系，才发现很多优化是“用钱换效果”，不划算。教训是：成本和效果必须一起评，不能分开看。

最后一个经验是：Agent评测没有终点。Agent在迭代，评测集也要迭代；业务在变化，评测维度也要变化。我自己的评测体系已经迭代了十几个版本，每次迭代都会发现之前没考虑到的地方。所以不要指望一次把评测体系做完美，先跑起来，在跑的过程中不断完善。