从Prompt到Loop:构建AI Agent自动化工作流的核心架构与实战
如果你还在手动给 AI 编程助手写 Prompt,然后等待、检查、再写下一个 Prompt,那你可能已经落后了。这种“人肉调度”模式,在 AI 能力越来越强的今天,正成为效率提升的最大瓶颈。真正的效率革命,不是让 AI 帮你写代码,而是让 AI 自己管理自己,形成一个能自动发现任务、分配任务、执行并检查的闭环系统。
这就是Loop Engineering正在解决的问题,也是AI Engineer这个新兴角色必须掌握的核心技能。它标志着我们从“使用 AI”的个体,转向“运营 AI”的系统设计者。想象一下,一个能自动评审 PR、修复 Bug、整理日报的 AI 工作流,在你睡觉时仍在高效运转,而你只需要在关键节点进行复核。这不再是科幻,而是正在落地的工程实践。
本文将深入解析如何构建一个Agent 构建 Agent 的自动化工作流。我们将从 Loop Engineering 的核心理念出发,拆解其五大核心组件,并提供一个从零到一搭建自动化工作流的完整实战指南。无论你是个人开发者希望解放双手,还是团队负责人思考如何规模化应用 AI,这篇文章都将为你提供清晰的路径和可落地的代码。
1. 从 Prompt 到 Loop:为什么我们需要自动化工作流?
过去两年,我们使用 AI 编程助手(如 Cursor、Claude Code)的典型流程是线性的:写 Prompt → AI 返回结果 → 人工阅读 → 再写下一个 Prompt。这个模式中,人类始终是那个最忙的“调度员”和“质检员”。AI 越强大,手动 Prompt 的瓶颈就越明显:它无法持续、无法并行、更无法在你离线时工作。
Loop Engineering 的本质,是将一次性的对话交互,升级为一个可持续运行的自动化系统。它不再是一个“问答机”,而是一个具备感知、决策、执行和自检能力的“智能体工厂”。其核心价值在于回答一个非常现实的问题:如果我不想一直守在 Agent 旁边,怎样让它在可控、安全、可验证的前提下持续工作?
这种转变带来了几个关键优势:
- 解放人力:将开发者从重复性的指令输入和结果检查中解放出来,专注于更高层的架构设计和问题定义。
- 提升稳定性:通过预设的规则(Skills)、隔离的环境(Worktrees)和分角色的检查(Sub-agents),减少因上下文混淆或单一 Agent 盲信自己输出导致的质量问题。
- 实现规模化:一个设计良好的 Loop 可以 7x24 小时运行,处理大量并发的、规则明确的微任务,如代码审查、测试运行、日志监控等。
- 增强可观测性:自动化工作流天然需要日志、状态记录和审计追踪,这使得 AI 的工作过程变得透明、可复盘、可调试。
对于希望进阶的 AI Engineer 而言,掌握 Loop Engineering 意味着从“会用工具”到“能造工具”的跨越。
2. Loop Engineering 核心五件套:构建自动化工作流的基石
一个健壮的、可持续的 AI 自动化工作流,不能只靠一个超级提示词。根据 Addy Osmani 在《Loop Engineering》中的阐述,它需要五个核心组件协同工作,缺一不可。
2.1 Automations:循环的“心跳”与触发器
Automations 决定了 Loop 何时启动。它是整个工作流的调度中心。
- 定时触发:例如,
每天上午9点自动生成项目日报、每10分钟检查一次线上服务健康状态。 - 事件触发:例如,
GitHub 有新 PR 创建时、Sentry 产生 P0 级告警时、特定 Slack 频道收到消息时。 在不同的工具中,它可能被称为/loop命令、Scheduled Tasks 或 Cloud Routines。其核心问题是:基于什么规则,让 Agent 自动开始工作?
2.2 Worktrees:实现并行与隔离的“沙盒”
当多个任务需要同时处理时,最大的风险是上下文污染和文件冲突。Git Worktree 是这个问题的优雅解决方案。
- 作用:允许在同一个 Git 仓库中,同时签出多个独立的工作目录(每个目录对应一个独立分支)。这样,不同的 Agent 或同一个 Agent 处理的不同任务,可以在完全隔离的环境中进行,互不干扰。
- 场景:夜间同时运行三条不同的自动化测试修复线;一个 Agent 在
feature/agent-fix-a分支上写代码,另一个 Agent 在review/agent-fix-a分支上做代码评审。
2.3 Skills:项目的“知识库”与“规范手册”
Skills 解决了“Agent 如何知道我们项目的特定规则”的问题。将项目规范硬编码在 System Prompt 中会导致其臃肿且难以维护。
- 最佳实践:将稳定的项目规则沉淀到独立的文档中,如
SKILL.md、AGENTS.md或project_constraints.json。 - 内容示例:
- 前端必须使用 Tailwind CSS,禁止内联样式。
- 所有 API 调用必须从
src/libs/api-client统一引入。 - 提交代码前必须通过 ESLint 和 Prettier 检查。
- 单元测试覆盖率不能低于 80%。 这样,Agent 在执行任务前或过程中,可以读取这些 Skills 文件,确保其行为符合项目长期约束,而不是依赖某次对话中的临时提醒。
2.4 Plugins / Connectors:连接现实世界的“手和脚”
一个无法与外部工具交互的 Agent,只是一个封闭的“思想家”。Connectors 让 Agent 具备了操作现实世界的能力。
- 类型:GitHub API、Linear/Jira API、Slack Bot、Sentry Webhook、数据库客户端、云存储 SDK 等。
- 价值:使 Loop 能从“本地实验”升级为“业务流程的一部分”。例如,一个完整的 PR 自动化评审 Loop 可能需要:通过 GitHub Connector 读取 PR 内容 -> 在独立 Worktree 中分析并尝试修复 -> 通过 Linear Connector 更新关联任务状态 -> 通过 Slack Connector 通知相关人员。
2.5 Sub-agents:角色分离的“专业化分工”
让一个 Agent 同时承担“方案设计”、“编码实现”和“质量评审”的角色,就像让运动员同时兼任裁判,容易产生盲点。
- 角色划分:
- Proposer/Planner:分析需求,拆解任务,制定执行计划。
- Implementer/Coder:在隔离的 Worktree 中,根据计划具体执行编码任务。
- Reviewer/Verifier:依据 Skills 和预定义的测试用例,对 Implementer 的产出进行审核。 这种分工协作的模式,借鉴了软件工程中的“职责分离”原则,能有效提升复杂任务的完成质量和可靠性。
3. 环境准备:搭建你的第一个 AI 自动化工作流
在开始构建复杂的 Loop 之前,我们需要一个最小化的实验环境。这里我们以基于Claude Code(或类似支持/loop命令的 IDE 插件)和Git的本地环境为例。
前置条件:
- 代码编辑器/IDE:安装并配置好 Cursor 或 VS Code with Claude Code 扩展。
- Git:确保本地已安装 Git,并熟悉基础命令。
- 目标仓库:准备一个用于实验的 Git 仓库(可以是你的个人项目)。
- AI 模型权限:确保你的 IDE 插件已正确配置,并能调用 Claude 3.5 Sonnet 或 GPT-4 等具备较强代码能力的模型。
核心思路:我们将构建一个最简单的自动化任务:每日自动整理当前 Git 仓库的变更摘要。
4. 实战:构建“每日代码变更摘要”自动化 Loop
4.1 第一步:定义清晰的 SPEC(规格说明书)
这是唯一必须由人来完成的一步,它定义了 Loop 的“目标”。创建一个名为SPEC_daily_summary.md的文件。
# 任务规格:每日代码变更摘要 ## 目标 每日上午 10:00,自动分析当前 Git 仓库自昨日摘要以来(或过去24小时)的代码变更,生成一份简洁的 Markdown 格式摘要报告。 ## 输入 - 当前 Git 仓库的本地路径。 - 上一次摘要的 Git Commit ID(从 `last_summary_commit.txt` 文件中读取,如果文件不存在,则默认为 `HEAD~24h`)。 ## 输出 - 一个名为 `daily_summary_<YYYYMMDD>.md` 的 Markdown 文件,内容包含: 1. 报告日期。 2. 统计信息:提交数量、贡献者、变更文件数。 3. 按模块/目录分组的变更摘要。 4. 关键提交的简要说明(避免罗列所有)。 - 更新 `last_summary_commit.txt` 文件,记录本次摘要结束时对应的最新 Commit ID。 ## 验收标准(成功条件) 1. 文件 `daily_summary_<YYYYMMDD>.md` 被成功创建在项目根目录的 `./summaries/` 文件夹下。 2. 文件内容符合 Markdown 格式,信息准确无误。 3. `last_summary_commit.txt` 文件被正确更新。 4. 整个过程无需人工干预,且不会破坏仓库现有文件。4.2 第二步:沉淀项目 Skills
创建SKILL.md文件,告诉 Agent 我们这个项目的通用规则。
# 项目 AI Agent 技能与规范 (SKILL) ## 代码风格与规范 1. 所有生成的代码必须通过项目已有的 ESLint 和 Prettier 检查。 2. 提交信息应遵循 Conventional Commits 格式。 3. 禁止直接修改 `main` 或 `master` 分支。所有工作必须在特性分支上进行。 ## 本自动化任务特定规则 1. 本任务(每日摘要)的产物是 **只读** 的 Markdown报告,**严禁**修改任何源代码文件。 2. 执行 Git 命令时,使用 `git log --oneline --since=<date>` 等查询命令,避免使用 `git reset`、`git push -f` 等危险命令。 3. 生成的摘要文件应放在 `./summaries/` 目录下,并按日期命名。 4. 如果 `./summaries/` 目录不存在,请先创建它。 ## 安全与权限边界 - 不允许执行任何安装软件包或修改系统配置的命令。 - 不允许访问项目 `.env`、`config/secrets.*` 等敏感文件。4.3 第三步:编写核心自动化脚本
虽然 Claude Code 的/loop命令可以接受自然语言,但为了更精确和可复用,我们创建一个可执行的 Shell 脚本run_daily_summary.sh。Agent 将主要执行这个脚本。
#!/bin/bash # 文件:run_daily_summary.sh # 描述:每日代码变更摘要生成脚本 set -e # 遇到错误则退出 PROJECT_ROOT=$(pwd) SUMMARIES_DIR="$PROJECT_ROOT/summaries" LAST_COMMIT_FILE="$PROJECT_ROOT/last_summary_commit.txt" TODAY=$(date +%Y%m%d) SUMMARY_FILE="$SUMMARIES_DIR/daily_summary_$TODAY.md" # 1. 确保 summaries 目录存在 mkdir -p "$SUMMARIES_DIR" # 2. 确定上次摘要的 commit,如果文件不存在,则默认查看过去24小时 if [ -f "$LAST_COMMIT_FILE" ]; then LAST_COMMIT=$(cat "$LAST_COMMIT_FILE") SINCE_FLAG="--since=$LAST_COMMIT" echo "基于上次摘要提交: $LAST_COMMIT" else SINCE_FLAG="--since=\"24 hours ago\"" echo "未找到历史记录,默认查看过去24小时" fi # 3. 获取 Git 日志统计信息 COMMIT_COUNT=$(git log --oneline $SINCE_FLAG | wc -l) AUTHORS=$(git log --format=\"%an\" $SINCE_FLAG | sort | uniq | tr '\n' ', ') CHANGED_FILES=$(git diff --name-only $SINCE_FLAG HEAD 2>/dev/null | wc -l || echo "N/A") # 4. 生成 Markdown 报告 { echo "# 每日代码变更摘要 - $TODAY" echo "" echo "## 📊 统计概览" echo "- **提交数量**: $COMMIT_COUNT" echo "- **贡献者**: ${AUTHORS%, }" echo "- **变更文件数**: $CHANGED_FILES" echo "" echo "## 📝 变更详情" echo "" # 按目录分组显示主要变更 echo "### 主要修改的目录" git diff --name-only $SINCE_FLAG HEAD 2>/dev/null | sed 's|/[^/]*$||' | sort | uniq -c | sort -rn | head -10 | while read count dir; do if [ -n "$dir" ]; then echo "- **$dir** ($count 个文件)" fi done echo "" echo "### 关键提交" git log --oneline -5 $SINCE_FLAG | while read line; do echo "- $line" done echo "" echo "---" echo "*本报告由 AI Agent 自动化生成*" } > "$SUMMARY_FILE" # 5. 更新最后一次记录的 Commit ID git rev-parse HEAD > "$LAST_COMMIT_FILE" echo "✅ 每日摘要已生成: $SUMMARY_FILE" echo "✅ 已更新最后提交记录: $(cat $LAST_COMMIT_FILE)"给 Agent 的提示:这个脚本提供了基础框架。Agent 的任务是理解它,并在必要时修复脚本中的错误、优化逻辑(例如更智能的分组),或者根据 SPEC 调整输出格式。
4.4 第四步:创建 Loop 配置文件与启动指令
我们需要一个中心化的配置文件来管理 Loop。创建一个loop_config.json。
{ "name": "daily_code_summary", "description": "每日自动生成代码仓库变更摘要", "schedule": "0 10 * * *", // Cron 表达式,表示每天上午10点 "trigger_type": "schedule", "command": "bash ./run_daily_summary.sh", "working_directory": "/path/to/your/git/repo", // 请替换为你的实际仓库路径 "environment_variables": { "GIT_AUTHOR_NAME": "AI Agent", "GIT_AUTHOR_EMAIL": "agent@example.com" }, "skills_file": "./SKILL.md", "output_directory": "./summaries/", "notifications": { "on_success": "log_only", "on_failure": "log_and_alert" // 可配置为发送到 Slack/Email } }4.5 第五步:启动与监控你的第一个 Loop
在 Claude Code 或支持类似功能的 IDE 中,你可以通过以下方式启动这个 Loop:
方式一:使用/loop命令(轻量级,适合测试)在 IDE 的 AI 聊天框中输入:
/loop 24h 请根据项目根目录下的 `loop_config.json` 和 `SKILL.md` 文件,执行每日代码摘要生成任务。重点:1. 读取配置。2. 确保在正确的目录执行脚本。3. 检查 `run_daily_summary.sh` 脚本是否有语法错误并修复。4. 执行脚本,并将生成的摘要内容读出来给我确认。这个命令会每隔24小时触发一次你定义的提示词,模拟定时任务。
方式二:配置系统级定时任务(生产环境推荐)对于真正的无人值守运行,需要借助外部调度器。
使用 Crontab (Linux/macOS):
# 编辑 crontab crontab -e # 添加一行,每天上午10点执行,并重定向日志 0 10 * * * cd /path/to/your/git/repo && /usr/local/bin/claude-code --run-task daily_summary 2>&1 | tee -a /tmp/ai_loop.log注:这里假设
claude-codeCLI 支持--run-task参数来执行预定义任务。实际工具可能不同,核心思想是定时调用能执行你脚本的命令。使用 GitHub Actions (云上/团队协作): 创建
.github/workflows/daily-summary.yml:name: Daily Code Summary on: schedule: - cron: '0 10 * * *' # UTC 时间,每天10点 workflow_dispatch: # 允许手动触发 jobs: summarize: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 # 获取全部历史,用于 git log - name: Setup AI Agent Environment # 这里需要配置你的 AI Agent 运行环境,例如通过 API 调用模型 run: | # 示例:调用 OpenAI/Claude API 来执行分析任务 # 实际中,你可能需要封装一个脚本,将 git log 结果作为上下文发送给 AI,并让其生成摘要。 echo "此处应替换为调用 AI 服务生成摘要的实际逻辑" # 模拟:直接运行我们的 Shell 脚本(假设AI逻辑已内化在脚本中) chmod +x ./run_daily_summary.sh ./run_daily_summary.sh - name: Commit and Push Summary run: | git config --local user.email "github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" git add ./summaries/ git commit -m "docs: add daily code summary for $(date +%Y%m%d)" || echo "No changes to commit" git push
5. 进阶:引入 Sub-agents 与 Connectors
当基础 Loop 运行稳定后,可以引入更复杂的模式。例如,构建一个PR 自动评审与修复建议 Loop。
工作流设计:
- Trigger:GitHub Webhook 监听
pull_request.opened事件。 - Planner Agent:接收 Webhook 数据,分析 PR 的变更范围、描述,根据
SKILL.md判断需要哪些检查(如代码风格、单元测试、依赖更新等),并创建检查任务清单。 - Implementer Agent:对于发现的问题(如 lint 错误),在独立的 Git Worktree 中尝试自动修复,生成一个修复分支。
- Reviewer Agent:审核 Implementer 的修复结果,运行测试套件,确保修复没有引入回归。
- Reporter Agent:将评审结果、修复建议(或自动修复的 PR 链接)以评论形式回写到原 GitHub PR,并可能同步状态到 Linear 等项目管理工具。
关键代码片段示例(概念性):
# 伪代码,展示使用 LangChain 或类似框架编排多个 Agent 的思路 from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import Tool from github_toolkit import GitHubToolkit from code_analysis_toolkit import CodeAnalysisToolkit # 1. 定义工具 github_tools = GitHubToolkit().get_tools() # 获取 PR、写评论等工具 code_tools = CodeAnalysisToolkit().get_tools() # 获取代码分析、运行测试等工具 all_tools = github_tools + code_tools # 2. 创建不同角色的 Agent planner_prompt = """你是一个计划员。请分析这个PR...""" planner_agent = create_react_agent(llm=llm, tools=all_tools, prompt=planner_prompt) implementer_prompt = """你是一个实现者。请根据任务清单和代码规范进行修复...""" implementer_agent = create_react_agent(llm=llm, tools=code_tools, prompt=implementer_prompt) # 可能不需要 GitHub 写权限 reviewer_prompt = """你是一个评审员。请检查代码...""" reviewer_agent = create_react_agent(llm=llm, tools=code_tools, prompt=reviewer_prompt) # 3. 编排工作流(简化示例) def pr_review_loop(pr_url): # Planner 分析 plan = planner_agent.run(f"分析PR: {pr_url}") tasks = parse_plan(plan) for task in tasks: if task.needs_fix: # 创建隔离的 worktree 和分支 branch_name = create_worktree_and_branch() # Implementer 在隔离分支上修复 fix_result = implementer_agent.run(f"在分支{branch_name}上修复任务: {task.description}") # Reviewer 评审修复 review_ok = reviewer_agent.run(f"评审分支{branch_name}的修复") if review_ok: create_fix_pr(branch_name, pr_url) # 最终报告 post_summary_comment(pr_url, plan)6. 运行效果与验证
成功运行“每日摘要” Loop 后,你应该能在项目./summaries/目录下看到按日期生成的 Markdown 文件。
示例输出daily_summary_20231027.md:
# 每日代码变更摘要 - 20231027 ## 📊 统计概览 - **提交数量**: 8 - **贡献者**: Alice, Bob - **变更文件数**: 14 ## 📝 变更详情 ### 主要修改的目录 - **src/components** (5 个文件) - **tests/unit** (4 个文件) - **docs** (3 个文件) ### 关键提交 - a1b2c3d feat: 添加用户个人中心页面 - e4f5g6h fix: 修复登录接口在移动端的兼容性问题 - i7j8k9l test: 为 UserService 添加单元测试 - m1n2o3p docs: 更新项目快速开始指南 - q4r5s6t chore: 更新依赖包版本 --- *本报告由 AI Agent 自动化生成*验证要点:
- 文件生成:检查
./summaries/目录下是否存在当日的文件。 - 内容准确性:核对提交数量、贡献者名单是否与
git log一致。 - 无副作用:确认源代码目录没有被意外修改。
- 状态持久化:检查
last_summary_commit.txt文件是否被更新为最新的 commit ID。
7. 常见问题与排查思路
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Loop 未按计划触发 | 1. Crontab 语法错误。 2. 命令路径不对。 3. 用户权限不足。 | 1. 检查crontab -l。2. 在 crontab 命令中使用绝对路径。 3. 查看系统日志 /var/log/syslog(Linux) 或邮件。 | 1. 使用crontab.guru网站验证语法。2. 在脚本开头使用 cd /absolute/path。3. 为脚本添加执行权限 chmod +x。 |
| Agent 执行了危险操作 | Skills 文件定义不严,或 Agent 权限过大。 | 1. 检查SKILL.md中是否明确禁止了相关操作。2. 审查 Loop 运行日志。 | 1. 细化 Skills,使用“最小权限原则”。 2. 在安全沙箱或容器中运行 Agent。 |
| 生成的摘要内容空洞或错误 | 1.git log时间范围错误。2. AI 模型理解偏差。 3. 脚本逻辑有 Bug。 | 1. 检查last_summary_commit.txt文件内容。2. 手动运行脚本,对比输出。 3. 在 SPEC 中更精确地定义“关键提交”的筛选逻辑。 | 1. 在脚本中添加更详细的日志,记录SINCE_FLAG的实际值。2. 在 Prompt 或 Skills 中提供更具体的示例。 3. 让 Reviewer Sub-agent 对摘要进行基础事实校验。 |
| 多个并行 Loop 导致文件冲突 | 未使用 Git Worktree 进行隔离。 | 检查不同 Loop 的工作目录是否相同。 | 为每个独立的任务或 Agent 实例创建独立的 Git Worktree。 |
| API 调用超时或失败 | 网络问题或第三方服务(如 GitHub API)限流。 | 1. 查看 AI 模型调用或 Connector 的返回错误。 2. 检查网络连接和 API 令牌配额。 | 1. 在代码中增加重试机制和指数退避。 2. 设置合理的超时时间。 3. 监控 API 使用量。 |
8. 最佳实践与工程化建议
构建可靠的 AI 自动化工作流,需要像对待任何生产系统一样严谨。
- 从简开始,迭代演进:不要试图一开始就设计一个完美的全自动工厂。从最小的、边界最清晰的单一任务(如每日摘要)开始,验证整个 Loop 的可行性,再逐步增加复杂度。
- SPEC 先行,定义“完成”:在写第一行自动化代码之前,必须用人类可读的方式明确写出任务的输入、输出和验收标准。这是防止 AI “跑偏”的锚点。
- 权限最小化:为每个 Loop 和 Sub-agent 配置严格的最小权限集。能读就不要写,能用特定 API 就不要给全局 Token。在 CI/CD 环境中,使用临时凭证。
- 隔离是安全的基石:充分利用 Git Worktree、Docker 容器或轻量级虚拟机来隔离不同任务和 Agent 的执行环境,避免状态污染。
- 审计与可观测性:每个 Loop 都必须有详尽的日志记录,包括触发时间、输入、关键决策、输出、消耗的 Token 数以及最终状态。这些日志应集中存储,便于排查问题和成本分析。
- 设置熔断机制:监控 Loop 的运行。如果连续失败 N 次,或单位时间内消耗 Token 异常高,应能自动暂停并告警,防止“失控燃烧”。
- 人始终在环(Human-in-the-loop):对于关键操作,如创建 PR、合并代码、发布部署,必须设置人工审批环节。自动化负责“建议”和“草稿”,人类负责“决策”和“执行”。
- 成本意识:将 Token 消耗作为关键指标进行监控。为不同的任务选择合适的模型(例如,代码生成用 Claude 3.5 Sonnet/GPT-4,文本摘要用 Claude Haiku/GPT-3.5-Turbo),并设置每次运行的预算上限。
9. 总结:从 AI 使用者到 AI 系统设计者
Loop Engineering 不仅仅是一个技术框架,它代表了一种思维模式的转变。我们不再满足于让 AI 执行单次命令,而是开始设计能够自主运转的智能系统。这要求我们具备系统思维、清晰的边界定义能力以及对安全与成本的深刻理解。
构建 Agent 自动化工作流的过程,本身就是对软件工程、DevOps 和 AI 能力的一次深度融合。你遇到的关于隔离、权限、调度、监控的问题,都是经典的工程问题。而解决它们的过程,正是在塑造“AI Engineer”这一角色的核心能力。
下一步,你可以尝试:
- 复杂化任务:将简单的摘要生成,升级为包含自动代码优化建议的 Loop。
- 连接更多工具:引入 Slack 通知、Jira 状态同步、Sentry 错误自动创建工单等 Connectors。
- 设计决策流:让 Planner Agent 不仅能拆解任务,还能根据代码变更的复杂度,动态决定是直接修复、请求人工评审还是忽略。
真正的自动化不是取代人类,而是将人类从重复劳动中解放出来,让我们能更专注于创造、设计和处理那些真正需要智慧与判断的复杂问题。现在,就从为你最重复的那个任务编写一份 SPEC 开始,启动你的第一个 Loop 吧。
