阿里妹导读
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
1 引子：
Loop Engineering 的目标不是写得更快，
而是让你从维护循环里撤出来
Boris Cherny 单日合并 150 个 PR；Peter Steinberger 同时跑 100 个 AI Agent 持续编码 30 天。数字背后是同一件事：瓶颈不在写得更快，而在能否设计出自己转的循环。
能跑起来的循环不等于有用的循环——循环的本质，是生成器接上验证器。没有验证器，自动化只是在更快地烧 token。
指标BeforeAfter变化
一周 ERROR 总量 1210 条 47 条↓ 96%
同类问题修复时间 48 分钟 15 分钟↓ 69%
人工介入次数（到预发）每次都要 0 次全自动
表1-1：Before/After 效果对比（三项指标分别对应发现速度、修复效率、人工介入三个断裂点）
上述数字来自同一条日常链路：一句指令，Agent 从 3 个日志库挖出 Bug → 诊断根因 → 生成补丁 → 跑完 334 条测试 → 提交 CR → 预发部署 → 集成验证 → 钉钉通知审批。人只需点「批准发布」。
这不是概念验证，是我们维护 AI 云诊断系统的日常。全文沿三条主线展开：
日志分析自主挖 Bug— 跨 3 个 Logstore 关联、7 子命令 +git log交叉验证
Bug 自主修复闭环— 发现 → 诊断 → 补丁 → 测试 → 预发部署，全程 Agent 驱动
一条指令或定时触发跑完全流程— 人工一句话触发，或 Automation 每日自动跑：开发 → 部署 → 测试 → 预发 → 线上对比
2 痛点：AI 写代码快了，
但发现→修复→上线的维护循环仍靠你推
2026 年 6 月第二周，我们一周捞出1210 条 ERROR——散在 3 个日志库，类型从上游超时到 LLM 幻觉应有尽有。
2025 年 3 月起，我们开始大规模用 AI 写代码。一个新功能从想法到实现，可能只要半天。但代码写完只是开头。
真正吃时间的，是上线之后的维护循环：发现问题 → 查日志 → 定位根因 → 写修复 → 跑测试 → 上线。AI 帮你写代码很快，推动这个循环转起来的，还是你。
我们维护着一套 AI 驱动的诊断系统——帮用户排查云服务器故障。讽刺的是：这个系统本身也有一堆线上问题要修。
值班同事打开日志控制台，只看得到热门几条。每条都要手动复制、喂 AI、对代码、写修复、跑测试、提审查、等发布。一轮排查花 2–3 天，覆盖的不过冰山一角。
图2-1：人工驱动维护循环的瓶颈——任一环节卡住，整条链路停转；人推循环 = 单线程瓶颈
2.1 维护循环卡死的三个断裂点：
看不见、记不住、没闭环
看不见。错误散在三个日志库（agentlog、mcpclientlog、mcpserver_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 行脚本（slslogquerytools.py）提供 7 个子命令，数据分散在 3 个 Logstore 中：
Logstore记录什么典型字段
agentlog API 入口、Agent 路由、Python 异常requestid,file,level
mcpclientlog MCP 工具执行详情、耗时requestid,toolname,duration_ms
mcpserverlog 工具调用链、入参出参requestid,responsestatus
表5-2：三个 Logstore 分工
7 个子命令对这三个库做到了跨库关联、全链路覆盖和结论可验证——普通做法需要在三个控制台手工对齐request_id，Agent 用trace一条命令就能串起完整链路。
真实案例：trace一条命令还原 30 分钟人工排查。某次ToolException报错，值班同事在三个控制台间切了 30 分钟才拼出完整链路。Agent 执行：
输出节选：
一条命令看清：API 入口 → Agent 路由 → MCP 工具超时 → 远端 Java 855 行抛错 → 我方缺 fallback。配合诊断 Skill Phase 2 的git log交叉验证，还能区分「新问题」还是「老毛病突然恶化」。
基础设施也是代码管理的。采集配置（logtailconfig.yaml）、告警规则（alertconfig.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 + retryToolException→ 降级处理返回空结果
内部缺陷 精确修改 file:linechat/repository.py:45→ 修改连接池配置
用户输入 添加参数校验 ODPS 查询前验证表名存在
基础设施 配置调整 连接池poolsize=5, maxoverflow=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 解决的是「写代码慢」；一年后发现，真正的瓶颈是维护循环仍靠人在推。
别再当循环里最慢的那一环——去设计循环。
千问云-为 Agent 而生，驱动 AI 生产力
扫描下方二维码，直达千问云体验
点击阅读原文即可体验！
