Google 发布 Gemini 3.8 Flash 的同时，深入探讨了 Harness Engineering 的重要性。本文对比 OpenAI、DeepSeek、Google 三大厂商的 Harness 路线，解析如何通过工程架构让 Agent 稳定、安全地完成复杂任务，并揭示未来企业评估 Agent 的关键指标。

9 月 2 日，Google 正式发布 Gemini 3.8 Flash，这是目前 Google 最强的 Flash 模型。同一天，Google AI 的开发者账号发布了一篇值得看的技术文章：《What is harness engineering and why should I care?》。

一边继续升级模型，一边讲 Harness Engineering，比单看某个 benchmark 更有意思。整个 Agent 行业越来越清楚地认识到一件事：模型决定 Agent 有多聪明，Harness 决定这份智能能不能持续、稳定、安全地完成工作。

这也是为什么今年 OpenAI、DeepSeek、Google，甚至 NVIDIA，都开始把大量工程资源投到模型架构。

一、Harness等同于Agent 的运行系统

如果 Agent 是一匹能力很强的赛马，Harness 就是赛道、缰绳和护栏。模型负责跑，Harness 决定它往哪里跑、能跑到哪里，以及冲出赛道的时候怎么把它拉回来。

从工程角度看，一个典型 Harness 可拆成几个部分：Model → Context → Tools → Execution → State → Verification → Repair Loop

Model 是 Gemini、Claude、GPT 或 DeepSeek等模型；Tools 负责文件、浏览器、数据库和 MCP；Execution 负责真正运行命令；State 记录任务进度和历史；Verification 判断结果有没有达到要求；Repair Loop 则负责失败之后自动重新尝试。

二、自动循环修复（Repair Loop）

Google 没有把 Harness Engineering 讲成特别复杂的架构理论，而是给了一个很简单的例子。

首先，把 Agent 限制在一个独立的 sandbox 工作区里，只允许它操作特定代码，同时把执行轨迹保存到单独目录。Agent 修改代码后不直接宣布任务完成，而是进入测试节点。测试通过，流程结束，测试失败，Harness 把错误日志重新交给 Agent，让它继续修改。连续失败超过设定次数，直接触发 Kill Switch 停止任务。Google 示例里设定的上限是 5 次。

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 中的节点，开发者可以通过图结构定义分支、循环、重试、并行、状态恢复。

模型负责解决开放问题，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 的总成本就一定越来越低。

假设一个 Coding Agent：连续推理 20 轮、调用 Shell 30 次、读取几十个文件、失败后重复测试、不断把历史上下文带回来。单个 Token 再便宜，最后也可能烧掉大量资源。所以 Harness 除了负责安全和稳定，还有一个越来越重要的职责：管理 Agent 的计算预算。

包括最多运行多少轮、什么时候压缩上下文、什么时候终止任务、哪些步骤值得用强模型、什么时候切到低档模型，以及什么时候应该让人介入。

未来企业评估 Agent，关注的指标会逐渐从 Token 单价转向：完成一个有效任务成本是多少。

五、OpenAI/DeepSeek/Google走出了三种 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

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 个百分点。但它说明一个很重要的问题：评估一个 Agent，只测底层模型已经越来越不够。

TechCrunch 在报道这项研究时，也把核心结论直接落到了 Harness：对于长周期任务、Memory、Context、Feedback 和 Supervisor 对最终效果会产生非常大的影响。这和 Google 此时强调 Harness Engineering，其实属于同一个行业信号。

、七、最值得马上实践的是四件事

第一，把权限边界真正做成代码。Agent 可以读哪些目录、能不能访问生产数据库、什么命令需要确认，不要只写在 Prompt 里。

第二，把测试变成 Agent Workflow 的一部分。不要等 Agent 说「完成了」再人工检查。单元测试、Lint、Type Check、E2E 都可以成为验证节点，失败结果直接重新回流给 Agent。

第三，给循环设置预算和 Kill Switch。例如最多修改 5 次、最高消耗多少 Token、最长运行多少分钟。一个 Agent 能持续工作几个小时以后，停止条件会和启动条件一样重要。

第四，优化项目的Agent Legibility。仓库目录、AGENTS.md、README、测试命令、日志和架构约束，都应该做到让 Agent 可以自己发现。OpenAI 的经验也很明确，给 Agent 一张清楚的地图，比塞进去一本几万字的操作说明更有效。

写到最后

过去一年，AI 开发者最喜欢讨论的问题是：哪家模型能力更强？

这个问题当然还重要。但进入 Agent 阶段之后，模型只是完整系统中的一层。

如果说过去两年大家主要学习 Prompt Engineering，那么接下来更需要补充工程能力：怎么设计一个环境，让 Agent 能自己工作、发现错误、修复，同时始终在设定边界里运行。

这才是 Harness Engineering 真正值得关注的地方。