本周，AI Agent 领域出现了一个新概念：Loop Engineering（循环工程）。初次接触可能感到陌生，但如果将其置于人与 AI 交互的演进脉络中，就很容易理解了。

最早，我们与 AI 主要依赖“对话”模式。为了让机器理解人类意图，便诞生了 Prompt Engineering（提示工程）——通过精心设计指令，使模型更精准地把握需求。随着 AI 开始处理更具体的任务，单靠一句指令已不足以支撑复杂场景，它需要了解项目背景、代码架构和历史决策。于是 Context Engineering（上下文工程） 应运而生——核心问题变成：应给 AI 提供哪些上下文，才能减少其判断偏差？

随后，AI Agent 具备了“行动能力”。它不再局限于对话框中的问答，还能编写代码、检索资料、调用工具、运行测试、修复缺陷。然而，当任务链条变长、复杂性提升时，新的挑战随之出现：

• 如何保证任务持续推进？
• 执行结果由谁来验证？
• 失败时如何修正？
• 修正的经验能否沉淀复用？
• 何时应当停止，将决策权交还给人类？

这正是 Loop Engineering 近期被广泛讨论的原因所在。

单独看这个词，确实像新发明的行话。但将其与另外三个概念放在一起审视，思路便会清晰：Prompt Engineering、Context Engineering、Loop Engineering、Harness Engineering。

它们分别回应了 AI Agent 工作流中的四个核心问题：如何提问、提供什么信息、如何持续迭代、以及在怎样的环境中安全运行。

Prompt Engineering：如何向 AI 提问

Prompt Engineering 是最早被普及的概念。当时人们常问：“你的提示词是怎么写的？”它关注的是人类如何组织指令，使模型更准确地理解任务，并按期望格式输出。我们会让 AI 扮演特定角色、明确输出结构、补充示例、强调注意事项，或要求分步骤完成。这些做法的目标非常直接：让 AI 更接近我们想要的结果。

可以说，Prompt Engineering 的核心问题只有一个：如何提问，才能让 AI 回答得更精准？

它适用于边界清晰、相对明确的任务，例如撰写文案、总结文章、提取要点或生成表格。

但任务复杂度提升后，仅靠提示词便显得力不从心。AI 可能完全不了解项目背景、代码结构以及历史决策。此时，重点便从“如何提问”转向了“提供什么信息”。

Context Engineering：给 AI 提供什么信息

执行任务时，应把哪些资料放入模型的上下文？这是 Context Engineering 需要解决的问题。

例如，你让 Agent 修复项目中的 Bug。它需要看到的，远不止一句需求描述，还包括相关的代码文件、项目目录结构、错误日志、测试结果、README 文档、团队规范、历史 Issue 以及之前的修改记录。

这些信息提供不足，Agent 可能缺乏判断依据；信息错误，它会朝着错误方向努力前行；信息过多，它又可能抓不住重点。

Context Engineering 要解决的核心问题可以概括为：给 AI 提供什么信息，才能让它更容易做出正确决策。

在 AI Agent 场景中，这个问题越发重要。因为 Agent 经常需要连续执行多个步骤，每一步都要判断：当前应该读取什么信息、保留什么、丢弃什么。

Loop Engineering：让 Agent 循环执行任务

本周热议的 Loop Engineering，主要解决 Agent 如何持续工作、围绕一个任务不断推进的问题。

过去使用 Agent 时，很多任务实际上依赖人工逐轮推动。例如，让 Agent 修复一个 Bug，它修改一版后，可以自动运行测试、读取报错信息，再继续调整。但整个过程是否继续、失败几次后应该停止、哪些结果算通过、最后是否需要人工审查，都需要一套流程来约束和判断。

Loop Engineering 的目标，就是将这一连串步骤设计成一个稳定的循环：任务输入 → Agent 执行 → 工具检查 → 失败反馈 → 再次修改 → 记录状态 → 必要时交给人。

以“修复 Bug 循环”为例，Agent 可以先读取 Issue，定位相关代码并尝试修改，再运行测试；若测试失败，则读取报错继续修复；若测试通过，则生成修改总结，最后创建 PR 或交给人来审查。

Loop Engineering 的重点，并非让 Agent 无休止地自动工作，而是将执行、反馈、验证、修正、记录、接管等环节串联起来。它要解决的是：Agent 如何持续推进一个任务，而不只是完成一次回答。

这一思路可应用于多种场景：修复 Bug、修复测试、处理 Issue、生成 PR、检查 CI 失败，也可用于整理资料、生成内容、沉淀项目规则。

例如，在内容生产场景中，我们也可以设计一个循环：先收集资料，再总结要点，接着核实事实、生成大纲、撰写正文、检查是否有夸张表达，最后交给人润色。这也是一种循环，只是循环对象不是代码，而是内容工作流。

Harness Engineering：为 Agent 搭建运行环境

AI Agent 工程的最后一个关键概念是 Harness Engineering。

这里的 Harness，可以理解为 Agent 外壳的“运行框架”：Agent 依赖哪些工具、能访问哪些权限、在什么环境中执行任务、过程如何记录、结果如何验证、出问题时如何交给人接管——这些都属于它要关心的范畴。

如果说模型是发动机，那么 Harness 就是车身、仪表盘、刹车、方向盘、安全带和道路规则。模型本身可以生成代码、回答问题、给出方案，但如果没有合适的 Harness，它很难安全地修改项目、运行命令、记录过程、处理失败，也难以让人了解它到底做了什么、做得是否正确。

Harness Engineering 要解决的核心问题是：Agent 在什么环境中运行，才能更安全、更稳定、更可控？

看起来它比前面三个概念更为工程化，但这里不展开细讲，记住几个关键词即可：工具、权限、沙箱、日志、测试、状态和人类接管。它们共同决定了 Agent 能做什么、不能做什么，以及完成后如何证明自己确实完成了任务。

Agent 的四个工程如何协同

将这四个概念放在一起，它们描述了 AI Agent 变得复杂后，开发者关注点的自然演进：从写出一条好提示词，到组织上下文，再到设计执行循环，最后为 Agent 搭建一套更安全、可控的运行环境。

而近期被频繁提及的 Loop Engineering，重点就落在“执行循环”这一环：让 Agent 能接收任务、调用工具、根据反馈继续修改、记录过程，并在关键节点交给人接管。

如何实践 Loop Engineering

如果你想尝试 Loop Engineering，不一定非要从搭建一个复杂系统开始。从一个很小的循环起步即可。

举个例子，Agent 需要修复代码，我们可以不只让它“改完告诉我”，还可以要求它先说明修改计划，再修改代码，再运行测试；若测试失败，则读取错误继续修复；最后输出它改了什么、验证了什么，以及还存在哪些风险。这就是一个非常基础的循环：让 Agent 不只是执行一步，而是围绕“完成任务”不断检查和修正。

再进一步，你可以把团队中反复出现的问题沉淀下来。例如，如果 Agent 经常忘记运行测试，就把测试要求写入规则；经常误改生成文件，就把禁止修改的目录明确列出；经常忽略项目约定，就把约定放入 CLAUDE.md、AGENTS.md 或项目文档；如果它经常判断不准，可以添加一个专门的 Verifier 负责检查。

到达这一步，Agent 工作流就不再只是一次次对话，而是在持续积累经验。当然，它依然需要人来把关。循环运行得越久，越需要清晰的边界、可靠的验证和明确的停止条件，否则错误也会被循环放大。

小结

因此，Prompt、Context、Loop、Harness 这四个概念，可以看作 AI Agent 工作流中的四个关注维度：如何提问、提供什么信息、如何持续推进、以及在哪里安全运行。

其中，Loop Engineering 重点关注“持续推进”这一环。它关心的是，如何把原本由人逐步推动的“提示—执行—检查—修正”过程，设计成一个清晰、可控、易于沉淀经验的循环。

这也是 AI Agent 从“能够回答问题”迈向“能够完成任务”时，一个非常关键的变化。