给270万行代码开“上帝视角”：Agent 自主定位根因实践
何新昇约 22 分钟开发者公众号专属群聊
扫码加入获取更多一手教程、科技前沿报告
腾讯广告的商品数据生产链路是由60+个在线服务、50+个存储节点、490+条数据流关系与270万行代码构成的复杂分布式系统，异常会沿数据流和调用链跨服务级联传播，表象与根因往往不在同一位置，排查高度依赖经验，处置结论也难以复用。为解决这些问题，团队以系统拓扑图为核心构建统一知识底座，引入问题发现、根因分析、自主修复和 Self-Improving 等 Agent 协同，将异常识别、证据取证、受控修复与经验沉淀整合成自治闭环。
面对复杂分布式系统中跨服务、长链路传播的异常，依靠局部排查和单点优化已难以稳定解决问题，建设贯通全链路、可持续进化的治理闭环成为了必然选择。让异常持续被发现、根因基于证据收敛、修复在安全边界内推进，并把经验沉淀为下一轮能力，使问题治理从被动救火走向系统免疫，如图1所示。
图1 从割裂排查到持续进化的系统免疫闭环
闭环的核心，是具备把局部信号放回全局链路理解的能力，需要理解异常如何产生、传播并最终显现。系统拓扑图将节点、数据流、调用依赖组织成结构化关系，并结合业务知识库和代码库，为各类 Agent 提供共享的“上帝视角”。商品数据的系统拓扑图如图2所示，图中的每个矩形节点都是一个在线服务、圆形节点是存储节点，每条边都是一条数据流。
图2 商品数据链路的系统拓扑图
闭环最终形成两类价值：对当前问题，更快定位真正根因、缩短异常影响时长；对长期治理，把有效路径、失败经验和修复策略沉淀为“免疫记忆”，让系统在下一次异常中发现得更早、定位得更快、处置得更稳，并持续减少同类问题复发。
01
1.1 复杂系统的问题，不再是单点故障
商品数据从接入到最终可用，通常要经过接入、解析、加工、理解、生产、分发和检索等多个阶段。整条数据链路涉及110+个节点（60+个在线服务、50+个存储节点）、490+条数据流关系、270 万行代码，同时混合RPC、消息队列、异步回调、云函数、数据库、缓存和外部依赖。
在这类系统中，异常发生位置和真正根因位置很可能不在同一个地方。例如某服务错误日志突然增加，也可能只是上游脏数据、配置变更或下游依赖抖动造成的连锁反应。
如果缺乏全链路视角，排查会自然陷入三个局限：
信息分散：告警、日志、指标、代码、配置和变更记录分布在不同系统中，研发需要频繁切换工具并手工拼接上下文，难以快速形成完整事实；
关系不可见：异常会沿数据流、RPC、消息队列、异步任务和上下游依赖跨节点传播；如果看不到节点之间的真实关系，就难以从现象反向追踪传播路径并收敛到真正根因；
经验难复用：服务职责、排查路径和历史结论主要掌握在少数核心研发手中，缺少结构化沉淀；新人接手慢，同类问题再次发生时仍需要重复学习和试错。
1.2 传统排查为何既低效，又难以沉淀系统能力
传统问题处理的目标通常是“尽快恢复当前故障”。监控发出告警，研发临时拉取日志、询问上下游、阅读代码，最终找到原因并完成修复。面对跨越多个服务和数据节点的级联异常，这种方式需要研发在不同监控、日志、代码仓库和上下游团队之间频繁切换，问题根因定位慢，异常影响时长也随之被拉长。问题虽然关闭了，但排查路线、关键证据、错误尝试和判断依据往往散落在聊天记录、个人记忆和临时文档中，没有真正回到系统。
这意味着同类问题再次发生时，团队仍要重新经历一次发现、理解和取证过程。即使上一次已经投入了大量专家经验，系统本身并没有获得“免疫记忆”。长期来看会形成四个反复消耗：
重复识别：已出现过的异常模式仍要依靠人工重新判断，发现时机没有提前；
重复学习：研发每次都要重新理解服务职责、上下游关系和数据传播路径；
重复试错：排查从报警节点开始逐个尝试，已被证伪的路径无法自动复用；
重复修补：修复只消除当前症状，没有沉淀验证规则，也无法系统性降低复发概率。
因此，闭环首先要解决的不只是“让某一次排查更自动”，还要直接提升研发同学的问题排查效率。系统拓扑图、业务知识库和代码库构成统一知识底座，根因分析Agent基于这份全局认知自主规划路径、并行取证并快速收敛到真正根因，减少研发跨系统查询和人工试错，从而缩短从异常发生到根因确认的时间，降低异常问题的影响时长。与此同时，问题发现、根因分析和自主修复在同一份系统认知上协同工作，生产环境的结果和人工反馈再回流到知识底座。只有这样，当前事件的处置结果才会成为下一次事件的起点，而不是随着工单关闭一起消失。
1.3 闭环如何沉淀为系统免疫力
建设闭环的价值，不只是把一次问题处理得更自动，而是让系统在每次异常处理中同时获得解决当前问题和增强后续能力的收益。问题发现、根因分析、自主修复与 Self-Improving 共享同一知识底座，最终形成四项可直接感知的系统能力：更早发现、更快定位、更稳处置、持续进化。
表1 闭环体系形成的系统免疫能力
如表1 所示，这些能力不是彼此孤立的功能，而是同一套闭环机制共同产生的结果：发现越及时，可用于分析和处置的窗口越充足；定位越准确，研发投入和异常影响时长越可控；修复越受控，变更带来的二次风险越低；经验沉淀越完整，后续处理同类问题时就越少依赖重复试错。
其中，知识底座承担跨轮次连接作用。系统拓扑图保存节点关系、数据流和异常传播路径，业务知识库与代码库保存服务职责、历史案例、根因证据和修复策略。每轮闭环产生的新证据、新结论和生产验证结果都会持续回写，使后续排查不再从零开始。
因此，闭环同时创造两类价值：本轮由根因分析 Agent承担跨服务探索与多源取证，帮助研发更快定位问题根因、提升排查效率并缩短异常影响时长；长期则把有效路径、失败经验和修复结果沉淀为可复用的“免疫记忆”，推动同类问题从重复处理走向更早识别、更少试错和更稳处置。
02
总体设计的核心，是为 AI 建立能够看清全局关系的“上帝视角”。系统拓扑图将节点、数据流、调用依赖、异常传播路径与取证入口组织为可计算、可推理的关系，业务知识库和代码库补充业务语义与实现细节，共同构成统一知识底座。在此基础上，问题发现 Agent、根因分析 Agent和自主修复 Agent 协同工作，Self-Improving 持续回写生产结果与经验，让每次异常处理都增强下一轮能力，形成持续进化的治理闭环。
图3 以“上帝视角”支撑问题发现、根因分析与自主修复闭环
2.1 五个关键组成共同构成闭环体系
整体由一个知识底座和四个关键 Agent能力构成，分别承担系统认知、问题发现、根因定位、自主修复和持续进化。
知识底座——系统拓扑图提供“上帝视角”：由系统拓扑图、业务知识库和代码库组成，其中系统拓扑图是核心。它将节点、数据流、调用依赖、异常传播和取证入口转化为可计算、可遍历、可推理的结构化知识，为各类Agent 提供统一、持续更新的全局系统认知。
问题发现 Agent——主动识别可疑信号：周期性监控指标波动和错误日志，结合动态阈值、历史基线与日志聚类来识别异常。其中我们会更关注对错误日志的异常识别，因为监控可能会漏报，或者监控颗粒度太粗导致长尾信号无法触发告警，可一旦系统有异常都会默认打印出错误日志，基于错误日志更容易发现长尾的潜在问题。
根因分析 Agent——自主探索并定位真正根因：基于系统拓扑图+源代码，结合日志、监控、配置、变更记录等信息来进行根因定位，可实现多跳级联分析与代码级定位。定位时不依赖人工经验SOP，只信任线上实际运行的代码，自主进行规划探索，也因此可应对各类已知、未知的问题。
自主修复 Agent——将代码 Bug 转化为受控变更：只处理已确认的代码 Bug，基于根因证据设计方案、修改代码、执行验证并发起MR，由人工 Review守住发布边界。外部数据源问题则输出证据和建议，转人工协同处理。
Self-Improving——沉淀经验并增强下一轮能力：汇总有效路径、排除路径、推理失败、Review反馈和生产验证结果，沉淀成经验，持续反哺知识底座，使后续问题能够更早发现、更快定位、更稳处置。
2.2 闭环运行机制与安全边界
闭环的主路径：生产环境产生运行信号 → 问题发现 Agent 或研发发起排查 → 根因分析 Agent 自主探索与证据收敛 → 根因分类 → 外部数据问题转人工协同，代码 Bug 进入自主修复、MR和人工 Review → 发布回生产环境。
过程中形成两类反馈：一是根因结论、排除路径、修复方案和生产验证结果经Self-Improving回写知识底座，形成可复用的“免疫记忆”；二是发布后的监控、日志和业务结果重新进入问题发现环节，用于验证修复效果并触发下一轮分析。因此，知识底座既为本轮提供全局认知，也承接本轮新增的证据和经验。
为保证闭环安全可控，运行过程遵循三个原则：
统一认知：各 Agent读取同一份系统拓扑、业务知识和代码知识。
证据驱动：继续探索、根因分类和进入修复都必须有结构化证据支撑。
受控行动：代码 Bug 可自动生成修复和MR，但生产发布保留人工Review；外部数据问题只输出证据和建议，转人工处理。
03
3.1 系统拓扑图：先让 Agent 真正理解系统
3.1.1 拓扑图应表达什么
传统架构图主要服务于人，常以方框和连线表达宏观关系；面向 Agent的拓扑图必须进一步结构化。一个可用于推理的节点至少要包含：
节点身份：模块、服务、任务、消息主题、数据库、缓存或外部依赖。
业务职责：该节点在商品数据链路中“负责什么”。
输入输出：处理什么数据、产出什么数据、关键字段是什么。
依赖关系：上游、下游、同步/异步方式、触发条件和失败传播方向。
取证入口：日志索引、监控指标、告警规则、配置中心和代码仓库。
治理属性：负责人、风险等级、可自动操作范围、验证项和回滚方式。
边也不能只有“调用”一种语义，而应区分数据流、控制流、调用关系、异步通知和配置依赖。只有这样，Agent才能回答“从现象反查上游”“沿调用链穿透到外部依赖”“评估一次修改影响哪些节点”等问题。
3.1.2 为什么不能靠人工一次性绘制
面对60+个在线服务、50+个存储节点和490+条数据流，人工绘制存在三个现实问题：成本高、容易漏、很快过期。更麻烦的是，文档里的理想架构与代码中的真实调用关系可能并不一致。
因此，我们采用多 Agent 协作的 Harness 工作流自动建设拓扑，用强化学习思想，实现多Agent自我迭代和多轮演进。
主 Agent：拆分模块和仓库，规划全局探索顺序，阅读业务知识、代码、配置和接口定义，提取节点、输入输出与依赖关系，根据代码梳理全局模块拓扑图，并根据质检和总结反馈不断迭代优化；质
检 Agent：随机抽取模块反向核验，只认可代码、配置与运行证据中的真实关系，识别错连、漏连和语义错误；
总结 Agent：汇总探索中的共性问题，沉淀新的扫描规则和提示模板，避免主 Agent 与质检 Agent 重复犯错；
园丁Agent：负责变更驱动的增量更新，变更触发器监听业务知识库、代码库和配置变化，定位受影响节点并触发相关子图增量更新，而不是周期性全量重画。
图4 基于多Agent的系统拓扑图构建系统
3.1.3 从“画一张图”到“经营一份活资产”
拓扑建设的难点不在首版生成，而在持续可信。我们把拓扑维护分成三类机制：
事件驱动更新：业务知识库、代码库或配置发生变更时，先识别受影响节点，再增量重建相关子图。
交叉校验：用运行时Trace、消息消费关系和监控标签反证静态代码分析结果。
置信度管理：每条边记录来源和置信度；来自代码调用、配置绑定、业务知识和运行时链路的证据权重不同。
拓扑中的知识也需要分层：稳定的业务职责和链路关系进入长期知识；高频变化的实例、指标和日志只保留访问方式，不把瞬时数据固化进图。这样既能保持全局认知，又避免知识快速腐化。
3.1.4 拓扑质量决定闭环上限
如果拓扑缺边，Agent可能提前终止穿透；如果节点职责错误，问题发现会把异常归到错误模块；如果取证入口过期，根因分析会拿不到有效证据。因此，拓扑质量需要单独度量：
表2 系统拓扑图的质量指标说明
3.2 根因分析Agent：统一承接异常信号，基于拓扑图的自主推理与根因定位
根因分析 Agent 面向复杂业务系统中的异常定位问题，目标不是简单匹配告警或执行固定 SOP，而是围绕异常信号自主规划排查路径，结合系统拓扑、观测数据、代码、配置和变更记录，逐步将问题从业务现象收敛到异常服务、具体代码文件和代码位置。
如图5所示整体流程包括五个核心环节：统一入口、主 Agent 规划归因、子 Agent 单点取证、根因报告输出、经验异步回写。
图5 根因分析 Agent 基于拓扑图的自主推理架构
3.2.1 统一入口：人发起 Query，Agent 也能发起 Query
根因分析 Agent不依赖单一告警格式，而是接受多种异常信号：监控截图、错误日志、具体商品Case、数据质量异常、调用链片段和发布变更等。它有两类入口：
研发主动发起：研发在 Oncall或日常排查中提交问题和已有线索，Agent 自动补齐关联证据并给出根因。
问题发现 Agent 发起：问题发现 Agent监控到异常波动或新错误簇后，携带时间窗口、样本和异常摘要自动提问。
3.2.2 主/子Agent分离：规划和取证解耦
复杂链路中，如果把告警、日志、代码、配置和变更记录全部交给一个 Agent处理，容易导致上下文膨胀、局部取证污染全局判断、多服务串行分析效率低等问题。因此系统采用主/子 Agent 分离：
主 Agent 负责规划和归因：解析异常信号，读取系统拓扑，识别首跳节点，规划多跳排查路径，维护已排除清单，并对最终根因负责。
子 Agent 负责单点取证：每个子 Agent 只分析一个服务或局部节点，消费日志、监控、Trace、代码、配置和变更记录，并输出局部发现。
主/子之间通过结构化数据交互：主 Agent 下发任务包，子 Agent 回传证据包，避免原始大文本进入全局上下文。
3.2.3 自主规划、多跳级联与代码级定位如何执行
根因分析 Agent 以系统拓扑图作为排查地图，不依赖固定 SOP 逐项检查，而是围绕异常入口自主规划路径。完整分析分为两个阶段：
阶段一：广度扫描，先缩圈。主 Agent根据用户现象、数据标识和拓扑，识别入口节点及上下游候选服务；并行派发2～3 个子任务，快速检查告警、监控和错误日志，排除明显无关节点。
阶段二：定向深挖，再穿透。对高嫌疑节点继续分析日志、监控、代码路径、配置、发布变更、消息、数据库、缓存和外部依赖，沿调用链持续向下游穿透，避免把中间报错服务误判为根因。
相比 SOP，“自主推理 + 拓扑驱动”的关键价值是：它不是预先假设问题一定落在某个检查项里，而是根据证据不断调整搜索空间，直到找到更接近根因的位置。
3.2.4 用强约束控制幻觉
根因分析最危险的不是“没有答案”，而是“给出一个听起来合理但无法验证的答案”。因此我们设置四条硬约束：
服务名必须有来源：只能来自系统拓扑、工具返回或用户输入，禁止凭经验编造；
时间窗必须可追溯：只能来自问题发生时间、告警时间或数据更新时间，禁止随意扩大；
调用链必须穿透：原则上追到数据库、缓存、消息系统、第三方或明确的业务输入异常，中间服务不能作为唯一根因；
关键判断至少双证据：例如错误日志与监控异常互证，代码路径与配置变更互证；单一信号只能标记为“待验证”。
最终报告先回答“根因是什么、影响是什么、建议怎么做”，再展开证据链、排除项和置信度。结构化输出比长篇推理更有利于复核和后续自动治理。
3.2.5 根因报告与经验沉淀
最终报告先回答三个问题：
根因是什么：异常服务、根因类型、代码位置或配置项；
影响是什么：影响范围、异常时间窗、受影响业务或数据；
建议怎么做：修复建议、验证方式、回滚或止损动作。
报告中的有效排查路径和关键证据会先形成候选经验。候选经验不会立即进入权威经验库，而是经过旁路 Agent 复现和人工确认后再沉淀复用，避免错误结论被后续分析反复引用。
通过这种闭环，根因分析 Agent 不只是完成一次排障，而是把高价值排查过程沉淀为可复用经验。随着经验积累，后续类似问题可以更快缩圈、更快选择排查路径，逐步降低对资深研发个人经验的依赖。
3.3 问题发现Agent：从被动告警走向主动识别潜在风险
3.3.1 问题发现不等于增加告警
传统告警依赖人工预先设定阈值，擅长发现已知故障，却很难覆盖缓慢劣化、数据分布漂移和从未出现过的新模式。告警越多，也越容易产生噪声和疲劳。
问题发现 Agent的目标不是“报得更多”，而是周期性监控可疑信号，把多源弱信号组合成少量值得求证的问题。整体流程如图6所示，其中输入部分重点包括：
监控指标异常波动：错误率、耗时、吞吐、积压、成功率等偏离正常基线。
错误日志：新增错误簇、异常放大、跨服务重复错误和关键链路报错。
数据质量与具体 Case：字段缺失率、关联成功率、质检准确率、上下游一致率、数据量级分布变化，以及业务反馈的处理失败Case。
变更事件：代码发布、配置修改、依赖升级和流量变化。
发现 Agent不直接下根因结论，而是把异常摘要、时间窗口、样本和影响范围组装成Query，交给根因分析 Agent求证。确认结果随后分流：外部数据源问题转人工与源头沟通；代码 Bug进入自主修复链路；暂时证据不足的问题继续观察或补充取证。
图6 异常信号经主动发现和根因求证后进入分类处置
3.3.2 动态阈值与日志聚类如何协同
传统的固定阈值适合有明确安全线的指标；对流量存在周期变化的系统，我们使用Z-Score等动态阈值，根据历史均值和波动识别异常点。同时实践中不能机械地把所有偏离都当问题，还要结合拓扑和业务上下文二次判断：
异常是否发生在关键节点？
上下游是否出现同向波动？
是否与发布、配置变更或业务活动重合？
异常是否持续，影响范围是否扩大？
错误日志侧则按指纹进行聚类，并对已确认问题进行去重，降低重复噪声；对周期内新增或显著放大的错误簇，自动抽取样本并向根因分析Agent 发起 Query。这样，问题发现 Agent输出的不是一堆日志，更不会直接猜测根因，而是带有时间窗、服务、影响面、趋势和样本的可验证问题。
3.3.3 用拓扑判断级联异常，而不是重复报障
如果多个下游服务同时异常，逐服务报警会制造多个工单。基于拓扑，可以寻找它们共同的上游依赖，把多个症状聚合为一个根问题；反过来，如果某上游异常但关键下游尚未受影响，也可以结合传播路径提前预警。
问题优先级不只看异常幅度，还综合考虑：节点关键度、受影响下游数量、持续时间、历史复发次数、是否存在可用降级路径。这样可以把有限治理资源优先投向“影响大且正在扩散”的问题。
3.4 自主修复Agent：从根因定位走向可控修复
3.4.1 核心原则：执行、把关、决策三者分离
让 AI 参与线上代码修复，难点不在代码生成能力，而在合入的可信度。模型具备理解与生成能力，但缺乏两类关键能力：一是对自身行为的约束能力（可能跳过必要环节、在未经授权时改动关键分支），二是对工作成果的验证能力（可能声称完成而实际未经验证）。
为此，系统确立单一设计原则：AI 执行，程序把关，人工决策。模型仅负责问题理解与代码生成；“流程走向、结果判定、合入权限”三项控制权由确定性程序与人工持有，不授予模型。
3.4.2 工程结构：状态机驱动的流水线
如图7所示，一次修复被建模为声明式状态机驱动的工程流水线，由四部分构成：
状态机：定义合法路径、回退预算与终态，与执行内核解耦；
编排器：依据状态机，以独立上下文异步调起各步骤的 Agent，步骤间不共享长对话，从而避免上下文污染，并支持恢复与审计；
产物契约：步骤间以落盘的结构化产物作为唯一交付物，而非依赖模型的文本自述；
裁决闭环：编排器读取产物并独立校验后，依据状态机裁决下一走向——继续、重试或转人工。
这一结构是后续约束得以成立的前提：模型的任何推进意图，须经编排器依据状态机裁定后方可生效，模型自身不具备路由权。
图7 状态机约束下的可控修复流程
3.4.3 确定性约束：防跳步、防幻觉、防越权
针对模型的两类失效——擅自行动与自认未验，系统以确定性约束从机制上收回对应控制权：
路径权（约束跳步）。流程走向由状态机裁定，禁止路径在任何条件下不可达，从根本上排除绕开评审、直接发布的可能；重试与回退受次数与时限预算约束，预算耗尽即收敛至成功、降级或转人工，不存在悬空状态。
裁判权（约束幻觉）。模型不为自身成果作判定。产物由程序独立核验：结果字段严格校验，代码片段须确属目标文件，补丁须可通过应用检查；执行状态与业务结果解耦，以区分“步骤异常终止”与“正常完成但业务未通过”。系统只采信落盘证据，不采信模型自述。
执行与终局权（约束越权）。发布红线由确定性规则固守：禁止自动合入、禁止推送至受保护分支、禁止不受控的全量暂存、禁止越界修改；是否合入及发布时机，终局由研发人员裁定。
3.4.4 正确性保证：结构、验证与兜底
所谓“AI 写对了”，并非模型单点的正确，而是系统三层保证的叠加结果：
结构层：流水线、独立上下文与产物契约，使每次改动均证据驱动、最小必要、边界清晰；
验证层：构建与测试真实执行、结果可解析，以证明改动确实成立；
兜底层：受控重试、降级、转人工与失败终态，保证异常可控、可恢复。
三层叠加，使每次修改均处于可审查、可回退、可人工接管的边界内。失败同样进入闭环，沉淀为评测集与规则库，持续压低同类问题复发率。自主治理的目标并非以机器替代人工修改代码，而是持续降低同类问题的发生概率——可靠性来自流程，而非模型本身。
3.5 Self-Improving：Agent的持续学习和自我进化
Self-Improving不是独立于业务闭环之外的“复盘模块”，而是贯穿发现、分析和修复全过程的持续学习机制。
每次排查结论都会反哺业务知识库：正确结论沉淀为可复用经验，错误或被驳回的结论记录失败原因，证据不足的案例补充取证规则。知识库变化又会触发系统拓扑更新，从而形成“结论沉淀—知识增强—拓扑更新—下一次推理更准确”的认知闭环。
在一次问题排查中，Agent 不只产出“根因是什么”，还会识别哪些判断被验证、哪些路径被排除、哪些操作失败、用户进行了哪些纠正，以及现有知识是否已经过时。这些学习事件经过结构化处理后，形成可跨会话复用的经验知识。
图8 Self-Improving 持续学习闭环
3.5.1 核心原则：持续进化，且不让错误规模化
持续学习的难点，不是让 Agent 记住更多内容，而是判断什么值得记、以什么优先级使用，以及在什么情况下应当修正或遗忘。如果把每次失败、每段对话和每个局部结论都不加区分地写入经验库，偶发故障、错误归因和过时知识就可能在后续任务中被反复召回，使一次局部偏差逐渐演变为系统性偏差。
因此，我们不把经验视为可以直接执行的“标准答案”，而是将其作为需要持续验证和治理的候选决策资产。经验从产生到复用，必须经过筛选、结构化、校验和边界约束；在使用时，则始终以当前证据为基础，并遵循明确的优先级关系。围绕这一目标，Self-Improving 机制遵循以下四项原则：
这四项原则共同构成经验从“产生”到“使用”的安全防线：失败触发学习，SOP 约束行为边界，持久性筛选控制知识噪声，可追溯与可回滚机制控制传播风险。Self-Improving 追求的不是无约束的自我修改，而是在可靠性边界内持续获得增量改进，让正确经验被稳定复用，让错误经验能够及时被识别和清除。
3.5.2 学什么：从结果扩展到完整推理轨迹
表3 Self-Improving 学习事件分类及复用价值
一条可复用经验至少需要回答六个问题：在什么范围内、什么现象下、依据哪些证据、采取什么动作、得到什么结果、何时不适用。只有具备明确边界和验证结果的内容，才能从“过程日志”转化为“决策知识”。
3.5.3 如何运行：在线复用与离线治理协同
图9 Self-Improving 在线复用与离线治理架构
任务前：按场景加载最相关经验
Agent 接到问题后，首先依据系统、业务域、节点、异常类型和任务阶段进行 Scope 过滤，再结合多路召回寻找候选经验，最后按照相关性、历史有效性、时效性和风险等级进行价值排序，仅选择 Top-K 条经验注入当前上下文。
经验以“建议和约束”而非“既定答案”的形式参与推理。例如：“出现库存回写延迟时，先核对消息积压与幂等记录；若消费位点连续推进，则不要优先判断为消费者停滞。”这种表达既提供有效先验，也要求 Agent 回到当前证据进行验证，避免历史结论被生搬硬套。
任务中：沿主链路取证，不额外制造负担
Agent 仍按照既有 ReAct 流程完成任务规划、工具调用、证据收集和根因归纳。Self-Improving 只在关键节点提供历史提醒，并记录经验是否被采用、是否帮助缩短路径、是否与当前事实冲突。失败事件不会立即写入长期知识库，而是先进入候选区等待校验。
任务后：把处置过程转化为学习事件
任务总结阶段会从完整轨迹中提取用户纠正、失败步骤、有效取证、排除路径、最终根因与处置结果，并通过规则审核、语义审核和必要的人工审核，过滤敏感信息、偶发故障、事实不完整以及不可泛化的内容。通过审核的候选经验被去上下文化，形成统一结构：适用范围 + 触发条件 + 关键证据 + 建议动作 + 预期结果 + 反例/终止条件 + 来源与版本。
离线阶段：持续治理经验质量
异步引擎负责计算经验价值，识别重复、冲突和过期内容，并执行合并、降权、淘汰或归档。被频繁命中且持续验证有效的经验，可逐步从“案例”晋升为“规则”；经过更严格审核后，再固化为标准 SOP。长期未命中、效果下降或与新架构冲突的经验则自动降权，防止历史包袱干扰当前判断。
3.5.4 关键机制：保证“记得住、找得到、用得对”
结构化经验模型：每条经验携带 Scope、触发特征、证据、动作、结果、置信度、来源、版本、更新时间和状态。
混合召回与价值排序：多层级、多路召回同时覆盖错误码、节点名等精确匹配和语义表达差异；再综合有效性、时效性与风险进行排序。
冲突与过期治理：经验与 SOP 冲突时以 SOP 为准；经验互相矛盾时保留各自适用条件并触发审核；架构变化时相关经验进入待验证或失效状态。
受控知识晋升：经验库承载“有用但仍需验证”的知识，知识库沉淀稳定事实，SOP 承载必须遵循的标准流程。
04
复杂系统不会因为引入大模型就自动变简单。Agent如果看不到服务之间的关系，仍然只能在局部信息里猜答案；如果没有证据约束和安全闸门，越强的行动能力反而可能带来越大的风险。
系统拓扑图提供可计算的全局坐标，问题发现 Agent提供周期性主动感知，根因分析 Agent 统一承接研发和 Agent 发起的 Query并完成证据收敛，自主修复 Agent 只对已确认的代码 Bug 生成方案和 MR，人工Review 守住发布边界，Self-Improving则让每一次处置都增强知识库和下一次推理能力。它们组合起来，才构成真正有技术价值的闭环。
我们真正要建设的，不是一个只能解释“为什么”的问答机器人，而是一套具备系统免疫力的治理机制：主动发现潜在问题，沿全链路定位根因，在安全边界内推动修复，并将每次处置沉淀为下一轮能力，让问题发现得更早、定位得更快、处置得更稳。
-End-