core
opensumi/core加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个场景：你的团队正在开发一款面向金融场景的 AI 编程工具，要求在 IDE 界面里直接调用大模型分析代码、自动生成文档，甚至根据注释写代码。市面上没有现成产品能完全满足——但如果有一个现成的"底层框架"，只需要往上面填业务逻辑，就能快速搭出一个完整的 AI IDE 呢？
这就是 OpenSumi 试图解决的问题。
图1：OpenSumi 框架能力预览（来源：GitHub README）
2019年，VSCode 已经成为了开发者最流行的编辑器。它的核心优势在于：强大的插件生态、熟悉的界面体验、以及背后微软持续投入的工程能力。然而 VSCode 的定位是"通用编辑器"，对于需要构建垂直领域 AI IDE 的团队来说，直接基于 VSCode 扩展存在几个现实瓶颈。
定制成本高：VSCode 的插件 API 暴露的是 UI 层面的定制能力，想要深度修改编辑器内核行为（比如注入 AI Agent 逻辑），往往需要 fork 源码，改动代价极大。
AI 集成碎片化：GitHub Copilot 火了之后，各家都想做自己的 AI 编程助手，但都是在编辑器之上叠加功能，缺乏一个系统性的"AI Native"架构设计。
阿里团队的破局思路：既然 VSCode 的内核是开源的（Monaco Editor + LSP），为什么不从零设计一个专为 AI 场景打造的 IDE 框架，把 AI 能力作为一等公民来架构呢？于是 OpenSumi 诞生了——它不是另一个 VSCode 分支，而是一个全新的框架，用于快速构建 AI 原生 IDE 产品。
项目最初由蚂蚁集团（Ant Group）内部团队开发，随后开源，目前由阿里巴巴和蚂蚁集团联合维护。截至2026年，GitHub 获星 3631 个，是 AI IDE 框架领域 Star 数最高的项目之一。
理解 OpenSumi 的第一步，是分清它是什么、不是什么。
OpenSumi 是一个框架（Framework），而不是一个可以直接安装使用的 IDE 产品。它提供的是搭建 IDE 所需要的全部底层模块：编辑器核心、文件管理、终端模拟、插件系统、主题系统、快捷键管理等。开发者基于 OpenSumi，可以像"拼积木"一样组合这些模块，定制出面向特定场景的 IDE 产品。
打个比方：如果 VSCode 是"成品笔记本电脑"，OpenSumi 就是"DIY 电脑主板 + 组件套装"——它给了你构建能力，但需要你自己动手组装。
项目中包含 60+ 个独立 packages，涵盖：
editor、monaco、notebookexplorer、file-tree-next、file-service、workspaceextension、extension-manager、extension-storageai-native（含 MCP Client）collaborationterminal-next、debug、search、scm、output、status-bar每个 package 都可以被独立引入、替换或扩展，这使得 OpenSumi 具有极高的灵活性。
2024年，随着 Anthropic 推出 Model Context Protocol（MCP），AI Agent 与外部工具的标准化集成成为行业热点。OpenSumi 迅速跟进，在框架层面内置了 MCP Client 支持，这是它最核心的 AI 相关能力。
MCP（Model Context Protocol）是一种让 AI 模型与外部工具交互的标准化协议。你可以把它理解为 AI 世界的"USB 接口"——有了统一协议，AI 模型就可以像使用 USB 设备一样，方便地调用各种外部工具，而不需要为每个工具单独写集成代码。
OpenSumi 的 MCP 实现包含几个核心组件：
MCPServerManager：每个浏览器 Tab 有独立的 MCP Server 管理器实例，负责维护多个 MCP 服务器的生命周期（启动/停止）。
MCPServerRegistry：前端代理服务，负责注册和管理 MCP 工具，并将工具调用转发到后端。
SumiMCPServerBackend：桥接浏览器和 Node.js 层的后端服务，处理前端与后端之间的通信。
ToolInvocationRegistry：为 AI Agent 提供可用的函数调用注册表，支持工具的注册、查询和注销。
通过这套架构，开发者可以在 OpenSumi 构建的 IDE 中，让 AI 模型直接调用文件系统、搜索工具、自定义脚本等。换句话说，AI 不再只是"帮你补全代码"，而是真正"接管 IDE 操作"——读取文件、搜索内容、执行命令、修改代码。
项目还内置了 CodeFuse IDE（蚂蚁内部 AI IDE 产品）作为参考实现。
OpenSumi 的技术选型非常务实：
主语言：TypeScript。IDE 框架对类型安全有天然需求，TypeScript 能在编译期捕获大量潜在错误。60+ 个 packages 全部用 TypeScript 实现，通过 Yarn workspaces + Lerna 管理 monorepo。
编辑器内核：Monaco Editor。Monaco 是 VSCode 的编辑器内核，OpenSumi 直接集成 Monaco，确保了与 VSCode 生态的高度兼容——VSCode 的 Language Server Protocol（LSP）插件在 OpenSumi 中基本可以无缝运行。
构建工具：tsx + cross-env。package.json 显示项目使用 tsx（基于 esbuild）进行 TypeScript 编译，兼顾开发体验和构建速度。
测试：Jest。项目有完整的测试套件和 E2E 测试（Playwright），CI 流水线包含单元测试、覆盖率检测和端到端测试，代码质量维护得相当积极。
代码规范：ESLint + Prettier + commitlint。完整的代码规范体系，并使用 husky 做 pre-commit 钩子，确保提交到仓库的代码风格一致。
整体代码质量评分可以达到 85/100，文档质量极高（项目维护了中英文双语 README），测试覆盖完善。
使用 OpenSumi 的前提是你已经决定要构建一个 IDE 产品，而不是找一款现成的编辑器来写代码。
官方提供了多个起步项目：
这些起步项目实际上是 OpenSumi 框架的具体产品化示例，开发者应该基于这些模板进行二次开发，而不是直接修改 OpenSumi 核心代码。
开发环境要求：Node.js >= 18、Yarn、Git、Python 3。国内网络访问需要配置 npm 镜像（淘宝源或 npmmirror）。完整的项目初始化（yarn init）需要下载大量依赖，首次构建耗时约 1-2 小时。
没有 Docker 支持是当前版本的一个遗憾——项目没有提供 Dockerfile 或 docker-compose.yml，无法通过容器化方式快速部署。这意味着如果你想用 OpenSumi 构建一个 Cloud IDE，只能自己实现容器化方案。
1. 框架定位限制了用户群。OpenSumi 的目标用户是"想构建 IDE 产品的团队"，而不是普通开发者。这意味着它天然是一个 B2B 工具，大众认知度远低于 VSCode 系列插件。
2. 缺乏开箱即用的 AI 功能。框架本身只提供了 MCP Client 集成，但具体的 AI 能力（比如代码补全、代码解释、自动生成 PR 描述）需要开发者自己基于 MCP 实现。没有类似 GitHub Copilot 的内置 AI 功能——这是有意为之的设计选择，但也增加了上手成本。
3. 中文生态的国际化挑战。项目由阿里团队主导，中文文档和中文 Issue 较多，但英文社区的活跃度相对有限，可能影响非中文开发者的参与。
4. 维护者集中度风险。虽然项目声称由阿里巴巴和蚂蚁集团联合维护，但从 GitHub 提交记录看，核心贡献者数量有限，社区依赖大厂持续投入。
OpenSumi 代表了一个重要趋势：AI Native IDE 的底层基础设施正在走向开源和标准化。
过去几年，围绕 VSCode 的 AI 扩展（Copilot、Codeium 等）已经非常丰富，但它们都是在"已有编辑器"上叠加 AI。OpenSumi 的思路是反过来的：从底层重新设计，让 AI 能力成为 IDE 的第一性原理。
随着 MCP 协议的普及和 AI Agent 技术的成熟，类似 OpenSumi 的框架可能会成为下一波 AI 开发工具浪潮的基石。2024-2025年，GitHub Star 的快速增长（从2000+增长到3600+）也印证了市场对这类基础设施的强烈需求。
如果你是 AI 工具开发者或企业 AI 转型团队，OpenSumi 值得深入了解——即使你现在不需要自己构建 IDE，它的 MCP Client 架构和插件化设计理念，也能为你提供关于"如何让 AI 与开发工具深度融合"的有益参考。
图2：OpenSumi 官方 Logo（来源：GitHub README）