Jido 2.0：把 Agent 当数据、跑在 BEAM 上的 Elixir 框架

2026 年 3 月 4 日，Mike Hostetler 宣布 Jido 2.0发布并上线 Hex。这个项目从 2024 年一个叫 BotHive 的机器人平台起家，作者赌了一件事：BEAM（Erlang/Elixir 虚拟机）才是跑 Agent 系统的最佳运行时。本文基于官方博客与 Hex 文档，拆解 Jido 2.0 的设计取舍，并把“官方观点”和“可核实事实”分开。

一、为什么是 BEAM

作者的立论很直白：TypeScript 的 Agent 框架是“单线程事件循环用 Promise 拼并发”，Python 的 Agent“跑不久就挂”，而 BEAM 从设计之初就是为海量并发进程、监督树、故障恢复而生的——这正是长期运行的 Agent 系统需要的。这是一个有观点的判断，而非 benchmark 结论，但它解释了 Jido 为什么走了一条和主流 TS/Python Agent 框架不同的路。

二、核心抽象：Agent 即数据

Jido 2.0 的地基是一个纯函数式的 Agent 模型：Agent 就是一个数据结构——一个带 state、actions、tools 的 struct，可以放进 GenServer 里运行。一切都流经同一个函数 cmd/2：动作进去，更新后的 agent 加上一份 directive（指令）列表出来。副作用不直接发生，而是被描述成类型化的 directive，由运行时去执行。

这带来一个直接好处：你可以在不碰网络、数据库或 LLM 的情况下，对 Agent 的每一次决策做单元测试。官方给的最小示例是这样的：

{:ok, updated_agent, directives} = Jido.Agent.cmd(agent, {ProcessOrder, order_id: "123"})

Jido.AgentServer 把任意 Agent 包进一个受监督的 GenServer，负责信号路由、指令执行和父子 Agent 层级——这是后续一切的 Agent 运行时。

三、策略是扩展点，AI 只是其中一种

Jido 把“怎么处理动作”抽成可插拔的 strategy。核心自带两个：Direct（顺序执行）和 FSM（带迁移守卫的状态机）——这两者完全不涉及 AI。ReAct、Chain-of-Thought 等推理策略，在 Jido 里只是往循环里加了 LLM 调用的 strategy 实现，用的是同一个 cmd/2 契约、同一套 directive 系统。作者想强调的是：AI 层是扩展，不是另一个世界；甚至 jido_behaviortree 这种行为树执行器也复用同一策略接口。

四、生态拆分：action 与 signal 独立成包

2.0 把两个横切关注点拆成了独立包：

• jido_action：统一的 action 契约。每个 Agent 能力都是一个带编译期 schema 校验、生命周期钩子的 Jido.Action，并能自动转成 ReqLLM 的 tool 格式；自带 25+ 预置工具和一个 DAG 工作流规划器。
• jido_signal：消息“神经系统”，基于 CloudEvents v1.0.2 规范，提供标准化信号信封、高性能 trie 路由、pub/sub 总线和九种 dispatch 适配器。作者刻意用标准而非私有协议，以便对接外部系统。

五、Jido AI 与 ReqLLM

在 Agent 核心之上是 Jido AI，自带六种推理策略：ReAct、Chain-of-Thought、Tree-of-Thoughts、Graph-of-Thoughts、TRM 和 Adaptive，对应不同成本/深度/质量权衡。它构建在作者自己的 Elixir LLM 客户端 ReqLLM 之上——这是个“副业产物”，因为当时不存在现成的；官方称其为 streaming-first、多 provider，11 个 provider 实现覆盖 665+ 模型，目前 ReqLLM 已到 1.6 版并有公司在生产使用。此外 ash_jido 随 2.0 发布，让 Ash Framework 资源的 CRUD action 直接变成带授权策略的 AI 可调用工具。

六、关键事实表

七、口径批判：哪些是观点，哪些是事实

必须把官方叙事里的态度和事实分开：

• “TypeScript/Python Agent 框架是玩具、跑不久”是作者观点，博客里没有给出任何并发数、延迟、崩溃率的对照基准，不能当成实测结论。
• “被生产验证”“18 个月打磨”是自述口径；本文能核实的是 Hex 版本号、Apache-2.0 协议、CloudEvents 规范、665+ 模型这类可对照的事实。
• Jido 1.0 被作者自己承认“过度设计”，2.0 是推倒重来的简化——这说明它 API 仍在快速演进，生产采用要钉住版本并接受变更成本。
• BEAM 的并发与容错优势真实存在，但门槛是 Elixir/OTP 功力：不熟悉 GenServer/监督树的团队，上手成本不低。

八、优势与局限

优势：Agent 即数据 + 纯函数 cmd/2，可测试性极强；strategy 可插拔，AI 与非 AI 逻辑统一在同一契约；基于 CloudEvents 与监督树，天然适合长驻、多 Agent、需要故障恢复的生产系统；背靠 Elixir 生态（Phoenix/LiveView/Ash/Req/Telemetry）。

局限：生态年轻，2.0 刚重写，文档与周边包仍在补齐；目标用户是已经会 Elixir 的团队，对只懂 TS/Python 的人有迁移成本；缺少独立第三方 benchmark，“比 TS/Python 框架更稳”目前仍是主张而非证据。

九、谁该关注

已经在用 Elixir/OTP、想把长驻 Agent 服务当成普通并发容错软件来写的团队，Jido 2.0 值得认真评估；若你的团队栈在 TS/Python 且没有 BEAM 经验，它更适合作为“另一种 Agent 架构观”来借鉴，而非直接替换。

参考来源

• Jido 2.0 is now available（官方博客）
• Jido Hex 文档 v2.3.3
• GitHub org agentjido
• Koala 项目库条目