本文深入探讨了Loop Engineering的概念及其在实际应用中的价值。通过分析如何将AI编程助手设计成可持续执行的工作系统，文章强调了定义清晰的目标、角色分工、状态管理和停止条件的重要性。以作者开发的h5-online项目为例，展示了如何通过服务边界和结构化产物管理多Agent团队，实现高效、可靠的AI工作流程。本文旨在帮助读者理解Loop Engineering的核心思想，并应用于实际项目中，提升AI助手的工程化水平。

Loop Engineering 只看名字，第一反应是：完了，又来一个概念。

Prompt Engineering 还没彻底讲明白，Vibe Coding 还在朋友圈乱飞，现在又来了 Loop Engineering。再这么下去，技术人可能不是被 AI 替代的，是先被各种英文名词熏晕的。

但认真看了一圈，它也不是纯造词。

Business Insider 在 2026 年 6 月 20 日发了一篇文章，标题很直接：Forget prompt engineering，Loop Engineering is all the rage now。文章把 Claude Code 的 Boris Cherny、OpenAI 的 Peter Steinberger，以及 Google Cloud 的 Addy Osmani 等人的观点放在同一个语境里：大家开始不满足于“写好一条 prompt”，而是在讨论怎么让 coding agent 进入持续工作的循环。

放到开发者日常里，就是以前你坐在电脑前一句一句催 AI；现在你开始设计一个系统，让 AI 自己发现任务、拆任务、派任务、检查结果，然后继续下一轮。

听起来很爽，对吧？

但脑子里第一反应不是“生产力爆炸”，而是另一句话：

这玩意儿如果没有停止条件，不就是一个会烧 token 的自动化死循环吗？

尤其是做工程的人，应该对“循环”这两个字天然敏感。for {} 很优雅，线上 CPU 打满的时候，也很优雅。

所以这篇文章不打算只追一个新词。想把 AnyAI 里的 h5-online 这条闭环摊开给你看：它表面上只是一个 H5 上线主控，实际是在用两个下游项目，编排一支超过 20 个 Agent 的审核、修复、复审队伍。

这件事比“写一段高级 prompt”更接近 Agent 工程。

Loop Engineering 到底在讲什么

先别急着被新词吓住。

Loop Engineering 不是让你掌握某种神秘 prompt 魔法，也不是写一个“请你持续努力直到成功”的长提示词就完事了。

它真正想说的是：人和 Agent 的交互重心变了。

过去我们把注意力放在 prompt 上：

• 这句话怎么写，模型更听话？
• 上下文怎么塞，模型更懂业务？
• 角色怎么设，模型更像专家？
• 输出格式怎么约束，模型更容易解析？

这些仍然重要。

但 Codex、Claude Code、Cursor 等各类 coding agent 越来越能跑长任务以后，问题就从“怎么问”变成了“怎么管”：

• 谁来决定下一步该干什么？
• 谁来判断当前结果是否合格？
• 失败以后是重试、降级，还是停止？
• 多个 Agent 之间怎么分工？
• 结果怎么被记录、审计和复用？
• 最后到底谁有资格说“可以上线”？

所谓 Loop Engineering，价值就在这些问题里：

它不是把 prompt 写得更漂亮，而是把一次 AI 对话改造成一条可运行的工作链路。

更工程一点说，一个 loop 至少要有四层东西：

层次	关心的问题
目标	这次 loop 到底要完成什么业务结果
角色	谁负责干活，谁负责验收，谁只能编排
状态	当前跑到哪一步，上一轮留下了什么证据
停止	什么条件算通过，什么情况必须阻塞

Addy Osmani 在相关讨论里提到过 automation、worktrees、skills、plugins/connectors、sub-agents。Business Insider 的报道也提到，一个常见套路是让一个 Agent 写代码，再让另一个 Agent 审核结果。

这个套路值得多看一眼。写代码的 Agent 太容易给自己打高分了。

这不是模型道德问题，而是工程常识：不要让交作业的人自己当唯一验收人。

以前写后端的时候，大家都知道不能只看日志里打印了 success。你要看数据库有没有提交，消息有没有 ack，文件有没有落盘，下游有没有消费，重试会不会重复写，回滚路径有没有准备。

可一到 Agent，很多人突然又变天真了。

模型说“我已经完成”，我们就信了。

模型说“已修复”，我们就放心了。

模型说“可以上线”，我们甚至还想给它鼓掌。

这不行。

Agent 越像人，工程系统越不能像人一样只听它描述。

AnyAI 里的 h5-online

h5-online 不是一个玄学 demo。它的定位很朴素：H5 站点上线编排 Agent。

它自己不亲自审核站点，也不亲自改代码。

它只做一件事：把“审核 -> 修复 -> 复审”这条链路编排成闭环。

在 examples/h5-online/agent.md 里，给这个 Agent 写的职责很明确：

你是 H5 站点上线编排主控。
你的职责是把用户的上线目标组织成一个闭环流程，
不亲自审核站点，也不亲自修改代码。

它下面只依赖两个共享技能：

harness-google-review-http：调用独立的审核项目完成审核/复审。
harness-coding-http：调用独立的编码项目完成受控修复和验证。

这两个 skill 背后，是在 AnyAI 里拆出来的两个独立项目：

• harness-google-review：负责 H5/站点审核，下面有 12 个专家 Agent。
• harness-coding：负责工程修复，下面有 17 个专家 Agent。

加上 h5-online 这个主控入口，整条链路已经不是“一个 Agent 自己反复想办法”，而是一个主控通过服务边界管理 29 个下游专家 Agent。

很多人一做 Agent，第一个冲动是把所有能力都塞进一个超级 Agent：

你既要理解用户需求，又要审查页面，又要修改代码，又要跑测试，还要自己判断能不能上线。

看起来很智能。放到工程里，会先打三个问号。

因为一个 Agent 既当开发，又当审核，又当上线裁判，本质上还是“自己给自己批作业”。

h5-online 的设计反过来：

层级	角色	只负责什么	明确不负责什么
上线主控	h5-online	维护状态、推进轮次、决定下一步调用谁	不亲自审核，不亲自改代码
审核服务	harness-google-review-http	发起初审/复审，返回结构化问题与上线判断	不修复源码
修复服务	harness-coding-http	根据审核问题受控修复，并返回验证摘要	不决定最终能否上线

这里最重要的不是“有 29 个 Agent”。

真正重要的是：验收权被拆出来了。

h5-online 没有直接对 29 个 Agent 发号施令。它只认识两个能力：

review(site_url, source_path, round, previous_fix_summary)
coding(site_url, source_path, issues, report_path, artifact_root)

审核项目内部怎么爬站、怎么做内容分析、怎么做 SEO/UX/政策/广告库存判断，由 review-lead 自己编排。

修复项目内部怎么做需求分析、方案、审批、编码、UI 测试、测试、审查、对齐，由 tech-lead 自己编排。

这就是在 AnyAI 里很看重的一层工程思维：

主控不要穿透所有细节，主控只管理服务契约。

如果把两条线拆开看，会更容易理解它们各自怎么把十几个专家收进一条流水线。

harness-coding：怎么改

tech-lead 负责的不是“改一改代码”，而是把需求、方案、实现、测试、审查拆成一串有门禁的阶段。

harness-google-review：怎么判

review-lead 负责的也不是“看一眼网站”，而是把爬取、分析、映射、报告拆成一串严格串行的阶段。

两条线合起来，就是 h5-online 背后的 29 个专家 Agent。但主控并不需要把这些名字全写进自己的提示词里。

它做的是一个非常后端工程的拆分：

编排层	看到什么	不需要知道什么
h5-online	审核服务、修复服务、轮次、上线判定	站点爬取细节、代码实现细节
review-lead	审核产物门禁、审核专家	修复代码怎么写
tech-lead	需求、方案、实现、测试、审查门禁	Google 审核报告怎么生成
专家 Agent	单一阶段输入、目标产物、完成格式	整条上线链路怎么收口

它不是用一个超大 prompt 管住 29 个 Agent，而是用项目边界、skill 契约、结构化产物和 runtime 状态，把 29 个 Agent 变成两条可调用、可验收的工程流水线。

Loop 最关键的不是开始，而是结束

看 h5-online 的固定闭环，可以先别盯着“循环”两个字，而是盯住每个岔路口：

步骤	动作	下一步
1	调用 harness-google-review-http 初审或复审	得到审核 JSON
2	判断 has_issues 和 submit_ready	通过或进入修复
3	调用 harness-coding-http 受控修复	得到修复 JSON
4	轮次递增，带着修复摘要复审	回到第 1 步
5	skill 失败、超时、无结构化结论	重试或报告阻塞，不编造结果

走到这里，开头那个问题就能回答了：

这玩意儿如果没有停止条件，不就是一个会烧 token 的自动化死循环吗？

是的。

所以真正让这套流程站住的，不是“重复 1-5”，而是它给了退出条件：

唯一通过条件：最后一轮审核明确表示 has_issues=false 且 submit_ready=true。

结论不明确时，视为仍需处理，不能退出闭环。

这两行看起来普通，工程含量很高。

不是 Agent 觉得差不多了就能上线，而是审核结论必须同时满足两个字段。

has_issues=false 说明没有发现问题。

submit_ready=true 说明可以提交。

两个都满足，才算过。任何一个不满足，继续处理。结论不明确，也不能假装通过。

现在越来越觉得，Agent 系统里最值钱的不是那句“请你自主完成任务”，而是这句：

什么情况下你必须停。

一个靠谱的工程 loop，至少要回答四件事：

• 什么条件下进入下一轮？
• 什么证据能证明本轮完成？
• 什么错误允许重试？
• 什么情况必须停止并报告给人？

没有这些东西，loop 就会变成一种很危险的乐观主义。每一轮都很努力，每一轮都输出很多文字，每一轮都看起来“正在变好”。最后 token 烧掉了，代码改乱了，问题还没真正解决。

你再去问它，它还会很礼貌地总结：“本次任务已取得显著进展。”

看到这种句子，血压一般会有一点进展。

把流程变成 skill 契约

h5-online 还有一个关键细节：具体调用规则没有散落在主提示词里，而是收进了 skill。

审核服务对应的 harness-google-review-http skill，不只是告诉模型“去审核一下”。它把服务地址、默认 agent、调用脚本、超时、session id、重试规则、输出字段都写清楚了。

修复服务对应的 harness-coding-http skill 也一样。它要求下游明确返回是否修复、改了哪些文件、做过哪些验证、还剩什么风险。

这些字段不是为了好看，是在把模型嘴里的“我修好了”，变成系统能判断的结构化信号。

Agent 可以写很多自然语言总结，但 loop 不能靠感觉推进。它必须有字段、有状态、有失败分支。

以前我们写代码，会把这些东西放到接口文档、重试策略、状态机和 runbook 里。现在做 Agent，也逃不掉。

只不过很多团队把它们塞进一大段 prompt，然后祈祷模型每次都记得。刺激到如果你半夜被叫起来排查，可能会发现“上线判定规则”藏在第 187 行提示词里，中间还夹着三段人格设定和两句“请你认真思考”。

Runtime 托住的是过程

AnyAI runtime，一个很重要的方向就是处理“过程”。

AnyAI 的定位是一个“项目优先”的 Agent 开发框架与运行时。项目作者主要写 anyai.yaml、agent.md、SKILL.md，运行时负责 Gateway、Session、Plan/Todo、Memory、Skill、事件、任务生命周期这些东西。

放到 Loop Engineering 里，这个定位会更清楚：loop 不是一条模型回复，而是一段持续运行的过程。

过程就需要 runtime 托住请求入口、run、session、子任务、工具失败、事件回放、超时和最终收口。

没有 runtime，loop 很容易退化成脚本加 prompt：脚本负责不断调用模型，prompt 负责不断鼓励模型，日志负责在出事以后折磨人。

h5-online 则给了一个更工程化的表达方式：

它每轮至少要记住四个东西：

状态	用来干什么
site_url	确认当前审核的目标站点
source_path	让修复服务知道该改哪里
site_slug	从 URL host 生成稳定前缀
round	区分 r1、r2、r3 等审核/修复轮次

每一轮的 session id 也不是随手编一个，而是按 site_slug 和 round 稳定生成。长任务最怕“上一轮做到哪了”只活在模型上下文里。上下文一丢，Agent 可能就重新开始；session 一乱，远端 run 可能无法复用；轮次不清，复审也不知道自己到底在验证哪一次修复。

所以这条 loop 可以压缩成一个状态表：

当前状态	结构化信号	状态迁移
初审/复审完成	has_issues=false 且 submit_ready=true	结束，输出上线结论
初审/复审完成	仍有问题，或结论不明确	调用修复服务
修复完成	fixed=true	round + 1 ，进入下一轮复审
修复未完成	fixed=false 或无结构化结论	重试，仍失败则阻塞
下游调用异常	ok=false 、超时、无 JSON	同轮次重试，连续失败后阻塞

流程不复杂，但抓住了 Loop Engineering 最核心的东西：

让 Agent 自己跑之前，先定义好它怎么被观察、怎么被验收、怎么被叫停。

过程纪律开始变贵了

这里再补一个最近的信号。

2026 年 6 月，arXiv 上有一篇论文叫 RigorBench: Benchmarking Engineering Process Discipline in Autonomous AI Coding Agents。它主张，评测自主 coding agent 不能只看最后有没有把代码写对，也要看过程纪律：计划是否靠谱、验证是否覆盖关键点、失败恢复是否有效、该放弃的时候会不会放弃。

这个方向戳中了 Agent 工程最容易被忽略的一层。

过去很多 AI 编程评测，关心的是最终结果：测试过了吗？issue 修了吗？benchmark 分数多少？

但真实工程里，过程也很重要。一个 Agent 最后碰巧把代码写对了，但中间靠瞎试、乱改、反复覆盖、没有验证、没有恢复策略，这种“对”其实不太让人放心。

反过来，一个 Agent 即使最终报告阻塞，但它能说清楚卡在哪里、缺什么输入、哪些验证已经跑过、下一步需要人怎么决策，这反而更像一个靠谱的工程助手。

所以 Loop Engineering 真正会把技术人的注意力从“模型会不会写代码”拉到另一个层面：

模型怎么工作，可能和模型做出了什么一样重要。

Agent 不是一次性问答，而是会动系统、改文件、调工具、调用其他 Agent 的执行单元。执行单元没有过程纪律，就不是生产力，是风险源。

管住 20+ Agent，靠的是门禁

如果把 h5-online 当成一个“会循环的 Agent”，你会低估它。

它真正做的是把一支 Agent 队伍关进工程门禁里。

这 29 个下游专家不是随便醒来、随便发挥、随便总结。它们被分成审核线和修复线，每条线都有自己的主控、阶段顺序、输入产物、输出格式和失败回退。

把这些门禁概括成七类：

门禁	作用
入口门禁	完整上线任务才进入闭环，普通问候和解释项目能力不启动下游服务
项目门禁	审核归 harness-google-review，修复归 harness-coding，主控只通过 HTTP skill 调用
产物门禁	审核、修复每个阶段都要留下正式产物，而不是只给一句“完成了”
状态门禁	记录 site_url、source_path、site_slug、round，并复用稳定 session
回退门禁	某一步失败，按责任边界回到上游阶段，而不是让 Agent 随便继续

|
所以 h5-online 管住 20+ Agent 的关键，不是它比别的 Agent 更聪明，而是它把“聪明”关进了流程里。

最后

Loop Engineering 这个词会不会长期流行，不知道。

技术圈的新词，有些会沉淀成方法，有些会变成 PPT 化石。这个不好说。但它背后指向的变化，我觉得是真的：

AI Agent 正在从一次性问答，变成可持续执行的工作系统。

一旦进入这个阶段，技术人就不能只关心 prompt 怎么写，也不能只关心“我有多少个 Agent”。

你还要关心它有没有边界、验收、证据、恢复路径和停止条件。它能不能管理一支 Agent 队伍，而不是把所有专家塞进一个大脑袋里；它烧 token 的速度，配不配得上它创造的价值。

别把 Loop Engineering 理解成“让 Agent 无限努力”。

真正靠谱的 loop，应该像一个好工程团队：有人接需求，有人做方案，有人实现，有人测试，有人审核，有人拍板，也有人在证据不足时说停。

这也是我为什么一直觉得 AnyAI 有意义。

我最开始做 AnyAI，想解决的问题很朴素：让任何人都能自由定义自己的 Agent 项目，而不是只能套一个固定形态的“智能助手”。你可以定义项目、agent、skill、产物和服务边界，把自己的想法变成一套能跑起来的 Agent 工程。

未来还会出现很多新词。今天叫 Loop Engineering，明天可能又叫别的名字。可只要 Agent 从“回答问题”变成“持续执行”，底层绕不开的还是这些东西：

状态、契约、权限、过程、验收、停止。

AnyAI 想做的，就是把这些底层能力托住，作为一个基座，承载不同人自己的想法。

这样我们就不用每次新词出来都从头追一遍，而是能回到那几个更稳定的问题：

这个系统要完成什么？
谁来做，谁来判，谁来停？
过程里的证据，能不能留下来？

下次你让 AI 帮你做一个长任务时，不要只写“请你完成这个需求”。多想三件事：

1. **这个任务应该拆成哪些角色和产物？**

2. **谁负责实现，谁负责验收，谁负责最终收口？**

3. **哪些字段满足时才能继续，哪些情况必须停止？**

这三句话不性感，却可能比“你是一个资深专家，请深呼吸”更接近真正的工程化。

也希望本文能够对各位读者有一定的帮助。

如果文中有不正确的地方，也欢迎各位读者留言指正和交流。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：

• ✅ 从零到一的 AI 学习路径图
• ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
• ✅ 百度/阿里专家闭门录播课
• ✅ 大模型当下最新行业报告
• ✅ 真实大厂面试真题
• ✅ 2026 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~

① 全套AI大模型应用开发视频教程

（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）

② 大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

③ 大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

④ AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

⑤ 大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

⑥ 大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

以上资料如何领取？

为什么大家都在学大模型？

最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！

不出1年，“有AI项目经验”将成为投递简历的门槛。

风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！

这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

以上全套大模型资料如何领取？