LLM for AIOps：行业专家深度解析泡沫与银弹之争

在大模型技术风潮席卷运维领域的当下，LLM Agent既被赋予“打破协同壁垒”的厚望，也深陷“过度炒作”的舆论漩涡。AIOps概念诞生已久，传统方案始终难以突破数据与智能的双重瓶颈，而“OS + LLM Agent”新范式的兴起，为行业注入了新的活力。「AI 进化论」第六期直播聚焦“LLM for AIOps，是泡沫还是银弹？”这一核心议题，特邀阿里云智能集团运维总监、龙蜥社区系统运维联盟主席冯富秋，以及云杉网络总裁向阳，从行业痛点、技术破局、未来规划三大维度，深入探讨LLM与OS底座的协同路径。以下为经编辑整理的专家对话实录。

1 行业痛点与争议——“银弹”幻象下的真实困境

Q1：LLM Agent既被视为“银弹”也被质疑为“泡沫”，行业最突出的争议和挑战是什么？

@冯富秋：AI究竟是银弹还是泡沫，本质在于预期与落地之间的偏差。从正向看，大模型的语义理解和文本分析能力卓越，在意图识别上远超传统NLP，能极大提升前线问题归因分析的效率。但反之，其推理及深度分析能力相对不足。我举个不恰当的比喻，当前AI Agent的能力宛如“神棍神医”，操作系统日志类似人的表征，如发烧，缺乏具体指标，仅凭表象就开药方，用户难以辨别对错。这就是业界所称的“幻觉”问题，看似正确，实则可能完全错误，构成主要矛盾。

@向阳：此事无疑是革命性的。AIOps发展多年，以往依赖规则化和数据清洗实现，现在借助大模型机遇，我们在客户处目睹了惊艳效果。例如银行发版，以往需七八个部门及相关运维厂商驻场，如今人数急剧减少，但尚未达到无人值守，类似自动驾驶，特斯拉FSD也未完全剥离驾驶员责任。它存在幻觉和准确率问题，提供柔性答案而非基于规则，只要非规则驱动，就有正确率挑战，需通过Guardrail等机制约束行为，让其随使用逐步成长。总体而言这是一场革命，但我们不能期望它如资深运维工程师般零失误。

Q2：“OS + LLM Agent”新范式，旨在解决传统AIOps的哪些痛点？

@冯富秋：AIOps提出已久但未达预期，原有技术要么是规则引擎，要么是小神经网络。规则引擎对复杂操作系统代码的静态分析都无能为力，关键字匹配效率低下，只能处理预设正向案例；小神经网络需监督训练，但运维领域缺乏高质量大数据，泛化能力不足，准确率甚至不及早期统计学模型。生成式模型的最大优势在于基于内在知识库生成，而非过往数据复现，能在较少人工调教下，产生比传统神经网络更佳效果。大模型的泛化能力，是运维场景的显著特征。

@向阳：以往AIOps痛点主要在数据与智能两方面。数据层面，过去依靠插桩、打日志采集数据，第一步就需痛苦的数据清洗，企业客户常耗时半年以上；智能层面，基于规则的方案难以应对大量Corner case。OS能提供零侵扰视角，洞察机器上所有进程活动，构建完整数据集；大模型则带来真正智能，犹如自动驾驶从规则跨越到FSD模型，突然具备可能性。当前模型泛化能力已足够强，运维领域更强调获取关联性强的实时数据，数据需完整且标签标注统一。

Q3：阿里云推动这一范式落地的核心诉求是什么？与云杉网络如何协同？

@冯富秋：阿里云的核心诉求是让模型切实提升工单处理效率，优化客户体验。我们与云杉网络是龙蜥系统运维联盟核心成员，整个AI落地过程涉及众多操作系统和观测技术。阿里云提供操作系统底座，确保其坚固可靠，还推出操作系统控制台，希望所有操作系统相关问题都能在此解决。在此基础上，我们提供诸多观测操作系统的探针，云杉网络基于这些探针构建上层应用和全链路容器等生态，双方强强联合，共同提升运营效率和用户体验。

@向阳：阿里开放操作系统的可观测性能力，如eBPF技术接口，这是关键基础能力。我们DeepFlow利用eBPF接口实现零侵扰可观测性，若采用日志或APM方式，会涉及繁琐数据清洗，但借助操作系统的eBPF能力，能高效实现零侵扰的结构化数据采集。尤其在金融等关键行业，生产环境中无需修改应用代码、不用重启，就能凭操作系统能力获取丰富数据，这些数据正是LLM Agent的“燃料”，双方相互促进。

Q4：如何保障LLM Agent这座“桥梁”不会成为系统的单点故障或脆弱点？

@冯富秋：这是热门话题，AI创新的同时，运行平台稳定性至关重要。我们从两个层面保障：一是操作系统层面，确保AI Agent运行环境稳定，通过操作系统控制台透出能力，让客户可视问题及解决方案；二是研究AI观测能力，诊断Agent本身是否出现HANG（算子挂死）、死锁、OOM（内存溢出）等问题，确保其稳定可靠、可诊断。此外，我们联合合作伙伴，实现模型快速装载、恢复及问答流路由，从节点和弹性环境两方面共同保障“桥梁”稳固。

@向阳：解决桥梁可靠性需从两方面入手：一是AI基础设施层面，保障GPU卡、显存、RDMA网络等环节及通用算力上分布式调用链的可靠性；二是应用层面，通过评估和反思机制持续提升推理质量，应对幻觉问题。我们与阿里合作的AI基础设施可观测解决方案刚获最佳案例奖，这正是双方合作成果的体现。

2 技术破局——降幻觉、强协同的实践路径

Q5：面对“幻觉”问题，提升可靠性、实现“降幻觉”的核心思路是什么？

@冯富秋：要将模型从“神棍神医”变为真正专家，我们总结三步法。第一步，提供工具支持，如同医院的CT、化验设备，将操作系统和运行环境的深层次问题提炼供模型使用，即AI Agent中的“工具”；第二步，制定结构化执行纲要，类似癌症诊疗指南，阿里巴巴沉淀大量运维工单经验，形成结构化纲要，让模型有章可循，对应AI Agent的Planning；第三步，持续迭代优化，AI答复不准确时，客服团队回收案例，对模型进行监督训练或强化训练，让模型积累经验、不断成长。

@向阳：我们的策略也是三步走。第一步，以基于操作系统的观测数据为主干，解决数据完整性和结构化问题，尤其在金融场景，能应对APM和日志参差不齐的情况；第二步，补齐数据关联关系，如在故障诊断中，将银行交易的不同流水号串联成调用链，类似把稀土冶炼成合金；第三步，基于状态机生成动态思维链，避免Workflow失控，同时在诊断和巡检报告中列出完整证据链，方便金融等严谨行业审计回溯，再通过评估反思机制让智能体持续学习，最终解决幻觉问题。

Q6：将eBPF采集的底层数据与LLM Agent决策逻辑打通，最难的环节是什么？如何平衡数据丰富性与性能损耗？

@冯富秋：核心难点是权衡数据采集的多与少。采集过多，CPU、内存、存储开销巨大，出问题时难分主次指标；采集过少，又无法准确定位问题。这需与大模型结合，以问题和场景为驱动，整合最优采集方案，甚至通过动态开关，在开销可控下达成预期效果。

@向阳：平衡数据丰富性与性能损耗，我们做了两件事。一是给eBPF常规数据打统一标签，标注云资产、容器资产、业务资产，消除数据“方言”差异，如避免APM和日志中对同一服务命名不一致；二是层次化递进获取实时数据，生产环境中长期开启黄金指标、调用链等低开销观测数据，当智能体发现数据不足时，借助eBPF热加载能力，通过Agent动态思维链，在故障现象丢失前快速补充实时数据，实现高效平衡。

Q7：LLM Agent适配企业内网环境时，面临哪些安全合规挑战？如何建立安全护栏？

@冯富秋：客户最关心两个尖锐问题：一是数据安全，担心生产数据泄露，我们推出Confidential AI双向可信方案，数据在完全可信沙箱内运行，阿里云和客户双方都看不到对方数据；二是答复可靠性，担心按AI结论操作失败后的责任归属，我们采取人机协同模式，AI结论先供客服和客户参考，不直接强制执行，通过持续监督训练提升模型可信度，逐步推进落地。

@向阳：生产环境的故障复杂度远高于实验室，首先要拉齐客户预期，让其理解目标非100%完美；其次要提供完整证据链，智能体的专业广度可能超越单人，工程师需通过证据链理解结论由来；合规层面，任何操作都需人在循环中担责，关键操作需人工审批，同时将诊断和恢复效果沉淀为反思数据集，持续优化模型，如同运维老司机积累经验，让智能体越用越强。

3 未来启示——生态共建与范式革新

Q8：未来吸引更多开发者和企业参与“OS + LLM Agent”生态，会侧重哪些方面？

@冯富秋：生态建设聚焦三个维度：一是阿里云聚焦操作系统核心能力，以MCP方式开放，让所有模型都能结合使用，如同提供专业诊疗设备供各方使用；二是依托龙蜥运维联盟构建沟通桥梁，与云杉网络等伙伴发布联合解决方案，堆叠各方能力；三是计划推出脱敏后的运维工单标准测试集，建立行业基准，让所有Agent都能测试，解决运维行业缺乏训练集和测试集的痛点，促进行业良性发展。

@向阳：主要有两个方面：一是通过DeepFlow开源社区降低eBPF技术使用门槛，解决其内核适配、技术门槛高的问题，同时在开源社区开放MCP Server等能力，让开发者能获取生产环境的剖析数据和调用数据；二是作为大模型和操作系统的用户，积极融入阿里这样的大生态，与行业伙伴共同推进技术落地。在分工明确的企业中，Multi-Agent是必然趋势，我们会按场景化实现智能体能力，且不同场景智能体之间会相互交互，形成闭环。

Q9：LLM for AIOps对运维领域有哪些启发？LLM Agent会成为服务器操作系统的“标配”吗？

@冯富秋：LLM Agent未来必将成为服务器操作系统的标配。当前开发者从IaaS到FaaS、MaaS，越来越聚焦客户价值，无需关注底层环境，但系统出问题时，运维会陷入困境，甚至被拉回基础操作层面。未来运维应是“零运维”模式，系统能自主发现、分析、推送问题，人只需做决策授权。LLM Agent正是实现这一目标的关键，能极大改善运维体验，让运维人员从基础操作中解放。

@向阳：我也认为LLM Agent会成为操作系统的标配。我们的愿景是让DeepFlow运行于每个操作系统上，目标三年内国内每年新增服务器的1%都能运行DeepFlow。未来每台服务器可能都会标配GPU，本地拥有算力解决本地问题。另一方面，云作为分布式操作系统，也需LLM Agent和可观测性能力保障稳定。可观测性和控制论最早成功解决飞船登月问题，因此面对复杂的分布式操作系统运维场景，LLM Agent和观测数据能力肯定是必备的。

Q10：落地LLM for AIOps最关键的是什么？有什么建议给到行业？

@冯富秋：首先要明确，LLM for AIOps既非银弹也非泡沫。它目前的推理能力和知识结构不足以解决所有复杂问题，行业需做好预期管理，这一领域还有长路要走。但它也不是泡沫，大模型确实能改善客户体验、精准理解客户意图，还能在模糊问题中做出取舍——这种取舍能力是传统程序不具备的。希望行业各方共同参与，客户不必抱过高预期，但可适当拥抱技术，让技术从泡沫中提炼精华，最终实现“零运维”效果。

@向阳：最关键的是“开始行动”。我们视其为一场革命，需勇敢迈出第一步，同时要避免上一代AIOps的错误——上一代AIOps的数据多来自插桩和日志，数据清洗过程异常痛苦，不少创业公司因此失败，交付团队也可能陷入客户环境泥沼。选择“OS + LLM Agent”的正确方向，走顺数据采集和规整的第一步，后续Agent的效果会在持续使用和评估反思中不断优化、加强。

4 结语：智能运维的进化，始于争议，成于协同

LLM for AIOps的行业争议，本质是新技术落地时预期与现实的必然碰撞。LLM for AIOps并非解决所有问题的“银弹”，却凭借语义理解、跨部门协同的核心能力，打破了传统AIOps的固有瓶颈；虽因“幻觉”问题仍面临“泡沫”质疑，但在OS底座的坚实支撑、eBPF技术的精准赋能，以及持续的技术迭代中，正不断走向完善。

从技术落地到产业普及，这场变革的核心在于“协同”——阿里云与云杉网络的生态协同，OS底座与LLM Agent的技术协同，大模型与传统规则、小模型的分工协同，以及人与机器的决策协同等。当生态层面的技术壁垒逐步消融，当数据与智能的闭环持续构建，当行业标准逐步完善，LLM Agent有望从“争议焦点”逐步成为“运维标配”，进而让“端着咖啡做运维”的梦想照进现实。