JetBrains 在旗下每一款 IDE 內建代理協調器
JetBrains 於 10 月 1 日在旗下 IDE 開放 Air 的早期存取。它可作為 JetBrains Marketplace 外掛程式取得，或內建於 IntelliJ、PyCharm、WebStorm、Rider 及家族其他成員的 2026.3 EAP 版本中，並可從 2026.2 版起運作。此外掛程式免費。
有趣的是它的定位。Air 不是模型，也不是代理。它出貨時並未安裝任何代理。JetBrains 將其描述為開發者已付費的代理與訂閱服務的管道，並會像 IDE 偵測終端機那樣，偵測機器上已安裝的項目。
用工作階段取代聊天
JetBrains 主張，同時協調多項任務與和模型對話是兩種不同的活動，而用同一個介面處理兩者一直是個錯誤。傳統 IDE AI 以聊天為核心，Air 則以工作階段為核心。
每個工作階段都是一個正在處理某項任務的代理，而介面會將它們一起追蹤：活動、未讀更新、已變更檔案、待推送的提交，以及每個工作階段的成本，全都集中在同一個檢視中。工作階段可以跨專案執行、以編輯器分頁的形式出現，或依任務需求停留在終端機或圖形化聊天中。在 IDE 任何地方連按兩下 Ctrl，就會開啟提示詞視窗，並附上目前的脈絡。
隔離機制是透過暫時的 Git worktree 來處理。工作階段可以從任何分支開始，在新分支或 detached 狀態下進行，結果再以 cherry-pick 挑回主要專案。JetBrains 表示，代理的輸出會以可審查的 diff 形式出現在 IDE 內，使用的是開發者審查 pull request 時所用的同一套工具，而且變更不會自動套用。
協定這一步才是策略重點
Air 會連接支援 Agent Client Protocol 的代理，這是 JetBrains 與 Zed 共同打造、以 Apache 授權條款發布的開放標準。ACP 透過 stdin 與 stdout 使用 JSON-RPC 2.0，目前已有 JetBrains、Zed、Google、GitHub 以及超過 25 個代理採用。兩家公司也推出了 ACP Registry，這是一個內建於 IDE、可探索相容代理的目錄。
最簡單的類比是 Language Server Protocol。LSP 讓任何編輯器透過單一共享標準支援任何語言，而不必為每種編輯器與語言的組合量身打造整合。ACP 的目標是為代理做到同樣的事。
JetBrains 競爭的不是模型品質，而是代理啟動、監督與審查所處的那一層；共同制定規範代理如何與編輯器溝通的協定，是讓自己成為基礎設施而非單一功能的方法。該公司自己的說法更直白：當代理式開發成為常態，與代理保持距離的 IDE 將會陷入苦戰。
支援的代理包括 Codex、Claude Agent、GitHub Copilot、Gemini、OpenCode 以及 JetBrains 自家的 Junie，還有其他相容於 ACP 的工具。已有 Anthropic、OpenAI 或 Google 金鑰的使用者，不需付費給 JetBrains。對於沒有代理訂閱的人，只要以 JetBrains 帳號登入，JetBrains 就提供免費的 Junie Lite 執行額度。JetBrains AI 點數每月十美元起，可存取該公司自家代管的模型。
Cursor 沒有的功能
JetBrains 主打的差異化在於，連上 Air 的代理可以將 IDE 工具當作技能來呼叫。代理可以觸發偵錯執行來調查失敗的測試，或執行效能分析工具，或使用具備完整多檔案脈絡的重構引擎。代理也可以透過 MCP 取用 IDE 工具，並以結構化脈絡運作，而不是貼上的文字。
JetBrains 表示，這對某些任務能產生更好的結果，而且在某些情況下會使用更少的 token。這項 token 說法是該公司自己的說法，目前尚未有獨立測試公開發表。
背後的論點在於代理能看見什麼。只能讀寫檔案的代理，只能從文字著手。能夠分析慢速函式並檢查呼叫堆疊的代理，擁有資深開發者診斷相同問題時會有的脈絡。JetBrains 花了 26 年打造這套工具，而 Air 是代理首次能取用這些工具。
為何這個時機點說得通
JetBrains 推出這項產品時，審查步驟已成為公認的瓶頸。對許多團隊來說，寫程式已不再是限制，檢查寫出來的內容才是。
這個判斷同時出現在整個工具市場。Qodo 在同一週推出 3.0 版，以審查為核心；Cursor 則在其代理工作流程中加入審查機器人。三家廠商得出相同結論，顯示這個限制已經永久轉移：當代理產生程式碼的速度快過人類閱讀的速度，價值就會轉移到任何能降低閱讀成本的事物上。
Air 的設計反映了這一點。該產品將平行代理工作階段視為待審查的工作佇列，而不是待引導的對話，並將每個工作階段的成本與已變更檔案放在同一個檢視中。對工程經理而言，決定要執行多少個代理時，那行成本就是實際限制。
每個工作階段的成本顯示是個小功能，卻對行為有超乎比例的影響。看不到長時間執行代理花費的團隊，傾向小心翼翼地只執行一個代理。能看到每個工作階段數字的團隊，則更願意同時執行多個，因為決策變成資源分配，而不是賭博。這與雲端支出儀表板帶來的轉變相同，也會改變人們組織工作的方式。
Air 也試圖解決一個協調問題。一個團隊如果在一項任務上跑 Claude、另一項跑 Codex、第三項跑 Copilot，最後會得到三個各自獨立的介面，而且沒有共享紀錄可看出各自碰過什麼。將它們整合進一個早已掌握 diff、檢查與版本控制的 IDE，比採用新工具是更小的改變；而對於在 Java、Kotlin 或 Python 上標準化使用 JetBrains 的團隊來說，這也避免了只為了取得代理而把所有人推到另一個編輯器。
尚未底定的事
Air 是早期存取版本。JetBrains 表示，請預期會有未臻完善之處、UI 與行為變更，以及大約每週一次的更新。該公司尚未公布正式推出日期。長時間執行任務的雲端執行功能僅限於擁有 AI 席次的組織使用，而 JetBrains 尚未公布其定價。
在隱私方面，該公司表示，若未登入任何代理，就不會有任何資料離開機器；若使用第三方訂閱，資料會依現有協議傳送給該供應商，而不是經由 JetBrains。停用此外掛程式不會造成其他改變，而獨立的 AI Assistant 仍持續受到支援。
值得在團隊自家儲存庫中測試的說法，是關於審查的那一項。Air 讓同時執行多個代理變得更容易。這麼做會產生更多合併完成的工作，還是更多沒人閱讀的 diff，是個實證問題，答案會在使用第一個月內揭曉，而不是在發布文章中。