Agent 评估：详细指南（53 分钟阅读）

# 智能体评估：一份详尽指南 来源：https://cameronrwolfe.substack.com/p/agent-evals [](https://substackcdn.com/image/fetch/$s_!LMJ6!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7b6f7ad2-6e1f-420d-bc95-8c916fd18592_1792x1080.png)（来自 [1, 3, 8, 12]） 评估是大语言模型（LLM）最重要的研究领域之一。最近，LLM 的使用模式和评估方法发生了巨大变化。过去，我们使用由静态问题或简短对话组成的基准来评估 LLM，而现在，我们有了能在长时间跨度内运行并与环境交互的智能体系统。由于智能体具有复杂性和自主性，对其进行正确评估十分困难。为了准确衡量智能体系统的能力，我们必须构建逼真且能够像实际应用那样测试智能体的测试框架。随着智能体在编码、医疗等高风险应用中的日益普及，构建这样的评估能力比以往任何时候都更加重要。 本概述将提供一份关于当前智能体系统如何评估的详细指南。我们将首先从一般概念理解智能体，涵盖从基本概念到多智能体系统的所有内容。然后，我们将基于实践中观察到的常见模式，为智能体评估过程提供一个清晰的框架。在此基础上，我们将以近期几个智能体基准测试为例进行案例研究，并提供一个路线图，说明如何应用类似概念构建我们自己的智能体评估。尽管评估耗时且困难，但学会如何正确评估智能体极具价值。通过严格衡量性能而不是依赖主观检验，我们可以快速提升智能体能力。 > *“LLM 越来越能够处理复杂的、多步骤的任务。推理、多模态和工具使用的进步，解锁了一类新的由 LLM 驱动的系统，即智能体。”* > — 来自 [3] 在智能体时代的早期，智能体与普通 LLM 之间的区别并不明确。毕竟，LLM 是所有智能体系统的核心。随着时间的推移，智能体系统的关键特征开始显现： - 推理（https://cameronrwolfe.substack.com/p/demystifying-reasoning-models） - 调用工具（https://cameronrwolfe.substack.com/p/teaching-language-models-to-use-tools） - 解决复杂的多步骤问题 - 从错误中恢复 - 代表用户执行操作 LLM 能够推理、调用工具和解决问题，但智能体的独特之处在于它们能够将这些组件组合在一个**智能体循环**中来解决难题。如下所示。实际上，最简单的智能体定义（https://simonwillison.net/2025/Sep/18/agents/）是：LLM 在循环中自主使用工具。与传统 LLM 不同，智能体必须评估中间结果，并动态地从自身错误中恢复，才能在这个智能体循环中有效运作。 [](https://substackcdn.com/image/fetch/$s_!w_bJ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fdc188a1a-2230-44f8-9b67-87f0a9872824_1472x938.png)智能体循环 考虑到智能体在长时间跨度内进行推理并使用工具，**它们还可以根据自主程度来划分**。传统 LLM 通常用于狭窄、范围明确的任务（如分类或问答），模型产生输出，但不会独立继续行动，也没有能力修改其环境。另一方面，智能体通常被允许在一段时间内控制自己的工作流程，并可以使用工具自主执行操作（例如，修改日历事件或预订机票）。 [](https://substackcdn.com/image/fetch/$s_!dPSO!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8b5bd8d4-a75a-4a61-a95c-f2e3363fef79_2216x700.png)传统 LLM 的输入输出模式 如上所示，LLM 的输入输出接口非常简单：**我们提供一个提示作为输入，并接收一个输出**。这种简单的接口在 AI 被公众广泛采用中发挥了重要作用：**LLM 既实用又直观**。这种文本到文本的接口还可以扩展以处理各种辅助行为，如推理和工具使用，使得传统 LLM 与智能体之间的差距相对较小。具体来说，智能体系统通常由三个组件组成： 1. 底层 LLM（或推理模型） 2. 智能体可使用的工具 3. 智能体的指令 LLM 作为系统的大脑，判断朝着最终解决方案的进展，并决定为实现目标必须采取的步骤。然而，在许多情况下，仅靠 LLM 本身无法得出正确的最终解决方案。我们必须明确指定智能体的预期行为，并使模型能够在必要时调用工具或执行复杂的推理。 **工具使用。** 为了与外部环境交互，LLM 需要能够使用 API、CLI 或 MCP 服务器（https://modelcontextprotocol.io/docs/getting-started/intro）等工具。例如，如果我们希望智能体为我们预订一家当地餐厅的座位，我们可以简单地教模型如何构造对 OpenTable API 的调用。具体来说，工具调用可以通过在 LLM 的 token 流中创建一组与工具调用相关的特殊 token，并教 LLM 如何使用这些 token，自然地处理；如下所示。 [](https://substackcdn.com/image/fetch/$s_!N4MY!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F59b33434-e0d9-4211-847a-ff89508dfa37_2382x350.png) 例如，Qwen3 模型通过几个 XML 风格的标签来处理工具调用，这些标签作为特殊 token 存储在分词器中： - `` 和 `` 用于封装工具定义。 - `` 和 `` 用于封装特定的工具调用，包括要调用的工具和相关参数。 - `` 和 `` 用于封装被调用工具返回的结果或响应。 Qwen3 的指令模板结构如下所示。我们在系统消息中定义可用的工具以及调用它们的预期格式，这为模型提供了必要的上下文，使其能够：i）理解哪些工具可用；ii）构造对这些工具的有效调用。然后，模型可以在生成输出时通过输出 `` 和 `` 标签来构造工具调用。在推理时，每当生成一个 `` token 时，我们便中断生成。然后我们可以解析请求、调用工具、将结果连接到当前输出，并重新开始生成。模型在生成剩余输出时，其上下文中就包含了工具调用的结果。 创建能被智能体轻松理解和正确调用（https://www.anthropic.com/engineering/writing-tools-for-agents）的有用工具是一门艺术。工具应有良好的文档、明确的目的、与其他工具重叠最小化，并能从错误中优雅恢复。判断工具是否设计正确的最简单方法是问自己：**人类工程师能根据提供的文档使用这个工具吗？** 工具调用在智能体系统中服务于多个目的。LLM 可以使用工具获取外部信息以减少幻觉、在环境中完成任务、执行代码、调用其他智能体等等。如果没有针对待完成任务的可用 API，我们甚至可以依赖计算机使用原语（https://arxiv.org/abs/2501.16150），让我们的智能体直接与计算机上的任意应用交互——**就像人类使用计算机一样**。 > *“计算机使用智能体通过人类使用的相同界面与软件交互——截图、鼠标点击、键盘输入和滚动——而不是通过 API 或代码执行……每个工具都应有标准化的定义，使工具与智能体之间能够灵活地多对多关联。文档完善、经过充分测试、可重用的工具可提高可发现性、简化版本管理，并防止重复定义。”* > — 来自 [1] 我们可以通过多种方式教 LLM 使用工具——例如通过**上下文学习（https://cameronrwolfe.substack.com/p/language-models-and-friends-gorilla）** 或**微调（https://cameronrwolfe.substack.com/p/teaching-language-models-to-use-tools）** ——但工具调用与 LLM 可以学习的任何其他技能并无不同。甚至有专门的基准测试（https://gorilla.cs.berkeley.edu/leaderboard.html）用于衡量工具调用能力，性能通过多种不同指标来衡量： - **调用准确性**衡量 LLM 是否在应该调用时正确决定调用工具，或在不应该调用时避免调用。例如，模型可能在应该直接回答问题的情况下调用工具。 - **选择准确性**衡量 LLM 是否调用了正确的工具，通常通过跟踪包含解决特定问题所需工具列表的 ground truth 轨迹来进行。 - **结构准确性**和**模式有效性**衡量工具调用的结构是否正确。例如，模型不应在工具调用中包含错误的参数或提供错误的调用结构。 - **轨迹准确性**关注模型在解决问题时发出的工具调用序列，并以某种方式将其与 ground truth 进行比较（例如，正确的调用顺序、正确的选择、是否使用了不必要的工具等）。 我们也可以使用面向结果的评估，关注 LLM 的最终答案是否正确，而不是它使用了哪些工具来产生答案。 **推理**在我们构建高效智能体系统的能力中也扮演着关键角色。虽然我们可以使用标准 LLM 作为智能体系统的底层模型，但使用具有推理能力的模型通常更有益处。为了解决多步骤任务，智能体必须能将难题分解为更小、更简单的部分，并逐一解决每个部分——**可能借助工具**——从而得出最终解决方案。此外，模型在解决问题时必须能够自我反思并从自身错误中恢复。以这种方式处理长期问题需要一定水平的推理和可靠性，而这直到最近随着推理模型的出现才成为可能。 [](https://substackcdn.com/image/fetch/$s_!iThv!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fff8c2a7d-e62b-4ed7-bb2c-99de79b0ad96_2390x688.png)推理模型产生的思考轨迹 与根据提示直接产生输出的标准 LLM 不同，推理模型不会立即给出答案。相反，它们在给出最终答案之前，会写出一段较长的——**通常隐藏的**——文本推理轨迹¹（https://cameronrwolfe.substack.com/p/agent-evals#footnote-1）；如上所示。这种思考过程自然而然地适应了**推理时间扩展规律（https://cameronrwolfe.substack.com/p/llm-scaling-laws）**。模型可以被教会根据不同的长度进行动态推理——**通常用推理轨迹中的 token 数量来衡量**。更长的推理轨迹需要更多的推理时间计算，因为我们生成了更多的 token。然而，这种计算投入通常会带来性能提升，**允许模型通过花更多时间推理来解决更困难的问题**。有关更多详细信息，请参阅下面链接的关于推理模型的详细文章。 理解推理模型（https://cameronrwolfe.substack.com/p/demystifying-reasoning-models） 推理模型和标准 LLM 不必相互排斥。我们很快将了解到可以由多个 LLM 或智能体组成的多智能体系统。例如，我们可以在高级规划和工作流管理中使用推理模型——**这些领域推理能力很重要**——同时将标准 LLM 暴露为用于较简单子任务的工具。 **指令。** 智能体系统的最后一个组件是智能体的指令。这些指令的核心可以来自该领域的现有文档（例如，注释指南或政策文档）。指令应尽可能清晰，通过明确的规则或具体示例澄清边缘情况，并指定智能体预期的确切操作。理想情况下，指令应在简单性和特异性之间取得平衡。我们希望指令足够详细，以可靠地指导智能体行为，但过于复杂的提示会变得脆弱且难以维护。为了帮助编写更好的智能体指令，我们可以使用模型在环方法——**或自动提示优化器（https://cameronrwolfe.substack.com/p/automatic-prompt-optimization）** ——来迭代指令并提高其清晰度。 > *“智能体倾向于一次尝试做太多事情——本质上是试图一步到位完成应用……这导致模型在实现过程中上下文耗尽……然后智能体不得不猜测发生了什么，并花费大量时间试图让基本应用重新工作。”* > — 来自 [4] 智能体的指令不仅应解释要解决的问题，还应解释解决问题的最佳策略。例如，我们可以指示智能体将问题分解为更小的部分，以避免试图一次解决过大的问题。此外，我们还可以进一步澄清智能体在此过程中的预期行为，例如确保解决方案的每一步都作为完全功能实现、编写持久性笔记供后续智能体参考、或维护一个全局待办事项列表。 **ReAct 框架。** 一个完整的智能体系统将所有组件组合在一个 while 循环中：**这称为智能体循环**。在此循环中，智能体将根据提供的指令进行推理、调用工具并采取行动，直到根据智能体的退出条件²（https://cameronrwolfe.substack.com/p/agent-evals#footnote-2）达到终止状态。此时，智能体将交出工作流的控制权——**要么交给人类用户，要么交给另一个智能体**。整个过程被视为智能体循环的一次“运行”。 [](https://substackcdn.com/image/fetch/$s_!AO24!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff7d4aadf-a95f-4a34-9039-8f8bcbc64d67_1902x1000.png)ReAct 框架 智能体循环的概念很简单，但存在许多变体。最早的变体之一是 ReAct——**RE**asoning and **ACT**ion 的缩写——框架 [5]，它为智能体循环提出了一种固定结构；如上所示。ReAct 智能体循环组织成一组顺序步骤。在每个步骤中，我们的智能体观察环境的当前状态，思考最佳后续步骤，并根据其推理过程采取一些行动。下面提供了这种迭代问题解决框架的具体示例。 ReAct 的关键创新在于它同时强调思考和行动。智能体循环的结构使得模型明确地推理所采取的每个行动，并在决定正确的行动时考虑所有上下文——**例如工具调用的观察结果或先前的思考**。简单来说，推理和行动具有共生关系。有关更多详细信息，请参见 ReAct 的完整概述以及智能体领域其他常见模式。