首款AI Native IDE Framework，OpenSumi 3.0正式釋出

作者 | OpenSumi

引言

OpenSumi是一個開源的、高效能和高度可客製的 IDE 研發框架，它為開發者提供了一套工具和元件，用以構建雙端（Web 和 Electron）的整合式開發環境。與 VS Code 和 IntelliJ IDEA 等 IDE 產品不同的是，OpenSumi 定位是可延伸的 IDE 框架，著重於降低客製難度，使開發者能夠輕松組合功能模組，以滿足特定的業務需求。

OpenSumi 主要裏程碑如下：

今天，OpenSumi 將帶來全新的 3.0 版本，為大模型時代的開發者帶來 AI 原生的研發體驗！

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，核心思路如下：

如果將現在和未來相比，我們可以判斷出一些關鍵行為的改動：

未來開發工作流

OpenSumi 3.0 已經在螞蟻集團及阿裏集團落地多個 AI 研發場景，在推廣過程中我們也積累了一些大模型套用開發經驗：

1. 數據準備 ：在做 AI 功能前，首先準備的是微調數據，例如 OpenSumi 的設定與命令功能、解決沖突數據等等，怎麽利用 IDE 中收集的運算元據生成更好的訓練數據，怎麽準備評測數據來評測這些 AI 功能的效果？在 AI 時代的套用開發數據尤為重要。

2. 高頻場景切入 ：我們發現越不打擾使用者的使用習慣，這些功能的使用頻率會越高，例如所有 AI 功能中程式碼補全的使用率肯定是最高，因為使用者在開發時只需 tab 就可以一鍵采納；我們也將高頻 AI 功能移到了編輯器中，藏在右鍵選單很難讓使用者非常方便的使用。

3. 指標演進 ：在推廣過程中我們觀察的指標也在一直變化

下文將介紹其中的部份功能改造

功能整合範例倉庫：https://github.com/opensumi/core/tree/main/packages/startup

智慧編輯器

開發者使用 IDE 最高頻的模組是編輯器模組，我們針對編輯器模組做了整體 AI 升級。OpenSumi 會盡可能的不改變開發者現有工作方式的情況下接受程式碼建議，包括：

程式碼補全

OpenSumi 3.0 內建了程式碼補全模組，開發者無需再額外安裝任何外掛程式，即刻體驗智慧化的行級和片段級程式碼自動補全。

相較於外掛程式提供的補全能力，OpenSumi 還會利用 IDE 特有優勢，充分挖掘和利用 IDE 環境中可獲得的廣泛上下文數據。這些封包括但不限於：

同時，也能透過介面輕松的采集到一些透過外掛程式難以獲取到的數據，如「提示程式碼展示與否」、「程式碼補全是否發生了部份采納」 等。

透過內建的提示詞工程，將能夠讓這些資訊轉化為模型可以理解的高品質提示詞，使模型提供更加精確和相關的程式碼補全建議。

依托於框架內實作的配置能力以及自動化測評（這裏提到的自動化測評是基於框架額外實作的外掛程式，用於執行程式碼補全測試，收集補全效果），對於程式碼補全場景，提示詞工程做的越 「多」 並不意味著越 「好」，以下面一段例子為例：

class AIService implements IAIService { // 觸發補全}

僅僅是透過程式碼片段進行相似度匹配，得到的模型補全可能並不會理想，更好的方式是獲取到該程式碼語境下依賴的介面定義 （如例子中的 IAIService）, 將其內容作為提示詞工程的一部份發給模型，模型才能如預期返回更加準確的補全程式碼。

在大多數的程式碼補全場景，我們也透過內部實踐總結出了一些使用者反饋教好的 「經驗」：

1. 程式碼補全的等待時間一旦超過 1.5s, 使用者有較大機率跳過本次補全結果。

2. 程式碼補全的提示詞工程需要設定最長檢索閾值，閾值需結合最終的補全程式碼總 Token 數、伺服端響應速度、請求時延綜合考慮，提示詞工程耗時不應超過 300ms。

3. 在超大檔情況下，需要考慮檔內容對計算帶來的負擔，應該在進行提示詞工程時進行提前截斷。

4. 常規的字串截斷方法有按字元截斷、按行截斷、按語法截斷，但實際套用下來，基於上述 1，2 規則限制，按語法截斷反而會在大部份補全場景下得不到好的效果，原因是依賴 tree-sitter 進行語法解析耗時還是較大。

5. ...

在 OpenSumi 3.0 中，我們透過模組方式整合了一份針對提示詞工程的預設配置，這將讓你能更好的開始這塊能力建設。

Inline Chat

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 的方式進行整合，以便整合方使用。我們誠邀各位使用者和開發者體驗這一經過精心打磨的功能，並提供寶貴的反饋。

CodeAction 增強

OpenSumi 3.0 支持自動辨識編輯器中的函式、程式碼塊等，快速喚起 AI 快捷操作入口，支持添加註釋、解釋程式碼、生成單測等功能。

這一功能基於 web-tree-sitter 和 WebAssembly，並提供了一套良好的介面，可以獲取到各語言的介面聲明或者函式聲明。不同語言的 tree-sitter 語法被提前構建成 WASM，釋出到 npm 源並托管到 CDN 上，再在瀏覽器端載入。

自動辨識函式進行 AI 快捷操作

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 使用範例

以下是如何使用我們的 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） 將原本文本通訊協定改為二進制通訊，前端與後端、後端與外掛程式行程的通訊效能得到了非常大的提升，特別是一些大檔、二進制檔，通訊速度得到了百倍的提升。

https://fury.apache.org/docs/introduction/benchmark

二進制的序列化方案可以將物件陣列等結構轉換為緊湊，高效的二進制格式，方便在網路傳輸、持久化儲存或行程間通訊中高效地傳輸和重建原始數據。二進制格式直接利用字節位來編碼數據，比如字節的前四位代表序列化協定版本，一些控制頭，第五位代表第一個欄位的型別等等。在二進制的序列化方案中，我們需要給定數據的型別，序列化框架會對型別進行編譯、程式碼生成等，從而加速在執行時的解析速度，因為這避免了在執行時的型別推斷和條件判斷等邏輯。由於二進制序列化直接操作字節流，無需進行字元編碼和解碼，所以在其中存取新的二進制流和字串流都非常方便，不會有太多效能損耗，二進制的體積也不會膨脹。

OpenSumi 3.0 前後端通訊

OpenSumi 後續會將 opensumi-rpc 獨立成包，給三方外掛程式與語言服務通訊多一種選擇

以下三個例子是前端請求後端的不同型別內容時，兩種 RPC 的效能表現：

同時我們也使用 Fury 最佳化了閘道器的解析效能，得益於二進制的封包結構，我們讀取封包的前幾個字節就能判斷出包的型別以及要轉發給哪個行程。

在小型數據（10k, 50k) 上我們得到了比 JSON 快 100 倍的結果，在更大型的數據上，這個數據會更好。

在進行這些最佳化後，OpenSumi RPC 支持了傳輸超過 200M 的檔，同時也支持流式傳輸，開發體驗相較 2.0 有非常大的提升。

基礎依賴升級

OpenSumi 3.0 對於底層諸多依賴進行了升級，包括不限於：

基礎依賴的升級讓我們得以從框架底層實作更多原本難以實作的功能，如：

1. 支持未改動程式碼自動折疊能力，更好地閱讀 Diff 程式碼

未改動的程式碼區域支持預設折疊，最佳化大檔下的程式碼 Diff 檢視體驗。

2. 更完整的程式碼補全能力支持及 Toolbar 能力

3. 更好的內建元件實作

我們進一步最佳化了內部一批內建元件的功能體驗，如 Modal、Dialog、Popover、Notification 等。

內建 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 開發場景實踐案例詳見

高效能全文搜尋

在之前的純前端版本中，由於沒有真正的 檔案系統的概念，所以對於簡單的檢視、瀏覽倉庫場景，很難實作效能較高的檔尋找（只能對接 GitHub API 進行搜尋）。而基於 WebC 的檔案系統，使得我們即使在沒有使用 ripgrep 的情況下，僅透過少量的程式碼改動就同樣實作了極快的搜尋效能。

基於 webcontainer 的全文搜尋功能

除了上述一些特性以外，opensumi.run 也內建了 GitLens 以及基礎的 Git 送出等功能，目前版本的 opensumi.run 僅作為技術預覽版，後續我們將繼續不斷完善 WebC 與 opensumi.run 的使用體驗，並考慮在不久的將來開源整套 WebAssembly 執行時。

外掛程式市場遷移

外掛程式市場遷移至支付寶小程式雲 （https://ide.cloud.alipay.com/marketplace） ，外掛程式下載更加穩定。

社群 IDE SIG 組籌建

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）