AI 工程新范式:Harness Engineering详解

📝 导读：当你的 Agent 还在"偶尔聪明、经常跑偏"时，有团队已经用 Harness Engineering 将成功率提升到 95% 以上。这不是模型的问题，是系统工程的问题。

一个真实案例引发的思考

年初，博主帮忙朋友调优一个 Agent 系统。团队已经竭尽全力：

• ✅ 换上了最好的大模型
• ✅ 提示词修改了上百版
• ✅ 各种参数反复调试

但实际表现依然不稳定——有时很聪明，有时莫名跑偏，任务成功率不到70%。

后来博主介入后，改动最大的地方既不是模型，也不是提示词，而是：

• 任务如何拆解
• 状态如何管理
• 关键步骤如何校验
• 失败后如何恢复

结果？同样的模型、同样的提示词，成功率提升到了 95% 以上。

朋友问："你到底改了啥？"

当时博主没有一个准确的词。直到最近 Harness Engineering 这个概念越来越火，才意识到：当时改的，本质上就是 Harness。

AI 工程的三次范式转移

过去两年，AI 工程经历了三次明显的重心迁移：

这三个阶段不是替代关系，而是包含关系——每一层都在前一层的边界上继续扩展。

Harness 到底是什么？

用一句通俗的话解释：

Harness = 让模型"别跑偏、跑得稳、出了错能拉回来"的一整套机制

🎯 一个比喻：派新人做客户拜访

假设你要派一个新人去完成一次重要的客户拜访：

Prompt Engineering = 把任务讲清楚

"见面先寒暄，再介绍方案，再问需求，最后约下一步"

Context Engineering = 把资料准备齐全

客户背景、过往沟通记录、产品报价、竞品信息、会议目标

Harness Engineering = 建立全程监督机制

带着 Checklist 去、关键节点实时汇报、会后及时记录和录音、发现偏差马上纠正、按明确标准验收结果

重点已经不是说清楚和资料齐不齐，而是有没有一套持续观测、持续纠偏、最终验收结果的机制。

成熟 Harness 的六层架构

根据一线公司（OpenAI、Anthropic 等）的实践，一个成熟的 Harness 系统可以分为六层：

第一层：上下文管理（Context Boundaries）

目标：让模型在正确的信息边界内思考

关键实践：

• 明确任务目标和成功标准
• 信息裁剪和筛选（越相关越好，不是越多越好）
• 结构化组织（规则放哪、状态放哪、外部证据放哪）

💡 洞察：信息一旦乱掉，模型就容易漏重点、忘约束甚至自我污染。

第二层：工具系统（Tool Integration）

目标：让模型能真正"做事"，不只是"说话"

关键实践：

• 给它什么工具（太少能力不够，太多注意力分散）
• 什么时候调用工具（不该查的时候别乱查，该查的时候别硬答）
• 工具结果如何重新喂给模型（提炼筛选，保持相关性）

第三层：执行编排（Execution Orchestration）

目标：解决"下一步该做什么"的问题

典型工作流： 1. 理解目标 2. 评估信息够不够，不够继续搜集 3. 执行并记录中间结果 4. 检查输出是否满足要求 5. 不满足则修正或重试

💡 这已经非常接近人类的工作方式——区别在于人靠经验，Agent 靠 Harness 环境。

第四层：记忆和状态（Memory & State）

目标：让 Agent 不"失忆"

需要区分的三层状态：

• 当前任务状态（会话中的中间结果）
• 长期记忆（用户偏好、历史经验）
• 系统状态（已完成/待完成/卡点）

💡 这三层如果混在一起，系统会越来越乱。

第五层：评估和观测（Evaluation & Observability）

目标：让系统知道自己做得好不好

关键能力：

• 输出质量验证
• 自动化测试和指标监控
• 问题归因和反馈

⚠️ 很多团队最容易忽视的一层——没有独立评估能力，Agent 就会长期停留在"自我感觉良好"的状态。

第六层：约束、校验与恢复（Constraints & Recovery）

目标：处理失败——因为在真实环境里，失败不是例外而是常态

必须包含的三件事：

 1. 约束：哪些能做，哪些不能做

 2. 校验：输出前后如何检查

 3. 恢复：失败后如何重试、回滚到稳定状态

💡 这一层往往才是决定系统上限的关键。

一线公司的真实实践

🏆 Anthropic：用 Harness 把排名从 30 名外杀到前 5

在底层模型完全不变的情况下，只通过改造和迭代 Harness，就把自家智能助手的排名从30 名开外提升到了前 5。

🤖 OpenAI：几名工程师构建百万行代码的生产系统

OpenAI 有一个只有几名人类工程师的团队，用 Agent 从零构建了一个超百万行代码的生产级应用：

• 100% 的代码由 Agent 编写
• 人类只负责约 10% 的关键决策
• Agent 可以完全自主编码，连续运行几个小时不出错
• 能做出完整的游戏、数字音频工作站等复杂应用

他们是怎么做到的？

关键洞察 1：上下文焦虑（Context Anxiety）

问题：任务时间一长，上下文越来越满，模型开始丢细节、丢重点，甚至"着急收尾"。

常规解法：Context Compaction（压缩上下文）

OpenAI 的做法：Context Reflect

不是压缩旧上下文，而是换一个干净的新的 Agent，把工作交接给它。

💡 这很像工程里遇到内存泄漏后，不是继续清缓存，而是直接重启整个进程再恢复状态。

关键洞察 2：自评偏差（Self-Evaluation Bias）

问题：模型自己干活，再让它自己打分，往往会偏乐观。

OpenAI 的做法：把干活的人和验收的人分开

• Planner：把模糊需求转化成完整规格
• Coder：负责逐步实现
• Verifier：像 QA 一样真实测试（不只是看代码，而是实际操作页面、检查结果）

💡 生产验收必须分离——只要评估者足够独立，系统就能形成"生成→检查→修复→再检查"的有效闭环。

🌐 Omini：重新定义工程师在 Agent 时代的工作

Omini 的思路非常有趣：人类不需要写一行代码，只需要设计环境。

工程师的工作变成三件事：

 1. 把产品目标拆解成 Agent 能执行的小任务

 2. Agent 失败时，不是让它"更努力"，而是问"环境里缺了什么能力"

 3. 建立反馈回路，让 Agent 真正能看到自己的执行结果

💡 当 Agent 遇到问题时，解决方案几乎从来不是"更努力"，而是"缺了什么样的结构性能力"。

📝 Omini 的另一个教训：Prompt 不是垃圾桶

早期错误：写了一个巨大的 Prompt，把所有规范、假设、约定全塞进去。

结果：Agent 更糊涂了。因为上下文窗口是稀缺资源，塞得太满等于什么都没说。

改进方案：把 Prompt 变成目录页

• 只保留核心索引
• 详细内容放到架构文档、设计文档、执行计划、质量评分、安全规则等具体子文档里
• Agent 需要时再查阅

💡 这本质上就是渐进式披露——不是信息全给，而是按需给、分层给、在正确的时间给。

🔍 让 Agent 看见整个应用

Omini 不只是让 Agent 写代码，还让 Agent 看见整个应用：

1. 接浏览器：能截图、能点击、能模拟用户真实操作 2. 接日志和指标系统：能查 Log、能查监控 3. 独立沙箱环境：每个任务在独立环境跑，互不影响

结果：Agent 不再是"写完就跑"，而是能跑起来看结果→发现问题→修复→再验证。

💡 这已经不只是代码规范，而是一套可持续运行的自动治理系统。

核心洞察：AI 落地的挑战正在转变

真正决定上线的可能是模型，但真正决定能不能落地、能不能稳定交付的是 Harness。

给实践者的建议

如果你正在做 Agent 相关项目，以下几点值得尽早想明白：

1. 不要过度迷信模型——同样的模型，不同的 Harness，表现差距可能极大

2. 评估和验收必须独立——让干活的人和验收的人分开

3. 失败是常态，不是例外——没有恢复机制的系统走不远

4. 渐进式披露优于信息堆砌——按需给、分层给、在正确的时间给

5. 人类角色正在转变——从写代码变成设计环境和反馈回路

📌 总结：Harness Engineering 不是要取代 Prompt 或 Context Engineering，而是在更大的系统边界上把前两者都包含进来。当任务从简单问答走向长链路、可执行、低容错的真实场景时，Harness 几乎不可避免。

AI 落地的下半场，拼的不是模型有多强，而是 Harness 有多稳。

来源：code 秘密花园

标题：Harness Engineering 完解析

小贴士：香港大学基于此，设计开发了一个基础底座OpenHarness项目，可供大家研究、学习或者定制开发：https://github.com/HKUDS/OpenHarness