1. 先搞清楚 Loop Engineering 到底在工程什么我今年踩过最大的一个坑是一个数据同步任务在while True里默默空转了七个晚上。它没报错、没退出每天把一堆重复数据写进仓库直到监控告警才发现异常。当时我就在想很多系统的稳定性根本不是靠写对顺序逻辑而是靠写对那几条循环。后来团队把这类问题整理成一套做法我们内部叫它 Loop Engineering。如果你最近在社区里搜过 loop engineering 介绍会发现它其实不是一个教科书名词而是一种把“循环”当成一等公民来设计的工程视角循环里每轮状态是否可观测、出口条件是否可靠、反馈信号是否能真正推动下一轮变好。这篇文章不打算讲高深理论就按我实际做项目的顺序把原理、三类常见循环、一个可以直接抄走的项目实战代码、以及调试循环时踩过的坑一次性讲清楚。1.1 先把一个误区拆掉循环不是语法是系统行为一说“循环”写代码的人脑子里第一反应是for、while、do-while觉得这是最基本的语法有什么好“工程”的但 Loop Engineering 讲的不是语法层面的循环而是系统行为层面的循环。举几个例子一个用户从注册到复购是一条循环一个团队从提交代码到线上监控反馈是一条循环一个 AI Agent 从调用模型、执行工具、观察结果到再次调用模型更是一条循环。这些行为都有一个共同结构某件事重复发生每一轮的结果会影响下一轮直到某个条件满足才停下来。所以我在项目里给团队成员的定义是Loop Engineering 是让系统在重复中收敛而不是在重复中空转或发散的一整套工程手段。它关心的问题是这一轮比上一轮变好了多少什么时候该停反馈信号是具体还是含糊如果某个循环空转了七个晚上工程上要做的不是去责怪写while True的那个人而是要让循环本身具备自我暴露问题的能力。1.2 为什么这两年“loop engineering”突然被反复提起有两个直接推手。第一个推手是 AI Agent。以前循环藏得深一个支付重试模块里有循环一个定时任务里有循环但它们只是业务逻辑的配角。到了 LLM Agent 时代循环变成了产品的主干模型输出一个动作工具执行完把结果喂回模型模型再决定下一步整个过程就是一个标准的 Agent Loop。你可以不写传统的for循环但不可能不写这个执行环。于是大家突然发现原本被当成“语法常识”的循环居然成了决定项目成本、稳定性和效果上限的核心模块。第二个推手是业务对“反馈闭环”的追求。PDCA、OODA、双环学习这些概念早就有了但过去很多系统是“交付一次就结束”的线性思维。现在大家都认同一件事产品竞争力来自闭环速度——谁更快收集反馈、更快调整、更快验证谁就领先。这个词的热度本质上是工程界对“闭环速度”的一种重新聚焦。顺带说一句Loop Engineering 不等于“把 while 循环写得优雅”也不只是 AI Agent 的专利。它是一种跨领域的通用视角下面我拆开讲。2. 一个循环的四个零件状态、推进、出口、反馈我拆解任何循环都只看四个零件状态、推进、出口、反馈。不管是写一个三行的 while 循环还是设计一整套运营自动化的闭环这四个东西想清楚循环就成功了一半。2.1 状态循环里最容易被写脏的东西状态就是每一轮循环“带到下一轮”的信息。代码里它是一个计数器、一个累积数组、一个上下文缓冲区业务里它是库存数字、用户画像、累计反馈的集合。循环出问题一大半出在状态上。最常见的是状态被写脏两个线程改同一个全局变量或者一个函数里悄悄重置了循环计数器导致循环要么提前结束要么永远不完。我曾经排查过一个重试模块明明每次失败都加了attempts但外面有个定时任务会把进程里所有模块的计数器统一重置于是重试逻辑永远停不下来。工程上我习惯的做法很简单把循环相关状态收拢成一个对象或一条记录所有改动走显式更新绝不允许散落在不同函数里互相改。每轮结束打一个快照循环出问题时直接把快照拉出来对比不用靠猜。2.2 推进与出口没有退路的循环是定时炸弹推进指的是每一轮循环必须让某个关键变量朝出口方向移动。出口条件则分两类一类是“成功出口”例如分数达到阈值、任务完成另一类是“兜底出口”例如最大轮数、超时时间、人工中断信号。最容易踩的坑是只写了成功出口没写兜底出口。看看这段代码while not task.done: try: process(task) except Exception: # 这里忘了做任何计数或状态更新 continue如果process一直抛异常这个循环就永远在空转。它没有推进也没有出口。正确姿势是每一轮至少更新一个关键字段并且把最大轮数和超时作为强制约束写进去。更稳妥的做法是先定出口再写循环体。循环体写得再漂亮出口条件不稳早晚出事。2.3 反馈信号循环是否有用的判断依据没有反馈的循环只是重复劳动有反馈的循环才是控制器。反馈信号决定了下一轮和上一轮有什么不同。比如 CI 构建的失败日志是反馈给开发者的信号Agent 每一轮自评的分数是反馈给模型决策的信号用户点击率是反馈给推荐系统的信号。反馈信号要满足两个条件可量化、低延迟。可量化是为了让“变好了”这件事可判断低延迟是为了让循环能及时调整。我曾经做过一个自动生成营销文案的循环反馈信号就是“是否包含品牌词”这种简单规则结果每轮生成结果千奇百怪但都满足规则循环看起来很“收敛”实际对业务毫无价值。后来把反馈改成“包含品牌词 长度在 80 到 120 字 语气评分”效果立刻不一样。零件作用常见失效形式工程化手段状态记录循环在第几轮、带着什么信息变量被覆盖、状态污染、线程间互相改状态对象化、每轮打快照、显式更新推进保证每轮朝出口方向前进continue未改变任何变量、重复处理同一数据每轮至少更新一个关键字段代码评审强调出口终止循环的条件只写成功出口、遗漏超时和最大轮数max_attempts、timeout、人工中断、看门狗反馈决定下一轮如何调整信号太稀疏、指标和业务目标不对齐量化指标、缩短反馈周期、引入自动评估3. 三类高频 Loop开发内环、业务反馈环、智能体执行环Loop Engineering 不是一个空概念它落在具体场景里就是不同的循环形态。我日常打交道最多的是三类开发内环、业务反馈环、智能体执行环。3.1 开发内环决定工程师心流的那条环路开发内环就是“改代码 → 看到结果 → 改下一处”这条循环。90 年代的程序员在命令行里编译等一分钟出结果现在的前端工程师改一行代码热更新毫秒级反馈。这条循环的核心指标是周期时间从你保存代码到获得反馈的秒数。我一直觉得开发内环是 Loop Engineering 最朴素也最被低估的应用场景。你可以不搞复杂的微服务治理但如果你把测试反馈从一分钟压到三秒团队效率提升是立竿见影的。实操上推荐用entr这种文件监听工具把“保存即测试”跑起来find . -name *.py | entr pytest -q这条命令会让 pytest 在任意 Python 文件变更时自动执行。我以前觉得这种工具太简单不值一提直到有一次给一个老项目配上之后组里一个新同事半天之内改完一个模块的测试他说“每次保存自动跑测试改错了马上知道”这就是反馈闭环的价值。3.2 业务反馈环让产品越用越聪明的闭环业务反馈环的典型链条是用户行为 → 数据采集 → 分析洞察 → 产品改动 → 发布实验 → 再次采集用户行为。推荐系统就是最典型的例子用户点击一个商品这个动作被记下来模型更新下一轮推荐结果就变了。做这类循环工程难点有两个。一个是缩短周期从行为发生到进入模型训练中间链路越短闭环越灵敏。另一个是保证信号质量用户点了一下到底是喜欢还是误触如果不做信号清洗整个循环都会被噪声带着跑。我之前见过一个团队用“页面停留时长”做反馈信号结果所有页面都被算法优化成了加载慢的页面因为加载越慢停留越长。这个例子特别能说明问题反馈信号定义错了循环越努力错得越远。3.3 智能体执行环LLM 应用真正的心脏现在讨论度最高的就是智能体执行环也就是 Agent Loop模型输出动作 → 工具执行 → 结果回到模型 → 模型再输出下一步。这个循环直接决定了 AI 应用的成败因为它把传统软件工程里“函数调用”变成了“多次模型调用的动态串联”。智能体执行环的核心问题有三个预算、终止、震荡。预算是指每次循环都要花钱和耗时不能让模型无限制地迭代下去终止是指必须有明确的成功条件和兜底条件震荡是指模型在两三条路径之间反复横跳始终不收敛。这些我后面专门用一整节来说。三类循环放在一起对比会更清楚循环类型典型周期反馈信号最容易挂的地方常用手段开发内环秒级编译错误、测试结果、热更新反馈链路太长、工具链割裂文件监听、增量测试、IDE 集成业务反馈环天级/周级点击率、转化率、停留时长信号噪声大、周期太长特征清洗、实验平台、数仓实时化智能体执行环秒级/分钟级任务完成率、模型自评分、工具报错成本失控、不收敛、来回横跳轮次上限、自省评估、历史记忆4. 项目实战实现一个带自省能力的文档问答 Agent Loop下面这个项目是我前段时间做内部知识库问答机器人时抽出来的最小骨架。它的需求很典型用户问一个问题Agent 先从文档库里检索片段再根据片段生成答案然后自己给答案打分如果分数不够就带着批评意见再检索、再生成直到分数达标或达到最大轮数。完整代码我贴在下面先看整体结构再逐段解释设计意图。4.1 先把需求说清楚再说为什么这么设计需求一句话Agent 要能自己判断“这次回答行不行”不行就带着具体缺陷重来。所以核心不只是一个“调用模型”的接口而是一个带反馈回路的循环控制器。设计上我有四个取舍用状态对象而不是一堆局部变量。因为循环要跑多轮状态散落在函数参数里很难维护。强制轮次上限和超时上限。每一轮都有模型调用成本绝不能无限迭代。自评环节同时保留规则检查。规则检查保证底线模型评分负责更精细的判断。每轮记录快照。项目一旦出问题快照能让调试时间从小时级降到分钟级。4.2 状态定义和基础工具函数import time from dataclasses import dataclass, field dataclass class AgentState: question: str # 用户原始问题 hits: list field(default_factorylist) # 本轮检索到的资料片段 answer: str # 当前答案 critique: str # 上一轮的自评意见 score: float 0.0 # 当前答案质量分 attempts: int 0 # 已执行轮数 logs: list field(default_factorylist) # 每轮快照 property def converged(self) - bool: # 成功出口分数达到 0.7 return self.score 0.7 def snapshot(self) - dict: return { attempts: self.attempts, hits: self.hits, answer: self.answer, score: self.score, critique: self.critique, }检索函数先用模拟数据代替方便你直接跑通逻辑。真实项目里换成向量检索、Elasticsearch 或者你们内部的搜索服务即可def search_docs(query: str) - list: # 真实环境替换为向量检索/ES这里用规则模拟召回 corpus { 退款: 退款流程用户在订单页提交退款申请1-3 个工作日内审核审核通过后原路退回。, 发票: 发票默认开具电子发票可在订单详情页下载如需纸质发票请在下单时备注。, 发货: 现货商品 24 小时内发货预售商品以商品页面标注时间为准。, } return [v for k, v in corpus.items() if k in query]4.3 生成、自评和提示词组装生成函数我留了一个call_llm的壳子。你在真实环境里把它替换成模型网关的调用即可OpenAI 兼容接口的写法大同小异。示例里用确定性的返回值是为了让循环逻辑在没有网络和 Key 的情况下也能被验证def build_prompt(state: AgentState) - str: if state.logs: last state.logs[-1] return ( f资料{state.hits}\n f问题{state.question}\n f上一轮回答{last[answer]}\n f上一轮缺陷{last[critique]}\n f请修正缺陷后重新回答不超过 120 字。 ) return ( f资料{state.hits}\n f问题{state.question}\n f请依据资料回答不超过 120 字。 ) def call_llm(prompt: str) - str: # 真实项目里替换为resp chat_completion(model..., messages[...]) if 上一轮缺陷 in prompt: return 退款流程用户提交申请后 1-3 个工作日审核审核通过后原路退回。 return 请先提交申请我们会尽快处理。自评函数是这条循环的“裁判”。示例中我用规则判断答案是否包含关键信息真实项目建议用“规则打底 模型评分”双保险规则失败直接判不过模型评分负责更细腻的质量判断def evaluate(state: AgentState) - tuple[float, str]: answer state.answer score 0.0 critique if 1-3 in answer or 1 到 3 in answer: score 0.4 if 原路退回 in answer or 原路退还 in answer: score 0.3 if 审核 in answer: score 0.3 if score 0.7: critique 回答缺失关键信息没有写清楚审核时限或退回方式。 return round(score, 2), critique4.4 循环控制器把四件套串起来class DocQALoop: def __init__(self, max_attempts: int 3, timeout_s: float 20.0): self.max_attempts max_attempts self.timeout_s timeout_s def run(self, question: str) - AgentState: state AgentState(questionquestion) deadline time.time() self.timeout_s while state.attempts self.max_attempts and time.time() deadline: state.attempts 1 # 推进首轮必须完成检索之后带着批评意见再检索 if not state.hits: state.hits search_docs(question) # 生成 自评 prompt build_prompt(state) state.answer call_llm(prompt) state.score, state.critique evaluate(state) state.logs.append(state.snapshot()) # 成功出口 if state.converged: print(f第 {state.attempts} 轮收敛score{state.score}) return state # 未达标带着具体批评意见进入下一轮 print(f第 {state.attempts} 轮未达标score{state.score}critique{state.critique}) state.hits search_docs(state.critique) # 兜底出口轮次或超时用尽 print(f达到轮次或超时上限共 {state.attempts} 轮) return state跑一个例子第 1 轮未达标score0.0critique回答缺失关键信息没有写清楚审核时限或退回方式。 第 2 轮收敛score1.0这个例子直观展示了 Loop Engineering 的核心价值第一轮失败不重要重要的是失败信息能精确导向下一轮的成功。如果第一轮生成的是“请先提交申请我们会尽快处理”自评立刻指出“缺少审核时限和退回方式”第二轮模型就能带着这个批评重新回答。4.5 从教学代码到生产代码要补的几件事上面这套骨架能跑但离生产还有距离。我列一下补齐的方向检索函数换成真实检索注意召回片段要带文档来源方便答案附带引用。call_llm换成真实模型调用记录每次调用的 token 数和延迟纳入成本观测。自评函数加上模型评分但保留至少一条确定性规则作为硬门槛。每轮快照写入结构化日志字段固定方便后续统计收敛率。并发跑多个任务时每个任务独占一个AgentState绝不能在多个任务之间共享可变状态。另外有一个我强烈建议的改动当轮次耗尽仍未达标时不要返回最后一步的状态而是返回历史得分最高的一轮。因为循环后期可能因为模型随机性把答案改差了。实现很简单每次得分提升时保存一份最优快照兜底出口返回它。这个习惯能救回很多“差一点就成功”的任务。5. 循环调优实录死循环、震荡和静默退化代码能跑通只是开始真正让 Loop Engineering 有价值的是面对循环出了问题时的排查和调优能力。我把最常见的三类问题分开讲每一类都会给排查链路和修复方向。5.1 死循环出口条件失效时系统会怎样死循环听起来低级但真实世界里的死循环往往不是语法问题而是逻辑问题。我开头说的那个空转七天的同步任务代码大概长这样while True: record fetch_one_pending_record() try: process(record) mark_done(record) except Exception: # record 没被标记但也没被计数 continue问题出在处理失败的记录永远不会被标记完成于是一直躺在队列里而循环本身没有最大轮次或失败次数限制于是它一遍一遍处理同一条记录表面看“CPU 在干活”实际上没有任何进展。排查链路我基本固定为四步看日志确认循环确实在同一批数据上反复横跳。找到循环头部确认每个continue和break之间有没有改变关键状态。在每轮末尾加心跳日志打出轮次和当前处理的数据 ID。修复要么失败时计数计数达上限后告警并跳出要么把失败记录移入死信队列。修复完之后我还会加一个看门狗外层再包一个最大运行时长超过就强制退出并告警。不要觉得这层保险多余我见过太多“这次一定不会死循环”的自信代码最后都死在了数据异常上。5.2 震荡为什么同样的两条路来回横跳震荡问题主要出现在 Agent Loop 和基于 LLM 的自评循环里。现象是模型第一轮给了方案 A自评说“不够完整”第二轮改成方案 B自评又说“偏离主题”第三轮又改回方案 A。循环没有死锁但也没有收敛白白消耗好几轮模型调用。根因有两个。第一是反馈意见本身不够具体。如果自评只说“回答质量不高”模型根本不知道往哪个方向改只能在原地打转。第二是模型随机性带来的过度修正。温度调高之后模型每次生成都有随机性面对“这版不如上一版”的反馈它可能矫枉过正。我的修复手段有三个反馈意见必须指向具体缺陷比如“缺少审核时限”“缺少退回路径”而不是“回答不好”。后续轮次降低温度比如第一轮 0.7第二轮 0.3减少随机性。引入历史记忆提示词里带上所有历史答案让模型知道“这段已经试过”避免反复横跳。如果有条件对答案做一次相似度去重和前一轮相似度过高时强制换一种表达。判断循环是否在震荡看一个信号就够连续多轮分数没有提升且答案内容高度相似。一旦命中先触发低成本的重试策略而不是继续无脑迭代。5.3 静默退化循环还在跑答案却越来越差静默退化比震荡更难发现因为循环每轮都正常执行出口条件也最终触发但答案质量悄悄下滑。我在一个自动摘要项目里遇到过循环第一轮生成 400 字摘要自评说“不够凝练”第二轮生成 200 字自评说“还是要精简”第三轮直接生成一句“见附件”。它收敛了但收敛到了一个毫无价值的答案。这种情况通常是因为反馈信号只关注“有没有变少”“有没有变短”而没关注“信息量是否还在”。修复方向是给自评加上“关键信息覆盖”这类正向要求并且做最优历史保留best_state None while ...: ... if best_state is None or state.score best_state.score: best_state deepcopy(state.snapshot()) ... # 兜底出口返回最优历史 return best_state or state“永远返回历史最优”这一招能让最坏情况从“返回一句空话”变成“返回之前最好的一次回答”工程价值很高。三类问题放在一起排查顺序是有讲究的现象可能根因优先检查修复方式循环永远不停出口条件失效、状态未推进检查每轮是否有状态更新、是否有兜底出口加轮次上限、超时、失败计数、看门狗多轮不收敛答案来回变反馈太笼统、模型随机性大看自评意见是否具体具体化批评、降低温度、引入历史去重循环能收敛但质量差反馈只惩罚不奖励、信号定义偏看评分指标是否覆盖正向要求重新定义评分规则、保存历史最优6. Loop 健康度四个指标和几条保命经验循环也需要体检。我每次给项目加上 Loop 相关模块都会同步埋好四个指标否则根本不知道循环是变好了还是变差了。6.1 四个核心指标的定义与用法收敛率成功收敛的任务数 / 总任务数。这个指标反映循环基础可靠性低于 0.9 说明循环经常跑不到成功出口。平均迭代次数所有任务迭代轮次的总和 / 任务数。它直接关联成本和延迟涨得太多就要考虑优化反馈质量。有效推进率较上一轮分数提升的轮次数 / 总轮次数。低于 0.6 说明反馈信号对下一轮帮助不大循环基本在瞎忙。回退率较上一轮分数下降的轮次数 / 总轮次数。高回退率是震荡的直接信号正常应该控制在 0.1 以下。指标计算方法建议阈值观测方式收敛率成功收敛数 / 总任务数 0.9任务结果表里记录是否收敛平均迭代次数总轮次 / 任务数成功任务 3日志聚合有效推进率分数提升轮次 / 总轮次 0.6每轮打点分数变化回退率分数下降轮次 / 总轮次 0.1每轮打点分数变化这四个指标一出来循环有没有问题一目了然。我曾经在一个 Agent 项目里看到收敛率只有 0.4平均迭代次数却到了 5一查日志全是震荡最后发现是自评提示词写得太模糊“多轮不收敛”的根子一下就找到了。6.2 几条保命经验最后分享几条我在实际项目里用血换来的经验不按教科书来就是干活总结先写出口条件再写循环体。我见过太多人把循环体写得极其炫酷最后收尾时匆匆补一个break。顺序反过来把“最多几轮、超时多久、什么算成功”先钉在纸上循环体怎么写都不会偏。循环里的日志要结构化。每轮至少记录轮次、状态快照、耗时、关键分数。排查死循环和震荡时这些日志就是唯一的线索。用确定性 mock 把循环逻辑测透再接真实模型。真实模型有随机性锅可能出在模型上也可能出在循环逻辑上。先用 mock 保证循环逻辑正确再替换模型出问题时才能快速定位。反馈一定要具体。“回答不够好”等于没说“缺少审核时限和退回路径”才是有效反馈。自评模块的质量决定了整个循环的收敛速度。永远返回历史最优状态。这个习惯成本很低却能避免“最后一次迭代分数下滑导致整体结果变差”的尴尬。我现在接手任何带循环的系统第一句会问如果所有逻辑都对它会在第几轮停下如果对方答不上来说明出口条件没有被当作功能来设计。这也是 Loop Engineering 给我带来的最大改变——从关心“这段代码跑了几次”变成关心“这套循环能不能在有限次数里收敛”。这个思维转换比任何具体工具都值钱。