停止构建编排框架，开始构建智能体。未来属于那些掌握生态系统的人，而不是那些被困在构建特定语言引擎中的人。
我需要坦白。我是一个框架狂热者。我的职业生涯建立在 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 代码生成工具，你可以用干净、简单的代码构建复杂的智能体。你的语言不是限制——试图用不必要的抽象包装它才是。
未来的框架不是你导入的代码库。它是对六个相互依赖层的掌握：你的语言、你的模型、你的开发工具、你的提示词、你的生态系统集成和你的架构。
也许我们不需要另一个智能体框架。也许我们所需要的只是一个智能体，一个能用你选择的语言创建智能体的智能体。一个开源的就更好了。
