过去我们习惯把 AI 应用的核心理解成 Prompt Engineering。但到了 Agent 阶段，问题变了：模型不只是回答一次，而是要观察、行动、获得反馈、修正、继续推进。于是 Context Engineering、Harness Engineering、Loop Engineering 这些概念陆续出现。它们不是简单的互斥关系，而是从输入、上下文、运行环境到循环控制的不同工程视角。这篇文章试着拆一下。
标题备选
- Prompt Engineering 过时了吗？现在大家开始谈 Loop Engineering
- AI Agent 真正难的不是 Prompt，而是 Loop
- 从 Prompt 到 Context，再到 Loop：AI 工程正在换重点
- 为什么 Loop Engineering 最近开始火了？
- 做 AI Agent，别只盯着提示词了
Prompt Engineering 之后，为什么又冒出 Loop Engineering？
过去两年，很多人对 AI 应用的理解，基本停留在一个动作上：
给模型一个好 Prompt，然后等它返回一个好答案。
这就是 Prompt Engineering 最早火起来的原因。你写清楚角色、任务、约束、格式、示例，模型输出就会稳定很多。对于写文案、总结、翻译、生成代码片段，这一套确实有效。
但到了 AI Agent 阶段，问题开始变化。
Agent 不只是“回答一次”。它可能要读文件、调用工具、执行命令、看报错、修改代码、重新运行测试、继续判断下一步。这个过程更像一个循环：
观察当前状态 → 思考下一步 → 执行动作 → 获得反馈 → 修正策略 → 再执行
这就是最近很多人开始讨论 Loop Engineering 的原因。
它关注的不是“这一句话怎么写得更好”，而是：
一个 AI 系统如何在连续反馈中，把事情一步步做完？
这个判断很关键。因为越往后，AI 应用的难点越不在“让模型说得好听”，而在“让模型持续做对”。
先说结论：四个概念解决的是不同层的问题
如果简单拆，可以这样理解：
| 概念 | 主要问题 | 关注对象 | 典型场景 |
|---|---|---|---|
| Prompt Engineering | 怎么问模型？ | 单次输入指令 | 写作、总结、问答、简单代码生成 |
| Context Engineering | 给模型看什么？ | 上下文组织 | RAG、长文档分析、代码库理解、企业知识库 |
| Harness Engineering | 模型之外的系统如何让 Agent 可靠工作？ | Agent 的运行与控制环境 | 提示、上下文、工具、记忆、沙箱、权限、反馈、验证、观测 |
| Loop Engineering | 系统如何反复驱动 Agent 并收敛？ | 多步反馈循环和停止条件 | 自动编程、自动研究、长期任务、周期性任务执行 |
这四个不是互相替代。更准确地说：Prompt 关注“怎么指令模型”，Context 关注“给模型看什么”，Harness 关注“模型之外的运行环境如何支撑和约束 Agent”，Loop 关注“怎样让这个 Agent 在多轮行动、反馈和验证中持续推进并停止”。
Prompt Engineering：让模型第一次回答得更好
Prompt Engineering 是最容易理解的一层，它主要优化单次模型调用。
常见做法包括：
- 明确角色：你是一个资深产品经理 / Python 工程师 / 法律顾问；
- 明确任务：请总结、请改写、请生成代码；
- 明确约束：不要超过 500 字、用表格输出、不要编造数据；
- 给示例：按照下面格式回答；
- 指定风格：严谨、口语化、适合小红书、适合技术博客。
比如你问：
帮我写一个产品介绍。
和你问：
请用面向企业 CTO 的语气，写一段 300 字以内的产品介绍，重点突出安全、私有化部署和系统集成能力，避免营销腔。
效果肯定不一样。Prompt 的价值，是降低模型理解任务的成本。
但它也有天然边界：如果任务需要多轮执行、根据结果修正方向、调用外部工具，再好的 Prompt 也只能解决第一步。
Context Engineering：让模型看到正确的东西
Context Engineering 解决的是另一个问题：
模型每次回答之前，应该看到哪些信息？
很多 AI 应用失败，不是因为 Prompt 写得差，而是上下文给错了。
比如让模型分析一个代码库，你不能只说“帮我修 Bug”。你要让它知道：
- 项目结构是什么；
- 相关文件有哪些；
- 报错信息是什么；
- 最近改过什么；
- 测试命令是什么；
- 业务规则和边界条件是什么。
Context Engineering 的核心不是“塞更多内容”，而是“选择正确内容”。上下文窗口变长以后，这件事反而更重要：信息越多，噪音也越多，模型注意力可能被稀释。
一个好的 Context Engineering 系统，通常要做几件事：
- 检索：从文档、代码、数据库里找到相关信息；
- 筛选：过滤掉不相关内容；
- 压缩：把长内容整理成模型能消化的结构；
- 更新：随着任务推进，不断刷新当前状态；
- 隔离：不同任务、不同权限、不同用户的上下文不能混在一起。
所以 Context Engineering 回答的是：
模型做判断时，它的“现场材料”是否正确？
现场材料错了，再好的 Prompt 也救不回来。
Harness Engineering：让模型可以安全地接入现实世界
再往外一层，是 Harness Engineering。
这个词没有 Prompt Engineering 那么普及，而且不同作者使用时边界也不完全一样。比较常见的一句话是：
Agent = Model + Harness
也就是说，harness 不是模型本身，而是模型之外让 Agent 能工作的那套系统。它可以包括系统提示词、上下文组织、工具描述、工具调用、文件系统、沙箱、权限、记忆、任务状态、日志、测试、验证、人工审批、错误恢复等。
所以，Harness Engineering 不能简单理解成 Loop Engineering 的另一个名字。它的范围通常更大：Loop 解决的是“如何反复驱动、反馈、修正和停止”，而 Harness 解决的是“模型被放进一个怎样的运行环境里，能看到什么、能做什么、怎么被约束、怎么被验证”。
它解决的问题是：
模型之外的系统，如何把模型能力变成可执行、可验证、可控制的 Agent 行为？
比如一个 AI 编程助手，不可能只生成代码就结束。它还需要：
- 读取文件；
- 修改文件；
- 执行测试；
- 捕获报错；
- 回滚失败修改；
- 控制命令权限；
- 记录每一步操作；
- 做安全检查；
- 和 Git、CI、Issue 系统集成。
这些不是 Prompt 本身能解决的，而是模型外面的运行环境和控制系统。
在评测领域也一样。你要判断一个模型是不是更强，不能只看一次回答。你需要一个 evaluation harness：
- 固定数据集；
- 固定评分规则；
- 固定运行环境；
- 可重复执行；
- 可比较结果。
所以 Harness Engineering 问的是：
模型被放进一个什么样的工作环境里？
很多 Agent demo 看起来很强，但一接入真实工作流就容易出问题，常常不是模型完全不行，而是 harness 太弱：权限不清、工具不稳、反馈不完整、失败不可控。
Loop Engineering：真正决定 Agent 能不能把事情做完
现在回到 Loop Engineering。它关注的是 Agent 的核心循环。
一个最简单的 Agent Loop 大概是：
1. 接收目标
2. 观察当前状态
3. 生成下一步计划
4. 调用工具或执行动作
5. 获取结果
6. 判断是否成功
7. 如果失败，分析原因并重试
8. 如果成功，继续下一步或结束
这个循环看起来简单，但每一步都有工程问题。
第一，什么时候继续，什么时候停止？
Agent 最常见的问题之一，是停不下来。它会反复搜索、反复修改、反复总结，看起来很努力，但没有明确收敛条件。
所以 Loop Engineering 要设计终止条件：
- 测试是否通过？
- 用户目标是否满足？
- 结果是否达到评分阈值？
- 是否超过最大步数？
- 是否需要人工确认？
没有终止条件的 Agent，本质上不是自动化，而是失控循环。
第二，失败之后怎么修正？
人类做事时，失败之后会判断原因：是信息不够、工具错了、假设错了，还是目标理解错了。Agent 也需要类似机制。
比如代码测试失败，下一步不能只是“再试一次”。它应该先判断：
- 是语法错误？
- 是依赖缺失？
- 是测试用例理解错了？
- 是之前修改影响了其他模块？
- 是需要回滚还是继续补丁？
Loop Engineering 的重点，是让 Agent 的重试不是“再来一次”，而是带着反馈修正。
第三，循环里的状态怎么管理？
Agent 每一步都会产生新信息。问题是：哪些要保留？怎么保留？保留多久？
比如一个编程 Agent 修 Bug，它可能经历：
- 用户需求；
- 初始假设；
- 查看过的文件；
- 修改过的代码；
- 运行过的测试；
- 出现过的报错；
- 已经排除的方向；
- 当前剩余问题。
如果这些状态管理不好，Agent 就会“失忆”，或者反复做同一件事。
这就把 Loop Engineering 和 Context Engineering 连在了一起：Loop 负责推进，Context 负责在每一步提供正确状态。
第四，什么时候让人介入？
一个成熟的 Agent 不应该假装什么都能自动完成。有些节点应该主动停下来：
- 要删除数据；
- 要提交代码；
- 要调用付费 API；
- 要访问敏感文件；
- 有多个方案但代价不同；
- 需求本身存在歧义。
Loop Engineering 不是追求全自动，而是设计合理的人机协作边界。
为什么现在 Loop Engineering 会变重要？
我觉得有三个原因。
1. AI 应用正在从 Copilot 走向 Agent
Copilot 时代，AI 主要是辅助人：你问，它答；你选，它改；你复制，它执行。
Agent 时代，AI 开始承担连续任务，比如：
- 自动修复一个 Issue；
- 自动生成并运行测试；
- 自动整理一份研究报告；
- 自动监控系统并发出告警；
- 自动帮你处理一批重复工作。
连续任务的难点不在第一次回答，而在中间过程：如何判断、行动、验证、修正，并最终停止。
2. 模型能力变强之后，系统设计反而更重要
模型越强，越容易让人误以为“只要模型够强，外部工程就不重要”。但现实往往相反。
模型能做的动作越多，越需要边界、反馈、验证和控制。否则它可能很自信地把事情做偏。
这也是为什么很多 Agent 产品最后拼的不是单个模型，而是：
- 工具设计；
- 状态管理；
- 权限系统；
- 评测体系；
- 错误恢复；
- 人机交互节点。
这些正是 Loop Engineering 和 Harness Engineering 变重要的地方。
3. 真实工作流天然是循环的
写代码、研究资料、写文章、处理客服工单，都不是一次问答就结束。真实工作流本来就是循环：做一点，看结果，再调整。AI 如果要进入真实工作流，就必须学会在循环里工作。
对开发者来说，应该怎么理解这个变化？
如果你是开发者，我建议不要把 Loop Engineering 当成一个新名词去追，而是把它当成一个提醒：
以后做 AI 应用，不要只写 prompt，要设计过程。
设计一个最小可用的 Agent Loop，至少要想清楚这些问题：
-
目标是什么？
用户到底希望完成什么，而不是模型应该说什么。 -
状态从哪里来？
当前任务进展、历史动作、外部信息如何进入上下文。 -
动作有哪些？
模型可以调用哪些工具？每个工具的输入输出是什么？ -
反馈是什么？
执行动作后，系统如何告诉模型成功还是失败？ -
如何验证？
靠测试、规则、评分器，还是人工确认？ -
什么时候停止？
成功、失败、超时、风险、歧义，分别怎么处理？ -
怎么避免重复犯错？
已经尝试过的路径如何记录？错误如何进入下一轮判断？
这些问题比“Prompt 应该怎么写”更接近真实工程，也决定了 Agent 是稳定推进，还是不断跑偏。
一个具体例子：让 AI 修一个 Bug
假设你要做一个“自动修 Bug”的 Agent。
只靠 Prompt Engineering，你可能会写：
你是一个资深工程师，请修复下面这个 Bug，并给出代码。
这能解决一部分问题，但离真正可用还差很远。
加入 Context Engineering，你会给它：
- Bug 描述；
- 报错日志；
- 相关文件；
- 项目结构；
- 测试用例；
- 最近提交记录。
加入 Harness Engineering，你会给它：
- 文件读写工具；
- 命令执行工具；
- 测试运行环境；
- Git diff 查看；
- 安全限制；
- 回滚机制。
加入 Loop Engineering，你要设计：
读取 Bug → 定位相关代码 → 提出假设 → 修改代码 → 运行测试
→ 如果失败，读取错误 → 判断原因 → 再修改
→ 如果通过，检查 diff → 输出总结 → 等待人工确认
这才像一个真正能工作的 AI Agent。严格说，在更宽的定义里，前面的 Prompt、Context、工具、验证和反馈都可以算作 harness 的组成部分；这里分开讲，是为了说明它们各自优化的工程问题不同。
需要警惕：Loop 不是越长越好
这里有一个容易被忽略的点：Loop Engineering 不是让 Agent 无限循环。
很多 Agent demo 看起来很酷，是因为它会不断行动。但在真实系统里，循环越长，成本越高，风险也越高。
风险包括：
- token 成本上升；
- 执行时间不可控；
- 错误累积；
- 上下文污染；
- 工具误调用；
- 结果难以复现；
- 用户不知道系统到底做了什么。
所以好的 Loop Engineering 不是“让 AI 多做几步”，而是“让每一步都有依据、有反馈、有退出机制”。Loop 的价值不在循环本身，而在收敛。
小结
Prompt Engineering 解决“怎么问”，Context Engineering 解决“给模型看什么”，Harness Engineering 解决“模型之外的运行环境如何支撑和约束 Agent”，Loop Engineering 解决“如何让 Agent 在多步反馈中持续推进并收敛”。
这几个概念背后，其实是 AI 应用开发重心的变化：从写好一句 Prompt，变成设计一个可靠的工作系统。
如果只是做一次性问答，Prompt 仍然重要。
如果要做知识库、代码理解、企业助手，Context 会变得重要。
如果要接入工具、执行命令、做评测、权限控制和可观测性，Harness 会变得重要。
如果要做真正的 Agent，让 AI 能持续行动、失败修正、最终收敛，Loop Engineering 就绕不开了。
所以我对 Loop Engineering 的理解是：
它不是一个新包装的 Prompt 技巧，而是 AI Agent 进入真实工作流之后，工程复杂度自然暴露出来的结果。
接下来很多 AI 产品的差距，可能不会只体现在“用了哪个模型”，而会体现在：谁把这个循环设计得更稳、更短、更可控。
你现在做 AI 应用时，最头疼的是 Prompt 不稳定，还是 Agent 在多步执行里容易跑偏？欢迎留言聊聊。