当 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 天，覆盖的还只是冰山一角。

整条维护链路卡死在三个断裂点上：

1. 看不见：错误分散在agent_log、mcp_client_log、mcp_server_log三个日志库，没有统一聚合。错误量从 50 条飙到 350 条，往往第二天才被发现，响应延迟整整一天。
2. 记不住：排查经验只存在于单次对话中，上次花一整天定位的连接池超时问题，下次遇到还要从头再来。AI 对话里推理得再好，关掉窗口就 “失忆”。
3. 没闭环：缺少独立验证机制，曾出现 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：

1. 发现：主动找出需要处理的任务
2. 交付：将任务隔离后交给 Agent 执行
3. 验证：切换独立 Agent 做结果校验
4. 持久化：把状态和经验写到对话之外
5. 调度：让整个流程周期性自动运转

调度是最后一块拼图 —— 没有自动化触发，循环就只是一次性操作。

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 踩过的四条血泪教训

落地过程中阿里该团队也踩了不少坑，值得所有想尝试的团队参考：

1. 警惕自动化带来的松懈：连续两周不看 diff 就合并，曾出现 Agent 把retry=3改成retry=0导致线上超时率翻倍的事故。对策：每周至少抽查 3 个 diff。
2. 验证器不全等于假安全感：初版只有单元测试，日志降级类假修复完全能通过。对策：至少搭建 3 层验证才能做自动合并。
3. Token 成本极易失控：初期单次全量诊断消耗 200K+Token，一周就烧完预算。对策：分级策略 —— 先用小模型初筛（仅 5K Token），高优问题才调用大模型深度诊断，配合预算熔断机制。
4. 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 搭建自己的自动化循环，把自己的时间释放给真正有价值的工作了。

最后想说，技术的浪潮从来不会等所有人准备好。但与其焦虑，不如动手：从你手头最重复的那一件事开始，试着搭一个属于你的第一个小循环。

---

本文参考：Loop Engineering 实战：实现从日志扫描到预发部署的全自主闭环