作为 Lazada 广告引擎团队，系统稳定性是重中之重。在日常运维当中，研发同学经常处理来自黄金眼、Kmonitor 等多个平台的报警，这些报警覆盖了从 SS、SP 到 Smax 等多条业务链路。
业务背景的特殊性：
首先，系统稳定性直接关系到广告收入。广告引擎是 Lazada 的核心营收系统，故障可能导致广告无法正常投放，进而造成资损。线上报警必须得到及时响应和处理，否则资损会随着时间推移而不可控地扩大。
其次，业务复杂度急剧上升。FY25 上线了全站推 Smax 业务，原有的广告系统从一条业务线（SS/SP）扩展到三条业务线（SS/SP + Smax 一期 + Smax 二期）。系统架构变得更加复杂，监控点位成倍增加，但团队人力却相对有限。报警数量不仅多，而且来源更加分散和复杂，急需更自动化、智能化的运维解决方案。
再次，新业务的特殊挑战。全站推 Smax 业务仍处于快速发展期，收入和曝光等重要指标因为基数小，经常出现较大波动。如何在这种高波动性的环境下精准判定真实报警，避免误报和漏报，是一个值得深入思考的命题。
面临的核心问题：
第一，报警太多，真假难辨。日常报警中大部分是由于流量波动、大促活动、客户预算调整等正常业务变化引起的。这些"假报警"占据了大量的人力，真正的问题反而容易被淹没。研发同学疲于应对，逐渐产生"报警疲劳"，对报警的敏感度下降。
第二，排查路径长，依赖个人排查经验。当收到报警时，研发同学需要跨多个平台（黄金眼、Kmonitor、TPP、SUEZ 等）确认指标趋势、检查系统模块、排查代码发布和实验变更、分析异常关联性。虽然已有诊断文档沉淀，但实战熟练度的培养仍需要较长的时间周期和大量的案例积累。
第三，业务扩展快，诊断能力跟不上。从最初的 Lazada SS/SP 扩展至 Miravia、Daraz、Smax 等多个业务域，虽然监控体系和诊断逻辑相似，但各业务域的数据特性差异显著。成熟业务数据基数大、适合实时报警，新兴业务数据基数小、波动剧烈、更适合小时级累计诊断。诊断策略需要针对不同业务的时效性、周期性、覆盖度进行差异化适配，能力建设难以匹配业务扩张速度。
二、目标
针对上述挑战，我们为智能诊断系统设定了以下核心目标：
三、解决方案
围绕上述目标，我们从噪音识别、链路诊断、关键技术三个层面构建了 Multi-Agent 智能诊断系统，以下逐一介绍各模块的设计思路与实现细节。
3.1 整体设计思路
我们的核心思路是：用 AI 模拟人工排查的思维过程，并将专家经验固化为可复用的知识。具体来说，我们构建了一个分层架构的 Multi-Agent 智能诊断系统：
系统架构
问题识别层
噪音识别 Agent：作为系统的第一道防线，判断报警是否是重复报警、误报或正常业务波动，过滤无效报警，减少后续诊断压力。
Agent 诊断层 根据报警信息，识别出当前报警属于哪个领域内报警，再由领域内子Agent 进行深度诊断：
·SD 链路 Agent：专门处理 Lazada SS/SP 的 SD（Sponsored Discovery）链路报警，基于收入公式进行层层下钻分析。
·Smax 链路 Agent：处理 Smax 一期和二期的报警，需要判断推荐侧还是广告侧异常。
·Error QPS Agent：专门分析 URP 的 Error QPS 异常，快速定位代码问题和系统压力。
基础能力层
知识库：存储诊断 SOP、业务规则、历史案例等结构化知识，支持 RAG 检索。
MCP 工具集：封装黄金眼、Kmonitor、TPP、SUEZ 等平台的数据查询能力，提供MCP协议标准化工具。
黄金眼工具：对接黄金眼平台API。
通用工具：接入新闻搜索，引入地震、战争等地缘因素信息。
大模型LLM：基于通义千问大模型，提供自然语言理解、推理决策、工具调用等核心能力，支持复杂的诊断逻辑推理和动态决策。
3.2 噪音识别：减少无效报警
在实际运营中，我们发现很多报警是重复的或者是正常的业务波动。为此，我们专门建设了噪音识别能力。
策略一：重复报警识别
实现了报警全链路的记录，将黄金眼原始报警、自动化诊断结论及人工复核数据统一沉淀至 Holo 数据库。同时，构建 MCP 工具，支持其基于国家、产品、时间等多维度灵活检索历史报警库。
自动检索过去 24 小时内同国家、同产品的报警记录。若当前报警的详细信息与诊断结论与某条经人工确认有效的历史记录高度相似，则判定为重复报警，并自动抑制通知发送，避免干扰。
策略二：业务特征
大促后流量回落、广告收入下降属正常现象，我们在语雀文档中持续维护实时大促时间表；若大促结束期间诊断结果显示“广告流量降幅处于合理区间，且推荐/搜索侧流量同比下滑”，则判定为大促回落，经确认后，仅报警一次，后续通过重复报警识别抑制。
业务上一些大型广告计划的停投也会影响广告流量、ppc、收入等指标，如LZD的MSA广告计划，我们提供MCP工具，支持查询近期MSA广告计划的开始及结束时间，“流量小幅度下滑，ppc大幅度下滑导致广告收入大幅下滑”，则可诊断为MSA广告停投，经确认后，仅报警一次，后续通过重复报警识别抑制。
策略三：交叉指标
自动检索过去1小时内同国家-不同产品、不同国家-同产品的报警记录，若诊断结论相同且非预期噪音报警如“大促流量回落，MSA计划停投”等情形，则判定存在跨产品、跨国家共性异常，报警信息将突出提示并强调关联风险，提醒关注系统性问题。
策略四：持续学习机制
每次报警时，人工可确认报警诊断结论错误或正确，并写回至holo。
结合MCP工具检索历史报警信息，联动诊断知识库中的案例文档构建智能Agent，按周频次由人工触发，提取诊断结论错误及知识库未覆盖的报警案例，开展人工清洗与优化，并将有效案例回流至诊断知识库作为参考；如需，可进一步迭代判定规则，建立持续学习机制，提升诊断准确率与覆盖率。
通过以上四个策略的报警噪音识别升级，我们的噪音识别准确率从最初的 60% 提升到了 85%，并有了持续迭代的能力。
3.3 SD 链路诊断：从公式到根因
SD 链路是我们最早建设的诊断能力。核心思路是基于广告收入的计算公式进行层层下钻：
收入 = 流量 × 曝光率(PVR) × 点击率(CTR) × 单次点击价格(PPC)
当收到收入下跌报警时，Agent 会：
第一步：结构化信息提取 从报警文本中提取关键信息：报警时间、国家、业务业务线、报警指标等。这一步用大模型的 NLP 能力就能很好地完成。
第二步：初步定位 按照上述公式，逐个检查流量、曝光率、点击率、PPC 这四个指标，这里我们根据知识库里定义的 MCP 调用规范获取实时数据。
第三步：根因下钻 找到异常指标后，继续调用工具下钻分析根本原因：
第四步：关联分析 检查是否有代码发布、实验变更等事件。我们会查询最近一小时的所有变更记录。
第五步：生成报告 将诊断过程和结论整理成结构化的报告，包括：
3.4 Smax 链路诊断：多时效策略
Smax 链路的特殊性在于其收入指标基数小、波动极大。常规的时间点序列报警极易误报，且报警量巨大。为此，我们针对性地设计了多时效性的监控体系，结合实时、小时级累计和 T+1 三种不同时效的监控，并针对性地优化诊断策略。
诊断策略：
3.5 Error QPS 诊断：快速定位代码问题
URP 的 Error QPS 报警往往意味着严重的线上问题——作为广告引擎的核心模块之一，URP 与 IEF 合计承载了引擎 90% 以上的能力，任何异常都可能直接影响广告投放。同时，URP 部署在 SuezOps 平台上，缺乏自动扩缩容等自愈机制，error QPS 上涨时需要人工快速判断和干预。因此，我们专门建设了 Error QPS Agent，将原本依赖个人经验、需要跨多个平台逐一排查的诊断过程自动化，实现从报警触发到定位根因、给出处理建议的全流程覆盖。
分级诊断策略：先低成本排除，再聚焦核心
我们总结了 Error QPS 上涨的六大原因分类，并设计了分级诊断策略——核心思路是按识别成本从低到高排列，先快速排除简单原因，再聚焦核心问题。
C1 单机问题（占比约 15%）：机器性能问题、OOM、混部干扰等导致少数机器 error QPS 异常偏高。通过 Kmon 监控指标按机器维度对比即可初步判断，不需要采集日志，可以作为优先快速排除的类型。
C2 流量/水位变化（占比约 20%）：突发性的流量增长导致机器压力增大、CPU 水位上升，进而引发 error QPS 上涨。这些流量可能来自旧场景流量的突发性变化、新场景流量的突然接入，或机房故障导致的流量倾斜。通过对比 error QPS 与整体请求 QPS 的趋势，结合 CPU 水位数据可以识别，同样可以作为优先快速排除的类型。
C3 发布导致（占比约 60%）：这是最常见也最复杂的原因，需要关联多平台发布记录和日志内容进行深度分析，是 Agent 的核心诊断重点。排除 C1 和 C2 后，Agent 将主要精力投入此类问题的诊断。
此外，C4（索引/数据层异常）和 C6（请求异常）本质上不是 URP 自身的问题，识别难度高且处理方式不同，当前阶段不做主动识别，建议人工排查。C5（上游依赖异常）同样非 URP 自身问题，但在排查 C3 的过程中如果发现了上游异常信号（如 iGraph 查询超时、RTP 调用失败等），会一并告知，减少人工排查成本。
C1 单机问题 & C2 流量/水位变化：快速排除
C1 单机问题：通过 Kmon API 获取按机器维度的 error QPS 数据，如果 error 集中在少数机器（如某台机器的值远高于平均值 5 倍以上），则判定为单机问题，建议重启或替换。
C2 流量/水位变化：Agent 会对比 error QPS、整体请求 QPS 以及系统 CPU 水位的变化趋势。如果三者在时间上呈现一致的上涨趋势，说明是流量增长导致系统压力过大引发的 error，Agent 会基于扩容公式自动计算扩容建议；如果某个机房 QPS 突增而另一个下降，则判定为机房流量倾斜。
C3 发布导致：核心诊断重点
排除 C1 和 C2 后，Agent 将主要精力投入发布问题的诊断。
首先，Agent 会采集 error 日志并按 error message 进行聚合分析，统计各类错误的出现频次和占比，识别出占比最高的几类错误。然后结合知识库中沉淀的错误日志速查表，将这些高频错误与已知的原因分类进行匹配，初步缩小排查范围。
在此基础上，Agent 会获取多平台的近期发布历史，将发布时间与 error QPS 上涨时间、error 日志内容进行关联匹配。广告引擎涉及多个平台的发布，我们将 C3 细分为多个子类：
由于线上发布通常分批推进，error QPS 变化的时间点可能不止一个，Agent 会识别所有上涨时间点并分别关联。多个发布同时存在时，按关联度排序并标注置信度（高度相关、可能相关、待排除），保留不确定性，让人工做最终判断。
白名单过滤：减少误判
系统中存在一定比例的"正常" ERROR——这些 ERROR 在日常运行中持续存在，属已知正常现象（如部分 biz 在当前集群未部署但仍尝试调用、下游 RPC 超时导致的正常降级等）。
我们按服务阶段维护了白名单正则表达式。Agent 在采集 error 日志后，会先用白名单过滤已知正常 ERROR，聚焦新增的异常 ERROR。如果过滤后 error QPS 未上涨，说明上涨由白名单内日常 ERROR 波动导致，无需进一步诊断。这一机制显著减少了误判。
诊断流程总结
四、技术实现的关键决策与挑战
4.1 从单 LLM 到多 LLM：解决下钻推理的重复问题
在项目初期，我们采用单个 LLM 完成整个诊断流程。但很快发现了一个严重问题：报警诊断具有层层下钻的特性，单 LLM 在第二次下钻时会重复第一次的推理过程。
以收入下跌诊断为例，完整的诊断流程包括：
表层分析：判断是流量、曝光率、点击率还是 PPC 异常
根因下钻：如果是ppc异常，继续分析是索引库问题、基线ppc异常问题还是大促商品集体停投等
单 LLM 模式下，当进行根因下钻时，模型会重新推理一遍表层分析的逻辑，不仅浪费 token，还容易在第二次推理时产生与第一次不一致的结论。
单LLM的重复推理示例：
于是，我们将诊断流程拆分为两阶段，串行两次 LLM 调用：
第一次 LLM（表层诊断）：聚焦于识别表面问题，基于收入公式（收入 = 流量 × 曝光率 × 点击率 × PPC）定位异常指标，输出结构化的中间结果，明确哪个环节出现异常
第二次 LLM（根因下钻）：接收第一次 LLM 的结论作为上下文，针对已确定的异常环节进行深度分析，探究根本原因（如ppc下降是因为索引深度降低还是由于某些计划周期性停投导致）
多LLM的分阶段推理：
4.2 MCP 工具设计：平衡信息完整性与上下文效率
诊断过程需要获取大量数据（黄金眼指标、Kmonitor 数据、日志等），很容易导致上下文溢出。更严重的是，初期设计的接口过于通用，一次返回多个维度的数据，形成严重的上下文干扰，导致推断耗时过长且不准确。
设计原则：
工具不等于 API：简单封装 API 会导致信息冗余。我们的做法是在工具内部进行数据聚合。例如，原始数据是时序数据点，我们的工具会先计算一定时间窗口内的平均值、最大值，Agent 利用这些聚合值进行波动推断，而不是处理原始的海量时序数据。
指标级别的精准查询：虽然 MCP 接口保持通用性，但每次执行时都指定具体指标，只返回当前指标的数据。例如，诊断曝光率问题时，只返回曝光率相关的时序数据和统计信息，而不是一次性返回流量、曝光率、点击率、PPC 等所有维度的数据。这种设计防止了数据过载形成的上下文干扰，显著提升了推理准确性和响应速度。
4.3 知识库组织：支持动态演进的诊断能力
采用 RAG（检索增强生成）方式，每个诊断场景都有独立的 Markdown 文档，包含场景描述、诊断步骤、工具调用、判定标准和真实案例。不同业务域的参数（如黄金眼指标名称、Kmonitor group_name）都配置在文档中，Agent 可以根据报警内容自动选择。
动态更新机制：根据新业务场景、诊断错误案例、人工反馈建议定期更新知识库，确保诊断能力持续演进。
4.4 准确性提升：人机协同的持续优化
初期诊断准确率不高，经常出现误判。我们设计了反馈机制：
五、数据化运营与持续优化
5.1 核心指标体系
我们建立了一套完整的指标体系来评估系统效果：
准确性指标：
效率指标：
覆盖度指标：
5.2 人机协同的 SOP
我们设计了一套标准化的操作流程：
报警触发后：
人工反馈：
数据闭环：所有的诊断记录、人工反馈都会存储到数据库，用于：
六、诊断案例和效果
6.1 诊断案例
6.2 效果数据
覆盖度：目前已经覆盖了 Lazada 的 SS/SP 、Smax主要广告营收业务，支持收入、曝光、PPC 等核心指标的诊断。Miravia、Daraz 的诊断能力正在建设中。
误报率：在FY26年，诊断误报率控制在20%内。
效率提升：诊断时效从人工排查的 10-15 分钟缩短到 1-2 分钟，自动结单率：70%以上。
七、总结和展望
智能诊断系统已在 Lazada 广告引擎团队正式落地，并已稳定运行大半年时间。从最初的规则引擎演进到现在的 Multi-Agent 系统，我们成功构建了一套分层架构的智能诊断体系，覆盖了 SS/SP 和 Smax 等核心广告营收业务。
通过 Agent 自动诊断能力的建设，团队运维成本大幅下降：诊断效率提升 5-10 倍，70% 以上的报警实现自动结单，噪音过滤准确率达 85%，诊断误报率控制在 20% 以内，让研发同学能够聚焦真正的核心问题。
系统最大的价值在于突破了时间限制，实现了非工作时段的及时响应。报警触发后，Agent 能在 1-2 分钟内完成自动诊断并推送钉钉卡片。这不仅保障了系统稳定性，更让研发同学从"7×24 小时待命"的压力中解放出来。
未来我们还将继续在以下方向持续深耕：
覆盖率提升
准确率优化
智能化增强
我们是阿里巴巴国际数字商业集团（AIDC）广告工程与 AI Infra 团队，负责支撑 Lazada、AliExpress、Miravia、Daraz、Gmarket等全球化电商平台的广告核心系统与智能基础设施建设。
团队聚焦广告召回、排序、投放、创意智能化，以及训练推理平台、特征与数据基础设施、模型服务等关键方向，持续提升商业化效率与用户体验。我们紧跟业界前沿技术，积极推动大模型、生成式 AI、Agent 等在国际电商广告场景中的落地应用。
团队紧跟业界前沿，与算法团队紧密协作，在 ICDE等顶级学术会议上有联合论文发表。加入我们，你将参与全球业务场景下从底层 Infra 到上层智能应用的全链路建设，用技术驱动商业增长～
