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

从日志扫描到全自主闭环：Loop Engineering如何真正解放开发者

有这么一组数字，值得每个做AI工程化的人仔细琢磨一下——Boris Cherny单日合并150个PR，Peter Steinberger同时跑100个AI Agent持续编码30天。这些惊人的产出背后，其实指向同一个核心：

不过，能跑的循环不一定是有用的循环。

没有验证这个环节，自动化只是在更快地烧token而已。

我们团队在维护AI云诊断系统时，把这条路完整走了一遍。先看一组效果数据：

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

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

这些数字来自一条非常具体的日常链路：

人需要做的，只剩下点一下「批准发布」。

这不是什么概念验证，这是我们维护AI云诊断系统的日常。全文会沿着三条主线展开：

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

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

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

痛点：AI写代码快了，但发现→修复→上线的维护循环仍靠你推

2026年6月第二周，我们一周捞出了

——散在3个日志库里，类型从上游超时到LLM幻觉应有尽有。从2025年3月开始大规模用AI写代码之后，新功能从想法到实现确实快多了，可能只要半天。但代码写完只是开始。

发现问题 → 查日志 → 定位根因 → 写修复 → 跑测试 → 上线。AI写代码快，但推动这个循环转起来的，还是你。

我们维护的是一套AI驱动的诊断系统——帮用户排查云服务器故障。讽刺的是：

值班同事打开日志控制台，只能看到热门几条。每条都要手动复制、喂AI、对代码、写修复、跑测试、提审查、等发布。

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

维护循环卡死的三个断裂点：看不见、记不住、没闭环

错误散在三个日志库（agent_log、mcp_client_log、mcp_server_log），没有人做聚合。某天从50条飙到350条，第二天才有人发现——

上次排查连接池超时花了整天（根因是某个方法设了2秒激进超时），下次遇到同类问题还得从头来。AI在对话里推理得很好，但关掉对话就失忆了。

有一次Agent说「已修复」——其实只是把logger.error改成了logger.warning。错误还在，只是不报了。

它靠人在推，人就是瓶颈。这三点缺位，正是前三代AI工程化填不上的坑。

演进：从Prompt到Loop，四代AI工程化范式逐层叠加

AI工程化走过了四层楼，像带新人：

——告诉新人「去查一下连接池超时的原因」，他能照着做一次，但下次换个问题还得你再说一遍。典型：ChatGPT对话式排查。

——把代码库、文档、日志样本一次性喂给他，他能给出更准的分析，但仍然是你问一句答一句。典型：Cursor带codebase索引。

——给他Shell、MCP、Git权限，他能自己查日志、改代码、跑测试，但每次都要你启动。典型：Claude Code单次会话修Bug。

——写好巡检规则、修复手册、验证标准，他每天自己扫、自己修、自己验，你只在关键节点审批。典型：本文实践。

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

图3-1：四代AI工程化范式演进——选范式前先问：你的任务卡在哪一层瓶颈

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

→ 发现（Connectors + Automations）

→ 持久化（State + Skills）

→ 验证（Sub Agents）

原理：Loop是让AI自己发现工作、验证结果并记住经验的系统设计方法

如果你发现自己每天都在手动触发Agent、审查结果、推进流程——

Harness是一次运行的武装——工具、动作、完成条件。Loop在Harness之上加了定时调度、子Agent并行、跨轮记忆三件事。

Loop靠发现、交付、验证、持久化、调度五个动作才能持续运转

图4-1：Loop五动作闭环——缺验证或调度，循环退化为一次性prompt

（找出该做的事）→ （隔离交给Agent）→ （换个Agent说不）→ （状态写到对话外）→ （一圈圈自动转）。

没有自动化，循环就不是循环，只是一次性操作。

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

五个动作描述了Loop

，但还有前置问题——。建Loop有setup成本（写Skill、接Connectors、调验证器），不是所有场景都值得投入。

我们的日志诊断场景逐条验证：每天跑（重复）、334条测试+6层验证（自动化）、单次耗费可预估（预算）、SLS+Langfuse+Pipeline全通（工具齐备）。反例：一次性架构评审、「提升用户体验」这类目标模糊的探索——任一条件缺失就不该建Loop。

六个组件如何拼成一个完整的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。缺一个，后面的都站不住。

实践：从日志扫描到预发部署，我们如何落地全自主Loop

系统每天自动扫描10+项目日志，自主发现、定位、修复、验证、发布。上周一次真实运转：

（分析失败原因 → 调整补丁 → 重跑测试），最多3轮。上周三连接池补丁导致2个单测失败，第2轮更新mock参数后通过。——不在错误方向上无限重试。

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

Connectors用MCP打通日志、追踪与发布，让Agent看见线上世界

没有工具接入，后面所有组件都是空中楼阁。

图5-1：Connectors六层架构——没有跨库trace，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

表5-2：三个Logstore分工

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

trace

某次ToolException报错，值班同事在三个控制台间切了30分钟才拼出完整链路。Agent执行：

一条命令看清：

配合诊断Skill Phase 2的git log交叉验证，还能区分「新问题」还是「老毛病突然恶化」。

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

没有跨系统关联分析（日志×追踪×代码变更），后面所有自动化都是空谈。

Automations用定时巡检与实时告警让系统自己发现异常

10+项目的错误散在3个日志库，50条飙到350条往往第二天才有人发现。

图5-2：Automations两层发现——巡检抓慢性问题，告警抓突发问题

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

Skills把诊断、修复、发布三段经验固化成可复用的SOP

排查经验在对话里，关掉就失忆。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概览

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

——每个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设计逻辑

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

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

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

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

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

——知识库积累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轮自动升级人工。

发布 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十一步流程

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

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

— Trace硬指标、独立诊断复查、预发vs线上Langfuse对比。

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

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

Worktrees为每个Bug开独立工作区，让多类错误并行修复互不覆盖

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

图5-4：Git Worktree并行修复——三类问题串行45分钟 vs 并行17分钟

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

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

一个Agent在../fix-timeout改连接池配置，另一个在../fix-hallucination加schema校验——互不干扰。每个分支独立走完

全流程后才合并到develop。

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

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

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

修复者自证不可靠，必须换Agent验。

图5-5：六层独立验证——第3层专抓日志降级类假修复

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

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

只靠单元测试，痛点章那次logger.error → logger.warning的假修复完全能过。

日志级别变了，但Langfuse Trace中的ERROR observation仍在。修复Agent能骗自己，骗不了独立验证Agent。

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

图5-6：验证通过后的钉钉审批卡片——须让Reviewer 5秒内判断merge风险

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

State把修复方案与巡检结果落盘，让同类问题越修越快

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

六个组件串成端到端流水线：验证失败自动重试，三轮不过升级人工

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

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

范式迁移：未来已来，工程师的角色正从「推循环的人」变成「设计循环的人」

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

图6-1：Loop规模化——从一个人推一个系统，到一个人设计多个系统的自主循环

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

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

踩过的坑：四条血泪教训

系统越好用人越容易放松警惕。结果一个Agent把retry=3改成了retry=0，导致线上超时率翻倍。

初版只有单元测试，logger.error→warning假修复就是因为第3层预发日志验证还没上线。

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

工具链（SLS查询脚本+Langfuse MCP+发布脚本）占了总工作量30%，但前两周几乎没投入。

给读者的行动清单

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

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

表6-2：四周落地计划

结语：工程师的价值正从写Prompt转向设计能自己转的循环

2025年我们以为AI解决的是「写代码慢」；一年后发现，