摘要
本报告系统考察2026年6月由Peter Steinberger、Boris Cherny和Addy Osmani独立提出并引爆AI圈的Loop Engineering(循环工程)概念。报告将其置于AI工程栈的第四层(Prompt → Context → Harness → Loop),从概念定义、技术架构、设计模式、产业实践、商业逻辑与风险边界六个维度展开深度分析。核心发现:Loop Engineering的本质是将开发者从"提示词的写作者"升级为"循环系统的设计者",使Agent从"被操作的工具"转变为"自主运行的员工"。但这一范式转移伴随验证债务、理解衰退、认知投降与Token爆炸四重隐性成本,最终的分化取决于人类是否保留足够强的判断力与否决权。
关键词:Loop Engineering;Agent工程;生成器-评估器分离;范式转移;判断力稀缺
第一章 引言:Agent工程范式的第三次跃迁
过去18个月,AI工程领域经历了三次范式跃迁,从Prompt Engineering到Context Engineering再到Harness Engineering,每次跃迁都重新定义了开发者与AI模型的交互方式。2026年6月,Loop Engineering作为第四次跃迁正式登上舞台,这次跃迁不仅改变了技术栈的结构,更从根本上重新定义了人类在AI开发过程中的角色定位。
1.1 从Prompt到Loop:18个月的技术栈演进
AI工程领域的范式演进呈现出清晰的层次递进特征,每一层都在前一层基础上向外推进一步,解决更加复杂的系统性问题。
第一层:Prompt Engineering(2022-2024)
Prompt Engineering是AI工程范式的第一层,核心问题聚焦于"如何让模型回答得更好"。这个阶段的主要特征是:
- 单轮交互模式:
开发者通过精心设计的提示词引导模型生成期望的输出 - 技巧驱动:
依赖零样本学习(zero-shot)、少样本学习(few-shot)、思维链(chain-of-thought)等技术 - 手动迭代:
需要开发者反复调整提示词表述,通过试错找到最优表达方式 - 天花板明显:
单次提示词的有效性受限于上下文窗口污染、信息遗漏等问题
根据IIT Patna与Stanford University联合发布的系统性综述研究,Prompt Engineering在2023-2024年间形成了完整的理论体系和技术框架,包括CO-STAR、SPECS、RISEN、TRACE等标准化框架,将原本依赖个人经验的技巧转化为可教学、可复用的工程实践[Sahoo et al., 2024]。
然而,Prompt Engineering存在根本性局限:它假设人类始终在每一轮对话中手动输入提示词,一旦对话历史过长或涉及多文件协作,精心设计的提示词往往被淹没在海量上下文中,模型无法有效识别关键信息。
第二层:Context Engineering(2025)
Context Engineering在2025年应运而生,将关注点从"如何写好一句话"转向"如何构建最优的信息集合"。这一层的核心突破在于:
- 信息架构设计:
系统性地组织系统指令、工具描述、领域知识、对话历史等要素 - 动态上下文构建:
根据任务需求实时选择和注入相关文档、代码片段、配置信息 - RAG系统成熟:
检索增强生成技术使模型能够访问外部知识库,突破上下文窗口限制 - 记忆管理:
引入持久化存储机制,解决跨会话信息遗忘问题
Anthropic在2025年9月发布的《Effective context engineering for AI agents》明确指出:"构建语言模型应用,正从寻找合适的词句,转向回答更宏大的问题——什么样的上下文配置最可能产生模型的期望行为?"[Anthropic, 2025]。
Microsoft Azure SRE Agent团队在实践中发现,单纯依赖模型升级和提示词优化无法在生产环境中获得可靠的结果,真正的突破来自于对上下文内容的精心设计——在什么时机、以什么形式、注入什么信息[Mehta, 2025]。
Context Engineering虽然解决了信息供给问题,但仍然假设人类在每一次任务执行时手动构建上下文。当Agent需要处理长周期、多步骤任务时,这一假设成为新的瓶颈。
第三层:Harness Engineering(2026年初)
Harness Engineering在2026年初正式成型,其命名来自软件测试领域的"测试脚手架(test harness)"概念。这一层将关注点从信息构建转向运行环境构建:
- 环境架构:
为单个Agent运行搭建完整的脚手架,包括约束规则、反馈循环、验证机制 - 架构边界:
通过机械规则和结构化测试强制执行模块化分层,防止架构腐化 - 自验证循环:
引入硬编码门控(如linter)、测试套件、CI/CD验证等确定性检查机制 - 熵治理:
通过持续性约束防止Agent行为漂移,维持系统稳定性
OpenAI在2026年2月发布的Harness Engineering实践中展示了令人震撼的成果:一支七人团队在五个月内使用Codex Agent生成了约一百万行代码和1,500个PR,构建了一个生产级应用,而零行代码由人工编写[Lopopolo, 2026]。
OpenAI技术团队成员Ryan Lopopolo总结道:"我们构建Harness以提供一致且可靠的方式运行大规模AI工作负载,使团队能专注于研究和产品开发,而非基础设施编排"[Lopopolo, 2026]。
Martin Fowler在LinkedIn评论中指出:"Harness Engineering是对AI赋能软件开发关键部分的宝贵框架。Harness包括上下文工程、架构约束和垃圾回收机制"[Fowler, 2026]。
Harness Engineering的核心命题是"Agent不难,Harness难"。约束Agent解空间的质量决定了其生产力和可靠性,而非模型规模或提示词技巧。
然而,Harness Engineering仍然假设每次任务执行都需要人类手动启动和监督。当Agent能力达到一定成熟度后,这一假设成为新的瓶颈——人类的时间和注意力成为系统吞吐量的限制因素。
第四层:Loop Engineering(2026年6月)
Loop Engineering在2026年6月由多位业界领袖独立提出并命名,标志着AI工程范式的第四次跃迁。这一次跃迁发生了根本性的角色转移:
- 范式转移:
从"我如何做"转向"系统如何自己运行" - 角色转换:
开发者从"提示词的写作者"变为"循环系统的设计者" - Agent定位转变:
从"被操作的工具"变为"自主运行的员工" - 无人值守运行:
Agent能够在没有人类干预的情况下长时间自主执行任务
Peter Steinberger(OpenClaw创始人,2026年2月加入OpenAI)在X平台上发布的观点获得了800万+浏览:"你不应该再手动提示AI编程助手了,你应该设计循环系统"[Steinberger, 2026]。
Boris Cherny(Anthropic Claude Code负责人)表达了相同的观点:"我的工作不再是提示Claude,我有循环在运行,它们才是提示Claude并判断下一步做什么的主体。我的工作变成了写Loop"[Cherny, 2026]。
Addy Osmani(Google Chrome工程负责人)在2026年6月7日撰写了系统性文章,将这一概念命名为Loop Engineering,并在Substack同步发布[Osmani, 2026]。
这三句话的共同指向揭示了一个核心变化:开发者不再在每一轮对话中手动输入提示词,而是设计一套系统,让系统自动发现工作、分配任务、验证结果、记录进度、决定下一步——整个循环在没有人类干预的情况下自主运转。
1.2 引爆点:三句话与一个命名
Loop Engineering概念的爆发呈现出有趣的同步性特征:三位不同背景的业界领袖在几乎同一时间窗口(2026年6月第一周)表达了相同的洞察,这种现象背后隐藏着技术成熟度的关键拐点。
Peter Steinberger的引爆帖
2026年6月初,Peter Steinberger在X平台上发布了仅两句话的帖子:"别再一条一条给编码Agent写提示词了,去设计一个循环,让循环替你提示它。"
这条帖子没有配图,没有代码链接,仅有这两句话,却在一周内获得了500万+浏览,AI编程圈随即掀起激烈讨论。有人质疑他在"制造焦虑",也有人承认他揭示了一件"大家已经在做但还没太愿意明说的事"[Steinberger, 2026]。
Steinberger是奥地利程序员,OpenClaw开源项目创始人,该项目三个月内冲到十几万star。他在2026年2月加入OpenAI,负责个人AI Agent开发。他的代码产量极为惊人——越是这类顶尖工程师,越早开始表达"别再把力气都花在手写提示词上"的观点。
Boris Cherny的实践证言
几乎在同一时间窗口,Anthropic Claude Code负责人Boris Cherny表达了类似观点:"我现在很少直接提示Claude,而是写循环,让循环去提示Claude、判断下一步做什么。我的工作变成了'写循环'"[Cherny, 2026]。
Cherny提供了具体的实践数据支撑:
自2025年11月起,他的代码100%由Claude Code产出,不再手敲修改,每天提交10-30个PR Anthropic整体数据:70%-90%的代码由Claude Code辅助写成,Claude Code团队内部约90% Anthropic内部统计:2026年每位工程师的代码产出增长了200%(约三倍) 按"每人每天合并的PR数"计算,增长67% 公开GitHub统计:约4%的提交已由Claude Code产出,行业预测年底可能达五分之一[Cherny, 2026]
Addy Osmani的系统命名
2026年6月7日,Addy Osmani在个人博客上撰写了系统性文章《Loop Engineering》,将这一概念正式命名,并在Substack同步发布。他综合了Steinberger和Cherny的观点,给出了清晰的一句话定义:
"Loop engineering是把自己从提示Agent的人的位置上替换掉,改为设计那个替你提示Agent的系统"[Osmani, 2026]。
Osmani进一步拆解了Loop的五个核心组件和第六个记忆组件,并与OpenAI Codex App和Anthropic Claude Code的功能模块进行了详细映射,揭示了两大产品在Loop架构上的高度同构性[Osmani, 2026]。
技术成熟度拐点
为什么三位从业者会在同一周不约而同地指向同一个方向?答案在于周围工具已悄然越过关键阈值:
- Agent能力阈值:
编码Agent已足够可靠,能够非中断地完成非平凡任务 - 调度原语出现:
主要Harness平台开始提供调度功能(cron、/goal命令等) - 成本下降:
单次Agent运行成本已降至足够低,重复运行(定时触发)不再显得浪费
当所有零部件同时就位时,组合它们的动作对所有人变得显而易见。名称滞后于实践数月:人们已开始写Loop,但尚未有人将其命名为Loop Engineering——就像团队早已在配对生成器与评估器Agent,直到"生成器-评估器分离"这一术语才赋予其正式身份[Osmani, 2026]。
1.3 研究问题与报告结构
Loop Engineering的出现提出了若干关键问题,本报告将围绕这些问题展开系统分析:
核心研究问题
- 概念界定:
Loop Engineering的本质是什么?它如何区别于之前的Prompt、Context、Harness三层范式? - 技术架构:
Loop的标准结构是什么?包含哪些核心组件?生成器-评估器分离为何成为关键架构决策? - 设计模式:
有哪些典型的Loop模式?它们如何组合使用(Loopcraft)?在不同场景下的适用性如何? - 产业实践:
Loop Engineering在企业级应用中的落地进展如何?Stripe、OpenAI、Anthropic等案例揭示了哪些关键经验? - 商业逻辑:
为什么Loop Engineering在2026年6月爆发?背后有哪些模型能力突破、厂商议程设置和锁定效应? - 风险边界:
Loop Engineering伴随哪些隐性成本和隐蔽陷阱?如何批判性地审视这一范式转移?
报告结构
本报告共分为七章,按照从概念到实践、从技术到商业、从收益到风险的逻辑展开:
- 第一章(引言):
阐述AI工程范式的四次跃迁,定位Loop Engineering的历史坐标,明确研究问题和报告结构 - 第二章(概念界定与架构解析):
定义Loop Engineering的概念内涵,解析Loop的标准结构(Observe-Think-Act-Evaluate-Replan-Repeat),拆解六大核心组件,重点分析生成器-评估器分离架构决策 - 第三章(七种典型Loop模式):
系统分析基础模式(ReAct Loop、Plan-and-Execute)、进阶模式(Reflection Loop、Tree of Thought、Graph Loop)、高级模式(Multi-Agent Loop、Self-Improving Loop),探讨Loop的可组合性(Loopcraft) - 第四章(产业实践与落地案例):
深入分析编程场景(Claude Code与Codex)、企业级案例(Stripe Minions每周1300+ AI生成PR)、跨场景扩展(营销、出海等行业),揭示实践经验和关键启示 - 第五章(商业逻辑):
分析模型能力的时间维度突破(METR基准数据)、模型能力收敛与厂商议程设置、锁定效应与双向绑定,批判性审视概念迭代速度的商业动机 - 第六章(风险、成本与批判性审视):
系统分析四重隐性成本(验证债务、理解衰退、认知投降、Token爆炸)、三个隐蔽陷阱(偷懒、自夸、漂移)、被放大的系统性问题,提供批判性视角 - 第七章(结论):
总结Loop Engineering的本质,分析同一Loop的两种相反结果路径,提出对未来软件工程的启示,强调判断力作为最终稀缺资源的核心命题
通过这七个章节的系统分析,本报告旨在为读者提供对Loop Engineering的全面理解——既认识其带来的范式转移价值,也清醒认知其伴随的风险边界,最终帮助从业者做出明智的采纳决策和实践设计。
