夜雨聆风AI Agent / Loop Engineering
AI Agent 的下一个关键词：Loop Engineering
真正重要的不是再写一条 Prompt，而是设计一个能持续推进任务的闭环
这两年，AI 工程领域的新概念几乎是一波接一波。
一开始Prompt Engineering为什么很多 Prompt 一上生产就失灵？一文讲清 Prompt Engineering 的本质，关心的是：怎么把问题问清楚。
后来的Context Engineering别再只盯着 Prompt 了：真正拉开 AI 系统差距的，是 Context Engineering，关心的是：怎么把正确的信息放进上下文。
再后来的 Harness Engineering从 Prompt 到 Context，再到 Harness：AI 工程到底升级了什么？，关心的是：模型不是孤立运行的，它需要工具、权限、状态、沙箱、观测、验证和人工介入。
最近，又出现了一个新的词：Loop Engineering。
乍一听，这又像是一个新概念。但其实它并不是一个完全独立的新东西，而是 Agent 工程发展到一定阶段后，自然暴露出来的问题：
当 Agent 不再只是回答一次问题，而是要持续发现任务、执行动作、验证结果、记录状态、继续下一步时，我们到底该怎么设计这个循环？
这就是 Loop Engineering 要解决的问题。
一Loop Engineering 到底是什么？
Loop Engineering，就是设计一个能持续驱动 Agent 工作的反馈闭环。
过去我们使用 AI Coding Agent，大多数时候是这样的：
人写 Prompt
Agent 执行
人看结果
人继续补充 Prompt
Agent 再执行
人继续检查在这个模式里，人是整个循环的发动机。
Agent 做完一步之后，下一步要干什么、结果是否正确、需不需要重试、什么时候停止，基本都靠人来判断。
而 Loop Engineering 想要改变的是这件事：
系统发现任务
系统组装上下文
系统调用 Agent
Agent 执行动作
系统验证结果
系统记录状态
系统判断继续、停止、重试或升级给人也就是说，人不再只是在一轮一轮地 prompt agent，而是在设计一个系统，让这个系统去 prompt agent、约束 agent、检查 agent，并决定下一轮该怎么走。
所以 Loop Engineering 的重点，不是某一条 Prompt 写得多漂亮，而是整个闭环是否可靠。
二它不是 Harness Engineering 之外的新大陆
很多人看到 Loop Engineering，第一反是：
是不是 Prompt Engineering、Context Engineering、Harness Engineering 之后，又来了一个新的 Engineering？
Loop Engineering 不是 Harness Engineering 外面凭空长出来的新大陆，而是 Harness Engineering 进入长期任务和持续自治场景后，出现的一层闭环控制能力。
Harness Engineering 解决的是：
模型在什么环境里运行？
它能调用哪些工具？
它能看到哪些上下文？
它的权限边界在哪里？
它的执行过程如何被观测？
它的结果如何被验证？
失败之后如何恢复？
什么时候需要人介入？这些问题本身就已经包含了很多 Loop Engineering 的基础能力。
比如状态管理、工具调用、沙箱隔离、验证机制、执行轨迹、人工介入，这些都不是 Loop Engineering 新发明的东西，而是 Harness 本来就应该承担的职责。
区别在于，Harness Engineering 更关注 Agent 如何完成一次可靠执行；Loop Engineering 更关注 Agent 如何在多轮、多任务、跨时间的过程中持续推进。
可以这样理解：
Harness Engineering
解决：Agent 如何在一个可靠环境里运行
Loop Engineering
解决：Agent 如何在这个环境里持续循环、验证、记忆、停止所以我更愿意把 Loop Engineering 看成：
Harness Engineering 的闭环控制层。
它不是替代 Harness，而是把 Harness 从“单次执行环境”推进到了“持续反馈系统”。
三为什么现在大家开始讨论 Loop Engineering？
以前的 AI 更像一个问答工具。你问，它答。你继续问，它继续答。
但现在的 Coding Agent、Research Agent、Computer Use Agent 已经越来越像一个执行系统。它们可以读代码、改文件、跑测试、查日志、调用浏览器、连接数据库、创建 PR，甚至在比较长的时间里持续处理一个任务。
这时候，真正的瓶颈就不再是“模型能不能写代码”这么简单了。
更大的问题变成了：
任务从哪里来？
上下文怎么给？
执行环境是否隔离？
怎么知道它真的做对了？
失败后是否重试？
重试几次才停止？
状态写在哪里？
下一轮怎么接着做？
哪些动作必须经过人确认？这些问题都不是一条 Prompt 能解决的。
所以软件工程不会因为 AI 会写代码就变得不重要。恰恰相反，AI 越能执行，工程系统越重要。
因为写代码只是其中一步。
关键判断
真正难的是把需求、上下文、权限、工具、验证、观测、回滚、协作和持续改进全部串起来。
这就是 Loop Engineering 出现的背景。
四一个 Loop 至少要包含哪些东西？
如果把一个 Agent Loop 拆开，它大概包含七个关键部分。
1. Trigger：任务从哪里被触发？
Loop 首先要有入口。
这个入口可以是定时任务，也可以是事件触发。
比如：
每天早上扫描昨天失败的 CI
每小时检查线上错误日志
每次 issue 被打上 bug 标签后触发
每次 PR 合并后检查文档是否需要更新
每周扫描过期的技术债没有 Trigger，就没有真正的 Loop。
你只是手动跑了一次 Agent。
2. Context Assembly：上下文怎么组装？
Agent 的能力很大程度上取决于它能看到什么。
如果你给它一堆过期文档，它会被误导。
如果你什么都不给，它会猜。
如果你把所有东西都塞进去，它又可能抓不住重点。
所以 Loop 里的上下文组装不是简单地“多给资料”，而是要设计一套可维护的上下文结构。
比如：
AGENTS.md 只做入口地图
架构文档放在 docs/architecture
业务规则放在 docs/product
接口约定放在 docs/api
测试策略放在 docs/testing
历史决策放在 docs/decisionsAgent 先看地图，再按任务需要去读取具体文档。
这就是 Context Engineering 和 Harness Engineering 在 Loop 里的结合点。
3. Skills：把重复知识沉淀下来
如果每一次都要重新告诉 Agent：
我们项目怎么启动
测试怎么跑
代码风格是什么
哪些目录不能动
数据库 migration 怎么写
PR 描述应该包含什么
安全审查要看哪些点那这个 Loop 很快就会变得不可维护。
Skills 的价值就在这里。
它把重复出现的项目知识、操作流程、约束规则和检查步骤，变成 Agent 每次都能复用的能力。
Prompt 是一次性的，Skill 是可复用的。
当一个 Loop 需要长期运行时，Skill 会比单次 Prompt 更重要。
因为你不能指望每一次循环都重新解释一遍项目背景。
4. Act：动作必须发生在受控环境里
Agent 一旦开始执行动作，就一定要有边界。
尤其是 Coding Agent。
它可能会改文件、跑命令、装依赖、访问接口、创建分支、提交 PR。
这时候必须考虑隔离问题。
比如多个 Agent 同时工作，如果都在同一个工作区里改代码，很容易互相覆盖。一个 Agent 修 bug，另一个 Agent 改重构，最后文件状态混在一起，问题就很难追。
所以 worktree、sandbox、临时环境、权限控制，都不是锦上添花，而是 Loop 能不能稳定运行的基础。
一个可靠的 Loop，必须让 Agent 的动作发生在可隔离、可回滚、可审计的环境里。
5. Observe / Verify：不能让执行者自己说自己做完了
Loop 最危险的地方是：
Agent 做完之后，说“我已经完成了”。
但它是不是真的完成了？
这个问题不能只靠 Agent 自己回答。
因为写代码的 Agent 很容易相信自己的方案。它可能修了一个表面错误，却绕开了真正的问题；也可能让测试通过了，但破坏了别的约束。
所以 Loop 里必须有验证机制。
验证可以来自：
单元测试
集成测试
类型检查
lint
安全扫描
性能指标
日志检查
人工评审
另一个 verifier agent实现者和验证者最好分开。
一个 Agent 负责实现，另一个 Agent 或确定性检查器负责验证。
这和软件工程里的 code review、CI、测试门禁是同一个思想。
AI Agent 并没有改变这些原则，只是让这些原则变得更重要。
6. Memory / State：状态不能只放在上下文窗口里
很多 Agent 系统做不长，很重要的原因是状态没有外部化。
一次会话里，Agent 好像记得自己做了什么。
但下一次启动，它可能什么都不知道。
所以 Loop 必须有外部状态。
这个状态可以是：
Markdown 进度文件
GitHub Issue
Linear 看板
数据库记录
评测结果
执行日志
PR 评论
任务状态表关键是：状态要活在模型上下文之外。
因为上下文窗口不是数据库。
长期任务不能依赖模型“记得”，而要依赖系统“记录”。
一个好的状态文件，至少应该记录：
当前目标是什么
已经尝试了什么
哪些方案失败了
失败原因是什么
哪些测试已经通过
还有哪些风险
下一步应该做什么
什么时候需要人介入这就是长期 Loop 的脊柱。
没有外部状态，Loop 只能靠运气续命。
7. Stop / Escalate：什么时候停止，什么时候交给人？
很多人只关心怎么让 Agent 动起来，却不关心怎么让它停下来。
但一个不能正确停止的 Loop，是非常危险的。
它可能反复修同一个 bug，越修越乱。
它可能为了让测试通过，删除测试。
它可能不断消耗 token、时间和计算资源。
它可能在权限过大的情况下做出不可逆操作。
所以每一个 Loop 都要有清晰的停止条件。
比如：
所有目标测试通过
lint 和类型检查通过
性能指标达到阈值
PR 已创建并等待人工 review
连续三次失败后停止
触及高风险文件后停止
涉及生产数据时停止
不确定需求含义时停止成熟的 Loop，不是一直跑，而是知道什么时候该停。
五Loop Engineering 容易踩的几个坑
第一个坑：把 Loop 理解成无限自动化
Loop 不是让 Agent 一直跑。
Loop 的核心是反馈控制，不是无限循环。
没有停止条件、没有预算限制、没有失败升级机制的 Loop，本质上就是一个会消耗资源的自动化黑盒。
第二个坑：让 Agent 自己验证自己
实现者当然可以做自检，但不能只靠自检。
尤其是代码、安全、数据、权限相关的任务，必须有独立验证。
可以是测试，可以是规则，可以是另一个 Agent，也可以是人工 review。
第三个坑：没有外部状态
很多系统看起来能跑几轮，但一旦跨天、跨任务、跨会话，就断了。
原因是状态只留在对话里，没有沉淀到外部系统。
长期 Loop 必须有外部记忆。
第四个坑：上下文越塞越多
很多人一看到 Agent 出错，就往 Prompt 里加规则。
最后 Prompt 变成一堵墙。
规则越来越多，但 Agent 反而更难抓重点。
更好的方式是：入口轻量化，知识结构化，任务相关内容按需加载。
第五个坑：权限给得太早、太大
Agent 可以执行，不代表它什么都应该执行。
读权限、写权限、部署权限、删除权限、生产环境权限，必须分层设计。
越是长期运行的 Loop，越要控制权限边界。
第六个坑：人完全退出
Loop Engineering 不是让工程师消失。
它只是把工程师的工作重心从“逐条指挥”转向“设计系统”。
你仍然要定义目标、设计边界、确认质量、处理异常、审查关键结果。
如果工程师完全不理解 Loop 产出的东西，只是机械接受结果，那不是效率提升，而是在积累理解债。
六Prompt、Context、Harness、Loop 到底是什么关系？
可以用一条线来串起来：
Prompt Engineering
解决：怎么表达任务
Context Engineering
解决：给模型看什么信息
Harness Engineering
解决：模型如何在工具、权限、状态、观测、验证中运行
Loop Engineering
解决：系统如何持续触发、执行、观察、修正、记忆和停止如果从包含关系看，我更建议这样理解：
Harness Engineering
├── Context Management
├── Tool Integration
├── Permission Control
├── Sandbox / Worktree
├── Memory / State
├── Observability / Tracing
├── Verification / Evaluation
├── Human-in-the-loop
└── Loop Engineering
├── Trigger
├── Plan
├── Act
├── Observe
├── Verify
├── Retry / Escalate
└── Stop Condition所以，Loop Engineering 不是要取代 Harness Engineering。
它更像是 Harness Engineering 在持续任务场景下的一种展开。
以前我们问的是：
Agent 能不能完成这一次任务？
现在我们开始问：
Agent 能不能在一个受控系统里，持续发现任务、推进任务、验证结果，并在必要时停下来？
这个问题，比写一条 Prompt 要复杂得多。
七真正重要的，还是工程能力
AI 技术每天都在变化。
今天是 Prompt Engineering，明天是 Context Engineering，后天是 Harness Engineering，现在又出现 Loop Engineering。
但你会发现，变化的是概念，不变的是工程问题。
不变的工程问题
系统边界要清楚。
状态要可追踪。
权限要可控制。
结果要可验证。
失败要可恢复。
流程要可观测。
知识要可维护。
人要知道什么时候介入。
这些东西不会因为模型能力变强而消失。
相反，模型越能行动，这些东西越重要。
因为当 AI 只是聊天时，错误最多影响一次回答。
但当 AI 能改代码、连系统、调工具、创建 PR、访问数据时，错误就会进入真实工程链路。
所以，AI Agent 时代真正考验程序员的地方，不是会不会让模型写一段代码。
而是你能不能设计一个系统，让模型在正确的上下文、正确的权限、正确的验证和正确的反馈里工作。
写代码，反而是最容易被模型接管的一步。
真正难的是：
定义问题
组织知识
设计流程
控制边界
验证结果
吸收反馈
持续改进这也是为什么我认为，Loop Engineering 的价值不在于它又提出了一个新名词。
它真正提醒我们的是：
Agent 工程的核心，正在从“如何问模型”，转向“如何设计一个能持续工作的系统”。
Prompt 是输入。
Context 是信息。
Harness 是运行环境。
Loop 是反馈闭环。
而工程师的价值，是把这些东西组织成一个可靠系统。
参考资料
Addy Osmani：Loop Engineering：https://addyosmani.com/blog/loop-engineering/ Addy Osmani：Plan-Act-Observe Loop：https://addyosmani.com/agentic-engineering/plan-act-observe/ OpenAI：Harness engineering: leveraging Codex in an agent-first world：https://openai.com/index/harness-engineering Anthropic：Demystifying evals for AI agents： https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
