一直以来，龙蜥社区在 RISC-V 生态建设中持续投入，并积极贡献上游社区。为加速 RISC-V 在数据中心场景的能力补齐与规模化落地，RISC-V International Data Center SIG 近期将例会节奏由月度调整为双周。以下为第六次会议内容：

RISC-V 架构中引入持久化内存缺口

近期，RISC-V 基金会 Data Center SIG 月度会议于线上召开，来自阿里云、中兴通讯、Rivos、RISC-V 国际基金会等企业的宋卓、王宝林、孙浩、郭任、贾云翔、Snehasish、Beeman、Rafael 等 13 位委员及代表参会。会议由宋卓先生主持，重点围绕“在 RISC-V 架构中引入持久化内存（Persistent Memory，PMem）相关支持”的方向展开讨论。

本次会议邀请阿里云王宝林以及阿里巴巴达摩院孙浩进行分享，王宝林长期负责 龙蜥社区内核内存子系统并参与上游维护，他从云计算实际工作负载出发，介绍了 PMem 的产业背景、数据中心应用价值以及 RISC-V 当前在相关指令/语义支持方面的缺口，并建议在社区层面推动形成面向 PMem 的标准化工作。

PMem 在云数据中心的现实需求：以 Redis/数据库场景为例

王宝林指出，PMem 具备字节寻址、高密度与直接持久化等特性。尽管 Intel 已宣布 Optane PMem 产品线停止，但 PMem 的研究与应用并未停止，产业界仍在持续投入。更重要的是，PMem 在云场景已经验证了价值：例如在云数据库/缓存系统（如 Redis）中，结合 PMem 可构建混合内存架构，在保持高吞吐的同时减少传统方案的周期性延迟抖动，并提升实例异常重启后的恢复效率。

他进一步强调，在数据中心落地 PMem 的关键不止在“介质可持久化”，还在于系统能否提供可靠的持久化语义保证：若缺乏明确的持久化点与配套机制，业务往往仍需依赖持久化云盘兜底，从而引入额外成本。

来自 Akeana 的 David Weaver 在讨论中表达了强烈支持。他提到自己曾在 Sun 与 Oracle 工作，数据库公司长期对 PMem 非常关注；他认为若 RISC-V 要严肃进入数据中心，PMem 相关能力必须补齐，“如果我们要认真做 RISC-V 数据中心生态，就需要把这件事做起来”。

作为 TSC（Technical Steering Committee）成员，David 也给出了清晰的推进路径建议：

• 对 TSC 的汇报重点不应是硬件实现细节，因为硬件设计属于后续任务组（TG）工作的范畴。
• TSC 需要先理解两点：为什么需要（动机与价值），以及准备做什么（任务组的工作范围与交付物）。

他建议提案应明确三类核心工作：定义持久化模型（persistency model）、定义对 ISA 的影响/原语（例如 flush 到持久化点的指令语义），以及讨论持久化顺序与相关互连/协议协作等问题。

社区关切：最终产出落在哪里？——ISA 扩展是核心方向

会上，来自社区的 Victor Lu 也提出了典型问题：RISC-V 以 ISA 为核心，本议题涉及较多系统特性，最终产出将如何与 ISA 对齐？

主持人宋卓与 David 等回应称，若后续推动成立 TG，该方向最终将形成面向 RISC-V 的架构/ISA 扩展建议（例如“将指定地址数据 flush 到持久化点”的指令或原语），并在规范层面给出一致语义；至于底层硬件实现方式，可由各厂商在遵循规范的前提下选择具体实现路径。

会议后段，阿里巴巴达摩院孙浩补充表示：硬件实现应当基于清晰的 RISC-V 规范。目前 RISC-V 缺乏对应 spec，因此应优先推动形成规范文本与语义定义，硬件实现可在此基础上由不同实现方展开，并参考其他架构既有经验逐步细化。

RISC-V 数据中心的潜在缺口与改进方向

为持续推动 RISC-V 在数据中心与服务器场景的可用性与可移植性，RISC-V International Data Center SIG 召开线上双周例会。本次会议由阿里巴巴宋卓主持，并邀请来自中兴通讯的贾云翔（Yunxiang Jia）从服务器视角系统梳理当前服务器相关规范中的潜在缺口与改进方向。来自 Rivos、字节跳动、阿里巴巴及 RISC-V International 的多位代表参与讨论并提出关键建议。

服务器视角的“缺口清单”：希望补强的能力点有哪些？

贾云翔介绍了服务器视角的“缺口清单”概要解读，主要覆盖以下几个方面：

• ISA 扩展建议

在现有服务器规范/配置中，一些 ISA 层扩展并非强制，但在安全性、可维护性等方面具有价值，贾云翔建议在服务器平台规范中评估补充（发言中举例提到若干扩展方向）。

• PMU（性能监控）事件完善

当前规范条目（发言中提及 SPM 030/040）偏重 PCIe inbound 事件定义；他认为 outbound PCIe 事件同样重要，应纳入规范。

另外，关于部分 CMO/缓存一致性相关事件 的标准化需求，他提到 Performance Events Task Group 可能已有相关工作，希望能与服务器规范衔接、视情况纳入。

• 调试/开发者能力（Debug capability）相关条目

他指出现有调试能力清单与 RISC-V Debug/Trace 相关规范版本之间存在差异，且有些能力（例如 program buffer 等）对开发调试很关键，希望服务器平台规范能更好覆盖。

• Trace（跟踪）能力

他建议在服务器规范中提高对 trace 的要求，至少支持某类 trace 形态（发言中倾向 E-Trace），并希望补充更明确的技术要求描述。

• Watchdog / Timer（看门狗与计时）

他认为 watchdog 对系统故障恢复很重要，当前要求不足；同时提到可参考 Arm 相关规范中关于 clock/time 的写法与约束。

• 其他：复位/电源管理/CSR、以及 CXL 集成等

他提到部分复位、电源管理与 CSR 等能力在当前版本中存在缺失；此外也提到了 CXL 相关内容，希望后续能在服务器平台规范中补齐或明确。

Rivos：规范的“取舍原则”——服务器规范聚焦 OS 可移植性，不强制 Machine Mode/外部调试能力

Rivos 的 Vedvyas Shanbhogue 在讨论中提出了非常关键的规范取舍原则

服务器 SoC/平台规范以及 ISA Profiles 的核心目标，是保证 可移植操作系统/Hypervisor 在低于 M-mode 的特权级上运行的一致性能力；

因此，许多 Machine Mode 才可见、或偏 外部调试/外部 trace（对 OS 不可见）的能力，之所以未被纳入强制要求，并非遗漏，而是有意为之的设计选择；

这类似于 Arm SBSA 等规范并不强制某些更高特权级能力。未来如果社区定义“Machine Mode Profile”，再把这类能力纳入会更合理。

这一点也帮助 SIG 成员对“哪些能力应该进入服务器平台强制项、哪些应留给实现选择”形成更清晰的边界认识。贾云翔表示会进一步消化该原则，并重新评估条目归类方式。

Trace 讨论升温：E-Trace 还是 N-Trace？SIG 需要形成偏好以利于软件可移植性

围绕 Trace，Vedvyas 进一步追问了一个对未来版本非常关键的问题：如果未来要把“自托管（self-hosted）trace”纳入 server SoC/平台规范，就必须在 E-Trace 与 N-Trace 之间做出倾向，否则两者都“可选”会削弱对可移植软件的价值。

针对此问题，贾云翔从个人角度表达更倾向 E-Trace，并希望进一步完善其规格细节；Vedvyas 表示个人也赞同，但更希望 Data Center SIG 形成明确立场/建议，以便未来规则制定与版本演进。

Watchdog/Timer 的必要性答疑：与 PMU Counter 的角色不同

字节跳动的崔云辉就 watchdog/timer 提问：既然已有 PMU counter，为何仍需要 watchdog 或独立 timer 硬件？

贾云翔回应：watchdog/timer 更多面向固件/更高特权级（偏 machine mode）场景，用于系统故障恢复与可靠性保障；崔云辉确认理解其适用范围。同时，Vedvyas 也补充：服务器 SoC 规范对 time 已有明确要求（例如 1ns 分辨率、64-bit 等），可满足长期不回绕等目标。

CXL：从“是否需要”到“如何写进规范”——类型演进与版本门槛成为焦点

CXL 部分引发了进一步讨论。字节跳动的何爽对 CXL 的必要性提出疑问：当前 CXL 是否仍偏研究探索，是否会真实落地？

主持人宋卓回应：CXL 不仅面向 AI，也在数据库与云场景有用例与业务价值，应当成为 RISC-V 服务器能力考虑的一部分。阿里巴巴薛帅补充：在云存储中“扩展内存（expander memory）”是常见使用方式。

接着，Vedvyas 则从规范制定角度补充了两点洞察：

CXL 规范整体“可选项较少”，并配套合规测试，相比 PCIe 的高可选性，往往难点在于“除了要求实现 CXL 规范本身，还需要额外规定什么”；

他们正在考虑提出更明确的版本约束：如果集成 CXL，建议至少从 CXL 2.0 起步，避免 CXL 1.0/1.1 在 Root Complex 上引入额外复杂性（例如 RCRB 等历史包袱）。他在会上征询与会者是否认可“2.0 或更高”的方向。贾云翔表示倾向认可，但是否在规范中写成明确约束仍需进一步评估。

此外，Vedvyas 也提到：PM、电源状态与唤醒、以及 CXL 集成等内容，正在 Server SoC2 Task Group 中推进；初版未纳入属阶段性取舍，欢迎把需求带到 SoC2 TG 进一步讨论。

下一步：材料进入邮件列表，与 Server SoC/平台 TG 联动推进

会议最后，宋卓建议贾云翔将本次“缺口清单”与材料通过 Data Center SIG 邮件列表共享，以便与其它 SIG/TG（尤其是 Server SoC TG 等）开展联动协作。贾云翔确认将把文档发送至相关 TG，推动后续对齐与吸收。

随着服务器场景标准化进入深水区，Data Center SIG 也将围绕“可移植 OS 视角的强制项边界”“Trace 取舍建议”“CXL 版本门槛与集成规则”等议题继续形成更明确的社区共识，并通过与相关 TG 的协作推进到规范条文层面。

—— 完 ——

全文链接：https://tecdat.cn/?p=45017
原文出处：拓端数据部落公众号
 

在国内大语言模型技术高速迭代的当下，行业发展已经从单纯的参数规模竞赛，转向了“性能、成本、可用性”三者平衡的产业落地阶段。过去，想要使用具备顶尖编码与智能体能力的大模型，只能依赖海外闭源API服务，不仅使用成本高昂，还存在核心数据出境的安全风险。而国内一众开源模型的崛起，正在彻底打破这一局面，MiniMax M2.5就是其中的代表性产品。我们在服务企业客户的过程中发现，多数企业在AI落地时面临着性能与成本难以平衡、闭源模型数据安全风险高、开源模型部署门槛高三大核心痛点。基于此，我们以MiniMax M2.5为核心，完成了从技术原理拆解、多维度性能测评到全场景落地应用的全流程研究，为各类企业选择与部署大模型提供了可直接复用的落地方案。本文覆盖了模型核心特性、实操应用案例、基准测试结果、主流模型横向对比及本地化部署方案，能够帮助技术人员与企业决策者快速掌握模型的应用价值与落地方法。

本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整内容已分享至交流社群。阅读原文进群，可与800+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路，帮大家既懂 怎么做，也懂 为什么这么做；遇代码运行问题，更能享24小时调试支持。

文章脉络流程图

MiniMaxM2.5大模型概述

大语言模型的发展，已经从实验室里的技术突破，走向了企业生产场景的规模化落地。过去，想要用上具备顶尖开发与智能办公能力的大模型，企业往往需要承担极高的API调用成本，还要面对核心业务数据上传到第三方平台的安全隐患。而国内开源大模型的快速发展，正在为企业提供一条低成本、高安全、可自主掌控的AI落地路径，MiniMax M2.5正是这条路径上的标杆产品。
MiniMax M2.5是由国内企业研发的开源权重大语言模型，于2026年2月正式发布。该模型从研发之初就完全瞄准企业真实生产场景的生产力需求，核心聚焦编码开发、智能体工具调用、网页信息检索、办公自动化四大高频企业场景，通过在超20万个复杂真实业务场景中进行强化学习训练，让模型具备了资深软件架构师级别的规划能力与自主执行能力。
和很多一味追求参数规模的大模型不同，MiniMax M2.5实现了“顶尖业务性能+极低使用成本”的双重突破，让行业一直提及的“普惠级人工智能”从概念变成了可落地的现实。模型同时提供两个商用版本，标准版推理速度可达50token/秒，闪电版更是能达到100token/秒，两个版本除了推理速度之外，核心业务能力完全一致，企业可以根据自身业务的响应需求灵活选择。

模型核心技术与创新特性拆解

MiniMax M2.5能在众多开源模型中脱颖而出，核心在于其针对企业产业落地场景做了深度的技术优化，形成了四大核心优势，我们也将这些技术特性用通俗易懂的方式为大家拆解说明。

多语言全栈开发能力

模型在训练阶段覆盖了超10种主流编程语言，包括Python、Rust、Java、Go等，不仅能完成基础的代码补全与bug修复，更能覆盖从0到1的系统架构设计、运行环境搭建、业务功能开发、代码合规审核、系统联调测试的全流程研发工作，同时支持Web网页、移动端应用、桌面端程序等多平台的全栈开发需求。

高效智能体工具调用与检索能力

在多轮函数调用与网页导航任务中，模型展现出了行业顶尖的执行水平，同时相比前代产品，完成同等业务任务所需的交互轮次减少了20%，能更高效地完成复杂任务的拆解与执行，大幅降低了长周期业务任务的token消耗与执行时间。

深度适配的办公自动化能力

为了满足企业办公场景的真实需求，研发团队联合金融、法律、社科等领域的资深专家，打造了完全贴合行业真实工作标准的训练数据，让模型能直接输出符合行业规范的文档、演示文稿、表格文件，在企业办公场景的专项测评中，相比主流模型的平均胜率达到了59%。

基于强化学习的极致效率优化

模型依托自研的Forge强化学习框架与CISPO算法，相比前代产品完成同等业务任务的速度提升了37%，同时token消耗更低，在编码专项测试中，单个开发任务平均仅消耗352万token，在保证业务性能的同时，进一步降低了企业的规模化使用成本。

相关文章

2026年Claude Code、OpenCode智能编码代理工具选型研究|附教程

原文链接：https://tecdat.cn/?p=45008

模型落地应用场景实操验证

技术特性最终要落到实际业务中才能体现价值，我们通过多个企业高频业务场景的实操验证，全面测试了MiniMax M2.5的实际落地效果，也为大家提供了可直接复用的应用思路。

多源数据合成与结构化分析

在企业投研与市场分析工作中，经常需要从多个公开渠道提取核心数据，并整合成规范的结构化表格，这也是日常办公中高频且耗时的重复性工作。我们通过模型完成了全球头部主权财富基金的多维度数据合成任务，具体指令如下：

针对全球资产管理规模前五的主权财富基金，提取以下维度信息：基金名称、所属国家、当前资产管理规模、现任负责人姓名及任职时间、最新年报披露的投资收益率，以及所属国家的基尼系数，最终整理成规范表格并标注每个数据的来源。

模型成功从多个公开数据源提取并核验了相关数据，输出了完整的结构化分析表格，结果如下：

这个看似简单的业务场景，却精准验证了模型的网页信息检索、多源信息整合、数据交叉核验三大核心能力，完全能满足企业投研分析、市场调研、行业研究等场景的真实工作需求。

全栈Web应用开发

在软件开发场景中，我们测试了模型从零搭建用户认证系统的能力，指令如下：

使用React框架搭建前端页面，配合Node.js开发后端服务，实现完整的用户注册与登录认证功能，同时设计对应的数据库表结构。

模型首先输出了完整的架构设计方案，包含UI原型规划、API接口设计、数据库表结构，随后生成了超1200行的前后端业务代码，最终实现了包含JWT认证与MongoDB数据库集成的完整应用，首次运行测试全部通过，总耗时22分钟，执行速度超过了主流闭源模型的平均水平。

企业估值Excel金融建模

在金融办公场景，我们测试了模型的专业财务建模能力，指令如下：

基于DCF现金流折现法，搭建一套初创企业估值Excel模型，同时完成多维度敏感性分析。

模型直接输出了包含完整计算公式、可视化分析图表的Excel文件，完全贴合国内金融行业的建模规范。值得一提的是，面对模糊的业务需求，模型会主动提出澄清问题，或做出合理的行业通用假设并明确标注，这一点完全匹配了企业真实工作中分析师的工作模式。

定制化智能体平台应用

MiniMax M2.5被深度集成在官方的智能体平台中，平台内置了大量预制的专项智能体，也就是官方所说的“专家”，用户可以像使用应用商店一样，直接选择对应场景的专家，快速完成专项工作。

截至模型发布，平台内用户自主创建并发布的定制化专家已经超过1万个，覆盖了办公、金融、编程、营销等多个行业场景，即使是没有开发能力的业务人员，也能快速搭建符合自身业务需求的专属AI智能体。

模型基准性能测评结果

我们通过行业通用的权威基准测试，全面评估了MiniMax M2.5的核心业务性能，测试结果也直观展现了模型的真实实力。
在编码能力专项测试SWE-Bench Verified中，模型得分达到80.2%，这个测试基于真实的开源项目业务需求，能真实反映模型解决实际开发问题的能力；在多语言跨仓库编码测试Multi-SWE-Bench中，模型以51.3%的得分位列榜首；在智能体网页导航测试BrowseComp中，模型得分76.3%，是所有开源权重模型中的第一名；在智能体编码专项测试Droid中，模型得分也达到了79.7%。

需要说明的是，在模型发布后的一周内，行业内接连发布了多款新一代闭源大模型，刷新了部分基准测试的榜单，但这也恰恰反映了当前大模型行业的迭代速度之快，而MiniMax M2.5作为开源模型，依然在开源赛道保持着领先地位。

模型获取与本地化部署方案

MiniMax M2.5提供了三种灵活的使用方式，能满足个人学习、中小企业测试、大型企业规模化部署的不同需求，同时我们也针对相关平台的国内使用情况做了适配说明。

主流大模型横向对比分析

我们将MiniMax M2.5与当前行业主流的闭源大模型做了多维度的横向对比，结果如下表所示：

从对比结果可以清晰看到，MiniMax M2.5在核心编码能力上已经与海外顶尖闭源模型持平，在多语言编码、开源开放性、推理速度、使用成本上具备显著优势，仅在通用知识与创意推理场景中，与闭源模型存在一定差距。简单来说，这款模型是开发人员与企业办公场景的“性价比首选”，是一款专精生产力场景的专家型模型。

模型行业价值与未来应用展望

在整个行业都在追逐大模型参数规模的当下，MiniMax M2.5走出了一条“产业落地优先”的差异化路线。它用开源的方式，让企业和个人开发者能以极低的成本，使用到具备顶尖编码与智能体能力的大模型，不仅打破了海外闭源模型的价格垄断，更解决了企业AI落地中的核心数据安全痛点。
对于开发人员来说，它能覆盖从代码编写、bug修复、版本审核到全栈应用开发的全流程工作，据官方披露，其企业内部80%的新增代码都由该模型生成；对于企业办公人员来说，它能完成金融建模、报告撰写、演示文稿制作等高频办公工作，大幅提升办公效率；对于企业来说，基于开源权重可以完成私有化部署，彻底解决核心数据出境的安全风险，同时极低的使用成本能让AI能力覆盖到更多业务场景。
当然，我们也要客观看到模型的不足，它在通用创意推理、跨领域综合知识储备上，与顶尖通用大模型还有一定差距，更适合生产力场景的专项应用。未来随着开源社区的二次开发与行业微调优化，模型的能力边界也将持续拓展。

总结

MiniMax M2.5用顶尖的生产力性能、开源开放的部署模式、极致亲民的使用成本，为大模型的企业级落地提供了全新的解决方案。它让我们看到，人工智能的发展，不仅有参数规模的向上突破，更有产业落地的向下深耕。对于想要落地AI能力的企业、想要提升工作效率的开发与办公人员来说，这款模型都是当下极具性价比的选择。

1 月 31 日，龙蜥×SGLang MeetUp 在北京市成功举办。在主题为“智算新生态：异构 AI 算力底座如何驱动大模型全场景落地？”的圆桌讨论中，汇聚了来自龙蜥智算联盟的多位产业与学术专家，围绕大模型推理中的核心挑战——KV Cache 管理、异构算力调度、软硬件协同与超节点架构——展开深入探讨。本次圆桌由 Mooncake 核心贡献者马腾主持，邀请了龙蜥社区智算联盟主席宋卓、摩尔线程副总裁王华、沐曦股份研究院院长李兆石、中兴通讯 Al Infra 资深架构师孙洪峰、浪潮信息系统软件研发经理 Andy Cao、中国科学技术大学特任副研究员白有辉 6 位技术专家，与现场嘉宾讨论涵盖国产 GPU 在量化与存储访问上的创新潜力、CXL 与 RDMA 网络在跨节点 KV 传输的应用、稀疏 Attention 算法的工业落地路径，以及超节点环境下分层存储体系的演进趋势，共同展望中国 AI Infra 生态的未来发展。

1、KV Cache 与显存瓶颈：硬件与算法的协同优化

摩尔线程副总裁王华指出，面对百万级上下文带来的显存压力，硬件层面可通过融合量化、反量化与计算的算子优化来降低访存开销，但物理上限决定了必须结合系统级优化（如压缩、分层存储）。他强调，硬件厂商需与社区紧密协作，共同定义和验证优化方案。

沐曦股份研究院院长李兆石则从硬件实现角度补充，量化（如 BF16 到 INT4）虽能压缩容量、提升带宽利用率，但其数值稳定性（如累加精度、微缩放、截断）高度依赖底层算子实现细节。他指出，量化需由算法牵引，通过社区反复验证才能落地。

中国科学技术大学特任副研究员白有辉分析，量化之所以被广泛采用，是因为它属于算子级改动，对系统软件影响小；而稀疏注意力（Sparse Attention）或线性注意力（Linear Attention）等方案则涉及系统级重构（如数据加载模式、内存管理），实现复杂度高，导致工业落地缓慢。他强调，稀疏注意力在解码阶段的动态选择机制（如 DeepSeek）虽有前景，但其与分布式 KV Cache 池的结合，将形成“全量 KV 在外部，热点 Top-K 在 GPU 缓存”的多级复杂系统，亟需系统层面的创新。

2、跨节点 KV Cache 传输：网络与协议的革新

中兴通讯 AI Infra 资深架构师孙洪峰分享，中兴基于定海网卡和凌云交换机，实现了对 KV Cache 的精细流控与优速带宽控制，保障了 P/D 分离场景下的低延迟传输。他透露，中兴已研发出全局 KV Cache 管理系统，并计划全面拥抱开源，向 SGLang 社区贡献技术。

浪潮信息系统软件研发经理 Andy Cao 则认为，当前互联拓扑（如 400G RDMA）已不再是瓶颈，关键在于如何利用高性能网络提升算力利用率。他提出，CXL 协议的出现为 KV Cache 传输提供了新思路，它既能作为高速内存扩展，又能作为存储接口，支持小数据、离散数据的高效传输。近日，浪潮信息已基于 Mooncake 社区开展 CXL 相关集成工作。

3、异构算力调度：统一管理与资源池化

龙蜥社区智算联盟主席宋卓强调，在包含多种 GPU 的集群中，不应盲目混用所有卡型，而应基于业务负载（计算密集型、存储密集型），如：长上下文等，制定明确的调度策略。他提出，需结合 KV Cache 池进行分级管理，并对不同算力的硬件差异能够 aware 感知，同时建立完善的容量评估，SLO 保障、资源监控与运维体系。

浪潮信息系统软件研发经理 Andy Cao 补充，浪潮信息的核心理念是“以应用为导向，以系统设计为核心”。他认同宋卓的观点，认为调度需区分不同 Workload，将计算密集型任务分配给算力强的 GPU，带宽密集型任务分配给带宽强的 GPU。同时，资源池化是关键，通过将 KV Cache 从单一节点解耦，形成共享池，可更灵活地匹配不同应用的复用需求，最大化整体资源利用率。

4、学术成果向工业实践的转化

中国科学技术大学特任副研究员白有辉认为，学术界在稀疏 KV Cache 存储方案上的研究（如动态 Top-K 选择）已相对成熟，但落地困难。主要原因在于：工业界对算法精度存疑，以及系统改造成本高。他建议，应通过开源共享研究成果，并与有真实需求的公司合作，搭建基于特定算法的 KV Cache 服务平台，是推动落地的有效路径。

5、软硬件协同：从适配到引领

摩尔线程副总裁王华指出，软硬件协同是核心，需从底层硬件（显存、带宽）到驱动、算子库、编程接口提供全面支持。他强调，优化需结合特定硬件（如 H800 与H20）的特性进行定制，形成从框架调度到底层算子的全栈优化。

沐曦股份研究院院长李兆石展望未来，认为国内生态已进入“引领创新”的阶段。他预测，随着 DeepSeek 等开源项目推动的 PD 分离等架构被国外广泛借鉴，未来国内的 AI Infra（如 Mooncake、SGLang）将反向驱动国内硬件创新，例如 GPU 直接访问对象存储、绕开 CPU 的新型存储栈等。

6、超节点场景下的KV Cache与系统演进

摩尔线程副总裁王华对 CXL 用于超节点的 KV Cache Offload 持保留态度，认为其需经 CPU 中转，延迟优势不明显，分布式存储才是更可靠的方案。他看好 CXL+DRAM+SSD 的异构分层系统。

沐曦股份研究院院长李兆石认为，超节点（如 GB200/GB300）的出现使 KV Cache 的分层存储更具经济性和必要性。浪潮信息系统软件研发经理 Andy Cao 指出，若 CXL Switch 普及，GPU 可直接通过南向互联访问 CXL 内存，有望将传统四层（HBM→Local SSD→Ethernet）简化为两层，核心在于计算能否覆盖传输延迟。

中国科学技术大学特任副研究员白有辉总结，当前 KV Cache 系统呈现 L1（HBM）、L2（CPU 内存）、L3（分布式池）的三层结构。随着上层应用（Agent）和算法（如动态稀疏）的演进，以及底层硬件（CXL、SSD）的迭代，中间层将不断丰富（如 L2.5、L4），系统将变得极为复杂。未来的关键是构建一个灵活、可扩展的系统框架，使其能包容任何硬件和算法的变革，实现“以不变应万变”。

（图/圆桌分享嘉宾）

此次圆桌讨论清晰勾勒出大模型时代 AI 基础设施的演进方向：硬件创新需与算法突破深度耦合，系统优化必须面向真实业务场景，而生态建设则依赖开源社区的协同共建。

从 KV Cache 管理到超节点架构，从异构调度到软硬件协同，每一个环节都既充满技术挑战，也蕴含弯道超车的机遇。这要求产业界建立更加灵活、可扩展的技术框架，以"以不变应万变"的系统思维，包容算法与硬件的快速迭代。龙蜥智算联盟将持续凝聚产学研力量，推动国内 AI 基础设施走向开放、高效的新阶段。

最后，感谢各位嘉宾的精彩分享，也感谢金美琴、宋卓、章津楠、潘珏君、李军等智算联盟成员对本场圆桌的组织和支持。

VMware ESXi 8.0U3i 发布 - 领先的裸机 Hypervisor

同步发布 Dell (戴尔)、HPE (慧与)、Lenovo (联想)、Inspur/IEIT SYSTEMS (浪潮)、H3C (新华三)、Cisco (思科)、Fujitsu (富士通)、Hitachi (日立)、NEC (日电)、Huawei (华为)、xFusion (超聚变) OEM 定制版

请访问原文链接：https://sysin.org/blog/vmware-esxi-8-u3/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

2026-02-24，ESXi 8.0U3i 发布，例行更新。

VMware ESXi - 领先的裸机 Hypervisor

产品简介

VMware ESXi：专门构建的裸机 Hypervisor

了解可直接安装到您的物理服务器的、可靠的裸机 Hypervisor。通过直接访问并控制底层资源，VMware ESXi 可有效地对硬件进行分区，以便整合应用并降低成本。它是业界领先的高效体系架构 (sysin)，在可靠性、性能和支持方面树立了行业标杆。

ESXi 的优势

IT 团队肩负着适应不断波动的市场趋势并满足更高客户需求的持续压力。与此同时，他们还必须延伸 IT 资源以适应日益复杂的项目。幸运的是，原名为 ESX 的 ESXi 可帮助均衡以下两种需求：提高业务成效和实现 IT 成本节约。VMware ESXi 使您能够：

• 整合硬件，以实现更高的容量利用率。
• 提升性能，以获得竞争优势。
• 通过集中管理功能精简 IT 管理。
• 降低 CAPEX 和 OPEX。
• 最大限度地减少运行 Hypervisor 所需的硬件资源，这意味着可以提高效率。

功能特性

ESXi 可将多台服务器整合到较少物理设备中，从而减少对空间、电力和 IT 管理的要求，同时提升性能。

• 占用空间小
  尽管 ESXi 占用空间仅为数百 MB，却可实现更多功能 (sysin)，同时还能最大限度地降低 Hypervisor 的安全风险。
• 可靠的性能
  适应任何规模的应用。虚拟机配置最高可达 768 个虚拟 CPU、24 TB 的 RAM 和 1024 台设备，以满足您的所有应用需求。咨询各项解决方案限制以确保您不会超过您环境的受支持配置。
• 增强的安全性
  利用强大的加密功能保护敏感的虚拟机数据。基于角色的访问可简化管理，而广泛的日志记录和审核可以更好地落实责任，还可更加轻松地进行取证分析。
• 卓越的生态系统
  获取对由硬件 OEM 供应商、技术服务合作伙伴、应用和客户机操作系统组成的广泛生态系统的支持。
• 方便用户使用的体验
  利用基于 HTML5 标准的内置现代 UI 管理日常行政操作。对于需要实现运维自动化的客户，VMware 提供 vSphere 命令行界面和便于开发人员使用、基于 REST 的 API。

产品选项

客户可以将 ESXi (ESX) 作为付费 vSphere 版本的一部分使用或与免费的 vSphere Hypervisor 版本配合使用，这样，您便可以在几分钟内轻松创建并置备虚拟机。

相关产品

vSphere

利用您的基础架构和应用实现最佳性能、可用性和效率。vSphere 是所有云环境的理想基础。

vCenter Server

扩展 ESXi 的功能，从而最大限度地降低 IT 复杂性，减少管理难题。

vSphere Hypervisor

下载能够虚拟化服务器的免费裸机 Hypervisor，以便将应用整合到更少的硬件上。

下载地址

VMware vSphere Hypervisor (ESXi) 8.0U3i

下载地址：https://sysin.org/blog/vmware-esxi-8-u3/

• 发布日期：2026-02-24
• 若干已知问题修复，详见官方文档或原文链接。
• VMware vSphere Hypervisor (ESXi ISO) image
  File Name: VMware-VMvisor-Installer-8.0U3i-25067014.x86_64.iso
• VMware vSphere Hypervisor (ESXi) Offline Bundle
  File Name: VMware-ESXi-8.0U3i-25067014-depot.zip

OEM Custom Image：

• Dell Custom Image for ESXi 8.0U3i Install CD
• HPE ProLiant Custom Image for ESXi 8.0U3i Install CD
• HPE Synergy Custom Image for ESXi 8.0U3i Install CD
• HPE Superdome Flex and Compute Scale-up family of servers Custom Image for ESXi 8.0U3i Install CD
• IEIT SYSTEMS Custom Image for ESXi 8.0U3i Install CD
• Lenovo Custom Image for ESXi 8.0U3i Install CD
• H3C Custom Image for ESXi 8.0U3i Install CD
• Cisco Custom Image for ESXi 8.0U3i Install CD
• Fujitsu Custom Image for ESXi 8.0U3i Install CD
• Hitachi Custom Image for 8.0U3i Install CD
• NEC Custom Image for VMware ESXi 8.0U3i Install CD
• Huawei Custom Image for VMware ESXi 8.0U3i Install CD
• xFusion Custom Image for VMware ESXi 8.0U3i Install CD
• 请访问：VMware ESXi 8.0U3i macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版

本站定制映像：

• VMware ESXi 8.0U3i macOS Unlocker & OEM BIOS 2.7 标准版和厂商定制版
• VMware ESXi 8.0U3i macOS Unlocker & OEM BIOS 2.7 集成网卡驱动和 NVMe 驱动 (集成驱动版)

相关产品：

• VMware ESXi 8.0U3i - 领先的裸机 Hypervisor
• VMware vCenter Server 8.0U3i - 集中管理 vSphere 环境
• VMware vSphere 8.0 Update 3i 下载 - 企业级工作负载平台

更多：VMware 产品下载汇总

真实的用户故事，最有说服力。在「用户对谈」系列里，我们希望走进不同行业、不同岗位的一线工作者，听他们讲述 AI 如何融入日常工作，解决了什么问题，改变了哪些流程。希望通过真实的使用场景和客观的效果反馈，或许能给你一些启发：AI 不是遥不可及的技术概念，而是能真正帮你节省时间、提升效率的实用工具。

这次我们对谈的嘉宾是李女士，她是一位医学研究人员。

在医学研究行业，数据不仅是数字，更是医疗质量的生命线。几万条药物信息、复杂的编码、繁琐的查重标注……这是李女士曾经的“日常大山”。

直到今年3月，一个叫“办公小浣熊”的 AI 工具闯入她的视野。从最初的抱着试一试，到如今的“深度依赖”，她甚至将它安利给了统计分析领域的泰斗。让我们来听听他的故事：

Part 1. 惊艳瞬间：3 分钟，搞定了半天的工作量

Q：还记得第一次用小浣熊时的场景吗？

李女士： 印象太深了，那简直是一个“奇迹时刻”。当时我手里有一张包含几千条诊疗数据的 Excel，要完成三个“连环动作”：

1. 精准筛选： 按照专业编码要求，把指定字母开头的数据挑出来并标红；
2. 跨表比对： 对比另一张上报表，找出漏报的数据并标黄；
3. 逻辑输出： 生成结果表。这套动作，以前我得靠 Excel 筛选、VLOOKUP 公式、手动标色……
   一套流程走下来，至少耗掉大半天，眼睛还容易看花。

Q：那小浣熊是怎么处理的？

李女士：直接把文件传上去，像聊天一样下达了指令。它只用了3分钟！导出的表格里，纵列标红、横行标黄，准确无误。那一刻我就知道，它真的懂数据，更懂我们的业务逻辑。

Part 2. 深度应用：从“繁琐搬砖”转向“专业把控”

Q：您说现在您已经成了高频用户，主要把小浣熊用在哪些场景里？

李女士： 我现在每周雷打不动要用三四次。医学行业数据把关非常严苛，我主要用它守住三个关口：

• 数据质量“守门员”： 以前写复杂的嵌套公式来剔除不合规记录，现在一句话，它就能从几万条数据里精准抓取。
• 系统“纠错员”： 我们要被动抓取数据和主动检索数据，并进行对比，找漏报。这种跨表匹配人工做最容易出错，它能做到又快又准。
• 逻辑审核“体检官”： 每条医学数据都有固定的先后逻辑。以前要一行行扫，现在它能自动把有问题的数据提前“拎”出来。

Q：量化一下，这到底解放了你多少精力？

李女士： 保守估计，每周至少节省 10 个小时。以前需要 4-5 小时的复杂上报任务，现在全流程缩短到1小时以内，效率提升了80%以上。

Part 3. 行业口碑：连统计分析大牛也“入坑”了

Q：听说你还把这个工具安利给了国内统计学的顶级专家？

李女士： 没错。我推荐给了一位国内的统计大咖。我觉得像小浣熊这种理解力，对专业统计人士也极具价值。因为它解决了数据预处理阶段最头疼的问题：低门槛、理解中文专业术语、支持连续多步操作。 一个工具好不好用，专业人士一试就心领神会。

Q：对比过其他 AI 工具吗？它的核心壁垒在哪里？

李女士： 试过很多。国外的工具理解不了特定中文语境下的行业术语；通用的对话 AI 处理大表格经常卡死。
小浣熊的优势在于 “稳”且“准”，处理几万条数据不卡顿，而且它懂中国人的表格逻辑。

Part 4. 真实反馈：它是生产力，也是期待

Q：作为“资深老友”，你对小浣熊还有哪些进化的建议？

李女士： 我有两个很具体的期待：

1. SOP 固化： 我的很多操作是固定流程。希望能一键保存成“模板”，下次传表直接套用，效率能再翻倍。
2. 数据安全： 医疗数据、金融数据都是非常敏感。希望增加“用完即焚”或“自定义保存时长”的功能，让隐私保护更极致。

Q：最后，你会怎么定义小浣熊在你工作中的角色？

李女士： 它不仅仅是一个工具，更像是我的 “数据管家”。它负责处理掉那些繁琐、重复、容易出错的“体力活”，让我能把精力真正放在需要专业判断的质控分析上。

（本文内容根据用户真实采访整理，感谢李女士的分享。）

后记

李女士的故事让我们看到，AI 并不遥远。它不是要取代专家，而是要成为专家的“外挂”。
每周节省的 10 小时，不仅是时间，更是认知带宽的释放。
当繁琐的筛选与标注交给机器，人类的智慧才能真正回归到“风险研判”与“流程优化”本身。
而她对办公小浣熊的更高要求，也是办公小浣熊不断优化的方向。
我们将持续深耕专业场景，让 AI 真正成为每一位行业专家的效率“外挂”。

「商汤小浣熊」是商汤科技推出的 AI 原生生产力体系，面向下一代办公方式而构建，包括办公小浣熊 & 代码小浣熊。在这里，软件研发、数据分析、任务规划、结果交付均由 AI 直接驱动，工作链路由 AI 重新定义。超过 300 万用户与 1000+ 企业，正与小浣熊一起推动这一场新的办公升级。欢迎关注商汤小浣熊的官方公众号、进入官方社群或访问官网获取更多信息，了解更多行业 & 场景解决方案。

近日，龙蜥社区分别召开了第 27 次技术委员会会议和第 39 次运营委员会会议。会上就 2025 年度成果做了回顾与总结，并围绕社区技术项目、2025 年度 3 大运营目标进展、联盟运作情况等进行了同步和探讨。本次会议，来自 25 家理事单位的 49 位委员及委员代表出席，技术委员会会议由浪潮信息徐国振主持，运营委员会会议由普华基础软件杨芳主持。

第 27 次技术委员会会议：ANCK 6.6 内核版本研发新机制、第七代 DMR 在 GCC 15 的支持现状等

（图/部分参会技术委员合影）

本次会议由浪潮信息徐国振主持，会议围绕星绽 Asterinas 项目、Intel 第七代 Xeon 平台 DMR 在 GCC 15 等工具链的支持现状、龙蜥在 ANCK 6.6 内核版本研发新的 LTS 同步机制等议题展开讨论。

蚂蚁技术研究院的田洪亮介绍了星绽 Asterinas 项目，旨在构建一个生产级别的国产 Rust 语言操作系统内核，以实现从发行版到内核层面的完全自主可信。该项目采用全 Rust 开发，具备内存安全优势，并提出‘框内核’架构，在保证宏内核性能的同时实现微内核级别的安全性。

Intel 的刘洪涛介绍 Intel 第七代 Xeon 平台 DMR 在 GCC 15 及相关工具链中的支持现状，并提议在 Anolis OS 23.5/23.6 中通过 multi-toolchain 机制引入对 GCC 15 工具链的支持。

阿里云谭钦云介绍了当前龙蜥社区在 ANCK 6.6 内核版本研发过程中，通过 rebase 的方式来同步内核上游 LTS 所引入的稳定性风险，以及对内核相关基础设施的影响，为此提出了新的 LTS 同步机制，通过引入内核补丁自动化同步平台，实现对上游 Linux 6.6 LTS 分支的持续监控、智能合入与质量闭环，进而提升研发效率与系统稳定性。

圆桌环节，技术委员会主席杨勇介绍龙蜥社区 1 月理事大会通过的决议信息，其中龙蜥社区支持范围从 CPU 厂商扩展至 GPU 厂商，以应对 AI 时代算力生态的发展趋势，同时也感谢 1 月各家对社区的贡献。

最后技术委员线上合影留念，本次月会圆满结束。

第 38 次运营委员会会议：年度运作报告和联盟生态进展同步

（图/部分参会运营委员）

本次会议由普华基础软件杨芳主持，主要围绕 2025 龙蜥社区年度回顾做了总结，同步了全年龙蜥社区 3 大运营目标、联盟运作情况及 2026 年社区贡献体系迭代规划等内容。

会议伊始，运营委员会主席陈绪做开场发言。他提到，龙蜥社区的组织架构与运营模式获得业界广泛认可，不仅吸引阿里云内部多个社区前来学习借鉴，也赢得了开放原子与天工开物两大开源基金会的积极支持。随后，陈绪解读了《2025 龙蜥社区年度回顾》海报，该海报也将作为年度惯例于春节假期前在社区公众号推出。他强调，龙蜥的组织活力和行业影响力有目共睹，而这一切离不开每一位成员的深度参与，这既是企业技术能力建设的助推器，也是个人在开源社区留下价值印记的宝贵机会。

接着，运营委员会副主席、联盟生态负责人金美琴围绕“2025 龙蜥年度三大运营目标”及智算联盟与安全生态的实际运作进行了整体同步。她介绍，2025 年龙蜥社区运营目标取得扎实进展，全年用户案例同比增长 58%，重点活动数量保持 50% 以上增速，超过 60% 理事完成贡献牵引目标。龙蜥社区安全联盟在软硬件安全与供应链安全工作的基础上，联盟围绕年度目标推动多款安全软件完成适配，联合输出多个行业解决方案，并成功举办多场重点活动，联盟厂商参与率达 72%，成员单位参与度显著提升。龙蜥社区智算联盟自 2025 年 8 月成立以来，各 TG 工作组工作正有序推进，各位组长围绕算子优化、性能测试及智算运维等方向分别同步，同时信通院也邀请联盟厂商积极参与人工智能相关标准的建设，智算联盟在社区生态中的身份进一步明确。

随后，运营委员蔡佳丽、胡捷和袁艳桃分别做了社区贡献体系迭代规划说明、2026 年中兴通讯和龙蜥的联合活动规划、龙蜥年度祝福等相关事宜。关于社区贡献体系，蔡佳丽提到，一是针对平台功能的优化；二是新增和调整部分提报类目；其目的是为消除提报歧义，提升规则透明度。

本次会议总结了过去一年龙蜥社区在技术创新、生态建设和开源协作等方面取得的显著成果，同时，也为新一年的发展指明方向。未来，社区将持续通过与合作伙伴开源共建，推动操作系统与 AI 基础设施的发展。

最后参会委员线上合影留念，本次月会圆满结束。感谢龙蜥社区的委员代表参与本次社区会议，本次会议内容将会继续同步在「社区品牌推广 SIG」中，欢迎关注。

—— 完 ——

云原生场景下节点/容器内存问题频发，内存一扩再扩

在云原生时代，Kubernetes（K8s）虽已成为容器编排的标准，但其复杂资源管理场景却让运维团队饱受挑战。其中，节点和容器的OOM（Out of Memory）及内存异常占用问题尤为常见，如：

• 内存持续高位占用：节点长期接近 memory pressure 阈值，导致 Kubelet 频繁触发驱逐机制，Pod 被迫迁移，业务稳定性受损。更糟糕的是，高内存压力还会影响节点调度评分，导致新 Pod 无法正常调度。
• 容器 OOM 频发：Pod 因超出 memory limits 而被 cgroup 终止，表现为OOMKilled 状态，导致业务频繁重启，难以定位真正原因。
• 应用内存泄漏隐性增长：应用存在内存泄漏时，短期压测可能完全正常，但运行数天甚至数周后，内存占用逐步攀升直至触发 OOM。这类问题隐蔽性极强，往往在生产环境才暴露。
• 资源配额设置失衡： requests/limits 配置不合理是常见问题——配置过低导致频繁 OOM 驱逐，配置过高则造成资源浪费和调度效率下降。而"合理值"的判断高度依赖业务特征和历史数据。

问题排查困难

但是云原生内存问题排查起来又遇到重重阻碍，通常需要多方专业人员协助投入，耗时多天才能定位定位根因找到合适解决方案。

应运而生：ACK AI助手与 ACK&SysOM MCP

面对上述痛点，业界一直在探索更智能的解决方案。阿里云容器服务团队推出的计算 AI 助手（ 也称 ACK AI 助手）、ACK MCP 工具与阿里云基础软件团队推出 SysOM MCP 工具集正是为此而生；通过将 SysOM 专业系统诊断能力以 MCP形式深度集成至 ACK AI 助手，从而一句话闭环云原生内存问题。

ACK AI 助手 + ACK MCP：懂云原生业务场景的「智能 SRE」

ACK AI 助手是构建在阿里云容器服务 ACK 之上的智能运维助手。

容器服务 AI 助手深度融合操作系统能力，打造覆盖容器全生命周期（Day0~Day2）的智能运维体验。基于“卓越架构”理念，助手在稳定性、成本、安全与性能等维度提供最佳实践指导。

其核心能力包括：
智能诊断——通过环境全感知、多轮反问补充上下文，并协同多个专家 Agent 会诊，结合观测数据与领域经验，实现从异常发现、根因定位到一键修复的闭环；
集群优化——自动完成成本、安全、架构及弹性配置等多维度分析，生成可执行优化方案并预测效果；
智能健康检查——对集群、节点、Workload、网络、存储等全方位进行动态异常检测，融合大模型与算法，超越传统阈值告警；
同时支持复杂场景下的全自动 AIOps 流程，未来还将实现应用创建与资源管理的自动化，真正让容器服务更智能、高效、自愈。

ACK AI助手也同样提供开源项目 ack-mcp-server tool集合 https://github.com/aliyun/alibabacloud-ack-mcp-server/，以提供用户在自己的AI Agent上构建阿里云容器服务 ACK、Kubernetes 领域的 SRE Agent。

SysOM MCP：深度操作系统诊断的「专业医生」

SysOM MCP 项目内置超过 20 个操作系统控制台生产级节点/容器诊断工具：

• 内存分析：内存全景诊断、应用内存诊断、OOM 内存诊断
• IO 诊断：IO 一键诊断、IO 流量分析诊断
• 网络排查：网络丢包诊断、网络抖动诊断
• 调度诊断：系统负载诊断、调度抖动诊断
• 磁盘诊断：磁盘分析诊断
• 宕机诊断：宕机诊断（dmesg 分析）、宕机诊断（vmcore 深入分析）

对于内存问题，SysOM 内存工具覆盖从内核内存到应用内存的全方位内存分析，涵盖 10+ 内存异常场景：

强强联合：云原生内存问题诊断闭环

为什么需要结合？

看起来我们已经有了两个强大的工具 -- 一个懂业务，一个懂内核。但在针对本文聚焦的云原生内存问题上，它们各自都存在一些局限性。如日常定位云原生内存相关问题时，通常也需要结合云原生和操作系统的相关专业知识来排查，这也正是我们需要将它们结合起来的原因。

数据维度全面打通

通过 ACK MCP 和 SysOM MCP 工具链，ACK AI 助手实现：

元数据自动关联：一次提问，AI 自动关联 Namespace → Deployment/Daemonset → Pod → Node → 实例规格，将 SysOM 的进程数据与 K8s 对象一一对应。SysOM 告诉你“是什么”（内核层面的内存异常根因结论），ACK MCP 告诉你“为什么”（K8s 配置上下文），两者结合才能形成完整的根因定位。

日志事件指标融合：OOM 发生时自动拉取容器日志、K8s Events、Prometheus 指标、审计日志等多维度数据。SysOM 提供“当前状态”（内存分布快照），Prometheus 提供“历史趋势”（何时开始异常），审计日志提供“变更事件”（是否与发布相关），三者交叉比对才能区分“流量突发”还是“版本缺陷”。

具体问题 CASE

CASE 1: kubectl top node 内存占用和节点监控不一致
客户在日常巡检中发现一个让人困惑的现象：kubectl top node 显示节点内存使用率仅 60%，但云监控控制台显示该节点内存占用已达 85%，两者差异超过 20%。这种数据不一致导致团队无法准确判断节点的真实负载状态，也无法确定是否需要扩容。

传统解决方案：

找到相关同学，获取具体指标的计算方式，检查计算差异，获取差异部分具体内存占用，得出数据不一致根因。通过 ACK AI 助手：

CASE 2: Java 应用 pod 频繁 OOMKilled

问题场景：

一个 netty 服务在生产环境运行一段时间后，开始频繁出现 OOMKilled 重启。容器配置了 4Gi 内存 limit，JVM 堆内存设置为 -Xmx3g，理论上应该足够。但 Pod 仍然每隔几小时就被 OOM 终止一次，业务方抱怨服务不稳定。

传统解决方案：

找到相关应用同学，通过各种各样 Java 问题排查工具，定位是哪部分内存使用不当导致；多方讨论如何改变设置或参数缓解问题。

通过 ACK AI 助手：

CASE 3: Emptydir 使用不当导致 Pod OOMKilled

问题场景：

一个数据处理服务的 Pod 在运行过程中突然被 OOMKilled，但应用日志中没有任何内存异常的迹象，应用本身的内存占用也远低于 limits。用户百思不得其解：明明应用没用多少内存，为什么容器还是被 OOM 了？

传统解决方案：

通过容器监控无法定位是哪部分内存占用导致 OOM，深入排查需要 SSH 登录节点、定位 cgroup 路径、手动解析memory.stat ，再与 Pod 配置交叉比对才能定位根因。整个过程涉及多系统切换、依赖内核经验，耗时长且门槛高。

通过 ACK AI 助手：

总结

通过 ACK AI 助手 + SysOM & ACK MCP 的组合，云原生内存问题从"凭经验"变为"有系统、有规则、有工具"的标准化闭环能力。

这不仅仅是两个工具的简单叠加，而是 "云原生视角"与"操作系统视角"的深度融合——让运维人员只需要一句话，就能获得从业务层到内核层的完整诊断报告和可执行建议。

产品链接：

ACK AI 助手功能说明文档：
https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/...

ACK MCP 官方开源 tool 工具集：
🌟 GitHub 地址：
https://github.com/aliyun/alibabacloud-ack-mcp-server/blob/master/README.md

SysOM MCP
🌟 GitHub 地址：https://github.com/alibaba/sysom_mcp

操作系统控制台：
https://help.aliyun.com/zh/alinux/product-overview/what-is-th...

联系我们

若想使用更全面的 SysOM 功能，请登录阿里云操作系统控制台体验，地址：https://alinux.console.aliyun.com/

您在使用操作系统控制台的过程中，有任何疑问和建议，可以搜索群号：94405014449 加入钉钉群反馈，欢迎大家扫码加入交流。

基于 YOLOv8 面向水环境监测的藻类细胞智能识别系统 [目标检测完整源码]（YOLOv8 + PyQt5 工程实践）

一、研究背景与问题引入

在水环境生态监测与藻类研究中，藻类细胞的种类与数量变化往往是评估水体富营养化、污染程度及生态健康状态的重要依据。然而，传统依赖人工显微观察与手动统计的方法，不仅效率低下，而且对操作者的专业经验依赖较强，难以满足大规模、连续化监测的实际需求。

随着深度学习技术在计算机视觉领域的快速成熟，基于卷积神经网络的目标检测算法逐渐成为生物显微图像分析的重要技术手段。其中，YOLO 系列模型凭借端到端结构和优秀的实时性能，在实时检测场景中展现出显著优势。

基于此，本文介绍一套面向藻类细胞检测的智能识别系统，该系统以 YOLOv8 为核心检测模型，并结合 PyQt5 构建可视化操作界面，实现从模型训练到实际应用部署的完整闭环。

源码下载与效果演示

哔哩哔哩视频下方观看：
https://www.bilibili.com/video/BV11i89zpEHc/

包含：

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址（含标注脚本

二、系统整体设计思路

本系统遵循“算法与应用解耦”的设计原则，整体可划分为四个功能层级：

1. 数据层：藻类显微图像数据集及 YOLO 标注文件
2. 模型层：YOLOv8 目标检测网络
3. 推理层：基于 PyTorch 的模型加载与预测接口
4. 交互层：PyQt5 图形化用户界面

这种分层结构既保证了算法模块的独立性，也为后续功能扩展（如更换模型、增加类别）提供了良好的工程基础。

三、藻类数据集构建与类别设置

3.1 数据集类别说明

系统当前支持 6 种常见藻类细胞的检测识别，覆盖多种典型水环境监测对象，包括：

• 扁藻属
• 小球藻属
• 盐藻
• 无狂藻属
• 红球藻属
• 血球藻属

每一类藻类在形态结构、尺寸分布和纹理特征上均存在差异，这对检测模型的特征提取能力提出了较高要求。

3.2 数据组织与标注规范

数据集采用标准 YOLO 格式进行组织，图像与标签一一对应。标签文件中使用归一化后的中心点坐标与宽高信息，确保模型在不同分辨率下具备良好的泛化能力。

四、YOLOv8 模型训练与性能分析

4.1 模型选择与训练流程

在模型选型上，系统采用 YOLOv8 Detection 分支作为基础网络。该模型具备 Anchor-Free 架构，减少了锚框设计对检测效果的影响，尤其适合尺度变化较大的藻类细胞目标。

完整训练流程包括：

• 数据加载与在线增强
• 多尺度特征提取
• 分类与定位联合优化
• 动态损失权重调整

训练完成后，系统会自动保存最优权重文件，供后续推理与部署使用。

4.2 训练结果评估指标

模型性能主要通过以下指标进行评估：

• Precision / Recall
• mAP@0.5
• 分类混淆矩阵

在实验数据集上，模型在主要类别上均取得较高的检测准确率，能够满足实际应用对稳定性与可靠性的要求。

五、模型推理与检测结果输出

训练完成的模型可通过 Python 接口快速完成推理任务。推理结果不仅包含目标的类别与置信度，还提供精确的边界框坐标信息，可用于后续统计分析或二次处理。

在系统实现中，推理模块与界面模块解耦，既支持 GUI 调用，也可作为独立脚本运行，方便在服务器或边缘设备上部署。

六、PyQt5 可视化检测系统实现

6.1 图形界面功能概述

为提升系统易用性，项目基于 PyQt5 构建了完整的桌面端应用，主要功能包括：

• 单张藻类图像检测
• 文件夹级批量检测
• 本地视频逐帧检测
• 摄像头实时检测

所有操作均通过按钮触发，无需任何命令行操作，适合科研教学与现场演示使用。

6.2 工程化应用优势

相比纯脚本形式，图形化系统在实际使用中具有明显优势：

• 操作直观，降低学习成本
• 结果可视化程度高
• 易于集成到现有实验流程
• 便于非算法背景人员使用

这使得深度学习模型真正从“算法原型”转化为“可用工具”。

七、应用场景与扩展方向

7.1 典型应用场景

• 水体藻类组成快速分析
• 环境监测与水质评估
• 生物实验教学与演示
• 藻类图像数据自动标注

7.2 可拓展研究方向

在现有系统基础上，还可进一步开展以下工作：

• 增加更多藻类类别，提升生态覆盖范围
• 引入实例分割以获取更精确的细胞轮廓
• 与时间序列数据结合，分析藻类变化趋势
• 部署至边缘设备，实现在线水体监测

八、结语

本文介绍了一套基于 YOLOv8 与 PyQt5 的藻类细胞智能检测系统，从数据集构建、模型训练到图形化部署，完整展示了深度学习技术在生物图像识别领域的工程化落地过程。实践表明，该系统在检测精度、实时性能与易用性方面均具备良好表现，能够有效提升藻类识别的自动化水平。

对于从事环境监测、生物信息分析或计算机视觉应用开发的研究者与工程人员而言，该项目提供了一个具有参考价值的技术范例，也为后续更复杂的智能水环境分析系统奠定了基础。

一、核心结论
在2025至2026年的行业背景下，关于先上ERP（企业资源计划）还是MES（制造执行系统），并没有绝对的标准答案。决策的关键在于评估企业自身的“数字体质”和核心痛点。正确的路径通常是基于企业现状量身定制的战略规划，而非简单的二选一。

二、ERP与MES的核心定位差异

1. ERP（企业资源计划）
   定位：企业级的经营管理平台，主要服务于管理层。
   核心功能：涵盖财务核算、采购管理、库存控制、销售订单处理及人力资源管理等。
   数据粒度：通常以“天”或“周”为单位进行数据统计和分析。
   关注重点：资源的整体优化、财务业务的闭环以及供应链的协同。
2. MES（制造执行系统）
   定位：车间级的生产执行系统，主要服务于执行层。
   核心功能：负责生产过程的实时监控、工序详细管控、质量数据采集与追溯。
   数据粒度：精确到“分钟”甚至“秒”级别的实时数据。
   关注重点：现场执行的透明度、设备综合效率（OEE）的提升以及实时数据的采集。

三、基于企业痛点的选型建议

情形A：建议优先实施ERP
如果您的企业面临以下问题，应优先考虑ERP：
订单管理、采购流程、库存数据及成本核算混乱不清。
销售、计划、采购、仓储等各部门之间信息割裂，形成数据孤岛。
急需整合全公司资源，提升财务透明度和管理规范性。
核心诉求是提高供应链协同能力和市场响应速度。
适用对象：管理基础相对薄弱、业务流程尚不规范的中小型企业。

情形B：建议优先实施MES
如果您的企业面临以下挑战，应优先考虑万界星空MES：
生产工艺极其复杂，涉及众多工序，且难以人工管控。
产品质量波动大，质量问题频发，缺乏有效的过程控制。
设备综合效率（OEE）偏低，设备停机原因不明。
对批次追溯有严格要求（如医药、食品、汽车零部件等行业）。
生产进度不透明，现场管理处于“黑箱”状态。
适用对象：离散制造、流程制造等生产复杂度高、对现场管控要求严格的企业。

四、2025年行业主流实施路径

根据《中国制造业数字化转型白皮书2024》及多家专业机构的观点，推荐的标准化路径为：“ERP先行 -> MES跟进 -> 系统集成”。
ERP打基础：首先通过ERP实现主数据、计划体系和财务业务的一体化，建立统一的数据标准和业务规范。
MES做深化：当基础管理规范后，针对生产复杂度的提升，引入MES进行精细化的工序级管控。
最终协同：实现ERP与MES的无缝集成，形成从经营层到执行层的端到端数据闭环。

五、决策诊断框架（五步法）

企业在做决定前，建议按以下步骤进行自我诊断：
诊断管理瓶颈：明确当前最严重的问题是出在经营层（如账实不符）还是执行层（如良品率低）。
评估生产复杂度：判断工序是否复杂，是否有严格的追溯要求。
梳理数据基础：检查主数据是否规范，BOM（物料清单）准确率是否达标。
盘点预算与资源：评估资金、人力和时间是否足以支撑大型系统的实施。
规划集成路径：提前规划未来是否需要ERP与MES的协同，避免形成新的孤岛。

六、常见误区与避坑指南

误区一：认为ERP万能，可以解决所有生产现场问题。

正解：ERP侧重资源计划，无法替代MES对现场的实时管控，两者需协同使用。

误区二：只上MES，忽略上游财务和采购流程。

正解：若上游业务流程未理顺，MES采集的数据将缺乏准确的计划依据，导致系统失效。

误区三：忽视PLM（产品生命周期管理）的作用。

正解：研发数据是源头，对于研发驱动型企业，理想顺序应为PLM -> ERP -> MES。

误区四：盲目追求大而全的系统。

正解：应根据企业实际规模和发展阶段，选择适度超前的解决方案。

七、针对不同企业类型的建议

小型制造企业：推荐ERP优先。性价比高，能快速规范管理流程。
中大型离散制造企业：推荐ERP先行，随后实施MES。分步实施可降低风险，确保数据连贯性。
流程行业（如化工、制药）：推荐MES优先。由于合规性和追溯性要求极高，现场管控是生存底线。
研发驱动型企业：推荐PLM -> ERP -> MES的顺序。确保设计数据准确传递至生产和经营环节。

总结：正确的决策不是简单的单选题，而是需要结合企业规模、行业特性及当前最迫切的管理痛点进行的战略规划。建议在启动项目前，先进行专业的数字化诊断，有需要可以私信免费提供解决方案。

毫无拦截，就这么水灵灵地显示出来了

说实话，我第一眼看到的时候，是愣住的。

不是“哎哟有点问题”，而是那种——
它怎么敢的？

就一段提示词，没有绕、没有藏、没有加什么奇怪的隐喻，
结果 违规图片直接生成，完整显示，全程无提示、无拦截、无打码。

真的就是——
输入提示词→ 出图 → 摆在你面前。

Big 胆

那一刻我脑子里只有四个字：
你是真敢啊。

要知道，这不是那种“边缘擦线、你非要说也能圆回来”的情况，
而是正常人一眼就能判断：这不该被生成，更不该被展示。

但它就这么出现了。
干干净净，明明白白，毫不遮掩。

不过，F得也挺快

事情发酵之后，有些提示词很快就被F掉了。

再试同样的描述，系统已经开始拦截，
要么直接拒绝生成，要么给你一个“内容不符合规范”的提示。

你们猜？

这次“翻车”，到底是什么原因？

• 是审核规则没跟上？
• 是图片生成拦截策略没兜住？
• 还是……
  有意放松边界，先拉一波热度再说？

我不敢下结论，但你要说完全是巧合，
说实话，也挺难让人信的。

毕竟现在的 AI 产品，尤其是出自 阿里云 这种体量的平台，
内容安全几乎是第一优先级。

这种“零拦截直出”的情况，
放在今天，真的不太常见。

总结

说到底，AI 翻车从来不只是“好不好笑”的问题。

它更像是在提醒我们一件事：

**模型再强，也不能裸奔；
创作再自由，也必须有边界。**

否则今天是“水灵灵生成违规图片”，
明天就可能是更大的坑。

前言

Linux 系统突发宕机是运维人员和开发者经常面临的难题。面对复杂的内核日志和内存转储文件，传统分析方式往往耗时费力且需要深厚的内核知识。本文将介绍阿里云操作系统控制台的宕机智能诊断功能，并展示其如何通过 AI 技术简化宕机分析流程。

传统宕机分析的"三座大山"

第一座大山：日志分析如同"看天书"

服务器宕机后，运维人员首先需要查看 dmesg 日志。然而，内核日志往往包含大量难以理解的信息：

[ 69518574.393036] Code: e8 38 ac e8 88 0b ff ff 0f 0b 48 c7 c7 d0 e8 38 ac e8 7a 0b ff ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 90 e8 38 ac e8 66 0b ff ff <0f> 0b 48 89 fe 48 c7 c7 58 e8 38 ac e8 55 0b ff ff 0f 0b 48 89 ee
[ 69518574.393070] RSP: 0018:ffffb0d3c0a3bb98 EFLAGS: 00010282
[ 69518574.393085] RAX: 0000000000000054 RBX: ffff9fbe07b158c0 RCX: 0000000000000000
[ 69518574.394079] RDX: ffff9fbeddf703e0 RSI: ffff9fbeddf5fb40 RDI: ffff9fbeddf5fb40
Kernel panic - not syncing: Fatal exception 

这些信息对于普通运维人员来说难以理解，而且真正的问题往往隐藏在数千行日志中，需要花费大量时间排查。

传统的日志分析不仅需要深厚的技术背景，还要对内核各个子系统有深入理解。例如，hardlockup 错误需要了解 CPU 调度、中断处理、自旋锁等机制；hungtask 问题需要熟悉进程状态转换、等待队列、资源竞争等概念。

第二座大山：VMCORE 分析耗时又费力

对于复杂问题，通常需要获取 VMCORE 文件进行深入分析。完整的 VMCORE 分析流程包括：
1.首先得加载 VMCORE 文件到调试工具
2.然后执行各种复杂的调试命令
3.手动分析各种输出信息
4.最后尝试拼凑出问题的全貌

整个过程可能需要数小时甚至数天，并且对分析人员的内核知识要求较高。VMCORE 分析涉及的技术层面非常广泛，包括内存布局分析、进程状态重建、内核数据结构解析等。例如，分析内存错误需要检查页面分配状态、分析内存损坏问题；排查死锁问题则需要重建锁依赖关系、分析调用栈行为。

第三座大山：找补丁如同"寻宝游戏"

定位到问题后，还需要找到对应的修复补丁。Linux 内核的 Git 仓库包含三十多年演进历史，累计超过百万次 commit，涉及上万名开发者。从如此庞大的代码库中找到与特定问题相关的修复，需要对内核演化历史有深入了解。人工筛选不仅效率低下，而且容易遗漏关键信息。

这三大挑战使得传统宕机分析流程复杂且耗时。阿里云操作系统控制台的宕机智能诊断功能旨在解决这些问题。

重磅推荐：阿里云操作系统控制台宕机智能诊断

阿里云操作系统控制台（简称操作系统控制台）是一站式操作系统运维管理平台，提供了内存、I/O、网络、内核崩溃等强大的系统诊断能力，SysOM 是操作系统控制台的运维组件。但这些功能通常需要用户登录控制台，并具备一定的运维经验才能有效使用。

什么是宕机智能诊断？

宕机智能诊断是阿里云操作系统控制台提供的系统场景诊断功能，基于大模型技术，融合了内核调试技术和丰富的故障案例，能够自动完成从日志分析到问题定位，再到补丁推荐的全流程，让原本复杂的宕机分析变得简单高效。

阿里云操作系统控制地址链接：https://alinux.console.aliyun.com/

三大核心能力，解决你的燃眉之急

1. 智能日志解析，告别"天书"

再也不用对着复杂的内核日志发愁了！宕机智能诊断的日志解析功能能自动提取关键信息，为后续 AI 分析提供结构化的数据基础。

核心能力：

• 结构化信息提取：自动从日志中提取版本号、崩溃标题、进程名、函数名、RIP 寄存器值、CPU 编号、加载模块等关键字段。
• 调用栈分层解析：识别并分离 NMI 栈、IRQ 栈、任务栈三层调用关系，过滤无效函数，提取 top-3关键函数调用链。
• 故障类型识别：支持 hardlockup、hungtask、memory_error、softlockup、hardware_error 等主流内核故障类型的快速判定。
• 错误日志聚合：自动按时间戳排序错误日志，过滤冗余调用栈信息，保留关键诊断线索。

实际效果：传统方式需要人工从数千行日志中逐行查找关键信息，而系统可以在秒级完成日志解析和结构化提取，将非结构化的 dmesg 日志转化为结构化的特征集合，为后续的 AI 诊断提供清晰的数据输入。

2. 专项诊断，精准打击

系统针对不同类型的内核问题设计了专属的诊断能力，深度集成 drgn 内核调试器，能够直接访问 VMCORE 中的内核数据结构，结合 AI 推理实现智能分析：

• Hardlockup 诊断：采用图遍历算法构建锁依赖图，自动检测循环等待和死锁场景，输出清晰的锁等待路径（如：CPU1→lockA→CPU2→lockB→CPU3→lockC→CPU1 形成死锁环路）。
• Hungtask 诊断：实现链式追踪算法，从 D 状态进程开始逐级分析等待链，定位终端阻塞点（Terminal Holder），给出完整的资源等待路径
• Memory Error 诊断：识别 use-after-free、空指针解引用、野指针等典型内存错误类型，追踪内存分配和释放路径
• Softlockup诊断：分析调度延迟、CPU 占用模式，检测软锁和响应超时问题

每种诊断都遵循"算法提取数据骨架 + AI 补全推理逻辑"的模式，既保证分析的准确性，又实现诊断的智能化。

3. 智能补丁匹配，一步到位

宕机智能诊断采用了混合向量检索技术来进行补丁搜索。系统首先使用 text-embedding-v4 模型将问题描述转换为 1536 维的稠密向量和稀疏向量，在面向 Linux 内核历史提交构建的向量数据库中进行语义相似度检索。

检索过程分为两个阶段：

• 第一阶段-向量检索：通过向量数据库快速从海量 commit 中召回 top-k 个最相关的候选补丁。
• 第二阶段-智能排序：利用大模型技术对每个候选补丁进行深度分析，评估其与当前问题的相关性（1-10分），并给出详细的相关性原因说明。

系统支持按内核版本进行过滤（如筛选 v5.10 及以上版本的补丁），帮助用户更精准地检索到适用于特定版本的修复方案。最终返回多个最相关的补丁，每个补丁都包含 commit ID、摘要、相关性评分和推荐理由。

实际效果：Hardlockup 死锁问题的智能诊断

以一个真实的生产环境 Hardlockup 故障为例，服务器突发系统无响应并崩溃。运维人员通过控制台发起诊断后，系统在 5 分钟内生成了完整的诊断报告。

报告包含了以下关键信息：

• 故障类型识别：自动判定为 Hardlockup 死锁问题。
• 死锁链路分析：识别出三方 CPU 间的循环等待关系，包括各 CPU 持有和等待的锁。
• 根因定位：指出导致死锁的关键代码路径和函数调用。
• 修复建议：提供 4 条针对性的缓解措施。
• 补丁推荐：从 Linux 内核百万级提交中检索出 3 个相关补丁，按相关性排序并说明推荐理由。

本次诊断中，系统首推的补丁正是实际修复该问题的补丁，其余 2 个推荐补丁也与故障症状高度匹配。对于这种复杂的多方死锁场景，传统人工分析通常需要数小时甚至数天，而宕机智能诊断在几分钟内完成了从问题分析到补丁推荐的全流程，大大降低了故障处理门槛和运维成本。

快速上手宕机智能诊断

宕机智能诊断功能支持使用 .rpm 包格式的主流 Linux 发行版，包括 Alibaba Cloud Linux、CentOS、Anolis OS、Rocky Linux、AlmaLinux 等。对于 Alibaba Cloud Linux、CentOS、Anolis OS 等发行版，系统会自动获取 debuginfo，降低使用成本。

推荐方式：通过 SysOM MCP 使用（AI 助手集成）

SysOM MCP阿里云开源的系统诊断工具集，基于 Model Context Protocol 协议，将宕机智能诊断能力封装为标准化的 MCP 工具，可以通过 AI 助手（如 qwen-code）使用自然语言直接进行宕机诊断。

🔗 项目地址：https://github.com/alibaba/sysom_mcp

请参考项目文档完成安装和配置。配置完成后，在 AI 助手中直接使用自然语言发起诊断：

示例 1：调用宕机智能诊断

请帮我分析一个宕机问题，vmcore 下载链接：https://path/to/your/vmcore

说明：
· API 接受的是 HTTP/HTTPS 下载链接，确保下载链接具有适当的访问权限，便于诊断服务下载和分析。
· 对于 Rocky Linux、AlmaLinux 等其他发行版，需要额外提供 debuginfo 和 debuginfo-common 的下载链接。暂不支持使用 .deb 包格式的发行版（如 Ubuntu、Debian 等），该功能正在开发中。

示例 2：查询历史诊断任务

查看我最近 7 天的宕机诊断记录，并返回上一次的诊断结果

AI 助手会自动调用相应的 MCP 工具，并将诊断结果以易读的方式呈现。

高阶方式：直接调用 OpenAPI 接口

对于需要集成到自动化运维系统或自定义工作流的场景，可以直接调用 OpenAPI 接口。详细使用方式请参考操作系统控制台 OpenAPI 文档。

操作系统控制台 OpenAPI 文档链接：
https://next.api.aliyun.com/api/SysOM/2023-12-30/CreateVmcore...

总结

Linux 宕机分析不再是少数专家的专利！阿里云操作系统控制台的宕机智能诊断功能通过 AI 技术与专业内核调试工具的深度融合，让每一位运维和开发都能轻松应对复杂的系统问题。

在这个追求高效运维的时代，拥有宕机智能诊断这样的功能，无疑会让你的工作事半功倍。无论是深夜排障还是日常维护，都能从容应对，再也不用为复杂的内核问题而头疼了。

如果你也想告别 Linux 宕机分析的烦恼，不妨试试阿里云操作系统控制台的宕机智能诊断功能，让 AI 成为你的得力助手！

联系我们

若想使用更全面的 SysOM 功能，请登录阿里云操作系统控制台体验，地址：

https://alinux.console.aliyun.com/

您在使用操作系统控制台的过程中，有任何疑问和建议，可以搜索群号：94405014449 加入钉钉群反馈，欢迎大家扫码加入交流。

背景

随着云端业务规模的持续扩大，AI 训练数据、实时日志与多媒体资料等数据量呈现指数级增长，云存储因此逐渐成为主流选择，同时也带来了 I/O 请求量的快速上升。在共享式的多租户架构中，多个租户共同使用底层存储资源，高并发访问极易引发 I/O 资源争抢与性能瓶颈。此外，混合云与多云部署日益普及，数据在多个云环境之间频繁流动，而不同云服务商在存储策略与监控机制上的不一致，使得 I/O 类故障的定位与追溯变得更加复杂。为提升此类问题的处理效率，阿里云云监控 2.0 结合 SysOM 智能诊断功能围绕常见的 I/O 异常场景，构建了一套覆盖“异常检测—根因分析—修复建议”全链路的 I/O 一键诊断功能。

业务痛点解析

痛点一：用户难以准确判断 IO 异常类型

大多数用户对 IO 问题的具体类型缺乏清晰认知，例如往往搞不清当前是 IO 延迟升高、IO 吞吐被打满，还是其它类型的异常，导致很难主动选用对应的排障工具和方法，只能依靠运维专家介入排查，整体诊断效率偏低，人力投入也随之增加。IO 一键诊断聚焦 IO 延时偏高、流量异常、iowait 居高不下等高频场景，自动捕捉 IO 子系统的异常特征，帮助用户快速完成问题类型的判定。

痛点二：异常发生瞬间难以“抓现场”，取证不充分

传统监控系统通常只采集操作系统层面的通用 IO 指标，比如 await、util、tps、bps 等，并以指标突变作为告警条件。然而，当指标被检测到异常时，真实问题往往已经发生甚至结束，此时再想获取更细致的采样和上下文信息，往往为时已晚，关键线索已经流失，难以形成完整的诊断证据链。要做到有效定位，就必须尽可能在异常刚出现或仍在持续时就触发针对性采集，因此，快速识别并及时行动，是获取最佳诊断数据的关键。

痛点三：指标体系割裂，监控数据与诊断结论之间缺乏直连

现有监控往往仅提供一组相互独立的指标，彼此缺乏联动，也没有与具体 IO 故障类型建立直观映射。以 util（磁盘繁忙度）偏高为例，实际分析时还需参考 await 等多项指标，并结合设备的理论 iops、bps 上限进行综合判断。即便勉强推断出问题类型，接下来仍离不开对各种诊断工具的经验性操作，包括如何按照指标数值选择合适的采样区间、参数配置等。IO 一键诊断的设计目标，就是将这一串复杂的关联分析与工具选型过程封装在系统内部，对用户直接呈现整理好的诊断报告和结论。

解决方案

架构介绍

在阿里云云监控 2.0 中，SysOM 管控模块原本就支持对 IO 延迟异常、IO 量异常以及 iowait 高等问题开展诊断。不过，大部分客户并不希望在业务环境上长时间运行高频诊断程序，以免对生产带来干扰。因此，IO 一键诊断采用了“监控先行、按需抓取”的架构：在用户指定的诊断时间段内，系统定期读取 IO 监控指标，用于异常识别与问题圈定，一旦满足条件，再触发具体的子诊断工具进行深度分析并输出报告，构成一个从发现到定位的闭环流程。

考虑到不同业务类型对 IO 行为和性能阈值的容忍度不尽相同，如果强行规定统一的固定阈值，势必会导致误报大量增加或严重漏报。因此，IO 一键诊断引入“动态阈值”机制进行异常识别，其总体处理链路可以概括为：

• 指标采集：定期从系统中抓取关键 IO 指标，如 await、util、tps、iops、qu-size、iowait 等。
• 异常检测：当采集到的指标突破动态阈值，就将其标记为潜在异常。动态阈值的计算方法是整个检测环节的核心，后文会展开说明。
• 自动诊断触发：依据异常的指标类型与特征，自动选择合适的诊断工具，并设置触发频率限制，避免频繁调用。
• 结果处理与展示：对诊断输出进行归纳和可视化呈现，为用户提供导致问题的根本原因以及可执行的优化建议。

实现原理

指标采集机制
当用户在控制台启动 IO 一键诊断后，系统会按配置好的时间间隔（cycle 毫秒）循环读取 iowait、iops、bps、qusize、await、util 等一系列 IO 指标，并在每个周期对最新采集的数据做异常检测判断。

动态阈值计算
为了能在秒级甚至更细粒度下捕获 IO 突发、短时抖动等异常，必须将各类单一 IO 指标联动起来，从整体上刻画 IO 子系统的“正常波动区间”。动态阈值就是用来界定这一“正常区间”和“异常尖峰”的边界。其计算过程主要分为三层：基础阈值、补偿阈值和最小静态阈值。

基础阈值：刻画整体波动幅度从时间序列的角度看，IO 指标在大多数时刻处于平稳运行状态，曲线起伏较小；当出现异常负载或者突发流量时，曲线会突然出现明显偏离均值的峰值。因此，首要任务是利用基础阈值，找出这些显著高于日常波动的“尖峰”。

实现策略是：使用一个滑动时间窗口持续观察数据点，在每个窗口中计算所有点相对于窗口平均值的“最大偏离量”，把这个偏离量记为该窗口的“瞬时波动值”；随后对连续多个窗口的“瞬时波动值”求平均，形成动态更新的“基础阈值”。随着新数据不断进入，该阈值也会自适应地调整，始终反映 IO 指标近期的真实波动特征。

补偿阈值：削弱基础阈值快速下降带来的误报基础阈值曲线（如示意图中的黄色线条）虽然能够反映指标的总体波动情况，但在系统处于稳定期时，IO 指标通常只在很窄的一段区间内轻微波动，此时基础阈值可能随波动减弱而快速下降，容易让一些微小的正常抖动被误判为异常。因此，需要额外引入一个“补偿阈值”，叠加在基础阈值之上，对其下降速度进行一定缓冲，从而抑制误报。

具体逻辑是：当系统监测到基础阈值在一段时间内持续走低，可以认为当前进入了相对“安静”的常态阶段。此时先过滤明显噪声点，再在剩余的稳定数据里计算一个“常稳态补偿值”，以刻画这类稳定状态下的细小波动。补偿值尚未收敛前，先用当前窗口内出现过的最大基础阈值暂时代替，并在每个新窗口开始时重新计算。一旦基础阈值停止下降或开始回升，就意味着系统波动模式发生了变化，此时补偿机制会被重置，重新进入更宏观的观察期。

最小阈值：兜底的静态门槛
最小静态阈值可以理解为预先设定的“绝对下限”，是业务方能接受的最低告警基线。最终用于判定异常的阈值，是“最小静态阈值”和“动态调整阈值（基础阈值 + 补偿值）”之间的较大者。只有当指标既超过了日常波动的正常范围，又突破了业务底线时，才真正被视为异常事件。

此外，如果指标本身已经明显高于“最小静态阈值”，则无需再额外叠加常态补偿值，此时仅以基础阈值作为判断依据即可，将分析重点聚焦在更显著的异常波动上。

异常识别策略

在运行时，一旦采集到的某项 IO 指标值高于其对应的动态阈值，即可认为存在异常风险。虽然不同指标（如 iowait、util、iops 等）的判定逻辑略有差异，但整体遵从以下共通规则：

• 确定告警基线：为每一类指标定义一条“警戒线”，其数值为“最小静态阈值”和“动态阈值”中的最大值，既考虑业务底线，也考虑历史波动范围。
• 决定是否触发诊断：当监控值超过警戒线，同时满足一定的监测条件（如持续时间、触发次数等），就可以启动对应的诊断流程。
• 持续更新模型：随着新数据不断加入，动态阈值会被持续修正，使其适配当前环境的正常波动模式，而非依赖一次性的静态配置。

智能诊断与频率控制

当系统确认存在 IO 异常后，一键诊断模块会自动调用相应的分析工具，抓取关键现场信息并进行自动化处理，帮助用户快速锁定问题。为避免过于频繁的诊断操作影响业务，系统通过以下两个参数对诊断频率进行约束：

• 诊断冷静期（triggerInterval）：规定两次诊断之间必须间隔的最短时间，用来避免在短时间内重复对同一类异常进行频繁扫描。
• 异常累积阈值（reportInterval）：设置触发诊断所需的异常累积条件。当该值为 0 时，只要异常满足冷静期结束的条件，就立即启动诊断；当该值为非 0 时，则需要在冷静期之后、限定时间窗口内出现一定次数的异常事件，才会真正触发。

根因分析

在完成现场数据采集之后，面对复杂多样的系统信息，如何从中筛选出与当前问题强相关的线索，是传统人工分析的难点。IO 一键诊断在工具层面内置了一套自动分析逻辑，能从采集结果中提炼结论，并以结构化信息的形式反馈给用户，包括但不限于：

• IO Burst 场景：分析在异常时间段内各进程对 IO 的贡献度，在报告中标明最“耗 IO”的进程。对于写 buffer IO 而由内核 kworker 线程负责刷脏的情况，也能追溯到最初发起写入的用户进程。
• IO 延迟异常：统计并展示异常区间内 IO 延迟的整体分布情况，标记延迟最高的路径（如对应的设备或文件/目录），帮助快速找到性能瓶颈所在。
• iowait 异常偏高：记录和展示导致 iowait 偏高的关键进程，以及引发大量等待的具体原因（例如磁盘被占满、脏页刷写过慢等）。

案例分析

iowait 高

在某些场景下，业务反馈系统整体响应慢，通过监控发现 iowait 指标异常升高。借助 IO 一键诊断，可以直接定位到哪一个或哪些进程在大量等待磁盘 IO，以及每个进程累计等待的时间长度，并进一步分析等待背后的原因。

在示例案例中，诊断结果显示：业务写入量过大导致 IO 压力偏高，系统中脏页堆积，最终使业务进程 task_server 长时间阻塞在 IO 等待上。针对这种情况，报告建议谨慎下调 dirty_ratio、dirty_bytes 等内核参数，以减少一次性刷脏量，降低磁盘压力，从而缓解 iowait 过高问题。

IO延迟高

另一类常见问题是写 IO 的延迟持续走高。某用户通过基础监控发现写入延迟异常后，通过 IO 一键诊断进行进一步排查。

诊断报告指出，在问题发生期间，DiskBlockWrite 进程是主要的 IO 负载来源，并且耗时主要集中在刷脏阶段，也就是说核心瓶颈在于磁盘将缓存数据落盘的过程。依据这一结论，系统给出两类优化建议：一是调整业务逻辑，减少短时间内大量 buffer IO 的写入；二是通过适当调整 dirty_ratio、dirty_background_ratio 等参数，控制脏页生成和回写的节奏，从系统层面降低写 IO 延迟。

相关链接：

[1] IO 一键诊断
https://help.aliyun.com/zh/cms/cloudmonitor-2-0/io-key-diagnosis

[2] 云监控-ECS 洞察-SysOM 系统诊断
https://cmsnext.console.aliyun.com/next/region/cn-shanghai/wo...

[3] 操作系统控制台实例纳管
https://help.aliyun.com/zh/alinux/user-guide/system-management

全文链接：https://tecdat.cn/?p=45008
原文出处：拓端数据部落公众号

在大模型技术快速渗透软件工程领域的当下，智能编码代理工具已成为提升研发效能的核心抓手，终端环境下的AI编码能力更是成为开发者关注的核心方向。过去数十年，终端工具始终是开发者的基础操作载体，却长期只承担单一的命令执行功能，开发者需要在编辑器、文档、调试工具间反复切换，大量重复工作消耗了研发精力。而生成式AI的爆发，让终端完成了从“命令执行器”到“智能研发助手”的跨越式升级，Anthropic推出的Claude Code率先实现了终端原生的全流程编码代理能力，开源社区也快速跟进打造了OpenCode，形成了闭源商业产品与开源开放产品两大核心路线。

本文基于我们在企业级研发效能提升领域的长期实践，结合对比分析法、实证测评法与场景适配分析法，对两款工具的核心能力、成本控制、安全合规、场景适配性进行全面拆解，为不同类型的开发者与企业团队提供可落地的选型参考。
本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整内容已分享至交流社群。阅读原文进群，可与800+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路，帮大家既懂 怎么做，也懂 为什么这么做；遇代码运行问题，更能享24小时调试支持。

文章研究脉络流程图

一、Claude Code核心能力与适配场景

Claude Code是Anthropic官方推出的终端原生智能编码工具，开发者通过自然语言指令，就能在终端内完成代码重构、文档生成、缺陷修复等全流程研发工作，无需复杂的环境配置，就能快速接入现有研发流程。

1.1 核心功能特性

开发者使用AI编码工具时，最常遇到的问题就是对话上下文超出模型窗口限制，导致工具丢失任务上下文、执行结果出错。Claude Code通过自动上下文压缩技术解决了这一问题，工具会实时监控对话的token消耗量，当用量达到阈值时，自动对历史对话进行摘要压缩，既保留了核心任务信息，又能避免触发上下文上限，保障长周期研发任务的稳定执行。
作为终端原生工具，Claude Code的所有核心能力都可在终端内闭环完成，包括功能开发与缺陷修复、Git版本管理与PR创建、MCP服务对接、多编码代理并行启动、自定义技能与自动化钩子配置。同时工具搭载的扩展思考模式，会在处理复杂任务时先暂停代码修改，先完成完整的解决方案规划，再逐步执行操作，大幅降低了代码出错的概率。

Claude Code的自动化钩子能力，可实现编码流程的全自动化，比如在代码写入后自动执行格式化、单元测试等操作，核心配置代码如下：

{ "auto_hooks": { "AfterToolExec": [ { "match_rule": "FileWrite", "hook_list": [ { "exec_type": "shell_command", "exec_content": "python -m black ." } ...... // 此处省略多场景hook规则、权限校验与异常处理代码 ] } ] }}

上述代码实现了文件写入后自动执行Python代码格式化的能力，开发者可通过修改match_rule与exec_content，自定义不同场景下的自动化操作。

1.2 优势与局限性

Claude Code由Anthropic官方团队维护，开箱即用的特性大幅降低了使用门槛，仅需完成账号授权与简单安装，就能快速投入使用。依托Anthropic的企业级服务能力，工具具备SOC2数据合规资质，能为企业团队提供完善的安全保障，同时搭配Claude Opus 4.6等旗舰模型，代码生成的幻觉率极低，极少出现虚构不存在的依赖库的情况。
但Claude Code也存在明显的局限性，首先是使用成本较高，尤其是搭配Opus系列旗舰模型时，长周期的研发任务会产生高额的token费用；其次工具属于闭源技术，开发者无法查看和修改底层代码，也只能使用Anthropic旗下的模型，无法切换其他模型服务商；同时工具内置的安全管控规则，会对部分系统级命令的执行做限制，无法满足部分定制化的操作需求。
Claude Code的核心安装与启动命令如下：

# 全局安装Claude Code终端客户端npm install -g @anthropic-ai/claude-code-terminal# 进入目标项目工作目录cd your-project-workspace# 启动Claude Code交互服务claude-terminal

相关文章

Qwen3大模型本地化部署、LoRA低秩适配轻量化微调与医疗推理领域应用落地研究|附代码数据

原文链接：https://tecdat.cn/?p=44985

二、OpenCode核心能力与适配场景

OpenCode是开源社区推出的智能编码代理工具，也是行业内对Claude Code闭源模式的开源响应。它支持终端交互、桌面客户端、IDE插件三种使用形式，核心定位是“模型无关”的通用编码代理平台，只提供代码编辑、终端执行、Git管理等标准化工具能力，底层的大模型可由开发者自主选择。

2.1 核心功能特性

OpenCode的核心优势在于极致的灵活性，开发者既可以接入闭源的大模型API，也能通过Ollama等工具接入本地部署的开源模型，实现完全离线的编码代理服务。与Claude Code优先保障响应速度的设计不同，OpenCode更侧重操作的完备性与安全性，开发者可自定义工具的执行策略，比如要求所有代码修改前必须执行完整的单元测试，虽然会增加操作耗时，但能大幅降低线上代码的回归风险。

针对金融、政务、医疗等强监管行业，OpenCode提供了“气隙模式”，配合本地开源模型使用时，所有代码与数据都不会离开企业内网，完全满足数据合规的要求。同时工具正在迭代的工作空间功能，基于客户端/服务端架构实现，即使关闭本地设备，服务端的任务上下文也能持续保留，这是Claude Code的轻量化CLI设计难以实现的能力，也是开源社区最关注的特性之一。

OpenCode的桌面客户端还提供了规划-构建双模式，开发者可先在规划模式中完成项目的整体架构设计、模块拆分与技术方案确认，再切换到构建模式执行代码编写，让复杂项目的开发流程更可控。

2.2 优势与局限性

开源的产品形态让OpenCode拥有了极高的自由度，开发者可自由切换开源/闭源模型，针对简单的文档编写任务可使用低成本甚至免费的模型，复杂的架构设计任务再切换到高性能旗舰模型，大幅降低了使用成本。同时开源的代码架构允许开发者根据自身需求定制化修改底层逻辑，没有闭源工具的功能限制。

但OpenCode也存在对应的使用门槛，开箱即用的体验弱于Claude Code，尤其是接入本地开源模型时，需要开发者自行完成模型下载、环境配置与服务对接，对使用者的技术能力有一定要求；同时本地运行大模型需要对应的硬件算力支持，即使不使用GPU，也需要设备提供足够的内存空间，否则会出现响应缓慢的问题。
OpenCode的核心安装与初始化命令如下：

# 一键安装OpenCode官方客户端curl -fsSL https://opencode.ai/install.sh | bash# 完成客户端环境初始化与服务配置opencode onboard --install-service# 检查客户端安装状态与运行环境opencode doctor

三、Claude Code与OpenCode横向对比测评

我们通过实证测评法，从性能延迟、成本效率、安全合规、易用性四个核心维度，对两款工具进行了全面的横向对比，结果如下表所示：

四、场景化选型建议

两款工具没有绝对的优劣之分，核心是匹配开发者与团队的实际需求，我们通过场景适配分析法，总结了不同场景下的选型建议。

优先选择Claude Code的场景：

1. 企业级研发团队，需要开箱即用的标准化编码代理工具，无需额外的环境维护成本
2. 对代码生成的稳定性与合规性有高要求，需要企业级的安全保障与技术支持
3. 团队已深度使用Anthropic旗下模型，希望在终端内实现研发流程的闭环
4. 优先追求研发效率，可接受对应的使用成本，无需定制化的底层修改
   优先选择OpenCode的场景：
5. 个人开发者与小型团队，对使用成本敏感，希望灵活控制研发投入
6. 强监管行业的研发团队，需要代码数据完全内网运行，不能上传至第三方云端
7. 有定制化的功能需求，希望修改工具底层逻辑，适配自身的研发流程
8. 有对应的算力资源，可本地部署开源模型，希望实现完全离线的编码代理服务

五、行业发展趋势展望

从智能编码代理工具的发展历程来看，开源工具往往会先从技术层面实现核心能力的对标，再通过社区生态逐步完善产品体验，最终推出商业化的云服务实现商业闭环。比如LangChain推出了LangSmith、LlamaIndex推出了LlamaCloud，都是遵循这一发展路径。我们预判，OpenCode未来也会推出对应的企业级云服务，为需要托管服务的团队提供一体化解决方案，形成开源免费版+企业商业版的双模式布局。
而闭源的Claude Code，会持续优化开箱即用的产品体验，深化与Anthropic模型的深度融合，在企业级市场持续深耕，同时会逐步开放更多的自定义能力，平衡易用性与灵活性。

六、研究结论

Claude Code与OpenCode分别代表了智能编码代理工具的两条发展路线，Claude Code以极致的易用性和一体化体验为核心，为企业团队提供了开箱即用的研发效能提升方案；OpenCode则以开源开放为核心，为开发者提供了极致的自由度与数据安全保障，适配了更多个性化的使用场景。
开发者在选型时，无需盲目追求功能的全面性，核心是匹配自身的成本预算、技术能力、数据合规要求与使用场景。对于追求效率与稳定性的企业团队，Claude Code是更优的选择；对于追求自由度、成本控制与数据安全的开发者，OpenCode会带来更贴合需求的使用体验。

背景

随着云计算的深入应用，企业核心业务加速上云，高质量的网络通信已成为保障业务连续性的关键。作为网络传输的核心指标，数据包丢失直接影响系统稳定性：轻度丢包可能导致通信中断、数据异常，扰乱业务逻辑；严重丢包则可能引发健康检查失败、Ping 不通、服务拒绝等系统性故障，带来连锁运维问题。

某客户在新区域部署分布式集群时，突遇网络丢包，导致节点通信中断，业务部署停滞，资源持续闲置。面对这一紧急情况，阿里云云监控 2.0 通过 SysOM 智能诊断功能，在数小时内精准定位故障根源，帮助客户快速恢复业务部署与系统稳定运行，有效避免资源浪费。

本文将通过这一典型案例，深入解析 SysOM 在丢包故障排查中的实战应用，展示其如何助力企业高效恢复业务连续性。

通过丢包诊断分析定位问题根因

场景一：问题快速定界

在阿里云 ACK（阿里云 Kubernetes 服务）新区域集群部署过程中，某客户遭遇系统性健康检查异常，导致业务部署流程全面受阻。在排除 iptables 规则配置异常的可能性后，运维团队将故障定位重点转向内核层丢包问题。

该类问题的排查涉及复杂的内核级分析流程，要求运维人员具备扎实的内核源码分析能力。需追踪数据包在内核协议栈中的处理路径，并结合 netfilter 框架各 hook 点的流量特征进行深度监控。这种技术方案不仅对排查人员的内核调试能力提出严苛要求，同时需要投入大量时间资源进行问题复现与验证。本次故障处置中，我们借助操作系统控制台的能力，成功定位问题根源。典型云原生架构下，承载 ACK Pod 的 ECS 实例集群前端配置了 SLB 负载均衡器，形成标准的云原生部署拓扑（如架构图所示）。

我们通过 tcpdump 对 ECS 的 eth0 网卡上进行抓包。抓包结果如下，抓包结果显示，源地址为SLB健康检查网段，此时 SLB 持续向本机发送 SYN 包以建立连接。但本机未返回 ACK 包，导致健康检查失败。那么本机为何未能返回 ACK 包？

iptable 规则导致？

按照常规排查思路，我们首先考虑是否存在 iptables 规则导致请求被过滤的可能性。但通过对正常主机与异常主机的 iptables 配置进行比对核查后发现，两者策略保持完全一致，由此可以判定该因素并非造成当前网络异常的原因。

内核丢包？

排查内核丢包问题时，过去往往需要精通网络内核模块的资深工程师进行深度分析，而如今只需通过阿里云操作系统控制台轻松操作，即可快速实现过去需专业人员才能完成的复杂诊断任务。

使用操作系统控制台对问题实例进行诊断：

如图上所示，在云监控控制台选择 ECS 洞察，选择系统诊断（SysOM）、节点诊断、网络诊断、丢包诊断，在第 5 步中选择所需要诊断的实例 ID，最后点击执行诊断。诊断完成以后，点击查看报告，可以看到机器中的丢包情况。

如上图所示，诊断结果显示未发现已知丢包异常记录。由此可判断，内核层丢包可能性已基本排除。

排查驱动或其他模块

结合操作系统控制台的诊断信息，目前已基本确认内核并未发生丢包，成功排除了底层协议栈存在异常的可能性。进一步分析显示，eth0 接口已成功接收到 SYN 包，说明网络链路未出现数据丢失；同时，iptables 规则检查无异常，也排除了因配置规则导致问题的可能。在完成上述排查后，我们意识到仍有一个潜在维度尚未覆盖——网络驱动或中间件模块可能存在异常。基于这一假设，我们决定将系统中的钩子（hook）日志打印出来进行分析。

从上图可以看出，与正常机器相比，该系统中多出了大量 sched_cls 类型的钩子。经与 ACK 研发团队确认，这些钩子来自某个网络组件。由此我们高度怀疑正是该组件所注入的钩子导致 SYN 包被意外过滤，遂将其卸载。卸载后，健康检查立即恢复正常。

通过操作系统控制台的协助，我们迅速完成了问题的初步定位，排除了内核丢包的可能性，从而能够更快地将排查重点转向其他方向，为后续问题的解决节省了大量时间。

精准定位问题

某客户在新建实例后，发现 1678 端口无法通过 telnet 连通，严重影响其业务运行。该端口是其业务进程对外通信的关键入口，一旦不通，将导致服务无法正常与外部系统交互。

本案例与前述问题较为相似，同样表现为网络不通。在处理此类问题时，我们的标准排查流程是：首先对目标端口或网卡进行抓包，观察数据包的实际流向和交互情况。客户在其机器上执行了 telnet 测试，发现 22 端口可以正常连通，但 1678 端口及其他多个端口均无法访问。进一步检查确认，相关端口均有业务进程正常监听，服务本身运行无异常。按照常规思路，我们首先怀疑是否为 iptables 规则拦截所致。在客户配合下，我们详细检查了该主机的 iptables 配置，确认未设置任何特殊或限制性规则，基本排除了防火墙策略导致的问题。结合上一个案例的经验，我们进一步考虑是否存在网络驱动或内核模块中的钩子（hook）干扰了数据包处理。于是，我们重点排查了系统中是否安装了安全类组件或注入了异常函数钩子。经查，该机器未部署额外的安全软件，也未发现可疑的内核钩子或网络拦截模块。因此，钩子机制导致 SYN 包被过滤的可能性也被排除。问题原因需从其他维度继续深入分析。

既然钩子和 iptables 都没有问题，那是否可能是内核层面出现了丢包？带着这个疑问，我们可以通过操作系统控制台对异常实例进行进一步诊断：

很快，诊断完成后，我们查看诊断的报告。

诊断报告中明确提示：需删除 iptables 丢包规则或相关 netfilter 驱动。结论十分清晰——丢包是由 netfilter 机制引起的。既然问题根源指向 netfilter，那么首要排查对象便是其规则配置。考虑到现代 Linux 系统可能同时使用 iptables 和 nftables（后者作为 netfilter 的新一代前端），我们首先检查 nftables 的规则设置：

通过查看 nftables 规则配置，发现其中确实存在一条针对 1678 端口的 drop 规则。

删除对应的规则并更新配置后，在本机监听 1678 端口，发现连接已恢复正常，问题得以解决。

总结

在日常系统运维中，丢包问题可能导致业务通信中断、服务异常甚至无法部署。但这类问题并非不可攻克——阿里云操作系统控制台提供了简单、易用且专业的诊断工具。当怀疑系统存在丢包时，可结合控制台按以下步骤进行排查：

• 首先直接使用操作系统控制台的丢包诊断功能，查看报告是否明确指出了问题根源。
• 若诊断结果显示内核未发生丢包，则检查系统是否安装了额外的安全软件，或与正常环境对比是否存在异常的钩子（hook）。
• 在确认无非预期驱动或钩子后，进一步核查 iptables 规则配置是否正确。
• 若仍无法定位丢包点，可借助 funcgraph、BPF 等工具，在可疑的网络路径上打点抓包，精准定位丢包位置。

通常，结合操作系统控制台并遵循上述四个步骤，大多数丢包问题都能被有效识别和解决，让复杂的网络故障变得轻松可控。

相关链接：

[1] 《一次内存诊断，让资源利用率提升 40%：揭秘隐式内存治理》
[2] 云监控 - ECS 洞察 - SysOM 系统诊断
https://cmsnext.console.aliyun.com/next/region/cn-shanghai/wo...

[3] 操作系统控制台实例纳管
https://help.aliyun.com/zh/alinux/user-guide/system-managemen...

[4] 操作系统控制台 Java 内存诊断
https://help.aliyun.com/zh/alinux/user-guide/java-memory-diag...

[5] 操作系统控制台热点追踪
https://help.aliyun.com/zh/alinux/user-guide/process-hotspot-...

[6] 操作系统控制台热点对比分析
https://help.aliyun.com/zh/alinux/user-guide/hot-spot-compara...

摘要：
混合搜索通过多模融合架构，支持单SQL处理结构化与非结构化数据混合查询。其核心流程分两阶段：粗排利用ANN、标量过滤和全文检索快速筛选候选集，通过RRF和归一化融合结果；精排则采用精确算法和复杂模型对候选结果精细化打分。OceanBase在VectorDB Bench中性能领先，以低成本实现高精度召回，并通过内核级优化提升混合查询效率。

背景

但在OceanBase 社区的实战营课程发布之后，有很多的社区用户在各个课程交流群中都提出了和混合搜索相关的问题，其中有比较多的问题都属于一些和混合搜索相关的基础概念，例如：混合搜索的流程是什么、“粗排”、“精排” 阶段分别是在干什么等等。

所以今天更新一篇非常简短的混合搜索基础概念学习笔记，作为 OceanBase 社区实战营第三季活动[1]的一个番外篇。

什么是混合搜索？

混合搜索目前已经成为 AI 时代数据库的刚需，DBA 必须都要了解。

为什么敢这么说？那就简单以一个最常见的知识库场景为例：

1. 在生产环境中使用数据库，往往都会考虑权限问题。权限问题主要的解法，就是把文档表、员工权限表以及各种各样的表去做 Join。我目前几乎没有看到过有用户和业务使用很 “纯粹” 的向量检索，一般都会有标量 & 向量混合搜索。这个标量，靠的就是传统数据库的检索能力。
2. 为了让检索更准确，对于 RAG 方案，目前业界比较共识的方案是：全文 + 向量混合搜索。未来，没有全文检索能力的数据库厂商，很难满足 RAG 方面的需求。
3. 其他类似于 GraphRag 的方案，在学术界以及工业界也比较活跃。所以，向量 + 图混合搜索的需求，也变的越来越常见。

那什么是混合搜索？与其给出定义，不如直接举个例子来的方便。

在上图的这个提问中：

距离五百米以内，是基于空间位置（GIS）的查询。
人均消费 25 元，评价 4.5 分以上，是基于传统标量的查询。
不用排队，是基于用户对店铺的评价，基于向量的语意检索。

这里直接借用 OceanBase 官网的一张图，来为大家展示一下数据库支持混合搜索之后，会有哪些优势。

从上图中可以看出：混合搜索，相比多组件分别检索（向量 / 标量 / 全文）然后再归并的优势，大概就是：

基于多模融合的一体化架构，无需引入额外组件，简化了 AI 技术栈，降低了运维复杂度。

支持通过一条 SQL 语句同时处理结构化、半结构化和非结构化数据的混合查询，简化了应用的开发流程。

数据库内核中的优化器感知到更多信息，因此可以提供更优的执行计划，提高了查询效率。

混合搜索的流程是什么？

一图胜千言。

下面这张图是借用 PowerMem 开源项目[2]中的一张和混合搜索相关的流程图，先看看你能看懂多少？

在上面这张图里，实战营课程中被提出最多的问题，就是 “粗排” 和 “精排” 阶段是在干什么？所以这篇文章的重点，就是补充解释一下之前遗漏的这些基础概念。

粗排阶段（召回 + 初筛阶段）

核心逻辑：以“速度”为优先级，快速从全量数据中筛选出「潜在相关」的候选集，尽可能排除明显不相关的内容，为后续精排减负。粗排主要逻辑就是通过向量 / 标量 / 全文几个维度粗过滤，然后进行一次各个维度粗过滤的结果融合。

这一部分主要为大家介绍粗排结果融合中涉及的两个概念 —— RRF（Reciprocal Rank Fusion） 和归一化（Normalization）。这两个专有名词听起来挺洋气，实际都非常简单，继续往下看一个例子就能搞明白。

1. 向量检索的粗排

向量相似性搜索（如 Embedding 匹配）若直接计算全量向量的相似度（如余弦相似度），时间复杂度是 O(n) （全量遍历），对大规模数据完全不可行。

因此粗排会用近似最近邻（ANN）算法（如 HNSW、IVF、PQ 等索引结构）：

通过“空间分块、分层索引”等方式，把向量空间“剪枝”，快速定位可能的近邻向量（牺牲少量精度换速度）。

输出 Top K 个候选向量（比如从百万级数据中快速筛出 1000 个候选）。

2. 标量过滤的粗排

标量是数值型字段（如价格、时间、销量等），粗排阶段用范围过滤 + 索引加速：

用 WHERE price BETWEEN 100 AND 500 这类条件，快速过滤不满足数值约束的文档，直接缩小数据规模。

特点：过滤逻辑“硬”（不满足则直接排除），执行速度极快（依赖数据库索引）。

3. 全文检索的粗排

全文搜索（如关键词匹配）的粗排依赖倒排索引：

倒排索引记录了“关键词→包含该词的文档 ID 列表”，能快速匹配用户输入的关键词（如 “笔记本 轻薄”），筛出包含关键词的文档集合。

这一步是“关键词存在性匹配”，不做复杂语义分析（比如不计算 BM25，只确保关键词出现）。

4. 粗排结果融合

混合搜索中，粗排会同时结合向量、标量、全文的初筛条件，通过 “交集 / 并集” 缩小候选集。

粗排结果融合常见的方法就是 RRF（Reciprocal Rank Fusion） 和归一化（Normalization）。

RRF（倒数排名融合）

一句话理解 RRF：“谁在多个排名里都排得靠前，谁就是真正的热门。”

排名越靠前的结果，贡献的分数越高，且采用“倒数”形式，强调高排名项。公式如下：

举个例子，假设我们用两种搜索方式召回 “如何学习 seekdb”，并对召回的 4 个技术文档进行排序

即使 A 文档在向量搜索中排名第一，但 B 文档在向量和全文中全都排在前两名，所以通过 RRF 算出的最终综合得分更高。

归一化

将不同来源的评分，转换到统一尺度（通常是 [0, 1]），以便更加公平的比较和融合排名结果。

最常用的 Min-Max 归一化公式如下：

为什么需要归一化？因为不同召回方式的得分范围可能完全不同。

如果那归一化之前的得分直接相加，显然向量相似度的结果对最终排名几乎没有任何影响。
这个比较好理解，就不举例子了。

精排阶段

这个阶段，就是对粗排筛选出的少量候选结果，通过大模型来进行精细化打分与排序，确保最终返回结果最相关、最符合业务需求。在 RAG、搜索引擎、推荐系统中加入 rerank 精排，可以显著提升检索的准确率。

精排阶段主要会使用复杂模型，让排序算法升级（让排序更精准）。

召回 / 粗排时常用 “近似、轻量” 的方法（如 ANN 向量检索、简单规则），rerank 阶段则会用更复杂的模型 / 算法修正误差：

向量检索：
粗排会用 ANN（近似近邻）
rerank 会用精确余弦相似度重新计算，修正近似误差。

全文检索：
粗排会用 “关键词存在性匹配”
rerank 会用 BM25 / 预训练模型（如 BERT） 计算文本语义匹配度，提升文本相关性。

其他
rerank 阶段，往往还会用更加复杂的排序大模型（如 LambdaMART、DNN），自动学习多特征的权重，输出更精准的排序。

除此以外，精排阶段还会注入业务规则，让结果更符合业务目标。例如在电商搜索中，粗排阶段只会聚焦 “相关性”，而 rerank 时会加入 “推广商品加权”、“新品标加权”、“高毛利商品倾斜” 等特殊规则。

rerank 是混合搜索流程的 “最后一公里”，通过多特征融合、复杂模型、业务规则，将“召回/粗排的候选集”转化为“用户看到的最终结果”。

最后一句话总结

粗排 + 精排
= 快而不准的多渠道召回 + 慢而准的 rerank
= 高效又高质的混合搜索。

Oceanbase数据库

OceanBase 向量数据库的几点优势

性能好 & 召回精度高：VectorDB Bench，比其它主流的向量数据库性能都好。

成本低：在同等条件下，成本业界最低。

效率更高：AI 负载需要的数据库能力，OceanBase[3] / seekdb[4] 向量数据库都能在一个集群支持。
更快：数据库混合查询，内核级别优化，性能比多个数据库的方案优数倍。
更易用：开发接口统一（开发优）、技术栈统一（架构优）、运维管控统一（运维优）。

其他：
分布式，横向可扩展。
金融级别高可用方案。
工具体系：端到端 迁移 / 开发/ 运维监控 & 诊断。
强事务能力：既有事务能力，性能也在 TPCC 榜单榜上有名。
还有这篇文章里的 “混合搜索”。
……

参考资料
[1]
OceanBase 社区实战营第三季活动: https://ask.oceanbase.com/c/training-centre/dba-practical-cam...
[2]
PowerMem 开源项目: https://github.com/oceanbase/powermem/
[3]
OceanBase: https://github.com/oceanbase/oceanbase
[4]
seekdb: https://github.com/oceanbase/seekdb

背景

在云原生架构普及的背景下，容器化显著提升了应用交付效率和资源利用率，但也带来了运维挑战。由于容器对底层系统的抽象，内存可见性降低，导致高负载下出现的内存占用过高、抖动甚至服务退化等问题难以及时发现和定位。传统依赖人工、日志回溯和逐节点分析的排查方式效率低下，难以应对动态环境；而隐性内存泄漏等长期问题则持续影响稳定性并推高运维成本。

为此，云监控2.0[1]全新打造底层操作系统诊断[2]能力，可实现对主机、容器运行时及应用进程的全栈内存状态一键扫描与统一分析。该方案无需侵入业务，即可快速识别异常模式，显著提升问题发现与根因定位效率。

业务痛点解析

隐式内存占用指业务运行中间接产生的系统内存消耗，未体现在应用进程的常规指标（如 RSS/PSS）中，因而难以被监控或业务感知。尽管不表现为“显式”使用，却真实占用物理内存。由于缺乏有效暴露与归因机制，这类内存往往在系统层面持续累积，最终导致可用内存下降、频繁回收甚至 OOM。在高负载、高并发或复杂云原生架构中，该问题尤为突出，严重影响服务延迟、调度效率与系统稳定性。因此，亟需结合内核级追踪与全栈关联分析，实现从“看到内存用量”到“理解内存成因”的跃迁，提升可观测性与资源治理精度。

痛点 1：文件缓存(filecache)高

filecache 用来提升文件访问性能，并且理论上可以在内存不足时被回收，但高 filecache 在生产环境中也引发了诸多问题：

• filecache 回收时，直接影响业务响应时间（RT），在高并发环境中，这种延时尤为显著，可能导致用户体验急剧下降。例如，在电商网站的高峰购物时段，filecache 的回收延时可能会引起用户购物和付款卡顿，直接影响用户体验。
• 在 Kubernetes（k8s）环境中，workingset 包含活跃的文件缓存，如果这些活跃缓存过高，会直接影响 K8s 的调度决策，导致容器无法被高效调度到合适的节点，从而影响应用的可用性和整体的资源利用率。

痛点 2：SReclaimable 高

SReclaimable 是内核维护的可回收缓存，虽不计入用户进程内存统计，但受应用行为（如频繁文件操作、临时文件创建/删除）显著影响。尽管系统可在内存压力下回收它，但回收过程涉及复杂的锁竞争与同步，常引发较高的 CPU 开销和延迟抖动。SReclaimable 长期高位会占用大量物理内存，却因监控通常只关注进程 RSS 或容器内存而被忽视，造成内存压力误判。

因此，应将 SReclaimable 纳入关键内存指标，结合应用行为与内核观测，实现精准归因与动态管控，防范其对系统稳定性的潜在威胁。

痛点 3：memory group 残留

cgroup 与 namespace 是容器运行时的核心机制。在高频调度场景（如大规模微服务或批处理系统）中，若清理不及时或内核释放延迟，易引发 cgroup 泄漏——即无关联进程的 cgroup 目录未被回收。这不仅占用内核内存，还会引起内存统计误差，导致监控异常、延时抖动等问题。

因此，保障 cgroup 生命周期闭环，结合内核监控与主动巡检，及时清理残留实例，是高密度容器环境稳定性治理的关键。

痛点 4：内存不足，却找不到去哪儿了

当系统内存紧张时，常规工具（如 top）难以揭示真实内存去向——它们无法观测内核驱动（如 GPU、网卡、RDMA）直接分配的内存。在 AI 训练等高性能场景中，GPU 驱动会大量申请 memory、DMA buffer 等系统内存用于显存映射与通信，但这些关键开销对用户“不可见”。运维人员只能看到 MemAvailable 骤降甚至耗尽，却无法定位具体任务、机制或判断是否存在泄漏。

这种可观测性盲区严重拖慢排障效率，可能导致服务中断或训练失败。更糟的是，根因不明易使同类问题反复发生，引发故障蔓延，威胁系统稳定性。

解决方案：用 SysOM 诊断隐式内存

方案介绍

在四种隐式内存占用场景中，文件缓存（page cache）过高最为常见。以该场景为例，核心问题是：哪些进程在读写哪些文件，导致缓存堆积？

解答的关键在于实现从内存页（page）到具体文件路径的精准归因。这需深入内核，完成从物理内存到文件语义的映射，主要分两步：

• 由 page 定位 inode：通过 page->mapping 和 index 找到其所属的 address\_space 和文件 inode；
• 由 inode 还原文件路径：遍历 dentry 缓存，在挂载命名空间中重建完整路径（如 /data/model/xxx.bin）。

要实现端到端追溯，系统需具备两大能力：全量扫描文件缓存页，以及根据 inode 高效解析对应路径。传统工具仅提供静态统计，缺乏进程-文件-页的动态关联。唯有构建细粒度、可追溯、低开销的全链路归因机制，才能回答“谁、读了什么、占了多少”，实现高缓存场景下的精准诊断与快速响应。

我们也调研分析了多种方案的优缺点：

最终我们选择基于 kcore 来解析系统 filecache 对应的文件，但也需要解决几个问题：

1. kcore 读的是 raw 内存，没有数据结构信息。
2. kcore 需要遍历全量内存，在大内存系统下，CPU 消耗大，时间长。
3. 需要支持整机和容器级的文件缓存扫描。

方案实施

针对传统 kcore 方案在文件缓存分析中内存依赖强、兼容性差、开销高等问题，我们提出一种基于 eBPF BTF 协同的轻量级解析机制。

核心优势在于：利用内核自带的 BTF 信息，动态获取关键数据结构的字段偏移，实现跨版本、跨发行版的安全内存解析。针对 page cache 物理页离散分布、全量遍历成本高的挑战，使用采样策略——仅需捕获少量活跃的缓存页，即可回溯至对应 inode，解析出文件路径及所属 cgroup。结合 /proc/kpageflags 和 /proc/kpagecgroup 提供的页级属性（如是否为文件页、可回收性、cgroup 归属等），实现物理内存到容器和工作负载的精准归因。

该方案首次在生产环境中实现非侵入、低开销、高精度的文件缓存溯源，突破“看得见总量、看不见来源”的瓶颈，为缓存膨胀与隐性内存占用提供有效诊断手段。

教育行业某客户通过控制台解决内存高问题

K8s 是一个开源的容器编排平台，主要用于自动化部署、扩展和管理容器化应用。它提供一个强大的、灵活的架构来支持大规模的应用服务，从而简化了应用的运维管理，企业在享受 K8s 在容器编排和部署所带来的便利时，同时也面临新的问题。

案例 1：通过 SysOM 分析容器内存工作集高

Kubernetes 采用内存工作集(workingset)来监控和管理容器的内存使用，当容器内存使用量超过了设置的内存限制或者节点出现内存压力时，kubernetes 会根据 workingset 来决定是否驱逐或者杀死容器。

内存工作集计算公式：Workingset = 匿名内存 + active_file。匿名内存一般是程序通过 new/malloc/mmap 方式分配，而 active_file 是进程读写文件引入，程序一般对这类内存使用存在不透明情况，经常容易出问题。客户通过容器监控发现其 K8s 集群中某个 pod 的 Workingset 内存持续走高，无法进一步定位究竟是什么原因导致的 Workingset 内存使用高。

针对上述场景，先找到 Pod 所在的 ECS 节点，通过使用 SysOM 使用内存全景分析诊断，选择目标 ECS 节点后，再选择目标 Pod，发起诊断：

诊断结果如下：

诊断结论明确指出：容器 xxx 内存使用率过高，存在内存不足风险，主要因文件缓存占用较大。
查看文件缓存排序表可见，前两个容器中的日志文件（路径为宿主机映射路径，容器内实际位于 /var/log）共占用约 228MB 缓存，系业务程序读写日志所致。

建议优化日志写入方式或限制缓存增长，避免 WorkingSet 内存过高触发 OOM 或直接内存回收，导致业务延迟。

修复建议：

1. 通过手动执行 echo 1 > /proc/sys/vm/drop_caches 来主动释放缓存。
2. 如产生文件缓存的文件是非必要文件，可以通过手动删除文件释放缓存。
3. 使用 ack 集群的内存 QoS 功能：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/...

案例 2： 通过SysOM分析共享内存高

某行业客户发现，在运行较久的机器上，通过 free -h 看到的剩余内存较少，buff/cache 比较多，客户通过分析和查阅资料，通过执行 echo 3 > /proc/sys/vm/drop_caches 来主动释放缓存。客户发现，使用该方法可以回收部分缓存，但是仍然还有大量的 cache 占用没有释放：

针对上述场景，通过使用 SysOM 对目标 ECS 进行内存全景分析诊断，诊断的结果如下：

诊断结论明确指出：共享内存占用过高（34.35 GB），且以大量小文件（如 160 KB）为主，疑似存在泄露。从共享内存缓存占用排序表可见，占用最高的前 30 个文件均来自 /dev/shm/ganglia/* ，证实了小文件泄漏问题。由此判断，客户业务程序在该目录下创建了共享内存文件但未及时释放。结合业务场景评估后，可直接删除这些文件以释放缓存内存。

内存全景诊断结果说明及详细使用教程可参考：https://help.aliyun.com/zh/alinux/user-guide/memory-panorama-...

客户收益

目前操作系统诊断能力[3]能够对高负载、网络延迟抖动、内存泄漏、内存溢出(OOM)、宕机、I/O 流量分析及性能抖动等各种复杂问题进行一键诊断，在保障稳定性的同时最大化资源效率，更重要的是，该能力有效缓解系统资源压力引发的性能抖动——如文件缓存膨胀或内核内存增长触发直接回收甚至 OOM Killer，造成延迟或服务中断。通过及时识别异常占用并释放非必要缓存，可避免 Pod 频繁进入内存回收路径，降低进程阻塞与响应延迟，保障关键业务服务质量。

下一步规划：

我们将持续演进 SysOM 的智能运维能力：融合大模型的泛化理解与小模型的实时推理，构建分层诊断体系，实现异常早期识别、根因推测与处置建议生成；支持跨平台、多环境统一管理，扩展主流 OS 发行版兼容性；深化内核级细粒度监控，填补观测盲区，并集成至告警框架，推动运维从“被动响应”转向“主动防控”。整体推动操作系统从资源管理者向智能运维中枢演进，为关键业务提供更强技术底座。

如果您想了解更多的诊断能力，可参考系统诊断文档。

相关链接：

[1] 云监控 2.0
https://account.aliyun.com/login/login.htm?oauth_callback=htt...

[2] 系统诊断
https://account.aliyun.com/login/login.htm?oauth_callback=htt...

[3] 操作系统诊断能力
https://help.aliyun.com/zh/alinux/user-guide/operating-system...

AIOps新范式：说句话就能做运维

当前，操作系统运维面临复杂架构、依赖关系混乱、故障定位难、依赖人工经验、工具碎片化、监控不足及自动化欠缺等挑战。为应对以上难题，阿里云结合大语言模型（LLM）、智能体（Agent）与模型上下文协议（MCP），实现了自然语言驱动的智能运维：LLM 理解指令，Agent 自主执行任务，MCP 连接底层诊断工具。这三者的协同，使 AI 助手能自动诊断系统问题，生成报告与修复建议，显著提升效率，推动运维向主动智能演进。

阿里云操作系统控制台（以下简称操作系统控制台）是一站式操作系统运维管理平台，提供了内存、I/O、网络、内核崩溃等强大的系统诊断能力，SysOM是操作系统控制台的运维组件。但这些功能通常需要用户登录控制台，并具备一定的运维经验才能有效使用。

随着 AI 助手（如 Qwen Code）的普及，用户更希望用自然语言一句话解决问题，比如“为什么 CPU 变高了？”为此，SysOM 将原有诊断能力通过 MCP（Model Context Protocol） 进行标准化封装，推出开源项目 SysOM MCP。SysOM MCP 脱胎于阿里云操作系统控制台，把复杂的运维操作转化为 AI 可直接调用的标准工具，让 AI Agent 能像专业工程师一样“动手”诊断系统问题——用户无需懂命令，只需用自然语言提问，即可获得精准的系统级分析。如今，SysOM MCP 正在推动自然语言成为操作系统诊断的新入口，让智能运维真正走向普惠与高效。

SysOM MCP 项目开源地址：https://github.com/alibaba/sysom_mcp

SysOM MCP：用自然语言驱动系统诊断

传统运维依赖命令行和专家经验，而通用 AI 虽能“说”却不能“做”。SysOM MCP 的出现填补了这一鸿沟——通过 MCP 协议，AI 不仅能理解问题，还能自动执行真实诊断，实现从“问答”到“行动”的闭环。

SysOM MCP 项目内置超过 20 个生产级诊断工具，全部通过标准 JSON-RPC over stdio/SSE 暴露，包括：

• 内存分析：内存全景诊断、Java 内存诊断、OOM 内存诊断
• IO 诊断：IO 一键诊断、IO 流量分析诊断
• 网络排查：网络丢包诊断、网络抖动诊断
• 调度诊断：系统负载诊断、调度抖动诊断
• 磁盘诊断：磁盘分析诊断
• 宕机诊断：宕机诊断（dmesg 分析）、宕机诊断（vmcore 深入分析）

项目支持 --stdio（本地嵌入）和 --sse（HTTP 服务）两种模式，轻松集成各类 AI 客户端。

git clone https://github.com/alibaba/sysom_mcp.git
cd sysom_mcp

再在配置文件中添加如下配置，就可以让 AI 助手能以自然语言驱动操作系统及运维操作。

{
  "mcpServers": {
    "sysom_mcp": {
      "command": "uv",
      "args": ["run", "python", "sysom_main_mcp.py", "--stdio"],
      "env": {
        "ACCESS_KEY_ID": "your_access_key_id",
        "ACCESS_KEY_SECRET": "your_access_key_secret",
        "DASHSCOPE_API_KEY": "your_dashscope_api_key"
      },
      "cwd": "<sysom mcp项目目录>",
      "timeout": 30000,
      "trust": false
    }
  }
}

最佳实践：谈话间揭秘隐蔽内存泄漏

OS Copilot 是阿里云基于大模型构建的操作系统智能助手，支持自然语言问答、辅助命令执行、系统运维调优等功能，帮助您更好地使用 Linux 系统，提高 Linux 的使用效率。目前，操作系统控制台上的 OS copilot 已接入 SysOM MCP，用户只需在操作系统控制台中以自然语言与 OS Copilot 对话，即可自动触发操作系统问题的根因排查。整个诊断过程无需人工干预，结果以结构化形式清晰呈现，大幅降低运维门槛，让复杂问题“一问即解”。

本文以隐蔽的内存泄漏为例，展示 SysOM MCP 的诊断功能。

我们可以看到上图的对话中，OS Copilot 给出了可能的泄漏原因。同时也可以点击下方的诊断报告，在操作系统控制台查看更详细的诊断结果。

下载体验，欢迎共建

SysOM MCP 脱胎于阿里云操作系统控制台，诊断工具已在大规模生产环境验证。

下载地址

项目采用现代 Python 工具链（uv + Python 3.11+），安装简单：

git clone https://github.com/alibaba/sysom_mcp.git
cd sysom_mcp && uv sync

支持一键启动：

uv run python sysom_main_mcp.py --stdio        # 供本地调用  
uv run python sysom_main_mcp.py --sse --port 7140  # 启动 HTTP 服务  

使用场景

SysOM MCP可接入各种AI agent，帮助您打造具备系统诊断能力的智能助手。

开源共建

🌟 GitHub 地址：https://github.com/alibaba/sysom_mcp

欢迎 Star、Fork、提交 Issue，一起构建 AI 原生运维新生态！

如想使用更全面的SysOM功能，请登录阿里云操作系统控制台（https://alinux.console.aliyun.com/）

您在使用操作系统控制台的过程中，有任何疑问和建议，可以搜索群号：94405014449 加入钉钉群反馈，欢迎大家扫码加入交流。