Loop Engineering解读，AI没有杀死工程一直在强化工程

文章主旨：

文章认为，Loop Engineering 是在 Prompt、Context、Harness 之后进一步扩大 AI 控制范围的工程能力，核心是用反馈、验证、预算和终止条件来编排重复任务，而不是简单替代 Agent。

关键要点：

1. Loop Engineering 被视为继 Prompt、Context、Harness 之后的新概念，它们不是替代关系，而是控制范围逐步扩大的工程能力；Loop 是带有反馈和终止条件的重复机制，也是一种编排方式。
2. Agent 本身是一种最基础的循环，基于用户需求调用工具直到任务完成，如 React 的“思考、行动、观察”；Loop 更强调工程、验证、预算、重试和终止，关注“做完了吗”。
3. 循环类型包括基础 Agent Loop、基于评测反馈的回路判断、事件/时间驱动循环、爬坡环；评测可用 LLM as a Judge 或 Code，爬坡环则从 Agent 的 Trace 定向优化 Prompt、Tool 或 Code。
4. 是否使用 Loop 取决于任务是否重复发生、结果能否验证、失败能否分流；适合并行或交叉验证、批量审查、迁移、多来源研究等场景。Skill 负责沉淀知识规则，Workflow 或 Loop 负责任务触发、执行、验证和停止。
5. 实践上可通过 Hook、固定 prompt 关键词、Claude Code 示例和编码/研究/内容循环模板落地；最终需在 Agent 与 Loop 之间权衡，重视验证、追踪、预算和人工关卡，并面对“快、好、便宜”的不可能三角。

内容结构：

1. 概念演进：从 Prompt、Context、Harness 到 Loop Engineering

文章指出，Prompt 用于给 AI 更明确的指令，Context 用于提供更清晰有效的历史、事实和约束，Harness 用于给 AI 更可靠的运行底座。Loop 融合了前面的能力，是一种带有反馈和终止条件的重复机制，也是一种编排方式。若工作流带有回路和终止条件，就可称得上循环；叠加预算、轮次、状态设计后，会更接近工程。

2. 循环的起源

作者先对概念祛魅：Agent 本身就是一种最基础的循环，基于用户需求，使用模型调用工具直到任务完成，例如 React 的“思考、行动、观察”，强调下一步做什么。Loop 强化的是更完善的工程和更有效的验证，强调“做完了吗”，例如上下文有预算，行动是否也要有预算；AI 完成任务后如何评估是否达成目标；未完成是否重试、何时终止。工程意味着稳定性、准确性，而稳定和准确又依赖追踪和评测。

文章引用火山引擎 Function Call 辅助理解：模型思考用户需求时，会结合可用工具判断是否需要调用工具，并基于工具结果再次给出答案。经典示例如“北京今天天气如何、适合穿什么衣服”，模型调用天气查询工具后，结合温度、天气状况等给出穿衣建议。

3. 循环的类型

Agent Loop 早期存在缺点，继续或停止依赖模型自主判断，不够严格。文章提到引入评测指标，如 LLM as a Judge 或 Code：前者解决不确定性问题，例如答案是否贴近口语化、贴近知识库切片；后者解决确定性问题，例如编译是否通过、格式是否错误。当 Agent 获得反馈结果后，就能与输出进行比对，确认是否进行回路。

文章还提到第三类循环：基于事件、时间驱动，类似 Agent 的定时任务，在什么时间基于什么事做什么。时间、Webhook、告警、PR 创建、文档更新都可以成为触发器。最著名的是 Openclaw 的心跳机制，让 Agent 变成始终在线、主动的助手；心跳机制也推进了 CLI 发展，使日程提醒、邮件提醒、定时任务和日报更顺畅。

第四类循环被 Sydney Runkle 称为“爬坡环”。它和 Goal 类似，类似 Hermes 的自我优化机制，但 Goal 加上评分指标后进一步用于编程。爬坡环更关注整个系统，从 Agent 的 Trace 去定向优化 Prompt、Tool 或 Code。目标让单次任务有终点，而爬坡让 Agent 持续自动调优。

4. 什么时候应该使用循环

文章引用 Claude Code 的定义：当任务超出单个 Agent 能协调的范围，需要并行或交叉验证，或者同一个步骤要在很多对象上重复执行，例如批量审查、迁移或多来源研究，就应该用 Loop。判断是否要做 Loop，不仅是复杂度和轮次，更关注是否重复发生、结果能否验证、失败能否分流。

Skill 和 Workflow 也不是替代关系。Skill 负责沉淀项目知识、规则和操作方式，Workflow 或 Loop 负责决定任务如何触发、执行、验证和停止。简单、低风险任务可以直接 Prompt + Skill；重复且要求稳定性的任务，才值得做成 Loop。文章还提到可以创建多个循环，让任务越出 Sub Agent、Agent Team 的约束。

5. 循环的实践案例

使用循环可以结合 Hook 或固定的 prompt 关键词，例如代码 commit 时触发审计，或让 AI 执行类似“/整理窗口”的指令来调用脚本整理终端窗口。

Claude Code 示例包括：跨来源研究竞争对手如何处理速率限制；审查每个更改的文件并写摘要；保持修复直到检查通过；审计许多文件以查找相同问题。具体如并行阅读三家竞争对手公开文档和 changelog 并比较；审查 PR 中每个更改文件并合并为排序摘要；运行 npx tsc --noEmit 并持续修复，直到类型检查通过或连续两轮无进展；审查 src/routes/ 下每个路由处理程序是否缺失认证检查，并在报告前对抗性验证。

文章还引用 Rahul 的模板：编码循环为读取 VISION.md 与 ARCHITECTURE.md、计划下一步修改、编辑代码、自动运行测试、失败则读错误修复重测、通过则总结变更并停止；研究循环为定义研究问题、搜索来源、总结发现、验证声明、比较冲突信息、综合最终答案，达到置信度阈值后停止；内容循环为定义主题受众目标、创建草稿、批评 agent 评审、根据批评重写、按成功标准评分，通过则发布，失败则继续重写。

6. 最后：Agent 与 Loop 的选择及工程约束

文章最后讨论困局：真的有必要上 Agent，还是 Loop 就足够。任务越长、工具越多、外部影响越大，验证、追踪、预算和人工关卡就越重要。Agent 的智能只是表象，工程和流程才能追求稳定、高效；动态、无边际的 Agent 容易漂移。

对 C 端而言，慢几乎零容忍，但小厂没有算力，所以用户会逼着解决不可能三角，例如不要开启深度思考还要让 AI 保持稳定。文章总结为，AI 时代也逃不过既要又要：又快、又好、又便宜。

文章总结：

文章认为，Loop Engineering 是 AI 工程化演进的重要方向，但落地关键不在概念包装，而在于根据任务重复性、可验证性和失败分流来设计反馈、预算、终止条件与人工关卡，以平衡稳定、高效和成本。