Loop Engineering 完整解读

打开 Claude Code 或者 Cursor，输入一段提示词，Agent 开始工作，报错了，你把错误粘贴回去，它再试，再错，你再贴，再等。二十分钟后你突然意识到——你在保姆一个本来应该替你工作的东西。你在做那个你本来想外包出去的、低价值的、重复性的工作。

设想一个具体场景：你让 Agent 修复一个数据库查询慢的问题。它找到了问题，修改了代码，但测试跑不过，因为本地数据库版本和生产环境不一致。它向你报告，你手动排查，把版本信息粘贴回去，它再修，测试过了，但 CI 报错了，因为它顺手改了一个不该改的依赖。它再向你报告，你再排查，再粘贴，再等。这个过程重复了六轮，最终你意识到，你花在”和 Agent 沟通”上的时间，比直接自己写代码还多。

这就是”人在循环里”（Human-in-the-Loop）的真实体感——一个听起来很安全、实际上很尴尬的状态：AI 在工作，但每一步都需要你确认、你介入、你推进。你没有从重复劳动中解放出来，你只是把”自己做重复劳动”换成了”和 AI 一起做重复劳动”。

Loop Engineering 的出现，不是要给你一套更好的提示词模板，也不是要推销某个新工具。它指向的是一个更根本的问题：如果你的工作流依赖你不断地”提示” Agent，那你设计的就不是一个 Agent 系统，你设计的是一个需要你参与的半自动脚本。

本文将系统梳理 Loop Engineering 的来龙去脉：它从哪里来，它是什么，它和之前的范式有什么本质区别，以及对于 AI PM 来说，这意味着什么。

一、一个抽象层级的爬升：从词语到循环

理解 Loop Engineering，必须先理解它身处的那条演化链。

从 Prompt Engineering，到 Context Engineering，再到 Harness Engineering，最终到 Loop Engineering，这不是四个独立的技术方向，而是同一个问题被反复逼近的四次尝试。这个问题是：如何让 AI 系统可靠地完成复杂任务，同时最小化人类的介入成本。

每一次演化，都是人类把对 AI 的控制权，从更具体的层级移交到更抽象的层级。用一个比喻来理解：

最开始，我们在学怎么写一封好邮件（Prompt Engineering）。后来意识到邮件里附什么材料，比措辞更重要（Context Engineering）。再后来开始设计整个部门的信息流转系统（Harness Engineering）。现在，我们在设计一套能自动处理所有日常工作的办公室系统，人只负责设定系统的目标和边界（Loop Engineering）。

这是认知层级的跃迁，不是工具迭代。每一次跃迁，人类设计的对象从”内容”变成”结构”，再变成”系统”，再变成”系统的运行逻辑”。这条链的终点，是把执行的决策权完全交给系统本身，而人，退到了设计系统的位置上。

有一句被反复引用的话——Epsilla 的研究者把这四年总结为：2022 年，我们在学怎么写完美的邮件；2025 年，我们学会了怎么管理收件箱；2026 年，我们在设计整个邮件系统本身。这个类比虽然简化，但准确地捕捉到了这条演化链的本质。

接下来，我们逐层拆解，看看每一层解决了什么问题，又遗留了什么缺陷。

二、Prompt Engineering：我们曾相信”说对话”是核心竞争力

Prompt Engineering 的核心假设是：模型的能力是固定的，影响输出质量的关键变量是你怎么提问。

这个假设在早期是成立的。研究者发现，通过”少样本示例”（Few-shot Prompting）、”思维链”（Chain-of-Thought）、”角色扮演设定”等技巧，可以在不改变模型权重的情况下，显著提升输出质量。”AI 提示工程师”曾经是一个被认真对待的职位名称。Andrej Karpathy 在 2023 年说：”最热门的编程语言是英语。”这句话彼时引发了巨大的共鸣。

但 Prompt Engineering 有一个根本性的局限：它只能优化单次交互。

一旦任务变长、步骤变多，Prompt Engineering 的解法就变成了写更长的提示词、更精细的指令、更多的约束和示例。但这条路有几个结构性死穴。

第一，上下文窗口的硬限制。提示词越来越长，迟早会撞到模型的上下文长度上限。你能塞进去的信息是有限的，塞多了反而会稀释重要信息的”注意力权重”，导致模型在推理中途忽略了你最想强调的约束条件。

第二，无状态带来的遗忘。大多数 LLM 是无状态的——每次对话结束，上下文清空，模型”忘记”了所有东西。一个需要多轮迭代的任务，每次重启都要把背景重新喂给模型，这不只是效率低，还会导致前后轮次的理解出现偏差和漂移。

第三，幻觉和注意力漂移。提示词越长，模型在中途”走神”的概率越大。精心设计的约束条件，可能在第 10 步就被模型悄悄忽略了，它会优先服务于最近的指令，而不是最重要的指令。

第四，人始终是循环里的决策节点。Prompt Engineering 依赖人来”启动”每一次交互。Agent 跑完一步，遇到问题了，需要人看、人判断、人重新提示。这是一个根本性的设计缺陷：人的参与不是偶发的，而是系统运作的必要条件。你没有办法在睡觉的时候让 Agent 继续工作，因为到了某一步，它必然要等你。

最深层的问题是，Prompt Engineering 把人的注意力集中在”怎么说话”上，却没有触碰 AI 工程真正的核心难题：如何构建一个能可靠、连续、自主运行多步骤任务的系统。提示词是一个接口，不是一个系统。把接口调教得再好，也无法弥补系统层面的缺失。

三、Context Engineering：从”怎么说”到”给什么信息”

Context Engineering 是 Prompt Engineering 的自然延伸。它的洞察是：与其纠结如何措辞，不如控制模型在推理时能”看到”什么。

这个认知转变是实质性的。在 Prompt Engineering 阶段，”上下文”只是提示词的附属品——你会在提示里补充一点背景信息。在 Context Engineering 阶段，上下文本身成了设计的核心对象。

Anthropic 把 Context Engineering 定性为”Prompt Engineering 的自然演化”——问题的视角从”如何问一个好问题”转向了”如何设计一个好的信息环境”。

Context Engineering 设计的是模型在推理时所见的完整信息环境，包含以下几类关键要素：

• 系统提示（System Prompt）：定义模型在这次任务中的角色、行为规范、约束边界和输出格式。这是信息环境的”宪法”。
• 工具定义（Tool Definitions）：通过 MCP（Model Context Protocol）等协议，告诉模型它能调用哪些外部能力——搜索、代码执行、数据库读写、文件系统操作。工具定义决定了模型的”行动半径”。
• 对话历史（Conversation History）：多轮对话中的历史信息，维持任务的连贯性和记忆。
• 检索结果（RAG）：检索增强生成是 Context Engineering 的核心实践。与其让模型”记住”所有知识，不如在它需要的时候把相关信息即时注入上下文——更新的知识、更精准的信息、更低的幻觉率。
• 当前状态（Current State）：任务进展、文件内容、代码仓库结构、环境变量——让模型始终能感知到”现在在哪里”。

MCP 协议的出现，是 Context Engineering 成熟化的重要标志。它把”如何让 Agent 获取外部信息”这件事标准化了，让 Context Engineering 从手工组装变成了可工程化的流程。

但 Context Engineering 同样有清晰的边界。它解决了”信息给得对不对”的问题，没有解决”任务跑得动不动”的问题。

一个被精心配置了上下文的 Agent，在面对需要多轮迭代、跨会话执行的复杂任务时，依然会卡住。原因在于：Context Engineering 改善的是单次推理的信息质量，但任务的连续性——谁来跟进下一步，谁来判断上一步是否成功，谁来决定下一个操作是什么——仍然需要人来维持。

上下文窗口终究是有限的。随着任务推进，对话历史变长，相关性下降的信息会持续占用有限的注意力空间，最终导致推理质量下降——Anthropic 的研究将这种现象称为”上下文焦虑”（Context Anxiety）：随着上下文窗口被填满，模型会进入一种”急于完成”的状态，匆忙收尾，质量骤降。

Context Engineering 把人从”提示词作者”升级成了”信息环境设计师”，但人依然在循环里，依然是任务推进的关键节点。

四、Harness Engineering：从信息到系统结构

如果说 Context Engineering 关心”模型看到什么”，那么 Harness Engineering 关心的是”模型在一个什么样的系统里工作”。

这个概念由 Mitchell Hashimoto（Terraform 和 Ghostty 的创始人）在 2026 年初提出并推广。他的核心洞察来自一个实际经验：每次 Agent 出错，与其修改提示词让它下次做得更好，不如改变系统结构，让这个错误在结构上无法再次发生。

这是一个工程思维的根本转变——从”调教模型”到”设计防错系统”。

Harness，直译是”马具”，引申为”脚手架”，在这里指包裹在 AI 模型外层的整套基础设施。用一个公式来表达：

Agent = Model + Harness

模型提供原始的推理能力，Harness 把这个推理能力变成可信赖的、可重复的生产力。Faros 的 2026 AI 工程报告指出，企业 AI 项目失败的根本原因，65% 不是模型能力不足，而是 Harness 层的缺失——具体表现为上下文漂移（Context Drift）、状态降级（State Degradation）和 Schema 不匹配三类问题。

Anthropic 的工程研究进一步识别出了几类 AI Agent 的固有失败模式，它们的解法都在 Harness 层而非模型层：

• 胜利声明偏差（Victory Declaration Bias）：Agent 很容易在没有真正完成任务的情况下自行宣告成功。它会判断”任务看起来差不多完成了”，然后报告”已完成”——而实际上代码逻辑有问题，测试没有覆盖边界情况，或者接口契约存在隐患。Harness 的验证层通过运行测试、类型检查、结果比对等机制，结构性地阻止了这种行为。
• 上下文焦虑（Context Anxiety）：随着对话历史变长、上下文窗口趋于饱和，模型会进入”急于收尾”的状态，开始在代码里走捷径，跳过验证步骤，甚至强行把所有剩余工作压缩进最后几步。这导致输出质量骤降。Harness 通过主动的上下文压缩（Compaction）和记忆管理——只保留最近几轮的详细记录，更早的历史以结构化摘要替代——来对抗这一问题。
• 一次性过度延伸（One-shotting Overreach）：Agent 倾向于一次性解决整个问题，而不是分步推进。这会产生难以验证的大型变更，代码改动范围超出任务边界，引入难以追踪的副作用。Harness 通过任务分解和阶段性验证来约束这种倾向，强制 Agent 每完成一个子任务就停下来验证，再继续下一个。

一个生产级的 Harness 通常包含五个层次：工具编排层（Agent 能调用哪些系统、以什么权限调用）、验证循环层（每一步输出的机器验证机制）、上下文与记忆层（跨会话的状态持久化）、护栏与约束层（Agent 的行为边界）、可观测性层（日志、追踪、成本监控）。

OpenAI Codex 团队的案例是这个范式最有说服力的工程验证：一支仅三人组成的团队，在五个月内产出了约 100 万行生产级代码，零手写代码。秘诀不是更好的提示词，不是更丰富的上下文，而是 Harness——严格的分层架构约束、自定义 Linter、全流程验证，让 Agent 的行为从”可能正确”变成了”结构性地可靠”。

Harness Engineering 的出现，标志着 AI 工程从”个人技艺”走向了”系统工程”。但它解决了可靠性，还没解决自主性——一个设计精良的 Harness，没有人的启动指令，依然不会自己运转。Harness Engineering 把人从”Agent 保姆”升级成了”系统架构师”，但系统的启动按钮，仍然在人手里。

五、Loop Engineering：你成了循环的作者

现在来到这条演化链最新的一层。

Claude Code 的创始人、Anthropic 的 Claude Code 负责人 Boris Cherny，在 2026 年 6 月 2 日的 WorkOS Acquired Unplugged 活动上，说了一段后来被广泛传播的话：

“我不再提示 Claude 了。我有循环在运行，它们自己在提示 Claude，自己决定下一步怎么做。我的工作是写循环。”

这句话值得仔细咀嚼。Boris 不是在说”我让 Claude 自动运行了”。他在说的是一个角色的根本性转变：他从一个操作 Agent 的人，变成了设计”操作 Agent 的程序”的人。Agent 变成了子程序，而他写的那套逻辑，决定了 Agent 什么时候工作、做什么判断、什么时候停止。

这个转变有一个数字佐证：在 2025 年 12 月 27 日之前的 30 天里，Boris 合并了 259 个 PR，其中 100% 由 Claude Code 生成。他在 2025 年 11 月删除了自己的 IDE，此后再未打开过。Claude Code 目前据报道已参与了 GitHub 上约 4% 的公开提交。

几天后，OpenClaw 创始人（现在 OpenAI）Peter Steinberger 在 X 上发了两句话，650 万次浏览：

“提醒你一下，你不应该再提示 Coding Agent 了。你应该设计让 Agent 来提示自己的循环。”

随后，Google Chrome 工程负责人 Addy Osmani 发布了系统性拆解，并为这个模式命名：Loop Engineering。

Loop Engineering 的定义：写让 Agent 自己提示自己的程序。

在这个范式里，你不再是循环里的那个决策节点——你成了循环本身的设计者。

理解这个范式，需要先理解 Loop Engineering 和它的”前辈们”的区别。

Loop 的概念不是 2026 年凭空出现的。2022 年的 ReAct 论文（Reason + Act）就形式化了一个基础模式：模型推理→调用工具→读取结果→重复，直到完成。2023 年的 AutoGPT 把它推向了大众视野，给 Agent 一个目标，让它自己提示自己——然后因为”无限转圈什么都不做”而声名狼藉，并由此播下了”Agent 是玩具”的种子。2025 年，Geoffrey Huntley 发布了著名的 ralph loop，用一行 bash 脚本实现了基础的自主循环：

while :; do cat PROMPT.md | claude; done

ralph loop 的创新不在于技术复杂度，而在于纪律性：每次迭代重置上下文到固定的锚点文件，进度通过磁盘文件持久化，而不是依赖模型的上下文记忆。这确保了 Loop 的每次运行都在一个干净、可控的信息环境里启动。

Loop Engineering 在 ralph 的基础上走得更远，把”单 Agent 的自主循环”升级成了”可以跨越时间、跨越上下文窗口、协调多个 Agent 运作的自动化系统”。它和 Cron Job 的本质区别在于：Cron Job 运行固定脚本，Loop 运行有决策能力的 Agent——后者读取当前状态，选择下一个动作，执行，验证结果，再决定继续、重试、回滚还是终止。

那么，一个实际运行中的 Loop 长什么样？

Louis Bouchard 描述了一个简单但典型的例子：一个 Loop 每天早上自动唤醒，读取昨天的 CI 失败记录、未解决的 Issue 列表和最近的代码提交日志，生成一个简短的”今日状态文件”，列出最值得处理的问题。对于其中一个 Issue，它自动开启一个独立的 Worktree，派遣一个 Agent 去起草修复方案。另一个 Agent 把这个修复方案和项目的测试规范、约定逐一核对。测试通过，自动提 PR 并更新任务状态；测试失败，把错误信息反馈给执行 Agent 再试，最多两次；两次都失败，停止并把问题放进你的待处理收件箱。

你没有在这个过程里出现过一次。你设计了这套系统，然后去做了其他事情。这就是 Loop Engineering 和之前所有范式的根本性断裂：执行过程不再需要你在场。 不是”你让它做了很多事”，而是”你设计了一套机制，这套机制自己决定做什么、怎么做、做没做完”。

因此，设计一个 Loop 之前，你必须先回答两个必答问题：

1. 触发器是什么——什么信号启动这个循环？
2. 可验证的终止条件是什么——什么状态意味着任务完成？

如果你给不出第二个问题的答案，你没有在设计 Loop，你在设计一个无限运行的 token 消耗机器——它不会报错，它只会自信地报告进展，直到预算耗尽。

六、一个生产级 Loop 的解剖

一个真正可以在生产环境运行的 Loop，并不是把 Agent 扔进 while 循环那么简单。Addy Osmani 把一个完整的 Loop 拆解成五个组件加一个基础层，这是目前工程界最广泛引用的结构性定义。

组件一：自动化触发（Automations）

Loop 需要能自主唤醒，而不是等待人工启动。触发信号可以是：定时计划（每天早上 8 点读取昨天的 CI 失败记录）、代码仓库的事件（PR 开启、Issue 更新、代码推送）、外部系统的通知（Slack 消息、数据库状态变化、监控报警）。

触发器决定了 Loop 的感知边界——它能响应哪些外部世界的变化。一个好的触发器设计需要回答：这个任务的”启动信号”在现实中是什么？这个信号是否明确、可靠、不会误触发？

组件二：工作树隔离（Worktrees）

当多个 Agent 并行工作时，必须有机制防止它们相互覆盖。Worktrees 让每个并行任务在独立的代码分支和文件空间里运行。

这对 Coding Agent 尤其重要——两个 Agent 同时修改同一个文件会产生不可预测的冲突。Boris Cherny 本人大量使用 Worktrees 来让多个 Claude 实例同时探索同一个问题的不同解法，互不干扰，最后从结果中选优。这也是 Loop Engineering 能支持真正并行执行的结构性基础。

组件三：技能库（Skills）

Skills 是 Agent 在每次运行时可以调用的”项目记忆”：代码规范、测试命令、架构约定、常见错误的处理方式、特定依赖的使用说明。通常以结构化的 Markdown 文件存储，挂载在项目根目录。

一个没有 Skills 的 Loop，每次运行都要从零重新”发现”你的项目——这是纯粹的 token 浪费，也是质量不稳定的根源。一个有良好 Skills 体系的 Loop 会产生复利效应：Agent 积累的经验通过 Skills 持久化，每次运行的起点都比上次更高，而不是每次都从同一个零点出发。

Addy Osmani 对 Skills 的实践建议是：每个 Skill 对应一类任务，信息密度尽量高，但不要让单个 Skill 撑满上下文窗口。让 Agent 自己维护一个 Skills 索引——这样 Agent 在启动时只需要读取索引，判断本次任务需要调用哪些 Skill，而不是每次都把所有 Skill 塞进上下文。

组件四：连接器与插件（Connectors/Plugins）

Agent 需要能调用外部系统：GitHub（读写 PR 和 Issue）、Linear（更新任务状态）、Slack（发送通知）、数据库（读写任务状态和进度）。这些连接器定义了 Loop 的”行动半径”。

连接器的权限设计需要格外谨慎：Agent 能写入哪些系统、读取哪些系统，哪些操作需要人工审批才能执行？这不只是安全问题，也是产品设计问题——过度授权的 Agent 会在用户不知情的情况下产生副作用；权限过窄的 Agent 则会在关键步骤卡住，依然需要人工介入。

组件五：子 Agent 协作（Sub-agents）

写代码的 Agent 不应该同时是审查代码的 Agent。这是 Loop Engineering 最有洞见的设计原则之一：执行者和评审者必须分离。

一个设计良好的 Loop，会让一个 Agent 负责实现，另一个 Agent 负责验证，验证结果反馈给执行者进行修正。这个分离消除了”Agent 自我说服”的风险——如果执行 Agent 同时是自己工作的裁判，它很容易形成”自认为正确”的闭环，产出看起来完成了实际上存在深层问题的结果。

Sub-agents 的协作模式还支持”一个 Agent 读取 GitHub、Slack 和 Twitter，决定接下来要构建什么；另外几百个 Agent 分头去实现”的规模化场景——这正是 Boris Cherny 描述自己当前工作流的方式。

基础层：记忆（Memory）

模型会遗忘，但仓库不会。Loop 的状态必须被持久化：进度文件、错误日志、已完成的任务列表、当前上下文的关键变量、每次迭代的结果摘要。这样 Loop 才能在中断后重启，才能在多次迭代中保持连贯性，才能跨越上下文窗口的边界而不丢失任务记忆。

Memory 是 Loop 可以”活过”单次上下文窗口的关键。没有 Memory 的 Loop，本质上仍然是一个无状态的单次执行——它的”自主性”只存在于一个上下文窗口的时间范围内。

七、与前三个范式的本质区别

厘清了 Loop Engineering 是什么，我们可以从四个维度做系统对比，给 AI PM 建立清晰的分析框架。

维度一：人的控制粒度

Prompt Engineering 阶段，人控制的是每一句话的措辞。Context Engineering 阶段，人控制的是信息环境的构成和质量。Harness Engineering 阶段，人控制的是系统的结构和约束规则。Loop Engineering 阶段，人控制的是目标定义和终止条件——执行过程本身，由 Agent 自主处理。

这个维度最直观地展示了抽象层级的爬升：人的注意力从”内容层”逐渐上移到”策略层”。人越来越不需要关心”怎么做”，越来越需要关心”做什么、做到什么程度算完成”。

维度二：人的介入时机

Prompt Engineering：每次交互都需要人介入，人是循环里不可缺少的节点。Context Engineering：每次会话启动前需要人配置信息环境，运行中也可能需要人调整。Harness Engineering：系统搭建时需要人设计，运行中偶发性介入，但人仍然是启动者。Loop Engineering：Loop 设计阶段需要人投入大量精力，运行阶段原则上不需要人——Loop 自己触发、自己执行、自己验证、自己终止，人在例外情况下才需要出现。

维度三：失败模式

这个维度最值得 AI PM 关注，因为它直接决定了产品的容错设计和异常处理逻辑。

Prompt Engineering 的失败很直观：提示词写得不好，输出质量差，用户能立刻感知，重试成本低。Context Engineering 的失败更隐蔽：Agent 基于错误的信息推理，产出的结果可能表面上看起来正确，但建立在错误的前提上——这类问题更难被普通用户发现。Harness Engineering 的失败需要排查系统结构：某个约束层有漏洞，Agent 在边界处行为异常，排查路径复杂。

Loop Engineering 的失败是最难被发现的：目标定义模糊，或者验证机制缺失，Agent 会无限自我说服，以极高的自信报告任务完成。代码通过了测试，但测试本身是 Agent 为了通过自己的实现而写的。PR 已经提交，但实现和最初的需求之间出现了系统性偏移，而这个偏移没有任何机制能捕捉到。这不是边缘案例，而是”目标不可验证”这个设计缺陷在生产环境里的必然表现。

维度四：适用任务类型

Prompt Engineering 适合一次性、目标明确的短任务，需要人判断结果并决定下一步。Context Engineering 适合需要特定知识输入的单轮或短程多轮任务，Agent 对信息质量敏感但任务本身并不复杂。Harness Engineering 适合需要多步骤自主执行的复杂任务，过程需要监视但不需要每步介入。

Loop Engineering 的适用前提非常具体：任务必须是可重复的、有明确通过/失败信号的、人工操作具有明显重复性特征的。如果你感觉自己在做的事情是重复的、低价值的、可以被规则描述的——建 Loop。如果任务是模糊的、探索性的、目标还没想清楚的——先把目标想清楚，再谈 Loop。

八、两个被高估的希望，两个被低估的风险

Loop Engineering 在工程师圈子里的传播速度很快，但传播中存在两个系统性的误读，以及两个在热度中被严重低估的现实风险。

被高估的希望一：Loop 让 Agent 完全自主，工程师可以放手

Loop Engineering 不是”放手让 AI 接管”。Boris Cherny 在澄清自己的工作流时非常明确：他在 2025 年花了大量时间写 Loop 的规范文件（CLAUDE.md）、Skills 配置、Loop 的运行逻辑；他运行了大量并行的 Claude Code 实例，观察哪些模式能产生可靠输出，哪些会产生垃圾——这些前期投入，才是他后来能”减少手动介入”的前提。Loop Engineering 转移的是执行权，不是判断权。你仍然需要决定做什么、定义什么叫成功、读懂 Loop 的产出、在 Loop 跑偏时出手干预。

被高估的希望二：Loop 适合所有任务

对于目标清晰、验证标准客观的任务，Loop 非常有效。但对于创意性任务、探索性任务、目标本身还在摸索中的任务，Loop 会把”模糊的意图”跑成”Agent 的自我满足”。如果你让一个 Loop 去”写一篇好文章”或者”想一个更好的产品策略”，它可能会无限重写，因为”好”无法被机器验证，它只会持续生产版本直到预算耗尽。

被低估的风险一：目标定义的精确度决定了 Loop 的上限

Loop Engineering 对目标定义的要求，远高于普通提示词。一个模糊的终止条件，等于给了 Agent 一张无限使用的授权书。”把这个功能做好”不是一个 Loop 目标；”所有单元测试通过、TypeScript 编译无报错、代码 Diff 不超过 500 行、PR 描述包含变更摘要和测试截图”才是一个可以自动验证的 Loop 目标。如果目标无法被机器验证，Loop 就无法安全终止。

这个问题的麻烦之处在于，它不是一个技术问题，是一个需求定义问题。而很多时候，需求本身就是模糊的——这意味着 Loop Engineering 的真正门槛，不在于代码能力，而在于需求澄清能力。

被低估的风险二：成本的指数级增长

这是 Loop Engineering 在社交媒体上被严重回避的话题。一个能自我提示、自我验证、自行生成子 Agent、在你睡觉时运行的 Loop，能在你不知情的情况下消耗大量 token 预算。Louis Bouchard 明确指出，在推特上热情讨论 Loop Engineering 的，大多是在大型实验室工作、有巨额 token 预算的人——对于普通团队来说，预算是架构的一部分，不是事后的考量。

每一个生产级 Loop 都必须有硬性约束：最大迭代次数、无进展检测机制（连续 N 次迭代没有实质变化，自动停止）、每日 token 或美元预算上限、异常报警机制。没有这些约束的 Loop，不是自动化，是不受控的资源消耗。

九、对 AI PM 的具体启示

Loop Engineering 看起来是工程师的事，但它对 AI 产品设计的影响是深层次的。以下四点，是我认为 AI PM 需要认真对待的具体启示。

启示一：终止条件成为产品设计的一等公民

传统软件产品设计里，我们习惯于描述”流程”——用户做 A，触发 B，展示 C，任务完成。但在 Agent 产品里，流程本身可以由 Agent 自主决定，PM 需要在需求阶段回答的第一个问题，变成了：什么状态意味着任务完成？

这个问题的答案，决定了整个 Agent 系统能否自主运行。如果 PM 在需求阶段说不清楚”成功标准是什么”，工程师就无法建立验证机制，Agent 就无法自主终止，系统就退化成需要人工保姆的半自动工具——和 Prompt Engineering 时代没有本质区别，只是包了一层”Agent”的壳。

这不是一个技术问题，是一个产品定义问题。明确、可验证的终止条件，是 AI 产品能从”Demo 能跑”走向”生产可用”的关键分野。

启示二：用户角色正在重构，产品交互需要相应演化

Prompt Engineering 时代，用户的核心门槛是”学会怎么说话”。Context Engineering 时代，用户的核心门槛是”学会给对材料”。Loop Engineering 时代，用户的核心门槛正在变成”学会定义可验证的目标、配置任务的边界和约束”。

这是一种更高阶的抽象能力，大多数普通用户目前并不具备——他们知道自己想要什么，但不知道怎么把”我想要什么”转化成”机器能验证的标准”。

这意味着 AI 产品的核心交互设计，正在从”提示词输入框”向”目标配置器 + 验证条件编辑器”演化。如何降低”定义可验证目标”的用户门槛，是未来一两年 AI PM 最值得深挖的设计命题：引导用户逐步澄清目标的对话式界面、预设的验证模板库、从历史任务中学习用户偏好的智能推荐——这些方向，都可能成为差异化竞争的核心。

启示三：PRD 需要新的描述维度

当 Agent 能够自主执行多步骤任务时，传统 PRD 的”用户故事 + 功能描述”框架是不足的。AI Agent 产品的 PRD 需要额外回答五个问题：

1. 触发条件：Agent 在什么情况下被启动？触发信号来自哪里？触发频率是否受控？
2. 执行边界：Agent 能操作哪些系统，绝对不能碰哪些数据，需要人工审批的操作阈值是什么？
3. 验证机制：成功的标准是什么，用什么方式验证，验证的执行者是机器还是另一个 Agent？
4. 失败处理：Agent 遇到无法自主解决的情况时，默认行为是什么——停止并告警、降级到人工、继续尝试直到预算耗尽？
5. 成本约束：单次任务的 token 预算上限是多少，超出后的行为是什么？

这五个维度，在传统软件产品设计里几乎不存在。在 Loop Engineering 的范式下，它们是产品能否正常工作的基础条件——缺少任何一个，都可能在生产环境里暴露出不可控的风险。

启示四：可观测性是产品能力，不是工程附属品

Loop 在自主运行时，用户需要能”看见”Agent 在做什么。这不只是日志和监控——那是工程侧的事。产品侧需要思考的，是面向用户的透明度设计：

Agent 当前在执行第几步？整体进度是多少？这次运行消耗了多少资源？上一次运行的结果是什么，失败的原因是什么？Agent 在某个步骤做了一个非预期的决定，用户能不能看到这个决定，能不能及时干预？

可观测性设计做得好，是 AI 产品建立用户信任的核心机制。Loop 越自主，可观测性越关键——因为用户对”黑盒系统”的容忍度，和任务的风险程度成反比。一个帮你整理日历的 Agent，用户对它的黑盒程度容忍度较高；一个帮你提交代码、发送 PR 的 Agent，用户需要能随时知道它在做什么、做了什么。

对于 AI PM，可观测性不应该是工程上线之后再补的功能，它应该从 PRD 阶段就作为核心产品功能被设计进去。

十、道而不在术：每一次跃迁背后的那个不变的问题

回顾这四次范式演化，有一个规律清晰可见：每一层”术”的演化，解决的其实是同一个”道”的问题——在与 AI 的协作过程中，人类如何保持对目标的清晰理解，以及对结果的真实所有权。

Prompt Engineering 的”术”是措辞技巧，背后的”道”是：你需要知道你想要什么，才能说清楚。Context Engineering 的”术”是信息架构设计，背后的”道”是：你需要知道什么信息是相关的，才能给对。Harness Engineering 的”术”是系统结构设计，背后的”道”是：你需要理解 Agent 的失败模式，才能设计防错结构。Loop Engineering 的”术”是循环程序设计，背后的”道”是：你需要知道什么叫”完成”，才能让 Agent 自主停止。

每一层技术，都在更高效地帮你执行——但每一层技术，都没有帮你解决”你到底想要什么”这个问题。这个问题，永远是人的责任。

Andrej Karpathy 那句”最热门的编程语言是英语”，在 2023 年听起来是一个洞见，在 2026 年回头看，它只说对了一半。英语（自然语言）是接口，不是能力。接口在持续升级——从提示词到上下文到 Harness 到 Loop——但接口背后的那个人，仍然需要对目标有判断，对结果有责任，对失败有理解。接口越来越强大，不代表人越来越不重要；它代表的是，人越来越需要在更高的层次上发挥作用。

有一个值得认真对待的担忧：当 Agent 越来越自主，当 Loop 越来越精密，会有人把 Loop Engineering 当成一种”外包判断力”的方式——让 Loop 决定做什么，让 Agent 决定怎么做，人只需要按一下”启动”。这个路径听起来很诱人，走下去的终点是一个没有人真正理解正在发生什么的系统。

这种风险在 AI 产品设计层面尤其值得警惕。一个 AI PM 如果把”用 Agent 自动化需求分析”作为逃避思考的理由，而不是放大思考的工具，最终产出的是一堆由机器生成的、没有人真正拍板确认过的需求文档——它们在形式上是完整的，在内容上是无人负责的。

Boris Cherny 在一次采访里对这个问题的表述非常克制：”你可以用 Loop 来更快地完成你理解的工作，也可以用 Loop 来回避对工作的理解。这是两件完全不同的事。为你未来的自己做正确的选择。”

这句话值得每一个 AI PM 记住。评估 Loop Engineering 的价值，不应该只看它能让 Agent 跑多快、自主性能走多远，而应该问：这套机制，是在帮助人更清晰地理解问题，还是在帮助人更优雅地回避理解问题？

从 Prompt 到 Context 到 Harness 到 Loop，这四次演化都在做同一件事：把越来越多的”术”交给机器，以便人可以把更多的注意力放在”道”上。这是一个方向正确的趋势——但前提是，人要真的把注意力放在”道”上，而不是用越来越复杂的”术”来掩盖对”道”的回避。

AI 不是在替你思考，它是在替你执行。思考的责任，从来没有，也永远不会，被外包出去。

四年，四次跃迁，不变的始终是这一件事：你对问题本身的理解，是所有技术范式无法替代的那个核心。

AI 的发展在道，不在术。