这周，AI Agent 圈又出现了一个新词：Loop Engineering。它看起来有点陌生，但如果放到我们和 AI 的交互变化里看，就会自然很多。
一开始，我们主要是在和 AI “对话”。AI 要理解我们的需求，就有了 Prompt Engineering：怎么把一句 prompt 写好，让它更准确地明白我们要什么。再后来，AI 开始进入更具体的任务场景。它不能只理解一句话，还得知道项目背景、任务目标、代码结构和历史决策。就诞生了 Context Engineering：要给 AI 什么上下文，它才更容易做对。
再往后，AI Agent 开始“长手长脚”了。不只是在聊天框里回答问题，它还能写代码、查资料、调用工具、跑测试、修 bug。但是 Agent 要处理的任务变长、变复杂之后，问题也随之来了：
要如何持续推进任务？
执行结果要怎么检查？
任务失败之后要怎么修正？
修正后的经验能不能沉淀下来？
什么时候该停下来，把决策权交给人？
这就是最近大家开始讨论 Loop Engineering 的原因。
单看 Loop Engineering，它像是一个新黑话。比较好的理解方式，是把它和另外三个词放在一起看：Prompt Engineering、Context Engineering、Loop Engineering、Harness Engineering。
它们其实是在回答 AI Agent 工作流里的四个问题：怎么问、给它看什么、怎么让它持续推进，以及让它在什么样的环境里安全运行。
Prompt Engineering：怎么问 AI
Prompt Engineering 是最早被大家熟悉的概念。那时候，我们经常会问一句：“你的 Prompt 是怎么写的？”Prompt Engineering 关心的是人要怎么组织指令，让模型更准确地理解任务，并按我们想要的格式输出结果。为此，我们会让 AI 扮演某个角色，明确输出格式，补充几个示例，告诉它回答时要注意什么，或者要求它分步骤完成任务。这些做法的目的都很直接：让 AI 更接近我们想要的结果。
Prompt Engineering 要解决的问题概括成一句话，就是怎么问，AI 才更容易答对。
它适合处理相对明确、边界比较清楚的任务，像是写一段文案、总结一篇文章、提取几个要点，或者生成一个表格。
但当任务变复杂之后，光靠 prompt 就不够了，因为 AI 可能不知道你的项目背景，不了解代码结构，也不清楚之前做过哪些决定。
这时候，重点就从“怎么问”，转向了“给它看什么”。
Context Engineering：给 AI 看什么
执行任务时，应该把哪些信息放进模型的上下文里，是 Context Engineering 要解决的问题。
举个例子，你让 Agent 修改一个项目 bug。它需要看到的不只是你的那句需求，还有相关代码文件、项目目录结构、错误日志、测试结果、README、团队规范、历史 issue，以及之前的修改记录。
这些信息给少了，Agent 可能缺少判断依据；信息给错了，它可能很努力在错方向上渐行渐远；信息给得太多，它又可能抓不住重点。
Context Engineering 要解决的问题概括成一句话，就是给 AI 看什么，它才更容易做对。
在 AI Agent 里，这件事会变得更重要。因为 Agent 经常要连续执行很多步，每一步都需要判断：现在应该读取什么信息，保留什么信息，又该丢掉什么信息。
Loop Engineering：让 Agent 循环工作
这周火起来的 Loop Engineering，主要解决 Agent 持续工作、围绕任务工作的问题。
以前我们使用 Agent 时，很多任务其实都要靠人一轮轮往前推。你让它修一个 bug，它改了一版之后，可以自己运行测试、读取报错，再继续修改；但这个过程要不要继续跑、失败几次后要不要停下来、哪些结果算通过、最后要不要交给人来进行 review，是要一套流程来约束和判断的。
Loop Engineering 想做的事情，就是把这个过程设计成一个稳定的循环：任务输入 → Agent 执行 → 工具检查 → 失败反馈 → 再次修改 → 记录状态 → 必要时交给人。
以“修 bug loop”为例，Agent 可以先读取 issue，找到相关代码并尝试修改，再运行测试；如果测试失败，它会读取报错继续修复；如果测试通过，就生成修改总结，最后创建 PR，或者把结果交给人来 review。
Loop Engineering 的重点不是让 Agent 无限制地自动干活，而是把执行、反馈、验证、修正、记录、接管这些步骤串起来。Loop Engineering 要解决的是：Agent 怎么持续推进任务，而不是只完成一次回答。
它能用在很多场景中，修 bug、修测试、处理 issue、生成 PR、检查 CI 失败，也可以用来整理资料、生成内容、沉淀项目规则。
举个例子，在内容生产场景里，我们也可以有 loop：先收集资料，再总结要点，接着检查事实、生成大纲、写正文、检查有没有夸张表达，最后交给人润色。这也是一种 loop，只不过循环的对象不是代码，而是内容工作流。
Harness Engineering：给 Agent 搭运行外壳
AI Agent 工程的最后一个关键词是 Harness Engineering。
这里的 Harness，可以理解成 Agent 外面的一套“运行外壳”：Agent 要依赖哪些工具，能访问哪些权限，在什么环境里执行任务，过程怎么记录，结果怎么验证，出问题时又该怎么交给人接管，这些都是它要关心的事情。
如果说模型是发动机的话，Harness 就是车身、仪表盘、刹车、方向盘、安全带和道路规则。模型本身可以生成代码、回答问题、给出方案，但如果没有合适的 Harness，它就很难安全地修改项目、运行命令、记录过程、处理失败，也很难让人知道它到底做了什么、做得对不对。
Harness Engineering 要解决的问题概括成一句话，就是 Agent 在什么环境里运行，才能更安全、更稳定、更可控。
看起来它比前面三个词更加工程化，但是本文不展开讲述，你只要记住这些关键词就够了：工具、权限、沙箱、日志、测试、状态和人类接管。它们共同决定了 Agent 能做什么、不能做什么，以及做完之后怎么证明自己真的完成了任务。
Agent 的 4 个工程如何合作
把这四个词放在一起看，它们其实是在描述 AI Agent 变复杂之后，开发者关注点的变化：从写好一句 prompt，到组织上下文，再到设计执行循环，最后给 Agent 搭一套更安全、可控的运行环境。
而最近被频繁提到的 Loop Engineering，重点就在“执行循环”这一环：让 Agent 能接收任务、调用工具、根据反馈继续修改、记录过程，并在关键节点交给人接管。
如何用 Loop Engineering
如果你想实践一下 Loop Engineering，不一定要一上来就搭一个复杂系统，我们可以先从一个很小的 loop 开始。
举个例子，Agent 要去修代码，我们可以不只让它“改完告诉我”，还可以要求它先说明修改计划，再修改代码，再运行测试；如果测试失败，就读取错误继续修；最后再输出它改了什么、验证了什么，以及还有哪些风险。这就是一个非常基础的 loop：让 Agent 不只是执行一步，而是围绕“完成任务”不断检查和修正。
再进一步，你可以把团队里反复出现的问题沉淀下来。如果 Agent 经常忘记跑测试，那就把测试要求写进规则；Agent 经常误改生成文件，就把禁止修改的目录写清楚；经常忽略项目约定，就把约定放进 CLAUDE.md、AGENTS.md 或项目文档；如果它经常自己判断不准，也可以加一个 verifier 负责检查。
到了这一步，Agent 工作流就不再只是一次次聊天，而是在不断积累经验。当然，它依然得要人来把关。Loop 跑得越久，越需要清晰的边界、可靠的验证和明确的停止条件，否则错误也会被循环放大。
小结
所以，Prompt、Context、Loop、Harness 这四个词，可以看成 AI Agent 工作流里的四个关注点：怎么问、给它看什么、怎么持续推进，以及在哪里安全运行。
其中，Loop Engineering，重点关注“持续推进”这一环节。它关心的是，如何把原本由人一轮轮推动的“提示—执行—检查—修正”过程，设计成一个清晰、可控、容易沉淀经验的循环。
这也是 AI Agent 从“能回答问题”，走向“能完成任务”时，一个很关键的变化。
