企业官网建设流程全解析

作者 / 来源：中智凯灵 / 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 上海站）的系列观察报道（1）：AI赋能研发组织提效的效果度量：从“个人效率”走向“组织交付”的新标尺

·第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（2）：从跑分到护栏：AI Agent 规模化落地，为什么必须先补上质量底座？

·第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（3）：从 AI Coding 到 Agentic Engineering：研发提效正在进入第二阶段

·第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（4）：为什么企业需要 Spec Driven：AI 写代码越快，需求越要结构化

·第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（5）：Checkpoint 成为训练生命线，AI Infra 的下一道护栏在存储侧

·第9届 AI+研发数字峰会（AiDD 2026 上海站）的系列观察报道（6）：知识库、Skills 与组织资产：AI 能力如何从一次性使用变成持续复利

·硬核对话：从1000人到1人：AI编程的"规模化陷阱"如何破？

·第9届AI+研发数字峰会（AiDD）上海站圆满收官！

这么好的内容，你不转一下吗

转发本篇文章至朋友圈，截图私信后台可免费领取AiDD上海站演讲PPT下载链接！

下一站

AI 运维的故事，上海站只是开篇。

当 AI 从编码、测试进入运维和复杂系统治理，企业更需要讨论的就不只是模型能力，而是数据底座、可观测证据、Agent 协同、因果推演和持续运营。

2026 年 AiDD 北京站，将在上海的基础上继续深挖：从能力突破到工程落地，从开发、测试到运维的全链路智能化升级，以及如何构建高效、可信、可持续演进的 AI+研发工程体系。

别急着把日志丢给大模型。先让系统有能力把事实变成证据。

北京，我们继续聊。