30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度如果你还在手动给AI写提示词每次让它改个bug、写个函数然后自己检查、再写下一个提示词那么你很可能正在错过AI编程真正的效率革命。这种“人肉调度”模式看似提升了单点效率实则让你成了整个流程中最忙、最不可替代的“瓶颈”。AI Agent越强大你手动Prompt的瓶颈就越明显。真正的转变是从“使用AI”到“运营AI”。这背后的核心方法论就是Loop Engineering循环工程。它不是一个新工具而是一套系统性的设计思想让AI Agent能够在一套明确的边界内自动发现任务、分配任务、执行检查并决定下一步形成一个可持续运行的自动化工作流。简单说就是让AI自己写代码甚至自己构建和优化工作流实现“AI造AI”的自动化循环。这篇文章要解决的正是每个尝试将AI融入开发流程的工程师都会遇到的终极困惑如果我不想一直守在Agent旁边如何让它安全、可控、可验证地持续工作我们将深入拆解Loop Engineering的核心理念、五大核心组件并通过一个从零到一的完整示例展示如何构建一个能自动修复单元测试失败的AI Agent工作流。读完本文你将掌握从手动Prompt到自动化工作流的设计方法并能够亲手搭建你的第一个“自循环”AI工程师。1. Loop Engineering从“司机”到“系统架构师”的思维转变过去两年我们使用AI编程Agent的典型模式是线性的写Prompt - Agent返回结果 - 人工阅读审核 - 再写下一个Prompt。在这个循环里人类是那个必须时刻握着方向盘的“司机”Agent只是听令行事的“乘客”。这种模式的效率天花板非常低因为它无法规模化也无法利用Agent的持续学习和迭代能力。Loop Engineering的本质是角色转换。你不再做“司机”而是成为“交通系统的架构师”。你一次性设计好信号灯规则、道路网络工作流和车辆行为规范Skills然后让多辆“AI车辆”Sub-agents在这个系统里自主、并行、安全地运行。你的工作变成了监督系统状态、处理异常和优化规则。这种转变解决了三个核心痛点解放人力从重复的Prompt编写和结果检查中脱身专注于更高层次的设计和决策。提升可靠性通过标准化的工作流、隔离的执行环境和明确的验收标准减少人为疏忽带来的错误。实现规模化一个设计良好的Loop可以7x24小时运行处理海量重复性任务如代码评审、测试修复、日志监控等。理解Loop Engineering首先要抛弃“AI工具”的旧观念建立起“AI系统”的新认知。2. 核心组件拆解构建自动化工作流的五大基石根据Addy Osmani在《Loop Engineering》中的阐述一个健壮、可持续的AI自动化循环需要五个核心组件原语和一个外部记忆系统。缺失任何一环循环都可能“泄漏”——失控、出错或停滞。2.1 Automations循环的“心跳”与触发器这是Loop的启动层决定了“什么时候该让Agent动起来”。它不再是手动输入/命令而是预设的规则。定时触发例如每天凌晨2点运行全量测试并生成报告、每10分钟检查一次生产环境健康状态。事件触发例如GitHub上有新的Pull Request创建、Sentry捕获到一个新的Error事件、CI/CD流水线失败、收到特定格式的Slack消息。在不同的工具中它可能被叫作/loop命令、Scheduled Tasks、Cloud Routines或Webhooks。其核心是将人工决策“现在该做什么”转化为系统可识别的事件。2.2 Worktrees并行执行的“隔离沙盒”当多个Agent同时处理不同任务时最怕的就是上下文污染和文件冲突。想象一下一个Agent在修复bug另一个在重构代码它们同时修改src/main.js会是什么结果Git Worktree是这个问题的优雅解决方案。它允许你在同一个Git仓库中创建多个独立的工作目录每个目录关联不同的分支。这样每个Agent都可以在完全隔离的沙盒中工作互不干扰。价值实现真正的并行化。你可以让Agent A在worktree/fix-bug-101分支上修复Bug同时让Agent B在worktree/refactor-auth分支上进行重构最后再人工或自动合并。2.3 Skills项目的“持久化记忆”与规范库你是否曾把一长串项目规范如“使用ESLint Airbnb规则”、“API调用必须通过/api模块”、“提交前必须跑通单元测试”塞进System Prompt这会导致Prompt臃肿且难以复用。Skills机制将这些稳定的、项目特定的知识从易失的对话上下文中剥离出来沉淀到如SKILLS.md、AGENTS.md或项目知识库文件中。工作方式在Loop启动时或Agent执行特定任务前自动将相关Skills文件的内容作为上下文注入。这确保了所有Agent都遵循同一套项目规范降低了沟通成本提高了输出的一致性。2.4 Plugins / Connectors通往真实世界的“桥梁”一个只会写代码却无法操作版本库、不能读取issue、不能发送通知的Agent只是一个高级记事本。Plugins插件或Connectors连接器是Agent与现有工具链如GitHub, GitLab, Jira, Slack, Sentry, 数据库交互的桥梁。作用让Loop从本地玩具升级为融入团队工作流的生产力设施。例如一个完整的“PR自动评审-修复”Loop需要通过GitHub Connector读取PR差异 - 在独立Worktree中创建修复分支 - 执行修复 - 运行测试 - 通过Connector将修复结果写回PR评论或创建新的PR。标准Model Context Protocol (MCP) 正在成为连接Agent与工具的事实标准它定义了统一的资源访问接口。2.5 Sub-agents职责分离的“角色扮演”让一个Agent既当运动员写代码又当裁判员评审代码它很容易陷入“自我确认偏差”忽略自己代码中的问题。Sub-agents模式通过引入角色分工来解决这个问题Proposer/Planner分析任务制定解决方案和拆分子任务。Implementer/Coder在隔离的Worktree中具体执行编码任务。Reviewer/Verifier根据Skills、测试用例和代码规范对Implementer的输出进行审查。优势实现了制造与检查的分离降低了单点风险更贴近人类团队的协作模式尤其适合复杂任务。3. 环境准备构建你的第一个AI自动化工作流在开始构建之前我们需要搭建一个实验环境。本文将使用Claude Code或Cursor这类集成了强大Agent能力的IDE作为演示平台因为它们对Loop Engineering的支持相对友好。同时我们会结合简单的脚本和Git来模拟一个完整的流程。核心工具栈IDE/Agent平台Claude Code (推荐) 或 Cursor。确保你有权限使用其高级Agent和自动化功能。版本控制Git (版本 2.15以支持Worktree)。项目语言本文示例使用Node.js/JavaScript但原理通用。包管理器npm 或 yarn。测试框架Jest (用于创建可验证的任务)。环境检查打开你的终端运行以下命令确保基础环境就绪# 检查Git版本及Worktree支持 git --version git worktree --help # 确认有此命令 # 检查Node.js环境 node --version npm --version # 创建一个用于实验的目录 mkdir ai-loop-engineering-demo cd ai-loop-engineering-demo git init我们的目标构建一个能自动检测并修复单元测试失败的Loop。这个任务边界清晰、结果可验证测试通过与否是入门Loop Engineering的绝佳起点。4. 从0到1构建自动修复测试的AI Loop让我们遵循“从薄到厚”的原则一步步搭建这个Loop。4.1 第一步定义清晰的SPEC规格说明书这是唯一必须由人类完成的一步它定义了“完成”的状态。在项目根目录创建SPEC.md。!-- SPEC.md -- # 自动测试修复循环规格说明书 ## 目标 创建一个自动化工作流当项目的单元测试失败时能自动分析失败原因尝试修复代码并验证修复是否成功。 ## 触发条件 1. 主分支(main)上的CI测试失败通过GitHub Actions webhook模拟。 2. 或本地运行测试命令npm test返回非零退出码。 ## 输入 - 失败的测试输出日志。 - 关联的源代码文件。 ## 输出 - 修复后的代码提交到以fix/test-fail-timestamp命名的分支。 - 修复结果的摘要报告包括失败原因、修改了哪些文件、修复后的测试结果。 ## 验收标准 1. **功能正确性**修复后的代码必须通过所有之前失败的测试用例。 2. **代码质量**修复不得引入新的ESLint错误或警告遵循项目规则。 3. **最小改动**修复应尽可能精准避免不必要的代码重构。 4. **隔离性**修复过程必须在独立的Git worktree中进行不影响主工作区。 ## 停止条件 1. 成功测试通过代码符合规范创建修复分支和报告。 2. 失败循环终止 - 连续3次修复尝试后测试仍然失败。 - 单次运行时间超过10分钟。 - Agent尝试执行危险命令如rm -rf /, :(){ :|: };:。4.2 第二步沉淀项目Skills创建SKILLS.md文件这是Agent的“项目手册”。!-- SKILLS.md -- # 项目开发规范 (Skills for AI Agent) ## 代码风格 - **语言**: JavaScript (ES6) - **缩进**: 2个空格 - **字符串**: 优先使用单引号() - **分号**: 不使用分号 (遵循 StandardJS风格) - **命名**: 变量/函数使用camelCase类使用PascalCase ## 测试规范 - **框架**: Jest - **文件位置**: 测试文件与源文件同名后缀为.test.js并存放在__tests__目录或同级。 - **断言**: 使用Jest提供的expect()语法。 - **覆盖率**: 非强制但新增代码应有对应测试。 ## 提交规范 - **分支命名**: fix/test-fail-YYYYMMDD-HHMMSS - **提交信息**: 遵循Conventional Commits例如fix(calculator): correct division by zero handling ## 安全与权限边界 - **严禁操作**: - 删除任何非由本循环创建的文件或目录。 - 修改package.json中的核心依赖版本。 - 向main分支直接推送代码。 - 执行任何网络请求除非明确授权。 - **必须操作**: - 所有代码修改必须在独立的git worktree中进行。 - 任何修复尝试前必须先运行npm test确认失败状态。 - 修复后必须运行npm run lint检查代码风格。4.3 第三步创建最小可运行Loop骨架我们用一个Bash脚本run_test_fix_loop.sh来模拟Loop的第一次触发。这个脚本封装了核心逻辑。#!/bin/bash # run_test_fix_loop.sh - 测试修复循环的最小骨架 set -e # 遇到错误即退出 LOG_FILEloop_$(date %Y%m%d_%H%M%S).log echo 启动测试修复循环 $(date) | tee -a $LOG_FILE # 1. 检查触发条件当前测试是否失败 echo [1/5] 检查测试状态... | tee -a $LOG_FILE if npm test 21 | tee -a $LOG_FILE; then echo 所有测试通过无需修复。循环结束。 | tee -a $LOG_FILE exit 0 else TEST_FAILEDtrue echo 检测到测试失败启动修复流程。 | tee -a $LOG_FILE fi # 2. 为本次修复创建独立的Git Worktree BRANCH_NAMEfix/test-fail-$(date %Y%m%d-%H%M%S) WORKTREE_PATH../worktree_${BRANCH_NAME} echo [2/5] 创建独立工作区: $WORKTREE_PATH (分支: $BRANCH_NAME)... | tee -a $LOG_FILE git worktree add -b $BRANCH_NAME $WORKTREE_PATH # 3. 进入工作区准备上下文 cd $WORKTREE_PATH cp ../SKILLS.md ./ # 注意这里简化了实际应将失败日志、相关代码文件传递给Agent echo [3/5] 上下文准备完毕。即将调用AI Agent进行修复... | tee -a $LOG_FILE # 此处是调用AI Agent的核心位置。我们用一个模拟的“思考”过程代替。 # 真实场景下这里会调用Claude Code API或Cursor的Agent并附上SPEC、SKILLS和失败日志。 echo 模拟AI Agent正在分析测试失败日志和代码... | tee -a $LOG_FILE sleep 2 echo 模拟AI Agent尝试修改了 src/calculator.js 中的 divide 函数... | tee -a $LOG_FILE # 假设Agent“修复”了代码我们模拟一个修改 cat src/calculator.js EOF // 模拟修复后的代码 function divide(a, b) { if (b 0) { throw new Error(Division by zero is not allowed.); } return a / b; } module.exports { divide }; EOF # 4. 验证修复结果 echo [4/5] 验证修复结果... | tee -a $LOG_FILE if npm test 21 | tee -a $LOG_FILE; then echo ✅ 测试通过修复成功。 | tee -a $LOG_FILE npm run lint 21 | tee -a $LOG_FILE echo ✅ 代码风格检查通过。 | tee -a $LOG_FILE # 提交更改 git add . git commit -m fix(calculator): handle division by zero error | tee -a $LOG_FILE echo [5/5] 修复已提交到分支: $BRANCH_NAME | tee -a $LOG_FILE RESULTSUCCESS else echo ❌ 修复后测试仍然失败。 | tee -a $LOG_FILE RESULTFAILURE fi # 5. 清理与报告 cd .. echo 循环结束结果: $RESULT | tee -a $LOG_FILE # 保留worktree供审查实际可根据策略删除或保留 # git worktree remove ../worktree_${BRANCH_NAME} # 此处可添加Connector逻辑将结果发送到Slack、创建PR等。 # echo 模拟将结果摘要发送至团队频道... | tee -a $LOG_FILE给脚本添加执行权限chmod x run_test_fix_loop.sh。这个脚本已经包含了Automation手动/定时触发、Worktree、Skills加载和验证的基本框架。4.4 第四步引入Sub-agents分工概念集成在真实的Claude Code或Cursor中你可以通过设计不同的Prompt角色来模拟Sub-agents。例如在调用AI时通过System Prompt明确其角色对于 Implementer Agent:你是一个资深JavaScript工程师Implementer。你的任务是修复以下单元测试失败问题。 请严格遵守项目规范SKILLS.md在独立的工作目录中进行修改。 你只负责编写和修改代码不要自行运行测试或评审。 修改完成后请输出修改后的完整文件内容。对于 Reviewer Agent:你是一个严格的代码评审员Reviewer。你的任务是评审Implementer提交的代码。 请依据项目规范SKILLS.md和以下测试失败日志检查代码 1. 是否解决了测试失败的根本原因 2. 是否引入了新的语法错误或风格问题 3. 是否符合最小改动原则 请给出明确的评审结论通过APPROVE或拒绝REQUEST_CHANGES并说明理由。在你的主控脚本或Loop配置中可以顺序调用这两个Agent将Implementer的输出作为Reviewer的输入实现职责分离。4.5 第五步连接真实世界Connectors集成最后让这个Loop融入开发工作流。我们可以用GitHub Actions来模拟一个事件触发的Automation。创建.github/workflows/test-fix-loop.yml:name: AI Test Fix Loop on: push: branches: [ main ] workflow_dispatch: # 允许手动触发 jobs: test-and-fix: runs-on: ubuntu-latest if: failure() # 关键只有测试job失败时才运行 steps: - uses: actions/checkoutv4 with: fetch-depth: 0 # 获取所有历史便于worktree操作 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 18 - name: Install dependencies run: npm ci - name: Run Tests (Expected to fail) run: npm test continue-on-error: true # 测试失败是此工作流的触发条件 - name: Trigger AI Fix Loop if: failure() # 如果上一步测试失败 run: | # 这里可以替换为调用你部署的AI Loop服务 # 例如: curl -X POST https://your-ai-loop-service/trigger \ # -d {repo: ${{ github.repository }}, commit: ${{ github.sha }}} echo 模拟触发AI修复循环。在实际场景中此处会调用一个托管服务该服务执行 run_test_fix_loop.sh 的逻辑。 echo 失败日志和代码上下文已被捕获。 - name: Create Issue on Failure if: failure() uses: actions/github-scriptv7 with: script: | github.rest.issues.create({ owner: context.repo.owner, repo: context.repo.repo, title: CI测试失败AI修复循环未成功, body: 主分支提交 ${context.sha} 的测试失败AI修复循环未能自动解决。请人工介入。\n\n 工作流运行链接: ${context.runId}, labels: [ci-failure, needs-triage] });这个工作流实现了当main分支的测试失败时自动触发后续处理这里是模拟触发AI Loop并在AI Loop也处理失败时自动创建Issue通知人类。这就是一个完整的事件驱动Automation。5. 运行与验证观察你的AI工程师如何工作准备一个失败场景在项目中故意引入一个bug导致测试失败。例如修改src/calculator.js中的divide函数移除除零检查。首次手动触发在终端运行./run_test_fix_loop.sh。观察日志输出看它是否成功创建worktree、模拟“修复”代码、运行测试并通过。验证Git状态运行git branch -a你应该能看到新创建的修复分支。使用git log --oneline branch-name查看提交。模拟CI集成将代码推送到GitHub仓库的main分支触发上述GitHub Actions工作流。观察Actions的执行日志理解事件触发的流程。成功标志脚本日志显示所有步骤完成最终结果为SUCCESS。新的Git分支被创建并包含有效的修复提交。如果集成CIGitHub Actions工作流被正确触发并执行了定义的后继步骤。6. 常见问题与排查思路在构建和运行Loop时你可能会遇到以下典型问题问题现象可能原因排查方式解决方案Loop脚本执行失败提示Git命令错误1. Git版本过低。2. 未在Git仓库中运行。3. 工作目录权限问题。1.git --version检查版本。2.git status确认在仓库内。3. 检查目录读写权限。1. 升级Git。2. 在正确的仓库根目录运行。3. 调整权限或更换目录。AI Agent“修复”后测试仍然失败1. Agent未获得正确的失败上下文。2. Skills定义不清晰Agent理解有误。3. 任务本身超出当前Agent能力。1. 检查传递给Agent的日志和代码片段是否完整。2. 审查SKILLS.md是否明确无歧义。3. 人工检查失败原因是否过于复杂。1. 优化上下文传递机制。2. 细化、拆分Skills。3. 对复杂任务需引入更复杂的Planner Sub-agent或人工干预。多个并行Loop导致文件冲突未正确使用Git Worktree进行隔离。检查Loop脚本是否每次都在唯一路径创建worktree。确保每个Loop实例使用带有唯一标识符如时间戳、任务ID的独立worktree路径。运行成本Token消耗过高1. 循环触发过于频繁。2. 每次调用注入的上下文如Skills、代码过大。3. 使用了不必要的大模型。1. 审查Automation触发频率。2. 统计每次API调用的Token数量。3. 评估任务复杂度。1. 调整触发条件如去抖debounce。2. 压缩、摘要或分块加载上下文。3. 为简单任务使用小型/廉价模型。Loop陷入无限循环或重复操作缺少明确的停止条件或停止条件判断逻辑有误。检查Loop逻辑中关于“成功”、“失败”、“最大重试次数”的判断分支。在SPEC中明确定义停止条件并在代码中实现强制的熔断机制如最大运行时间、最大重试次数。7. 最佳实践与工程化建议将Loop Engineering投入生产环境需要遵循以下原则以确保其可靠性、安全性和可维护性。目标必须可判定Verifiable GoalsLoop的终极目标必须是机器可明确判断的。优先选择那些有二进制结果通过/失败或可量化指标的任务如“测试通过率100%”、“lint错误数为0”、“编译成功”。避免“代码质量提升”、“优化性能”这类模糊目标。权限必须按任务配置Least Privilege为不同的Loop配置不同的权限白名单。一个用于自动写日报的Agent绝对不应该有git push --force的权限。在调用AI服务时利用其工具调用Tool Calling的权限控制系统明确允许和禁止的命令列表。成本必须显式预算Explicit Budgeting将Loop视为有成本的服务。为每个Loop设置预算Token预算单次运行最大Token消耗。时间预算单次运行最长时间。财务预算每日/每周最大API调用费用。 监控这些指标并设置告警。输出必须可审查Auditable Output任何由Loop产生的变更都必须留有“审计线索”。代码变更始终提交到特性分支或草稿PR绝不允许直接推送至受保护分支如main,master。运行日志所有Loop执行过程、AI的思考过程、工具调用记录都应持久化到日志系统。摘要报告每次循环结束生成一份人类可读的摘要说明做了什么、为什么做、结果如何。设计必须渐进式Progressive Enhancement不要试图一开始就构建一个全自动的复杂系统。遵循“爬-走-跑”的节奏爬手动触发输出建议人工审核后执行。走自动触发在隔离环境执行结果提交为草稿人工合并。跑全自动闭环仅在异常时通知人类。 每增加一个“自动化度”都必须经过充分测试和验证。人是最终的责任主体Human in the LoopLoop Engineering不是“设置好就忘记”的魔法。它的目标是放大人的能力而非取代人的判断。始终在关键节点如生产部署、数据库变更、核心逻辑修改保留人工审批的入口。定期审查Loop的产出和决策防止“认知投降”——因为自动化而放弃思考。8. 总结从Prompt工程师到Loop架构师Loop Engineering标志着一个关键的范式转移我们与AI协作的单元从一次性的、离散的“对话”Prompt升级为持续性的、系统化的“工作流”Loop。这要求开发者从“Prompt工程师”转变为“Loop架构师”。这种转变的核心技能不再是雕琢单句提示词而是系统设计能力如何定义清晰边界、如何拆解原子任务、如何设计安全隔离、如何建立验证反馈机制。本文通过一个具体的“自动测试修复”案例展示了构建这样一个Loop所需的完整路径从SPEC设计、Skills沉淀、到利用Worktree和Sub-agents实现隔离与分工最后通过Connectors融入CI/CD流水线。最危险的误区是为了追求“全自动”而放弃控制权。最强的Loop恰恰是那些将人类智慧置于系统关键控制点的设计——人类定义规则、设定边界、处理异常而AI负责在规则内高效、不知疲倦地执行。你的第一个Loop不必复杂可以从“每天自动整理我未提交的代码变更并生成摘要”这样的小任务开始。重要的是迈出第一步体验从“驾驶座”退到“指挥塔”的视角变化。当你成功运行起第一个Loop看着AI在你设计的轨道上自动解决问题时你会真正理解AI时代的工程师价值不在于写更多的代码而在于设计更聪明的系统让代码无论是谁写的能够自动、可靠地运行。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度