从Prompt Engineering到Loop Engineering：构建AI自动化工作流的核心组件与实践

🚀 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。这个循环中，人类是永恒的“驾驶员”和“调度员”。

这种模式存在几个明显的瓶颈：

1. 上下文断裂：每次对话都是独立的，AI 没有长期记忆，需要人类反复提供背景。
2. 任务调度 overhead：人类需要不断判断“下一步做什么”，并精确地用 Prompt 描述。
3. 难以规模化：一个人类开发者同一时间只能有效引导一个或少数几个任务流，无法并行处理大量琐碎或重复性任务。

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.js，Agent 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）。

前置条件：

1. 一个 GitHub 仓库，包含一个存在单元测试的简单项目（例如一个 Node.js 项目）。
2. Claude Code 已安装并配置了 GitHub 权限。
3. 在仓库中设置一个 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], check=True) 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 第五步：运行与验证

1. 模拟失败：故意在项目中引入一个测试错误并推送到 main 分支，触发 CI 失败。
2. 观察 Loop：Webhook 会触发你的脚本。观察日志，看脚本是否成功执行了分析、创建分支、调用 Agent、提交修复、创建 PR 等一系列操作。
3. 验证结果：检查是否创建了一个新的分支和草稿 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/邮件)]

流程解读：

1. 触发：CI 失败事件通过 Webhook 激活 Automation 组件。
2. 隔离：立即创建一个独立的 Git Worktree，确保此次修复任务不会干扰主分支或其他并行任务。
3. 认知：主协调 Agent 或 Proposer Sub-agent 读取SPEC明确目标，并加载SKILLS.md掌握项目规范。
4. 诊断：一个 Sub-agent（或主 Agent）通过 GitHub Connector (Plugin) 获取详细的失败日志，并分析根本原因。
5. 规划与执行：Proposer Sub-agent 制定修复方案，Implementer Sub-agent 在隔离的工作树中执行代码修改。
6. 验证：Reviewer Sub-agent 或 Implementer 自身运行测试，确保修复有效且符合规范。
7. 交付：通过 Git Plugin 将更改提交到新分支，并通过 GitHub Plugin 创建草稿 PR。
8. 通知：通过 Slack/邮件等 Connector 通知开发者进行最终人工复核。这是至关重要的安全边界。

5. 关键风险、安全清单与最佳实践

构建自动化的 AI 工作流力量强大，但风险同样显著。在投入生产前，必须设立严格的安全边界。

5.1 Loop 不能替你承担的三类责任

1. 最终验证责任：Agent 说“完成”，绝不等于任务真的完成。尤其是涉及业务逻辑、安全或数据变更时，必须有人工复核的强制环节（如草稿 PR）。
2. 系统理解责任：Loop 运行得越快，你与系统真实状态的距离可能越远。你必须通过清晰的日志、变更摘要和审计记录，保持对系统的理解和掌控力，避免成为“盲目的管理者”。
3. 核心判断责任：Loop 是效率放大器，而非思考替代品。将目标定义、权限划分、成本控制和验收标准这些需要人类判断的环节自动化，是极其危险的。

5.2 上线前安全检查清单

在部署任何 Loop 到生产环境前，请务必核对以下清单：

最危险的反模式：为了追求“全自动”而全局跳过所有权限确认（例如在脚本中默认对所有提示回答“yes”）。这等同于拆掉了系统的刹车。权限是安全边界，不是开关。

5.3 四条核心落地原则

1. 目标可判定：Loop 的成败必须能由客观标准（测试用例、Lint 规则、类型检查、验证脚本）自动判定，而不是依赖 Agent 的主观汇报。
2. 权限按需配置：给“自动写日报”的 Loop 和“自动修复生产环境 Bug”的 Loop 分配相同的权限，是灾难性的。必须根据任务风险等级精细化配置权限。
3. 成本显性化：每次循环触发都是一次完整的 LLM 会话，会产生成本。必须像管理云资源一样管理 Loop 的成本，设置预算和警报。
4. 输出可审查：所有的产出（代码、文档、消息）都必须留有审查入口，如草稿 PR、隔离分支、变更摘要、操作日志，确保整个过程可追溯、可回滚。

6. 常见问题与排查思路

在实际搭建和运行 Loop 时，你可能会遇到以下典型问题：

7. 总结：从“使用AI”到“运营AI”的关键一跃

Loop Engineering 代表的不仅仅是一种技术实践，更是一种思维模式的升级。它要求我们从关注单次 Prompt 的“术”，转向设计可持续自治系统的“道”。通过将Automations、Worktrees、Skills、Plugins 和 Sub-agents这五大组件有机组合，我们能够构建出真正理解上下文、安全可控、并能够嵌入真实开发流程的 AI 智能体工作流。

对于开发者而言，最大的收益并非完全取代人工，而是将人类从重复、琐碎、模式化的任务中解放出来，专注于更高层次的架构设计、复杂问题解决和最终的质量把关。你可以从今天最重复的一个任务开始——无论是自动生成日报、整理代码库，还是初步的 PR 评审——为其编写一个清晰的 SPEC，然后用一个最简单的脚本将其自动化。一旦这个最小闭环跑通，你就可以像搭积木一样，逐步引入更复杂的组件。

记住，强大的工具也意味着更大的责任。在享受自动化带来的效率提升时，务必坚守目标可判定、权限按需配、成本显性化、输出可审查这四条原则，为你的 AI 工作流装上可靠的“方向盘”和“刹车”。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度