斯坦福CS146S：AI辅助、多智能体、AI原生，一次说清楚三者关系

斯坦福CS146S：AI辅助、多智能体、AI原生，一次说清楚三者关系 斯坦福CS146S：AI辅助、多智能体、AI原生，一次说清楚三者关系 Modified March 16 故障时刻判定与风险变更排序 故障诊断触发次数趋势 小红书设计了一套智能根因定位系统，通过生成调用拓扑、数据采集、异常检测、异常拓扑提取和根因分析等步骤实现快速定位。该系统已应用于所有业务线，覆盖近百个核心场景，平均每天触发1000多次诊断，Trace链路场景的故障定位准确率达到80%以上。 这一数字从最初的40%+提升到近期的80%+，历时一年多，经过每双月对上百个故障案例的持续复盘迭代。 从40%到80%，意味着什么？原本10个故障里有6个要靠工程师人工拉网式排查，现在只有2个需要。剩下8个由系统给出方向性结论，工程师核实并执行。 华为云GaussDB Doer （来源：华为开发者大会2025官方发布，华为云官网） 华为云基于盘古大模型，利用全球上万个GaussDB运维案例的百亿Tokens数据微调，构建专业运维基模型；面向不同故障构建专业智能体，调用对应的50+处置工具，实现Agentic AIOps。 50个工具调用，对应的是50种不同类型的数据库故障场景。每个专业智能体只干一件事，但组合起来覆盖了原本需要高级DBA（ 数据库管理员 ）介入的大部分场景。 Klarna （来源：Klarna官方新闻稿，2024年2月27日；OpenAI官方案例） Klarna的AI客服助手上线第一个月，共处理了230万次对话，承担了三分之二的客服聊天，相当于700名全职员工的处理量；客户满结问题的时间从平均11分钟压缩到不足2分钟，重复咨询减少25%；预计为Klarna带来2024年全年4000万美元的利润改善。 但这个案例有一个不该被忽略的后续。到2025年，Klarna CEO塞巴斯蒂安·西米亚科夫斯基公开承认，当初以成本为主要评估标准导致了"服务质量下降"。公司随后开始重新招募人工客服，并将部分业务收回内部。 4000万美元利润改善写进了新闻稿。服务质量下降的代价，由客户承担。 Coinbase （来源：Resolve AI官方案例，Coinbase工程团队公开资料） Coinbase是全球最大加密货币交易平台之一，服务超过1.2亿用户，管理逾5000亿美元资产，每季度处理近3000亿美元交易量。几分钟的延迟足以导致大量交易错过价格窗口。 部署多智能体AI SRE系统后，事故调查时间缩短72%，关键事故从告警到确定根因压缩到10分钟以内。超过100名工程师每周使用系统超过250次——不只是故障时用，日常检查SLO（ 服务级别目标，衡量系统是否达标的指标 ）、部署历史、流量异常，全部经过AI系统。 第三层：AI原生——人退到目标层，AI接管执行层 这不只是效率问题，是 注意力分配结构的根本重组 。 工程师不再操作工具，而是说一句"帮我查清楚这次支付失败"，AI系统自主规划调查路径、协调多个智能体、给出结论或直接处理。 华为云"1 5 10"目标体系 （来源： 华为云官方社区博客、华为云技术峰会公开发言 ） 华为云提出了"1分钟发现故障、5分钟定界、10分钟恢复"的目标，构建了智能故障定界能力。通过将数千个主机节点的升级时间从原来的数十天缩短到5个小时以内，大幅提升了云平台演进效率。 这是中国企业在AI原生方向上目前可验证的、最接近实战的目标体系。注意"目标"这个词——说明这是方向，不是已经稳定落地的标准。 DoorDash （来源：AWS官方案例研究，2024 2025年） DoorDash利用Amazon Bedrock和Anthropic Claude构建了语音支持智能体，每天处理数十万次配送员客服电话，对话延迟控制在约2.5秒以内，每天减少数千次向人工客服的转接。 这里的关键词是"每天处理数十万次"。如果是AI辅助，这数十万次都需要人工接听；如果是多智能体，AI处理大部分、人处理复杂情况；如果是AI原生，人退到了流程设计层，不再参与具体对话。DoorDash的模式已经接近第三层。 AI原生是AI辅助、多agent协作的未来形态 维度 AI辅助 多智能体协作 AI原生 谁是主角 人，全程操作 人定方向，AI处理子任务 AI主导，人设目标 认知负担 不变 关联分析转移给AI 转移到目标设定和异常监控 中国案例 美团Horae告警收敛 小红书根因定位、华为GaussDB Doer 华为云"1分钟发现/5分钟定界"目标体系 海外案例 GitHub Copilot代码生成 Coinbase调查时间降72%、Klarna客服 DoorDash每日数十万次自主客服处理 核心风险 故障量增长撑破人力 协调机制失败可放大错误 错误在无人介入时自动扩大 谁承担损失 工程师个人 工程师+系统共担 系统主导，责任归属模糊 AI原生出问题以后，人类能不能快速发现？ 2024年2月，Klarna（瑞典金融科技公司，类似"先买后付"版的支付宝）高调宣布：AI客服上线一个月，处理了230万次对话，相当于700名员工的工作量，预计全年省出4000万美元利润。 问题是，减少700个客服，意味着复杂问题、情绪化投诉、非标准流程，全部压到了AI身上。AI处理不了的，用户要么等更久，要么得不到满意的答复。 这个代价不会出现在发布会PPT里，而是分散在每一个没被好好服务的用户身上。Klarna的财报好看了，用户体验的成本由用户自己吸收。 到2025年，Klarna CEO西米亚科夫斯基公开承认，当初以成本削减为主要目标，导致服务质量下滑，公司随后开始重新招募人工客服。 AI原生系统的收益，建立在"系统判断正确"的假设上。但没有任何系统能保证100%正确。 问题不在于AI会不会出错——出错是必然的。问题在于： 出错之后，损失扩大的速度，是否快过人类发现问题的速度？ 这个问题，比"AI能不能替代工程师"更值得认真对待。 END 故障时刻判定与风险变更排序 故障诊断触发次数趋势 小红书设计了一套智能根因定位系统，通过生成调用拓扑、数据采集、异常检测、异常拓扑提取和根因分析等步骤实现快速定位。该系统已应用于所有业务线，覆盖近百个核心场景，平均每天触发1000多次诊断，Trace链路场景的故障定位准确率达到80%以上。 这一数字从最初的40%+提升到近期的80%+，历时一年多，经过每双月对上百个故障案例的持续复盘迭代。 从40%到80%，意味着什么？原本10个故障里有6个要靠工程师人工拉网式排查，现在只有2个需要。剩下8个由系统给出方向性结论，工程师核实并执行。 华为云GaussDB Doer （来源：华为开发者大会2025官方发布，华为云官网） 华为云基于盘古大模型，利用全球上万个GaussDB运维案例的百亿Tokens数据微调，构建专业运维基模型；面向不同故障构建专业智能体，调用对应的50+处置工具，实现Agentic AIOps。 50个工具调用，对应的是50种不同类型的数据库故障场景。每个专业智能体只干一件事，但组合起来覆盖了原本需要高级DBA（ 数据库管理员 ）介入的大部分场景。 Klarna （来源：Klarna官方新闻稿，2024年2月27日；OpenAI官方案例） Klarna的AI客服助手上线第一个月，共处理了230万次对话，承担了三分之二的客服聊天，相当于700名全职员工的处理量；客户满结问题的时间从平均11分钟压缩到不足2分钟，重复咨询减少25%；预计为Klarna带来2024年全年4000万美元的利润改善。 但这个案例有一个不该被忽略的后续。到2025年，Klarna CEO塞巴斯蒂安·西米亚科夫斯基公开承认，当初以成本为主要评估标准导致了"服务质量下降"。公司随后开始重新招募人工客服，并将部分业务收回内部。 4000万美元利润改善写进了新闻稿。服务质量下降的代价，由客户承担。 Coinbase （来源：Resolve AI官方案例，Coinbase工程团队公开资料） Coinbase是全球最大加密货币交易平台之一，服务超过1.2亿用户，管理逾5000亿美元资产，每季度处理近3000亿美元交易量。几分钟的延迟足以导致大量交易错过价格窗口。 部署多智能体AI SRE系统后，事故调查时间缩短72%，关键事故从告警到确定根因压缩到10分钟以内。超过100名工程师每周使用系统超过250次——不只是故障时用，日常检查SLO（ 服务级别目标，衡量系统是否达标的指标 ）、部署历史、流量异常，全部经过AI系统。 第三层：AI原生——人退到目标层，AI接管执行层 这不只是效率问题，是 注意力分配结构的根本重组 。 工程师不再操作工具，而是说一句"帮我查清楚这次支付失败"，AI系统自主规划调查路径、协调多个智能体、给出结论或直接处理。 华为云"1 5 10"目标体系 （来源： 华为云官方社区博客、华为云技术峰会公开发言 ） 华为云提出了"1分钟发现故障、5分钟定界、10分钟恢复"的目标，构建了智能故障定界能力。通过将数千个主机节点的升级时间从原来的数十天缩短到5个小时以内，大幅提升了云平台演进效率。 这是中国企业在AI原生方向上目前可验证的、最接近实战的目标体系。注意"目标"这个词——说明这是方向，不是已经稳定落地的标准。 DoorDash （来源：AWS官方案例研究，2024 2025年） DoorDash利用Amazon Bedrock和Anthropic Claude构建了语音支持智能体，每天处理数十万次配送员客服电话，对话延迟控制在约2.5秒以内，每天减少数千次向人工客服的转接。 这里的关键词是"每天处理数十万次"。如果是AI辅助，这数十万次都需要人工接听；如果是多智能体，AI处理大部分、人处理复杂情况；如果是AI原生，人退到了流程设计层，不再参与具体对话。DoorDash的模式已经接近第三层。 AI原生是AI辅助、多agent协作的未来形态 维度 AI辅助 多智能体协作 AI原生 谁是主角 人，全程操作 人定方向，AI处理子任务 AI主导，人设目标 认知负担 不变 关联分析转移给AI 转移到目标设定和异常监控 中国案例 美团Horae告警收敛 小红书根因定位、华为GaussDB Doer 华为云"1分钟发现/5分钟定界"目标体系 海外案例 GitHub Copilot代码生成 Coinbase调查时间降72%、Klarna客服 DoorDash每日数十万次自主客服处理 核心风险 故障量增长撑破人力 协调机制失败可放大错误 错误在无人介入时自动扩大 谁承担损失 工程师个人 工程师+系统共担 系统主导，责任归属模糊 维度 维度 AI辅助 AI辅助 多智能体协作 多智能体协作 AI原生 AI原生 谁是主角 谁是主角 人，全程操作 人，全程操作 人定方向，AI处理子任务 人定方向，AI处理子任务 AI主导，人设目标 AI主导，人设目标 认知负担 认知负担 不变 不变 关联分析转移给AI 关联分析转移给AI 转移到目标设定和异常监控 转移到目标设定和异常监控 中国案例 中国案例 美团Horae告警收敛 美团Horae告警收敛 小红书根因定位、华为GaussDB Doer 小红书根因定位、华为GaussDB Doer 华为云"1分钟发现/5分钟定界"目标体系 华为云"1分钟发现/5分钟定界"目标体系 海外案例 海外案例 GitHub Copilot代码生成 GitHub Copilot代码生成 Coinbase调查时间降72%、Klarna客服 Coinbase调查时间降72%、Klarna客服 DoorDash每日数十万次自主客服处理 DoorDash每日数十万次自主客服处理 核心风险 核心风险 故障量增长撑破人力 故障量增长撑破人力 协调机制失败可放大错误 协调机制失败可放大错误 错误在无人介入时自动扩大 错误在无人介入时自动扩大 谁承担损失 谁承担损失 工程师个人 工程师个人 工程师+系统共担 工程师+系统共担 系统主导，责任归属模糊 系统主导，责任归属模糊 AI原生出问题以后，人类能不能快速发现？ 2024年2月，Klarna（瑞典金融科技公司，类似"先买后付"版的支付宝）高调宣布：AI客服上线一个月，处理了230万次对话，相当于700名员工的工作量，预计全年省出4000万美元利润。 问题是，减少700个客服，意味着复杂问题、情绪化投诉、非标准流程，全部压到了AI身上。AI处理不了的，用户要么等更久，要么得不到满意的答复。 这个代价不会出现在发布会PPT里，而是分散在每一个没被好好服务的用户身上。Klarna的财报好看了，用户体验的成本由用户自己吸收。 到2025年，Klarna CEO西米亚科夫斯基公开承认，当初以成本削减为主要目标，导致服务质量下滑，公司随后开始重新招募人工客服。 AI原生系统的收益，建立在"系统判断正确"的假设上。但没有任何系统能保证100%正确。 问题不在于AI会不会出错——出错是必然的。问题在于： 出错之后，损失扩大的速度，是否快过人类发现问题的速度？ 这个问题，比"AI能不能替代工程师"更值得认真对待。 END 🔗 原文链接： https://mp.weixin.qq.com/s/j2lM2Ral... https://mp.weixin.qq.com/s/j2lM2Ral... 原创 Mango Mango 烂芒2026年3月16日 08:35 上海 阅读前必看——核心词解释： SRE（Site Reliability Engineer，站点可靠性工程师） ：专门负责保障线上系统稳定运行的工程师，出了故障第一个被呼机叫醒的那类人。 AIOps（AI + IT Operations）：用人工智能处理监控告警、定位故障根因的技术方向。简单说，就是让AI替代人工盯着系统跑。 AIOps能力及应用场景 AIOps应用场景演进策 略 AIOps关联团队关系图 MTTR（Mean Time To Resolve，平均修复时间） ：从发现故障到修复完毕的平均耗时，越短越好。 根因分析（RCA，Root Cause Analysis） ：不只找"哪里坏了"，而是找"为什么坏"——是代码问题、数据库问题，还是上游服务拖垮了下游？ 近些年根因分析相关研究 行业内各公司在根因分析上的实践和分享 告警疲劳 ：系统每天产生几万条告警，大部分是噪音，真正的故障信号被淹没，工程师久而久之开始麻木。 Trace链路（调用链路） ：一次用户请求经过多个服务的完整路径记录，出了故障用来追溯"哪一段出了问题"。 一条结构线，先说清楚三者关系 这三者不是同一条升级路线上的三个站。它们是三种不同的 系统架构 ，决定了不同的风险分布和利益格局。 第一层：AI辅助——工作流不变，人还是瓶颈 AI加速每一个单步动作，但工作流骨架原封不动。工程师出了故障还是要自己跳转监控平台、日志系统、部署记录，手动关联所有信号，最后做出判断。 认知负担，一分没少。 运维领域发展历程 行业产品AIOps能力分析 美团 （Horae系统，来源：美团技术团队官方公开文章） 美团服务运维部从告警管理切入AIOps实践，开发了故障发现系统Horae，核心解决"告警风暴"问题——海量指标涌入时，系统自动过滤噪音、收敛告警，减少无效呼叫。时序数据分类准确率达到95%以上。 这是典型的AI辅助形态：AI嵌入了原有流程的若干节点，但工程师还在操作每一个后续环节。 GitHub Copilot （来源：InfoQ 2024企业级随机对照试验汇总） 2024年针对约4800名开发者的随机对照试验显示，Copilot用户每周合并请求数量增加约26%，经验较少的开发者收益更大。但另一项针对约800名开发者的观察性研究显示，PR合并量无明显提升，且Copilot用户的PR中bug密度上升了41%。 这个结论值得停下来想：如果AI加速了代码生成，而bug密度同步上升，那么谁来处理这些bug引发的生产故障？还是那些工程师。AI辅助在编码端的收益，可能正在运维端产生新的成本。 第二层：多智能体协作——拆开任务，专业智能体并行处理 这里需要先解释一个结构性问题： 为什么一个AI处理不了所有事？ 处理一次线上故障，需要同时分析数据库连接池（ 数据库处理请求的资源池，资源耗尽就像收费站只剩一个窗口 ）状态、上游服务响应时间、最近的代码部署记录、安全日志异常。这四件事要求截然不同的推理策略。 单个AI顺序处理：查完日志再查指标，再查部署记录。更危险的是，第一步方向判断错了，后面全部跟着走偏，没有其他路径纠偏。 多智能体的核心不是"更多AI"，而是 并行假设测试 ：多个专业智能体同时从不同方向逼近根因，互不等待，互相校验。 小红书AIOps （来源：小红书技术官方公众号REDtech，2024年10月） 小红书 AIOps 现状 故障定位整体方案 图4.3 核心场景调用拓扑生成 表4.3 节点和边采集指标信息表 不同指标异常检测方法 表4.5 节点状态定义和判定条件 异常拓扑提取过程