Agent 开发：Python 生态与 JVM 生态的抉择
为什么写 Agent “天然”选择 Python？JVM 生态真的没有一席之地吗？
一、现状：Python 的压倒性优势
如果 2025-2026 年要写一个 AI Agent，绝大多数工程师的第一反应是 Python。这不是偏见，而是数据事实：
| 框架 | 语言 | GitHub Stars | 创建时间 | 定位 |
|---|---|---|---|---|
| LangChain | Python | 137K+ | 2022-10 | Agent 工程平台 |
| Dify | TypeScript/Python | 142K+ | 2023-04 | 可视化 Agent 工作流平台 |
| AutoGen | Python | 58K+ | 2023-08 | 多智能体编程框架（微软） |
| CrewAI | Python | 52K+ | 2023-10 | 角色扮演式多 Agent 编排 |
| LlamaIndex | Python | 50K+ | 2022-11 | 文档 Agent + RAG |
| PydanticAI | Python | 17K+ | 2024-06 | 结构化 AI Agent 框架 |
| Transformers | Python | 161K+ | 2018-10 | 模型定义框架（HuggingFace） |
对比 JVM 生态：
| 框架 | 语言 | GitHub Stars | 创建时间 | 定位 |
|---|---|---|---|---|
| LangChain4j | Java | 12K+ | 2023-06 | JVM 版 LangChain |
| Spring AI | Java | 8.7K+ | 2023-06 | Spring 官方 AI 框架 |
| Embabel Agent | Kotlin | 3.4K+ | 2025-04 | GOAP 规划式 Agent 框架（Spring 创始人） |
| JetBrains Koog | Kotlin | 4.2K+ | 2025-05 | JVM 企业级 Agent 框架 |
| Agents-Flex | Java | ~1K | 2024 | 轻量级 Java AI 框架 |
Python 生态在 Star 数量上是 JVM 的 10-30 倍，这不是偶然，而是由深层原因决定的。但 Star 数量≠生产适用性，这正是本文要探讨的核心。
二、为什么 Agent “天然”和 Python 绑定？
1. 模型基础设施几乎全部 Python-first
这是最根本的原因。所有主流 LLM 的参考实现和训练推理栈都建立在 Python 之上：
- HuggingFace Transformers：161K⭐，事实上的模型加载和推理标准库
- vLLM：高性能推理服务，Python 原生
- PyTorch：所有主流模型训练框架
- Ollama / llama.cpp 的 Python binding：本地推理的标准接口
- MLX（Apple Silicon）：Python API
这意味着：在 Python 里调用模型是一等公民，在其他语言里是二等封装。
当模型能力每周都在迭代（新 API、新模态、新结构化输出格式），Python SDK 总是第一时间支持，其他语言只能等待社区封装。
2. Agent 框架的”马太效应”
LangChain (2022-10) 是最早的 Agent 编排框架，它选择了 Python，之后产生了连锁反应：
Python-first LLM SDK → LangChain 选择 Python → 社区贡献涌入 →
更多工具/集成围绕 LangChain 构建 → 新框架(crewAI, AutoGen)也选 Python →
生态飞轮转动 → JVM 社区只能做"跟随者"(LangChain4j)
这是一种典型的路径依赖——不是因为 Python 在工程层面更好，而是因为先入者选择了它。
3. Agent 开发的”实验性”特质
Agent 开发目前仍然高度实验性：
- Prompt 需要反复调试
- 工具调用需要试错
- 多 Agent 交互行为难以预测
- 评估指标尚未标准化
Python 的解释执行、REPL、Jupyter Notebook 天然适合这种”快速尝试→观察结果→修改”的工作流。而 JVM 的”编译→运行”循环在这个阶段是劣势。
4. 数据科学生态的天然延伸
Agent 经常需要处理数据（RAG、工具调用返回结构化数据、分析结果），Python 的 pandas、numpy、matplotlib 等构成了完整的”获取→处理→展示”链路。JVM 生态在数据处理上虽然有 Spark、Flink，但对单 Agent 场景来说太重了。
5. MCP 协议的 Python-first
Model Context Protocol（Anthropic 提出的 Agent 工具调用标准）的官方 SDK 是 TypeScript 和 Python 的。虽然有社区 Java 实现，但不是官方一等支持。
三、JVM 生态的可取之处
如果说 Python 赢在”快”和”先”，那 JVM 赢在”稳”和”深”。 以下是在生产环境中选择 JVM 生态的真正理由：
1. 企业级工程能力（JVM 的核心护城河）
这是 JVM 生态最不可替代的优势。对比 Python 和 JVM 在关键工程维度上的差异：
| 维度 | Python | JVM (Java/Kotlin) |
|---|---|---|
| 类型安全 | 动态类型 + 可选 type hints | 强类型系统，编译时检查 |
| 并发模型 | GIL 限制，asyncio 复杂 | 真正的多线程，虚拟线程 (Java 21+) |
| 依赖管理 | pip/poetry/uv，生态碎片化 | Maven/Gradle，成熟稳定 |
| 测试生态 | pytest，够用但不统一 | JUnit + Mockito + Testcontainers，工业级 |
| 部署 | 容器化后差异不大 | GraalVM 原生镜像，秒级启动 |
| 监控 | 需要额外集成 | Spring Boot Actuator + Micrometer，开箱即用 |
| 安全审计 | 需要手动配置 | Spring Security 等企业级方案成熟 |
| 重构 | IDE 支持有限 | IntelliJ 重构，安全且大规模可用 |
对于银行、保险、电信、大型电商等对稳定性、可维护性、安全合规有严格要求的行业，这些不是”锦上添花”，而是准入门槛。
2. Spring 生态的无缝集成
如果你的企业已经在用 Spring Boot，选择 Spring AI 意味着：
Spring AI + Spring Security (认证/授权)
+ Spring Data (数据库)
+ Spring Cloud (微服务治理)
+ Spring Boot Actuator (监控)
= 零额外学习成本的 AI 能力集成
对比 Python 方案，你需要分别集成 FastAPI、SQLAlchemy、Celery、Prometheus 等多个独立项目，并自己处理它们之间的兼容性和运维。
这不是框架之争，而是基础设施复用率之争。
3. 高并发场景的性能优势
Java 21 引入的虚拟线程 (Virtual Threads) 让 JVM 在高并发 Agent 场景下有明显优势：
- 一个 Agent 服务同时处理数百个并发用户会话
- 每个会话可能阻塞等待 LLM API 响应（通常 2-10 秒）
- Python 的 asyncio 需要显式异步编程模型，容易写出阻塞代码
- JVM 的虚拟线程让你用同步代码风格获得异步性能
对于客服 Agent、交易 Agent、实时监控 Agent等需要高并发响应的场景，JVM 的工程优势会直接转化为基础设施成本的降低。
4. Kotlin 带来的现代语言体验
JetBrains 推出的 Koog（4.2K⭐，2025-05）是 JVM Agent 生态的重要新玩家：
- Kotlin 的协程模型天然适合异步 Agent 工作流
- DSL 语法让 Agent 编排代码可读性极强
- 同时支持 Java 和 Kotlin，兼容现有企业代码库
- 原生支持 MCP 协议
- 由 IDE 巨头 JetBrains 背书，工程质量和文档水平有保障
Koog 的定位很清晰：不是 Python 的移植版，而是为 JVM 平台原生设计的 Agent 框架。
5. LangChain4j 的快速追赶
LangChain4j（12K⭐）是目前最成熟的 JVM Agent 框架：
- 统一的 LLM Provider API（OpenAI、Anthropic、Ollama、HuggingFace 等）
- 内建 RAG（检索增强生成）支持，集成多种向量数据库
- 工具调用（Function Calling）的完整实现
- Memory 管理机制
- 社区活跃，每周更新
虽然它是 LangChain 的跟随者，但在 API 设计上更简洁——它不需要兼容 Python 的历史包袱。
6. Embabel：Spring 创始人的 Agent 框架
如果说 LangChain4j 是”LangChain 的 Java 翻译版”，那 Embabel（3.4K⭐，2025-04）则是 JVM 生态中架构理念最激进、最有野心的 Agent 框架。它的 README 只写了一句话就足以让人震惊：
From the creator of Spring.
是的，Rod Johnson——Spring Framework 的创始人——在做 Agent 框架。这意味着 Embabel 从一开始就带着 Spring 级别的工程标准和架构思考。
核心理念：GOAP 规划引擎
Embabel 与所有主流 Agent 框架最大的区别在于它的规划机制：
| 框架类型 | 编排方式 | 举例 |
|---|---|---|
| 链式/管道式 | 按代码定义顺序执行 | LangChain, LangChain4j |
| 图式/工作流 | DAG 节点编排 | Dify, AutoGen |
| 规划式 (Planning) | 动态生成执行计划 | Embabel |
Embabel 内置了 GOAP（Goal-Oriented Action Planning）——一种源自游戏 AI 的规划算法。工作流程是：
目标 (Goal) → GOAP Planner (A*搜索) → 生成行动计划 → 执行第一步 →
重新评估状态 → 重新规划 → 继续执行 → 目标达成
这意味着：你可以给 Agent 定义一组动作和目标，但具体的执行顺序由框架在运行时动态决定。系统能在每个动作之后重新规划，适应新信息。这比硬编码的链式或图式工作流灵活得多。
关键概念
Embabel 用四个核心概念建模 Agent 流程：
- Actions（动作）：Agent 执行的具体步骤
- Goals（目标）：Agent 想要达成的状态
- Conditions（条件）：评估动作前置条件和目标是否达成
- Domain Model（领域模型）：强类型的对象体系
这些概念支撑了三个差异化优势：
- 真正的规划而非有限状态机：使用非 LLM 的 AI 规划算法（GOAP），系统能完成它”没被显式编程”的任务——把已知步骤以新顺序组合
- 动态可扩展性：添加新的动作、目标、条件就能扩展能力，不需要修改现有的编排定义
- 强类型 + 面向对象：所有东西都有类型，支持完整的 IDE 重构，告别”魔法 Map”
技术特性
- 两种编程模型：注解驱动（类似 Spring MVC 的
@Agent、@Goal、@Action）和 Kotlin DSL（agent { }块） - 同时支持 GOAP 和 Utility AI（效用系统，适合探索性任务）
- OODA Loop（观察→判断→决策→行动）架构，每步动作后重新规划
- 原生 Spring 集成：Spring 可以注入和管理 Agent，用 AOP 装饰函数
- 内建 MCP、RAG、多 LLM 混合调用支持
- 从设计之初就支持测试——单元测试和 Agent 端到端测试都很简单
- 2026-05-18 刚发布 v0.4.0，每周迭代
为什么说 Embabel 值得关注？
在 JVM Agent 生态中，Embabel 是唯一一个在架构层面与 Python 框架拉开差距的项目。它不是在做”Java 版 LangChain”，而是在回答一个更根本的问题：Agent 的编排机制应该是什么样的？
GOAP 的思路本质上把 Agent 从”编程”变成了”声明”——你声明目标、动作、条件，框架负责找出达成目标的路径。这种范式如果成熟，可能代表 Agent 开发的下一个阶段。
当然，Embabel 目前仍处于早期（v0.4.0），社区规模和文档深度远不及 LangChain4j。但考虑到创始人的履历和对架构的深度思考，它是最值得关注的 JVM Agent 项目。
7. 已有技术栈的沉没成本
这是最务实的理由。如果一个团队：
- 90% 的代码是 Java/Kotlin
- CI/CD、监控、安全审计全基于 JVM 生态
- 运维团队对 Python 不熟悉
- 合规部门要求代码必须经过静态分析
那么在 JVM 上构建 Agent 是降低整体风险的选择。强行引入 Python 意味着两套技术栈的运维成本。
四、什么时候选 Python，什么时候选 JVM？
选 Python 的场景
| 场景 | 原因 |
|---|---|
| 原型验证 / POC | 快速实验，Jupyter 交互式调试 |
| 需要调用最新模型能力 | Python SDK 第一时间支持 |
| 数据密集型 Agent | pandas/numpy 无缝衔接 |
| 个人项目 / 创业初期 | 生态丰富，开发速度最快 |
| 需要自定义模型 / 微调 | PyTorch + Transformers 无可替代 |
| 团队以 Python 为主 | 学习成本最低 |
选 JVM 的场景
| 场景 | 原因 |
|---|---|
| 企业级生产系统 | 类型安全、监控、安全合规 |
| 已有 Spring Boot 技术栈 | 无缝集成，无需引入新语言 |
| 高并发 Agent 服务 | 虚拟线程 + 成熟连接池 |
| 金融 / 电信 / 政务 | 审计、合规、长生命周期维护 |
| 大规模微服务中的 Agent 节点 | 与现有服务治理体系一致 |
| 团队以 Java/Kotlin 为主 | 利用已有工程能力 |
五、混合架构：两全其美的实践模式
现实中，越来越多的团队采用混合架构：
┌─────────────────────────────────────────┐
│ 用户请求 (HTTP/gRPC) │
└──────────────────┬──────────────────────┘
│
┌──────────────────▼──────────────────────┐
│ JVM 层 (Spring Boot) │
│ ┌─────────────────────────────────────┐ │
│ │ 路由 / 认证 / 限流 / 监控 │ │
│ │ Spring AI / Koog (轻量编排) │ │
│ └────────────────┬────────────────────┘ │
└───────────────────┼──────────────────────┘
│ 内部 RPC / HTTP
┌───────────────────▼──────────────────────┐
│ Python 层 (FastAPI / gRPC) │
│ ┌─────────────────────────────────────┐ │
│ │ 模型推理 (vLLM / Transformers) │ │
│ │ 复杂 Agent 编排 (LangChain/AutoGen) │ │
│ │ 数据处理 (pandas / numpy) │ │
│ └─────────────────────────────────────┘ │
└──────────────────────────────────────────┘
分工原则：
- JVM 层：处理流量入口、业务逻辑、服务治理、数据持久化——发挥企业级工程优势
- Python 层：处理模型调用、Agent 编排、数据分析——发挥 AI 生态优势
- 通信：gRPC 或 HTTP API，清晰的服务边界
这种架构下，两边各取所长，避免了”用 Python 写生产服务”和”用 Java 折腾最新模型 API”的双重痛苦。
六、未来展望
Python 生态的趋势
- 标准化加速：OpenAI SDK、Anthropic SDK 趋于稳定
- Agent 框架收敛：LangChain、CrewAI、AutoGen 的功能边界逐渐清晰
- 评估体系成熟：更多的 benchmark 和评估工具出现
JVM 生态的趋势
- 官方重视度提升：Spring AI 是 Spring 官方项目，不再是社区插件
- Kotlin 异军突起：JetBrains Koog 代表了 JVM Agent 框架的新方向
- 规划式 Agent 崛起：Embabel 的 GOAP 思路如果成熟，可能代表 Agent 编排的下一个范式——从”编程流程”到”声明目标”
- MCP for Java：随着 MCP 协议普及，JVM 官方 SDK 迟早会来
一句话总结：Python 在”前沿探索”上遥遥领先，JVM 在”生产落地”上有不可替代的价值。选择哪个生态，取决于你处于 Agent 开发的哪个阶段、以及你的团队基因是什么。
对于大多数企业团队，我的建议是：先用 Python 快速验证 Agent 是否真的能解决业务问题，确认价值后再用 JVM 做生产级重写或构建混合架构。 不要在验证阶段就追求工程完美，也不要在生产阶段裸奔。
参考资料
| 资源 | 链接 |
|---|---|
| LangChain | https://github.com/langchain-ai/langchain |
| LangChain4j | https://github.com/langchain4j/langchain4j |
| Embabel Agent | https://github.com/embabel/embabel-agent |
| Spring AI | https://github.com/spring-projects/spring-ai |
| JetBrains Koog | https://github.com/JetBrains/koog |
| AutoGen | https://github.com/microsoft/autogen |
| CrewAI | https://github.com/crewAIInc/crewAI |
| LlamaIndex | https://github.com/run-llama/llama_index |
| PydanticAI | https://github.com/pydantic/pydantic-ai |
| Dify | https://github.com/langgenius/dify |
| Agents-Flex | https://github.com/agents-flex/agents-flex |