I’ve been watching the “Loop Engineering” conversation build up steam for a while now and I keep landing in the same spot: I’m not buying it. Not the way it’s being sold, anyway.“循环工程”这话题，我一直看着它升温。想了许久，还是同一个结论：我不信。至少不是现在这样卖给我的那种信法。
The pitch is seductive. Wrap the LLM in a loop — plan, act, observe, correct, repeat — and you get an autonomous-ish thing that grinds away at your problem until it’s done. Everybody nods. It sounds rigorous. It sounds like engineering. And that’s exactly the part that’s bugging me, because the more of these “loop” architectures I look at, the more they look like something I’ve seen before. They look like the same slow, cumbersome, ceremony-laden SDLC that companies have been stuck in for thirty years — except now we’ve bolted it onto a language model and called it innovation.这套说辞很诱人。把大语言模型裹进一个循环里——计划、行动、观察、纠正、重复——它就能自个儿在那磨，直到把问题磨完。人人都点头。听起来很严谨。听起来像工程。这正是我不安的地方。因为这类“循环”架构我见得越多，越觉得眼熟。它们像极了公司里用了三十年、又慢又笨、仪式繁多的软件开发生命周期——只不过现在给它安了个语言模型，管它叫创新。
Let me be blunt about the thing I actually think is happening here. We are not designing new ways to work with LLMs. We are retrofitting the broken software development lifecycle we already had onto a brand new kind of tool, and then acting surprised when the result is convoluted and bloated. The loop isn’t a breakthrough. In a lot of shops it’s a reskin of the ticket-grooming, status-meeting, hand-off-and-wait machine that made software slow in the first place. Largely, it defeats the entire advantage of using an LLM in the first place.说句直话，我觉得实际情况是这样的。我们不是在设计跟大语言模型打交道的新方式。我们是把本来就有毛病的软件开发生命周期硬生生套在一个新工具上，然后惊讶地发现结果又乱又臃肿。循环不是突破。在很多团队里，它就是贴了层皮的任务梳理、状态会议、交接等待机器——软件变慢的根源还在。这在很大程度上抹掉了大语言模型本来的优势。
The tell: it’s ceremony, not capability端倪：是仪式，不是能力
Here’s what tips me off. Go look at a bunch of these “agentic loop” designs in some of the more advanced companies – the ones that are supposedly doing this right – and count the steps. Plan the plan. Break the plan into subtasks. Score the subtasks. Route the subtasks. Re-plan when a subtask fails. Reflect on the reflection. Summarize the reflection into a memory. Retrieve the memory to plan the next plan.让我起疑的是这个。去看看那些所谓的先进公司里的“智能体循环”设计——就是那些据说做对了的——数数步骤。规划计划。把计划拆成子任务。给子任务打分。分配子任务。子任务失败时重新规划。对反思进行反思。把反思总结成记忆。把记忆检索出来用于规划下一个计划。
Squint! That’s not a novel machine intelligence workflow. That’s Scrum with a transformer in the standup. It’s the same “process as a substitute for thinking” instinct that gave us story points and RACI charts and forty-five minute refinement meetings. We took a slow, human, coordination-heavy process – one that mostly exists because humans forget things, go home at night, and don’t share memory – and we handed it, wholesale, to a system that doesn’t forget in the same way, doesn’t go home, and can share state instantly.眯眼一看！这不是什么新颖的机器智能工作流。这是带了个Transformer开晨会的Scrum。是那种“用流程代替思考”的本能，跟故事点、RACI图表、四十五分钟梳理会议一脉相承。我们把一个缓慢的、人类密集的、协调繁重的流程——它之所以存在，很大程度上是因为人类会忘事、晚上会回家、不会共享记忆——原封不动地交给了一个不会那样忘事、不会回家、能即时共享状态的系统。
The loop, in a huge number of cases, is coordination overhead that the model doesn’t actually need. We’re paying for it in tokens, latency, and complexity, and calling the bill “engineering rigor.”在很多情况下，循环是模型并不需要的协调开销。我们用令牌、延迟和复杂度买单，却把这账单叫作“工程严谨”。
Loops exist to cover for things LLMs shouldn’t need covered循环的存在是为了弥补大语言模型本不需要弥补的东西
A loop is fundamentally an error-correction and coordination structure. You loop when you can’t get it right in one pass and you have no better way to make forward progress than to try, check, and try again. That’s a completely reasonable thing to do sometimes. But notice why the classic SDLC is so loopy: it’s loopy because the humans and systems in it have terrible, lossy interfaces to each other. Requirements get garbled on the way to the dev. Context evaporates between the ticket and the code. Nobody can see the whole thing at once, so we iterate blindly and use process to catch the drops.循环从根本上说是一种纠错和协调结构。你之所以要循环，是因为一次搞不定，又没有更好的办法往前推进，只能试、检查、再试。有时这完全合理。但留意一下传统的软件开发生命周期为什么这么容易循环：因为里面的人和系统相互之间的接口又烂又丢信息。需求传到开发者那儿已经走了样。上下文在工单和代码之间蒸发掉了。没人能一次看到全貌，所以我们盲目迭代，用流程来兜住掉下来的东西。
When you lift that structure and drop it onto an LLM, you inherit all of those assumptions – lossy hand-offs, missing context, blind iteration – even when they no longer apply. The model can hold enormous context. It can be given the whole picture at once. It can be handed clean, structured inputs instead of a garbled ticket. So a lot of the loop is there to solve a problem you’ve already got the tools to eliminate. You’re building a bucket brigade next to a working fire hose.当你把那个结构搬到大语言模型上时，你继承了所有这些假设——丢信息的交接、缺失的上下文、盲目迭代——即使它们已经不适用了。模型能容纳极大的上下文。它可以一次拿到全貌。它可以收到干净的结构化输入，而不是一张走样的工单。所以循环的很大一部分是在解决一个你已经有工具消除的问题。你是在一根好用的消防水管旁边搭了个传水桶的人链。
That’s the reframe I want people chewing on: don’t fit the LLM to the broken SDLC. Fix the SDLC around what the LLM is actually good at, and a lot of the loop – and the SDLC – just disappears. Not all of it — some feedback is real and necessary — but a lot of it goes away.这就是我希望大家思考的重新定位：别让大语言模型去适应那套烂软件开发生命周期。根据大语言模型真正擅长的东西去改造软件开发生命周期，那样循环（以及软件开发生命周期）的很大一部分就消失了。不是全部——有些反馈是真的、必要的——但很多都会消失。
So what do you build instead? Workflows, not loops.那替代方案是什么？工作流，不是循环。
A workflow is a directed thing. It has a shape. It moves from a known input to a known output through steps that each do one clear job, and it only bends back on itself where a real signal says it must. Not on a fixed “reflect every turn” cadence because the architecture diagram had a box for it. Here are the approaches I’d actually reach for, and roughly in the order I’d reach for them.工作流是有方向的东西。它有形状。从已知的输入走到已知的输出，每一步只干一件清楚的事，只有在真实信号要求时才往回拐。不是按固定的“每轮反思”节拍，因为架构图上有个框。下面是我实际会用的方法，大致按优先顺序排列。
1. Front-load context so the first pass is the good pass1. 把上下文前置，让第一次尝试就是好尝试
The single biggest source of looping is a bad first attempt caused by starved input – a barren prompt that is missing context, scope, and specifics. So stop starving it. Instead of a thin prompt and a correction loop to claw the quality back, spend your engineering effort upfront assembling everything the model needs: the relevant code, the schemas, the conventions, the prior decisions, the actual constraints. Curate it. Structure it. Hand the model the whole board. Give it a specific thing to do with plenty of reference (MCP/RAG, etc) to get what it needs to get the job done right from inception.循环最大的来源是输入不足导致的糟糕第一次尝试——一个空荡荡的提示，缺少上下文、范围和细节。那就别再让它挨饿。与其用瘦提示加上纠正循环把质量往回拽，不如把工程精力花在提前准备好模型需要的一切上：相关的代码、模式、约定、先前的决策、实际的约束。整理好。结构化。把整块面板递给模型。明确告诉它要做什么，并给足参考（比如MCP/RAG等），让它一开始就能拿到做好工作所需的东西。
This is a workflow move, not a loop move. You’re not iterating toward context — you’re delivering it before step one. The payoff is enormous, because every loop you avoid is latency and tokens and a chance to go off the rails that you never spent. A well-fed single pass beats a starved five-pass loop most of the time, and it’s cheaper and easier to reason about. Put the work where it compounds: the input.这是工作流的方法，不是循环的。你不是在通过迭代获取上下文——你在第一步之前就已经把上下文送达了。回报巨大，因为你避免的每一次循环都是没花出去的延迟和令牌，也是一个省去的偏离轨道的风险。喂饱的单次尝试大多数时候胜过饿着的五次循环，而且更便宜、更容易理解。把功夫花在能产生复利的地方：输入。
2. Decompose along data flow, not along a status board2. 沿着数据流分解，而不是沿着状态板
When a task genuinely is too big for one pass, the instinct from SDLC-brain is to break it into “tickets” and manage them in a loop. Don’t. Break it along the data instead – a pipeline where each stage has a typed input and a typed output, and stages connect because one’s output is literally the next one’s input.当一个任务真的太大，一次处理不了时，软件开发生命周期思维的本能是把它拆成“工单”放在循环里管理。别这样做。改为沿着数据分解——一个流水线，每个阶段有类型化的输入和输出，阶段之间通过一个阶段的输出是下一个阶段的输入来连接。
Extract, then transform, then validate, then render. Parse, then plan, then generate, then check. Each stage is a small, boring, testable unit that does one thing to a known input. This is the old Unix-pipe wisdom, and it holds up beautifully with LLMs: small components with sharp interfaces that you can compose, test, and swap. The magic is that a clean pipeline removes the reason to loop – you’re not re-planning the whole job when stage three hiccups, you’re re-running stage three. The blast radius of a failure is one stage, not the entire task. That’s the difference between a workflow and a loop: the workflow contains failure; the loop lets it slosh around the whole system.提取，然后转换，然后验证，然后渲染。解析，然后规划，然后生成，然后检查。每个阶段是一个小型的、无趣的、可测试的单元，对已知输入做一件事。这是古老Unix管道的智慧，在大语言模型上依然成立：小组件配上清晰的接口，可以组合、测试、替换。妙处在于，干净的流水线消除了循环的理由——当第三阶段出问题时，你不是重新规划整个任务，而是重新运行第三阶段。一次失败的波及范围只有一个阶段，而不是整个任务。这就是工作流和循环的区别：工作流把失败包裹起来；循环让它在整个系统里晃荡。
3. Make feedback event-driven, not clock-driven3. 让反馈由事件驱动，而不是由时钟驱动
Here’s where I think the loop crowd goes most wrong. In a canonical loop, you reflect and re-plan every iteration, on a cadence, whether or not anything happened worth reflecting on. That’s the transformer equivalent of a daily standup where nothing changed but everyone talks anyway. Pure ceremony.我认为循环派在这里错得最厉害。在规范循环里，你每轮迭代都要反思和重新规划，按节拍进行，不管有没有值得反思的事情发生。这就像每天开站会，什么也没变但人人都在说话。纯粹的仪式。
Flip it. Don’t loop on a clock – react to events. Wire the model into a workflow where a specific, real signal triggers a specific corrective action. Tests failed? Route the failing output and the error back for a targeted fix – not a full re-plan, just “fix this.” Schema validation rejected the payload? Send it back with the exact violation. A confidence or a guard check tripped? Escalate that one thing. Everything else flows straight through.反过来。别按时钟循环——对事件做出反应。把模型接入一个工作流，其中某个具体的真实信号触发某个具体的纠正动作。测试失败？把失败输出和错误送回来做针对性修复——不是全面重新规划，只是“修好这个”。模式验证拒绝了负载？连确切违规一起送回去。置信度或守卫检查触发了？把那一件事升级处理。其他一切径直流过。
The behavior looks loop-like from a distance, sure – things sometimes go back around. But the structure is completely different, and the difference is the whole point. Correction happens because something concrete demanded it, scoped to exactly what broke, instead of on a blind fixed schedule that burns tokens re-litigating work that was already fine. Nine times out of ten nothing needs to go back, and your workflow should sail straight through when that’s the case.从远处看，这种行为看起来像循环——有些东西确实会绕回来。但结构完全不同，而区别恰恰是关键。纠正是因为有具体的事情要求它，范围限定在恰好坏掉的东西上，而不是按固定的盲计划烧令牌重新评判已经没问题的工作。十次有九次不需要回退，那时你的工作流应该径直通过。
4. Push determinism to the edges and let the model do the fuzzy middle4. 把确定性推到边缘，让模型处理中间的模糊部分
A ton of what gets stuffed inside these loops is stuff the model has no business doing repeatedly – running code, hitting an API, checking a value against a rule, formatting an output. Every time you make the LLM babysit that inside a reasoning loop, you’ve added a slow, nondeterministic, expensive step to do a job that a plain function does perfectly, instantly, and the same way every time.大量被塞进循环里的东西是模型不该反复做的——运行代码、调用API、检查值是否符合规则、格式化输出。每次你让大语言模型在推理循环里看管这些，你就为一项普通函数能完美、瞬时、每次相同完成的工作增加了一个缓慢、不确定、昂贵的步骤。
So carve it out. Let deterministic code own everything that can be deterministic: the tool calls, the validation, the I/O, the formatting, the branching on hard rules. Let the model own the genuinely fuzzy judgment in the middle – the part that actually needs a language model. When you draw that line cleanly, the “loop” collapses into a mostly-straight workflow with the LLM as one well-scoped component inside a larger deterministic system, instead of the LLM being the anxious general contractor re-checking every subcontractor’s work on every pass. Less looping, more determinism, and the model spends its cycles on the one thing only it can do.所以把它切出去。让确定性代码拥有所有可以确定的东西：工具调用、验证、I/O、格式化、基于硬规则的分支。让模型拥有中间真正模糊的判断部分——这部分才真正需要语言模型。当你划清这条线时，“循环”就坍缩成一个基本直线的工作流，大语言模型作为更大确定性系统中的一个边界清晰的小组件，而不是那个焦虑的总包每次都在检查每个分包商的工作。更少循环，更多确定性，模型的计算周期花在只有它能做的事情上。
Pulling it together综合起来
Put those four together and look at the shape you get. You front-load context so the first pass lands. You decompose along data flow so failures stay contained. You make correction event-driven so you only bend back when something real demands it. And you push everything deterministic out to the edges so the model isn’t looping over work a function should own. What’s left is a workflow – directed, inspectable, cheap, testable – with the LLM doing the fuzzy judgment it’s uniquely good at and nothing else.把上面四点放在一起，看看你得到的形状。你把上下文前置，让第一次尝试落地。你沿着数据流分解，让失败保持局限。你让纠正由事件驱动，这样只有真实的事情要求时才回退。你把所有确定性的东西推到边缘，这样模型就不会循环做那些应该由函数掌握的工作。剩下的是一个工作流——有方向、可检查、廉价、可测试——大语言模型只做它最擅长的不确定判断，不做别的。
Compare that to the canonical loop: an undirected grind, re-planning and re-reflecting on a cadence, coordination overhead standing in for capability, the whole thing shaped by the assumption that every hand-off is lossy and every input is garbled – assumptions that came straight out of the broken SDLC and mostly don’t apply here.把它和规范循环对比：无方向的苦磨，按节拍重新规划和反思，协调开销代替能力，整个结构基于每个交接都丢信息、每个输入都走样的假设——这些假设直接来自有问题的软件开发生命周期，在这里大部分不适用。
I want to be fair about it: loops aren’t always wrong. There are open-ended, genuinely exploratory problems where you can’t shape the path in advance and try-check-try is honestly the best you’ve got. Fine. But that’s the exception, and right now the industry is treating it as the default. We’re reaching for the loop reflexively because it feels like the rigorous, grown-up, “real engineering” thing to do – when a lot of the time it’s just the old ceremony in new clothes.公平地说：循环并非总是错的。有些开放式的、真正探索性的问题你无法预先规划路径，试-检查-再试确实是你能做的最好选择。这没问题。但那是例外，而现在行业把它当成了默认。我们下意识地伸手去拿循环，因为它感觉像严谨的、成熟的、“真正的工程”做法——而很多时候它只是旧仪式穿了新衣服。
There’s more going on with LLMs than the loop. A lot more. The loop is one tool, and it’s become a bit of a security blanket for people who’d rather port their existing broken process than sit down and design a new one. My request is simple: before you wrap your model in yet another plan-act-reflect grinder, ask what the loop is actually for in your case. If the honest answer is “to cover for lossy hand-offs and missing context,” then you don’t have a loop problem. You have an SDLC you never cleaned up – and the fix is a workflow, not another lap.大语言模型能做的事远不止循环。循环只是工具之一，而且它已经成了某种安全毯——给那些宁可直接移植现有烂流程也不愿坐下来设计新流程的人。我的请求很简单：在你把模型裹进又一个规划-行动-反思的研磨机之前，问问自己循环在你的场景里到底是为了什么。如果诚实的答案是“为了弥补丢信息的交接和缺失的上下文”，那么你没有循环问题。你有一个从未清理干净的软件开发生命周期——解决方法是工作流，而不是再兜一圈。
