循环工程入门：让AI智能体自动运行工作流

什么是循环工程（Loop Engineering）

最近AI圈冒出了很多新概念——Prompt Engineering、Context Engineering、Agent Harness……而现在，一个更进阶的概念正在被越来越多的团队采用：Loop Engineering（循环工程）。

简单来说，循环工程是在智能体运行时的外层搭建一套环境，通过触发器、共享文件系统和日志机制，让智能体不再需要人工逐次提示，而是能够自主地、持续地完成工作。据B站UP主分享，他们团队的代码库凌晨一点还在不断有PR提交——不是因为团队加班，而是智能体循环在自动发现问题、自动接活。他们的Growth Loop已经连续运行两天，每天产出20到40个高质量页面，持续为公司带来流量。

这不是科幻，而是Loop Engineering的真实应用场景。

从Prompting到Loop：AI使用方式的演进

回顾大语言模型的使用历程，可以清晰地看到三个阶段：

2023年：Prompt Engineering阶段。 GPT-3.5/GPT-4 API刚出来时，我们做的事情很简单——给API一段输入，让模型输出文本。核心技术是研究怎么把合适的上下文放进模型调用来引导行为。这个阶段的核心挑战在于模型的上下文窗口极为有限（通常只有4K Token，约3000个英文单词），开发者必须精心设计每一个字符的用途，通过Few-shot示例、Chain-of-Thought提示、角色设定等技巧，在极其有限的空间内最大化模型的输出质量。

2024年：Context Engineering阶段。 模型的上下文窗口从4K暴涨到128K，Google甚至推到了100万Token。窗口变大后，我们开始给模型配工具（如MCP），让它一轮轮执行直到任务完成。MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议，旨在标准化大语言模型与外部数据源、工具之间的连接方式——类似于USB-C之于硬件设备，任何符合协议的工具都可以被模型即插即用地调用。这使得智能体能够在一轮对话中多次调用搜索引擎、数据库、代码执行器等外部工具，逐步完成复杂任务。围绕"如何把有用信息放进窗口"，发展出了System Prompt优化、长对话压缩、Skills扩展等一系列技术。

2025年：Loop Engineering阶段。 我们开始让模型处理更长、更大的任务。很多人已经习惯把Claude Code放出去跑30分钟甚至两个小时。我们不再指望一个智能体包办全程，而是同时开多个智能体会话，每个负责一部分任务。

这就需要一套机制在不同会话之间追踪状态，让每个智能体都知道进展到哪了——这正是Loop Engineering要解决的问题。

循环工程的核心：复利效应

循环工程最强大的地方不在于单个循环本身，而在于多个循环叠加产生的复利效应。

这里的复利效应借用了金融领域的概念：单个循环产生的价值是线性的（每次执行产出固定价值），但当多个循环的输出成为其他循环的输入时，系统整体价值呈指数增长。每个循环既是价值的消费者也是生产者，形成正反馈网络。这与单纯的自动化脚本有本质区别——脚本是线性执行，而循环网络是自我强化的。

以一个客服智能体为例：你让它每30分钟跑一次，抓取所有支持工单，能自动处理的直接回复，同时把用户卡点和改进想法记录下来。这个循环本身已经很有价值了。但更强的是，它记录的想法可以触发编码智能体直接实现部分改进，这些智能体还能继续监控效果——如果之后还有客户遇到类似问题，甚至可以告诉对方相关改动已经上线。

以下是一个团队正在运行的多个循环实例：

• Support Loop：每30分钟触发，处理支持工单，记录用户卡点和想法到Signals文件夹
• SEO Loop：每天早上9点抓取数据，发布SEO页面，同时发现转化缺口等信号
• Product Loop：分析产品Session数据，判断实验优先级
• Growth Loop：持续产出高质量内容页面

关键在于：所有Loop读写同一套共享文件夹系统。比如SEO Loop发现某个关键词点击率不错但缺少自然流量内容，这条Signal就能反馈给Growth Loop，让它优先为这些关键词生产内容。不同Loop有的每小时跑，有的每天跑，但共享同一个"大脑"，复利效应就此启动。

搭建循环的四个核心组件

1. 代码库Harness：让智能体有正确的工作环境

核心目标是让代码库足够清晰，让智能体看得懂该在哪里改、改什么，同时能跑起来验证修改。具体做法包括：

• Agent's MD文件控制在100行左右，详细信息指向文档系统让智能体自己查
• 自定义Lint规则：不能指望智能体每次都找到正确信息，但可以把规则写进Lint检查，做错了警告自动冒出来。Lint是一类静态代码分析工具，能在代码运行前检测潜在错误和风格问题。对智能体来说，自定义Lint规则相当于设置了"护栏"——即使智能体不了解某个约定，违反时也会立即收到明确的错误提示，从而自我修正。
• DevServer零成本启动：本地脚本直接把整套服务器跑起来，让智能体把注意力放在真正的工作上
• WorkTree友好：确保同时开5个智能体也能各自启动开发服务器、跑测试而互不冲突。WorkTree是Git提供的功能（git worktree），允许在同一个仓库中同时检出多个工作目录，每个目录对应不同的分支。这意味着多个智能体可以在同一代码库的不同分支上并行工作，各自拥有独立的文件系统状态，互不干扰地启动开发服务器和运行测试——这是实现真正并行化智能体协作的基础设施前提。

验证环节特别重要：推荐使用Playwright CLI让智能体操作浏览器并录制视频附到PR里。Playwright是微软开源的端到端测试框架，支持Chromium、Firefox和WebKit三大浏览器引擎，其CLI模式允许通过命令行直接控制浏览器执行页面导航、元素点击、表单填写等操作，并支持将操作过程录制为视频文件。这意味着智能体可以像真实用户一样操作应用界面，验证代码修改是否产生了预期效果，而不仅仅依赖单元测试。录制的视频附到PR中，为人类审查者提供了直观的验证证据。

同时要加端到端测试覆盖关键流程（如升级、注册等），并且不要让智能体完全自己验证自己的工作——PR skill会要求它带详细Spec，启动只读Verifier Agent进行复核。让智能体验证自己的工作存在一个根本性问题：如果生成代码的逻辑有偏差，那么验证逻辑很可能也会有相同的偏差——这类似于让学生自己批改自己的试卷。Verifier Agent是一个独立的只读智能体实例，它不参与代码编写，只负责根据预定义的Spec检查产出是否符合要求。只读权限确保Verifier不会"修复"问题来让验证通过，而是如实报告偏差。

2. 文件系统：共享知识层

文件系统是循环工程的抽象层，主要包含三类文件：

Artifacts（产物）：智能体的产出或发现，是共享知识层的核心。类型包括Docs、Signals、Tasks等。每个Artifacts文件夹里放一个README说明schema，每个条目包含Metadata、正文内容和变更Timeline。这种设计借鉴了数据库schema的思想——通过统一的结构定义，确保不同智能体在不同时间产出的内容格式一致，可以被其他智能体可靠地解析和利用。

Signals（信号）：反馈、想法或循环观察到的信息。智能体可创建Signal并链接原始反馈或支持工单等Artifacts。这些Signal在多个循环之间共享，是复利效应的关键载体。Signal的设计理念类似于事件驱动架构中的"事件"——它是一个轻量级的信息单元，携带足够的上下文让接收方决定是否需要采取行动，而不是直接触发固定的后续流程。

Logs（日志）：全局WorkLog记录跨领域的上下文。每次完成大块工作后写入，开始新工作前先读最近5到10条记录。WorkLog解决的是智能体的"记忆连续性"问题——由于每次循环触发时智能体的上下文窗口是全新的，它需要一种机制快速恢复对当前项目状态的理解，WorkLog就充当了这个"短期记忆"的角色。

3. 触发器：让循环自动运转

触发器可以是定时任务（如Cron Job）、另一个智能体、服务器事件，甚至是webhook。Cron是Unix/Linux系统中的定时任务调度器，允许按照固定时间间隔或特定时间点自动执行命令；Webhook则是一种HTTP回调机制，当特定事件发生时（如收到新工单、代码被推送），目标URL会收到一个POST请求。这两种机制结合，使得循环既可以按固定节奏运转，也可以被外部事件实时唤醒。

智能体被唤醒后，通常先做调查，再执行动作，最后产出backlog或想法列表，必要时还能分派任务给其他智能体。

4. Loop Contract：循环的"契约"

每个循环定义一个Contract，包括目标、要遵循的Workflow以及Backlog列表。每次触发时，循环先读Contract、目标、流程和历史记录，这些信息决定下一步做什么。Contract的设计借鉴了"契约式设计"（Design by Contract）的软件工程原则——通过明确的前置条件、后置条件和不变量，约束智能体的行为边界。这确保了即使智能体的底层模型发生变化或出现幻觉倾向，它的行为仍然被限定在预期范围内。

实战：搭建Support Loop

以客服Support Loop为例，完整搭建流程如下：

第一步：准备Skills。 包括拉取工单的Common Skills、Stripe支付订阅数据查询、Supabase分析数据查询等。Skills在这里指的是预定义的工具调用模板或API封装——它们将复杂的外部服务交互简化为智能体可以直接调用的标准化接口。例如，Stripe Skills封装了查询用户订阅状态、退款历史等操作，智能体无需了解Stripe API的具体细节即可获取所需信息。还需要准备业务背景的Claude MD文件和Architecture MD文件。

第二步：定义工作流。 每次触发时拉取过去X小时内更新过的工单，调查用户问题，创建工单相关Artifacts，记录反馈和想法，并把操作日志写下来。

第三步：手动校准。 先手动跑一遍作为测试，和智能体一起校准工作流是否符合预期。确认后让智能体创建README作为Contract，把目标、工作流和时间安排写清楚。这个校准步骤至关重要——它类似于机器学习中的"人类反馈强化学习"（RLHF），通过人工审查早期输出来调整智能体的行为模式，确保自动化运行后的质量符合预期。

第四步：设置自动触发。 将Loop设置为每小时自动触发一次。智能体会自动处理工单、生成Artifacts、识别客户反馈、记录工程bug。

总结与建议

循环工程的本质是把智能体从"被动响应"升级为"主动运转"。你不需要一开始就搭建复杂的多循环系统，可以从一个最简单的Loop开始——比如每小时处理一次客服工单，或者每天生成一篇SEO内容。

真正建议你做的第一步是：把代码库整理到智能体可以验证结果的状态。即使不写循环，这一步本身也会大幅提升你与AI协作的效率。当你的第一个Loop稳定运行后，再逐步引入共享文件系统，让多个Loop之间产生复利效应——这才是循环工程真正的威力所在。

核心要点