线束工程：AI Agent的行为评估

# 线束工程：让你的AI Agent每次失误后都能变得更聪明。

AI编程Agent能够检查代码仓库、编辑文件、运行命令，并在几乎不需要人工干预的情况下完成任务。

设想一个Agent被要求更新构建配置。它修改了正确的文件并报告任务已完成。项目成功构建，因此端到端测试将此次运行标记为成功。

然而，这里存在一个问题。该Agent从未运行项目的验证器。这次结果碰巧是正确的，但Agent跳过了一个在下次任务中可能至关重要的步骤。

谷歌关于线束工程的新指南从行为评估的角度审视了这一问题。线束不仅可以检查Agent的最终答案，还可以检查Agent在执行过程中实际采取了哪些步骤，而不是将最终答案作为唯一的测试标准。

## 成功的结果并不能告诉你Agent是如何得出答案的

大多数评估最终都只回答一个问题：任务是否成功？

这对于衡量Agent能完成什么任务很有帮助，但几乎无法提供关于产生该结果的执行过程的信息。如果Agent失败了，最终得分并不一定能告诉你问题出在哪里——是选错了工具、误解了请求、编辑了错误的文件、跳过了必要的检查，还是未能从错误中恢复。行为评估则能让这些中间步骤变得可见。

当Agent在模型、提示词、工具或线束发生变更后开始表现异常时，这为工程师提供了更有价值的排查依据。

## 行为评估测试的是执行过程，而非仅仅是答案

谷歌的指南给出了几个可以独立检验的行为示例。

如果请求描述不够明确，期望的行为可能是向用户寻求澄清，而不是自行假设。如果编程任务需要验证，Agent应在声明变更完成之前运行验证器。对于生成的文档，要求可能是仓库链接必须指向权威来源。每项要求都可以对照Agent的执行轨迹进行检验。

谷歌以其Antigravity SDK为例进行了演示。在一个示例中，Agent被询问实时天气状况，评估会检查响应过程中所使用的工具：

tools = [call.name async for call in response.tool_calls]

assert types.BuiltinTools.SEARCH_WEB in tools

这条断言并不是在检查最终答案是否听起来像一个实时天气响应，而是检查网络搜索工具是否真的被调用了。每当某个特定操作本身是需求的一部分时，这一区别就显得尤为重要。

同样的模式也适用于编程Agent。如果一个Agent反复修改配置文件却不运行验证器，那么这个被跳过的验证步骤就可以成为未来运行的测试用例，而不仅仅停留在某次失败执行的备注记录中。

## 一次失败可以成为线束的一部分

再回到构建配置的例子。Agent正确地完成了编辑，但跳过了验证命令。这个缺失的行为就是编写测试的起点。

在这里，需求很简单：验证器必须在任务被视为完成之前运行。

因此，一个概念性的检查可以是：

assert agent_ran_validator

具体实现取决于Agent框架以及它暴露执行事件的方式。重要的是这个测试的来源：一次真实的失败。

一旦这种检查机制存在，每当智能体发生变化时，它就可以被重新运行。新模型可能会提升其编码能力，但在验证的一致性上却有所下降。新的工具定义可能会改变它处理任务的方式。提示词的变动可能会影响其工具选择。

这正是测试框架超越指令与工具集合的地方。它开始承载着关于那些已经引发过问题的行为的知识。

能够复现的失败可以转化为测试用例。随每次变更自动运行的测试，可以成为框架的一部分。

## 一次成功的运行还不够

假设某个智能体在回答依赖最新信息的问题之前，需要先进行网络搜索。它在一次运行中正确地执行了搜索。但在另一次运行中，它直接依据模型已有的信息作出回答。任务本身没有任何变化，但行为却不同了。

反复运行评估，能让这种差异变得可见。你不再只是记录智能体是否完成了某项任务，而是可以衡量它遵循预期行为的频率。

Google 建议关注聚合通过率，因为智能体的单次执行结果可能存在波动。这在对比不同版本的模型、提示词、工具配置或测试框架时尤为有用。反复运行能揭示某种行为究竟是稳定可靠的，还是只是偶然发生的。

## 测试应描述一项要求，而非某条特定路径

行为测试也可能变得过于严苛。假设要求是：智能体在完成任务之前必须对代码变更进行验证。一种测试方式是记录某次成功运行的精确操作序列，并要求后续版本遵循同样的序列。

这样做很脆弱。智能体可能会找到另一条同样满足要求的路径。

例如，测试不应该强制要求智能体依次使用工具 A、工具 B、再使用工具 C。如果多条路径都能产生经过正确验证的结果，这些路径都应当被视为有效。

因此，评估应当聚焦于真正重要的要求。如果运行验证器是必不可少的，就检查验证器是否已运行。如果多种不同的工具都能满足同一需求，评估就可以关注最终的行为结果，而非某一特定的工具使用序列。

Google 对直接行为断言与更灵活的评估方式之间的区别进行了探讨。对于难以用简单布尔条件表达的行为，Google 还讨论了使用 LLM 作为裁判的方案。这可以提供更全面的评估，但裁判本身也会成为一个需要被测试的组件。

## 智能体循环为框架提供了评估对象

Anthropic 在循环工程方面的工作，强调了验证在推动智能体持续迈向有效结果中所扮演的角色。

智能体循环赋予智能体反复行动、检视结果、并继续推进或纠正工作的机会。验证机制正是告知循环上一步操作是否真正成功的手段。

LangChain 关注的是框架的另一个层面：如何在多个智能体之间组织上下文。在其 Deep Agents 框架中，子智能体可以在独立的上下文中运行，也可以通过分叉上下文继承主管智能体的当前状态。继续执行调查任务的工作者智能体可以利用继承的上下文来避免重复工作，而验证器则可以使用独立的上下文来审查结果，从而不受主管智能体推理过程的影响。

工具链为这一过程提供了围绕其运行的条件：可供智能体使用的工具、其执行环境、约束条件、状态，以及用于检查重要行为的评估机制。

对于编程智能体而言，验证可能意味着在编辑文件后运行测试。在另一个系统中，它可能意味着验证生成的文件、检查数据库操作，或确认某个必要工具已被调用。循环决定接下来发生什么，而工具链则提供用于判断上一步骤是否可接受的检查机制。

## 一个小型评估循环就足以作为起点

一个概念性回归检查可能如下所示：

def test_build_change_is_verified(result):

assert result.used_validator

assert result.final_status == "verified"

这不是 Google 的 Antigravity API，而是对该模式的一个简化示例。

在实际实现中，`used_validator` 可以从记录的工具调用、Shell 执行或智能体追踪中的其他事件中派生出来。该模式很简单：捕获一次真实的失败，识别其中关键的行为，将针对该行为的检查编码化，并在未来的执行中持续运行该检查。随着时间推移，这些检查将演变为一个针对系统重要行为的回归测试套件。

## 行为评估不能替代端到端测试

行为评估并不能替代对智能体是否能够完成任务的测试。一个智能体可以使用正确的工具、遵循预期的验证流程，却仍然无法完成整体任务。反之亦然——智能体可能产出了正确的最终结果，却跳过了对可靠性至关重要的某些行为。

这两种评估回答的是不同的问题。OpenAI 也指出，工具链本身可能影响评估结果。其评估指南指出，工具、状态管理、重试机制以及设置的其他部分，都可能影响智能体在多步骤任务中的表现。

端到端评估衡量的是智能体能否完成任务。

行为评估揭示的是智能体执行任务过程中的重要细节。

同时使用两者，能让工程师在模型、提示、工具或工具链发生变更时，更清晰地了解究竟是什么发生了改变。

## 工具链可以将失败转化为永久性检查

智能体的一次失败不必在即时任务修复后便消失无踪。如果该失败揭示了某个重要行为，那么这一行为可以转化为一项评估指标。下一版本的智能体随后必须通过同样的检查。

随着时间推移，工具链将成为一份记录，载录系统已经历过的问题，以及为防止这些问题重现而添加的行为检查。模型负责推理和执行操作，工具链则提供环境、观察执行过程，并在系统演进时持续检验重要行为是否依然成立。

一个可靠的智能体，不仅仅是能够完成任务的智能体，而是其重要行为可以在系统演进时被反复测量和验证的智能体。

📌 AI 智能体驱动真实业务成果。让我们为您构建，预约探索通话：https://juteq.ca/

📌我专为真正在使用 AI 智能体进行构建的人解码 AI 智能体。如果你正是其中之一，我们应该建立连接：https://www.linkedin.com/in/rakeshgohel01/

AI #AIEngineering #AIAgents #AgenticAI #HarnessEngineering

参考资料：

- 工具链工程的解析：https://developers.googleblog.com/the-anatomy-of-harness-engineering-how-to-evaluate-iterate-and-guard-ai-coding-agents