这四个库里有三个，在出事时会写出同一份事故报告，因为它们派发的是同一份 JSON、对着同一张你填好的工具表。第四个让模型写 Python 然后执行——这不是更好或更坏的选择，而是另一套安全架构，套着同一个 Agent(...) 构造器。先按这一条选，永远别按手感选。
一眼看全
四个都是宽松许可的 Python 库，都能在十五行上下给你一个能用工具的智能体。它们分歧的地方，在于各自认为自己的职责是什么。
| 项目 | 许可证 | 重心落在哪 | 它不愿意管的 |
|---|---|---|---|
| Pydantic AI | MIT | 每一道边界上的类型契约——入参、工具、出参。 | 运行时、持久化、部署。 |
| smolagents | Apache-2.0 | 动作的表示法：模型写的是 Python，不是 JSON。 | 几乎其余一切——核心以「约一千行」著称。 |
| Agno | Apache-2.0 | 一套运行时与控制面：会话、记忆、追踪、审批。 | 很少。这既是它的卖点，也是它的代价。 |
| Strands Agents | Apache-2.0 | 一个模型驱动的循环，且心里早有部署目标。 | 对你应用层的意见。 |
把那张图读成四个不同的产品，而不是一张排行榜。Agno 的数字里含着冲着运行时与 UI 来的人；Pydantic AI 的数字里含着本来就信任 Pydantic 这个名字的人；Strands 的 PyPI 量与 star 数之比，则是一个「经由雇主而不是经由一篇博客抵达」的库的签名。这些都不告诉你该用哪一个。
派发机制才是真正的岔路口
Pydantic AI、Agno 与 Strands 走的都是寻常路线：模型吐出一个结构化的工具调用，框架拿名字去你填好的表里查，按 schema 校验实参，再调用你的函数。智能体能做的事的集合，就是你注册进去的那个集合。这条性质三者都不会拿来宣传，因为它是从厂商的 function calling API 继承来的——但正因如此，「这个智能体能干什么」的评审，才是一份清单的评审。
smolagents 把这件事翻了过来。它的 CodeAgent 让模型吐出 Python，然后执行；而框架自己的说法是，这正是要点所在——组合、循环与控制流都免费到手，而不必靠多轮往返去模拟。这是个确有实据的好主意，也是那个带后果的选择。
「执行」具体是什么意思
默认情况下，执行发生在 LocalPythonExecutor 里：那是一个遍历 AST 的解释器，而不是一次 exec() 调用——导入按白名单放行，操作次数设了上限，于是显而易见的死循环和显而易见的 import os 都被挡住。项目自己的文档对这层天花板很诚实：它比 exec() 安全，而它不是一道安全边界。要那个，你得挂上远程执行器：E2B、Docker、Modal、Blaxel 或 Wasm。
所以真正该比的不是「smolagents vs Pydantic AI」，而是「smolagents 加一个沙箱 vs Pydantic AI」；而沙箱是一笔持续开销、一片运维面、一份延迟预算。如果你本来就在某处跑不可信代码，这笔钱已经付过了，smolagents 近乎免费。如果没有，采用它就意味着把沙箱化当作一个子系统来采用；而这个决定值得被有意识地做出，而不是从一行 import 语句里继承下来。
各自到底怎么垮
对着同一种失效来横向比：一个被人劝动、去做了它不该做之事的模型。在另外三者的 JSON 派发下，损害的上限是你注册过的工具之并集——糟糕，但有界，而且可以对着一个文件审计出来。在「代码即动作」配本地执行器之下，上限是那个 Python 进程能够到的一切：在开发者笔记本上是开发者的凭证，在服务器上是服务账号。在「代码即动作」配远程沙箱之下，上限重新变得有界，而那道边界如今是一件你自己拥有、也必须持续打补丁的基础设施。三种姿态，一种 API 形状。
第二根轴：谁持有状态
把派发放到一边，另一份排名会浮现出来；而那一份，才预测得了十八个月后一次迁移要花多少钱。
Pydantic AI 与 smolagents 不持有任何持久之物。对话归你存，记忆归你定义，部署归你安排。这就是它们读起来「薄」的原因，也是替换掉其中任何一个只需一个周末的原因：你删掉一个依赖，数据原封不动。Pydantic AI 尤其是在刻意做一件事——在语言模型触及的每一道边界上放一个经过校验的类型，好让一个畸形的工具实参成为一个被捕获的异常，而不是下游某处一桩莫名其妙的失败。它是本文里最保守的选择，也是最容易反悔的。
Agno 则刻意是相反的提案。它是框架、是运行时、也是控制面：AgentOS 在你运行中的智能体之上给出聊天、会话、追踪、评测、记忆与审批，而记忆以用户 ID 为键、跨对话累积。对一个否则就得把这一切自己造一遍的团队来说，这是巨大的杠杆，那个 star 数是挣来的。它也是那个「采用会一路伸进你数据层」的。等六个月的用户记忆住进了它的 schema、而你的产品又把它们呈现出来，你手上就不再是一个库依赖，而是一套记录系统；换掉它是一次带回滚方案的迁移。
Strands 处在两者之间，重心落在部署叙事上而非应用叙事上。它给出一个模型驱动的循环，以及一大批 provider 类——Bedrock、OpenAI、Anthropic、Gemini、Ollama、Mistral、LiteLLM、SageMaker——这正是一个「预期自己会被一个早已选好云的组织采用」的库该有的样子。它的模型无关性是真的，也值得拥有；而围绕它的一切形状仍然是 AWS 形状的，而当那与你的部署位置相符时，想要这一点是合理的。
值得留意的那处倒置：star 数最大的那个库，退出成本最高；而 star 数最小的那个，背后是最有可能还在维护它的厂商。这两条事实单拎出来都不构成论证。而它们在任何一张功能表上都不存在。
什么时候该选哪个
| 情形 | 选 | 因为 |
|---|---|---|
| 放进一个既有 Python 服务里、端到端带类型的智能体 | Pydantic AI | 边界都经校验，无需采用运行时，反悔起来不费事。 |
| 数据类工作：任务本身就是调库、再把结果组合起来 | smolagents | 代码正是对的动作表示法——而且把沙箱当作这个决定的一部分算进预算。 |
| 你需要会话、记忆与一个评审 UI，否则就得自己造 | Agno | 杠杆是实打实的。在 schema 被填满之前，先把数据归属这个问题想清楚。 |
| 部署到 AWS，方案里有 Bedrock | Strands Agents | 与环境契合，同时不锁死模型选择。 |
| 你说不清自己需要的是哪一列 | Pydantic AI，然后重新评估 | 它是那个「选错了代价最小」的选择。 |
有一条告诫对四者都成立：智能体循环本身不是难的那部分，也不是你在买的东西。重试策略、工具派发和一份消息列表，在它们任何一个里都是几百行。你真正买下的，是一组关于校验、执行与持久化的决定——而这三者里唯一不能日后低价重议的，是持久化。
常见问题
「代码即动作」真的比 JSON 工具调用好吗？
对于主要是组合的任务——筛这个、跟那个连起来、对结果做循环——是的，而且好得可测量，因为模型在一个代码块里表达完的事，JSON 派发要花好几轮往返。对于「一串离散的、需要逐个审批的副作用」这类任务，它更糟，因为你把一份可评审的调用清单换成了一段程序。更长的论证见代码即动作。
不配沙箱能用 smolagents 吗？
能；而且在本地拿自己的数据做实验，这是合理的。那个遍历 AST 的本地执行器按白名单放行导入、给操作次数设上限，比 exec() 安全得有意义。但它不是一道你该把不可信输入放在其后的边界，项目自己也这么说。上生产就挂上 E2B、Docker、Modal、Blaxel 或 Wasm。
star 数更大是不是更稳妥的赌注？
它意味着来的人更多。在本文里，最大的那个项目恰恰是采用后伸进你数据模型最深的那个，而最小的那个背后是一家云厂商。star 量的是关注度；你想知道的是维护状况与退出成本，而这两样都不在那张图上。
这些与 LangGraph、CrewAI、OpenAI Agents SDK 是什么关系？
那些位于编排栈更上面的位置，为多智能体工作备了显式的图或 handoff 原语。这里的四个更轻：三个是你从自己的控制流里调用的库，还有一个（Agno）正在底下长出一个运行时。如果你的问题是协调好几个智能体，相关的是那份对比。
要是以后需要换呢？
那就守住让「换」变便宜的那两样：把你的工具函数写成签名里不含框架类型的普通 Python；把你的对话与记忆状态放进一个你自己定义的 schema。做到这两点，这四个里换任何一个都是几天的事。跳过这两点，你选的那个框架就变成了一条关于你数据库的事实。
延伸阅读
本站：
- 智能体框架——这个品类是干什么的。
- 代码即动作——smolagents 所依托的那个模式。
- 沙箱与代码执行——那个选择所蕴含的子系统。
- 结构化输出——Pydantic AI 处处强制的那条性质。
- 退出一个托管智能体运行时——那张 star 图藏起来的成本。