在实际 AI 工程实践中，我们常常面临一个矛盾：一方面，我们希望 AI Agent 能够自主、持续地处理复杂任务，减少人工干预；另一方面，我们又担心完全自动化的 Agent 会脱离控制，产生不可预知的结果。这种“既要自动化，又要可控性”的需求，催生了一种新的工程范式——Loop Engineering。它并非一个全新的工具或框架，而是一套系统性的方法，旨在将 AI Agent 从一次性的、手动驱动的“对话伙伴”，转变为能够持续、自主、安全地执行闭环工作流的“自动化系统”。
对于开发者、AI 工程师和团队负责人而言，理解并实践 Loop Engineering 意味着能够将 AI 能力真正嵌入到日常开发、运维和业务流程中。本文将从核心理念出发，拆解 Loop Engineering 的五个核心组件，并通过一个从零到一的构建示例，展示如何设计一个能够自动发现、分配、执行和检查任务的 AI 自动化工作流。我们还将深入探讨其边界、风险以及上线前的安全检查清单，帮助你避免常见的陷阱，构建出既高效又可靠的 AI 自动化系统。
1. 理解 Loop Engineering：从手动 Prompt 到自动化系统
1.1 传统 AI Agent 使用模式的瓶颈
过去两年，大多数开发者使用 AI 编程 Agent（如 Cursor、Claude Code、GitHub Copilot）的模式是线性的：写一个 Prompt -> Agent 返回结果 -> 人工阅读并判断 -> 再写下一个 Prompt。这个模式确实提升了单次任务的效率，但人始终是流程中最繁忙的“调度员”和“质检员”。随着任务复杂度的增加，这种模式的瓶颈日益明显：
- 上下文断裂：每次对话都是独立的，Agent 难以记住长期目标和项目规范。
- 人工介入频繁：每个决策点都需要人工判断和输入，无法实现真正的“无人值守”。
- 难以规模化：这种模式难以复用到团队或跨项目场景中。
1.2 Loop Engineering 的核心理念
Loop Engineering 的核心思想是将一次性的手动提示，转变为一个可以自动运行、自我检查并决定下一步的可持续循环系统。它回答了一个关键问题：如果我不想一直守在 Agent 旁边，如何让它在可控、安全、可验证的前提下持续工作？
这个“循环”不是指简单的while True死循环，而是一个具备明确状态、输入、输出和终止条件的自动化工作流。你从“驾驶员”转变为“系统架构师”和“监督员”，负责设计循环的规则和边界，而将重复性的执行和初步检查交给 Agent 系统。
1.3 Loop 与普通脚本或 Cron Job 的区别
你可能会问，这和我写一个定时运行的脚本（Cron Job）有什么区别？关键在于“智能决策”和“上下文感知”。
- 普通脚本/Cron Job：执行固定的、预定义的命令序列。如果环境变化或任务条件改变，脚本无法自适应，要么失败，要么产生错误结果。
- Loop Engineering 构建的 AI 工作流：Agent 在循环中能够根据当前上下文（如代码变更、测试结果、外部事件）进行判断、生成新的计划或代码，并验证结果。它是一个具备一定认知和决策能力的动态系统。
2. 构建可持续 Loop 的五个核心组件
一个健壮的、可持续运行的 AI 自动化循环，需要五个基础组件（原语）协同工作。缺少任何一个，循环都可能“泄漏”——即失控、出错或无法持续。
2.1 Automations：循环的触发引擎
Automations 决定了循环何时启动，它是整个系统的心跳。触发方式主要分为两类：
- 定时触发：例如，每小时检查一次线上服务的健康状态，或每天早晨自动整理前一天的 Git 提交记录。
- 事件触发：这是更强大的方式，让 Loop 能够响应外部系统的变化。常见事件源包括：
- 代码仓库：GitHub/GitLab 的 Push、Pull Request (PR) 创建、Issue 更新。
- 通信工具：Slack、钉钉、飞书的特定消息或 @ 提及。
- 监控告警：Sentry 错误、Prometheus 指标异常、云监控告警。
- 项目管理：Linear、Jira 任务状态变更。
- 通用 Webhook：任何能发送 HTTP 请求的系统。
在不同的工具中，Automations 可能有不同的名称，如 Claude Code 的/loop命令、Scheduled Tasks，或是云函数（Cloud Routines）。其核心问题是统一的：基于什么条件，让 Agent 自动开始新一轮工作？
2.2 Worktrees：实现并行与隔离
当 Loop 运行起来后，很可能会同时处理多个任务，或者需要多个 Agent 协作（例如一个写代码，一个做评审）。此时，最大的风险是上下文污染和文件冲突。
Git 的worktree功能为此提供了优雅的解决方案。它允许你在同一个 Git 仓库中，创建多个独立的工作目录，每个目录关联不同的分支。这样：
- Agent A可以在
worktree/feature-fix-a中修复 Bug A。 - Agent B可以在
worktree/feature-fix-b中开发 Feature B。 - 两者互不干扰，拥有独立的文件状态和修改历史。
这对于实现 Sub-agents（子代理）分工和并行处理多条任务线至关重要。
# 示例：为AI Agent创建独立的工作树 git worktree add ../myrepo-agent-fix-bug-123 fix-bug-123 cd ../myrepo-agent-fix-bug-123 # 现在，这个目录是一个独立的沙箱，Agent可以在此安全地工作2.3 Skills：沉淀可复用的项目知识
很多团队初期会把大量项目特有的规则（如代码规范、框架约定、API调用方式）硬编码在 System Prompt 里。这导致 Prompt 臃肿且难以维护。
Skills 组件鼓励你将这类稳定的、可复用的项目知识沉淀到独立的文档中，例如SKILLS.md或AGENTS.md。Agent 在需要时可以读取这些文档来指导自己的行为。
一个糟糕的 Prompt 示例：
你是一个前端专家。请修复这个React组件。记住，我们项目使用Tailwind CSS，不要用内联样式。API调用必须从`src/libs/api`导入，错误处理要用`useToast` hook...一个更好的实践：
创建
PROJECT_SKILLS.md：## 前端开发规范 - **样式**：使用 Tailwind CSS，禁止内联 `style`。 - **API**：所有请求函数定义在 `src/libs/api/` 目录下，组件中通过 `import { userApi } from ‘@/libs/api’` 调用。 - **错误处理**：使用 `src/hooks/useToast` 显示用户提示。 - **提交信息**：遵循 Conventional Commits 规范。在给 Agent 的 Prompt 中简化为：
请根据 `PROJECT_SKILLS.md` 中的规范，修复这个React组件。
这样，项目知识得以固化、版本化管理，并且可以在多个不同的 Loop 和 Agent 间共享。
2.4 Plugins / Connectors：连接真实世界
一个只能“空想”而不能“动手”的 Agent 价值有限。Plugins 或 Connectors 是 Agent 与外部工具链和系统交互的桥梁。通过它们，Agent 可以：
- 读写代码仓库：克隆、提交、创建 PR、合并代码。
- 操作项目管理工具：创建、更新、关闭任务。
- 发送通知：将结果同步到 Slack、邮件或钉钉。
- 查询数据库或API：获取业务数据作为决策依据。
- 执行命令：运行测试、构建脚本或部署命令。
例如，一个自动化 Code Review 的 Loop，可能需要 Connectors 来：读取 GitHub PR 的代码变更，在独立 Worktree 中运行测试和 Lint，将评审意见以评论形式写回 PR，并在 Linear 中更新相关任务状态。
2.5 Sub-agents：职责分离与制衡
让一个 Agent 同时负责“提出方案”、“实现代码”和“检查质量”，就像让运动员同时兼任裁判，容易陷入“自我确认偏差”，难以发现自己的错误。
Sub-agents 模式通过角色分离来引入制衡：
- Proposer/Planner：分析问题，拆解任务，制定执行计划。
- Implementer/Coder：在隔离的 Worktree 中，根据计划具体执行编码任务。
- Reviewer/Verifier：根据 Skills 文档、测试用例和验收标准，严格检查 Implementer 的产出。
这种分工不仅提高了输出质量，也使得整个 Loop 更模块化、更易于调试和维护。每个子代理可以专注于自己的强项，甚至可以使用不同配置的大模型（例如，让更强大的模型做 Review）。
3. 实战：从零构建一个自动化 PR 初步评审 Loop
现在，我们将结合上述五个组件，设计一个具体的 Loop：当 GitHub 上有新的 Pull Request 创建时，自动进行代码风格和基础逻辑的初步评审，并生成评审摘要。
3.1 步骤一：明确 SPEC 与验收标准（人类的工作）
这是 Loop Engineering 中最关键且无法完全自动化的一步。你必须清晰定义“完成”是什么样子。
SPEC 文档 (spec_pr_review.md):
# PR 自动初步评审 Loop 规格 **目标**：对指定仓库的新 PR 进行自动化初步评审，减轻人工评审负担。 **触发条件**：仓库 `my-org/my-app` 有任何新的 Pull Request 被创建。 **输入**：PR 的编号、标题、描述、变更文件列表、Diff 内容。 **处理流程**： 1. 获取 PR 详情。 2. 在独立工作区克隆代码并切换到 PR 分支。 3. 运行项目预定义的代码检查（ESLint, Prettier 检查）。 4. 分析 Diff，检查是否存在明显的逻辑错误（如未处理的空值、明显的性能问题）。 5. 检查提交信息是否符合规范。 6. 生成一份结构化评审摘要。 **输出**： - 在 PR 下方以评论形式发布评审摘要。 - 摘要需包含：通过项、警告项、建议项。 - 如果发现严重问题（如构建失败），需在评论中明确标出。 **停止条件**： - 成功发布评审评论后，本次循环结束。 - 如果过程中遇到网络错误或仓库权限问题，记录日志并结束循环，等待下次触发或人工介入。 **非目标**： - 不自动批准或拒绝 PR。 - 不修改 PR 中的代码。 - 不进行需要深度业务理解的逻辑评审。3.2 步骤二：准备 Skills 与项目配置
创建项目知识文件，让 Agent 了解评审标准。
文件：.github/agents/PR_REVIEW_SKILLS.md
# PR 评审技能指南 ## 代码风格检查 - 运行 `npm run lint`。任何 Error 级别的 lint 错误必须指出。 - 检查变更文件是否使用 Prettier 格式化过。可运行 `npx prettier --check [文件]`。 ## 常见问题模式（需指出） - **空值风险**：新增代码中访问 `object.property` 前，是否检查了 `object` 可能为 `null` 或 `undefined`？ - **硬编码**：检查是否存在新的魔法数字或字符串，应建议提取为常量。 - **大文件**：单个文件变更行数超过 200 行，建议拆分。 - **注释**：新增的复杂逻辑是否有相应注释？ ## 提交信息规范 - 提交信息第一行应符合 Conventional Commits 格式（如 `feat:`, `fix:`, `docs:`）。 - 第一行长度不超过 72 个字符。 ## 评审摘要格式 请使用以下 Markdown 模板： ### 🤖 自动初步评审摘要 **✅ 通过项** - [ ] Lint 检查通过 - [ ] 无明显的语法错误 **⚠️ 警告/建议项** - [ ] （在此列出具体建议，链接到代码行） **❌ 阻塞项（如存在）** - [ ] （在此列出导致构建失败或功能错误的严重问题）3.3 步骤三：搭建 Loop 骨架与连接器
我们将使用 GitHub Actions 作为 Automation 触发器，并利用其环境运行我们的 Agent 逻辑。
文件：.github/workflows/auto-pr-review.yml
name: AI Agent - PR Preliminary Review on: pull_request: types: [opened, synchronize] # PR创建或更新时触发 jobs: review: runs-on: ubuntu-latest permissions: contents: read pull-requests: write # 需要写入权限以发表评论 steps: - name: Checkout PR Code uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} # 检出PR分支代码 fetch-depth: 0 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: ‘18’ - name: Install Dependencies run: npm ci - name: Run Lint & Format Check (Skills 验证) id: checks run: | echo “Running lint...” npm run lint 2>&1 | tee lint-output.log LINT_EXIT=$? echo “Running prettier check...” npx prettier --check . 2>&1 | tee prettier-output.log PRETTIER_EXIT=$? # 将结果存入环境变量，供后续步骤使用 echo “lint_exit_code=$LINT_EXIT” >> $GITHUB_OUTPUT echo “prettier_exit_code=$PRETTIER_EXIT” >> $GITHUB_OUTPUT - name: Analyze Diff & Generate Review (Agent 核心逻辑) env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} PR_TITLE: ${{ github.event.pull_request.title }} PR_BODY: ${{ github.event.pull_request.body }} PR_NUMBER: ${{ github.event.pull_request.number }} LINT_RESULT: ${{ steps.checks.outputs.lint_exit_code }} PRETTIER_RESULT: ${{ steps.checks.outputs.prettier_exit_code }} run: | # 此处是AI Agent的“大脑”。我们可以调用大模型API来分析代码Diff。 # 以下是一个简化的Python脚本示例，使用OpenAI API。 python .github/agents/generate_review.py - name: Post Review Comment uses: actions/github-script@v7 with: script: | const fs = require(‘fs’); // 读取上一步生成的评审摘要 const reviewBody = fs.readFileSync(‘.github/agents/review_output.md’, ‘utf8’); github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: reviewBody });文件：.github/agents/generate_review.py(Agent 逻辑示例)
import os import openai import subprocess from pathlib import Path # 1. 获取 PR Diff def get_pr_diff(): # 使用 git 命令获取当前PR与目标分支的diff result = subprocess.run([‘git’, ‘diff’, ‘origin/main’, ‘HEAD’, ‘—’, ‘.’], capture_output=True, text=True) return result.stdout # 2. 读取 Skills 文档 def read_skills(): skills_path = Path(‘.github/agents/PR_REVIEW_SKILLS.md’) return skills_path.read_text() if skills_path.exists() else “” # 3. 构建 Prompt，调用大模型进行分析 def analyze_with_ai(diff_content, skills_content, lint_status, prettier_status): client = openai.OpenAI(api_key=os.environ.get(‘OPENAI_API_KEY’)) system_prompt = f“””你是一个资深的代码评审助手。请根据以下项目评审规范，对提供的代码变更进行评审。 项目评审规范： {skills_content} 当前PR的自动化检查结果： - ESLint 检查: {‘通过’ if lint_status == 0 else ‘失败’} - Prettier 代码格式检查: {‘通过’ if prettier_status == 0 else ‘失败’} 请专注于代码变更本身，给出具体的、可操作的评审意见。“”” user_prompt = f“””请评审以下代码变更（Git Diff格式）： {diff_content} 请严格按照指定的Markdown模板格式输出评审摘要。“”” try: response = client.chat.completions.create( model=“gpt-4-turbo-preview”, # 可根据成本和性能选择模型 messages=[ {“role”: “system”, “content”: system_prompt}, {“role”: “user”, “content”: user_prompt} ], temperature=0.2, # 低温度，保证输出稳定 max_tokens=1500 ) return response.choices[0].message.content except Exception as e: return f“## ❌ 自动评审失败\n调用AI服务时出错: {e}” # 4. 主函数 def main(): diff = get_pr_diff() skills = read_skills() lint_ok = os.environ.get(‘LINT_RESULT’, ‘1’) == ‘0’ prettier_ok = os.environ.get(‘PRETTIER_RESULT’, ‘1’) == ‘0’ review_summary = analyze_with_ai(diff, skills, lint_ok, prettier_ok) # 5. 保存输出 output_path = Path(‘.github/agents/review_output.md’) output_path.write_text(review_summary) print(f“Review generated and saved to {output_path}”) if __name__ == “__main__”: main()3.4 步骤四：运行与验证
- 将上述文件提交到你的 GitHub 仓库。
- 在仓库 Settings -> Secrets and variables -> Actions 中，添加
OPENAI_API_KEY。 - 创建一个新的 Pull Request。
- 观察 Actions 页面的执行情况。成功后，你会在 PR 的评论区看到 AI Agent 发布的评审摘要。
这个 Loop 实现了：
- Automation：由 GitHub PR 事件触发。
- Skills：从
PR_REVIEW_SKILLS.md读取规范。 - Connector：通过 GitHub Actions 和
git命令与代码仓库交互。 - Sub-agents 雏形：虽然在一个 Job 内，但逻辑上分为了“检查执行”（Lint/Prettier）和“分析总结”（AI 模型）两个角色。
- Worktree 思想：GitHub Actions 的每个 Job 运行在一个干净的 Runner 中，本质是一个隔离环境。
4. Loop Engineering 的风险边界与安全清单
Loop 能力越强，设定清晰的边界就越重要。无人值守的自动化一旦失控，其破坏力也成正比放大。
4.1 Loop 不能替你承担的三项责任
- 最终验证责任：Agent 说“完成”，绝不等于任务真的完成。尤其是涉及代码逻辑、业务规则和最终决策时，必须保留人工复核的环节。自动化是辅助，不是替代。
- 系统理解责任：Loop 运行得越顺畅，开发者与系统真实状态之间的“认知鸿沟”可能越大。如果你完全依赖 Agent 的摘要而不查看具体变更，长期将失去对系统的掌控力。好的 Loop 设计必须提供透明的审计日志和变更追溯。
- 目标定义与价值判断责任：这是最核心的一点。Loop Engineering 是为了放大人的判断力，而不是让人逃避判断。用自动化去执行一个错误或模糊的目标，只会更快地走向错误的方向。
4.2 上线前的安全检查清单
在将一个 Loop 投入生产级使用（尤其是具备写权限的 Loop）之前，请务必核对以下清单：
| 检查项 | 说明与示例 | 风险后果 |
|---|---|---|
| 提示词包含明确停止条件 | 在 Prompt 中明确单次运行的最大 Token 数、最长运行时间或明确的中止信号（如[DONE]）。 | 无限循环，消耗大量资源与费用。 |
| 权限最小化原则 | 为 Loop 配置完成任务所需的最小权限。例如，只读访问的评审 Loop 与可以创建分支的修复 Loop，权限应严格区分。 | 权限过大导致越权操作，破坏生产数据。 |
| 操作隔离与沙箱化 | 写操作必须在隔离分支、临时目录或容器内进行。使用git worktree或 Docker 沙箱。 | 污染主分支或生产环境文件。 |
| 输出处于待审批状态 | Agent 的产出（如代码、配置）应处于“草稿 PR”、“待合并分支”、“审核中”状态，而非直接生效。 | 未经审核的变更直接上线。 |
| 保留完整的运行历史 | 记录每次 Loop 触发的输入、执行的命令、AI 的思考过程（如果支持）和最终输出。 | 出错时无法追溯和调试。 |
| 设置成本与频率监控 | 监控每次运行的 Token 消耗、API 调用次数和费用。对高频触发任务设置限流。 | 产生意外的高额费用。 |
| 熔断机制 | 当连续运行失败、输出重复无意义内容或成本超阈值时，应能自动暂停 Loop 并告警。 | 在错误状态下持续运行，浪费资源。 |
最危险的反模式：为了追求“全自动”而全局禁用所有确认和权限检查（例如，在脚本中自动对所有提示回答“yes”）。这等同于拆掉了系统的刹车。权限是 Loop 的安全边界，不是开关。
5. 进阶：从简单 Loop 到复杂工作流
当你掌握了基本 Loop 的构建后，可以按需引入更复杂的组件，构建更强大的自动化系统。
5.1 引入 Sub-agents 实现专业分工
将上例中的“分析总结”步骤进一步拆解：
- Planner Agent：分析 PR Diff 和 Skills，生成一个具体的评审检查清单（Checklist）。
- Coder Agent（可选）：如果检查清单中包含“自动修复简单的格式问题”，则由此 Agent 在独立 Worktree 中执行修复，并生成新的 Commit。
- Reviewer Agent：基于 Planner 的清单和 Coder 的修复结果（如果有），进行最终评审并生成面向人类的摘要。
这三个 Agent 可以通过消息队列（如 Redis）或共享状态文件来协调工作。
5.2 连接更丰富的工具链（Connectors）
- 与项目管理工具集成：当 PR 评审完成后，自动将状态同步到 Linear 或 Jira 的对应任务中。
- 与监控告警集成：当 Sentry 收到一条高频错误告警时，触发一个 Loop，让 Agent 尝试分析错误日志，在代码库中搜索相似错误的历史修复方案，并生成初步的诊断报告和修复建议，发送到 Slack 指定频道。
- 与内部知识库集成：让 Agent 在执行任务前，先查询内部的 Confluence 或 Wiki 页面，获取最新的 API 文档或设计规范。
5.3 设计循环的循环：Meta-Loop
更高阶的模式是设计一个管理其他 Loop 的“元循环”（Meta-Loop）。例如：
- 健康度检查 Loop：定期检查所有正在运行的业务 Loop 的状态、成功率和资源消耗，在发现异常时发出告警或尝试重启。
- Skills 优化 Loop：分析历史上人工评审对 AI 评审的修正记录，自动总结新的模式，并提议更新
SKILLS.md文档。
6. 总结：从使用 AI 到运营 AI
Loop Engineering 标志着我们从“使用 AI 工具”向“运营 AI 系统”的思维转变。它的价值不在于概念的新颖，而在于提供了一套可落地的、系统化的方法，将 AI Agent 的能力安全、可控、可持续地融入软件开发和运维的生命周期中。
开始实践 Loop Engineering，并不需要你一开始就设计一个庞大的自动化工厂。有效的路径是从一个最具体、最重复、边界最清晰的任务开始：
- 选择一个种子任务：比如“每天早晨自动生成昨日代码变更摘要”。
- 写下它的 SPEC：明确输入、输出、触发条件和完成标准。
- 用最简单的方式跑通闭环：可以是一个
/loop命令，一个 GitHub Action，甚至是一个定时运行的 Python 脚本。 - 固化状态与知识：将运行状态记录到文件，将项目规则沉淀到
SKILLS.md。 - 按需增加复杂度：当这个简单 Loop 运行稳定后，再根据实际需求，逐步引入 Worktree 隔离、Sub-agents 分工或外部 Connectors。
通过这种方式，你可以渐进式地构建起属于你自己或团队的 AI 自动化工作流，让 AI 真正成为一位不知疲倦、严守规则、能力可增长的协作者，从而将你的精力释放到更具创造性和战略性的工作中去。
