AI 编码智能体的行为评估框架

# 驾具工程剖析：如何评估、迭代并守护 AI 编码智能体

开发者初次为智能体编码系统做驾具工程时，往往会陷入同一个陷阱：他们运行 Terminal-Bench、DeepSWE 等常见端到端基准测试，看到综合分数变动几个百分点，却完全不知道原因。

端到端基准测试是评估模型性能、确定深入调查方向的事实标准，但这类调查的代价往往高昂。

行为评估通常能更好地衡量：你所期望的行为是否真的发生了？在处理回归问题或新模型变更时，你究竟是在向正确方向前进，还是在倒退？行为评估可以充当迭代伙伴，帮助你洞察某些变更为何会以某种方式影响结果。

以下是我们对行为评估的见解，包括在模型持续演进过程中帮助我们保持智能体系统可靠性的各种方法。

作者：@ntaylormullen 与 @chgunderman

## 范式转变：成绩单 vs. 行为路标

大多数团队评估 AI 智能体的方式，就像评估一个参加考试的学生：将一个大型代码库交给智能体，给它设定时间限制，然后根据测试通过或失败的数量来衡量其成功与否。

当分数下降时，究竟哪里出了问题？

- 模型是否对模糊提示过度自信？

- 它是否忘记在提交前验证测试套件？

- 它是否产生了虚构的 CLI 标志？

端到端基准测试通常无法直接回答这些问题。

行为评估的功能类似于改进智能体驾具操作的集成测试。当你拥有足够丰富的行为评估集时，你就有了一条基线，明确了智能体应达到的目标行为，并且能够通过迭代优化提示词来逐步实现它。

行为评估不衡量智能体是否完成了整个多文件重构，而是衡量离散、可观察的动作：

- 面对描述不清的提示，智能体是否会提出澄清问题，而不是凭空猜测？

- 修改构建文件时，它是否会在声明完成之前运行本地验证器？

- 生成文档时，它是否会提供规范的仓库链接？

## 何时评估：自用先行原则

不要在第一天就搭建复杂的评估框架，而应将这段时间用于追随直觉、运行实验。

从零开始构建智能体时，起点是开发者的直觉和自用（dogfooding）。在智能体能够自用自身代码库、处理样板代码、编写自己的 Markdown 渲染器并执行常规开发任务之前，运行评估并无意义。

评估属于开发的第二阶段：确保持续前进并防范回归。

评估套件的首要目的并非庆祝智能体提升了 2%，而是让你对以下事项保有坚定信心：一次新的提示词调整、工具模式变更或模型升级，没有让智能体整体变得更差。

## 行为评估架构的工作原理

一个健壮的驾具评估框架，会将行为断言分离为快速、确定性的单元测试式检查，并在本地运行。

将焦点转移到这些更小的、可观察的行为上，能够构建一个可靠的安全网。你可以放心地迭代系统提示词，或切换到不同的模型，因为一旦不小心破坏了某个核心行为，你会立刻发现。

编写行为评估

行为评估针对中间执行步骤进行断言，例如特定的工具调用或文件修改，而不是最终字符串的相等性比较：

示例基于 Antigravity SDK 编写。浏览完整代码仓库。(https://github.com/google-antigravity/antigravity-sdk-python)

有了丰富的行为评估套件，你就可以将提示词工程自动化。例如，你可以设置一个循环，让 LLM 自行调整其系统提示词，不断迭代直到某个失败的测试最终通过，与此同时，测试套件的其余部分则类似于 CI/CD 风格的护栏在运行。这有助于确保变更不会破坏任何已有功能。

## 构建行为测试套件时需要考虑什么

从一开始就可以做一些事情，使这个过程具备可重复性。我建议从一个三步行为测试循环开始，由小及大：

1. 选定一个失败模式：找到你的智能体最近犯下的一个错误，例如在将任务标记为完成之前忘记运行单元测试。找到那个明显被遗漏的单一行为，将其作为目标。

1. 根据任务复杂度编写灵活的断言：对于只有一个最优解的简单任务，构建严格的单轮断言，检查智能体是否达到了特定里程碑（例如，验证它是否调用了测试运行器）。然而，对于更复杂的任务，模型可能会走一条意想不到但完全正确的路径。在这类场景中，避免强制要求固定的工具调用顺序。转而使用更模糊的、基于结果的检查，例如以 LLM 作为评判者，来评估智能体所选步骤是否成功且安全地解决了问题。

1. 自动化批量评估以监测稳定性：不要因为单次评估运行可能因 AI 模型的非确定性而产生噪声，就将其作为阻塞 PR 的门槛，而应自动化批量评估来获取更大量的数据。随时间追踪聚合通过率，确保模型行为朝着正确方向发展。依赖这种方向性信号，让你在调整提示词和升级模型时能够安全推进，而不必因预期内的方差而停滞开发。

你的智能体不需要更高的基准测试分数才能起步。它需要的是一套让它保持诚实的评估框架。

要构建一个稳定且有弹性的框架，你必须停止将模型视为一个只需通过期末考试的黑箱，转而像对待需要单元测试和集成测试的标准软件一样对待你的框架。

## 最后的思考

尽管行为评估是框架工程的核心支柱，但它并不能取代更大规模的端到端评估套件，两者实际上是互补的。宏观基准测试验证最终目的地，微观行为评估则作为一个搭档，支持安全、快速的迭代。当你同时采用两者时，在进行迭代时——无论是修改提示词、开发新功能，还是部署全新模型——你都将拥有更高的信心。