Jido Elixir 智能体框架
面向 Elixir/OTP 的有状态工作流与协作进程框架。
- Star 数
- ★ 1.9k
- 最近更新
- 22 天前
- License
- Apache-2.0
- 主语言
- Elixir
- FA 评分
- 50/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台
- 费用
- 免费,无需付费服务
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- Elixir 后端团队需要把多个长期运行、可监督的业务进程组织为协作工作流时。
- 不适合
- 需要 Python 或 JavaScript 生态的团队,Jido 只面向 Elixir/BEAM
- 仍在使用 Elixir 1.16 或 OTP 25 及更早版本的项目
- 希望开箱即用内置大模型接入的团队,核心包不含 AI 能力
- 源码审查
- 50/100 · 缺口较多
这个 Agent 能做什么,适合哪些场景?
Jido 是一个用于构建工作流和多主体系统的 Elixir 自主智能体框架。它将智能体定义为带状态、实现 cmd/2 的不可变结构;Action 执行工作并转换状态,Signal 将事件路由进系统,Directive 描述由运行时处理的外部效果。生产运行使用基于 GenServer 的 AgentServer,并提供监督、父子智能体生命周期、信号路由、实例分区和多租户边界。框架还提供 Direct 与 FSM 执行策略、可组合插件、计划式编排和 Pod 形式的持久智能体组。AI 不是核心运行条件,模型集成由 jido_ai 等生态包按需提供。
开发者用 use Jido.Agent 定义名称、描述、schema 和 signal_routes,再用 use Jido.Action 定义带参数 schema 的 run/2。调用 MyAgent.cmd(agent, {ActionModule, params}) 会执行 Action,返回更新后的 agent 与 directives;StateOp 由策略层处理状态更新,而 Emit、SpawnAgent、Schedule、Stop 等 Directive 由 AgentServer 运行时解释。运行中的 AgentServer 可通过 Jido.AgentServer.call(pid, Jido.Signal.new!("increment", %{amount: 10}, source: "/user")) 接收 Signal;实例模块可用 start_agent、whereis 和 list_agents 管理进程。
- Elixir 后端团队需要把多个长期运行、可监督的业务进程组织为协作工作流时。
- 需要将 CloudEvents 风格消息路由到有明确状态和命令边界的服务时。
- 构建需要父子进程生命周期管理、延迟调度或运行时发射事件的 BEAM 应用时。
- 希望以 FSM 策略实现状态驱动流程,而非在 GenServer 回调中混合业务逻辑时。
- 需要在共享实例中通过 logical partitions 或 Pod 管理多租户工作空间时。
如何安装或部署这个 Agent?
运行:
mix igniter.install jido这会添加依赖、创建 MyApp.Jido、写入配置并加入监督树。也可在 mix.exs 添加 {:jido, "~> 2.0"},创建:
defmodule MyApp.Jido do
use Jido, otp_app: :my_append
在 config/config.exs 配置:
config :my_app, MyApp.Jido, max_tasks: 1000, agent_pools: []并将 MyApp.Jido 放入 application.ex 的 children。文档要求 Elixir 1.17+ 与 Erlang/OTP 26+;未说明凭据要求。
如何使用这个 Agent?
先定义 Agent 和 Action,例如为 Agent 配置 signal_routes: [{"increment", MyApp.Actions.Increment}],并在 Action 的 run/2 中返回 {:ok, %{count: current + params.amount}}。创建并执行:
agent = MyApp.CounterAgent.new(){agent, directives} = MyApp.CounterAgent.cmd(agent, {MyApp.Actions.Increment, %{amount: 5}})
要以进程方式运行:
{:ok, pid} = MyApp.Jido.start_agent(MyApp.CounterAgent, id: "counter-1")
{:ok, agent} = Jido.AgentServer.call(pid, Jido.Signal.new!("increment", %{amount: 10}, source: "/user"))
Signal 类型必须已在 signal_routes 中声明。
这个 Agent 有哪些优点和局限?
- 以 Elixir/OTP 和 GenServer 为基础,提供监督与故障容忍,而不是只提供链式调用接口。
- cmd/2 明确返回更新后的 agent 和 directives,使状态转换与运行时拥有的效果分离。
- 提供可配置的父子层级、实例作用域监督、逻辑分区与 Pod,适合持久化协作进程拓扑。
- Direct 与 FSM 策略,以及可合并 schema 的插件,支持不同的工作流建模方式。
- 采用需要 Elixir 1.17+ 和 Erlang/OTP 26+,对非 BEAM 技术栈团队存在运行时与迁移成本。
- AI/LLM 不属于核心包;需要模型功能时还要评估并集成 jido_ai、req_llm 等生态包。
- Action 可以执行 API、文件或数据库操作,因此具体应用仍须自行设计 I/O、权限和错误处理边界。
- 资料只展示内置运行时与生态包,未说明针对 OpenAI、Anthropic 或其他命名模型提供商的核心包适配范围。
这个 Agent 与同类方案有什么区别?
README 将 Jido 与 LangChain、CrewAI 对比:LangChain 被描述为 Python 优先的链式编排,CrewAI 被描述为基于角色的团队协作;Jido 的定位是建立在 GenServer 之上的 OTP 原生智能体模式,强调监督树、不可变状态和显式 Directive 效果边界。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Jido Elixir 智能体框架 当前 | 50 · 缺口较多 | 开发框架免费 | ★ 1.9k | 22 天前 | Elixir | — |
| Lemon 常驻编码代理 | 72 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 136 | 2 天前 | Elixir | OpenAI API · Claude API |
| Pi Dynamic Workflows | 72 · 存在缺口 | Agent 插件 / 技能免费 + 模型费 | ★ 591 | 12 天前 | TypeScript | — |
| Agently AI 应用运行时 | 64 · 存在缺口 | 代码库 / SDK免费 + 模型费 | ★ 1.7k | 26 天前 | Python | OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent?
查看各维度的扣分理由
README 明确区分 Agent 决策、Action 与 Runtime directive,并指出 Action 可执行 API、文件和数据库操作,directive 由 runtime 解释;这种效果边界提升可见性,但没有展示按操作进行权限控制、敏感数据处理或撤销策略,因此这些项扣分。发布 skill 提供逐步检查和人工确认,但它属于发布流程,不证明一般 Agent 操作需要用户确认。工作流权限可见且较窄;依赖安全与发布者身份缺少独立证据。
README 描述不可变状态、监督树和结构化流程,AGENTS.md 也强调纯 cmd/2 和 tagged errors;但 README 将开发基线写为 Elixir 1.17+/OTP 26+,AGENTS.md 写为 Elixir ~>1.18、OTP 27+,构成版本说明不一致。CI 配置指向外部可复用工作流,依赖供应情况未在材料中说明。README 有 timeout 与 signal 排障步骤,但失败信息和恢复行为缺乏具体覆盖。
材料明确定位 Elixir/OTP 工作流、多 Agent 与可选 AI 用途,并说明直接执行、FSM、插件、信号和多租户等能力边界。发布 skill 的触发条件具体;不过面向不同部署环境的前置条件有版本基线冲突,环境适配说明不完整。
README 组织了安装、快速开始、概念、指南和 FAQ;Igniter 与手动安装均有步骤。Agent、Action、Signal、Directive 等命名在文档中相对稳定,示例可操作。README 说明 AI 可选和 Action 可有副作用,但已知限制不系统。LICENSE 明确为 Apache-2.0。版本范围示例为 ~>2.0,但没有提供 changelog,AGENTS.md 说明发布说明由 Git 历史生成。维护责任只有版权人和贡献指南线索,未说明支持承诺;发布者身份仍未知。
README 提供从定义 Agent 到运行 AgentServer 的完整示例,列出核心能力和生态包,能帮助读者判断适用性。成本收益说明偏概括,没有量化资源、运营成本或与原生 OTP 的迁移代价,故未给高分。
主要架构主张可在 README 的契约、特性表和示例中追溯,AGENTS.md 对纯决策、runtime 和结构化错误做了交叉呼应,CI 与发布 workflow 也提供配置证据。部分性能、可靠性及生产适用主张没有本材料中的结果证据;文档一般能区分事实和设计建议,但版本基线冲突削弱了可核验性。
- 安装前核对目标环境的 Elixir/OTP 版本:README 与 AGENTS.md 给出的最低版本不同。
- Action 可以直接访问 API、文件和数据库;部署时应由应用自行限制权限并评估副作用,材料没有显示通用确认或回滚机制。
- CI 和发布流程引用外部可复用 GitHub Actions 工作流;此材料未提供其实现或依赖安全审查结果。
最近版本
来自该项目 GitHub Releases 的最新发布记录,说明为上游原文摘录,未经本站改写或测试。
-
发布说明摘录
Breaking Changes: * agent_server: remove custom process spawn callback by mikehostetler * agent: replace supplied state fields in set by mikehostetler * agent: use DSL blocks for module definitions by mikehostetler * agent: remove redundant definition getters by mikehostetler * agent: require plain map route defaults by mikehostetler * agent: require one executable per route by mikehostetler * name route Signal helpers with as by mikehostetler * use one durable Agent identity by mikehostetler * replace Agent and Topology Builders with data constructors by mikehostetler …在 GitHub 查看 ↗ -
v2.4.0 Release v2.4.0
发布说明摘录
Features: * agent: enforce optional state size budgets by mikehostetler Bug Fixes: * schema: preserve defaults with Zoi 0.18.11 by mikehostetler * deps: update mint for security advisory by mikehostetler * lifecycle: preserve normal owner shutdown reasons (#367) by Iulian Costan * error: preserve validation paths in transport (#336) by mikehostetler在 GitHub 查看 ↗ -
v2.3.3 Release v2.3.3
发布说明摘录
Bug Fixes: * deps: update Mint for CVE-2026-59249 by mikehostetler * instance-manager: fail closed on thaw errors (#316) by mikehostetler * agent-server: serialize sync call drain races (#312) by mikehostetler在 GitHub 查看 ↗
常见问题
Jido 是否必须使用 AI 或 LLM?
cmd/2 返回的 directives 会再次修改 agent 状态吗?
生产环境如何运行智能体?
框架怎样处理运行中子进程和故障?
核心包是否要求网络、文件系统或 MCP?
谢谢反馈,我们会据此改进页面。