当大家开始谈 Harness 时，我们真正该理解的是什么？从 Representation 到 Harness，再到 System，AI 研发正在进入新的一套系统分层

过去一段时间，AI 圈子里开始越来越多地出现一个词：Harness。

这个词之所以被反复提起，不只是因为业界又多了一个新名词，而是因为一个更实际的变化正在发生：
当模型不再只是“回答问题”，而开始真的“完成任务”，问题就不再只在模型本身，而开始落到模型之外那套让任务得以持续运行的执行系统上。

这也是为什么，最近一线团队真正频繁讨论的，已经不再只是模型怎么回答，而是上下文怎么组织、任务怎么持续执行、反馈怎么进入闭环。

这些词表面上各说各话，背后其实都在指向同一个问题：

当模型开始真正干活，我们到底该如何组织它工作的那套系统？

而事情走到这里，真正浮出来的，已经不只是 Harness 本身。

更值得被看清的，可能是这样一条更完整的链路：

任务先要被表达，然后才能被执行，最后还要进入验证、反馈与系统吸收。

也就是说，今天更值得被看清的，也许不是某一个流行词，而是软件研发正在慢慢浮现出来的一种新分层：

Representation × Harness × System。

过去一两年，AI 工程领域一个很明显的变化是：
大家关注的重点，正在从“模型怎么回答”，转向“模型怎么做事”。

当模型主要被当作对话对象时，很多问题集中在 prompt 上。
但一旦模型开始被用来写代码、改代码、调用工具、执行多步任务、根据反馈继续推进，问题就变了。

这时候，模型就不再只是一个“回答器”，而更像一个正在工作的执行者。
而一个执行者，天然不可能只靠 prompt 存在。
它需要工具、状态、运行时、反馈、边界、恢复机制，也需要一套能把任务持续推进下去的支撑。

所以，Harness 真正对应的，并不是“提示词之后的又一个新技巧”，而是一个更根本的变化：

AI 工程开始承认，模型能力只是起点；真正让任务落地的，是模型外部那套执行支撑系统。

这也是为什么，越来越多团队开始讨论 context engineering、harness engineering、long-running agents、managed agents、evals 这些更靠近系统层的问题。

这些词并不是在重复命名。
它们共同指向的，已经不再只是模型输出本身，而是上下文如何组织、任务如何持续执行，以及反馈如何进入闭环。

行业关注点，正在从“如何优化模型输出”，转向“如何组织一个可持续工作的 Agent 系统”。

Harness，正是在这个过程中，被明确看见的一层。

要理解 Harness，最重要的一步，不是先给它下定义，而是先看它为什么会出现。

原因其实很朴素：

当模型开始真正承担任务时，它就必须被放进一个可以工作的环境里。

在“问答阶段”，模型更多是被动响应。
你给它输入，它给你输出。
但在“执行阶段”，模型要做的事情完全不同：

一旦进入这种模式，模型就已经不再只是“会说”，而是开始“做事”。
而只要开始做事，它就一定需要某种外部支撑层。

这层支撑，今天常常被叫作 Harness。

从工程上看，Harness 至少承担三类职责：

第一，是执行接入。
让模型能够接触工具、终端、代码仓库、浏览器、接口和文件系统，而不是被困在对话框里。

第二，是运行管理。
让任务能够持续跑下去，包括状态保存、上下文管理、长任务 loop、错误恢复、重试机制和步骤编排。

第三，是反馈衔接。
让模型不只是“往前做”，而是能够根据测试结果、日志、检查结果和人工反馈继续修正。

从这个意义上说，Harness 解决的核心问题，不是“任务是什么”，而是：

一个已经被交给模型的任务，怎样才能被持续地跑起来。

最近 OpenAI 对 Agents SDK 的更新，其实把这层说得更具体了。
官方已经不再把 harness 当作一个泛泛的比喻，而是把它落成一层明确的执行控制结构：它负责 agent loop、tool routing、approvals、tracing、recovery，以及 run state；而真正运行命令、读写文件、安装依赖的那一层，则被放进 sandbox execution。

这个区分很重要。
它说明 Harness 不只是 shell 或 sandbox 本身，而是围绕模型的执行控制层；sandbox 更像是工作真正发生的执行基底。(OpenAI - The next evolution of the Agents SDK)
也正因为如此，Harness 正在从社区经验，变成一类被正式产品化的能力组合。

如果再往外看，任务越来越复杂之后，被显式化的就不只是 Harness 本身了。
单靠 prompt 已经不够；
单靠把上下文喂给模型，也不够。
最近被提到的 Environment，更像是另一个正在浮出来的问题域：它提醒我们，除了给模型一套执行支撑层，我们还需要重新思考，它所处的运行世界本身，是否足够适合 Agent 工作。

比如：

当这些问题开始被讨论时，说明变化已经不只是“模型变强了”，而是：

软件系统本身，开始被重新设计成一个更适合 Agent 参与工作的环境。

而 Harness，正是这个变化中最先被显式看见的一层。

Harness 被越来越多地讨论，说明行业确实开始承认一件事：
模型之外的执行支撑系统，已经不再是附属品，而开始成为 AI 落地效果的一部分。

但随着 Harness 被看见，另一件事也开始变得更清楚：

执行，并不是全部。

一个任务能不能真正进入自动化闭环，不只是看它能不能被跑起来，还要看两件更靠前、也更靠后的事情：

一是，任务本身有没有被说清；
二是，执行结果能不能被验证、吸收，并进入后续系统。

这也是为什么，只有 Harness 还不够。

因为 Harness 解决的，主要是一个任务怎样被持续执行。
它默认了一个前提：任务已经被交代给它了。

可在真实研发场景里，这个前提往往并不天然成立。

很多时候，问题不是 Agent 不会做，而是任务本身还停留在一种“人能大致理解，但系统无法稳定消费”的状态里。
目标不够明确，边界不够清晰，约束没有显式化，验收标准也没有被单独提出来。
这种情况下，执行系统越强，往往只是更快地把一个模糊任务推进成一个模糊结果。

也就是说，Harness 并不负责回答：

而在执行之后，它也没有独立回答另一类问题：

所以，Harness 的边界，其实比很多表述里看起来要更明确一些。

它当然不是“工具接入”这么简单。
但它也还不是完整的系统闭环。

更准确地说，Harness 解决的是：

任务一旦被交给 Agent，怎样才能被持续地跑起来。

这已经是一层巨大的进步。
但也恰恰因为它足够重要，它的边界才更需要被看清。

真正更常见的，不是 Agent 完全不会做，而是它开始做了，却做在了一片仍然模糊的地带里。

比如一个看起来并不复杂的研发任务：
“给待发货列表加一个筛选条件，并调整空态和交互反馈。”

如果直接把这句话交给 Agent，它当然也能开始做：它会去找页面、找接口、猜状态、改交互、补空态。
但问题往往不在于它会不会改，而在于它并不知道很多真正关键的东西：
筛选条件到底作用于哪个状态集合，空态是在筛选后出现还是全局无数据时出现，交互反馈是局部刷新还是整页刷新，是否要保持现有组件行为一致。

这些内容，对人来说往往可以边做边补；
但对 Agent 来说，如果没有被显式整理出来，执行过程就只能依赖临时推断。

一旦把这些内容进一步整理成更稳定的任务表示，比如 scope、constraints、acceptance、repo context，任务的稳定性就会明显提升。
到这里才会发现，真正缺的并不是“一个更会改代码的 Agent”，而是任务先被表达成了一个可执行对象。

到这里，另一个更基础的问题开始浮出来：

任务到底是以什么形式，被交给系统的？

过去，这件事很少被单独拿出来看。
因为人一直是默认的执行者。需求文档、设计稿、接口说明、口头沟通、历史经验、代码上下文，最终都由人自己在脑中完成理解、补全和判断。

也正因为如此，很多“表达”长期是隐性的。
它没有真正成为系统对象，而是寄存在人身上。

但当执行者开始从人转向 Agent，这件事就不再能被含混地带过去了。

这也是为什么，AI 可以跳过部分手写代码，却不能跳过 Representation。

这里说的 Representation，并不是某一种固定格式，也不一定非得是 JSON。
它更接近一种能力要求：

任务需要被整理成一种既能被人理解，也能被系统稳定消费的表示。

它至少要回答几件事：

Representation 并不是“写得更详细的需求文档”，也不是“换个格式再说一遍”。
它的关键，不在于形式更工整，而在于它开始承担新的角色：

它不再只是沟通材料，而逐渐成为执行输入。

这是一个很重要的变化。

因为当执行者是人时，表达可以保留大量模糊地带。
人会自己补全，会自己问，会根据经验修正。
但当执行者变成 Agent，表达如果还停留在这种状态，系统就会把原本由人隐式承担的理解成本重新暴露出来。

很多看起来像“模型不够强”的问题，往往其实不是模型问题。
它更像是：任务还没有被表达成一个足够稳定的对象。

所以，任务并不是天然可执行的。
它需要先被表达；
然后才能被执行；
最后还要被验证、吸收，并纳入更大的系统闭环。

Representation 的价值，就在这里。

如果说 Representation 让任务开始被稳定表达，Harness 让任务开始被持续执行，那么再往后，问题还会继续推进一层。

因为在真实研发里，一个任务真正完成，并不等于它“跑过了一遍”。

它还需要被判断。
需要被验证。
需要被反馈。
需要被纳入后续系统。
需要在下一次类似任务到来时，能够被复用、被观测、被治理。

这也是为什么，事情走到最后，问题会从 Harness 继续落到 System。

这里的 System，不是一个空泛的大词。
它更接近一种新的组织方式：

表达、执行、验证、反馈，不再分别寄存在人、工具和流程碎片里，而开始被组织成一个可以持续运作的闭环。

这层闭环至少意味着几件事。

首先，结果不再只是“生成出来”，而是需要被独立验证。
系统不能只知道自己做了什么，还得知道自己是否真的完成了目标。

其次，任务不再只是一轮性完成，而是要能够被反馈吸收。
一次执行里暴露出来的问题，不能只靠某个人临时记住；
一次需求里补充出来的约束，也不能只停留在当前对话。

再往后，系统还需要知道什么时候该继续自动推进，什么时候该停下来，什么时候该交给人。
这背后对应的，其实是 routing、governance、human-in-the-loop 这些能力。
系统真正成熟的标志，不是它永远不停，而是它知道何时自动、何时让渡、何时升级。

所以从这个角度看，System 的出现，并不是因为我们想把话说得更大。
恰恰相反，是因为事情走到这里，已经不能只用“执行支撑层”来描述了。

这也是为什么，最近大厂对 agent 的投入，开始明显从“模型会不会调 tool”，转向“执行系统是否可靠”。
OpenAI 最新更新里专门强调 harness 和 compute 的分离，并把它们分别组织成 control plane 和 sandbox execution plane；给出的理由也已经不只是“更好用”，而是 security、durability、scale 这些系统目标。
这意味着 Harness 已经不再只是一个执行便利层，而开始承担一部分系统职责。
当状态恢复、安全隔离、并行执行、恢复运行这些能力被放进官方产品结构里时，agent 的问题也就不再只是“能不能做”，而是“如何在真实系统中持续做、可靠做、可治理地做”。
这并不意味着 Representation 不重要；恰恰相反，它说明当 Harness / System 这两层被补齐之后，上游的任务表达会变得更加关键。

Harness 让任务开始被跑起来。
但只有进入 System，任务才开始真正被组织起来。

前一个阶段更像是：

给 Agent 一套能工作的支撑。

后一个阶段更像是：

把 Agent 放进一套会持续吸收结果、修正行为、管理边界的系统。

到了这一步，AI 落地真正竞争的，也就不只是模型能力，甚至不只是执行能力，而是更完整的 系统组织能力。

如果把前面的讨论收回来，会发现最近围绕 Harness 的热度，真正重要的地方，并不只是“业界又多了一个新词”。

更重要的是，Harness 被反复讨论这件事本身，说明行业已经开始正视一件过去长期被忽略的事情：

任务并不是天然可执行的，AI 也不是天然可落地的。

在模型主要负责生成内容的时候，这个问题还没有完全暴露。
但当模型开始承担真实任务，它立刻就浮出来了。

这时候，问题不再只是模型够不够强，也不再只是输出质量够不够高。
更靠近本质的问题开始出现：
任务有没有被说清，执行能不能持续，结果是否能够被验证、吸收，并进入后续系统。

也正是在这个意义上，Harness 之所以重要，不只是因为它提供了一套新的执行支撑层。
更因为它让“执行”这一层第一次被明确地单独看见。

而一旦执行层被看见，另外两层也会随之浮出来：
一层是任务如何被表达，另一层是结果如何进入闭环。

过去很长时间里，软件研发默认人是那个把一切缝在一起的中间层。
人负责理解模糊需求，补全上下文，调用工具，判断结果，记住经验，再把这一切带到下一个任务里。

而现在，随着执行者逐渐从人转向 Agent，这些原本隐性寄存在人身上的中间层，开始被迫显性化、系统化。

Representation 于是浮出来。
Harness 于是浮出来。
System 也于是浮出来。

真正发生变化的，不只是“AI 更能干活了”。
而是软件研发开始被迫把过去寄存在人身上的中间层，重新拆开并显式化。

如果把这件事再压缩成一个更清晰的结构，它最终会落在三层上：

第一层，是 Representation。
任务必须先被表达成一个稳定对象，而不是停留在人可以大致理解、系统却无法稳定消费的状态里。

第二层，是 Harness。
任务一旦被交给 Agent，就需要有一套执行支撑层，让它能够调用工具、保持状态、处理错误、根据反馈继续推进。

第三层，是 System。
执行结果不能停留在一次完成，而要进入验证、反馈、治理与吸收的闭环，成为系统的一部分。

不是行业在追逐新术语，
而是软件研发正在逐渐长出一套新的分层。

这套分层，不再只围绕代码组织，
也不再只围绕模型组织，
而是开始围绕一个更完整的系统来组织：

Representation × Harness × System。