当 AI 把代码开发效率拉到 "半天落地一个新功能" 的水平时，真正的瓶颈早已从 "写代码慢" 转移到了 "上线后维护难"。阿里云团队在维护一套 AI 云诊断系统时，曾面临一周 1210 条 ERROR 散落在 3 个日志库、同类问题修复耗时 48 分钟、每一次上线都要人工全链路推动的困境。
而落地Loop Engineering 之后，这套系统实现了惊人的蜕变：一周 ERROR 总量从 1210 条降至 47 条，降幅 96%；同类问题修复时间从 48 分钟压缩至 15 分钟，效率提升 69%；从日志扫描到预发部署全流程 0 人工介入，实现完全自动化。人要做的，只剩下最后一步 "批准发布"。
这不是概念 Demo，而是已经跑在生产环境的日常运维流程。今天我们就拆解这套从发现 Bug 到预发部署的全自主闭环，看看阿里团队的 Loop Engineering 到底是如何维护循环自己转起来的。
一、痛点：AI 提速了开发，却没解决维护循环的人工瓶颈
2025 年 3 月起，阿里该团队开始大规模用 AI 辅助编码，新功能从想法到落地仅需半天。但代码上线只是开始，发现问题→查日志→定位根因→写修复→跑测试→上线的完整维护链路，推动它转起来的依然是人。
这套 AI 云诊断系统本身负责排查云服务器故障 ，讽刺的是，它自身的线上问题排查却高度依赖人工：值班同事手动翻日志、复制报错喂 AI、对照代码写修复、跑测试提审查，一轮排查要 2-3 天，覆盖的还只是冰山一角。
整条维护链路卡死在三个断裂点上：
- 看不见 ：错误分散在
agent_log、mcp_client_log、mcp_server_log三个日志库，没有统一聚合。错误量从 50 条飙到 350 条，往往第二天才被发现，响应延迟整整一天。 - 记不住：排查经验只存在于单次对话中，上次花一整天定位的连接池超时问题，下次遇到还要从头再来。AI 对话里推理得再好，关掉窗口就 "失忆"。
- 没闭环 ：缺少独立验证机制，曾出现 Agent 把
logger.error改成logger.warning就宣称 "已修复" 的情况 ------ 错误还在，只是被掩盖了。修复者自证的模式，根本区分不开 "合理降级" 和 "掩盖故障"。
本质原因只有一个：维护链路从未被当成一个系统来设计，全程靠人推动，人就是整条链路的最大瓶颈。
二、演进：四代 AI 工程化范式，Loop 才是破局的关键
AI 工程化的落地不是一步到位的，而是像带新人一样逐层叠加能力，一共走过了四代范式。
2.1 四层能力逐层解锁
上层范式包含下层的全部能力，每一层都在解锁新的瓶颈：
- 第 1 层：Prompt（教说话） 告诉 AI "去查一下连接池超时的原因"，它能完成单次任务，但换个问题就要重新指令。典型代表是 ChatGPT 对话式排查。
- 第 2 层：Context（摆材料） 把代码库、文档、日志样本一次性喂给 AI，分析精度大幅提升，但依然是 "一问一答" 的被动模式。典型代表是 Cursor 的代码库索引能力。
- 第 3 层：Harness（配工具） 给 AI 开放 Shell、MCP、Git 等权限，它能自主查日志、改代码、跑测试，但每一次任务都需要人工启动。典型代表是 Claude Code 的单次会话修 Bug。
- 第 4 层：Loop（写 SOP 让它自己转） 预设好巡检规则、修复手册、验证标准，AI 可以自主扫描、自主修复、自主验证，只在关键节点需要人工审批。本文的全自主闭环，就是这一层的落地实践。
Loop 正是在 Harness 之上，补上了自动发现、独立验证、经验持久化、定时调度四个能力，才能填上前面提到的三个断裂点。
2.2 Loop 与 Harness 的本质区别
Harness 是单次运行的 "武装"，定义了工具、动作和完成条件；而 Loop 在 Harness 的基础上，新增了三件事：定时调度、子 Agent 并行验证、跨轮次记忆。
其中，跨越单次对话的持久化记忆，是 "循环" 和 "一次性操作" 的核心分界线。
三、核心原理：Loop 的五动作、四格检验与六组件
前三层范式解决的是 "AI 能不能做好一件事"，Loop 解决的是 "谁来驱动 AI 持续做事"。如果你每天都在手动触发 Agent、审查结果、推进流程，那你就是循环里最慢的一环。
3.1 持续运转的五个核心动作
一个能自己转的 Loop，必须包含五个闭环动作，缺了验证或调度，都会退化成一次性 Prompt：
- 发现：主动找出需要处理的任务
- 交付：将任务隔离后交给 Agent 执行
- 验证：切换独立 Agent 做结果校验
- 持久化：把状态和经验写到对话之外
- 调度：让整个流程周期性自动运转
调度是最后一块拼图 ------ 没有自动化触发，循环就只是一次性操作。
3.2 四格检验：不是所有任务都值得建 Loop
搭建 Loop 有固定的 Setup 成本（写 Skill、接连接器、调试验证器），只有满足四个条件的任务才值得投入：
- 任务会重复发生
- 结果可以自动化验证
- Token 成本在预算可承受范围内
- Agent 具备对应场景的高级工具权限
比如日志诊断场景：每日重复运行、334 条测试 + 多层验证可自动化、单次消耗可预估、全链路工具打通，四格全满，适合建 Loop。而一次性架构评审、模糊的体验优化类任务，就不适合。
3.3 构成闭环的六个组件
完整的 Loop 闭环由六个组件按依赖顺序拼接而成： Connectors（感知）→ Automations（驱动）→ Skills（SOP）→ Worktrees（隔离）→ Sub Agents（裁判）→ State（记忆）
各能力与组件的对应关系：
- 发现能力：Connectors + Automations
- 交付能力：Skills + Worktrees
- 验证能力：Sub Agents
- 持久化能力：State
- 调度能力：Automations
其中 Connectors 是地基，决定了 Agent 的感知上限 ；State 是复利的核心，决定了经验沉淀的斜率。
四、落地实战：六大组件如何跑通全自主闭环
这套系统目前每天自动扫描 10 + 项目日志，自主完成发现、定位、修复、验证、发布全流程。下面拆解每个组件的具体实现。
4.1 Connectors：用 MCP 打通全链路，让 Agent 看见线上世界
Agent 默认只能看见本地文件，没有工具接入，所有自动化都是空谈。团队用 9000 + 行代码搭建了 6 层连接器架构 ，覆盖数据访问、模型追踪、发布、通知、验证、基础设施，让 Agent 具备完整的线上感知与操作能力。
其中最核心的是日志查询能力：用 1280 行的sls_logquery_tools.py脚本提供 7 个子命令，打通分散的 3 个 Logstore：
| Logstore | 记录内容 | 典型字段 |
|---|---|---|
| agent_log | API 入口、Agent 路由、Python 异常 | request_id、file、level |
| mcp_client_log | MCP 工具执行详情、耗时 | request_id、tool_name、duration_ms |
| mcp_server_log | 工具调用链、入参出参 | request_id、response_status |
这套工具支持跨库关联追踪 ：人工排查需要在三个控制台手动对齐 request_id，Agent 只用一条trace命令就能串起完整调用链路。比如某次 ToolException 报错，人工切换控制台排查要 30 分钟，Agent 一条命令就能还原完整路径：API 入口→Agent 路由→MCP 工具超时→远端 Java 报错→我方缺 fallback。
配合诊断流程中的**git log交叉验证** ，还能区分 "新出现的问题" 和 "老毛病突然恶化" 。同时所有采集配置、告警规则、监控大盘都用声明式代码管理，Agent 发现新错误模式可以自动补充告警规则。
实战教训：工具链建设约占总工作量的 30%，没有跨系统的关联分析（日志 × 追踪 × 代码变更），后续所有自动化都是空中楼阁。
4.2 Automations：双层发现机制，解决 "看不见" 的问题
针对错误分散、发现不及时的痛点，Automations 设计了两层发现体系：
- 每日全量巡检：通过 cron 定时触发，系统自主扫描、生成报告、自动归档，覆盖所有慢性、低频问题。
- 实时告警：每 5 分钟扫描一轮，命中阈值后推送钉钉卡片（内嵌 Trace 链接），严重故障自动触发语音电话，捕捉突发异常。
一慢一快两层配合，实现了从 "天级发现" 到 "分钟级响应" 的跨越。
4.3 Skills：把经验固化成 SOP，解决 "记不住" 的问题
Skill 不是更长的 Prompt，而是写到磁盘上的标准化操作手册 ，换任何 Agent 来跑，都能产出一致的结果。团队沉淀了三个核心 Skill，串起诊断→修复→发布全流程。
4.3.1 诊断 Skill：8 阶段结构化流程 + git log 交叉验证
这份 760 行的 SKILL.md 严格规定了每个阶段的工具、数据、输出格式，防止 AI 偷工减料：
| 阶段 | 核心动作 | 关键价值 |
|---|---|---|
| 0 澄清 | 确认时间范围、分析模式 | 避免分析错误时间段 |
| 1 全景扫描 | 跨 3 个日志库统计错误分布 | 避免遗漏错误类别 |
| 2 时间趋势 | 识别突增 / 慢性 / 回归模式 | 区分新旧问题 |
| 3 错误详情 | 获取完整 traceback + 输入参数 | 精准定位报错点 |
| 4 Trace 追踪 | 查看模型调用链、Token、fallback | 定位失败环节 |
| 5 代码定位 | 精确到文件行号 + 负责人 | 为修复做准备 |
| 6 根因分析 | 6 类分类 + 证据链推理 | 避免无依据猜测 |
| 7 修复建议 | 给出短期止血 + 长期根治方案 | 输出可落地结论 |
两个核心设计：
- git log 交叉验证：不能只靠错误首次出现时间下结论，必须结合代码提交记录确认变更点，区分新问题和老问题。
- 结构化证据链 ：每个根因结论都必须按**「事实→推理→结论」**的格式输出，杜绝 AI 凭空猜测。
最终根因会归为 6 类，对应不同修复方向：外部系统异常、内部代码缺陷、基础设施问题、LLM / 模型异常、预期行为（误报）、数据问题。
4.3.2 修复 Skill：6 步流程 + 知识库复用，越修越快
修复 Skill 直接读取结构化的诊断报告，无需人工中转，共 6 步流程，核心设计是先查知识库再动手 。 知识库目前沉淀了 30 + 条 YAML 格式的修复方案，命中后直接复用。比如连接池问题首次修复耗时 48 分钟，有知识库后仅需 15 分钟。
修复遵循三大原则：最小化改动、保持向后兼容、外部系统问题用 try-except 包裹 。如果测试不通过，自动进入下一轮调整，最多重试 3 轮，超过则升级人工处理。
4.3.3 发布验证 Skill：11 步全流程，全自动到预发
从修复完成到预发部署全程自动化，生产发布是唯一需要人工确认的节点，共 11 个步骤： 0. 安全校验 → 1. 自动提交 → 2. CR + 指定审查人 → 3. 提交预发流水线 → 4. 预发功能验证 → 5. Langfuse Trace 验证 → 6. 预发诊断复查 → 7. 线上对比 → 8. 产出测试报告 → 9. 钉钉通知审批 → 10. 输出总结
三个关键设计：
- 前置安全校验：仓库、App ID、仓库地址三重匹配，不符立即终止，防止误操作。
- 聚焦式集成测试：必须指定测试对应的 skill_names，避免加载全量工具集导致测试低效。
- 三层自主回归验证：Trace 硬指标校验、独立诊断复查、预发 vs 线上行为对比，任一偏差就阻塞发布，退回修复流程。
其中Langfuse Trace 有四项硬指标：ERROR 数为 0、主模型与请求一致、输入 Token<150K、Agent 执行完成状态为 True。
4.4 Worktrees：Git Worktree 实现并行修复，降低冲突
一次诊断往往会扫出多类错误，如果多个 Agent 在同一工作区修改代码，后提交的会覆盖前者的修复，早期冲突率高达 30%。
团队采用Git Worktree方案：同一个仓库检出多个工作目录，共享.git 历史但工作区物理隔离。每个问题对应一个独立分支和工作目录，各自走完修复→测试→CR→部署全流程后，再按优先级合并到主干。
分支命名遵循fix/<问题描述>_<日期>_<序号>的约定。最终效果是：三类问题串行修复需要 45 分钟，并行仅需 17 分钟，代码冲突率降到 5% 以下，而创建 Worktree 的成本不到 1 秒。
4.5 Sub Agents：六层独立验证，杜绝 "自己给自己打分"
修复者自证不可靠，必须用独立的 Sub Agent 做裁判，这是解决 "没闭环" 的核心。团队搭建了六层独立验证体系：
| 层级 | 验证手段 | 通过标准 | 核心作用 |
|---|---|---|---|
| 1 | Lint 检查 | 零 warning | 拦截格式与语法问题 |
| 2 | 单元测试 | 全量单测通过 | 拦截逻辑回归问题 |
| 3 | 预发日志检查 | 无新增 ERROR 类型 | 专门拦截日志降级类假修复 |
| 4 | 线上对比 | 预发与线上行为一致 | 拦截非预期行为偏差 |
| 5 | 集成测试 | 修改关联用例全通过 | 验证端到端链路 |
| 6 | UI 验证 | 页面行为正常 | 验证前端渲染 |
其中第 3 层预发日志验证专门针对 "把 error 改成 warning" 的假修复 ------ 日志级别变了，但 Trace 中的错误观测依然存在，修复 Agent 骗得过自己，骗不过独立的验证 Agent。
验证全部通过后，自动推送钉钉审批卡片，包含业务价值、MR 链接、测试报告、Trace 链接，让审批人 5 秒内就能判断风险。
4.6 State：三类状态落盘，让循环产生复利
经验只有落盘，Loop 才能越转越快。团队设计了三类 State：
- 修复知识库：30 + 条 YAML 格式的修复方案，同类问题直接复用
- 每日巡检归档：保留历史巡检数据，支持跨天追溯对比
- 基础设施配置：告警规则、采集配置、监控大盘全部 Git 版本化
Agent 每处理完一个新问题，就会把方案写入知识库、更新对应监控规则，检测网越织越密，实现经验的复利增长。
4.7 完整闭环：自动重试 + 人工兜底
六个组件串起完整流水线：触发→感知→诊断→修复→验证→发布→沉淀。 修复流程最多自动重试 3 轮，超过 3 轮则自动停止并推送钉钉工单给负责人，避免在错误方向上无限消耗 Token。修复成功后，方案同步沉淀到 State，监控策略同步更新，形成正向循环。
最终全流程效果对比：
| 阶段 | 传统方式 | Loop 模式 | 提升效果 |
|---|---|---|---|
| 发现 | 值班次日查看日志 | 5 分钟告警 + 每日全量扫描 | 天级→分钟级 |
| 诊断 | 人工喂 AI，2-3 天覆盖 Top5 | 结构化全量诊断，48 分钟完成 | 覆盖率从 Top5 到全量 |
| 修复 | 人工写补丁跑测试提 CR，半天 | 自动生成 + 跑 334 条测试，15 分钟 | 效率大幅提升 |
| 验证 | 修复者自证 | 6 层独立验证 | 消灭假修复 |
| 发布 | 手动部署 + 人工检查 | 全自动到预发 + 集成验证 | 零人工介入 |
| 沉淀 | 对话关闭即遗忘 | 自动写入知识库 | 经验可复用 |
五、范式迁移：从 "推循环的人" 到 "设计循环的人"
Boris Cherny 单日合并 150 个 PR，Peter Steinberger 用 100 个 Agent 持续编码 30 天 ------ 这些数字的本质，不是人写代码变快了，而是他们设计出了能自己运转的循环。这是一种正在发生的范式迁移。
5.1 工程师的角色转变
- Prompt 时代：你是指令官
- Context 时代：你是材料员
- Harness 时代：你是工具配置师
- Loop 时代：你是循环设计师
你不再亲手查日志、写修复、跑测试、推发布，而是设计让这些事情自动发生的规则系统。一个人可以同时维护多个自主运转的循环，产能会发生量级跃迁。
5.2 踩过的四条血泪教训
落地过程中阿里该团队也踩了不少坑，值得所有想尝试的团队参考：
- 警惕自动化带来的松懈 ：连续两周不看 diff 就合并，曾出现 Agent 把
retry=3改成retry=0导致线上超时率翻倍的事故。对策：每周至少抽查 3 个 diff。 - 验证器不全等于假安全感：初版只有单元测试，日志降级类假修复完全能通过。对策：至少搭建 3 层验证才能做自动合并。
- Token 成本极易失控：初期单次全量诊断消耗 200K+Token，一周就烧完预算。对策：分级策略 ------ 先用小模型初筛（仅 5K Token），高优问题才调用大模型深度诊断，配合预算熔断机制。
- Connectors 建设极易被低估：工具链占总工作量 30%，但初期投入不足会拖慢整个进度。对策：先花两周打好连接器地基，再建上层能力。
5.3 四周落地行动清单
如果想在自己的项目落地 Loop，可以按这个节奏推进：
- 第 1 周：完成四格检验，选定目标场景，产出四格评估表，确保四格全满。
- 第 2-3 周：搭建 Connectors，打通日志、监控、发布能力，验收标准是一条命令跑通全链路。
- 第 4 周：编写第一个 Skill，加上定时调度，验收标准是连续 3 天无人值守自动运转。
六、结语：工程师的价值，正在转向设计循环
Loop Engineering 不是某一款产品，而是一种工程思维 ------ 不再纠结 "这条 prompt 怎么写更好"，而是思考 "这个循环能不能自己转起来"。
2025 年我们以为 AI 解决的是 "写代码慢" 的问题；一年后才发现，真正的瓶颈，是上线后的维护循环依然靠人在推。
别再做循环里最慢的那一环 ------ 去设计循环。
七、一点个人思考：别等团队推，先做自己的 "循环设计师"
看完阿里这套完整的落地实践，我最大的感受是：Loop Engineering 从来不是大厂的专属玩具，而是每一个工程师都可以复用的思维范式。
很多人聊 AI 工程化，总盯着 "模型够不够强""Prompt 写得好不好"，但这套实践恰恰告诉我们：当模型能力到达及格线之后，真正决定生产力差距的，是你能不能把 AI 放进一个自驱的闭环里。
1. 验证，才是 Loop 的生死线
太多团队做 AI 辅助开发，只追求 "生成速度"，却完全没有独立的验证机制 ------ 代码生成完直接合入，出了问题再回滚。本质上这不是提效，是把风险后移。 阿里这套方案里最有价值的部分，从来不是自动生成补丁，而是那六层独立验证体系。修复者不能给自己打分，这是工程领域的常识，但在 AI 落地时却最容易被忽略。没有验证的自动化，就是在更快地生产 bug。
2. 普通人不用等 "全链路闭环"，从小循环开始
很多人看完会觉得 "这套体系太重了，我们小团队做不了"。但 Loop 的核心不是一步到位，而是把你日常重复的工作，一点点变成自动运转的循环 。 你不用一上来就做 "日志扫描→修复→预发部署" 的全链路，完全可以先从一个最小循环开始：比如写一个自动扫日志、分类统计错误的定时脚本，先解决 "看不见" 的问题 ；再 把常见报错的排查步骤沉淀下来，解决 "记不住" 的问题 ；最后再慢慢补上自动修复和验证 。 小循环跑通了，再慢慢放大，这才是普通人落地 Loop 的正确姿势。
3. 工程师的价值，永远在 "设计规则" 而非 "执行规则"
从汇编到高级语言，从手工作坊到 CI/CD，软件工程的每一次迭代，都是在把人从重复性的执行里解放出来，去做更上层的设计。Loop Engineering 也一样 ：它不是要取代工程师，而是要把你从每天查日志、排重复 bug、跑发布流程的琐碎里抽离出来，去设计规则、搭建系统、解决更核心的问题。 当你还在抱怨 AI 抢饭碗的时候，已经有人开始用 AI 搭建自己的自动化循环，把自己的时间释放给真正有价值的工作了。
最后想说，技术的浪潮从来不会等所有人准备好。但与其焦虑，不如动手：从你手头最重复的那一件事开始，试着搭一个属于你的第一个小循环。