Rails World 2026：AI Euphoria下的Rails工程实践与Agent构建

1. 主旨演讲说了什么：AI Euphoria 不是 PPT 之喜

1.1 从"Rails is magic"到"AI is in the stack"

Rails World 2026 的主旨演讲主题定为"AI Euphoria"，这个词选得很有意思。如果你常年混 Ruby 社区，应该知道 Rails 过去的 slogan 是 "Rails is magic"，强调的是框架帮你把繁琐的底层细节藏起来，让你专注业务逻辑。而这次演讲的核心关键词从"magic"转向了"euphoria"，不是简单的口号替换，而是一次基调转换：AI 大规模进入 Rails 开发者的日常之后，那种"原本要写两小时、现在五分钟搞定"的体验，确实是会让人上头狂喜的。

我看了演讲回放之后最大的感受是，演讲者并没有像很多技术大会那样，拿一堆 Future Roadmap 画饼。他现场做了一次真实演示：让 AI 直接基于需求描述生成一套完整的 Rails 多租户脚手架，包括迁移文件、模型关联、路由、控制器和基础测试，然后现场跑迁移、跑测试、打开页面验证。整个过程大概十分钟，中途还故意设计了需求变更，让 AI 修改数据库结构。这在过去是不可想象的，哪怕是 Rails 的脚手架，也需要你先有清晰的表结构设计，而 AI 连这一步都给你省了，它还会主动提出"这里需要用 lockbox 加密敏感字段"这种建议。

所以"狂喜"不是口号。如果你也经历过手动敲 migration、反复改 schema、被 has_many 关联绕晕的阶段，看到 AI 直接生成完整可运行的代码，你很难不产生类似的感觉。但演讲里也提了一句非常重要的话："Euphoria is a feeling, but software is still engineering."意思是兴奋归兴奋，工程问题还是工程问题，这就引出了后面我想重点展开的内容。

1.2 三个核心信号：原生工具链、Agent 化应用、Rails 成为 AI 后端

主旨演讲的信息量很大，但拉出骨架之后，我认为真正有价值的可以浓缩成三个信号。

第一个信号是AI 原生工具链全面入驻 Rails 开发流程。这不是指装个 Copilot 补全代码那么简单，而是指从项目的生成、测试、代码审查到发布，每个环节都有 AI 参与。演讲里提到了一个新的 Rails 官方插件体系，能在你执行rails new的时候就根据项目描述自动生成基础结构，并在后续的rails generate命令中理解模型之间的语义关系，而不是只做关键词匹配。开发者对代码的掌控方式，从"手写每一行"变成了"审查、调整、纠正 AI 的结果"。

第二个信号是Agent 化应用的工程化。Rails 社区终于不再停留在讨论 AI 聊天机器人，而是开始讨论如何用 Rails 构建真正有自主行为的 AI Agent。所谓 Agent，通俗说就是一个能自己决定下一步做什么的 AI 程序，它不只是回答你的问题，还会自己去调数据库、查 API、操作文件系统，然后基于结果继续决策。演讲用一个客户支持系统做例子：用户发邮件说账号被锁了，Agent 自动查询用户状态、执行解锁操作、给用户发确认邮件，全程不需要人手动介入。而这套系统的后端，就是标准的 Rails MVC 结构。

第三个信号是Rails 作为 AI 应用后端基座的定位越来越清晰。过去几年，Python 在 AI 领域几乎一家独大，很多做 AI 应用的人第一反应是 FastAPI。但演讲给出了一个很有意思的论点：AI 应用不仅仅是一堆模型调用，它需要用户体系、支付、后台管理、任务队列、数据库迁移，这些恰恰是全栈框架 Rails 最擅长的领域。你可以在 Rails 里通过一个 API endpoint 调用语言模型，然后利用 ActiveJob 处理异步任务，用 ActionCable 推送流式响应，用 ActiveRecord 管理 Agent 的长期记忆，这套组合比想象中更顺滑。

这三个信号合并起来，其实在说一件事：AI 不再是贴在 Rails 边上的一块补丁，它开始进入框架的内核。对于 Rails 开发者来说，这是一个手艺层面的大洗牌。以前我们拼的是谁更熟悉 API、谁记得更多方法，以后拼的是谁能更准确地描述需求、谁能更快审查 AI 生成代码的质量、谁能设计出更好的 Agent 工作流。演讲结尾放了张幻灯片，上面就一句话："The best Rails developer in 2026 is not the one who writes the most code, but the one who understands the most."我想这句话值得每个 Rails 开发者抄下来。

2. 为什么是 Rails：AI 时代框架选择的底层逻辑

2.1 数据库驱动的 Agent：状态持久化被严重低估

最近两年我做了不少 AI 相关项目，绕了一圈之后对"为什么是 Rails"有了自己的理解。最核心的一点，是Rails 的数据库中心化设计，天然契合 Agent 应用对状态管理的需求。

你可以把 AI Agent 想象成一个非常聪明但健忘的助手。它每次调用语言模型，模型的上下文窗口都是有限的，就像助手的短期记忆。如果你不给它长期记忆，它下次再找你的时候什么都不记得。长期记忆放在哪里？最可靠的地方就是数据库。Rails 的 ActiveRecord 在这方面有碾压性的优势，它把表、关联、迁移、验证、查询全部统一在一个抽象层里，你写user.orders.includes(:items).where(paid: true)就能拿到结构清晰的数据，Agent 完全可以利用这些数据做决策。

打个生活化的比方。如果你的 Agent 是一个餐厅服务员，它需要在短时间内记住每桌客人点了什么、有没有忌口、上菜顺序是什么。如果让它在对话里硬记，很快就会被新信息冲掉。但如果它每次下单都把信息写进一张表格，等客人喊它的时候查一下表就行。Rails 提供的正是这套表格系统。pgvector 插件还能给表格增加向量列，让 Agent 可以做语义搜索，找"最近有没有用户抱怨过支付失败"这样的信息，而不只是精确匹配关键词。

我在一个真实项目里验证过这个思路。当时做一个内部知识库问答工具，最开始用的是无状态的纯 API 调用，问题是用户每问一句，模型都要重新理解一遍对话背景，稍微复杂的对话就上下文爆炸、token 费用飙升。后来我把对话历史、用户偏好、知识片段全部落进 PostgreSQL，通过外键关联到用户表，每个会话都能实时读取历史上下文。改造之后，token 消耗降了将近一半，回答的连贯性反而提升了。这件事让我彻底想明白了：很多 AI 项目的瓶颈不在模型能力，而在数据架构。

2.2 约定优于配置：让 AI 生成的代码更可控

Rails 最经典的哲学是"约定优于配置"（Convention over Configuration），放在 AI 编程这个语境下，它有了全新的价值。

大模型生成代码的原理是概率预测，它读过的训练数据里绝大多数是符合框架惯例的代码。当一个框架高度约定化，比如 Rails 规定模型文件名必须是单数、表名必须是复数、控制器命名必须遵循 RESTful 风格，AI 生成代码时的"猜测空间"就被大幅压缩。你让 AI 写一个posts资源的 CRUD，它几乎不会在命名上出幺蛾子，因为它训练数据里 Rails 项目的写法都长一个样。

而如果你的项目是用 Node.js 写的，你很可能要被 AI 的随机性气死。没有强约定，同一个需求它能给你写出 Express、Fastify、Koa 三种不同风格，目录结构一会儿分层一会儿扁平，甚至同一个项目里前后两段代码风格不统一。我最近接手过一个 Node 项目就是这样，AI 生成的核心模块还好，但干活的人不是同一个提示词，导致代码风格割裂，看得我头皮发麻。反观 Rails 项目，AI 生成的东西至少风格是统一的，跑起来之后你一眼就能知道去哪找 controller、去哪加 migration。

更重要的是，Rails 的脚手架和生成器让 AI 的产出可以被快速验证。AI 生成的代码如果是一堆散落的文件，你没法轻易验证它有没有副作用、DB schema 对不对。但 AI 生成的是rails generate model的输出格式，你可以直接跑bin/rails db:migrate看是否成功，再跑bin/rails test看测试是否通过。这种"生成后可立即验证"的能力，是 Rails 在 AI 时代非常大的加分项。你可以用 AI 快速生成一个骨架，然后基于骨架不断迭代，而不是让 AI 在混沌中盲飞。

2.3 社区信号与市场热度：为什么这个话题会炸

如果把镜头拉远，看看热搜词里"ai编程"、"ai agent"、"ai大模型"、"ai测试开发"这些词条的密度，你会发现 AI 与编程的结合已经不是一个技术话题，而是市场级的焦虑释放口。Rails World 2026 把主旨演讲定为"AI Euphoria"，本质上是在响应整个行业的集体情绪：大家都在拼命找 AI 与自身技能的接合点，而 Rails 恰好提供了一个相对稳妥的落脚点。

为什么是 Rails 而不是其他框架？因为 Rails 社区有一个特质：它在技术上保守，但在工程效率上激进。二十年里 Rails 一直坚持一套成熟的模式，没有盲目追新，这让它积累了大量可被 AI 学习的范式化代码。另一方面，Rails 又在持续引入现代能力，比如 Rails 8 的原生 SQLite 支持、固态缓存（Solid Cache）、定时任务（Solid Queue），这些功能让 Rails 可以承担 AI 应用的后台基础设施，而不必像以前那样为了队列和缓存去额外部署一堆外部服务。

市场信号也很明确。越来越多的独立开发者和中小团队发现，用 Rails 做 AI 应用的原型速度极快。你不需要自己训练模型，只需要调用现成的模型 API，然后把精力放在产品逻辑上。Rails 全家桶提供了一个完整的闭环：Devise 做用户认证、ActiveAdmin 做运营后台、ActiveJob 做异步任务、ActionCable 做实时交互。很多 AI 应用项目的"非 AI 部分"其实占了八成工作量，而 Rails 把这些部分的工期压得非常短。这就是为什么"Rails 是 AI 应用的最佳后端"这句话，虽然听起来有点激进，但在实践层面是有依据的。

3. 实操：把演讲落地到自己的 Rails 项目

3.1 五分钟搭一个 Rails + 大模型 API 的最小示例

光说不练没有意义。我带你从零走一遍最基础的"Rails 接入大模型 API"的流程，你跟着做就能跑通。

首先，确保你的环境里有 Ruby 3.3 以上和 Rails 8。执行：

rails new ai_bot --css=tailwind cd ai_bot

然后安装一个 HTTP 客户端 gem。过去大家可能用 rest-client，现在我推荐直接用标准库的Net::HTTP，也可以上httparty，但为了少一个依赖，我用Net::HTTP做示例。

接下来创建一个简单的控制器，用来接收用户的提示词、调用大模型 API、返回结果：

# app/controllers/chat_controller.rb class ChatController < ApplicationController def create prompt = params[:prompt] response = call_llm(prompt) render json: { reply: response } end private def call_llm(prompt) uri = URI("https://api.example.com/v1/chat/completions") http = Net::HTTP.new(uri.host, uri.port) http.use_ssl = true request = Net::HTTP::Post.new(uri) request["Authorization"] = "Bearer #{ENV.fetch("LLM_API_KEY")}" request["Content-Type"] = "application/json" request.body = { model: "your-model", messages: [ { role: "system", content: "你是一个严格的Ruby技术专家。" }, { role: "user", content: prompt } ] }.to_json body = JSON.parse(http.request(request).body) body.dig("choices", 0, "message", "content") end end

加上路由：

# config/routes.rb post "/chat", to: "chat#create"

然后用bin/rails s启动服务，用 curl 测试：

curl -X POST http://localhost:3000/chat \ -H "Content-Type: application/json" \ -d '{"prompt":"解释一下什么是Rails的约定优于配置"}'

这个流程虽然简单，但你需要注意一个问题：不要在控制器里做同步 HTTP 调用。如果大模型响应慢，整个 Rails 进程会被阻塞，请求经验稍多就会拖垮服务器。正确做法是把任务塞给 ActiveJob 做异步处理，或者用流式响应让用户看到逐字出现的效果。我个人推荐一开始就上流式，用户体验完全不同。

3.2 用 SSE 实现流式响应，告别干等三分钟

大模型 API 通常支持流式输出（stream），也就是说服务器是一块一块地把内容推给客户端的，而不是憋一大段完整内容再返回。要实现这个效果，Rails 里最轻量的方案是使用 SSE（Server-Sent Events），配合 Rails 自带的 ActionController::Live。

先看控制器怎么写：

# app/controllers/stream_chat_controller.rb class StreamChatController < ApplicationController include ActionController::Live def create response.headers["Content-Type"] = "text/event-stream" prompt = params[:prompt] # 这里调用大模型的流式接口，把每一块文本即时写出 llm_client.stream_chat(prompt) do |chunk| response.stream.write("data: #{chunk}\n\n") end ensure response.stream.close end end

对应的前端，你可以用原生的EventSource或者 fetch API 配合 ReadableStream 来接收。关键点是，SSE 只是单向推送，如果用户需要中断输出、发多轮对话，你可能还需要配合 ActionCable 来做。

实测下来，SSE 方案在开发环境用得很顺，但部署到 Puma 多线程模式下要特别小心：ActionController::Live 会占用一个线程，如果并发高了，Puma 线程池很容易被打满。如果你预计并发会上去，建议把流式交互转移到 ActionCable 的 WebSocket 上，或者直接用一套独立的流式服务，Rails 只负责业务逻辑。我在生产环境踩过这个坑，当时 20 个并发请求就把 Puma 默认线程数吃光了，页面全部转圈，后来把流式模块迁到独立服务才解决。

3.3 给 Rails 加一个 Agent 端点：从聊天到自主执行

现在做一个稍微进阶的玩法：让 AI 不只是回答，而是能执行操作。我们构建一个简单的 Agent，它根据用户指令决定调用哪个"工具"（Tool），比如查天气、查订单、修改状态，Rails 负责提供这些工具。

核心是一个工具分发器：

# app/services/agent_dispatcher.rb class AgentDispatcher TOOLS = { "query_order" => ->(args) { Order.find(args["order_id"]).to_json }, "update_order_status" => ->(args) { Order.find(args["order_id"]).update(status: args["status"]); "OK" }, "get_customer" => ->(args) { Customer.find(args["customer_id"]).to_json } }.freeze def self.call(prompt, user) # 先让 LLM 分析意图，返回 JSON 格式的 tool_call tool_call = llm_parse_intent(prompt, TOOLS.keys) tool_name = tool_call["name"] args = tool_call["arguments"] raise "Unknown tool: #{tool_name}" unless TOOLS.key?(tool_name) TOOLS[tool_name].call(args) end end

这个设计参照了"函数调用（function calling）"的模式。大模型接口会返回一个结构化的调用指令，你的代码再根据指令去执行真实的业务操作。Rails 在这里的角色是提供一套安全的工具舱：Agent 的每个动作都要受权限控制，不能让模型直接执行任意代码。

我强烈建议你把 Agent 的每一次工具调用记录下来。建一张表：

# app/models/agent_log.rb class AgentLog < ApplicationRecord belongs_to :user serialize :request, coder: JSON serialize :response, coder: JSON end

每次调用都写日志，包括用户是谁、模型说了什么、调了什么工具、参数是什么、结果如何。这不仅是审计需要，当你发现 Agent 行为异常的时候，这张表就是你的破案线索。

3.4 用 pgvector 做语义检索，给 Agent 装上长期记忆

前面提到 Agent 需要长期记忆，具体落地我推荐用 pgvector 插件，直接在 PostgreSQL 里加向量字段，顺畅得很，不需要额外引一个向量数据库。

先启用插件并添加一个记忆表：

class AddMemoryTableToAgent < ActiveRecord::Migration[8.0] def change enable_extension "vector" create_table :agent_memories do |t| t.references :user, null: false t.text :content t.vector :embedding, limit: 1536 t.timestamps end end end

写入记忆时，先调用大模型的 embedding 接口把文本转成向量，然后存进embedding字段。查询的时候：

class AgentMemory < ApplicationRecord def self.relevant(query_embedding, user:, limit: 5) where(user: user) .order(Arel.sql("embedding <=> ?", query_embedding)) .limit(limit) end end

这个流程实测下来非常稳。向量距离用<=>表示余弦距离，取最近的几条作为上下文，拼进提示词里，模型就能"想起"这个用户以前讨论过什么。需要注意一点：embedding 的生成是外部 API 调用，会引入延迟和 token 费用。我的做法是写一个异步的 ActiveJob，在对话结束后把内容存进记忆库，不阻塞主流程。否则用户每说一句话都要先等半天 embedding，体验直接崩。

4. 常见问题与排查实录

4.1 AI 生成的 Rails 代码跑起来直接挂？先查这三个地方

AI 生成代码翻车是最常见的，但我发现大量问题其实集中在三个固定位置，排查起来可以有的放矢。

第一是migration 里的数据默认值。AI 经常会在 change_column 里用一个带随机数的默认值，比如default: -> { "uuid_generate_v4()" }，如果你的数据库不是 PostgreSQL 或者没装 uuid-ossp 扩展，跑迁移就会报函数不存在。解决方法是先把数据库类型统一，或者在生成后审查一遍 schema。

第二是model 里关联的 class_name 拼写。AI 生成belongs_to :order的时候，如果对应的模型叫CustomerOrder，就会因为找不到Order模型而崩溃。你需要在模型里显式指定class_name: "CustomerOrder"。审查 AI 代码时先重点扫一遍关联声明。

第三是强参数（strong parameters）的漏配。Rails 7/8 的控制器默认用 Strong Parameters 校验参数，AI 生成 controller 经常会漏掉params.require(...).permit(...)，导致所有写操作都报ForbiddenAttributesError。这类问题报错信息很明确，看日志基本一眼就能定位。

我自己的铁律是：AI 生成的 migration 必须人工 review 完再db:migrate，AI 生成的控制器必须先跑一遍测试再合入主干。这不是不信 AI，而是对工程风险的基本敬畏。

4.2 流式响应卡住的排查思路

如果你发现 SSE 流式响应偶尔"吐"到一半就停了，别急着怀疑大模型接口。多数情况是 Rails 侧的问题。

第一次遇到这个情况，我排查的顺序是：先看 Puma 线程池是否打满，再看反向代理/负载均衡的 buffer 设置。注意 Nginx 默认会缓冲代理响应，你可能需要在配置里关掉缓冲：

location /stream { proxy_buffering off; proxy_cache off; proxy_set_header X-Accel-Buffering no; }

另一个容易忽略的点是HTTP/1.1 的 keep-alive。SSE 依赖长连接，如果你在客户端和服务器之间有某个中间层把连接断开了，就会出现"只收到一半"的情况。开发环境用 Puma 直连通常没问题，生产环境就得逐层排查。

4.3 性能毛刺：大模型调用与数据库连接池争抢

当一个请求既要调用大模型 API（耗时 2 到 5 秒），又要操作数据库时，如果数据库连接被长时间占用，就会拖垮整个应用。我有个客户项目就出现过这种情况：首页加载3秒还打不开，查了半天是 ActiveJob 里同步调用大模型占住了数据库连接。

我的建议是：凡是涉及大模型调用，一律走异步作业，不要在 controller 或 model 里同步调用外部 API。ActiveJob 默认用的是async适配器，开发环境够用，生产环境配合 Solid Queue 或者 Sidekiq 都能扛住。另外，给数据库连接池加足够的容量，Puma 的线程数和连接池大小要匹配。一个粗略的参考：

RAILS_MAX_THREADS=10 DB_POOL=20

让连接池比线程数多一些，避免高并发时请求排队等连接。如果你同时开了很多 ActiveJob 跑 AI 任务，他们的并发也会吃掉连接，所以预留余量是必要的。

4.4 常见问题速查表

5. 我的实践体会与后续扩展建议

5.1 用 AI 提升 Rails 开发效率的真实感受

讲完技术细节，说点我自己的操作体会。

经过这段时间大量使用 AI 辅助 Rails 开发，我最大的感受是：AI 最适合的工作是"生成结构"，而不是"解决问题"。让 AI 生成一堆 CRUD 控制器、迁移文件、表单视图，它又快又好。但是一旦你让它解决"为什么这个关联会 N+1 查询"或者"如何设计一套支持多租户的权限模型"，它的表现就时好时坏，需要你反复引导。所以我现在的工作流是：AI 负责体力活，我负责判断和兜底。代码审查的时间占比明显上升，但总工时是降下来了的。

给你们一个小技巧：给 AI 的提示词里，一定要带上你的 Rails 版本和 Ruby 版本。比如"Rails 8.0, Ruby 3.4"放在最开头，AI 就会尽量使用对应版本的语法，生成的代码基本不用改就能跑。如果不说版本，它经常给你生成一堆旧版的写法，比如render :json =>这种老语法。

5.2 从主旨演讲延伸出的团队落地建议

如果你想在自己的团队里推进 Rails + AI 的改造，我建议不要一上来就做很大的 Agent 平台，那样大概率翻车。从最小闭环开始：先挑一个内部工具，比如客户支持工单分类、知识库检索机器人、日常 SQL 查询生成器，用 Rails 把它们做出来，跑通"用户输入到 AI 反馈"的闭环，再逐步增加 Agent 能力。

团队里一定要有一个人专门负责"提示词资产库"的建设。所谓提示词资产，就是公司内部项目生成的、被验证过的提示词模板，比如"根据以下自然语言生成 SQL 查询，遵循 company_style 规则。数据库表: ...。需求: ..."。把这些模板沉淀下来，团队效率会显著提高。我在一个咨询项目里帮客户建了这个资产库，原本每个新成员要熟悉业务数据结构两周，现在用 AI 辅助查询，三天就能上手。

5.3 最后再分享一个实用小技巧

如果你在 Rails 里做 Agent 设计，一定要给 Agent 的输出加一层验证器。大模型经常“一本正经地胡说八道”，它声称自己更新了订单状态，实际上因为权限不足、订单 ID 不存在等原因根本没有成功。所以 Agent 执行工具之后，必须把执行结果回传给模型，让模型知道真实结果是什么，再基于真实结果给用户答复。我在实际项目中曾经因为没有做这层反馈，Agent 煞有介事地告诉用户"订单已退款"，结果订单还挂着，直接引发客诉。自从强制加了"结果确认并反馈"这一步，这类问题基本绝迹。

AI 时代做 Rails 开发，兴奋是真实存在的，但这种兴奋必须建立在扎实的工程底线之上。狂喜没错，醒来之后把地基打好，才真正算数。