前面我们讲了 Agent Loop。它是 Agent 能多步执行的最小内核。但真实工作里问题很快会变成另一种形态。不是帮我执行这一次。而是以后只要 PR 有新评论就帮我检查。 每天早上把重要信息汇总给我。 每晚跑一次文档漂移检查。 CI 失败时先自动定位原因。 发现依赖风险时生成修复草稿。这已经不是一次对话里的 Agent Loop这是目标驱动自动化。本系列把这类工程实践称为Loop Engineering。先把口径说清楚Loop Engineering 不是一个已经完全标准化的官方学科名。它更像是开发者社区对一组正在成熟的工程实践的命名。这些实践包括agent loop scheduled routines event-driven automation long-running agents verification loops human approval loops recovery loops它们的共同点是围绕一个目标让 Agent 在触发器、状态、工具、验证和恢复机制之间持续运行。一、从 prompt 到 routine手动提示的工作方式是人发现问题 人打开工具 人描述任务 Agent 执行 人检查结果这种方式适合临时任务但它有明显上限。人必须记得触发。人必须重复描述背景。人必须每次判断下一步。人必须发现失败。Routine 的工作方式不同它把一组配置保存下来目标 上下文 仓库或数据源 连接器 触发器 权限 验证方式 汇报方式然后在合适的时机自动运行。比如 Claude Code Routines 这类能力把 prompt、repo、connectors 和 triggers 组合成可复用任务。CLI 里的 schedule、GitHub 事件、API webhook本质上都是让 Agent 从“等人提问”变成“按条件触发”。这就是 Loop Engineering 的第一层变化从交互式调用变成持续任务。二、六个组件一个可用的 Loop Engineering 系统至少要有六个组件。2.1 Goal目标必须稳定。不能写成帮我看看项目有没有问题。这太宽。更好的目标是每天检查 docs/ 中是否存在与代码行为不一致的说明并生成修复建议。或者当 PR 出现 review comments 时分类为可自动处理、需要作者决策、需要人工确认三类。好的 Goal 应该包含对象 范围 成功标准 风险边界 输出形式2.2 TriggerTrigger 决定 loop 什么时候启动。常见触发器有四类。时间触发每天 9 点、每周一、每晚 事件触发PR、issue、CI、webhook 人工触发/loop、/schedule、按钮、命令 状态触发指标异常、任务积压、文档过期Trigger 不是简单的定时器它要带上触发上下文。比如哪个 PR 哪条评论 哪个 job 失败 哪些文件变化 上次运行结果是什么没有触发上下文Agent 每次都要重新探索。成本高也容易误判。2.3 StateState 是持续运行的核心。没有 StateAgent 每次启动都像失忆。State 至少包括上次运行时间 已处理对象 当前进度 重要决策 失败记录 待人工确认事项 预算消耗State 可以存在 session 里可以存在数据库里也可以存在仓库文件里。关键不是形式。关键是下一次运行能恢复任务。2.4 ActionAction 是 Agent 能做什么它来自工具和权限。比如读 PR 评论 拉取代码 运行测试 修改文件 提交 commit 写草稿 发 Slack 创建 issueAction 必须分级只读动作可以自动化可回滚动作可以在验证后自动化。外部副作用动作要审批。不可回滚动作要非常谨慎。2.5 VerificationLoop Engineering 的核心不是让 Agent 多跑而是让它每一轮知道自己是否接近目标。验证可以是测试通过 lint 通过 schema valid 引用来源完整 diff 符合范围 人工审批通过 LLM reviewer 通过没有 Verificationloop 会变成自动化幻觉。它会一直做事但你不知道它是否在变好。2.6 Recovery长期运行一定会失败工具会报错权限会过期网络会失败模型会走偏。上下文会污染预算会耗尽。所以 Recovery 不是兜底装饰它是核心组件。至少要设计retry rollback checkpoint pause escalate to human resume from state一个没有 Recovery 的 loop不应该接高价值任务。三、/loop、Routines、cron 和 headless agent这些东西经常被混在一起。但它们不是同一个层级。/loop更像交互式命令。让当前 Agent 在一个目标上持续执行直到满足条件或被停止。Routines更像保存好的 Agent 任务配置。它把 prompt、repo、connectors、触发器、权限和运行环境组合起来。cron headless agent更像开发者自己搭的自动化。定时触发一个无界面 Agent让它在 CI、服务器或工作流平台里运行。workflow engine更像确定性编排系统。Agent 只参与其中一部分步骤。所以选择时不要问哪个更高级要问谁负责触发 谁负责状态 谁负责权限 谁负责验证 谁负责恢复 谁负责审计如果这些问题没有答案换什么名字都不算工程化。四、什么时候适合用 LoopLoop 适合这类任务。第一重复发生。比如 PR 评论、issue triage、日报、周报、依赖检查。第二目标可验证。比如测试是否通过、草稿是否生成、链接是否有效、评论是否处理。第三路径有一定不确定性。如果路径完全固定用普通 workflow 就够了。第四失败能恢复。失败后能重试、暂停、回滚或升级人工。第五风险可分级。低风险动作自动执行高风险动作进入审批。典型场景包括PR babysitting daily digest issue triage nightly documentation drift check build failure auto-fix dependency update draft knowledge base freshness check这些任务不一定需要 Agent 全天候运行。它们需要的是在正确时机启动 拿到正确上下文 执行有限动作 完成验证 留下状态 必要时叫人五、什么时候不要用 LoopLoop 不适合所有任务。下面几类要谨慎。5.1 目标含糊比如让产品更好。 帮我优化增长。 自动维护整个项目质量。这类目标太宽。Agent 会在错误方向上很努力。5.2 高风险且不可回滚比如自动转账 自动删生产数据 自动发送大规模营销消息 自动改权限不是绝对不能自动化但不能只靠 loop。需要强审批、沙箱、审计和补偿机制。5.3 难以验证如果没有成功标准Agent 只能自说自话这比不自动化更危险。5.4 人类其实想要判断而不是执行有些任务看似重复其实核心价值在判断。比如定战略、定价格、定组织调整。这种场景可以让 Agent 准备材料。不要让它闭环决策。六、实战 Checklist把一个手动提示改成 Loop 前先检查这十二项。1. Goal 是否写成可验证目标 2. Trigger 是否清楚 3. Trigger 是否携带上下文 4. State 存在哪里 5. State 是否能恢复下一次运行 6. Action 是否分级 7. 哪些动作自动允许 8. 哪些动作必须审批 9. Verification 是否可执行 10. 失败后如何 retry / rollback / pause 11. 预算上限是什么 12. 如何向人类汇报结果和风险如果这些答案都清楚Loop 才有资格进入长期自动化。七、最后Loop Engineering 不是把 prompt 重复运行也不是让 Agent 一直跑。它的核心是围绕目标设计可持续执行系统。Prompt 让任务说清楚。Context 让每一步看对信息。Harness 让 Agent 有工具、权限、验证和观测。Loop 把这些能力变成持续运行的自动化。下一篇我们进入最容易翻车的部分长运行 Agent。因为 loop 一旦拉长三个问题会被放大上下文会断。 目标会漂。 成本会爆。参考资料Claude Code Docs: Routines and scheduled routinesOpenAI Agents SDK: Runner, sessions, handoffs and human-in-the-loopAnthropic: Effective Harnesses for Long-Running AgentsAnthropic: Long-running Claude for Scientific ComputingAnthropic: Building Effective AI Agents参考文献第十三篇Loop Engineering从手动提示到目标驱动自动化