Atlassian Teamwork Graph MCP、CLI Beta：AI agent 點樣拎到企業工作脈絡

呢個分別好重要。MCP 路徑係畀 agent 用：相容的 AI 系統可以喺運行時請求相關工作脈絡。CLI 路徑就更貼近 developer workflow：把 graph 查詢帶入 terminal、coding environment，以及 Claude Code、Cursor 呢類 coding agent 場景，據發布報道所述 。

Teamwork Graph 加入嘅其實係工作關係

Atlassian 將 Teamwork Graph 定位為其 AI 體驗背後的共享上下文層。Team ’26 相關報道形容，佢係一張持續更新的工作地圖，連起人、項目、文件、決策同各類工作，橫跨 Atlassian 同第三方工具；當中已有超過 1,500 億個連結 。Atlassian 產品頁亦指，團隊可以把 agent 接駁到 Teamwork Graph，從 Jira、Confluence、Jira Service Management、Loom，以及已整合的第三方工具拉取連貫的 Atlassian 上下文 。

對企業 AI 嚟講，真正難位往往唔係模型讀唔明一句文字，而係佢唔知道文字背後嘅工作關係：邊張 Jira issue 擋住 release、邊份 Confluence 文件屬於邊個項目、邊個團隊擁有某個決定、邊張 service ticket 同客戶問題有關。Teamwork Graph 的角色，就係把呢啲關係變成結構化上下文，而唔係將一大堆文件硬塞入 prompt。

MCP beta：畀 agent 更精準咁問 graph

TechTarget 報道，beta MCP 同 CLI 工具會讓 Rovo 內部同第三方平台的 AI agent 更細緻存取 Teamwork Graph 數據，包括資料資產之間的關係，用嚟引導自動化 。SiliconANGLE 亦報道，Atlassian 正透過 Rovo 的 MCP server 交付 Teamwork Graph tools，向外部 agent 同工具開放 graph 。

對企業團隊嚟講，最大改變係選擇性。過往 agent 好容易要靠大範圍搜尋結果、文件 dump 或長篇歷史紀錄來補上下文；而 MCP 路徑的想法，是讓 agent 按需要拉取更相關、互相連接的工作脈絡 。如果 graph 反映到真實工作流程，檢索層就有機會由「搵一堆資料」變成「搵啱嗰幾個關係」。

CLI beta：把 Teamwork Graph 帶入 terminal

Teamwork Graph CLI 係面向 terminal 的 access path。Atlassian 的 Team ’26 blog 表示，Teamwork Graph 會喺 browser、mobile app、terminal 等 agent 場景可用，並推出 Teamwork Graph CLI 公開測試版 。SiliconANGLE 報道指，CLI 包含超過 300 個 command，亦可讓 Claude Code、Cursor 等 coding agent 查詢 graph 入面嘅工作同關係 。

呢點對 software team 特別有感。開發者本身已經長時間喺 terminal、IDE 同 coding assistant 入面工作；如果 coding agent 要建議實作方案，佢可能需要先理解相關 Jira issue、Confluence 頁面、負責團隊、項目關係或依賴脈絡。CLI 的用意，就係令呢啲 graph context 可以喺開發者原本的工作流入面被取用 。

點解有機會減低 token 成本

慳 token 的邏輯，重點係檢索精準度。TechTarget 報道，Atlassian 的 beta MCP 同 CLI 工具旨在透過更細緻的 Teamwork Graph context access，減少 agent 之間嘈雜、冗餘的數據交換 。Atlassian 亦表示，按其 benchmark，以 Teamwork Graph 數據作 grounding，回應準確度提升 44%，同時使用少 48% tokens 。

呢個機制唔係神奇壓縮，而係少啲垃圾上下文。若 agent 可以只取相關 issue、頁面、owner、決策、dependency 或關係，就唔需要把大量無關文字送入模型。企業 AI 工作流入面，prompt 一肥，token 成本同延遲就好容易累積；精準 retrieval 正正係想減少呢種浪費 。

不過要講清楚：44% 準確度提升同 48% token 減少，是 Atlassian 自家 benchmark 的說法，唔係每間公司都必然做到的保證 。實際效果會取決於 graph 覆蓋範圍、資料質素、所用模型、retrieval 設定，以及企業點樣把 MCP 或 CLI 接入自己 agent workflow。

企業喺 beta 期間應該點試

既然呢兩條 access path 仍屬 beta 或 open beta，企業唔應該一見到慳 token 就即刻照單全收 。更實際嘅做法，是用自己數據同治理要求去驗證：

• Teamwork Graph 係咪真係覆蓋你啲 agent 需要用到的 Jira、Confluence、Jira Service Management、Loom 同第三方工具資料 ？
• MCP-based agent 拉出嚟的上下文，係咪比現有搜尋或 RAG workflow 更相關 ？
• token telemetry 有冇顯示 prompt 變細，而答案質素又冇下降 ？
• 對於可以跨工具搜尋、推理同執行動作的 agent，安全、權限控制同審計要求是否足夠 ？
• CLI 係咪真係融入到開發者日常，尤其係 coding agent 需要項目關係同 dependency context 的場景 ？

一句到尾

Atlassian 今次為 Teamwork Graph 開出兩條 beta 路：透過 Rovo MCP server 提供 Teamwork Graph tools，以及推出 Teamwork Graph CLI 。策略重點係，AI agent 唔應該只靠一大段 prompt 猜答案，而應該可以由一張連起團隊、項目、文件、決策同工作的 graph 入面，抽取結構化工作脈絡 。

如果做得好，企業有機會少啲 token 浪費、答案亦更貼近實際工作情境。但呢個承諾能否落地，仍然要睇每間公司自己的資料、權限、開發流程同 agent 設計 。