AI Engineering 领域每隔几个月就冒出一个新概念，Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering……名字越起越大，好像你没跟上就落后了。
但如果从第一性原理出发去看 AI 应用的发展，模型能做什么，决定了人需要给什么，这些概念诞生背后的逻辑其实没什么区别。
同一个问题，不同的答案
我们一直在回答同一个问题：想让 AI 交付一个好结果，需要给它提供什么？
模型能力每进一步，同一个问题的答案就变一次。
早期模型推理弱，你得把问题描述得足够清楚，甚至需要辅以角色扮演之类的小技巧来优化产出结果。
后来模型能理解你了，但完成任务需要的信息大多在训练数据之外，上下文窗口又有限，你得替它筛选和注入关键信息。
再到后来，模型有了更大的上下文窗口、能稳定调用工具了、长上下文注意力变强了，Agent 能完成任务了，但过程中还需要人频繁介入来补充信息、纠正方向。你想要的是它能被约束住、能稳定产出高质量的结果，减少人的参与。
当我们发现 Agent 能较为稳定地产出高质量结果了，我们开始思考如何进一步偷懒，减少人的介入，让 Agent 自己跑长任务。于是我们开始往更外层套上循环，你只需要给定一个明确、可验证的目标，让它自己朝目标逼近。
人们给这样的四个阶段各自取了个名字：Prompt Engineering, Context Engineering, Harness Engineering, Loop Engineering。所谓「范式转移」，不是什么天才拍脑袋想出来的。是模型能做的事变了，你给的东西自然也要变。
Prompt Engineering：打磨提示词，用技巧弥补推理不足
2022 年底，ChatGPT 刚出来。模型能对话了，但推理能力很弱，经常不遵循指令。想让 AI 交付好结果，你能做的就是在 prompt 里倾注大量精力：把问题描述清楚，说细致，说明白，附上期望、约束、输出格式、正面示例、反面示例。角色扮演（「你是一个专业的 xxx」）、Chain of Thought、few-shot 等各种技巧，后来被总结成各种方法论，本质上都是在做同一件事：用人类语言的技巧去弥补模型推理能力的不足。
Prompt Engineering 没被谁发明。当模型需要你把话说得很细才能产出符合预期的结果，你自然会去琢磨怎么把它说细、说明白。但随着模型理解和推理的能力不断提升，今天的我们几乎不再需要刻意地去做这样的工作了，Prompt Engineering 这个词也逐渐淡出了大众的视野。
Context Engineering：精选上下文，提升信噪比
2024 年中，Claude 3.5 Sonnet 发布，Agentic 能力（工具调用、自主规划）有了质的突破。也是在这个时期，Cursor 作为 AI IDE 崛起，中间编辑区，右侧 AI 对话面板的模式成为了主流，Vibe Coding 成为了可能，我们只需要在对话框内提我们的诉求，剩下的全都交给 AI 来完成即可。
AI 应用开始从 Chat 向 Agent 转移，我们不再需要人工手动复制粘贴来为 AI 补充训练数据之外的上下文，而是由 AI 应用根据当前任务自动注入上下文，以及提供工具给 AI，让它自己主动去收集完成任务所需要的信息。但 Transformer 对长文本中间段的注意力天然衰减，并且模型的上下文窗口有限。你能给它什么、怎么给，直接决定了它的产出质量。
Cursor 的 Tab 补全便是非常好的诠释。同时期的 AI IDE 中，Cursor 的 Tab 几乎是无敌的存在，自动补全效果好到就像是读了你的脑子一样，知道你下一步想要编辑什么，这便是上下文质量高的功劳，模型能精准地预测你下一步的动作。
到了 Agent 时代，上下文窗口几乎都是被工具的使用占满的，工具定义要占用，调用结果也要占用。当 AI 不再只是补全代码，而是需要自主调用工具完成任务时，工具描述的冗余和调用结果的噪声都会直接侵蚀模型对核心任务的注意力。关于工具使用的上下文工程，可以看之前写的《MCP vs Skill vs CLI: AI Agent 上下文管理的本质与实践》。
人的重心从「怎么描述问题」转移到了「给什么样的上下文」，后来这样的工作有了一个名字「Context Engineering」。与 Prompt Engineering 不同，时至今日，我依然觉得这项工作非常重要，拥有「上下文洁癖」（只给相关的、精简的、高信噪比的信息）是开发/使用 Agent 提升产出效果的利器。
Harness Engineering：搭环境、建约束、构建反馈回路
2025 年 2 月，Claude 3.7 Sonnet 和 Claude Code 发布。Claude Code 第一次把对话区变成了主战场，终端开始取代编辑器成为 AI 编码的主要界面。Cursor 在 2026 年初的数据也印证了这个趋势，agent 模式用户首次超过了 tab 补全用户。AI Agent 为主，人为辅的范式成为大势所趋。
模型能稳定理解、推理、调用工具了。Agent 能完成任务了，但过程中人还是得频繁介入，补信息、纠方向、盯质量。能干活跟能自主干好活，是两件事。
最开始，我们在 CLAUDE.md 和 Cursor Rules 里写代码规范和工程结构要求，期望 AI 按规范写。这是 prompt 和 context 层面的「约束」，与其说是约束，倒不如说是靠引导模型去避免这样的问题。但逐渐发现，不管怎么强调，AI 还是会写出不合规范的代码。规范写得越多，它越容易顾此失彼。
于是我们想着通过 Lint 来约束 AI 产出的代码。用代码逻辑来消除 AI 产出物的不确定性。说不行的事，靠机制来卡住。
但这个阶段我们只解决了 Coding 的问题。早期用 AI 更多都是辅助生成代码，只在写代码这个环节提效。而工程师并不是把代码写完就完事了，部署、测试、查日志，AI 写完了，人接手。在很长一段时间内，乃至到现在大部分人的 AI Coding 方式也还是这样。
这样的状态维持了一段时间，我们逐渐开始对这样的协作方式感到厌倦。每次 AI 产出代码，我得去帮它部署、帮它测、帮它查问题。我能不能直接把这些都给它？于是给 AI 加了部署工具、测试工具、日志查询工具、浏览器控制台调试能力。把我自己交付一个需求需要的一切，都暴露给 AI。让 AI 不仅能写代码，还能自己验证写的代码能不能跑，出问题了自己去看日志、排查。
最早我了解到 Harness Engineering 这个概念是从 OpenAI 2026 年 2 月发布的Harness Engineering。这篇报告的核心思想是给 Agent 一套全透明、高效的环境，所有知识和记录都留在代码仓库里，确保 Agent 能通过仓库了解整个业务系统，自己迭代、运维一整个业务系统。三个人五个月从零迭代到一百万行代码，合并了 1500 个 PR。
工程团队不再编写代码，而是设计环境、明确意图和构建反馈回路，从而使 Agent 能够稳定可靠地交付工作。 这就是我最早理解的 Harness。当你在搭的不只是一堆工具，而是一套让 AI 能自己验证交付结果的完整环境时，你已经在做 Harness Engineering 了。不过时至今日，Harness 这个词已经被进一步泛化，可以总结为一个公式：「Agent = Model + Harness」，模型之外的一切都是 Harness。这和早期的含义并不矛盾：早期我们说的 Harness 是给单个 Agent 搭建的运行环境，而 Agent 工程本身就是在给模型搭建运行环境，两者本质上是同一件事的不同粒度。
Loop Engineering：给定目标，让 AI 自主循环收敛
环境搭好了，反馈链路有了，给定一个明确、可验证的目标，AI 就能自己一轮一轮地逼近。
2026 年 6 月，OpenClaw 的作者 Peter Steinberger 发了条推说「You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents」，随后 Claude Code 的作者 Boris Cherny 跟了一句「I don’t prompt Claude anymore, I write loops」，Osmani 接着写了篇文章Loop Engineering，Loop Engineering 这个名字就开始在社交平台上疯狂传播了。
Lint 规则集收敛。 我们有一套积累了近两百条的文字版代码规范，我们的目标是尽可能地把这些规范能 Lint 化的都 Lint 化，于是先让 AI 梳理出哪些是可以通过 Lint 来覆盖的，然后让 AI 把初步评估可行的近 100 条规则通过 Lint 实现了，这个时候肯定会有很多 Lint 规则会有误报。于是我构建了这样一个循环：在整个代码仓库里批量跑这批规则，每条规则对扫描到的 case 抽检 10 条，用子 Agent 逐一检查是否存在误报。有误报就调整规则，或者标记为当前无法实现。提交改动，进入下一轮。几轮下来，规则集的准确性就收敛到了一个可靠的水平。
CLI 工具迁移。 我有一个用 Bun + TypeScript 开发的 CLI 工具，想打包传到平台上给其他人使用。但 Bun 打包出来的二进制本身就大，还需要一次性上传多个平台的二进制文件，平台限制了文件大小，方案行不通。于是决定往 Go 迁移。让 AI 梳理好迁移计划清单和验证方式之后，AI 连续跑了五六个小时，一把通过，一个小问题都没有。
实现其实很简单。我写了一个 Hook 来拦截 Claude Code 的会话结束动作，Hook 脚本里检查迁移计划里是不是所有待办项都完成了，没完成就阻塞，提示还有任务未完成，整个 Hook 的逻辑就几行代码。有点像后来 Codex 出的 Goal 模式，就是通过更 Harness 的方式不让 AI 停下来，直到它把事情做完。
但说实话，我个人感觉 Loop Engineering 更像是一种应用方式，而不是一个新的范式，也不是所有场景都适合用 Loop。当环境、反馈、可验证的目标都有了，让 AI 自主循环，长时间运行来逼近目标是一个很自然的选择。一个简单循环就能做的事，没必要包装成玄学。有些文章把 Loop Engineering 说得无所不能，我们读完后总会感觉似懂非懂，好像什么都能做，又好像不知道自己的场景能做什么。
那么，什么样的场景是适合「Loop」的呢？我认为就一个，有非常清晰、可验证且能逐渐收敛的目标。
- 清晰：明确自己想要的是什么，盲目地去跑 Loop 除了能让你看到大量 Token 消耗以及跑了 xxx 小时的长任务用于对外吹牛传播焦虑之外，带来不了任何价值。比如在 Lint 规则集开发的例子里，我们的目标就是连续 3 轮零误报。
- 可验证：有了清晰的目标，你得给 Agent 一把用于度量目标达成情况的尺子，最好是有客观的指标能体现达成情况，优化类工作，可以量化出一个 xxx 率，系统重构迁移或者新项目的开发，可以是一个一个功能点的测试用例执行情况。这些都是能非常直观地反映出任务完成度的指标。
- 可收敛：任务一定得是随着一轮一轮循环，逐渐逼近目标的。不可收敛的目标，再怎么 Loop 也拿不到你想要的结果。
实践提示：Loop 的效果和模型特点有关。我的体感是 Claude 系模型更容易对自己的产出感到满意、容易糊弄完成，GPT 系（截止 2026 年 4 月）则严谨得多，一点小细节不满足都会继续优化。在 Loop 类任务中可以尝试换不同的模型，甚至引入多模型对抗来利用各自的特性。
Loop 很有价值，但也不是什么万金油。知道了它的边界，才知道什么时候用它、怎么用明白它。
回到第一性原理
这四个阶段不是替代关系。Prompt Engineering 确实被模型能力的提升弱化了，你不再需要各种花里胡哨的提示词技巧，但把问题表达清楚永远是基本功。而 Context、Harness、Loop 是共存的，每进入一个新阶段，不是前面的就不需要了，而是你需要考虑的维度更高阶、更全面了。
永远会有新概念被发明，永远会有新工具出现。追着它们跑是追不完的，只会越追越焦虑。
比起追概念，不如养成一个习惯：从本质出发，从自己的问题出发。我们想要什么？AI 现在缺什么？为什么做不好？我们身处这么好的时代，有这么好的工具，可以追求更懒一些。多问自己为什么不能交给 AI 做，多追问 AI 为什么做不到，直到找到问题的根源。当你能分清哪些是模型的能力边界、哪些只是还没人给 AI 铺好路，自然就知道下一步该往哪走。
推荐阅读
- Prompt Engineering — Lilian Weng (OpenAI), 2023.3
- Effective Context Engineering for AI Agents — Anthropic, 2025.9
- Harness Engineering — OpenAI, 2026.2
- The Coming Loop — Armin Ronacher, 2026.6
- Getting started with loops — Anthropic, 2026.6
- Effective harnesses for long-running agents - Anthropic, 2025.11
- Harness design for long-running application development - Anthropic, 2026.3