什么是 harness 工程？

Google 员工 Shir Meir Lador 在一篇技术文章中系统介绍了 harness 工程（Harness Engineering）：用一组确定性的传统软件组件把大模型「包裹」起来，让 AI Agent 在没有人工逐行审查的情况下也能安全地生成与修改代码。这是当前 Agent 开发领域的核心概念之一，值得做 AI 应用的开发者了解。

核心思想：把不确定性关进确定性框架

大模型的输出天然带有随机性，直接让它在生产环境里改代码，风险在于没人知道它下一步会执行什么。harness 工程的解法不是指望模型本身更可靠，而是在模型外围架起一层结构化的「挽具」：由编排层决定调用顺序，由沙箱限制执行边界，由验证环节把关结果。模型只负责生成方案，而方案能否落地、如何落地，都由确定性的工程组件裁决。这层思路对任何想上 Agent 的人和企业都适用，无论底层用的是哪家的模型。

四大组成：编排、沙箱、状态与验证

一个完整的 harness 通常包含四块。编排层负责任务拆解与流程控制，决定先做什么后做什么；执行沙箱把代码运行隔离在受控环境里，即便生成了有问题的代码也不会波及真实系统；状态持久化让多步骤任务在中断、重试后还能续上，不必从头再来；验证工具则像自动化的代码审查员，跑测试、查规范、比对预期输出，把「模型说做完了」变成「测试证明做完了」。四者配合，才能让 Agent 不需要人逐行盯着也能放心干活。

Google 的演示：ADK 2.0 与 Antigravity SDK 的自动修复循环

文章用 Google 自家的 Agent Development Kit 2.0 与 Antigravity SDK 演示了一条自动修复编码循环：Agent 提交代码改动后，harness 自动运行测试，失败信息回喂给模型，由它再生成修复方案，循环往复直到全部通过。整个过程不需要人逐行读代码，人只在循环收敛不了时介入。这相当于把「写代码—跑测试—改 bug」这条开发者最耗时的循环整体自动化，也是各家 Agent 编码工具正在趋同的架构方向。

对开发者的意义：从「审代码」转向「审框架」

对想引入 AI 编码助手的团队，harness 思路给出了务实的路线：与其纠结模型够不够聪明，不如先把沙箱、测试、状态管理这些确定性基建搭扎实。模型能力越强，harness 的杠杆越大；反过来，没有 harness 的奔式 Agent 在真实项目里很难让人放心。入门路径可以从最小闭环做起：一个受限执行环境加一套自动测试，就能让代码生成任务先安全跑起来，再逐步补齐编排与状态管理。

原文来源

本文整理自 DEV 社区 Google AI：https://dev.to/googleai/what-is-harness-engineering-and-why-should-i-care-8n0，版权归原作者所有，了解详情请查看原文。