套具工程：用行为评测看住编码智能体

套具工程的解剖：怎样评测、迭代并看住 AI 编码智能体

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

图 1：套具工程与行为评测。

开发者刚开始为智能体编码系统做套具工程（harness engineering，包在模型外面、负责调用工具、检查产物并约束行为的那层程序）时，常常掉进同一个陷阱：跑 Terminal-Bench、DeepSWE 这类常见的端到端基准，看见综合分移动了几个百分点，却不知道为什么变了。

端到端基准是评测模型表现、并决定什么需要更深调查的事实标准。难处在于，这些调查代价很高。

行为评测（behavioral evaluation，检查某一种可观察动作有没有发生，而不是只看最终分数）常常是更好的信心度量：你期望的行为是不是真的发生，以及在回归或换新模型时，你是在往前走还是在倒退。它们可以当迭代伙伴，并帮助看出某些改动为什么把指针往这边或那边推。

下面是他们对行为评测的看法，包括帮助他们在模型演进时保持智能体系统可靠的做法。

范式转换：成绩单，还是行为路标

多数团队评测 AI 智能体的方式，像评一个在考试的学生。他们交给智能体一个大代码库，给一个时间限制，再按通过或失败多少测试来衡量成功。

分数掉了的时候，哪里错了？

• 模型是不是在含糊的提示上过于自信？
• 它是不是在提交前忘了核对测试套件？
• 它是不是编造了一个命令行开关？

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

行为评测的作用，像是为改进智能体套具运行而做的集成测试。当你有一套足够丰富的行为评测集，你就有了你要从智能体身上得到的行为基线，并且可以迭代改进提示，直到走到那里。

行为评测不测量智能体有没有完成一次跨多个文件的重构，而测量离散的、可观察的动作：

• 拿到规格不足的提示时，智能体是提出澄清问题，还是猜？
• 修改构建文件时，它是不是在宣布完成之前跑了本地校验器？
• 生成文档时，它有没有给出规范的仓库链接？

图 2：宏观端到端基准与行为评测的对照。

什么时候评测：先自己用的先例

不要在第一天就搭一套复杂的评测套具。用这段时间跟着直觉做实验。

从零引导一个智能体时，你从开发者直觉和自己用（dogfooding，团队先用自己正在做的产品）开始。在你做出的智能体还不能在自己的代码库上自己用、处理样板、写自己的 markdown 渲染器、并执行日常开发任务之前，跑评测没有意义。

评测属于开发的第二阶段：保证向前，并挡住回归。

评测套件的首要目的，不是在你把智能体做「好 2%」时庆祝。它是给你不可动摇的信心：一次新的提示微调、工具模式改动或模型升级，没有让智能体在整体上变差。

行为评测架构怎么工作

一套稳的套具评测框架，把行为断言拆成快的、确定的、单元测试风格的检查，在本地跑。

把注意力移到这些更小的、可观察的动作上，会做出一张可靠的安全网。你可以有信心地迭代系统提示，或换成另一个模型，因为如果无意中弄坏了一个核心行为，你会立刻知道。

写一条行为评测

行为评测断言的是中间执行步骤，例如某次工具调用或文件修改，而不是最终字符串相等：

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

例子是为 Antigravity SDK 写的。完整仓库：https://github.com/google-antigravity/antigravity-sdk-python

有一套丰富的行为评测之后，你可以把提示工程自动化。例如设一个循环，让大模型改自己的系统提示，一直迭代到一条失败的测试终于通过，同时其余测试套件像 CI/CD（持续集成与持续交付，合并前自动跑检查）式的护栏一样工作。这帮助你确认改动没有弄坏已有功能。

做行为套件时要考虑什么

从一开始有几件事可以让这个过程可重复。他们建议用一个三步的行为测试环，从小做起：

1. 选一种失败模式。 找智能体最近犯的一个错，例如在把任务标成完成之前忘了跑单元测试。找一个漏掉的、单一而明显的动作，把它当成目标。
2. 按任务复杂度写有弹性的断言。 对只有一条最优解的简单任务，做严格的单轮断言，检查智能体有没有打到某个里程碑（例如确认它调用了测试运行器）。对更复杂的任务，模型可能走一条没料到但完全正确的路径。这时不要强制一条僵硬的工具序列。改用更模糊的、基于结果的检查，例如用大模型当评判（LLM-as-a-judge，让另一个模型按标准判断这一步是否合格），看智能体选择的步骤是否成功且安全地解决了问题。
3. 自动做批量评测，以监测稳定性。 不要因为单次评测运行就挡住合并请求。AI 模型的非确定性会让单次结果很吵。把批量评测自动化，拉更大的数据量。跟踪一段时间里的合计通过率，确认模型行为的趋势是对的。依靠这个方向信号，你就有余地安全地改提示、升级模型，而不必为预期中的波动停掉开发。

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

你的智能体不需要先有更高的基准分才能开始。它需要一套让它保持诚实的评测套具。

要做出稳定、有韧性的套具，你得停止把模型当成一个通过期末考试的黑盒，开始把套具当成需要单元测试和集成测试的普通软件。

最后

行为评测是套具工程的一根核心支柱，但它们不是更大的端到端评测套件的替代。两者是互补的。宏观基准核对最终目的地，微观行为评测是让安全、快速迭代成为可能的伙伴。两者都用上之后，你在迭代时会有更高的信心，无论是改提示、做新功能，还是部署全新的模型。

出处：Taylor Mullen，Christian Gunderman，The Anatomy of Harness Engineering: How to Evaluate, Iterate, and Guard AI Coding Agents，2026-09-09，https://developers.googleblog.com/the-anatomy-of-harness-engineering-how-to-evaluate-iterate-and-guard-ai-coding-agents ，CC BY 4.0。