LLM for AIOps：从争议到协同，OS+LLM Agent引领智能运维新范式

随着大型语言模型热潮席卷系统运营维护领域，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的痛点主要集中在两方面：一是数据，二是智能。数据层面，过去依靠插桩、打日志的方式采集数据，第一步就要进行繁琐的数据清洗，企业客户往往需要花费半年以上时间；智能层面，基于规则的方案难以应对大量的边缘情况。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有望从“争议焦点”逐步成为“运维标配”，进而让“端着咖啡做运维”的梦想照进现实。