AI编程代理的评估与迭代方法论

当开发者首次从事 Agent 编码系统的 Harness Engineering 时，往往会落入同一个陷阱：运行 Terminal-Bench 和 DeepSWE 等常见的端到端基准测试，看着一个综合分数变动几个百分点，却完全不知道为什么会变。

端到端基准测试是评估模型性能和确定哪些地方需要深入研究的事实标准，但问题在于这些深入研究代价高昂。

在判断你所期望的行为是否真正发生、以及在面对回归或新模型变更时是否在朝着正确方向前进而不是倒退方面，行为评估往往是更好的信心度量。它们可以充当你的迭代伙伴，帮助洞察为什么某些变更以某种方式推动了指标变化。

以下是我们对行为评估的看法，包括帮助我们在模型演进过程中保持 Agent 系统可靠性的方法。

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

大多数团队评估 AI Agent 的方式类似于评估参加考试的学生。他们给 Agent 一个大型代码库，设定时间限制，然后根据有多少测试通过或失败来衡量其成功。

当分数下降时，问题出在哪里？

是模型在模糊提示词上过于自信了？

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

是它幻觉出了一个 CLI 参数？

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

行为评估的功能类似于改进 Agent Harness 操作的集成测试。当你有一个足够丰富的行为评估集时，你就有了从 Agent 那里获取目标行为的基础，并且能够迭代地改进提示词来达到目标。

与其衡量 Agent 是否解决了整个多文件重构，不如用行为评估来衡量离散的、可观察的动作：

当收到一个未完整指定的提示词时，Agent 是会提出澄清问题而不是猜测？

当修改构建文件时，Agent 是否会在宣布完成前运行本地验证器？

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

何时评估：吃自己狗粮的先例

不要在第一天就建立复杂的评估 Harness，利用这段时间跟随你的直觉做实验。

从头引导一个 Agent 时，你从开发者的直觉和吃自己狗粮（dogfooding）开始。直到你已经构建出一个能够对自己的代码库进行狗粮测试、处理样板代码、编写自己的 Markdown 渲染器、并执行日常开发者任务的 Agent 之前，跑评估都没有意义。

评估属于开发的第二个阶段：确保前进方向并防止回归。

评估套件的主要目的不是在 Agent 提升 2% 时庆祝，而是给你一个坚定不移的信心——确保新的提示词调整、工具 Schema 变更或模型升级没有让 Agent 整体变差。

行为评估架构如何工作

一个健壮的 Harness 评估框架将行为断言分离为快速的、确定性的、类似单元检查的风格，在本地运行。

将注意力转移到这些更小、更可观察的动作上，可以创建一个可靠的 safety net。你可以自信地迭代系统提示词或切换到不同的模型，因为如果意外破坏了某个核心行为，你会立即知道。

编写行为评估

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

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."
  )

有了丰富的行为评估套件，你可以自动化提示词工程。例如，你可以设置一个循环，让 LLM 调整自己的系统提示词，反复迭代直到一个失败的测试最终通过，而套件中的其余测试则类似于 CI/CD 风格的 guardrail 那样运作。这有助于确保变更不会破坏任何现有功能。

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

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

选择一种失败模式：找到你 Agent 最近犯的一个错误，比如在将任务标记为完成前忘记运行单元测试。找到一个滑落的单一、明显的动作，并将其作为目标。

根据任务复杂度编写灵活的断言：对于只有一个最优解的简单任务，构建一个严格的一次性断言，检查 Agent 是否达到了特定里程碑（例如验证它是否调用了测试运行器）。然而，对于更复杂的任务，模型可能会采取一条出乎意料但完全正确的路径。在这些场景下，避免强制执行僵硬的工具序列，而是使用更模糊的、基于结果的检查，例如 LLM-as-a-judge，来评估 Agent 所选步骤是否成功且安全地解决了问题。

自动化批量评估以监控稳定性：不要因为 AI 模型的非确定性导致单次评估运行可能有噪声，就在 PR 上设置阻塞，而是自动化批量评估以拉取更大体量的数据。追踪随时间变化的总体通过率可以确保模型的行为趋势正确。依赖这种方向性信号可以让你安全地调整提示词和升级模型，而不会因为预期的差异而停止开发。

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

你的 Agent 不需要更高的基准测试分数才能开始。它需要一个让它保持诚实的评估 Harness。

要构建一个稳定、有弹性的 Harness，你必须停止把模型当作通过最终考试的 黑盒，而是开始把 Harness 当作需要单元测试和集成测试的标准软件。

虽然行为评估是 Harness Engineering 的核心支柱，但它们并不能替代更大规模的端到端评估套件。实际上，它们是互补的。宏观基准验证最终目的地，而微观行为评估则充当一个伙伴，使安全、快速迭代成为可能。当你同时采用两者时，在迭代时会有更高的信心——比如进行提示词变更、构建新功能，甚至部署全新模型时。