Harness Engineering学习

• 引言
• 正文
• 参考资料

引言

Harness Engineering 是什么和提示词工程和上下文工程有什么关系？

正文

2026年OpenAI在一篇博客文章提到了 AI engineering（驾驭工程） 之后，它就快速在AI圈里火了起来。很多人根本不知道它到底是什么，就开始各种跟风吹爆。

在三天一重磅、五天一炸裂的AI圈里，虽然离谱，但也合理。那它到底是什么？和这两年很火的 提示词工程（Prompt Engineering）、上下文工程（Context Engineering） 又是什么关系？

全网资料参差不齐，如有差异以我为准。今天就把这些概念串起来讲透，看完你就会知道 AI Agent 的开发本质上是在做什么。

• 为什么同样的模型换个 AI Agent 效果会差这么多？
• 有了AI，程序员就不写代码是真的吗？
• 怎么做到的？

Prompt Engineering（提示词工程）

把 ChatGPT 的外壳剥开，里面的大模型也就是 LLM，本质就是一个磁盘上的超大参数文件。将它加载到显卡内存里，配上 HTTP 接口，就成了大模型 API 服务。给它加个聊天界面，就变成了聊天AI；加个代码编辑器，就成了 AI IDE。

AI大模型做的事情很简单，就是基于当前输入的内容，预测下一个字词大概率会是什么。它本质上只是在猜你想要什么，所以如果你给它输入的指令太宽泛，那它预测的答案就会非常发散。

比如你丢给它一段代码说”加个排序”，它可能只回你排序的那部分怎么写。你得补一句”给我完整函数代码，不要乱改我的代码”，它给的结果才会更符合要求。

能加的内容有很多，比如角色设定、背景、历史对话、参考文档、限制、输出格式，这些约束构成了所谓的 提示词（Prompt）。而这种有意识的调整和设计提示词，让模型稳定地朝着你预期的内容和格式输出的技术手段，就是所谓的 提示词工程。它解决的是大模型无引导乱说话的问题。

Context Engineering（上下文工程）

提示词写得越长越仔细，模型知道的就越多，回答就越准。反过来同理，大模型回答不准，那大概率是因为知道的不够。于是大家很自然会不断往大模型里塞各种资料。

这些打包到一起发给大模型的所有信息就叫 上下文（Context）。提示词只是上下文的一部分。但大模型再强，一次性能处理的上下文也有最大限制，这个限制叫 上下文窗口（Context Window）。

在AI大模型应用里多对话几轮，就很容易将上下文窗口打满，于是就需要通过一些策略去压缩或丢弃部分信息。在这个过程中不可避免会丢失关键信息，从而破坏上下文的完整性和准确性，这类问题被统称为 上下文腐化（Context Corruption）。效果上就是模型开始记不住，回答前后不一致。

上下文窗口就这么大，于是问题就变成了：怎么才能在合适的时候将合适的内容塞入到有限的上下文中？于是衍生了一套负责动态管理大模型上下文的技术，也就是所谓的 上下文工程。

提示词是上下文的一部分，那自然提示词工程其实也是上下文工程的一部分。它一般通过外部程序来实现，比如 Cursor、Claude Code、Cline 这类 Coding Agent。

每一家的技术实现都有差异，但总的来说可以总结为三个步骤：召回、压缩、组装。

第1步 召回：说白了就是找什么信息。这些信息可以来自外部新闻，也可以来自过去聊天记录、当前代码环境以及程序运行报错等。总之就是从里面找出最相关的内容。这里面涉及到一些 RAG、Memory 等技术。

第2步 压缩：很多上下文窗口有限，所以需要将信息变小。比如将信息分开发给大模型做总结。

第3步 组装：因为信息放置的位置和顺序会直接影响模型的理解和输出，比如越靠后越容易被模型关注。所以我们需要通过一定的结构重新组装内容，这样进入模型的上下文更精简更相关，输出也会更稳定更准。

不同 AI 工具的上下文工程策略不同，所以你会发现就算用的是同一个模型，不同 AI 工具的执行效果也会有差异。

AI Engineering（驾驭工程）

提示词工程解决了大模型无引导乱说话的问题，上下文工程解决的是上下文的组织问题。模型是更聪明了，但它只能聊天，没法帮我们干活。

于是我们可以给大模型加入 Bash 沙箱、文件系统、MCP 这些能力，让它能像人一样操作外部工具：读写代码文件、执行命令、做测试。它们共同构成了 执行层（Execution Layer）。

将它们串成一个流程，在外部套一层循环。于是我们就可以通过提示词工程和上下文工程组装上下文发给大模型，大模型负责思考，外部程序负责执行。过程中得到的报错等信息，再加到上下文里继续推理和执行。

这套一边思考一边行动的循环，就是所谓的 ReAct。而这个能通过聊天帮你执行任务的程序，就是所谓的 AI Agent。

Agent 的本质就是一个 for 循环。只要这个循环一长，上下文就一定会膨胀，上下文工程做再好也可能会 腐化。随着它看过的文件越来越多，拿到的信息越来越杂，前面定好的目标和约束，后面可能慢慢就被冲淡了，理解也会越来越偏。

怎么办呢？很简单。只要我们可以保证每次给大模型的上下文中都包含一些可复用的核心信息，比如项目目标、技术栈、需求背景、代码风格、禁止事项等。只要保证这部分一直在那，大模型就能在大框架约束下减少理解偏移。

这些核心信息可以单独写成文件，固定在代码仓库里。比如 Claude Code 用 CLAUDE.md，Cursor 或 Cline 也会有各自的 rules 文件。它们暂时没有统一的名字，我暂且称为 规则文件。规则文件会在调用大模型的时候，作为系统提示词自动注入上下文。

但规则文件写多了也会变长，所以上下文也会很长。那就拆——把它拆成几份更短的文件，再加一个简单的路由。比如背景就读 BG.md，技术栈就看 STACK.md。一般情况下只需要加载文件地址路径，真正需要的时候再加载文件的全部内容。

将它们跟提示词工程和上下文工程配合在一起，形成 记忆层（Memory Layer）。

有了记忆层和执行层的配合，Agent 就能不停写代码、跑 Lint 和单元测试。过程中发现执行有问题，还可以将测试输出和报错加入到 上下文里，这样就可以驱动 Agent 在下一轮循环中自动做修复。这套通过校验结果回传错误来实现自动修复问题的能力，形成了 反馈层（Feedback Layer）。

但 Agent 的循环如果缺乏全局规划和清晰的结束目标，依然很容易跑偏，甚至陷入无效死循环。所以我们还可以将大任务拆解为有明确执行标准的多个子任务，按规划驱动 Agent 分步执行。这种以全局规划为核心，对任务做拆解与全流程管控的能力，形成了 编排层（Orchestration Layer）。

总结

编排层 + 执行层 + 反馈层 + 记忆层，这些能力共同组成了一套包裹着大模型的工程外壳，它就是 AI Engineering（驾驭工程）。

大模型越强，外壳就可以做得越薄。但无论怎么样，这层外壳都得有。

公式：Agent = 大模型 + AI Engineering 只要不是大模型的那部分，都属于 AI Engineering 的范畴。

AI Engineering 怎么落地？

概念理解了，那最重要的问题来了：怎么落地？以 Claude Code 为例。

Claude Code 软件本身已经原生支持 Agent 的4层能力，所以最轻量的做法就是在 CLAUDE.md 文件里写清楚：项目背景是什么，你希望大模型做什么别做什么，做完之后要跑哪些 Lint、单元测试、执行哪些 Skill 就行。

如果不想自己写这么累，那就引入一些插件，比如 Spec Kit 这类扩展。它会根据项目将需求拆成多个阶段。做的事情也很简单：先生成对应的规则文件，明确需求；再制定具体开发计划，拆解任务；最后才是实际修改加测试。每个阶段都可能会更新一次 CLAUDE.md，这样每一阶段注入上下文的尽可能都是核心信息。

这套开发方式也叫 Spec-Driven Development，简称 SDD。本质上做的事情就是 AI Engineering 的落地。但 Spec Kit 整体还是不够强，我相信很快会有更加全面的替代方案出现。

有了 AI Engineering 之后，程序员的工作内容就从写代码慢慢改为写规则和 Skill。

一句话总结：

参考资料