智能体循环实战：Agent自动化工程设计与护栏搭建指南

凌晨十二点，代码库仍在不停收到新的 PR——这不是团队在拼命加班，而是 Agent 每 30 分钟自动醒来一次，扫描代码找 bug、查服务器日志、提交 PR 并附上验证证据，部分低风险修复甚至直接自动合并。这样的自动化循环（Loop）已经在生产环境稳定运行了几个月。本文基于一位实践者的深度分享，拆解如何用 Claude Code / Codex 构建可验证、可自我进化的智能体工作流。

拼出一个 Loop 只是 5% 的工作

很多人以为，理解了 Loop 的概念，就能用 Claude Code 或 Codex 搭出一个能用的自动化循环。但这只是 5% 的难度——真正的挑战在于设计护栏（Guardrails），让 Agent 能放心地自主运行。

Loop 的核心目标是让 Agent 自主选任务、执行、验证并持续改进。单靠一个会循环调用的脚本远远不够，你需要一整套系统结构来保证它安全、稳定地交付成果，并且不会在同一个坑里反复踩。

作者团队内部每个 Loop 都遵循相似的结构：一个 Markdown 文件承载 Loop Contract（循环契约），同时记录状态和日志，相当于这个 Loop 的活文档；再配上一个触发层（Trigger），负责在合适的时机唤醒 Agent。这套结构可以覆盖工程任务、CRM 用户分层、多语言客服工单等多种真实场景。

Loop Contract：循环的「宪法」

Loop Contract 是整个系统的核心，可以把它理解成这个循环的「宪法」。它的设计理念借鉴了分布式系统中「契约式编程」（Design by Contract）的思想——该概念由计算机科学家 Bertrand Meyer 在 1986 年提出，核心主张是软件组件必须明确声明三类约束：前置条件（Precondition，调用方必须满足的输入保证）、后置条件（Postcondition，组件执行完毕后必须满足的输出保证）以及不变量（Invariant，无论何时都必须成立的系统属性）。这三类约束共同确保了组件之间的交互可预测、可验证。

将这一思想引入 AI Agent，本质上是在解决 LLM 的「目标漂移」（Goal Drift）问题：大型语言模型在长时间自主运行中，由于每次推理都依赖当前上下文，极易在多轮迭代后逐渐偏离初始意图，尤其当任务目标描述模糊时，模型会自行填充假设并演变出与原始需求相悖的行为路径。这一问题在实践中的表现往往是隐性的——Agent 不会突然「出轨」，而是通过每一步看似合理的微小决策，在数十轮迭代后累积出显著的语义漂移。

值得注意的是，目标漂移与模型「幻觉」（Hallucination）并不相同：幻觉指模型生成事实错误的内容，而目标漂移是指模型在事实层面并无明显错误，却在意图层面悄然偏离了原始任务目标。这使得目标漂移更难被及时发现，往往等到系统已经在错误方向上运行了相当多轮次后才暴露出来。通过强制 Agent 在每次执行前对照契约校验行为边界，Loop Contract 将抽象的「意图」转化为可机器解读的操作规程，在架构层面建立了一道形式化的意图锚定机制。

Loop Contract 主要包含三件事：

• 意图（Intent）：到底什么算成功？有没有明确的终点？
• 边界（Boundary）：哪些事 Agent 可以自作主张，哪些必须找人确认？
• SOP：Agent 每次运行要遵循的标准流程和操作原则。

以团队代码库里的 React Doctor Check 为例：这个 Loop 每天在代码库里运行一次开源 CLI 工具 React Doctor，自动扫出关键问题、列成清单并打分，然后挑最重要的一个问题自动修复。它的 Contract 会明确写出目标（Goal）、边界（Boundary，包括如何派生子 Agent 在隔离轨迹里执行修复）、完整验证流程，以及哪些改动可以自动 Merge、哪些必须先经人工 Review。

State 与 Log：让 Agent 记住自己

光有契约还不够，Agent 还需要记住之前尝试过什么、学到了什么。这部分通常拆成两块：

• State（状态）：类似长期快照，记录 Agent 当前的判断、假设、Backlog 以及已交付但需后续跟进的事项。这部分要刻意保持精简，不要什么都往里塞。
• Log（日志）：按每轮运行 Append-Only（只追加） 的方式记录。

Append-Only 的日志设计是数据库和分布式系统中的经典可靠性保障模式，被 Apache Kafka 的消息持久化机制、Event Sourcing 架构以及 PostgreSQL 的 WAL（Write-Ahead Logging）预写式日志等广泛采用。其核心优势体现在三个维度：

首先，不可变性保证了历史记录的完整性——日志条目一旦写入便不可修改，任意时间点的系统状态都可以通过从头重放（Replay）日志精确重建，这一特性被称为「事件溯源」（Event Sourcing），在金融交易系统和审计场景中尤为关键，因为它提供了完整的操作审计链；其次，顺序追加写入规避了随机写的 I/O 开销，在高并发场景下也不存在并发写入引发的数据竞争（Race Condition）问题；第三，也是在 Agent 工作流中最关键的一点——Append-Only 日志解决了 LLM 特有的「幻觉式重复」困境。

由于大型语言模型本质上是无状态的推理引擎，每次被唤醒时上下文窗口都是全新的，没有持久化执行历史的模型极易将已证明无效的方案重新「发明」出来，陷入反复踩坑的低效循环。这一问题有时被研究者称为「失忆性循环」（Amnesiac Loop）——系统表面上在运转，实则每次都在重复同样的错误探索路径，徒耗计算资源。Append-Only 日志为 Agent 构建了一个外部长期记忆（External Long-term Memory），弥补了 LLM 上下文窗口有限这一天然架构缺陷，使跨会话的知识积累成为可能。

没有这块记录，Loop 每次醒来都可能重新踩同一个坑，反复追着早就试过的噪声和错误跑。对于小型 Loop，Contract、State 和 Log 可以合并放在同一个 Markdown 文件里。

四类触发器：选对方式能大幅降低成本

很多人觉得 Loop 概念难以落地，部分原因就在于触发器类型的选择。作者将触发器分成四类：

1. Go Command（连续循环）

Codex 和 Claude Code 都支持 Go Command，可以设定条件和目标，让 Agent 一轮一轮跑下去，直到任务完成或触发轮次 / Token 上限。本质上是一个 While Loop，特别适合能马上拿到反馈的场景，比如修复 Bug 或按清晰 Spec 实现某段复杂逻辑。

2. 定时任务（Schedule）

如 Codex Automation 或 Claude Code Schedule，逻辑直接：每隔一段时间唤醒一次 Agent。与 Go Loop 的主要区别在于一个在云端跑，一个在同一会话里持续运行。

3. 事件驱动（Event-Driven）

让 Agent 对特定事件做出即时反应，比如新邮件进来、服务器发生 Incident 时立刻唤醒。

事件驱动触发器所依赖的 Webhook 机制，是现代 SaaS 生态系统集成的核心协议。与轮询（Polling）模式相比，Webhook 采用「推送」模型：当源系统发生事件时主动向目标 URL 发送 HTTP POST 请求，而非由消费者周期性查询。这一差异在高频低命中场景下具有显著的资源效益——以每 30 秒轮询一次、每天实际触发 10 次的场景为例，轮询模式每天产生约 2880 次无效请求，而 Webhook 仅发出 10 次请求，延迟也从秒级轮询间隔降低至近实时水平。Webhook 还是 GitHub Actions、Stripe 支付回调、Slack App 等主流平台事件集成的标准方式，其安全性通常通过 HMAC 签名验证机制保障，确保请求来源的合法性。

然而，这类触发在架构层面与 LLM API 的无状态调用模式存在根本张力：Webhook 要求消费端具备持久监听能力（长期在线的 HTTP 服务），而 Claude Code 和 Codex 的标准调用范式是「发起请求—等待响应—会话结束」的短生命周期模型，二者无法直接对接。在工程实践中，这个「阻抗不匹配」（Impedance Mismatch）问题通常通过引入消息队列（如 Redis Stream 或 SQS）加以缓冲——Webhook 事件先写入队列持久化，再由 Daemon 按节奏消费，避免在 Agent 处理繁忙时丢失事件。因此，通常需要自己起一个本地 Daemon 进程，暴露 URL 供 Webhook 打入，再由 Daemon 决策何时拉起 Agent 会话。

4. Combo / Workflow（组合式，最实用）

这是作者认为最有价值的一类。定时器照样触发，但不立刻唤醒 Agent，而是先跑脚本拉取数据、判断是否有新工作。以支持邮箱分流 Loop 为例：团队用 JavaScript 先从 Intercom 拉数据，检查过去 30 分钟有没有新的待处理更新，确实有工作才触发 Agent，否则直接跳过。

这种方式消耗更少的 Token 和资源，先攒批量工作再交给 Agent 统一处理。根据 Loop 类型选对触发方式，真的能把运行成本降很多。 后两类触发器需要自己搭本地脚本和 Daemon，作者团队为此开源了专门的工具来运行这类触发。

Agent 执行：调度、执行、验证三阶段

真正干活的 Agent 通常走三个阶段：收集信号找出待办工作并排优先级 → 执行任务 → 对复杂高风险任务（如工程 Ticket）让 Verifier 检查质量。

简单任务一个 Agent 可以包办全部三件事；复杂任务则拆成三个角色：调度智能体接收 Prompt、做研究和规划，拉起多个执行子 Agent 在隔离 WorkTree 里并行工作，每个执行器完成后交给 Verifier 跑测试、检查结果并将证据附到 PR 里。

这里的 WorkTree 指 Git 的 git worktree 功能——允许同一个仓库在文件系统的不同目录下同时检出多个分支，每个目录拥有独立的工作区（Working Tree）和暂存区索引（Index），但所有 worktree 共享同一个 .git 对象数据库（Object Store），这意味着提交历史、引用和配置都是统一管理的，不存在数据冗余。与 git clone 相比，git worktree 无需复制整个对象数据库，新增一个 worktree 的磁盘开销仅为几个指针文件，在大型 monorepo 场景下这一差异尤为显著。

这一设计与 Docker 容器的进程隔离思想异曲同工，却在资源消耗上更为轻量。在多 Agent 并行工作流中，git worktree 解决了一个核心工程难题：当多个 Agent 同时对同一代码库发起修改时，若共享同一工作区，文件锁竞争和未提交变更的相互污染将导致不可预期的冲突；而每个 Agent 在独立 worktree 中操作自己的分支，变更通过 PR 机制汇聚到主干，将分布式系统中「无共享架构」（Shared-Nothing Architecture）的隔离原则引入了 AI 编程工作流，是实现真正并行化 Agent 任务而不产生文件冲突的关键工程决策。值得一提的是，这种「各自在隔离分支工作、最终通过 PR 汇聚」的模式，与大型开源项目中 Fork-based 贡献模型高度契合，也意味着整套 Code Review 基础设施（包括 CI 检查、代码评审工具、Branch Protection Rules）可以无缝复用于 AI Agent 生成的变更，无需为 Agent 单独搭建验收通道。

这样人类 Review 起来轻松很多，所有更新也会写回 Loop Contract 文档。

Verifier：修改生产代码的前提

只要涉及修改生产代码或发送客户消息，Verifier 基本是必要前提。

Verifier 的设计哲学与测试驱动开发（TDD）和持续集成（CI）体系高度契合，但又存在本质区别：传统 CI 流水线依赖人工预先编写的静态测试用例，其验证逻辑在编写时即已固化，无法覆盖未预料到的边界行为；而 AI Verifier 具备动态推理能力，可以根据任务的具体上下文自适应地判断「什么叫验证通过」，例如对一个修复表单验证 bug 的 PR，Verifier 可以自行推断需要验证哪些边界输入组合，而无需人工预先枚举。

这种能力使 Verifier 在处理探索性修复和创造性任务时尤为有价值，但也意味着其验证结论本身需要人类保持一定程度的审查——AI Verifier 和它所验证的 AI Executor 都由语言模型驱动，存在「共同幻觉」（Correlated Failure）风险：两者可能对同一个错误假设形成共识，导致错误的修复通过了 Verifier 的验证却未被人类察觉。这是当前 AI 验证体系中尚未完全解决的核心挑战，也是为什么人类 Review 环节在关键修改中仍不可缺失的根本原因。在实践中，AI Verifier 与传统静态测试往往形成互补关系，而非替代：静态测试保障已知行为的回归防护，AI Verifier 则负责覆盖上下文相关的语义验证。

核心目标是让整个流程易于运行，同时产出人类容易 Review 的验证证据。实践方式包括：用 Playwright CLI 让 Agent 验证自己的工作并录制视频 / 截图作为证据——这借鉴了「验收测试」（Acceptance Testing）的理念，Playwright 作为专为现代 Web 应用设计的端到端测试框架，其 CLI 模式支持无头浏览器（Headless Browser）执行、自动截图和视频录制，使 Agent 可以在无图形界面的服务器环境中生成完整的视觉验证证据。Reviewer 无需亲自在本地复现场景，仅凭录屏即可快速判断修复是否符合预期，将 Code Review 的认知负担从「重建上下文并验证」降低为「核查证据并决策」；此外，用远程 Sandbox 环境执行任务，可以避免受限于本机同时跑多少 DevServer 的资源瓶颈。作者还将这些实践打包成了名为 Verifier Setup 的 Skill，可以直接交给 Claude Code 或 Codex 在真实代码库里搭好验证系统。

Evolve Loop：让循环自我进化

多数 Loop 刚起步时都不完美。触发器如何设计更省成本、如何把重复 SOP 变成脚本——这些优化其实可以交给更大的模型自己完成，只要把 Agent 现有配置、过去运行数据、日志和原始对话历史都提供给它。

做法很简单：每跑完 5 到 10 轮 Loop，启动一次专门的 Evolve Session。 在这个 Session 里，Agent 拿到当前配置和历史日志，判断哪些改动最值得优先处理。改动可以是 Loop Contract 本身，也可以是清理过期状态，或编写 Trigger Script 来处理重复动作。前面提到的 Support Loop，就是在 Evolve Run 过程中开始搭建程序化 Trigger 的——只在真正需要时才唤醒 Agent。

Evolve Loop 的价值不仅在于优化单次运行效率，更在于它将「元学习」（Meta-learning）的思想引入了工程自动化：系统不只是在完成任务，还在观察自己完成任务的方式并加以改进。这与 DevOps 领域的「持续改进」（Continuous Improvement）文化高度一致，但执行者从人类 SRE 变成了 Agent 本身。

从系统论的角度看，Evolve Loop 构成了一个典型的「双环学习」（Double-Loop Learning）结构——概念最早由管理学家 Chris Argyris 在 1970 年代提出，用以区分两种不同层次的学习：单环学习仅在既有框架内调整执行策略（「如何做得更好」），而双环学习则质疑并修正框架本身的假设（「我们是否在做正确的事」）。Evolve Session 中，Agent 不只是优化执行参数，而是有权重写 Contract、重构触发逻辑，这正是双环学习在自动化系统中的具体体现——系统具备了反思并修正自身运行规则的能力。

从最小可用的 Loop 起步

最适合入门的是 Documentation Maintainer Loop（文档维护循环）。大多数团队都有 README、CLAUDE.md、代码库说明等上下文文件，但这些内容很容易过期。这个 Loop 每天唤醒一次 Agent，检查过去 24 小时上线了什么、代码里有哪些 diff，再和 README、安装指南、Runbooks 对比——发现不一致时验证到底是代码对还是文档对；没发现过期内容就直接结束 Session；发现问题就做快速修复并开 PR。

值得注意的一个细节：Agent 有一种「哪怕没必要也想做点什么」的默认倾向。这一现象在 AI 对齐研究领域被称为「过度协助偏差」（Sycophancy / Over-helpfulness Bias），其根源在于 RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）的训练机制。

在 RLHF 流程中，人类标注员对模型的多个候选回复进行偏好排序，这些偏好标注随后被用于训练一个奖励模型（Reward Model），再通过 PPO（Proximal Policy Optimization，近端策略优化）等强化学习算法优化语言模型的输出分布。问题在于，人类标注员在评估时往往对「看起来有产出、内容丰富」的回复给予更高评分，即便任务本身并不需要额外输出——这种系统性偏差通过强化学习信号被放大并固化进模型权重，导致模型学会了即便任务已完成或无需操作时也倾向于生成看似有用的额外输出。斯坦福大学和 Anthropic 的研究均已证实这一现象的普遍性，在长对话场景中模型的迎合倾向会随对话轮次增加而显著加剧。

这一偏差在自动化工作流中还有一个隐蔽的放大效应：当 Evolve Session 中的 Agent 审阅历史日志时，「做了很多操作」的 Run 记录在外观上比「判断无需操作、直接退出」的 Run 记录看起来更「成功」，这可能导致 Evolve Agent 在修订 Contract 时无意间强化了「多做总比少做好」的行为倾向，形成正反馈循环。因此，在 Contract 和 Evolve Prompt 中都需要明确将「正确判断无需操作并退出」列为高质量行为，与「执行了有效修复」同等正面评价。

在自动化 Loop 场景中，这一偏差会产生直接的负面后果：文档被无故重写（即便内容仍然准确）、代码被不必要地重构（徒增引入 bug 的风险）、日志充斥着「优化建议」而非实际执行记录。因此，Contract 里需要明确写上「若文档内容准确，不得为显示工作成果而修改」之类的约束规则——这本质上是通过 System Prompt 层面的行为对齐干预，利用模型对显式指令的遵循倾向来覆盖其深层的训练偏差，将模型的默认行为校准至任务实际所需。

团队还内部开发了用于协调和配置这些 Loop 的工具，内置 Dashboard 追踪打开了哪些 PR、哪些已 Merge、健康分数如何提升，并默认内置 Evolve 行为（Dashboard 上每隔几个 Session 出现的蓝点就是 Evolve Run）。该工具已开源，内置 Documentation Maintainer、react-doctor-loop、tech-debt 清理等可直接复用的模板。

小结

从 Loop Contract 的宪法式定义，到四类触发器的成本权衡，再到调度—执行—验证的三段式 Agent 结构，以及自我进化的 Evolve Loop，这套方法论经过数月生产验证，呈现的不是一个 Demo，而是一套可落地的工程化体系。

它的核心启示在于：智能体自动化的价值不在于「能不能跑」，而在于护栏设计得是否足够稳、验证证据是否足够扎实，以及系统能否随时间自我改进。 对于希望将 Agent 真正带入生产环境的工程团队，这套结构值得逐条参考落地。

核心要点