ChenDaqian

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

一、Harness 的演进

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

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

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

1.1 Prompt Engineering

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

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

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

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

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

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

Prompt Engineering 为什么会有效

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

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

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

Prompt Engineering 的天花板

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

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

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

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

1.2 Context Engineering

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

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

为什么 Context Engineering 会兴起

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

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

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

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

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

Context 到底是什么

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

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

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

Context Engineering 的典型实践：RAG

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

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

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

Agent Skills：渐进式披露

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

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

Context Engineering 的局限性

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

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

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

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

1.3 Harness Engineering

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

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

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

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

三者的对比

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

Prompt Engineering — 先把任务讲清楚：

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

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

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

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

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

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

三者的关系

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

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

• 当任务简单时，Prompt 就够了
• 当任务复杂到上下文不够用时，Context 成为核心
• 当任务变成需要持续执行、长链路、低容错时，Harness 几乎不可避免

二、Harness 的构成

2.1 Harness 到底是什么？

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

Agent = Model + Harness
Harness = Agent - Model

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

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

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

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

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

2.2 第一层：上下文管理

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

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

角色与目标定义

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

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

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

信息选择与裁剪

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

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

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

上下文的结构化组织

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

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

2.3 第二层：工具系统

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

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

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

2.4 第三层：执行编排

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

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

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

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

2.5 第四层：状态与记忆

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

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

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

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

2.6 第五层：评估与观测

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

通常包括：

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

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

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

三、Harness 的实践

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

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

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

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

3.1 Anthropic 的实践

两个典型问题

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

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

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

实践一：上下文重置

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

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

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

实践二：引入评估者

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

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

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

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

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

3.2 OpenAI 的实践

重新定义”工程师”

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

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

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 自己验。

结果是什么？单次 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 看起来路径不同，做法也不一样，但它们本质上都在补同一套东西：

看到这里，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