谷歌开发者博客 9 月 2 日发了一篇讲 harness 工程的文章，作者是 Shir Meir Lador。文章给 harness 下的定义相当直白：包在大模型外面的全部确定性组件——编排层、执行沙箱、状态持久化、验证工具，都算在内。
开篇引的例子是一个数字对比：OpenAI 某个实验性产品里手写代码为 0 行，3 名工程师靠模型生成的代码做出并上线了内部测试版。作者拿它引出的问题不在模型能力，在于把模型圈进可控流程的那层结构。
缰绳、眼罩和赛道
文章用了个赛马的比方：模型是马，harness 是赛道、眼罩和缰绳，负责让它朝一个方向跑。
“The harness is composed of all the deterministic components that wrap the LLM.” harness 由包裹大模型的全部确定性组件构成。
这个定义把一批过去归在「提示词工程」名下的活儿挪了位置。约束模型行为无非两条路：写进提示词，或者写进外面的代码。前者靠模型自觉遵守，换个模型就要重调；后者是硬约束，模型换代照样生效。过去一年做智能体产品的团队大多两头都试过，代价也吃过。提示词里那句「不要修改测试文件」，模型在长上下文里读到第三十轮就开始选择性失明。
三条设计原则
严格边界。把智能体关进沙箱，不给它碰生产数据的机会。文章的演示里，智能体只能在 ./sandbox 目录下写文件，越界的操作根本执行不到。
修复回环。错误不该直接抛给人。测试跑挂了，harness 把干净的日志回喂给模型让它自己改。ADK 2.0 在这里给的是基于图的工作流——校验步骤本身就是图里的一个路由节点，跑失败会自动把控制流绕回生成节点，不需要在编排代码里手写重试逻辑。
仓库结构可渐进发现。不要写一个几千行的说明文件一次性塞给智能体，把仓库组织成它能一层层探进去的样子，让它按需要去发现上下文。
配套的 Antigravity SDK 管的是本地环境那一侧：划定工作区边界，同时提供记忆持久化。两个工具拼在一起，覆盖的是「智能体在哪跑」和「跑错了怎么回来」这两件事。
五轮上限和那个开关
演示的自愈循环走通了完整一圈：智能体在受限沙箱里写代码，自动跑测试，测试失败，日志回喂，智能体改，再跑一遍。上限设成 5 轮，到顶就由 harness 掐断，作者管它叫 kill switch。
这个 5 是整篇文章里最实用的一个数字。自愈循环的典型失败模式，是模型在两个错误状态之间来回横跳，每一轮都在烧 token 却不收敛。设一个硬上限，等于提前承认模型有改不动的时候，让它早点把问题交回人手上。没有这个开关，一个跑歪的循环能在无人值守的夜里把预算烧穿。
把这套东西跟今年上半年流行的智能体框架比一下，重心的移动挺明显。早期框架讲的多是编排，怎么把多个智能体串起来、怎么分工、怎么传消息。现在讲的是验证和边界：执行放在哪、错误怎么回流、什么时候停。前者解决「能不能跑起来」，后者解决「能不能放心让它跑在真项目上」。
对国内团队来说，ADK 2.0 和 Antigravity SDK 这两个具体工具未必用得上，三条原则倒是可以照搬。沙箱、回环、渐进式上下文，任何一套自研的编码智能体都绕不开，区别只在于是提前设计，还是等它把测试文件删了一次之后再补。
参考来源：谷歌开发者博客、CocoLoop、ADK 与 Antigravity SDK 项目文档；harness 定义、三条设计原则与 5 轮上限按原文核对，0 行手写代码与 3 名工程师的数据引自文章转述。