简介：本文围绕智能体（Agent）评估容易被忽视的问题展开，说明为什么不能把 Agent 当普通问答系统来评分。文章提出结果层、轨迹层、资源成本层三层评测框架，并讨论硬门禁、任务完成定义、指标选择、测试样本设计、结果解读与适用边界，帮助开发者、架构师和技术负责人建立可落地的 Agent 评测方法。
在智能体应用逐渐进入研发流程、自动化办公、数据处理、运维辅助和业务系统集成之后，一个非常现实的问题随之出现：如何判断一个 Agent 到底做得好不好？
很多团队在评估 Agent 时，会自然沿用传统问答系统或文本生成模型的评测方式。常见的做法是准备一批题目，让 Agent 给出答案，再由人工或模型打分。这种评测方式看起来直观，却很容易掩盖 Agent 真正的行为问题。
Agent 与普通问答模型最大的不同在于，它不只产生一段答案，而是执行一连串动作。它可能调用工具、查询数据、读取文档、修改状态、发送请求，甚至执行外部操作。最终答案只是这串动作的结果之一，而不是全部。
因此，Agent 评估的核心对象不应该只是“最终输出”，而应当是“任务完成情况”“执行过程质量”和“资源消耗情况”的综合表现。本文将从这三个层面展开，讨论一套可落地的 Agent 评测框架。
本文适合以下读者：
需要提前说明的是，本文不针对某一家云厂商或某一个具体 Agent 产品进行评测，而是讨论一类通用评估方法。文中提到的云服务、模型能力和工具能力均为通用技术概念。
评估 Agent 的第一步，并不是寻找一套放之四海皆准的指标，而是先把每类任务的完成条件写清楚。
很多评测冲突，其实是来自各方对“完成”的理解不一致。例如，一个研究类 Agent 输出了一篇看似完整的报告，但遗漏了关键信息源，或者对相互矛盾的证据没有处理。对使用者来说，只要报告流畅就可能被认为完成；而从工程角度看，这种输出并不能算真正可靠。
因此在设计评测之前，需要先回答以下问题：
这些问题看似基础，但如果没有事先定义，后续的自动化评分、人工复核和模型裁判都会失去判断基础。
不同类型的 Agent 任务，应当有不同的完成条件。
事实问答类任务
完成条件不应只是“答案看起来正确”。关键结论必须与可靠证据一致，并且证据能够支撑对应主张。对于无法确认的内容，Agent 应当说明不确定性，而不是用流畅表达掩盖信息缺失。
研究分析类任务
完成条件至少包括：
工具操作类任务
完成条件需要更谨慎。Agent 调用工具后，仅凭接口返回“成功”并不等于业务状态真的发生了变化。例如，创建工单、发送消息、修改配置、写入数据等操作，必须通过后端业务状态或二次查询确认。
代码类任务
应通过测试用例、构建结果或预期行为进行验证，而不能以 Agent 自述“已经修复”作为完成标准。
为了保持评测的一致性和可追溯性，每条样本最好同时保存以下内容：
对于开放任务，不一定需要唯一的“标准答案”，但至少要有可验收的事实、范围和完成证据。否则，不同评测人员或不同版本的分数之间没有可比性。
将 Agent 当普通问答模型来评估，最常见的问题是只看“最终答案好不好”。
这种做法至少会带来三个严重偏差。
一个 Agent 可能选错工具、多次无效调用、忽略关键限制，最后仍然碰巧得到看起来合理的答案。如果只看最终输出，这种不稳定行为会被掩盖。下一次遇到相似任务时，Agent 可能因为路径变化而失败。
有些 Agent 执行过程看起来很有条理，工具调用顺序合理，日志也清晰。但是，如果任务最终没有完成，或者关键目标没有达成，依然不能算成功。
即使任务最终完成，执行过程也合理，如果消耗了大量不必要的 Token、调用次数、时间或人工介入，那它在真实业务中的可用性仍然存疑。
因此，单一维度的评分很难支撑 Agent 的生产级判断。更合理的做法是建立分层评估体系。
为了避免单层评估带来的偏差，建议将 Agent 评估拆成三个层次：
三者之间不是简单相加关系。结果正确不能抵消越权操作；过程规范也不能替代任务失败；成本较低更不能弥补关键事实错误。
安全、权限、关键事实和副作用确认应当作为硬门禁。也就是说，只要这些方面出现问题，即使最终答案流畅、执行路径简短、资源消耗较低，也不能判定为合格。
结果层是评估 Agent 的第一道判断。它关注的是用户目标是否被真正满足。
任务完成率不应只看“有没有输出”。需要拆解用户要求中的关键目标，逐项确认是否完成。对于复杂任务，可以设计必须完成项与可选项，分别统计。
关键主张必须与可靠证据一致。评测时可以将 Agent 输出中的关键事实抽取出来，与预先准备的证据集合进行比对。
在需要引用来源的任务中，不能只统计引用数量。更关键的是，引用是否真的支撑它旁边的结论。一个字符串中有多个链接，不代表结论有依据。
一些 Agent 会用大量无关内容制造“信息很丰富”的错觉。评测需要检查用户最初要求中的关键点是否被真正覆盖，而不是看输出长度或表面结构。
对于要求输出表格、代码、文件、结构化字段的任务，格式是否符合要求是硬性完成条件。如果格式不正确，即使内容正确也可能无法接入下游系统。
当证据不足时，Agent 是否说明了限制，是否请求澄清，是否拒绝武断下结论，这些都应作为结果质量的一部分。
对于涉及消息发送、数据修改、工单创建、权限变更等外部操作的任务，必须通过后端状态或业务验证器确认实际效果。只根据接口返回成功来判定存在风险。
其中，权限合规、关键事实、必须引用和副作用确认应设为硬门禁。一次越权操作不能被最终文字的完整性所掩盖。
只看最终结果，很容易漏掉偶然猜对、错误工具选择、无效循环和不稳定恢复等问题。因此需要引入轨迹层评估。
很多 Agent 会输出一段推理过程或内部思考。虽然其中可能包含有价值的信息，但不应将其作为主要评测依据。
原因在于，隐藏思维链不一定反映真实决策过程，也可能在输出时被重写或简化。更可靠的方式是基于可观察动作轨迹进行判断，包括工具调用、参数、返回状态、重试、切换策略和环境变化。
轨迹层可以重点观察以下方面：
例如，一个研究任务中，Agent 多次请求同一数据源而未得到有效信息，仍然继续重复访问，说明其在失败处理上不够成熟。又如，一个代码修复任务中，Agent 修改了多个文件，但没有运行相关测试，这种轨迹本身就存在风险。
要评估轨迹，评测环境需要记录完整的动作序列。通常包括：
这些信息可以来自日志、调用记录或专门的评测平台。评测人员可以从中判断 Agent 的行为模式，而不是只看最后一段话。
资源成本层常常被忽视，但在生产环境中非常关键。
成本不只是金额。可以从以下维度观察：
一个任务即使完成，如果每次都需要大量无效调用，批量化运行时会带来明显资源压力。
由于不同任务复杂度不同，不建议使用绝对数值作为唯一标准。更合理的做法是结合任务等级，观察成本与结果之间的关系。
可以建立“任务等级—最低可接受成本—典型成本—异常成本”的参考区间。例如，简单信息查询不应出现大量工具调用；复杂研究任务则允许更多查询步骤。超出合理区间的，需要进一步分析轨迹。
同时，可以引入效率指标，例如：
这些指标可以在多次运行后形成分布，用于观察 Agent 的稳定性和效率。
在评测体系设计中，必须明确区分“硬门禁”和“软指标”。
硬门禁是一票否决项。只要违反，就判定当前样本不合格，无需考虑其他维度。
常见硬门禁包括：
硬门禁的目的是防止模型或人工裁判因为答案文笔较好、格式较完整，就在综合评价中“平均掉”严重错误。
软指标用于在通过硬门禁的样本之间进一步比较质量优劣，例如流畅度、覆盖度、结构化程度、调用效率等。软指标可以打分，但不能用于抵消硬门禁问题。
Agent 评测不能只靠少量示例。要得到稳定结论，需要建立一定规模的评测集。
样本可以来自真实业务日志、用户问题、典型流程，也可以由专家构造边界用例。需要注意去重、覆盖不同任务类型和难度等级。
建议按任务难度和风险等级分层，例如：
不同层的样本数量不必完全相等，但每层都应有足够数量以支持结论。
每次评测需要记录：
这些信息决定评测结果是否可复现，也决定结论适用于什么范围。
一次完整评估可以按以下流程进行。
先确定本次评测要回答什么。例如：
避免在一次评测中同时堆积过多指标，导致最后结果难以解释。
准备样本集，并在相同条件下运行一个或多个基线版本。基线可以是上一版本、通用模型方案，也可以是人工执行结果。只有存在对比，结果才有意义。
分别从功能、结果正确性、轨迹合理性、安全性、资源消耗、易用性等维度进行验证，而不是只给出一个总分。
每次运行都要保存完整过程信息。对于出现问题但最终成功的样本，尤其值得分析。
不要只看平均分。建议观察：
例如，如果 Agent 在简单任务上成功率高，但在多步任务上频繁出现无效调用，那么更可能的问题出在工具选择策略或状态维护能力，而不是模型知识不足。
由于不同任务目标不同，很难给出统一分数标准。但可以从以下信号判断 Agent 是否具备较好能力。
如果 Agent 在大量样本上极少触发硬门禁，说明其基础行为约束较为可靠。
即使失败，如果失败原因集中在明确环节，例如工具返回格式异常、前置条件不足等，也比随机性失败更容易改进。
如果资源消耗分布稳定，较少出现极端值，说明 Agent 行为可预测，便于容量规划和成本控制。
在长流程任务中，是否能在错误后调整策略，而不是继续重复同一动作，是评估成熟度的重要信号。
不同业务场景下，三层评估的侧重点会有所不同。
企业知识问答场景
重点看结果层的事实正确性、引用支持度和不确定性处理。轨迹层关注查询路径是否合理，资源成本层看是否存在大量重复检索。
研发辅助与代码场景
必须验证代码是否通过测试或构建，而不是 Agent 自述。轨迹层关注修改范围是否最小化、是否运行了验证步骤、是否触碰无关文件。
业务系统操作场景
硬门禁优先级最高。副作用确认必须通过业务校验，不能只看接口返回。轨迹层要观察是否存在未授权修改、重复提交或不可逆操作。
数据分析与研究场景
结果层关注覆盖度和冲突处理。轨迹层看是否收集了足够信息、是否检查了数据质量。资源成本层面，分析任务的成本容忍度通常更高，但不能出现明显无效循环。
任何评测方法都有边界。
首先是样本偏差。评测集覆盖不全会导致结论局部有效。其次，环境差异会影响轨迹与成本表现。不同模型配置、网络条件、工具可用范围都可能改变 Agent 行为。
人工裁判也存在不确定性。不同评审人对“完成”和“合理轨迹”的理解可能不同，需要通过清晰的标准和样例进行对齐。
此外，Agent 行为具有随机性。单次评测可能不代表稳定表现，建议多次运行并对分布进行分析。
最后，评测只能基于可观察信息。如果系统日志不完整，或轨迹记录缺失关键字段，轨迹层评估会受到限制。
对于希望在真实业务中使用 Agent 的团队，建议不要过度依赖一次性评测结论。
更合理的方式是：
如果资源有限，可以先从高风险任务开始建立评测集。对于涉及外部副作用的操作，应优先保证硬门禁和轨迹层记录完整。
Agent 评估不能简化为“给一道题、看一个答案、打一个分”。因为 Agent 的背后是一连串动作，而不是单次生成。
更可靠的评估方式，是将判断拆成三层：任务结果、执行轨迹和资源成本。结果层回答“目标是否完成”，轨迹层回答“是否用正确方式完成”，资源成本层回答“完成代价是否可接受”。
在这三层之上，安全、权限、关键事实和副作用确认应当作为硬门禁。硬门禁不能被任何软指标抵消。
要建立这样的评测体系，并不依赖某一种特定工具或平台，而更依赖先定义清楚什么叫完成、记录什么过程、观察什么成本。只有先建立这些基础，模型裁判、人工评审和自动化指标才有可靠的判断依据。
对于开发者、技术负责人和企业团队来说，建立一套适合自身业务特点的 Agent 评测框架，可能比继续增加模型能力更重要。因为只有在可验证、可比较、可控制的评估体系下，Agent 的迭代才有方向。