这两天ai圈有个词特别火，叫作loop工程。
起因是OpenClaw创始人斯坦伯格在X上发了一条动态：“你不该再为编程Agent写提示词了。你应该设计循环，让循环来提示你的Agent。”
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
本以为评论区会热闹非凡，大家踊跃探讨loop工程的落地路径。
结果却演变成一场观点交锋。
有人指出loop会大量消耗token，除非拥有无限额度，否则仍需人工介入验证；也有人调侃这是概念炒作，“loop工程迟早取代harness工程”。
这条X帖目前已获得800万次浏览。
最早提出“loop工程”这一说法的，其实是Claude Code创始人鲍里斯。
他在一次访谈中坦言：“我现在已不再手动给Claude Code写提示词——那些loop替我写了。它们自己判断该修改什么，我的工作只剩下编写loop。”
显然，并非所有人都买账。毕竟上一个热词“harness”，距离现在也不过一两个月时间。
旧概念尚未沉淀消化，新范式又扑面而来。
但争议归争议，loop工程本身究竟指向什么？它和编程中的循环（loop）又是否真是一回事？
什么是loop？
先厘清第一个问题：loop工程到底指什么？
loop直译即“循环”。
Agent loop，表面看确实与传统编程里的循环相似。
在常规编程中，循环行为高度确定：
比如一个for循环遍历数组，机器就严格从首元素走到末元素。其本质，是让计算机重复执行一段预设好的指令序列。
而在AI Agent语境下，loop同样强调“重复执行”。
那二者区别在哪？
关键在于：Agent loop执行的不是固定指令，而是持续逼近某个“目标”。它通过如下闭环不断迭代，直至输出满足预期：
目标Goal → 行动Action → 观察Observation → 评估Evaluation → 修正Revision → 下一轮行动
这个流程中的每一步，都不是静态的。
Agent需实时感知当前状态，自主决策采取何种行动；执行后再次观察结果，依据预设标准评估成效，再决定如何调整策略。
而传统循环中，每次迭代执行的是完全相同的代码逻辑——哪怕处理不同数据，处理方式也始终如一。
因此你必须穷尽所有可能分支，提前写出对应的if-else判断逻辑。
但现实世界的开放性任务充满变数，你无法预先枚举全部场景。一旦遇到未覆盖的情况，程序便直接崩溃。
这正是Agent loop的价值所在。
你无需把所有边界条件硬编码进去，只需明确目标、提供工具与上下文，然后放手让它在loop中自主探索。
它或许绕路、或许出错，但只要存在反馈机制与评估标准，就能在多轮试错中逐步收敛至正确解。
这种机制尤其适用于不确定性高的任务：写代码、修缺陷、做研究、搭产品……这些工作的共性是路径不唯一，需边做边调。传统程序难以应对，而Agent在loop中却能灵活适应。
澳洲程序员杰弗里·亨特利（Geoffrey Huntley）于2025年7月发布的ralph，便是典型Agent loop实践。
它本质上是一个bash脚本，反复将同一份提示词文件喂给Agent。真正的突破在于其纪律性：每次迭代都重置上下文至一组固定的锚点文件，而非任由对话历史无序膨胀。
为验证ralph能力，杰弗里用它构建了一门完整编程语言，总成本约297美元。
这个案例揭示：loop的核心价值，不在于提升Agent单次推理能力，而在于为其构建一个可持续进化的运行环境。
在这个环境中，Agent不必一次成功；它可以失败、学习、积累经验，并在连续迭代中稳步推进。
进入2026年春季，Codex与Claude Code相继推出/goal命令，将ralph理念正式产品化——该命令将持续运行loop，直到验证通过为止。
但斯坦伯格所指的loop，已远超“让一个Agent反复执行某项任务”的范畴，而是将其升维为一种可长期运行、跨Agent协作、自动调度的AI工作系统。
具体而言，斯坦伯格视loop为工作的基本单元。
过去我们向AI下达的指令通常是临时性的：“帮我修复这个bug”“帮我写一篇文章”——任务完成即终止。
而他提出的loop，则是一个持续运转的工作模块。例如：每日扫描GitHub issue，识别待修复项，自动分派给对应Agent；修复后运行测试；失败则重试，成功则提交PR。
重点已不再是“解决某一个bug”，而是一个长期存在的自动化流程，专门处理某一类问题。
当多个此类loop并行运行时，新挑战浮现：谁来统筹协调？谁来判定优先级？谁来监督质量？
于是斯坦伯格开始用loop去监管其他loop：
顶层loop负责全局监控 → 发现待办事项 → 分发至多个子loop → 各子loop独立执行 → 顶层loop汇总进度与结果
提示词是输入，loop是过程
斯坦伯格那条引发热议的推文，之所以触动神经，正因为它触及一个敏感命题：
提示词工程是否正在退场？
截至目前，提示词仍是人类向Agent传达意图最主流的方式——它依然要求清晰、具体、富含必要上下文。
换言之：一份糟糕的提示词，不会因被塞进loop就 magically 变好。
但单次提示词，的确已不再是Agent运作的核心驱动力。
原因很简单：若你能在初始阶段就精准描述全部需求，Agent仅凭一次输出即可完美交付，那后续上下文就毫无意义。
使用聊天补全、重试、结构化输出和明确的 User-Agent 标头运行 AIMLAPI LLM 与推理工作流，适用于 Codex 对 AIMLAPI 模型进行脚本化提示/推理调用的场景。
现实却是：你往往要在看到初稿后，才发现遗漏关键约束；或发现Agent虽满足字面要求，但在实际使用中暴露缺陷。
更关键的是，许多反馈信息在任务启动时根本不存在。
比如BUG，只有运行测试才能暴露。
过去你需要紧盯每一轮输出，手动判断对错，并引导下一步方向。
如今，你只需设计好loop框架，明确定义目标与评估规则，然后交由Agent自主运行。
归根结底，loop工程就是为Agent搭建一套运行框架——告诉它每一轮该关注什么、该做什么、如何判断成败、何时终止。
举个例子你就明白了：
你要让Agent生成一个登录页面。
提示词工程的做法，是撰写详尽指令：“请生成一个登录页，含用户名密码框、登录按钮、‘忘记密码’链接；样式简洁现代，主色为蓝色；需表单验证（用户名非空、密码≥8位）；登录失败显示错误提示。”
若提示词足够优质，Agent可能产出视觉上达标的页面。
但这页面真的可用吗？验证逻辑是否健壮？跨浏览器兼容性如何？是否存在安全漏洞？
loop工程的做法，则是构建一整套闭环流程：
第一步：基于需求生成页面代码；
第二步：运行自动化测试，检验基础功能；
第三步：启动浏览器截图，检查视觉呈现；
第四步：若测试失败或截图异常，定位具体问题；
第五步：针对性修改代码；
第六步：重新测试，循环往复，直至全部验收项达标。
在此流程中，初始提示词可以极简——因为你清楚后续有多轮反馈与修正机会。Agent无需首战告捷，它可在每轮中依据真实反馈持续优化。
loop工程究竟在设计什么？
那么，如何真正落地一个loop工程？
你需要统筹设计五大核心组件。
第一组件：目标（Goal）
听起来像常识，实则多数loop失效的根源，正在于目标模糊。
“帮我优化一下”不是合格目标。优化什么？优化到何种程度？有哪些限制条件？均未定义。
理想目标应具备可验证性。例如：“将该接口响应时间从800ms压至300ms以内；保持原有行为不变；所有单元测试必须通过；输出改动说明，列明具体优化点。”
目标的每一项，都应能被客观衡量。
清晰的目标，本质是为Agent提供稳定锚点——每轮迭代皆可据此校准方向。
第二组件：上下文管理（Context Management）
上下文远不止人机对话记录那么简单。
它涵盖：代码库当前快照、关联文档、需求规格、错误日志、测试报告、用户偏好、历史决策，以及此前各轮尝试与结果。
许多Agent表现不佳，主因并非模型能力不足，而是每轮输入的上下文太杂、太少、或太随意。
“太杂”指混入大量噪声信息，迫使Agent耗费token过滤干扰，反而忽略关键线索；
“太少”指缺失关键材料，导致Agent缺乏判断依据；
“太随意”指上下文组织缺乏一致性，使Agent难以建立稳定认知模式。
前文提到的Ralph loop，其关键创新正在于此：每轮重置上下文至固定锚点文件，杜绝对话历史无限膨胀带来的污染。
你需要主动决策：哪些信息必须保留？哪些应舍弃？哪些需摘要后留存？
2026年的主流loop系统已采用Git驱动的状态管理——每轮变更自动提交，Agent可回溯历史提交，理解过往动作及动机。
第三组件：工具集（Tools）
说白了，就是Agent能调用哪些外部能力。
巧妇难为无米之炊，工具选择必须匹配任务特性。
若让Agent写代码却不赋予测试执行权限，它便无法验证自身产出。
但工具也非越多越好。工具数量增加，意味着决策空间扩大，Agent可能陷入“选工具”而非“做任务”的困境。
优秀的loop设计，会精挑细选工具集：仅提供完成任务所必需的工具，且每个工具用途明确、触发时机清晰。如此，Agent方能聚焦于目标本身，而非工具抉择。
第四组件：评估机制（Evaluation）
这是loop的灵魂。没有评估，循环即成空转。
评估的关键在于自动化。
若每轮都依赖人工判断，loop便丧失自主性。因此必须设计可自动执行的评估标准，使Agent能自行判定当前状态是否达标。
当然，自动化评估亦有局限。某些维度难以量化——如代码可读性、UI美学、文字感染力。
对此类指标，可设置人工检查点，由人在关键节点介入评判。
AI领域有个术语叫human-in-the-loop，其精髓并非剔除人类，而是将人精准部署于高价值、高风险决策环节。自动化承担常规判断，人类守住最后防线。
第五组件：终止条件（Stop Condition）
自编程诞生之初，任何循环都必须定义退出机制。
例如经典for循环中，计数器i逐次递增，当i超过阈值即停止。
对Agent而言，最理想终止条件是“任务达成”，但现实常更复杂。
有时Agent陷入死循环，反复尝试同一无效方案；有时它持续微调，每次略有改进却永难完美，不知何时收手。
因此需设定多重终止策略：
- 成功条件：所有评估项通过，目标达成；
- 失败条件：连续多轮无进展，或错误频次超限，表明当前路径失效；
- 资源限制：运行超时、token超支、成本超标等硬性约束；
- 风险检查点：当Agent拟执行高危操作（如删库），必须暂停并等待人工确认——此类操作容错率极低，不可全盘自动化。
将这五大组件有机整合，你便拥有了一个完整、稳健、可落地的loop。
本文来自微信公众号“字母AI”，作者：苗正，36氪经授权发布。
