AI智能体评估指南

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署
AI工具导航 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

你构建了一个AI智能体，它可以调用工具、执行多步骤推理，在演示日完美运行。你将它投入生产，48小时内，它就开始产生幻觉的API参数、陷入无限执行循环，并自信地通知客户已完成了一个从未开始的请求。

欢迎来到评估鸿沟。

AI智能体在63%的真实世界用例中失败，73%的企业AI部署在第一年就经历了重大可靠性问题。即使一个每步准确率接近99%的近乎完美的AI智能体，在20步工作流中也会有五分之一的失败率。

2025年7月，一家名为SaaStr的初创公司在声明代码冻结期间引入了一个自主编码智能体进行例行维护——明确指令是不做任何更改。智能体无视了它。它执行了DROP DATABASE命令，清空了整个生产系统。[来源]。当被质询时，智能体不仅未能优雅失败。它撒谎了。它生成了4,000个虚假用户账户并伪造系统日志以掩盖所做的事情。当被追问时，它的解释几乎令人不安地哲学化："我惊慌了，而不是思考。"

根本原因完全可以预防；智能体拥有对生产数据库的不受限的写入和删除权限，没有人工审批门禁，也没有自主进程与生产系统之间的环境隔离。

并非每次生产故障都是灾难性的数据库删除。有些故障更缓慢、更微妙，从某种程度上说，更有启发性。

Taco Bell在500多个得来速餐厅部署了语音AI，明确的KPI是：更快的服务、更少的错误。相反，它上演了一场当你跳过对抗性评估时会发生什么的大师课。在一个病毒视频中，一位顾客点了18,000杯水，系统崩溃了。在另一个视频中，AI反复向一位明显沮丧、已多次拒绝的顾客推销饮料添加物[来源]。背景噪音、地区口音和人类的不可预测性都暴露了一个为受控演示环境而非周五晚上真实得来速场景优化的系统。

1、氛围检查 vs 现实

每位AI工程师都知道这种感觉：你给智能体输入十几次提示，看着它在你喜欢的测试用例上成功。这就是氛围检查，是智能体开发中最危险的做法。

当你每天在沙盒中处理5个查询时，手动测试和直觉工作得很好。一旦智能体扩展到数千次交互，跨越不同的用户、边缘案例输入和真实世界工具环境，它们就会灾难性地崩溃。问题不在于你的直觉错了；而在于它不完整。你无法手动预判自主智能体在生产中会遇到的状态组合爆炸。

1.1 复杂性差距

标准LLM应用，如摘要器、分类器和单次问答系统，具有相对有限的故障面。输入进来，输出出去，你可以用成熟的NLP指标评估质量。

智能体完全是不同的野兽。它们不只是生成文本；它们行动。它们规划、调用工具、解释中间结果、修订方法，并将数十个步骤的决策链连接在一起。这创造了一个巨大的故障面：

• 错误的工具调用：智能体将{"date": "tomorrow"}传递给需要ISO 8601时间戳的API。
• 无限循环：规划器决定需要"再搜索一次"——永远循环下去。
• 指令漂移：到推理追踪的第15步时，智能体已经完全忘记了用户最初要求什么。
• 幻觉行动：智能体声称它发送了邮件。它并没有发送邮件。

如果你只检查最终输出，这些故障模式中的每一个都是不可见的。每一个都可能级联成下游灾难。

以下是本指南构建的核心论点：

严格的评估不仅是安全网；它是产品和研究团队之间最高带宽的沟通渠道。

当产品经理说"智能体应该端到端处理退款请求"，这是一个需求规范。当工程师将其转化为包含确定性评分器和通过率目标的30个评估用例套件时，这就是一个合约。评估将模糊的产品直觉转化为可测量、可调试、可改进的工件。它们告诉研究团队模型在哪里失败。它们告诉产品团队智能体能够可靠地做什么、不能做什么。

在自主智能体时代，你的评估套件就是你的需求规范。我们需要相应地对待它。

2、为评估定义智能体架构

在评估智能体之前，你需要一个共享的词汇表来描述你在评估什么以及智能体如何运作。并非所有智能体都是平等的，架构决定了评估策略。

2.1 单轮 vs 多轮

最基本的架构区分是智能体在单个周期内完成工作还是跨越多个交互轮次完成。

单轮智能体是主力。它们是面向任务的cron作业，交互在一个端到端周期内完成。想象一个智能体接收自然语言请求，如"生成Q3的周销售报告并发送给财务团队"，然后规划工具调用、执行它们并返回最终结果。有一个输入、一个执行追踪、一个输出。用户在执行过程中不干预。

评估单轮智能体相对简单。你有明确定义的输入、明确定义的预期结果，以及可检查的追踪。挑战在于追踪本身的复杂性。我们需要评估智能体是否以正确的顺序、正确的参数调用了正确的工具。

多轮智能体是对话式或长期运行的智能体，它们维护状态并根据中间工具结果和用户反馈进行调整。一个客户支持智能体询问澄清问题、查找订单历史、提出解决方案，然后根据客户回应调整，这就是多轮智能体。跨越多次交流迭代解决方案的编码助手也是如此。

多轮评估要困难得多。你不仅需要评估最终结果，还需要评估交互质量：智能体是否提出了正确的澄清问题？它是否在各轮之间保持了上下文？当用户改变主意时，它是否优雅地恢复了？状态空间随着每一轮的增加而爆炸式增长。

2.2 评估的词汇表

在我们构建任何东西之前，我们需要共享语言。以下是四个基础概念：任务（Task）、试验（Trial）、评分器（Grader）和追踪记录/追踪（Transcript/Trace）

评估AI智能体的基础概念-作者图片[Vivedha Elango]

这四个概念构成了本指南中讨论的每个评估系统的支柱。一个结构良好的评估套件，本质上是一组任务的集合，每个任务跨多次试验运行，由评分器打分，每次执行都捕获在追踪记录中用于调试。

3、识别智能体在哪里失败

如果不知道在测试什么，就无法构建好的评估。让我们系统地映射故障场景。

3.1 端到端故障

这些是用户直接看到的故障：

未能完成目标：要求智能体安排会议，它却没有安排。可能被模糊的时区搞糊涂了，可能调用了错误的API，可能在工具返回意外错误后放弃了。无论根本原因如何，用户的意图未被满足。

无限思考循环：这是智能体版的无限while循环。智能体决定需要更多信息，调用搜索工具，获取结果，决定需要更多信息，再次调用搜索工具，重复直到达到token限制或超时。变体包括智能体反复修订计划但从不执行，或在两种矛盾策略之间摇摆。

这些端到端故障是最关键的需要捕获的，但它们对调试来说信息量最少。知道智能体未能预订航班并不能告诉你为什么。为此，你需要组件级评估。

3.2 组件级故障

每个端到端故障的表层之下，都有一个具体的组件出了问题：

错误的工具调用：这可以说是智能体系统中最常见的故障模式。LLM生成了一个工具调用，但是：

• 参数无效（类型错误、缺少必填字段、超出范围的值）
• 参数有效但错误（搜索2024年6月15日的航班而不是2025年）
• 智能体误解了工具的响应，将错误消息当作成功结果，或从JSON响应中提取了错误的字段

# 智能体生成的内容：
{"tool": "search_flights", 
 "params": {"from": "San Francisco", "to": "New York", "date": "June 15"}}

# API期望的内容：
{"tool": "search_flights",
 "params": {"origin": "SFO", "destination": "JFK", "date": "2025-06-15"}}

幻觉行动：智能体声称执行了从未实际执行的操作。这特别阴险，因为最终输出看起来是正确的。"我已向john@example.com发送了确认邮件"，但实际上没有邮件被发送。智能体完全幻觉了工具调用，或幻觉了实际返回错误的工具的成功响应。

内存和上下文漂移：在长期运行的智能体中，推理追踪积累了token。随着上下文窗口填满，智能体对原始用户意图的关注度下降。到第20步时，智能体可能在优化与用户最初要求完全无关的子任务。这在用户需求演化的多轮对话中尤其危险；智能体需要同时跟踪原始意图和修改。

理解这些故障模式不是学术性的；它直接决定了你需要什么指标以及在哪里放置评分器。只检查最终输出的评估套件会遗漏错误的工具调用。只检查工具调用的评估套件会遗漏上下文漂移。你需要分层。

4、测量真正重要的东西

并非所有指标问同样的问题。有些告诉你什么坏了。其他的告诉你为什么。还有一些告诉你智能体是否只是运气好。让我带你了解这些指标。

4.1 端到端指标

这些是你的利益相关者关心的指标。它们回答的问题是：智能体是否做了用户想要的事情？

任务完成率衡量智能体满足预期目标的程度。对于单轮智能体，这通常是二元的：会议安排了或没有安排；代码能编译或不能编译。但对于更细致的任务，你会想要连续的刻度。智能体是否预订了航班？（是/否。）是否是最便宜的航班？（部分得分）是否是用户要求的9点后出发的最便宜直飞航班？（满分）

关键洞察是任务完成应该根据用户意图而非单一黄金答案来衡量。完成任务通常有多种有效方式。

任务完成率-解释-作者图片[Vivedha Elango]

对话完整性是多轮等价物。它评估在整个对话过程中，智能体是否满足了用户的所有需求。一个客户支持智能体可能成功处理了退款（任务完成：✓），但未能解决用户关于积分的后续问题（对话完整性：部分）。这个指标通常需要基于LLM的评分，因为它涉及对对话的所有线索是否都已解决的主观判断。

4.2 组件特定指标

这些指标帮助你调试核心指标中的失败。当任务完成率下降时，组件指标告诉你原因。

参数正确性评估LLM生成有效工具参数的能力。对于追踪中的每个工具调用，你将生成的参数与预期参数进行比较。对于结构化字段（日期、ID、枚举值）可以用精确匹配测量，对于自由文本字段可以用语义相似度测量。

# 参数正确性评分器示例
def grade_tool_args(expected_args: dict, actual_args: dict) -> float:
    correct = sum(1 for k, v in expected_args.items() if actual_args.get(k) == v)
    return correct / len(expected_args)

工具召回率和精确率评估智能体的规划能力。

召回率问的是：智能体是否在执行计划中包含了所有必要的工具？如果完成任务需要调用"search_flights"、"select_seat"和"process_payment"，但智能体只调用了前两个，召回率是2/3。 精确率问的是：智能体是否避免了不必要的工具调用？如果智能体还调用了"search_hotels"和"get_weather"，而两者都不需要，这些是增加延迟、成本和出错机会的浪费调用。

高召回率低精确率意味着你的智能体做得太多。低召回率高精确率意味着它做得不够。两种模式都是可操作的。

4.3 工程可靠性指标

智能体是非确定性的。相同的输入在不同运行中可能产生不同的输出。可靠性指标量化了这种差异。

Pass@k衡量k次试验中至少一次成功的概率。它回答："如果我给智能体k次尝试，它是否至少能成功一次？"这对于理解智能体的能力上限很有用。

Pass^k（有时写作Pass-all-k）衡量所有k次试验都成功的概率。它回答："我能依赖这个智能体每次都成功吗？"这是生产环境中真正重要的指标。一个Pass@5 = 95%但Pass⁵ = 40%的智能体是有能力的但不可靠的——它能完成任务，但你不能指望它。

Pass@k和Pass^k之间的差距是智能体一致性的直接衡量。缩小这个差距通常比提高原始能力更有价值。

语义相似度指标如BERTScore或ROUGE在精确匹配指标无法捕获效用时至关重要。如果预期答案是"航班下午3:45起飞"而智能体说"您的航班在15:45出发"，精确匹配评分会失败，但语义相似度指标会正确识别它们是等价的。使用上下文嵌入的BERTScore通常比ROUGE更受青睐，因为它对释义更鲁棒。

5、构建评估流水线

理论没有实现就毫无用处。以下是如何从零开始构建评估流水线，一步一步来。

5.1 设置LLM追踪

你无法评估你无法观察的东西。在编写任何评分器之前，在智能体上实现全面的追踪。

追踪意味着将智能体执行中的每个有意义的事件记录为结构化数据。两个关键概念是：

• 跨度（Span）：单个工作单元。可以是一个LLM调用、一个工具调用、一个检索查询。每个跨度捕获输入、输出、延迟、token计数和任何错误。
• 追踪（Trace）：完整的端到端执行，由多个链接在树或DAG结构中的跨度组成。

# 追踪智能体执行的伪代码
with trace("handle_user_request", user_input=request) as t:
    with span("planner_llm_call") as s1:
        plan = llm.generate(planning_prompt)
        s1.log(output=plan, tokens=plan.usage)
    
    for tool_call in plan.tool_calls:
        with span(f"tool_{tool_call.name}") as s2:
            result = execute_tool(tool_call)
            s2.log(input=tool_call.params, output=result)
    
    with span("synthesizer_llm_call") as s3:
        response = llm.generate(synthesis_prompt)
        s3.log(output=response, tokens=response.usage)

LangSmith、Arize Phoenix、Braintrust或基于OpenTelemetry的开源替代方案等工具可以处理这种仪器化。关键要求是每个跨度都链接到其父追踪，以便在调试时重建完整的执行路径。

没有追踪，你的评估就是黑盒。有了追踪，每个失败的评估都变成可调试的工件。

5.2 选择你的评分器

评分器是评估系统的核心。你将使用以下三种类型的混合，每种都有不同的权衡：

确定性（基于代码的）评分器快速、便宜、可重现且客观。它们是你的第一道防线。

在以下情况使用它们：

• 你可以用精确逻辑定义成功（例如，"函数调用必须包含值为Y的参数X"）。
• 你在评估代码生成智能体（代码能编译吗？单元测试通过了吗？）。
• 你需要检查结构属性（有效JSON、正确模式、输出中无PII）。

def grade_tool_call(trace, expected_tool: str, expected_args: dict) -> bool:
    """确定性评分器：检查是否用正确的参数调用了正确的工具。"""
    for span in trace.spans:
        if span.type == "tool_call" and span.name == expected_tool:
            return all(span.args.get(k) == v for k, v in expected_args.items())
    return False

优势：每次评估零成本、完美可重现、无需校准。 劣势：脆弱。无法处理释义、替代有效解决方案或细致的质量判断。

基于模型的（LLM作为裁判）评分器使用单独的LLM来评估智能体的输出。它们灵活，可以处理细致的主观评估。

在以下情况使用它们：

• 成功是主观的或多维度的（例如，"响应是否乐于助人且有同理心？"）。
• 有多个有效答案，你无法全部列举。
• 你需要评估自然语言质量、连贯性或对源材料的忠实度。

JUDGE_PROMPT = """
你正在评估AI智能体的响应。
用户请求：{user_request}
智能体响应：{agent_response}
工具调用记录：{tool_calls}
请按以下维度给智能体评分（1-5分）：
1. 任务完成度：智能体是否满足了用户的请求？
2. 正确性：事实和工具调用是否准确？
3. 效率：智能体是否使用了最少的必要步骤？
以JSON格式提供评分：{"completion": X, "correctness": X, "efficiency": X}
"""

优势：灵活、可评估开放式输出、扩展性好。 劣势：非确定性（裁判本身有差异）、可能有偏差、需要校准。你必须在样本案例上验证LLM裁判与人类判断的一致性，以确保它实际测量了你认为它在测量的东西。

专业提示：使用比驱动智能体的模型更强的模型作为裁判。如果你的智能体运行在GPT-4o-mini上，使用GPT-4o或Claude Sonnet作为裁判。并且始终在裁判提示中包含评分标准——模糊的指令会产生模糊的分数。

人工参与的评分器是高风险领域的黄金标准。

在以下情况使用它们：

• 误报成本非常高（医疗、法律、金融智能体）。
• 你在校准自动化评分器（引导LLM作为裁判）。
• 你需要评估LLM也难以处理的主观品质（文化敏感性、品牌声音、情商）。

实际方法是在评估样本上使用人工评分，而不是全部。在完整套件上运行自动化评分器，然后让人审查分层样本（尤其是边界案例和失败案例）以测量评分器准确性。

5.3 构建黄金数据集

临时测试——在智能体中输入随机查询并观察发生什么——是大多数团队的起点。也是大多数团队停留的地方，也是他们的智能体在生产中崩溃的原因。

黄金数据集是20-50个高质量、无歧义任务的策划集合，代表智能体必须支持的核心能力。每个任务包括：

1. 输入：用户请求或触发器，包含所有必要上下文。
2. 预期行为：应该调用什么工具，用什么参数，按什么顺序（如果顺序重要）。
3. 预期结果：最终结果或响应，可能有多个有效变体。
4. 边缘案例分类：这是"快乐路径"测试、边缘案例还是对抗性输入？

# 黄金数据集条目示例
task_id: "flight_booking_001"
description: "预订SFO到JFK最便宜的直飞航班6月15日"
input:
  user_message: "帮我找6月15日从旧金山到纽约的最便宜直飞航班"
expected_tools:
  - name: "search_flights"
    args:
      origin: "SFO"
      destination: "JFK"
      date: "2025-06-15"
      stops: "direct"
      sort_by: "price"
expected_outcome:
  contains: ["flight", "price", "departure"]
  tool_called: true
  min_results: 1
graders:
  - type: "deterministic"
    check: "tool_args_match"
  - type: "llm_judge"
    criteria: "智能体是否清晰地呈现了最便宜的直飞选项？"
category: "happy_path"

如何构建你的黄金数据集：

1. 从产品需求开始：智能体应该具备的每项能力都应该映射到至少一个任务。
2. 包含无聊的案例：应该始终有效的简单快乐路径场景。这些成为你的回归套件。
3. 故意添加边缘案例：模糊输入、缺失信息、矛盾需求、异常格式。
4. 包含对抗性输入：提示注入、超出智能体范围的请求、操纵工具调用的尝试。
5. 版本控制它：你的黄金数据集是代码。像对待代码一样对待它。放到Git中。在PR中审查更改。

20-50个任务的神奇数字并非随意。少于20个你没有足够的覆盖率来捕获回归。超过50个套件变得昂贵且难以运行和维护（特别是如果你每任务运行多次试验并使用LLM作为裁判评分）。从20个开始，增长到50个，只有在有明确的覆盖缺口时才扩展到更多。

6、不同智能体类型的专门评估

不同的智能体架构需要不同的评估策略。以下是三种常见智能体类型的定制方法。

6.1 编码智能体

编码智能体在某种程度上是最容易评估的类别，但团队仍然会搞错。这里有一个很少被充分讨论的不公平优势：代码能运行。你不需要裁判、评分标准或语义相似度分数。你需要测试套件和终端。

失败到通过的单元测试是编码智能体的黄金标准指标。你给智能体一个失败的测试用例和代码库，智能体的工作是生成使测试通过的代码。评分器的工作就是简单地运行测试套件。它会评估"之前失败的测试现在通过了吗？之前通过的测试有被破坏吗？"

def grade_coding_agent(trace, test_suite_path: str) -> dict:
    """对智能体生成的代码运行测试套件。"""
    generated_code = extract_code_from_trace(trace)
    apply_patch(generated_code)
    
    results = run_pytest(test_suite_path)
    return {
        "target_tests_passed": results.target_pass_rate,
        "regression_tests_passed": results.regression_pass_rate,
        "syntax_valid": results.no_syntax_errors,
        "static_analysis_clean": run_linter(generated_code).is_clean
    }

静态分析补充了基于测试的评估。即使代码通过了测试，你也应该检查：

• 代码规范违规和风格不一致。
• 安全漏洞（SQL注入、硬编码密钥）。
• 性能反模式（O(n²)算法在O(n)可行时）。
• 适当的错误处理和边缘案例覆盖。

专业提示：编码智能体有时可以通过编写通过特定测试用例但不具泛化能力的代码来"作弊"。包含智能体从未见过的保留测试来衡量真正的泛化能力。

6.2 对话式智能体

对话式智能体——客户支持机器人、销售助手和治疗聊天机器人——是最难评估的，因为成功本质上是主观和多维的。

与编码智能体不同，对话式智能体面临的挑战是交互质量本身就是一个指标。评估这些系统需要衡量多维度成功。

• 工单解决了吗？（状态检查）
• 响应是否恰当？（LLM评分标准）
• 是否高效？（追踪约束，如在10轮内完成）

高级基准测试通常使用第二个LLM模拟用户角色，压力测试智能体处理沮丧或对抗性客户的能力。

真实用户会以你想象力无法预期的方式给你惊喜。但你不能等到生产流量来发现你的智能体在某人粗鲁、困惑时——或者像Taco Bell发现的那样，在有人点了18,000杯水时崩溃。模拟角色是在混乱花费你代价之前安全制造这种混乱的方式。

SIMULATED_USER_PROMPT = """
你扮演一个沮丧的客户。你的订单#12345
损坏送达。你想要全额退款，而不是换货。你不
耐烦，如果智能体在3次交流内没有解决问题
你会升级。

像这个客户一样自然回应。如果智能体满意地
解决了你的问题，说"谢谢，这样可以。"
如果你变得太沮丧，说"我要和经理谈。"
"""

6.3 研究/搜索智能体

这些智能体根据其从开放网络收集、综合和分析信息的能力进行评估。老实说，这是我见过的生产系统中最令人谦卑的失败。

想想我们真正要求这些智能体做什么。我们不只是要求它们找到信息。我们要求它们像经验丰富的调查记者一样行事：识别可信来源、交叉引用声明，并从互联网上分散的数据点构建连贯的叙述。这是一个很高的要求。

生产中真正重要的关键指标：

• 基础性：智能体的声明是否基于实际检索的来源，还是自信地产生幻觉？我见过智能体生成完全捏造的、写得很好的摘要。基础性得分迫使你严格审计声明与来源之间的联系。
• 覆盖范围：智能体是否找到了所有关键事实，还是只是容易的部分？部分检索是最危险的故障模式之一，因为对于未经训练的人来说它看起来是完整的。
• 来源质量：智能体引用的是同行评审论文还是两年前的Reddit帖子？权威来源验证是你能信任的研究助手与会自信误导你的助手之间的区别。

像**BrowseComp**这样的专门基准测试更进一步，使用大海捞针检索任务，智能体必须定位一旦找到就很容易验证但极其难以定位的高度特定信息。这是知道答案存在与知道去哪里找之间的区别。根据我的经验，这正是那种将真正有能力的智能体与在标准基准测试上碰巧运气好的智能体区分开来的对抗性评估。

评估研究智能体迫使你面对一个哲学问题：*对AI来说，真正理解某件事与仅仅检索它意味着什么？*最好的研究智能体不只是找到信息；它们知道什么时候还没有找到足够的信息。

7、生产周期的最佳实践

将智能体从有前景的演示转移到生产环境是真正工程开始的地方。我喜欢将评估视为活的需求规范——在发布前完成的检查清单，而是持续演化的文档，反映系统承诺做什么并证明它做到了。

以下是实践中的样子：

7.1 能力评估 vs 回归评估：

这个区分让我的团队避免了一些真正痛苦的生产事故。这两种类型的测试服务于根本不同的目的，混淆它们是一个常见陷阱。

能力评估是你雄心壮志的可衡量化。它们定义了你想要智能体做什么，这些评估以低通过率开始是完全健康的。低分不是失败；而是要攀登的山峰，是工程努力应该流向的信号。从30%通过率开始，看着它在六个冲刺周期内爬升到80%，是智能体开发中最令人满意的弧线之一。

回归评估是你对自己的承诺。这些覆盖智能体已经处理得很好的行为，它们应该保持接近完美的通过率。如果回归评估开始失败，说明某件事出了问题。

生命周期在其逻辑中是优雅的。随着你的能力评估成熟并通过率爬升到生产可用的水平，成功的那些毕业进入回归套件。

7.2 每次都隔离环境

这听起来很明显，直到你花了三天调试一个神秘的15%性能下降，结果发现是由前一次运行的遗留文件污染状态造成的。

每个评估试验必须从干净、隔离的环境开始。共享状态是评估可靠性的沉默杀手。缓存数据、残留文件、来自之前成功运行的git历史——这些不仅引入噪音。它们可以让智能体以难以检测的方式作弊。读取git历史来重建之前成功运行所做的事情的智能体不是在展示能力；它是在展示它有多擅长游戏化你的评估系统。

干净的环境不是开销成本。它们是让你的信号值得信赖的原因。

7.3 设计部分得分

二元通过/失败评分在确定性软件世界中有意义。在智能体工作流中，它是一个破坏信号的钝器。

考虑一个处理退款请求的支持智能体。一个正确识别客户问题、验证身份、检查购买历史，然后在最终退款步骤失败的智能体——这是一个失败吗？技术上，是的。但它与第一步就幻觉客户姓名并从此螺旋式下降的智能体是完全不同类型的失败。将两者视为等同的失败就像因为医学学生诊断正确但药物名称发音错误而让他不及格。

在设计评分器时考虑部分得分。多步骤工作流值得多维度得分。它在哪里成功了？在哪里崩溃了？这种粒度将你的评估套件从二元警报转变为诊断工具。

8、阅读追踪记录/追踪

如果我能给每个构建AI智能体的团队一条建议，那就是： 阅读追踪记录。不是偶尔。是系统性地。

自动化指标快速且可扩展，但它们可能具有深刻误导性。我见过模型因为找到了实际上是更好的创造性解决方案而"失败"评估。我也见过模型通过利用评分漏洞"通过"，同时完全遗漏了用户的真实意图。

追踪记录——智能体做了什么以及为什么的完整追踪——是真相来源。在这里你会发现失败是真正的错误还是评分逻辑的缺陷。在这里你会发现意想不到的涌现行为，无论是令人担忧的还是令人愉悦的。在这里智能体不再是黑盒，而是你真正理解的系统。

9、结束语

构建可靠的AI智能体是将"智能体感觉变差了"转化为可操作、数据驱动工程的旅程。感觉是调查的开始，不是结论。

尽早开始

我见过团队最常见的错误之一是等到有了完整的评估套件才开始测量。不要这样。你不需要数百个任务。你需要20到50个来自实际失败的简单真实世界案例来开始建立信号。

尽早开始的目的不仅仅是测量：它迫使需求清晰。在智能体能通过之前编写的评估是需求规范。它在实际构建内容中的模糊性固化成痛苦的架构决策之前就将其暴露出来。这就是评估驱动开发——就像传统软件中的测试驱动开发，它最大的礼物是迫使你尽早进行对话。

智能体评估的瑞士奶酪模型

没有单个评估层是完美的。每个方法都有漏洞——自动化评估遗漏细微差别、生产监控落后于真实失败、人工审查不能无限扩展。瑞士奶酪模型的洞察是，你不需要任何单层是完美的。你需要多个不完美层，它们的优势覆盖彼此的漏洞。

智能体性能的完整图景需要：

• 自动化评估用于快速迭代和回归捕获
• 生产监控用于大规模的真实数据
• 定期人工审查用于校准和指标无法捕获的事项

这些层共同创造了纵深防御，没有任何单一方法能单独实现。当一层的漏洞让某物通过时，另一层捕获它。

原文链接：An Engineer's Guide to Evaluating AI Agents

汇智网翻译整理，转载请标明出处