大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



下午好，

2026 年初，OpenAI 的一个小型工程团队，用 5 个月时间，构建并交付了一个超过 100 万行代码的生产级软件产品。

这个产品有真实的内部用户，有外部 alpha 测试者，它发布、部署、出故障、被修复。

整个生命周期里，没有一行代码是人工编写的。工程师不写代码，他们用自然语言描述任务，运行 Agent，让 Agent 开 Pull Request，从应用逻辑到测试、CI 配置、可观测性设置，乃至内部工具，全部由 AI 完成。

听上去像科幻小说。

但如果你的第一反应是"那一定是因为用了最强的模型"，这正是今天我想打破的直觉。

LangChain 做过一次实验，他们的 coding agent 在 TerminalBench 2.0 基准测试上，从 52.8% 跳到了 66.5%，排名从前 30 开外进入了全球前 5。

他们改变了什么？模型一行没换，只改了包裹模型的那套系统。

这套系统，就叫做 Harness。它是决定 Agent 能力上限的真正变量，而不是模型本身。

书接上回，上两篇我们聊了提示词设计与 Skill 设计。

今天我们要讲的是一整套工程控制论，也就是那个把 AI 从"概率生成器"变成"可控工程系统"的底层基础设施。

"Harness"是马具的英文，不只是缰绳，也不只是马鞍，而是驯马师用来驾驭马匹的整套装置：辔头、胸甲、套索、车架。

这个比喻很精准：AI 模型像马，强大、迅速，但如果没有完整的驾驭系统，它不知道该往哪里走，也控制不了力道。

在工程语境里，Harness 的意思是包裹在 Agent 外部的那套完整控制系统，让模型的能力变成可预期的、可验证的、可迭代的工程行为。

要理解 Harness，需要先把它和两个经常被混淆的概念区分清楚。

最小的单元是 Prompt，即单次的文字输入，告诉模型"做什么"。

往外一层是 Context，也就是模型在每一步能"看到"什么，包括检索结果、历史记录、工具描述、文档片段。

而 Harness 是最外面那一层，是完整的控制系统，它不只是"给模型看什么"，还包括：动作如何被仲裁、状态如何跨会话延续、失败如何被检测和修复、行为如何被治理和审计。

一个关键认知是：Context Engineering 是 Harness 的子集，而不是同义词。

很多人谈到 Agent 工程就只想到 context 设计，这是一个根本性的认知缺口。

来自南洋理工大学和阿里巴巴联合实验室的论文给出了一个更精确的分解框架，把 Harness 写作 H = ⟨C, A, R⟩，即 Control、Agency、Runtime 三层。

Control 是持久存在的制约物，包括 AGENTS.md、架构规则、linter、权限策略、验收标准，人类的判断在这里被翻译成机器可读的约束。

Agency 是模型被允许做什么，代码执行、浏览器交互、文件读写、sub-agent 调度，这是 Harness 开放给模型的"可用动作空间"。

Runtime 是工作展开过程中的动态机制，包括上下文组装、记忆压缩、断点恢复、审批流程、预算管理、执行轨迹记录，这里决定长时程任务的成败。

论文特别指出，很多 Agent 系统的性能差异并非来自模型本身，而是"harness-sensitive"，取决于 Harness 层的设计质量。

同样的模型，同样的 prompt，不同的 Harness，行为可以有根本性差异。

与传统软件工程相比，这种变化是系统性的。在传统工程里，核心资产是代码，可靠性来自类型系统、编译器和单元测试，控制发生在编译期，失败了就修复 bug，工程师的核心工作是实现功能。

在 AI Agent 工程里，核心资产是 Harness，可靠性来自 Harness 的约束加上反馈循环，控制是运行时闭环、持续动态的，失败了就改进 Harness，工程师的核心工作是设计 Agent 可工作的环境。

Harness 有三大核心支柱，每个都值得单独深入。

第一个，也是最基础的一个，叫做 Context Engineering，即信息治理。

理解这个支柱，要从一个最根本的认知出发：从 Agent 的视角来看，任何在运行时无法在上下文中访问的内容，对它而言实际上都不存在。

存在于 Google Docs 里的决策、Slack 讨论里的架构方向、工程师脑子里的隐性知识，对 Agent 来说，这些都不存在。

这是 OpenAI 在《Harness Engineering》里明确指出的一点。

这句话听起来简单，但它的工程含义极其深远。想象一下：你们团队在 Slack 上花了两个小时讨论，最终决定了某个关键的架构模式，这个决策以后每天影响着代码的走向。

但如果这个决策没有被写进 repo、没有被 Agent 在运行时可以访问到，它对 Agent 来说和从未发生过没有区别。

OpenAI 用了一个非常准确的比喻：这就像一个新工程师加入团队三个月后，才有人告诉他"对了，上次的那个架构讨论……"。

三个月里，他所有的决策都建立在不完整的信息上。

OpenAI 最初的解决方案很直觉：把所有重要信息都放进一个大文件，他们叫它 AGENTS.md，一份给 Agent 的"终极操作手册"。

结果可预见地失败了，原因有三个，每一个都是系统性的。

第一是上下文挤占。

上下文窗口是稀缺资源，一个巨大的指令文件会把任务本身、相关代码、重要文档全都挤掉，Agent 不得不在"理解规则"和"完成任务"之间做零和博弈。

第二是注意力稀释。

当一个文件里 500 条规则都被标记为"重要"，这等于没有任何规则是重要的，Agent 开始做局部的模式匹配，而不是真正理解意图，这直接导致 hallucination 率上升。

第三是腐烂问题。

一个单体文件会成为过时规则的墓地，规则在写入的时候是正确的，但随着项目演进，没人维护这个文件，Agent 无法判断哪条规则还有效、哪条早已被废弃，一个文件安静地变成了"误导性诱惑"。

正确的解决方案是分层的信息架构，而不是单点的信息堆积。

第一层是静态知识层，包含 docs、schema、ADR（架构决策记录）和 golden principles，这些是永久有效的"系统真相"，放进 repo，随代码一起版本化管理。

第二层是动态状态层，包含 progress files、plans 和 execution logs，这些记录当前任务的进展，每次 Agent 启动时可以快速重建上下文。

第三层是即时任务层，即当前任务的描述和必要背景，尽可能精简，只包含完成这个具体任务所必需的信息。

这三层对应三种不同的信息生命周期，混在一起是认知负担，分开管理才是工程智慧。

来自 ThoughtWorks 的 Distinguished Engineer Birgitta Böckeler 在 Martin Fowler 的博客上提出了一个极其实用的分类。

驾驭 Agent 的上下文控制，分为两类完全不同性质的机制：Guides 和 Sensors。

Guides 是前馈控制，在 Agent 行动之前介入，预判行为并提前引导，目标是提高第一次就做对的概率，例如 AGENTS.md 里的架构约束、system prompt 里的行为规范。Sensors 是反馈控制，在 Agent 行动之后介入，观察结果，帮助自我纠正，例如 linter、测试失败信号、LLM as Judge 的评审结果。

两者缺一不可。

只有 Guides 没有 Sensors，Agent 就是在执行规则但从不知道规则是否起效，规则写了等于没写。

只有 Sensors 没有 Guides，Agent 每次都要犯错再改，效率极低且成本高昂。

在执行方式上，每种控制还分两种：

Computational 是确定性执行，由 CPU 执行，如 linter、schema validator、单元测试，快速、廉价、确定性结果，可以在每次代码变更时自动运行、毫秒级响应。

Inferential 是推断性执行，由 LLM 执行，如 LLM as Judge 的代码审查、语义一致性检查，速度慢、成本高，但能处理确定性工具无法捕捉的语义层问题，比如"这段代码风格是否与项目整体一致？"

最优实践是混合使用：用 Computational 做高频低成本的检查，用 Inferential 做低频高价值的语义判断，这种混合架构让 Harness 既快又准。

第二个支柱叫做 Architectural Constraints，是 Harness 设计里最反直觉的一个原则。

人们通常觉得，给 AI 更多自由度，它才能发挥更大的创造力，产出更高质量的结果。

实践证明，恰恰相反。更多约束往往带来更高的可靠性，而不是更低。

OpenAI 的 Codex 团队发现，当 Agent 在由 linter 和 validator 强制执行的严格架构边界内工作时，表现反而更好。

为什么？

这里有一个深层的控制论逻辑。Agent 本质上是一个在巨大搜索空间里工作的系统。

没有约束时，这个搜索空间几乎是无限的：可以选择任意语言、任意模式、任意架构风格。

这看起来是"自由"，但在实践中意味着 Agent 需要在每一个决策节点做大量的隐性权衡，而大多数时候，它没有足够的上下文来做好这些判断。

约束就是在收缩搜索空间，当某些路径被明确关闭，Agent 的"注意力"就可以集中在剩余的合法空间里，做出更高质量的选择，这正是控制论里 Boundary Conditions 的作用：不是限制能力，而是引导收敛。

Architectural Constraints 不是文档里写的"建议"，而是系统强制执行的硬规则，执行方式分两类。

第一类是机械约束，通过 custom linters、structural tests 和 dependency rules 实现。这些工具在 CI/CD 流水线里自动运行，违反约束的 PR 会被自动拒绝，没有人工干预空间，没有例外。

比如 OpenAI 的实践里有这样的规则：

禁止跨模块直接引用内部实现；所有外部数据必须在边界处验证或使用 typed SDK，不允许"YOLO 式"的数据假设，即假设某个字段存在然后直接用。

这些规则通过 linter 自动检查，任何违反都会被 CI 拒绝。

为什么这么重要？

因为当 Agent 产出量爆炸，没有人工能逐个 review 每一个边界假设，机械约束是唯一可以规模化的保障手段。

第二类是语义约束，通过 agent review agent 实现。

一个专门的 Agent 扮演代码审查员，用语义理解来检查另一个 Agent 的输出是否符合项目的整体风格、意图和质量标准，这些是确定性工具无法检测的东西，需要语言理解能力。

OpenAI 把他们最重要的架构约束称为"Golden Principles"。

关键在于，这不是一份规范文档，而是直接编码进 repo 的可执行规则。举两个具体例子：

第一，优先使用 shared utility package，不要手写重复的 helper，这条规则通过 linter 检测重复代码模式来强制执行，原因是如果相同逻辑散落在多处，Agent 每次更新时必须找到所有实例一起改，这对 Agent 来说极其容易出错，集中到单一位置，不变量就只有一个地方需要维护。

第二，不允许在未验证的数据结构上构建逻辑，Agent 有时会根据上下文"猜测"某个 API 的返回结构然后直接使用，这在 demo 里没问题，在生产里是灾难，这条规则要求所有外部数据都必须通过 schema 验证，强制 Agent 只能在已知的结构上工作。

这里还有一个有趣的正向循环：

强约束不只是让当前的 Agent 运行得更好，还让整个代码库对未来的 Agent 运行更加友好。

当代码结构是一致的、模块边界是清晰的、命名是可预期的，Agent 在下一次任务里需要理解这个代码库时，花费的认知成本大幅降低，约束创造了一种自我强化的可理解性。

第三个支柱是 Garbage Collection，这是 OpenAI 在实践中发现的一个最出人意料的教训，也是被大多数 Harness 讨论遗漏的核心机制。

每一个工程师都了解技术债，糟糕的代码会慢慢积累，直到有人花一大段时间清理，这是传统软件工程的节奏：缓慢积累，定期清理。

当 Agent 开始写代码，这个节奏发生了根本性的变化。

Agent 的工作方式是模式匹配和模式复制，它学习代码库里已有的模式，然后在新代码里延续这些模式。

这本来是好事，这就是为什么代码库对 Agent 的可读性如此重要。

但这里有一个致命的副作用：Agent 会以同样的效率复制错误的模式。

想象一下：某个工程师在某次任务里写了一个不规范的 helper，在传统开发里，这个 helper 可能只会被少数几个地方用到，影响有限。

但如果 Agent 认为这是"项目里已有的模式"，它可能在接下来的 100 个任务里都用同样的方式写 helper，技术债的扩散速度，从人类的手速变成了 Agent 的机器速度。

OpenAI 团队曾每周五花费整整一天，即 20% 的工作时间，清理这类"AI slop"。

这显然无法随着规模扩大而延续。

OpenAI 的解决方案是把"清理"本身变成一个系统性的、自动化的流程，而不是依赖人工的例行工作。具体方法分三步。

第一步，将 Golden Principles 编码进 repo，前面讲过，Golden Principles 是架构约束的精华，把它们变成机器可读的格式，是 GC Agent 能自动运行的基础。

第二步，定期运行后台 GC Agent，这些 Agent 不是在响应具体任务，而是主动扫描整个代码库，查找偏离 Golden Principles 的代码模式、文档与代码之间的不一致、过时或错误的注释，以及架构约束的违反。

第三步，自动开 PR，人工快速审查，GC Agent 找到问题后，不是把问题报告给人工，而是直接开 Pull Request 提出修复方案，由于修复的是明确定义的规则违反，大多数 PR 可以在不到一分钟内完成审查并自动合并。

这是一个关键的工程突破：把"清理技术债"这件事从人工的、偶发的、依赖纪律性的工作，变成了机械的、持续的、由系统保证的流程。

GC 有两个维度。

代码 GC 负责检测架构约束的违反，找到错误模式的复制，触发 refactor PR，这是最直接的熵控制。

文档 GC 负责检测 docs 与代码之间的不一致，清理过时的规则和描述，更新 AGENTS.md 里已经失效的指引。

文档腐烂对 Agent 来说比对人类更危险，因为 Agent 会认真地按照文档执行，即使文档是错的。

从控制论的视角来看，这是一个熵增与秩序恢复的动态平衡。

没有 GC 机制的 Harness，就像一个没有垃圾回收的运行时：短期可以工作，但随着时间推移，系统会因为熵增而逐渐失控。

Context Engineering、Architectural Constraints、Garbage Collection，三个支柱各自独立，但真正让 Harness 运转起来的，是把它们连接成一个闭环的反馈机制。

标准反馈循环的流程是这样的：

描述任务，Agent 生成，测试和 Lint，Agent 修复，Agent Review，合并，最后观察并改进 Harness。

注意这个循环的最后一步，不是"任务完成"，而是"改进 Harness"。这是整个方法论里最重要的思维方式转变。

OpenAI 的原文在这一点上说得非常清晰：当 Agent 遇到困难时，他们将其视为信号，识别缺失了什么，工具、护栏、文档，然后把改进反馈回 repo，始终让 Codex 自己来写这个修复，修复的方式，几乎从来不是"努力重试"。

这句话非常值得慢慢品味。

当 Agent 失败了，传统的反应是调整 prompt、换个措辞、多试几次，而 OpenAI 的反应是，这个失败说明 Harness 里缺少某个东西，把那个东西加进去。

这是一种截然不同的问题诊断思路，失败不是 Agent 的问题，是环境的问题，环境设计者也就是工程师的工作，就是让环境更好，让同样的失败不再发生。

反馈结构分三个层级。

Micro 层是单步层，触发于单次 tool call 失败或 linter 报错，Agent 立即重试和修正，由 Harness 自动处理。

Task 层是任务层，触发于 PR 被 agent review 打回，Agent 迭代修改，直到所有 reviewer 满意，由 Agent 加自动流程处理。

System 层是全局层，触发于某类错误反复出现或 GC Agent 发现模式性问题，响应方式是更新 Harness 本身，加规则、加 linter、改文档，由工程师主导。

这三层反馈处理不同粒度的问题，大多数 Agent 系统只做了 Micro 层，这远远不够。

在 PR 的自动闭环上，OpenAI 有一个具体机制值得单独说：他们让 Agent review 自己的 PR，然后响应来自其他专项 Agent 的 review 意见，迭代修改，直到所有 Agent reviewer 都满意，才允许 PR 进入人工审查阶段。

这意味着大量的低价值工作，格式问题、明显逻辑错误、文档缺失，在到达人工之前就已经被自动过滤和修复。

人工只需要关注真正需要判断力的问题：架构决策、产品逻辑、安全风险。

如果前面三个支柱描述的是"做什么"，那么 Legibility 描述的是"为了谁设计"。

这是整个 Harness 工程的第一性原理，却经常被讨论者忽略。

Legibility 字面意思是"可读性"。

但在 Harness 语境里，它的含义比人类工程师的代码可读性更精确、更苛刻：Agent 能理解的系统，才是对 Agent 存在的系统。

从 Agent 的视角出发，理解某个东西有三个条件：

它在运行时的上下文里出现，也就是可访问；它以 Agent 能推理的方式组织，也就是可导航；它包含 Agent 做出正确决策所需的充分信息，也就是可推理。

任何一个条件不满足，那个信息对 Agent 来说就是虚构的。

OpenAI 在《Harness Engineering》里有一段话非常核心：因为 repo 完全由 Agent 生成，它首先针对 Codex 的可读性进行优化，就像团队努力提升代码库对新工程师的可导航性一样，工程师的目标是让 Agent 能够直接从 repo 本身推理出完整的业务领域。

这个实践有一个朴素但根本的结论：所有对 Agent 工作有影响的知识，必须以某种形式进入 repo。

这不仅是技术要求，它从根本上改变了工程团队的信息管理习惯。Slack 讨论了重要的架构决策，就要写进 ADR，放进 docs 目录。

口头对齐了某个 API 的行为规范，就要写成 schema，放进 repo。

某个边界情况在会议上达成了共识，就要写成注释或 AGENTS.md 条目，版本化管理。

这种实践的意义远超 AI 工程本身，它实际上是在强迫团队做一件一直应该做但很少做到的事：把隐性知识显性化，把口头共识文档化，把团队智慧变成系统智慧。

Legibility 不意味着"信息越多越好"，恰恰相反，好的 Legibility 设计需要精心管理信息的暴露层次。

入口层即 AGENTS.md，这是 Agent 在一个 repo 里看到的第一张地图。

它应该是目录，不是手册。简明地告诉 Agent：这个 repo 里有什么，重要的文档在哪里，运行和测试的方式，以及最关键的几条行为规范。

读完 AGENTS.md，Agent 应该知道去哪里找它需要的东西，而不是已经找到了所有东西。

领域层即 docs 目录，是按功能域、技术领域组织的深度文档，Agent 在需要特定信息时按需加载，文档写法应该对"新工程师"友好，因为 Agent 的推理方式与新工程师非常相似，都需要从显性信息中重建上下文。

执行层包含 schema、ADR 和 plans，是机器可读的规范，schema 定义数据结构，ADR 记录架构决策的来龙去脉，executable plans 描述可以被 Agent 直接执行的任务分解，这一层是 Context Engineering 和 Architectural Constraints 的交汇点。

一个 Harness 的 Legibility 质量可以通过几个代理指标来衡量。

首次尝试成功率，即 Agent 在第一次尝试时就正确完成任务的比例，这是 Legibility 最直接的量化指标，如果 Agent 经常需要多轮迭代才能做对，往往说明它在第一次就缺少某个关键信息。

人工干预频率，即需要工程师手动介入纠正 Agent 行为的频率，频率高说明 Harness 提供的上下文不足以让 Agent 自主完成工作。

Hallucination 率，即 Agent 凭空创造了不存在的 API、不存在的模块、不存在的约定的频率，Hallucination 很大程度上是 Legibility 失败的症状：Agent 没有找到真实信息，于是用猜测填补空白。

到这里，我们已经讲完了 Harness 的技术层面。

但还有一个同样重要的维度，是关于工程文化和工程哲学的。

当 Agent 的产出速度开始超越人类的处理速度，整个工程团队的运作方式必须重构。

OpenAI 的实验里有一个数字没有被广泛引用，但极其关键：在全量使用 Agent 工作后，PR 的数量是传统开发模式的数倍乃至数十倍。

每个 Agent 任务都会产生 PR，Agent 的并发能力意味着可以同时运行大量任务。

这立刻暴露了一个问题：人工 code review 成了瓶颈。

传统开发的 code review 已经是很多团队最慢的环节，现在 PR 量是原来的十倍，人工审查能力完全跟不上。

这带来了工程文化的三个根本转变。

在质量保障上，旧范式是通过预防错误保证质量，大量的预防性 review，谨慎地合并；新范式是通过迭代修正保证质量，快速合并，出了问题立即修复。

在 PR 节奏上，旧范式是大 PR、慢审查，每个 PR 包含大量变更，review 成本高；新范式是小 PR、快合并，每个 PR 聚焦单一任务，agent review 先行。

在人工介入上，旧范式是逐行 review，人工是每个变更的守门人；新范式是人工关注高风险决策点，低风险变更由 agent review 自动处理。

这种转变需要工程团队对"风险"有完全不同的认知。传统范式里，合并未经仔细 review 的代码是高风险行为。

新范式里，有完善 Harness 保障的代码，在 agent review 通过后即可快速合并，出了问题可以快速 revert 和修复，整体风险是可控的。

这是整个 Harness Engineering 讨论里最具人文色彩的部分：工程师在做什么？在传统软件工程里，工程师的价值体现在写出正确、高效、优雅的代码。

在 Agent 工程里，工程师的价值体现在设计出一个让 Agent 能正确、高效、优雅地工作的环境。这不是技能的降级，而是抽象层次的提升。

就像操作系统的出现让程序员不需要手动管理寄存器，Harness 的出现让工程师从"写代码"升维到"设计可靠的 Agent 运行系统"。

OpenAI 的原文这样表述：我们需要理解的，是当一个软件工程团队的主要工作不再是写代码，而是设计环境、定义意图、构建让 Agent 可靠工作的反馈循环时，会发生什么变化。

具体地说，工程师现在做的事包括：

观察 Agent 的失败模式，诊断 Harness 里缺少的东西；

设计和实现新的 linter、新的约束、新的上下文组织方式；

评估哪些任务适合全量交给 Agent，哪些任务需要人工介入；

维护整个系统的 Legibility，确保 Agent 永远有足够的信息工作。

这些工作需要的能力，是系统性思维、对 Agent 行为的深度理解、对控制系统设计的把握，某种程度上，比"写出好代码"要求更高级的工程判断力。

Harness Engineering 作为一个正式领域，2026 年才刚刚命名。但已经有一批研究者在探索它的下一个形态。

Anthropic 在 2025 年 11 月发表了《Effective Harnesses for Long-Running Agents》，解决的是一个具体而普遍的问题：即使是最强的模型，如果只给它一个高层次的 prompt，比如"帮我构建一个 claude.ai 的克隆"，它也会失败。

失败的模式很固定：Agent 要么试图一口气做完所有事情，然后中途用完 context window；要么做了一半就自认为完成了，即 premature victory；要么在新会话开始时不记得上次做了什么，从头再来。

Anthropic 的解决方案是一套双 Agent 架构，本质上是 Harness 的 Runtime 层设计。

Initializer Agent 在第一次会话运行时，创建 feature_list.json，里面包含 200 多个粒度化的功能点，初始状态全部标记为"failing"；初始化 git repo；创建 claude-progress.txt 进度日志；创建 init.sh 启动脚本。

Coding Agent 在每次会话运行时，从读取 git log 和进度文件开始，重建上下文；运行基础 smoke test；从 feature_list.json 里选择一个 failing 的功能点实现；提交代码并更新进度文件；确保每次都在"干净状态"结束，方便下一个会话接手。

两个细节特别值得注意。

第一，feature list 用 JSON 格式而非 Markdown，因为实验发现模型更不容易"不当修改"JSON 格式的数据，而 Markdown 格式的 list Agent 有时会自行重组或删改。

第二，每次会话结束时必须留下"干净状态"，这是把人类工程师的交接班规范，翻译成了 Agent 可以遵循的结构化要求。

这套方案的核心思想被 arXiv 中的论文总结为三个属性：状态必须是"外部化的"，即写入文件而非只在内存里；"路径可寻址的"，即可以通过路径重新打开；"压缩稳定的"，即在 context truncation 和 restart 后依然可用。

清华大学深圳研究生院的团队在 2026 年 3 月提出了一个更激进的方向：如果 Harness 的控制逻辑现在被埋在 Python 代码、控制器代码和 runtime 特定的约定里，能不能把这些逻辑"外部化"，变成用自然语言写成的、可以被不同 runtime 执行的可移植文件？

他们把这个东西叫做 NLAH，即 Natural-Language Agent Harness，它用可编辑的自然语言表达 Harness 的行为，包括角色定义、合同约束、验证门控、持久化状态语义、委派边界，并通过一个共享 runtime 来执行。

如果 Harness 的逻辑可以被写成自然语言文件，它就变成了一个可以被检查、可以被跨团队迁移、可以被比较和研究的科学对象，而不是埋在特定代码库里的"隐性实现"。

Meta-Harness 是 2026 年 3 月由 Stanford、MIT 和 KRAFTON 联合发表的论文，它提出了一个真正令人惊奇的方向：把"优化 Harness"这件事本身交给 Agent 来做。

Meta-Harness 是一个 coding agent，它通过访问完整的文件系统、检查和验证代码改动，来搜索更好的 Harness 配置，它会存储之前尝试过的源代码、评估分数和执行轨迹，从历史中学习，进化出更好的 Harness。

实验结果相当令人信服：

在在线文本分类任务上，Meta-Harness 比强 baseline 高 7.7 个百分点，同时使用的 context token 减少 4 倍；

在数学推理上，单个发现的 Harness 平均提升 5 个模型的准确率 4.7 个百分点；

在 TerminalBench-2 上，使用 Claude Opus 4.6 达到 76.4%，超过了此前最好的 74.7%。

这些数字的意义不在于它们的绝对值，而在于它们的来源：没有换模型，只是自动优化了 Harness，就获得了这样的提升，这是对"Harness 比模型更重要"这个命题最有力的实证。

NTU 和阿里巴巴联合实验室的论文提出了 HARNESSCARD，一个轻量级的披露模板，要求研究者在发表 Agent 相关论文时，不只报告模型，还要报告 Harness 层的关键设计。

这背后有一个严肃的方法论问题：当两篇论文比较不同 Agent 系统的性能时，如果它们的 Harness 不同，这个比较是在比什么？

很多文献报告的"性能提升"，实际上可能是 harness-sensitive 的，换了 Harness 设计就不成立，HARNESSCARD 是一次让这个领域的研究更可比较、更可重现的尝试。

我们从一个反直觉的数字开始：同样的模型，不同的 Harness，性能差距可以超过 13 个百分点。

然后我们沿着这个问题往深处走，一路走到了控制论、信息治理、约束设计、熵控制、系统反馈和工程哲学。现在可以把整个图景连起来了。

Harness 是 Agent 的操作系统。

它通过三个核心支柱运作：

Context Engineering 管理信息，让 Agent 看到它需要看到的东西，不多也不少；

Architectural Constraints 管理行为，用机械约束和语义约束共同把 Agent 的行动空间收缩到正确的范围；

Garbage Collection 管理熵增，用自动化的清洁机制对抗 Agent 高速工作带来的技术债扩散。

这三个支柱通过反馈循环连接成一个闭环系统，而整个系统服务于一个第一性原理，即 Legibility，让 Agent 能够理解和导航它工作的环境。

在这套系统成立的前提下，工程的哲学发生了根本转变：从"通过预防保证质量"变成"通过迭代保证质量"，从"工程师写代码"变成"工程师设计 Agent 工作的环境"。

在实践中，有几类常见的 Harness 反模式值得警惕。

第一是超大单体 AGENTS.md，把所有规则堆在一个文件里，结果是什么都重要等于什么都不重要，而且文件必然腐烂。

第二是无约束工具调用，给 Agent 无限的工具访问权限，没有边界条件，没有权限管理，越界行为不是概率问题，是时间问题。

第三是无 eval、无 sensor，没有任何机制观察 Agent 的行为是否正确，所有问题都靠事后人工发现。

第四是依赖 Agent 的自我判断，让 Agent 自己决定任务是否完成、质量是否达标，而生成与评估必须分离。

第五是忽视熵增，没有 GC 机制，不定期清理技术债，等待着 Agent 复制错误模式直到代码库失控。

第六是知识留在 repo 之外，重要的架构决策在 Slack 上，重要的约定在人脑里，对 Agent 来说，这些知识都不存在。

没有任何团队能从零到完整的 Harness，这是一个渐进的工程过程，通常沿着这条路径演化：

从一个强制函数开始，比如"新模块不允许手写代码"，强迫团队投入 Harness 建设；

然后建立最基本的 Context 架构，AGENTS.md 加 docs 目录；

接着加入第一批机械约束，linter 加 structural tests；

随着任务量增加，加入反馈循环，agent review 加自动 merge；

当技术债开始出现，加入 GC Agent；随着团队积累经验，持续细化 Golden Principles，让 Harness 越来越精准。

这个过程可能需要数月，OpenAI 花了 5 个月。

但 Harness 本身是一个复利工具：投入越多，回报越高，而且随时间指数级放大。

回到最开始的类比：你不会在没有操作系统的裸 CPU 上运行业务。

无论 CPU 多强，没有操作系统，它只是一块运算芯片，无法完成任何有意义的工作。

模型是 CPU，Harness 是操作系统。

在没有 Harness 的情况下，直接在模型上构建生产级 Agent 系统，这不是工程，这是赌博。

好的消息是：Harness Engineering 的原则正在快速成形，工具正在快速成熟，社区正在积累可以直接借鉴的实践。

这个时代的工程师，不再只是写代码的人，他们是设计系统的人，设计让智能可以可靠地工作的系统。

Agent 的能力上限，不由模型决定，而由 Harness 决定。

软件工程正在从"写代码"演化为"设计可靠的 Agent 运行环境"。

这个转变，既是挑战，也是机遇。