首款AI Native IDE Framework，OpenSumi 3.0正式发布

作者 | OpenSumi

引言

• 2019 年：由阿里集团和蚂蚁集团联合发起，并开始封闭开发

• 2020 年：发布 1.0 版本，引入插件机制并实现了对 VS Code 插件的兼容

• 2021 年：发布 2.0 版本，提供了基于 React 组件的侧边面板插件机制，定制 UI 界面更加方便

• 2022 年 3 月：项目正式开源，被应用于支付宝小程序 IDE、支付宝小程序云 Codespaces、飞书开发者工具、钉钉开发者工具等多个产品中

• 2023 年 9 月：发布了纯前端版解决方案 CodeBlitz（https://github.com/opensumi/codeblitz）， 它提供了一个无需后端容器支持的、运行在浏览器环境的 IDE 框架，支持代码读写、运行、提交等功能，并且已在 Gitlink、Codeup、AtomGit、Gitee 等平台集成

AI Native IDE Framework

2023 年是 AIGC 引领技术革命的一年，大语言模型取得了前所未有的突破，催生了无数 AI 驱动的应用程序，尤其在研发领域，以 Github Copilot 为代表的 AI 开发助手，通过自动补全、代码重构、代码解释、添加注释、对话问答等功能，极大的提高了开发者的编码效率和准确性。

各大公司都相继推出 GitHub Copilot 竞品插件，例如 Amazon 的 CodeWhisperer、Sourcegraph 的 Cody、智谱的 CodeGeeX、百度的 Comate、阿里云的通义灵码、蚂蚁集团的 CodeFuse，可以说 AI 辅助编码是大模型最早落地的应用之一，也是最具有实用性和商业价值的场景之一。

GitHub Copilot 能取得如此成功，核心优势在于 GPT-4 强大的模型能力，以及专为 VS Code 定制的创新交互方式。可以这么说，没有针对代码场景定制的交互，便得不到如此优秀的使用体验。

例如 Inline Chat 交互，GitHub Copilot 可以非常自如的在编辑器内部弹出输入框，让用户在编辑器里用自然语言和模型交互，并且将生成的代码以 Diff 的方式展示在编辑器内部，开发者只需选择接受或者放弃即可，整体体验一气呵成。

然而 Inline Chat 目前只提供给 GitHub Copilot 这样的“一方插件”使用，其余 Copilot 插件只能通过右键菜单发送至 Copilot 对话面板中，开发者再从对话面板复制或插入到编辑器中，整体交互受限于当前插件 API 的开放程度，开发者使用非 GitHub Copilot 的三方插件就会有明显的割裂感，这也是 GitHub Copilot 的产品壁垒之一。

此外，尽管有补全和对话视图这样的基础 API 功能，VS Code 对于其他研发活动开放出来 AI 扩展功能非常有限，无法对运行、调试、问题面板、终端、Git 等 IDE 功能进行更多的扩展，包括最新的 Participant API 也只供给 GitHub Copilot 对话进行扩展，以至于 Anysphere 的 Cursor、字节的 MarsCode 需要 Fork VS Code 进行定制化开发，以便满足其特殊需求，但这样的分叉又不可避免地增加了后续升级和解决冲突的成本。

市面上迫切需要一个可以高度定制和扩展的 AI 原生 IDE 框架，这个框架应当能够对代码补全、问题诊断、终端操作、调试、对话、IDE 设置等功能进行 AI 封装，并提供即插即用的集成方式，使企业能够便捷的构建出大模型时代的 IDE 产品，并与企业内部的模型服务与 DevOps 工具链深度整合。

核心思路

OpenSumi 在 2023 年 7 月份开始进行 AI 方向的改造，目标是将 OpenSumi 从传统 IDE 框架升级至 AI Native IDE Framework，核心思路如下：

• 行为模式转变：使用命令行或者图形界面来下发命令，转变成描述意图。操作上由原来的命令行或者图形界面，转变成意图描述和多轮沟通。

• 以“用户诉求”为中心，整合场景下相关的任务。以前用户可能会跨多平台完成开发。在新模式下，用户描述清楚意图后，AI 引擎负责具体的调度和执行这要求 AI 能够理解用户的诉求，并根据用户的诉求去拆解任务、智能调度任务。

• 交互模式变革：新模式下，编辑器、与 AI 交互的区域是最核心的区域，弱化 IDE 不常用的功能，例如将原来的菜单栏、设置等删除，terminal、文件树等阅读属性的弱化，强化与 AI 的交互。

• 极低的切换成本：就像 GitHub Copilot 团队倡导的 “It’s a bug if you have to change the way you code when using GitHub Copilot.” OpenSumi 并没有改变开发者现有的开发模式，而是在现有开发习惯上潜移默化的附加 AI 能力，让用户更加方便的使用到 AI 的功能。

如果将现在和未来相比，我们可以判断出一些关键行为的改动：

未来开发工作流

OpenSumi 3.0 已经在蚂蚁集团及阿里集团落地多个 AI 研发场景，在推广过程中我们也积累了一些大模型应用开发经验：

1. 数据准备：在做 AI 功能前，首先准备的是微调数据，例如 OpenSumi 的设置与命令功能、解决冲突数据等等，怎么利用 IDE 中收集的操作数据生成更好的训练数据，怎么准备评测数据来评测这些 AI 功能的效果？在 AI 时代的应用开发数据尤为重要。

2. 高频场景切入：我们发现越不打扰用户的使用习惯，这些功能的使用频率会越高，例如所有 AI 功能中代码补全的使用率肯定是最高，因为用户在开发时只需 tab 就可以一键采纳；我们也将高频 AI 功能移到了编辑器中，藏在右键菜单很难让用户非常方便的使用。

3. 指标演进：在推广过程中我们观察的指标也在一直变化

• 规模：最开始时 AI 版本的使用规模，首先要让开发者用起来

• 使用率：当 AI 版本有一定用户量后，我们主要观察 AI 功能使用率，一些使用率较低的功能我们会做交互优化，例如自然语言生成终端命令，最开始的版本是内置了一个全局 CLI，例如在终端执行“ai 帮我列出当前运行的 Node.js 进程”，这种方式使用率很低，我们参考 warp (https://www.warp.dev) 将终端和 AI 能力深度结合，使用率从 3% 增加到了 20%

• 采纳率：当使用率也上来后，追求的指标就是各个 AI 功能的采纳率，通过工程、prompt、微调、模型升级不断提升采纳率

下文将介绍其中的部分功能改造

功能集成示例仓库：https://github.com/opensumi/core/tree/main/packages/startup

• 行级、内敛补全：写代码时通过 tab 键即可采纳代码建议
• inline-chat：无需使用左侧对话面板，直接在 IDE 中对选中代码进行代码解释、添加注释以及其他命令的快捷操作
• Code Action：用户使用语言服务提供的重构、获取代码建议时会用到代码片段右上角的“小灯泡”，OpenSumi 在“小灯泡”里也会注册和 AI 相关的代码解释、添加注释、代码优化等功能
• 重命名：用户使用重命名功能时自动推荐重命名建议
• 下拉补全：传统语言服务补全排序是按照补全项首字母顺序排序，可以利用不同语言服务提供的扩展能力对下拉补全进行推荐，让用户更短距离选择到想要的补全内容
• ...

OpenSumi 3.0 内置了代码补全模块，开发者无需再额外安装任何插件，即刻体验智能化的行级和片段级代码自动补全。

相较于插件提供的补全能力，OpenSumi 还会利用 IDE 特有优势，充分挖掘和利用 IDE 环境中可获得的广泛上下文数据。这些数据包括但不限于：

• 光标前后内容、文件名、文件语言

• 开发者在 IDE 中的操作历史，包括最近访问、编辑的文件，代码中依赖的文件等

• 语言服务构建的语法上下文

同时，也能通过接口轻松的采集到一些通过插件难以获取到的数据，如“提示代码展示与否”、“代码补全是否发生了部分采纳” 等。

通过内置的提示词工程，将能够让这些信息转化为模型可以理解的高质量提示词，使模型提供更加精确和相关的代码补全建议。

依托于框架内实现的配置能力以及自动化测评（这里提到的自动化测评是基于框架额外实现的插件，用于运行代码补全测试，收集补全效果），对于代码补全场景，提示词工程做的越 “多” 并不意味着越 “好”，以下面一段例子为例：

class AIService implements IAIService {  // 触发补全}

仅仅是通过代码片段进行相似度匹配，得到的模型补全可能并不会理想，更好的方式是获取到该代码语境下依赖的接口定义 （如例子中的 IAIService）, 将其内容作为提示词工程的一部分发给模型，模型才能如预期返回更加准确的补全代码。

在大多数的代码补全场景，我们也通过内部实践总结出了一些用户反馈教好的 “经验”：

1. 代码补全的等待时间一旦超过 1.5s, 用户有较大概率跳过本次补全结果。

2. 代码补全的提示词工程需要设定最长检索阈值，阈值需结合最终的补全代码总 Token 数、服务端响应速度、请求时延综合考虑，提示词工程耗时不应超过 300ms。

3. 在超大文件情况下，需要考虑文件内容对计算带来的负担，应该在进行提示词工程时进行提前截断。

4. 常规的字符串截断方法有按字符截断、按行截断、按语法截断，但实际应用下来，基于上述 1，2 规则限制，按语法截断反而会在大部分补全场景下得不到好的效果，原因是依赖 tree-sitter 进行语法解析耗时还是较大。

5. ...

在 OpenSumi 3.0 中，我们通过模块方式集成了一份针对提示词工程的默认配置，这将让你能更好的开始这块能力建设。

OpenSumi 3.0 开放了编辑器 Inline Chat 功能，这项能力是 VS Code 尚未开放的、专为 GitHub Copilot 设计的“私货” 。开发者能够使用该功能在编码过程中轻松地利用“代码解释”、“添加注释”和“补充测试”等 AI 驱动的功能。Inline Chat 功能也可以直接在用户的编辑器界面弹出输入框，允许开发者采用自然语言与 AI 进行对话，并根据 Diff 视图直接在代码旁边完成接受或拒绝更改的操作。这样的设计极大地提高了工作效率，免去了在代码编辑界面与对话界面之间频繁切换的繁琐步骤，开发者能够更加集中注意力于编码本身，保持心流状态。

选中代码即可弹出 inline chat 组件，在编辑器内部采纳、丢弃、或者重新生成

我们的 Inline Chat 功能其实自推出以来，经历了三次重构与迭代升级，期望达到最佳的用户体验和功能性平衡。

在最初的设计阶段，我们采取了一种较为激进的策略，试图将丰富的功能集成于浮层面板中，以满足我们预设的用户需求。然而，这种做法在实际过程中有很差的用户体验问题，主要表现在：

1. 用户在选中代码时，浮层面板的选中触发造成了不必要的干扰。

2. 浮层面板的尺寸过大，影响了用户对代码的阅读和理解。

3. 输入框的尺寸同样偏大，严重遮挡了用户的视线，影响了代码的可读性。

面对上述挑战，我们重新审视了该功能的核心价值，并围绕以下关键问题进行了深入思考：

1. 如何在不干扰用户正常工作流程的前提下，提供有效的帮助？

2. 用户应如何便捷地查看 inline chat 返回的代码与原始代码之间的差异（diff）？

1. 对浮层面板进行了精简，仅保留了最核心的功能，去除不必要的元素，以减少对用户的干扰。

2. 提供了灵活的触发机制，用户可以通过选中或使用快捷键来激活浮层面板，增加了操作的自由度。

3. 引入了 inline diff editor 功能，使用户能够直观地查看并对比 inline chat 提供的代码修改建议与原始代码，同时可以方便地选择是否采纳这些建议。

在第三次迭代中，我们对功能进行了进一步的优化和改进。现在，浮层面板的展示位置可以动态调整，不再固定于某个特定角落，而是更加智能地在用户选中区域的周边寻找合适的空白区域进行展示，从而最大限度地减少对代码阅读的影响。

经过这一系列的迭代和优化，我们的最新版 inline chat 功能也已经支持通过模块 API 的方式进行集成，以便集成方使用。我们诚邀各位用户和开发者体验这一经过精心打磨的功能，并提供宝贵的反馈。

OpenSumi 3.0 支持自动识别编辑器中的函数、代码块等，快速唤起 AI 快捷操作入口，支持添加注释、解释代码、生成单测等功能。

这一功能基于 web-tree-sitter 和 WebAssembly，并提供了一套良好的接口，可以获取到各语言的接口声明或者函数声明。不同语言的 tree-sitter 语法被提前构建成 WASM，发布到 npm 源并托管到 CDN 上，再在浏览器端加载。

自动识别函数进行 AI 快捷操作

用户在编辑器内使用“重命名符号”功能时，OpenSumi 3.0 会通过 AI 能力自动推荐可选名称。用户点击 AI 推荐名称后，可自动帮助用户重命名所选符号并修改关联代码。

这项功能也是 VSCode 专门为 GitHub Copilot 开放的能力，在 OpenSumi 里你可以任意使用。

在用户打开重命名面板后，我们会通过语言服务获取到用户此时需要重命名的字符串，然后结合代码上下文生成 prompt 发送给大模型。另外构造重命名候选项的 prompt 需要考虑不少东西，我们需要告诉模型要重命名哪个位置的字符串，符号位置的上下文，要遵守的代码风格和返回格式。

在使用重命名功能时智能推荐名称

对话面板

类似于其他 Copilot 插件，OpenSumi AI 模块为开发者提供一个交互式的对话面板，开发者能够直接与 AI 模型对话，从而实现更为直观的编程体验。不仅仅是基础的对话功能，OpenSumi 还进一步内置了一系列开发者常用的 AI 命令，这些包括但不限于代码解释、自动添加代码注释等实用功能。

在对话面板完成知识问答

为了提升 AI 模型对 OpenSumi 特有环境的理解能力，蚂蚁集团对内部模型进行了额外的训练，微调了专属 OpenSumi 的命令和设置数据集，模型微调确保了 AI 能够更准确地解析用户意图，从而调用 IDE 中的相应命令与设置。

后续考虑开源 OpenSumi 命令及设置数据集

通过自然语言调用 IDE 命令

IDE Agent

OpenSumi 3.0 主推从插件向智能 Agent 转型，IDE Agent 会逐步取代插件的角色，开发者可以通过自然语言直接激活和使用 IDE 的功能，而无需专门学习不同插件的操作方法。开发者仅需简单的对话式指令，即可实现复杂的功能调用。企业可以开发一系列 Agent 工具来无缝对接平台服务，构建一个自然语言交互的开发环境。

未来的展望中，智能体将能够自动编排和协调各种 Agent 的工作，进一步简化开发过程。OpenSumi IDE Agent 不仅与 VS Code 提议中的 Chat Participant API 兼容，而且还提供了 React 组件来渲染对话卡片，增强了用户体验。

IDE Agent 调用链路

举个例子：开发者通过自然语言对话，可以轻松完成代码提交（commit）和拉取请求（PR）。结合模型的能力，Git Agent 甚至能自动生成 Commit Message、PR 的标题和描述，从而简化了版本控制的流程并提高了效率。

使用 Git Agent 完成代码 commit 能力

使用 Git Agent 提交 PR

问题诊断

在 IDE 环境中编写和运行代码时，开发者时常会遇到各种报错和异常。在过去，这些异常信息多在终端或者调试控制台中显示，而开发者往往需要手动复制这些信息到搜索引擎或者 Copilot 的对话面板上进行查询，之后再切换回 IDE 进行问题的修复。这一过程不仅繁琐，而且效率低下。

为了简化这一流程，OpenSumi 3.0 引入了智能错误捕获机制，当异常信息在终端或调试控制台中弹出时，OpenSumi 将自动捕获这些错误信息，并提供“一键排查”功能。用户只需点击一下，即可快速定位问题并获取解决方案，甚至是直接修复的代码。这种集成化的排错和修复体验极大地节省了开发者的时间，提高了工作效率，同时也降低了从错误检测到问题解决的认知负担，开发者可以更加专注于代码创造本身，而非消耗宝贵时间在解决环境和调试问题上。

前端 tsc 编译错误捕获与解决

异常信息的捕获是一个复杂且关键的环节。由于异常信息的表现形式多样，它们通常以不同格式出现在终端输出的字符串中。这种多样性源于不同的应用程序、编程语言和框架，它们生成的异常日志信息缺乏统一标准，这使得构建一个能够涵盖所有情况的解决方案变得极具挑战性。

为了满足业务方对异常信息捕获的广泛需求，我们设计了一套高度可定制的 API 接口。该接口允许用户根据其特定的业务需求，定义和实施个性化的异常信息提取规则。通过这种方式，用户可以精确地捕获、分析并处理异常信息，从而提高问题解决的效率和准确性。

此外，为了简化用户的使用过程，我们已经集成了一系列针对不同编程语言的预设提取规则。这些规则不仅可以直接应用于大多数常见场景，而且用户还可以根据自己的需要对其进行继承和扩展。

以下是如何使用我们的 API 进行异常信息捕获的示例代码：

registry.registerTerminalInlineChat(    {        id: 'terminal-catch',        name: 'catch',    },    {        // 定义触发规则，包括预设的和自定义的matcher        triggerRules: [            NodeMatcher,            TSCMatcher,            NPMMatcher,            ShellMatcher,            JavaMatcher,            // 下面是一个自定义的matcher示例            class extends BaseTerminalDetectionLineMatcher {                doMatch(output) {                    // 检查输出中是否包含特定的 error 关键字                    return output.some((t) => t.content.includes('error'));                }            },        ],        // 定义执行逻辑，当触发规则匹配成功时执行        execute: async (stdout, stdin, rule) => {            // 具体实现细节根据业务需求定制        },    },);

通过上述示例，用户可以快速地将问题诊断功能集成到自己的产品当中

智能终端

得益于 OpenSumi 出色的自定义模块化能力以及 Xterm.js 终端渲染框架的强大能力，OpenSumi 借助 Shell 中植入 OSC 转义控制符的动态监控和解析，使得 IDE 层可以感知到终端的运行状态，例如终端此时处于 Prompt 状态，或者用户正在终端输入命令或者字符，亦或者某些命令运行的开始和结束，这样便可以让传统的终端交互变得更加可定制化和智能化。

借助终端的状态感知，OpenSumi 便可以根据目前的终端状态和用户终端交互做出针对性的优化，比如说当终端处于 Prompt 状态，并且检测到用户输入的第一个字符是 “#” 时，通过 Xterm.js Decoration 为在终端输入光标的周围渲染出 AI 的交互弹框，用户输入的自然语言通过大模型处理后返回数个可选的 Shell 命令，然后在用户选择终端命令时，通过 OpenSumi 的终端模块发送命令到 Shell 中，之后只需要敲击回车便可以执行命令。

这是非常自然的通过对话完成终端命令的调用。对于 Linux Shell 的重度用户来说，终于可以扔掉手中的 CheatSheet，享受 AI 带来的便利。OpenSumi 将来还会继续优化这一功能，让终端补全功能的进一步智能化和易用性提升，与 IDE 编辑器内部的代码补全体验相媲美。

自然语言调用终端命令

智能解决冲突

在传统的软件开发流程中，代码冲突的解决是一项耗时且需要开发者主观判断的任务，开发者需决定哪些代码应当保留，哪些应当删除。蚂蚁集团内部代码托管平台通过大量线上真实解决冲突数据对 AI 模型进行持续微调，目前微调后的模型解决冲突准确率在 75% 左右。

使用线上数据持续 finetuning

通过 OpenSumi 3.0 开发者可以快速搭建智能解决冲突场景，这不仅可以减少手动解决代码冲突的工作量，还能提高整体的解决速度和效率。

通过 3-way 模式一键解决代码冲突

OpenSumi Design

OpenSumi 3.0 也发布了 OpenSumi Design，对于 IDE 中的组件、UI 进行了明确的规范。

除了上述 AI 原生的 IDE 交互风格以外，UI 皮肤也进行了进一步升级，OpenSumi Design 提供一种更为清新、现代且高度定制的用户界面。

OpenSumi Design 里的亮色风格皮肤

CodeBlitz 升级

随着 OpenSumi 3.0 的发布，CodeBlitz（OpenSumi 的无容器、纯前端 IDE 解决方案 https://github.com/opensumi/codeblitz）同样迎来了 AI 技术的升级。

在这一新版本中，CodeBlitz 不仅延续了其在“阅读”代码方面的强大能力（例如在阅读代码时解释当前代码，这在代码服务平台非常有用），而且通过 AI 的赋能，扩展了其功能范围，现在即便是 Java、Go、C++ 等后端语言，在纯浏览器上运行的 CodeBlitz 上也拥有了强大的 AI 代码补全功能。

无需容器的 CodeBlitz AI Native 版本

通信协议升级 - OpenSumi RPC

OpenSumi 之前通信方案与 Eclipse Theia 一致，都是通过 vscode-jsonrpc 做为通信协议依赖库。vscode-jsonrpc 是一个基于 JSON RPC 2.0 协议进行通信的 RPC 库，在 OpenSumi 内被用于 IDE 客户端和服务端、插件端之间的通信。JSON RPC 是一个无状态、轻量级的远程过程调用（RPC）协议，它允许数据以 JSON（JavaScript Object Notation）格式被发送和接收。

OpenSumi 2.0 前后端通信

虽然 JSON RPC 简单易用，但也会有一些性能问题：

1. 文本格式的可读性导致的低效率：JSON 是为了人类可读性和简单性设计的，而不是为了效率。比如，数字可能会包含额外的空格或者格式化字符，字符串可能包含很多转义字符，这些内容会导致传输数据的冗余。

2. 大量数据传输：当需要传输大量数据时，由于 JSON 是文本格式，它的大小通常会大于二进制格式。这意味着网络传输会占用更多的带宽，导致传输速度变慢。

3. 解析和序列化开销：JSON 的序列化和反序列化需要时间和计算资源。对于 IDE 这种高频率的消息交换，这个过程的开销可能会对系统性能产生影响。插件进程往 IDE 客户端通信甚至需要两次序列化和反序列化，对 CPU 和内存的消耗较大。

例如 OpenSumi 2.0 版本是直接将二进制当成数组进行 JSON 序列化的，这会导致传输数据的膨胀，在 JavaScript 的世界中，"hello-world，你好世界"这个字符串转换为二进制仅会占用 26 个字节，这个 Buffer 使用数组表示再转为 JSON 字符串表示后会占用 129 个字节。这一个 Buffer 膨胀了近 5 倍。

上述问题在 Cloud IDE 场景中尤为明显，常常出现弱网卡顿、大文件打不开等问题，导致 Cloud IDE 体验相较于本地研发还是有不少差距。

OpenSumi 3.0 将通信部分进行了重构，去除了 vscode-jsonrpc 的依赖，重写了 OpenSumi RPC，利用 Fury（蚂蚁集团 2023 年开源的基于 JIT 动态编译的高性能多语言序列化框架，目前已捐献给 Apache 基金会 https://github.com/apache/incubator-fury） 将原本文本通信协议改为二进制通信，前端与后端、后端与插件进程的通信性能得到了非常大的提升，特别是一些大文件、二进制文件，通信速度得到了百倍的提升。

二进制的序列化方案可以将对象数组等结构转换为紧凑，高效的二进制格式，方便在网络传输、持久化存储或进程间通信中高效地传输和重建原始数据。二进制格式直接利用字节位来编码数据，比如字节的前四位代表序列化协议版本，一些控制头，第五位代表第一个字段的类型等等。在二进制的序列化方案中，我们需要给定数据的类型，序列化框架会对类型进行编译、代码生成等，从而加速在运行时的解析速度，因为这避免了在运行时的类型推断和条件判断等逻辑。由于二进制序列化直接操作字节流，无需进行字符编码和解码，所以在其中存取新的二进制流和字符串流都非常方便，不会有太多性能损耗，二进制的体积也不会膨胀。

OpenSumi 3.0 前后端通信

OpenSumi 后续会将 opensumi-rpc 独立成包，给三方插件与语言服务通信多一种选择

以下三个例子是前端请求后端的不同类型内容时，两种 RPC 的性能表现：

同时我们也使用 Fury 优化了网关的解析性能，得益于二进制的数据包结构，我们读取数据包的前几个字节就能判断出包的类型以及要转发给哪个进程。

在小型数据（10k, 50k) 上我们得到了比 JSON 快 100 倍的结果，在更大型的数据上，这个数据会更好。

在进行这些优化后，OpenSumi RPC 支持了传输超过 200M 的文件，同时也支持流式传输，开发体验相较 2.0 有非常大的提升。

基础依赖升级

OpenSumi 3.0 对于底层诸多依赖进行了升级，包括不限于：

• Monaco 从 0.35.0 升级至 0.47.0

• React 从 16.8 升级至 18.2.0

• Mobx 从 5.9.4 升级至 6.12.0

• Webpack 从 4.39.3 升级至 5.90.0

基础依赖的升级让我们得以从框架底层实现更多原本难以实现的功能，如：

自带 WebAssembly 运行时的 opensumi.run

在开源了纯前端版本解决方案的同时，我们注意到过去的几年社区出现了许多可以在浏览器环境中模拟一个操作系统以便于运行 Node.js 的项目。基于对阿里和蚂蚁集团内部的需求，我们也同样自研了一款基于 WebAssembly 技术的 POSIX 运行时（我们暂时称它为 WebC），它兼容 Node.js 16 ，内置了 bash、libgit2 等大常用命令，并支持部分编译为 wasm 格式的应用。我们将 OpenSumi 纯前端版本与 WebC 深度结合，开发了可能是国内首款基于 WebAssembly 技术的纯前端在线 IDE opensumi.run (https://opensumi.run/opensumi/run)。

插件进程支持

如果你体验过社区其他类似的纯前端编辑器产品，你会发现它们自带的 TypeScript/JavaScript 语言服务功能似乎不是那么的 “智能”。这是由于它们完全基于纯浏览器构建，没有完整的文件系统 (特别是同步调用)，所以只能运行 WebWorker 版本的 tsserver （TypeScript 内置的 Language Server），这个版本的 TypeScript 语言服务器所提供的功能只能说是非常简陋，当你尝试从 foo.ts 文件点击跳转到 bar.ts 文件，大概率会抛出错误。因为语言服务器没有对整个项目进行索引，它无法知道这个 文件 bar 到底是 bar.js 还是 bar.ts，又或者是 bar.tsx、bar.jsx，只能傻傻地让编辑器尝试打开没有后缀的文件 bar，很显然，这个文件并不存在。

这里需要了解一个基础概念就是，对于 OpenSumi 来说有两个插件环境，一个运行在本地 Node.js 环境，由一个 IDE Server 端来启动（一个简易的 Node.js 服务端应用），由于它可以访问完整的 Node.js API，绝大多数 CloudIDE 插件都运行在这个插件环境中。而另一个插件环境运行在 WebWorker 中，它无法直接访问系统 API，只能通过主线程进行异步调用，所以只能运行一些环境无关的插件，例如对文档的修改、装饰以及对 IDE 主界面的增强等。

而基于 WebC 天然的 Node.js 环境，我们将原本需要由 OpenSumi Server 端来启动的插件进程 (Node.js 版本) 无缝运行在了由 WebC 模拟的进程中，由于去掉了中间作为转发的 Server 端，插件进程可以直接与主线程通过浏览器的 MessageChannel 通信，通信成本反而更低。

基于 WebContainer 的纯前端 IDE 插件进程

FaaS 开发场景实践案例详见 WebContainer 在支付宝云开发的实践

高性能全文搜索

在之前的纯前端版本中，由于没有真正的 文件系统的概念，所以对于简单的查看、浏览仓库场景，很难实现性能较高的文件查找（只能对接 GitHub API 进行搜索）。而基于 WebC 的文件系统，使得我们即使在没有使用 ripgrep 的情况下，仅通过少量的代码改动就同样实现了极快的搜索性能。

基于 webcontainer 的全文搜索功能

除了上述一些特性以外，opensumi.run 也内置了 GitLens 以及基础的 Git 提交等功能，目前版本的 opensumi.run 仅作为技术预览版，后续我们将继续不断完善 WebC 与 opensumi.run 的使用体验，并考虑在不久的将来开源整套 WebAssembly 运行时。

插件市场迁移至支付宝小程序云（https://ide.cloud.alipay.com/marketplace），插件下载更加稳定。

OpenSumi 正在联合 OpenAnolis（龙蜥社区）及 OpenEuler 社区成立 IDE Sig 组，将以开放的态度，推动国内 IDE 领域相关的技术交流、信息扩散、资源共享、工具共建。

目前龙蜥社区 IDE SIG 组已经成立，详见 https://openanolis.cn/sig/ide。

随着 Devin和 GitHub Copilot Workspace 的问世，研发领域 AI Agent 的时代在 2024 年提前到来。

AI Agent 是一种智能实体，具备感知环境、做出决策并执行任务的能力，在软件开发的过程中，人类开发者的角色逐渐转变为 AI Agent 的“Copilot”，在 AI Agent 遇到问题或需求帮助时提供指导和提示。

展望未来，开发者只需定义明确的目标，例如添加新的接口功能，而 AI Agent 则有能力在一个具备运行环境的 Workspace 中，自主操控编辑器、终端和浏览器等工具，自动化完成一系列标准的软件开发任务。

我们坚信，在不久的将来，IDE 环境中必将植入一款 AI Agent，它将成为串联整个软件开发和交付生命周期的关键纽带，涵盖从知识学习、依赖安装、代码编写、Bug 修复、构建、运行、调试、测试、代码提交到部署等各个阶段。

OpenSumi 憧憬着与您共同见证并参与这一令人振奋的技术革新之旅， 欢迎大家使用 OpenSumi 3.0（https://github.com/opensumi/core）