Loop 工程：为什么 AI Agent 需要反复迭代

2301_80117363

138人浏览 · 2026-07-06 21:18:02

2301_80117363 · 2026-07-06 21:18:02 发布

Loop 工程：为什么 AI Agent 需要反复迭代

单次对话能解决问题，但不能积累经验。Loop 就是让 AI 学会「复盘」。

单次对话的问题

你用 Claude Code 写代码，体验应该还不错。告诉它需求，它读上下文、生成代码、跑测试，一气呵成。

但你有没有遇到过这种情况：

上次对话里，CC 写了一个接口，你发现它忘了做参数校验，告诉它要加。它加了，测试过了，皆大欢喜。

这次对话，你让它写另一个接口。它又忘了参数校验。

你说了同样的话，它犯了同样的错。

这不是模型能力的问题。CC 能写参数校验，上次不就写了吗？问题在于：上次的对话结束了，这次的对话是全新的。 AI 不记得上次你纠正过它什么，不记得上次它犯了什么错，不记得上次它学到了什么。

每次对话都是从零开始。

这就是「单次对话」的根本问题：它能解决问题，但不能积累经验。

三个典型的翻车现场

单次对话的问题不只是「忘了参数校验」这么简单。来看三个更典型的场景。

翻车 1：重复犯错

你让 CC 修一个 bug：数据库查询没加索引，导致慢查询。CC 加了索引，问题解决了。

两周后，另一个模块出了同样的问题。CC 完全不知道上次的教训，又写了一个没加索引的查询。

根因：AI 没有记忆。每次对话结束，学到的东西就丢了。

翻车 2：没有验证

你让 CC 写一个工具类。它说「写好了，测试也过了」。你信了，直接 push。

CI/CD 管道挂了。原因是 CC 说的「测试过了」只是本地跑了一下，没有覆盖边界情况。

根因：AI 没有强制验证机制。它自己说过了不算，得有外部的裁判。

翻车 3：偏离方向

你让 CC 加一个「获取用户详情」的接口。它加了，但顺手把用户服务的查询方法重构了一遍，还改了三个不相关的文件。

你 review 的时候一脸懵：我只是要加个接口，怎么改了这么多东西？

根因：AI 没有行为边界。它不知道什么该碰、什么不该碰。

共同根因

这三个问题的共同根因：AI 的工作没有闭环。

没有反馈：做完了不知道对不对
没有约束：想改什么就改什么
没有积累：上次学到的这次忘了

怎么解决？需要两样东西：先装轨道（约束），再跑圈（迭代）。

Harness：先给 AI 装上轨道

大模型的能力就像岷江的水——水量充沛，但如果不加引导，就会泛滥。

都江堰不是造水的，是治水的。它用鱼嘴分水、飞沙堰排沙、宝瓶口引水，把岷江的水引导到成都平原。

Harness 工程做的是同样的事。它不是造模型能力的，是引导模型能力的。

什么是 Harness

Harness = 约束工程。通过文档和规则约束 AI Agent 的行为，让它在正确的路径上工作。

四个核心原则

分流/分步骤：大任务拆成小步骤，一步一步来
控量约束：限制 AI 能做什么、不能做什么
兜底机制：出错了有明确的处理流程
长期维护：约束文档要跟着项目一起演进

存在形式

文件	作用
CLAUDE.md	用户级全局规范
AGENTS.md	项目级入口和架构说明
GUARDRAILS.md	行为边界，能做什么、不能做什么
DONE.md	完成标准，什么算做完了

这些文件不是给人看的文档，是给 AI 看的约束。它们和代码一样重要。

Harness 的局限

Harness 解决了「约束」问题——翻车 3（偏离方向）可以靠 GUARDRAILS.md 来防止。

但它没有解决「反复迭代」问题——翻车 1（重复犯错）和翻车 2（没有验证）还是会发生。

因为 Harness 是静态的。它告诉你规则，但不帮你执行。你需要一个机制，让 AI 的工作有反馈、有验证、有积累。

这就是 Loop。

Loop 是什么

Loop 不是编程里的 for 循环。

在 AI 工程的语境下，Loop 是 AI Agent 的一轮工作周期：接收任务、读取上下文、生成代码、验证结果、写回学习成果——这一整个流程就是一次 Loop。

你可以把 Loop 理解为 AI 的「一轮活」。人有工作日，AI 有 Loop。

一次 Loop 的完整流程

  触发
    |
    v
 读取上下文
    |
    v
 执行任务
    |
    v
 验证结果
    |
    v
 知识回写
    |
    v
 完成（或反馈到下一次 Loop）

触发：告诉 AI 该干活了
读取上下文：AI 读 AGENTS.md、架构文档、相关代码，搞清楚状况
执行任务：在 Harness 约束下生成代码
验证结果：编译、测试、检查是否符合 DONE.md 的标准
知识回写：把这次学到的东西写回文档，下次 Loop 就知道了

Loop vs 单次对话

维度	单次对话	Loop
反馈	没有，做完就完	有，验证不通过就重来
约束	没有，AI 想怎么干就怎么干	有，GUARDRAILS.md 定义边界
积累	没有，下次从零开始	有，知识回写让 AI 越来越懂你的项目
验证	AI 自己说过了就行	有外部裁判（编译、测试、CI/CD）
结束条件	你说「好了」就结束	按 DONE.md 的标准判断是否完成

一句话：单次对话是「交作业」，Loop 是「交作业 + 改错 + 记笔记」。

三层架构

Loop 不是在真空中工作的。它在一个三层架构下运行：

+---------------------------+
|  L1 架构层                 |
|  系统整体设计              |
|  （人写的，很少变）        |
+---------------------------+
            |
            v
+---------------------------+
|  L2 模式层                 |
|  设计模式和约束规则        |
|  （Harness 文档，偶尔更新）|
+---------------------------+
            |
            v
+---------------------------+
|  L3 代码层                 |
|  由 Loop 生成的实际代码    |
|  （每次 Loop 都可能变）    |
+---------------------------+

L1 架构层：系统整体设计——有哪些服务、数据怎么流、部署在哪儿。这是人写的，很少变。

L2 模式层：设计模式和约束规则——AGENTS.md、GUARDRAILS.md、编码规范。这是 Harness 文档，偶尔更新。

L3 代码层：由 Loop 生成的实际代码——Controller、Service、测试类。每次 Loop 都可能生成新的 L3。

关键逻辑

每次 Loop 先读 L1 + L2 作为上下文，再在 L2 的约束下生成 L3。

这保证了两件事：

AI 知道项目整体是什么样的（读了 L1）
AI 知道什么能做什么不能做（读了 L2）

L1 和 L2 是人写的（或者由之前的 Loop 沉淀的），L3 是 AI 生成的。这个分层保证了 AI 不会「自由发挥」到偏离项目方向。

Loop 的标准工作流

每次 Loop 都遵循一套标准操作流程（SOP）。七步走完，一个 Loop 才算闭环。

[1] 识别任务涉及的服务
         |
[2] 读取事实层：AGENTS.md + 架构文档
         |
[3] 检查跨服务需求：docs/contracts/
         |
[4] 检查护栏：GUARDRAILS.md
         |
[5] 自验证：编译 -> 启动 -> 测试
         |
[6] 关闭：按 DONE.md 检查完成度
         |
[7] 知识回写：将新知识写回 Harness 文档

Step 1：识别服务

接到任务后，先搞清楚这个任务涉及哪些服务。是只改用户服务，还是跨了订单服务和支付服务？

Step 2：读取事实层

读 AGENTS.md 了解项目结构和规范，读架构文档了解服务之间的关系。这一步是让 AI「搞清楚状况」。

Step 3：检查跨服务需求

看看 docs/contracts/ 里有没有接口约定。如果要改一个 API，得确认下游服务能不能兼容。

Step 4：检查护栏

读 GUARDRAILS.md，确认这个任务在 AI 的行为边界内。比如：不能改数据库 schema、不能动生产配置。

Step 5：自验证

按 BUILD.md 的指引，编译代码、启动服务、跑测试。这一步是 AI 自己检查自己。

Step 6：关闭

按 DONE.md 的标准检查完成度。代码写完了不代表做完了——有没有写测试？有没有更新文档？

Step 7：知识回写

把这次 Loop 学到的东西写回 Harness 文档。比如：发现了一个新的边界情况、总结了一个新的最佳实践。

这一步最容易被忽略，但它是 Loop 和普通 AI 对话的核心区别。

没有知识回写，每次 Loop 都是从零开始。有了知识回写，AI 会越来越懂你的项目。

回到开头的问题：为什么 CC 总是重复犯同样的错？因为没有知识回写。上次你纠正它「要加参数校验」，它没有把这条写进 GUARDRAILS.md。下次对话，它自然就忘了。

如果有了知识回写，上次 Loop 结束时会写一条：「所有 API 接口必须有参数校验」。下次 Loop 读到这条，就不会再犯同样的错。

Loop 的触发方式

Loop 的第一个问题是：什么时候开始？

有四种触发方式：

手动触发

最常见的。你告诉 CC「帮我加一个接口」，这就是手动触发一个 Loop。

适合场景：开发过程中，你有明确的任务要交给 AI。

定时任务

用 cron 或定时调度器，定期触发 Loop。比如每天凌晨跑一次代码质量检查，每周跑一次依赖更新。

适合场景：周期性的维护任务，不需要人盯着。

事件触发

某个事件发生时自动触发 Loop。比如：

CI/CD 管道失败了 → 触发一个修复 Loop
Git 有新的 push → 触发一个代码审查 Loop
收到一封邮件 → 触发一个处理 Loop

适合场景：需要对特定事件做出响应。

Action 触发

通过 GitHub Actions 或 GitLab CI 的 workflow 触发。本质上是事件触发的一种，但更结构化。

比如：PR 创建时自动触发代码审查，合并时自动触发部署。

对比

触发方式	适合场景	人工介入
手动触发	开发过程中的具体任务	需要
定时任务	周期性维护
不需要
事件触发	响应特定事件	不需要
Action 触发	CI/CD 集成	不需要