Prompt已死，Loop为王：新一代AI工程Loop Engineering完整详解

原创于 2026-06-18 22:50:08 发布 · 198 阅读

4 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#人工智能

文章目录

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。

前言

2026年6月的同一周，两个AI大佬几乎说了同一句话。

Boris Cherny在推特上写：「别再提示了，开始循环，Prompt已死，Loop才是新的工作单元。」

Peter Steinberger在博客里说：「我们花了数年完善prompt，现在发现真正的工程在于设计让prompt变得不必要的loop。」

两个不同背景、不同产品的人，得出了相同结论。这不是巧合，这是范式转移的信号。

当然，也可能是他们同时被自家AI的prompt搞崩溃了，半夜三点同时拍桌子：「老子再也不写prompt了！」

一个新的工程学科正在浮现——Loop Engineering。

Prompt Engineering：就像每次去餐厅都要重新教厨师炒菜

先说说我们是怎么走到这一步的。

2023年，Prompt Engineering火遍全网。那时候大家觉得，只要prompt写得够好，AI就能产出神级结果。于是全网都在研究「怎么让AI更听话」。

这就像一个老板，每天亲自站在厨师旁边，手把手教：「盐放3克，油烧到180度，翻炒15秒。」

第一天，厨师照做了，菜很好吃。第二天，你还得重新说一遍。第三天，你嗓子哑了，厨师还在问：「盐放几克来着？」

Prompt Engineering就是这个状态。你每次都要重新教，AI每次都要重新学。一次对话结束了，知识清零，下次从头再来。

这哪是人工智能，这是人工智障加人工复读机。

于是大家进化到了Agent Engineering。给AI配点工具，让它能自己查资料、写代码、跑测试。AI从「只会回答问题的学生」变成了「能动手干活的小工」。

但问题来了。这个小工干完一个活就站着发呆，等着你派下一个任务。你不去喊它，它就不动。你喊晚了，它还能给你来一句：「在呢，有什么可以帮您？」

像极了你家里那个「眼里没活」的队友。垃圾袋满了看不见，地板脏了装不知道，你吼一嗓子才动一下。

Loop Engineering解决的就是这个问题。它不再关注「怎么写好一个prompt」，而是关注「怎么设计一个让AI能持续、自主、可靠地完成任务的循环系统」。

换句话说，以前你是AI的监工，现在你是AI的架构师。你设计好一套机制，AI自己就能跑起来，越跑越顺，越跑越聪明。

就像你终于教会了那个队友：垃圾满了自动倒，地板脏了自动扫，不用你喊，它自己知道什么时候该干什么。

当然，前提是你设计得对。设计错了，它可能把垃圾倒进了马桶，把地板扫成了天花板。

Loop的核心结构：观察、决策、行动、评估、迭代

一个典型的Loop包含5个要素，我给它起了个外号叫**ODAEI循环**——Observe（观察）、Decide（决策）、Act（行动）、Evaluate（评估）、Iterate（迭代）。

这5步听起来很学术，其实特别像你家猫的日常。

Observe：猫盯着鱼缸看，观察鱼游到哪了。Decide：猫判断「这鱼我能抓到吗」。Act：猫扑上去。Evaluate：猫发现鱼缸是玻璃的，鱼没抓到，爪子湿了。Iterate：猫舔舔爪子，决定下次换个策略，比如等鱼自己跳出来。

你看，猫天生就是Loop Engineering大师。它不需要你写prompt教它怎么抓鱼，它自己观察、自己决策、自己行动、自己评估、自己迭代。

唯一的区别是，猫的Loop可能跑100次也抓不到鱼，而AI的Loop如果设计得好，跑10次就能从「完全不会」进化到「熟练工」。

当然，设计得不好的Loop，就像那只永远抓不到鱼的猫，无限循环，永不收敛。在程序员眼里，这叫**死循环**。在老板眼里，这叫「这个需求下周再给你」。

一句话定义：Loop Engineering是设计和优化AI自主运行循环的工程实践。它关注的不是「如何写好一个prompt」，而是「如何设计一个让AI能持续、自主、可靠地完成任务的循环系统」。

Harness vs Loop：赛道和赛车跑法

很多人问：Loop和Harness有什么区别？

答案是：它们是同一枚硬币的两面。Harness是Loop运行的基础设施，Loop是Harness上跑的行为模式。

这个比喻可能有点抽象。我给你翻译成人话。

想象一辆赛车。Harness是赛道——它定义了边界、工具、状态管理、错误处理。Loop是赛车在赛道上的跑法——它定义了策略、节奏、何时加速何时刹车。

没有赛道，赛车跑不起来。没有跑法，赛道就是个空壳，顶多当个停车场。

再打个比方。Harness是你家的厨房，有锅碗瓢盆、冰箱、燃气灶。Loop是你做饭的流程：先洗菜，再切菜，再炒菜，最后尝一口咸淡，咸了加水，淡了加盐。

厨房再好，你不会做饭，Loop设计得稀烂，最后出来的可能是黑暗料理。Loop设计得再精妙，厨房里没有锅，你也只能干瞪眼。

Harness决定了Loop的「能力上限」，Loop决定了Harness的「价值释放」。一个好的Harness配一个差的Loop，就像一条好赛道配一个不会开车的司机——他能把F1开出拖拉机的速度。

反过来，一个差的Harness配一个好的Loop，就像让舒马赫开三轮车——他技术再好，三轮车的上限就在那里，翻车了还得自己爬起来。

SuperPower vs Loop：一次性超能力 vs 永动机

SuperPower是2024-2025年间流行的一个概念。通过精心设计的prompt和工具链，让AI在单次任务中展现出「超能力」般的表现。

这就像一个武林高手，每次出招都惊艳全场。但问题是，每次出招前你都要给他喂一颗「大力丸」，不然他就打不出那套拳法。

Loop Engineering不一样。它不关心单次表现是否惊艳，它关心的是「能不能让AI持续、稳定、自主地运行」。

打个比方。SuperPower是你每天给AI一个精心设计的prompt，让它帮你做代码审查。每次审查都很出色，但你每天都得写prompt。就像你每天亲自给武林高手喂大力丸，喂了365天，你手都酸了。

Loop Engineering是你设计一个Loop，让AI自动监听Git提交，每次有新代码就自动审查，发现问题自动创建issue，审查质量通过反馈机制持续提升。你只需要设计一次Loop，然后AI就像上了发条一样，24小时不停运转。

这哪是AI，这是你雇了一个不要工资、不要加班费、不会请假、不会闹情绪的超级员工。唯一的缺点是它不会跟你一起吐槽产品经理。

当然，两者不是替代关系，而是互补。SuperPower解决「能力」问题，Loop Engineering解决「持续性」问题。最好的实践是：用SuperPower的方法提升Loop中每一步的质量，用Loop Engineering的方法让这些步骤自主运行。

就像武林高手吃了大力丸之后，不是只打一套拳就完事了，而是自动循环打拳，越打越熟练，越打越厉害。前提是你得先把大力丸的配方写进Loop里。

RalphLoop vs Loop Engineering：玩具车 vs 真赛车

RalphLoop是2025年底出现的一个开源项目，实现了一个简单的Agent循环框架。它就像一辆玩具车，能跑，但只能在平地上跑，遇到坑就翻。

Loop Engineering作为工程学科，是面向生产环境的。它要考虑的事情比RalphLoop多得多。

RalphLoop只实现了基础的observe-act循环，缺少收敛条件和自适应策略。就像一个只会「看到什么做什么」的机器人，看到墙了还往上撞，撞了继续撞，撞到没电为止。

Loop Engineering要设计多种Loop模式：收敛型、探索型、修复型、学习型、递归型。每种模式对应不同的场景，就像赛车要根据赛道类型换轮胎——雨天用雨胎，晴天用光头胎，雪地用钉胎。

RalphLoop没有状态管理，每次循环都是独立的，缺少跨循环的记忆和上下文。就像你那个金鱼记忆的朋友，你刚跟他说「帮我带杯咖啡」，他转身就忘了，你再说一遍，他还是忘了。

Loop Engineering要设计短期状态、中期状态、长期状态。短期状态记住当前循环在干什么，中期状态记住当前任务的上下文，长期状态记住跨任务积累的经验。就像一个好的员工，不仅记得今天该干什么，还记得上周干了什么，以及去年这个时候踩过什么坑。

RalphLoop没有错误恢复机制，循环出错时就卡在那里。就像你电脑蓝屏了，除了重启没别的办法。

Loop Engineering要设计重试、回退、降级、人工干预。临时性错误自动重试，逻辑错误回退到上一个检查点，系统性错误停止Loop并升级到人工。就像飞机自动驾驶，遇到气流自己调整，遇到严重故障自动切换手动，遇到坠机风险自动弹射。

当然，最后这个弹射功能希望永远用不上。

Goal：Loop的北极星，不能是「随便吃点」

在Loop Engineering里，Goal是一个核心概念。没有明确目标的Loop，只是一个死循环。

我给大家讲个真实的故事。有个工程师设计了一个Loop，让AI自动优化代码。它跑了一晚上，把代码改得面目全非。原来能跑的程序，现在跑都跑不起来了。

我问他：「你的Goal是什么？」他说：「优化代码质量啊。」

我说：「『代码质量』太模糊了。你需要一个可度量的Goal。比如：『让所有函数的圈复杂度降到10以下』或『让测试覆盖率从60%提升到80%』。」

他说：「但AI不知道这些指标怎么计算。」

我说：「这就是Loop Engineering的核心——你不仅要定义Goal，还要定义Goal的评估函数。Loop的每一步都要检查：『我离Goal更近了吗？』」

Goal设计有4个原则，我总结成「MBBD」——Measurable（可度量）、Bounded（有边界）、Decomposable（可分解）、Verifiable（可验证）。

可度量：不能说「让代码更好」，要说「测试覆盖率大于80%」。就像你不能跟理发师说「剪短点」，要说「剪到3厘米」。不然你可能从长发变秃头。

有边界：不能说「优化所有代码」，要说「优化src/core目录下的代码」。不然AI可能把你三年前写的祖传代码也优化了，一优化，全崩了。

可分解：大Goal拆成小Goal。「提升系统可靠性」可以拆成「减少P0 bug数量」、「提升错误处理覆盖率」等。就像「减肥20斤」拆成「每天跑步5公里」、「晚饭不吃碳水」、「每周称重一次」。

可验证：每次循环都能检查是否达到了Goal。如果验证成本太高，Loop就跑不起来。就像你让你家猫去抓鱼，但鱼缸在隔壁老王家，猫每次验证都要翻墙，那这Loop肯定跑不动。

Loop的5种模式：从减肥到修马桶

Loop Engineering有5种核心模式，每种对应不同的生活场景。

1. 收敛型 Loop：减肥专用

适用场景：有明确目标和度量标准的任务。

核心逻辑：while not goal_reached，持续向目标收敛。

这就像你减肥。Goal是「瘦到100斤」，每天称重，如果还没到100斤就继续减，如果连续一周体重没变化就停止（收敛停滞）。

典型案例：自动代码优化、自动测试生成、自动文档补全。AI不断修改，直到指标达标。

2. 探索型 Loop：逛街模式

适用场景：目标不精确，需要边探索边明确。

核心逻辑：generate-test-learn，预算花完就停。

这就像你老婆逛街。目标不明确，「随便看看」，但预算有限。看到喜欢的就试，试完决定买不买，预算花完自动回家。

典型案例：研究调研、方案探索、竞品分析。AI不断尝试不同方案，直到找到最优解或预算耗尽。

3. 修复型 Loop：自动修理工

适用场景：持续监控并修复问题。

核心逻辑：detect-fix-validate，修不好就喊人。

这就像你请了一个24小时在线的修理工。家里水管漏水了，它自动检测，自动修，修好了验证一下不漏水了，继续监控。修不好就给你打电话：「老板，这个得您亲自来看看。」

典型案例：自动bug修复、安全漏洞修复、性能问题修复。

4. 学习型 Loop：从失败中成长

适用场景：需要从历史中学习并改进。

核心逻辑：execute-feedback-refine，越干越聪明。

这就像你学做饭。第一次做红烧肉，糖放多了，齁甜。第二次少放糖，结果淡了。第三次调整比例，终于完美了。每次失败都是一次学习，Loop不断从反馈中优化策略。

典型案例：客服问答优化、推荐策略调整、写作风格适应。

5. 递归型 Loop：老板分解任务

适用场景：复杂任务需要分解为子任务。

核心逻辑：decompose-solve-synthesize，大事化小，小事化了。

这就像你老板让你做一个大项目。你一看，太大了，搞不定。于是你分解给10个下属，每个下属再分解给10个实习生。最后把结果汇总，合成最终方案。如果某个子任务还是太大，继续分解，直到能搞定为止。

典型案例：复杂代码重构、多步骤研究、跨领域分析。

Loop设计5步法：从0到1造一个永动机

说了这么多，怎么动手设计你的第一个Loop？我总结了5步法，简称「GSMOS」——Goal、Select、Model、Observe、Safety。

等等，acronym好像不太对。不管了，记住5步就行。

Step 1：明确Goal

在写任何代码之前，先回答3个问题：

你要让AI自主完成什么任务？不是「帮我做XX」，而是「自主完成XX」。
成功的标准是什么？可度量的指标。
什么情况下应该停止？收敛条件。

就像你让AI去相亲。不能说「帮我找个对象」，要说「找一个身高165以上、年薪30万以上、喜欢猫的人，找到3个候选人就停止」。不然AI可能给你找1000个，你筛选到明年。

Step 2：选择Loop模式

优化已有代码→收敛型。调研新技术→探索型。监控系统健康→修复型。改进用户体验→学习型。重构大型系统→递归型。

选错了模式就像穿错了鞋。你去跑步穿高跟鞋，去面试穿拖鞋，去爬山穿皮鞋。不是不能走，是走得很难受。

Step 3：设计ODAEI循环

以一个「自动代码审查Loop」为例：

new_commits = git.detect_new_commits(branch="main")

for commit in new_commits:
    # Observe: 检测新的代码变更
    review_plan = ai.plan_review(
        code_diff=commit.diff,
        context=commit.related_files,
        standards=team.coding_standards
    )
    # Decide: 确定审查策略
    review_result = ai.execute_review(review_plan)
    # Act: 执行审查
    quality_score = evaluate_review(review_result)
    if quality_score < 0.7:
        review_result = ai.execute_review(review_plan, attempt=2)
    # Evaluate: 检查审查质量
    knowledge_base.add(commit.id, review_result)
    # Iterate: 将结果反馈到知识库
    for issue in review_result.issues:
        if issue.severity >= "high":
            github.create_issue(issue)