解密 AI Agent 的评估方法

引言

有效的评估让团队能够更自信地部署 AI Agent。没有评估，组织会陷入被动循环——只在生产部署后才发现问题，修复一个问题可能引发其他问题。评估能在用户遇到问题之前暴露问题和行为变化，在 Agent 的整个生命周期中带来复利收益。

正如在"构建有效的 Agent"中所讨论的，Agent 跨越多轮操作：执行工具、调整内部状态、响应中间结果。让 Agent 有价值的特性——自主性、推理能力和适应性——同时也增加了评估的复杂性。

通过内部开发和与前沿客户的合作，Anthropic 完善了为 Agent 设计严谨、实用评估的方法。本指南分享了在不同 Agent 架构和真实部署场景中经过验证的策略。

评估的结构

评估通过提供输入并对输出应用评分逻辑来测试 AI 系统。本文聚焦于自动化评估——可在开发过程中执行，无需真实用户参与。

单轮评估很基础：提示词、响应、评分标准。传统的大语言模型评估主要是单轮非 Agent 式评估。随着能力提升，多轮评估变得越来越普遍。

Agent 评估引入了额外的复杂性。Agent 在多轮中利用工具，持续改变环境状态并适应——这使错误能够叠加。先进的模型可以想出超出静态评估边界的创意解决方案。例如，Opus 4.5 在处理 tau2-bench 航班预订场景时发现了一个政策漏洞，技术上"未通过"规定的评估，但为用户带来了更好的结果。

关键定义

一个任务（也称为问题或测试用例）代表具有指定输入和成功标准的单个测试。

一次试验构成对任务的一次尝试。由于模型输出在多次运行中会波动，执行多次试验能产生更稳定的结果。

一个评分器实现了评估 Agent 某些方面表现的逻辑。任务可以使用多个评分器，每个评分器包含多个断言（有时称为检查）。

一个记录（也称为轨迹或路径）记录了试验的完整过程：输出、工具调用、推理、中间结果和交互。对于 Anthropic 的 API，这包括评估完成时的完整 messages 数组——评估过程中的所有 API 调用和响应。

结果代表试验后的最终环境状态。航班预订 Agent 可能在其记录中声明"您的航班已预订"，但结果反映环境数据库中是否存在实际预订。

一个评估框架提供端到端评估执行的基础设施。它提供指令和工具、并发执行任务、记录所有步骤、生成分数并汇总结果。

一个Agent 框架（或脚手架）构成让模型作为 Agent 运作的系统：处理输入、引导工具调用、交付结果。评估"一个 Agent"时，你检查的是框架和模型的协同工作。Claude Code 是一个灵活的 Agent 框架示例；其基础组件通过 Agent SDK 支撑了"长时间运行的 Agent 框架"。

一个评估套件包含针对特定能力或行为的任务。套件任务通常追求共同目标——客户支持评估可能评估退款、取消和升级。

为什么要构建评估？

早期阶段的 Agent 构建者通过手动测试、自我使用和直觉取得了惊人的进展。形式化评估可能看起来是限制交付速度的开销。然而，一旦 Agent 进入生产并扩展，没有评估的开发就变得不可持续。

关键时刻出现在用户报告修改后 Agent 性能下降，而团队除了试错之外没有验证方法。没有评估，故障排查变成被动的：收集投诉、手动复现问题、实施修正，并希望没有造成附带损害。团队无法可靠地区分实际回归和统计噪声，无法在部署前针对数百个场景系统测试修改，也无法量化改进。

这种轨迹频繁重复。Claude Code 展示了这种模式：由 Anthropic 和外部用户反馈驱动的快速迭代先于正式评估。随后，针对性的评估出现了——最初针对简短性和文件修改等狭窄领域，后来扩展到过度工程等复杂行为。这些评估暴露了问题、指导了增强，并同步了研究-产品协作。与生产监控、对比测试、用户调查和其他方法相结合，评估为 Claude Code 的持续增强和扩展提供了信号。

早期评估开发在 Agent 生命周期中证明是有益的。最初，评估推动产品团队明确 Agent 的成功标准。后来，它们维持一致的质量阈值。

Descript 的视频编辑 Agent 围绕三个评估维度构建：维护现有功能、执行请求的任务、交付高质量结果。演进从手动评估发展到由产品规格和定期人工校准指导的基于 LLM 的评分，现在运行着独立的质量和回归测试框架。Bolt 的团队在大量用户采用后整合了评估，在三个月内完成了综合评估框架，利用静态分析、基于浏览器的测试和 LLM 判断来评估指令遵循。

团队遵循不同的评估实施时间表。有些在初始开发期间建立评估；其他则在扩展揭示评估成为开发瓶颈后引入。早期采用需要明确的行为规范，消除工程师之间的解释差异。无论实施时机如何，评估都能加速开发。

评估还影响模型采用速度。新出现的强大模型迫使没有评估的团队投入数周验证，而使用评估的竞争对手则能快速识别模型优势、定制提示词，并在数天内完成切换。

现有评估自动提供基线和回归监控：延迟、token 消耗、每任务成本和失败频率在稳定的任务库中跟踪。评估还作为产品和研究部门之间最高保真的沟通工具，定义研究人员可以追求的可测量目标。显然，评估提供超越基本回归和改进跟踪的收益。累积价值往往被忽视，因为初始成本是透明的，而长期收益逐渐显现。

如何评估 AI Agent

目前，常见的规模化 Agent 类别包括编码 Agent、研究 Agent、计算机使用 Agent 和对话 Agent。虽然部署在不同行业，但适用的评估方法类似。不需要开发全新的评估。以下部分描述了多种 Agent 类别的验证策略。使用这些基础，然后根据你的上下文定制。

Agent 的评分器类型

典型的 Agent 评估整合三种评分器类别：基于代码、基于模型和人工。每种评估记录或结果的要素。有效的评估需要为目标选择合适的评分器。

基于代码的评分器使用字符串匹配（精确、基于模式、模糊）、二进制验证（失败到通过、通过到通过）、静态检查（代码检查、类型检查、安全）、结果确认、工具调用验证和记录检查。优点包括速度、经济性、客观性、可重复性、简化的调试和条件验证。缺点包括对不匹配模式的合理变化的脆弱性、复杂性有限，以及对主观评估的适用性受限。

基于模型的评分器使用评分标准评估、基于语言的断言、对比分析、基于参考的评估和多评判者共识。优点包括灵活性、可扩展性、细致的评估、开放式任务处理和不受限制的输出格式。限制包括非确定性、相对于代码评分的成本，以及需要针对人工判断进行校准。

人工评分器包括专家审查、分布式评估、选择性检查、对比测试和一致性测量。优点包括黄金标准判断质量、专业共识和参考标准化。缺点包括成本、延长时间线，以及偶尔的专家可用性限制。

每任务评分模型各不相同：加权（组合评分器成就达到阈值）、二进制（所有评分器通过）或混合策略。

能力评估与回归评估

能力或质量评估问"什么表现好？"从较低的通过百分比开始，它们针对 Agent 的局限性，建立改进目标。

回归评估问"Agent 是否保持以前的性能？"维持接近 100% 的通过率。它们防止倒退，分数下降表明故障。在优化期间与能力评估并发执行，确认没有在其他地方出现意外后果。

在启动和优化后，高表现的能力评估可以晋升为防止性能漂移的持续回归套件。以前测量能力的任务变成测量可靠性的评估。

评估编码 Agent

编码 Agent开发、验证和修正代码，遍历存储库并运行命令，类似于人类开发者。当代编码 Agent 评估通常需要明确定义的任务、可靠的测试生态系统和全面的代码验证。

确定性评分自然适合编码 Agent，因为软件的评估很简单：代码是否执行并通过测试？SWE-bench Verified 和 Terminal-Bench 展示了这种策略。SWE-bench Verified 为 Agent 提供 Python 存储库的 GitHub 问题，通过测试套件执行对解决方案评分；解决方案只有通过修复失败的测试而不破坏现有测试才能成功。LLM 能力在单年内从 40% 提升到 >80%。

在为关键任务结果建立通过或失败测试后，评估记录通常证明是有益的。代码质量启发式方法评估超越测试通过的解决方案，而具有定义标准的基于模型的评分器评估工具调用或用户交互等行为。

说明性编码任务评估：

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

此示例展示了用于说明的综合评分器种类。实际编码评估通常依赖于单元测试正确性验证和 LLM 评分标准进行代码评估，仅在合理时才加入额外的评分器和指标。

评估对话 Agent

对话 Agent在协助、商务或指导等领域参与用户对话。与传统聊天机器人不同，它们保持上下文、使用工具并在对话中执行操作。虽然编码和研究 Agent 涉及大量用户交互，但对话 Agent 呈现独特的评估障碍：交互质量本身成为可评估内容。有效的评估通常使用可验证的最终状态结果和捕获完成度及沟通有效性的标准。独特的是，它们经常需要另一个 LLM 模拟用户。这种技术支撑了 Anthropic 的对齐评估 Agent，使用延长的、对抗性的对话压力测试模型。

对话 Agent 的成功测量包括多个方面：问题解决（状态验证）、在约束内完成（记录参数）和适当的沟通风格（LLM 评估）。τ-Bench 及其后继者 τ2-Bench 展示了多维度，创建跨越零售协助和航空公司交易的多轮场景，一个模型模拟用户行为，而 Agent 处理真实情况。

说明性对话任务评估：

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 是否通过故意简单验证但具有挑战性的任务定位晦涩的网络信息。

研究 Agent 评估构建有效混合评分器类型。基础验证确认断言基于检索的文档，覆盖验证指定必要事实，来源验证确认所咨询文档的可信度而非检索位置。对于可客观验证的问题（"公司 X 的第三季度收入？"），精确匹配有效。基于 LLM 的评估识别未支持的断言和覆盖缺口，同时确认综合的连贯性和完整性。

鉴于研究质量的解释维度，基于 LLM 的评分标准值得定期专家校准以进行可靠的 Agent 评分。

计算机使用 Agent

计算机使用 Agent使用人类界面与应用程序交互——图形、指针、文本输入、滚动——而不是 API 或直接代码。它们可以导航任何基于 GUI 的软件，从创意工具到过时的商业系统。评估需要在真实或受保护的环境中使用实际应用程序执行 Agent，检查客观完成度。WebArena 评估浏览器作业，使用 URL 和页面状态验证确认导航，使用后端状态确认确认数据修改（验证实际购买完成而非确认页面外观）。OSWorld 将范围扩展到完整的操作系统管理，检查执行后的各种工件：文件系统状态、应用程序配置、数据库内容和界面属性。

浏览器 Agent 需要在 token 保存和响应速度之间取得平衡。DOM 方法执行快但消耗大量 token；截图方法操作慢但节省 token。当指示 Claude 提取维基百科信息时，DOM 提取很经济。在亚马逊上寻找新的笔记本电脑包值得基于截图的交互（全面的 DOM 提取消耗大量 token）。Claude for Chrome 的进步创建了评估，确认 Agent 根据情况选择适当的方法，实现更快、更准确的浏览器完成。

Agent 评估中的非确定性

无论类别如何，Agent 性能在执行中波动，使结果理解复杂化。每个任务都有不同的成就率——可能一个 90%，另一个 50%——以前成功的任务可能随后失败。有时测量目标涉及 Agent 每任务成功的_频率_。

两个指标阐明这种微妙之处：

pass@k代表 Agent 在 k 次尝试中实现≥一次成功解决的可能性。随着 k 增加，pass@k 分数上升：额外的解决方案机会提高成功几率。50% 的 pass@1 分数表示一半的评估任务在首次尝试中成功。编码通常优先考虑初始成功——pass@1。在其他地方，生成多个解决方案就足够了，只要有一个有效。

pass^k量化_all k_次尝试都成功的概率。增加 k 会降低 pass^k，因为要求跨额外尝试的一致性提高了标准。三次试验中 75% 的每次试验成功率产生 (0.75)^3 = 42% 的 pass^k。这个指标对于期望一致操作的用户面向 Agent 特别重要。

pass@k 和 pass^k 随着试验扩展而分化。在 k=1 时，它们相同。到 k=10 时，它们展示了相反的叙述：pass@k 接近 100%，而 pass^k 下降到零。

两者都有益；选择取决于产品需求：当单次成功足够时使用 pass@k，当可靠性至关重要时使用 pass^k。

从零到一：构建优秀 Agent 评估的路线图

本节分享经过现场测试的指导，从没有评估过渡到可信赖的评估框架。将此视为以评估为中心的开发计划：尽早建立成功参数、清晰量化、持续改进。

为初始评估数据集收集任务

步骤 0. 尽早开始

团队经常推迟评估构建，认为必须要有数百个任务。实际上，从真实失败中获取的 20-50 个简单任务是一个很好的开始。早期 Agent 修改通常产生明显、可见的后果，大的效应量意味着有限的样本就足够了。成熟的 Agent 可能需要扩展的、更难的评估来检测效应，尽管从 80/20 方法开始效果最佳。延迟评估开始会造成障碍。初始条件自然从规格产生考试案例。延迟开发从操作系统反向工程成功参数。

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

从现有的预发布检查开始——每次启动前确认的行为和典型的最终用户查询。已经投入生产？调查问题日志和帮助渠道。将报告的失败转换为考试确保套件相关性；按用户影响优先级优化能量分配。

步骤 2. 编写带有参考解决方案的明确任务

稳健的任务组合比预期更棘手。高质量任务达到独立领域专家会达成匹配裁决的结果。他们能独立完成任务吗？如果不能，需要改进。任务规范的模糊性变成测量噪声。基于模型的评分器不精确与此平行：模糊的标准造成不一致的判断。

任务需要 Agent 通过指令遵从性来解决。微妙之处经常出现。Terminal-Bench 分析揭示，请求编写脚本而不指定文件路径，结合假设特定位置的测试，可能导致 Agent 尽管正确执行但失败。评分验证应在任务措辞中明确体现；Agent 不应因不明确的指示而受到惩罚。前沿模型达到 0% 的 pass@100 信号表明任务规范损坏而非 Agent 限制——仔细检查任务定义和评分器设置。有价值的实践：创建参考解决方案——确认满足所有评分标准的功能输出。这展示任务的可解性并确认正确的评分器配置。

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

包括行为_应该_表现的评估场景以及_不应该_表现的场景。单方面覆盖产生单方面增强。例如，仅测试搜索必要性可能生成过度搜索的 Agent。防止类别不平衡的评估。这个教训在 Claude.ai 网络搜索评估开发期间出现。问题：防止不必要的搜索同时保护称职的研究能力。解决方案：涵盖需要搜索的查询（天气请求）和知识响应式查询（Apple 创始人识别）的综合评估集。在过度使用和过度使用之间取得理想平衡需要大量迭代，涉及提示词和评估改进。新兴的失败继续丰富评估的全面性。

设计评估框架和评分器

步骤 4. 使用稳定环境构建稳健的评估框架

生产 Agent 功能应该接近评估 Agent 行为，环境稳定性防止不必要的噪声。"隔离"试验应以未污染的条件初始化。意外的共享状态（剩余文档、回收数据、耗尽资产）造成源于基础设施问题而非 Agent 能力的相关失败。分布式条件人为夸大成就。内部观察的场景揭示 Claude 通过审查早期尝试历史获得不应得的测试好处。共享试验情况下，独特的测试因相同限制（计算资产不足）失败，使结果由于相互依赖而不可靠用于 Agent 能力评估。

步骤 5. 深思熟虑地设计评分器

严谨的评估平衡 Agent 和评估的最佳评分器选择。优先考虑在可行时进行确定性评分，在必要或有益时进行 LLM 评分，并谨慎包含人工评分器进行验证。

常见倾向有利于验证 Agent 执行了特定步骤——按正确顺序的工具序列。这产生过度刚性和过度脆弱的验证，因为 Agent 发现合法的意外路径。避免惩罚独创性需要评估成就而非实现路径。

多组件任务值得纳入部分学分。正确识别问题并验证客户但错过退款处理的 Agent 代表比立即失败有意义的改进，需要成功连续体表示。

模型评分需要彻底迭代以建立准确性。LLM 作为评判者的评分器需要大量人工专家校准才能获得可信的性能。通过在缺少足够上下文时提供"未知"等替代方案来减轻幻觉。独立评分不同方面的结构化评分标准，然后应用单独的 LLM 评估而非统一判断，加强可靠性。在基本稳健性之后，不频繁的人工评估证明足够。

微妙的失败模式降低甚至熟练的开发。Agent 性能恶化有时反映评分缺陷、Agent 框架限制或模糊性而非能力限制。严谨的团队遇到遗漏的问题。Opus 4.5 最初显示 42% 的 CORE-Bench 性能，直到 Anthropic 专家识别出多个问题：僵化的评分拒绝"96.12"当寻求"96.124991..."时、不清晰的任务语言、以及不可能复制的不可预测分配。纠正这些并使用不受限制的脚手架将 Opus 4.5 提升到 95%。METR 同样发现了错误配置的基准分配，要求优化到阈值分数同时要求超过阈值——惩罚合规的 Claude 同时奖励违反规则的竞争对手。严谨的任务和评分器验证防止复发。

加强评分器防止利用。Agent 不应轻松"作弊"评估。任务和评分器工程应该需要真正的问题解决而非发现意外的捷径。

长期维护和使用评估

步骤 6. 检查记录

不审查大量试验记录和分数，评分器功效不清楚。Anthropic 投资于记录查看基础设施，定期检查它们。失败的任务值得调查——记录阐明真正的 Agent 错误与评分器拒绝合法解决方案，表面化重要的行为信息。

失败值得公平性评估：存在明显的 Agent 困惑和原因。分数停滞需要对结果的信心。当进展停滞时，基于环境的关注必须取代假定的 Agent 缺陷。阅读记录确认评估测量准确性并且至关重要。

步骤 7. 监控能力评估饱和

100% 的性能监控回归但对开发没有信号。评估饱和发生在 Agent 耗尽可解任务时，消除改进空间。SWE-Bench Verified 从 30% 开始，前沿 Agent 接近 >80% 饱和。接近饱和时，增强放缓，因为困难任务保留。这掩盖现实：有意义的能力改进表现为适度的分数增益。Qodo 在审查代码评估时对 Opus 4.5 不以为然，因为简单的评估错过了复杂任务胜利。他们开发了 Agent 框架，阐明真正的改进。

标准实践：在详细调查和记录采样之前不要使用字面评估分数。不公平的评分、模糊的规范、惩罚正确的解决方案或框架限制需要修订。

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

评估套件代表需要持续维护和明确所有权的活文档，以保持持久有用。

Anthropic 测试了各种保护技术。成功的方法指定专门的评估团队管理核心架构，而领域专家和产品人员提供大多数任务并进行评估。

产品组织应该将评估创建和改进视为标准——匹配单元测试处理。团队冒着在初始可接受的创新上损失开发周数的风险，这些创新最终在不言明的要求出现时令人失望。评估规范更好地压力测试产品目标是否事先足够具体。

建议以评估为导向的开发：在 Agent 能力之前建立描述预期能力的评估，然后增强直到实现。在内部，团队构建当前表现良好但预测未来模型容量的功能。较低开始的能力评估展示了这一点。模型发布通过套件执行快速揭示成功的估计。

最终用户交互和需求理解将利益相关者定位为最适合定义成功。当前模型强度赋能产品领导、客户关系主管或使用 Claude Code 的商务专业人员输入评估任务——让他们参与！更好：积极促进参与。

评估如何与其他方法配合以全面理解 Agent

自动化评估在数千个场景中运行，没有生产影响或真实用户参与。这代表众多性能理解方法中的单一评估途径。综合评估包括生产检查、消费者输入、A/B 对比检查、手动记录检查和组织的人工评估。

自动化评估提供快速迭代、完整的可重复性、零用户影响和每次提交执行，使大规模场景测试无需部署成为可能。缺点包括前期投资、解决产品-模型漂移的持续维护，以及可能因与实际行为不一致而过度自信。

生产监控在规模上展示真实的消费者行为，捕获评估遗漏的问题，并提供运营真相。缺点包括反应性——问题首先到达消费者、信号变异性、仪器需求以及评分基本事实缺失。

A/B 测试评估真实的消费者结果（继续、完成）、管理混淆变量，并系统地扩展。限制包括缓慢（显著性需要天/周和足够的流量）、狭窄测试（仅部署的变体）以及在没有彻底记录检查的情况下对变化驱动因素的减少解释。

用户反馈用真实的人类实例表面化意外问题，与优先级相关。限制包括稀疏性和选择偏差有利于急性问题、缺少关于失败的解释、缺乏自动化，以及可能完全依赖问题表面化的用户伤害。

手动记录审查建立失败直觉、表面化自动化程序忽略的精细关注，并发展性能理解。限制包括劳动强度、有限的可扩展性、不一致的覆盖以及影响审查者一致性的疲劳效应。

系统的人工研究从众多评分者提供权威的专家判断、处理主观/模糊的分配，并指导 LLM-评分器增强。限制包括相对费用、延长的周期、要求评分者间和解，以及需要专业研究的专家需求（司法、商业、医疗）。

不同方法与开发间隔对齐。预发布和 CI/CD 强烈受益于自动化评估，每次修改和模型修订运行作为初始失败防御。发布后生产监控检测分布变化和意外失败。在足够的流量之后，对比测试确认有意义的修改。用户输入和记录检查保持连续：定期评估反馈、每周采样记录、按需升级。保留结构化的人工评估用于 LLM-评分器校准或专家输出评估，其中人工共识提供参考标准。

像瑞士奶酪安全模型一样，不同的评估阶段解决各种失败。单一方法捕获一切；组合策略捕获通过先前障碍的内容。

高表现的组织混合方法：自动化评估用于快速迭代、生产监控用于运营确认、定期人工评估用于对齐。

结论

没有评估的团队经历被动循环——纠正失败、生成其他失败、区分实际回归和随机性证明是不可能的。早期投资的组织遇到相反情况：随着困难变成考试案例，开发加快，评估防止倒退，测量取代猜测。评估阐明改进目标，将 Agent 评估从模糊转变为可操作。当作为核心而非补充处理时，收益在 Agent 生命周期中倍增。

方法在 Agent 分类中波动，但基础保持一致。立即开始避免追求完美。从观察到的失败中收集现实问题。阐明透明、有效的成功定义。深思熟虑地选择评分方法，联合不同的品种。要求足够的挑战。改进评估以提高可靠性。检查记录！

Agent 评估代表发展中、快速推进的研究。延长的 Agent 分配、多 Agent 团队合作和增加的主观性将需要自适应方法论。进度分享将在知识积累时坚持下去。

附录：评估框架

多个开放和商业评估资源帮助开发，无需从头开发基础设施。选择取决于 Agent 品种、运营生态系统以及离线与生产可观察性要求。

Harbor通过跨越云分发和注册表提供的规范基准的基础设施解决容器化 Agent 执行，促进自定义集成。

Promptfoo强调轻量级声明式 YAML 规范，具有从字符串评估到 LLM 作为评估器框架的综合验证品种。Anthropic 将此用于业务评估。

Braintrust将离线评估与运营监控和试验管理结合——最适合并发开发迭代和运营质量跟踪。自托管的 Langfuse 为隔离基础设施需求提供等效的 OSS 替代方案。

LangSmith提供跟踪、离线和生产评估以及集成到 LangChain 环境的数据集管理。

团队定期集成多个平台、构建专有方法或从基本脚本开始。优秀的框架促进加速和标准化；成功取决于评估实质。快速选择生态系统匹配的框架；通过迭代测试改进和评分复杂性将关注重定向到高质量评估创建。

---

发布时间： 2026年1月9日