Rasa 是什么
Rasa 是成熟的对话式 AI 框架：通过训练式 NLU 管道完成意图分类和实体提取，并通过规则、故事（stories）和策略完成对话管理。它原生基于 Python，可自行托管，多年来一直是大规模脚本化客服助手的默认选择。Rasa Pro 增加了商业层级，包括由 LLM 驱动的对话。
相同的问题，不同世代的解法
EDDI 和 Rasa 都源自对话式 AI 领域，EDDI 自 2006 年起就作为对话平台持续开发。区别在于智能位于何处。Rasa 把它放在你用自己的标注数据训练的模型中，从而获得精确、可重复的控制。EDDI 把它放在由声明式配置治理的、经过编排的 LLM 中，以部分确定性换取覆盖范围和变更速度。
对话、工具与变更成本
| 维度 | Rasa | EDDI |
|---|---|---|
| 理解方式 | 训练式 NLU：基于标注数据的意图分类和实体提取 | LLM 理解，外加基于意图的智能体发现与路由 |
| 修改行为 | 更新训练数据、重新训练、评估、重新部署 | 编辑 JSON 配置；无需重新训练，也无需重新部署 |
| 确定性 | 高。规则和策略让流程可重复、可测试 | 本质上较低，通过行为规则和审批关卡予以弥补 |
| 语言 | Python；自定义动作是 Python 代码 | JVM 运行时；智能体逻辑是配置，工具是声明式的 |
| 工具生态 | 需要你自行构建和托管的自定义动作服务器 | 84 个 MCP 工具、内置智能体工具，外加任何 OpenAPI 端点 |
| 多智能体 | 每套部署一个助手是常见模式 | 基于协调者的编排和 7 种群组讨论风格 |
| 许可 | 社区版，外加商业授权的 Rasa Pro 层级；请核实当前条款 | Apache 2.0，OSI 认证 |
| 合规 | 自行托管支持数据驻留；合规框架按部署各自实现 | 审计账本、数据主体权利 API，平台内涵盖 15+ 个合规框架 |
关于对方工具的信息，已于 2026 年 10 月对照其官方文档和代码仓库核实。这些项目更新很快，决策前请向厂商确认当前行为。
如何在两者之间选择
Rasa 更合适的场景
- 你已经拥有标注好的对话数据，以及能维护 NLU 管道的机器学习团队。
- 监管或品牌方面的约束要求助手具备确定性，且决策路径可审计、不涉及语言模型。
- 针对狭窄意图集的超大规模流量，此时每轮 LLM 成本会占主导。
- 你需要对分类置信度阈值和回退行为进行细粒度控制。
EDDI 更合适的场景
- 助手必须基于变化速度快于重新训练周期的文档和系统来回答。
- 业务人员需要在没有机器学习工程师、没有训练运行、也没有部署的情况下修改行为。
- 问题需要多个专业智能体协作，而不是一棵扁平的意图树。
- 你想要 LLM 的灵活性，但合规官要求在上线前具备审批关卡和带签名的日志。
- 你想避免模型层的锁定：19 个提供商，或通过 Ollama 或 Jlama 使用的本地模型。
从 Rasa 迁移助手
这种映射是概念层面的而非机械的，因为两者把智能放在不同的位置。预期你需要把意图结构转换为路由和提示词，而不是转换文件。
| Rasa | EDDI |
|---|---|
| 意图和训练样例 | 基于意图的智能体发现；标注数据变为评估材料，而不再是训练输入 |
| 实体和槽位 | 结构化提取，外加持久化的用户记忆 |
| 故事和规则 | 行为规则和管道配置 |
| 自定义动作服务器 | MCP 工具或 httpCall 工具定义 |
| 响应和领域文件 | 提示词片段，可复用且带版本 |
| 回退策略 | 带超时策略的人工介入升级 |
常见问题
EDDI 只是又一个取代训练式 NLU 的 LLM 封装吗？
EDDI 自 2006 年起就作为对话平台开发，远早于当前这一代 LLM，并保留了真正重要的部分：基于意图的路由、受管理的对话状态和管道架构。LLM 取代的是理解层，而不是其周围的编排。
我们出于合规需要确定性的答案。这是否排除了 EDDI？
不一定，但这一取舍应当明确。LLM 的输出不是确定性的。EDDI 的应对方式是：用行为规则约束响应，对重大操作设置人工审批关卡，并用带签名的审计账本记录做出了什么决定以及原因。如果你的要求是决策中完全不能有语言模型参与，Rasa 是更好的答案。
过渡期间可以同时运行两者吗？
可以。常见的模式是，将已知的高流量意图路由到现有的 Rasa 助手，同时由 EDDI 处理开放式查询和系统集成，然后随着信心增强逐步转移流量。EDDI 可以通过 httpCall 调用 Rasa 端点。