Java AI Agent 的春天來了？ai4j + CodeAuto 填補 JVM 生態嘅巨大空白

每一個 Python 開發者而家都有 Claude Code、Cursor、Windsurf 用，但同一個時間點，Java 開發者手上嘅選項近乎零。呢個唔係誇張——Spring AI 同 LangChain4j 再強，佢哋做嘅都係模型抽象層，唔係幫你寫代碼嘅 AI Agent。2026 年嘅 JVM 生態出現咗兩個值得關注嘅開源項目：424 stars 嘅 ai4j 同 43 stars 嘅 CodeAuto。一個走大而全路線，一個走 Claude Code clone 路線。問題係：邊個會跑出？

JVM 生態嘅 AI Coding 空白

我哋先搞清楚件事。2026 年中嘅 JVM AI 框架已經好成熟——Spring AI 2.0 GA、LangChain4j 1.18、Embabel 1.0、Koog 1.0，全部都係正經嘅 production-grade 框架。但呢啲框架解決嘅問題係：點樣喺 Java 應用入面接 LLM、做 RAG、做 Tool Calling。佢哋冇一個解決到嘅問題係：點樣用 AI 幫你寫 Java 代碼。

Python 生態嘅 Claude Code 同 Cursor 之所以好用，唔係因為佢哋個 LLM 模型有幾勁，而係因為佢哋成個 runtime 做得好好——30 幾種工具（讀寫文件、搜尋、終端、Git）、權限審批、session 恢復、上下文壓縮、MCP 整合、持久記憶。呢啲基建嘢聽落唔 sexy，但正正係決定一個 AI 編程工具好唔好用嘅關鍵。

Java 開發者面對嘅困境好具體：你嘅 codebase 可能十幾年歷史、全部跑喺 JDK 8、用緊 Spring Boot 2.x，你想引入 AI 輔助開發，但 Python 嘅工具根本唔 understanding 你嘅 Java 專案。你需要一個原生喺 JVM 上面跑、認真 understanding Java 生態嘅 AI Coding Agent。而直到最近，呢個位真係空嘅。

ai4j：一個想做 JVM 嘅 LangChain 嘅野心

ai4j 嘅定位好清晰——佢想做 JDK 8+ 嘅一站式 AI Agentic SDK。424 個 stars、Apache 2.0 授權、多模組架構（core、agent、coding、cli、spring-boot-starter），功能覆蓋面相當廣：統一接入二十幾個 LLM 平台（OpenAI、Anthropic、DeepSeek、Moonshot、智譜等等）、Tool Calling、MCP、RAG pipeline、向量數據庫支援（Pinecone、Qdrant、pgvector、Milvus、Redis）、Agent Runtime、Coding Agent、CLI/TUI/ACP。

佢最特別嘅地方係支援 JDK 8。呢樣嘢聽落好似係 backward compatibility 嘅妥協，但其實係一個 strategic decision。全世界 90% 嘅 Fortune 500 公司仲跑緊 Java，大部分企业級 legacy system 根本唔可能一夜之間升到 Java 17。Spring AI 同 LangChain4j 都要求 Java 17+，直接將呢堆 enterprise codebase 排除在外。ai4j 嘅 JDK 8 支援，等於係打開咗一道門，等呢啲 legacy 系統都可以模組化咁引入 AI 能力。

2026 年 4 月嘅 v2.0 重組咗成個架構，拆出 ai4j-agent、ai4j-coding、ai4j-cli 等獨立模組。7 月嘅 v2.4 更係加咗 RAG query planner、增量 ingestion、online evaluation、cost tracking，以及 coding agent 嘅 workspace-aware 工具。從功能完整度嚟講，ai4j 已經唔係「又一個 LLM wrapper」，而係一個有野心嘅 agentic 開發套件。

但 ai4j 嘅問題亦好明顯：佢想做嘅嘢太多。統一接入、Agent Runtime、RAG、Coding Agent、CLI、Spring 整合、FlowGram 整合……每樣都做，但每樣都未必做到最好。同 Spring AI、LangChain4j 嘅直接比較入面，佢嘅優勢主要喺 JDK 8 兼容同 Coding Agent 呢兩點。如果開發者淨係想用 Spring Boot 接 LLM，Spring AI 嘅 auto-config 同 advisor chain 明顯更 mature；如果想要最多嘅 provider 支援，LangChain4j 嘅 20+ LLM + 20+ vector store 亦更全面。ai4j 嘅真正價值，喺 Coding Agent 同 legacy 系統整合呢個交叉位。

CodeAuto：野心細但目標準

CodeAuto 走嘅係完全唔同嘅路。43 個 stars、MIT 授權、Java 21、2026 年 5 月先開始。佢冇 ai4j 嘅宏大野心，但目標極度聚焦：做一個 Java 版嘅 Claude Code。

CodeAuto 嘅作者 Yulin-Bi 好坦白咁講：「當前主流嘅 AI Coding 工具幾乎全部基於 TypeScript 或 Python 實現，JVM 生態嚴重缺位。」佢直接參考 Claude Code 嘅源碼設計思路，融合 MINICODE 嘅輕量可擴展理念，用 Java 21 搞咗一個簡潔嘅 AI 編程代理 runtime。

功能上，CodeAuto 嘅完成度已經唔低：CLI + 全屏 TUI 兩種交互方式、30 餘種內置工具（文件讀寫、搜尋、命令執行、網頁搜尋、技能載入、記憶管理、Todo 管理、MCP 整合）、權限審批、文件 diff review、Git 檢查點同 undo、後台任務管理、session 保存同恢復、上下文壓縮、Skills 系統、持久化記憶、多級專案指令載入、自反思（Reflexion）同 ACE 結構化經驗記憶。

呢個功能清單擺喺 Claude Code 隔離比，你會發現佢覆蓋嘅場景幾乎一樣。而佢嘅最大優勢係：佢係 Java 寫嘅，天然 understanding JVM 開發者嘅工作流——Maven/Gradle 建構、JUnit 測試、Spring Boot 專案結構、Java 特有嘅類型系統同 pattern。

但 CodeAuto 嘅局限亦好清楚。Java 21 嘅要求等於係將一大班 legacy Java 開發者擋喺門口。43 個 stars 代表 community 還未形成。同 ai4j 嘅多模組架構相比，CodeAuto 更似一個 prototype——好用、好 targets、但仲需要大量 community 沖刺先至可以 mature。

邊個會跑出？或者兩個都需要

如果你問我「邊個會贏」，我嘅答案係：呢個問題本身就問錯咗。

ai4j 同 CodeAuto 嘅 target user 其實唔一樣。ai4j 係做俾想喺 Java 應用入面嵌入 AI 能力嘅開發者用嘅——佢更似一個 SDK，你想做 AI 功能就用佢。CodeAuto 係做俾想用 AI 幫自己寫 Java 代碼嘅開發者用嘅——佢更似一個 tool，你想提高開發效率就用佢。兩者唔係互斥嘅選擇，而係互補嘅方案。

而從更大嘅角度嚟睇，呢兩個項目嘅意義唔止於佢哋本身。佢哋證明咗一件事：JVM 生態嘅 AI Coding 空白係真實存在嘅，而且有需求。Spring AI、LangChain4j、Embabel、Koog 做嘅係模型抽象同 Agent orchestration，但冇一個認真咁做 AI Coding Agent。呢個位留俾咗 smaller、nicher 嘅項目去填。

我作為一個喺香港做 tech startup 嘅人，對呢類項目有個偏見：我更看重邊個先有真實用戶喺 production 用緊，而唔係邊個 stars 多。ai4j 嘅 424 stars 代表佢已經過咗 initial traction 嘅門檻，CodeAuto 嘅 43 stars 仲喺非常早期。但 stars 嘅差距唔代表產品質素嘅差距——Claude Code 出嚟嘅時候，stars 都唔多，但佢解決嘅問題係 real 嘅。

俾你嘅建議

如果你係 Java 開發者，想開始用 AI 幫你寫代碼，我嘅建議好簡單：唔好等「完美版」出嚟先至用。而家就去試。如果你嘅環境仲係 JDK 8，ai4j 係你嘅唯一選擇，佢嘅 coding agent 功能已經夠你開始體驗。如果你已經喺 JDK 21+，CodeAuto 嘅 Claude Code-like 體驗會更 directly useful。而如果你係想喺自己嘅 Java 應用入面加入 AI 能力，Spring AI 2.0 + LangChain4j 1.18 仍然係最穩健嘅選擇。

最關鍵嘅一點係：唔好覺得 Java 開發者係 AI 時代嘅 second-class citizen。JVM 生態嘅 AI 工具鏈已經成熟到一個程度，Spring AI 2.0、LangChain4j、Embabel 1.0、Koog 1.0 全部都係 production-ready。而 ai4j 同 CodeAuto 呢類項目嘅出現，正正係生態補全嘅信號。Python 開發者有嘅嘢，Java 開發者遲早都會有。問題只係時間，而個時間正在到來。