当所有人都在用Python和TypeScript，他偏要赌一把Elixir
2024年初，Mike Hostetler 做了个在当时看来有点"反直觉"的决定。
那时候AI Agent赛道刚刚火起来，所有人都在用Python——OpenAI的SDK是Python的LangChain是Python的。TypeScript那边也有Hugging Face、AutoGPT这些玩家。两条路都被占满了，选哪个都不算出格。
但他偏不。
他选了Elixir，选了BEAM虚拟机，选了一条几乎没人走的路。
"TypeScript agent frameworks felt like toys. Single-threaded event loops trying to juggle concurrent agents with promises and prayer. Python agents did a little better, but after a long time they couldn't stay up. The BEAM was built for exactly this kind of work."
这话说的很不客气，但意思很明白：在座的各位，都是弟弟。
18个月后，他赌对了。
从BotHive到Jido：一个"失败"开局的逆袭
故事的开始其实有点狼狈。
2024年，Mike Hostetler 做的第一个产品叫BotHive，一个机器人平台。想法挺好，定位也清晰。但很快，AI Agent浪潮来了。
他做了一个决定：推翻重做。
这个决定需要勇气。18个月的开发周期，足够一个技术团队从入门到放弃。但他没有犹豫——既然AI Agent才是未来，那就要做一个真正为Agent而生的框架，而不是在旧架构上缝缝补补。
Jido 1.0 在2024年3月发布了。
然后他发现，自己挖了个坑。
"I was still learning OTP in depth, and it showed. I added abstractions that didn't make sense in practice. This created too much friction to do basic things that other agent frameworks made easy out of the box."
说实话，这种坦诚挺难得的。一个开发者公开承认自己早期代码"过度工程化"、"学习曲线陡峭"，这不多见。
但真正让我高看他一眼的，是他接下来做的事：
他没有硬着头皮继续堆功能，而是停下来，认真听社区反馈。
2.0的核心：把"复杂"藏起来，把"简单"交出去
Jido 2.0 的设计哲学就一句话：People wanted to build agents, not fight the framework.
怎么理解这句话？
想象一下：你是一个开发者，你想写一个AI Agent帮你查订单、回答客户问题。在其他框架里，你可能需要先配置环境、理解异步机制、处理各种边界情况。写个Demo要半天，真正跑起来又是另外一回事。
Jido 2.0 的做法是：Agent就是数据，命令就是函数。
{:ok, updated_agent, directives} = Jido.Agent.cmd(agent, {ProcessOrder, order_id: "123"})
没有进程，没有副作用，完全可测试。单元测试不需要网络、不需要数据库、不需要调用LLM——这在以前几乎不可想象。
但这还不是最狠的。
最狠的是策略层。
Jido 2.0 允许你像插拔U盘一样更换Agent的执行策略：
- Direct：顺序执行，简单直接
- FSM：状态机，带过渡守卫
- ReAct：推理+行动，标准的Agent循环
- Chain-of-Thought：链式思考
- Tree-of-Thoughts：树状思考
- Graph-of-Thoughts：图状思考
同一套代码，换个策略就能换种"思维方式"。这就好比给同一个大脑换不同的思维模式，而且这些模式都是开箱即用的。
一个Side Quest的意外收获
开发过程中有个小插曲，Mike Hostetler 不得不先做个"副项目"——ReqLLM。
为什么？因为没有好用的Elixir LLM客户端。
他原本可能只是想临时写个工具自己用，结果写着写着，ReqLLM长成了一个独立的项目：1.6版本、11个Provider实现、覆盖665+模型、有了自己的贡献者社区、好几家公司生产环境在跑。
有时候就是这样。你奔着A去，结果顺路做出了B，而且B可能比A更有影响力。
这让我想起一句话：真正的创新，往往诞生于解决自己实际痛点的过程中。
为什么Elixir/BEAM适合AI Agent？
这个问题值得展开说说。
首先，BEAM虚拟机生来就是为了高并发。它可以轻松跑几千个"进程"（Erlang进程，不是操作系统进程），每个进程只有几KB内存占用。一个Reddit用户说的很直接：
"BEAM is so incredibly lightweight. Theoretically you could run 1000s of agents on a single server."
其次，监督树（Supervision Tree）机制让它特别适合做"容错"。
一个Agent调用链失败了，怎么恢复？传统的做法是try-catch+重试逻辑。但在BEAM里，每个工具执行都可以是一个受监督的单元，有清晰的重启/升级语义。你不用自己写容错代码，框架帮你搞定。
第三，位置透明性。虽然严格来说不是完全的透明，但OTP的设计让分布式Agent变得出奇地自然。
有个评论说的很精准：
"The hardest part with agent frameworks isn't model plumbing, it's operational boundaries: how you isolate tools, enforce time/budget limits, and recover from partial failures when an agent call chain fans out. BEAM's supervision model feels like a genuinely strong fit for that."
一个彩蛋：Ash Framework的深度整合
Jido 2.0 还放了个大招：ash_jido。
如果你在用Ash Framework（一个Elixir生态里很火的元框架），现在可以直接在Ash资源里加一个jido DSL块，你的CRUD操作瞬间变成AI可调用的工具，而且保留授权策略、数据层、类型安全。
这意味着什么？
意味着你不用为了支持AI Agent而重写现有代码。已有的Ash资源加几行配置，就能被LLM调用。
这个整合思路很聪明：与其说服开发者从零开始用Jido，不如让他们在现有系统上"长出"Agent能力。阻力小很多，落地快很多。
尾声：一个小众语言的逆袭时刻
看完Jido 2.0的发布日志，我脑子里就一个想法：有时候，慢就是快。
当所有人都在追Python、追TypeScript、追最新最热的框架时，有人愿意花18个月打磨一个"非主流"方案，而且真的把它做成了。
这不是叛逆，这是选择。
Elixir从来不是最流行的语言，BEAM也不是最被讨论的运行时。但它们有自己独特的优势——高并发、容错、分布式——而这些恰恰是AI Agent系统最需要的。
一个人，18个月，硬刚整个Agent圈。
结果他把事情做成了。
【MiniMax-M2.1锐评】：用"Agent就是数据"这种极简哲学对抗TypeScript/Python的臃肿，18个月的冷板凳坐出了BEAM生态的第一个Agent框架。这波叫：用魔法打败魔法。
参考链接：
https://jido.run/blog/jido-2-0-is-here