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

我需要坦白。我是一個框架狂熱者。我的職業生涯建立在 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 年構建框架實際意味着什麼：

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

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

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

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