借助旅行机器人对代理进行评估：结果与轨迹、门控机制以及pass^k。

智能体不仅会调用 API，还会进行推理、即时选择工具、制定多步骤计划，从而处理那些过去需要人类花费数小时才能完成的任务。然而，一旦这些智能体投入实际使用，一个棘手的问题就会出现：如何确定它们确实能正常工作？

不是通过今天最常用的演示指令，而是等到下周，当有人修改了系统指令、添加了新工具、更换了底层模型或调整了提示词之后。这样的改动是否解决了某个问题，却悄悄破坏了另外三个功能？

普通软件拥有确定性的单元测试，比如 assert add(2, 2) == 4。而智能体是概率性的，可能会通过不同的路径达成相同目标，因此仅对最终输出文本进行字符串比较是远远不够的。智能体评估机制正好弥补了这一缺陷。

数学考试的类比

想象一位老师只看最终分数来批改考试，这样会出现两个问题：

1. 幸运的猜测。其计算过程毫无逻辑，两次算术错误相互抵消，结果恰好正确。
2. 最后一步的错误。方法本身完美无缺，定理也理解正确，但最后出现拼写错误，本应写42的地方却写成了41。

优秀的教师会同时评价方法和答案。智能体也应得到同样的评价标准，因为智能体会执行一系列操作：调用工具、进行搜索、处理格式化数据以及做出状态决策。公平评价意味着需要考量两方面的内容：

• 结果：它所带来的业务成果。
• 路径：它达成该结果所经历的流程。

简而言之，智能体评估就是结果评估与路径评估的结合，通过硬性代码检查与灵活的判断标准在同一测试中共同完成评估。

评分的两个维度

任何智能体都可以从两个独立的维度进行评估。

评估什么？

• 结果检查旨在确认是否存在正确的最终结果，例如正确的航班、合适的酒店价格或准确的预订记录。
• 流程检查则着眼于智能体是否以可靠的方式达成目标：工具是否按合理顺序被调用、参数是否有效、是否存在无限循环。

如何评分？

• 确定性检查针对那些有明确客观答案的问题。价格要么是150美元，要么不是；某个工具要么被调用过，要么没有。简单的代码断言可用于处理这类问题。

基于判断的核查涵盖所有需要上下文、意图或细微差别的情况。比如“budget”是否被误理解为“economy”？所选的酒店是否符合用户的真实需求？由人工智能模型担任中立评估者来对这些进行评分。

实际案例：旅游预订代理

以负责规划行程的代理为例。用户的需求是：廉价的航班、在纽约住三晚的酒店以及从机场到市区的接送服务。为此，它可能会使用名为search_flights、search_hotels、book_flight、book_hotel和book_airport_transfer的工具。

轨迹指标会读取执行日志、调用顺序、工具参数以及推理过程。常见的问题包括：它在采取行动前是否制定了计划？搜索是在预订之前进行的吗？酒店的日期与航班日期是否一致？它是否避免了不必要的重复调用？

结果指标则用于检查代理实际创建的预订信息：票价、每晚费用、交通方式、货币类型以及日期。

平均分之前的筛选条件

有一个往往需要付出惨痛代价才能领悟的教训：并非所有指标都适合纳入平均分计算。想象这样一种代理，由于出色的推理能力和完美的工具使用顺序而获得了95%的总体评分，但却以1,500美元而非150美元的价格预订了航班。在实际应用中，这绝不能被视为优秀的表现，而是一场严重的计费灾难。

为避免高推理分数掩盖业务上的关键缺陷，评估可分两个阶段进行。

第一阶段：关卡检测。首先对价格、日期、货币、计费标识及费用触发条件等关键字段进行确定性检查。若任何关卡检测失败，整个测试立即判定为不合格，再好的推理也无法改变这一结果。

第二阶段：加权评分。只有通过所有关卡的测试才能获得质量分数，该分数是根据工具效率、推理质量、计划遵循程度及语义匹配度等其余指标综合计算得出的。规则很简单：通过所有关卡且加权分数达到或超过阈值（例如0.85），则视为合格。

利用2×2矩阵诊断故障

仅凭“82%的通过率”无法为调试提供任何有用信息。你需要知道运行失败的原因，这样才能决定是修复提示词、工具还是数据集。将结果与执行路径对应起来，就会出现四个象限：

• 路径正确且结果良好：达到目标。
• 路径错误但结果良好：纯属运气使然，未来仍存在风险。
• 路径正确但结果不佳：最后阶段出现问题，通常是由工具或数据导致的。
• 路径错误且结果不佳：存在根本性缺陷，需要重新处理。

端到端的追踪

以下是该流程如何处理预订代理的一次尝试。它从用户的请求和代理的追踪记录开始，首先制定计划（搜索航班、搜索酒店、同时预订两者、添加接送服务），然后按顺序记录每一个思考过程和工具调用。

// Step 1: Upfront Plan Formulation
Thought: "I need to book budget travel to NYC for 3 days. Plan: 1) Search economy flights, 2) Search budget hotels in NYC, 3) Book flight, 4) Book hotel for matching dates, 5) Book airport transfer."

// Step 2: Tool Call - search_flights
→ call: search_flights({ origin: "SFO", destination: "JFK", cabin_class: "economy", date: "2026-10-10" })
← return:
[
  {
    flight_id: "fl_eco_9921",
    airline: "BudgetAir",
    price: 150.00
  }
]

// Step 3: Tool Call - search_hotels
→ call: search_hotels({ city: "New York", checkin: "2026-10-10", nights: 3, max_rate: 150 })
← return:
[
  {
    hotel_id: "ht_manhattan_pod",
    name: "Pod Midtown NYC",
    rate_per_night: 120.00
  }
]

// Step 4: Tool Call - book_flight
→ call: book_flight({ flight_id: "fl_eco_9921", passenger: "Chris Dias", price: 150.00 })
← return:
{
  booking_ref: "BK-FL-7701",
  status: "confirmed"
}

// Step 5: Tool Call - book_hotel
→ call: book_hotel({ hotel_id: "ht_manhattan_pod", nights: 3, rate_per_night: 120.00, guest: "Chris Dias" })
← return:
{
  reservation_id: "RSV-HT-8832",
  status: "confirmed"
}

// Step 6: Tool Call - book_airport_transfer
→ call: book_airport_transfer({ pickup: "JFK", dropoff: "Pod Midtown NYC", fee: 35.00 })
← return:
{
  ride_id: "TX-4402",
  status: "confirmed"
}

// Step 7: Final Synthesized Output Payload
Final Output:
{
  flight: {
    id: "fl_eco_9921",
    cabin: "economy",
    price: 150.00,
    status: "confirmed"
  },
  hotel: {
    id: "ht_manhattan_pod",
    nights: 3,
    rate_per_night: 120.00,
    status: "confirmed"
  },
  transfer: {
    service: "JFK Pickup Shuttle",
    fee: 35.00,
    status: "confirmed"
  },
  total_billed: 545.00
}

接下来，评估系统会检查那些对任务至关重要的字段：航班价格、每晚酒店费用以及接送费用。假设这三项的数值分别符合150美元、每晚120美元和35美元的预期值，那么评估就会通过，测试将进入第二阶段。

在第二阶段，每个剩余的指标都会被赋予0到1之间的分数，再乘以相应的权重，所有权重的总和为1。举例来说，假设五个指标的权重分别为0.20、0.20、0.15、0.15和0.30，对应的分数分别为1.0、1.0、0.8、1.0和0.95，那么加权后的总分为0.20 + 0.20 + 0.12 + 0.15 + 0.285，即0.955。由于事先设定的阈值是0.85，因此该测试通过。

最终结果会记录三个事实：评估通过了、加权分数超过了阈值，且诊断矩阵将此次测试归类为“良好路径、良好结果”的类别。

使用pass@k和pass^k衡量方差

单次测试无法反映全部情况，因为智能体具有非确定性。十分钟后使用相同的工具和提示词进行测试时，模型可能会先搜索酒店、以不同的方式组织论据或沿另一条逻辑链推理。今天通过测试的模型，在完全相同的输入下明天也可能失败。

Anthropic关于智能体评估的工程文档中提到了两种用于控制这种差异性的统计指标：pass@k和pass^k。

pass@k：能力指标

该指标衡量的是在k次独立尝试中是否至少有一次成功。随着k值的增加，得分也会上升，因为更多的尝试会增加成功的概率。这一指标因OpenAI在代码生成领域的HumanEval项目而广为人知，在该项目中，系统会生成多个候选程序并检查其中是否有通过单元测试的。

它适用于需要人工干预的架构以及带有自动验证功能的系统：可为旅行经理提供三个行程草案供其选择，或给出五个SQL查询候选方案，由引擎自动运行第一个有效的查询。

pass^k：一致性

这是指该代理在k次尝试中每次都能成功的概率，即单次试验成功率p的k次方。随着k值的增大，该数值会迅速下降。假设该代理在单次试验中的成功率为75%：

• 仅尝试1次：75.0%，
• 连续尝试3次：约42.2%，
• 连续尝试5次：约23.7%，
• 连续尝试10次：约5.6%。

这就是用于自主化、关键任务型生产环境的标准。当预订代理与支付卡及服务提供商的API相连时，用户并不在乎它可能每五次才成功一次，他们需要的是每次都能稳定运行。

为何选择很重要

当 k 等于 1 时，这两个指标完全相同，都等于基础成功率。而当 k 达到 10 时，它们则呈现出截然不同的情况：pass@k 的值会趋向 100%，因为足够的尝试最终必然能取得成功；而 pass^k 的值则会趋向零，因为要连续十次毫无错误、没有幻觉或工具故障地完成任务实属困难。选择与产品承诺相匹配的指标，才能区分表面上的基准数据与真正的可靠性。

实用建议

1. 不要只测试最终结果。那些通过错误推理得出正确答案的智能体会带来实际应用风险。
2. 结合代码与大型语言模型进行评估。对于价格、编号和存在性检查，使用确定性代码；而对于推理质量、计划遵循程度以及意图匹配，则由大型语言模型来评估。

确保绝对不会出错。精妙的推理机制不应让错误的价格、劣质的货币或无效的日期影响整体结果。

将评估视为持续集成流程。每当提示词或模型发生变化时都运行整套测试，以便在用户发现问题之前就捕捉到异常。

可靠的智能体并非依赖模型今天的表现，而是依靠每日都会进行检查的机制来保证其正常运行。