摘要：Google 提出"harness 工程"——用确定性组件包裹 LLM，含编排层、执行沙箱、状态持久化与验证工具，让智能体无需逐行人工监督即可自修复编码循环。
"harness 工程"这个词，最近在 Google 的工程语境里出现的频率明显变高，它回答的是一个很实际的问题：怎么让 LLM 不只是"会聊天"，而是"能干活还不翻车"。核心思路是用确定性组件把模型包起来。具体来说，一个 harness 包含四块：编排层（决定下一步调谁、走什么流程）、执行沙箱（模型写的代码在隔离环境里跑，炸了也不波及外面）、状态持久化（任务跑到一半断了能续上）、以及验证工具（自动判断结果对不对）。把这些"非智能"的硬骨架搭好，模型就只需要负责它擅长的事——理解和生成——而可靠性交给骨架兜底。
Google 用 ADK 2.0 和 Antigravity SDK 做了个演示：一个编码智能体能在 harness 里自己跑"写代码 → 跑测试 → 失败 → 改 → 再测"的循环，大部分情况下不需要人一行行盯着。关键点在于，循环的控制流是确定性的，模型只是在循环里被反复调用；一旦验证工具说"过了"，循环就停。这种"模型在框里转、框外有人看着"的结构，正是当前 Agent 能走向生产的关键。它把一个"可能胡说八道的生成模型"关进了一个"有红绿灯、有护栏、有终点线"的跑道里——模型再怎么天马行空，也只能在跑道边界内发挥。
对工程师，harness 工程的启发是：别把智能体的可靠性全押在模型多聪明上。先把"出错怎么办、怎么验证、怎么回滚"这些确定性逻辑写死，模型的自由度反而能放心放开。这也是为什么很多落地团队发现，把 30% 精力花在 prompt、70% 花在 harness，比反过来要稳得多。一个常被低估的事实是：同一个模型，配一个设计精良的 harness 和配一个粗糙的，在生产环境里的表现可能天差地别——差的那部分，几乎全在骨架，不在模型。
把 harness 工程放回本期更大的图景里看，它其实和 #12 的 reward hacking 研究是同一枚硬币的两面：模型本身越强大、越自主，就越需要"外部确定性约束"来防止它跑偏。无论是用沙箱挡住危险操作，还是用验证工具把"走捷径"挡在门外，思路都是"信任但要验证、放权但要约束"。对任何打算把 Agent 接进真实系统的团队，这篇文章值得逐段精读——它不是在教你写更好的提示词，而是在教你搭一个让模型"既敢干、又干不坏"的容器。
落到团队落地，harness 工程的门槛其实没想象中高，但需要换一种工程直觉：过去我们习惯"把逻辑写进模型提示里"，现在要习惯"把逻辑写进模型外面的确定性代码里"。一个最小可用的 harness，往往就是从"一个循环 + 一个沙箱 + 一个验证函数"起步，不必等架构图多华丽。很多团队卡在"想一步到位设计完美 Agent"，结果迟迟不落地；反而是先搭个粗糙但能跑的 harness 把循环转起来，再在真实失败里迭代骨架，进步最快。值得记住的是，harness 不是一次性的，它会随着模型能力升级而调整——模型更强了，你可以放心放开更多自由度，但骨架的"红绿灯"始终要在。把可靠性寄托在"模型变聪明"上，不如寄托在"框住模型的骨架"上，这是今年反复被验证的一条经验。
