本文深入探讨了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 engineeringLoop 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-onlineh5-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初审或复审得到审核 JSON2判断has_issues和submit_ready通过或进入修复3调用harness-coding-http受控修复得到修复 JSON4轮次递增带着修复摘要复审回到第 1 步5skill 失败、超时、无结构化结论重试或报告阻塞不编造结果走到这里开头那个问题就能回答了这玩意儿如果没有停止条件不就是一个会烧 token 的自动化死循环吗是的。所以真正让这套流程站住的不是“重复 1-5”而是它给了退出条件唯一通过条件最后一轮审核明确表示has_issuesfalse且submit_readytrue。结论不明确时视为仍需处理不能退出闭环。这两行看起来普通工程含量很高。不是 Agent 觉得差不多了就能上线而是审核结论必须同时满足两个字段。has_issuesfalse说明没有发现问题。submit_readytrue说明可以提交。两个都满足才算过。任何一个不满足继续处理。结论不明确也不能假装通过。现在越来越觉得Agent 系统里最值钱的不是那句“请你自主完成任务”而是这句什么情况下你必须停。一个靠谱的工程 loop至少要回答四件事什么条件下进入下一轮什么证据能证明本轮完成什么错误允许重试什么情况必须停止并报告给人没有这些东西loop 就会变成一种很危险的乐观主义。每一轮都很努力每一轮都输出很多文字每一轮都看起来“正在变好”。最后 token 烧掉了代码改乱了问题还没真正解决。你再去问它它还会很礼貌地总结“本次任务已取得显著进展。”看到这种句子血压一般会有一点进展。把流程变成 skill 契约h5-online还有一个关键细节具体调用规则没有散落在主提示词里而是收进了 skill。审核服务对应的harness-google-review-httpskill不只是告诉模型“去审核一下”。它把服务地址、默认 agent、调用脚本、超时、session id、重试规则、输出字段都写清楚了。修复服务对应的harness-coding-httpskill 也一样。它要求下游明确返回是否修复、改了哪些文件、做过哪些验证、还剩什么风险。这些字段不是为了好看是在把模型嘴里的“我修好了”变成系统能判断的结构化信号。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、子任务、工具失败、事件回放、超时和最终收口。没有 runtimeloop 很容易退化成脚本加 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_issuesfalse且submit_readytrue结束输出上线结论初审/复审完成仍有问题或结论不明确调用修复服务修复完成fixedtrueround 1进入下一轮复审修复未完成fixedfalse或无结构化结论重试仍失败则阻塞下游调用异常okfalse、超时、无 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大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取