Atlassian Teamwork Graph 開放測試：MCP 與 CLI 對企業 AI 代理有何意義

Atlassian 這次 Teamwork Graph 更新，最適合用「AI 代理的脈絡基礎設施」來理解。在 Team ’26，Atlassian 表示將開放 Teamwork Graph，讓 Rovo 與更廣泛生態系的代理程式，可以跨工具、跨團隊安全地搜尋、推理與採取行動 。

真正的產品重點，是兩條 beta 存取路徑：一是透過 Rovo 的 Model Context Protocol，簡稱 MCP，server 提供 Teamwork Graph 工具；二是給開發者與代理工作流使用的 Teamwork Graph 命令列介面 CLI 。

Atlassian 這次推出了什麼

這不是單純多放一個 AI 聊天視窗在產品裡。Atlassian 要做的是把 Teamwork Graph 暴露給外部代理與開發者工具，讓它們能在需要時取得工作脈絡。

新存取路徑	主要對象	作用
透過 Rovo MCP server 提供的 Teamwork Graph 工具	Rovo 與第三方 AI 代理程式	讓代理透過 Model Context Protocol 工具，更細緻地存取 Teamwork Graph 脈絡 。
Teamwork Graph CLI	開發者、終端機使用者與 coding agent 工作流	讓使用者與代理可從命令列探索、查詢圖譜；報導稱 CLI 具備超過 300 個指令 。

這兩條路徑的差異很重要。MCP 是偏「代理執行時」的路徑：相容的 AI 系統可以在任務進行中請求相關工作脈絡。CLI 則更貼近開發者日常，將圖譜查詢帶進終端機與編碼環境；發布報導提到，Claude Code、Cursor 等 coding agent 可透過它查詢工作與關係資料 。

Teamwork Graph 補上的，是工作關係這一層

Atlassian 將 Teamwork Graph 描述為其 AI 體驗背後的共享脈絡層。Team ’26 相關報導稱，它是一張連結人員、專案、文件、決策，以及 Atlassian 與第三方工具中工作的動態地圖，並且已有超過 1500 億個連結 。Atlassian 的產品頁也表示，團隊可將代理連到圖譜，從 Jira、Confluence、Jira Service Management、Loom 與已整合的第三方工具拉取相互連結的 Atlassian 脈絡 。

這一層關係資料，正是企業 AI 經常缺少的部分。大型語言模型可以處理文字，但企業工作往往不只是一段文件內容，而是「這張 Jira issue 卡在哪個版本」、「哪份 Confluence 頁面記錄了決策」、「哪個團隊負責」、「哪張服務單與客戶問題相關」。Teamwork Graph 的企圖，是把這些關係變成可查詢的結構化脈絡，而不是把一大包未整理的內容全部塞進提示詞。

MCP beta：讓代理少撈一點，但撈得更準

MCP 工具讓 AI 代理能以更窄、更精準的方式從 Teamwork Graph 取得工作脈絡。TechTarget 報導指出，這次 beta 的 MCP 與 CLI 工具，會讓 Rovo 以及第三方平台中的代理，更細緻地存取 Teamwork Graph 資料，包括資料資產之間的關係，以引導自動化 。SiliconANGLE 也報導，Atlassian 正透過 Rovo 的 MCP server 所提供的 Teamwork Graph 工具，把圖譜開放給外部代理與工具 。

對企業團隊來說，關鍵字是「選擇性」。過去常見做法是把搜尋結果、文件片段或長篇歷史紀錄大量送進模型；現在的思路則是讓代理向圖譜詢問更相關的連結脈絡。圖譜越能反映真實工作關係，這層檢索就越有機會變得有用。

CLI beta：把圖譜帶進開發者的終端機

Teamwork Graph CLI 是偏向終端機與工程流程的存取方式。Atlassian 的 Team ’26 部落格表示，Teamwork Graph 將可在瀏覽器、行動 app 與終端機等代理使用情境中存取，並推出 Teamwork Graph CLI open beta 。SiliconANGLE 報導稱，這個 CLI 含有超過 300 個指令，並可讓 coding agent 查詢圖譜中的工作與關係 。

這對已經在終端機、IDE 與 AI 編碼助理中工作的軟體團隊特別有感。例如 coding agent 在建議實作方式前，可能需要理解相關 Jira issue、Confluence 頁面、專案關係或依賴脈絡；CLI 的定位，就是把這些圖譜脈絡帶到開發者原本工作的地方 。

為什麼它可能降低 token 成本

token 成本的邏輯，不是神奇壓縮，而是「檢索更精準」。TechTarget 報導指出，Atlassian 的 beta MCP 與 CLI 工具，目標是透過更細緻地存取 Teamwork Graph 脈絡，減少代理之間嘈雜的資料交換 。Atlassian 也表示，根據其內部基準測試，將回應建立在 Teamwork Graph 資料上，可帶來 44% 更高準確度，同時使用 48% 更少 token 。

簡單說，如果代理能只抓出相關 issue、頁面、負責人、決策、依賴或關係，就不必把大量不相干文字一起送進模型。企業 AI 工作流中的 token 成本與延遲，常常正是累積在這類過度膨脹的提示詞裡 。

不過，這裡也要打上星號：44% 準確度提升與 48% token 減少，是 Atlassian 的基準測試主張，不代表每家企業都會自動得到同樣結果 。實際效果仍取決於圖譜覆蓋率、資料品質、所用模型、檢索設定，以及企業如何把 MCP 或 CLI 接進自己的代理工作流。

企業導入前該驗證什麼

由於這些存取方式仍屬 beta 或 open beta，企業不宜一看到「省 token」就直接預設會大幅降本，而應先拿自己的資料與治理需求做測試 。幾個實務問題值得先問：

• 圖譜是否涵蓋你的代理真正需要的 Jira、Confluence、Jira Service Management、Loom 與第三方資料來源 ？
• 透過 MCP 的代理，是否比既有搜尋或檢索流程抓到更相關的脈絡 ？
• token 監控數據是否顯示提示詞變小，同時回答品質沒有下降 ？
• 對於能跨工具搜尋、推理與行動的代理，安全、存取控制與稽核要求是否足夠 ？
• CLI 是否真的融入開發者流程，特別是 coding agent 需要專案與依賴脈絡的場景 ？

結論

Atlassian 這次開放 Teamwork Graph 的核心，是兩個 beta 管道：透過 Rovo MCP server 提供的 Teamwork Graph 工具，以及 Teamwork Graph CLI 。前者服務 AI 代理在執行時取得脈絡，後者服務開發者、終端機與 coding agent 工作流。

它的戰略意義在於，代理若能從一張連結團隊、專案、文件、決策與工作的圖譜中取得結構化脈絡，就可能比單純依賴大量提示詞填充更有用 。至於是否真的能降低 token 成本、提高回答品質，仍需要企業在自己的資料環境中驗證 。