Harness Engineering

介绍

2026 年初，AI 工程界达成了一个关键共识：

大模型能力的提升正遭遇边际效应递减，真正的瓶颈在于执行环境（Execution Environment）。

LangChain 团队曾做过一个实验：

使用同一个前沿模型，仅仅通过调整周围的”缰绳”（Harness）配置——包括上下文管理、工具权限、反馈机制——其基准测试成绩从 52.8% 飙升至 66.5%，排名从 Top 30 直接跃升至 Top 5。模型一行代码未改，仅凭”缰绳”的优化就实现了质的飞跃。

Mitchell Hashimoto（Terraform 之父）将这一现象命名为 Harness Engineering（缰绳工程）。而 Nous Research 刚刚开源的 Hermes Agent 正是 Harness Engineering 概念的第一次完整产品化。

传统 AI “一次性对话” —— 每次从零开始，用完即走。
Hermes “自我进化” —— 记住你，学习你，越用越懂你。

为什么非得套上 Harness？

因为大模型有 5 个改不掉的毛病：

无状态：聊完就忘，不记仇也不记账。
上下文腐烂：塞超过窗口 40%，逻辑就开始混乱。
工具调用幻觉：API 一多（几十个起），调错、传错参数。
开环：每一步只管自己输出，不为下一步负责。
过早停止：自己觉得差不多了，就宣布任务完成。

所以要在外面搭一套工程系统兜底。

Agent 是否真厉害？只需问几个问题

上下文怎么管？
- 有没有独立工作区？子Agent 之间会不会互相污染上下文？
- 任务断了能不能续?
有没有Checkpoint？走错一步，能回滚到哪一版?
- 错误是它自己修，还是你帮它修？
报错日志会不会自动喂回模型？还是要人肉介入？
“你这 Agent,Model用谁的，Harness是自己搓的还是用CMA?

答得上来再聊产品。答不上来，多半是Demo。

按 LangChain、Salesforce 的总结，Harness 工程关键有 6 件事：

持久化文件系统 —— 把没用上的上下文卸到文件里，窗口保持干净。
分层记忆 —— 短期上下文 / 中期文件 / 长期向量库，按需调度。
状态持久化与断点续跑 —— 每步打快照，断了能续，错了能回滚。
隔离沙箱 —— Docker 级强隔离，rm -rf 也烧不到宿主机。
错误自恢复 —— 报错日志喂回模型，自动改、自动重试。
全链路评估 —— 量化成功率、Token 成本、鲁棒性，把”玄学”变成”数据”。

一套生产级 Harness 大概要 1–2 个月。

2026年4月，Anthropic 把这套东西做成了PaaS服务：Claude Managed Agents（CMA），共内包含6 个 API 模块（Environments / Resources / Vaults & Memories / Sessions / Events / Agent Versions），对应上面 6 大能力，企业不再需要顶级基础设施团队，也能在短期内实现Claude Code级别的稳定性。

定义

Harness Engineering（驾驭工程）是 OpenAI 在 2026 年初正式提出的一套面向 AI 时代的新型软件工程方法论。

核心理念：「Humans steer, agents execute」（人类掌舵，智能体执行）。

传统软件开发模式中，工程师亲自编写每一行代码，就像自己骑马奔跑一样。
而在 Harness Engineering 范式下，人类工程师不再手动编写代码，而是转变为设计环境、明确意图和构建反馈回路的角色。

这种转变将工程速度提升数个数量级，最大化利用人类最稀缺的资源——时间和注意力。

OpenAI 实践数据非常惊人：在五个月内，仅用 3-7 名工程师的小团队，就从空 Git 仓库起步，交付了约 100 万行代码的产品，打开了约 1500 个 Pull Request，平均每位工程师每日能完成 3.5 个 PR，开发效率提升约 10 倍。更重要的是，这个产品已经拥有了数百名内测用户。

Harness Engineering 把问题推到了更远的一层：不只是管理信息输入，而是设计整个工作环境——围栏在哪里，路怎么铺，什么时候需要兽医巡检，马走偏了谁来纠正。

Harness 工程 = 给 AI 搭建”自动纠错的基础设施”（测试+监控+安全边界），让从”需要 babysit 的实习生”变成”能独立交付的工程师”。

核心公式

“Agent = Model + Harness”

Harness 原义: 挽具, 套在马身上的那套皮带、缰绳和金属件，让人可以引导一匹强壮但不知道该往哪走的动物去做有用的工作。

烈马、马具与骑手”的生产力模型：

烈马（AI 模型）：算力强大、速度极快，但容易偏离方向或产生幻觉。
马具（Harness）：基础设施、代码检查工具（Linters）、自动化测试、系统沙盒和反馈循环。
骑手（人类工程师）：提供方向、设定意图，并设计好这套“马具”。

演变

2026年2月，这个词几乎同时从三个地方冒了出来。

2月5日，Mitchell Hashimoto——HashiCorp创始人、Terraform作者——在博客里定义了 harness engineering：
每当agent犯一次错，就把工作环境改造一次，让它不可能再犯同样的错。
2月13日，OpenAI发表工作 Blog，标题直接用了这个词。
- 【2026-2-11】工程技术：在智能体优先的世界中利用 Codex
- Codex团队花了五个月，用零行手写代码构建了一个百万行的生产系统。工程师做了什么？不写代码。他们设计约束、编写文档、构建检查机制、部署定期清理“垃圾”的后台agent——所有这些都是在打造一副让AI能够稳定工作的挽具。
同一周，Martin Fowler 网站上发了一篇评论，把harness组成归纳为三块：
- context engineering（让agent看到该看的东西）
- architectural constraints（用确定性的规则卡住agent的行为边界）
- garbage collection（定期清扫agent制造的混乱）

进化路径: Prompt -> Context -> Harness

范式	时间	核心问题	主要手段	能解决什么	解决不了什么
`Prompt Engineering`	2023–2024	优化输入措辞，怎么”说”得好	精心设计指令、少样本示例	单次调用质量	多步骤任务的一致性
`Context Engineering`	2025	优化信息输入，”知道”什么	RAG、MCP、Memory、AGENTS.md	信息检索与注入	架构级的行为约束
`Harness Engineering`	2026	优化运行环境，在什么”环境”里做事	约束、验证、反馈回路、状态管理	系统可靠性与长期维护性	——（当前最前沿）

上下文工程见站内专题：上下文工程

总结

Thin Harness, Fat Skills

小红书图解

YC Combinator CEO Garry Tan 发布文章 Thin Harness, Fat Skills，不是“AI Agent 又要提效多少倍”，而是把 Agent 系统为什么会拉开差距讲清楚了。

同一个模型，有人只能用出 2 倍效率，有人能用出 10 倍、100 倍，差别不一定在模型本身，而在模型外面的架构。
Thin Harness 指运行模型的外壳要薄：负责模型循环、文件读写、上下文管理和安全边界，不要把所有工具、规则、接口都塞进去。
Fat Skills 指真正的能力要沉淀在可复用的 skill 里。一次调查、一次代码审查、一次资料整理，如果以后还会再做，就不该永远靠临场提示词，而应该写成可调用的流程。

记住：

需要理解、判断、综合、识别矛盾的事，交给模型。
需要查询、计算、排序、精确执行的事，交给确定性工具。
很多 Agent 不稳定，不是模型不够强，而是把工作放错了地方

Agent 设计准则框架

最上层: 大量的Agent Skills。Garry 称 Fat Skills，Agent软件中开发量最大的主体部分。
每个SKILL就像一个函数，等待被Agent调用。其中既包括纯粹用英语描述的SKILL.md，也包括完成任务的程序脚本。

二者要严格区分开：

前者在 Latent Space 工作，用文字驱动LLM的智能去做事情；
后者是确定逻辑（Deterministic）的，用代码脚本完成工作。

论文

总结

CMU / Yale / Amazon 等 9 个机构论文 Agent Harness Engineering

LLM agent 真正的瓶颈,可能不在模型 🔥

CMU、Yale、Amazon 等 9 个机构联合发布的 agent 系统提出相当直接的观点:

决定一个 LLM agent 能否在生产环境可靠运行的,往往不是模型本身,而是包在模型外面那层基础设施。

这层基础设施定义为 agent harness。

同一个模型, 完全不动权重,只改 harness:

coding benchmark 上 10× 提升
Terminal-Bench 2.0 上 +13.7 个点

表现超过所有人工调过的 baseline

核心贡献:

1️⃣ 提出 ETCLOVG 七层 taxonomy,涵盖 Execution / Tool / Context / Lifecycle / Observability / Verification / Governance
2️⃣ 系统梳理 170+ 个开源 agent 项目,看清各层生态密度
3️⃣ 总结了 prompt → context → harness engineering 的三阶段演化
4️⃣ 指出当前最薄弱的层(governance、observability)及未来研究方向

🎯 适合谁看:

做 coding agent、browser agent、long-running research agent,或者任何想把 agent 跑进生产的从业者。
📄 论文 + project page + Awesome list 链接在评论区自取～

Harness 要点

有效 harness 的六大组件，协同系统

组件名称	核心作用
System Prompts（系统提示词）	用 `AGENTS.md` / `CLAUDE.md` 写清项目规范、边界和约定，明确 Agent 的行为规则。
Tools & MCP（工具与MCP）	让 Agent 真正拥有可调用的工具链，从只会“说话”升级为能实际执行操作。
Skills（技能）	按需加载能力，避免把所有上下文一次性塞给模型，减少冗余并提升效率。
Sub-agents（子智能体）	把复杂任务拆小，让上下文范围受控、职责更清晰，降低主 Agent 的复杂度。
Hooks（钩子）	在关键节点插入确定性控制流，强制触发检查或动作，确保流程按规则执行。
Back-pressure（反压）	把测试、审查、规则校验反馈给 Agent，形成反压纠错机制，避免错误持续放大。

本质上，Harness Engineering 的目标

把 Agent 从“自由发挥”的黑盒模型，变成一个可预期、可控制、可校验的可控执行系统，少了任何一个组件都可能导致可靠性断层。

Harness 三大支柱：上下文工程、架构约束、熵管理

目标：不是限制产出，而是降低系统熵，让agent运行更稳定

四根最关键的「护栏」：

结构化文档（上下文工程） —— 新员工手册
- 结构化文档（AGENTS.md）是 AI 智能体进入代码仓库时看到的第一份指南。这不是一本 1000 页的说明书，而是一张地图——智能体需要的是清晰的路径指引，而不是冗长的细节描述。情境是一种稀缺资源，巨大的指令文件反而会挤掉任务、代码和相关文档的展示空间。
架构约束 —— 把品味编码成规则
- 每个团队都有自己的代码「品味」和架构原则，但在传统开发中，这些原则往往依赖于人的自觉遵守。Harness Engineering 将这些「品味」编码成可机械执行的规则——通过自定义 linters 和结构测试来强制执行架构规则。例如，依赖方向必须经过严格验证，仅允许有限的一组边；横切关注点必须通过单一显式接口进入。这种做法就像是在赛道上设置固定的护栏，赛马只能在规定的路径内奔跑。
反馈循环 —— 智能体审智能体；
- Agent 审查、自动化测试
- 传统开发中，人类工程师负责代码审查（Code Review）。
- Harness Engineering 中，这个工作变成了「智能体对智能体」的方式：
- Codex 在本地审核自身更改，请求额外审查，循环往复直到通过。人类可以审核 Pull Request，但已经不是必须步骤。这种机制就像赛马有自动计分系统，不需要人工裁判也能判定成绩。
可观测性（熵管理） —— 让智能体也能看日志
- 传统开发中，日志和监控主要是给人看的。
- 但在 Harness Engineering 中，AI 智能体也必须具备查看和分析这些信息的能力。这样智能体就能在独立版本上运行任务，查询监控系统来诊断问题，复现 bug 并验证修复。
- OpenAI 为 Codex 提供了完整的可观察性堆栈，包括日志、指标、追踪，支持使用 LogQL、PromQL、TraceQL 进行查询。
- 熵管理：小步偿还技术债，定期扫描偏差，文档自动修复过时内容

Harness Engineering 有个独特的概念——「熵与垃圾回收」。

随着时间推移，软件系统会逐渐变得混乱（熵增），技术债务会累积。

传统开发中，人们往往等到问题严重时才集中处理。
但在 Harness Engineering 中，OpenAI 采取了一种更持续的策略：定期运行后台 Codex 任务扫描偏差，更新质量等级，发起针对性重构 Pull Request。他们把这种方法形象地称为「垃圾回收」，并认为技术债务就像高息贷款——持续小额偿还优于一次性痛苦解决。此外，还有一个专门的「Doc-gardening」智能体扫描过时文档并修复。

实现

DeepMind AutoHarness

【2026-2-10】DeepMind 新论文解决了大语言模型做智能体的核心痛点，甚至让小模型直接吊打了大模型，思路简单又惊艳，非技术也能轻松看懂 AutoHarness。

《AutoHarness: improving LLM agents by automatically synthesizing a code harness》

AutoHarness 最打动人的地方，不是又刷了 benchmark，而是给 Agent 工程提供很清晰的方向：

不要把所有智能都塞进模型的一次输出里。让模型写代码，让代码守规则，让环境给反馈，让搜索来挑选可靠版本。

和做实际系统的经验非常一致。真正稳定的 Agent，往往不是“一个无所不能的大脑”，而是一个会把能力沉淀到工具、脚本、规则和测试里的系统。

AutoHarness 也许只是个开始，更有趣的问题：Agent 能不能不断把自己的失败经验固化成代码？能不能把这些代码迁移到新任务？能不能形成可审计、可复用、可演化的智能体操作层？

如果答案是肯定的，那么未来的 Agent 可能不只是会调用工具，而是会慢慢学会给自己建工具、写规则、做测试，并把一次次失败变成下一次成功的基础设施

harness 分成三类，从保守到激进依次：过滤、验证、直接生成

1 Harness-as-Action-Filter：模型先生成多个候选动作，代码过滤出合法动作，再让 LLM 从合法动作里选。
- 好处是安全，坏处是仍然比较依赖 LLM 产生足够好的候选集合。
2 Harness-as-Action-Verifier 论文主要实验采用的形态。
- 1． LLM 根据当前 observation 生成一个动作;
- 1. is_legal_action() 判断动作是否合法;
- 3．如果非法，就把“非法动作”反馈给LLM，让它重新生成;
- 1. 直到得到合法动作或达到限制。这相当于给 Agent 加了一个行动前的守门员。
3 Harness-as-Policy 更激进的版本：不只是写校验器，而是让代码直接生成动作。
- 测试时甚至可以不再调用 LLM。LLM只在训练阶段作为代码合成器出现，推理阶段运行纯 Python 策略。
- 这就从“LLM+代码护栏”变成了“LLM 生成出来的代码策略”。

港大 OpenHarness

港大开源的 Harness 系统 OpenHarness 在GitHub上迅速收获万颗星。

这套万行代码构建的AI基础设施，如同给大模型装上了手脚和记忆

43个工具是灵巧的手指，54条指令是清晰的指令集，10个子智能体是默契的团队。

港大开源 Harness 系统，打造”一键启动”的AI代理基础设施，让开发者轻松构建个性化AI工作流。

① 系统规模：43+工具、54条指令、10个子智能体构成完整AI代理框架
② 核心功能：文件操作、联网搜索、多智能体协作、持久记忆、权限控制等全方位支持
③ 使用便捷性：单命令”o”启动全部系统，无需复杂配置，上手即用
④ 模型兼容性：无缝对接Claude、OpenAI、Copilot等主流AI模型，灵活切换
⑤ 实际应用：ohmo个人代理可在企业通讯软件中工作，直接处理编程任务

一键启动的AI代理框架，让每个开发者都能拥有自己的”AI驾驶舱”。

使用

GitHub项目：OpenHarness

# 安装系统：
pip install openharness-ai
# 配置环境：
oh setup（Windows用openh setup）
# 启动系统：
oh（Windows用openh）
# 设置个人代理：
ohmo init → ohmo config → ohmo gateway start

护栏工程（Harness Engineering）指南

Harness Engineering