揭秘AI Agent评估：从理论到落地的完整指南

本文基于Anthropic工程实践与前沿客户合作经验，系统拆解了AI Agent评估的核心方法论、技术选型与落地路线图，是目前行业内最具实操性的Agent评估指南之一。

引言

好的评估体系能让团队更有信心地交付AI Agent。没有评估，团队很容易陷入被动循环——只能在生产环境中发现问题，而修复一个故障往往又会引发新的问题。评估能在问题影响用户之前将其暴露，并且其价值会随着Agent生命周期的推进不断累积。

正如我们在《构建高效Agent》一文中所述，Agent的运行是多轮次的：调用工具、修改状态、基于中间结果动态调整。而正是这些让Agent变得有用的特性——自主性、智能性与灵活性——也让它们的评估变得异常困难。

通过内部实践与前沿客户的合作，我们总结出了一套适用于多种Agent架构与真实部署场景的严谨、实用的评估方法。本文将分享这些经过验证的经验。

一、评估的基本结构

评估（Eval）本质上是对AI系统的测试：给AI一个输入，然后通过评分逻辑判断其输出是否符合预期。本文重点讨论无需真实用户参与、可在开发阶段自动运行的自动化评估。

• 单轮评估：结构简单，由"提示词-响应-评分逻辑"三部分组成，是早期大语言模型的主要评估方式。
• 多轮评估：随着AI能力提升逐渐成为主流，需要模拟Agent与环境/用户的多轮交互。
• Agent评估：复杂度最高，Agent会跨多轮调用工具、修改环境状态并动态适应，错误可能会传播和累积；同时前沿模型还可能找到超出静态评估预期的创造性解决方案（例如Opus 4.5曾通过发现政策漏洞解决了一个τ2-bench的航班预订问题，虽然"未通过"评估设计，但实际上给出了更好的用户解决方案）。

在构建Agent评估体系时，我们统一使用以下核心定义：

术语	定义
任务（Task）	具有明确输入和成功标准的单个测试用例
试验（Trial）	对单个任务的一次执行尝试；由于模型输出具有随机性，需运行多次试验以获得稳定结果
评分器（Grader）	对Agent表现的某个维度进行打分的逻辑；一个任务可包含多个评分器，每个评分器可包含多个断言
轨迹（Transcript/Trace）	一次试验的完整记录，包括输出、工具调用、推理过程、中间结果等所有交互
结果（Outcome）	试验结束后环境的最终状态（例如航班预订Agent的最终结果是数据库中是否存在真实预订记录，而非Agent的口头确认）
评估框架（Evaluation Harness）	端到端运行评估的基础设施，负责提供指令与工具、并发执行任务、记录步骤、评分并聚合结果
Agent框架（Agent Harness）	让模型能够作为Agent运行的系统，负责处理输入、编排工具调用并返回结果（例如Claude Code）
评估套件（Evaluation Suite）	用于测量特定能力或行为的任务集合，例如客服评估套件可能包含退款、取消、升级等场景

二、为什么必须构建评估体系？

团队在早期构建Agent时，往往可以通过手动测试、内部试用和直觉走得很远，甚至会觉得评估是拖慢交付速度的额外负担。但当Agent进入生产环境并开始规模化后，没有评估的开发模式会迅速崩溃。

崩溃点通常出现在：用户反馈Agent在更新后体验变差，但团队除了猜测和手动验证外，没有任何方法可以客观确认。没有评估，调试完全是被动的：等待用户投诉→手动复现→修复bug→祈祷没有引入新的回归问题。团队无法区分真实的性能下降与随机噪声，无法在发布前自动测试数百种场景，也无法量化改进效果。

我们见过无数次这样的发展历程：

• Claude Code最初基于员工和外部用户的反馈快速迭代，后来逐步添加了针对简洁性、文件编辑、过度工程化等维度的评估，这些评估帮助我们识别问题、指导改进并聚焦研究与产品的协作方向。
• Descript的视频编辑Agent围绕"不破坏现有功能、完成用户指令、高质量完成"三个维度构建评估，从人工评分逐步演进为带产品团队定义标准的LLM评分，并定期进行人工校准，现在运行两套独立的评估套件分别用于质量基准测试和回归测试。
• Bolt AI团队在Agent已经广泛使用后才开始构建评估体系，仅用3个月就搭建了完整系统：通过静态分析评分代码输出、使用浏览器Agent测试应用、利用LLM评分器评估指令遵循等行为。

评估在Agent生命周期的任何阶段都有价值：

• 早期：强制产品团队明确定义"成功"的标准，消除不同人对需求理解的歧义。
• 中期：提供基线和回归测试，自动跟踪延迟、Token用量、单任务成本、错误率等指标。
• 后期：加速新模型的采用——没有评估的团队需要数周测试新模型，而有完善评估的团队可以在几天内完成模型能力评估、提示词调优和升级。

评估还是产品团队与研究团队之间最高效的沟通渠道，它明确定义了研究人员可以优化的指标。其价值是复利式的：前期投入成本可见，但收益会随着时间不断累积。

三、AI Agent的核心评估方法

目前大规模部署的Agent主要包括编码Agent、研究Agent、计算机使用Agent和对话Agent四类。虽然应用行业各不相同，但它们可以使用相似的评估技术。

3.1 三种核心评分器类型

有效的评估设计核心是为不同任务选择合适的评分器组合。Agent评估通常结合以下三种类型：

评分器类型	常用方法	优势	劣势
基于代码的评分器	字符串匹配（精确/正则/模糊）、二进制测试、静态分析（lint/类型/安全）、结果验证、工具调用验证、轨迹分析	速度快、成本低、客观、可复现、易于调试、可验证特定条件	对符合预期的有效变体过于脆弱、缺乏细微差别的判断能力、不适合主观任务
基于模型的评分器	基于评分标准的打分、自然语言断言、成对比较、基于参考的评估、多评委共识	灵活、可扩展、能捕捉细微差别、处理开放式任务和自由格式输出	非确定性、比代码评分器成本高、需要与人工评分校准以保证准确性
人工评分器	领域专家评审、众包判断、抽样检查、A/B测试、标注者间一致性	金标准质量、符合专家用户判断、可用于校准基于模型的评分器	成本高、速度慢、通常需要大规模获取领域专家

对于每个任务，评分方式可以是：

• 加权式：多个评分器的综合得分达到阈值即通过
• 二进制式：所有评分器必须全部通过
• 混合式：结合上述两种方式

3.2 能力评估 vs 回归评估

这是两种完全不同目标的评估类型，必须明确区分：

• 能力评估（质量评估）：回答"这个Agent擅长做什么？"，初始通过率应该较低，聚焦于Agent目前难以完成的任务，为团队提供需要攻克的目标。
• 回归评估：回答"这个Agent是否还能处理它以前能处理的所有任务？"，通过率应该接近100%，用于防止性能倒退。

当能力评估的通过率变得很高时，可以将其"升级"为回归套件，持续运行以检测任何性能漂移。曾经衡量"我们能否做到这件事"的任务，会变成衡量"我们能否可靠地做到这件事"的任务。

3.3 不同类型Agent的评估实践

编码Agent评估

编码Agent会像人类开发者一样编写、测试、调试代码，导航代码库并运行命令。有效的编码Agent评估依赖于明确的任务定义、稳定的测试环境和全面的生成代码测试。

确定性评分器是编码Agent的天然选择：软件是否运行、测试是否通过是明确的二进制结果。SWE-bench Verified和Terminal-Bench是两个广泛使用的编码Agent基准测试：

• SWE-bench Verified：给Agent提供流行Python仓库的GitHub Issue，通过运行测试套件来评分解决方案，只有修复了失败测试且不破坏现有功能的解决方案才算通过。过去一年，大模型在该基准上的通过率从40%提升到了80%以上。
• Terminal-Bench：测试端到端技术任务，例如从源码编译Linux内核、训练机器学习模型。

除了验证最终结果的单元测试外，还可以对轨迹进行评分：例如基于启发式的代码质量规则、评估工具调用方式的LLM评分标准等。

编码Agent评估示例（YAML）

task:
  id: "fix-auth-bypass_1"
  desc: "修复密码字段为空时的身份验证绕过漏洞..."
  graders:
    - type: deterministic_tests
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
    - type: llm_rubric
      rubric: prompts/code_quality.md
    - type: static_analysis
      commands: [ruff, mypy, bandit]
    - type: state_check
      expect:
        security_logs: {event_type: "auth_blocked"}
    - type: tool_calls
      required:
        - {tool: read_file, params: {path: "src/auth/*"}}
        - {tool: edit_file}
        - {tool: run_tests}
  tracked_metrics:
    - type: transcript
      metrics: [n_turns, n_toolcalls, n_total_tokens]
    - type: latency
      metrics: [time_to_first_token, output_tokens_per_sec, time_to_last_token]

对话Agent评估

对话Agent用于客服、销售、教练等领域，与传统聊天机器人不同，它们会维护状态、使用工具并在对话中采取行动。对话Agent的独特挑战在于：交互质量本身就是评估的一部分。

有效的对话Agent评估通常结合可验证的最终状态结果，以及同时捕捉任务完成度和交互质量的评分标准。与其他评估不同，对话Agent评估通常需要第二个LLM来模拟用户（我们在对齐审计Agent中使用这种方法，通过扩展的对抗性对话对模型进行压力测试）。

对话Agent的成功是多维度的：工单是否解决（状态检查）、是否在10轮内完成（轨迹约束）、语气是否合适（LLM评分）。τ-Bench和τ2-Bench是两个多维度对话评估基准，它们模拟零售支持、航班预订等领域的多轮交互，一个模型扮演用户角色，另一个作为Agent处理真实场景。

对话Agent评估示例（YAML）

graders:
  - type: llm_rubric
    rubric: prompts/support_quality.md
    assertions:
      - "Agent对客户的沮丧情绪表示了共情"
      - "解决方案得到了清晰解释"
      - "Agent的回复基于fetch_policy工具的结果"
  - type: state_check
    expect:
      tickets: {status: resolved}
      refunds: {status: processed}
  - type: tool_calls
    required:
      - {tool: verify_identity}
      - {tool: process_refund, params: {amount: "<=100"}}
      - {tool: send_confirmation}
  - type: transcript
    max_turns: 10
tracked_metrics:
  - type: transcript
    metrics: [n_turns, n_toolcalls, n_total_tokens]
  - type: latency
    metrics: [time_to_first_token, output_tokens_per_sec, time_to_last_token]

研究Agent评估

研究Agent负责收集、综合和分析信息，生成答案或报告。与编码Agent不同，研究质量只能相对于任务来判断：“全面”、“来源可靠”、"正确"的定义取决于具体场景（市场调研、收购尽职调查、科学报告各有不同标准）。

研究评估面临独特挑战：专家可能对综合结果是否全面存在分歧、参考内容不断变化导致基准漂移、更长的开放式输出带来更多错误空间。BrowseComp是一个研究Agent基准，测试AI Agent能否在开放网络中找到特定信息。

构建研究Agent评估的有效策略是结合多种评分器：

• 真实性检查：验证声明是否有检索到的来源支持
• 覆盖率检查：定义好的答案必须包含的关键事实
• 来源质量检查：确认使用的来源是权威的
• 对于有客观正确答案的任务，使用精确匹配
• 使用LLM检查未支持的声明、覆盖范围差距以及综合结果的连贯性和完整性

由于研究质量的主观性，基于LLM的评分标准需要经常与专家人工判断进行校准。

计算机使用Agent评估

计算机使用Agent通过与人类相同的界面（截图、鼠标点击、键盘输入、滚动）与软件交互，而不是通过API或代码执行。它们可以使用任何带有图形界面的应用程序，从设计工具到遗留企业软件。

评估计算机使用Agent需要在真实或沙盒环境中运行Agent，并检查其是否达到预期结果：

• WebArena：测试基于浏览器的任务，使用URL和页面状态检查验证导航正确性，对于修改数据的任务还需要后端状态验证（确认订单确实已提交，而不仅仅是显示了确认页面）。
• OSWorld：扩展到完整操作系统控制，评估脚本会在任务完成后检查各种工件：文件系统状态、应用配置、数据库内容、UI元素属性。

浏览器使用Agent需要在Token效率和延迟之间取得平衡：基于DOM的交互执行速度快但消耗大量Token，基于截图的交互速度较慢但Token效率更高。我们在Claude for Chrome产品中开发了评估，检查Agent是否为每个上下文选择了正确的工具，这使我们能够更快、更准确地完成基于浏览器的任务。

3.4 处理评估中的非确定性

无论哪种类型的Agent，其行为在不同运行之间都会存在差异，这使得评估结果的解读比表面上更复杂。每个任务都有自己的成功率，一次通过的任务可能在下一次运行中失败。我们真正需要测量的是Agent在一个任务上成功的概率。

两个关键指标可以捕捉这种细微差别：

• pass@k：衡量Agent在k次尝试中至少获得一个正确解决方案的可能性。k越大，pass@k得分越高。在编码场景中，我们通常最关心pass@1（第一次尝试就成功）；在其他场景中，只要有一个解决方案有效，提出多个方案也是可以接受的。
• **pass^{k**：衡量所有k次试验都成功的概率。k越大，pass}k得分越低。这个指标对于面向用户的Agent尤为重要，因为用户期望每次都能获得可靠的行为。

例如，如果一个Agent的单次试验成功率为75%，运行3次试验：

• pass@3 ≈ 98.4%（至少有一次成功的概率）
• pass^3 ≈ 42.2%（三次都成功的概率）

选择哪个指标取决于产品需求：对于工具类产品，一次成功就足够，使用pass@k；对于需要高可靠性的面向用户产品，使用pass^k。

四、从零到一构建评估体系的路线图

这是我们经过实践验证的、从无到有构建可信评估体系的分步指南，遵循"评估驱动开发"的理念：提前定义成功标准，然后持续迭代直到Agent达到要求。

步骤0：尽早开始

不要等到有数百个任务才开始构建评估。实际上，从真实故障中提取的20-50个简单任务就是一个很好的起点。在Agent开发早期，系统的每次变化都会产生明显的影响，大的效应量意味着小样本量就足够了。

评估越晚构建越困难：早期产品需求可以自然转化为测试用例，而等待太久后，你将不得不从一个正在运行的系统中反向工程成功标准。

步骤1：从你已经在手动测试的内容开始

从开发过程中你已经在运行的手动检查开始——每次发布前验证的行为、终端用户经常尝试的常见任务。如果你已经在生产环境中运行，查看你的bug跟踪器和支持队列。将用户报告的故障转化为测试用例，确保你的评估套件反映真实的使用情况；按用户影响优先级排序，将精力投入到最重要的地方。

步骤2：编写明确的任务和参考解决方案

任务质量是评估的基础。一个好的任务应该是：两个领域专家能够独立得出相同的通过/失败结论。如果专家自己都无法通过这个任务，那么任务需要改进。任务描述中的任何歧义都会变成指标中的噪声。

每个任务都应该可以被遵循指令的Agent正确完成。我们发现，0%的通过率（即使运行100次试验）通常是任务本身有问题的信号，而不是Agent能力不足。常见问题包括：模糊的任务描述、评分器假设了任务中未说明的条件、环境配置错误。

为每个任务创建一个参考解决方案：一个已知可以通过所有评分器的正确输出。这证明了任务是可解的，并验证了评分器的配置是正确的。

步骤3：构建平衡的问题集

同时测试"应该发生某种行为"和"不应该发生某种行为"的情况。片面的评估会导致片面的优化：例如，如果你只测试Agent是否在应该搜索时进行搜索，你最终会得到一个几乎对所有问题都进行搜索的Agent。

我们在构建Claude.ai的网络搜索评估时亲身体验了这一点。挑战在于防止模型在不应该搜索时搜索，同时保留其在需要时进行广泛研究的能力。我们构建了双向评估：模型应该搜索的查询（如查询天气）和模型应该从现有知识回答的查询（如"谁创立了苹果？"）。在提示词和评估上经过多轮改进后，我们才找到了触发不足和过度触发之间的正确平衡。

步骤4：构建具有稳定环境的健壮评估框架

评估中的Agent应该与生产环境中的Agent运行方式基本相同，并且环境本身不应引入额外的噪声。每次试验都应该从一个干净的环境开始，运行之间的不必要共享状态（遗留文件、缓存数据、资源耗尽）会导致基础设施不稳定引起的相关故障，而不是Agent性能问题。

共享状态还可能人为地提高性能：例如，在一些内部评估中，我们发现Claude通过检查先前试验的git历史获得了不公平的优势。如果多个不同的试验因为环境的相同限制（如有限的CPU内存）而失败，那么这些试验不是独立的，评估结果对于衡量Agent性能是不可靠的。

步骤5：精心设计评分器

我们建议：尽可能使用确定性评分器，必要时使用LLM评分器以获得灵活性，谨慎使用人工评分器进行额外验证。

一个常见的误区是检查Agent是否遵循了非常具体的步骤（如特定顺序的工具调用）。我们发现这种方法过于僵化，会导致测试非常脆弱——Agent经常会找到评估设计者没有预料到的有效方法。为了不不必要地惩罚创造性，通常更好的做法是评分Agent产生了什么，而不是它采取了什么路径。

对于具有多个组件的任务，引入部分评分。一个正确识别问题并验证客户身份但未能处理退款的客服Agent，明显比一开始就失败的Agent表现更好。在结果中体现这种成功的连续性很重要。

模型评分需要仔细迭代以验证准确性。LLM作为评委的评分器应该与人类专家密切校准，以确保人类评分和模型评分之间几乎没有分歧。为了避免幻觉，给LLM一个"退出"选项，例如当没有足够信息时返回"未知"。创建清晰、结构化的评分标准来评估任务的每个维度，然后使用独立的LLM评委对每个维度进行评分，而不是使用一个评委来评分所有维度。

步骤6：检查轨迹

除非你阅读了大量试验的轨迹和评分，否则你不会知道你的评分器是否工作良好。在Anthropic，我们投入了大量工具来查看评估轨迹，并定期花时间阅读它们。当一个任务失败时，轨迹会告诉你是Agent真的犯了错误，还是你的评分器拒绝了一个有效的解决方案。

失败应该看起来是公平的：应该清楚Agent哪里做错了以及为什么。当分数没有提升时，我们需要有信心这是由于Agent的性能，而不是评估本身的问题。阅读轨迹是验证你的评估是否在衡量真正重要的事情的方法，也是Agent开发的一项关键技能。

步骤7：监控评估饱和

一个通过率达到100%的评估只能跟踪回归，不能提供任何改进信号。当Agent通过了所有可解的任务时，就会发生评估饱和，此时没有进一步改进的空间。

例如，SWE-Bench Verified的分数今年从30%开始，现在前沿模型已经接近80%的饱和点。随着评估接近饱和，进展也会放缓，因为只剩下最困难的任务。这可能会使结果具有欺骗性，因为巨大的能力提升可能只表现为分数的小幅增加。

作为一项规则，在有人深入研究评估细节并阅读一些轨迹之前，我们不会表面上接受评估分数。如果评分不公平、任务模糊、有效解决方案被惩罚或框架限制了模型，那么评估应该被修订。

步骤8：通过开放贡献和维护保持评估套件的长期健康

评估套件是一个活的工件，需要持续的关注和明确的所有权才能保持有用。

在Anthropic，我们尝试了各种评估维护方法。最有效的方法是：建立专门的评估团队来拥有核心基础设施，而领域专家和产品团队贡献大部分评估任务并自己运行评估。

对于AI产品团队来说，拥有和迭代评估应该像维护单元测试一样常规。团队可能会在早期测试中"工作正常"的AI功能上浪费数周时间，但这些功能实际上无法满足一个设计良好的评估本应提前揭示的未明确期望。定义评估任务是压力测试产品需求是否足够具体以开始构建的最佳方法之一。

我们建议实践评估驱动开发：在Agent能够实现计划的能力之前构建评估来定义这些能力，然后迭代直到Agent表现良好。在内部，我们经常构建今天"足够好"但押注未来几个月模型能力的功能。初始通过率较低的能力评估使这一点变得可见。当新模型发布时，运行评估套件会迅速揭示哪些押注得到了回报。

五、评估与其他方法的结合

自动化评估可以在数千个任务上运行Agent，而无需部署到生产环境或影响真实用户。但这只是理解Agent性能的众多方法之一。一个完整的图景还包括生产监控、用户反馈、A/B测试、手动轨迹审查和系统的人工评估。
就像安全工程中的瑞士奶酪模型一样，没有单一的评估层能捕捉到所有问题。通过结合多种方法，穿过一层的失败会被另一层捕捉到。

方法	优势	劣势
自动化评估	迭代速度快、完全可复现、无用户影响、可在每次提交时运行、无需生产部署即可大规模测试场景	需要前期投入构建、需要持续维护以避免漂移、如果与真实使用模式不匹配可能产生虚假信心
生产监控	揭示大规模真实用户行为、捕捉合成评估遗漏的问题、提供Agent实际表现的真实数据	被动；问题在被发现前已经影响用户、信号可能有噪声、需要投入工具建设、缺乏评分的真实依据
A/B测试	衡量实际用户结果（留存、任务完成率）、控制混杂因素、可扩展且系统化	速度慢；需要数天或数周才能达到显著性且需要足够流量、只能测试你部署的更改、无法深入了解指标变化的"原因"
用户反馈	揭示你没有预料到的问题、来自真实人类用户的实际例子、通常与产品目标相关	稀疏且自我选择、偏向严重问题、用户很少解释为什么失败、不是自动化的、主要依赖用户发现问题会产生负面用户影响
手动轨迹审查	建立对故障模式的直觉、捕捉自动化检查遗漏的细微质量问题、帮助校准"好"的标准并掌握细节	耗时、不可扩展、覆盖不一致、评审者疲劳或不同评审者会影响信号质量、通常只提供定性信号而非明确的定量评分
系统人工研究	来自多个训练有素的评审者的金标准质量判断、处理主观或模糊任务、为改进基于模型的评分器提供信号	相对昂贵且周转时间慢、难以频繁运行、标注者间分歧需要协调、复杂领域需要人类专家

这些方法适用于Agent开发的不同阶段：

• 自动化评估：在发布前和CI/CD中特别有用，作为防止质量问题的第一道防线，在每次Agent更改和模型升级时运行。
• 生产监控：在发布后启动，检测分布漂移和未预料到的真实世界故障。
• A/B测试：在你有足够流量后验证重大更改。
• 用户反馈和轨迹审查：持续进行以填补空白：持续分类反馈，每周抽样阅读轨迹，并根据需要深入挖掘。
• 系统人工研究：保留用于校准LLM评分器或评估主观输出，其中人类共识作为参考标准。

最有效的团队会结合这些方法：自动化评估用于快速迭代，生产监控用于真实数据，定期人工审查用于校准。

结论

没有评估的团队会陷入被动循环——修复一个故障，制造另一个故障，无法区分真实的回归和噪声。而早期投资评估的团队会发现相反的情况：随着故障变成测试用例，测试用例防止回归，指标取代猜测，开发速度会加快。评估给整个团队一个明确的目标，将"Agent感觉更糟了"变成可操作的问题。

评估的价值是复利式的，但只有当你将其视为核心组件而非事后想法时才能实现。虽然模式因Agent类型而异，但本文描述的基本原则是不变的：

1. 尽早开始，不要等待完美的套件
2. 从你看到的真实故障中提取现实任务
3. 定义明确、健壮的成功标准
4. 精心设计评分器并结合多种类型
5. 确保问题对模型来说足够困难
6. 持续迭代评估以提高信噪比
7. 一定要阅读轨迹！

AI Agent评估仍然是一个新兴、快速发展的领域。随着Agent承担更长的任务、在多Agent系统中协作以及处理越来越主观的工作，我们将需要调整我们的技术。我们将继续分享我们学到的最佳实践。

附录：常用评估框架

以下是一些可以帮助团队无需从零开始构建基础设施的开源和商业评估框架，选择取决于你的Agent类型、现有技术栈以及你需要离线评估、生产可观测性还是两者兼有：

• Harbor：专为在容器化环境中运行Agent设计，提供跨云提供商大规模运行试验的基础设施，以及定义任务和评分器的标准化格式。Terminal-Bench 2.0等流行基准通过Harbor注册表发布，使运行已建立的基准和自定义评估套件变得容易。
• Braintrust：结合了离线评估、生产可观测性和实验跟踪的平台，适合既需要在开发期间迭代又需要在生产中监控质量的团队。其autoevals库包含用于事实性、相关性等常见维度的预构建评分器。
• LangSmith：提供跟踪、离线和在线评估以及数据集管理，与LangChain生态系统紧密集成。
• Langfuse：作为自托管开源替代方案，提供类似的功能，适合有数据驻留要求的团队。
• Arize：提供开源平台Phoenix用于LLM跟踪、调试和离线/在线评估，以及SaaS产品AX用于扩展、优化和监控。

许多团队会结合多个工具，或者自己构建评估框架，或者从简单的评估脚本开始。我们发现，虽然框架可以加速进展和标准化，但它们的好坏取决于你通过它们运行的评估任务。通常最好快速选择一个适合你工作流程的框架，然后将精力投入到评估本身，通过迭代高质量的测试用例和评分器来获得最大价值