一、什么是 Loop EngineeringLoop Engineering 是由谷歌工程师 Addy Osmani 提出的 AI 编程新范式。其核心理念是围绕大模型构建自主循环运行系统使 AI 从单次响应工具升级为长期自治代理。在传统的 AI 辅助开发中开发者与 AI 的交互模式是一问一答——你发一条指令AI 回复一次然后等待下一条指令。这种模式的瓶颈在于人成了循环的瓶颈。每一步都需要人类介入AI 无法自主推进复杂工作流。Loop Engineering 的解法是让人从循环内部的操作者转变为循环之上的监督者和目标设定者。你定义做什么和何时算完成AI 自己决定怎么做和下一步是什么直到目标达成或确认不可达。类比传统工程学中的 PDCA 循环Plan-Do-Check-Act在 Loop Engineering 中模型是执行者Loop是控制中枢规则框架是边界约束这三者组合让 AI 在可控范围内自主推进复杂工作流。为什么现在重要当模型能力足够强时循环设计成为决定 AI 自主性与可靠性的关键瓶颈。一个设计良好的循环可以让 AI 连续工作数十轮完成复杂重构而一个设计糟糕的循环可能在第三轮就失控。Loop Engineering 被视为继 Prompt Engineering、Context Harness Engineering 之后的AI 编程第三次革命——开发者角色从提示词工程师彻底升级为AI 系统架构师。二、Loop Engineering 与 ReAct 的区别ReActReasoning Acting是目前最主流的 AI Agent 交互范式由 Yao et al. 在 2022 年提出。其核心模式是思考 → 行动 → 观察 → 思考 → 行动 → 观察……交替进行推理和工具调用直到任务完成。Loop Engineering 与 ReAct 经常被放在一起讨论但它们解决的是不同层次的问题。理解两者的区别是正确实践 Loop Engineering 的前提。本质关系Inner Loop vs Outer LoopReAct 是 Loop Engineering 的 Inner Loop。Loop EngineeringOuter Loop┌─────────────────────────────────────────────────────┐│ 目标拆解 → 任务分配 → 结果汇总 → 再计划 ││ ││ ┌─────────────────────────────────────────────────┐ ││ │ ReActInner Loop │ ││ │ 思考 → 行动 → 观察 → 思考 → 行动 → 观察 ... │ ││ └─────────────────────────────────────────────────┘ ││ ││ ┌─────────────────────────────────────────────────┐ ││ │ ReActInner Loop │ ││ │ 思考 → 行动 → 观察 → 思考 → 行动 → 观察 ... │ ││ └─────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────┘ReAct 解决的是单次任务内怎么一步步做的问题Loop Engineering 解决的是跨任务做什么、谁来做、何时停、怎么续的问题核心差异对比维度ReActLoop Engineering关注层次单次任务的执行过程跨任务的编排与调度循环粒度细粒度单步工具调用粗粒度整个任务周期状态管理依赖上下文窗口内记忆状态外置到文件/数据库每次迭代全新上下文停止条件模型自己判断做完了独立评估器验证可度量条件是否满足验证机制自我检查同一模型对抗验证不同模型/独立评估器错误恢复在同一上下文内重试断点续跑可跨会话恢复并行能力单 Agent 串行多 Agent 并行 工作树隔离运行周期单次对话可持续数小时甚至数天用一个类比理解把开发一个软件比作建一栋楼ReAct是工人的工作方式——“我需要砌这面墙先搬砖再和水泥再砌检查是否平整不平就修”。它关注的是单步操作的执行质量。Loop Engineering是项目经理的工作方式——“今天完成地基明天搭框架后天装管道质检通过再进行下一步不合格就返工”。它关注的是整体工程进度的编排与质量保障。没有工人的砌墙能力ReAct楼建不起来没有项目经理的编排Loop Engineering工人可能把墙砌错了地方或者砌完才发现管道没留口。ReAct 的局限Loop Engineering 如何补位局限 1上下文窗口有限长任务必然遗忘ReAct 在同一个上下文窗口内持续推理。当任务跨越几十步操作时早期信息被压缩或遗忘导致 AI 忘记之前做了什么、为什么这么做。Loop Engineering 的解法状态外置。每轮迭代从全新上下文开始从持久化文件中读取状态不依赖模型记忆。CodeBuddy 中的 Memory、CODEBUDDY.md、Rules 就是这一原则的体现。局限 2自我检查存在盲区ReAct 中同一个模型既写代码又检查代码容易产生确认偏误——“我写的当然没问题”。Loop Engineering 的解法对抗验证。执行者和评估者使用不同模型或指令。CodeBuddy 中/goal的评估器用小模型独立判断Team 模式中 planner/coder/reviewer 使用不同角色都是对抗验证的实践。局限 3没有跨任务的进度跟踪ReAct 完成一个任务就结束没有做到哪了的持久记录。如果中途崩溃只能从头来。Loop Engineering 的解法断点续跑。通过状态文件记录进度崩溃后可从断点恢复。CodeBuddy 中/goal支持--resume恢复未完成的 goalMemory 记录跨会话上下文。局限 4缺少编排能力ReAct 是单 Agent 串行执行无法同时推进多个子任务。Loop Engineering 的解法多 Agent 并行 工作树隔离。CodeBuddy 的 Team 模式支持多个 Agent 同时工作在不同分支上互不干扰最后合并结果。不是替代是演进Loop Engineering 不是要替代 ReAct而是在 ReAct 之上增加编排层。两者关系Prompt Engineering → 怎么问单次交互优化 ↓ReAct → 怎么做单任务内的推理-行动循环 ↓Loop Engineering → 怎么管跨任务的编排、验证、状态管理在 CodeBuddy 中当你用/goal设置一个条件时每一轮内部 AI 仍然使用 ReAct 模式来思考和行动但/goal的评估器在 Outer Loop 层面判断整体进度——这就是两层循环的协作。三、Loop Engineering 的核心架构五阶段循环机制Loop Engineering 遵循Discover → Plan → Execute → Verify → Iterate闭环阶段说明关键设计Discover自动读取 CI 失败、issue、代码审查等信号输入源要结构化、可订阅Plan分解目标为具体步骤温度适中避免过早收敛Execute执行代码编辑与工具调用工具调用要幂等、可回滚Verify通过测试、lint、类型检查等客观信号验证验证标准必须客观、可机器判定Iterate失败则自动修复并重新循环成功则进入下一任务状态要持久化支持断点续跑双层循环模型Loop Engineering 采用双层循环架构Outer Loop编排层 目标拆解 → 任务分配 → 结果汇总 → 再计划 Inner Loop执行层 感知 → 推理 → 规划 → 行动 → 观察 ↑ ↓ 评估 / 修正 ←───────────┘Inner Loop 单个 Agent 的工作循环等价于 ReAct 模式Outer Loop 编排器管理多个 Inner Loop 的生命周期六要素构建体系要素作用为什么重要自动化提供循环心跳按计划或事件触发没有心跳就没有循环工作树通过 git 为每个 Agent 创建独立工作目录并行开发零冲突技能SKILL.md固化项目知识避免每次冷启动重新推导知识复用降低 token 消耗连接器MCP打通 issue 系统、CI 等真实工具链AI 必须能感知和操作真实世界子智能体将写代码与检查代码分离形成对抗验证避免单一 Agent 自我检查的盲区状态文件记录进度支撑断点续跑防止上下文遗忘和信息漂移状态外置哲学Loop Engineering 的一个关键设计原则所有状态存储在外部系统而非模型的上下文窗口。每次循环迭代从一个全新的上下文窗口开始基于实际持久化内容工作。这彻底解决了模型遗忘、信息漂移与上下文压缩问题。四、CodeBuddy 中的 Loop Engineering 实现CodeBuddy 提供了三种核心机制来实现 Loop Engineering它们分别对应不同的循环驱动模式3.1/goal— 条件驱动的持续工作/goal是 Loop Engineering 最直接的实现。你设置一个可验证的完成条件CodeBuddy 跨多轮自动工作直到条件满足。# 基本语法/goal 完成条件# 实际示例/goal all tests in test/auth pass and the lint step is clean# 加兜底上限防止无限循环/goal all tests pass or stop after 20 turns# 非交互模式headless 运行codebuddy -p /goal CHANGELOG.md has an entry for every PR merged this week写好条件的三个关键要素要素说明示例可度量的终态测试结果、构建退出码、文件数等all tests in test/auth pass可证明方式明确怎么验证npm test exits 0或git status is clean不可破坏的约束过程中不能改的东西no other test file is modified评估机制每轮结束后由独立小模型评估器判断条件是否满足三态结果✅ok: true— 条件已满足清除 goalUI 显示✔ Goal achievedok: false— 条件未满足reason 注入 history继续下一轮❌ok: false, impossible: true— 目标不可达立即清除 goal关键设计评估器使用小模型如 gemini-2.5-flash快速且便宜只看 transcript 不调用工具。评估器与执行 Agent 使用不同模型天然形成对抗验证。3.2/loop— 时间驱动的循环任务/loop按时间间隔重复执行指令适合监控、巡检等持续性场景# 语法/loop [时间间隔] 指令# 检查 CI/CD 流水线状态/loop 3m 检查一下流水线是否跑完把结果告诉我# 定时运行单元测试/loop 30m 帮我运行一次单元测试如果有失败的用例告诉我# 每小时汇总代码审查待办/loop 1h 看一下有没有新的 PR 需要我审查特性说明最小间隔1 分钟每会话上限50 个任务自动过期3 天后自动清除生命周期会话级退出后消失执行时机只在会话空闲时触发3.3 Automations — 跨会话的定时任务Automations 是持久化的定时任务不随会话消失适合需要长期运行的监控场景Recurring按 cron 规则重复执行如FREQHOURLY;INTERVAL1Once指定时间点一次性触发三种方式的对比方式下一轮何时开始何时停止适用场景/goal上一轮结束后立即评估器确认条件满足有明确终态的实质性工作/loop时间间隔触发主动停或模型判定结束监控、巡检、定期检查Automations按 cron 规则永久或设有效期跨会话的长期监控五、Loop Engineering 架构在 CodeBuddy 中的映射Loop Engineering 要素CodeBuddy 实现说明自动化循环心跳/goal、/loop、Automations三种驱动模式覆盖不同场景工作树并行隔离Git worktree Team 模式多 Agent 并行开发互不干扰技能SKILL.mdSkills 机制固化项目知识避免冷启动连接器MCPMCP 协议打通 issue、CI、数据库等工具链子智能体对抗验证Task 工具 Team 模式规划者/执行者/评审者三角分工状态文件Memory、CODEBUDDY.md、Rules跨会话知识持久化六、实践案例实践 1使用/goal完成模块迁移场景将一个旧认证模块从auth/legacy迁移到新 API直到所有调用点都能编译且测试通过。/goal all tests in test/auth pass, npm run build exits 0, no file in auth/legacy is imported anywhere, or stop after 30 turns为什么这样写条件all tests in test/auth pass— 可度量的终态确保功能不受损npm run build exits 0— 可证明方式确保编译通过no file in auth/legacy is imported anywhere— 不可破坏的约束确保旧代码完全移除or stop after 30 turns— 兜底上限防止无限循环CodeBuddy 的自动循环过程Discover扫描auth/legacy目录识别所有导出和调用点Plan列出需要修改的文件制定迁移步骤Execute逐个文件修改导入路径更新调用方式Verify运行npm test和npm run build检查编译和测试结果Iterate如果测试失败分析错误原因修复后重新运行每轮结束后评估器独立判断“所有 auth 测试通过了吗构建成功了吗旧文件还有被引用吗”——只有三个条件全部满足才宣告完成。实践 2使用/loop实现 CI 监控与自动修复场景在提交 PR 后持续监控 CI 状态如果失败则尝试自动修复。/loop 2m 检查当前分支的 CI 状态如果失败了查看失败日志并尝试修复修好后提交这个循环的工作流每 2 分钟触发 → 读取 CI 状态 → 如果通过 → 报告成功 → 如果失败 → 读取错误日志 → 分析原因 → 修改代码 → 提交 → 等待下一轮验证注意/loop是时间驱动的不会自动停止。当你确认 CI 通过后需要手动取消取消 CI 监控的定时任务实践 3使用 Team 模式实现对抗验证场景复杂重构任务需要规划者、执行者、评审者三角分工。1. 创建 Team2. 生成 planner负责分析代码库、制定重构方案3. 生成 coder根据方案执行代码修改4. 生成 reviewer独立审查修改结果确保质量5. planner 和 reviewer 使用不同模型/指令形成对抗验证为什么对抗验证重要单一 Agent 自己检查自己的代码容易产生盲区——“我写的代码当然没问题”。规划者和评审者使用不同的视角和指令能发现执行者忽略的问题。实践 4使用 Skills 固化项目知识场景团队有一套编码规范和架构约定希望 AI 每次都能遵循。在skills/目录下创建skill.md将项目知识固化---name: project-conventionsdescription: 项目编码规范和架构约定---## 架构约定- 所有 API 调用必须经过 service 层controller 不直接调用 repository- 数据库查询必须使用参数绑定禁止字符串拼接 SQL- 错误处理遵循统一异常体系...## 命名规范- Service 类以 Service 结尾- Repository 类以 Repository 结尾...效果每次 AI 工作时自动加载这些约定不需要你在每次对话中重复说明。这正是 Loop Engineering 中技能要素的体现——避免每次冷启动重新推导。实践 5使用 MCP 连接器打通工具链场景让 AI 能读取 Jira issue、触发 Jenkins 构建、查询数据库。通过 MCP 协议接入第三方工具{ mcpServers: { jira: { command: mcp-jira, args: [--project, MYPROJ] }, jenkins: { command: mcp-jenkins, args: [--url, https://ci.example.com] } }}接入后在/goal循环中 AI 可以/goal all issues labeled bug in current sprint have a corresponding test that passes, or stop after 50 turnsAI 能直接读取 Jira issue 列表、编写测试、运行验证——整个 Discover → Plan → Execute → Verify → Iterate 闭环都在真实工具链中运行。实践 6使用 Rules 和 Memory 实现状态外置场景长期运行的重构任务需要跨会话保持上下文。Rules.codebuddy/rules定义硬性约束AI 每次启动都会读取- 所有数据库查询必须使用参数绑定- 修改 API 接口必须同步更新 OpenAPI 文档- 每个 PR 不超过 300 行变更Memory记录跨会话的偏好和上下文- 用户偏好使用 pytest 而非 unittest- 当前项目使用 Python 3.11类型注解必须完整- 用户上次重构到 step 3下次继续从 step 4 开始效果每次新的循环迭代从全新的上下文窗口开始时Rules 和 Memory 提供了状态外置——关键信息不依赖模型的记忆而是从持久化存储中读取。这正是 Loop Engineering 状态外置哲学的体现。七、最佳实践与注意事项写好/goal条件的 checklist终态可度量用测试通过“构建成功”文件数为 0这类客观指标避免代码质量提升这类主观判断验证方式明确指定用什么命令/工具来验证如pytest test/auth exits 0约束不可破坏明确过程中不能改的东西如不修改其他模块的测试兜底上限始终加or stop after N turns防止无限循环消耗 token条件不超过 4000 字符这是/goal的硬性限制避免常见陷阱陷阱说明解法验证责任不可转移无人值守的循环也是无人值守地犯错关键变更仍需人工审查Loop 不代替 Code Review理解债务加速累积代码库真实状态与开发者理解之间的鸿沟随循环加速扩大定期 review AI 的变更保持对代码库的理解认知投降风险开发者极易停止独立判断系统给什么就接受什么把 AI 当协作者而非权威质疑每个变更Token 成本约束循环运行消耗大量 token设置stop after N turns用小模型评估器条件模糊导致无效循环条件不够具体AI 反复尝试但无法满足条件要写成AI 自己的输出能证明的形式何时用哪种循环模式有明确终态的实质性工作迁移、重构、实现功能 → /goal持续性监控和巡检CI 状态、PR 审查、性能回归 → /loop跨会话的长期定期任务每日构建检查、每周代码审查汇总 → Automations需要多角色协作的复杂任务规划执行评审 → Team 模式 /goal八、总结Loop Engineering 的核心不是某个具体工具而是一种系统设计思维把 AI 当作循环中的执行者你设计循环的规则、验证标准和状态管理。CodeBuddy 提供了完整的工具链来实现这一范式/goal是 Loop 的心跳——条件驱动自动循环/loop是 Loop 的时钟——时间驱动定期触发Skills是 Loop 的知识——固化经验避免冷启动MCP是 Loop 的触手——连接真实工具链Team 模式是 Loop 的分身——对抗验证多角色协作Rules Memory是 Loop 的记忆——状态外置断点续跑从一问一答到设定目标、自动循环这是 AI 辅助开发从工具到伙伴的质变。而 Loop Engineering 的实践者正是这一质变的设计师。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
一、什么是 Loop EngineeringLoop Engineering 是由谷歌工程师 Addy Osmani 提出的 AI 编程新范式。其核心理念是围绕大模型构建自主循环运行系统使 AI 从单次响应工具升级为长期自治代理。在传统的 AI 辅助开发中开发者与 AI 的交互模式是一问一答——你发一条指令AI 回复一次然后等待下一条指令。这种模式的瓶颈在于人成了循环的瓶颈。每一步都需要人类介入AI 无法自主推进复杂工作流。Loop Engineering 的解法是让人从循环内部的操作者转变为循环之上的监督者和目标设定者。你定义做什么和何时算完成AI 自己决定怎么做和下一步是什么直到目标达成或确认不可达。类比传统工程学中的 PDCA 循环Plan-Do-Check-Act在 Loop Engineering 中模型是执行者Loop是控制中枢规则框架是边界约束这三者组合让 AI 在可控范围内自主推进复杂工作流。为什么现在重要当模型能力足够强时循环设计成为决定 AI 自主性与可靠性的关键瓶颈。一个设计良好的循环可以让 AI 连续工作数十轮完成复杂重构而一个设计糟糕的循环可能在第三轮就失控。Loop Engineering 被视为继 Prompt Engineering、Context Harness Engineering 之后的AI 编程第三次革命——开发者角色从提示词工程师彻底升级为AI 系统架构师。二、Loop Engineering 与 ReAct 的区别ReActReasoning Acting是目前最主流的 AI Agent 交互范式由 Yao et al. 在 2022 年提出。其核心模式是思考 → 行动 → 观察 → 思考 → 行动 → 观察……交替进行推理和工具调用直到任务完成。Loop Engineering 与 ReAct 经常被放在一起讨论但它们解决的是不同层次的问题。理解两者的区别是正确实践 Loop Engineering 的前提。本质关系Inner Loop vs Outer LoopReAct 是 Loop Engineering 的 Inner Loop。Loop EngineeringOuter Loop┌─────────────────────────────────────────────────────┐│ 目标拆解 → 任务分配 → 结果汇总 → 再计划 ││ ││ ┌─────────────────────────────────────────────────┐ ││ │ ReActInner Loop │ ││ │ 思考 → 行动 → 观察 → 思考 → 行动 → 观察 ... │ ││ └─────────────────────────────────────────────────┘ ││ ││ ┌─────────────────────────────────────────────────┐ ││ │ ReActInner Loop │ ││ │ 思考 → 行动 → 观察 → 思考 → 行动 → 观察 ... │ ││ └─────────────────────────────────────────────────┘ │└─────────────────────────────────────────────────────┘ReAct 解决的是单次任务内怎么一步步做的问题Loop Engineering 解决的是跨任务做什么、谁来做、何时停、怎么续的问题核心差异对比维度ReActLoop Engineering关注层次单次任务的执行过程跨任务的编排与调度循环粒度细粒度单步工具调用粗粒度整个任务周期状态管理依赖上下文窗口内记忆状态外置到文件/数据库每次迭代全新上下文停止条件模型自己判断做完了独立评估器验证可度量条件是否满足验证机制自我检查同一模型对抗验证不同模型/独立评估器错误恢复在同一上下文内重试断点续跑可跨会话恢复并行能力单 Agent 串行多 Agent 并行 工作树隔离运行周期单次对话可持续数小时甚至数天用一个类比理解把开发一个软件比作建一栋楼ReAct是工人的工作方式——“我需要砌这面墙先搬砖再和水泥再砌检查是否平整不平就修”。它关注的是单步操作的执行质量。Loop Engineering是项目经理的工作方式——“今天完成地基明天搭框架后天装管道质检通过再进行下一步不合格就返工”。它关注的是整体工程进度的编排与质量保障。没有工人的砌墙能力ReAct楼建不起来没有项目经理的编排Loop Engineering工人可能把墙砌错了地方或者砌完才发现管道没留口。ReAct 的局限Loop Engineering 如何补位局限 1上下文窗口有限长任务必然遗忘ReAct 在同一个上下文窗口内持续推理。当任务跨越几十步操作时早期信息被压缩或遗忘导致 AI 忘记之前做了什么、为什么这么做。Loop Engineering 的解法状态外置。每轮迭代从全新上下文开始从持久化文件中读取状态不依赖模型记忆。CodeBuddy 中的 Memory、CODEBUDDY.md、Rules 就是这一原则的体现。局限 2自我检查存在盲区ReAct 中同一个模型既写代码又检查代码容易产生确认偏误——“我写的当然没问题”。Loop Engineering 的解法对抗验证。执行者和评估者使用不同模型或指令。CodeBuddy 中/goal的评估器用小模型独立判断Team 模式中 planner/coder/reviewer 使用不同角色都是对抗验证的实践。局限 3没有跨任务的进度跟踪ReAct 完成一个任务就结束没有做到哪了的持久记录。如果中途崩溃只能从头来。Loop Engineering 的解法断点续跑。通过状态文件记录进度崩溃后可从断点恢复。CodeBuddy 中/goal支持--resume恢复未完成的 goalMemory 记录跨会话上下文。局限 4缺少编排能力ReAct 是单 Agent 串行执行无法同时推进多个子任务。Loop Engineering 的解法多 Agent 并行 工作树隔离。CodeBuddy 的 Team 模式支持多个 Agent 同时工作在不同分支上互不干扰最后合并结果。不是替代是演进Loop Engineering 不是要替代 ReAct而是在 ReAct 之上增加编排层。两者关系Prompt Engineering → 怎么问单次交互优化 ↓ReAct → 怎么做单任务内的推理-行动循环 ↓Loop Engineering → 怎么管跨任务的编排、验证、状态管理在 CodeBuddy 中当你用/goal设置一个条件时每一轮内部 AI 仍然使用 ReAct 模式来思考和行动但/goal的评估器在 Outer Loop 层面判断整体进度——这就是两层循环的协作。三、Loop Engineering 的核心架构五阶段循环机制Loop Engineering 遵循Discover → Plan → Execute → Verify → Iterate闭环阶段说明关键设计Discover自动读取 CI 失败、issue、代码审查等信号输入源要结构化、可订阅Plan分解目标为具体步骤温度适中避免过早收敛Execute执行代码编辑与工具调用工具调用要幂等、可回滚Verify通过测试、lint、类型检查等客观信号验证验证标准必须客观、可机器判定Iterate失败则自动修复并重新循环成功则进入下一任务状态要持久化支持断点续跑双层循环模型Loop Engineering 采用双层循环架构Outer Loop编排层 目标拆解 → 任务分配 → 结果汇总 → 再计划 Inner Loop执行层 感知 → 推理 → 规划 → 行动 → 观察 ↑ ↓ 评估 / 修正 ←───────────┘Inner Loop 单个 Agent 的工作循环等价于 ReAct 模式Outer Loop 编排器管理多个 Inner Loop 的生命周期六要素构建体系要素作用为什么重要自动化提供循环心跳按计划或事件触发没有心跳就没有循环工作树通过 git 为每个 Agent 创建独立工作目录并行开发零冲突技能SKILL.md固化项目知识避免每次冷启动重新推导知识复用降低 token 消耗连接器MCP打通 issue 系统、CI 等真实工具链AI 必须能感知和操作真实世界子智能体将写代码与检查代码分离形成对抗验证避免单一 Agent 自我检查的盲区状态文件记录进度支撑断点续跑防止上下文遗忘和信息漂移状态外置哲学Loop Engineering 的一个关键设计原则所有状态存储在外部系统而非模型的上下文窗口。每次循环迭代从一个全新的上下文窗口开始基于实际持久化内容工作。这彻底解决了模型遗忘、信息漂移与上下文压缩问题。四、CodeBuddy 中的 Loop Engineering 实现CodeBuddy 提供了三种核心机制来实现 Loop Engineering它们分别对应不同的循环驱动模式3.1/goal— 条件驱动的持续工作/goal是 Loop Engineering 最直接的实现。你设置一个可验证的完成条件CodeBuddy 跨多轮自动工作直到条件满足。# 基本语法/goal 完成条件# 实际示例/goal all tests in test/auth pass and the lint step is clean# 加兜底上限防止无限循环/goal all tests pass or stop after 20 turns# 非交互模式headless 运行codebuddy -p /goal CHANGELOG.md has an entry for every PR merged this week写好条件的三个关键要素要素说明示例可度量的终态测试结果、构建退出码、文件数等all tests in test/auth pass可证明方式明确怎么验证npm test exits 0或git status is clean不可破坏的约束过程中不能改的东西no other test file is modified评估机制每轮结束后由独立小模型评估器判断条件是否满足三态结果✅ok: true— 条件已满足清除 goalUI 显示✔ Goal achievedok: false— 条件未满足reason 注入 history继续下一轮❌ok: false, impossible: true— 目标不可达立即清除 goal关键设计评估器使用小模型如 gemini-2.5-flash快速且便宜只看 transcript 不调用工具。评估器与执行 Agent 使用不同模型天然形成对抗验证。3.2/loop— 时间驱动的循环任务/loop按时间间隔重复执行指令适合监控、巡检等持续性场景# 语法/loop [时间间隔] 指令# 检查 CI/CD 流水线状态/loop 3m 检查一下流水线是否跑完把结果告诉我# 定时运行单元测试/loop 30m 帮我运行一次单元测试如果有失败的用例告诉我# 每小时汇总代码审查待办/loop 1h 看一下有没有新的 PR 需要我审查特性说明最小间隔1 分钟每会话上限50 个任务自动过期3 天后自动清除生命周期会话级退出后消失执行时机只在会话空闲时触发3.3 Automations — 跨会话的定时任务Automations 是持久化的定时任务不随会话消失适合需要长期运行的监控场景Recurring按 cron 规则重复执行如FREQHOURLY;INTERVAL1Once指定时间点一次性触发三种方式的对比方式下一轮何时开始何时停止适用场景/goal上一轮结束后立即评估器确认条件满足有明确终态的实质性工作/loop时间间隔触发主动停或模型判定结束监控、巡检、定期检查Automations按 cron 规则永久或设有效期跨会话的长期监控五、Loop Engineering 架构在 CodeBuddy 中的映射Loop Engineering 要素CodeBuddy 实现说明自动化循环心跳/goal、/loop、Automations三种驱动模式覆盖不同场景工作树并行隔离Git worktree Team 模式多 Agent 并行开发互不干扰技能SKILL.mdSkills 机制固化项目知识避免冷启动连接器MCPMCP 协议打通 issue、CI、数据库等工具链子智能体对抗验证Task 工具 Team 模式规划者/执行者/评审者三角分工状态文件Memory、CODEBUDDY.md、Rules跨会话知识持久化六、实践案例实践 1使用/goal完成模块迁移场景将一个旧认证模块从auth/legacy迁移到新 API直到所有调用点都能编译且测试通过。/goal all tests in test/auth pass, npm run build exits 0, no file in auth/legacy is imported anywhere, or stop after 30 turns为什么这样写条件all tests in test/auth pass— 可度量的终态确保功能不受损npm run build exits 0— 可证明方式确保编译通过no file in auth/legacy is imported anywhere— 不可破坏的约束确保旧代码完全移除or stop after 30 turns— 兜底上限防止无限循环CodeBuddy 的自动循环过程Discover扫描auth/legacy目录识别所有导出和调用点Plan列出需要修改的文件制定迁移步骤Execute逐个文件修改导入路径更新调用方式Verify运行npm test和npm run build检查编译和测试结果Iterate如果测试失败分析错误原因修复后重新运行每轮结束后评估器独立判断“所有 auth 测试通过了吗构建成功了吗旧文件还有被引用吗”——只有三个条件全部满足才宣告完成。实践 2使用/loop实现 CI 监控与自动修复场景在提交 PR 后持续监控 CI 状态如果失败则尝试自动修复。/loop 2m 检查当前分支的 CI 状态如果失败了查看失败日志并尝试修复修好后提交这个循环的工作流每 2 分钟触发 → 读取 CI 状态 → 如果通过 → 报告成功 → 如果失败 → 读取错误日志 → 分析原因 → 修改代码 → 提交 → 等待下一轮验证注意/loop是时间驱动的不会自动停止。当你确认 CI 通过后需要手动取消取消 CI 监控的定时任务实践 3使用 Team 模式实现对抗验证场景复杂重构任务需要规划者、执行者、评审者三角分工。1. 创建 Team2. 生成 planner负责分析代码库、制定重构方案3. 生成 coder根据方案执行代码修改4. 生成 reviewer独立审查修改结果确保质量5. planner 和 reviewer 使用不同模型/指令形成对抗验证为什么对抗验证重要单一 Agent 自己检查自己的代码容易产生盲区——“我写的代码当然没问题”。规划者和评审者使用不同的视角和指令能发现执行者忽略的问题。实践 4使用 Skills 固化项目知识场景团队有一套编码规范和架构约定希望 AI 每次都能遵循。在skills/目录下创建skill.md将项目知识固化---name: project-conventionsdescription: 项目编码规范和架构约定---## 架构约定- 所有 API 调用必须经过 service 层controller 不直接调用 repository- 数据库查询必须使用参数绑定禁止字符串拼接 SQL- 错误处理遵循统一异常体系...## 命名规范- Service 类以 Service 结尾- Repository 类以 Repository 结尾...效果每次 AI 工作时自动加载这些约定不需要你在每次对话中重复说明。这正是 Loop Engineering 中技能要素的体现——避免每次冷启动重新推导。实践 5使用 MCP 连接器打通工具链场景让 AI 能读取 Jira issue、触发 Jenkins 构建、查询数据库。通过 MCP 协议接入第三方工具{ mcpServers: { jira: { command: mcp-jira, args: [--project, MYPROJ] }, jenkins: { command: mcp-jenkins, args: [--url, https://ci.example.com] } }}接入后在/goal循环中 AI 可以/goal all issues labeled bug in current sprint have a corresponding test that passes, or stop after 50 turnsAI 能直接读取 Jira issue 列表、编写测试、运行验证——整个 Discover → Plan → Execute → Verify → Iterate 闭环都在真实工具链中运行。实践 6使用 Rules 和 Memory 实现状态外置场景长期运行的重构任务需要跨会话保持上下文。Rules.codebuddy/rules定义硬性约束AI 每次启动都会读取- 所有数据库查询必须使用参数绑定- 修改 API 接口必须同步更新 OpenAPI 文档- 每个 PR 不超过 300 行变更Memory记录跨会话的偏好和上下文- 用户偏好使用 pytest 而非 unittest- 当前项目使用 Python 3.11类型注解必须完整- 用户上次重构到 step 3下次继续从 step 4 开始效果每次新的循环迭代从全新的上下文窗口开始时Rules 和 Memory 提供了状态外置——关键信息不依赖模型的记忆而是从持久化存储中读取。这正是 Loop Engineering 状态外置哲学的体现。七、最佳实践与注意事项写好/goal条件的 checklist终态可度量用测试通过“构建成功”文件数为 0这类客观指标避免代码质量提升这类主观判断验证方式明确指定用什么命令/工具来验证如pytest test/auth exits 0约束不可破坏明确过程中不能改的东西如不修改其他模块的测试兜底上限始终加or stop after N turns防止无限循环消耗 token条件不超过 4000 字符这是/goal的硬性限制避免常见陷阱陷阱说明解法验证责任不可转移无人值守的循环也是无人值守地犯错关键变更仍需人工审查Loop 不代替 Code Review理解债务加速累积代码库真实状态与开发者理解之间的鸿沟随循环加速扩大定期 review AI 的变更保持对代码库的理解认知投降风险开发者极易停止独立判断系统给什么就接受什么把 AI 当协作者而非权威质疑每个变更Token 成本约束循环运行消耗大量 token设置stop after N turns用小模型评估器条件模糊导致无效循环条件不够具体AI 反复尝试但无法满足条件要写成AI 自己的输出能证明的形式何时用哪种循环模式有明确终态的实质性工作迁移、重构、实现功能 → /goal持续性监控和巡检CI 状态、PR 审查、性能回归 → /loop跨会话的长期定期任务每日构建检查、每周代码审查汇总 → Automations需要多角色协作的复杂任务规划执行评审 → Team 模式 /goal八、总结Loop Engineering 的核心不是某个具体工具而是一种系统设计思维把 AI 当作循环中的执行者你设计循环的规则、验证标准和状态管理。CodeBuddy 提供了完整的工具链来实现这一范式/goal是 Loop 的心跳——条件驱动自动循环/loop是 Loop 的时钟——时间驱动定期触发Skills是 Loop 的知识——固化经验避免冷启动MCP是 Loop 的触手——连接真实工具链Team 模式是 Loop 的分身——对抗验证多角色协作Rules Memory是 Loop 的记忆——状态外置断点续跑从一问一答到设定目标、自动循环这是 AI 辅助开发从工具到伙伴的质变。而 Loop Engineering 的实践者正是这一质变的设计师。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
