前面我们讲了 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 Trigger
Trigger 决定 loop 什么时候启动。
常见触发器有四类。
时间触发：每天 9 点、每周一、每晚 事件触发：PR、issue、CI、webhook 人工触发：/loop、/schedule、按钮、命令 状态触发：指标异常、任务积压、文档过期Trigger 不是简单的定时器，它要带上触发上下文。
比如：
哪个 PR？ 哪条评论？ 哪个 job 失败？ 哪些文件变化？ 上次运行结果是什么？没有触发上下文，Agent 每次都要重新探索。成本高，也容易误判。
2.3 State
State 是持续运行的核心。没有 State，Agent 每次启动都像失忆。
State 至少包括：
上次运行时间 已处理对象 当前进度 重要决策 失败记录 待人工确认事项 预算消耗State 可以存在 session 里，可以存在数据库里，也可以存在仓库文件里。
关键不是形式。关键是下一次运行能恢复任务。
2.4 Action
Action 是 Agent 能做什么，它来自工具和权限。
比如：
读 PR 评论 拉取代码 运行测试 修改文件 提交 commit 写草稿 发 Slack 创建 issueAction 必须分级，只读动作可以自动化，可回滚动作可以在验证后自动化。
外部副作用动作要审批。不可回滚动作要非常谨慎。
2.5 Verification
Loop Engineering 的核心不是让 Agent 多跑，而是让它每一轮知道自己是否接近目标。
验证可以是：
测试通过 lint 通过 schema valid 引用来源完整 diff 符合范围 人工审批通过 LLM reviewer 通过没有 Verification，loop 会变成自动化幻觉。
它会一直做事，但你不知道它是否在变好。
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 只参与其中一部分步骤。
所以选择时不要问：
哪个更高级？要问：
谁负责触发？ 谁负责状态？ 谁负责权限？ 谁负责验证？ 谁负责恢复？ 谁负责审计？如果这些问题没有答案，换什么名字都不算工程化。
四、什么时候适合用 Loop
Loop 适合这类任务。
第一，重复发生。
比如 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 全天候运行。
它们需要的是：
在正确时机启动 拿到正确上下文 执行有限动作 完成验证 留下状态 必要时叫人五、什么时候不要用 Loop
Loop 不适合所有任务。
下面几类要谨慎。
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 routines
- OpenAI Agents SDK: Runner, sessions, handoffs and human-in-the-loop
- Anthropic: Effective Harnesses for Long-Running Agents
- Anthropic: Long-running Claude for Scientific Computing
- Anthropic: Building Effective AI Agents
参考文献：
第十三篇：Loop Engineering，从手动提示到目标驱动自动化
