评估智能体行为：结果、发展轨迹与生成反馈
如何超越最终答案来评估智能体系统：将LangChain、LangGraph和LangSmith对应到不同角色，对轨迹与上下文进行评分，并将生产过程中的故障纳入评估体系。
来源: Building Better Agentic AI Systems: What I Learned About Deep Agents, LangSmith Engine & Evals
使用目前的模型和框架，让人工智能代理在演示环境中运行只需一个下午的时间。但当该代理被集成到实际产品中时，问题就出现了：它可能选择错误的工具、获得的上下文信息不足、采取无人预料的处理路径，或者给出看似正确实则错误的答案。本文将探讨如何通过工程化流程让这类系统具备可靠性，重点讨论评估方法——需要衡量什么、在哪个层面进行衡量，以及如何将每一次生产故障转化为防止其再次发生的检查机制。文中示例使用了LangChain生态系统（LangChain、LangGraph、LangSmith和Deep Agents），但这些理念同样适用于其他技术栈。
从单次大语言模型调用到智能代理系统
大语言模型的基本工作流程很容易想象：输入请求，进行一次模型调用，然后输出响应。
User → Prompt → LLM → Response
智能体是一种特殊的存在。面对目标时，它可以将任务拆分、检索文档、调用API、运行工具、维护状态、将部分工作交给其他智能体处理、检查中间结果、从错误中恢复，然后决定下一步行动。该控制流的简化示意图如下：
USER GOAL
│
▼
AGENT
│
PLAN
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
TOOLS MEMORY SUBAGENT
│ │ │
└──────────────┼──────────────┘
│
▼
DECIDE / ACT
│
More work needed?
↙ ↘
YES NO
│ │
└── LOOP ▼
RESULT
注意底部的循环：智能体会不断判断是否还需要执行更多工作，每次迭代都可能涉及工具、内存或子智能体。此时你已不再只是输出模型响应，而是在运行一个系统。这一点对质量至关重要，因为最终答案的质量取决于生成它的决策链。即便模型本身正确，但检索步骤出错，或者计划良好却使用了错误的工具，依然会导致糟糕的结果。
角色分配：LangChain、LangGraph与LangSmith
要区分 LangChain 的三大核心产品，一个实用的方法是将每个产品与其解决的工程问题联系起来。
- LangChain 提供与模型相关的功能：模型集成、工具、外部数据检索及连接功能。它要解决的问题是：应用需要具备哪些能力？
- LangGraph 负责处理具有智能特性的工作流中的协调逻辑，包括状态管理、条件分支、循环、工具调用、人工审批流程以及多智能体协作。它要解决的问题是：工作流应如何运行？
- LangSmith 关注系统上线后的情况：使用了哪些工具、模型看到了什么上下文、延迟出现在何处、哪个步骤出错、为何做出某项决策，以及新版本是否真的优于旧版本。它要解决的问题是：实际发生了什么，结果是否良好？
将这些环节串联起来，流程从业务目标出发，经过各项能力与协调机制，最终产生结果，随后会对该结果进行观察与评估，以便团队从中学习。
BUSINESS GOAL
│
▼
LANGCHAIN
Models • Tools • Data
│
▼
LANGGRAPH
State • Flow • Decisions
│
▼
AGENT SYSTEM
│
▼
RESULT
│
▼
LANGSMITH
Observe • Trace • Eval
│
▼
LEARN
最后一个箭头最为重要。观察并非最终状态，而是为学习提供依据。如果对LangChain与LangGraph之间的区别仍不清晰，我们关于链式结构与有状态图结构的对比内容能深入阐述这一点。
利用智能体提升智能体性能：LangSmith引擎
追踪功能能够准确显示代理的执行过程，但仅凭追踪数据本身无法解决问题。仍需有人来阅读这些数据，分析出问题所在，检查其他地方是否出现相同故障，找出根本原因，进而修改系统，并确认修改没有引发其他问题。对于少量运行记录来说这尚可处理，但面对成千上万的实时追踪数据则根本无能为力。
在撰写本文时，LangSmith 推出了新功能 LangSmith Engine，它通过代理来执行此类分析。该引擎会扫描实时追踪数据中的重复模式与故障，对相关问题进行分类，协助诊断并提出改进方案。尤为重要的是，它发现的故障可以被纳入评估流程，这样今天发现的问题就能在明天得到针对性检查。从概念上来看，其处理流程如下：
PRODUCTION AGENT
│
▼
TRACES
│
▼
LANGSMITH ENGINE
│
▼
Detect Patterns
│
▼
Diagnose Issues
│
▼
Suggest Improvement
│
▼
Add Evals
│
▼
Regression Testing
│
▼
Review / Deploy
│
└────────► Observe Again
每个阶段都在逐步缩小问题范围：原始追踪数据转化为模式，模式进一步发展为诊断结果，诊断结果则成为候选修复方案；在人工审核并部署这些修复方案之前，还需通过新的评估和回归测试进行验证。之后，这一循环会以新的追踪数据重新开始。
这里的变化在于对追踪数据的处理方式。它们不再只是在故障发生时才被查看的对象，而是成为持续改进的原始素材。这正是传统软件中成熟的质量工程所采用的方式：生产环境中的漏洞不应仅通过补丁来解决，而应通过测试来防止同类缺陷再次悄然出现。不过，自动化诊断并不能取代人工审核的必要性——针对提示或工具定义提出的修复方案可能会带来副作用，因此审核和回归测试环节仍需保留。
用于长周期任务的深度智能体
有些任务背后涉及大量工作。以质量工程类的请求为例：面对新的产品需求，智能体必须查阅相关文档，标记风险最高的用户流程，为这些流程起草测试场景，深入分析实现这些流程的代码，并记录分析结果。
要完成这类任务，智能体需要制定计划、读取文件、获取知识、调用工具、可能还需要运行代码、保存中间结果、分配特定任务，并记住已学到的内容。具体工作流程如下：
Understand Goal
│
▼
Create Plan
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Read Files Use Tools Search Knowledge
│ │ │
└─────────────┼─────────────┘
│
Delegate Work
│
▼
SUBAGENTS
│
▼
Combine Findings
│
▼
RESULT
Deep Agents 是 LangChain 专为这类长周期任务设计的智能体框架。它集成了规划、工具使用、文件处理、上下文管理、技能调用、记忆功能以及子智能体等功能，无需用户自行逐一配置。
有趣之处不在于智能体能完成更多任务，而在于其自主性的构建方式。给智能体配备二十种工具并不会使其变得更优秀，反而常常会降低工具选择的效率。将每个任务分配给五个子智能体同样不能自动提升整体架构，因为每次任务交接都会消耗资源并可能导致上下文丢失。构成智能体的基本组件能力越强，围绕它们的设计决策就越重要。一个实用的默认原则是：只有当某个子任务需要独立的上下文或不同的工具集时才添加子智能体，并且要让每个智能体的工具列表保持在任务允许的最小规模。
操控智能体是另一个问题：受控深度智能体
构建一个功能强大的智能体并在生产环境中稳定运行，是两项截然不同的工程任务。长期运行的智能体需要能够应对中断、保持状态、处理文件、安全地执行代码、将进度信息同步到用户界面、保留内存，同时还要输出足够的遥测数据，以便工程师还原所发生的情况。
在撰写本文时，同一生态系统中还有一项托管服务——Managed Deep Agents，正是针对这一运营层面设计的。二者之间的关系可以理解为：上层是智能体的行为逻辑，下层则是运行时基础设施：
DEEP AGENT
Planning • Tools • Files • Subagents
│
▼
Agent Behavior
│
▼
MANAGED DEEP AGENTS Durable Execution
Persistence
Sandboxes
Memory
Streaming
Identity
Tracing / Evaluation
智能体通过规划、工具、文件以及子智能体来定义行为。管理层则提供可靠的执行机制、数据持久化功能、沙箱环境、内存管理、流式处理、身份认证以及带有评估功能的追踪能力。无论你使用托管服务还是自行开发，这一原则都同样适用：智能体模型只是生产级人工智能架构中的一个组成部分，而围绕它的基础设施也同样需要得到同等重视。我们在关于运行时框架与组合式框架的比较中探讨了自行构建与直接采用这两种方案之间的权衡。
为何智能体会打破传统测试模式
传统的测试方法依赖于确定性。给函数输入已知的值，得到相应的输出，再对其进行验证。
Input → Function → Output → Assertion
使用固定请求调用 API，便可检查状态码、响应结构、负载数据、头部信息以及业务规则。而智能体并不遵循这种模式。让某个智能体去调查生产环境中的故障并找出可能的根本原因，它的处理方式可能因次而异：有时会先读取日志再查询数据库，有时则会先查阅文档、调用 API，之后才查看日志。尽管路径不同，但两者都可能得出合理的结论。
另一种情况也存在，且更为危险：即使智能体依赖了不可靠的来源、使用了不合适的工具，或是基于错误的理由得出了正确结论，最终给出的答案却看似合理。仅通过输出结果的精确匹配无法区分这些情况，而这正是评估功能所要填补的空白。
评估所衡量的内容
一个可行的定义是：评估标准用于衡量人工智能系统在完成特定任务时达到相关重要标准的程度。这些标准源自具体任务本身，而非评估框架。
以一个能根据需求生成测试场景的智能体为例，仅知道它返回了十个格式正确的JSON测试用例并不能提供太多信息。有意义的指标在于质量：
GENERATED TESTS
│
▼
EVALUATE
│
┌────────────────┼────────────────┐
│ │ │
Coverage Correctness Relevance
│ │ │
├──────── Hallucination ──────────┤
│ │
└──────────── Duplication ─────────┘
│
▼
QUALITY SIGNAL
在实践中，这些维度会转化为具体的问题：
- 这些测试是否真正覆盖了所有需求？
- 每个测试用例都与需求相关吗？
- 该智能体是否编造了产品实际上并不具备的功能行为？
- 它是否有遗漏重要的负面情况或边界场景？
- 这十个测试用例中是否有几个实际上是重复的？
每个问题都可以作为评估标准：有些是确定性的（通过标准化文本或嵌入向量进行重复检测），有些需要参考数据集（与已知要求对比），还有一些通常需要以大语言模型作为评判者或依赖人工标注（检测虚构功能）。虽然结构检查如模式有效性仍然值得进行，但应将其作为基准，而非成功的定义。
三种评估维度：响应、步骤与轨迹
在处理智能体时，不必仅评估最终输出。至少有三种有用的评估目标：
- 最终响应：答案是否正确、完整且相关？
- 单个步骤：例如，智能体是否为该子问题选择了合适的工具，并给出了合理的依据？
以下是一个问答智能体的典型路径：
User Goal
│
▼
Agent
│
├── Search Documentation
│
├── Query Database
│
├── Call API
│
└── Generate Answer
最终结果仅为最后一个节点。对于许多应用而言，路径与目标同样重要，例如智能体在查询生产数据之前是否查阅了文档，或者它是否进行了本无需进行的API调用。一旦智能体能够修改数据、创建工单、运行代码、触发工作流或在企业系统内执行操作，轨迹评估就变得至关重要，因为即便最终输出看似正常，若有有害的中间操作存在，依然属于失败。轨迹检查可以是严格的（要求完全按照预期顺序执行）、宽松的（只需包含必要步骤且无禁止步骤），或是通过模型来判定；鉴于上述路径的多样性，宽松的检查通常是最合适的起点。
离线与在线评估合为一轮
评估自然可划分为两种模式，这两种模式与常见的软件开发实践相对应。
离线模式：针对已知案例进行测试
在发布之前，会先使用精心挑选的数据集和场景进行离线评估。你需要用候选版本代理处理代表性案例，为其打分，再与当前版本对比，从而决定是否发布。
Known Dataset
│
▼
Agent Version
│
▼
Run Evals
│
▼
Compare Results
│
▼
Release Decision
这相当于持续集成中的回归测试套件，但针对代理系统。由于模型输出在不同运行中会有差异，因此多次执行每个案例并比较分数分布比仅查看单次结果更为有效。
在线模式：从真实流量中学习
在线评估能够反映生产环境中的实际情况，而生产环境恰恰充满各种意外。用户会提出没人预料到的需求，外部工具可能出故障，上下文信息可能不完整，数据也可能在运行过程中发生变化，此外代理还会采取任何数据集都未涵盖的行进路径。通过对实时日志样本进行评分，就能发现这类问题。
形成闭环
当这两种模式相连时，其价值便会大幅提升：在线发现的每一处有意义的生产故障都会被添加到离线数据集中，以便在后续版本中对其进行测试。
OFFLINE EVALS
│
▼
BUILD
│
▼
DEPLOY
│
▼
PRODUCTION TRACES
│
▼
ONLINE EVALS
│
▼
DISCOVER FAILURE
│
▼
ADD FAILURE TO DATASET
│
└────────► OFFLINE EVALS
随着时间推移，离线测试套件不再反映团队预想的用户行为，而是开始体现用户的实际操作。在将生产环境数据复制到数据集时需格外注意隐私问题；应在敏感字段成为永久性测试数据之前对其进行遮蔽或处理。
智能体行为作为新的质量评估维度
以上内容并不能替代传统测试。对于任何可靠的产品而言，UI测试、API测试、集成测试、数据验证测试、性能测试以及安全测试依然是必不可少的。智能体系统则在此基础上增加了另一层评估维度——即智能体行为的质量。这一层面又引出了新的问题：
- 它选择的工具是否合适？
以模型形式呈现的这些问题与经典的测试金字塔有很大不同：
AGENT QUALITY
│
┌─────────────────┼─────────────────┐
│ │ │
OUTCOME TRAJECTORY CONTEXT
QUALITY QUALITY QUALITY
│ │ │
▼ ▼ ▼
Correctness Tool Usage Groundedness
Relevance Decisions Relevance
Completeness Efficiency Freshness
│
┌────────┴────────┐
│ │
MEMORY RECOVERY
│ │
▼ ▼
Accuracy Failure Handling
Relevance Retry Behavior
结果质量包括正确性、相关性和完整性。轨迹质量涉及工具使用、决策效率，又可细分为内存方面（召回内容的准确性与相关性）和恢复方面（故障处理与重试行为）。上下文质量则涵盖合理性、相关性和时效性。每个节点可对应一个或多个评估指标，这些指标共同提供的信息远比仅用通过/失败来判定最终答案要丰富得多。构建这样的评估体系需要围绕智能体测试、可观测性、轨迹评估、AI回归测试套件、生产环境评分以及持续改进等新方法，这也是质量工程师与AI工程师职责日益重叠的领域。关于同一问题的安全性方面，请参阅我们的指南：LangChain防护机制与中间件。
针对自身智能体项目的实际改进措施
所有这些经验表明，不必采用每一个新功能。相反，更应谨慎考虑架构设计。
- 在设计智能体时就明确评估标准，而非等到其上线后再制定。
- 将可观测性视为初始架构的一部分，而非后续添加的功能。
- 将生产环境中的追踪数据作为反馈反馈给工程团队，而不仅仅是事故处理的证据。
- 确保每一次重大的生产故障都能被纳入未来的评估体系中。
- 根据问题的复杂程度选择合适的方案。有时简单的智能体就足够了；有时需要使用LangGraph进行协调；还有时任务确实需要子智能体、持久化上下文或完整的智能体框架才能高效完成。
技术应当服务于问题，而非相反。
改进循环
框架会不断更迭，但永恒的理念是循环。
LEARN
│
▼
BUILD
│
▼
OBSERVE
│
▼
EVALUATE
│
▼
IMPROVE
│
└──────────► LEARN AGAIN
你先学习某个概念，然后用它来构建事物。构建过程会暴露出你尚未理解的部分，运行则会显现出你未曾预见的问题。评估用证据取代假设，证据推动改进，而改进通常会揭示接下来需要学习的内容。
核心要点
- 智能体是一套决策系统；应评判这些决策，而不仅仅是最终输出的结果。
- 为每个工具明确指定职责：LangChain负责功能实现，LangGraph负责协调管理，LangSmith负责观察与评估。
- 在响应、步骤及整体路径三个层面进行评估，当有效路径存在差异时，宜采用较为宽松的路径检查标准。
- 将在线评估与离线评估相结合，以便将生产环境中的故障转化为回归测试案例。
该领域的模型、框架及托管产品更新迅速，因此请查阅最新文档以了解 LangSmith Engine 和 Managed Deep Agents 等功能。通过观察、测量并将经验反馈至系统，才能在周围环境不断变化的情况下保持智能体的可信度。