清洗说明：从微信公众号「Soyoger」2026-07-20 推送抓取，已去掉微信号、二维码、运营推广等噪声；正文按”开篇痛点 → 三处断裂诊断 → 四层进化 → 三笔账 → 5 动作 + 6 零件 → 三套 Skill → 6 层验证 → 真实数据 + 4 教训”结构完整保留；代码示例（sls trace / curl POST / 6 层 validate_fix 伪代码）完整保留；公众号文末互动话题”你们现在有在跑自动化维护循环吗？”已剔除。
AI 推高了研发速度，却把维护成本默默转移给了值班工程师。
上个季度，我们团队有个工程师每天早上做的第一件事，是打开三个日志控制台，在 agent_log、mcp_client_log、mcp_server_log 三个 Logstore 之间来回切，手动拼出每个 ERROR 的完整链路。
平均一个排查下来：40 分钟。一周还有 1000 多条 ERROR 等着。
那一刻我突然意识到：我们用 AI 把写代码的速度翻了一倍，但上线之后的维护循环，还是全靠人在推。
AI 写代码很快，但发现问题 → 定位根因 → 修复 → 验证 → 发布，这条链路的每一步，我们都还是人工在中间接棒。这不是 AI 不够聪明，是我们根本没有把维护链路当成一个需要工程化设计的系统。
这篇文章，复盘我们从「人工维护循环」改造成「Agent 自维护体系」的完整过程：
我们花了两周复盘，维护循环卡死，绝大多数情况不是 AI 不够用，而是卡在三个极其具体的地方。
我们系统一周能产出 1000+ ERROR，散在三个日志库里。值班工程师打开控制台，一眼只能看到”热门”的几条，真正高频但低曝光的错误，往往三四天才被人发现。
有一次某类错误从每天 50 条飙到 350 条，整整晚了 24 小时才有人注意到。
自查方法很简单：如果你们的线上 ERROR 量突然翻 5 倍，团队多久能发现？超过 1 小时的，都算”看不见”。
这个坑我们踩得最痛。
有一次排查连接池超时花了整整一天——根因是某个方法设了 2 秒的激进超时值，修完写在 AI 对话里，第二次出同类问题照样从头来。
AI 在对话窗口里推理得头头是道，但关掉窗口它就失忆了。没有任何东西把这次排查经验持久化下来，下次换个人值班，又是重新走一遍。
自查：同一类问题出现第二次时，你们修得比第一次快吗？快不了，就是”记不住”。
这是最隐蔽的一个坑。
有次 Agent 汇报”已修复”，点开代码一看——它把 logger.error 改成了 logger.warning。错误还在，只是不喊了。
掩盖故障和合理降级，只有独立验证才能区分，不能让修复者自证。
这三处断裂点，刚好对应三个本质缺失：看不见 = 缺自动发现；记不住 = 缺持久化；没闭环 = 缺独立验证。把这三个补上，维护循环才能真正自转起来。
在说怎么做之前，有必要说清楚，这套东西在 AI 工程化里处于哪个位置。
我理解 AI 工程化走了四层楼：
我们现在做的，就是第四层。
有个认知很重要：跳级必翻车。2023 年 AutoGPT 火了一阵，就是直接从第一层跳到第四层，没有趁手工具、没有验证器、没有记忆，最后循环空转烧钱，没有落地。Loop 不是买一个产品就有的，是在前三层地基上垒出来的。
建这套东西不是零成本，别头脑一热就冲。
反例也说一下：一次性的架构评审（不重复）、目标模糊的用户体验优化（没有客观判据）——这两类条件缺失，就老老实实用 Harness 人工带着跑，别硬建 Loop。
Loop 转一圈，本质上是五个动作：
发现（找出该做的事） → 交付（隔离交给 Agent 执行） → 验证（换一个独立 Agent 说”不”） → 持久化（状态写到对话外） → 调度（到点自动触发下一圈）
少任何一个都不行。少”验证”，等于在批量生产假修复；少”调度”，整个循环就退化成一次性操作，你又变回那个每天手动按启动键的人。
五个动作落到六个具体零件上：
实施顺序不能乱：Connectors → Automations → Skills → Worktrees → Sub Agents → State。每一层依赖前一层，跳层必踩坑。
这是整套体系最容易被低估的一步。
Agent 默认只能看见本地文件系统，等于蒙着眼干活。没有 Connectors，后面所有零件都是空中楼阁。
我们用 MCP 打通了六层数据接口：
核心能力是跨库串链路。以前值班工程师排查一个 ToolException 报错，要在三个控制台之间切换 30 分钟拼出完整链路；封装 trace 子命令后，一条指令串起全貌：
1
2
3
4
5
$ sls trace --request-id=xxxxxxxx
[prod] 08:12:03 DiagAgent 收到诊断请求 request_id=xxxxxxxx...
[mcp_exec] 08:12:05 tool=listReportedOperationalEvents duration=8230ms status=failed
[chain] 08:12:05 Java stackTrace: RemoteServiceImpl:XXX ExceptionGroup
[prod] 08:12:05 ToolException → 未捕获，诊断中断
一眼看清：API 入口 → Agent 路由 → MCP 工具超时 → 远端 Java 抛错 → 我方缺 fallback。再配合 git log 交叉验证，能顺手判断这是新问题还是老毛病突然恶化。
验收标准只有一个：一条命令能查日志、串 trace、触发预发部署，中间不需要人切任何控制台。达不到这个标准，Connectors 就没建完，后续 Skill 写了也是残废。
很多人把 SKILL.md 当作”更长的 Prompt”，这是根本性误解。
SKILL.md 是一份严格的操作手册，不是一段描述。每个阶段规定用什么工具、查什么数据、输出什么格式、哪些步骤不许跳过。规则不写死，Agent 一定偷懒——跳过趋势分析、不做交叉验证、看一条日志就下结论。带过实习生的人都懂这个道理。
我们把整条链路固化成三个 Skill：
Phase 2 的 git log 交叉验证是精华——判断标准写死在 Skill 里，Agent 不能自由发挥：
1
2
3
4
5
git log --oneline --since="<错误首次出现时间>" -- <相关目录>
- 首次出现 <7 天，且有对应代码变更 → 新问题（优先排查最近提交）
- 首次出现 >14 天 → 长期问题（检查是否被其他修复掩盖）
- 错误曲线突然突变 → 突发恶化（对比前后版本变更）
- 消失后复现 → 回归（排查上次修复是否不彻底）
Phase 6 的证据链格式，是把”Agent 拍脑袋”堵死的核心机制：
1
2
3
4
5
6
7
8
[事实①] SLS 日志显示 tool=listReportedOperationalEvents 返回 ExceptionGroup
↳ 证据来源：SLS error-lookup 结果第 3 条，request_id=xxxxxxxx...
[事实②] Error message 包含 Java stackTrace: RemoteServiceImpl:855
↳ 证据来源：traceback 中 ToolException 消息体
[推理①] 远端 Java 服务在处理该 instanceId 时抛出内部异常
↳ 依据：事实①② —— ExceptionGroup 嵌套了 Java stackTrace
[结论] 根因是远端 Java 服务 Bug（一级责任），我方缺少 fallback（二级责任）
↳ 分类：外部系统异常
每个结论必须标注证据来源，没有证据链的结论，一律打回重做。
根因分类六选一，每类对应明确的修复方向：
最后一类要单独说：数据问题不让 Agent 修，直接转给人。知道什么不该自动化，和知道什么该自动化一样重要。
诊断报告就是接口，修复 Skill 自动读取结构化报告接管后续，人不需要在中间传话：
Step 2 是整套体系的复利飞轮。知识库现在积累了 30+ 条修复方案（YAML 格式）。连接池超时这类问题，第一次修复花 48 分钟，有知识库之后 15 分钟搞定。随着知识库积累，命中率越来越高，修复越来越快。
修复原则写死三条：最小化改动、保持向后兼容、外部系统问题一律 try-except 包裹。
测试不过就调整重跑，最多 3 轮，超过自动升级人工。这条限制很关键——成功率 95% 的事情连乘 N 次就归零，别让 Agent 在错误方向上无限重试，那只是在烧 Token。
修复完成，11 个步骤一条命令触发：
1
2
3
4
5
# 正确：聚焦测试受影响的 Skill
curl -X POST "$BASE_URL/api/v1/chat" -d '{"skill_names": ["diagnose_cloud"], "query": "验证连接池超时修复"}'
# 错误：不指定 skill_names，全量加载，测试漫无目的
curl -X POST "$BASE_URL/api/v1/chat" -d '{"query": "验证连接池超时修复"}'
从发现问题到这里，人工介入次数：0 次。人唯一要做的事，是看完审批卡片，点一下”批准”。
回到那个把 logger.error 改成 logger.warning 的案例。
如果验证也由同一个 Agent 完成，它大概率会汇报”验证通过”。这不是模型能力问题，是设计问题——修复者永远不应该给自己打分。
Sub Agents 的职责是做独立裁判：修复 Agent 提交补丁后，由一个全新启动的验证 Agent 来判断修复是否真实有效。我们配了 6 层验证：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 验证 Agent 的六层检查（伪代码示意）
def validate_fix(fix_report, env="staging"):
checks = [
check_unit_tests_pass(fix_report), # 单元测试全绿
check_no_new_errors(env), # 预发无新增 ERROR 类型
check_trace_normal(env), # Langfuse Trace 0 ERROR
check_log_level_not_downgraded(fix_report), # 拦截日志降级假修复
check_backward_compatible(fix_report), # 保持向后兼容性
compare_behavior(env, "production") # 预发 vs 线上行为一致
]
failed = [c for c in checks if not c.passed]
if failed:
# 验证不通过，打回修复 Agent 重做
return ValidationResult(passed=False, failures=failed)
return ValidationResult(passed=True)
这段逻辑做了一件事：把验证权从修复者手中移走，交给独立的裁判。假修复（如日志降级）能被第四层 check_log_level_not_downgraded 直接拦截。
没有独立验证，自动化修复等于在批量生产假绿灯。
三个数字背后是同一条每天在跑的链路：一句指令，Agent 从 3 个日志库挖出 Bug → 诊断根因 → 生成补丁 → 跑完 334 条测试 → 提交 CR → 预发部署 → 集成验证 → 推送审批卡片。人只需要点一下”批准发布”。
AI 写代码只是开始，维护循环才是真正的战场。
2026 年很多团队已经用 AI 把研发速度拉满，但维护成本却在默默爬升——因为写代码的速度快了，上线之后出问题的频率也高了，维护循环还是靠人推。
我的判断是：下一个工程化能力的分水岭，不在写代码的速度，而在维护循环能不能自己转。做到这件事的团队，会把那些还在手动拼日志的团队越甩越远。
备注：
[事实①] [证据来源] [推理①] [结论] 完整保留