The 3 questions every agent builder should be able to answer:

✅ Where the agent fails ✅ How to reproduce it ✅ How to make it stop

Watch @JakeBroekhuizen’s session: https://t.co/yQkzaV0GVt https://t.co/YFfv9Dtf52

TL;DR：拥有“自己的智能“，意味着能回答三个问题——Agent 在哪里失败、如何可靠复现失败、以及如何让它不再失败。

拥有自己的智能：每个 Agent 构建者都应能回答的三个问题

开场：从实践者视角谈“拥有你自己的智能“

欢迎大家。这是 LangChain 的新办公室，很高兴大家能来。我将从实践者的角度探讨“拥有你自己的智能“意味着什么——面向那些正在用 Agent 构建应用的人，面向那些在构建和改进 Agent 的过程中可能正经历各种流程的人。

三个核心问题

任何在构建 Agent 的人都需要牢牢掌握三个核心问题。如果能很好地回答这三个问题，就可以明确地说，你拥有了你自己的智能。

1. Agent 在哪里会失败？ 不仅要理解 Agent 是否失败了，还要理解我们如何让它再次失败。
2. 如何复现这些失败？
3. 需要做什么才能让它在未来不再失败？

这显然是通往构建能够不断自我改进的 Agent 的关键一步，也是通往完全掌控你的模型（也许包括权重）、以及你所有的运行框架（harness）的关键。

第一个问题：理解 Agent 在哪里失败

要真正理解你的 Agent 为什么以及如何失败，需要对追踪（tracing）和理解 Agent 的行为有非常深入的掌握。而这通常来自于挖掘你的 Agent 的生产环境追踪数据。

构建一个 Agent，如果你在做追踪的话，你会拥有大量的轨迹数据，以及对 Agent 所采取的各种不同行为的理解。在所有这些数据中，会有大量有价值的信号，比如：

• Agent 成功调用了某个工具
• Agent 错误地调用了某个工具
• Agent 因为缺乏正确的上下文而导致用户感到沮丧

你的 Agent 追踪数据中蕴含着各种各样的信号，尤其是生产环境的追踪数据。这是判断 Agent 是否失败时非常重要的一个需要捕捉的要素。

规模化的挑战：用专门的评判模型挖掘信号

问题在于规模化操作。如果你的 Agent 每天有数千次甚至数百万次运行，想要规模化地理解 Agent 是否按预期执行就非常困难。使用前沿模型作为评判者、LLM-as-Judge、在线评估器当然非常有效，但在大规模场景下成本也非常高。

举个例子，LangChain 采用的方法之一——也是你可以借鉴的方式——是制作专门用于评估的评判模型（judge），去提取和挖掘 Agent 的生产环境信号。

我们在 LangChain 最近就做了这件事：进行了微调、标注，制作了一个评判模型，用来判断 Agent 是否为用户提供了良好的体验，以及是否存在可感知的错误。比如：

• Agent 让用户感到沮丧
• Agent 做了一连串的工具调用最终导致了错误的操作，而用户期望的是另一件事

能够在规模化的情况下对 Agent 的行为进行某种形式的监控和理解，是判断 Agent 是否失败的重要一步。这也是将随着 Agent 构建和改进而开始出现的各种行为模式和失败机制进行聚类的重要方式。

第二个问题：可靠地复现 Agent 的失败

这只是旅程的第一步。一旦我们知道并分类了 Agent 的行为，接下来还需要采取一系列后续步骤，来复现这些问题，并随着问题的持续出现来实际修复它们。

在过去的六七个月里，这方面发生了非常显著的变化。

从输入输出评估到环境模拟

以往典型的做法——或者说比较浅层的做法——是简单地评估给定输入后 Agent 的输出是否符合预期行为。这在捕捉各种 Agent 失败机制方面非常强大，但往往无法涵盖全貌。

原因在于，Agent 的行为可能受到其所处环境中外部因素的影响：

• 它所交互的数据库状态
• 它拥有的权限
• 它所使用的特定 Schema
• 它之前执行的操作所导致的当前环境状态

因此，我们真正需要的是一种能够模拟 Agent 在生产环境中所依赖的更广泛应用机制的方法。这就引出了通过构建一种方式来模拟 Agent 所存在的世界或环境，从而构建更稳健的评估。

用“规范“（Specification）定义 Agent 的世界

这是一个迭代的过程。LangChain 找到的一种相当成功的做法，是通过“规范“的概念来定义 Agent 的世界以及其中的任务。

具体来说，需要一个通用的世界规范（world spec），定义在 Agent 的世界中不会发生变化的事物，比如：

• 权限
• Agent 可访问的领域特定规则
• 文件系统的状态
• 它所交互的依赖关系

这些都是在 Agent 的操作空间中不随其行为而改变的事物。

案例：LangChain 的 GTM Agent

我们在 LangChain 有一个非常常用的内部 Agent，叫做 GTM Agent。我们的 Go-to-Market 团队会用它来做竞争情报调研，比如调研交易中竞争对手的情况，或者分析某个商机的管道情况。

在那种情况下，“世界“就是该 Agent 需要交互的所有系统：Gong、Salesforce、Calendly、Google Calendar——也就是它在被我们所有销售人员使用时所接触和交互的那些系统。

世界中的任务代表 Agent 需要采取的具体行动或任务，它们会被用来测试并希望能暴露出你想要测试的各种涌现行为。一个任务示例是：研究某个客户的全部 Gong 转录记录，帮助我起草下一步的最佳触达方案。

这远远超出了简单基于输入输出的评估。

警惕 Reward Hacking

在创建这些世界、制定这些规范、并让编码 Agent（coding agent）并行协助开发的过程中，我们发现 Agent 本身在构建这些内容时表现并不太好，或者说需要持续的监督和指导。

因此，非常重要的一点是确保 Agent 定义的任务：

• 既能可靠地具有挑战性，能让你持续改进 Agent
• 又不能存在让 Agent 设计出容易被**奖励作弊（reward hacking）**的任务的情况

这确保我们所开发的世界和提供给 Agent 的任务具有足够的难度，从而使我们所做的改进是可量化的，并且真正模拟了 Agent 在生产环境中的行为。

应用层开发者的数据优势

一旦我们拥有了这种机制——能够创建和发展一个 Agent，让它在一个真正模拟其运行环境的世界中解决问题——我们就有能力将我们从生产环境运行 Agent 中获得的数据转化为这类任务、这类世界。

大卫对歌利亚的局面

毫不意外，当今最好的一些模型由前沿实验室生产。他们能够用于获取数据、构建这些世界和任务的资本远超普通应用层公司所能承担的范围。一个经典案例：Google 对 Spirit Airlines 提出了 1000 万美元的要约——不是为了收购公司，而是为了购买内部 Slack 备忘录、邮件和文档，因为显然所有这些都会被用来开发任务和训练数据集，以产出更好的模型。

但这有点像大卫对歌利亚的局面。因为与前沿实验室不同，应用开发者和应用所有者能够看到人们使用 Agent 的那些极端和长尾场景。正因如此，他们能够：

• 从遥测数据中生成数据
• 理解真实用户如何与 Agent 交互和使用它
• 开发出前沿实验室永远无法开发的任务和环境

一旦我们从 Agent 的追踪数据中获得了这些信息，我们就能真正设计出强大的任务和世界，来帮助改进我们的 Agent。

这自然变成了一个数据处理问题——需要去重、需要各种不同的方式将这些追踪数据转化为可靠的任务。但一旦完成，我们就拥有了 Agent 进一步改进和发展的基础，也拥有了一个强大的基准和起点，能够进行量化的 Agent 改进。

第三个问题：如何让 Agent 不再失败

一旦我们有了一个世界，有了该世界中的一组任务——理想情况下，每个任务都针对你在 Agent 中观察到的某种失败模式——真正的变革就发生在两个层面。这是“拥有你自己的智能“真正开始产生复利效应的地方，因为现在你可以在所有层面上灵活地进行改变。

Harness 层面的改变

• 提示词（prompt）的更改
• 工具 Schema 的更改
• 改变上下文注入的方式，使 Agent 在给定特定任务时能以特定方式回答

模型层面的改变

我不会深入太多，因为我知道 Charlie 接下来会介绍在这个层面可以进行的各种后训练技术。但同样，现在你有了灵活性，可以选择你偏好的后训练算法并进行更改，帮助缓解你想要测试并最终解决的问题。

完成之后，我们可以重新运行测试，确认在该环境中的 Agent 能够通过那些特定任务，并开始按照我们期望的方式表现。

应对变化：持续测试的能力

一旦我们建立了一个稳健的环境或世界和一组任务，随着模型的发展：

• 我们测试的部分内容必然会变化，回归问题也会被引入
• 同时我们为解决 Agent 特定缺陷而设计的部分也会被吸收到模型中

我们一直看到框架的部分能力——无论是长任务分解还是动态工具路由——都在被吸收到模型层中。我们会看到这种变化，但我们将能够对其进行测试，因为我们现在有了一种稳健的方式来实际模拟 Agent 在生产环境中的行为。

同时，人们使用你 Agent 的交互模式显然也会改变。由于我们现在拥有这种非常稳健和强大的测试方式，我们仍然可以有效地测试并判断 Agent 在这些特定交互模式下是否能经受住考验。

结语

真正拥有你自己的智能，归根结底是能够适应模型改进时的变化，适应用户交互模式的变化。作为构建者，一旦我们意识到这一点，一旦我们建立了通过稳健环境和不同任务来测试各种行为的机制，我们就能够在这个快速变化的世界中保持领先。

Source: @LangChain — 拥有自己的智能：每个 Agent 构建者都应能回答的三个问题