目录

• 第一章：Loop Engineering 通俗介绍
• 第二章：核心内容点及设计原因
• 第三章：Loop Engineering 与 Harness Engineering 的关联
• 第四章：在 AI Coding 中运用 Loop Engineering
• 第五章：未来发展趋势展望
• 参考文献

---

前言概要

本报告共五章，约 840 行。如果你只有 3 分钟，读完这一页就够了。

第一章：Loop Engineering 通俗介绍 — Loop Engineering 是设计「让 AI Agent 自己提示自己」的系统。你从「手动对话者」变成「自动化生产线设计师」。它由 Peter Steinberger、Boris Cherny、Karpathy 三个独立信号在 2026 年 6 月同时引爆，本质是 Prompt Engineering → Context Engineering → Loop Engineering 的第三次抽象层跃迁。Loop ≠ 定时任务——关键区别在于循环内部有一个能判断、能决策、能从失败中学习的 Agent。

第二章：核心内容点及设计原因 — 一个 Loop 由六要素构成：trigger + context + action + verification + state + retry/stop rules。Boris Cherny 定义了五大构建块（Automations、Worktrees、Skills、Connectors、Sub-agents）加 Memory。Claude Code 源码揭示了六条防线让循环稳定运行：多出口防卡死、看行动不看自报、反馈伪装成 user 消息、自然收敛配硬刹车、State 原子传递、TodoWrite 对冲遗忘。成本公式 迭代次数 × token × 并行实例数 提醒我们：Loop Engineering 不只是工程问题，也是经济问题。

第三章：与 Harness Engineering 的关联 — Loop 不是替代 Harness，而是在 Harness 之上加了两个关键能力：Automations（自动触发） 和 Memory（跨次记忆）。Harness 是「接住 Agent 的产出」，Loop 是「让 Agent 自己决定什么时候产出」。四层体系（Prompt → Context → Harness → Loop）层层包裹，内层从不消失。Inner Loop 管单次执行质量，Outer Loop 管跨会话知识沉淀，两者形成复利循环。

第四章：在 AI Coding 中运用 — 建 Loop 前先过三条检查：有可衡量 metric？失败代价可控？Harness 够硬？工作按适合度分三区——绿区（CI 修复、依赖更新等）强烈推荐，黄区（PR 审查、文档生成等）需人在关键节点，红区（架构设计、产品策略等）不建议 Loop 化。落地路径是渐进式的：从单个 Automation 观察一周开始，逐步加入 Maker-Checker 分离，最后扩展到多 Loop + Outer Loop 知识沉淀。

第五章：未来趋势展望 — 抽象层还会往上叠（Loop → Fleet），Metric 自动化会通过 AI 评估、组合信号、人类偏好学习三个方向突破，Inner/Outer Loop 融合会让 Agent 越用越聪明。但三个风险只会更尖锐而非消失：理解力债务（代码出货快于你理解的速度）、认知投降（停止思考接受一切）、自主性与安全性的张力。人设计 Loop，但设计 Loop 的那个人，不能停止当工程师。

---

第一章：Loop Engineering 通俗介绍

1.1 一句话定义

Loop Engineering 是设计「让 AI Agent 自己提示自己」的系统，而不是你亲自去提示它。

更准确地说：Loop Engineering 是构建一套自动化的闭环系统——它能按计划唤醒 AI Agent、给它分配任务、让它执行、验证结果、记住进度，然后决定下一步该做什么——整个过程不需要人坐在屏幕前逐条输入指令。

1.2 用日常类比理解

想象你经营一家面包店：

阶段	你的角色	类比到 AI Coding
手工烘焙时代	你亲手揉面、烤面包、检查品质	Prompt Engineering：你手动写提示词，一问一答地跟 AI 对话
半自动化时代	你买了搅拌机和烤箱，但每一步都要按按钮	Harness Engineering：你给 AI 搭好约束环境（测试、CI/CD），但每次任务都要人来触发和审查
全自动生产线	你设计了一条完整的生产线——原料自动进料、自动搅拌、自动烤制、自动质检、不合格的自动回炉	Loop Engineering：你设计一个闭环系统，AI 自动发现任务、自动执行、自动验证、自动迭代

关键区别：你从「操作员」变成了「生产线设计师」。你不再亲手做面包（写代码），也不再按按钮启动机器（手动提示 AI），而是设计那条能自己运转的生产线。

1.3 这个概念从哪来的？

Loop Engineering 在 2026 年 6 月集中爆发，三个独立信号同时指向了同一个方向：

Peter Steinberger（OpenClaw 作者）：

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

他用 50 个 Codex 并行审查 3,000 个 PR，单日 627 次提交。他不是在讲理论——他每天就在这么干。

Boris Cherny（Anthropic Claude Code 负责人）：

“I don’t prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops.”

他定义了 Loop 的五大构建块（Automations、Worktrees、Skills、Connectors、Sub-agents + Memory），把 Loop Engineering 从一个模糊概念变成了可操作的工程框架。

Andrej Karpathy（前 Tesla AI 总监）：用 630 行 Python 让一群 Agent 自主跑了 700 次实验，发现 20 个优化，实现 11% 的训练加速。他说：

“The goal is not to emulate a single PhD student, it’s to emulate a research community of them.”

Shopify CEO 复刻了 Karpathy 的做法：一个晚上跑了 37 次实验，内部 AI 模型性能提升 19%。

1.4 Loop Engineering 和之前那些概念有什么区别？

很多人会困惑：这和 Prompt Engineering、Context Engineering 到底有什么不同？下面这张表一目了然：

维度	Prompt Engineering	Context Engineering	Loop Engineering
你在优化什么	单条提示词的措辞	输入给模型的上下文信息	自动运行的闭环系统
工作单元	一次你手动输入的对话	围绕一次回答的条件设置	跨越多轮的自运行循环
人的角色	对话者	信息策展人	系统设计师
核心问题	“怎么问？”	“给它看什么？”	“怎么让它自己跑起来，还能自己停下来？”
时间线	2023-2024	2024-2025	2026 至今

重要澄清：这三层不是替代关系，而是包裹关系。Loop 里面包着 Context，Context 里面包着 Prompt。Loop Engineering 不是说 Prompt 不重要了——一个 Loop 里面的烂 Prompt 只会更快地生产垃圾。

1.5 Loop 不等于 Cron Job

有人会说：「这不就是定时任务吗？」

不是。 关键区别在于循环内部的决策者：

• Cron Job 运行固定脚本：每次执行完全相同的操作，不管结果如何。
• Loop 运行一个有判断力的 Agent：它会查看当前状态、选择下一步行动、执行、检查结果，然后决定下一步——继续、重试、回滚，还是停止。

用 Louis-François Bouchard 的话说：

“A cron job runs a fixed script. A loop runs an agent that looks at the current state, chooses the next action, does it, checks the result, and decides what to do next.”

一个 Loop 至少需要两个前提才能工作：

1. 触发器（Trigger）：什么启动这个循环——可以是 PR 打开、CI 失败、定时调度、Slack 消息，或者你手动输入的一条命令。
2. 可验证的目标（Verifiable Goal）：什么告诉循环可以停下来——可以是确定性的（所有测试通过、CI 变绿），也可以是柔性的（一个审查模型判断 UI 是否符合设计稿）。

没有可验证的目标，你建的不是 Loop，而是一台「自信的 Token 焚烧炉」。

1.6 是 Buzzword 吗？

坦率地说，是，也不是。

是 Buzzword 的部分：把本来就存在的事（自动化工作流 + CI/CD + 定时任务）换了一个新名字，然后宣称是「范式转移」。如果你之前就有好的 CI/CD、好的测试、好的 Agent 约束，你已经在做 Loop Engineering 的一部分了。

不是 Buzzword 的部分：LLM Agent 带来的真正新能力是「读上下文、产生假设、从失败中学习」。这不是传统的 cron job + 脚本能做到的。Karpathy 的 700 次实验不是随机搜索，是 Agent 在读之前的实验结果、形成新假设、写新代码。这是质的差异。

1.7 本章小结

Loop Engineering 的本质，可以浓缩为一句话：

人设计 Loop，Loop 提示 Agent，Agent 执行并验证，结果反馈回 Loop。人从「每一步都要参与」变成「设计系统、审查结果」。

但这不意味着人变得不重要——恰恰相反。每往上一个抽象层，你需要理解的东西更多，不是更少。你从写代码，到写 Prompt，到建 Harness，到设计 Loop。设计 Loop 的那个人，不能停止当工程师。

---

第二章：核心内容点及设计原因

2.1 Loop 的公式

Reddit 上一位务实派开发者给出了目前最简洁的 Loop 定义公式：

loop = trigger + context + action + verification + state + retry/stop rules

要素	含义	缺少会怎样
Trigger	什么触发循环启动（定时、事件、手动）	循环永远不会开始
Context	Agent 每轮能看到什么信息（代码、历史、规则）	Agent 盲猜，产出质量低下
Action	Agent 能做什么操作（编辑文件、运行命令、调用 API）	Agent 只能说不能做，沦为聊天机器人
Verification	怎么判断这一步做对了（测试通过、类型检查、审查模型）	Agent 自我感觉良好地一直跑下去
State	跨轮次的记忆（做到哪了、上次结果是什么）	每轮从零开始，第 15 轮忘了第 1 轮的目标
Retry/Stop Rules	什么时候重试、什么时候停止	要么卡死不动，要么无限空转烧钱

这六个要素缺一不可。缺少任何一个，Loop 就会退化为一个更低效的系统——要么是不会验证的盲跑脚本，要么是没有记忆的健忘症 Agent。

2.2 五大构建块 + Memory

Boris Cherny 在 Addy Osmani 的访谈中定义了构成一个 Loop 的五大构建块，加上一个贯穿始终的 Memory 层。这是目前业界引用最广的 Loop 架构框架：

构建块一：Automations（自动触发）

Automations 是 Loop 的心跳——让循环真正成为循环而不是一次性运行的关键。它是一个定期触发的发现和分类流程，不需要人来启动。

实现方式：

• OpenAI Codex：在 App 中提供 Automations 标签页，可以选择项目、设定运行 Prompt、调度频率。找到工作就进入 Triage 收件箱，没找到就自动归档。
• Claude Code：通过 /loop 命令设置定时运行的 Prompt（本质上转化为 cron job），也可以推送到 GitHub Actions 让它在关闭笔记本后继续运行。/goal 命令则持续运行直到一个可验证的条件成立。

设计原因：人不可能 24 小时盯着屏幕。如果每次都需要人来输入第一条指令，Loop 的吞吐量就被人的注意力瓶颈锁死了。Automations 解放了这个瓶颈——你设计好触发条件，系统自己发现工作。

构建块二：Worktrees（并行隔离）

当你同时运行多个 Agent 时，文件冲突是第一个要解决的问题。两个 Agent 同时写同一个文件，和两个工程师在同一行代码上提交但互不沟通，是完全一样的灾难。

Git Worktree 的方案：为每个 Agent 创建一个独立的工作目录和分支，共享同一份仓库历史，但彼此的编辑物理隔离。

实现方式：

• Codex：内建 worktree 支持，多个线程可以并行操作同一仓库。
• Claude Code：通过 --worktree 标志或 sub-agent 配置中的 isolation: worktree 实现。

设计原因：Loop 的价值很大程度上来自并行——同时让多个 Agent 处理不同任务。没有隔离机制，并行就是灾难。但 Worktree 只解决了机械层面的冲突，审查瓶颈仍在你身上——你能审查和合并多少变更，才是并行上限的真正天花板。

构建块三：Skills（知识编码）

Skill 是把项目知识写下来，让 Agent 不用每次从零开始猜你的项目规范。

格式统一为一个包含 SKILL.md 的文件夹，里面是指令、元数据，以及可选的脚本和参考资料。Agent 在任务匹配 Skill 描述时自动加载。

设计原因：Agent 每次会话都是冷启动的——它不记得上次你告诉过它什么。没有 Skill 的 Loop，每一轮都要重新发现你的项目结构、编码规范、构建命令。这不仅浪费 Token，更会导致每次猜测的结果不一致。Skill 让知识在循环间复利累积，而不是每轮归零。

Louis-François Bouchard 特别强调：

“A loop with no reusable skills just rediscovers your project from zero every run. It burns tokens re-learning what you already know. A loop with good skills starts to compound.”

最佳实践：一个 Skill 对应一个任务，尽可能密集，不要用大段 Skill 填满上下文。然后让 Agent 建立索引，自动检索需要的 Skill。

构建块四：Connectors / Plugins（外部工具连接）

一个只能看文件系统的 Loop 是一个微小的 Loop。Connectors 基于 MCP（Model Context Protocol），让 Agent 能读你的 Issue Tracker、查数据库、调用 Staging API、在 Slack 发消息。

设计原因：现实中的软件开发不只是编辑代码文件。开 PR、关联 Jira、跑 CI、通知团队——这些都是工作流的一部分。没有 Connectors，Loop 生产的代码只能停在本地，无法完成从「代码变更」到「交付上线」的最后一公里。

Daniel Demmel 进一步指出，CLI 工具是目前 Agent 最好的接口：

“CLI tools that are pipeable and progressively explorable are the optimal interface for current AI models… text-in, text-out interfaces are what these models are most fluent with.”

这和 Unix 哲学不谋而合——小工具、单一职责、文本流连接——半个世纪前的设计原则，在 AI Agent 时代重新焕发价值。

构建块五：Sub-agents（制作者与检查者分离）

一个 Loop 中最关键的结构性决策：写代码的 Agent 和审查代码的 Agent 必须分开。

模型对自己的作业打分太慷慨了。一个写了代码的 Agent，让它自己审查，它会说「看起来不错」——因为它倾向于合理化自己刚才的决策。用第二个 Agent（甚至不同的模型）来审查，才能捕捉第一个 Agent 说服自己忽略的问题。

实现方式：

• Codex：在 .codex/agents/ 下定义 TOML 文件，每个 sub-agent 有独立的名称、指令、模型和推理强度。安全审查用强模型高强度，探索性任务用快模型只读模式。
• Claude Code：在 .claude/agents/ 下定义，支持 agent teams 在 agent 之间传递工作。/goal 命令的底层就是用一个独立的小模型来判断循环是否完成——做工作的和判断完没完的，不是同一个。

设计原因：Loop 在你不看的时候运行——一个你真正信任的验证者是你能离开的唯一理由。制作者-检查者分离不是可选的优化，而是 Loop 能无人值守运行的必要条件。

第六要素：Memory（跨次记忆）

Memory 是所有长时间运行 Loop 的脊柱。Skills 存放的是持久的项目知识（我们怎么构建、规范是什么），Memory 存放的是变化中的状态（什么已完成、什么还在进行、下一步是什么）。

它可以是一个 Markdown 文件、一个 Linear Board、一个 GitHub Issue 列表。唯一的要求是：它必须活在上下文窗口之外，因为模型在两次运行之间会忘记一切。

Agent 会遗忘，但仓库不会。

设计原因：没有 Memory，明天早上的运行不知道今天下午做到了哪里。每次循环都从头开始，之前所有的工作成果都白费了。Memory 让 Loop 具备了跨会话的连续性——这是 Loop 和单次 Agent 对话的本质区别之一。

2.3 三种 Loop 的层次

虽然大家都在说 Loop Engineering，但仔细看会发现，不同人嘴里的「Loop」指的是三个不同层次的东西：

Karpathy Loop：单一指标的自主研究循环

Karpathy 用 630 行 Python 构建的系统非常纯粹。每一轮做三件事：

1. 读研究论文和过去的实验记录
2. 产生假设并编写代码修改
3. 跑实验，测量一个明确的指标（训练速度）

关键数据：700 次实验、2 天、20 个有效发现、11% 训练加速。

关键限制：你需要一个可以自动衡量的 metric。有 metric 就能 loop，没有 metric 就只能靠人判断。Karpathy 自己也区分了这和 AutoML 的差别——AutoML 是随机搜索超参数，Karpathy Loop 是 Agent 读论文、形成假设、写代码、从失败中学习。

适用场景：机器学习训练优化、性能基准测试、任何有明确量化指标的探索性任务。

Boris Loop：多 Agent 开发工作流的编排

Boris Cherny 讲的是另一个维度。他的 Loop 是一套由五大构建块 + Memory 组成的完整开发工作流编排系统（详见 2.2 节）。这不是一个 Agent 跑很多次实验，而是多个 Agent 按角色分工协作——有的做分类、有的写代码、有的做审查——通过自动调度和状态持久化串联成一个自运行的开发流水线。

适用场景：日常软件开发中的重复性工作——CI 失败修复、Issue 分类、PR 审查、依赖更新等。

Reddit 实用派 Loop：只在边缘加循环

一位 Reddit 用户给出了最务实的定义。他把自己的工作流分成两段：

适合 Loop 化的部分（重复、可验证、风险可控）：

• 收集候选素材、去重、检查来源
• 验证链接有效性、事实查核、图片校验
• 输出草稿但不发布

不适合 Loop 化的部分（需要判断、创意、掌舵）：

• 选题决策、观点建构、叙事结构、最终定稿

他的结论是最清醒的一句话：

“Maybe loop engineering is more ‘add memory, verification, and guardrails around repetitive or risky parts.’”

不是把整个工作流 Loop 化，而是在重复和高风险的环节加上记忆、验证和护栏。其余需要判断和创意的部分，仍然是你的工作。

2.4 Agent Loop 源码级的六条防线

ATA 文章《Agent Loop：转圈的艺术》对 Claude Code 的 Agent Loop 源码做了深入解析，揭示了一个能稳定运行的 Loop 需要的六道防线。这些防线回答了一个核心问题：为什么同一个模型在 Claude Code 里三五轮就能修绿测试，换一个粗糙的循环框架却二十轮原地震荡？

差别不在模型的能力，而在循环本身怎么写。

防线一：多出口防卡死

Claude Code 的循环核心是 while (true)——语法上的无限循环。但它在循环体内散布了多个 return 出口：

出口	触发条件	含义
reason: 'completed'	模型本轮没有调用任何工具	自然收敛，活干完了
reason: 'max_turns'	轮数超过 maxTurns 上限	硬刹车，强制踢出
reason: 'model_error'	模型调用出错	异常退出，带着错误信息离开

设计原因：如果出口只有一个（靠模型自报"我完成了"），那种原地震荡的循环永远停不下来。多出口是循环不被自己卡死的第一层保险。

防线二：看行动不看自报

Claude Code 判断「模型有没有做完」的标准，不是模型嘴上说的 stop_reason（那个不可靠），而是它这一轮有没有真的往 toolUseBlocks 数组里塞过工具调用。

模型嘴上说「我已经做完了」不算数，它伸不伸手去调工具才算数。

设计原因：这正是早年 AutoGPT 最出圈的吐槽的镜像——「它会兴高采烈地一直转下去，自我感觉良好地把任务做歪。」根因是信了模型自报的「完成」。模型是一个会自我感觉良好的协作者，把停不停的决定权交给它，等于把刹车交给一个看不清路的人。

防线三：反馈伪装成 user 消息流回

工具执行完的结果，被 Claude Code 规整成 user 角色的消息塞回对话流。这是一个微妙但关键的设计：

在模型的处理权重中，system 消息被当背景设定，assistant 消息被当自己说过的话，而 user 消息被当作「需要回应的新输入」。文件内容、测试报错、命令输出，全都顶着 user 的身份流回来，模型于是天然地把它当作「我必须回应的新情况」。

设计原因：如果工具结果被截断、压缩或降级为 system 旁白，反馈回路的信噪比就崩了。模型拿到的不再是现实的精确回话，它只能猜——而猜，就意味着下一轮出错的概率大于零。一个角色标签的选择，决定了反馈到底会不会被模型认真对待。

防线四：自然收敛配硬刹车

自然收敛（模型没调工具 → 判定完成）是优雅出口。但闭环控制器有个尴尬：它不保证一定收敛。所以 Claude Code 配了硬刹车——maxTurns。转够指定轮数还没停，不管模型多想继续，return 直接踢出循环。

设计原因：这是一种「服软式设计」——承认控制器会卡住，所以配一根熔断丝。与其假装系统完美，不如诚实地为失控预留出口。

防线五：State 原子传递记忆

每轮结束若决定继续，Claude Code 不是修改旧的 State 对象，而是整包替换成一个全新的 State：

新 State = 老消息 + 模型刚说的话 + 工具刚返回的结果

设计原因：整包替换而不是逐字段修改，让「一轮结束」成为一个干净的原子操作——要么完整跨进下一轮，要么不跨，中间不留半新半旧的脏状态。State 就是循环的「工作记忆」，认知科学里人做多步骤任务时脑子里挂着的「我做到哪了」。

防线六：TodoWrite 对冲遗忘

循环转得越久，模型越容易忘了自己原本要干嘛。上下文里堆了十几轮工具输出，最初的目标早被淹在底下。

Claude Code 的 TodoWriteTool 让模型把任务清单写到循环外面去——三步以上的任务就该列清单，收到新指令就记下来，动手前先标为「进行中」，同一时刻只许一个 todo 处于进行中。

更妙的是收尾时的小动作：当模型关掉 3 项以上的 todo 却没有一项是「验证」步骤时，系统会追加一句提醒——「你确定不验证一下？」恰好在循环要退出、最容易偷懒的那一刻触发。

设计原因：没有外化记忆的长循环，会在第 15 轮丢掉第 1 轮的目标，把一个明确任务跑成一团发散的瞎忙——这是有别于原地震荡的另一种死法：方向漂移。

六条防线的实验验证

《Agent Loop：转圈的艺术》作者真的跑了 64 个多轮试次（4 组 × 8 任务 × 2 重复），每轮代码用 Python 3.12 真跑隐藏测试。实验证明：

• 拆掉反馈回路（不把工具结果喂回模型）→ 循环退化成开头那台二十轮修不绿的坏机器
• 拆掉硬刹车（不设 maxTurns）→ 循环可能无限空转
• 拆掉 TodoWrite→ 长任务方向漂移，第 15 轮忘了第 1 轮的目标

每一道防线的存在，都不是理论推导，而是「少了它循环就死」的实证结果。

2.5 Loop 的成本结构

这是大部分 Loop Engineering 讨论中被跳过的关键部分。

手动 Prompt Agent 的成本是线性的——打一次 prompt、花一次 token、看一次结果。Loop 的成本结构完全不同：

成本 = 迭代次数 × 每次 Agent 调用的 token × 并行实例数

三个乘数同时作用，成本可以指数级增长。举几个真实场景：

场景	成本估算
Karpathy 700 次实验，每次约 12K token	约 840 万 token
加上 sub-agent 做验证	成本直接翻倍
Loop 在你睡觉时也在跑	醒来时账单可能已经失控

必须的成本控制机制：

1. 固定时间限制：Karpathy Loop 的第三要素就是「每次实验有固定时间限制」，同时也是成本上限
2. Budget Cap：设定每个 Loop 的 token 预算，超过就停
3. 收敛检测：如果连续 N 次迭代都没有改善 metric，自动停止，不要空转烧钱
4. 分层用模型：Loop 里的初筛用便宜模型（如 Haiku），只在关键判断点用贵模型（如 Opus）

ROI 计算也变了：以前是「AI 帮我省了多少小时人力成本」，现在是「Loop 的 API 成本 + 设计成本，有没有低于它发现的价值」。Karpathy 的 11% 训练加速，对一个前沿 AI 实验室来说，省下的 GPU 时间远超 API 成本。但如果你的 Loop 只是自动跑 lint 然后开 PR，先算一下 token 账单再决定值不值得。

Loop Engineering 不只是工程问题，也是经济问题。设计 Loop 的时候，停止条件和成本上限跟循环逻辑一样重要。

2.6 本章小结

Loop Engineering 的核心可以用一句话概括：用可验证的目标驱动、有记忆的闭环系统，替代人工逐条提示的线性交互。

它的五大构建块（Automations、Worktrees、Skills、Connectors、Sub-agents）加上 Memory，构成了从发现任务到验证交付的完整闭环。而 Claude Code 源码级的六条防线（多出口、看行动不看自报、user 角色伪装、自然收敛+硬刹车、State 原子传递、TodoWrite 对冲遗忘）则揭示了一个能稳定运行的 Loop 背后必须存在的工程纪律。

但最重要的认知是：Loop 不是万能的。 它有三个层次、有明确的适用边界、有不可忽视的成本结构。不是所有工作都该 Loop 化——只有重复的、可验证的、风险可控的环节，才是 Loop 的最佳战场。

---

第三章：Loop Engineering 与 Harness Engineering 的关联

3.1 三次迁移的脉络

Loop Engineering 不是凭空出现的。它是工程师与 AI 协作方式经历三次迁移后的自然产物，每一次迁移都把人往上推了一个抽象层：

迁移阶段	时间	人的角色	核心活动	瓶颈
Prompt Engineering	2023-2024	对话者	手动写提示词，一问一答	人的打字速度和注意力
Harness Engineering	2025-2026 初	约束设计者	给 AI 搭约束环境（测试、CI/CD、hooks），但每次任务人来触发和审查	人仍在每一步触发 Agent
Loop Engineering	2026 中至今	系统设计师	设计自动触发的闭环系统，Agent 自己跑、自己验证、自己触发其他 Agent	验证质量和成本控制

三次迁移的共同方向一致：人往上移一个抽象层。从写代码 → 写 Prompt → 建 Harness → 设计 Loop。但每上一层，你需要理解的东西反而更多，不是更少。

以 OpenAI 内部的实践为例：3 个工程师用 Codex 在 5 个月内产出 100 万行代码、0 行人写。他们的核心工作不是写代码，而是建约束——preflight gate、SHA discipline、remediation loop、hooks 机制。人不再写代码，但仍在每一步触发和审查 Agent。这是典型的 Harness Engineering。

Peter Steinberger 则更进一步：他用 50 个 Codex 并行审 3,000 个 PR，单日 627 次提交，不是坐在电脑前盯出来的——Agent 自动发现工作、自动执行、自动验证。这就是从 Harness 到 Loop 的跨越。

3.2 Agent = Model + Harness

Birgitta Böckeler 在 martinfowler.com 上发表的《Harness Engineering for Coding Agents》给出了最清晰的定义：

Agent = Model + Harness

Harness 是 Agent 中除了模型之外的所有东西。她进一步把 Harness 拆分成两个方向：

方向	英文	作用	时机	举例
Guides（前馈/导引）	Feedforward	在 Agent 行动之前引导它走正确方向	行动前	CLAUDE.md、类型系统、Linting 规则、SKILL.md
Sensors（反馈/传感）	Feedback	让 Agent 在行动之后观察到后果	行动后	测试结果、编译报错、运行时日志、浏览器截图

Daniel Demmel 在他的《Feedback Loop Engineering》文章中进一步指出：他所说的「Feedback Loop Engineering」本质上就是 Harness Engineering 的 Sensor 半边——刻意地建设反馈基础设施，让 Agent 能看到自己代码在运行环境中的真实表现。

他列举了五种关键反馈通道：

1. 浏览器调试 CLI：Agent 能导航到页面、检查 DOM、查看控制台错误、验证前端渲染
2. 数据库查询 Skill：Agent 能验证迁移是否正确执行、数据是否按预期写入
3. 日志和崩溃追踪：Agent 看到运行时真正发生了什么，而不是从代码猜测
4. OpenTelemetry 追踪：在微服务架构中，跟踪请求穿过整个系统
5. 开发环境 API Key：Agent 能调用真实的开发端点，而不是只靠 Mock

这些反馈通道的价值在于：它们把验证从「代码能编译吗？」提升到「代码在系统中真的能工作吗？」

3.3 Harness 和 Loop 的本质差异

Boris Cherny 的五大构建块听起来很新，但如果对照 Harness Engineering 的概念，会发现大部分已经存在——只是被重新组合和升级了：

Boris 的构建块	Harness 系列的对应概念	新在哪里
Automations	没有直接对应	全新：定时自动触发，不需要人启动
Worktrees	Control Plane Pattern 中的 git worktree	从单一 Agent 扩展到多 Agent 并行
Skills	AGENTS.md / CLAUDE.md 知识库	更结构化，变成可复用的 SKILL.md
Connectors	MCP 工具整合	基本相同
Sub-agents	EFC 论文中的 verifier agent	从概念落地到具体架构角色
Memory	没有直接对应	全新：跨次执行的持久状态

真正新的东西是两个：Automations（自动触发）和 Memory（跨次记忆）。

这两个加在一起，让系统从「人按一下跑一次」变成「自己决定什么时候跑、记得上次跑到哪里」。

这就是 Harness 和 Loop 的本质差异：

• Harness 是「接住 Agent 的产出」——你触发 Agent，Harness 确保它在约束范围内工作，然后你审查结果。
• Loop 是「让 Agent 自己决定什么时候产出、产出什么」——系统自动触发、自动执行、自动验证、自动记住进度。

用一句话说：Loop 是 Harness 加上了自动触发和持久记忆之后的升级版本。 没有 Harness 的 Loop，就是一个自动跑、自动出错、自动制造垃圾的系统。

3.4 Inner Loop 与 Outer Loop

Daniel Demmel 和 Mozilla AI 的 cq 项目揭示了 Loop 的另一个重要维度：内外两层循环。

Inner Loop（内循环）

这是单次会话内的即时反馈循环。Agent 写代码 → 运行 → 看结果 → 基于结果修改 → 再运行。一切都发生在同一个上下文窗口内。

紧凑的 Inner Loop 直接决定了单次会话的产出质量。第二章讨论的六条防线（多出口、看行动不看自报、user 角色伪装等），全部服务于 Inner Loop 的稳定性。

Outer Loop（外循环）

这是跨会话的知识沉淀循环。一次会话中 Agent 花半小时发现某个 API 会静默截断超大 payload——在 Inner Loop 中，这个知识活在上下文窗口里，会话结束就消失了。在 Outer Loop 中，它被提炼并写回共享知识库（一个新 Skill、一条 CLAUDE.md 规则、一个知识库条目），下一次会话的 Agent 从一开始就知道这件事。

Mozilla AI 的 cq 是目前最干净的 Outer Loop 实现：

• Agent 把发现存储为结构化的「知识单元」——未文档化的 API 怪癖、变通方案、修复方法
• 下次遇到类似问题前，先查询知识库，避免重复踩坑
• /cq:reflect 命令从已完成的会话中提取值得保留的经验教训

内外循环如何连接：今天 Outer Loop 沉淀的经验，变成明天 Inner Loop 的 Guide（前馈）——Skills、CLAUDE.md 规则、知识库条目。Outer Loop 默默改善 Inner Loop 的每一次运行。这和一个好团队的运作模式完全一样：有人调试了一个棘手问题，写了复盘文档，下一个人不用从头来过。

3.5 四层体系总览

综合所有来源，从 Prompt 到 Loop 可以归纳为一个四层递进体系：

┌─────────────────────────────────────────────────┐
│              Loop Engineering                    │
│  设计自运行的闭环系统：自动触发 + 持久记忆       │
│  ┌─────────────────────────────────────────────┐ │
│  │           Harness Engineering               │ │
│  │  Agent 的约束环境：Guides(前馈) + Sensors(反馈)│ │
│  │  ┌─────────────────────────────────────────┐│ │
│  │  │        Context Engineering              ││ │
│  │  │  管理输入给模型的上下文信息              ││ │
│  │  │  ┌─────────────────────────────────────┐││ │
│  │  │  │      Prompt Engineering             │││ │
│  │  │  │  优化单条提示词的措辞               │││ │
│  │  │  └─────────────────────────────────────┘││ │
│  │  └─────────────────────────────────────────┘│ │
│  └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘

每一层包裹着内层——Loop 包着 Harness，Harness 包着 Context，Context 包着 Prompt。内层从不消失，只是外层在它之上叠加了新的能力。

Daniel Demmel 对四层体系下每层回答的核心问题做了精确区分：

• Prompt Engineering：怎么措辞？
• Context Engineering：给模型看什么？
• Feedback Loop Engineering（Harness 的 Sensor 半边）：Agent 做完之后，怎么让它看到后果？
• Harness Engineering：整个装置怎么治理——调哪些工具、碰哪些文件、什么时候停？

Loop Engineering 在这之上再加一个问题：什么时候自动启动、怎么跨次记住进度？

3.6 本章小结

Loop Engineering 和 Harness Engineering 不是对立关系，而是继承和延伸关系。

• Harness 是 Loop 的地基。没有好的测试、好的 CI/CD、好的 Agent 约束机制，Loop 只是在自动化地制造垃圾。
• Loop 在 Harness 之上加了两个关键能力：Automations（自动触发） 和 Memory（跨次记忆）。这两个能力让系统从「人按一下跑一次」升级为「自己发现工作、自己记住进度」。
• Inner Loop 管单次会话的执行质量，Outer Loop 管跨会话的知识沉淀。两者形成良性循环——今天的教训变成明天的起点。

Peter Steinberger 在 Reddit 上被问到具体怎么做 Loop 时，回答是：「I have my Claw supervising my Codexes.」然后开玩笑说，几个月后我们会在谈「fleets that design your loops」——设计你的 Loop 的 Fleet。这不是玩笑，这是抽象层不断往上叠的现实。但每往上一层，下面的基础就更重要——你的 CI/CD 够不够稳、你的测试覆盖率够不够高、你的 Agent 约束机制够不够硬。

---

第四章：在 AI Coding 中运用 Loop Engineering

4.1 先别急着建 Loop：三条前提检查

不是所有工作都应该 Loop 化。在决定为一个工作环节建 Loop 之前，先问三个问题：

检查项	问题	不满足时怎么办
可衡量性	有可自动衡量的 metric 吗？	不能全自动 Loop；只能 Loop 到「输出草稿等人审」
失败可控性	失败的代价可控吗？	需要人在 Loop 里（审批节点），不是 Loop 外（事后补救）
Harness 成熟度	你的 Harness 够硬吗？（测试覆盖率、CI/CD、类型系统）	先补 Harness 基础，不要急着建 Loop

Karpathy 的成功恰恰是因为他的场景完美符合这三个前提：一个明确的 metric（训练速度）、一个封闭的修改空间（训练代码，失败不影响生产）、一个可以自动跑的验证流程（跑模型测 benchmark）。

大多数软件工程的日常不完全满足这三个条件。但这不意味着 Loop 完全无用——而是你需要在合适的环节使用。

4.2 哪些工作适合 Loop 化？

根据对 12 篇文章的综合分析，工作可以按「Loop 化适合度」分为三个区域：

绿区：强烈推荐 Loop 化

这些工作重复、有明确的通过/失败信号、风险可控：

• CI 失败自动修复：测试报错信息是完美的可验证反馈，修完跑测试就知道对不对
• 依赖版本更新：bump 版本 → 跑测试 → 绿了就开 PR，经典闭环
• Issue 分类和 Triage：读 Issue 内容 → 打标签 → 分配优先级，可以用简单的审查规则验证
• 代码风格和 Lint 修复：Linter 输出就是完美 metric
• 重复性重构：如 API 迁移、命名规范化，可以用类型检查和测试验证
• 安全漏洞扫描和初步修复：扫描工具的输出是明确的验证信号

黄区：谨慎使用 Loop，需要人在关键节点

这些工作有一定规律但需要判断力，适合「Loop 做初稿 → 人审后合并」的模式：

• PR 审查辅助：Loop 做首轮检查（风格、测试覆盖、明显 Bug），但最终合并决定权在人
• 文档生成和更新：Loop 可以从代码变更自动更新 API 文档草稿，人审核后发布
• 测试用例补充：Loop 分析覆盖率缺口并生成测试草稿，人验证测试意图是否正确
• Bug 修复草稿：Loop 基于错误日志和堆栈追踪尝试修复，人决定是否采纳

红区：不建议 Loop 化

这些工作需要创意、判断力或上下文理解，是人的核心价值区：

• 系统架构设计：权衡取舍需要对业务上下文的深度理解
• 产品策略决策：涉及商业判断，不是技术验证能解决的
• 选题和叙事构建：创意工作的「好」没有自动化 metric
• 关键安全决策：影响范围大，需要人类判断力兜底
• 跨团队沟通协调：涉及人际关系和组织动态

Jack Marchant 对此的经验总结很精准：

“Before running anything through the loop, ask: is the decision already made, or is the agent being asked to make it? Execution is a good handoff. Decision-making usually isn’t.”

判断标准：如果决策已经做完了，只剩执行——适合 Loop。如果 Agent 需要替你做决策——不适合。

4.3 一个完整 Loop 的端到端实例

以下是一个经过实战验证的 Loop 设计，可以直接映射到 Claude Code 或 Codex：

┌─ 每个工作日早上 9:00 自动触发 ──────────────────────────┐
│                                                          │
│  ① Automation 调用 Triage Skill                         │
│     读取昨天的 CI 失败、未关闭 Issue、最近 commit        │
│     写入发现到 Memory 文件（TODO.md 或 Linear Board）    │
│                                                          │
│  ② 对每个值得处理的发现                                  │
│     ├── 打开一个隔离的 Worktree                          │
│     ├── 派一个 Sub-agent（Maker）起草修复                │
│     └── 派另一个 Sub-agent（Checker）审查                │
│         审查依据：项目 Skills + 现有测试                  │
│                                                          │
│  ③ 通过验证？                                            │
│     ├── 是 → Connectors 开 PR、更新 Issue、通知 Slack    │
│     └── 否 → 反馈错误给 Maker，重试 1-2 次              │
│             仍然失败 → 放入你的收件箱，等你上班处理       │
│                                                          │
│  ④ 更新 Memory：记录哪些完成、哪些需要人介入             │
│     明天早上的运行从这里接续                              │
└──────────────────────────────────────────────────────────┘

关键要点：你设计了这个七步系统一次，之后不需要每天早上手动触发任何一步。但你仍然是最终审查者——Loop 不能自动合并到主分支，只能开 PR 等你审核。

4.4 工具层面的实践指南

Claude Code 中的 Loop 实践

# 定时运行分类 prompt，每个工作日早上 9 点
/loop "Read yesterday's CI failures and open issues, 
write findings to TODO.md, and draft fixes for anything 
labeled quick-win" --schedule "0 9 * * 1-5"

# 运行直到可验证的停止条件成立
/goal "All tests in test/auth pass and lint is clean"

• /loop：把你的 prompt 转成 cron job，可以推送到 GitHub Actions 让它在关机后也能运行
• /goal：持续运行直到条件成立，用独立的小模型做验证判断（不是做工作的那个模型）
• Hooks：在 Agent 生命周期的特定点触发 shell 命令（如提交前跑 lint）

OpenAI Codex 中的 Loop 实践

# 持久化的长期目标（CLI 0.128.0+）
codex /goal "Migrate the billing module to the new pricing API, 
keep all existing tests green"

• Automations 标签页：选择项目、设定 Prompt 和频率，结果进入 Triage 收件箱
• Skills：用 $ 或 /skills 调用，也可在任务匹配时自动加载
• Sub-agents：在 .codex/agents/ 下定义 TOML 文件，支持不同模型和推理强度

通用实践：Skills 编写最佳原则

Skills 是 Loop 中投资回报率最高的环节。以下是从多篇文章中提炼的编写原则：

1. 一个 Skill 对应一个任务：不要写大而全的 Skill，保持每个 Skill 聚焦
2. 尽可能密集：把规范、示例、测试命令、绝不能做的事全部压缩进去
3. 建立索引：让 Agent 自动检索需要的 Skill，而不是每次都加载全部
4. 描述要无聊且精确：Agent 根据描述匹配 Skill，花哨的描述不如精确的描述
5. 把「那一次事故」写进去：「我们不这样做，因为上次那个事故」——这种知识是 Skill 最高价值的内容

4.5 从手动到全自动的渐进迁移路径

不要试图一步到位建一个复杂的 Loop。建议按以下路径渐进迁移：

第一步：建好 Harness 基础（前提条件）

• 确保有足够的测试覆盖率（这是 Loop 验证环节的基础）
• 建立 CI/CD 流水线
• 配置类型系统和 Linter
• 写好 CLAUDE.md / AGENTS.md

第二步：从单个 Automation 开始

• 选一个最简单、风险最低的重复性任务（如 CI 失败分类）
• 设一个 Automation 每天早上把 CI 失败整理到一个 Markdown 文件
• 不要开自动合并，只生成报告给你看
• 观察一周，了解 Loop 的行为模式

第三步：加入 Maker-Checker 分离

• 在观察满意后，让 Loop 不只分类，还尝试修复
• 但用独立的审查 Agent 检查修复质量
• 修复结果以 PR 形式呈现，由你最终合并

第四步：扩展到多个 Loop

• 在第一个 Loop 稳定后，逐步为其他适合的工作环节建 Loop
• 每个 Loop 都有独立的成本预算和停止条件
• 建立 Memory 机制，让 Loop 之间共享知识

第五步：建立 Outer Loop

• 在 Loop 运行一段时间后，开始沉淀知识
• 每次 Loop 发现的新知识写回 Skills
• 今天的教训变成明天的起点

Addy Osmani 的建议最中肯：

“Start simple, then add autonomy only when it pays for itself. If the workflow is one-off, just prompt the model. If the work repeats and has a clear pass or fail signal, build a loop.”

4.6 实战中的成本管理

在实际使用中，成本控制需要融入 Loop 的设计：

控制手段	具体做法	预期效果
迭代上限	每个 Loop 设 maxTurns（如 10 轮）	防止无限空转
Token 预算	每日 / 每 Loop 设 token 上限	防止账单失控
收敛检测	连续 3 次无改善就自动停	避免低效重试
分层模型	初筛用 Haiku/Flash，关键判断用 Opus/Pro	降低平均成本
手动启动 vs 全自动	初期手动启动 Loop 并观察	降低风险
慢频率起步	从每天一次开始，不要上来就每小时	观察效果再加速

Louis-François Bouchard 的态度很务实：

“I personally want to manually launch my loops and check them to ensure everything goes smoothly.”

在信任建立之前，手动启动并监控是最明智的做法。

4.7 本章小结

在 AI Coding 中运用 Loop Engineering 的核心原则：

1. 先检查前提：有可衡量的 metric？失败代价可控？Harness 够硬？
2. 选对战场：重复的、可验证的、风险可控的环节才适合 Loop
3. 渐进迁移：从单个 Automation 开始，观察稳定后再扩展
4. 投资 Skills：知识编码是 Loop 中投资回报率最高的环节
5. 成本先行：停止条件和成本上限跟循环逻辑一样重要
6. 人不退场：Loop 是让你专注于更高价值工作的工具，不是替代你的工具

---

第五章：未来发展趋势展望

5.1 更高抽象层的到来：Fleets that Design Your Loops

Peter Steinberger 半开玩笑的预言——「几个月后我们会在谈 fleets that design your loops」——很可能成为现实。

抽象层叠加的方向是明确的：

写代码 → 写 Prompt → 建 Harness → 设计 Loop → 设计 Fleet（管理 Loop 的 Loop）

当 Loop 本身变得复杂（多个 Loop 之间有依赖、需要协调资源、需要统一的知识沉淀），就会自然催生出「管理 Loop 的系统」。Peter Steinberger 已经在实践了——他的 Claw 在监管他的多个 Codex。这个模式一旦被工具化，就会成为下一个标准能力。

判断：2026 年底到 2027 年初，主流 AI Coding 工具（Claude Code、Codex、Gemini CLI）很可能会内建 Fleet/Orchestrator 层级的能力，让用户可以定义多个 Loop 之间的依赖和协作关系。

5.2 Metric 自动化的突破方向

Karpathy Loop 的成功建立在一个硬前提上：可自动衡量的 metric。这也是 Loop Engineering 当前最大的限制——大量工作没有明确的自动化 metric。

未来可能的突破方向：

方向一：AI 作为 Metric 的评估者
Claude Code 的 /goal 已经在做这件事——用一个独立模型来判断目标是否达成。随着模型判断力的提升，越来越多的「模糊目标」可以被另一个模型来评估。例如「这个 UI 是否匹配设计稿」已经可以通过截图比对模型来验证。

方向二：组合式 Metric
单一 metric 覆盖不了的场景，可以通过组合多个弱信号来构建。例如代码质量 = 测试通过率 × Lint 通过率 × 类型检查通过率 × 复杂度评分。每个单独不够，但组合起来可以作为「可接受」的阈值。

方向三：人类偏好学习
像 RLHF 一样，通过积累人对 Loop 产出的接受/拒绝信号，逐步训练出更精准的自动 metric。你审查了 100 个 PR，接受了 80 个，系统可以从中学到你的偏好模式。

判断：metric 自动化不会在短期内完全解决。创意性工作（「这篇文章有没有洞见」）和高风险决策（「这个架构选型合不合理」）在可预见的未来仍然需要人来判断。Loop 的适用范围会扩大，但不会覆盖所有工作。

5.3 Inner Loop 和 Outer Loop 的融合

目前 Inner Loop（会话内反馈）和 Outer Loop（跨会话知识沉淀）还是相对独立的。Mozilla AI 的 cq 是最早的融合尝试。

未来趋势是两个循环的边界会越来越模糊：

• 实时知识沉淀：Agent 在会话中发现的新知识，不等会话结束就自动写入共享知识库
• 跨 Agent 知识共享：一个 Agent 在 Loop A 中学到的经验，实时同步给正在运行的 Loop B
• 自适应 Skill 更新：基于 Loop 运行的成功/失败模式，自动更新和优化 Skills

判断：这个方向会在 2026-2027 年间快速发展。「Agent 越用越聪明」不再是幻想，而是通过 Outer Loop 的知识沉淀机制在工程上实现。但关键挑战在于知识的去噪——Agent 学到的不全是对的，错误的「经验」如果沉淀下来会污染后续所有运行。

5.4 Loop 经济学的演化

成本结构将随着三个趋势发生变化：

趋势一：Token 成本持续下降
过去两年，主流模型的 token 单价下降了一个数量级以上。如果这个趋势持续，Loop 的经济可行性门槛会大幅降低——更多原本「不值得 Loop 化」的工作会变得经济上可行。

趋势二：智能路由和模型分层
Loop 内部会更智能地选择模型——简单的分类用最便宜的模型，复杂的判断才用最贵的。这已经是当前的最佳实践，但未来会被工具自动化。

趋势三：从 Token 计费到结果计费
一些 AI Coding 工具已经在探索「按任务收费」而不是「按 token 收费」。如果这个趋势发展，Loop 的成本管理会变得更可预测——你为一个修复付固定价格，而不是担心 Loop 空转烧钱。

判断：Loop 的经济门槛在下降，但「免费」不会到来。成本控制仍然是 Loop 设计的核心要素之一，只是控制的粒度和工具会更精细。

5.5 风险与边界：三个不会消失的问题

Loop Engineering 的三个核心风险不会随着技术进步消失，反而会随着 Loop 变得更好而变得更尖锐：

风险一：Comprehension Debt（理解力债务）

Loop 出货代码的速度越快，工程师对自己系统的理解就越跟不上。一个顺畅的 Loop 只会让这个差距更快扩大。

Boris Cherny 的警告：

“The faster the loop ships code you didn’t write, the bigger the gap between what exists in the repo and what you actually understand.”

应对：必须投入时间阅读 Loop 产出的代码。Loop 省下的不是你理解代码的时间，而是你手动编写代码的时间。

风险二：Cognitive Surrender（认知投降）

当 Loop 自己运行时，停止思考、接受它返回的一切是最舒适的失败模式。两个人可以建完全相同的 Loop 却得到相反的结果：一个用 Loop 加速自己深度理解的工作，另一个用 Loop 逃避理解工作。Loop 不知道区别，但你知道。

应对：设计 Loop 的人不能停止当工程师。定期手动审查 Loop 的产出，质疑它的决策，保持对系统的理解力。

风险三：自主性与安全性的张力

一个有 Connector 权限的无人值守 Loop 可以触碰生产系统。随着 Loop 能力增强，安全边界的设计变得越来越关键——权限控制、审计日志、操作范围限制。

应对：遵循最小权限原则。Loop 只有它执行任务所必需的最小权限，不多给。生产环境的任何操作都需要人类审批节点。

5.6 本章小结：一个清醒的展望

Loop Engineering 的未来方向是明确的：

• 抽象层还会往上叠——从 Loop 到 Fleet，从单 Agent 到 Agent 群体协作
• 适用范围会扩大——随着 metric 自动化和成本下降，更多工作可以 Loop 化
• 知识沉淀会加速——Inner Loop 和 Outer Loop 的融合让 Agent 越用越聪明

但同样明确的是它的边界：

• 需要人类判断力的工作不会被 Loop 替代
• 理解力债务和认知投降是不会消失的风险
• 成本控制始终是 Loop 设计的核心约束

最后，用 Boris Cherny 的话收尾：

“Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.”

人设计 Loop。但设计 Loop 的那个人，不能停止当工程师。

---

参考文献

外部优质文章

6. Louis-François Bouchard — Loop Engineering Explained
   https://www.louisbouchard.ai/loop-engineering/

7. Lushbinary Team — Loop Engineering: Designing Systems That Prompt AI Agents（2026 年 6 月）
   https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/

8. Wisely Chen — Loop Engineering：不再 Prompt Agent，改設計 Loop 讓 Agent Prompt Agent
   https://ai-coding.wiselychen.com/loop-engineering-from-prompt-to-loop-paradigm-shift/

9. Cobus Greyling — Loop Engineering Playbook（Medium）
   https://cobusgreyling.medium.com/loop-engineering-playbook-4460e01e88d8

10. Jack Marchant — Engineering the Loop（2026 年 3 月）
    https://www.jackmarchant.com/engineering-the-loop/

11. Addy Osmani — My LLM Coding Workflow Going into 2026
    https://addyosmani.com/blog/ai-coding-workflow/

12. Daniel Demmel — Feedback Loop Engineering
    https://www.danieldemmel.me/blog/feedback-loop-engineering

关键人物引用来源

• Peter Steinberger（OpenClaw 作者）：2026 年 6 月 8 日推文，3 百万观看
• Boris Cherny（Anthropic Claude Code 负责人）：Addy Osmani 访谈
• Andrej Karpathy（前 Tesla AI 总监）：Fortune 报道及个人推文
• Birgitta Böckeler：Harness Engineering for Coding Agents，martinfowler.com
• Tobias Lutke（Shopify CEO）：复刻 Karpathy Loop 实验

---