这几天 Loop Engineering 这个词突然被刷得很多。

有人说 Prompt 已死，Loop当立。听起来很热闹，但当你了解之后就会发现，从政治课本里那句 “事物发展是前进性和曲折性的统一，发展的形式是波浪式前进、螺旋式上升”，到过往工作中梳理 case → 定义问题 → 清洗 / 构造数据 → 训练 → 评估 → 找 badcase → 再迭代，乃至面试求职时面试失利、复盘总结、反复再战的循环，我们其实早就一直在实践 Loop Engineering 了。

什么是 Loop Engineering

Loop Engineering（循环工程），指的是：把 Agent 的多次执行组织成一套可持续运行的自动闭环，由系统决定下一步做什么、如何验证结果、何时继续以及何时停止。

目前，它仍是一个新兴概念，尚未形成严格统一的定义。Google Chrome 与 Cloud AI 工程负责人 Addy Osmani 被普遍视为这一概念的正式提出者。他将其概括为：过去由人持续向 Agent 输入 Prompt，现在由程序自动生成并提交下一轮 Prompt。[1]

举个生活化的例子。

你让一个实习生整理资料。

常规指令是：

“

帮我看看 xxx、xxx 这几个博主的公众号有没有发布新文章。

Loop 版本是：

“

每天上午 10 点检查新文章；发现更新后先去重，再按主题分类；每篇提取 3 个核心观点并附上原文链接；遇到付费墙、难以理解的论文或证据不足的结论，转交人工处理；每天晚上将新增内容写入同一个文档；连续 3 天没有更新则暂停任务。

前者只规定了这一次要做什么，后者同时规定了触发时间、处理步骤、异常分支、结果存储和停止条件。

可以把 Loop Engineering 理解为一种“我预判了你的预判”：提前考虑 Agent 可能出现的遗忘、重复、跑偏、卡住和无限执行，并把对应的处理规则写进流程。

换到代码场景也是一样。

过去你会对 Agent 说：

“

帮我修一下这个 Bug。

现在你可以设计一个 Loop：

“

每天早上扫描过去 24 小时内失败的 CI，读取失败日志和相关 PR，按照“环境抖动、测试不稳定、代码回归、依赖问题”进行分类；对能够本地复现的问题运行最小测试集；对低风险问题创建 worktree 并尝试修复；交给另一个 verifier agent 审查 diff；验证通过后创建 draft PR；遇到无法确定的问题，或连续两轮修复失败，则转交人工处理。

它和几个相近概念的区别

可以把它们理解为三个层级：

因此，Loop Engineering 位于之前讲的 Harness Engineering 之上，负责调度和反馈控制。 Harness 管理 Agent 单次运行所需的环境，Loop 则反复启动 Harness，根据执行结果生成下一轮任务，让整个系统持续推进，直到完成目标或触发停止条件。

一个 Loop 通常包含什么？

一个比较完整的 Loop，通常包含下面八个部分。

1.Trigger：什么时候启动？

Trigger 是 Loop 的入口。

它可以是定时任务，例如每天上午 10 点检查一次新文章；也可以是 GitHub 事件，例如 PR 出现新评论、CI 运行失败；还可以是监控告警、新数据到达，或者用户主动发起任务。

没有 Trigger，Agent 就只能等人手动输入下一条指令。它仍然能完成任务，但还没有真正形成自动运行的 Loop。

2.Task Discovery：下一步做什么？

Trigger 只负责把系统叫醒，Task Discovery 负责寻找这一轮真正值得做的事情。

比如每天扫描一次 GitHub，并不意味着所有 Issue 都要处理。系统还要判断：

• 哪些问题是新出现的；
• 哪些问题已经有人处理；
• 哪些问题风险低、适合交给 Agent；
• 哪些问题优先级更高；
• 哪些任务互相依赖，不能同时开始。

Task Discovery 和普通定时脚本的区别就在这里。定时脚本通常执行固定命令，而 Loop 需要先观察当前状态，再决定这一轮该做什么。

3.State / Memory：上次做到哪里了？

长期运行的 Loop 不能只依赖当前对话记录。

系统需要把已经处理过的任务、当前进度、历史尝试、失败原因和下一步计划，写入模型上下文之外的持久化存储。它可以是 Markdown、JSON、数据库、GitHub Issue，也可以是项目管理系统中的任务卡片。

比如公众号监控 Loop 至少要记住：

• 上一次检查时间；
• 已经收录过哪些文章；
• 哪些文章处理失败；
• 失败原因是什么；
• 哪些内容正在等待人工确认。

否则下一轮 Agent 很可能把旧文章当成新文章，再总结一遍。

4.Agent Execution：具体由谁来执行？

这一层才轮到 Agent 真正干活。

系统根据当前任务调用 Coding Agent、Research Agent 或数据分析 Agent，让它读取材料、调用工具、修改代码、执行实验或者生成报告。

这里需要明确 Agent 的工具和权限边界。例如：

• 可以读取哪些文件；
• 可以运行哪些命令；
• 是否允许修改代码；
• 是否允许访问 GitHub、数据库或内部文档；
• 是否允许创建 PR；
• 哪些操作必须先经过人工审批。

5.Verifier：怎么证明做对了？

Agent 说“完成了”，不代表任务真的完成了。

Verifier 负责提供外部验证信号。不同任务可以使用不同方式：

• 编码任务：单元测试、构建结果、lint、类型检查；
• 数据任务：Schema、行数、空值率、质量规则；
• 文档任务：格式检查、引用完整性、人工抽样；
• 开放任务：Rubric、LLM Judge 或独立 Reviewer Agent。

验证信号应该尽量从确定性规则开始，再逐步使用模型判断。越接近生产环境，越不能只依赖 Agent 的自我评价。

6.Iteration Policy：失败后怎么调整？

Verifier 不通过以后，系统不能只把完全相同的 Prompt 再运行一遍。

Iteration Policy 要规定失败以后怎么改变策略，例如：

• 补充缺失的上下文；
• 换一种检索方式；
• 缩小问题范围；
• 根据错误日志修改方案；
• 回滚本轮修改；
• 切换另一个 Agent；
• 连续失败后转交人工。

这一层决定了 Loop 是在“迭代”，还是在机械地重复犯错。

7.Stop Condition：什么时候停止？

目标型 Loop 可以在目标完成、连续多轮无进展、达到最大次数或预算耗尽时停止。

周期型 Loop 则要区分两种停止：

• 单轮停止：这一次检查和处理已经完成；
• 整个任务停止：人工关闭、超过运行期限、连续抓取失败、权限失效或预算耗尽。

比如公众号监控任务不是“三天没有新文章就永久停止”。更合理的设计是：没有新文章时结束本轮检查，第二天继续运行；只有连续多次抓取失败、账号无法访问、达到成本上限或人工关闭时，整个 Loop 才暂停。

CI 巡检也是一样。外层 Loop 每天持续检查，内层修复 Loop 在测试通过、达到重试上限或转人工以后结束。

8.Budget Control：最多花多少钱？

Loop 会放大 Agent 的 Token、时间和 API 消耗。

所以系统需要提前设置：

• 最大运行时间；
• 最大迭代次数；
• 最大模型调用次数；
• Token 或金额预算；
• 最大并发任务数；
• 无进展多久以后暂停。

预算控制不是简单的成本优化，它本身就是停止条件和安全边界的一部分。一个没有预算上限的 Loop，即使技术上没有死循环，也可能变成账单上的死循环。

支撑 Loop 运行的基础组件

上面的八个部分描述的是 Loop 如何运转。真正落地时，还需要一组基础组件支撑它。

• Worktree：为多个 Agent 或多次实验提供隔离的代码工作区，避免互相修改同一份文件；
• Skills：沉淀项目规则、操作步骤和领域知识，避免每轮都从零解释；
• Connectors：把 Agent 接入 GitHub、数据库、日志平台、任务系统等真实工作环境；
• Sub-agents：把探索、执行和验证拆给不同 Agent，减少自己写、自己审的问题；
• 持久化 Memory：把进度和决策保存在单次会话之外，让下一轮可以继续。

这些组件并不等于 Loop 本身。更准确地说，它们是 Loop 能够长期、并行、稳定运行的基础设施。

它算不算一个新东西？

如果只看底层思想，Loop Engineering 并不新。

ReAct 里有“推理—行动—观察”的循环，Plan-Execute 会根据执行结果更新计划，Self-Refine 会生成、评价再修改。自动重试、CI/CD、定时任务、工作流引擎和状态机里，也早就存在触发、执行、判断、回滚和停止。

所以有人把 Loop Engineering 调侃成：

“

cron job + Agent + evaluator + memory

这个评价有一定道理。

但它也只说对了一半。

新变化不在于人类突然发明了“循环”，而在于 Coding Agent 的能力已经跨过了一个临界点。现在的 Agent 可以长时间操作代码库、读取非结构化信息、调用外部工具、运行测试、启动子 Agent，并根据多轮反馈调整任务。

过去的自动化流程通常需要工程师提前写死每一步。现在的 Loop 可以把一部分“下一步做什么”的判断交给 Agent。

工程重点也因此发生了变化：

过去我们主要关心：

“

这一条 Prompt 怎么写，模型才会给出更好的答案？

现在还要继续关心：

“

下一轮 Prompt 由谁生成？什么时候生成？带哪些上下文？执行完以后谁来验收？失败以后怎么改？状态保存在哪里？什么时候必须停？

所以 Loop Engineering 真正有价值的地方，是把任务发现、Agent 执行、结果验证、状态记忆、继续策略、预算控制和停止条件，统一成一个工程设计对象。

Loop Engineering 能做什么？

前面讲的是框架，下面讲场景。

我建议你面试的时候不要只讲“可以做 CI，可以做自动实验”这种泛泛而谈的话。

你要讲“这个场景为什么适合 loop，loop 怎么设计，验证信号是什么，风险在哪里”。

场景举例：CI / PR Babysit Loop

这是最适合第一版落地的 loop。

因为它有几个天然优势：

• 触发信号明确：CI 失败、PR 更新、review comment 出现；
• 输入证据明确：测试日志、commit diff、失败栈；
• 验证方式明确：本地测试、CI 状态；
• 回滚方式明确：git branch / worktree；
• 风险可控：先只开 draft PR，不自动合并。

第一版不要急着自动修。

我会先做只读 triage：

每天上午 9 点读取最近 24 小时 CI 失败：

1. 1.读取失败 workflow、PR、commit、失败日志；
2. 2.判断失败类型：环境抖动、测试不稳定、代码回归、依赖问题；
3. 3.能本地复现就跑最小测试集；
4. 4.输出报告：证据、可能原因、建议负责人；
5. 5.不改代码，不开 PR，不发外部消息；
6. 6.超过 10 个失败项或证据不足时停止。

这版跑稳定之后，再放开 L2：

• 对格式化失败、快照更新、依赖锁文件冲突这类低风险问题开 worktree；
• 修完只跑对应测试；
• 通过后开 draft PR；
• verifier agent 独立审查 diff；
• 人类最终 review。

这个案例面试很好讲，因为它完整覆盖了 Automations、Worktree、Skill、Connector、Sub-agent、Memory、Stop condition。

面试官追问“为什么需要 worktree”，你可以答：

“

多个 Agent 同时修不同 CI 失败时，如果都在主工作区改文件，冲突会非常混乱。worktree 相当于给每个尝试一个隔离空间，失败就丢掉，通过再合并，和人类开分支修 bug 是同一个逻辑。

面试官追问“为什么不直接自动 merge”，你可以答：

“

因为 CI 通过只是必要条件，不是充分条件。它只能证明没有触发已有测试，不能证明业务语义正确。第一阶段我会让 Agent 只开 draft PR，自动合并要等问题类型固定、测试覆盖充分、回滚机制成熟之后再考虑。

这就是工程判断。

一些最近的面试题

你来谈谈Loop Engineering吧

我理解的 Loop Engineering，是把人反复给 Agent 下指令、检查结果、继续追问的过程，设计成一套可以自动运行的反馈闭环。

它主要解决四个问题：

1. 1.Agent 下一步做什么；
2. 2.当前结果是否合格；
3. 3.失败以后重试、换方案还是转人工；
4. 4.什么情况下停止运行。

从架构上看，Loop Engineering 位于 Agent Harness 之上。

Harness 负责 Agent 单次运行所需的环境，例如上下文、工具、Skills、沙箱、权限、日志和状态持久化。Loop 负责反复调用 Harness，根据每一轮的执行结果，生成下一轮任务，让系统持续向长期目标推进。

一个比较完整的 Loop 通常包含几个部分：

• Trigger 和任务发现，例如定时扫描 GitHub Issue 或 CI 失败；
• 任务拆分与调度，决定优先级以及交给哪个 Agent；
• Agent 执行，通过 Harness 调用工具、修改代码；
• Verifier，通过测试、规则、Rubric 或独立 Agent 验证结果；
• State 和 Memory，记录已经完成的任务、失败原因和中间产物；
• 迭代策略与停止条件，包括最大重试次数、Token 预算、超时和人工升级。

例如，在 CI 修复场景中，Loop 可以每天扫描过去 24 小时的失败任务，读取日志并分类；对能够复现的低风险问题创建 worktree，让 Coding Agent 尝试修复；修改完成后运行测试，再交给 Verifier Agent 审查 diff；验证通过就创建 Draft PR，连续两轮失败或者涉及高风险模块则转交人工。

个人观点：

Loop Engineering 这个名称比较新，但它使用的很多组件已经存在于工作流引擎、状态机、CI/CD、任务调度和控制系统中。现在的变化是 Agent 可以理解非结构化信息、动态选择工具并调整下一步策略，所以 Loop 从固定流程逐渐变成了带语义判断能力的自适应流程。

追问：Agent 本身不就有循环吗？

Agent 内部通常也有 Plan、Act、Observe 循环，它解决的是一次任务执行过程中的推理和工具调用。Loop Engineering 讨论的是外层循环，例如什么时候启动一个 Agent、给它什么任务、怎样验证结果、怎样保存进度、失败后是否重新启动，以及什么时候结束整个长期任务。

追问：Verifier Agent 会不会也判断错？

会，所以不能只依赖另一个模型的主观评价。验证信号应该分层设计：优先使用可执行测试、编译结果、类型检查、数据库约束等确定性信号；再使用规则和 Rubric；最后才使用 LLM Judge。涉及生产发布、数据删除、资金或权限变更时，还要加入人工审批。

01

什么是AI大模型应用开发工程师？

如果说AI大模型是蕴藏着巨大能量的“后台超级能力”，那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。

AI大模型应用开发工程师是基于AI大模型，设计开发落地业务的应用工程师。

这个职业的核心价值，在于打破技术与用户之间的壁垒，把普通人难以理解的算法逻辑、模型参数，转化为人人都能轻松操作的产品形态。

无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能，还是办公场景中的自动记账工具、会议记录用的语音转文字APP，这些看似简单的应用背后，都是应用开发工程师在默默搭建技术与需求之间的桥梁。

他们不追求创造全新的大模型，而是专注于让已有的大模型“听懂”业务需求，“学会”解决具体问题，最终形成可落地、可使用的产品。

CSDN粉丝独家福利

给大家整理了一份AI大模型全套学习资料，这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取 【保证100%免费】

02

AI大模型应用开发工程师的核心职责

需求分析与拆解是工作的起点，也是确保开发不偏离方向的关键。

应用开发工程师需要直接对接业务方，深入理解其核心诉求——不仅要明确“要做什么”，更要厘清“为什么要做”以及“做到什么程度算合格”。

在此基础上，他们会将模糊的业务需求拆解为具体的技术任务，明确每个环节的执行标准，并评估技术实现的可行性，同时定义清晰的核心指标，为后续开发、测试提供依据。

这一步就像建筑前的图纸设计，若出现偏差，后续所有工作都可能白费。

技术选型与适配是衔接需求与开发的核心环节。

工程师需要根据业务场景的特点，选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同，选型的合理性直接影响最终产品的表现。

同时，他们还要对行业相关数据进行预处理，通过提示词工程优化模型输出，或在必要时进行轻量化微调，让基础模型更好地适配具体业务。

此外，设计合理的上下文管理规则确保模型理解连贯需求，建立敏感信息过滤机制保障数据安全，也是这一环节的重要内容。

应用开发与对接则是将方案转化为产品的实操阶段。

工程师会利用选定的开发框架构建应用的核心功能，同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通，确保数据流转顺畅。

在这一过程中，他们还需要配合设计团队打磨前端交互界面，让技术功能以简洁易懂的方式呈现给用户，实现从技术方案到产品形态的转化。

测试与优化是保障产品质量的关键步骤。

工程师会开展全面的功能测试，找出并修复开发过程中出现的漏洞，同时针对模型的响应速度、稳定性等性能指标进行优化。

安全合规性也是测试的重点，需要确保应用符合数据保护、隐私安全等相关规定。

此外，他们还会收集用户反馈，通过调整模型参数、优化提示词等方式持续提升产品体验，让应用更贴合用户实际使用需求。

部署运维与迭代则贯穿产品的整个生命周期。

工程师会通过云服务器或私有服务器将应用部署上线，并实时监控运行状态，及时处理突发故障，确保应用稳定运行。

随着业务需求的变化，他们还需要对应用功能进行迭代更新，同时编写完善的开发文档和使用手册，为后续的维护和交接提供支持。

03

薪资情况与职业价值

市场对这一职业的高度认可，直接体现在薪资待遇上。

据猎聘最新在招岗位数据显示，AI大模型应用开发工程师的月薪最高可达60k。

在AI技术加速落地的当下，这种“技术+业务”的复合型能力尤为稀缺，让该职业成为当下极具吸引力的就业选择。

AI大模型应用开发工程师是AI技术落地的关键桥梁。

他们用专业能力将抽象的技术转化为具体的产品，让大模型的价值真正渗透到各行各业。

随着AI场景化应用的不断深化，这一职业的重要性将更加凸显，也必将吸引更多人才投身其中，推动AI技术更好地服务于社会发展。

CSDN粉丝独家福利

给大家整理了一份AI大模型全套学习资料，这份完整版的 AI 大模型学习资料已经上传CSDN，朋友们如果需要可以扫描下方二维码&点击下方CSDN官方认证链接免费领取 【保证100%免费】