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

阿里妹导读

文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。

1 引子：

Loop Engineering 的目标不是写得更快，

而是让你从维护循环里撤出来

Boris Cherny 单日合并 150 个 PR；Peter Steinberger 同时跑 100 个 AI Agent 持续编码 30 天。数字背后指向同一核心：瓶颈不在代码生成速度，而在能否设计出自主运转的维护循环。

能跑起来的循环不等于有用的循环——循环的本质，是生成器接上验证器。没有验证器，自动化只是在更快地消耗 Token。

指标	Before	After	变化
一周 ERROR 总量	1210 条	47 条	↓ 96%
同类问题修复时间	48 分钟	15 分钟	↓ 69%
人工介入次数（到预发）	每次都要	0 次	全自动

表 1-1：Before/After 效果对比（三项指标分别对应发现速度、修复效率、人工介入三个断裂点）

上述数据源自同一条日常链路：一句指令，Agent 从 3 个日志库挖掘 Bug → 诊断根因 → 生成补丁 → 运行 334 条测试 → 提交 CR → 预发部署 → 集成验证 → 钉钉通知审批。人工仅需点击「批准发布」。

这并非概念验证，而是我们维护 AI 云诊断系统的日常。全文沿三条主线展开：

1. 日志分析自主挖 Bug— 跨 3 个 Logstore 关联、7 子命令 + git log 交叉验证

2. Bug 自主修复闭环 — 发现 → 诊断 → 补丁 → 测试 → 预发部署，全程 Agent 驱动

3. 一条指令或定时触发跑完全流程 — 人工一句话触发，或 Automation 每日自动跑：开发 → 部署 → 测试 → 预发 → 线上对比

2 痛点：AI 写代码快了，

但发现→修复→上线的维护循环仍靠你推

2026 年 6 月第二周，我们一周捞出 1210 条 ERROR——散落在 3 个日志库，类型涵盖上游超时至 LLM 幻觉。

自 2025 年 3 月大规模应用 AI 写代码以来，新功能从构思到实现仅需半天。然而，代码完成仅是开始。

真正耗时的是上线后的维护循环：发现问题 → 查日志 → 定位根因 → 写修复 → 跑测试 → 上线。AI 加速了编码，但推动循环运转的仍是人力。

我们维护着一套 AI 驱动的诊断系统，用于排查云服务器故障。讽刺的是：该系统本身也存在大量线上问题待修。

值班人员打开日志控制台，仅能看到热门条目。每条需手动复制、喂给 AI、核对代码、编写修复、运行测试、提审、等待发布。一轮排查耗时 2–3 天，覆盖范围不过冰山一角。

图 2-1：人工驱动维护循环的瓶颈——任一环节卡住，整条链路停转；人推循环 = 单线程瓶颈

2.1 维护循环卡死的三个断裂点：

看不见、记不住、没闭环

看不见。错误散落在三个日志库（agent_log、mcp_client_log、mcp_server_log），缺乏聚合。某日错误量从 50 条飙升至 350 条，次日才被发现——延误整整一天。

记不住。上次排查连接池超时耗费整天（根因为某方法设置 2 秒激进超时），下次遇到同类问题仍需从头开始。AI 在对话中推理出色，但关闭对话即失忆。

没闭环。曾有 Agent 声称「已修复」，实则仅将 logger.error 改为 logger.warning。错误依旧存在，只是不再上报。区分「掩盖故障」和「合理降级」需要独立验证，不能依赖修复者自证。

根因只有一个：维护链路从未被视作一个需要设计的系统。它依赖人力推动，人即是瓶颈。这三点缺位，正是前三代 AI 工程化未能填补的坑——接下来探讨 AI 工程化的演进阶段，以及为何到了 Loop 层才能真正填平这些断裂点。

3 演进：从 Prompt 到 Loop，

四代 AI 工程化范式逐层叠加

AI 工程化历经四层演进，如同培养新人：

第 1 层：先教说话（Prompt）——告知新人「去查连接池超时原因」，他能执行一次，但下次换题仍需重述。典型：ChatGPT 对话式排查。

第 2 层：再摆材料（Context）——一次性提供代码库、文档、日志样本，他能给出更精准分析，但仍是你问一句他答一句。典型：Cursor 带 codebase 索引。

第 3 层：再配工具（Harness）——赋予 Shell、MCP、Git 权限，他能自查日志、改代码、跑测试，但每次均需你启动。典型：Claude Code 单次会话修 Bug。

第 4 层：最后写 SOP 让他自己转（Loop）——制定巡检规则、修复手册、验证标准，他每日自扫、自修、自验，你仅在关键节点审批。典型：本文实践。

上层包含下层所有能力，每层解锁新瓶颈：

图 3-1：四代 AI 工程化范式演进——

选范式前先问：你的任务卡在哪一层瓶颈

Loop 在 Harness 之上补全自动发现、验证、持久化与调度，从而填平三个断裂点：

→ 看不见→ 发现（Connectors + Automations）

→ 记不住→ 持久化（State + Skills）

→ 没闭环→ 验证（Sub Agents）

理清四层关系后，具体定义：Loop 层包含什么？如何判断任务是否该建 Loop？需要哪些组件？

4 原理：Loop 是让 AI 自己发现工作、

验证结果并记住经验的系统设计方法

前三层解决「AI 能否做好一件事」，Loop 解决「谁来驱动 AI 持续做事」。若你每日手动触发 Agent、审查结果、推进流程——你便是循环中最慢的一环。

Loop 与 Harness 的本质区别：Harness 是一次性运行的武装——工具、动作、完成条件。Loop 在 Harness 基础上增加定时调度、子 Agent 并行、跨轮记忆三要素。跨越单次对话的记忆，是「循环」与「一次性操作」的分界线。

4.1 Loop 靠发现、交付、验证、

持久化、调度五个动作才能持续运转

图 4-1：Loop 五动作闭环——

缺验证或调度，循环退化为一次性 prompt

发现（找出该做的事）→交付（隔离交给 Agent）→验证（换个 Agent 说不）→持久化（状态写到对话外）→调度（一圈圈自动转）。

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

4.2 四格检验：不是所有任务都值得建 Loop

五个动作描述了 Loop怎么转，但还有一个前置问题——该不该建。建 Loop 有 setup 成本（写 Skill、接 Connectors、调验证器），并非所有场景都值得投入。

四格检验：任务会重复、验证能自动化、Token 预算可承受、Agent 具备高级工程师工具——四格全满才值得建 Loop。我们的日志诊断场景逐条验证：每日运行（重复）、334 条测试 +6 层验证（自动化）、单次耗费可预估（预算）、SLS + Langfuse + Pipeline 全通（工具齐备）。反例：一次性架构评审、「提升用户体验」等目标模糊的探索——任一条件缺失就不该建 Loop。

4.3 六个组件如何拼成一个完整的 Loop 闭环

Loop 运转需六个配合零件——Connectors（感知）、Automations（驱动）、Skills（SOP）、Worktrees（隔离）、Sub Agents（裁判）、State（记忆）。它们按依赖顺序拼成闭环：

图 4-2：六个组件协作架构——

Connectors 决定感知上限，State 决定复利斜率

五个动作映射到六个组件：发现靠 Connectors + Automations，交付靠 Skills + Worktrees，验证靠 Sub Agents，持久化靠 State，调度靠 Automations。实施依赖顺序：Connectors（地基）→ Automations → Skills → Worktrees → Sub Agents → State。缺一个，后续皆不成立。

5 实践：从日志扫描到预发部署，

我们如何落地全自主 Loop

这不是 Demo，而是每日运行的生产系统。系统每天自动扫描 10+ 项目日志，自主完成发现、定位、修复、验证、发布。

上周一次真实运转：

验证失败时，修复 Skill 自动进入下一轮（分析失败原因 → 调整补丁 → 重跑测试），最多 3 轮。上周三连接池补丁导致 2 个单测失败，第 2 轮更新 mock 参数后通过。第 3 轮仍失败则自动停止并推送钉钉工单给 Owner——避免在错误方向无限重试。

阶段	传统方式	我们的 Loop	提升
发现	值班同事第二天看日志	5 分钟内自动告警 + 每日全量扫描	天级 → 分钟级
诊断	人工复制日志喂 AI，两三天覆盖 Top 3-5	8 阶段结构化诊断，48 分钟全部根因定位	覆盖率从 Top 5 → 全量
修复	人写补丁、跑测试、提 CR	自动生成补丁 → 跑 334 个测试 → 提交	人工半天 → 自动 15 分钟
验证	修复者自己说「好了」	6 层独立验证，修复者不能给自己打分	消灭假修复
发布	手动部署 + 人工检查	自动部署预发 → 集成测试 → Trace 验证 → 钉钉推送	全自动到预发
沉淀	关掉对话就忘了	修复方案自动写入知识库，同类问题从 48min 降到 15min	经验可复用

表 5-1：传统方式 vs. Loop 全流程对比

（发现、诊断、修复、验证、发布、沉淀六阶段）

5.1 Connectors 用 MCP 打通日志、

追踪与发布，让 Agent 看见线上世界

Connectors 排第一，因为 Agent 默认只能看见本地文件系统。没有工具接入，后续所有组件皆为空中楼阁。

图 5-1：Connectors 六层架构——

没有跨库 trace，Agent 只能做单表搜索

9000+ 行工具链搭建 6 层连接器（数据访问 → 模型追踪 → 发布 → 通知 → 验证 → 基础设施），赋予 Agent 完整的线上感知和操作能力。

日志查询是 Connectors 层最核心的能力。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

表 5-2：三个 Logstore 分工

7 个子命令对这三个库实现跨库关联、全链路覆盖和结论可验证——普通做法需在三个控制台手工对齐 request_id，Agent 用 trace 一条命令即可串起完整链路。

真实案例：trace一条命令还原 30 分钟人工排查。某次 ToolException 报错，值班同事在三个控制台间切换 30 分钟才拼出完整链路。Agent 执行：

输出节选：

一条命令看清：API 入口 → Agent 路由 → MCP 工具超时 → 远端 Java 855 行抛错 → 我方缺 fallback。配合诊断 Skill Phase 2 的 git log 交叉验证，还能区分「新问题」还是「老毛病突然恶化」。

基础设施也是代码管理的。采集配置（logtail_config.yaml）、告警规则（alert_config.yaml）、监控大盘（dashboards/*.json）全部声明式管理。Agent 发现新错误模式即补充告警规则，新增日志库即更新采集配置。

教训：工具链建设约占 30% 总工作量。没有跨系统关联分析（日志 × 追踪 × 代码变更），后续所有自动化皆是空谈。

5.2 Automations 用定时巡检与

实时告警让系统自己发现异常

Automations 解决痛点章「看不见」：10+ 项目的错误散在 3 个日志库，50 条飙到 350 条往往第二天才有人发现。

图 5-2：Automations 两层发现——

巡检抓慢性问题，告警抓突发问题

两层协作：第一层每日 cron 全量巡检，系统自扫、自写报告、自归档；第二层实时告警每 5 分钟扫一轮，命中后钉钉群推送卡片（内嵌 Langfuse Trace 链接），严重故障自动触发语音电话。

5.3 Skills 把诊断、修复、发布

三段经验固化成可复用的 SOP

Skills 解决痛点章「记不住」：排查经验在对话里，关掉即失忆。Skill 把 SOP 写到磁盘，换个 Agent 来跑，产出一致。

图 5-3：三个 Skill 流水线——

Skill 是 SOP 磁盘化，不是更长 prompt

Skill	做什么	规模	关键设计
诊断（diagnose）	8 阶段结构化诊断	760 行 SKILL.md	每个结论必须标注证据来源
修复（auto-fix）	解析报告→查知识库→生成补丁→跑测试→提交	6 步流程	先查历史方案，最多 3 轮
发布验证（deploy-and-verify）	安全校验→CR→Pipeline→预发→集成测试→Trace 验证→线上对比→通知	11 步，400 行	独立 Agent 复查

表 5-3：三个核心 Skill 概览

5.3.1 诊断 Skill 用 8 个 Phase 和 git log 交叉验证，堵住 Agent 偷工减料

这份 SKILL.md 不是 prompt，而是一份严格的操作手册——每个 Phase 规定用什么工具、查什么数据、输出什么格式、哪些步骤不可跳过。不写死规则，Agent 就会偷懒：跳过趋势分析、不做交叉验证、只看第一条日志就下结论。

Phase	做什么	为什么不能跳	关键工具
0 澄清	确认时间范围、分析模式	不确认就会分析错误时间段	对话
1 全景扫描	跨 3 个日志库统计错误分布	不扫全景就会遗漏类别	raw-query+diagnose
2 时间趋势	识别突增/慢性/回归模式	不看趋势就分不清新旧	error-trend+git log
3 错误详情	完整 traceback + 输入参数	截断 traceback 就定位不了	error-lookup
4 Trace 追踪	模型调用链、token、fallback	不查 Trace 就不知道哪步失败	Langfuse MCP
5 代码定位	精确到 file:line + Owner	不定位就没法修	Read+git log
6 根因分析	6 类分类 + 证据链推理	没证据链就是猜	交叉验证
7 修复建议	短期止血 + 长期根治	没建议就等于没诊断	—

表 5-4：诊断 Skill 八个 Phase 设计逻辑

Phase 2 的精华：git log 交叉验证。Agent 不能只看错误首次出现时间就下结论：

Phase 6 的精华：结构化根因推理链。每个结论必须按 [事实]→[推理]→[结论] 格式输出：

根因分类	修复方向	示例
外部系统异常	防御式：try-except + fallback + retry	MCP 工具返回 Java stackTrace
内部代码缺陷	精确修改 file:line	TypeError 在 src/deep_diagnose/
基础设施问题	配置调整	连接池 pool_size=5
LLM/模型异常	Prompt 约束 + schema 校验	幻觉编造不存在的表名
预期行为（误报）	确认后降级日志级别	CancelledError
数据问题	不修，转工单给 Owner	用户数据异常

表 5-5：六种根因分类与修复方向

5.3.2 修复 Skill 用 6 步把诊断报告自动变成可合并的补丁

诊断报告就是接口——修复 Skill 读取结构化报告后自动接管，人无需在中间传话。

Step 2 先查知识库再动手修——知识库积累 30+ 条修复方案（YAML 格式），命中后直接复用。连接池问题首次修复 48 分钟，有知识库后 15 分钟。

分类	修复模式	示例
外部系统	try-except + fallback + retry	ToolException→ 降级处理返回空结果
内部缺陷	精确修改 file:line	chat/repository.py:45→ 修改连接池配置
用户输入	添加参数校验	ODPS 查询前验证表名存在
基础设施	配置调整	连接池pool_size=5, max_overflow=10
预期行为	日志级别调整	logger.error→logger.warning

表 5-6：按根因分类选择修复模式（侧重具体改法，分类见表 5-5）

修复原则：最小化改动、保持向后兼容、外部系统问题用 try-except 包裹。测试不过就修改重跑，最多 3 轮——超过 3 轮自动升级人工。

5.3.3 发布 Skill 用 11 步串起预发部署、Trace 验证与独立复查

到预发全自动，生产发布是唯一需要人确认的环节。修复完成后，11 个步骤一条命令触发：

步骤	做什么	关键约束
0 安全校验	确认是正确的仓库和应用	仓库 + App ID 必须匹配，否则立即停止
1 自动提交	创建 feature 分支 + 推送	禁止直推 master/develop
2 CR + Reviewer	创建 Code Review + 指定审查人	MR 目标必须是 develop 分支
3 提交 Pipeline	触发预发部署流水线	Pipeline 423（预发）
4 预发功能验证	针对本次修改的集成测试（自主回归）	必须指定 skill_names 聚焦测试
5 Langfuse Trace 验证	0 ERROR + 正确模型 + token < 150K	不允许非预期 fallback
6 预发诊断复查	调用诊断 Skill 扫描预发环境	部署后不能有新增 ERROR 类型
7 线上对比	Langfuse Trace 对比预发 vs 线上	行为偏差则阻塞发布
8 产出测试报告	写入 docs/reports/	结构化 Markdown
9 钉钉通知	推送审批卡片	包含业务价值 + MR 链接 + 报告链接
10 输出总结	全流程状态汇总	/ /

表 5-7：发布 Skill 十一步流程

三个最易踩坑的步骤：

Step 0 安全校验— 执行前验证仓库、App ID、仓库地址三重匹配，任一不符立即停止。

Step 4 集成测试——必须聚焦。必须指定 skill_names，否则系统加载全量工具集，测试不聚焦：

Step 5–7 构成自主回归三层验证— Trace 硬指标、独立诊断复查、预发 vs 线上 Langfuse 对比。任一偏差则阻塞发布，回到修复 Skill 第 2 轮。

检查项	通过标准	为什么
ERROR observations	必须为 0	任何 ERROR 说明有未处理异常
主模型	与请求一致，无非预期 fallback	fallback 说明首选模型有问题
max input_tokens	< 150K	超过说明 context 窗口快溢出
Agent finished	True	False 说明 Agent 中途崩溃

表 5-8：Langfuse Trace 四项硬指标

（ERROR、主模型、token 上限、Agent 完成状态）

Step 9 钉钉通知须含业务价值描述，让 Reviewer 5 秒内理解收益与风险。

5.4 Worktrees 为每个 Bug 开独立工作区，

让多类错误并行修复互不覆盖

Worktrees 解决并行覆盖：三个 Agent 同时改同一文件，后提交的覆盖前者修复，浪费一整轮 token。

图 5-4：Git Worktree 并行修复——

三类问题串行 45 分钟 vs 并行 17 分钟

诊断一次扫出多类错误，每类问题需要独立修复。早期三个 Agent 在同一工作区同时改代码，后提交的覆盖前者修复，冲突率约 30%。

Git Worktree 是解法：同一仓库检出多个工作目录，共享 .git 历史但工作区物理隔离：

一个 Agent 在 ../fix-timeout 改连接池配置，另一个在 ../fix-hallucination 加 schema 校验——互不干扰。每个分支独立走完修复 → 测试 → CR → Pipeline → 验证全流程后才合并到 develop。

分支命名约定：fix/<问题描述>_<日期>_<序号>。三个 Worktree 各自完成验证后，按修复优先级依次合入 develop。若两分支改同一文件，第二个合并前 rebase 并重新跑测试——比同一工作区互相覆盖可控得多。大部分修复涉及不同文件，冲突率不到 5%。

并行加速：三类问题串行约 45 分钟，并行只需 17 分钟（最长的一类 + 合并开销）。git worktree addsetup 成本不到 1 秒。

5.5 Sub Agents 用六层独立验证确保修复者不能给自己打分

Sub Agents 解决痛点章「没闭环」：修复者自证不可靠，必须换 Agent 验。

图 5-5：六层独立验证——

第 3 层专抓日志降级类假修复

层	评判手段	通过标准	能抓什么	典型盲点
1	Lint	零 warning	格式/语法	逻辑与行为
2	单元测试	全量单测通过	逻辑回归	日志降级类假修复
3	预发日志	无新增ERROR 类型	部署引入的新 ERROR	—
4	线上对比	预发与线上一致	行为偏差	—
5	集成测试	修改部分全过	端到端链路	—
6	UI 验证	页面行为正常	前端渲染	—

表 5-9：六层独立验证体系（含各层能抓 / 抓不住）

只靠单元测试，痛点章那次 logger.error → logger.warning 的假修复完全能过。第 3 层独立诊断复查专抓这类问题：日志级别变了，但 Langfuse Trace 中的 ERROR observation 仍在。修复 Agent 能骗自己，骗不了独立验证 Agent。

验证通过后自动推送钉钉审批卡片——包含业务价值描述、MR 链接、测试报告、Langfuse Trace 链接：

图 5-6：验证通过后的钉钉审批卡片——

须让 Reviewer 5 秒内判断 merge 风险

6 层验证解决「当次修复是否可信」；State 解决「下次遇到同类问题是否更快」。

5.6 State 把修复方案与巡检结果落盘，

让同类问题越修越快

State 解决痛点章「记不住」：经验必须落盘，Loop 才有复利。三类 State 各司其职：知识库沉淀修复方案（30+ 条 YAML），每日归档保留巡检数据跨天可追溯，基础设施配置（告警规则、采集配置、监控大盘）全部 Git 版本化——Agent 发现新错误模式即补充规则，检测网越织越密。

5.7 六个组件串成端到端流水线：

验证失败自动重试，三轮不过升级人工

六个组件拼成一条完整链路：触发 → 感知 → 诊断 → 修复 → 验证 → 发布 → 沉淀。

图 5-7：端到端 Loop 闭环——

3 轮失败升级人工，避免 0.95^N 在错误方向空转

修复 Skill 最多 3 轮自动重试；超过 3 轮停止并推送钉钉工单给 Owner。成功后修复方案写入知识库（State），监控策略同步更新（Automations 反哺），下次遇到同类问题直接复用。

小结：回顾整条链路——Connectors 让 Agent 看见线上世界，Automations 让发现不再依赖人，Skills 把经验固化为可复用的 SOP，Worktrees 让多类问题并行不冲突，Sub Agents 确保修复者不能自证，State 让同类问题越修越快。六个组件各司其职，拼出了从发现到预发全程 48 分钟、0 人工介入的完整闭环。系统跑通了——但更值得思考的问题是：当维护循环不再需要人来推，工程师的角色发生了什么变化？

6 范式迁移：未来已来，工程师的角色正从

「推循环的人」变成「设计循环的人」

未来不是远景，而是正在发生的事。Boris Cherny 一天提交 150 个 PR——不是因为他写代码更快，而是因为他设计了让 Agent 自己转的循环。这不是个例，而是一种范式迁移的信号。

图 6-1：Loop 规模化——从一个人推一个系统，

到一个人设计多个系统的自主循环

范式迁移的核心变化不是工具，而是人的角色。Prompt 时代你是指令官，Context 时代你是材料员，Harness 时代你是工具配置师——到了 Loop 时代，你是循环设计师。你不再亲手查日志、写修复、跑测试、推发布，而是设计让这些事情自动发生的规则系统。

我们已经在这条路上走出了第一步。日志诊断 Loop 证明了从发现到预发的全链路可以自动转。下一步是把同样的骨架（五动作 + 六组件）复制到更多项目——换 Connectors、换 Skills、换验证器，但架构不变。

6.1 踩过的坑：四条血泪教训

!教训一：连续两周不看 diff 就合并。系统越好用人越容易放松警惕。结果一个 Agent 把 retry=3 改成了 retry=0，导致线上超时率翻倍。对策：每周至少抽查 3 个 diff。

!教训二：验证器覆盖不全 = 假安全感。初版只有单元测试，logger.error→warning 假修复就是因为第 3 层预发日志验证还没上线。对策：至少 3 层验证才能自动合并。

!教训三：Token 成本失控。初期每次全量诊断耗费 200K+ token，一周烧掉预算上限。后来加了分级策略：先用小模型做初筛（耗费 5K token），只有高优问题才调大模型深度诊断。对策：分级策略 + 预算熔断。

!教训四：Connectors 建设被低估。工具链（SLS 查询脚本 + Langfuse MCP + 发布脚本）占了总工作量 30%，但前两周几乎没投入。对策：先花两周打好 Connectors 地基，再建上层。

6.2 给读者的行动清单

如果你想把 Loop 应用到自己的项目，按这个顺序走：

周	做什么	产出	验收标准
1	四格检验 + 选场景	一张四格表 + 一个确定的目标场景	四格全满
2-3	建 Connectors（接日志/监控/发布）	Agent 能查日志、能触发发布	一条命令跑通全链路
4	写第一个 Skill + 加定时调度	每天自动跑一轮 Loop	连续 3 天无人值守运转

表 6-2：四周落地计划

7 结语：工程师的价值正从

写 Prompt 转向设计能自己转的循环

Loop Engineering 不是一种产品，而是一种工程思维——不再问「这条 prompt 怎么写更好」，而是问「这个循环能不能自己转」。

2025 年我们以为 AI 解决的是「写代码慢」；一年后发现，真正的瓶颈是维护循环仍靠人在推。

别再当循环里最慢的那一环——去设计循环。