Ruby 是构建 AI 应用的最佳语言？深度分析与反思

原文：Ruby Is the Best Language for Building AI Apps

最近读到 Paolo Perrotta 的一篇文章，声称 “Ruby 是构建 AI 应用的最佳语言”。作为一个同时用 Python、Ruby 和 TypeScript 写过 AI 应用的人，我觉得有必要拆解一下这个论点——哪些是对的，哪些需要补充视角。

核心论点拆解

作者 Paolo 的立场很明确：2026 年想快速交付 AI 应用，选 Ruby。

他的逻辑链条：

AI 开发 ≠ 模型训练 —— 训练是 Python 的天下，但应用开发是 HTTP 调用 + 工程化
LLM 库的认知负担 —— LangChain 过度设计，RubyLLM 简洁优雅
Rails 生态完整性 —— auth、billing、streaming、持久化，开箱即用
并发模型适配 —— Fibers 天然适合网络密集型 LLM 工作流

这个框架站得住脚吗？大部分是的，但需要补充几个关键视角。

赞同的部分

1. “训练 vs 应用” 的切割是正确的

太多人混淆了这两个领域。训练需要 CUDA、分布式、梯度优化；应用开发需要：

流式响应处理
对话状态管理
成本追踪与限流
多 provider 切换

这确实是 Web 工程问题，不是 ML 问题。

2. LangChain 确实过度设计

作者举的例子很说明问题：

1
2
3
4
5
6
7
8


# LangChain: provider-specific metadata 结构不一致
response.response_metadata['token_usage']      # GPT
response.response_metadata['usage']            # Claude
response.response_metadata                     # Gemini: nothing

# RubyLLM: 统一接口
response.tokens.input
response.tokens.output

这种细节在规模化时会变成噩梦。RubyLLM 的抽象层次恰到好处。

3. Rails 的完整性是真实优势

AI 应用不只是 chat.completions.create()。你需要：

用户认证（Devise）
后台任务（Sidekiq）
实时 UI（ActionCable / Hotwire）
文件存储（Active Storage）

Rails 把这些打包好了，其他语言需要拼凑。

需要补充的视角

1. Python 生态的护城河比想象中深

作者低估了 Python 在 AI 应用层的渗透：

向量数据库：Pinecone、Weaviate、Chroma 的 Python SDK 最成熟
Agent 框架：CrewAI、AutoGen、Pydantic AI 社区活跃
MCP 协议：Model Context Protocol 的生态目前 Python-first

RubyLLM 很棒，但当你需要集成一个只有 Python SDK 的新工具时，摩擦是真实的。

2. “简洁” 的双刃剑

Ruby 的优雅是有代价的。看作者的 Agent 示例：

1
2
3
4
5


class SupportAgent < RubyLLM::Agent
  model "gpt-5-nano"
  instructions "You are a concise support assistant."
  tools SearchDocs, LookupAccount
end

对比 LangChain：

1
2
3
4
5


graph = create_agent(
    model=model,
    tools=[search_docs, lookup_account],
    system_prompt="You are a concise support assistant",
)

Ruby 版本确实更简洁，但这种 DSL 风格在复杂场景下可能变成黑盒。当 Agent 需要：

条件分支逻辑
人工介入节点
状态机管理

显式编排（LangGraph 的图结构）可能比隐式约定更可控。

3. 性能论点的语境

作者提到 Fibers 和 Async Ruby 适合 LLM 工作流。这是对的，但需要澄清：

IO 密集型：Ruby Fibers 确实高效（网络等待时不占线程）
CPU 密集型：Ruby 仍然慢，Embedding 生成、后处理逻辑会吃亏

如果你的 AI 应用涉及大量本地计算（PDF 解析、图片处理、音频转录），Python 的库生态优势会显现。

JavaScript/TypeScript 的位置

作者把 JS 放在中间位置，但 2026 年的现实是：

Vercel AI SDK + Next.js 可能是目前最快的 AI 应用交付路径。

原因：

边缘部署：Vercel Edge Runtime 让 AI 应用全球低延迟
流式 UI：React Server Components + streaming 的整合度极高
全栈类型安全：从 API 到 UI 的端到端类型推导

RubyLLM 的 API 设计确实比 AI SDK 更优雅，但 Next.js 的生态整合速度正在定义新的标准。

什么时候选 Ruby？

基于以上分析，Ruby/Rails/RubyLLM 最适合：

场景	理由
快速 MVP	Rails 的脚手架速度无可匹敌
团队已有 Rails 经验	认知负担最低
重业务逻辑、轻 AI 编排	传统 CRUD + LLM 增强
多 Provider 切换需求	RubyLLM 的抽象最干净

什么时候不选：

场景	更好选择
重 RAG 流程	Python（向量库生态）
边缘部署优先	Next.js + Vercel
复杂 Agent 工作流	LangGraph / Pydantic AI
团队无 Ruby 背景	别折腾，用熟悉的

结论

Paolo 的文章是一篇优秀的观点文，不是技术白皮书。他的核心洞察——“AI 应用开发是工程问题，不是 ML 问题”——完全正确。RubyLLM 的设计也确实比 LangChain 更符合直觉。

但 “最佳语言” 这个标题是流量策略。2026 年的 AI 应用开发没有银弹：

Python：生态最深，工具最全，但过度工程化严重
Ruby：开发体验最佳，但生态在追赶
TypeScript：部署和 UI 整合最强，但 AI SDK 的 API 设计有妥协

我的建议：

如果你是 Rails 开发者，毫无疑问用 RubyLLM。如果你从零开始，评估团队技能栈 + 部署需求 + 集成复杂度，别被 “最佳” 绑架。

毕竟，ship 出来的产品才是好产品，用什么语言是手段，不是目的。

参考阅读：