在2025年的今天，人工智能代理（Agent）已经不再是实验室里的玩具，而是真正走进银行柜台、客服系统、金融风控流程中的生产级工具。我们不再只是问“AI能不能回答问题”，而是关心“它能不能安全、稳定、可扩展地融入现有业务系统”。
正是在这样的背景下，一场关于技术选型的深层对话悄然展开：当我们要构建一个真正能落地的银行客服代理时，是选择当下火热的Python生态，还是回归企业级开发的老牌劲旅——Java？
最近，Spring框架之父Rod Johnson在Medium上发表了一篇引发热议的文章，题目很直接：《用Java构建比Python更好的Agent：Embabel vs Pydantic AI》。这不是一次简单的语言之争，而是一场关于架构思维、工程成熟度和系统集成能力的深度较量。
他选取了Pydantic AI官网上的一个典型示例——为银行构建支持型Agent——并用Java中的Embabel框架进行了重构，结果令人深思。
这个任务本身并不复杂：用户提供一个客户ID和一段咨询内容，系统需要返回三条信息——对客户的回复文本、本次交互的风险评分、以及是否需要冻结该账户（比如客户提到“我丢卡了”）。
看似简单，但它触及了Agent开发中最核心的问题：如何与真实世界的数据和业务逻辑无缝对接？这正是区分“玩具Demo”和“生产系统”的分水岭。
Pydantic AI作为Python生态中新兴的Agent框架，主打“让生成式AI应用更易投入生产”。它的设计思路是通过装饰器（decorator）机制，将动态数据注入到LLM的系统提示词中，并利用Pydantic模型保证输出结构的类型安全。
这种方式确实比早期粗糙的字符串拼接进步了许多，至少避免了运行时因字段缺失导致的崩溃。
然而，当你深入代码，会发现这种“注入式”的设计其实把用户输入、数据库连接、上下文管理全都揉进了一个叫SupportDependencies的对象里，像是把钥匙、钱包、工作证都塞进同一个口袋，用起来方便，但长远看却模糊了职责边界。
相比之下，Java版的Embabel实现则展现出一种截然不同的工程美学。它没有依赖魔法般的装饰器，也没有把各种不相干的东西捆绑在一起。相反，它遵循着经典的企业级分层架构：定义清晰的输入输出模型（SupportInput/SupportOutput），建立真实的客户领域对象（Customer），并通过Spring Data的CustomerRepository来抽象数据访问。
最关键的是，这个Customer对象不只是个数据容器，它还拥有行为——比如balance(includePending)方法，可以直接作为工具暴露给LLM调用。
这意味着，余额计算的业务规则被牢牢锁在代码中，而不是散落在提示词里任由模型自由发挥。
这种设计背后体现的是一种叫做“领域集成上下文工程”（DICE）的理念：不是把所有信息塞给模型去猜，而是让模型在受控的、结构化的环境中调用可信的代码。
你可以想象，当客户问“我卡丢了怎么办”，LLM不会凭空编造处理流程，而是调用blockCard()这样的方法，触发真正的风控逻辑。这种能力，在金融场景下意味着巨大的安全性提升。
更进一步说，Embabel的优势并不仅仅在于语法或框架本身，而在于它所扎根的生态系统。Spring Boot、Spring Data、JPA、事务管理、依赖注入……这些在Java世界里被千锤百炼的技术，构成了一个稳固的底座。
一个银行系统很可能已经有成百上千个用Java写的微服务、几十个成熟的领域模型和复杂的权限控制逻辑。现在你要加一个AI Agent？没问题，它天然就能和其他服务对话，复用已有的认证、日志、监控体系。而Python版本呢？很可能需要重新实现一套数据访问层，甚至要面对类型不一致、异步处理混乱、部署运维困难等一系列“非AI问题”。
还有一个容易被忽视但极其重要的点：可测试性。在Embabel的实现中，提示词是用标准的Java字符串模板构建的，你可以轻松地写单元测试，模拟不同客户状态下的输出结果。而在Pydantic AI中，提示词被拆分成多个装饰器函数，分散在不同地方，拼接过程隐藏在框架内部，想做精确的测试反而变得困难。对于一个要处理金钱交易的系统来说，这种可控性差异可能是决定性的。
当然，有人会说：“Python写得快啊，几行代码就跑起来了。”没错，对于快速验证想法，Python确实有优势。但我们要区分“快速原型”和“可持续演进的系统”。前者追求的是今天能跑通，后者考虑的是三年后还能维护。当你的Agent从单一客服扩展到信贷评估、反欺诈、财富管理等多个模块时，Java那种强调模块化、类型安全、架构清晰的风格，反而会成为加速器而非拖累。
Rod Johnson最后提到，Embabel的目标从来不是“追赶Python框架”，而是提供一个真正适合企业级AI应用的编程模型。它不追求炫技，而是致力于让AI agent成为企业现有技术栈的自然延伸。你可以把它看作是“把AI装进Spring容器里”的一次大胆尝试。
如果你正在思考如何让AI真正落地业务，不妨换个角度：不要问“哪个框架功能最多”，而要问“哪个能让我的团队最安心地交付、最轻松地维护、最安全地运行”。在这个问题上，Java+Embabel给出的答案，或许比我们想象的更有力量。