图解 Harness 工程

我让GPT-4写代码审查，结果它连“print(‘Hello’)”都要改成f-string

说实话吧，这两年我在Agent上翻的车，比我写十年技术专栏加起来都惨。

2023年底，我兴冲冲地用GPT-4搭一个自动化代码审查机器人。当时的我啊，天真得不行——以为把需求塞进system prompt，模型就能自己飞。三天？第四天它就开始作妖了：每一行代码都标“建议优化”，连 print(“Hello”) 都要改成f-string！

你说离不离谱？

我把prompt从500字改到3000字。角色设定、思维链、few-shot，什么都往里头塞。结果呢？该抽风还是抽风，该乱来还是乱来。

后来我才明白——问题根本不在模型身上，在模型外面那层东西上。

那个“外面那层东西”，2025年之前没人正经给它起名字，大家都叫它“工程技巧”。但到了2026年，终于有人把它当一门学科了——Harness Engineering。

我花了三个周末把最新的综述和几个团队的实战经验啃了一遍，中间还自己跑了几个实验，踩了几个坑。今天这篇文章，就当是给你拆开看看，该骂的骂、该夸的夸，全是自己试出来的血泪。

炸裂！你脑子里那个假设，其实是错的

先给你一个最炸裂的。

过去两年，学术界和工业界一直有个潜规则：Agent的能力等于模型的能力。 你只要模型选得够强，配上顶级prompt，Agent什么都能干。框架、工具链、环境配置这些，都是“工程细节”，不影响上层的智能。

2026年的这篇综述，直接给了三个耳光，一个比一个响——

耳光1： 同一个人，同一个模型，只改了工具的格式和周围的harness配置，模型权重的参数一个没动。结果15个模型的编码基准测试，成绩差了多少？10倍！ 不是提升两三个百分点，是量级的差距啊朋友。

我当时看到这个数字，手里那杯水差点泼桌上。因为我2024年也干过一样的蠢事：同一个CodeLLaMA，在本地跑和在Colab跑结果完全不一样。我当时以为是环境配置的问题。现在看明白了——就是那个“周围的东西”变了。

耳光2： 固定用GPT-5.2-Codex，只改系统提示、中间件上下文注入、加了个自验证钩子。Terminal-Bench 2.0的成绩 从52.8%跳到了66.5%，涨了13.7个百分点。你知道模型迭代一次通常涨多少吗？2到4个点。你花大价钱换模型，不如好好改改你的harness。

耳光3： 有人搞了个Meta-Harness，纯自动化优化harness结构，在Terminal-Bench-2上直接跑到 76.4%，碾压所有人类手工设计的配置。

作者给这个现象起了个名字：Binding-Constraint Thesis。翻译过来就是——长篇任务里，基准的差异根本不是由模型决定的，而是由执行Harness驱动的。模型？它只是被绑在harness上的那个“执行单元”。

这个结论看起来激进。但说实话，我心服口服。

我去年把一个跑半小时就崩的Agent从LangChain迁移到自定义harness，一个模型都没换。结果呢？连续跑了三天，屁事没有。不是模型变聪明了，是harness帮它兜住了底。

三个阶段：从“跪求模型听话”到“直接修笼子”

那harness这种思维是怎么一步步来的？你看这篇论文的脉络，特别清楚：

第一阶段：Prompt Engineering（2022–2024）

说白了就是调prompt。指令够不够优雅？few-shot给了没？推理模板是用chain-of-thought还是tree-of-thought？工程的边界只到“单次文本输入 -> 单次模型调用”。核心假设只有一个：只要你说得对，模型什么都能干。

我那时候最高纪录是写过一个6000字的system prompt，里面塞了3个角色切换、17条约束规则、5个示例。每次换场景都得全改，跟牵着一头牛在茶壶里跳舞似的。

这个阶段的本质是什么？ 你觉得模型不理解你，你就拼命解释。但问题根本就不在解释上啊。

第二阶段：Context Engineering（2025）

Karpathy在2025年大力推这个概念——核心不再是“你说了什么”，而是“模型每一步看到了什么”。

你看，Agent变成多步长跑之后，模型每次都只看到一个小窗口。你prompt吹得天花乱坠，前几步就丢进历史了。所以大家开始搞RAG、记忆压缩、渐进式信息暴露、状态管理。

我2025年底写过一个Deep Research工具，核心就是上下文管理。当时我按阶段只给模型当前需要的上下文，而不是把全部资料塞进去。后来痛苦地发现：模型在第5步之后就会忘记自己第1步的结论。不是它笨，是你给的上下文已经膨胀到128K之外了。

这个阶段开始承认一个事实： 模型不是你肚子里的蛔虫。它就是个按窗口看信息的哑巴，你得想好每一步让它看到什么。

第三阶段：Harness Engineering（2026）

到了2026年，大家的共识彻底变了：既然模型是个黑盒，你又不能保证它永远不乱来，那就别试图“说服”它了。把它扔到一个设计好的笼子里，笼子决定了它能干啥、不能干啥。

这个笼子就是Harness。2026年，OpenAI正式把Harness定义为独立学科。这意味着行业从“调Prompt”正式进入了“搭Harness”的时代。

但你要记住：这三个不是替代关系，是包含关系。

• Prompt工程是对“指令”的工程化
• Context工程是对“输入环境”的工程化
• Harness工程是对“整个运行系统”的工程化

你做一个Harness的时候，里面一定含着Context工程。Context工程里又含着Prompt工程。前一层没有消失，它变成了当前这一层的底座。

七层解剖：Harness到底长什么样？

论文里把Harness拆成了七层。我刚看到的时候觉得太学术了——什么ETCLOVG，根本不是给人念的名字。但读完细节，我发现这个分层非常成熟，每一层都对应着现实的工程痛点。

我给你画个简化版本：

+---------------------------+
| O 可观测性 | ← 贯穿各层
+---------------------------+
| V 验证与评估 | ← 贯穿各层
+---------------------------+
| G 治理与安全 | ← 底层准入
+---------------------------+
| E 执行环境与沙箱 | ← 结构支柱
+---------------------------+
| T 工具接口与协议 | ↓
+---------------------------+
| C 上下文与内存管理 | ↓
+---------------------------+
| L 生命周期与编排 | ↓
+---------------------------+

核心是E/T/C/L这四层，是跑Agent的骨架。然后O/V/G是控制平面，横着插进去的。

挑几个让我印象深刻的点给你讲：

E层：执行环境与沙箱

论文把这一层拆成了7个子类。代码专用沙箱、计算机使用Agent基础设施、浏览器评测环境……

你想想以前跑Agent最怕什么？跑着跑着把宿主系统的环境搞坏了。我一个朋友在2024年试过让Agent执行shell命令，结果直接修改了生产环境配置——还好发现得早。现在有了环境沙箱和OS级权限沙箱，Agent只能在笼子里跑。

我自己2025年构建一个代码审查Agent的时候，用了Docker容器做沙箱。每次agent session一个独立容器，任务结束就销毁。代价是冷启动多了大概8秒。但跟安全收益比起来，这8秒算什么啊？

C层：上下文与内存管理

论文总结出了三个难题：上下文膨胀、信息U型衰减、上下文漂移。

太精准了！

我自己测试过：上下文超过80K token，模型的有效信息召回率就开始断崖式下降。你放在中间那30K的信息，基本等于白费。所以现在有人在做progressive disclosure——不是一股脑塞进去，而是逐步暴露信息。这个方法我亲自试过，在RAG场景下准确率提升了13%。

V层：验证与评估

论文独创了一个五阶段的task-to-feedback lifecycle。我特别喜欢“执行前验证”这一步——在模型真正调用工具之前，先做一次合规检查。

去年我在写一个金融场景的Agent时加了这一步：Agent提出要执行某个SQL，我先用正则和schema检查语句是否安全，符合规则才放行。效果出奇的好，因为很多错误在执行之前就能看出来。

G层：治理与安全

LLM输入前、工具调用前、执行后、人工介入——四个拦截点。说白了就是给Agent上了三重门禁。

有个细节特别有意思：论文提到了“声明式宪法”这个概念。你定义一套规则（比如“不能删除超过100条记录”），Harness自动把这些规则嵌到各个拦截点上。而不是在prompt里写“请遵守公司政策”——那玩意儿模型根本记不住。

我去年就是吃了这个亏：提醒了800遍“不要删除用户数据”，结果Agent跑到第三层分支时还是调了DELETE。你说气不气人？

先让Agent撒欢，再给它套上笼子

光看论文不够，得看看真正拿Harness在用的团队是怎么干的。

我从几个公开分享里找到了非常有趣的策略，够不够爽？

Stripe：5秒级别拦下违规代码

Stripe的做法是这样的：先给Agent一个完整的开发环境，让它自主写代码。但每次Agent提交代码之后，“structural tests”会自动执行。Agent想违反模块边界？测试直接fail，代码合不进去。

整个流程快得离谱，5秒内就能告诉Agent：你这代码架构不合法。

Stripe的人说了一句让我印象特别深的话：“我们的核心挑战不再是让模型写代码，而是让它不写出违反架构的代码。”

Anthropic：从失败模式反推边界

Anthropic的做法更绝：先让Agent自由发挥一段时间，把它的所有失败模式都记下来。然后针对每种失败模式，设计一个harness里的“保险”。失败一次，加一条规则。失败模式收敛了，harness就稳定了。

他们有一个细节：每个session只让Agent做一个feature。这个约束通过system prompt传达，但Harness会检查agent的行为是否跨出边界。如果它想同时改三个文件做两个不相关的事，harness会直接打断它。

OpenAI：定期“垃圾回收”

OpenAI内部有一个很有意思的设计——不是等agent提交才检查，而是持续扫描整个代码库。如果发现架构drift，比如模块边界被侵蚀、重复代码积累，自动创建修复任务分配给agent。

环境主动把需要处理的问题推到agent面前，agent自己决定怎么修。

他们最后总结了一句话，我看了好几遍：

**“过去的思维是：让模型更聪明。现在的思维是：让系统更宽容。”**

好了，说到这儿，你大概能明白当年那个GPT-4为什么会对print(“Hello”)发疯了。

不是模型不行，是我给它的那个“笼子”不行。

我拼命在prompt里加规则，就像在笼子里贴满纸条——“请遵守纪律”。但笼子本身的门都没关好，它想出去就出去了。

Harness Engineering教我们的，不是什么更高级的提示技巧。它教我们：别再跟模型讲道理了。给它画条路，然后把它能走的路给铺好。

过去我们问“哪家模型最强”。现在该问的是——“谁家的harness最兜得住？”

你以为Agent是你的手下，错了。

它只是你设计好的那个笼子里，一只听话的鸟。

一篇好文章，要能让你带走一个念头。今天这个念头够劲：当模型的能力已经过剩，对系统的设计才是真本事。