从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. 实战构建“每日代码变更摘要”自动化 Loop4.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 --sincedate 等查询命令避免使用 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: agentexample.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 21 | 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/checkoutv4 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 push5. 进阶引入 Sub-agents 与 Connectors当基础 Loop 运行稳定后可以引入更复杂的模式。例如构建一个PR 自动评审与修复建议 Loop。工作流设计TriggerGitHub 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(llmllm, toolsall_tools, promptplanner_prompt) implementer_prompt 你是一个实现者。请根据任务清单和代码规范进行修复... implementer_agent create_react_agent(llmllm, toolscode_tools, promptimplementer_prompt) # 可能不需要 GitHub 写权限 reviewer_prompt 你是一个评审员。请检查代码... reviewer_agent create_react_agent(llmllm, toolscode_tools, promptreviewer_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 吧。