GitHub 的 Releases 頁面是一個安靜的介面。左邊一欄版本標籤，右邊一欄日期，像一張拉直的時間表。十月七日，掘金上一篇長文把 Spring AI Alibaba 的這張時間表截了下來：最後一個正式版停在 v1.1.2.2，日期欄寫著 2026 年 3 月 10 日。往下翻，再沒有新的日期進來。一個累積了一萬零八百多個星標的專案，發佈欄空白了半年。技術羣裡的問句接連冒出來，「我們剛把生產系統遷過去，這就停更了？」「是不是得趕緊換框架？」整場焦慮，都是從這片空白開始的。
一欄日期停在三月
Releases 頁面的設計原則很單純：它只陳列結果。每一次發佈是一個打包好的包裹，掛上版本號，蓋上日期章，排進欄位。使用者依賴這個欄位判斷專案的健康狀態，因為它是多數人唯一會停留的頁面。問題在於，這個介面天生只會說一種話。它顯示「有」，也顯示「沒有」；當「沒有」持續半年，畫面上的留白就被讀成最強烈的訊息。
傳聞裡真實的那一半就落在這裡。v1.1.0.0 於 2025 年 12 月 30 日發佈，是 1.1.x 系列的首個穩定版；2026 年 2 月的 v1.1.2.0 帶來 Agent Skills 與多個 Agent 並行執行；3 月 10 日的 v1.1.2.2 之後，欄位停格。把時間表攤直來看，節奏的斷裂確實刺眼。發佈欄是專案的櫥窗，櫥窗半年沒換展品，路人難免讀成歇業。
版本號裡的一枚字母
這張時間表上其實還有一行字，只是它被讀漏了。2026 年 6 月 25 日，倉庫裡出現了 v2.0.0-M1.1。M 是 milestone 的字首，在語意化版本的規範裡，這一枚字母把承諾降了一級：方向已定，貨還沒到。這組字尾同時交代了兩件事，主線要從 1.x 跳上 2.0，而 2.0 要跟進 Spring AI 2.0 的新地基。
版本號是一種排印合約。四段數字 v1.1.2.2 裡每一段各有職責：主版本宣告相容性的斷點，次版本標記功能的量，修補段與微調段處理細節。字尾的 M、RC、SNAPSHOT 則是補充條款，告訴讀者這個包裹能不能押上生產線。把狀態寫進字母、把進度寫進字尾，這套數字文法我們在watchOS 內部版本號的字尾文法裡讀過一次，一個小寫字母照樣能對外交代一整輪測試的進度。半年空白裡，v2.0.0-M1.1 的那個 M 是最接近「我們還在」的一枚字。
另一個頁面上的綠格子
把視線從櫥窗移到工坊，畫面換了一套色彩。GitHub 的提交熱度圖把時間做成色階：一天一格，有提交的日子填上綠色，越密集色越深。Releases 頁一片安靜，這張圖上卻仍有綠格。掘金那篇長文的作者把紀錄翻完：8 月 25 日還有最新提交；7 月 24 日到 8 月 25 日之間合併了 35 個 PR，其中 8 月 24 日單日合了 8 個；v1.1.2.2 發佈至今，主分支總共合併了 137 個提交。
兩個介面，兩種敘事。發佈頁陳列完成品，熱度圖記錄工作本身。一個專案完全可能在工坊裡熱火朝天，在櫥窗裡沉默半年，而兩個頁面各自都沒有說謊。
動詞換了一套
更有意思的是這些提交的內容。Graph 序列化的修復、Admin 主控臺的中文化、JUnit 5 的遷移、文件連結的修正。把這份清單裡的動詞挑出來看：修復、中文化、遷移、修正。這一組動詞的共同點很整齊，全部在照顧既有之物，沒有一個動詞在開新路。對照 v1.1.2.0 那個階段的新增與引入，更新日誌的動詞系統換了一套，專案的狀態也跟著換了。原文的說法是，專案在「養護」，還沒回到「建設」。
動詞是更新日誌裡真正被讀進去的字級。使用者掃過 changelog，抓住的往往就是那幾個動詞：fix 給人安全感，add 給人期待，migrate 給人預告。一套保養型的動詞持續半年，單獨讀確實像低潮；與熱度圖並排之後，讀到的卻是另一種狀態：工程師還在，手上的工作從蓋樓換成了修繕。
四天一版與半年一版
真正的轉折藏在最後一個正式版的功能欄裡。v1.1.2.2 最大的新特性，是首次引入 AgentScope Java 整合：新增 spring-ai-alibaba-starter-agentscope，用一個 AgentScopeAgent 把 AgentScope 的 ReActAgent 封裝成 BaseAgent，接進自家的 Graph 工作流裡編排。這是一個轉接頭式的設計，兩個框架各守一端，中間用一層封裝對齊介面。一個被傳放棄維護的專案，最後一次大動作是在擁抱自家的兄弟框架。鋪路的意圖，寫在命名裡。
官方其實一年前就把話說完了。java2ai.com 上的公告《一文講透 Spring AI Alibaba 與 AgentScope 的定位與區別》，發表在 AgentScope-Java 於 2025 年 9 月開源後不久，內容寫得直白：開放框架呈現兩種趨勢，SAA 以 Graph 為核心做工作流編排，AgentScope 以 Agentic 為核心最大化基礎模型能力，兩者獨立發展。
公告是文字，節奏才是態度。同一個阿裏旗下，AgentScope Java 的版本列是 2.0.2 落在 9 月 3 日、2.0.3 落在 9 月 7 日，四天一版；SAA 的正式版半年一版。一邊週更，一邊半年更，資源往哪邊傾斜，發佈日曆上看得一清二楚。欄位的密度藏不住品牌的重心，這一點我們在Grok Bot 把後端擇優收進系統內部的介面位移裡也見過：當一個功能從門口被收進牆內，位置本身就是宣言。
三層樓的說明書
這場傳聞暴露的深層問題，原文給了一個清晰的架構：Java 的 AI 框架可以分成三層。第一層解決怎麼連上模型，涵蓋模型接入、工具呼叫、向量資料庫，Spring AI 2.0 與 LangChain4j 都在這一層，而且始終活躍。第二層解決怎麼編排多個步驟，Graph 工作流、條件路由、狀態持久化，Spring AI Alibaba 與 Embabel 駐守這裡。第三層解決怎麼讓 Agent 長期穩定運行，從對話持久化、多租戶隔離到沙箱執行與斷點恢復，AgentScope 守在這一層。
這份分層讀起來像一棟建築的樓層說明。需求若只是在 Java 裡呼叫大模型、做 RAG、接工具，住在第一層就夠了，那一層的兩位住戶一直準時亮燈。真正需要編排與長期運行的團隊，才會走到二、三樓。選框架選錯樓層，焦慮就會找上門；這次傳聞裡最慌的一批人，恰好是剛把生產系統遷進二樓的團隊。
櫥窗與工坊
回頭看整場傳聞，它更像一堂介面閱讀課。發佈頁是櫥窗，熱度圖是工坊，更新日誌的動詞是施工告示牌，版本號的字尾是承諾的刻度。四個介面各自誠實，也各自只說了一半的話，把任何一個頁面單獨當成答案，都會讀出錯的結論。
對使用者，結論是讀一個專案至少要讀兩個頁面，發佈欄與提交圖互相對照，再補一份官方部落格。對維護者，啟示更硬一些：沉默本身也是一種版面。半年的空白沒有配任何說明，使用者就會自己填答案，而且填的往往是最壞的那個。發佈節奏、版本字尾、更新動詞，全是開源專案的溝通設計；工坊再忙，櫥窗也該按時換字。至於「Java 還有希望嗎」這個問句，格子本身就填錯了欄位，該填的是你需要哪一層，而那三層樓上，目前每一層都有燈亮著。