Prompt 时代你是指令官Context 时代你是材料员Harness 时代你是工具配置师。到了 Loop 时代你是循环设计师。不再亲手查日志、写修复、跑测试、推发布而是设计让这些事情自动发生的规则系统。架构师管理的不是系统是系统背后的规则。大家好从日志扫描到预发部署的全自主闭环该不该建怎么判断、照什么顺序建、要花多少钱、怎么过安全评审这篇一次讲完。0、太长不看版一句话AI 写代码早就不慢了慢的是上线之后发现问题 → 修好 → 发出去这条维护循环它至今还靠人在推。Loop Engineering 干的就是把这条循环做成系统机器自己扫日志、自己修、自己验人只在发版前点一次批准。三个数字一周线上 ERROR 从 1000 条降到 40 条-96%同类问题修复从 50 分钟缩到 15 分钟-70%从发现问题到预发部署人工介入 0 次。适不适合你先过四道题任务天天重复吗验证能自动化吗Token 花得起吗Agent 拿得到高级工程师同款的工具权限吗四个都答是直接翻到第 8 节抄施工计划有一个答否先补短板别硬上。1、这事到底解决什么痛先看疗效2025 年起我们开始大规模用 AI 写代码一个新功能从想法到能跑半天搞定。爽了没几个月就发现代码写完只是开头真正吃人的是上线之后发现问题 → 查日志 → 定位根因 → 写修复 → 跑测试 → 走发布。这条循环里每一步 AI 都能帮上忙但把整条循环推着转起来的还是人。更讽刺的是我们维护的本身就是一套 AI 云诊断系统帮用户排查云服务器故障结果这套系统自己一周能攒出1000多条 ERROR散在 3 个日志库里。值班同事打开日志控制台只看得到热门几条一轮排查花 2–3 天覆盖的不过冰山一角。判断你是不是同款受害者有个土办法如果你每天的工作里有手动触发 Agent、把日志复制粘贴给 AI、盯着它跑完再点下一步这类动作你就是循环里最慢的那一环。Boris Cherny 一天合并 150 个 PR、Peter Steinberger 让 100 个 Agent 连跑 30 天靠的不是打字快是他们把自己从循环里撤了出来只负责设计循环。还有一盆冷水要先泼能跑起来的循环 ≠ 有用的循环。循环的本质是生成器接上验证器。没有验证器自动化只是在更快地烧 token。这句话后面会反复出现因为我们在它上面栽过跟头。1.1 先亮账本我们跑了一个多月的结果指标BeforeAfter变化对应哪个断裂点一周 ERROR 总量1000 条40条↓ 96%看不见发现速度同类问题修复时间50 分钟15 分钟↓ 70%记不住修复效率人工介入次数到预发每次都要0 次全自动没闭环人工卡点这三个数字来自同一条每天在跑的链路一句指令Agent 从 3 个日志库挖出 Bug → 诊断根因 → 生成补丁 → 跑完 300 条测试 → 提交 CR → 预发部署 → 集成验证 → 推送审批卡片人只需要点一下批准发布。不是 PoC 演示是生产系统的日常。全文就沿三条主线展开日志分析自主挖 Bug跨 3 个 Logstore 关联、7 个子命令 git log交叉验证Bug 自主修复闭环发现 → 诊断 → 补丁 → 测试 → 预发部署全程 Agent 驱动一条指令或定时触发跑完全流程人工一句话或每天定时自动跑。2、对号入座你的循环卡在哪三处维护循环卡死通常不是卡在AI 不够聪明而是卡在三个很具体的断裂点上。逐个对号入座看不见错误散在各处没人聚合。我们的错误散在 agent_log、mcp_client_log、mcp_server_log 三个日志库里谁都没做聚合。某天 ERROR 从 50 条飙到 350 条第二天才有人发现整整晚了一天。自查线上错误量突然翻 7 倍你们团队多久能知道答案超过 1 小时的都算看不见。记不住排查经验锁死在对话里。上次排查连接池超时花了一整天根因是某个方法设了 2 秒的激进超时下次遇到同类问题照样从头来。AI 在对话里推理得头头是道关掉窗口就集体失忆。自查同一类问题第二次出现时你们修得比第一次快吗快不了就是记不住。没闭环修复者自己给自己打分。真事有次 Agent 汇报已修复点开一看是把 logger.error 改成了 logger.warning错误还在只是不喊了。区分掩盖故障和合理降级需要独立验证不能听修复者自证。自查你们的修好了是谁说的如果是干活的那个人或那个 Agent自己说的就是没闭环。根因就一句话维护链路从来没被当成一个需要设计的系统。它一直靠人肉在推人自然就成了瓶颈。图 1人工驱动的维护循环任一环节卡住整条链路停转人推循环 单线程瓶颈一轮 2–3 天断裂点本质缺的是后文对应解法看不见自动发现Connectors Automations§6.1 / §6.2记不住持久化Skills State§6.3 / §6.6没闭环独立验证Sub Agents§6.53、别跳级先看你在四层楼的哪一层AI 工程化这几年走了四层楼跟带新人一模一样第 1 层先教说话Prompt2022。告诉新人去查一下连接池超时的原因他能照着做一次换个问题你还得再说一遍。典型ChatGPT 对话式排查。第 2 层再摆材料Context2025。把代码库、文档、日志样本一次性喂给他分析更准了但仍然是你问一句他答一句。典型Cursor 带 codebase 索引。第 3 层再配工具Harness2026 初。给他 Shell、MCP、Git 权限他能自己查日志、改代码、跑测试——但每次都要你按启动键。典型Claude Code 单次会话修 Bug。第 4 层写好 SOP 让他自己转Loop2026.06。巡检规则、修复手册、验证标准都写死他每天自己扫、自己修、自己验你只在关键节点审批。典型本文实践。图 2四代 AI 工程化范式逐层叠加选范式之前先问你的任务卡在哪一层瓶颈两条实操建议其一上层包含下层的全部能力每层解锁的是新瓶颈Prompt 缺上下文Context 不能动手Harness 仍需人推。你的任务卡在哪层就补哪层别在第 2 层就幻想全自动。其二跳级必翻车。2023 年 AutoGPT 火过一阵为什么没落地就是想从第 1 层直接跳到第 4 层没有趁手工具、没有验证器、没有记忆循环空转烧钱。Loop 不是买个产品就有的是在前三层地基上垒出来的。Loop 在 Harness 之上补的是四样东西自动发现、独立验证、持久化、调度正好对上三个断裂点看不见 → 发现没闭环 → 验证记不住 → 持久化。跨越单次对话的记忆就是循环和一次性操作的分界线。4、立项之前先算三笔账建 Loop 不是零成本要写 Skill、接 Connectors、调验证器。所以先回答该不该建再谈怎么建。4.1 四格检验全满才建缺一格就先补短板检验项通过标准我们的日志诊断场景你的场景① 任务会重复天 / 周级别反复发生每天都要扫日志 ✔□ 是 □ 否② 验证能自动化有客观判据机器可判对错334 条测试 6 层验证 ✔□ 是 □ 否③ Token 预算可承受单次成本可预估、可设上限分级诊断单次不超 150K ✔□ 是 □ 否④ Agent 有高工同款工具日志 / 追踪 / 发布权限齐备SLS Langfuse Pipeline 全通 ✔□ 是 □ 否反例也给两个省得对号入座跑偏一次性的架构评审不重复、提升用户体验这类目标模糊的探索没有客观判据验证没法自动化任一条件缺失就老老实实用第 3 层 Harness 的方式人工带着跑别硬建 Loop。4.2 三笔账立项汇报直接抄第一笔建设账。参考投入1 名有线上排障经验的高级工程师牵头加 SRE 半个人配合约 4 周。其中工具链Connectors建设约占总工作量的 30%这笔最容易被低估我们前两周几乎没投入后面全在还债详见第 10 节教训四。第二笔运行账。大头是 token。初期我们每次全量诊断烧 200K token一周就烧穿预算。后来改成分级小模型初筛约 5K token→ 只有高优问题才调大模型深度诊断再叠加预算熔断。给自己定两条线单次任务 token 上限、月度总预算超线自动停。第三笔收益账。拿值班人天算最直观以前一轮排查 2–3 人天还只盖得住 Top 3–5 类错误现在机器 48 分钟跑完全量人只花 1 分钟点审批。按每周两轮算一个月省 20 个人天以上这就是给老板看的那一页。5、总体设计五个动作、六个零件、两条铁律Loop 和 Harness 的本质区别一句话说清Harness 是一次运行的武装工具、动作、完成条件Loop 在 Harness 之上加了定时调度、子 Agent 并行、跨轮记忆三件事。Loop 转一圈要五个动作发现找出该做的事→交付隔离交给 Agent→验证换一个 Agent 说不→持久化状态写到对话外→调度到点自动转下一圈。少任何一个都不行少验证是在批量生产假修复少调度就退化成一次性操作你又变回那个按启动键的人。图 3Loop 五动作闭环缺验证或调度循环就退化为一次性 prompt五个动作落到六个零件上职责、断裂点、验收标准一张表看全组件一句话职责解决哪个断裂点验收标准Connectors 感知MCP 打通日志 / 追踪 / 发布让 Agent 看见线上看不见前提一条命令能查日志、串 trace、触发预发Automations 发动机定时巡检 实时告警自动触发看不见异常从第二天发现变5 分钟响应Skills 经验载体诊断 / 修复 / 发布 SOP 固化成手册记不住换一个 Agent 跑产出一致Worktrees 隔离层每个 Bug 独立工作区提效率多问题并行修互不覆盖Sub Agents 裁判独立验证修复者不能自证没闭环假修复如日志降级能被拦下State 记忆修复方案 / 巡检结果落盘记不住同类问题第二次修明显更快实施依赖顺序照抄能少走弯路Connectors地基→ Automations → Skills → Worktrees → Sub Agents → State。缺一个后面的都站不住。图 4六组件协作架构与五动作映射实施依赖顺序Connectors → Automations → Skills → Worktrees → Sub Agents → State6、施工手册六个零件逐个建每个零件按同一个模板讲干什么 / 怎么建 / 验收标准 / 坑在哪。可以直接当施工检查单用。6.1 Connectors先让 Agent 看见线上世界干什么。Agent 默认只看得见本地文件系统等于蒙着眼干活。Connectors 用 MCP 把日志、模型追踪、发布流水线、IM 通知接进来没有这层后面所有组件都是空中楼阁所以它排第一。怎么建。我们用 9000 行工具链搭了六层从下往上依次是数据访问SLS 日志服务1280 行脚本 sls_logquery_tools.py7 个子命令→ 模型追踪Langfuse MCP调用链、Span 分析、token、耗时→ 发布三条 Pipeline 流水线→ 通知机器人→ 验证Playwright / DevTools 自动化→ 基础设施采集配置、告警规则、监控大盘全部 YAML / JSON 声明式进 Git。Logstore记录什么典型字段agent_logAPI 入口、Agent 路由、Python 异常request_id, file, levelmcp_client_logMCP 工具执行详情、耗时request_id, tool_name, duration_msmcp_server_log工具调用链、入参出参request_id, response_status核心能力是跨库串链路。普通做法要在三个控制台之间手工对齐request_id封装一个 trace 子命令后一条命令串起完整链路。真实案例一次 ToolException 报错值班同事在三个控制台间切了 30 分钟才拼出链路Agent 一条 trace 命令直接看清全貌[prod] 08:12:03 DiagAgent 收到诊断请求 request_idxxxxxxxx... [mcp_exec] 08:12:05 toollistReportedOperationalEvents duratinotallow8230ms statusfailed [chain] 08:12:05 Java stackTrace: RemoteServiceImpl:XXX ExceptionGroup [prod] 08:12:05 ToolException → 未捕获诊断中断一眼看清API 入口 → Agent 路由 → MCP 工具超时 → 远端 Java 855 行抛错 → 我方缺 fallback。再配合诊断 Skill 里的 git log 交叉验证还能顺手区分这是新问题还是老毛病突然恶化。验收标准。一条命令跑通查日志 → 串 trace → 触发预发部署中间不需要人切任何控制台。坑在哪。工具链建设约占总工作量 30%先花两周打地基别急着写 Skill。另外基础设施本身也要代码化Agent 发现新错误模式就补告警规则、新增日志库就更新采集配置这些改动全走 Git可回滚、可审计。 企业适配对照 文中的 SLS / Langfuse / IM / Pipeline 只是我们的技术栈 不是标准答案。对应到你家日志换 ELK / Loki / Splunk模型追踪换 LangSmith / Jaeger / SkyWalking通知换企业微信 / 飞书 / Slack发布换 Jenkins / GitLab CI / 云效。架构不变换零件即可。6.2 Automations让系统自己发现异常干什么。解决看不见10 项目的错误散在 3 个日志库50 条飙到 350 条往往第二天才有人发现。Automations 让发现这件事不再依赖有人恰好打开了控制台。怎么建。两层发现机制一层管慢性病一层管急性病第一层每日定时全量巡检cron。每天固定时间自动扫 10 项目日志深度遍历系统自己扫、自己写报告、自己归档产出错误分布、趋势分析、Call Stack、触发条件一张全局视角的体检报告。第二层实时告警。每 5 分钟扫一轮高风险事件命中即向群推卡片内嵌 Langfuse Trace 链接点开直达现场。我们配了五条规则Agent 执行超时超过 20 分钟、模型请求失败、MCP 工具异常、Skill 路由错误、严重故障100% 失败且不少于 10 次最后这条直接自动打语音电话不给没看见群消息留借口。验收标准。发现时效从天级进到分钟级告警必须带上下文trace 链接别只丢一句出错了。坑在哪。告警规则宁缺勿滥先从五条以内起步。规则一多就是狼来了群里没人看等于绕一圈回到看不见。6.3 Skills把老师傅的经验写成操作手册干什么。解决记不住。排查经验在对话里关掉就失忆Skill 把 SOP 写到磁盘上换一个 Agent 来跑产出一样。先纠正一个普遍误会SKILL.md 不是更长的 prompt而是一份严格的操作手册每个阶段规定用什么工具、查什么数据、输出什么格式、哪些步骤不许跳。规则不写死Agent 一定偷懒跳过趋势分析、不做交叉验证、看一条日志就下结论。带过实习生的都懂。我们把整条链路固化成三个 SkillSkill做什么规模关键设计诊断diagnose8 阶段结构化诊断760 行 SKILL.md每个结论必须标注证据来源修复auto-fix解析报告 → 查知识库 → 生成补丁 → 跑测试 → 提交6 步流程先查历史方案最多重试 3 轮发布deploy-and-verify安全校验 → CR → Pipeline → 预发 → 验证 → 通知11 步400 行独立 Agent 复查双重保障6.3.1 诊断 Skill8 个 Phase一步不许跳Phase做什么为什么不能跳关键工具0 澄清确认时间范围、分析模式不确认就会分析错时间段对话1 全景扫描跨 3 个日志库统计错误分布不扫全景就会遗漏类别raw-query diagnose2 时间趋势识别突增 / 慢性 / 回归模式不看趋势就分不清新旧error-trend git log3 错误详情完整 traceback 输入参数截断 traceback 就定位不了error-lookup4 Trace 追踪模型调用链、token、fallback不查 Trace 就不知道哪步失败Langfuse MCP5 代码定位精确到 file:line Owner不定位就没法修Read git log6 根因分析六类分类 证据链推理没证据链就是猜交叉验证7 修复建议短期止血 长期根治没建议等于没诊断——两个精华设计值得单独说其一git log 交叉验证Phase 2。Agent 不能只看错误首次出现的时间就下结论必须对着代码变更历史比对判断标准直接写死在 Skill 里# 结合 git log 交叉验证判断标准写死在 Skill 里 git log --oneline --since错误首次出现时间 -- 相关目录 首次出现 7 天且有对应代码变更 → 新问题 首次出现 14 天 → 长期问题 错误曲线突变 → 突发恶化 消失后复现 → 回归其二证据链格式Phase 6。每个结论必须按 [事实] → [推理] → [结论] 输出每条事实标注证据来源哪个日志库、第几条、request_id 是什么。这一条把Agent 拍脑袋直接堵死没有证据链的结论一律打回。[事实①] SLS 日志显示 toollistReportedOperationalEvents 返回 ExceptionGroup ↳ 证据来源SLS error-lookup 结果第 3 条request_idxxxxxxxx... [事实②] Error message 包含 Java stackTrace: RemoteServiceImpl:XXX ↳ 证据来源traceback 中 ToolException 消息体 [推理①] 远端 Java 服务在处理该 instanceId 时抛出内部异常 ↳ 依据事实①② —— ExceptionGroup 嵌套了 Java stackTrace [结论] 根因是远端 Java 服务 Bug一级责任我方缺少 fallback二级责任 ↳ 分类外部系统诊断的落点是根因分类六选一每类对应明确的修复方向根因分类修复方向示例外部系统异常防御式try-except fallback retryMCP 工具返回 Java stackTrace → 降级返回空结果内部代码缺陷精确修改 file:lineTypeError 在 src/deep_diagnose/改 repository.py:45基础设施问题配置调整连接池 pool_size5, max_overflow10LLM / 模型异常Prompt 约束 schema 校验幻觉编造不存在的表名 → 查询前验证表名存在预期行为误报确认后降级日志级别CancelledError数据问题不修转工单给 Owner用户数据异常注意最后一类数据问题不让 Agent 修直接转工单给人。知道什么不该自动化和知道什么该自动化一样重要。6.3.2 修复 Skill6 步先查知识库再动手诊断报告就是接口修复 Skill 读取结构化报告后自动接管人不需要在中间传话Step 1 解析诊断报告提取根因分类 file:line traceback Step 2 grep 知识库命中 → 直接复用历史方案跳到 Step 4 Step 3 生成修复补丁按根因分类选择修复模式 Step 4 运行测试先跑受影响模块再跑全量 334 个 case Step 5 提交代码创建 feature 分支 push Step 6 触发部署验证→ 进入发布 SkillStep 2 是复利所在知识库积累了 30 条修复方案YAML 格式命中直接复用。连接池问题首次修复花了 48 分钟有知识库之后 15 分钟。修复原则三条最小化改动、保持向后兼容、外部系统问题一律 try-except 包裹。测试不过就调整重跑最多 3 轮超过自动升级人工成功率 95% 的事连乘 N 次就归零别让 Agent 在错误方向上无限重试。6.3.3 发布 Skill11 步到预发全自动生产只留一个人工卡点修复完成后11 个步骤一条命令触发步骤做什么关键约束⚠ 0 安全校验确认是正确的仓库和应用仓库 App ID 地址三重匹配任一不符立即停止1 自动提交创建 feature 分支 推送禁止直推 master / develop2 CR Reviewer创建 Code Review、指定审查人MR 目标必须是 develop 分支3 提交 Pipeline触发预发部署流水线仅预发流水线生产流水线无权限⚠ 4 预发功能验证针对本次修改的集成测试自主回归必须指定 skill_names 聚焦测试5 Langfuse Trace 验证0 ERROR 正确模型 token 上限不允许非预期 fallback6 预发诊断复查调用诊断 Skill 扫描预发环境部署后不能有新增 ERROR 类型7 线上对比Langfuse Trace 对比预发 vs 线上行为偏差则阻塞发布8 产出测试报告写入 docs/reports/结构化 Markdown9 IM 通知推送审批卡片含业务价值 MR 链接 报告 Trace 链接10 输出总结全流程状态汇总通过 / 失败 / 跳过 一目了然三个最容易踩坑的步骤单独拎出来Step 0 安全校验。执行前验证仓库、App ID、仓库地址三重匹配任一不符立即停止防的是 Agent 把补丁提到别人家仓库这种事真的会发生。Step 4 集成测试必须聚焦。必须指定skill_names否则系统加载全量工具集测试就不聚焦了curl -s -N -X POST $BASE_URL/api/v1/chat \ -H Authorization: Bearer $TOKEN \ -d { question: 诊断目标机器的故障原因, agent: DiagAgent, skill_names: fault-diagnose, ← 必须指定否则加载全量工具集 model: your-model } --max-time 300Step 5–7 构成三层自主回归。Langfuse Trace 硬指标 独立诊断复查部署后不能有新增 ERROR 类型 预发 vs 线上行为对比。任一偏差阻塞发布打回修复 Skill 第 2 轮。四项硬指标如下检查项通过标准为什么ERROR observations必须为 0任何 ERROR 说明还有未处理异常主模型与请求一致无非预期 fallbackfallback 说明首选模型有问题max input_tokens不超过 150K超过说明 context 窗口快溢出Agent finishedTRUEFalse 说明 Agent 中途崩溃最后一个细节Step 9 的 IM 审批卡片必须包含业务价值描述 MR 链接 测试报告 Trace 链接让 Reviewer5 秒内判断得了 merge 风险。审批体验好人才愿意长期当这个卡点别小看这一条它决定了流程能不能持续跑下去。6.4 Worktrees并行修复不打架干什么。诊断一次往往扫出多类错误每类要独立修复。早期三个 Agent 在同一工作区同时改代码后提交的覆盖前者冲突率约 30%一轮 token 白烧。怎么建。git worktree同一仓库检出多个物理隔离的工作目录共享 .git 历史复制git worktree add ../fix-timeout fix/db_connection_timeout_20260620_01 git worktree add ../fix-hallucination fix/llm_hallucination_20260620_02 git worktree add ../fix-mcp fix/mcp_tool_failure_20260620_03一个 Agent 在 ../fix-timeout 改连接池配置另一个在 ../fix-hallucination加 schema 校验互不干扰。每个分支独立走完修复 → 测试 → CR → Pipeline → 验证全流程才合并到 develop若两分支改了同一文件第二个合并前先 rebase 再重跑测试。分支命名约定fix/问题描述_日期_序号谁看都秒懂。效果。三类问题串行约 45 分钟并行 17 分钟最长的一类 合并开销冲突率从 30% 降到不足 5%git worktree add的 setup 成本不到 1 秒。图 5Git Worktree 并行修复大部分修复涉及不同文件物理隔离后冲突可控6.5 Sub Agents修复者不能给自己打分干什么。解决没闭环。道理跟考试一样让学生自己批卷子人人都是满分。怎么建。六层独立验证生成者与评判者物理分离图 6六层独立验证体系多层独立验证 × 相互隔离 × 结果可追溯 高质量交付还记得那次 logger.error → logger.warning 的假修复吗只靠单元测试它完全能混过去第 3 层独立诊断复查就是为它设的日志级别改了Langfuse Trace 里的 ERROR observation 还在。修复 Agent 能骗自己骗不了拿不到修改权限的验证 Agent。6.6 State让同类问题越修越快干什么。解决记不住的后半段。经验必须落盘Loop 才有复利。怎么建。三类 State 各司其职知识库沉淀修复方案30 条 YAML修复 Skill 第 2 步先 grep 它每日巡检数据归档跨天可追溯趋势基础设施配置告警规则、采集配置、监控大盘全部 Git 版本化Agent 发现新错误模式就补规则检测网越织越密。验收标准。就看一条曲线同类问题第 N 次的修复时长。我们的连接池类问题48 分钟 → 15 分钟。曲线不降说明 State 没生效。6.7 串起来一条端到端流水线六个零件拼成完整链路触发 → 感知 → 诊断 → 修复并行→ 验证 → 发布 → 沉淀。验证不过自动回到修复最多 3 轮3 轮不过推送 IM 工单升级人工。跑成功后修复方案写入知识库State监控策略同步更新Automations 反哺下次同类问题直接复用。图 7端到端 Loop 闭环3 轮失败升级人工避免 0.95^N 在错误方向上空转小结一遍Connectors 让 Agent 看见线上世界Automations 让发现不再靠人Skills 把老师傅的经验固化成 SOPWorktrees 让多类问题并行不打架Sub Agents 确保修复者不能自证State 让同类问题越修越快。拼起来就是那条 48 分钟、0 人工介入的闭环。7、跑起来什么样一天的真实流水账上周一次真实运转时间线原样贴出来08:00Automation 定时启动扫描 10 项目日志 08:05诊断 Skill 发现 3 类异常连接池超时 / LLM 幻觉 / MCP 工具失败 08:08开 3 个 Worktree 并行修复三类问题同时处理 08:25修复完成334 / 334 单元测试通过 08:28自动提交 CR → Pipeline 构建 → 预发部署 08:40预发集成测试通过 Langfuse Trace 验证0 ERRORtoken 在 150K 以内 08:43独立诊断 Skill 复查预发环境无新增 ERROR 08:45IM 推送审批卡片含 MR 链接 测试报告 Trace 链接 08:48人工确认后发布上线——生产部署是唯一需要人的环节✅ 结果 从发现到待发布全程 48 分钟人工介入 0 次。以前同样的事值班同事至少 2–3 天还只能覆盖 Top 3–5 类错误。失败的时候什么样也得交代信任来自失败处理不来自成功案例上周三一个连接池补丁导致 2 个单测失败修复 Skill 自动进入第 2 轮分析失败原因、调整 mock 参数、重跑测试通过。如果第 3 轮还不过自动停止并推送 IM 工单给 Owner绝不在错误方向上无限重试。阶段传统方式我们的 Loop提升发现值班同事第二天看日志5 分钟内自动告警 每日全量扫描天级 → 分钟级诊断人工复制日志喂 AI两三天盖住 Top 3–58 阶段结构化诊断48 分钟全部根因定位覆盖率 Top 5 → 全量修复人写补丁、跑测试、提 CR自动生成补丁 → 跑 334 个测试 → 提交人工半天 → 自动 15 分钟验证修复者自己说好了6 层独立验证修复者不能给自己打分消灭假修复发布手动部署 人工检查自动预发 → 集成测试 → Trace 验证 → IM 推送全自动到预发沉淀关掉对话就忘了修复方案自动写入知识库同类问题 48min → 15min经验可复用8、四周施工计划照抄就能开工图 8四周落地甘特图第一周的产出看起来少但决定了后面四周是建设还是返工周干什么产出验收标准周 1四格检验 选试点场景一张四格表 一个确定的目标场景四格全满周 2–3建 Connectors接日志 / 监控 / 发布Agent 能查日志、能触发发布一条命令跑通全链路周 4写第一个 Skill 加定时调度每天自动跑一轮 Loop连续 3 天无人值守运转贯穿每周人工抽查 3 个 diff 复盘抽查记录无未审出的高危变更试点场景怎么选三条标准错误量适中每周几十到几百条太少喂不饱循环太多一上来兜不住测试覆盖较好验证器现成四格检验第②格才打得了勾避开核心资金 / 交易链路给自己留容错空间安全评审也好过。分工建议牵头人选有线上排障经验的高级工程师他脑子里的排障 SOP 就是诊断 Skill 的初稿SRE 配合开日志 / 监控只读权限平台组配合开 CI/CD 预发触发权限再给 Agent 申请一个专用账号权限矩阵见下一节。一个心态提醒第一周的产出看起来会很少就一张表、一个场景。忍住别跳过。四格检验没过、硬着头皮上的项目大概率死在第 5 周。9、安全、审批与风控拿去过评审这一节是写给你拿去过安全评审和老板审批用的可以直接抄。第一件事权限最小化。给 Agent 开一个专用账号权限矩阵如下资源Agent 权限说明日志 / 监控只读通过 MCP 访问敏感字段在 Connector 层脱敏后再给 Agent代码仓库可建分支、提 MR禁止直推 master / develop所有变更走 CR 留痕CI / CD仅预发流水线生产流水线不给触发权限生产环境无任何权限生产发布由人在审批后手动触发IM 通知可发消息用于告警卡片、审批卡片、工单第二件事四道保险丝。① 重试熔断验证失败自动重试最多 3 轮3 轮不过停止并推工单升级人工② 预算熔断单次任务 token 上限 月度总预算上限超线即停③ 每周抽查人工至少抽查 3 个已合并 diff教训一的血泪见下节④ 三重安全校验执行发布前验证仓库 App ID 仓库地址三重匹配任一不符立即终止。第三件事全程留痕。每次修复自动归档 MR 链接、测试报告、Trace 链接、审批记录审计要什么给什么。图 9风控卡点与四道保险丝自动化止步于预发生产发布永远由人按下按钮9.1 评审现场常被问的四个问题QAgent 把线上改坏了怎么办A它到不了线上。自动化止步于预发生产发布是唯一人工卡点预发之前还有 6 层验证 3 轮熔断。真正要防的反而是人连续两周不看 diff 盲批所以有每周抽查制度兜底。Qtoken 会不会烧穿预算A分级策略小模型初筛约 5K token只有高优问题才调大模型深度诊断再叠加单次 / 月度双熔断。我们踩过单次 200K 的坑改完之后成本完全可预估。Q安全部门不让 Agent 碰生产日志怎么办A两个折中一是日志在 Connector 层脱敏后再给 Agent二是先从预发 / 测试环境的日志起步跑通闭环价值验证后再谈生产只读权限。闭环架构不变数据源可以逐步升级。Q我们没有 334 条测试怎么办A那四格检验第②格验证能自动化就是空的先补测试再建 Loop。顺序不能反验证器是循环的地基不是装饰。10、我们踩过的四个坑每条都值几万 token教训一连续两周不看 diff 就合并。系统越好用人越松懈。结果一个 Agent 把 retry3 改成了retry0线上超时率翻倍。对策每周至少人工抽查 3 个 diff写进值班表。教训二验证器覆盖不全 假安全感。初版只有单元测试logger.error → warning 那次假修复就是这么混过去的因为第 3 层预发日志验证还没上线。对策至少 3 层验证才允许自动合并。教训三Token 成本失控。初期每次全量诊断烧 200K token一周烧穿预算上限。对策分级策略小模型 5K 初筛 → 高优问题才调大模型深度诊断 预算熔断。教训四Connectors 建设被低估。工具链SLS 查询脚本 Langfuse MCP 发布脚本占了总工作量 30%但前两周几乎没投入后面全在还债。对策先花两周打好 Connectors 地基再建上层。11、效果怎么量化、怎么向上汇报三个 KPI正好对着三个断裂点KPI怎么定义我们的变化对应断裂点发现时效异常出现 → 被发现的时间天级 → 5 分钟内看不见同类修复时长同类问题第 N 次修复耗时48 分钟 → 15 分钟记不住人工介入次数发现到预发之间的人工动作数每次都要 → 0 次没闭环给老板的汇报模板一句话本月 Loop 自动处理线上问题 X 类 / Y 次节省值班 Z 人天全部变更经 6 层验证 人工审批0 起生产事故token 成本 W 元约合每人天成本的 1/N。再配一个每周看板盯三条曲线ERROR 总量趋势该降、修复轮次分布1 轮过 / 2 轮过 / 3 轮升级人工的占比1 轮占比该涨、知识库命中率该涨命中率涨说明复利在生效。12、结语从推循环的人变成设计循环的人范式迁移的核心变化不是工具是人的角色Prompt 时代你是指令官Context 时代你是材料员Harness 时代你是工具配置师。到了 Loop 时代你是循环设计师。不再亲手查日志、写修复、跑测试、推发布而是设计让这些事情自动发生的规则系统。架构师管理的不是系统是系统背后的规则。我们已经在这条路上走出了第一步日志诊断 Loop 证明了从发现到预发的全链路可以自动转。下一步是把同一副骨架五动作 六组件复制到更多项目换 Connectors、换 Skills、换验证器架构不变。2025 年我们以为 AI 解决的是写代码慢一年后发现真正的瓶颈是维护循环仍靠人在推。Loop Engineering 不是一种产品是一种工程思维不再问这条 prompt 怎么写更好改问这个循环能不能自己转。别再当循环里最慢的那一环去设计循环。