为什么有这篇
最近我在看Agent Loop和Loop Engineering。
一开始我以为它只是“让 AI 多跑几轮”。但看了一些实践和讨论后，我的理解变了：Loop 不是多调用几次模型，而是把 Agent 的工作方式从“人一步步提示”，变成“系统自己持续推进”。
这篇先当成学习资料收集，不是最终结论。我的目标是把几个关键观点整理清楚：它是什么，为什么现在开始重要，和Prompt / Context / Harness的关系是什么，以及我自己可以怎么用。
结论先行
我现在的判断是：
Loop Engineering不是 Prompt 技巧，而是一套 Agent 持续工作的控制系统。- 它建立在
Prompt、Context、Harness之上，解决的是“做完一步之后，系统怎么继续推进”。 - 一个可用的 Loop 至少要有目标、状态、反馈、验证、记忆和停止条件。
- 人不是退出循环，而是从“每一步都提示”变成“在关键节点确认”。
- 现阶段最适合先落地的，不是超级自动化，而是需求、编码、测试这些明确边界的小循环。
这个概念解决什么问题
以前我们和 AI 协作，主要是人驱动。
我提需求 -> AI 回答 -> 我发现问题 -> 我再提示 -> AI 再修改这套方式能用，但有几个问题：
- 人一直在流程里，容易变成瓶颈。
- 任务一长，就需要反复补上下文。
- AI 做完一步后，不知道下一步该干什么。
- AI 不知道什么时候该继续，什么时候该停。
- 失败后的修正逻辑，大部分还是人来驱动。
Loop Engineering解决的是这个问题：
❝
能不能设计一套系统，让 Agent 在目标、反馈、验证和停止条件之间自己循环起来？
❞
它的最小形态大概是：
输入目标 -> 读取状态 -> 选择下一步动作 -> 执行动作 -> 收集反馈 -> 验证结果 -> 更新记忆 -> 判断继续、停止或请求人确认这个东西不是简单自动化脚本。
脚本更像固定流程；Loop 会根据反馈调整下一步。
几个大佬的定义怎么理解
Boris Cherny：我不再提示 Claude，我写 loops
Boris Cherny 有一句话很关键：
❝
I no longer prompt Claude directly. My job is to write loops.
❞
我的理解是：开发者的工作从“给 Agent 下每一步指令”，变成“设计让 Agent 自己下下一步指令的系统”。
比如自动维护 PR：
发现 PR 有评论 -> 读取评论 -> 修改代码 -> 跑测试 -> 如果失败继续修 -> 如果通过输出说明这里人不是每步都插手，而是定义规则、权限和停止条件。
Peter Steinberger：不要给 Agent 写 Prompt，要设计给 Agent 写 Prompt 的 Loop
Peter Steinberger 的说法更直接：
❝
You should not be prompting your coding agent anymore. You should be designing the loop that prompts your agent.
❞
这句话对我启发很大。
以前我关注“这句 prompt 怎么写得更好”。现在要关注的是：
- 谁来触发 Agent？
- Agent 每轮看哪些信息？
- 结果怎么验证？
- 失败怎么处理？
- 什么情况下必须停下来问人？
这已经不是 Prompt Engineering，而是工作流设计。
Addy Osmani：Loop Engineering 是让系统替你提示 Agent
Addy Osmani 的定义比较系统：
❝
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
❞
他把两类问题区分得很清楚。
| Prompt Engineering | Loop Engineering |
|---|---|
| 我该说什么，才能获得最佳输出？ | 我该构建什么系统，让 Agent 自主发现、执行、验证并记住工作？ |
| 人每一步都提示 | 系统循环驱动，人在关键点确认 |
| 关注单次输出 | 关注持续推进 |
我觉得这里最值得记的是六个要素：
| 要素 | 要回答的问题 |
|---|---|
| 目标 | 这轮循环要完成什么？ |
| 触发 | 什么情况下启动？ |
| 执行 | Agent 每轮做什么？ |
| 验证 | 怎么判断做对了？ |
| 记忆 | 什么经验和状态要留下来？ |
| 退出 | 什么时候停止或升级给人？ |
为什么是 Prompt -> Context -> Harness -> Loop
我现在更愿意把 AI 开发分成四层。
Prompt -> Context -> Harness -> Loop| 层次 | 解决的问题 | 我的理解 |
|---|---|---|
Prompt | 怎么表达任务 | 把意图说清楚 |
Context | 怎么提供背景 | 让 Agent 不要瞎猜 |
Harness | 怎么让 Agent 能安全做事 | 工具、权限、校验、工作区 |
Loop | 怎么让 Agent 持续推进 | 目标、反馈、记忆、停止条件 |
这个顺序很重要。
如果没有 Context，Agent 不知道背景。
如果没有 Harness，Agent 没有工具和边界。
如果没有 Loop，Agent 只能被动等人下一步指令。
所以 Loop 不是替代前面几层，而是建立在前面几层之上。
吴恩达的三层闭环，对我很有启发
Andrew Ng 把反馈循环按时间拆成三层，我觉得很适合用来判断人和 AI 的分工。
分钟级：Agent 自己处理
这类反馈很快，可以机器验证。
- 编译是否通过
- 单测是否通过
- 页面是否报错
- 接口返回是否符合 schema
- 文档格式是否符合要求
这类事情不应该每一步都问人。
小时级：人确认关键方向
这类事情需要人的判断。
- 产品方向是否对
- UI 流程是否合理
- 功能优先级怎么排
- 方案复杂度是否可接受
- 这个需求第一版做到什么程度
这就是人在回路的位置。
不是人一直盯着，而是在关键节点确认。
天/周级：真实用户反馈
这类反馈来自真实环境。
- 用户是否真的使用
- 指标有没有变化
- 功能是否解决真实问题
- 是否值得继续投入
这层不能靠 Agent 自己闭环。
所以三层关系可以这么看：
分钟级：Agent 自修复小时级：人确认关键决策天/周级：用户反馈修正方向我现在最想先落地的 Loop
现阶段我不想一上来做“超级自动化”。
我更想先把几个小循环跑稳。
1. 需求侧 Loop
很多需求进不来，不是编码慢，而是需求太薄。
一句话需求 / 用户反馈 -> Agent 扩展成产品说明 -> Agent 生成可交互原型 -> Agent 自评审并修正 -> 输出关键决策点 -> 人确认 -> 进入设计和开发这个 Loop 的价值是：先把需求变厚，再让后面的 SDD / Harness 去执行。
2. 编码执行 Loop
这个更适合在SPEC稳定后跑。
读取 SPEC -> 编码 -> 跑测试 / lint / 编译 -> 根据错误修复 -> 通过后提交结果 -> 连续失败则升级给人这里重点不是让 Agent 发挥，而是让它按约束快速执行。
3. 维护类 Routine
这类适合长期运行。
定时扫描问题 -> 判断是否低风险 -> 自动修复 -> 验证 -> 生成记录 -> 高风险升级给人比如失败测试、文档更新、简单 bug、接口变更同步。
现在需要警惕什么
Loop 听起来很美，但我现在不太相信“一步到位的全自动”。
几个风险要先写清楚。
1. 无限循环
Agent 一直修，一直失败，一直重试，成本会失控。
所以必须有：
- 最大步骤数
- 超时时间
- 连续失败上限
- 无进展检测
2. 错误被放大
如果目标本身错了，Loop 只会更稳定地跑向错误方向。
所以需求侧的关键决策，必须有人确认。
3. 验证不可靠
Agent 自己说“完成了”不算。
要尽量用：
- 测试
- 编译
- lint
- schema
- 截图
- 人工确认
4. 过度自动化
不是所有事情都应该自动。
我的原则是：
机器能验证的，交给 Agent 循环人类有上下文优势的，交给人确认高风险动作，必须停下来一个可复用的 Loop 模板
我后面设计 Loop 时，可能会用这个模板。
## Loop 名称这个循环解决什么问题？## 目标最终要推进到什么状态？## 输入需要哪些材料？需求、代码、文档、测试结果、用户反馈？## 状态要记录哪些状态？已完成、失败原因、待确认问题？## 触发条件人工触发、定时触发、PR 评论、CI 失败，还是用户反馈？## 执行动作Agent 每轮能做什么？读文档、改代码、跑测试、生成原型？## 验证机制怎么判断做对了？测试、指标、评审、人确认？## 停止条件目标达成、连续失败、成本超限、高风险决策？## 人类确认点哪些节点必须交给人？## 记忆沉淀结束后要记录什么？这个模板的重点不是形式，而是逼自己先想清楚：目标、验证、停止和人类确认点。
小结
我现在对Loop Engineering的阶段性理解是：
❝
它不是写更好的 Prompt，而是设计一个让 Agent 围绕目标持续执行、验证、修正、记忆并停止的工作系统。
❞
如果说Harness解决的是“Agent 怎么安全地做一次事”，那Loop解决的是“Agent 怎么持续把一类事推进完”。
我现在不会把它理解成最终答案。
更合理的做法是：先从需求侧、执行侧、维护侧这些小 Loop 开始，把验证和停止条件做扎实，再慢慢扩大自动化范围。
关键概念和信息
| 概念 | 我的理解 | 需要注意 |
|---|---|---|
Prompt | 一次任务表达 | 只能解决怎么说清楚 |
Context | 背景和状态 | 防止 Agent 瞎猜 |
Harness | 工具、权限、校验和工作区 | 让 Agent 能安全执行 |
Loop | 目标、反馈、验证、记忆、停止条件组成的循环 | 不是多调用几次模型 |
Routine | 可长期运行的 Loop | 适合维护、监控、周期任务 |
Stop Hooks | 停止或升级规则 | 控制成本和风险 |
可以收藏的 5 个判断：
Prompt是一次输入，Loop是持续推进机制。- 没有验证机制的 Loop，很容易制造“形式完整但方向错误”的结果。
- 人不应该盯每一步，但必须确认关键决策点。
- 需求侧的问题，不能只靠更强的编码模型解决。
- Agent 越能循环执行，人越要把目标、边界和停止条件定义清楚。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
