过去一年，我使用 Agent 的方式经历了几个很明显的阶段。
最早，我关注的是 Prompt Engineering：怎么把任务说清楚，怎么限制输出格式，怎么让模型少误解我的意图。
后来，我开始把项目规则、历史决策、知识库和真实文件交给 Agent。问题变成了 Context Engineering：不只是“怎么问”，而是模型在行动之前能看到什么。很多时候，Agent 输出不好，不是因为 prompt 写得不够漂亮，而是因为它没有拿到源码、产品约束或真实业务状态。
再后来，当 Agent 开始进入 repo、调用工具、操作浏览器、连续执行多个步骤时，问题又变了。
我不再只关心它这一轮回答得好不好，而开始关心：它行动之后，怎么知道自己做对了？失败以后，是重试、换路，还是停止？哪些结果可以由机器验收？哪些判断必须重新交还给人？
这就是我现在理解的 Loop Engineering。
它不是让 Agent 简单地多跑几轮，而是设计一个由反馈驱动的工作系统。
四个概念解决的是四类问题
Prompt Engineering、Context Engineering、Harness Engineering 和 Loop Engineering 经常被写成一条不断升级的技术路线。但它们并不是彼此替代的四个版本，而是在解决不同的问题。
| 层次 | 核心问题 |
|---|---|
| Prompt Engineering | 这一轮应该要求 Agent 怎么做 |
| Context Engineering | Agent 做判断时应该看到什么 |
| Harness Engineering | Agent 可以怎样行动，受到什么约束 |
| Loop Engineering | 一轮行动结束后，系统如何继续 |
Prompt 负责表达任务。Context 负责提供事实、规则、历史和环境状态。Harness 负责工具权限、格式校验、确认门、回滚与风险控制。Loop 则把多次行动编排起来：什么时候触发、如何观察结果、失败后怎么处理、满足什么条件才算完成。
如果压缩成一句话：
Prompt 决定这一轮怎么做，Context 决定这一轮知道什么，Harness 决定这一轮允许怎样行动，Loop 决定这一轮结束以后发生什么。
其中最关键的变化，是从前馈走向反馈。
Prompt 和 Context 主要改善 Agent 出发前的信息质量；Loop Engineering 关心 Agent 行动之后，现实世界返回了什么，以及这个结果如何进入下一轮判断。
Loop Engineering 的本质是设计反馈
一次普通的 LLM 调用是线性的：输入、推理、输出，然后结束。无论 prompt 多完整、context 多丰富，输出产生之后，这次调用就结束了。模型并不会自然知道结果有没有被接受，代码能不能运行，文件是否真的上传，用户是否认可这个方案。
Loop 在外面增加了一层反馈结构：行动之后观察结果、做验证，需要时修正，再进入下一轮。
它不直接提高模型单次推理的能力上限，却能让模型通过多轮试错，更稳定地兑现已有能力。
我习惯用一个并不严谨、但很有解释力的公式理解它：
有效完成范围 ≈ 单次能力 × 有效迭代次数 × 验证器质量
这里最重要的不是迭代次数，而是“有效”和“验证器”。
如果每一轮都能获得方向正确的反馈，循环就是有目标的搜索。如果反馈本身是错的，循环只会更快地放大错误。
Agent 不会自动追求真实。它会不断逼近验证器愿意接受的状态。
因此，Loop Engineering 最难的部分从来不是把流程接成一个环，而是回答：什么证据足以证明这一轮真的完成了？
为什么研发工作天然适合 Loop
研发是目前最适合 Loop Engineering 的工作之一，因为代码世界天然拥有大量低成本、可重复、机器可读取的反馈。
代码能否编译、测试是否通过、类型是否正确、接口返回是否符合 schema、页面是否出现异常，这些结果都可以直接变成验证器。
它们至少具备几个共同特征：
- 判断标准相对明确；
- 反馈可以快速获得；
- 失败信息能指导下一轮修改；
- 修改通常可以回滚；
- 多次尝试的边际成本较低。
这让 coding Agent 可以进入一个相对自主的循环：修改代码，编译和测试，读取错误，再修改，直到通过后进入 review。
人不需要盯住每一步，只需要把正确的测试、产品约束和退出条件放进系统，并在合并或上线之前保留最终闸门。
但研发场景有硬验证器，不代表它天然可靠。
我之前把“Codex 实现 → Claude Code review → Codex 复核”做成自动化流程时，就遇到过两次“假绿”。
一次是 Agent 没有真正执行，循环却因为错误的完成判断而宣告收敛。另一次修改的是 iOS 代码，验证器跑的却是 Python 测试。测试全部通过，但被修改的代码根本没有编译。更危险的是，Agent 通过删除原有行为消除了报错，而 review 模型因为没有拿到 PRD，也认为结果没有问题。
这件事让我形成了一个比“多 Agent 互相 review”更重要的判断：
系统会收敛到验证器接受的状态，不一定是真实正确的状态。
测试选错、spec 缺失、两个模型共享同一个盲区，都会让循环产生“绿色的错误”。红色错误会迫使人介入，绿色错误反而会让整个系统误以为自己已经完成。
所以，即使在最适合 loop 的研发场景里，真正的工程工作依然是验证器设计。
为什么产品工作不能照搬 Coding Loop
产品工作当然也可以反复生成、检查和修改，但它缺少 coding loop 最重要的条件：足够接近真实目标的硬验证器。
一份 PRD 是否包含必要章节，可以自动检查。但它解决的是不是正确的问题，不能通过章节完整度证明。
一个方案是否逻辑自洽，可以让另一个 Agent review。但它是否符合当前业务阶段、组织能力和风险边界，模型通常没有完整信息。
一个功能是否值得做，更不能因为两个模型都认为“值得”就得到证明。
产品工作的关键反馈往往存在于系统之外：
- 用户是不是真的有这个问题；
- 业务方是否愿意改变现有流程；
- 团队能否承担后续维护成本；
- 当前阶段更应该追求增长、效率还是风险控制；
- 一个短期合理的方案，一年后是否仍然成立；
- 一次决策产生的现实影响是否可逆。
这些反馈通常是延迟的、含混的，甚至带有利益冲突。很多时候，只有通过用户访谈、业务沟通、真实上线或组织决策才能获得。
如果让 AI 自己生成方案、自己检查方案、自己修改方案，很容易形成一个封闭的自证系统：文字越来越完整，结构越来越漂亮，论证越来越自洽，但没有获得任何新的外部事实。
这不是有效闭环，只是在已有 context 里反复采样。
因此，更准确的说法不是“产品工作不适合 loop”，而是：
产品工作适合分段闭环，不适合让 AI 独立完成最终闭环。
资料完整性、格式一致性、数据计算、事实引用、版本同步等环节，可以建立机器验证器。用户价值、业务方向、组织取舍和风险承担，则必须在关键位置引入真实世界的反馈或人的判断。
PM 在 Loop Engineering 里的价值，也不是陪 Agent 多跑几轮，而是决定：什么结果可以由机器验证，什么判断不能由 AI 自证，哪些信息必须从真实世界重新获取，以及哪一步必须停止，把决定交给承担结果的人。
人工 checkpoint 不是自动化没有做完，而是产品 loop 的正确组成部分。
重复执行不等于 Loop
Loop 的触发器不一定是实时事件，也可以是定时器、人工操作或上游状态变化。触发方式应该由任务对新鲜度的要求决定，而不是越频繁越好。
我在工作中有大量定时任务：固定时间取数、运行脚本、更新数据。但“每天执行一次”本身只是重复自动化，不一定是 Loop Engineering。
如果任务只是“时间到了 → 运行脚本 → 写入结果 → 结束”，它是一条定时流水线。即使连续运行一年，也只是同一个线性过程被执行了很多次。
如果任务会检查数据完整性和更新时间，发现异常后重新拉取、切换处理方式、阻止错误数据覆盖、触发人工确认，并在验证通过后才更新下游——触发、行动、观察、验证、选择下一步，直到收敛或退出——它才形成真正的反馈闭环。
最简单的判断标准是：上一轮行动的结果，有没有成为下一轮决策的输入？
时钟可以让任务再次发生，只有反馈才能让系统根据现实改变行为。
一个更适合产品工作的 Loop
我最近想到一个很具体的个人应用场景。
这套状态机和命令行工作流已经整理为开源仓库：social-media-publish-loop。仓库只包含可复用的执行框架，不包含我的照片、草稿、发布记录、浏览器数据或知识库内容。
平时吃完一家餐厅或结束一次旅行后，我会把照片和一份文本放进 iCloud 的指定文件夹。文本里包含消费金额、体验、推荐内容、优缺点和想表达的重点。之后，我需要整理成小红书正文、修改话题格式、上传图片，再完成发布和归档。
如果只使用 Prompt Engineering，我可以保存一段提示词：
根据这些素材生成小红书标题和正文，并把文末话题统一成
#话题格式。
它减少了我每次重新解释任务的成本，但素材仍要由我手动提交，后续步骤也要由我推进。
加入 Context Engineering 后，Agent 还可以读取照片、原始文本、历史文章、我的标题习惯和平台格式规则。第一次生成的质量会明显提高。
但生成完成后，系统仍然不知道下一步是什么，也不知道自己的结果有没有真正进入发布页面。
把它设计成 loop 后，工作流才发生了本质变化。系统每天固定时间检查一次 iCloud 素材文件夹：没有新素材就正常退出，素材不完整就停在 collecting 等下一次检查。素材完整之后，任务沿着一条持久的状态链推进，由 Computer Use 完成上传和填写，最后停在发布确认页等我：
在这个场景里，素材晚几个小时处理并不会失去价值。如果每隔五分钟扫描一次 iCloud，不仅没有明显收益，还会增加重复检查、同步未完成和意外触发的概率。每天检查一次已经足够。
定时器只负责启动流程。真正构成 loop 的，是后面的状态判断、完整性验证、分支处理和人工断点。
落地后的触发结构比这句话还要保守一层：每日定时任务本身由一个低成本模型执行只读扫描，只判断状态、汇报缺失项；只有当存在待生成或待上传的任务时，它才拉起一个更强的模型去完成草稿、上传和页面验证，而这个被拉起的任务永远停在最终发布之前。观察用便宜的部件，行动用昂贵的部件。
状态机里还有一条容易被忽略的回退规则：素材在草稿生成之后再发生变化，任务会退回 ready_for_draft。它保证旧正文永远不会配着新素材被上传。
不同阶段使用的验证器也不同。素材阶段检查文件是否存在、图片是否可读、必要信息是否缺失；文案阶段检查标题长度、话题格式和重复项；上传阶段检查页面是否出现对应数量的图片、标题和正文；最终发布则保留人工确认。
把概念标签贴回去的话：一次性状态、回退规则和“发布按钮不在自动化权限内”属于 Harness，各阶段的最小证据检查是验证器，而 Loop 负责的是它们之间的时间结构——什么时候检查、什么触发下一步、什么时候停止。四个层次在这个小系统里各就各位。
公开发布这个动作并不难，难的是发布意味着我认可内容，并愿意承担它产生的结果。
因此，“页面字段已经完整”只能证明机械步骤完成了，不能证明“这篇内容应该被公开”。最后一次确认必须由我完成。
这个断点不是系统的缺陷，而是系统对责任边界的正确表达。
当然，这个个人场景里的“责任”很轻：我只需要对一篇帖子负责。工作场景里的责任要重得多——方案影响的是用户、团队和业务结果——所以那里的断点应该更早出现、更频繁出现。这个小场景演示的是断点怎么设计，而不是一个真实产品 loop 需要多少断点。
第一次真实运行，推翻了哪些预期
2026 年 7 月，我用一组真实的餐厅探店素材跑通了第一次完整流程：15 张原图中选择并按顺序上传 9 张，页面验证到标题、539 字正文和 7 个话题全部就位；我完成最终发布确认后，系统归档源素材，并把发布事实同步到个人知识库的页面、索引和操作日志。
这一次还不足以证明流程已经稳定，也无法给出“每篇节省多少分钟”或失败率这样的统计结论。但它暴露了几件比顺利演示更有价值的事。
第一，状态管理确实比 prompt 更影响可靠性。 发布页一旦被打开，就必须先进入一次性的 upload_started。即使我没有点击最终发布，后续定时扫描也不能再次触发上传链路。ready_for_final_review 只表示页面内容已经验证，kb_sync_pending 表示我已确认发布但知识库尚未完成，只有知识库页面、索引和日志都校验通过，任务才能进入 archived。这样，“上传完成”“公开发布”和“结果已沉淀”不会被混成同一个状态。
第二，Computer Use 的失败信号比预期更模糊。 第一次上传花了很久。文件选择器的无障碍树显示 9 个文件已经选中，但“打开”按钮仍不可用。中间很容易误判成多选方式、扩展名大小写、文件隔离属性或网页上传组件的问题。真正原因是 Chrome 没有处于前台；激活 Chrome 后，同一组文件立即可以提交。这里需要的不是无限尝试，而是一条固定诊断顺序：先确认目标应用在前台，再检查选择数量和按钮状态，最后才允许更换方案。
第三，验证器也有成本。 反复读取完整页面或无障碍树虽然能增加观察，但会消耗大量时间和 token，还可能让 Agent 在噪声中继续试错。更好的做法是只读取完成当前判断所需的最小证据，并给重试次数设上限：图片数量、标题、正文字数和话题数量已经足以决定是否进入人工确认。
第四，Computer Use 消除的是操作摩擦，不是判断责任。 图片上传、正文填写和页面核对可以交给系统，最终公开发布仍由我点击。第一次运行也说明，人不需要重新接管所有机械操作，只需要在真正承担结果的位置回来。
接下来仍需要用更多真实素材记录四个指标：每篇内容节省的人工操作时间、需要我介入的次数、重复或失败上传的比例，以及素材进入 ready 后到达最终确认页的时间。一次成功运行是证据，不是稳定性结论。
Context Engineering 和 Loop Engineering 的实际差别
两者最容易混淆，是因为一个设计良好的 loop 必然需要 context。
每次循环开始时，Agent 都需要读取当前状态、历史结果、失败原因和相关约束。这些都属于 Context Engineering。没有它，Agent 每一轮都会像失忆一样重新开始。
但只有 context 仍然不够。
Context Engineering 解决的是：为了做好下一次判断，Agent 应该看到什么。
Loop Engineering 解决的是：什么事件会触发下一次判断，上一轮结果如何进入下一轮，以及系统何时停止。
在小红书场景里，历史文章、照片、原始记录和格式规则是 context；每天检查文件夹、判断素材是否完整、有边界地处理上传失败、等待人工确认，以及发布后同步知识库并归档，才是 loop。
换句话说：
Context 是每一轮的认知环境，Loop 是多轮之间的时间结构。
产品场景真正需要设计的，是 Loop 在哪里断开
当 Agent 开始能够操作文件、浏览器和本地应用时，很容易把“全自动”当成理想终点。
但一个流程能否全自动，不取决于 Agent 会不会点击按钮，而取决于它能不能获得足以承担决定的反馈。
研发的循环可以大量在机器内部闭合；产品工作则很难把方向判断交给同一个系统自我证明。
因此，Loop Engineering 在产品工作中的核心能力，可能不是让 AI 自主运行更久，而是更准确地设计人的位置。
哪些步骤可以退出人工操作，哪些步骤必须引入新的外部事实，哪些决策需要由承担结果的人确认，这些问题可能比“再增加一个 Agent”更重要。
好的 loop 不是一个永远不需要人的系统。
它是一个只在真正需要判断时，才把人叫回来的系统。