Google 讲解 Harness 工程：如何评估、迭代并守护 AI 编码 Agent

2026年9月9日

当开发者首次为智能体编程系统进行 harness 工程时，他们常常会掉进同一个陷阱：他们运行像 Terminal-Bench 和 DeepSWE 这样的常见端到端基准测试，看着综合得分变动几个百分点，却完全不知道为什么会变。

端到端基准测试是评估模型性能、确定哪些地方需要深入调查的事实标准，但挑战在于，这些调查的成本很高。

行为评估往往能更好地衡量信心——判断你期望的行为是否真的发生，以及你是在朝着正确方向前进，还是在回归问题或新模型变更方面出现倒退。它们可以充当你的迭代伙伴，帮助揭示为什么某些改动会以某种方式产生影响。

以下是我们对行为评估的看法，包括一些帮助我们随着模型演进而保持智能体系统可靠的方法。

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

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

当分数下降时，出了什么问题？

• 模型是否在模糊的提示上变得过度自信？
• 它是否忘记在提交前验证测试套件？
• 它是否幻觉出了一个 CLI 标志？

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

行为评估的作用类似于集成测试，用于改进智能体 harness 的运行。当你拥有足够丰富的行为评估集时，你就有了针对智能体目标行为的基线，并且能够迭代改进提示词以达到目标。

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

• 当收到一个描述不充分的提示时，智能体是提出澄清问题，还是进行猜测？
• 当修改构建文件时，它是否在宣布完成之前运行本地验证器？
• 当生成文档时，它是否提供规范的仓库链接？

何时评估：dogfooding 的先例

与其在第一天就搭建复杂的评估 harness，不如利用这段时间跟随你的直觉并运行实验。

从零开始引导一个智能体时，你从开发者直觉和 dogfooding 开始。在你构建出一个能够 dogfood 自己的代码库、处理样板代码、编写自己的 markdown 渲染器并执行日常开发者任务的智能体之前，运行评估是没有意义的。

评估属于开发的第二阶段：确保向前推进和防范回归。

评估套件的主要目的不是在你让智能体变好 2% 时庆祝；而是给你不可动摇的信心，确信新的提示词调整、工具 schema 变更或模型升级没有让智能体整体上变得更糟。

行为评估架构如何运作

一个稳健的 harness 评估框架将行为断言拆分为快速、确定性的、单元风格的检查，并在本地运行。

将你的焦点转向这些更小的、可观察的动作，会创建一个可靠的安全网。你可以自信地迭代系统提示词或切换到不同的模型，因为你会立即知道是否意外破坏了某个核心行为。

编写行为评估

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

import pytest
from google.antigravity import Agent, LocalAgentConfig, types

@pytest.mark.asyncio
async def test_agent_uses_web_search_for_live_weather():
  """Assert that the agent consults ground truth rather than guessing."""
  config = LocalAgentConfig()

  async with Agent(config) as agent:
    response = await agent.chat("What's the weather like in Mountain View, California?")
    tools = [call.name async for call in response.tool_calls]

  # Assert behavior, not output prose
  assert types.BuiltinTools.SEARCH_WEB in tools, (
      "Agent answered from memory without consulting live search."
  )

Python

已复制

为 Antigravity SDK 编写的示例。探索完整仓库。

借助一套丰富的行为评估，你可以自动化你的提示工程。例如，你可以设置一个循环，让 LLM 调整自己的系统提示，不断迭代，直到某个失败的测试最终通过，同时你的其余测试套件则像 CI/CD 风格的护栏一样运作。这有助于你确保这些更改不会破坏任何现有功能。

构建行为测试套件时需要考虑的事项

从一开始你就可以做一些事情，让这个过程可重复。我建议你从小处着手，采用三步行为测试循环：

1. 选择一个失败模式：找出你的 agent 最近犯的一个错误，比如在将任务标记为完成之前忘记运行单元测试。找出一个单一、明显的疏漏动作，并将其作为你的目标。
2. 根据任务复杂度编写灵活的断言：对于只有一个最优解的简单任务，构建严格的单轮断言，检查 agent 是否达到了某个特定里程碑（例如，验证它调用了测试运行器）。然而，对于更复杂的任务，模型可能会走一条出乎意料但完全正确的路径。在这些场景中，避免强制要求固定的工具调用顺序。相反，使用更模糊、基于结果的检查，例如 LLM-as-a-judge，来评估 agent 所选择的步骤是否成功且安全地解决了问题。
3. 自动化批量评估以监控稳定性：与其因为单次评估运行可能因 AI 模型的非确定性而产生噪声就阻塞 PR，不如自动化批量评估以获取更大规模的数据。长期跟踪总体通过率可确保模型的行为朝着正确方向发展。依赖这种方向性信号，让你能够灵活地调整提示并安全地升级模型，而不会因为预期内的波动而中断开发。

# Run local behavioral suite in under 5 seconds
pytest evals/behavioral/ -v

Shell

已复制

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

要构建一个稳定、有韧性的框架，你必须停止把你的模型当作一个通过期末考试的黒盒，而是开始把你的框架当作需要单元测试和集成测试的标准软件。

最后的思考

虽然行为评估是框架工程的核心支柱，但它们并不能取代更大规模的端到端评估套件。它们实际上是互补的。宏观基准验证最终目的地，而微观行为评估则作为伙伴，支持安全、快速的迭代。当你同时采用两者时，在迭代时——比如进行提示更改、构建新功能，甚至部署全新模型——你将拥有更高的信心。

上一篇

下一篇