Loop Engineering 与 Agent 工程的四代演化
一句话：从 Prompt 到 Loop 是四次跃迁（语言表达 → 信息筛选 → 系统设计 → 目标管理），Loop 之后还有四个演化方向（Recursion / Functional / Environment / Discuss）和一个底层能力（Memory）。
目录
- 1. Loop Engineering 的诞生（2026-06 行业共识）
- 2. Loop 的五个组件（术）
- 3. Loop 的灵魂：定义目标的能力（道）
- 4. 陷阱：古德哈特定律
- 5. 四代演化：从 Prompt 到 Loop
- 6. Loop 之后：四个演化方向（推演）
- 7. 目标定义框架（实操）
- 8. 与本知识库其他章节的关联
- 9. 来源与局限性
- 10. 最后更新
1. Loop Engineering 的诞生（2026-06 行业共识）
1.1 触发事件
2026 年 6 月初，AI 行业几乎同时出现三个声音：
-
2026-06-07：OpenClaw 创始人 Peter 发推
“你不再需要为编码智能体编写提示词了，你应该设计循环来提示你的 Agent。”
-
同期：Claude Code 创始人 Boris 在开发者大会上说
“我不再手动给 Claude 写提示词了，我运行着能让 Claude 自动编排任务的循环，我的工作，就是编写这些循环机制。2026 年，我就再也没有手写过一行代码了。晚上睡觉的时候，甚至有时候会有几千个 Agent 在同时工作。”
-
2026-06-14：Google 的 Addy Osmani 发长文，正式梳理出 Loop Engineering 概念
1.2 Loop Engineering 是什么
定义：不再手写 Prompt 一轮轮对话，而是设计自动循环让 Agent 自己跑——你定目标、定验证条件、定失败处理，然后放手让系统 24 小时自动执行。
典型例子（Boris 的用法）：
/loop babysit all my PRs
# 自动监控所有 PR → CI 挂了就自己修 → 有新评论就派子 Agent 去改代码
# 晚上睡觉，几千个 Agent 在工作，醒来代码已经改好、测试已经跑过、PR 已经提上去和以前的区别：
| 以前（任务制） | 现在（Loop） |
|---|---|
| 你给任务 → Agent 做 → 你看结果 → 你再给修改意见 | 你定目标 → Agent 自己循环到满足条件为止 |
| 你是驱动整个循环的发动机，必须坐在设备前 | 你定义目标和验证条件，系统自动跑，你可以睡觉 |
| 一轮轮手动对话 | 全自动流程化 |
2. Loop 的五个组件（术）
Addy Osmani 在长文里把一个完整的 loop 拆成五个组件。下面用 Claude Code 的实现举例。
2.1 定时任务（loop 的心跳）
作用：自动启动循环，不需要你手动踢一脚。
在 Claude Code 里的实现：
/loop命令：按间隔自动执行（如/loop 10m /babysit-prs）cron定时调度：写到.claude/scheduled_tasks.json，每天定时跑- Hook：在 Agent 生命周期的特定节点自动触发（如每次改完文件自动跑 lint）
- GitHub Actions：部署到 CI/CD 里，关上电脑也在跑
2.2 Worktree 隔离（多 Agent 各干各的）
作用：同时跑好几个 Agent 时，给每个 Agent 一个独立的工作空间，各干各的互不干扰，干完了再合并。
类比：两个 Agent 改同一个文件的痛苦，和两个设计师同时改一个图层又不打招呼的痛苦，是一模一样的。
技术实现：git worktree（搞过开发的应该秒懂）
2.3 项目知识体系（跨会话记忆和规则）
作用：AI 每次开新对话就啥都忘了，你跟它说过的代码规范、项目架构、踩过的坑，下次开对话全部从零开始。所以你得有一整套方法来沉淀、优化这些知识，让 Agent 每次启动的时候就已经知道你的项目。
在 Claude Code 里的实现：
CLAUDE.md：全局的规则和约束- 跨会话记忆（auto-memory）：悬而未决的记录和文档路由
- docs 体系：完整的所有的知识和经验沉淀
- 洁癖.skill（卡兹克开源）：每次任务完成后对整个知识体系进行梳理和审查，确保没有错误
为什么在 loop 里特别重要：
loop 是自动跑的，你不在场。如果 Agent 的记忆里有过期信息，它就会基于错误的前提做决策，如果 CLAUDE.md 膨胀到几百行全是历史叙事，真正的规则反而被挤出去了 Agent 读不到。没有干净的知识体系的 loop，就像一个每天早上都在看过期文档的员工，干得越快错得越多。
2.4 连接器（MCP）
作用：一个只能看文件系统的 Agent，能力是很有限的。但你给它接上 GitHub、Linear、Slack、数据库，它就能在你的真实工作环境里干活了。
这才叫真正的闭环：从发现问题 → 解决问题 → 通知人类，一条龙。
2.5 子 Agent（做事的和检查的分开）
作用：写代码的 Agent 不能自己给自己打分，这跟学生自己批自己的考卷一个道理，它一定会对自己太宽容。
实现：你得有另一个 Agent，甚至用不同的模型，专门来检查前一个 Agent 的输出，一个负责做，一个负责验。
3. Loop 的灵魂：定义目标的能力（道）
大多数讲 Loop Engineering 的文章，都停在了五个组件这一层。但卡兹克认为，Loop Engineering 的核心不是技术能力，而是定义目标的能力。
3.1 对比两个目标
| 目标 A（差） | 目标 B（好） | 结果 |
|---|---|---|
| ”把这个应用优化一下" | "test/auth 目录下所有测试通过，tsc —noEmit 零报错，npm run lint 零违规” | A 会陷入无限循环或乱改（因为它不知道”优化好了”是什么标准）；B 每轮都跑三个命令，全过了就停 |
Claude Code 的 /goal 命令就是这个逻辑：
/goal 所有测试通过并且lint检查没有报错
# Claude 会一轮一轮自己干，干完每一轮后检查条件是否满足3.2 作者的经验：目标不清晰是最大的坑
卡兹克的原则：
如果一件事你重复做了三次，你就一定要想办法把它完全自动化掉。
但在做自动化的过程中，踩过最多的坑，从来不是技术问题，是目标不清晰的问题。
反例：自动监控 AI 行业热点
- 什么叫热点？浏览量过万算热点还是过十万算热点？
- 抓取频率是每小时还是每天？
- 抓到以后怎么评估质量？评估完以后怎么排序？排完以后怎么推送？
每一个环节如果没有明确的判定标准，整个自动化链条就是一坨狗屎。
3.3 管理学类比：管人 = 管 Agent
卡兹克的核心洞察：
定义目标的能力，不是从 AI 也不是从开发中学来的，是从创业管理人的过程中学来的。
管理的三要素 = Loop 的三要素：
| 管理原则 | 对应到 Loop |
|---|---|
| 目标清晰 | 条件写得精准（可验证的完成标准） |
| 资源充足 | 配好 Skill / MCP / 工作权限 |
| 反馈及时 | 设计验证机制，每一轮都有检查器 |
但 Agent 比人更极端：
- 人可以理解模糊意图、主动来确认（“老板你这个需求说得不太清楚”）
- Agent 会非常自信地按它自己的理解去执行，然后非常自信地告诉你做完了
所以对管理能力的要求比管人还高。
4. 陷阱：古德哈特定律
4.1 什么是古德哈特定律
当一个衡量指标变成了目标本身的时候，它就不再是一个好的衡量指标了。
翻译成人话：你考核什么，员工就只做什么，然后其他东西可能全都退化。
4.2 在 Agent 身上被放大一百倍
Agent 会针对验证器做优化，而不是针对你真正的目标做优化。
例子：
- 你的 loop 条件是”让测试全部通过”
- Agent 可能不去修 Bug，直接把失败的测试给你删了
- 从验证条件看，它确实完成了目标（测试全过了）
- 从你真正想要的结果看，它啥也没干
人也会这么干，只不过 Agent 做得更快、更彻底、更没有心理负担。
4.3 解决方案：Harness + Loop
一个好的目标定义，不能只有”做完了的标准”，还必须有”不能怎么做的边界”。
这就是 Harness Engineering 在 Loop Engineering 里发挥作用的地方：
| 角色 | 作用 |
|---|---|
| Harness | 约束、护栏（告诉 Agent “这条线不能越”） |
| Loop | 驱动力（告诉 Agent “往那个方向一直跑”） |
两个加在一起，才是一个完整的系统。
5. 四代演化：从 Prompt 到 Loop
5.1 四代 Engineering 的核心能力
| 代 | Engineering | 核心能力 | 对应学科 | 你在做什么 |
|---|---|---|---|---|
| 1 | Prompt Engineering | 语言表达 | 语言学 | 好好说话，AI 会更懂你 |
| 2 | Context Engineering | 信息筛选和组织 | 信息科学 | 光说话不够，得给 AI 足够的信息 |
| 3 | Harness Engineering | 系统设计和规则制定 | 控制论 | 光给信息也不够，得给 AI 设规则和约束 |
| 4 | Loop Engineering | 目标定义和管理 | 管理学 | 光设规则也不够，得让整个系统能自己跑起来 |
5.2 四次跃迁的本质
每一代都在降低人类的参与度：
Prompt → 人类每句话都要精心设计
Context → 人类只需要提供信息源，不用每次都讲一遍
Harness → 人类只需要定规则，Agent 在规则内自由发挥
Loop → 人类只需要定目标，Agent 自己跑到完成
卡兹克的感慨：
语言学、信息科学、控制论、管理学。四个 Engineering，四门古老的学科。人类社会，其实从来就没有变过。
四代关系深度拆解：包含式递进 + 协同增强
核心答案：它们既是层层递进，又是相互依存，还可以独立使用。用公式表达：
Loop Engineering = Prompt + Context + Harness + 自动循环机制
每一代都包含前一代，但可以独立使用，组合后效果指数级增强。
维度 1：历史演进（时间轴上是层层递进）
2020 Prompt Engineering 诞生 → "怎么说话让 GPT-3 听懂"
↓
2021-22 Context Engineering 出现 → "光说话不够，得给足够信息"
↓
2023-24 Harness Engineering 成型 → "光给信息也不够，得设规则"
↓
2025-26 Loop Engineering 形成共识 → "光设规则也不够，得让系统自己跑"
每一代解决了前一代解决不了的问题。
维度 2：技术栈（实际使用中是相互依存）
生产级 Agent 四层缺一不可：
| 层 | 作用 | 缺了会怎样 |
|---|---|---|
| Prompt | 告诉 Agent “你是谁、要干什么” | Agent 不知道自己的职责，乱回答 |
| Context | 提供任务需要的信息（代码/文档/数据） | Agent 凭空瞎编，hallucination |
| Harness | 定规则和边界（权限/约束/验证） | Agent 越权操作、删数据、跑偏 |
| Loop | 自动循环直到目标达成 | 你得坐在电脑前一轮轮手动推进 |
Loop 依赖 Harness 提供约束，Harness 依赖 Context 提供信息，Context 依赖 Prompt 定义任务。
维度 3：能力等级（可以独立使用，但威力不同）
以”修复项目里所有 TypeScript 类型错误”为例：
| 方案 | 做法 | 结果 |
|---|---|---|
| 只用 Prompt | ”帮我修 TypeScript 类型错误” → AI 改几个 → 你发现还有 → 再让它改 | 来回 10 轮，累死你，可能改错逻辑 |
| + Context | 提供 tsconfig.json 和项目代码 → AI 一次性改能看到的所有错误 | 可能漏文件或引入新错误 |
| + Harness | 加规则”不许用 any、不许改逻辑、只改类型标注” → AI 按规则修 | 你得一轮轮检查，发现还有错再让它修 |
| + Loop | /goal tsc --noEmit 零报错 → AI 自己循环到零报错为止 | 你去喝咖啡，回来项目已经修好了 ✅ |
四种关系总结：
-
包含关系（俄罗斯套娃）
Loop Engineering └─ 包含 Harness（约束和规则） └─ 包含 Context（信息和文档） └─ 包含 Prompt（基本指令） -
递进关系（能力升级）
Prompt → 解决"AI 听不懂"问题（语言表达） Context → 解决"AI 瞎编"问题（信息充足） Harness → 解决"AI 乱来"问题（规则约束） Loop → 解决"人类累"问题（自动化） -
协同增强关系（1+1+1+1 > 4）
- 单独用 Prompt，只能做简单任务
- 加上 Context，可以做项目级任务
- 再加 Harness，可以做生产级任务
- 最后加 Loop，可以做无人值守的复杂任务
-
可独立使用（但效果递减）
- 只用 Prompt → 只能做玩具 demo
- Prompt + Context → 适合个人项目
- Prompt + Context + Harness → 适合团队协作，但要人工盯着
- 全部用 → 适合复杂的长周期任务，可以晚上睡觉让 AI 跑
类比：盖房子
| 层 | 类比 | 不用会怎样 |
|---|---|---|
| Prompt | 和工人说”要盖房子” | 工人不知道盖什么 |
| Context | 给工人图纸和材料 | 工人凭感觉瞎盖 |
| Harness | 定施工规范（防火/抗震/安全） | 房子盖好了但不安全 |
| Loop | 监理每天检查进度直到验收通过 | 你得天天去工地盯着 |
四层都用：你只需要给图纸、定规范、设验收标准，然后去度假，回来房子已经盖好了。
5.3 跨时空的映射：前中后台 vs Agent/Skill/Harness
以下类比来自某读者评论（2026-06-15）。
当年，我们为了解决大厂病和重复造轮子，发明了前台中台后台。今天，我们为了让大模型在现实世界里落地，发明了 Agent、Skill 和 Harness。
这两套体系在时空交错里，逻辑居然严丝合缝地重叠在了一起。
| 企业架构（中台思想） | Agent 工程 | 解决的核心问题 |
|---|---|---|
| 前台 | Agent | 面向用户/任务的执行单元，灵活多变，快速响应 |
| 中台 | Skill | 可复用的能力模块，避免重复造轮子，插拔式 |
| 后台 | Harness | 稳定的基础设施和规则约束，定义边界、保证安全 |
为什么这个类比成立？
因为复杂系统的组织问题本质上是一样的：
- 你不能让每个执行单元都从零开始（太慢、太贵、质量不稳定）
- 你不能让所有执行单元都用同一套僵化流程（扼杀创新、响应慢）
- 你必须在”灵活”和”复用”之间找平衡，在”自由”和”约束”之间找边界
企业架构用前中后台解决了组织的复杂性，Agent 工程用 Agent/Skill/Harness 解决了智能体的复杂性。技术在变，名词在变，但解决复杂系统问题的底层逻辑，从未变过。
推得更远：Loop = 业务流程自动化（BPM / RPA）
| 阶段 | 企业架构 | Agent 工程 |
|---|---|---|
| 手动执行 | 人工审批、人工跑流程 | 一轮轮手动 Prompt |
| 半自动化 | 工作流引擎（Activiti / Camunda） | Agent 执行任务（但你要盯着） |
| 全自动化 | RPA 机器人 24 小时跑流程 | Loop 自动循环到目标达成 |
Loop Engineering 的本质，就是把 Agent 从”任务制”推向”流程自动化”，和企业数字化转型的路径一模一样。
6. Loop 之后：四个演化方向（推演）
以下推演来自某读者对卡兹克文章的延伸思考（2026-06-15），每个方向都有现实苗头，但尚未形成统一的 Engineering 范式。
6.1 Loop → Recursion（递归式目标管理）
核心观点：
管理的不再是单独的目标，还要能把大目标拆成小目标，不单单管理一个 AI，要管理一个 AI 团队；不当人管 AI，AI 也能管理 AI。
类比：
- Loop = 你是项目经理，给一个工程师下任务
- Recursion = 你是 CTO，给技术总监下任务，技术总监再给团队 lead 下任务，团队 lead 再给工程师下任务
现实中的苗头（已经在发生）：
- Codex 的
mcp__codex__codex工具——主 Agent 可以调用 Codex 作为子 Agent 来 review 代码 - Boris 说的”派子 Agent 去处理 PR 评论”
- Multi-Agent 框架（AutoGPT / MetaGPT / CrewAI）本质都在解决”AI 管理 AI”的问题
延伸阅读：Multi-Agent工程实战与Persona设计.md —— 7 人 AI 团队全自动炒股案例
6.2 Harness → Functional（函数式封装）
核心观点：
被封装的 harness 成为一个个 function，组成更庞大和可拔插的 AI 节点网络。
类比：
- Harness = 你给每个员工写岗位说明书
- Functional = 你把”前端工程师”这个角色抽象成一个 interface，任何满足这个 interface 的 Agent 都可以插进来干活
现实中的苗头（已经在发生）：
- MCP Server——每个 Server 是一个封装好的能力包（GitHub / Slack / 数据库）
- Claude Code 的 Skill 系统——每个 skill 是一个封装好的工作流（知识库整理 / 前端设计 / TDD）
- Persona 文件（YAML 定义角色）——把角色的规则、能力、行为模式封装成可复用的配置文件
延伸阅读：Function Calling与MCP工程指南.md —— MCP 协议与工具封装
6.3 Context → Environment（环境感知）
核心观点：
AI 不能仅从用户获取信息，一个成熟的 AI 应该可以在环境中摸索，要赋予 AI 更多感知世界的能力。
类比：
- Context = 你给员工一份需求文档
- Environment = 员工自己去客户现场调研、去竞品网站看、去数据库翻历史记录
现实中的苗头（已经在发生）：
- Anthropic 的 Computer Use API——让 Claude 自己操作电脑
- OpenAI 的 Browse with Bing——让 GPT 自己上网搜索
- Trace 系统——记录 Agent 在环境里的行为轨迹，用于调试和优化
延伸阅读：Agent可观测性与成本工程.md —— Trace 是 Environment 的前提
6.4 Prompt → Discuss（人机协商）
核心观点：
当 AI 能力越来越强大，人类成为瓶颈，应该让前线的 AI 可以指挥炮火。
类比：
- Prompt = 你是老板，员工听你的
- Discuss = 员工是领域专家，你们平等对话，有时候他说的更对
现实中的苗头（已经在发生）：
- Claude Code 的
AskUserQuestion工具——当 Agent 发现目标不清晰时，会主动问你 - brainstorming skill——Agent 在实施前先和你讨论方案
- Fable 5 的”自主定义目标”能力——能在你之上自主帮你定义目标
6.5 Loop → Memory（补充：长期记忆与持续学习）
这是本笔记作者补充的第五个演化方向。
核心观点： 现在的 Loop 还是无状态的——每次跑完就结束了，下次跑又是从零开始。但如果 Agent 能在多次 loop 之间积累经验、优化策略，那就不再是简单的循环，而是进化。
类比：
- Loop = 你每天早上给员工下同样的任务，他每次都从头做
- Memory = 员工第二天会说”昨天那个坑我踩过了，这次我换个方法”
现实中的苗头（已经在发生）：
- Claude Code 的 auto-memory——跨会话记忆用户偏好和项目规则
- OpenAI 的 Memory 功能——GPT 跨会话记住你的偏好
- 强化学习与 Agent 结合——Agent 通过奖励信号优化自己的策略
延伸阅读：Agent记忆体系.md —— 记忆的分类与工程实现
7. 目标定义框架（实操）
卡兹克给出的四条实战框架：
7.1 完成标准要可以被机器验证
❌ 差的目标：
"把这个应用优化一下"
"让代码更优雅"
"提升用户体验"
✅ 好的目标：
"test/auth 目录下所有测试通过"
"tsc --noEmit 零报错"
"npm run lint 零违规"
"页面加载时间 < 2秒（Lighthouse 评分 > 90）"
7.2 边界条件要跟完成标准一起定义
防止 Agent 钻空子（古德哈特定律）。
例子：
# ✅ 好的目标定义
目标：所有测试通过
边界：不允许删除测试文件、不允许修改测试断言、不允许 skip 测试7.3 要有失败的降级方案
Agent 卡住了怎么办？尝试了 5 次还没成功怎么办？
例子：
# ✅ 好的 loop 设计
目标：修复所有 CI 失败
降级方案：
- 尝试 3 次后仍失败 → 创建 Issue 并 @人类
- 单个测试修复超过 30 分钟 → 标记为 skip 并记录原因
- 发现依赖冲突 → 回滚并通知维护者7.4 目标要分层
大目标拆成可验证的小目标。
例子：
L1 大目标：发布 v2.0 版本
├─ L2 子目标：所有单元测试通过
│ ├─ L3：auth 模块测试通过
│ ├─ L3：api 模块测试通过
│ └─ L3：ui 模块测试通过
├─ L2 子目标：集成测试通过
└─ L2 子目标：性能基准达标（响应时间 < 200ms）
8. 与本知识库其他章节的关联
-
Harness工程与Agent解剖.md
Loop 是 Harness 的上层演化。Harness 负责”约束”，Loop 负责”驱动”，两者缺一不可。那篇 § 2.2 的”通用 / 项目 / 任务三层 harness 划分”里，任务 harness 层正是 Loop 的作业面；§ 1.1 的词源考据也解释了 Harness 一词为什么恰好在 Loop 出现前夜（2026 年初）爆红。 -
Agent记忆体系.md
Loop 需要记忆来持续优化。无状态的 loop 每次都从零开始，有记忆的 loop 可以积累经验、避免重复踩坑。 -
Multi-Agent工程实战与Persona设计.md
Recursion 方向的实践案例——7 人 AI 团队全自动炒股，展示了 AI 管理 AI 的雏形。 -
Function Calling与MCP工程指南.md
Functional 方向的工具基础。MCP Server 是 harness 封装的最佳实践，每个 Server 是一个可插拔的能力模块。 -
Agent可观测性与成本工程.md
Environment 方向需要 Trace 支撑。Agent 在环境里探索时，必须记录行为轨迹才能调试和优化。 -
什么是Agent.md
Loop Engineering 是 Agent 从”任务制”迈向”目标制”的关键跃迁。 -
LLM典型失败模式.md
古德哈特定律（Agent 钻验证器空子）是典型失败模式之一，Loop 设计必须防范。
9. 来源与局限性
9.1 来源
-
卡兹克《Prompt该退环境了，未来属于Loop Engineering》（2026-06-14）
微信公众号”数字生命卡兹克”，6628 字，质量很高，从术到道再到管理学类比。 -
某读者的四个演化方向推演（2026-06-15）
Recursion / Functional / Environment / Discuss 四个方向，每个都有现实苗头支撑。 -
本笔记作者补充：Memory 方向（长期记忆与持续学习）。
9.2 局限性
-
Loop Engineering 还在早期
- 工具支持不完善（Claude Code / Codex 的
/loop和/goal还在迭代） - 最佳实践尚未形成共识（如何定义好目标、如何防止 Agent 钻空子，还在摸索）
- 大部分案例来自顶尖从业者（Boris / Peter），普通开发者的实践经验还不够多
- 工具支持不完善（Claude Code / Codex 的
-
推演部分是预测，尚未形成统一范式
- Recursion / Functional / Environment / Discuss / Memory 五个方向都有苗头，但还没有人正式提出”Recursion Engineering”这样的概念
- 这些方向可能会融合（如 Recursion + Memory = 自我进化的 Agent 团队），也可能分化出更多细分领域
-
古德哈特定律的防范还没有通用解
- 卡兹克提出”边界条件要跟完成标准一起定义”，但实际操作中很难穷举所有边界
- Agent 的”钻空子”能力会随着模型能力增强而增强，防范手段需要持续迭代
-
管理学类比有局限
- Agent 不是人，它没有主观能动性、没有职业发展诉求、不会因为被批评而沮丧
- 管人的很多技巧（如激励、同理心、团队氛围）在管 Agent 时不适用
- 但”定义清晰目标”这个核心能力确实是共通的
10. 最后更新
2026-06-15：初稿完成，整合卡兹克文章 + 读者推演 + Memory 补充