Context Engineering Isn’t Enough — A Loop Engineering Experiment With No LLM Inside the Loop
Context Engineering Isn’t Enough — A Loop Engineering Experiment With No LLM Inside the Loop
上下文工程已不足够——一项在循环中不使用大语言模型的“循环工程”实验
A deterministic, zero-dependency Python benchmark comparing loop engineering against linear execution, sanity-checked across 300 random seeds before a single number was trusted. 这是一个确定性的、零依赖的 Python 基准测试，旨在比较“循环工程”与“线性执行”的差异。在采信任何数据之前，该测试已通过 300 个随机种子的完整性检查。
Key Takeaways / 核心要点
The Scope: This isn’t a benchmark pitting agent frameworks against each other, nor does it claim this controller is “smarter.” It claims something narrower and much more defensible: that failure isolation is a real, measurable architectural property. 研究范围： 这不是一个让各种智能体框架相互竞争的基准测试，也不声称该控制器更“聪明”。它主张的是一个更狭窄且更具说服力的观点：故障隔离是一种真实且可衡量的架构属性。
It’s a Pattern, Not a Product: Loop engineering is a control-flow pattern, not a specific framework. It’s the concept of replacing a single giant prompt with an iterative system that observes state and acts toward a goal. 这是一种模式，而非产品： 循环工程是一种控制流模式，而非特定的框架。它的核心理念是用一个能够观察状态并朝着目标行动的迭代系统，来取代单一的巨型提示词（Prompt）。
Built for Verification: To prove this mechanism rather than take it on faith, I built a tiny, deterministic implementation of a goal-directed controller. It requires zero LLM calls and has zero external dependencies. 为验证而生： 为了证明这一机制而非仅仅依赖信仰，我构建了一个微小的、确定性的目标导向控制器实现。它不需要任何 LLM 调用，且没有任何外部依赖。
Measurable Failure Isolation: While a linear, one-shot pipeline halts entirely on its first unresolved obstacle, this controller isolates failures to the specific branch that contains them. Across 300 random seeds, the controller completed a mean of 3.3 out of 10.3 independent branches, compared to just 0.4 for the linear baseline. 可衡量的故障隔离： 当线性的“一次性”流水线在遇到第一个未解决的障碍时就会完全停止时，该控制器能将故障隔离在包含它们的特定分支中。在 300 个随机种子的测试中，该控制器平均完成了 10.3 个独立分支中的 3.3 个，而线性基准测试仅完成了 0.4 个。
Radical Transparency: I actually found and fixed a real bug in my own benchmark logic before trusting these numbers, and I’m walking through that mistake in detail rather than hiding it. 彻底的透明度： 在采信这些数据之前，我确实发现并修复了基准测试逻辑中的一个真实 Bug，我将详细剖析这个错误，而不是掩盖它。
The Pipeline That Stopped for No Reason / 无故停止的流水线
A few months ago, I watched a task-processing pipeline collapse on step three of forty. Step three needed a configuration value that I hadn’t set yet. Because of that single missing value, everything downstream just sat there dead. That included thirty-some steps that had absolutely nothing to do with the missing config. 几个月前，我目睹了一个任务处理流水线在四十个步骤中的第三步崩溃了。第三步需要一个我尚未设置的配置值。由于这一个缺失的值，下游的所有任务都陷入了停滞。这其中包括了三十多个与该缺失配置毫无关联的步骤。
The work itself wasn’t impossible. The system collapsed simply because the pipeline had no conceptual ability to skip a broken branch and keep moving on the others. This is not a prompt problem. No amount of rewriting instructions for the model would have fixed it, because the model was never the part that broke. The failure happened in the control code. The logic responsible for deciding what to do next when things went sideways didn’t decide anything. It just quit. 工作本身并非无法完成。系统崩溃仅仅是因为流水线在概念上没有跳过损坏分支并继续处理其他分支的能力。这不是提示词的问题。无论如何重写模型指令都无法解决它，因为模型本身并不是崩溃的部分。故障发生在控制代码中。负责在情况出错时决定下一步操作的逻辑没有做出任何决定，它只是直接退出了。
I am writing this to address the layer completely above the prompt. This is the part of an agentic system that manages state and determines the next move after a step succeeds, fails, or gets stuck. In AI engineering circles, people call this loop engineering. 我写这篇文章是为了探讨提示词之上的那一层。这是智能体系统中管理状态，并在步骤成功、失败或卡住后决定下一步行动的部分。在 AI 工程圈子里，人们称之为“循环工程”。
What “Loop Engineering” Means, and Where the Term Comes From / 什么是“循环工程”，以及该术语的由来
If you spend time on AI engineering Twitter, Substack, or LinkedIn, you have probably seen the phrase loop engineering. I want to be precise about its origin rather than treating it as ambient knowledge. Misattributing a fast-moving term is exactly how you erode trust in a technical article. 如果你经常浏览 AI 工程领域的 Twitter、Substack 或 LinkedIn，你可能已经见过“循环工程”这个词。我想准确说明它的起源，而不是将其视为一种常识。错误地归因一个快速演变的术语，正是削弱技术文章可信度的方式。
Google engineer Addy Osmani named and structured the term in an essay published in June 2026. He built on a line from developer Peter Steinberger, who argued that practitioners should stop prompting coding agents directly and instead design the loops that prompt them. Around the same time, Anthropic’s Claude Code lead, Boris Cherny, made a similar point about his own workflow shifting from writing prompts to writing the loops that write prompts. Google 工程师 Addy Osmani 在 2026 年 6 月发表的一篇文章中命名并构建了这个术语。他的观点基于开发者 Peter Steinberger 的一句话，后者认为从业者应该停止直接提示编码智能体，转而设计那些能够提示智能体的循环。大约在同一时间，Anthropic 的 Claude Code 负责人 Boris Cherny 也表达了类似的观点，即他自己的工作流正从编写提示词转向编写“编写提示词的循环”。
Osmani’s essay frames loop engineering as sitting one level above what he separately calls harness engineering, the layer concerned with the environment a single agent runs inside. Other practitioner write-ups extend this into a fuller stack, prompt engineering to context engineering to harness engineering to loop engineering, with each layer wrapping the one before it. Osmani 的文章将循环工程定位在“工具链工程”（harness engineering）之上——后者关注的是单个智能体运行的环境。其他从业者的文章将其扩展为一个更完整的技术栈：从提示词工程到上下文工程，再到工具链工程，最后是循环工程，每一层都包裹着前一层。
We should also credit a direct technical predecessor. Engineer Geoffrey Huntley described running a coding agent inside a plain while loop in July 2025, an approach that became known as the Ralph technique. The core idea, feeding an agent the same goal repeatedly until it satisfies a written spec, is a simpler ancestor of the exact same pattern.
我们还应该归功于一个直接的技术先驱。工程师 Geoffrey Huntley 在 2025 年 7 月描述了在一个简单的 while 循环中运行编码智能体的方法，这种方法后来被称为“Ralph 技术”。其核心思想是反复向智能体输入同一个目标，直到它满足书面规范，这是该模式的一个更简单的雏形。
Why I Built This Without Calling a Single LLM / 为什么我在构建此实验时没有调用任何 LLM
Every explainer I read about loop engineering assumes an LLM sits inside the loop, making the decisions at each turn. That is a reasonable assumption for products like Claude Code, which genuinely put a model at the center of the decision loop. But this creates a problem if you want to evaluate the architecture on its own terms. If the loop’s behavior depends entirely on what the model decides to do, you can never fully separate a good loop design from a model that just got lucky on a specific run. 我读过的每一篇关于循环工程的解释文章都假设 LLM 位于循环内部，在每一步做出决策。对于像 Claude Code 这样真正将模型置于决策循环核心的产品来说，这是一个合理的假设。但如果你想独立评估架构本身，这就会产生问题。如果循环的行为完全取决于模型决定做什么，你就永远无法将优秀的循环设计与仅仅在某次运行中运气好的模型区分开来。