30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度如果你还在手动给 AI 编程助手写 Prompt看着它一行行生成代码然后自己再手动检查、合并、提交那么你可能已经触及了当前 AI 辅助开发的天花板。这种“人肉调度”模式效率提升有限你依然是整个流程中最忙、最不可替代的环节。真正的质变发生在 AI 开始自己管理自己甚至自己“创造”新的 AI 工作流时。这听起来像科幻但“Loop Engineering”循环工程正在将这一场景变为现实。它不是一个具体的工具而是一套系统性的方法核心目标是将 AI Agent 从一次性的“对话伙伴”升级为能够自主发现任务、分配任务、执行并检查的“自动化工作流系统”。简单来说Loop Engineering 要解决的核心问题是如何让 AI 在无人值守、安全可控的前提下持续、自动地完成复杂任务这不仅仅是让 AI 写代码而是让 AI 去设计、执行并优化一个完整的代码生产与维护流程即“AI 构建 AI 工作流”。本文将深入拆解 Loop Engineering 的核心理念、核心组件并通过一个从零到一的实战示例展示如何构建一个能自动修复单元测试失败的 AI Agent 工作流。你将理解如何从“使用 AI”进阶到“运营 AI”实现开发效率的阶跃式提升。1. Loop Engineering从“手动驾驶”到“自动驾驶”的范式转移过去两年我们使用 AI 编程助手如 Cursor、Claude Code、GitHub Copilot的典型模式是线性的人类写 Prompt - AI 返回代码 - 人类阅读并评估 - 人类再写下一个 Prompt。这个循环中人类是永恒的“驾驶员”和“调度员”。这种模式存在几个明显的瓶颈上下文断裂每次对话都是独立的AI 没有长期记忆需要人类反复提供背景。任务调度 overhead人类需要不断判断“下一步做什么”并精确地用 Prompt 描述。难以规模化一个人类开发者同一时间只能有效引导一个或少数几个任务流无法并行处理大量琐碎或重复性任务。Loop Engineering 正是为了打破这些瓶颈而生。它的核心理念是将一次性的 Prompt 交互设计成一个可持续、自运行的“循环”Loop。在这个循环中AI Agent 能够感知Automations自动发现需要处理的任务如定时检查、事件触发。规划与分解Sub-agents Skills将复杂任务拆解为原子任务并依据既定规则Skills规划执行路径。安全执行Worktrees Plugins在隔离的环境中并行执行任务并通过连接器Plugins操作真实系统如 Git、CI/CD。检查与决策Sub-agents对执行结果进行验证并决定循环是继续、终止还是上报。这种转变的本质是从Prompt Engineering优化单次指令走向System Engineering设计自治系统。你的角色从一个“微操驾驶员”变成了一个“系统架构师”和“监督员”。2. 构建自动化工作流的五大核心组件一个健壮的、可投入生产的 AI 自动化工作流Loop离不开五个关键组件的协同。它们共同构成了 Loop 的“骨架”。2.1 Automations触发器循环的心跳触发器决定了 Loop 何时启动。它是整个工作流的开关。定时触发例如每天凌晨 2 点自动运行测试并生成报告每 10 分钟检查一次生产环境健康状态。事件触发这是更强大的模式。例如GitHub 上有新的 Pull Request 创建时Sentry 捕获到一个新的错误告警时CI/CD 流水线失败时收到特定格式的 Slack 消息时。在不同的工具中触发器可能有不同的名称如/loop命令、Scheduled Tasks、Cloud Routines 或 Webhooks但其功能本质一致让工作流在正确的时机自动运转起来无需人工干预。2.2 Worktrees工作树并行执行的隔离舱当多个 AI Agent 同时处理多个任务如同时修复多个 bug时最大的风险是文件冲突、上下文污染和状态覆盖。问题Agent A 在修改src/utils.jsAgent B 也在修改同一个文件最终提交会互相覆盖。解决方案利用git worktree机制。每个 Agent 可以在同一个代码仓库的不同“工作树”中独立工作每个工作树关联独立的分支。这为每个并行任务提供了物理隔离的沙箱环境是并行化 Agent 工作的基础设施保障。2.3 Skills技能库项目知识的沉淀我们习惯于将项目规范、代码风格、架构约束等写在冗长的 System Prompt 里。这导致 Prompt 臃肿、难以维护且无法在不同任务间复用。最佳实践将这些稳定的、项目特有的知识沉淀到独立的文档中例如SKILLS.md或AGENTS.md。作用AI Agent 在执行任务前或任务中可以读取这些技能文件来理解“在这个项目中应该怎么做”。这相当于将人类的项目经验编码成了 Agent 可执行的约束规则实现了知识的持久化和标准化。# SKILLS.md - 前端项目规范 ## 代码风格 - 使用 ESLint Prettier配置见 .eslintrc.js。 - React 组件使用函数式组件和 Hooks。 - 使用 import/export 语法禁止 require。 ## API 调用 - 所有 HTTP 请求必须通过 src/libs/api-client 封装的函数发起。 - 错误处理需使用统一的 handleApiError 工具。 ## 提交规范 - 提交前必须运行 npm run lint 和 npm test。 - 提交信息遵循 Conventional Commits 格式。2.4 Plugins / Connectors连接器通往真实世界的桥梁一个只会生成代码文本的 Agent 是“瘸腿”的。真正的价值在于让 Agent 能够操作真实世界的工具和系统。功能连接器让 Agent 能够调用外部 API 和服务。例如Git 操作克隆仓库、创建分支、提交代码、发起 Pull Request。项目管理从 Linear/Jira 读取任务更新任务状态。通信将执行结果或告警发送到 Slack/钉钉。监控从 Sentry/Datadog 读取错误日志。意义有了连接器AI 工作流才能从“本地实验”升级为“业务流程的一部分”实现端到端的自动化。2.5 Sub-agents子智能体职责分离与权力制衡让同一个 Agent 既提出方案、又实现代码、还自己评审就如同让运动员兼任裁判存在“自我确认偏差”的风险。角色拆分Proposer提议者分析问题提出解决方案和任务拆解。Implementer实现者在隔离的 Worktree 中根据方案编写代码。Reviewer评审者根据SKILLS.md和测试用例对 Implementer 的代码进行审查确保质量。价值这种分工不仅降低了上下文污染的风险更引入了“制造”与“检查”的分离机制是构建可靠、高质量自动化工作流的关键。3. 实战构建一个自动修复单元测试的 AI Agent 工作流现在我们将理论付诸实践构建一个具体的 Loop当 CI 中的单元测试失败时自动分析日志、定位问题、尝试修复并提交代码。3.1 环境准备与工具选型我们选择Claude Code作为 Agent 运行环境因为它对/loop命令和 Scheduled Tasks 有较好的支持。同时我们需要一个代码仓库和 CI 服务如 GitHub Actions。前置条件一个 GitHub 仓库包含一个存在单元测试的简单项目例如一个 Node.js 项目。Claude Code 已安装并配置了 GitHub 权限。在仓库中设置一个 GitHub Actions Workflow用于运行单元测试。3.2 第一步定义清晰的 SPEC规格说明书这是唯一必须由人类完成且最关键的一步。我们需要明确告诉 AI 工作流的目标、边界和完成标准。创建一个文件specs/auto_test_fixer.md# 自动测试修复循环规格说明书 (SPEC) ## 目标 当主分支main的 CI 单元测试失败时自动分析失败原因尝试修复代码并将修复提交到一个新的分支最后创建一个草稿 Pull Request。 ## 触发条件 - **事件**GitHub Actions 工作流 run-unit-tests 运行失败。 - **过滤**仅当失败原因是单元测试npm test而非构建或其他步骤时触发。 ## 输入 1. 失败的 GitHub Actions 运行日志 URL。 2. 关联的提交 SHA。 ## 输出 1. 一个新的 Git 分支命名格式为 fix/test-failure-日期-简短哈希。 2. 修复后的代码更改。 3. 一个指向新分支的草稿 Pull Request标题为 fix: auto-fix for test failure in commit-sha。 4. 一份修复摘要说明失败原因和采取的修复措施。 ## 验收标准成功条件 - [ ] 修复后的代码能够通过本地 npm test。 - [ ] 代码变更符合项目规范参考 SKILLS.md。 - [ ] 修复没有引入新的编译错误或 Lint 错误。 - [ ] 创建的 PR 是草稿状态并 相关负责人员。 ## 停止/熔断条件 - 尝试修复超过 3 次仍失败。 - 单次运行时间超过 10 分钟。 - 检测到修复涉及敏感文件如 package-lock.json, config/*.secret.js。3.3 第二步沉淀项目知识到 SKILLS.md创建或更新项目根目录的SKILLS.md文件内容如 2.3 节示例。这将是所有 Agent 的“行动宪法”。3.4 第三步编写核心 Loop 脚本我们在项目根目录创建一个 Python 脚本作为 Loop 的核心逻辑。这个脚本将被 Claude Code 的 Scheduled Task 调用。文件scripts/auto_fix_loop.py#!/usr/bin/env python3 自动测试修复循环的核心脚本。 由 GitHub Actions 失败事件触发或由定时任务调度。 import os import sys import subprocess import json from datetime import datetime import requests from typing import Dict, Optional # 假设我们从环境变量获取触发信息 GITHUB_RUN_ID os.getenv(GITHUB_RUN_ID) REPO os.getenv(GITHUB_REPOSITORY) # ‘owner/repo’ COMMIT_SHA os.getenv(GITHUB_SHA) def fetch_failure_logs(run_id: str) - Optional[str]: 从 GitHub API 获取失败的测试日志 # 此处简化实际需使用 GitHub Token 调用 API # 返回提取出的错误摘要 print(f[INFO] Fetching logs for run {run_id}) # 模拟返回一个错误信息 return “Error: AssertionError in test_user_login: expected ‘Welcome, Alice’ but got ‘Welcome, Bob’” def analyze_error(log_summary: str) - Dict: 分析错误日志判断问题类型和位置 # 这里可以集成一个 LLM 调用如 OpenAI/Claude API进行智能分析 # 为简化我们进行规则匹配 if “AssertionError” in log_summary and “test_user_login” in log_summary: return { “file”: “src/services/auth.test.js”, “test_name”: “test_user_login”, “error_type”: “AssertionError”, “hypothesis”: “用户登录后的欢迎语逻辑可能出错或测试期望值需要更新。” } return {“error_type”: “Unknown”} def create_fix_branch() - str: 创建一个新的修复分支 branch_name f“fix/test-failure-{datetime.now().strftime(‘%Y%m%d’)}-{COMMIT_SHA[:7]}” subprocess.run([“git”, “checkout”, “-b”, branch_name], checkTrue) print(f“[INFO] Created and switched to branch: {branch_name}”) return branch_name def run_agent_fix(error_info: Dict): 调用 AI Agent 来执行修复 # 这里是核心构造一个给 Claude Code 的 Prompt启动一个子进程或调用其 API # 我们将错误分析和项目技能文件作为上下文提供 prompt f“““ 项目上下文请阅读项目根目录下的 SKILLS.md 文件以了解规范。 任务修复单元测试失败。 失败详情 - 文件{error_info.get(‘file’)} - 测试{error_info.get(‘test_name’)} - 错误{error_info.get(‘error_type’)} - 假设{error_info.get(‘hypothesis’)} 请执行以下步骤 1. 定位并分析失败的测试代码。 2. 根据 SKILLS.md 的规范编写修复代码。 3. 运行 npm test 确保修复通过。 4. 如果修复成功提交更改提交信息格式为fix(test): auto-fix for {error_info.get(‘test_name’)}。 ”“” # 在实际实现中这里会调用 Claude Code 的 API 或使用其 SDK # 例如subprocess.run([“claude”, “–prompt”, prompt, “–command”, “run-fix”]) print(f“[INFO] Instructing AI Agent with prompt: {prompt[:200]}...”) # 模拟 Agent 执行成功 return True def create_draft_pr(branch_name: str, error_info: Dict): 创建草稿 Pull Request title f“fix: auto-fix for test failure in {COMMIT_SHA[:7]}” body f“““ ## 自动修复摘要 **触发的 CI 运行:** {GITHUB_RUN_ID} **失败测试:** {error_info.get(‘test_name’)} **问题分析:** {error_info.get(‘hypothesis’)} 此 PR 由自动测试修复循环创建请人工审查。 ”“” print(f“[INFO] Would create draft PR: {title}”) print(f“[INFO] PR Body: {body}”) # 实际应调用 gh pr create –draft –title “{title}” –body “{body}” 或 GitHub API def main(): print(“[INFO] Starting Auto-Test-Fix Loop...”) # 1. 获取失败信息 log_summary fetch_failure_logs(GITHUB_RUN_ID) if not log_summary: print(“[ERROR] Could not fetch failure logs. Exiting.”) sys.exit(1) # 2. 分析错误 error_info analyze_error(log_summary) if error_info.get(“error_type”) “Unknown”: print(“[WARN] Error type unknown, agent may not handle correctly.”) # 3. 创建隔离分支 fix_branch create_fix_branch() # 4. 调用 Agent 修复 success run_agent_fix(error_info) if not success: print(“[ERROR] AI Agent failed to fix the issue.”) sys.exit(1) # 5. 创建草稿 PR create_draft_pr(fix_branch, error_info) print(“[SUCCESS] Auto-fix loop completed. Draft PR created.”) if __name__ “__main__”: main()3.5 第四步配置自动化触发器我们需要设置两种触发器1. 事件触发器GitHub Actions Webhook在 GitHub 仓库的 Settings - Webhooks 中添加一个指向你运行 Claude Code 或调度服务的 Webhook监听workflow_run事件且仅当结论为failure时触发。Webhook 负载将包含run_id等信息可以触发上述 Python 脚本。2. 在 Claude Code 中配置 Scheduled Task备用如果希望定期检查可以在 Claude Code 中设置一个定时任务。# 在 Claude Code 中你可以配置一个 Scheduled Task 任务名称: Daily Test Health Check 命令: cd /path/to/your/repo python3 scripts/auto_fix_loop.py –mode check 时间表: 0 2 * * * (每天凌晨2点)3.6 第五步运行与验证模拟失败故意在项目中引入一个测试错误并推送到 main 分支触发 CI 失败。观察 LoopWebhook 会触发你的脚本。观察日志看脚本是否成功执行了分析、创建分支、调用 Agent、提交修复、创建 PR 等一系列操作。验证结果检查是否创建了一个新的分支和草稿 PR。查看 PR 中的代码更改是否符合SKILLS.md规范并确认该修复是否真的能让测试通过。4. 核心工作流程与数据流转为了让整个 Loop 的运作更直观我们可以梳理其核心的工作流程与数据流转路径。下图清晰地展示了从事件触发到最终产出的人工审核入口整个过程中各组件如何协同[GitHub Actions 测试失败] | v [Webhook 事件触发] | v [Automation 触发器启动 Loop] | v [创建隔离的 Git Worktree] | v [主 Agent 读取 SPEC 和 SKILLS.md] | v / \ / \ / \ [Sub-agent: 分析错误] [通过 Plugin 获取日志] | | v v [Sub-agent: 规划修复] | v [Sub-agent: 执行修复] - [在 Worktree 中修改代码] | v [Sub-agent: 运行测试验证] | v [通过 Plugin 提交代码到新分支] | v [通过 Plugin 创建草稿 PR] | v [通知人工审核 (Slack/邮件)]流程解读触发CI 失败事件通过 Webhook 激活 Automation 组件。隔离立即创建一个独立的 Git Worktree确保此次修复任务不会干扰主分支或其他并行任务。认知主协调 Agent 或 Proposer Sub-agent 读取SPEC明确目标并加载SKILLS.md掌握项目规范。诊断一个 Sub-agent或主 Agent通过 GitHub Connector (Plugin) 获取详细的失败日志并分析根本原因。规划与执行Proposer Sub-agent 制定修复方案Implementer Sub-agent 在隔离的工作树中执行代码修改。验证Reviewer Sub-agent 或 Implementer 自身运行测试确保修复有效且符合规范。交付通过 Git Plugin 将更改提交到新分支并通过 GitHub Plugin 创建草稿 PR。通知通过 Slack/邮件等 Connector 通知开发者进行最终人工复核。这是至关重要的安全边界。5. 关键风险、安全清单与最佳实践构建自动化的 AI 工作流力量强大但风险同样显著。在投入生产前必须设立严格的安全边界。5.1 Loop 不能替你承担的三类责任最终验证责任Agent 说“完成”绝不等于任务真的完成。尤其是涉及业务逻辑、安全或数据变更时必须有人工复核的强制环节如草稿 PR。系统理解责任Loop 运行得越快你与系统真实状态的距离可能越远。你必须通过清晰的日志、变更摘要和审计记录保持对系统的理解和掌控力避免成为“盲目的管理者”。核心判断责任Loop 是效率放大器而非思考替代品。将目标定义、权限划分、成本控制和验收标准这些需要人类判断的环节自动化是极其危险的。5.2 上线前安全检查清单在部署任何 Loop 到生产环境前请务必核对以下清单检查项说明示例/方法明确的停止条件循环必须有清晰的结束条件避免无限循环烧钱。设置最大运行次数如3次、超时时间如10分钟、或目标达成条件测试通过。Token/成本预算为单次运行设置 Token 或时间预算。在调用 LLM API 时设置max_tokens和timeout。根据任务复杂度选择模型如修复用 Claude Haiku分析用 Sonnet。最小权限原则Agent 只能访问必要的工具和文件。通过插件系统配置白名单。明确拒绝rm -rf、:wq等危险命令禁止访问*.env,config/secret.*等敏感文件。隔离写入所有写操作必须在隔离分支或沙箱中。使用git worktree。代码只能提交到特性分支并创建草稿PR严禁直接推送至main或production分支。审计日志完整记录每次循环的输入、决策、输出和错误。将每次运行的关键信息触发事件、Agent 决策、代码差异写入数据库或日志文件便于追溯。人工复核入口必须有一个强制的人工干预点。所有代码变更必须通过草稿 PR所有数据库写入操作必须进入待审批队列。熔断机制监测异常及时自动停止。监控连续失败次数、Token 消耗异常增长、或输出重复无意义内容触发熔断并告警。最危险的反模式为了追求“全自动”而全局跳过所有权限确认例如在脚本中默认对所有提示回答“yes”。这等同于拆掉了系统的刹车。权限是安全边界不是开关。5.3 四条核心落地原则目标可判定Loop 的成败必须能由客观标准测试用例、Lint 规则、类型检查、验证脚本自动判定而不是依赖 Agent 的主观汇报。权限按需配置给“自动写日报”的 Loop 和“自动修复生产环境 Bug”的 Loop 分配相同的权限是灾难性的。必须根据任务风险等级精细化配置权限。成本显性化每次循环触发都是一次完整的 LLM 会话会产生成本。必须像管理云资源一样管理 Loop 的成本设置预算和警报。输出可审查所有的产出代码、文档、消息都必须留有审查入口如草稿 PR、隔离分支、变更摘要、操作日志确保整个过程可追溯、可回滚。6. 常见问题与排查思路在实际搭建和运行 Loop 时你可能会遇到以下典型问题问题现象可能原因排查思路解决方案Loop 未被触发1. Webhook 配置错误或未送达。2. 事件过滤条件太严格。3. 调度服务如 Cron未正常运行。1. 检查 GitHub Webhook 的交付历史查看 payload 和响应。2. 打印接收到的初始事件数据验证过滤逻辑。3. 检查服务器日志确认调度任务是否执行。1. 验证 Webhook URL 和密钥。2. 简化初始过滤条件先确保能触发。3. 检查 Cron 服务状态和脚本执行权限。Agent 行为不符合预期1.SKILLS.md文件未被正确读取或格式错误。2. 提供给 Agent 的上下文Prompt不完整或模糊。3. 模型能力不足或温度temperature参数过高。1. 在 Agent 执行前打印它实际读取到的技能文件内容。2. 审查构造的 Prompt确保 SPEC 和错误信息清晰传递。3. 尝试更强大的模型如 Claude 3.5 Sonnet或降低 temperature 以获得更确定性的输出。1. 确保技能文件路径正确内容为清晰 Markdown。2. 优化 Prompt 结构采用“角色-任务-上下文-输出格式”模板。3. 更换模型或调整参数并对关键任务进行少量样本测试。多个 Agent 任务间文件冲突未使用git worktree或工作目录隔离不彻底。检查不同任务是否在同一个 Git 工作目录下操作了相同文件。强制使用git worktree。在每个 Loop 或子任务开始时创建独立的工作树和分支。循环无限运行或成本失控1. 停止条件定义模糊或无法达成。2. 未设置 Token 或时间限制。1. 检查循环逻辑确认成功/失败判断条件是否可能永远为假。2. 查看 LLM API 调用记录检查单次消耗是否过大。1. 在循环逻辑中加入强制退出机制如最多重试 3 次。2. 在调用 LLM API 时务必设置max_tokens和request_timeout参数。创建的 PR 或代码质量差1. Reviewer Sub-agent 缺失或失效。2.SKILLS.md规范不具体。3. 缺少自动化测试验证环节。1. 检查是否配置了独立的代码评审步骤。2. 审查 Agent 提交的代码看违反了哪条规范。3. 确认修复后是否自动运行了测试套件。1. 引入独立的 Reviewer Agent其 Prompt 专注于代码质量和规范检查。2. 将SKILLS.md细化包含具体的代码示例和反例。3. 在 Loop 中必须加入运行npm test或pytest的步骤并将测试通过作为成功条件。7. 总结从“使用AI”到“运营AI”的关键一跃Loop Engineering 代表的不仅仅是一种技术实践更是一种思维模式的升级。它要求我们从关注单次 Prompt 的“术”转向设计可持续自治系统的“道”。通过将Automations、Worktrees、Skills、Plugins 和 Sub-agents这五大组件有机组合我们能够构建出真正理解上下文、安全可控、并能够嵌入真实开发流程的 AI 智能体工作流。对于开发者而言最大的收益并非完全取代人工而是将人类从重复、琐碎、模式化的任务中解放出来专注于更高层次的架构设计、复杂问题解决和最终的质量把关。你可以从今天最重复的一个任务开始——无论是自动生成日报、整理代码库还是初步的 PR 评审——为其编写一个清晰的 SPEC然后用一个最简单的脚本将其自动化。一旦这个最小闭环跑通你就可以像搭积木一样逐步引入更复杂的组件。记住强大的工具也意味着更大的责任。在享受自动化带来的效率提升时务必坚守目标可判定、权限按需配、成本显性化、输出可审查这四条原则为你的 AI 工作流装上可靠的“方向盘”和“刹车”。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度