作者 / 来源中智凯灵 / AiDD——基于第9届 AI研发数字峰会AiDD 2026 上海站的观察报道▼在智能运维里模型越强越不能把原始日志、指标和链路数据直接丢给它。这听起来有些反直觉。过去一年很多团队都在尝试把大模型接进运维系统让它读告警、看日志、总结故障、生成排查建议甚至调用工具完成诊断。Demo 阶段通常并不难看一个模型可以很快把一堆杂乱信息整理成一段像样的解释。但真实运维现场不是一段干净文本。它是微服务、容器、多云架构、指标、日志、链路、告警、事件、变更记录和拓扑关系交织出来的复杂系统。信息量巨大噪声很高关系又并不线性。模型能读到很多内容不等于它能看到信号它能找到相关现象也不等于它理解了因果。在第9届 AI研发数字峰会AiDD 2026 上海站上智能系统运维与运营相关分享反复指向同一个判断AI 运维的关键不是把更多原始数据塞进上下文窗口而是先把领域数据变成 Agent 可以消费的高密度信号、可调用工具、可追溯证据和可验证推理链路。图 1陈鹏飞《大模型在智能运维场景中的初步探索》运维挑战集中在规模巨大、依赖复杂、多样性强、动态性高和数据量大PPT 第 9 页▍AI 运维的第一误区把日志当成上下文喂给大模型智能运维天然适合引入大模型。运维工程师每天面对大量非结构化信息告警摘要、日志片段、变更记录、排障手册、监控曲线、工单备注、知识库经验。大模型擅长语言理解和总结看起来正好可以缓解人工排查的压力。但问题也出在这里。运维不是阅读理解题而是诊断任务。中山大学计算机学院教授陈鹏飞在《大模型在智能运维场景中的初步探索》中把云原生系统的运维痛点概括为几类观测难覆盖、数据难融合、工具难协同、方法难泛化、结果难实施。这里每一项都不是单靠更长上下文能解决的。例如日志里出现同一个错误码可能来自不同服务、不同版本、不同调用链位置一个 CPU 异常可能是资源不足也可能是线程争抢、数据加载瓶颈、缓存策略变化或上游流量突增。模型如果只是读到局部文本很容易把“看起来相关”的现象当成原因。这就是直接把日志丢给大模型的风险它可以给出一个流畅答案却未必给出一个可复核的诊断过程。运维场景里答案的可读性远远不够真正重要的是证据是否完整、路径是否可回放、结论是否能被验证、操作是否有边界。所以AI 运维的第一步不是“让模型多读一点”而是让模型读到更对的东西。图 2刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》AI Investigation 需要综合指标、日志、链路、图、CI/CD、Runbook 和人工审核PPT 第 8 页▍模型不是不够强而是缺少可消费的领域信号阿里云云原生可观测技术专家刘贵阳在《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》中给出了一个很直接的判断LLM 的推理能力在快速增长但直接面对 EB 级指标、日志和链路数据时它既看不懂也想不对。这句话背后是 AIOps 从 Demo 走向工业级应用时必须补上的数据底座。在刘贵阳的分享里关键不是把原始数据直接交给模型而是搭建一套让 Agent 能消费运维信号的结构算子层负责从海量数据中做计算和压缩MCP 工具层提供标准化查询接口数据工具化层再把这些能力封装成 Agent 可以直接调用的高层工具。这件事的本质是把“原始数据”变成“可行动证据”。原始日志告诉你发生了什么领域信号告诉你什么值得被关注指标曲线告诉你数值变化工具化接口告诉 Agent 应该怎么进一步查询拓扑关系告诉你服务之间有关联统一实体模型才能让 Agent 在服务、实例、链路、事件和变更之间建立稳定映射。这也是为什么刘贵阳强调统一实体模型和 Investigation Graph。图不是为了画得更好看而是为了把服务、节点、指标、事件、变更、证据和调查状态装进同一个可推理容器里。没有这层结构Agent 很容易在海量数据中反复搜索有了这层结构Agent 才能围绕对象、关系和证据推进诊断。图 3刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》统一实体模型与 Investigation Graph 构成运维数据底座PPT 第 13 页图 4刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》Graph Modeling 将状态、上下文和调查进展沉淀到图结构中PPT 第 15 页▍从相关到因果AI 运维不能停在“可能是它”运维诊断最容易走偏的地方是把相关性当成因果。一次线上故障发生时系统里同时会出现大量现象某个服务延迟升高某个接口错误率上升某个实例重启某条链路变慢某个配置刚刚变更。它们可能都和故障有关但真正的问题是哪个现象是原因哪个只是结果哪个变化触发了连锁反应哪个只是同时发生的噪声传统告警系统很难回答这个问题通用大模型也很难凭一段上下文回答。因为因果推断需要结构化证据、反事实验证和逐步收敛的调查过程。刘贵阳的分享把这一点讲得很清楚AIOps 的技术路线不能只停留在关联推理最终要走向因果推理。所谓因果推理不是让模型说出一句“根因可能是某某服务”而是能解释为什么不是其他服务为什么这个变化足以导致结果关键证据来自哪里反事实条件下故障是否会消失。这也是图驱动多 Agent 协同的价值。不同 Agent 可以分别处理指标、日志、链路、事件、变更和历史案例但它们不能各查各的最后拼一段总结。它们需要围绕同一个证据模型协作让每一步调查都能进入统一状态容器并在需要时被回放、被审核、被纠偏。真正进入生产的 AI 运维系统不应只追求“答案生成得快”而要追求“诊断过程站得住”。图 5刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》证据模型覆盖指标、链路、事件、日志与因果图PPT 第 30 页图 6刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》反事实验证用于确认 RCA 核心因果链PPT 第 31 页▍多 Agent 不是分工表而是调查协议很多团队一听到多 Agent就会先想到角色分工日志 Agent、指标 Agent、链路 Agent、诊断 Agent、修复 Agent。这个方向并没有错但如果只停留在角色命名多 Agent 很容易变成“多个模型轮流发言”。运维场景里的多 Agent 更关键的是协议。谁能发起调查谁负责收集证据谁能更新假设不同 Agent 的结论如何冲突解决什么时候进入下一步排查什么时候停止哪些动作需要人工确认这些问题不解决多 Agent 只是把一个黑盒拆成多个黑盒。刘贵阳展示的多 Agent 协同更接近一个围绕证据和状态运转的调查系统Agent 不只是说话角色而是围绕图结构和证据模型执行任务协同不是简单并发而是有状态、有上下文、有轨迹、有回放能力的过程。这对企业非常重要。运维不是开放式创作而是高责任任务。系统可以推荐根因可以建议修复但每一步都要能回答依据是什么查了哪些证据排除了哪些假设风险边界在哪里。所以多 Agent 运维的核心不是“人多力量大”而是让复杂调查能够被拆分、协作和复核。图 7刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》多 Agent 协同需要围绕统一协议和状态闭环展开PPT 第 38 页▍从实验走向平台告警、知识库、工具和人机协作要接在一起陈鹏飞的分享从另一个角度补充了这个问题智能运维不是单点能力而是平台能力。在他展示的智能运维平台构想中运维大模型、运维知识库、多智能体协作、指标检测工具、日志分析工具、调用链分析工具、诊断智能体、人机协作共同覆盖故障检测、告警管理、故障诊断、故障自愈等场景。这说明 AI 运维的落地路径不能只看某个模型或某个 Agent 是否能回答问题。它必须把几类能力接起来底层有可观测数据和运维知识库中间有工具查询和分析能力上层有多 Agent 协作和诊断流程旁边还有人工审核、反馈和持续演进机制。很多智能运维 Demo 做得顺是因为它绕开了平台化难题数据事先准备好工具调用被简化权限问题不出现异常路径没有展开。但真实生产环境会不断打断这种顺滑感。告警会误报日志会缺失工具会失败知识库会过期模型会把偶然相关误判成因果。平台化的意义就是让这些不确定性有地方被承接。不是每次故障都临时拼上下文而是把数据接入、工具调用、知识更新、Agent 协作、人工审核和效果评估变成稳定机制。图 8陈鹏飞《大模型在智能运维场景中的初步探索》智能运维平台覆盖故障检测、告警管理、故障诊断和多智能体协作PPT 第 23 页▍复杂系统里的 AI最终拼的是可观测和全链路指标智能运维不仅发生在业务系统里也发生在 AI 系统自身。阿里云技术专家孙禹峰在《AI-Infra 全链路性能分析和优化实战》中从训推性能优化角度说明了另一个底层事实大模型时代的系统问题越来越难定位原因往往跨越数据、计算、通信、存储、网络和业务指标。这对 AI 运维同样成立。一个推理服务变慢可能不是模型本身变差而是 Prefill 和 Decode 混跑导致延迟抖动一个训练任务效率下降可能不是 GPU 不够而是 CPU 或数据加载先成为瓶颈一个线上接口 RT 稳定增长常规监控可能看不出明显异常但 Trace 里的耗时空洞会暴露真正问题。孙禹峰给出的全链路性能指标体系覆盖系统级效率、训推业务指标、高性能网络、存储资源、CPU/GPU 计算资源等多个层次。它提醒企业AI 系统进入生产后诊断对象不再只是应用本身而是一条跨软硬件、跨模型、跨平台的复杂链路。如果没有这样的指标体系Agent 再聪明也只能在碎片信息里猜有了全链路可观测Agent 才可能把推理建立在证据之上。图 9孙禹峰《AI-Infra 全链路性能分析和优化实战》全链路性能指标体系覆盖系统级、业务、高性能网络、存储和计算资源指标PPT 第 11 页▍给企业的启发别先问模型会不会推理先问数据能不能变成证据把这几场分享放在一起看可以得到一个很清晰的结论AI 运维的竞争点正在从“模型能不能回答”转向“企业有没有把复杂系统变成可推理对象”。模型能力当然重要但在严肃运维场景里模型只是最后一环。真正决定落地效果的是前面有没有把数据清洗成信号把工具封装成接口把关系建成图把过程沉淀成轨迹把结论变成可验证证据把运行结果回流到评估和知识体系中。这也是为什么“领域基础设施”会越来越重要。越是高风险、高复杂度、高责任的场景越不能指望一个通用模型直接读完上下文就做判断。企业需要先建设能让 Agent 工作的环境数据底座、工具体系、知识库、可观测指标、权限边界、评估基准和人机协作流程。对正在规划 AI 运维的团队来说有几个问题比“模型选哪个”更值得先问运维数据能不能被统一建模日志、指标、链路、事件、变更和拓扑能不能关联到同一对象Agent 调用工具时能不能拿到高密度、低噪声、可复核的信号RCA 结论有没有证据链能不能做反事实验证线上每一次失败能不能回流成新的评估样本和知识更新如果这些问题没有答案AI 运维很容易停在 Demo。它看起来会分析实际上难以承担责任它看起来会总结实际上无法稳定定位它看起来能调用工具实际上缺少可治理的工程边界。如果这些问题逐步被解决AI 运维才有机会从“会回答”走向“会诊断”再走向“可运营”。 主要参考资料•陈鹏飞《大模型在智能运维场景中的初步探索》AiDD 2026 上海站智能系统的运维与运营2026-05-22。•刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》AiDD 2026 上海站智能系统的运维与运营2026-05-22。•孙禹峰《AI-Infra 全链路性能分析和优化实战》AiDD 2026 上海站大模型架构创新与工程优化2026-05-22。 相关文章·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道1AI赋能研发组织提效的效果度量从“个人效率”走向“组织交付”的新标尺·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道2从跑分到护栏AI Agent 规模化落地为什么必须先补上质量底座·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道3从 AI Coding 到 Agentic Engineering研发提效正在进入第二阶段·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道4为什么企业需要 Spec DrivenAI 写代码越快需求越要结构化·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道5Checkpoint 成为训练生命线AI Infra 的下一道护栏在存储侧·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道6知识库、Skills 与组织资产AI 能力如何从一次性使用变成持续复利·硬核对话从1000人到1人AI编程的规模化陷阱如何破·第9届AI研发数字峰会AiDD上海站圆满收官这么好的内容你不转一下吗转发本篇文章至朋友圈截图私信后台可免费领取AiDD上海站演讲PPT下载链接下一站AI 运维的故事上海站只是开篇。当 AI 从编码、测试进入运维和复杂系统治理企业更需要讨论的就不只是模型能力而是数据底座、可观测证据、Agent 协同、因果推演和持续运营。2026 年 AiDD 北京站将在上海的基础上继续深挖从能力突破到工程落地从开发、测试到运维的全链路智能化升级以及如何构建高效、可信、可持续演进的 AI研发工程体系。别急着把日志丢给大模型。先让系统有能力把事实变成证据。北京我们继续聊。
别把日志直接丢给大模型：AI 运维落地，为什么先要补领域基础设施？
作者 / 来源中智凯灵 / AiDD——基于第9届 AI研发数字峰会AiDD 2026 上海站的观察报道▼在智能运维里模型越强越不能把原始日志、指标和链路数据直接丢给它。这听起来有些反直觉。过去一年很多团队都在尝试把大模型接进运维系统让它读告警、看日志、总结故障、生成排查建议甚至调用工具完成诊断。Demo 阶段通常并不难看一个模型可以很快把一堆杂乱信息整理成一段像样的解释。但真实运维现场不是一段干净文本。它是微服务、容器、多云架构、指标、日志、链路、告警、事件、变更记录和拓扑关系交织出来的复杂系统。信息量巨大噪声很高关系又并不线性。模型能读到很多内容不等于它能看到信号它能找到相关现象也不等于它理解了因果。在第9届 AI研发数字峰会AiDD 2026 上海站上智能系统运维与运营相关分享反复指向同一个判断AI 运维的关键不是把更多原始数据塞进上下文窗口而是先把领域数据变成 Agent 可以消费的高密度信号、可调用工具、可追溯证据和可验证推理链路。图 1陈鹏飞《大模型在智能运维场景中的初步探索》运维挑战集中在规模巨大、依赖复杂、多样性强、动态性高和数据量大PPT 第 9 页▍AI 运维的第一误区把日志当成上下文喂给大模型智能运维天然适合引入大模型。运维工程师每天面对大量非结构化信息告警摘要、日志片段、变更记录、排障手册、监控曲线、工单备注、知识库经验。大模型擅长语言理解和总结看起来正好可以缓解人工排查的压力。但问题也出在这里。运维不是阅读理解题而是诊断任务。中山大学计算机学院教授陈鹏飞在《大模型在智能运维场景中的初步探索》中把云原生系统的运维痛点概括为几类观测难覆盖、数据难融合、工具难协同、方法难泛化、结果难实施。这里每一项都不是单靠更长上下文能解决的。例如日志里出现同一个错误码可能来自不同服务、不同版本、不同调用链位置一个 CPU 异常可能是资源不足也可能是线程争抢、数据加载瓶颈、缓存策略变化或上游流量突增。模型如果只是读到局部文本很容易把“看起来相关”的现象当成原因。这就是直接把日志丢给大模型的风险它可以给出一个流畅答案却未必给出一个可复核的诊断过程。运维场景里答案的可读性远远不够真正重要的是证据是否完整、路径是否可回放、结论是否能被验证、操作是否有边界。所以AI 运维的第一步不是“让模型多读一点”而是让模型读到更对的东西。图 2刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》AI Investigation 需要综合指标、日志、链路、图、CI/CD、Runbook 和人工审核PPT 第 8 页▍模型不是不够强而是缺少可消费的领域信号阿里云云原生可观测技术专家刘贵阳在《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》中给出了一个很直接的判断LLM 的推理能力在快速增长但直接面对 EB 级指标、日志和链路数据时它既看不懂也想不对。这句话背后是 AIOps 从 Demo 走向工业级应用时必须补上的数据底座。在刘贵阳的分享里关键不是把原始数据直接交给模型而是搭建一套让 Agent 能消费运维信号的结构算子层负责从海量数据中做计算和压缩MCP 工具层提供标准化查询接口数据工具化层再把这些能力封装成 Agent 可以直接调用的高层工具。这件事的本质是把“原始数据”变成“可行动证据”。原始日志告诉你发生了什么领域信号告诉你什么值得被关注指标曲线告诉你数值变化工具化接口告诉 Agent 应该怎么进一步查询拓扑关系告诉你服务之间有关联统一实体模型才能让 Agent 在服务、实例、链路、事件和变更之间建立稳定映射。这也是为什么刘贵阳强调统一实体模型和 Investigation Graph。图不是为了画得更好看而是为了把服务、节点、指标、事件、变更、证据和调查状态装进同一个可推理容器里。没有这层结构Agent 很容易在海量数据中反复搜索有了这层结构Agent 才能围绕对象、关系和证据推进诊断。图 3刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》统一实体模型与 Investigation Graph 构成运维数据底座PPT 第 13 页图 4刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》Graph Modeling 将状态、上下文和调查进展沉淀到图结构中PPT 第 15 页▍从相关到因果AI 运维不能停在“可能是它”运维诊断最容易走偏的地方是把相关性当成因果。一次线上故障发生时系统里同时会出现大量现象某个服务延迟升高某个接口错误率上升某个实例重启某条链路变慢某个配置刚刚变更。它们可能都和故障有关但真正的问题是哪个现象是原因哪个只是结果哪个变化触发了连锁反应哪个只是同时发生的噪声传统告警系统很难回答这个问题通用大模型也很难凭一段上下文回答。因为因果推断需要结构化证据、反事实验证和逐步收敛的调查过程。刘贵阳的分享把这一点讲得很清楚AIOps 的技术路线不能只停留在关联推理最终要走向因果推理。所谓因果推理不是让模型说出一句“根因可能是某某服务”而是能解释为什么不是其他服务为什么这个变化足以导致结果关键证据来自哪里反事实条件下故障是否会消失。这也是图驱动多 Agent 协同的价值。不同 Agent 可以分别处理指标、日志、链路、事件、变更和历史案例但它们不能各查各的最后拼一段总结。它们需要围绕同一个证据模型协作让每一步调查都能进入统一状态容器并在需要时被回放、被审核、被纠偏。真正进入生产的 AI 运维系统不应只追求“答案生成得快”而要追求“诊断过程站得住”。图 5刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》证据模型覆盖指标、链路、事件、日志与因果图PPT 第 30 页图 6刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》反事实验证用于确认 RCA 核心因果链PPT 第 31 页▍多 Agent 不是分工表而是调查协议很多团队一听到多 Agent就会先想到角色分工日志 Agent、指标 Agent、链路 Agent、诊断 Agent、修复 Agent。这个方向并没有错但如果只停留在角色命名多 Agent 很容易变成“多个模型轮流发言”。运维场景里的多 Agent 更关键的是协议。谁能发起调查谁负责收集证据谁能更新假设不同 Agent 的结论如何冲突解决什么时候进入下一步排查什么时候停止哪些动作需要人工确认这些问题不解决多 Agent 只是把一个黑盒拆成多个黑盒。刘贵阳展示的多 Agent 协同更接近一个围绕证据和状态运转的调查系统Agent 不只是说话角色而是围绕图结构和证据模型执行任务协同不是简单并发而是有状态、有上下文、有轨迹、有回放能力的过程。这对企业非常重要。运维不是开放式创作而是高责任任务。系统可以推荐根因可以建议修复但每一步都要能回答依据是什么查了哪些证据排除了哪些假设风险边界在哪里。所以多 Agent 运维的核心不是“人多力量大”而是让复杂调查能够被拆分、协作和复核。图 7刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》多 Agent 协同需要围绕统一协议和状态闭环展开PPT 第 38 页▍从实验走向平台告警、知识库、工具和人机协作要接在一起陈鹏飞的分享从另一个角度补充了这个问题智能运维不是单点能力而是平台能力。在他展示的智能运维平台构想中运维大模型、运维知识库、多智能体协作、指标检测工具、日志分析工具、调用链分析工具、诊断智能体、人机协作共同覆盖故障检测、告警管理、故障诊断、故障自愈等场景。这说明 AI 运维的落地路径不能只看某个模型或某个 Agent 是否能回答问题。它必须把几类能力接起来底层有可观测数据和运维知识库中间有工具查询和分析能力上层有多 Agent 协作和诊断流程旁边还有人工审核、反馈和持续演进机制。很多智能运维 Demo 做得顺是因为它绕开了平台化难题数据事先准备好工具调用被简化权限问题不出现异常路径没有展开。但真实生产环境会不断打断这种顺滑感。告警会误报日志会缺失工具会失败知识库会过期模型会把偶然相关误判成因果。平台化的意义就是让这些不确定性有地方被承接。不是每次故障都临时拼上下文而是把数据接入、工具调用、知识更新、Agent 协作、人工审核和效果评估变成稳定机制。图 8陈鹏飞《大模型在智能运维场景中的初步探索》智能运维平台覆盖故障检测、告警管理、故障诊断和多智能体协作PPT 第 23 页▍复杂系统里的 AI最终拼的是可观测和全链路指标智能运维不仅发生在业务系统里也发生在 AI 系统自身。阿里云技术专家孙禹峰在《AI-Infra 全链路性能分析和优化实战》中从训推性能优化角度说明了另一个底层事实大模型时代的系统问题越来越难定位原因往往跨越数据、计算、通信、存储、网络和业务指标。这对 AI 运维同样成立。一个推理服务变慢可能不是模型本身变差而是 Prefill 和 Decode 混跑导致延迟抖动一个训练任务效率下降可能不是 GPU 不够而是 CPU 或数据加载先成为瓶颈一个线上接口 RT 稳定增长常规监控可能看不出明显异常但 Trace 里的耗时空洞会暴露真正问题。孙禹峰给出的全链路性能指标体系覆盖系统级效率、训推业务指标、高性能网络、存储资源、CPU/GPU 计算资源等多个层次。它提醒企业AI 系统进入生产后诊断对象不再只是应用本身而是一条跨软硬件、跨模型、跨平台的复杂链路。如果没有这样的指标体系Agent 再聪明也只能在碎片信息里猜有了全链路可观测Agent 才可能把推理建立在证据之上。图 9孙禹峰《AI-Infra 全链路性能分析和优化实战》全链路性能指标体系覆盖系统级、业务、高性能网络、存储和计算资源指标PPT 第 11 页▍给企业的启发别先问模型会不会推理先问数据能不能变成证据把这几场分享放在一起看可以得到一个很清晰的结论AI 运维的竞争点正在从“模型能不能回答”转向“企业有没有把复杂系统变成可推理对象”。模型能力当然重要但在严肃运维场景里模型只是最后一环。真正决定落地效果的是前面有没有把数据清洗成信号把工具封装成接口把关系建成图把过程沉淀成轨迹把结论变成可验证证据把运行结果回流到评估和知识体系中。这也是为什么“领域基础设施”会越来越重要。越是高风险、高复杂度、高责任的场景越不能指望一个通用模型直接读完上下文就做判断。企业需要先建设能让 Agent 工作的环境数据底座、工具体系、知识库、可观测指标、权限边界、评估基准和人机协作流程。对正在规划 AI 运维的团队来说有几个问题比“模型选哪个”更值得先问运维数据能不能被统一建模日志、指标、链路、事件、变更和拓扑能不能关联到同一对象Agent 调用工具时能不能拿到高密度、低噪声、可复核的信号RCA 结论有没有证据链能不能做反事实验证线上每一次失败能不能回流成新的评估样本和知识更新如果这些问题没有答案AI 运维很容易停在 Demo。它看起来会分析实际上难以承担责任它看起来会总结实际上无法稳定定位它看起来能调用工具实际上缺少可治理的工程边界。如果这些问题逐步被解决AI 运维才有机会从“会回答”走向“会诊断”再走向“可运营”。 主要参考资料•陈鹏飞《大模型在智能运维场景中的初步探索》AiDD 2026 上海站智能系统的运维与运营2026-05-22。•刘贵阳《突破 LLM 的运维能力边界图驱动多 Agent 协同与因果推演实战》AiDD 2026 上海站智能系统的运维与运营2026-05-22。•孙禹峰《AI-Infra 全链路性能分析和优化实战》AiDD 2026 上海站大模型架构创新与工程优化2026-05-22。 相关文章·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道1AI赋能研发组织提效的效果度量从“个人效率”走向“组织交付”的新标尺·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道2从跑分到护栏AI Agent 规模化落地为什么必须先补上质量底座·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道3从 AI Coding 到 Agentic Engineering研发提效正在进入第二阶段·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道4为什么企业需要 Spec DrivenAI 写代码越快需求越要结构化·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道5Checkpoint 成为训练生命线AI Infra 的下一道护栏在存储侧·第9届 AI研发数字峰会AiDD 2026 上海站的系列观察报道6知识库、Skills 与组织资产AI 能力如何从一次性使用变成持续复利·硬核对话从1000人到1人AI编程的规模化陷阱如何破·第9届AI研发数字峰会AiDD上海站圆满收官这么好的内容你不转一下吗转发本篇文章至朋友圈截图私信后台可免费领取AiDD上海站演讲PPT下载链接下一站AI 运维的故事上海站只是开篇。当 AI 从编码、测试进入运维和复杂系统治理企业更需要讨论的就不只是模型能力而是数据底座、可观测证据、Agent 协同、因果推演和持续运营。2026 年 AiDD 北京站将在上海的基础上继续深挖从能力突破到工程落地从开发、测试到运维的全链路智能化升级以及如何构建高效、可信、可持续演进的 AI研发工程体系。别急着把日志丢给大模型。先让系统有能力把事实变成证据。北京我们继续聊。
