Java智能體框架的繁榮是一種代碼異味

停止構建編排框架，開始構建智能體。未來屬于那些掌握生態系統的人，而不是那些被困在構建特定語言引擎中的人。

我需要坦白。我是一個框架狂熱者。我的職業生涯建立在 Apache Camel 之上，我人生中的大部分成功都歸功于企業集成模式的優雅。我懂。如果有一個社區值得獲得諾貝爾框架獎，那就是 Java 社區。從早年在紅帽公司到整個大數據生態系統，框架 15 年來一直是 JVM 世界的引擎。我們是抽象的大師。

因此，當智能體時代來臨而 Java 在奮力追趕時，我的第一本能是原始的：構建一個框架。我甚至開始了一個，驅動力是這樣一個想法："AI 智能體的 Apache Camel 在哪里？"

三個月前，可能只有一個嚴肅的 Java 智能體框架。現在，包括 Embabel 在內，已經有了三個。競賽開始了。但目睹這場爆炸式增長，我不得不提出一個難題：框架本身是否正在成為一種反模式？我們是否在為自己創造負擔，而不是專注于真正重要的事情：構建智能體？

最近 Java 智能體框架的繁榮并非一個健康、成熟生態系統的標志。它是一種癥狀。一種架構層面的代碼壞味道，告訴我們我們的方法存在根本性問題。

我們最初為什么要構建框架？

讓我們回顧一下。為什么像 Spring 和 Camel 這樣的框架變得如此主流？原因清晰且合理：

開發人員生產力： 我們當時淹沒在樣板代碼中。框架將其抽象掉了。
代碼質量與治理： 它們提供了標準化的模式，防止每個開發人員重新發明輪子。
可重用性： 它們為我們提供了經過實戰檢驗的構造來構建，節省了大量的時間和精力。

目標是優化生產力、質量和治理。但這些是我們今天應該優化的相同參數嗎？感覺我們像是在用 2010 年的方法解決 2025 年的問題，完全忽視了房間里的大象：AI 驅動的開發工具。

這頭大象有個名字：Cursor（及其伙伴）

在我們忙于將 LangChain 移植到 Java 時，情況發生了變化：

Cursor 和 Copilot 生成樣板代碼的速度比你輸入 import 語句還快。你正在構建的那個復雜的鏈式抽象？Cursor 三秒鐘就能寫出來。你正在標準化的那個工具注冊模式？Copilot 已經知道五種變體。

但在這里，我們需要停下來問一個更根本的問題：你的最終用戶實際需要什么？

你真正需要構建什么？

讓我們具體點。我們大多數人面臨兩種情況：

場景 1： 你在未來 12 個月內構建一個關鍵智能體。也許它是一個每天處理 10,000 次對話的客戶服務智能體。或者一個需要理解你公司特定標準的代碼審查智能體。或者一個絕不能對監管要求產生幻覺的合規智能體。
場景 2： 你正在構建一個智能體平臺。成百上千個智能體，每個都有不同的上下文、不同的領域、不同的需求。也許你在一家咨詢公司，為多個客戶構建智能體。或者你正在創建一個內部平臺，不同團隊可以在上面啟動自己的智能體。你需要可重用、適應性強、可演進的東西。一種能讓你快速創建新智能體，同時保持所有智能體一致性和質量的東西。

在這兩種情況下，誠實地問自己：你的用戶需要一個代碼框架嗎？

還是他們需要完全不同的東西？

重新定義框架

在放棄我的框架并實際交付智能體之后，我學到了：我們不需要消除框架。我們需要重新定義在 AI 時代框架實際意味著什么。

舊框架定義： 一種可重用的代碼抽象，提供結構并處理橫切關注點。你導入并在其之上構建的東西。
新框架定義： 構建智能體的完整環境，一組協同工作的相互依賴的層，其中代碼層只是更大拼圖的一部分。

以下是現代智能體框架中真正重要的層次：

第 1 層：語言本身

Java（或你選擇的語言）及其構造、類型和模式。不包裝在抽象中，直接使用。語言已經是你的邏輯結構框架。你不需要在 Java 之上再加一個代碼框架。Java 本身就是框架。

第 2 層：模型

一個真正好的大語言模型：GPT-5、Claude、Gemini、Grok。這不僅僅是你調用的 API。它是你技術棧的核心組件。模型的能力直接決定了你能構建什么。像選擇編程語言一樣仔細地選擇它。

第 3 層：開發人員生產力工具

Cursor、Copilot 以及下一代 AI 驅動的開發工具。這些不是可選的。它們是關鍵基礎設施。你的框架應設計成與這些工具無縫協作。如果 Cursor 不能輕松地按照你的模式生成代碼，那么你的模式是錯誤的，或者你可能需要很好地描述你的模式。

第 4 層：提示詞包與指南

你經過版本控制、測試、治理的提示詞。你的組織語音。你的領域知識。你的合規規則。這是你的業務邏輯存在的地方——不在代碼中，而在精心策劃的上下文和指令中。將這些視為你的依賴構件，就像 JAR 包，但用于智能體行為。

第 5 層：生態系統 API

對新興的專業化平臺及其 API 的上下文感知。用于知識檢索的向量數據庫。上下文存儲和內存管理系統，如 Zep 或 Cognee。工具執行平臺，如 Arcade。用于智能體監控的可觀測性平臺，如 Langfuse。提示詞管理和版本控制工具。這些大多暴露 REST API 或標準協議，大多提供 LLM.txt 用于上下文導入。你的框架需要知道這些存在，并知道如何連接到它們。

第 6 層：架構與設計模式

作為指南和模式捕獲的架構思維。關于這些層如何在不同用例中組合在一起的可重用藍圖。不是代碼抽象——關于路由邏輯、版本控制策略、部署模式和生態系統集成的文檔化知識，這些知識成為你組織上下文的一部分。

想想看。當你構建那個關鍵的客戶服務智能體時，真正決定其成功的是什么？

調用 LLM 的 Java 代碼嗎？（那是 20 行代碼，Cursor 寫的）
復雜的鏈式編排嗎？（標準控制流）
重試邏輯和錯誤處理嗎？（Java 已經有這方面的模式）

還是：

你選擇的模型以及它處理你領域的能力
教導它你的升級規則和語氣的提示詞
讓你能快速迭代這些提示詞的工具
與像 Arcade（工具）和 Zep（內存）這樣的平臺的集成
讓你能夠對變更進行版本控制、測試和部署的架構
讓你能在多個智能體中重用這種方法的設計模式

那就是你的框架。所有六層，協同工作。

實踐中的框架

讓我向你展示在構建智能體時的實際示例：

第 4 層（提示詞包） 是版本化的構件，不是你代碼中的字符串：

prompts/
  customer-service/
    v1.2/
      system-prompt.md
      escalation-rules.md
      tone-guidelines.md
      product-context.md
      examples/
        refund-scenarios.yaml
        technical-issues.yaml

第 5 層（生態系統 API） 配置在你的環境中：
你的生態系統上下文嵌入在指南中：

# 生態系統集成指南

## 工具發現
- 調用 Arcade API 列出可用工具: GET /tools
- 參考: 查看 Arcade LLM.txt 位于 https://docs.arcade.dev/llms.txt

## 內存管理
- Zep 會話 API: https://api.getzep.com/v2/sessions/{session_id}
- 參考: 查看 Zep API 文檔位于 https://docs.getzep.com

## 基礎設施與存儲
- 用于提示詞構件的對象存儲: S3, GCS, 或 Azure Blob
- 用于長時間運行工作流的狀態持久化

第 1 層（Java） 提供結構，干凈簡單：

public class CustomerServiceAgent {
    private final Model model;
    private final PromptPack prompts;
    private final ArcadeClient tools;
    private final ZepMemory memory;
    
    public Response handle(CustomerQuery query) {
        // 檢索會話內存
        var history = memory.getSession(query.sessionId());
        
        // 從 Arcade 獲取可用工具
        var availableTools = tools.listTools();
        
        // 使用上下文渲染提示詞
        var context = prompts.render("main", query, history, availableTools);
        
        return model.complete(context);
    }
}

第 3 層（Cursor） 在幾秒鐘內生成這段代碼。你專注于架構。

第 6 層（架構） 指南：

# 智能體架構指南

## 工作流路由
- 為多節點智能體工作流設計路由邏輯
  - 分類節點 → 路由到專家節點（支持、銷售、技術）
  - 復雜性分析 → 路由到適當的模型層級（GPT-4o vs GPT-3.5）
  - 工具選擇節點 → 根據用戶意圖路由到工具執行節點
- 通過 Arcade 網關路由工具執行：集中認證、速率限制、工具發現
- 提示詞版本的 A/B 路由：10% 到 v2.0，90% 到 v1.5，監控質量

## 速率限制與節流
- 每用戶令牌預算：10K 令牌/天（免費），100K（付費）
- 隊列管理：最大 100 個并發請求，溢出到 SQS...
..
..

為什么這個框架能擴展

對于一個關鍵智能體： 選擇你的模型（第 2 層），編寫清晰的代碼（第 1 層），用 Cursor 迭代（第 3 層），優化提示詞（第 4 層），集成生態系統 API（第 5 層），遵循架構模式（第 6 層）。
對于一千個智能體： 相同的模型，相同的架構模式，相同的生態系統 API，但每個智能體都有自己的提示詞包。Cursor 生成樣板代碼。你的語言提供結構。生態系統處理難題。

美妙之處何在？各層協同工作。Cursor 生成代碼是因為模式簡單。提示詞是獨立版本控制的。集成使用 REST API。架構無需抽象即可實現重用。

不需要編排框架。這就是框架。

引擎與 SDK 的問題

讓我澄清一下：我并不是說所有框架都應該消失。我對 LangChain、LangGraph、Mastra、CrewAI、Autogen 等團隊所構建的東西懷有極大的敬意。但我們需要理解一個在急于將所有東西移植到 Java 的過程中被忽視的關鍵區別。

不要混淆引擎和 SDK。

我的意思是：我迫不及待地想用 Java 開發完整的智能體。我熱愛 Java。但我不想僅僅因為我想用 Java 開發智能體就要一個 Java 引擎。

考慮這些例子：

LangChain4J？ 作為連接更廣泛的 LangChain 生態系統的 SDK，這是一個很好的開始。你用 Java 編寫，但你正在利用一個經過驗證的引擎。
帶有 Java SDK 的 Crew AI？ 完美。在 Python 中掌握編排模式，然后給我一個 Java 接口來使用它們。
支持多語言的 Mastra？ 正是正確的方向。構建一次引擎，為每種語言提供 SDK。
為使用 Go 構建的 Not7 添加 Java SDK 或任何語言 SDK？

這里的模式是？用你喜歡的語言開發，而無需用該語言重建整個引擎。

編排層正在變薄

這就是為什么我認為即使是 SDK 方法也可能是暫時的，或者至少變得非常精簡的原因：

一方面： 模型正變得 dramatically 更好。GPT-5、Claude 4.5、Gemini 2.5 Pro、Grok 的推理能力使得復雜的編排模式過時了。它們可以用簡單的提示詞處理多步驟工作流，而這在六個月前需要復雜的鏈。
另一方面： 真正的工程問題正在由專業平臺解決。以 Arcade 為例：工具發現、認證、大規模執行、處理速率限制、管理工具版本。這才是艱難的工程工作所在。工具管理不再是編排問題；它是在平臺層解決的基礎設施問題。
在中間： 編排框架正被擠壓得越來越薄。

當你的模型能夠推理工作流，并且平臺處理復雜的工程問題（工具、內存、上下文）時，編排還剩下什么？

答案是：非常少。這就是為什么工程重點需要從編排轉向更廣泛的智能體開發挑戰——提示詞管理、生態系統集成、工具決策可審計性、成本優化。真正的問題已不在編排之中。

新現實：AI 原生框架

代碼壞味道不僅僅是我們構建了太多框架。而是我們正在為一個不復存在的世界構建框架。以下是 2025 年構建框架實際意味著什么：

方面	過去的框架思維模式 (2005-2024)	下一代框架思維模式 (2025+)
定義	需要導入的代碼庫	跨越6個層級的完整環境
業務邏輯	位于代碼抽象中	位于版本化提示詞與指南中
關鍵構件	JAR 文件、軟件包	提示詞、上下文、API 知識
可重用性	代碼繼承與組合	架構模式與藍圖
開發工具	用于編寫代碼的 IDE	用于生成代碼的 AI 工具（如 Cursor）
生態系統	自包含、單體式	集成專業化平臺
樣板代碼	由框架抽象處理	由 AI 在幾秒內生成
你導入/使用什么	Spring、Camel、框架 JAR 包	無需導入——你只需組合這些層級

接受 AI 驅動的開發現實 每個構建智能體的開發人員都將使用 Cursor、Copilot 或類似工具。這不是趨勢——這是新的基線。設計你的框架以與 AI 代碼生成無縫協作，而不是背道而馳。如果 Cursor 無法理解你的模式，那你的模式就是錯的。
你的框架是純文本英語，而不僅僅是代碼 你的框架最關鍵部分將是精心設計的提示詞、清晰的指南和結構化的上下文——而不是聰明的抽象。這些是你的版本化構件。這些決定了智能體行為。像對待代碼一樣嚴格對待它們。
當你需要 SDK 時，不要重新發明引擎 是的，Java SDK 至關重要。但你不需要僅僅為了用 Java 編寫智能體就重建整個編排引擎。生態系統已經有平臺在解決難題：內存（Zep, Mem0）、工具（MCPs, Arcade）、向量（Weaviate, Pinecone, Qdrant）、可觀測性等。集成，不要重建。
框架仍然至關重要——但不是為了編排 如果你正在解決真正的問題——提示詞版本控制、決策可審計性、生態系統集成模式、成本優化——那就構建這些。但編排？生態系統已經向前發展了。內存、工具、上下文、可觀測性正由專業平臺解決。將你的創新重點放在其他地方。
相信你的語言 如果你覺得你選擇的語言中缺少一個框架，請退后一步。現代語言——Java、Python、TypeScript、Go——非常強大。憑借它們的最新特性加上 AI 代碼生成工具，你可以用干凈、簡單的代碼構建復雜的智能體。你的語言不是限制——試圖用不必要的抽象包裝它才是。

未來的框架不是你導入的代碼庫。它是對六個相互依賴層的掌握：你的語言、你的模型、你的開發工具、你的提示詞、你的生態系統集成和你的架構。

也許我們不需要另一個智能體框架。也許我們所需要的只是一個智能體，一個能用你選擇的語言創建智能體的智能體。一個開源的就更好了。

【注】本文譯自：Java's Agentic Framework Boom is a Code Smell

posted @ 2025-11-04 10:47 碼者無疆閱讀(7) 評論(0) 收藏舉報

刷新頁面返回頂部

碼者無疆

“碼”界老兵，分享程序人生。