大模型浪潮席卷运维领域之际，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 有望从 “争议焦点” 逐步成为 “运维标配”，进而让 “端着咖啡做运维” 的梦想照进现实。