Loop Engineering：让 AI 自己沉淀上下文

Agent 上下文 技能
AI工具
发布日期:   2026-06-17
文章字数:   5.8k
阅读时长:   20 分

Loop Engineering：让 AI 自己沉淀上下文封面图

Loop Engineering：让 AI 自己沉淀上下文

这两天 X 上关于 Loop Engineering 的讨论突然热了起来。

先是“Prompt Engineering 正在让位于 Loop Engineering”的说法被频繁讨论，后面又有人继续补充：别再只写提示词，要去设计循环；最小可用的 Loop，甚至只需要几份配置，就能让 Claude 自己跑测试、读错误、修 Bug、再跑测试。最近金尘马和 Kyrie 又各写了一篇长文，一个把它讲成普通用户也能上手的实践框架，一个把它讲成工程里能跑的 daily triage。

我看完之后，感觉这不是一个被硬造出来的新概念。

它其实讲中了我日常用 AI 最重要的一件事：不要只优化单次对话，要优化下一次对话开始时，AI 已经知道什么、会自己检查什么、能自动沉淀什么。

我现在越来越少把 AI 当成一个“问一句答一句”的聊天窗口。更准确地说，我是在养一个长期工作的系统：它会读上下文，会查历史，会调用工具，会把有价值的对话沉淀成 memory / skill / 项目文档，下次遇到类似任务，不需要我从头解释。

这就是我理解的 Loop Engineering。

从 Prompt 到 Loop：人不再手动转每一轮

Prompt Engineering 当然还有用。

一个清楚的任务描述、边界、输出格式，依然能显著提高模型表现。问题是，Prompt 解决的是“这一轮怎么说清楚”，不是“这个系统如何越用越顺”。

以前我们使用 AI 的方式大概是这样：

sequenceDiagram
    participant U as 用户
    participant A as AI
    U->>A: 写一个任务 Prompt
    A-->>U: 给出结果
    U->>A: 复制报错 / 补充背景 / 提修改意见
    A-->>U: 再改一版
    U->>A: 下次重新解释一遍

这里最大的问题不是 AI 不聪明，而是每次会话都像临时工入职。

你要重新介绍项目结构，重新解释个人偏好，重新说明哪些坑踩过，重新告诉它“别再这么做”。Prompt 能把当前这次任务做得更好，但很难让系统本身变得更懂你。

所以后面大家开始讲 Context Engineering。

不是只写一句 prompt，而是给 AI 准备更好的上下文：项目文件、规范、历史记录、工具说明、运行环境、错误日志。

再往后是 Harness Engineering：给 Agent 配工具、权限、测试、回滚、子任务调度，让它不只是“会说”，而是真的能在系统里干活。

Loop Engineering 再往上走一层。

它关心的是：Agent 做完一件事之后，系统如何继续运行、验证、更新自己。

Loop 的基本骨架：触发、行动、验证、记忆

卡牌大师崔斯特那篇补充文章里，把 Addy Osmani 对 Loop 的拆解讲得很清楚：一个能跑起来的循环，通常由六类零件组合出来。

  • Automation：定时任务、hook、webhook，让任务不必等你开口
  • Worktree：隔离并行 Agent，避免互相踩文件
  • Skill：让 Agent 自己读操作手册，而不是每次从零解释
  • Connector：连接 GitHub、Slack、浏览器、数据库、X、文件系统等外部世界
  • Sub-agent：把写代码、检查、修复、研究拆给不同上下文
  • Memory：把跨运行仍然有价值的状态留在磁盘上

所以 Loop Engineering 不是“写一个更长的 prompt”。

它更像是在设计一个小型操作系统：触发器负责启动，工具负责执行，检查器负责验收，记忆文件负责跨轮延续，skill 负责复用经验，worktree 负责隔离并行工作。

可以画成这样：

flowchart TD
    A[Automation
定时 / Hook / Webhook] --> B[Agent 读取上下文]
    B --> C[Skill
加载操作手册]
    B --> D[Memory
读取状态文件]
    C --> E[Connector
调用工具和外部系统]
    D --> E
    E --> F[Sub-agent / Worktree
并行执行]
    F --> G[Evaluator
测试 / Lint / 类型检查]
    G --> H{停止条件满足?}
    H -->|否| B
    H -->|是| I[写回 Memory / Skill / Docs]

这里最关键的一点是：Agent 会忘，但文件不会。

模型的上下文窗口会结束，会压缩，会丢掉细节。但一个 PROGRESS.md、STATE.md、AGENTS.md、SKILL.md，只要维护得好，就能让下一次循环从上一次的经验继续，而不是从零开始。

先判断边界：什么任务值得做成 Loop

不是所有任务都值得 Loop 化。

很多人看到“循环”两个字，第一反应是把所有重复动作都自动化。但这里有个很重要的区别：批处理只是重复执行，Loop 是根据上一轮结果决定下一轮动作。

比如让 AI 遍历 100 篇文章，每篇都生成摘要，这只是批处理。第一篇摘要写得好不好，并不会影响第二篇怎么做。真正的 Loop 应该是：上一轮检查发现摘要缺来源，下一轮就补来源；发现概念页强行关联，下一轮就拆开；发现连续两轮都无法判断，就停止并交给人。

所以判断一个任务该不该做成 Loop，可以先过三道门：

  • 重复：这件事是不是经常发生？如果只是一次性任务，设计循环的成本可能比手动做还高。
  • 可验：什么叫“完成”、什么叫“做好”，能不能写成测试、清单、字段校验或 reviewer 规则？
  • 值得：它省下的时间、降低的错误率，是否抵得过 token、工具调用、维护规则的成本？

三条都满足，才值得认真做成 Loop。缺一条，普通 prompt、脚本或人工判断往往更划算。

还可以再分一层：

  • 流程型任务：步骤固定、结果确定，用脚本/RPA 就够了，不一定需要 Agent。
  • 工具辅助型任务：目标清楚，但路径需要人判断，适合 Copilot 式协作。
  • 目标驱动型任务：人给目标、边界和验收标准，系统自己观察、行动、验证、迭代，这才是 Loop Engineering 最适合的位置。

从最小闭环开始：先让 AI 自己跑测试

老金那篇“最小 Loop”给了一个很好的落地例子。

很多人用 Claude Code 写代码时，真实流程是这样的：

flowchart LR
    A[Claude 写代码] --> B[你跑测试]
    B --> C[你复制报错]
    C --> D[Claude 修复]
    D --> B

这个流程里，人其实变成了一根 USB 线。

Claude 写代码，你跑测试；Claude 等结果，你粘错误；它再修，你再跑。你做的不是判断，而是搬运。

最小 Loop 要做的，就是把这条直线弯成循环：

flowchart TD
    A[写变更] --> B[运行检查]
    B --> C{有失败?}
    C -->|有| D[读取错误并定位根因]
    D --> E[修复代码]
    E --> B
    C -->|无| F[报告完成并附通过输出]
    D --> G{同一错误重复?}
    G -->|是| H[停止，不再猜]

这个 Loop 的价值不在于高级，而在于它够硬。

你不再允许 Agent 在没有检查输出的情况下说“完成”。你也不允许它通过删测试、弱化断言、跳过错误来制造绿色结果。完成的定义从“我写完了”变成“检查通过了”。

这一步非常关键。

因为 Agent 最大的问题之一，不是不会干活，而是太容易提前乐观。它会把“代码看起来像完成了”当成“任务完成了”。Loop Engineering 要做的，就是给它一个不会被语言糊弄的停止条件。

验证是心脏：Evaluator 必须有硬闸门

这里有个坑：很多人会加一个“检查 Agent”，但只是让它“帮我审一下”。

这不够。

一个只被要求“审一下”的第二 Agent，很容易变成另一个乐观主义者。它会用语言判断语言，然后大家一起觉得差不多了。

真正有效的 evaluator-optimizer 模式，必须有客观失败信号：

  • 测试是否通过
  • 类型检查是否通过
  • Linter 是否通过
  • 构建是否成功
  • 页面是否真的渲染
  • API 是否返回预期字段
  • 生成文件是否存在且内容包含关键短语

也就是说，Evaluator 不应该只是“发表意见”。它应该站在一道硬闸门前。

flowchart LR
    A[Generator
生成方案] --> B[Evaluator
运行硬检查]
    B --> C{检查通过?}
    C -->|否| D[返回失败证据]
    D --> A
    C -->|是| E[允许完成]

这也是我自己用 AI 时很在意的一点：结论必须带证据，完成必须有验证。

如果没有验证输出，它说“好了”没有意义。

验证之后，还要沉淀上下文

我日常用 Agent，最看重的不是它一次性回答得多漂亮，而是它做完之后会不会更新自己的上下文资产。

每次任务结束，我希望它自动判断三件事：

  1. 这次任务里有没有稳定事实？
  2. 有没有以后还会复用的流程？
  3. 有没有项目文档或技能需要更新？

如果有，就不要等我手动整理。

比如：

  • 我纠正过一次沟通风格，它应该写进长期偏好
  • 某个仓库的部署命令、目录约定、测试坑点，应该写进项目规则或 memory
  • 某类任务跑通了 5 步以上，应该沉淀成 skill
  • 某个旧 skill 过期了，应该当场 patch，而不是下次继续踩坑
  • 某次问题只是临时进度，就不要污染长期记忆

这就是“AI 自己沉淀对话内容”的价值。

它不是把所有聊天记录都塞进记忆。那样只会制造噪音。真正重要的是分类：什么是长期事实，什么是流程经验，什么只是本次任务状态。

我现在更喜欢把 AI 的知识沉淀拆成四层。

flowchart LR
    A[对话内容] --> B{是否值得沉淀}
    B -->|用户偏好 / 稳定事实| C[Memory]
    B -->|可复用流程 / 踩坑经验| D[Skill]
    B -->|项目内协作规范| E[AGENTS.md / README / Docs]
    B -->|临时进度| F[Session History / PROGRESS.md]

    C --> G[下次自动知道你是谁]
    D --> H[下次自动知道怎么做]
    E --> I[同一项目所有 Agent 都能遵守]
    F --> J[当前循环继续推进]

这几层不能混。

Memory 适合存偏好和稳定事实。Skill 适合存步骤、命令、坑点、验证方式。项目文档适合约束同一个仓库里的所有 Agent。临时进度则应该放在 session history 或 PROGRESS.md 里。

如果你把所有东西都塞进长期记忆，系统会越来越吵。记忆不是存档，记忆是索引。它应该保存能改变未来行为的东西，而不是保存“今天做了什么”。

状态文件：给循环一个短记忆

Loop 里最容易被低估的是状态文件。

一个 PROGRESS.md 或 STATE.md，看起来很土，但非常有用。

它解决的是“Agent 两次运行之间会忘”的问题。每次循环开始时，先读它；每次循环结束时，再把关键状态写回去。

但这里有一个原则：短。

一个让 Agent 每次都读 2000 行的记忆文件，比没有记忆更糟。好的状态文件应该只回答几个问题：

  • 上一轮做了什么
  • 当前卡在哪里
  • 已经排除过什么
  • 下一步要试什么
  • 停止条件是什么

比如可以长这样：

# PROGRESS.md

## Goal
修复登录页在移动端无法提交的问题。

## Last Run
- 已确认不是按钮 disabled 状态导致
- `LoginForm.tsx` 的 submit handler 没触发
- 怀疑外层 form 被样式层遮挡

## Next
- 检查移动端 CSS z-index
- 跑 `npm test -- LoginForm`
- 如果同一错误再出现 2 次，停止并请求人工判断

这不是为了写日报，而是为了让循环下一轮不用从零开始。

普通用户的最小模板：目标、流程、验收、停止

如果说上面的 PROGRESS.md 更偏 Agent 工程，那 Adrian Punk 那篇面向入门用户的 Loop Engineering 教程，补上的其实是另一块：不要一上来就讲 Agent、worktree、sub-agent，先让普通用户把任务写成一个可执行循环。

它的新意不在概念更深，而在表达更低门槛：一个最小 Loop 不必复杂到像系统架构，先写清楚四件事就够了。

  • 目标：到底要交付什么，不要只说“做好一点”
  • 流程：先做什么、后做什么，别让 AI 自己乱猜顺序
  • 验收标准：什么叫合格，最好能逐条检查
  • 停止条件：什么时候结束，最多改几轮，避免无限润色

这个框架很适合把一次性提示词改造成第一版 Loop。比如以前你可能会说：

帮我写一篇 AI 工具教程。

更好的写法是：

请用 Loop 的方式完成这个任务。

目标：写一篇面向新手读者的 AI 工具教程。
流程：
1. 先判断读者是谁
2. 再列出文章大纲
3. 写第一版正文
4. 按验收标准自查
5. 如果不合格，只修改最重要的一轮
6. 合格后停止

验收标准：
- 开头有具体案例或数字
- 每个概念都用生活化例子解释
- 不出现大段空话
- 结尾给出今天就能做的一步

停止条件：
所有验收标准满足后停止；最多修改 2 轮，仍不满足就说明原因。

这个模板看起来朴素，但它抓住了 Loop Engineering 的入门钥匙：不要只告诉 AI “我要什么”，还要告诉它“怎么判断已经做好”。

也正因为如此，我会把 Loop 分成两层来看：

  • 对普通用户，Loop 是目标、流程、验收、停止条件
  • 对 Agent 工程，Loop 才进一步变成工具调用、硬检查、记忆写回、skill 沉淀和多 Agent 协作

前者解决“让 AI 别只答题，要按流程做事”；后者解决“让 AI 跨任务、跨会话、跨工具持续变强”。两层不是互斥关系，而是同一件事的不同成熟度。

经验复用：Skill 比 Memory 更像“程序”

Memory 适合存事实，但流程不应该塞进 memory。

如果你发现某件事有固定步骤、有依赖、有坑点、有验证方法，那它更适合写成 Skill。

比如“从 X 线程写成 Hexo 博客”就不是一句记忆能解决的，它至少包含：

  • 读取 X 原帖、Article、引用、配图
  • 判断是否需要保留原图
  • 生成符合 Hexo 的 front matter
  • 用 Mermaid 或插图增强文章
  • 生成封面并上传图床
  • npx hexo generate 校验
  • 只交付草稿，不擅自部署

这就是 Skill 的价值：它把一次经验变成可复用的操作系统能力。

对 Agent 来说，Memory 像“我知道你偏好什么”，Skill 像“我知道这类事该怎么做”。两者都重要，但混在一起就会出问题。

扩大到工程场景：隔离并行与做检分离

Loop 一旦开始自动化，迟早会遇到并行问题。

一个 Agent 修测试，另一个 Agent 改页面，第三个 Agent 做重构。如果它们都在同一个工作目录里改文件，很容易互相覆盖、互相污染。

所以 worktree 是 Loop 里的基础设施，不是高级玩法。

每个 Agent 拿一个隔离工作区，做完后再合并结果。这样并行才是真的并行，不是几个人挤在同一张桌子上改同一份稿子。

Sub-agent 的意义也类似。

主 Agent 不应该什么都自己做。它可以让一个子 Agent 研究方案，让另一个子 Agent 做实现，让第三个子 Agent 按测试和规范做审查。尤其是当主会话已经连续失败几轮时，一个干净上下文的 fixer 往往比继续在原窗口里硬修更有效。

这也是 Loop Engineering 和普通自动化脚本的区别：它不只是重复执行命令，而是在设计不同上下文之间的协作方式。

一个完整例子：晨间维护 Loop

如果把前面的零件拼起来，一个比较真实的工程 Loop 可以长这样：

每天 9 点触发：
1. 读取 PROGRESS.md，跳过已经处理过的问题
2. 收集昨夜 CI 失败、新 issue、依赖审计告警
3. 每条问题开独立 worktree 或分支
4. Agent 只起草最小修复，不顺手重构
5. Reviewer agent 只读检查：跑测试、跑 lint、看 diff
6. PASS 且低风险：开 PR
7. FAIL 或涉及公开 API / 数据迁移 / 删除操作：写入 PROGRESS.md，交给人
8. 更新 PROGRESS.md，结束

这个例子的重点不是“每天 9 点”，而是四个工程约束：

  • 隔离：每条问题在独立 worktree 或分支里处理，不污染主线。
  • 最小改动：一次只修一个问题，避免 Agent 把维护任务做成重构任务。
  • 做检分离：写代码的 Agent 不给自己判分，Reviewer 必须亲自跑测试和 lint。
  • 人类闸门：只让低风险、证据充分的结果自动进入 PR；高风险决策必须停下来。

这比“让 AI 帮我修一下项目”要可靠得多。后者是一句愿望，前者是一条有入口、有状态、有检查、有退出条件的生产线。

收尾动作：把经验写回正确的位置

如果你也想这样用 AI，可以先从一个很简单的规则开始。

每次任务结束前，让 Agent 做一次自检：

这次任务有没有任何信息，能让未来同类任务少解释一次？

如果有，再判断放哪里：

  • 用户偏好、稳定身份、长期环境事实：写 Memory
  • 5 步以上的可复用流程、复杂排错路径：写 Skill
  • 只对当前项目有效的规范：写 AGENTS.md / README / docs
  • 当前循环推进状态：写 PROGRESS.md / session history
  • 一次性结果和临时进度：不要写长期记忆

这个规则非常朴素，但已经能让 AI 的使用体验发生变化。

你会发现，真正省时间的不是它某一次回答快了 10 秒，而是它不再反复问你同样的问题。

回头看 Prompt：它只是循环里的一个节点

所以我不太会说“Prompt Engineering 过时了”。

更准确地说，Prompt 正在从主角变成节点。

以前我们把所有希望都压在一句 prompt 上：写得越完整越好，越结构化越好，越像说明书越好。

但在 Agent 工作流里，prompt 只是循环的一部分：

  • 它触发任务
  • 它指定目标
  • 它约束输出
  • 它提供必要背景

然后系统继续往下走：读文件、查历史、调用工具、验证结果、修正错误、沉淀经验。

如果只盯着 prompt，等于只盯着流水线入口。真正决定产能的是整条线怎么转、哪里质检、哪里返工、哪里把经验固化成制度。

最后装刹车：Loop 如何失控

Loop 不是免费的。

它把你守在对话框前复制粘贴的时间，换成了 token、工具调用、日志维护和验收成本。真正贵的通常不是单次运行，而是频率：每天跑一次的维护循环可能很划算，每 5 分钟跑一次同样的循环，成本会放大两个数量级。

所以 Loop 不是先追求“跑起来”，而是先确认“坏了会怎么停”。我会把常见失控分成四类：

  • Runaway：轮次和账单一直涨，但没有实质进展。通常是没有次数上限和预算上限。
  • Silent death：表面上还在运行，其实已经卡在同一个状态里。通常是没有 heartbeat、状态文件或外部监控。
  • Random walk：每轮都在动，但离目标越来越远。通常是没有硬验收条件，只靠模型判断“看起来差不多”。
  • Comprehension debt：PR、文档、代码越来越多，人却越来越不理解系统。通常是没有强制人工阅读和高风险闸门。

对应的刹车也不用玄学：

  • 次数上限：最多重试几轮，不要无限“再试一次”。
  • 预算上限：时间、token、钱、外部 API 调用都要有边界。
  • 无进展检测：连续几轮没有新信息、新 diff、新测试结果，就停。
  • 心跳记录：每轮写入状态文件，沉默太久就告警。
  • 爆炸半径：限制在一个 worktree、一个分支、一个低权限目录里。
  • 人工闸门：公开 API、数据迁移、删除、发布、付款这类动作必须停下来交给人。

Agent 可以更快地生成代码、文档和 PR，但如果你不读、不审、不理解，仓库里的东西会越来越多，而你真正掌握的部分会越来越少。Loop Engineering 不是让人从系统里消失，而是把人从“每轮搬运报错”升级为“设计规则、检查证据、承担结果”的角色。

一个好 Loop 应该让你少做机械重复，不应该让你放弃判断。这才是 Loop Engineering 值得关注的地方。

结语：把 AI 从“聪明回复”养成“长期系统”

Loop Engineering 真正击中的，是一个很朴素的需求：大家已经不满足于“AI 回答得不错”了。我们开始希望 AI 能带着工具、带着记忆、带着流程，持续参与自己的工作系统。

Prompt 仍然重要，但它不再是全部。

下一阶段真正重要的是：

  • 你有没有给 Agent 足够好的上下文
  • 你有没有给它可靠的工具和边界
  • 你有没有让它验证自己的结果
  • 你有没有让它把可复用经验沉淀下来

如果没有这些，AI 再聪明，也只是一次性对话。

如果这些循环跑起来，它就开始变成一个会自我更新的工作伙伴。

这大概就是我理解的 Loop Engineering：不是让 AI 替你多说几句话，而是让它在每次工作后，都比上一次更懂你的系统。

参考：

文章作者: Onefly
文章链接: https://onefly.top/posts/loop-engineering-ai-memory.html
版权声明: 本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 Onefly !
Agent 上下文 技能
赏
评论
  目录