AI 不仅仅属于 Python：在现有技术栈中集成 LLM
尽管关于引入 AI 的讨论总是以 Python 为前提，但在实际的企业场景中，运行在 Ruby、Java 和 PHP 上的服务要多得多。本文通过 RubyLLM 的案例，从实务视角梳理了在不改变现有技术栈的前提下接入 LLM 的现实路径和判断标准。
AI 不仅仅属于 Python：在现有技术栈中集成 LLM
核心摘要 (TL;DR) 无需 Python 也可以对接 LLM。本文梳理了基于 Ruby、Java 和 PHP 的团队在考虑为现有技术栈引入 AI 时，可以选择的路径（集成层、Python 微服务、直接进行 HTTP 调用）以及各自现实的优缺点。无论使用哪种框架，最先需要明确的是“要解决什么问题”的清晰判断。
我们的后端是 Ruby，要想对接 LLM 必须先招 Python 开发人员吗？
考虑在现有技术栈中引入 AI 的团队，多半都会被这个问题卡住。“我知道该引入 AI，但我们的服务是用 Rails 运行的。”这是我们团队在开发者社区或客户会议上最常听到的话。随着 AI 引入讨论的升温，反 ironical 地，基于 Ruby、Java、PHP 的团队的边缘感却在加深。技术博客上全是 Python 的示例，LangChain 教程和 PyTorch 文档也都默认以 Python 为前提。
然而现实中的技术栈并非如此。稳定运营多年的基于 Rails 的 SaaS 后端、使用 Java Spring 运行的电商平台、用 PHP Laravel 搭建起来的 ERP 系统 —— 这才是大多数企业的真实面貌。这些团队想要接入 LLM，真的必须从重新招聘开始吗？正是因为这个原因，我们开始认真探讨这个问题。
AI 开发生态系统是如何被 Python 垄断的？
始于学术界与研究的结构性倾斜
Python 掌控 AI 生态并非偶然。在 NumPy 和 SciPy 成为科学计算的标准之后，深度学习框架自然而然地构建在 Python 之上。PyTorch 起源于 Facebook AI Research，TensorFlow 起源于 Google Brain，它们都以 Python 优先为出发点，而 LangChain 也依托 Python 生态迅速成长。在 Stack Overflow Developer Survey 2025 中，Python 依然稳居前列。然而，这一数据并不代表 Web 服务后端市场的全部。
非 Python 团队引入 AI 面临的现实障碍
随着 AI 框架向 Python 倾斜并固化，非 Python 团队面前出现了三个现实障碍。第一是新语言的学习成本 —— 现有的 Rails 开发人员掌握 Python 并学会使用 LangChain 所需的时间。第二是与现有代码库分离的问题 —— 如果用 Python 构建独立的 AI 服务，身份验证、数据访问和错误处理等都需要做双重处理。第三是运维成本 —— 需要有专门的团队来独立部署、监控和维护 Python 微服务。在国内的中小企业中，能同时承受这三点的团队又有多少呢？
Ruby LLM 对接的实用选择：RubyLLM
通过单一接口连接 OpenAI、Anthropic、Gemini
RubyLLM 是一个开源框架，它将 OpenAI、Anthropic、Google Gemini 等主流 LLM 提供商统一到了单个 Ruby 接口中。在 Rails AI 集成方面，其架构允许仅通过添加一个 gem 就接入 LLM。由于它能与现有的 Rails 代码库完全集成，因此可以自然地与 ActiveRecord 模型连接，无需单独的 Python 服务即可在同一代码库内运行 AI 功能。
Hacker News 216 分背后的启示
RubyLLM 在 Hacker News 上获得 216 分，其意义远超数字本身。在 AI 讨论高度向 Python 生态倾斜的 HN 上，一个基于 Ruby 的 LLM 对接工具能获得如此反响，其实是在社区层面印证了“非 Python 团队也想使用 LLM”的切实需求。当然，HN 的分数并不能保证生产环境的采用率。建议您亲自确认 GitHub Star 的增长趋势、Issue 的响应速度以及最后一次提交的日期。
“最小公倍数陷阱” —— 抽象便利性的另一面
这里需要坦率地指出一点。虽然将不同的提供商抽象为单一接口可以提高便利性，但很难充分利用各提供商的差异化特有功能。 比如 Claude 的 Extended Thinking（深度思考）、GPT-4o 的多模态处理、Gemini 的上下文窗口优化 —— 这些功能在抽象层上只能受到限制地使用。为了优化成本和性能而动态路由到特定提供商，或者向更便宜的模型进行 fallback 的处理，目前也还没有被完美解决。引入前请在团队内部明确讨论。
这不是在谈论“全新 AI 应用”
基于 Rails 的 SaaS 和电商才是真正的主体
像 RubyLLM 这样的框架，其真正价值并不在于开发全新的 AI 原生应用。为运营了 7 年的基于 Rails 的 B2B SaaS 添加客户咨询自动分类功能、在电商后端利用 LLM 生成商品描述草稿、在现有 CRM 中添加邮件摘要功能 —— 这些场景要现实得多，需求也更庞大。我们团队在与客户交流时也有同样的感受。比起“想开发全新的 AI 服务”，“想在现有服务中增加一项 AI 功能”的需求占据了压倒性的多数。
现有技术栈引入 AI 的路径：集成层 vs. Python 微服务
从实际业务视角来看，主要有三种可选路径：
① 使用现有语言内的集成层（如 RubyLLM 的方式）
- 优点：与现有代码库完全集成，运维复杂度降到最低
- 缺点：限制了对提供商特有功能的使用，依赖于框架的成熟度
② 独立运行 Python 微服务
- 优点：可利用整个 Python 生态系统，能完全发挥提供商的所有功能
- 缺点：运维双重化，团队精力分散，前期构建成本高
③ 直接调用 LLM 提供商 API (HTTP)
- 优点：与语言无关，结构最简单
- 缺点：必须自行实现错误处理和重试逻辑，流式处理（Streaming）较为繁琐
没有哪条路径是绝对正确的。如果团队完全没有 Python 能力且要添加的功能相对简单，那么 ① 是最现实的。相反，如果像 Claude Extended Thinking 这样的特有功能是核心，那么 ② 更合适，而 ③ 则适用于原型设计阶段或添加单一功能。另一方面，从生态系统的角度来看，这种各语言 AI 集成层的扩散是否绝对是件好事，则另当别论。如果已经在 Python 圈子里过度饱和的框架竞争蔓延到 Ruby、Java 和 PHP，从长远来看可能会分散社区的力量。是“创新”还是“分裂”，取决于各语言生态系统实际上是如何被激活的。
如何判断适合我们团队的 LLM 对接路径
结合团队情况的决策清单
如果依然存在“那我们团队该怎么做？”的疑问，建议先在团队内部简单讨论以下四个问题：
- 目前团队中是否有 Python 开发能力？ —— 如果有，Python 微服务路径反而会更加自然。
- 要接入的 LLM 功能是否依赖于提供商的特有功能？ —— 如果多模态、Extended Thinking 等是核心，请先确认抽象层的限制。
- 与现有代码库的集成是核心，还是可以作为独立服务分离？ —— 如果必须与现有的数据库、身份验证系统紧密相连，集成层会更有优势。
- 是否有能承担长期运行和维护的团队结构？ —— 开源框架如果社区变小，维护负担就会完全落在引入该框架的团队身上。
在现有技术栈引入 AI 之前，必须确认的开源框架选择标准 3 要素
在将各语言的 LLM 对接层引入生产环境之前，有一些指标需要亲自确认：
- GitHub Star 趋势：最近 6 个月是呈增长态势，还是处于停滞、下降状态
- 最后一次提交日期及 Issue 响应速度：如果停滞了 2~3 个月以上，则存在维护风险
- 是否存在生产环境案例：不仅仅是 README 里的示例，社区中是否有实际应用到服务的案例分享
如果不确认这三点就抱着“反正加一个 gem 就行，先用用看”的态度开始，一旦 6 个月后框架停止维护，你就必须自己 Fork 代码或者被迫切换到其他路径。一次小小的确认可以避免日后付出巨大的成本。
LLM 对接真正的阻碍并不是语言栈
我们 Grinda AI 团队之所以关注这一话题，并不仅仅是因为技术趋势。在出口一线，我们也每天面对着如何将 AI 自然地融入沉淀多年的既有业务系统（如 ERP、CRM、销售管理工具）的问题。我们深知，比起“用 Python 重新开发一个”， “如何将其融入现有系统”是一个现实得多的问题。LLM 对接真正的阻碍并不是语言栈，而是对于要用 AI 解决什么问题的清晰判断。 如果没有这个前提，任何框架都无济于事。
作者 · RINDA 出口销售研究团队（海外买家开发·出口销售自动化研究编辑）
基于 200+ 韩国出口企业的海外买家开发管道数据及 RINDA 平台的内部观察，编写可在出口实务中立即应用的策略与清单。
在类似的背景下，Grinda AI 正在通过将 AI 融入出口企业现有销售流程的方式，助力海外买家开发和出口销售自动化。这是一种比起技术栈、更先追问“要解决什么问题”的方法。专为寻找海外买家而打造的 AI 平台 RINDA 也是基于相同的理念诞生的。如果您想了解在您团队现有技术栈中接入 AI 的最现实路径，不妨与 Grinda AI 团队进行一次 30 分钟的交流。
常见问题解答
Q. 如果使用像 RubyLLM 这样的抽象层，以后更换提供商会很容易吗？
A. 对于基本的文本生成、聊天完成等通用功能，更换提供商相对比较容易。但是，如果您已经在使用 Claude 的 Extended Thinking 或 GPT-4o 的 Vision（视觉）等特定提供商的专有功能，那么在转换时您必须放弃这些功能或自行实现。从一开始就有意识地管理对专有功能的依赖度，从长远来看是更有利的。
Q. 在没有 Python 的情况下引入 AI 时，最需要注意什么？
A. 必须提前验证开源 LLM 对接框架的成熟度以及维护是否活跃。如果不确认 GitHub Star 趋势、最近提交日期以及是否分享了实际的生产案例，可能会遇到 6 个月后停止支持而不得不亲自 Fork 或更换路径的情况。与其被便利性所吸引而仓促引入，不如先衡量长期运行的可行性。
Q. 在现有服务中开始对接 LLM 之前，最先应该决定的是什么？
A. 比起“要接入什么功能”，首先应该是“该功能是否切实解决了用户或业务问题”。虽然对接 LLM 在技术上变得越来越容易，但如果没有明确的问题定义就开始做，AI 功能往往最终只会徒增运维成本并被搁置。建议在团队内部能够回答“如果这个功能消失了，谁会感到不便”这个问题时再开始。