AI工程范式的三次演化:PromptEngineering→ContextEngineering→HarnessEngineering

最近有一个概念”Harness Engineering” 开始兴起，看到很多堆砌概念的文章，读了没什么用。

我结合自己的经历来理解了下。总的来说，我的结论是：如果目标只是让模型在一轮对话里回答得更像样，Prompt Engineering依然重要；但如果目标变成“让Agent连续几十分钟完成一个真实任务”，只优化提示词通常是不够的。很多失败并不是模型不会写，而是它不知道该看什么、能用什么、错了以后怎样自我校正。它缺少了一些运行的环境和良好的规范。

这篇文章想回答三个更具体的问题：

1.Prompt Engineering、Context Engineering、Harness Engineering 分别在解决什么问题？2.为什么在 coding agent 场景里，后者会越来越重要？3.当 Agent 表现不好时，我应该怎么做？

首先，我的结论是：这三者不是替代关系，而是同一套AI工程系统的三个层次。

• • Prompt 决定你如何发出任务
• • Context 决定模型在关键时刻能看到什么
• • Harness 决定模型在什么运行机制里完成任务

它们的外延其实是越来越大的。

当我们的目标从“答对一道题”变成“稳定完成一段工作流”，系统重心就会自然外移。我们会先发现优化prompt不够，再发现只补上下文也不够，最后不得不处理运行环境、反馈回路、权限边界和记录系统这些更工程化的问题。

所以，这篇文章表面上是在讲三次演化，真正落点其实是一个更实用的启示：在coding agent场景里，很多问题并不是“prompt还不够好”，而是我们没有把系统搭好。（我理解的harness工程的核心思想）

大多数人第一次接触LLM，都是从prompt开始的。打开ChatGPT、DeepSeek或豆包，在输入框里写一句话，模型给你一段回答。比如，在输入框输入文字：“中国的首都是哪里” 答：”北京“。这种交互方式诞生了大量的ChatBot。它将模型的能力封装成了一个更高效的知识库、数据库、搜索引擎产品。这个阶段，AI的核心是问答任务，即如何更好的输出用户想要的答案。

这一阶段最常见的方法，基本都在解决同一件事：如何让模型更准确地理解我们的意图。所以大家都是在研究提示词技巧：

1.设定身份、背景、行为的格式化方法2.举例子给模型，所谓one shot/few shot3.让模型一步步思考的思维链方法4.让模型推理行动观测的ReAct方法（这里已经初步演进到agent的概念了）

严格一点说，Prompt Engineering不只是“写一句更有效的话”，还包括测试、评估和迭代。它解决的是输入表达问题。

但它的边界也很明确。

• • 它不能凭空给模型补进我们的私域知识
• • 它不能让模型知道今天的外部世界发生了什么
• • 它不能天然解决跨轮对话的持续记忆
• • 它也不能代替权限控制、执行环境和错误恢复机制

我们对LLM的期待不是一个高级的数据库查询式的问答，我们希望它能处理上述事情。实际上，我们是在期待一个Agent，而Agent的任务是多步执行。

模型是通过上下文窗口来工作的，prompt是其中的一部分。当任务从问答变成执行，问题的重心就从“如何提问”迁移成“如何组织上下文”。

这里的上下文，不只是system prompt。凡是会进入模型视野、影响其下一步决策的信息，都可以算上下文，例如：

• • 提示词
• • 用户输入
• • 工具定义
• • 工具返回结果
• • 历史对话
• • 检索出的知识片段
• • 长短期记忆
• • 当前任务状态

那么如何才能有效的组织这些信息呢？还是机械的将它们填充进来吗？肯定不是。

2.1 RAG：解决“模型不知道的私有知识库”

私域知识、产品文档、内部规范、历史记录，往往比上下文窗口大得多，不能整包塞给模型。这时候就需要先查，再把最相关的片段喂进去。

RAG的价值在于：它尽量让检索结果和任务语义相关，而不是只做字面匹配。比如同样搜索“苹果”，一斤苹果5块钱和一部苹果手机8000块都可能命中，但对当前任务有帮助的内容其实完全不同。经典的笑话就是，女朋友说“我要买苹果，给我转点钱”，你转了100块，想来买20斤总是够吃了吧。

不过，RAG的发生也是波折的，中间火热的时候，说”RAG for everything”，模型上下文窗口一长，微调技术成熟的时候，又说”RAG is dead“。在实际的企业知识问答实践中，RAG也总会遇到各种问题被抱怨。

但从我的观察来看：

• • 在企业知识问答、流程文档检索、内部规范辅助这类场景里，RAG 仍然很重要
• • 在代码仓库导航、局部文件定位这类强结构化场景里，Grep、Glob、Read 这类直接操作文件系统的方式，往往比向量检索更直接

不是RAG消失了，而是不同任务需要不同的增强方式。

我自己做debug agent时就踩过这个坑。我最初尝试过把代码仓库做索引，再让Agent通过语义检索去找崩溃相关代码，结果召回率很低。原因是很多调试任务依赖的不是“语义相似”，而是术语、符号名、文件路径、调用链和历史改动，这些信息更适合用grep、日志关键字和 git记录去逼近。后来直接调用claude code sdk，准确率一下就上去了。

2.2 Tools：解决“模型不知道外部世界，也不能直接行动”

如果没有工具，LLM很像一个”缸中之脑”。它能推理，但不知道现在几点，不知道今天发生了什么，也不能亲手执行动作。依然会给人“很蠢”的感觉。

所以我们给模型接工具：

• • 要知道时间，就接时间工具
• • 要知道现实世界信息，就接搜索或接口
• • 要改文件、跑命令、查日志，就接代码与系统工具

这条路线持续在进化。早期很多系统靠正则匹配模型输出，再映射到某个函数；后来发展到更稳定的function calling；再往后，为了把工具能力从某个模型服务或某个聊天客户端里解耦出来，又出现了像MCP这类协议层抽象。

工具一多，新的问题又来了：工具描述本身会占上下文，选择错误的工具也会带来执行成本。所以现在不少系统开始做按需加载，把工具和经验封装成skills，避免一上来把所有能力都塞给模型。

2.3 Memory：解决“模型每次都像第一次见你”

LLM天生不是持续有状态的。当前轮次的推理，不会自动继承上一次对话的内部状态。现实交互却不是这样，人类天然假设“前文还在”。

最简单的做法，就是把之前的对话一起放回上下文。这确实有效，而且现在依然是最常见的办法。但对话一长，窗口就会被迅速吃满，于是我们又不得不面对两个更细的问题：

• • 哪些历史信息应该保留
• • 哪些信息应该压缩、摘要或者外置存储

短期记忆解决连续对话，长期记忆解决跨任务偏好、固定约束和历史决策。到这里，会发现Context Engineering已经不是“多加几个字段”，而是在做信息编排。

2.4 为什么只补上下文，很多 Agent 还是做不稳

上下文问题解决的是“模型看到什么”，但它不直接解决下面这些问题：

• • 它会不会误用高风险工具。典型的，我遇到openclaw把自己断网了，然后就再也联系不上了。
• • 它改完代码以后如何验证
• • 它失败了以后如何重试或回滚
• • 它什么时候应该停下来汇报，而不是继续乱做，过早或者过晚都是不合适的
• • 它怎样在长任务里留下可以追溯的过程记录

这些问题一出来，视角就必须继续外扩。我们研究的不再只是上下文，而是整个运行系统。这就是我理解的Harness Engineering。

如何理解harness，我想到一个合适的例子。一个新入职的经验丰富的工程师，我们需要怎样才能保证它的产出呢？

• • 给他配好的电脑
• • 告诉他规则和权利
• • 给它工作用的软件和运行环境
• • 告诉它本领域的知识 同理，如果把一个能力不错的Agent看作新入职的工程师，那么prompt只是任务说明，context只是你递给他的材料，而harness更像他所处的工作环境。

真正决定他能不能稳定交付的，通常不是“会不会写代码”这一件事（也就是我们默认模型的能力足够强了），而是下面这些工程条件是否存在：

• • 有没有明确的目标、边界和停止条件
• • 有没有合适的权限和运行环境
• • 有没有足够的领域知识和工具入口
• • 有没有日志、测试、页面反馈这类可观测信号
• • 有没有文档、记录和版本系统让它在长任务里不至于失忆

所以Harness Engineering是在回答一个问题：如何把模型放进一个能持续做事的工程闭环环境里。

3.1 确定任务目标

很多Agent失控，不是因为它听不懂，而是因为系统没有给它清晰的“完成条件”和“禁止动作”。

比如在代码任务里，至少要让它知道：

• • 什么叫完成
• • 哪些目录、分支、环境不能碰
• • 失败后是继续尝试、回退，还是停下来请求确认
• • 什么时候必须先汇报，再进入下一步

这类约束看起来不像AI技术，实际上却直接决定产出质量。因为Agent一旦进入多步执行，没有约束的系统，天然更容易出现过度行动。这和对待人类程序原是一样的。

3.2 暴露隐性知识，而不是默认模型自己会懂

实践里,coding agent最常见的跑偏原因，是它不知道团队那些“默认不言自明”的规则导致的。

比如“做一个上新的功能”，在人类团队里可能隐含了很多前置约束：

• • 哪些指标必须埋点
• • 哪些埋点字段有历史兼容要求
• • 哪些 UI 改动要同步改文案和活动配置
• • 哪个目录下的脚本才是正式发布链路

在需求层面，我们人类程序员已经和前端营销、产品讨论过很多轮，我们听起来是非常的自然，但模型并不理解它的细节。我们可能提供了只言片语，但完全不充分。我们人类的沟通中，大量使用了语音、视觉等多模态的信息。这些信息的密度非常的高，如果没有清晰的呈现出来，agent的幻觉就会将其放大。

所以我更愿意把这件事理解成：不要只给Agent一个需求，而要补给它“一个新人第一周会被老员工口头交代的那些东西”。

3.3 给足够但不过载的工具

这不是说，工具越多越好，太多工具会带来两个副作用：

• • 模型选择成本变高
• • 工具说明本身开始挤占上下文

所以更合理的做法，往往不是“无限加工具”，而是让工具可发现、可按需加载。很多优秀的coding agent其实都不追求“为每个动作发明一个专用工具”，而是优先提供一小组通用能力，例如：

• • Read
• • Write
• • Grep
• • Glob
• • Bash

典型的如claude code , pi-mono。这套设计的好处，是看似给了很少的工具，但实际覆盖面很大。前四个让它高效操作代码和文件，Bash则提供兜底能力。剩下的空间，交给具体项目里的CLI、脚本和工作流。

隐含的逻辑是“我相信Agent足够的智能，可以找到自己合适的工具”。

3.4 提供可观测的反馈回路

没有反馈，Agent就很难自我纠错。它做了一步动作，却不知道结果好坏，下一步只能继续猜。

在软件开发里，最典型的反馈源包括：

• • 测试结果
• • lint和类型检查（很多coding agent工具会搭LSP）
• • 结构化日志
• • 页面或接口的真实运行输出
• • 调试信息、浏览器行为、硬件或串口回传

很多人觉得Agent输出质量差，第一反应是继续改prompt尝试。可如果系统根本没有把这些反馈暴露出来，再好的prompt也无法替代观测能力。一个不会看结果的Agent，很难进入稳定迭代。

从另一个层面说，这也是某些岗位的壁垒所在。越是依赖真实世界给予反馈的，越晚被替代。比如嵌入式开发，需要通过调试器等将信号接回到agent系统。反之则越快被替代，今年已经开始出现前端部门被整锅端掉了。

3.5 提供渐进式披露的记录系统

上下文窗口很宝贵，但长程任务天然需要大量记录。人类做项目时也不是把全部细节背在脑子里，而是把信息外化到文档、代码、日志和版本历史里，需要时再检索回来。没见过做项目要先背下整个需求的吧。

Agent也一样。好的记录系统，不是把百科全书塞进AGENTS.md，而是给它一张地图，再把细节拆到真正可维护的位置：

• • AGENTS.md负责告诉它规则、入口和知识分布
• • docs/负责沉淀领域文档、流程说明、排障记录
• • git负责保存每一步代码变化和提交语义

这样做有两个直接好处：

• • 上下文不需要永久背着所有细节
• • 需要追溯时，可以沿着文档和版本历史反查

从这个角度看git本身就是很适合Agent的外部记忆。它天然和代码关联，又鼓励小步迭代，检索成本也低。

这块经验来自OpenAI在2026年2月11日发布的文章《工程技术：在智能体优先的世界中利用Codex^[1]》，他们后来不再把 AGENTS.md当百科全书，而是把它当作内容目录，真正的知识沉淀在结构化的docs/里。这个判断和我自己的实践是一致的：长任务需要的是可检索的记录系统，而不是一段越来越长的总提示词。

我在做一个语音agent vixio工程时，对“记录系统”还有一个更强的感受：如果不强制Agent把关键决策写下来，长任务一定会越来越漂。

我的做法是：

• • 每次开始实现前，先要求Agent完成设计并存到文档里
• • 后续实现一旦有更新，必须同步更新这份设计文档
• • 后面遇到关联任务时，要求Agent先回看并引用这份文档，再继续实现

回想起来，这件事看起来像文档习惯，实际上是harness的一部分。因为它解决的不是“当前回答得好不好”，而是“多轮、多阶段任务里，Agent 能不能保留稳定的项目记忆”。

这里我越来越认同一个判断：长期任务里的记忆，不能只寄希望于上下文窗口自动维持，而要外置到文档、git、任务记录这些系统里。窗口里放的是当前阶段最相关的片段，真正的长期记忆应该在窗口外有可检索的落点。

4.1 第一版：只有prompt、问题描述、日志和仓库

一般解决一个BUG，都是如下的步骤，给出任务要求：

解决这个崩溃问题。

然后补上三类材料：

• • 问题描述
• • 崩溃日志
• • 代码仓库

从“信息已经不少”的角度看，这似乎已经够了。但实际效果很差。Agent会执行很久，读很多文件，尝试很多方向，却很难稳定定位到真正相关的代码段。它不是完全不能做事，而是一直在低效搜索。

最主要的问题在于：不稳定。能不能找到问题点所在，完全看运气。最典型的就是，找崩溃问题，找到memory空指针，然后就围绕着这个空指针一直去自我证明。实际上，这里不会空指针，只是写法没有那么规范，导致它容易误判。

这时候如果只从Prompt Engineering的角度思考，很容易得出一个错误结论：是不是prompt还不够细？

4.2 我当时的误判：先去做代码RAG

我第一反应其实不是做harness，而是继续补context。我试过把代码做索引，让Agent通过语义检索找与崩溃相关的代码。

这一步没有带来预期收益，核心问题是召回率很低。

调试类任务和知识问答不太一样。很多关键线索并不体现为自然语言语义相近，而体现为：

• • 崩溃堆栈里的特定符号
• • 日志中的关键字
• • 仓库里的历史术语
• • 某次改动引入的调用链变化

也就是说，这个问题表面上像“信息不够”，本质上却是“信息组织方式不对”。代码语义检索在这里不是完全没用，但不是最有效的入口。

4.3 真正起作用的改动：给它一个崩溃分析技能

后面效果明显改善，是因为我不再继续堆prompt，而是补了一套更接近工程经验的运行支架。

我给Agent增加了一个“崩溃分析技能”，里面不是抽象原则，而是非常具体的工作方法：

• • 遇到这类崩溃，先搜哪些关键字
• • 应该优先调用电脑上的哪个分析工具
• • 可以参考一份过去解决过的类似问题分析
• • 遇到术语不理解时，要通过git记录理解术语含义，并反查对应代码段

这次改动以后，执行效果就明显好了很多。因为Agent不再是在整个仓库里盲目游走，而是开始沿着一条更像资深工程师排障的路径推进。

这件事对我最大的提醒是：很多时候，Agent缺的不是“再解释一遍任务”，而是“给它一条可执行的调查路径”。

4.4 这个案例里，三层分别发挥了什么作用

如果用本文的三层框架回看这次调试过程，大概可以这样归因：

• • Prompt负责定义目标，比如“解决这个崩溃问题”
• • Context负责提供材料，比如日志、代码仓库、过去案例和关键字
• • Harness负责把排查流程固定下来，让它知道先做什么、用什么工具、如何通过git和记忆系统持续逼近答案

实际上，它能成功运行分析工具，也是我实现准备好了运行环境。 也正因为这样，我现在对很多Agent失败场景的第一反应，已经不是“把 prompt再写长一点”，而是先问一句：它到底缺的是目标表达、任务材料，还是工程支架？

Prompt Engineering解决的是如何把任务说明白，Context Engineering解决的是如何把关键信息摆到模型眼前，Harness Engineering解决的是如何让模型在真实环境里稳定做事。

三者并不是谁取代谁，而是抽象层次一层层向外扩展。任务越接近真实生产，后两者的重要性就越高。

模型能力越来越强，它所需要更多可能是“给他一个自由发挥的舞台”，人类需要来协助它搭建舞台。而不是反过来，人类强烈的干预它的行为，却不给予它帮助。

如果你用了顶级模型，但vibe coding效果不好，大概率不是模型不够聪明，而是还没有给模型提供足够好的运行环境，从而充分发挥它的能力。

参考：

1.https://openai.com/zh-Hans-CN/index/harness-engineering/2.https://x.com/Vtrivedy10/article/2031408954517971368

技术交流群邀请函

扫描二维码添加小助手微信

—完—
为您推荐
《跨语言大模型》最新综述
深度学习领域，你心目中 idea 最惊艳的论文是哪篇？
思考丨到底什么叫算法工程师的落地能力？
Transformer模型有多少种变体？看看这篇全面综述
从SGD到NadaMax，十种优化算法原理及实现
各种注意力机制的PyTorch实现