一、Harness Engineering 的起源与提出者

Harness Engineering 在 2026 年爆火不是概念炒作，而是 AI Agent 能力跨越"实用阈值"后，工程化需求的自然爆发。直接导火索：OpenAI 的标志性事件

1.1 概念溯源
Harness 一词并非诞生于 AI 时代，它源自传统软件工程中的 "Test Harness"（测试夹具），最早出现在 ISTQB（国际软件测试认证委员会）词汇表中，指"在受控且可观测的环境中运行测试的脚本、Mock、桩和基础设施集合"。
在 AI 领域，这一概念经历了两次关键跃迁：

1.2 关键人物与文献
EleutherAI（2021）：首次将 Harness 系统化用于 LLM 评测，定义了"任务集 + Prompt Pipeline + 模型执行器"的三层结构
Addy Osmani（O'Reilly Radar, 2026）：发表 Agent Harness Engineering，提出 "一个 decent 模型 + 优秀的 harness 击败一个 great 模型 + 糟糕的 harness"
Nathan Lambert（Interconnects, 2026）：在 What comes next with open models 中提出 AI 系统 = Weights + Tools + Harness 的三元分解
OpenAI（2025-2026）：内部实践被业界广泛引用——通过 Harness 工程在 5 个月内构建 100 万行代码产品，SWE-bench 通过率约 80%
UK AISI（2025）：发布 Inspect AI 框架，定义了 Agent Harness 的"Dataset + Solver + Scorer"绑定范式

二、什么是 Harness Engineering

2.1 核心定义
Harness Engineering 是围绕 AI Agent 的评测、执行控制与持续迭代所构建的一套工程化体系。它的本质是把 Agent 在特定任务上的行为变成：
可重复、可版本化、可门禁的测试与评估流水线
学术界有更精确的定义。arXiv 论文 Necessary and Sufficient Conditions for an Agent Harness 将 Harness 分为三层语义：

2.2 Harness Engineering 的核心公式
业界公认的工程化范式可以概括为：
[ \text{Harness} + \text{Evals} + \text{Harness Engineering} \rightarrow \text{Better Agent} ]
即：测试框架 + 评估用例 + 框架工程能力 → 更优的智能体
这与传统 ML 的公式形成对偶：
[ \text{Model} + \text{Training Data} + \text{Gradient Descent} \rightarrow \text{Better Model} ]

 2.3 Harness的本质

Harness 本质上 是AI Agent（智能体）领域的一种工程基础设施参考框架。它的核心公式为 Agent = Model + Harness，旨在通过一套系统化的工程方案，将基础大模型的原始智能转化为可靠、可控、可用的智能体能力，以系统性地弥补裸模型在记忆、代码执行、工具调用等方面的固有缺陷。

从架构设计上看，真正的 Harness 是一套围绕着大语言模型建立的、纯粹的工业级管理制度，通常包含以下核心模块：

1. 文件系统与沙箱：提供工作空间、中间结果存储，并通过 Bash 加沙箱赋予 Agent 代码执行和自我验证的能力，同时提供安全隔离。
2. 记忆系统：通过文件存储和上下文注入，为模型提供长期记忆和知识扩展，对抗上下文腐烂。
3. 工具接入：通过 Web Search 加 MCP 突破模型知识截止日期的限制，获取实时信息并连接外部工具与数据源。
4. 编排协调与上下文工程：协调多个 Agent 协同工作，并在关键节点注入确定性检查以保障输出质量；同时管理模型的输入上下文，优化信息呈现。

三、如何设计一个 Harness Engineering

 3.1 基于当前业界共识（OpenAI、UK AISI、EleutherAI 的实践），我总结出六层设计模型：

3.2 六大设计原则（OpenAI 范式)

  根据 OpenAI 提出的 Harness Engineering 落地方法论：  

3.3 四类 Harness 的选择

3.4 关键设计决策清单
设计一个 Harness 时，需要回答以下问题：
被测对象是什么？黑盒（HTTP API）还是白盒（直接调用 Python 函数）？评测什么？最终输出（Result）还是执行轨迹（Trajectory）？通过标准如何定义？精确匹配、包含匹配、相似度阈值、多指标加权？如何保障可复现性？固定随机种子、隔离运行环境、版本化用例？如何闭环迭代？评测结果是否直接反馈给开发流程？

四、Harness 工程实践

4.1 判断一个工程是否是harness engineering？

  判断一个工程是否属于 Harness Engineering，其核心判断标准在于：工程师是否通过构建外部环境（缰绳），将 AI 的随机性转化为确定性，并建立起“从失败中学习”的闭环机制。

具体来说，判断一个工程是否体现了 Harness Engineering，主要看它在以下四个维度的具体表现：

1. 核心文件：是否存在“机器可读”的规则与错题本

这是判断 Harness 最直观的标志。如果项目中存在专门写给 AI 看的结构化文档，说明它已经脱离了纯粹的 Prompt 工程阶段。

• AGENTS.md / CLAUDE.md：这是 Harness 的“错题本”和“宪法”。它不仅包含代码规范，更重要的是记录了 Agent 过去犯过的错误及修正方式。每一次 Agent 的失败都被工程化地写进这个文件，确保同类错误不再发生。
• 结构化文档（docs目录）：存在作为“单一事实来源（Single Source of Truth）”的架构规范、API 契约和执行计划，Agent 在执行前会读取这些文档来理解上下文。

2. 代码与架构约束：是否存在“不可逾越”的机械护栏

Harness 不依赖 AI 的“自觉”，而是依赖代码层面的强制约束。

• 机械约束（Linter/结构测试）：代码库中配置了严格的 Linter 和架构测试（例如强制依赖流向必须遵守 Types → Config → Repo → Service → Runtime → UI 层级），任何违反规则的代码会被 CI 直接拒绝。Agent 无法绕过这些硬性边界。
• 具体表现：这相当于给 AI 戴上了“紧箍咒”，通过代码层面的自动化检查，强制 AI 遵守架构规范。Pre-commit Hooks（提交前拦截）：在代码提交到版本库之前，系统会自动运行架构检查脚本。如果 AI 生成的代码违反了规则（例如 UI 层直接调用了数据库层），代码会被直接拦截，无法进入主分支。自定义架构 Linter：不同于检查语法错误的常规工具，这类 Linter 专门用于检查架构边界。当 AI 违规时，Linter 不仅会报错，还会将“错误信息变成教学时刻（Teaching Moment）”。例如，它会明确告诉 AI：“违反了依赖方向规则，正确的做法是在 application 层定义接口，由 infrastructure 层实现”，并附带相关文档的链接，引导 AI 自动修正。契约对齐校验：在构建阶段，Harness 会自动比对前端类型定义与后端 API 契约。如果 AI 生成的代码出现字段缺失或类型不匹配，流水线会直接失败，迫使 AI 重新对齐规范。LLM 驱动的代理审查（Agent 互审）：在提交代码前，系统会触发一个专门的“审查 Agent”，让它像人类同事一样对生成的代码进行 Code Review，检查是否偏离了既定模式。
• 深度表现：除了基础的 Pre-commit 拦截和架构 Linter，真正的 Harness 还会包含以下深层约束机制：四层层级约束体系：Harness 的约束不仅限于代码风格，而是从底层到顶层的完整金字塔：架构约束：通过脚手架（如 Cookiecutter）强制规定项目目录结构、模块划分和技术栈限制。代码约束：除了常规的 Linter，还包括 Formatter（如 Prettier）强制统一格式，以及设计模式约束。安全约束：通过静态安全扫描工具（如 SonarQube、Snyk、CodeQL）强制执行输入验证规则、敏感数据处理限制和安全编码标准。业务约束：通过自定义验证框架和单元测试，强制验证领域模型规范、数据一致性和合规性要求。前馈控制（Feedforward / Guides）：不仅在代码写完后检查，还在 Agent 行动之前施加约束。例如提供测试前置条件、环境 Setup 规范，从源头提高 Agent 的一次成功率。并发 Agent 的隔离与协调约束：当多个 Agent 并行工作时，Harness 必须包含防冲突机制（如文件锁、目录隔离），防止多个 Agent 互相等待或同时修改同一文件导致代码库被污染。二阶控制（自我进化的约束）：Harness 的约束规则本身也是可进化的。系统会有后台 Agent 定期扫描技术债，一旦发现新的反模式，就会自动生成新的 Linter 规则，让“自我控制能力”越来越强。
• 受控的 REPL 容器：代码层面实现了一个具备边界控制、工具路由和确定性反馈的循环容器。模型被视为无状态的计算单元，所有需要跨轮次一致性的状态都被卸载到外部存储中。
• 具体表现：这相当于给 AI 提供了一个安全的“无菌手术室”和“质检仪”，确保它的操作是安全且可验证的。严格的沙箱隔离（Sandbox）：AI 的所有代码执行、命令运行都在一个受限的沙箱环境中进行。沙箱限制了网络访问、文件系统权限和资源配额，确保即使 AI 执行了高危命令，也不会破坏宿主环境。

3. 框架结构：是否具备完整的“感知-规划-行动-反馈”闭环

Harness 工程在架构上表现为一个持续运转的反馈循环，而不是简单的“一问一答”。

• CI/CD 深度集成：Agent 不是独立运行的脚本，而是直接操作开发工具链（自己开 PR、跑测试、根据失败信息迭代修改），人的角色从“写代码”转变为“审 PR”。
• 可观测性与垃圾回收：系统具备端到端的链路追踪和状态审计能力。同时，存在定期运行的“垃圾回收”机制，自动扫描并修复不再反映真实代码行为的过时文档，持续偿还技术债。
• 具体表现：确定性反馈协议（沉默即成功）：这是 Harness 最核心的反馈机制。当 AI 执行测试或命令时，如果成功，系统只返回一个极简的“✓”符号（占用极少 Token）；只有当测试失败时，才会将完整的结构化错误日志打印出来。这避免了 AI 被大量无用信息干扰，让它精准聚焦于修复问题。强制边界检查与死循环检测：在 AI 标记任务完成前，Harness 会强制拦截，要求其对照需求逐项确认边界条件和错误处理。此外，系统会监控 AI 的行为，如果同一文件被修改超过 3 次且测试仍失败，会触发干预机制（如建议回滚并重新审视需求），防止 AI 陷入死循环。状态卸载与无状态计算：在受控容器中，模型本身被视为无状态的。所有需要跨轮次保持一致性的状态（如当前的开发计划、中间结果、报错信息）都会被卸载到外部文件系统或数据库中。AI 每次执行下一步时，只需读取最新的文件状态，从而彻底对抗“上下文腐烂”。
• 深度表现：三层反馈闭环（神经系统）：即时反馈（秒级）：语法检查、静态分析、格式检查，快速捕获明显错误，减少无效迭代。功能反馈（分钟级）：单元测试、集成测试、类型检查，验证业务逻辑的正确性。深度反馈（小时级）：端到端测试、性能测试、安全扫描、用户验收，确保系统达到生产就绪状态。对抗与评估机制（Sprint Contract）：引入“Generator（生成者）”与“Evaluator（评估者）”的多轮博弈。两个 Agent 进行对抗，直到生成者的产出被评估者接受。这种对抗压力往往能逼出 AI 的创造力，并保证极高的代码质量。上下文规约与注意力管理（Token 转化流水线）：解决“无限状态 vs 有限 Token”的核心矛盾。在每次请求 LLM 前，Harness 会跑一条流水线：信息聚合 → 算分排序（按时间衰减和语义相似度丢弃低优上下文） → 预算分配 → 模板组装。主动管理模型的注意力，解决“大海捞针”的上下文失效问题。容错与兜底降级路径：当工具调用（Function Calling）失败或 JSON 解析报错时，Harness 不能直接挂掉。它必须将结构化的错误信息（如 Invalid JSON format）扔回给模型重试；如果连续失败（如 3 次），必须有回退到自然语言指令的机制，或者中断挂起请求人工介入。可观测层（Observability）：要求每次工具调用、模型回复、校验结果全部打结构化日志（Trace）。没有 Trace 就没有定位问题的能力，这是 Harness 能够持续优化的数据基础。分级沙箱策略：根据场景提供不同级别的隔离，从 L1 进程级隔离（速度快，适合内部工具），到 L2 容器隔离（Docker，行业标准），再到 L3 微虚拟机（Firecracker，适合多租户），甚至 L4 完全虚拟机。

4. 核心指标：是否实现了“模型无关”的性能跃升

这是检验 Harness 是否成功的最终业务表现。

• 环境优化带来的质变：如果在不改变底层大模型参数的前提下，仅仅通过优化外围环境（如文档结构、验证回路、代码编辑格式、追踪系统），就能让 Agent 的基准测试得分或实际产出质量获得数倍提升，这就是典型的 Harness Engineering 成果。

5. 最佳实践Harness的落地清单

(最小MVH)

优先级	核心模块	具体动作	机制 / 目的 / 内容
P0	最小可用底座 (先让 Agent 知道该做什么，且能验证)	建立唯一可信源（AGENTS.md）	内容：写明项目说明、核心架构规范、禁止操作（Hard Stops），以及最关键的完成定义（Definition of Done）。 强制验证：在文件末尾固化验证命令（如 pnpm typecheck && pnpm lint && pnpm test && pnpm build），明确规定：退出码不为 0，任务就不算完成，防止 Agent 过早宣布胜利。
		封装最小执行沙箱（Sandbox）	动作：使用 Docker 或 e2b 搭建隔离环境，编写 setup.sh 锁死依赖版本（如 pnpm install --frozen-lockfile）。 目的：赋予 Agent 安全的 Bash 和代码执行能力，形成“写代码 → 跑测试 → 看报错 → 修复”的自验证闭环。
		配置执行权限（Permissions）	动作：在配置文件（如 .claude/settings.json）中配置最小权限原则，限制 Agent 对宿主机核心文件的直接修改。
P1	状态与记忆管理 (解决跨会话失忆与上下文焦虑)	建立持久化进度文件（PROGRESS.md）	动作：创建 PROGRESS.md，包含四块内容：已完成、进行中、待办、已知问题。 机制：在 AGENTS.md 中固化约定——新会话第一件事读取 PROGRESS.md；任务完成或断点变化时，立即回写。
		实施上下文重置机制（Context Reset）	动作：设定 40% 上下文利用率为警戒线。 机制：当 Token 用量接近阈值时，强制 Agent 停下，将当前状态结构化提取并写入 PROGRESS.md，然后启动一个全新的干净 Agent 继续工作，对抗“上下文腐烂”。
		标准化校验动作路由	动作：建立“修改 → 校验”的标准路由。例如，改了框架跑 check-harness，改了 Java 代码必须跑 lint-java，不再靠经验判断。
P2	护栏与反馈闭环 (从“经验驱动”到“流程路由驱动”)	独立标准化护栏文件（Guards）	动作：在 AGENTS.md 或独立文件中明确三类护栏： 🚫 Hard Stops：绝对禁止行为（如禁止直接修改生产核心字段）。 🚨 Escalation Guards：必须升级决策（如影响用户 >1000 必须升级评审）。 ✅ Completion Guards：完成必须满足的关口（如未完成 3 轮 DB 对比不算完成）。
		引入 Hooks 系统（执行钩子）	动作：在关键操作（如文件写入、命令执行）前后注册检查 Hook。 目的：将团队的编码规范、安全要求编码成自动化规则，实现“违反即阻断”的硬性卡口。
		接入 CI/CD 自动化反馈	动作：在 PR 创建时自动运行测试和 Lint，部署可观测性工具监控 Agent 执行日志，让机器可执行的验证命令成为最终裁判。
P3	高阶熵管理与持续优化 (保持系统生命力)	定期扫描与垃圾回收	动作：后台运行周期性 Agent，定期扫描代码库里的技术债、过时的依赖、违反架构约束的模块，自动提交修复 PR。
		定期审视与删除冗余组件	动作：每季度回顾 Harness 的各个组件。随着模型能力的提升（如从 Sonnet 升级到 Opus），某些防护机制可能变得多余，应果断删除，保持 Harness 的简洁。
		建立三层评估管道	动作：引入 Inline evals（生成中实时检查）、Post-generation evals（生成后完整验证）和 Regression suite（历史失败案例作为回归测试），防止同类问题反复出现。

五、总结

Harness Engineering 的本质，是将控制论中所有的稳态设计套路（分层、边界、负反馈、二阶控制）一次性全部应用到 LLM Agent 身上。它是一套包含了状态管理、安全隔离、并发控制、动态反馈、可观测性以及自我进化的庞大系统工程。

判断一个工程是不是 Harness Engineering，不是看它用了什么代码或框架，而是看它的“控制面”是如何设计的。如果工程师的核心工作已经从“手写代码”转移到了“设计环境、明确意图、建反馈循环”，并且通过 AGENTS.md、机械约束、沙箱隔离等工程手段，让 AI 能够稳定、可预期、不重复犯错地完成复杂任务，那么这就是一个标准的 Harness Engineering 实践。
判断这些机制是否生效的具体表现就是：AI 无法绕过规则，且能在无人工干预的情况下实现“试错-报错-自动修复”的闭环。 人的角色从“写代码”和“口头提要求”，完全转移到了“制定 Linter 规则”、“维护沙箱环境”和“审查 AI 的测试报告”上。