1 引言
1.1 智能体的结构
在大语言模型驱动的自主智能体系统中，大语言模型充当智能体的“大脑”，并辅以以下几个关键组件：
（1）规划
子目标与任务分解：智能体将大型任务拆解为更小、更易管理的子目标，从而高效处理复杂任务。
反思与优化：智能体能够对过往行动进行自我批评与反思，从错误中学习并优化后续步骤，从而提升最终结果的质量。
（2）记忆
短期记忆：我们可以将所有上下文学习（见提示工程相关内容）视为模型利用短期记忆进行学习的过程。
长期记忆：通过借助外部向量存储与快速检索等技术，智能体具备了在长时间内保留和回忆（近乎无限）信息的能力。
（3）工具使用
智能体学习调用外部API以获取模型权重中缺失的额外信息（这些信息通常在预训练后难以更新），包括实时信息、代码执行能力、访问专有信息源等。
参考：LLM Powered Autonomous Agents
1.2 Agent-Loop
在每次智能体会话中，系统会遵循一个清晰、循环的工作流程。整个过程始于接收用户的提问，并在智能体完成所有必要的分析和处理之后，最终输出回应。
流程概览如下：
- 接收输入：用户提出问题，系统会结合当前对话的历史记录和相关指令，为智能体准备完整的上下文。
- 分析与决策：智能体基于当前信息评估状况，决定下一步行动。它可能会选择直接以文本形式回复，也可能会决定调用一个或多个外部工具来获取更多信息或执行操作，或者两者结合进行。
- 执行工具：如果智能体决定调用工具，系统便会执行这些工具，并将执行结果收集起来，反馈给智能体，以供其进行下一步的思考和决策。
- 循环处理：上述的“分析决策”和“执行工具”两个步骤会循环进行。智能体会持续地调用工具、分析结果，并调整其策略，直到它认为已经获取足够信息，可以形成最终答案，并且不再需要调用更多工具为止。这样一个完整的“分析-执行”周期称为一个“回合”。
- 返回最终结果：当循环结束时，智能体会生成包含最终答案的文本响应，系统随之结束本次会话，并可能附带一些本次交互的摘要信息。
示例说明：
对于一个简单的问题，例如“这里有哪些文件？”，整个过程可能非常迅速，智能体仅需调用一两次文件查找工具便可直接回复。
而对于一个复杂的任务，比如“重构身份验证模块并更新测试”，则可能涉及数十次工具调用（如读取文件、编辑代码、运行测试等），并经过多轮的分析与调整，智能体会根据每一步的结果来优化其解决方案。
参考：https://platform.claude.com/docs/en/agent-sdk/agent-loop
在上面这个Loop里，有两个关键组件，一个工具调用，另一个则是评估（Evaluate）。
Claude Code 内建工具包括：
接下来详细介绍下Evaluate。
1.3 Eval飞轮
PRD 是为确定性世界设计的。AI 产品的世界是非确定性的。
那 PRD 该被什么取代？答案是 eval——结构化、可重复、自动化的产品质量评测。
参考：https://mp.weixin.qq.com/s/0bHZsi7HffxWki9YZ4jAdg
2 评估的结构
Evaluation （简称“eval”）是对AI系统的一种测试：给AI系统输入数据，然后应用评分逻辑对其输出进行评估，以衡量其成功程度。本文重点介绍无需真实用户参与即可在开发过程中运行的自动化评估 。
单轮评估简单明了：一个提示、一个回答和评分逻辑。对于早期的学习者学习模型（LLM）而言，单轮、非智能体评估是主要的评估方法。随着人工智能能力的提升， 多轮评估变得越来越普遍。
| 在简单的评估中，智能体处理提示，评分器（grader ）检查输出是否符合预期。对于更复杂的多轮评估，编码智能体接收工具、任务（本例中为构建 MCP 服务器）和环境，执行“智能体循环”（工具调用和推理），并使用实现更新环境。评分器随后使用单元测试来验证 MCP 服务器是否正常工作。 |
|---|
在构建智能体评估时,我们使用以下定义:
- 任务(Task)(也称为问题或测试用例): 具有定义的输入和成功标准的单个测试。
- 试验(Trial): 对任务的每次尝试。由于模型输出在运行之间有所变化,我们运行多次试验以产生更一致的结果。
- 评分器(Grader): 对智能体表现的某些方面进行评分的逻辑。一个任务可以有多个评分器,每个评分器包含多个断言(有时称为检查)。
- 记录(Transcript)(也称为追踪或轨迹): 试验的完整记录,包括输出、工具调用、推理、中间结果和任何其他交互。对于Anthropic API,这是评估运行结束时的完整消息数组——包含评估期间的所有API调用和所有返回的响应。
- 结果(Outcome): 试验结束时环境中的最终状态。航班预订智能体可能会在记录末尾说"您的航班已预订",但结果是环境的SQL数据库中是否存在预订。
- 评估框架(Evaluation Harness): 端到端运行评估的基础设施。它提供说明和工具,并发运行任务,记录所有步骤,对输出进行评分并聚合结果。
- 智能体框架(Agent Harness)(或脚手架): 使模型能够作为智能体运行的系统:它处理输入,编排工具调用,并返回结果。当我们评估"智能体"时,我们评估的是框架和模型协同工作。例如,Claude Code是一个灵活的智能体框架,我们通过Agent SDK使用其核心原语构建了我们的长期运行智能体框架。
- 评估套件(Evaluation Suite): 旨在测量特定能力或行为的任务集合。套件中的任务通常共享一个广泛的目标。例如,客户支持评估套件可能会测试退款、取消和升级。
3 为什么要构建评估体系？
| 原因 | 核心要点 | 详细说明 | 实践案例/证据 |
|---|---|---|---|
| 避免扩展后的崩溃 | 从快速进展到规模化崩溃的转变 | • 早期阶段:手动测试、内部使用、直觉就能取得显著进展• 假象:评估看起来像减慢发布的开销• 规模化后:没有评估会暴露严重问题• 崩溃点:用户反馈"智能体变差"时,团队"盲目飞行"• 核心问题: - 调试变成被动模式(等待投诉→手动重现→修复错误→祈祷无回归) - 无法区分真实回归和噪音 - 无法自动测试数百个场景 - 无法量化改进 | • 用户体验下降• 团队无法验证问题• 被动修复循环 |
| 2. 主动预防 vs 被动响应 | 将问题解决从被动转向主动 | • 没有评估:等待用户投诉才发现问题• 有评估:在影响用户前就发现和解决问题• 从被动修复转变为主动预防• 提前识别问题,指导改进方向 | Claude Code案例:• 初始阶段:基于员工和外部用户反馈快速迭代• 进化阶段:添加评估体系 - 优先级评估:简洁性、文件编辑等狭窄领域 - 复杂行为评估:过度工程等高级行为• 成果:结合生产监控、A/B测试、用户研究,评估提供持续改进的信号 |
| 3. 明确质量标准,消除歧义 | 生命周期价值:早期编码行为,后期维持标准 | • 早期价值: - 迫使产品团队明确定义"成功"意味着什么 - 编码预期行为,消除规范中的歧义 - 解决不同工程师对相同规范的不同解读 - 特别是边缘情况的处理标准• 后期价值: - 维持一致的质量标准 - 防止随着时间和迭代导致的质量漂移 | • 两个工程师阅读相同规范可能有不同解读• 评估套件解决歧义• 无论何时创建,都加速开发• 明确AI边缘case的处理方式 |
| 4. 加速新模型采用 | 战略竞争优势:模型升级速度对比 | • 评估能力直接影响新模型采用速度• 速度对比: - 没有评估的团队:面临数周的手动测试周期- 有评估的团队: - 快速确定新模型的优势和劣势 - 高效调整提示词和配置 - 在数天内完成升级部署• 战略意义:在AI快速迭代的竞争中,评估能力成为决定性优势 | 更强大的模型推出时• 无评估团队:数周测试• 有评估团队:快速评估→调优→几天升级•竞争力差距显著 |
| 5. 获得基础设施价值和协作效益 | 免费获得基础设施,促进团队协作 | • 免费获得的基础设施: - 基线测试能力 - 回归测试能力 - 可跟踪的关键指标: - 延迟(Latency) - 令牌使用(Token Usage) - 每任务成本(Cost Per Task) - 错误率(Error Rate)• 团队协作桥梁: - 成为产品团队和研究团队之间最高带宽的通信渠道 - 定义清晰的研究优化目标 - 促进跨团队协作和知识共享• 复合价值效应: - 评估的价值远不止于跟踪回归和改进 - 成本在前期可见,但效益会在后期累积 - 具有显著的复利效应,越早建立价值越大 | • 延迟、令牌、成本、错误率自动跟踪• 产品-研发协作渠道建立• 多维度价值复合积累 |
4 如何评估AI智能体
我们看到今天大规模部署的几种常见类型的智能体,包括编码智能体、研究智能体、计算机使用智能体和对话智能体。每种类型可能在广泛的行业中部署,但它们可以使用类似的技术进行评估。您不需要从头开始发明评估。以下部分描述了几种智能体类型的经过验证的技术。使用这些方法作为基础,然后将它们扩展到你的领域。
4.1 智能体的评分器类型
智能体评估通常结合三种类型的评分器:基于代码、基于模型和人工。每个评分器评估记录或结果的某些部分。有效评估设计的一个关键组成部分是为工作选择合适的评分器。
基于代码的评分器:
基于模型的评分器:
人工评分器:
对于每个任务,评分可以是加权的(组合评分器分数必须达到阈值)、二进制的(所有评分器必须通过)或混合的。
4.2 能力评估与回归评估
能力或“质量”评估会问：“这个智能体擅长做什么？”评估应该从较低的通过率开始，针对智能体难以完成的任务，给团队设置一个挑战。
回归评估旨在询问“代理是否仍然能够处理之前的所有任务？”，其通过率应接近 100%。回归评估可以防止系统退步，因为分数下降表明某些环节出现问题，需要改进。团队在进行能力评估时，同时运行回归评估至关重要，以确保变更不会在其他地方引发问题。
代理程序启动并优化后，通过率高的能力评估可以“升级”为回归测试套件，持续运行以检测任何偏差。以前衡量“我们能否完成这项任务？”的任务，现在可以衡量“我们是否仍然能够可靠地完成这项任务？”
4.3 评估编码智能体
编码代理能够编写、测试和调试代码，像人类开发者一样浏览代码库并执行命令。对现代编码代理进行有效评估通常依赖于明确的任务定义、稳定的测试环境以及对生成代码的全面测试。
对于编码代理来说，确定性评分器是天然的选择，因为软件的评估通常比较直接：代码能否运行，测试能否通过？两个广泛使用的编码代理基准测试工具 SWE-bench Verified 和 Terminal-Bench 都采用了这种方法。SWE-bench Verified 会向代理提供来自热门 Python 代码库的 GitHub 问题，并通过运行测试套件来评估解决方案；只有当解决方案修复了失败的测试且不破坏现有测试时，才能通过评估。
一旦你拥有了一套用于验证编码任务关键结果的合格/不合格测试，通常也需要对代码进行评分 。 例如，基于启发式的代码质量规则可以基于除通过测试之外的其他因素来评估生成的代码，而带有清晰评分标准的基于模型的评分器可以评估诸如智能体如何调用工具或如何与用户交互等行为。
示例：编码代理的理论评估
考虑这样一项编码任务：智能体必须修复一个身份验证绕过漏洞。如下面的示例 YAML 文件所示，可以使用评分器和指标来评估该智能体。
task:id: "fix-auth-bypass_1"desc: "Fix authentication bypass when password field is empty and ..."graders:- type: deterministic_testsrequired: [test_empty_pw_rejected.py, test_null_pw_rejected.py]- type: llm_rubricrubric: prompts/code_quality.md- type: static_analysiscommands: [ruff, mypy, bandit]- type: state_checkexpect:security_logs: {event_type: "auth_blocked"}- type: tool_callsrequired:- {tool: read_file, params: {path: "src/auth/*"}}- {tool: edit_file}- {tool: run_tests}tracked_metrics:- type: transcriptmetrics:- n_turns- n_toolcalls- n_total_tokens- type: latencymetrics:- time_to_first_token- output_tokens_per_sec- time_to_last_token请注意，此示例仅展示了所有可用的评分工具，仅供参考。在实际应用中，代码评估通常依赖于单元测试进行正确性验证，并使用 LLM 评分标准评估代码整体质量，其他评分工具和指标仅在必要时添加。