[{"data":1,"prerenderedAt":787},["ShallowReactive",2],{"blog-loop-engineering":3},{"id":4,"title":5,"body":6,"category":773,"date":774,"description":283,"extension":775,"meta":776,"navigation":777,"path":778,"seo":779,"series":780,"seriesOrder":762,"stem":781,"tags":782,"__hash__":786},"blog\u002Fblog\u002Floop-engineering.md","Loop Engineering：把\"提示 AI\"这件事交给 AI 自己",{"type":7,"value":8,"toc":761},"minimark",[9,13,28,36,57,65,73,80,88,93,96,105,115,126,133,139,143,146,247,254,261,266,270,273,284,316,323,328,332,335,341,348,355,360,364,367,460,467,472,476,483,492,554,565,572,579,590,597,602,606,609,628,637,643,648,651,664,669,673,676,682,688,694,700,706,711,714,717,749,752,755],[10,11,5],"h1",{"id":12},"loop-engineering把提示-ai这件事交给-ai-自己",[14,15,16],"blockquote",{},[17,18,19,20,27],"p",{},"推荐一个非常好用的海外 AI 代充平台 ",[21,22,26],"a",{"href":23,"rel":24},"https:\u002F\u002Fbewild.ai?code=BYZDOTME",[25],"nofollow","BeWild","，我的海外 AI 服务全都是在这个平台代充的。",[17,29,30,31,35],{},"最近几个月，AI 编程圈冒出一个新词：",[32,33,34],"strong",{},"Loop Engineering（循环工程）","。Peter Steinberger（Steipete）在一条推文里说了一句被反复引用的话：",[14,37,38],{},[17,39,40,41,44,45,50,51,56],{},"\"别再手动提示 coding agent 了。你应该设计的是",[32,42,43],{},"让 agent 跑起来的循环","。\"\n—— Steipete 推文，2026 年 6 月（经 ",[21,46,49],{"href":47,"rel":48},"https:\u002F\u002Faddyosmani.com\u002Fblog\u002Floop-engineering\u002F",[25],"Addy Osmani 博客","与 ",[21,52,55],{"href":53,"rel":54},"https:\u002F\u002Fwww.theregister.com\u002Fai-and-ml\u002F2026\u002F06\u002F24\u002Floop-engineering-latest-ai-buzzword-still-needs-humans-in-the-loop\u002F5261735",[25],"The Register"," 转述）",[17,58,59,60,64],{},"Anthropic Claude Code 负责人 Boris Cherny 在另一次场合说了几乎一样的话：\"我已经不直接 prompt Claude 了，我有一堆跑着的循环在替我 prompt Claude、搞清楚该干什么。我的工作是写循环。\"（同样经 ",[21,61,63],{"href":53,"rel":62},[25],"The Register 同篇报道","转述）",[17,66,67,68,72],{},"这两句话几乎同时引爆话题，Addy Osmani 随即写了篇",[21,69,71],{"href":47,"rel":70},[25],"同名博客","把概念系统化。一时间 Hacker News 上相关讨论近千条，\"loop engineering\"成了继 prompt engineering、agentic coding 之后又一个被争相讨论的标签。",[17,74,75,76,79],{},"但这个概念到底是真进步，还是旧瓶装新酒？我研究了一圈一手资料后，发现答案是：",[32,77,78],{},"两者都是","。这篇文章就来把它拆开看清楚——它新在哪里、旧在哪里、以及作为工程师该怎么理性地用它。",[17,81,82,83,87],{},"如果你读过我这个博客上一篇 ",[21,84,86],{"href":85},"\u002Fblog\u002Fai-agent-harness-engineering","《AI Agent 的工程化哲学：Harness 设计的核心原则》","，可以把本文当成它的下一层：Harness 讲的是\"如何搭好单个 agent 的脚手架\"，Loop Engineering 讲的是\"如何在脚手架之上再搭一层让 agent 自己跑起来的循环\"。Addy 自己也是这么定位的——loop engineering 是 harness engineering 的上一层。",[89,90,92],"h2",{"id":91},"_1-到底什么是-loop-engineering","1. 到底什么是 Loop Engineering",[17,94,95],{},"先把定义说清楚。Addy Osmani 给出的最常被引用的定义是：",[14,97,98],{},[17,99,100,101,104],{},"\"Loop engineering 是用一套系统替换掉'那个亲自提示 agent 的人'。你来设计这个系统，让它去提示。这里的 loop 可以理解成一个",[32,102,103],{},"递归目标","——你定义一个目的，AI 不断迭代直到完成。\"",[17,106,107,108,110,111,114],{},"关键词是",[32,109,103],{},"和",[32,112,113],{},"迭代直到完成","。传统用 AI 编程是\"你说一句、它做一步、你再说一句\"——你是那个 driver，每一轮都要你在场。Loop Engineering 要把人从 driver 座位上挪开，换成一坨自动跑的代码：它自己发现该干什么、自己干、自己验、自己记录、自己决定下一步。人退到\"循环设计者\"的位置上。",[17,116,117,118,121,122,125],{},"打个比方：用 Claude Code 像是在",[32,119,120],{},"开车","，你的每一次指令都是打方向盘；Loop Engineering 像是在",[32,123,124],{},"给车装自动驾驶","，你设定目的地和规则，它自己跑，你只在关键路口接管。",[17,127,128,129,132],{},"这不是简单的\"让 agent 多跑几轮\"。ReAct 循环、agentic coding 早就有了，Loop Engineering 多出来的东西是",[32,130,131],{},"让循环能长期、自治、可记忆地跑下去的那套外围设施","——调度、隔离、记忆、验证、子 agent。这才是它作为一个新标签的内核。",[17,134,135,138],{},[32,136,137],{},"小结："," 从 prompt engineering 到 loop engineering，人机关系的转变是从\"我每一轮都在场\"到\"我设计好规则就离场\"。这个转变能不能成立，完全取决于那套外围设施搭得够不够硬。",[89,140,142],{"id":141},"_2-一个-loop-需要的五件套-一个记忆","2. 一个 Loop 需要的五件套 + 一个记忆",[17,144,145],{},"Addy 把一个 loop 拆成五个组件外加一个记忆载体。这个模型很实用，直接照搬过来：",[147,148,149,165],"table",{},[150,151,152],"thead",{},[153,154,155,159,162],"tr",{},[156,157,158],"th",{},"组件",[156,160,161],{},"作用",[156,163,164],{},"为什么是它",[166,167,168,182,195,208,221,234],"tbody",{},[153,169,170,176,179],{},[171,172,173],"td",{},[32,174,175],{},"Automations（自动化）",[171,177,178],{},"按计划触发 agent 的\"心跳\"",[171,180,181],{},"没有它，loop 就不是 loop，只是一次性脚本",[153,183,184,189,192],{},[171,185,186],{},[32,187,188],{},"Worktrees（工作树）",[171,190,191],{},"给每个并行 agent 一个隔离的工作目录",[171,193,194],{},"防止多个 agent 同时改一个文件互相踩",[153,196,197,202,205],{},[171,198,199],{},[32,200,201],{},"Skills（技能）",[171,203,204],{},"把项目约定固化成 SKILL.md",[171,206,207],{},"避免 loop 每轮都从零推导你的项目该怎么写",[153,209,210,215,218],{},[171,211,212],{},[32,213,214],{},"Plugins \u002F Connectors（连接器）",[171,216,217],{},"让 agent 接入真实系统",[171,219,220],{},"能开 PR、更 ticket、发 Slack，loop 才能真正交付",[153,222,223,228,231],{},[171,224,225],{},[32,226,227],{},"Sub-agents（子 agent）",[171,229,230],{},"把\"制造者\"和\"检查者\"分开",[171,232,233],{},"写代码的不能给自己批作业，得另派一个 agent 验证",[153,235,236,241,244],{},[171,237,238],{},[32,239,240],{},"Memory（记忆）",[171,242,243],{},"活在单次对话之外的状态",[171,245,246],{},"记录\"做了什么、下一步是什么\"，存在 markdown 或看板里",[17,248,249,250,253],{},"第五条\"制造者\u002F检查者分离\"特别值得展开。人类写代码都有\"自己写的 bug 自己看不出来\"的问题，LLM 更甚——它对自己产出的置信度天生偏高。所以一个靠谱的 loop 一定会派",[32,251,252],{},"第二个 agent"," 来审查第一个 agent 的产出，而且最好用不同的 prompt 甚至不同的模型。Addy 特别提到，很多成熟 agent 框架会用一个独立的 goal-checker（通常配更小更便宜的模型）来判断\"任务到底完成没有\"——停止条件必须是可验证的，比如\"auth 模块测试全过、lint 干净\"，而不是让干活的模型自评一句\"done\"。",[17,255,256,257,260],{},"这里有个反直觉的点：Memory 用 markdown 文件或 Linear 看板这种\"土\"载体，而不是塞进 LLM 的 context window。原因很现实——",[32,258,259],{},"agent 会忘，但 repo 不会忘","。把状态写在磁盘上，下一次循环从文件读起来接着干，比指望模型记住跨会话的上下文可靠得多。这其实是 Context Engineering 的延伸：上下文窗口是稀缺资源，长期状态就该外置。",[17,262,263,265],{},[32,264,137],{}," 一个能脱离人长期跑的 loop，缺一不可的是这五件套加一个外部记忆。其中最容易被忽视、也最关键的是\"制造者\u002F检查者分离\"和\"状态外置\"——前者保证质量，后者保证连续性。",[89,267,269],{"id":268},"_3-四层循环栈从会跑到会进化","3. 四层循环栈：从\"会跑\"到\"会进化\"",[17,271,272],{},"Addy 的五件套是\"横向\"的组件视角。LangChain 给了一个\"纵向\"的分层视角，把 loop 工程拆成四层嵌套的循环栈。我觉得这个框架更透，因为它解释了 loop engineering 的价值到底在哪一层：",[274,275,280],"pre",{"className":276,"code":278,"language":279},[277],"language-text","┌─────────────────────────────────────────────┐\n│ Loop 4  Hill-climbing loop   自我改进        │  ← 用生产 trace 优化 harness 配置\n├─────────────────────────────────────────────┤\n│ Loop 3  Event-driven loop    嵌入生态        │  ← cron\u002Fwebhook 触发，后台常驻\n├─────────────────────────────────────────────┤\n│ Loop 2  Verification loop    质量闸门        │  ← grader 按标准打分，失败带反馈重试\n├─────────────────────────────────────────────┤\n│ Loop 1  Agent loop           干活            │  ← 模型反复调工具直到子任务完成\n└─────────────────────────────────────────────┘\n","text",[281,282,278],"code",{"__ignoreMap":283},"",[285,286,287,294,300,306],"ul",{},[288,289,290,293],"li",{},[32,291,292],{},"Loop 1（Agent loop）","：最底层，就是模型在一个子任务里反复\"调工具 → 看结果 → 再调\"直到干完。这是 ReAct 时代就有的，不算新。",[288,295,296,299],{},[32,297,298],{},"Loop 2（Verification loop）","：在 Loop 1 外面套一个验证循环。agent 干完不是直接交付，而是交给一个 grader 按评分标准检查；不过关就把失败原因喂回去让它重做。这就是上一篇 Harness 文章里讲的 Verifier Loop 的工程化形态。",[288,301,302,305],{},[32,303,304],{},"Loop 3（Event-driven loop）","：让 loop 真正\"活\"在系统里——cron 定时触发、webhook 事件触发，agent 在后台常驻运行。这一层是 loop 从\"手动跑一次\"变成\"自动持续跑\"的关键。Addy 的\"早晨循环\"就是典型形态：每天定时跑起来，扫 CI 失败和 issue，自己派活、自己开 PR。",[288,307,308,311,312,315],{},[32,309,310],{},"Loop 4（Hill-climbing loop）","：最上层，也是最科幻的一层。把生产环境的 trace 喂给一个分析 agent，让它根据实际运行数据",[32,313,314],{},"重写下面几层 harness 的配置","——loop 不只是干活，还在改进自己干活的系统。一个最小可行形态长这样：把 Loop 2 里 grader 打分偏低、却靠重试蒙混过关的 case 收集起来，喂给一个分析 agent，让它自动改写 grader 的 rubric prompt 或调整某个工具的 description，下次 Loop 2 就能用更严的标准拦住同类问题。这本质是把 eval 结果当优化信号，反向喂给 harness——再往前一步，LangChain 甚至展望它对接 RL fine-tuning，用 trace 直接改模型本身。",[17,317,318,319,322],{},"一个关键判断：",[32,320,321],{},"Loop 1、2 是基本功，Loop 3 是分水岭，Loop 4 是远景","。绝大多数团队现在能做好 Loop 1 就不错了，Loop 2 要认真做验证基础设施，Loop 3 才是\"loop engineering\"这个标签真正想强调的东西——让 agent 真正嵌入工作流自治运行。Loop 4 目前基本还是愿景，但它指出了 loop engineering 的终极方向：让系统自己变好。",[17,324,325,327],{},[32,326,137],{}," 四层循环栈里，真正的工程价值集中在 Loop 2（验证）和 Loop 3（事件驱动）。Loop 1 早就有，Loop 4 还很远。判断一个所谓\"loop engineering\"方案成不成熟，看它有没有把 Loop 2、3 做扎实就够了。",[89,329,331],{"id":330},"_4-一个早晨循环长什么样","4. 一个早晨循环长什么样",[17,333,334],{},"抽象框架讲完，来个具体的。Addy 描述了一个他每天在用的\"早晨循环\"，很能说明 loop engineering 的实际形态：",[274,336,339],{"className":337,"code":338,"language":279},[277],"每天早晨 cron 触发\n   ↓\nautomation 跑在 repo 上，调用 triage skill\n   ↓\n读取：昨天的 CI 失败、open issues、最近 commits\n   ↓\n把发现写进 markdown \u002F Linear 看板（Memory）\n   ↓\n对每个值得做的发现：\n   ├─ 开一个隔离 worktree\n   ├─ 派 sub-agent A 起草修复\n   └─ 派 sub-agent B 对照项目 skills 和测试审查 A 的草稿\n   ↓\nconnectors 开 PR、更新 ticket\n   ↓\nloop 处理不了的 → 扔进 triage inbox 给人\n",[281,340,338],{"__ignoreMap":283},[17,342,343,344,347],{},"注意这个流程里人什么时候出现——",[32,345,346],{},"只在最后，处理 loop 自己搞不定的东西","。前面所有环节：发现工作、隔离环境、起草、审查、开 PR，全是 loop 自己跑的。人从\"每一行代码的审批者\"变成了\"异常处理者\"。",[17,349,350,351,354],{},"这听起来很美，但有个容易忽略的成本：",[32,352,353],{},"人的 review 带宽是天花板","。Addy 自己强调，worktree 解决的是多个 agent 互相踩踏的\"机械碰撞\"，但解决不了\"人看得过来吗\"这个问题——你能同时 review 几个 agent 开的 PR，决定了你这个 loop 实际能跑多大规模。工具不是瓶颈，你是瓶颈。这点我深以为然，很多人讨论 loop engineering 时只盯着自动化能跑多快，却不想想自己 review 的速度跟不上，结果 loop 跑出来的东西堆在那没人看，反而是负资产。",[17,356,357,359],{},[32,358,137],{}," 一个成熟的 loop 把人挤到异常处理的位置，但人的 review 带宽决定了 loop 的实际吞吐上限。自动化跑得再快，review 跟不上就是堆废代码。",[89,361,363],{"id":362},"_5-它和那些相邻概念什么关系","5. 它和那些相邻概念什么关系",[17,365,366],{},"Loop engineering 不是凭空冒出来的，它处在一堆近义词的包围里。不讲清关系，很容易越看越糊涂：",[147,368,369,379],{},[150,370,371],{},[153,372,373,376],{},[156,374,375],{},"概念",[156,377,378],{},"和 Loop Engineering 的关系",[166,380,381,395,408,421,434,447],{},[153,382,383,389],{},[171,384,385,388],{},[32,386,387],{},"Vibe Coding","（Karpathy, 2025）",[171,390,391,394],{},[32,392,393],{},"前驱与对立面","。vibe coding 是\"跟着感觉走、不读代码、人在场\"，loop engineering 是\"结构化、自动化、人离开\"。从感性共舞走向工程化自治",[153,396,397,402],{},[171,398,399],{},[32,400,401],{},"Agentic Coding",[171,403,404,407],{},[32,405,406],{},"包含与演化","。agentic coding 泛指 agent 自主调工具干活，loop engineering 是它进一步要求\"可调度、可记忆、多层循环\"的演化形态",[153,409,410,415],{},[171,411,412],{},[32,413,414],{},"Context Engineering",[171,416,417,420],{},[32,418,419],{},"子组件","。context\u002Fmemory 管理是 loop 五件套里的 Memory 和 Skills，是 loop 能长期跑的前提",[153,422,423,428],{},[171,424,425],{},[32,426,427],{},"Spec-Driven Development",[171,429,430,433],{},[32,431,432],{},"互补","。spec 可作为 loop 的输入契约和验证标准（Loop 2 的 rubric）",[153,435,436,441],{},[171,437,438],{},[32,439,440],{},"Eval-Driven Development",[171,442,443,446],{},[32,444,445],{},"高度重叠","。Loop 2 的 grader 和 Loop 4 的 trace 分析本质就是 eval 驱动",[153,448,449,454],{},[171,450,451],{},[32,452,453],{},"Harness Engineering",[171,455,456,459],{},[32,457,458],{},"下层","。harness 是单 agent 的运行环境，loop engineering 是 harness 之上加调度、子 agent、自我喂食",[17,461,462,463,466],{},"一句话总结这张关系图：",[32,464,465],{},"Loop engineering 是个上位概念，它把 agentic coding、context engineering、eval-driven、spec-driven 当组件编织进一个自治循环系统；vibe coding 是它的前驱与反面。"," 这也解释了为什么它争议大——上位概念天然容易\"看起来什么都包含、又什么都没新说\"。",[17,468,469,471],{},[32,470,137],{}," 别把 loop engineering 当成一个独立的新学科，它是把一堆已有实践（agent 循环、context 管理、eval、spec）编织进一个自治系统的\"打包命名\"。理解它最好的方式是理解它打包了什么。",[89,473,475],{"id":474},"_6-争议这是新工程还是旧概念换皮","6. 争议：这是新工程，还是旧概念换皮？",[17,477,478,479,482],{},"这是整件事最值得认真看的部分。Loop engineering 一边被追捧，一边被尖锐批评。批评方核心论点很统一：",[32,480,481],{},"你说的这些，分布式系统二十年前的概念都有","。",[17,484,485,486,491],{},"iii.dev 的 Mike Piccolo 给了一张很扎眼的",[21,487,490],{"href":488,"rel":489},"https:\u002F\u002Fiii.dev\u002Fblog\u002Floop-engineering-is-just-software-engineering\u002F",[25],"术语对照表","：",[147,493,494,504],{},[150,495,496],{},[153,497,498,501],{},[156,499,500],{},"Loop Engineering 术语",[156,502,503],{},"二十年前的分布式系统叫法",[166,505,506,514,522,530,538,546],{},[153,507,508,511],{},[171,509,510],{},"Automations",[171,512,513],{},"Cron 定时任务",[153,515,516,519],{},[171,517,518],{},"Memory",[171,520,521],{},"KV 存储",[153,523,524,527],{},[171,525,526],{},"Sub-agents",[171,528,529],{},"消息队列里的隔离 worker",[153,531,532,535],{},[171,533,534],{},"Verifier",[171,536,537],{},"带 retry 的发布订阅",[153,539,540,543],{},[171,541,542],{},"Traces",[171,544,545],{},"可观测性 pipeline",[153,547,548,551],{},[171,549,550],{},"Triage inbox",[171,552,553],{},"死信队列（Dead-letter queue）",[17,555,556,557,560,561,564],{},"他的结论很直接：",[32,558,559],{},"\"命名不同，系统是一样的。\""," AWS SQS 早在 2004 年就上线了（比 S3 和 EC2 还早）。",[21,562,55],{"href":53,"rel":563},[25]," 更是冷嘲热讽，说这是在\"celebrating autonomous token consumption\"（为\"自主烧 token\"欢呼），并指出编程里的循环早在 Fortran 时代就有。",[17,566,567,568,571],{},"这些批评对不对？",[32,569,570],{},"对，事实层面完全对","。loop engineering 描述的机制——调度、重试、死信、隔离、可观测——确实都是分布式系统的老概念。如果你是一个做过消息队列、工作流引擎、批处理系统的工程师，看 loop engineering 的五件套会有强烈的\"这不就是 XX 吗\"的既视感。",[17,573,574,575,578],{},"但批评也漏了一层。",[32,576,577],{},"旧概念换了个新场景，本身就是有价值的工程进展","。这些分布式系统原语过去是给\"确定性的业务代码\"用的，现在要套到\"非确定性的 LLM\"上，这个迁移不是简单改名：",[285,580,581,584,587],{},[288,582,583],{},"LLM 的输出是概率性的，验证循环（Loop 2）的比重远大于传统系统——你不能假设一次执行就对。",[288,585,586],{},"LLM 有 context window 限制，Memory 这一层不只是缓存，而是\"把记忆外置让 agent 跨会话连续\"的专门设计。",[288,588,589],{},"LLM 的\"智能\"可以被引导，所以 Skills（把项目知识固化）这一层在传统系统里没有对应物——你不需要给一个 SQS worker 讲\"我们项目的代码风格\"。",[17,591,592,593,596],{},"所以我的判断是：",[32,594,595],{},"机制是旧的，场景是新的，组合是有价值的","。把它当神药吹捧是傻，把它当纯营销话术一棍子打死也是懒。正确的态度是承认它的工程内核借鉴了成熟的分布式系统设计，同时认真对待 LLM 这个新场景带来的新约束。",[17,598,599,601],{},[32,600,137],{}," 批评者说\"这就是分布式系统旧概念\"在事实上没错，但忽略了把这些原语适配到非确定性 LLM 场景本身就是工程迁移。loop engineering 的价值不在发明新机制，在于把老机制和新场景做了一次有效组合。",[89,603,605],{"id":604},"_7-真实代价钱理解腐烂认知缴械","7. 真实代价：钱、理解腐烂、认知缴械",[17,607,608],{},"比起概念之争，更该关心的是实际代价。有意思的是，最清醒的风险清单来自 Addy 本人——他在定义 loop engineering 的同一篇文章里就列了三大风险，这种坦诚反而增加了他的可信度。",[17,610,611,614,615,620,621,624,625],{},[32,612,613],{},"第一，验证仍然在你身上。"," 无人值守的 loop 也在无人值守地犯错。agent 说\"done\"是声明，不是证明。如果你没配好 Loop 2 的验证循环，或者验证标准本身有漏洞，loop 会又快又自信地生产错误。",[21,616,619],{"href":617,"rel":618},"https:\u002F\u002Fjeena.net\u002Floop-engineering",[25],"jeena.net 有一个血淋淋的案例","：他用完整的 plan\u002Fexecute\u002Fcritique\u002Frepair 循环架构做韩译英翻译，结果 critic 一直说\"翻得不够好\"打回来，executor 又一直改进不到让 critic 满意的程度——",[32,622,623],{},"死循环跑了几个星期，最后放弃了","。这是 loop engineering 的典型失败模式：验证者和执行者陷入死锁，没有断路器（circuit breaker）兜底。",[32,626,627],{},"loop 能替你干活，但替不了你判断干得对不对。",[17,629,630,633,634],{},[32,631,632],{},"第二，理解腐烂（comprehension debt）。"," loop 越快地 ship 你没读过的代码，\"代码库里存在的\"和\"你真正理解的\"之间的差距就越大。短期看产出飞快，长期看你维护的是一个自己越来越看不懂的系统。这比技术债更阴险——技术债至少你知道欠了多少，理解腐烂是你根本意识不到自己不懂了。",[32,635,636],{},"代码能跑和你能维护，是两件事。",[17,638,639,642],{},[32,640,641],{},"第三，认知缴械（cognitive surrender）。"," 这是最微妙也最危险的一个。loop 自跑的时候，人极易\"放弃自己的判断、照单全收\"。Addy 有句话说得很准：",[14,644,645],{},[17,646,647],{},"\"Designing the loop is the cure when you do it with judgement, and the accelerant when you do it to avoid thinking. 同一个动作，相反的结果。\"",[17,649,650],{},"他自己也说，如果不是亲自 review 代码、而是完全依赖自动 loop 来修，\"产品质量会下降，很可能陷入下行螺旋\"。",[17,652,653,654,657,658,663],{},"除了 Addy 列的三条，还有个绕不开的现实问题：",[32,655,656],{},"钱","。loop 让多个 sub-agent 各跑各的，每个都烧 token。Ed Zitron 在批评时引用了一个数字（虽是批评者转述）——Boris Cherny 每月的 token 开销\"upwards of $130,000\"。这个量级对个人开发者和小团队是天文数字。loop engineering 默认假设你烧得起 token，这个假设本身就筛掉了大多数人。",[21,659,662],{"href":660,"rel":661},"https:\u002F\u002Fblog.codacy.com\u002Fthe-ai-coding-maturity-scale-the-path-to-loop-engineering",[25],"Codacy 的调研","也佐证：开发者平均每周已经在 Claude Code 里花 20 小时，且团队在\"增加而非削减\"每个开发者的 token 预算。loop engineering 是有门槛的奢侈玩法。",[17,665,666,668],{},[32,667,137],{}," loop engineering 的真实代价是四重：验证漏了会又快又错、理解会随自动化腐烂、人容易认知缴械放弃判断、token 开销可能高到不可承受。前三个尤其阴险，因为它们不会立刻暴露，而是悄悄累积。",[89,670,672],{"id":671},"_8-工程师该怎么理性对待它","8. 工程师该怎么理性对待它",[17,674,675],{},"讲了这么多，落到一个实际问题：作为工程师，现在该怎么对待 loop engineering？我的建议是分阶段、看场景：",[17,677,678,681],{},[32,679,680],{},"先别急着搭 Loop 3、4，把 Loop 1、2 做扎实。"," 大多数人连单 agent 的验证循环都没做好，就想着搞自动调度、多 agent 并行，这是典型的还没学会走就想跑。先把\"agent 干完 → 客观验证 → 失败带反馈重试\"这条 Loop 2 跑通，再谈更高层。Loop 2 的 grader 和测试基础设施，是后面一切的地基。",[17,683,684,687],{},[32,685,686],{},"状态外置比上下文塞满重要。"," 这是 loop 能不能脱离人长期跑的关键分水岭。把\"做了什么、下一步是什么\"写在磁盘文件或看板里，而不是指望模型记住。你设计 loop 的第一件事应该是设计它的 state schema——这和设计任何长跑系统一样。",[17,689,690,693],{},[32,691,692],{},"制造者\u002F检查者分离，从单 agent 内部先做起。"," 不一定要上来就派两个 sub-agent。先在一个 agent 里，让\"写代码\"和\"review 代码\"用不同的 prompt 角色切换，也能拿到大部分收益。等你发现单 agent 自审总是漏 bug，再升级到真正的双 agent。",[17,695,696,699],{},[32,697,698],{},"对\"无人值守\"保持警惕。"," loop 跑得越自动，你越要保留人类检查点（human-in-the-loop）。LangChain 强调\"自动化不等于移除人类\"——敏感动作（改生产配置、动数据库、发外部消息）前必须人类审批。loop 的自动化程度，应该和你的验证可靠度匹配，而不是和你的乐观程度匹配。",[17,701,702,705],{},[32,703,704],{},"给 worktree 并发数设两道闸门：token 预算和 review 带宽。"," 这是 loop engineering 比 harness 多出来的一层具体约束。N 个 sub-agent 并行就是 N 倍的 token 烧速，先按\"月 token 预算 ÷ 单 agent 平均消耗\"估出 token 维度的安全并发数；再算你一天能认真 review 几个 PR——两者取小值，才是你实际该开的 worktree 数。多数人会高估第一项、忽略第二项，结果要么月底账单爆炸，要么 PR 堆成山没人看。",[17,707,708,710],{},[32,709,137],{}," 分阶段、看场景，别让自动化程度超过验证可靠度。loop engineering 目前还处于\"流行词 + 实践流派\"的早期阶段，没有统一标准定义，公开的可验证生产案例也极少——除了 jeena 那个失败案例和 iii.dev 的产品自述，几乎没有带量化指标的第三方生产数据。所以现在学它的价值，在于学这套工程思维（调度、隔离、验证、记忆、子 agent 的组合），而不是急着找个\"标准框架\"照搬。那些分布式系统的老概念之所以能用二十年，正因为它经过充分验证；loop engineering 要真正成熟，也得经过同样的检验。",[89,712,713],{"id":713},"总结",[17,715,716],{},"把整件事浓缩成几句话：",[285,718,719,725,731,737,743],{},[288,720,721,724],{},[32,722,723],{},"Loop Engineering 的内核","：把\"人逐轮提示 agent\"升级成\"人设计循环、agent 自治运行\"，核心是让循环能脱离人长期跑下去的那套外围设施（调度、隔离、记忆、验证、子 agent）。",[288,726,727,730],{},[32,728,729],{},"它的结构","：横向是 Addy 的\"五件套 + 一个记忆\"，纵向是 LangChain 的四层循环栈（agent → verification → event-driven → hill-climbing）。真正的工程价值在 Loop 2 和 Loop 3。",[288,732,733,736],{},[32,734,735],{},"它的争议","：机制是分布式系统二十年前的旧概念，但适配到非确定性 LLM 场景的这次迁移是有价值的组合，不必神化也不必贬低。",[288,738,739,742],{},[32,740,741],{},"它的代价","：验证漏洞、理解腐烂、认知缴械、token 成本——前三个阴险，第四个昂贵。",[288,744,745,748],{},[32,746,747],{},"怎么对待它","：先把 Loop 1、2 做扎实，状态外置，制造者\u002F检查者分离，保留人类检查点，别让自动化程度超过验证可靠度。",[17,750,751],{},"如果说 vibe coding 是\"感性共舞\"，harness engineering 是\"给 agent 搭脚手架\"，那 loop engineering 就是\"在脚手架之上装一套让 agent 自己干活的自动循环\"。三者是同一条演进线上的不同阶段。作为一个仍在快速分化的早期概念，现在最值得学的不是某个具体框架，而是它把已有工程原语重新组合的那套思路——调度、隔离、验证、记忆，这些词你换成 cron、worktree、测试、状态机，其实就是你早就熟悉的那些东西。",[17,753,754],{},"Loop engineering 没有发明新机制，它只是提醒我们：当模型聪明到可以自治时，工程师的主战场就从\"写每一行代码\"挪到了\"设计让代码自己被写出来的系统\"。这个转变是不是真的会发生、能走多远，还得再观察一阵——但至少，先把它的工程内核吃透，总没坏处。",[17,756,757],{},[21,758,760],{"href":759},"\u002Fblog\u002F","返回博客列表",{"title":283,"searchDepth":762,"depth":762,"links":763},2,[764,765,766,767,768,769,770,771,772],{"id":91,"depth":762,"text":92},{"id":141,"depth":762,"text":142},{"id":268,"depth":762,"text":269},{"id":330,"depth":762,"text":331},{"id":362,"depth":762,"text":363},{"id":474,"depth":762,"text":475},{"id":604,"depth":762,"text":605},{"id":671,"depth":762,"text":672},{"id":713,"depth":762,"text":713},"AI\u002FLLM","2026-07-16","md",{},true,"\u002Fblog\u002Floop-engineering",{"title":5,"description":283},"AI Agent 工程化","blog\u002Floop-engineering",[783,784,401,414,785],"Loop Engineering","AI Agent","AI编程","V_JTPbIOKw1lNlp8p2hJlKvzC1pyEVNi3ah9Kxvr-kE",1784193098907]