JetBrains Air 登陸 IDE 開放 EAP，但真正押注的是協調能力

JetBrains 已將 JetBrains Air in IDEs 開放予早期存取，將五個支援的編程代理帶進專為平行處理任務而設的工作區。此舉與其說是新增另一個聊天機械人，不如說是在決定開發者會在哪裡監督由 AI 生成的程式碼。

Air 原生支援 Codex、Gemini、GitHub Copilot、Claude Agent，以及 JetBrains 自家的 Junie。它亦可透過 Agent Client Protocol（ACP）連接其他相容工具；ACP 是編程代理與開發環境之間的通用介面。

這使 JetBrains 與以模型為中心的軟件開發觀點形成對壘。在這個模式中，開發者會追隨當前表現最佳的代理。JetBrains 則押注，真正具持久價值的產品，是能提供脈絡、追蹤同步進行工作，並協助人類審查每項變更的環境。

早期焦點是 EAP 擴展至五個 IDE。JetBrains 現時的文件則指出，外掛支援其 IDE 產品線中的所有產品，Android Studio 除外，令最終涵蓋範圍比最初的說法更廣。更重要的數字仍是五個代理，因為 Air 將它們視為同一控制介面內可互換的工作者。

JetBrains 並非要求開發者放棄 Codex、Claude、Gemini、Copilot 或 Cursor。它希望這些系統在 JetBrains 產品內運作。這個分野令 JetBrains Air EAP 成為一項測試：當代理承擔更多實作工作時，IDE 能否繼續成為軟件開發的核心。

JetBrains Air in IDEs 將工作區與模型分開

JetBrains Air in IDEs 是協調層，而不是新模型，亦不是 AI Assistant 的改名版本。

JetBrains 在 10 月初透過 Marketplace 及其 IDE 的 2026.3 EAP 版本推出 EAP。該公司的 Air EAP 公告表示，外掛推出時並未安裝任何代理，亦不充當 AI 供應商。

這個設計相當重要，因為它把使用者常常視作一體的三類產品分開。模型負責生成或理解文字。編程代理負責規劃任務、操作工具、編輯檔案及執行指令。Air 則在 IDE 內組織這些代理及其工作。

開發者可連接已在使用的代理，但須遵守各供應商的驗證規則。他們毋須只為運行相容的第三方代理而訂閱 JetBrains AI。Air 可偵測本機安裝的代理、透過登錄檔提供代理，並重用支援的授權方式。

五個代理獲明確提供第一級支援：Codex、Gemini、GitHub Copilot、Claude Agent 及 Junie。Cursor 和其他工具可透過 ACP 相容性接入，但確切介面與授權途徑會因代理而異。

產品圍繞工作階段而非單一持續聊天來組織工作。每個工作階段代表一項任務、其代理、脈絡、進度及所產生的變更。開發者可檢視跨專案的進行中工作、識別等待輸入的工作階段，並開啟已完成的變更作審查。

Air 亦支援預設配置。預設配置會儲存代理、模型選擇、推理力度、存取級別及其他啟動設定。這讓團隊可為日常修正、較大型重構、審查或實驗建立不同配置。

這個結構令 IDE 成為調度中心。開發者可將失敗測試交給 Codex、把文件變更分派予 Gemini，並要求 Junie 檢視效能問題。Air 並未聲稱這些代理會像集體智能般互相協作。它為每項任務提供可見位置，並將輸出保留在審查流程之內。

這個分野可避免對「運行五個 AI 代理」一語產生重要誤解。Air 原生支援五個具名代理，但不要求五者同時運行。它亦不保證同時運行的代理會產生互相相容的程式碼。

JetBrains 目前的 Air 文件 指出，本機代理在開發者的電腦上運行。Air 透過協定與 ACP 相容代理通訊，而命令列代理則可在 IDE 內保留其終端機介面。

外掛可安裝於 2026.2 版本，並已內置於 2026.3 EAP 版本。JetBrains 現時記錄的支援範圍涵蓋其 IDE，Android Studio 除外。可用性、代理授權及雲端執行仍可能取決於使用者的產品版本及機構設定。

這些細節令它不止是一次發佈更新。JetBrains 正圍繞委派工作重組其 AI 介面，同時保留現有編輯器、除錯器、檢查功能、導覽及版本控制工具，讓它們緊貼結果。

為何 JetBrains 正超越 AI 聊天面板

JetBrains 面對的壓力源於開發者行為的轉變，而不只是語言模型變得更強。

第一代 IDE AI 功能集中於自動完成及聊天。開發者選取程式碼、提出問題、獲得答案，然後決定要貼上或套用甚麼。這種互動很自然地適合置於側邊面板。

編程代理帶來不同的管理問題。它們可讀取多個檔案、制定計劃、執行指令、修改儲存庫，並在交還控制權前運行測試。開發者亦可在首個代理仍處於活躍狀態時啟動另一項任務。

JetBrains 表示曾嘗試將更多代理放進現有的 AI Assistant 聊天介面。公司得出的結論是，監督同步進行的任務需要產品圍繞工作狀態而非對話紀錄來組織。

這個結論解釋了為何 Air 與 AI Assistant 在 EAP 期間維持分開。AI Assistant 繼續在既有 IDE 體驗中提供聊天、補全、程式碼洞察、下一步編輯建議及代理存取。Air 則將代理與工作階段視為主要工作單位。

JetBrains 預期 Air 將隨時間成為其主要的代理式介面，但尚未宣布移除 AI Assistant。使用者可保留已安裝的 AI Assistant，但若透過 AI Assistant 通知安裝 Air，舊外掛會被停用，以避免兩個介面同時運行。使用者可在外掛設定中重新啟用它。

更深層的競爭問題，是誰擁有開發者的注意力。以代理為先的編輯器及命令列工具可將工作從傳統 IDE 中抽走。若開發者大部分時間都在其他地方發出提示及審閱修補程式，IDE 便有可能淪為只在困難除錯時才使用的次要場所。

Air 嘗試扭轉這種流向。它不強迫開發者在 JetBrains 與外部代理之間二選一，而是邀請外部代理進入 JetBrains 環境。代理負責規劃與生成，IDE 則提供儲存庫脈絡及驗證工具。

這種做法亦應對模型快速更替。領先的編程模型更替速度，可能快過機構更換開發環境的速度。一家公司可能偏好使用某個代理處理 Java 遷移、另一個處理介面工作，並為包含受限制程式碼的儲存庫使用內部代理。

即使 Junie 未能在每項比較中勝出，只要 Air 仍是管理這些系統的地方，JetBrains 亦毋須讓 Junie 勝出。公司可從更強的第三方代理中獲益，因為它們令共享工作區更實用。

這正是 ACP 為何居於核心位置。ACP contract 定義客戶端（例如 IDE）與代理之間的通用連接。代理保留自身的模型選擇、工具、驗證及規劃行為。

JetBrains 將這個邊界比作 Language Server Protocol 的角色。編輯器毋須為每個相容的語言伺服器各自建立私有整合。ACP 旨在減少每個代理與每個開發環境之間需要專門外掛的情況。

這個類比有其限制。編程代理可以執行指令及修改儲存庫的大量部分，因此其權限與副作用帶來更大風險。儘管如此，通用連接層可減少整合工作，並降低轉換代理所帶來的干擾。

對 JetBrains 而言，這創造了策略性機會。Cursor、Codex、Claude、Copilot 及 Gemini 毋須在模型層面被擊敗。它們可成為 JetBrains 多代理 IDE 內的選項。

IDE 成為代理工作的控制平面

Air 的核心押注是：隨着程式碼生成變得更容易，驗證會變得更有價值。

生成修補程式只是軟件開發其中一部分。仍需有人判斷修補程式是否符合需求、保留架構、通過測試、遵守安全邊界，以及在真實情況下正確運作。

JetBrains 已擁有許多用於這類工作的工具。其 IDE 能理解符號、類型、參照、專案結構、測試執行器、版本控制、資料庫、除錯器及效能分析檔。Air 將代理活動連接至這些既有介面。

代理可接收檔案、提交、截圖及可重用指示作為脈絡。開發者可檢查已變更檔案、比較差異、導覽相關程式碼，並運行專案，毋須將結果轉移至另一個應用程式。

這種連接可減少重複探索。編程代理往往會花費 token 列出目錄、開啟設定檔及定位相關符號。由 IDE 提供的脈絡可讓它較早鎖定正確程式碼，但節省幅度會因代理及任務而異。

Air 亦讓受支援代理存取 IDE 技能，以進行除錯、效能分析、資料庫探索及語意程式碼搜尋等工作。JetBrains 表示，這些工具可改善某些任務的結果，但這項說法仍需在不同儲存庫及程式語言中進行廣泛測試。

代理工作階段成為此工作流程的容器。它記錄已選代理、對話、活動、已變更檔案、提交及所報告成本。工作階段可在多個專案之間保持可見，協助開發者發現已完成或需要介入的工作。

這個模式不同於開啟五個聊天分頁。聊天分頁主要保留對話；Air 工作階段則將對話連結至儲存庫狀態及審查操作。

試想一名負責某項服務、並面對失敗整合測試的開發者。一個工作階段可調查失敗原因；第二個可在獨立分支更新相關相依套件；第三個可檢查受變更影響的文件。

當這些工作階段推進時，開發者可繼續在主要 checkout 中工作。當其中一項完成後，IDE 便成為審查差異、運行檢查、核對測試，以及決定結果是否應併入目標分支的地方。

這個流程符合工程工作的更廣泛轉變。開發者愈來愈多協調生成的變更，而不是親手輸入每一項實作。他們的責任沒有消失，而是轉向指定任務、提供脈絡、檢視證據及解決衝突。

JetBrains 正將 IDE 定位為承擔這些責任的控制平面。這個詞指協調工作者與狀態、但本身並非工作者的介面。只要 Air 令多個代理更易於監督，它便毋須生成最佳修補程式也能帶來價值。

模型亦保留使用者的選擇權。開發者可在供應商允許的情況下連接現有訂閱、選用 JetBrains AI，或使用本機已設定的 ACP agent。Air 本身並不提供專有模型。

這種彈性具有策略重要性。綁定單一模型的封閉工作區，會承襲該模型的弱點及商業變動。多 agent 工作區則可讓開發者更換 agent，同時保留專案慣例及審查工具。

已在建立可搜尋工程脈絡的團隊，或會認出同一種模式。可持續的資產並非單一答案，而是連結程式碼、決策、文件與審查的結構。 技術知識庫可透過保留應在單一編碼任務以外持續留存的資訊，補足 agent 工作階段。

Air 本身無法解決這個更廣泛的知識問題。一個工作階段包含有用的工作脈絡，但團隊仍需要保存架構決策、事故及需求的長期記錄。IDE 可以協調實作，而共享知識系統則保存實作存在的原因。

並行 Agent 帶來合併與注意力問題

只有在開發者能審查、協調並信任輸出時，運行更多 agent 才會提升產能。

Air 讓開發者可從分支開啟工作階段，並將工作置於暫存 Git worktree。worktree 是連結至相同 repository 歷史紀錄的獨立工作副本，可令 agent 的修改與開發者目前 checkout 隔離。

這種隔離對並行工作至關重要。兩個 agent 在同一工作區修改相同檔案，可能覆寫彼此的假設，或產生各自能通過、合併後卻失敗的改動。獨立 worktree 可減少直接互相干擾。

Air 可顯示結果，並讓開發者將已選取的 commits 轉移回目前專案。其文件所述的 工作階段流程支援先審查變更，再將其 cherry-pick 至目標分支。

隔離不會消除整合作業。若五個 agent 修改了相連範圍，開發者可能面對五個分支、重複修改、不一致的抽象設計及 merge conflicts。每個 agent 都可能產出看似合理的本地結果，但整體系統卻變得欠缺一致性。

瓶頸隨即由程式碼產出轉移至人類注意力。開發者必須理解每個 agent 改了甚麼及原因，亦要判斷哪些測試提供有意義的證據，而不是接受由編寫程式碼的同一系統產生的綠燈摘要。

Air 的工作階段清單有助呈現這項工作量。它可顯示進行中的工作階段、未讀更新、已修改檔案、待提交 commits，以及等待輸入的工作。這種可見度相當有用，但無法判斷背後決策是否正確。

這正是 JetBrains Air EAP 的核心取捨。並行可縮短等待時間，卻也可能倍增審查責任。若團隊啟動 agent 的速度快過核實其工作的能力，只會建立更大的不確定 patch 排隊隊列。

Presets 亦帶來另一項管治考慮。它們令設定可重複使用，但團隊必須決定每類工作應使用哪些模型、權限及投入程度。適合一次性測試 repository 的高權限 agent，未必可接受用於生產基礎設施。

認證方式亦仍不一致。JetBrains 支援多種途徑，包括由供應商管理的登入方式、第三方憑證及 JetBrains AI。然而，可在一個介面使用的訂閱，未必會授權在另一個介面中使用同一 agent。

Claude 正好說明這種複雜性。JetBrains 表示，Claude 訂閱可透過終端機介面使用；但結構化 chat 中的 Claude Agent，則需要 JetBrains AI，或具 API billing 的 Anthropic API key。開發者不應將 Air 視為通用訂閱中樞前，應先查核目前的授權規則。

雲端執行再增添更多界線。本地工作階段在開發者的電腦上執行，但符合資格的機構可將某些工作傳送至 JetBrains 基礎設施。即使 IDE 關閉，雲端執行仍可繼續，但可用性取決於機構設定、repository hosting 及 JetBrains AI 訂閱。

因此，資料處理取決於所選路徑。JetBrains 表示，當使用第三方訂閱時，第三方 agent 的資料會根據使用者現有協議直接傳送至該供應商。JetBrains AI 及雲端功能則按其適用條款運作。

EAP 協議亦明確列出其成熟度。早期存取軟件可能包含錯誤、出現非預期行為，並會在開發期間改變。當 agent 可修改檔案及執行指令時，團隊不應把 EAP 標籤視為普通徽章。

審慎的推出方式應由非關鍵 repository 及狹窄權限開始。團隊應要求人手審查、保留可復原的分支，並在合併前執行獨立測試。任何 agent 獲取敏感程式碼脈絡前，必須先就供應商及資料路由作出明確決定。

這些控制措施並非反對在 IDE 中採用 JetBrains Air 的理由，而是讓其並行模式發揮作用的條件。只有在 orchestration 令責任更清晰可見，而非隱藏於活動儀表板背後，才能創造槓桿效益。

JetBrains 正將競爭對手變成可替換元件

Air 透過吸納 agent，同時保留 JetBrains 開發環境，向 agent-first editors 發起挑戰。

最重要的對手並非某一家公司，而是「編碼 agent 應擁有整個開發者工作區」這個理念。

agent-first editor 可圍繞一個整合系統最佳化每次互動。這可創造專注的體驗，但亦可能令開發者工作流程依賴該產品的模型路由、介面決策及發佈時間表。

JetBrains 採取相反立場。IDE 維持穩定，而 agent 在其中競爭處理工作。開發者可保留熟悉的導航、重構、除錯及檢查工具，同時更換產生程式碼的系統。

ACP 令這項主張更具可信性。若沒有共享協議，支援多個 agent 便需要不斷增加的私有整合。每次供應商更新都可能弄壞 connector，或令各產品之間的功能不一致。

透過 ACP，可替換的單位不僅是模型。agent 帶有其規劃邏輯、工具、權限、模型路由及介面行為。Air 透過共同 client 邊界連接至這整套組合。

這讓 JetBrains 能受惠於外部創新。若 Codex 在 repository 規模的修改上有所改善，Air 使用者可選用它。若 Gemini 更適合另一類工作負載，工作區毋須改變。內部 ACP agent 可處理受限制的工作。

因此，五個具名 agent 是首批陣容，而非固定上限。Codex、Gemini、GitHub Copilot、Claude Agent 及 Junie 為 EAP 提供容易辨識的選項。registry 及自訂設定則擴展可能的選擇範圍。

Cursor 是一個具啟發性的例子。它作為以 AI 為導向的編碼環境而爭奪開發者注意力，但其 agent 亦可透過 ACP 連接至 JetBrains 產品。JetBrains 可將一個與轉換 editor 有關的產品，變成其自身 IDE 中可用的工作者。

這不保證使用者會留下來。原生 agent-first 產品仍可提供更一致的介面、更快的功能交付，或與其首選模型更緊密的整合。協議相容性很少能令每個 client 體驗完全相同。

Air 亦必須證明選擇的複雜性值得。五個具不同權限、訂閱、模式及強項的 agent，可能比一個熟悉工具更難管理。工作區需要清晰狀態、可預測的設定，以及可信的審查資訊。

JetBrains 自家的產品陣容亦增加另一項風險。使用者已會遇到 AI Assistant、Junie、Air、ACP agents、供應商帳戶及 JetBrains AI。Air 建立了較清晰的概念劃分，但過渡期仍可能令人感到零散。

該公司正嘗試透過讓 Air 成為 agentic workflows 的專用環境，同時保留 AI Assistant 用於 chat 及行內協助，來解決這個問題。使用者是否理解及偏好這種劃分，將是 EAP 的關鍵成果。

JetBrains 最初將獨立 Air 環境定位為圍繞 agent 建立的空間，而非加上 AI 的 editor。其 3 月的 公開預覽確立了並行委派作為產品的核心理念。

將該體驗帶進既有 IDE 改變了這項主張。開發者毋須採用獨立應用程式來測試這種工作流程。JetBrains 可透過已嵌入工程團隊的產品發佈 Air。

這項分發優勢意義重大，但採用取決於日常實用性。開發者不會只因一個工具視窗能識別多個 agent 便一直使用它。Air 必須讓並行工作比獨立 terminal 或供應商應用程式更容易理解、審查及合併。

JetBrains Air EAP 後值得關注的事項

下一個考驗不是 Air 列出多少個 agent，而是團隊能否以更少的脈絡切換及可管理的審查成本，完成真實工作。

第一個訊號是一般 repository 的採用情況。JetBrains 需要證據顯示，當啟動並行工作階段的新鮮感消退後，開發者仍持續使用 Air。若在除錯、維護、測試及重構中重複使用，將支持 orchestration 的論點。

有用的指標並非 prompts 數量。團隊應檢視已完成工作、獲接受的修改、審查時間、重開缺陷，以及 agent 完成後所需的人手修復量。高工作階段數量可掩蓋低質素輸出。

第二個訊號是基於 worktree 的整合可靠性。Air 應清楚呈現 branch state、未提交變更、衝突及轉移目標。為並行 agent 而設計的系統，必須防止開發者遺失工作，或將正確 patch 套用到錯誤分支。

JetBrains 記錄了保障措施及審查控制，但 EAP 將揭示它們在日常壓力下如何運作。大型 repositories、生成檔案、monorepos 及重疊重構，將比孤立示範提供更嚴苛的測試。

第三個訊號是 agent 供應商及競爭 editor 的反應。更廣泛採用 ACP 會強化 JetBrains 的開放工作區策略，因為開發者可在支援的 clients 之間移動 agents。供應商則可能偏向僅在自家應用程式內運作最佳的專有功能。

支援常見能力的重要性，將不亞於 agent 數量。權限、工具呼叫、脈絡附件、成本報告、工作階段恢復及 diff 歸屬，需要一致的行為。若協議連接許多 agents，卻只呈現它們最低共同功能，便會限制 Air 的優勢。

機構亦應留意行政控制。JetBrains 表示公司可透過受管理 AI 存取權停用 Air，但其文件指出 IDE Services 管理尚未完成。企業採用需要針對供應商、憑證、雲端執行、資料路由及可審計性制定清晰政策。

Air 與 AI Assistant 之間的關係，是另一個具體訊號。JetBrains 表示，AI Assistant 將繼續獲得支援，而 Air 會成為首選的代理式體驗。未來版本應會顯示，這種分工會否變得更簡單，還是帶來重疊的介面。

成功的過渡，應讓開發人員有一個清晰的位置處理委派任務，另有一個位置提供輕量的行內協助。混亂的過渡，則會迫使用戶理解每個代理、訂閱或聊天模式分別由哪個外掛程式負責。

這五個支援的代理亦會揭示專門化是否帶來實際價值。開發人員需要有可觀察的理由，針對某項工作選擇 Codex，而在另一項工作選擇 Junie 或 Gemini。否則，選擇器便會淪為行政選項，而非提升生產力的功能。

JetBrains Air 在 IDE 中的基礎，最終建基於一個站得住腳的前提：生成式程式碼提高了情境與審查的價值。尚未解決的問題是：一個 IDE 能否組織足夠多的代理，而不令開發人員變成全職的佇列管理員。

請在可復原的分支上試用 EAP，並交給它一項橫跨多個檔案、測試及審查步驟的任務。然後把整個工作流程與你目前的代理配置比較。Air 是否減少了情境切換、令變更更容易檢查，並保留你對儲存庫的控制？還是它只是把五個介面集中在同一個視窗？這個答案一旦在真實團隊中反覆得到驗證，便會決定 JetBrains Air 會成為代理式開發的操作層，還是僅僅停留在一項有趣的實驗。