截至 2026 年 8 月 17 日，Google ADK 与 OpenAI Agents SDK 的官方资料都以 Python 3.10 作为基础支持门槛。(github.com)
本周建议动作：不要先按 GitHub 星标选框架。先从轻量 SDK、状态型工作流、多 Agent 协作和知识型框架中各挑候选，再用同一任务、同一模型、同一运行环境完成 POC。简单单 Agent 选薄抽象；长任务选图或工作流；只有确实需要角色分工时，才选多 Agent 框架。
最后更新于 2026 年 8 月 17 日，框架状态、许可证、支持语言与核心能力核实自各项目官方仓库、README、LICENSE、Releases 和功能文档。
这篇文章适合谁，以及 10 个候选如何划边界
如果你准备从零开发工具型、编码型或知识型 Agent，需要先建立一份可验证的框架短名单，这篇文章适合你。
如果你的 Agent 原型正在迁移到持续运行环境，或者你需要控制权限、恢复能力、维护成本和基础设施投入，也可以直接使用后面的决策矩阵。
本文纳入的 10 个候选是：
- LangGraph
- OpenAI Agents SDK
- Google ADK
- Microsoft Agent Framework
- CrewAI
- Pydantic AI
- Mastra
- smolagents
- Strands Agents
- LlamaIndex
入选标准不是“热门”或“星标高”，而是：
- 核心代码有公开仓库和明确许可证；
- 官方仓库仍有发布、提交或维护说明；
- 能独立运行 Agent，而不只是模型调用封装；
- 至少覆盖工具调用、Agent 循环、工作流或多 Agent 编排中的一类核心能力。
例如，OpenAI Agents SDK 官方定位是轻量、多 Agent 工作流 SDK，提供工具、Handoff、Guardrails、Sessions 和 Tracing；Google ADK 则强调代码优先、评估、部署和多 Agent 组合。(github.com)
哪些项目不应被混为一谈？
薄 SDK 负责减少 Agent 循环和工具接入的样板代码。图式工作流负责状态、分支、暂停和恢复。CrewAI 这类角色协作框架适合职责清楚的多 Agent 场景。LlamaIndex 更偏知识、数据接入、检索和文档 Agent，不应直接拿来和纯 Agent SDK 比“谁更轻”。(github.com)
先看开发成本：轻量抽象和强流程控制不是同一件事
比较首次运行时，不要只数代码行数。更应该看 4 个问题：
- 你是否需要理解新的状态模型；
- 工具参数和结构化输出是否自动校验；
- 从单 Agent 扩展到多步骤任务时，是否需要重写；
- 调试时能否定位“模型决策错”还是“工具执行错”。
| 框架类型 | 代表候选 | 首次开发成本 | 复杂任务扩展 | 更适合的项目 |
|---|---|---|---|---|
| 薄 SDK | OpenAI Agents SDK、Pydantic AI、Strands Agents | 低 | 依赖应用层编排 | API Agent、客服、内部助手 |
| 图式工作流 | LangGraph | 中 | 状态、分支、暂停和恢复更清晰 | 长任务、审批流、编码 Agent |
| 多 Agent 协作 | CrewAI、Microsoft Agent Framework | 中到高 | 角色、委派和流程需要额外治理 | 研究、内容、流程分工 |
| 代码执行型 | smolagents | 低到中 | 需要重点处理沙箱和权限 | 数据处理、代码 Agent |
| TypeScript 工作流 | Mastra | 中 | 适合融入 Node.js 应用 | Web App、TS 服务 |
| 知识型框架 | LlamaIndex | 中 | 数据管线与 Agent 组合能力强 | RAG、文档、知识库 Agent |
Pydantic AI 的核心思路是用 Python 类型提示和 Pydantic 校验约束 Agent 输入、输出与工具接口；smolagents 则保留较薄的抽象，并同时提供 CodeAgent 和 ToolCallingAgent。两者都适合快速验证，但生产环境仍要自行补齐权限、隔离和恢复机制。(github.com)
Python 团队和 TypeScript 团队应该怎么分流？
Python 团队可以优先比较 LangGraph、OpenAI Agents SDK、Google ADK、Pydantic AI、CrewAI、smolagents、Strands Agents 和 LlamaIndex。TypeScript 团队则应重点看 Mastra，同时核对其他候选是否提供与你现有运行时匹配的官方 SDK，而不是只看社区适配包。
工具调用：能接入工具，不等于能安全运行工具
工具能力至少要拆成 5 个检查项：
- 函数工具是否能自动生成或校验参数；
- 是否支持 MCP；
- 工具调用前能否暂停并请求人工确认；
- 是否有超时、重试和错误返回机制；
- 是否能记录调用参数、结果和执行身份。
OpenAI Agents SDK 官方文档明确列出 Function Tools、MCP Server Tool Calling、Guardrails、Human in the Loop 和 Tracing。Google ADK 也提供工具确认流程，可在工具真正执行前要求显式确认。(github.com)
你可以把工具按风险分成 3 级：
- ✅ 低风险：只读搜索、读取公开文档、查询数据库；
- ⚠️ 中风险：写入业务数据、发送邮件、创建工单；
- ❌ 高风险：执行 Shell、读写代码仓库、删除文件、访问生产服务。
如果 Agent 需要执行命令或修改文件，优先选择有明确沙箱路径的方案。OpenAI Agents SDK 提供 Sandbox Agents，并允许配置工作区；smolagents 官方资料则列出 Docker、E2B、Modal、Blaxel 等沙箱方向。这里要注意：框架能调用沙箱，不代表沙箱已经按你的安全边界配置完成。(github.com)
状态与工作流：短会话、长任务和人工审批要分开评估
单 Agent SDK 通常把状态交给应用层。这样上手快，但你要自己决定会话存储、幂等键、重试策略和恢复位置。
LangGraph 的优势在于把状态和执行路径显式化。官方代码与文档中可以看到 Checkpoint、Interrupt、Durability 和恢复相关接口；其持久化机制可支持人工介入、记忆、时间回溯和故障恢复。(github.com)
你可以按任务特征选择：
- 只需一次模型调用加 1—2 个工具：OpenAI Agents SDK、Pydantic AI 或 Strands Agents；
- 需要循环、分支、人工确认和暂停恢复：LangGraph；
- 需要多个角色互相委派：CrewAI 或 Microsoft Agent Framework；
- 需要文档解析、检索、索引和知识型 Agent：LlamaIndex；
- 已有 Node.js / TypeScript 服务：Mastra；
- 希望让 Agent 用代码组合工具：smolagents，但必须先设计沙箱边界。
多 Agent 一定比单 Agent 更适合复杂任务吗？
不一定。多 Agent 会增加上下文传递、角色冲突、调度、成本和失败定位问题。只有当任务确实存在稳定的职责边界，例如“检索、审查、执行”由不同角色负责时，多 Agent 才可能带来结构性收益。否则，一个带明确状态图和工具权限的单 Agent，通常更容易测试。
可靠性和生产部署：演示成功只是起点
开源 AI Agent Framework 上生产前，至少要验证下面 6 项：
- [ ] 模型超时后是否能识别失败类型；
- [ ] 工具返回异常时是否保留原始错误上下文；
- [ ] 进程中断后能否从最近状态继续；
- [ ] 重试是否可能重复扣款、重复写入或重复发送；
- [ ] Tracing 是否记录模型、工具、耗时和输入输出摘要；
- [ ] 敏感信息是否会进入日志、Checkpoint 或第三方托管服务。
Microsoft Agent Framework 官方仓库同时覆盖 Python 和 .NET，并提供从 Semantic Kernel、AutoGen 迁移的文档；这对企业多语言团队有价值，但也意味着你需要额外确认不同语言实现的功能是否完全一致。(github.com)
Strands Agents 采用模型驱动的 Agent Loop，支持 MCP、多 Agent、流式输出和多个模型提供方；Mastra 则面向现代 TypeScript 技术栈，但其仓库采用 Apache 2.0 与企业许可并存的目录划分，部署前必须核对你使用的具体目录和功能许可。(github.com)
统一 POC 的 5 步验收流程
第一步，固定输入。
准备同一组任务、同一批工具、同一模型和同一数据集。不要让每个框架使用不同 Prompt 或不同上下文。
第二步，只实现最小任务。
让 Agent 完成“读取一个文件、调用一个外部服务、返回结构化结果”这条链路。先不加入多 Agent，避免把框架差异和业务复杂度混在一起。
第三步，加入 3 类故障。
分别制造工具异常、模型超时和进程中断。记录错误是否可定位、任务是否能恢复、已完成步骤是否会重复执行。
第四步，测试权限。
验证读文件、写文件、执行命令和访问外部服务是否可以分别授权。确认人工确认发生在执行前，而不是执行后才记录。
第五步，做迁移和维护检查。
核对 LICENSE、Release、迁移文档、Python 或 TypeScript 支持范围，并把锁定版本、依赖清单和部署脚本一并提交。Google ADK 官方仓库明确区分稳定安装与直接从主分支安装的开发版本，后者应主要用于测试新变化。(github.com)
2026 年候选短名单：按条件选，不按热度排
你可以先用下面的条件缩小范围：
- 快速原型：OpenAI Agents SDK、Pydantic AI、Strands Agents；
- 长任务和状态型工作流：LangGraph；
- 明确的多角色协作：CrewAI；
- 企业 Python 与 .NET 团队：Microsoft Agent Framework；
- Google 生态或需要工具确认：Google ADK；
- TypeScript 应用：Mastra；
- 代码执行型 Agent：smolagents；
- 文档、RAG 和知识 Agent：LlamaIndex。
许可证也要进入验收表。你应逐一打开 10 个官方仓库的 LICENSE 文件，确认核心代码、插件目录和企业功能是否属于同一许可范围。尤其是存在多种许可目录的项目，不能只根据仓库首页的一个许可证名称判断整个部署方案是否可用。
建议你的最终 POC 短名单不超过 3 款：
- 一款薄 SDK；
- 一款状态型工作流框架；
- 一款与你团队语言或知识场景最匹配的候选。
如果你的当前方案是直接用模型 API 加自写循环，短期看起来灵活，但通常会逐渐暴露出状态存储分散、工具权限难审计、失败恢复靠业务代码补丁等问题。若改用其他云主机，又可能遇到环境不一致、并行 POC 资源不足和持续运行维护成本上升。对于需要同时测试多款框架、执行编码 Agent 或保持隔离工作区的团队，租赁 Hashvps 的 Mac 环境往往比临时改造本地设备更容易控制交付路径；你可以先查看 Hashvps 的云端环境与服务说明，再结合 帮助中心 核对远程连接、部署和运维细节。
本周先建立隔离 POC，不要直接把候选框架接入生产。等统一验收完成后，再决定是自购 Mac、继续使用现有云环境，还是使用 Hashvps 的 Mac 租赁环境承载并行测试与持续任务。
为 Agent POC 准备一台稳定的云端 Mac
使用 Hashvps 的原生 macOS 云端 Mac，在真实环境中快速验证 Agent 框架的工具调用、工作流与自动化能力。
M4 Apple Silicon、最高 1Gbps 独享带宽与独享公网 IPv4，适合开发调试、自动化测试和持续集成节点。