Harness Engineering

Harness Engineering

AI 工程的重心正在经历第三次迁移：Prompt Engineering → Context Engineering → Harness Engineering。本文从演进脉络、构成解析和业界实践三个角度，完整拆解这一新概念。

Harness Engineering 概览 | harness_00.png

一、Harness 的演进

过去两年，AI 工程领域经历了三次重心迁移。表面上看只是术语在更新，但把时间线拉长，你会发现它们对应着三个越来越本质的问题：

  • 模型是否听得懂你在说什么？
  • 模型是否拿到了足够且正确的信息？
  • 模型是否能在真实执行中持续做对？

理解这三次迁移，不只是理解几个新名词，而是在理解 AI 系统是如何一步步从"会聊天"走向"可交付"的。

1.1 Prompt Engineering

大模型刚爆发的时候，很多人第一次感受到一种近乎魔法的体验：同一个模型，换一种说法，结果可能天差地别。

你对它说："帮我总结一下这篇文章。" 它可能给你一段平平无奇的概述。但如果你换成：

"请以资深技术编辑的身份，用三段结构总结这篇文章，先讲核心观点，再讲论证方式，最后讲局限性，每段不超过 150 字。"

结果通常会明显好很多。这就是 Prompt Engineering 最早的魅力所在。

它的核心思想很朴素：模型不是不会，而是你没有把问题讲清楚。 既然模型对输入形式敏感，那工程优化的第一步，自然就是优化指令本身。

于是，一整套方法迅速流行起来：

Prompt Engineering 常见技巧 | harness_01.png

技巧 说明
角色设定 先告诉模型"你是谁"，限定专业视角，你是一个XXXX
风格约束 告诉模型"怎么说"，控制表达方式，你不能XXX，应该XXX
Few-shot 示例 少讲原则，多给样例，模型更擅长模仿范式
分步引导 别让它直接跳答案，先拆再想再答
格式约束 提前规定输出长什么样，提升可用性
拒答边界 先划红线，再让它回答，降低"不知道还自信"的风险

Prompt Engineering 为什么会有效

因为大模型本质上是一个对上下文极度敏感的概率生成系统。它不是"命令行"，更像是一个临时搭建出来的认知场：

概率生成系统示意 | harness_02.png

  • 你给它什么身份，它会沿着那个身份分布去采样
  • 你给它什么例子，它会沿着那个模式继续补全
  • 你强调什么约束，它就更可能把那部分当成高权重信号

所以，Prompt Engineering 的本质，不是"下命令"，而是"塑造局部概率空间"。

Prompt Engineering 的天花板

Prompt 问题出在：很多任务不是"你说清楚就行"，而是"你得真的知道"。比如你让模型分析一份公司内部文档、回答某个产品最新配置、对照一套长规范生成代码……

提示词再漂亮，也不能替代事实本身。

  • Prompt 擅长：澄清任务、约束输出、激发已有能力
  • Prompt 不擅长：凭空补齐缺失知识、管理大量动态信息、处理长链条任务中的状态变化

说得更直接一点：单纯提示词是有上限的，Prompt 解决的是"表达问题"，不是"信息问题"。

1.2 Context Engineering

如果说 Prompt Engineering 的默认假设是：模型本来就知道，只是你得问对。

那么 Context Engineering 的默认假设变成了：模型未必知道，所以系统必须在调用时把正确的信息送进去。

为什么 Context Engineering 会兴起

最重要的原因是模型的使用场景变了。

在大模型刚流行的时候，主流交互形态还是聊天：用户提一个问题，模型给一段回答。这种模式下，Prompt 的权重很高。

但后来 Agent 开始爆火，情况一下子变了。模型不再只是回答问题，而开始被放进真实的执行环境中：

  • 要持续多轮对话
  • 要调用搜索、浏览器、代码、数据库等工具
  • 要在多个步骤之间传递中间结果
  • 要根据外部反馈不断修正计划
  • 甚至要和其他 Agent 分工协作

这时候，系统面对的已经不是"一次回答对不对"，而是"一整个任务链路能不能跑通"。

Context 到底是什么

在工程意义上，Context 不是一堆附加文本，而是所有会影响模型当前决策的信息总和：

Context 构成全景 | harness_03.png

  • 当前用户输入、整个任务的历史对话
  • 外部知识检索结果、工具调用返回
  • 当前任务状态、工作记忆与中间产物
  • 系统规则与安全约束、其他 Agent 传过来的结构化结果

Prompt 只是 Context 的一部分，而不是全部。

Context Engineering 的典型实践：RAG

RAG 解决了 模型参数里没有的知识，怎么在运行时补进去

RAG 工作流 | harness_04.png

但真正成熟的 Context Engineering，关心的不只是"检索一下"，而是整条链路：

  • 文档如何切块，才能既保留语义又方便召回
  • 检索结果如何排序，才能让真正关键的内容优先进入上下文
  • 长文档如何压缩，才能不把窗口挤爆
  • 历史对话什么时候保留原文，什么时候该摘要

Agent Skills：渐进式披露

最近爆火的 Agent Skills，是对 Context Engineering 的又一大典型实践。其核心机制——渐进式披露：

不要让模型从一开始就看到全部能力和全部信息，而是只在需要的时候，暴露与当前任务最相关的那一部分。

Skills 三层架构 | harness_05.png

层级 Token 消耗 内容 加载时机
元数据层 ~50 Token 技能名称、触发条件、功能概述 启动时全局加载
指令层 ~500 Token 标准作业流程（SOP）、输入输出规范 任务触发时加载
资源层 按需加载 脚本、模板、API 文档 执行具体步骤时动态调用

Context Engineering 的局限性

到这里，很多系统已经比纯 Prompt 时代强很多了。可新的问题又出现了：

即便信息是对的，模型也未必会稳定执行对。它可能：

  • 计划做得很好，但执行偏了
  • 调了工具，但误解了结果
  • 中间某一步出错后继续一路错下去
  • 表面看起来很自信，实际上任务状态早已失真
  • 在长流程里逐渐偏航，却没人发现

Prompt 和 Context 都主要作用在"输入侧"。但真实世界的复杂任务还有一个更难的问题：当模型开始连续行动时，谁来持续监督它、约束它、纠正它？

1.3 Harness Engineering

Harness 这个词，原本就有"缰绳、马具、约束装置"的意思，如何驾驭AI这匹马

Harness 词义 | harness_06.png

放在 AI 系统里，它是一个非常直白的提醒：

当模型从"回答问题"走向"执行任务"，系统不能只负责喂信息，还必须负责驾驭过程。

Harness 出发点 | harness_07.png

如果说前两代工程思路关注的是如何让模型"更会想"，那么 Harness Engineering 更关心的是：如何让模型"别跑偏、跑得稳、出了错能拉回来"。

三者的对比

我们来看一个通俗的例子：假设你要让一个新人完成一次重要客户拜访。

Prompt Engineering — 先把任务讲清楚：

"见面先寒暄，再介绍方案，再问需求，最后确认下一步。" 重点是把话说明白。

Context Engineering — 接着把资料准备齐：

客户背景、过往沟通记录、产品报价、竞品情况、这次会议目标。重点是把信息给对。

Harness Engineering — 如果会议很重要，你还会：

  • 让他带着 checklist 去
  • 要求关键节点实时回报
  • 会后核对纪要与录音
  • 出现偏差时马上纠正
  • 对最终结果按明确标准验收

重点已经不只是"说清楚"和"给资料"，而是建立一个持续观测、纠偏、验收的机制。

三者的关系

很多人看到新词出现，就容易误以为旧词过时了。恰恰相反，它们是层层递进的关系：

三者递进关系 | harness_08.png

范式 关注点 本质
Prompt Engineering "我该怎么对模型说" 对"提示词"的工程化
Context Engineering "模型能看到什么信息" 对"输入环境"的工程化
Harness Engineering "模型在真实执行中是否被持续约束" 对"整个运行控制系统"的工程化

边界一层比一层大，后者天然包含前者。

概念 核心对象 关键问题 工程重心
Prompt Engineering 指令表达 我有没有把任务讲清楚？ 如何描述任务与约束
Context Engineering 信息供给 模型有没有拿到正确材料？ 如何组织、筛选、压缩、传递上下文
Harness Engineering 运行控制 模型在执行中能否持续做对？ 如何观测、校验、纠偏、收敛
  • 当任务简单时，Prompt 就够了
  • 当任务复杂到上下文不够用时，Context 成为核心
  • 当任务变成需要持续执行、长链路、低容错时，Harness 几乎不可避免

二、Harness 的构成

2.1 Harness 到底是什么？

LangChain 工程师给 Harness 下了一个非常典型的定义：

Agent = Model + Harness
Harness = Agent - Model

简单理解：Harness 是在一个 Agent 环境中除了模型外的所有东西，它决定了模型看到什么、能做什么、按什么规则做、做错了怎么纠偏，以及最后如何把能力稳定地交付出来。

理解这一点，你对 Agent 的认识会一下子清晰很多：

  • 为什么同一个模型，在不同产品里表现差距巨大？
  • 为什么有些 Agent 看起来"像个实习生"，有些却像"成熟员工"？

模型的能力上限是由 OpenAI、Anthropic 这些公司决定，而 Harness 由我们这些工程师来决定。

一个成熟的 Harness，通常至少包含下面六个核心部分：
上下文管理、工具系统、编排能力、状态记忆、评估反馈、约束和重试
Harness 六层架构 | harness_10.png

2.2 第一层：上下文管理

在大量任务里，大模型能力的差异并不在于它本身的"智商"，而是来自模型它看到了什么信息。

一个模型再强，如果上下文是乱的、缺的、过载的，它也很难稳定发挥。所以 Harness 的第一职责，是让模型在正确的信息边界内思考。

角色与目标定义

模型需要先知道自己是谁、任务是什么、成功标准是什么。同样是"写一篇文章"，你给它的上下文不同，结果会完全不同：

  • 是技术科普，还是产品宣传？
  • 面向小白，还是面向工程师？
  • 是追求传播性，还是追求严谨性？

这些都不是"文风细节"，而是任务边界。Harness 要把这些边界明确地灌给模型。

信息选择与裁剪

上下文不是越多越好。大模型常见问题不是"知道太少"，而是"信息太杂"。一个好的 Harness 会做两件事：

  1. 把相关信息挑出来
  2. 把不相关的信息挡在外面

这其实很像一个成熟工程师接需求：不是把所有文档都丢给同事，而是先整理好关键背景，再让他进入问题。

上下文的结构化组织

同样的信息，堆成一团和按层次组织，效果天差地别。成熟 Harness 往往会把上下文分层：

上下文分层示意 | harness_11.png

我们期望的是降低模型"看漏重点"或"忘记约束"的概率。

2.3 第二层：工具系统

如果没有工具，大模型本质上只能做"文本预测"。一旦接上工具，事情就变了。模型可以：搜网页、读文档、写代码并执行、调用数据库和业务 API、操作浏览器、生成图片、编辑文件、发送消息……

这时，模型不再只是"回答问题的人"，而开始变成"做事情的人"。

工具系统架构 | harness_12.png

Harness 在这里要解决三个核心问题：

问题 说明
给模型什么工具 围绕任务场景配置，不是"越全越好"
什么时候调用工具 引导模型判断：是否需要外部信息？当前上下文是否足够？
如何把结果喂回模型 返回结果如何被理解、筛选、吸收，再进入下一步决策

2.4 第三层：执行编排

有了上下文和工具，Agent 还不够成熟。因为它还需要一个能力：知道下一步该干什么。

执行编排流程 | harness_13.png

很多失败的 Agent，不是因为不会某一步，而是因为不会"串起来"。执行编排解决的就是这个问题。一个完整任务通常会被拆成：

  1. 理解目标
  2. 判断信息是否足够
  3. 必要时获取外部信息
  4. 基于结果继续分析
  5. 生成输出
  6. 检查输出是否满足要求
  7. 不满足则修正或重试

一个成熟 Harness 往往不仅是"能调工具"，而是具有明确的：步骤划分、决策节点、中间产物、终止条件、异常处理逻辑。

2.5 第四层：状态与记忆

很多人对 Agent 的期待是"像人在持续工作"。而要做到这一点，系统必须有状态。

没有状态的系统，每一轮都像失忆。

Harness 里的状态管理至少要回答三个问题：

状态管理三问 | harness_14.png

问题 示例
当前任务进行到哪一步了？ 已完成资料收集、正在撰写提纲
哪些中间结果应该保留？ 已确认的需求约束、已筛选过的资料
哪些内容应该形成长期记忆？ 用户偏好、稳定规则、长期项目背景

记忆不是"存得越多越好"，而是要区分：临时状态、会话记忆、长期偏好。这三者混在一起，系统就会越来越乱。分得清，Agent 才会越来越像一个靠谱的协作者。

2.6 第五层：评估与观测

很多系统的问题不是"生成不出来代码"，而是"生成完了却不知道好不好"。

评估与观测体系 | harness_15.png

通常包括：

  • 输出验收：是否满足任务要求
  • 环境验证：是否真的可运行、可点击、可交互
  • 自动测试：代码、接口、页面、文档格式等
  • 过程观测：日志、指标、调用链、重试记录
  • 质量归因：问题到底出在模型、上下文、工具，还是流程设计

2.7 第六层：约束、校验与失败恢复

真正让系统从"能跑"走向"能上线"的，往往不是主流程，而是异常流程。因为真实环境里，失败才是常态。

约束与恢复机制 | harness_16.png

机制 说明
约束 限制模型哪些能做哪些不能做，比如哪些工具能用、哪些场景必须查证
校验 在输出前做检查，是否遗漏关键要求
恢复 当一步失败时：分析错误原因、重试同一步、切换备用路径、回退到上一个稳定状态

三、Harness 的实践

各大头部公司纷纷发布了 Harness 在各自产品上的工程实践：

OpenAI 实践 | harness_17.png

  • OpenAI：Harness engineering: leveraging Codex in an agent-first world — 仅有几名人类工程师的团队，利用 Codex 智能体构建了超百万行代码的生产级应用，100% 由智能体编写，耗时仅为人工的 1/10。

  • Anthropic：Harness design for long-running application development — 仅凭一句自然语言需求，Claude 就能连续运行数小时，端到端地交付 2D 游戏制作工具、数字音频工作站。

Anthropic 实践 | harness_18.png

  • LangChain：Improving Deep Agents with harness engineering — 仅通过改造 Harness，就把代码智能体得分从 52.8 拔高到 66.5，从 Top 30 开外杀入 Top 5。

LangChain| harness_19.png

3.1 Anthropic 的实践

两个典型问题

Anthropic 在大量实践中总结了两个典型的失败模式：

Compaction vs Reset | harness_20.png

  1. 上下文焦虑：任务一长，上下文窗口越来越满，模型开始丢细节、丢重点。当模型接近窗口极限时，它会"焦虑"地想赶紧收尾，这也是为什么我会在提示词第一句就让他"喵"一下（兴许有用）。

  2. 自评失真：模型自己做完之后再让它自己评判，它往往会偏乐观，尤其在设计、体验、产品完整度这类没有绝对二元答案的问题上。

实践一：上下文重置

很多系统在上下文长了之后会做 Context Compaction（压缩历史继续跑）。而 Anthropic 的思路是做 Context Reset：

Planner-Generator-Evaluator 架构 | harness_21.png

模式 做法 效果
Compaction 同一个 Agent，历史变短了，但知道自己要干啥 "心理状态"延续着
Reset 直接换一个干净上下文的新 Agent 两个模型交班时要把工作交接清楚

Anthropic 发现，对于某些模型（如 Claude Sonnet 4.5），仅靠压缩并不能解决"上下文焦虑"；而真正的 Reset 才能给模型"清空包袱、重新出发"的效果。

这很像工程里的进程重启与状态恢复：不是所有内存泄漏都能靠"清理缓存"解决，有时候就得重启进程。

实践二：引入评估者

Anthropic 说得很直白：让模型评估自己产出的质量时，它往往会"自信地夸自己"，即便结果在真人看来很一般。

所以他们采用了一个很典型的 Harness 手法：把"干活的人"和"打分的人"拆开。

核心思路：generator + evaluator，后来扩展成 planner + generator + evaluator。

角色 职责
Planner 把一句很短的需求，扩展成完整产品规格
Generator 逐步实现
Evaluator 像 QA 一样，用浏览器和工具真实操作应用，检查功能、设计、代码质量等

这个设计背后是一个朴素但非常硬核的工程原则：生产与验收必须分离。

Evaluator 不是"读代码打分"，而是会实际操作页面、跑交互、看结果——这是"带环境的验证"。一旦 Evaluator 能独立测试、独立质检，系统就能实现"生成 — 检查 — 修复"的工程循环。

工程师新角色 | harness_22.png

3.2 OpenAI 的实践

重新定义"工程师"

OpenAI 的 Codex 团队从第一天就定了一条铁律：人类不写代码，只设计环境。

实践对应关系 | harness_23.png

工程师的核心工作变成了三件事：

  1. 拆解意图：把产品目标拆成 Agent 能理解的小块任务
  2. 补全能力：Agent 失败时，不是"再试一次"，而是问"环境里缺了什么让它失败了"，然后补上
  3. 建立反馈回路：让 Agent 能看到自己工作的结果，而不是盲人摸象

当出了问题，修复方案几乎从来不是"更努力"，而是"缺了什么结构性的能力"。

渐进式披露

早期他们犯了一个经典错误：写了一个巨大的 AGENTS.md 文件，把所有规范、架构、约定一股脑塞进去。结果 Agent 反而更迷糊了——因为上下文窗口是稀缺资源，塞太满等于什么都没说。

他们最终的方案：

AGENTS.md          ← 入口，只有指针（~100 行）
ARCHITECTURE.md    ← 架构总览
docs/
├── design-docs/   ← 设计文档（带验证状态）
├── exec-plans/    ← 执行计划（活跃/已完成/技术债务）
├── product-specs/ ← 产品规格
├── references/    ← 第三方参考
├── QUALITY_SCORE.md ← 各模块质量评分
└── SECURITY.md

这就是 Skill 的核心机制：渐进式披露。Agent 先看到目录，需要深入时再去查对应文档。更关键的是，他们用 CI 自动校验文档的新鲜度，还有一个专门的"文档园丁" Agent 定期扫描过时文档并提 PR 修复。

让 Agent "看见"整个应用

产代码的速度上去之后，瓶颈从"写"变成了"验"——人类根本验不过来。OpenAI 的解法是：让 Agent 自己验。

能力 具体做法 解决什么问题
UI 验证 接入 Chrome DevTools Protocol，Agent 能截图作 DOM、模拟用户行为 不再"写完代码就声称做完了"
可观测性 每个 worktree 配独立的 Loki + Prometheus + Tempo 栈，Agent 用 LogQL/PromQL 查日志和指标 "确保启动时间 <800ms" 这种需求可直接验证
隔离环境 每个 git worktree 是独立的应用实例，任务结束后销毁 多个 Agent 并行工作互不干扰

结果是什么？单次 Codex 运行经常连续工作 6 小时以上，通常是在人类睡觉的时候。Agent 自己跑应用、发现 bug、修复、验证、提 PR，一条龙。

把架构约束写进系统里

人类 Code Review 的带宽跟不上 Agent 的产出速度（每人每天 3.5 个 PR），怎么保证代码质量？

答案是：把资深程序员的经验判断，写成机器可以自动执行的检查规则。

例如，他们把业务代码按固定分层组织：Types → Config → Repo → Service → Runtime → UI。更重要的是，这些规则不只是负责报错，还会告诉 Agent 该怎么改——检查结果本身就带着修复提示，可以直接回到上下文里，推动下一轮修改。

除了拦截提交时的问题，他们还会定期运行后台 Agent，持续扫描代码库，找出变乱的模块、打质量分、找出值得重构的部分、直接提交修复 PR。

它的价值不只是发现问题，更是趁问题还小的时候就把它修掉。

3.3 回过头看，大家做的其实是同一件事

如果把前面的案例重新放回 Harness 的框架里，你会发现：

OpenAI、Anthropic 看起来路径不同，做法也不一样，但它们本质上都在补同一套东西：

核心问题 Anthropic 的解法 OpenAI 的解法
模型应该看到什么 Context Reset 渐进式披露
模型能做什么 — 工具 + 浏览器 + 隔离环境
模型下一步该做什么 Planner 编排 步骤化约束
如何保持连续工作 Context Reset 后台 Agent 持续扫描
怎么知道自己做得对不对 独立 Evaluator Agent 自验证 + CI 校验
出错后怎么拉回来 生成—检查—修复循环 架构约束 + 修复提示

看到这里，Harness 的意义其实就很清楚了：

把模型从一个会回答问题的概率机器，变成一个能稳定完成任务的工程系统。

结语

回头看这三次演进，会发现它们并不是谁取代了谁，而是 AI 工程在不断面对更复杂任务时，重心一层层向外扩展。

  • 当任务还停留在单轮生成时，Prompt Engineering 很重要
  • 当任务开始依赖外部知识和运行时信息时，Context Engineering 成为关键
  • 当模型真正进入长链路、可执行、低容错的真实环境后，Harness Engineering 几乎不可避免

Prompt 没有过时，Context 也不是终点。它们都还在，而且都很重要。

只是越往后，我们越会意识到：

真正决定 AI 产品上限的，也许是模型；但真正决定 AI 产品能否落地、能否稳定交付的，往往是 Harness。

未来 AI 工程的竞争，未必只是"谁接入了更强的模型"，而更可能是谁更早建立起一套成熟的运行系统：它知道该给模型看什么，允许模型做什么，要求模型如何验收结果，又在失败时如何把它拉回正轨。

Harness Engineering 不是一个新瓶装旧酒的概念，它更像是一个信号：

AI 落地的核心挑战，正在从"让模型显得聪明"，转向"让模型在真实世界里稳定工作"。

参考资料：

  • OpenAI: Harness engineering: leveraging Codex in an agent-first world
  • Anthropic: Harness design for long-running application development
  • LangChain: Improving Deep Agents with harness engineering
posted @ 2026-07-18 14:34  陈大欠  阅读(2)  评论(0)    收藏  举报