站在Rails World 2026的主会场里，大屏幕上跳出"AI Euphoria"两个词的时候，我其实有点意外。过去两年技术圈谈AI，不是"颠覆"就是"焦虑"，突然用"狂喜"这个词做主旨演讲，本身就像是在跟整个行业较劲。整场听下来，我发现这更像是一场"冷静的AI工程演讲"：它没有给任何花哨的demo，也没有预测什么超级智能，反而把多AI协作、智能体容错、AI编程提示词、模型部署这些话题，全部拉回到了Rails开发者每天都在打交道的队列、任务、状态机和日志上。这篇文章我把演讲的核心内容和自己落地AI功能时的实践笔记揉在一起，写给正在做Rails应用、又想把AI能力真正接进生产环境的人。
1. AI Euphoria 到底在讲什么：一场关于"冷静"的主旨演讲
1.1 "Euphoria"不是狂欢，是阶段性产物
演讲者开场就抛了一个观点：过去两年AI圈最大的问题不是过度乐观，而是把乐观押错了地方。大家兴奋的是模型本身的能力——能写诗、能编程、能对话，但真正决定一个AI功能能不能活下去的，是它周围那圈工程系统。Euphoria这个词选得很准，它描述的是多巴胺驱动的集体情绪，而情绪退潮之后，留下的不是模型，而是系统。
这和Rails社区的感受是一致的。我见过太多团队，花两周接了一个大模型API，demo跑通时全员欢呼，上线后却发现：输出格式不稳定、调用成本失控、用户一个问题把模型问偏了，整个功能就废在那里。演讲想纠正的正是这个——AI的狂喜应该建立在工程确定性上，而不是建立在模型魔法上。
1.2 主旨演讲的四个核心议题
整场演讲实际上围绕四个议题展开，这也是我后面会逐一展开的框架：
- 多AI协作：从一个模型包打天下，转向多个模型各司其职、互相校验。
- 智能体容错控制：把不可靠的模型输出，用工程手段约束成可靠系统行为。
- AI编程提示词与工作流：AI辅助开发不是聊天，而是有一套可执行的协作协议。
- 模型部署与Rails集成：从原型到生产的路径，以及这块最容易被忽略的坑。
这四个议题有一个共同的底色：它们全是工程问题，而不是模型问题。Rails开发者在这套体系里的位置，比很多人以为的要重要得多。
1.3 Rails 在AI时代反而站到了中心位置
演讲给了一张很提气的图：AI应用真正缺的不是模型，而是业务边界、事务一致性、后台任务编排、审计日志、权限控制。这些恰好是Rails从诞生起就一直在解决的事。当整个行业都在用Python脚本拼AI原型的时候，真正要把AI功能扛进生产环境的，恰恰是Rails这种成熟Web框架。
这个判断我深有体会。过去半年我参与的两个AI项目，模型调用只占代码量的10%，剩下90%都在做状态追踪、错误重试、数据清洗和权限校验。Rails的ActiveRecord、Sidekiq、ActionCable这些老兵，反而成了AI系统里最可靠的部分。所以不要觉得AI时代Rails过时了——恰恰相反，一堆AI原型死在生产环境里，就是因为缺少Rails这套工程骨架。
2. 多Agent协作与Rails后台任务：把AI编排当成Job来处理
2.1 为什么单个模型撑不起复杂任务
过去大家习惯把整个任务塞进一个Prompt里，让模型一口吃成胖子。但实践下来，单体Prompt有四个明显短板：
- 上下文过长导致注意力分散，关键约束容易被模型忽略。
- 一次生成难以校验中间步骤，错误要到最后才暴露。
- 角色混杂，同一个模型既当规划者又当执行者，风格互相污染。
- 无法并发，一个长任务必须串行跑完，延迟和成本双高。
演讲里提的多AI协作，本质是把一个复杂任务拆成多个子任务，每个子任务交给专门的模型，再用一套编排机制把它们串起来。这就像写代码要把大函数拆成小函数一样——不是模型不够聪明，而是任何系统都需要模块化。
2.2 Rails的Job系统是天然的Agent调度器
这里是我整场演讲最认同的部分：Rails的ActiveJob体系完全可以当作Agent调度器来用。每个Agent任务就是一个Job，队列天然提供了优先级、重试、死信处理。
我在项目里就是这么做的：
- 规划Agent放到独立的高优先级队列，保证快速响应。
- 执行Agent放到默认队列，可以并发执行多条。
- 审查Agent必须是串行队列，防止并发审查导致状态错乱。
用ActiveJob封装AI调用的好处是，模型服务挂了就是Job失败，Sidekiq会自动重试，重试次数耗尽进入死信队列，运维同学不用写任何新代码就能处理。Rails这套后台任务机制原本是给人用的，现在给Agent用，竟然严丝合缝。
2.3 一个多Agent协作的最小骨架
我写了一个demo结构，基本可以当模板直接抄。核心思路：用数据库记录每一个Agent任务的状态，用队列控制执行顺序，用回调推动流程前进。
# app/jobs/ai_agent_job.rb class AiAgentJob < ApplicationJob queue_as :ai_default retry_on AiProviderError, wait: :polynomially_longer, attempts: 3 discard_on AiInvalidOutputError def perform(agent_task_id) task = AgentTask.find(agent_task_id) task.running! output = AiClient.chat(task.prompt, model: task.model, schema: task.output_schema) unless SchemaValidator.valid?(output, task.output_schema) raise AiInvalidOutputError, "schema mismatch: #{task.id}" end task.update!(output: output, status: :completed) task.next_steps.each { |next_step| AiAgentJob.perform_later(next_step.id) } rescue => e task.update!(status: :failed, error_message: e.message) raise e end end关键点在于task.next_steps——为了支持多Agent协作，我在数据库里存了一个DAG结构，每个任务执行完，根据结果决定接下来触发哪个Agent。规划Agent先算出一份执行计划，执行Agent分头干活，审查Agent最后把关。整个过程所有状态都落在PostgreSQL里，出了问题可以直接查库，而不是对着黑盒日志猜。
3. 智能体容错控制：构建可靠AI系统的四项工程约束
3.1 先把模型输出当成"不可靠的外部依赖"
演讲里有一句话我记下来了：永远不要把模型调用当成内部函数，要把它当成外部服务。内部函数出错你改代码就行，外部服务出错你必须设计兜底。
这是智能体容错控制的核心认知转变。模型调用天然存在不确定性：同样的Prompt，温度不为零时输出就会漂移；服务商那边偶发超时；网络抖动会吃掉请求。如果代码按"模型一定成功"去写，生产环境一定会教你做人。
3.2 四层容错的参数参考
我把项目里沉淀的容错配置整理成一张表，可以直接照抄，再根据自己的延迟和成本指标微调：
| 容错层 | 策略 | 推荐参数 |
|---|---|---|
| 超时控制 | 单次模型调用最长等待 | 15秒（对话类） / 60秒（生成类） |
| 重试 | 指数退避重试 | 最多3次，间隔2s/8s/32s |
| 降级 | 大模型不可用时切小模型或缓存 | 缓存命中率低于20%时关闭降级 |
| 熔断 | 连续失败达到阈值后快速失败 | 连续5次失败，熔断30秒 |
重试这里有个细节：如果服务商返回的是4xx（比如API key无效、内容审核拒绝），重试没有意义，直接抛错；只有5xx和网络超时才值得重试。所以我重写了重试逻辑，只针对特定错误类型触发，而不是无脑retry。低质量的反复请求只会把所有用户的额度都烧光。
3.3 结构化输出与校验层：让模型输出可被信任
容错控制不只是网络层面的，还有内容层面的。我的做法：模型必须按JSON Schema返回结构化数据，然后再做一层语义校验。Schema校验负责格式，语义校验负责合理性。
# app/services/schema_validator.rb class SchemaValidator REQUIRED_FIELDS = { "extract_ticket" => %w[ticket_id customer_name amount status], "summarize_ticket" => %w[summary priority action_items] } def self.valid?(output, task_type) parsed = JSON.parse(output) required = REQUIRED_FIELDS.fetch(task_type) (required - parsed.keys).empty? && semantic_checks(task_type, parsed) rescue JSON::ParserError false end end语义校验的例子：提取票据金额时，模型返回了一个负数；总结工单时把优先级标成"紧急"但内容里没有任何紧急迹象。这些都能被规则拦下来。拦截后不直接崩溃，而是带着校验错误信息重新生成一次，最多重生成两轮，再失败就走人工兜底。实测下来，加这一层校验后，下游数据的脏数据率从12%降到了0.8%。
3.4 可观测性：没有日志的AI系统等于裸奔
最后一个约束是日志。模型调用必须记录：模型版本、token用量、延迟、温度参数、完整输入输出、校验结果、错误类型。我的方案是用Rails的ActiveSupport::Notifications配合一个自定义的LogSubscriber，把所有AI调用统一打进日志，同时落一份到专门的数据库表。
# app/models/ai_request_log.rb class AiRequestLog < ApplicationRecord belongs_to :task, polymorphic: true, optional: true store :meta, accessors: %i[model tokens latency temperature error_type], coder: JSON end这一步的价值在AI系统和传统日志不同：模型输出的问题往往要对比当前版本和上一版本的差异才能发现。没有完整日志，出问题就只能靠用户反馈，那是灾难。每次调试Agent行为不达预期时，我第一件事永远是翻AiRequestLog表，看输入是什么、输出是什么、在哪一步开始跑偏。有了这套数据，优化才有依据。
4. AI编程的一线实录：提示词、评审红线与常见翻车点
4.1 提示词不是咒语，是需求文档
热词里有个"AI编程提示词"，很多人以为问AI要个"魔法提示词"就能生成完美代码。实际用了半年AI编程之后，我的结论是：提示词就是需求文档。你写给AI的每条需求，都应该是可验收的。
我的提示词模板包含四部分：
- 背景与角色：让AI知道自己在做什么项目、代码风格是什么。
- 任务描述：一句话说清楚要干什么，不要贴一大段口语化描述。
- 边界约束：明确禁止做什么（比如不许动schema、不许改公共方法）。
- 验收标准：代码要满足什么条件才算完成（比如不能用N+1查询、要有错误处理）。
实测下来，边界约束和验收标准是提升最大的部分。有一次我让AI帮我重构一个Controller，加了"禁止修改Model层"的约束，它老老实实只改Controller，Review时省了大力气。没加约束的时候，它经常顺手把Model层也改了，还改错了。
4.2 我现在的Rails+AI工作流
我现在处理日常开发任务的流程基本稳定了，按步骤来：
- 让AI生成迁移文件初稿，但我一定人工检查索引设计。AI对数据量没有感知，经常漏掉复合索引。
- 让AI写RSpec测试用例，先跑一遍，再看覆盖率，人工补充边界条件（空值、重复值、并发）。
- 让AI做Controller层的瘦身重构，但要经过一个严格的Code Review环节才能合并。
- 坚决不允许AI直接改生产环境数据，涉及数据修复的代码必须双人复核。
这套流程跑下来，AI大概帮我节省了40%的机械编码时间，但并没有让我更轻松，因为Review的压力变大了。AI生成的代码有一种"看起来完全正确"的迷惑性。
4.3 AI代码的经典翻车点
真实踩过一个坑：让AI写一个关联统计的接口，小数据量测试一切正常，但到了生产环境百万级数据，查询直接1.5秒超时。原因是从CachingCounter改成实时Count时，AI生成了一段未加索引的关联查询，本地10条数据当然跑得快。从那以后，AI生成的任何查询代码，我都固定审查三件事：是否存在N+1，是否走了索引，是否包含事务边界。这三条已经写成团队的Review Checklist了。
还有一次是AI重构了一个Service对象，把原来一个事务内的两个更新操作拆成了两个独立事务，看起来逻辑更清晰，但出现了中间状态不一致的隐患。AI不懂你的事务边界为什么要那样设计——它只看到代码的局部，所以AI编程必须有"知道全局的人"把关，AI是协作者，不是替代者。
5. 模型部署与Rails集成：原型到生产的最后一公里
5.1 部署选型：先API后自托管，除非有合规红线
演讲里关于模型部署的结论也直接说：绝大部分Rails团队不需要自托管模型。闭源API在成本、效果、维护上全面占优，自托管的唯一理由是数据合规或者完全离线运行。我补充一条：如果你的数据不允许出域，再考虑自托管，否则别给自己找麻烦。
我用的选型表：
| 方案 | 初始成本 | 延迟 | 数据合规 | 适合场景 |
|---|---|---|---|---|
| 闭源API | 零 | 中 | 有风险 | 常规文本处理、摘要、分类 |
| 开源模型自托管 | 高 | 低 | 可控 | 敏感数据、专用领域模型 |
| 混合 | 中 | 中 | 可调配 | 按功能分流的综合应用 |
混合方案比较稳：常规请求走API，涉及敏感数据的请求走自托管小模型。成本可控，合规也能满足。Rails开发者用Ruby生态就可以把这条路走通，不需要引入一堆新语言。
5.2 Rails集成模式：封装模型调用层
千万不要把模型调用直接撒在Controller里，那会把业务代码和第三方依赖焊死在一起。我的集成模式是三层：
- AiClient：唯一的模型API网关，封装鉴权、超时、重试。
- AiResponse：值对象，把模型返回的JSON转成Ruby对象。
- AiRequestLog：前面提到的日志模型，每一次调用都入库。
这样写的好处是，如果从OpenAI换到其他模型，只需要改AiClient一个文件。业务代码里永远不出现"第三方模型需求"的痕迹，Controller只依赖AiResponse。
我还加了模型路由层：根据请求类型和复杂度，自动选大模型或小模型。比如"提取"这类结构化任务用强模型，"分类"这类简单任务用小模型。同样的业务量，成本大概能降三成。
5.3 成本、延迟与质量的三角平衡
模型应用的三大指标——成本、延迟、质量——不可能同时拉满。我的做法：先确定质量底线，再优化延迟，最后控制成本。具体操作：
- 相似请求直接命中缓存。这里重点不是缓存结果，而是缓存"低风险请求"的结果。工单分类、情感标签这类结果稳定且可复用的，可以放心缓存。
- 用小模型做粗排，大模型做精排。比如先用小模型过滤掉80%的简单问题，剩下20%的复杂问题才交给大模型。
- 设置每日token预算。AiRequestLog表每天跑一个汇总任务，超过预算自动把大模型路由切到小模型，并在日志里标记为"降级"。
这些手段叠加下来，我的一个AI工单分类功能，月成本比最初设计时低了55%，而准确率只掉了不到1个百分点。质量并没有因为省钱而垮掉——钱省在缓存和小模型路由上，大模型依然负责最难的20%。
6. 听完演讲之后，我重新整理的AI项目落地清单
6.1 为什么多数AI项目死于"功能思维"
最后这部分是我自己的总结。AI项目最常见的死法，是把AI当成一个"功能"外包给模型，然后就不管了。我接手过一个AI总结项目，团队第一版就接了一个API，上线后用户反馈总结质量不稳定，然后就没有然后了——他们不知道还能做什么，因为整个系统里没有状态追踪、没有评估集、没有质量反馈回路。
AI功能本质上是需要持续迭代的产品模块。模型版本会换、提示词要调、业务数据在变，所有这些都需要工程化支撑。没有评估集，你连"质量变好还是变坏"都说不清。
6.2 建立你的最小评估集
演讲里最实用的一句话：每一个AI功能，从第一天开始就要有评估集。不需要多，50条就够了——每条包括输入、期望输出、验收标准。每次改提示词、换模型、调参数，把这50条跑一遍，看通过率是升是降。
我的做法是写了一个Rake task，定时把评估集跑一遍，结果写到一张评估表里。本周通过率80%，下周换成新版提示词变成78%，那就回滚；变成85%，就继续。没有这个流程，所谓"优化AI效果"全是拍脑袋。
6.3 给后来者的实用建议
根据我自己踩过的坑，这里集中写几条：
- 从"镶边型"AI功能开始。先做摘要、分类、抽取这类任务边界清晰、失败影响可控的功能，不要一上来就做复杂Agent多跳转流程。
- 用ActiveRecord存Agent任务状态，用队列做编排，用日志做复盘。AI项目的基础设施，Rails全部都有，别自己发明轮子。
- 永远假设模型会失败。设计上从第一天就考虑超时、重试、降级、人工兜底，别上线后再补。
- AI代码必须经过严格Review。重点看索引、事务、N+1，这三条是我认为最重要的。
以我个人实际操作中的体会，AI Euphoria这场演讲真正触动我的不是"AI有多强"，而是它把AI拉了回来，回到了我们最熟悉的工程世界。给模型套上队列、日志、校验和重试之后，你会发现所谓"狂喜"，其实是一种一切都在掌控之中的踏实感。最后再分享一个小技巧：给模型调用加一个全局的request_id，贯穿Agent任务全链路，出了问题直接grep "req_xxx" logs/production.log，能省你整整一天的排查时间。把AI当成一个普通但又有点特别的外部依赖，Rails开发者一定能把它做得很稳。
