The Anatomy of Harness Engineering: How to Evaluate, Iterate, and Guard AI Coding Agents

发布时间 2026-09-21 10 天前
来源 Google Developers Blog
字数 3,155 字
查看原文

AI智能总结

奇安工程师 Taylor Mullen 与 Christian Gunderman 指出,端到端基准(如 Terminal-Bench、DeepSWE)虽能衡量 AI 编程智能体整体表现,但难以解释分数波动的具体原因。

Harness(智能体执行框架)工程的解剖:如何评估、迭代并守护 AI 编程智能体

2026 年 9 月 9 日 Taylor Mullen 首席工程师  Christian Gunderman 资深软件工程师

BlogBanner_990x556_x2

当开发者首次着手为智能体式(agentic)编程系统做 Harness 工程时,往往会掉进同一个陷阱:他们跑一些常见的端到端基准,比如 Terminal-Bench 和 DeepSWE,看着一个综合分数上下波动几个百分点,却完全不知道分数变化背后的原因。

端到端基准是评估模型性能、决定哪些方向值得深入调查的事实标准,但问题在于,这些深入调查的成本非常高昂。

行为评估(Behavioral Evaluations)通常是更能带来信心的衡量方式——它能告诉你,你期望发生的行为是否真的发生了,以及当你面对回归问题或更换新模型时,整体方向是在前进还是在倒退。它可以充当你的迭代伙伴,并帮助你洞察为什么某些改动会让结果向一个方向或另一个方向偏移。

以下是我们对行为评估的看法,包括那些在模型持续演进过程中帮助我们保持智能体系统可靠性的实践方法。

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

大多数团队评估 AI 智能体的方式,和评估一个参加考试的学生没什么两样:丢给智能体一个庞大的代码仓库,给它设定一个时间限制,再根据它通过了多少测试来判断是否成功。

当这个分数下滑时,究竟是哪一步出了问题?

  • 模型是否在模糊不清的提示面前变得过度自信?
  • 它是否忘了在提交之前验证一下测试套件?
  • 它是否凭空捏造了一个根本不存在的命令行参数?

端到端基准通常并不能直接回答这些问题。

行为评估则像集成测试一样,帮助你改进智能体 Harness 的运行机制。当你拥有足够丰富的行为评估集时,你就拥有了一条基线——针对你期望智能体表现出的行为——并且能够通过反复迭代提示词来达成目标。

行为评估不去衡量智能体是否完成了一次跨多文件的整体重构,而是衡量一个个离散的、可观测的动作:

  • 当面对一个描述不够具体的提示时,智能体是否会先提出澄清问题,而不是擅自猜测?
  • 当修改构建文件时,它是否会在宣称完成之前先跑一遍本地校验?
  • 当生成文档时,它是否会附带规范的代码仓库链接?

Screenshot 2026-09-09 at 9.34.40 AM

何时进行评估:「自家狗粮喂养」的先例

不要在第一天就搭建一套复杂的评估体系,而是把这段时间用来跟随直觉、做实验。

从零开始引导一个智能体时,你最初的依靠是开发者的直觉和「自家狗粮喂养」(dogfooding)。在你打造出一个能够「自给自足」、能处理样板代码、能自己写 Markdown 渲染器、能执行日常开发任务的智能体之前,贸然跑评估并没有意义。

评估属于开发流程的第二个阶段:确保前进的进度,以及防范回归。

评估套件的首要目的并不是在你让智能体变好 2% 时弹冠相庆,而是给你一份不可动摇的信心——让你确信一次新的提示词微调、工具结构变更或模型升级,并没有让智能体整体变差。

行为评估架构是如何运作的

一套健壮的 Harness 评估框架会把行为断言拆分成快速、可确定、本地即可运行的「单元式」检查。

把关注点转移到这些更小、更可观测的动作上,就能构建出一张可靠的安全网。你可以放心地迭代系统提示词,或切换到不同的模型,因为一旦你不小心破坏了某个核心行为,你能立刻知道。

编写一个行为评估

行为评估断言的是中间执行步骤(例如具体的工具调用或文件修改),而不是最终字符串是否相等:

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

@pytest.mark.asyncio
async def test_agent_uses_web_search_for_live_weather():
  """断言智能体应当查询真实信息,而非凭空猜测。"""
  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 types.BuiltinTools.SEARCH_WEB in tools, (
      "Agent answered from memory without consulting live search."
  )

Python 已复制  示例代码面向 Antigravity SDK 编写。查看完整代码仓库。

拥有一套丰富的行为评估之后,你就可以把提示词工程自动化。比如,你可以搭一个循环,让一个大语言模型自己微调系统提示词,反复迭代,直到一个原本失败的行为评估终于通过;与此同时,你的其余测试套件就像 CI/CD 流水线中的护栏一样运行,确保改动不会破坏既有功能。

构建行为评估套件时需要考虑什么

有若干件事你从一开始就可以做,让这个过程具备可重复性。建议你从一个三步行为测试循环开始,小步快跑:

  1. 挑选一个失败模式:找出一个智能体近期犯过的错误,比如在把任务标记为完成之前忘了跑单元测试。锁定那个明显遗漏的单一动作,把它当作本次的目标。
  2. 根据任务复杂度编写灵活的断言:对于只有一个最优解的简单任务,构建一个严格、单轮的断言,检查智能体是否达到了某个里程碑(例如,确认它调用了测试运行器)。然而,对于更复杂的任务,模型可能会走一条意料之外、却完全正确的路径。在这类场景中,不要强行规定死板的工具调用顺序,而是采用更宽松、基于结果的检查,例如借助「LLM 作为裁判」(LLM-as-a-judge)来评估智能体所选择的步骤是否安全、有效地解决了问题。
  3. 自动化批量评估以监控稳定性:不要让单次评估结果(由于 AI 模型的非确定性,这种结果往往噪声很大)去阻塞 PR;相反,应自动化批量评估,以拉取更大数据量。持续追踪总体通过率随时间的走势,可以确保模型行为的方向是正确的。依靠这种方向性的信号,你就能放心地微调提示词、升级模型,而不必因为可预期的波动而停下开发的脚步。
# 在 5 秒以内跑完本地行为评估套件
pytest evals/behavioral/ -v

Shell 已复制

你的智能体并不需要一个更高的基准分数来起步。它需要的是一套让它「诚实作答」的评估 Harness。

要构建一个稳定、有韧性的 Harness,你必须停止像对待一个「通过期末考试的黑盒」那样对待模型,而是把 Harness 当作普通的软件来对待——它需要单元测试,也需要集成测试。

最后的思考

虽然行为评估是 Harness 工程的核心支柱,但它并不能取代更大规模的端到端评估套件。事实上,两者互为补充:宏观基准验证的是「终点是否达成」,微观行为评估则是让你能够安全、快速迭代的伙伴。当你同时采纳两者,你就能在迭代时拥有更高的信心——无论是修改提示词、构建新功能,还是上线全新的模型。

相关文章