1 引子Loop Engineering 的目标不是写得更快而是让你从维护循环里撤出来Boris Cherny 单日合并 150 个 PRPeter Steinberger 同时跑 100 个 AI Agent 持续编码 30 天。数字背后是同一件事瓶颈不在写得更快而在能否设计出自己转的循环。能跑起来的循环不等于有用的循环——循环的本质是生成器接上验证器。没有验证器自动化只是在更快地烧 token。指标BeforeAfter变化一周 ERROR 总量1210 条47 条↓ 96%同类问题修复时间48 分钟15 分钟↓ 69%人工介入次数到预发每次都要0 次全自动表1-1Before/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 维护循环卡死的三个断裂点看不见、记不住、没闭环看不见。错误散在三个日志库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-1Loop 五动作闭环——缺验证或调度循环退化为一次性 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驱动、SkillsSOP、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-58 阶段结构化诊断48 分钟全部根因定位覆盖率从 Top 5 → 全量修复人写补丁、跑测试、提 CR自动生成补丁 → 跑 334 个测试 → 提交人工半天 → 自动 15 分钟验证修复者自己说「好了」6 层独立验证修复者不能给自己打分消灭假修复发布手动部署 人工检查自动部署预发 → 集成测试 → Trace 验证 → 钉钉推送全自动到预发沉淀关掉对话就忘了修复方案自动写入知识库同类问题从 48min 降到 15min经验可复用表5-1传统方式 vs. Loop 全流程对比发现、诊断、修复、验证、发布、沉淀六阶段5.1 Connectors 用 MCP 打通日志、追踪与发布让 Agent 看见线上世界Connectors 排第一因为 Agent 默认只能看见本地文件系统。没有工具接入后面所有组件都是空中楼阁。图5-1Connectors 六层架构——没有跨库 traceAgent 只能做单表搜索9000 行工具链搭了 6 层连接器数据访问 → 模型追踪 → 发布 → 通知 → 验证 → 基础设施让 Agent 具备完整的线上感知和操作能力。日志查询是 Connectors 层最核心的能力。1280 行脚本sls_logquery_tools.py提供 7 个子命令数据分散在 3 个 Logstore 中Logstore记录什么典型字段agent_logAPI 入口、Agent 路由、Python 异常request_id,file,levelmcp_client_logMCP 工具执行详情、耗时request_id,tool_name,duration_msmcp_server_log工具调用链、入参出参request_id,response_status表5-2三个 Logstore 分工7 个子命令对这三个库做到了跨库关联、全链路覆盖和结论可验证——普通做法需要在三个控制台手工对齐request_idAgent 用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-2Automations 两层发现——巡检抓慢性问题告警抓突发问题两层协作第一层每日 cron 全量巡检系统自己扫、自己写报告、自己归档第二层实时告警每 5 分钟扫一轮命中后钉钉群推送卡片内嵌 Langfuse Trace 链接严重故障自动触发语音电话。5.3 Skills 把诊断、修复、发布三段经验固化成可复用的 SOPSkills 解决痛点章「记不住」排查经验在对话里关掉就失忆。Skill 把 SOP 写到磁盘换个 Agent 来跑产出一样。图5-3三个 Skill 流水线——Skill 是 SOP 磁盘化不是更长 promptSkill做什么规模关键设计诊断diagnose8 阶段结构化诊断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-querydiagnose2 时间趋势识别突增/慢性/回归模式不看趋势就分不清新旧error-trendgit log3 错误详情完整 traceback 输入参数截断 traceback 就定位不了error-lookup4 Trace 追踪模型调用链、token、fallback不查 Trace 就不知道哪步失败Langfuse MCP5 代码定位精确到 file:line Owner不定位就没法修Readgit log6 根因分析6 类分类 证据链推理没证据链就是猜交叉验证7 修复建议短期止血 长期根治没建议就等于没诊断—表5-4诊断 Skill 八个 Phase 设计逻辑Phase 2 的精华git log 交叉验证。Agent 不能只看错误首次出现时间就下结论Phase 6 的精华结构化根因推理链。每个结论必须按[事实]→[推理]→[结论]格式输出根因分类修复方向示例外部系统异常防御式try-except fallback retryMCP 工具返回 Java stackTrace内部代码缺陷精确修改 file:lineTypeError 在src/deep_diagnose/基础设施问题配置调整连接池 pool_size5LLM/模型异常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 查询前验证表名存在基础设施配置调整连接池pool_size5, max_overflow10预期行为日志级别调整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/develop2 CR Reviewer创建 Code Review 指定审查人MR 目标必须是 develop 分支3 提交 Pipeline触发预发部署流水线Pipeline 423预发4 预发功能验证针对本次修改的集成测试自主回归必须指定skill_names聚焦测试5 Langfuse Trace 验证0 ERROR 正确模型 token 150K不允许非预期 fallback6 预发诊断复查调用诊断 Skill 扫描预发环境部署后不能有新增 ERROR 类型7 线上对比Langfuse Trace 对比预发 vs 线上行为偏差则阻塞发布8 产出测试报告写入 docs/reports/结构化 Markdown9 钉钉通知推送审批卡片包含业务价值 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 说明有未处理异常主模型与请求一致无非预期 fallbackfallback 说明首选模型有问题max input_tokens 150K超过说明 context 窗口快溢出Agent finishedTrueFalse 说明 Agent 中途崩溃表5-8Langfuse Trace 四项硬指标ERROR、主模型、token 上限、Agent 完成状态Step 9 钉钉通知须含业务价值描述让 Reviewer 5 秒内理解收益与风险。5.4 Worktrees 为每个 Bug 开独立工作区让多类错误并行修复互不覆盖Worktrees 解决并行覆盖三个 Agent 同时改同一文件后提交的覆盖前者修复浪费一整轮 token。图5-4Git 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 层专抓日志降级类假修复层评判手段通过标准能抓什么典型盲点1Lint零 warning格式/语法逻辑与行为2单元测试全量单测通过逻辑回归日志降级类假修复3预发日志无新增ERROR 类型部署引入的新 ERROR—4线上对比预发与线上一致行为偏差—5集成测试修改部分全过端到端链路—6UI 验证页面行为正常前端渲染—表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 把经验固化为可复用的 SOPWorktrees 让多类问题并行不冲突Sub Agents 确保修复者不能自证State 让同类问题越修越快。六个组件各司其职拼出了从发现到预发全程 48 分钟、0 人工介入的完整闭环。系统跑通了——但更值得思考的问题是当维护循环不再需要人来推工程师的角色发生了什么变化6 范式迁移未来已来工程师的角色正从「推循环的人」变成「设计循环的人」未来不是远景而是正在发生的事。Boris Cherny 一天提交 150 个 PR——不是因为他写代码更快而是因为他设计了让 Agent 自己转的循环。这不是个例而是一种范式迁移的信号。图6-1Loop 规模化——从一个人推一个系统到一个人设计多个系统的自主循环范式迁移的核心变化不是工具而是人的角色。Prompt 时代你是指令官Context 时代你是材料员Harness 时代你是工具配置师——到了 Loop 时代你是循环设计师。你不再亲手查日志、写修复、跑测试、推发布而是设计让这些事情自动发生的规则系统。我们已经在这条路上走出了第一步。日志诊断 Loop 证明了从发现到预发的全链路可以自动转。下一步是把同样的骨架五动作 六组件复制到更多项目——换 Connectors、换 Skills、换验证器但架构不变。6.1 踩过的坑四条血泪教训**!**教训一连续两周不看 diff 就合并。系统越好用人越容易放松警惕。结果一个 Agent 把retry3改成了retry0导致线上超时率翻倍。对策每周至少抽查 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 解决的是「写代码慢」一年后发现真正的瓶颈是维护循环仍靠人在推。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】