Agent Loop 不只是重复执行——从 Claude、Codex 到生产级可靠性
原文：《Claude、Codex、Mira 都在讲 Loop，架构师更该看什么》— 若飞，公众号「架构师」
一句话结论
Loop 的本质不是自动化，而是可靠性。先确保每轮能拿到可信反馈、能验证、能停止，自动化才能建在稳固的地基上。
核心观点
1. Loop ≠ 重复执行，而是"带约束的反馈机制"
Loop 要跑得稳，四个要素缺一不可：
- 目标可验证：怎么判断"做完了"
- 反馈可获取：每轮结果能不能被判断对错
- 状态可继承：上轮发生了什么，下轮知道
- 停止条件明确：什么时候该停、什么时候交还给人
缺任何一项，Loop 就会变成"模型一直在忙，但没人说得清它到底推进了什么"。
2. 经典高可靠架构经验可以直接复用
| 传统架构概念 | Agent Loop 落地方式 |
|---|---|
| SLO / 错误预算 | 允许多少失败、返工、误判 |
| 健康检查 | 每轮是否有证据、工具是否可用 |
| 超时/重试/熔断 | 一轮跑多久、失败几次就停 |
| 隔舱/配额 | 任务、工具、权限隔离 |
| 降级/补偿 | 结果不可信时退回草稿或人工确认 |
| 可观测 | 留下输入、动作、错误、证据链 |
3. 状态机 > 聊天上下文
纯对话式 Loop 容易出现"步骤依赖不清、失败恢复无边界"。正确做法是把控制流外置：
待触发 → 运行中 → 等待验证 → 验证通过 ✅
├→ 验证失败 → 重试
├→ 风险超界 → 交还给人
└→ 无新增证据 → 停止
4. 代码场景先成熟，因为反馈有"硬裁判"
代码有测试、lint、类型检查作为硬标准，失败就是失败。日常场景（会议纪要、邮件）反馈强度弱，需要分级处理。
5. 日常场景按风险分级
| 风险等级 | 任务类型 | 处理规则 |
|---|---|---|
| 低风险 | 日程摘要、群聊要点 | 自动生成，保留来源 |
| 中风险 | 会议纪要、邮件草稿 | 先出草稿，人确认后使用 |
| 高风险 | 对外承诺、付款、删数据 | 默认不自动闭环，只准备依据 |
6. 人从"执行者"变成"规则设计者"
一段 prompt 写得差，只会得到一次差结果。一个 Loop 设计得差，会稳定地产生差结果。
落地方法论
任务筛选四问
- 是不是重复发生、流程相近？
- 有没有测试/规则/审批/日志反馈？
- 出错后能不能撤回？
- 每轮能不能留下证据？
前两个不满足 → 用普通 prompt 或脚本。后两个不满足 → 只让 Agent 做草稿和建议。
落地顺序（别跳级）
- 先让一次手动执行稳定
- 把规则沉淀成文档/Runbook
- 加上验证和停止条件
- 最后再接定时/事件/工具
Loop 可观测指标
| 传统 SRE 信号 | Loop 对应指标 |
|---|---|
| 延迟 | 单轮耗时、触发到交付总时间 |
| 流量 | 每天触发次数、并发 Loop 数 |
| 错误 | 验证失败率、人工打回率 |
| 饱和度 | token 消耗、队列积压、API 配额 |
最佳起点
从低风险、重复、可复核的小任务起步。示例——「每日 CI 失败分流」：
- 触发：每天 9 点
- 输入：失败 job、相关 PR、日志摘要
- 动作：归类失败原因，生成处理建议
- 限制：只写 triage 文档，不直接改代码
- 验证：每条结论带日志片段或 PR 链接
- 停止：处理完、超 30 分钟、找不到证据
- 交还：涉及回滚、删测试、生产配置时只给建议
文章来源：微信公众号「架构师」，作者若飞