9 月 2 日，Google AI 的开发者账号发布了一篇值得看的技术文章：《What is harness engineering and why should I care?》。同一天，Google 正式发布 Gemini 3.8 Flash，这是目前 Google 最强的 Flash 模型。
一边继续升级模型，一边专门讲 Harness Engineering。这两个动作放在一起，比单看某个 benchmark 更有意思。
整个 Agent 行业正在越来越清楚地认识到一件事：模型决定 Agent 有多聪明，Harness 决定这份智能能不能持续、稳定、安全地完成工作。
这也是为什么今年 OpenAI、DeepSeek、Google，甚至 NVIDIA，都开始把大量工程资源投到模型架构。
一、Harness=Agent 的运行系统
Harness 其实不是什么特别玄的概念，假设你直接调用一个大模型 API，它能做的事情很有限：接收上下文，进行推理，然后返回结果。
要把它变成真正可以工作的 Agent，还需要给它文件系统、Shell、浏览器、工具、记忆、权限、任务状态、测试环境，以及出错后的恢复机制。这些围绕模型工作的确定性系统，基本都属于 Harness。
Google 在这篇文章里的描述很形象：如果 Agent 是一匹能力很强的赛马，Harness 就包括赛道、缰绳和护栏。模型负责跑，Harness 决定它往哪里跑、能跑到哪里，以及冲出赛道的时候怎么把它拉回来。
从工程角度看，可以把一个典型 Harness 拆成几个部分：Model → Context → Tools → Execution → State → Verification → Repair Loop
其中 Model 可能是 Gemini、Claude、GPT 或 DeepSeek；Tools 负责文件、浏览器、数据库和 MCP；Execution 负责真正运行命令；State 记录任务进度和历史；Verification 判断结果有没有达到要求；Repair Loop 则负责失败之后自动重新尝试。
这也解释了为什么同一个模型放到不同 Agent 产品里，实际表现可能差很多。
二、Repair Loop
Google 没有把 Harness Engineering 讲成特别复杂的架构理论，而是给了一个很简单的例子。
首先，把 Agent 限制在一个独立的 sandbox 工作区里，只允许它操作这里的代码，同时把执行轨迹保存到单独目录。然后让 Agent 修改代码，代码修改之后，不直接宣布任务完成，而是进入测试节点。测试通过，流程结束，测试失败，Harness 把错误日志重新交给 Agent，让它继续修改。连续失败超过设定次数，直接触发 Kill Switch 停止任务。Google 示例里设定的上限就是 5 次。其实就是：
Agent 修改代码
↓
运行测试
↓
成功 → 结束
↓
失败
↓
返回错误日志
↓
Agent 修复
↓
超过最大次数 → 停止
看上去非常普通。但这正是 Harness Engineering 和单纯 Prompt Engineering 最大的区别。过去失败以后，人把报错复制回来，再告诉 AI继续修。这个时候，人自己就是 Harness。
Google 在文章里也直接提到这点：普通聊天窗口中，需要人类负责复制错误、重新输入、判断是否继续；当这些动作被软件化之后，系统开始能够自己闭环处理。Agent 的自主性，就是这样一点点建立起来的。
三、ADK 2.0 为什么开始强调 Graph Workflow
Repair Loop 能处理的好，还得益于Google 经把 ADK 升级到了 2.0。
最核心的变化是引入新的 Workflow Runtime。以前很多 Agent 框架习惯把执行过程写成固定的 Sequential、Parallel、Loop。到了 ADK 2.0，Agent、Tool 和普通函数都可以成为 Workflow Graph 中的节点，开发者可以通过图结构定义分支、循环、重试、并行、状态恢复和 Human-in-the-loop。
模型负责解决开放问题，Workflow 负责守住流程。这其实是企业 Agent 很重要的一种架构思路。完全自由的 Agent 很难控制，完全固定的 Workflow 又缺少智能。
真正好用的企业 Agent，大概率会长期处在「确定性流程 + 非确定性 Agent」之间。
Google ADK 2.0 的 Graph Workflow，本质上就是在给这两部分提供一个共同的执行环境。
四、Gemini 3.8 Flash让Harness 的价值更明显
Gemini 3.8 Flash 直接面向长时间软件工程、自主 Agent 和复杂企业任务。针对复杂任务会执行更多推理步骤，并进行更多迭代工具调用。在高 Thinking 档位下，它有时会消耗更多 Token 来换取任务质量。
这句话对 Agent 开发者很重要。模型越来越便宜，并不代表 Agent 的总成本就一定越来越低。
假设一个 Coding Agent：连续推理 20 轮、调用 Shell 30 次、读取几十个文件、失败后重复测试、不断把历史上下文带回来。单个 Token 再便宜，最后也可能烧掉大量资源。
所以 Harness 除了负责安全和稳定，还有一个越来越重要的职责：管理 Agent 的计算预算。
包括最多运行多少轮、什么时候压缩上下文、什么时候终止任务、哪些步骤值得用强模型、什么时候切到低档模型，以及什么时候应该让人介入。
未来企业评估 Agent，关注的指标会逐渐从 Token 单价转向：完成一个有效任务成本是多少。
五、OpenAI/DeepSeek/Google走出了三种 Harness 路线
把今年3家的动作放到一起看，Harness 已经逐渐形成不同的技术路线。
OpenAI：从真实 Coding Agent 倒推 Harness
OpenAI 在今年 2 月专门发布了 Harness Engineering 实践。他们做了一个极端实验：从空 Git 仓库开始，应用代码、测试、CI、文档、可观测性以及内部工具都让 Codex 编写。OpenAI 表示，这个内部产品最终达到百万行级别代码，整体开发时间大约相当于传统手写方式的十分之一。
这个实验最后得到的核心经验，并不是要写更长的 Prompt。真正有用的是让仓库对 Agent 足够清晰，把规则写进 AGENTS.md，把架构约束做成 lint 和测试，把日志和运行环境开放给 Agent，同时让验证能够自动执行。
Codex CLI 本身也已经以 Apache 2.0 协议开源。OpenAI 这条路线可以概括成：先把 Coding Agent 做到极致，再从真实生产环境反推 Harness 应该长什么样。
DeepSeek：把 Harness 本身做成产品
今年 8 月发布的 DeepSeek Harness 明确提出：Agent = Model + Harness
它最大的特点是 Everything is a Plugin。模型、Tools、Skills、Session、Sandbox、Storage、Agent Loop、调度甚至 UI 都被设计成插件，开发者可以通过配置替换组件，而不需要修改 Harness 核心。整个项目采用 MIT 开源协议，目前仍处于 Developer Preview。
DeepSeek 还特别强调每次 Agent 执行都应该能够回放。系统提示词、推理、工具调用、子 Agent 调度、上下文注入都会记录进 append-only Session Log，支持 Resume、Fork、Search 和 Replay。
它关注的是 Harness 自身的可组合性。
Google：Harness + Workflow + Agent Runtime
Google 现在呈现的是另一种结构。
ADK 负责 Agent 和 Workflow 编排；Antigravity SDK 负责状态化 Agent Runtime、工具、Hooks、Policies、MCP 和后台 Trigger；Gemini 负责模型能力。
其中 Google Antigravity SDK 已经以 Apache 2.0 开源，官方将它定义为一层 secure、scalable、stateful infrastructure，帮助开发者抽象 Agent Loop。它默认采用只读模式，也提供 deny、allow、ask_user 等策略控制工具调用。
Google 的路线更接近：Model + Runtime + Workflow Engine + Enterprise Platform。
三家路线不同，但它们解决的是同一个问题：模型越来越强之后，怎样让它稳定运行更长时间。
六、NVIDIA 最近的实验，进一步放大 Harness 价值
如果觉得 Harness 只是几家模型厂商在制造新概念，NVIDIA 最近的一项实验很值得参考。
8 月，NVIDIA 公布了 Agentic Variation Operators，也就是 AVO。
它在长周期 Agent 外面增加持久记忆、执行工具和 Supervisor，让上层 Agent 在陷入重复探索或停滞时能够得到纠偏。
NVIDIA 在 ARC-AGI-3 的公开集实验中，使用 Claude Opus 5 作为底层模型，完整 AVO 系统取得了 100% RHAE，完成了 25 个环境、183 个 Level。ARC Prize 此前单独报告的 Claude Opus 5 High reasoning 基线约为 30%。NVIDIA 同时明确提醒，两组实验的 Harness、推理设置和评测环境并不相同，不能简单理解成 Harness 单独贡献了 70 个百分点。(NVIDIA Developer)
但它仍然说明一个很重要的问题：
评估一个 Agent，只测底层模型已经越来越不够。
TechCrunch 在报道这项研究时，也把核心结论直接落到了 Harness：对于长周期任务，Memory、Context、Feedback 和 Supervisor 对最终效果会产生非常大的影响。(TechCrunch)
这和 Google 此时强调 Harness Engineering，其实属于同一个行业信号。
七、对开发者来说，Harness Engineering 最值得马上实践的是四件事
如果现在正在用 Codex、Claude Code、Gemini 或 DeepSeek 做真实项目，我觉得暂时没必要马上自己造一个完整 Harness。
更值得先改造现有项目。
第一，把权限边界真正做成代码。Agent 可以读哪些目录、能不能访问生产数据库、什么命令需要确认，不要只写在 Prompt 里。Google Antigravity 默认只读，以及 Policies 里的 deny、allow、ask_user，都是这个思路。(GitHub)
第二，把测试变成 Agent Workflow 的一部分。不要等 Agent 说「完成了」再人工检查。单元测试、Lint、Type Check、E2E 都可以成为验证节点，失败结果直接重新回流给 Agent。
第三，给循环设置预算和 Kill Switch。例如最多修改 5 次、最高消耗多少 Token、最长运行多少分钟。一个 Agent 能持续工作几个小时以后，停止条件会和启动条件一样重要。
第四，优化项目的Agent Legibility。仓库目录、AGENTS.md、README、测试命令、日志和架构约束，都应该做到让 Agent 可以自己发现。OpenAI 的经验也很明确，给 Agent 一张清楚的地图，比塞进去一本几万字的操作说明更有效。(DEV Community)
这几件事情做好以后，就已经在做 Harness Engineering 了。
最后
过去一年，AI 开发者最喜欢讨论的问题是：
Gemini、Claude、GPT、DeepSeek 到底谁更强。
这个问题当然还重要。
但进入 Agent 阶段之后，模型只是完整系统中的一层。
一次持续几个小时甚至几天的任务，需要记忆，需要工具，需要沙箱，需要权限，需要状态恢复，需要测试，需要预算控制，也需要知道什么时候应该停止。
这些都属于 Harness。
所以 Google 在 Gemini 3.8 Flash 发布的同一天专门讲 Harness Engineering，我觉得很有代表性。
模型能力还在快速上涨，但真正决定 Agent 能不能进入生产环境的竞争，已经越来越多地发生在模型外面。
如果说过去两年大家主要学习 Prompt Engineering，那么接下来产品经理和开发者都值得补一门新的工程能力：
怎么设计一个环境，让 Agent 能自己工作、自己发现错误、自己修复，同时始终待在你设定的边界里。
这才是 Harness Engineering 真正值得关注的地方。
