智能体框架选型Claude Agent SDK、LangGraph、Deep Agents、LlamaIndex、CrewAI、AgentScope 与 OpenAI Agents SDK
**摘要：**本文对 Claude Agent SDK、LangGraph、Deep Agents、LlamaIndex、CrewAI、AgentScope、OpenAI Agents SDK 等主流智能体框架进行横向深度评估，从架构范式、模型与运行时锁定、持久化与故障恢复、安全治理、部署伸缩、许可与成本等维度展开比较。核心结论是：不存在在所有维度都占优的框架，选型的关键在于识别应用属于显式状态机、长程自主 Agent、数据/RAG Agent、角色型多 Agent 还是轻量 handoff/tool loop。文章给出通用默认建议（LangGraph 作为编排底座、Deep Agents 作为长程 Agent harness），并按业务场景、团队规模与合规要求提供决策流程、分层技术栈与最终选型建议。
执行摘要
研究结论先行：不存在一个框架在所有维度都占优。真正的分界线不是“哪个框架 Star 多”，而是你的应用更接近哪一种运行时范式：显式状态机、长程自主 Agent、数据/RAG Agent、角色型多 Agent、代码执行型 Agent，还是轻量 handoff/tool loop。
截至 2026 年 10 月 3 日，综合架构成熟度、部署弹性、模型锁定、持久化能力、安全治理、开发体验和生态，我的选型判断如下：
| 需求画像 | 首选 | 次选 | 核心理由 |
|---|---|---|---|
| 通用生产级 Agent / 工作流平台，希望最大控制力 | LangGraph | AgentScope | 显式图、持久化、durable execution、HITL、状态恢复最成熟；适合把确定性业务逻辑和 Agent 步骤混合。citeturn18view0turn18view1 |
| 长时间自主执行、研究、编码、文件操作、子 Agent | Deep Agents | Claude Agent SDK | Deep Agents 已把 filesystem、subagent、context management、memory、MCP、sandbox 组合成开箱即用 harness，同时保持模型无关。citeturn13view0turn13view1 |
| 明确押注 Claude，特别是代码生成/代码库操作/终端 Agent | Claude Agent SDK | Deep Agents | 直接复用 Claude Code 的 agent loop、文件/终端工具、subagent、skills、hooks 和 MCP；但模型和运行方式锁定明显。citeturn11view0turn20view0 |
| RAG、企业知识库、PDF/文档理解是产品核心 | LlamaIndex | LangGraph + RAG 组件 | 数据连接器、索引、retrieval、文档解析和 agent workflow 是其传统优势；但官方自身已明确把公司重点转向 LlamaParse/document processing。citeturn13view2turn20view2 |
| 快速搭建角色型多 Agent、业务自动化、PoC | CrewAI | Deep Agents | Crews + Flows 的心智模型直观，Python 上手快，适合业务人员容易理解的“角色—任务—流程”建模。citeturn14view2 |
| 中国技术栈、国产模型、多 Agent、A2A/MCP、Java 企业系统 | AgentScope | LangGraph | 2026 年的 AgentScope 2.0 已明显增强：Python/Java/TS、多模型、MCP、A2A、权限、sandbox、分布式状态和 agent service 都很完整。citeturn16view0turn16view1turn16view2 |
| Python 为主、OpenAI-first、需要 handoff/guardrail/realtime/voice | OpenAI Agents SDK Python | LangGraph | API 简洁，Agent/Tool/Handoff/Guardrail/Session/Tracing/Sandbox/Realtime/Voice 已形成较完整体系，而且当前 SDK 宣称可接 100+ 非 OpenAI LLM。citeturn17view1 |
如果你现在没有给出语言、预算、合规、云厂商等限制，我会把“通用默认答案”给 LangGraph。 原因不是它最简单，而是它在“业务逻辑可控性、故障恢复、状态持久化、HITL、长期运行、模型中立、生产部署”之间取得了最好的平衡；代价是学习曲线和工程复杂度最高之一。官方也把 LangGraph 定位为低层 orchestration runtime，而不是高层 Agent 模板。citeturn18view1
如果你的目标是做类似 Claude Code / Cursor / Deep Research 的长程 Agent，而不是业务状态机，则 Deep Agents 是更值得优先试验的默认项。 它实际上是“LangGraph runtime + 预装好的 Agent harness”：filesystem、subagent、context compression、persistent memory、HITL、skills、MCP 已集成，且支持 OpenAI、Anthropic、Google、开放权重模型、Ollama、vLLM、llama.cpp 等。citeturn13view0
Claude Agent SDK 很强，但它不是普通意义上的“Claude 版 LangGraph”。 它的优势来自直接把 Claude Code 的成熟 agent harness 嵌进应用；其生产部署模型是一会话一 claude 子进程，需要把 subprocess、workspace、filesystem state、sandbox 和横向扩容都纳入容量规划。因此，它特别适合“代码/文件/终端型 Agent”，不适合作为追求多模型可移植性的通用编排层。citeturn20view0
LlamaIndex 的选择条件也应更严格：当“数据/文档”是产品核心时选它，而不是因为你需要一个通用 Agent framework 就选它。 官方仓库已明确表示，公司当前主要聚焦 LlamaParse、文档解析与提取；开源 LlamaIndex Framework 仍维护，并提供 300+ integration packages，但战略重心变化值得纳入长期维护风险判断。citeturn13view2
AgentScope 在 2026 年已经不能再简单归类为“学术型多 Agent 框架”。 Python 2.0 包含 ReAct、toolkit、MCP、memory、context middleware、权限、sandbox、多租户 agent service；Java 2.0 更进一步提供 Redis/MySQL/PostgreSQL 状态、cross-replica recovery、Docker/Kubernetes sandbox、stateless horizontal scaling。对中国企业 Java/Python 技术栈，它是本次比较中值得认真考虑的一项。citeturn17view0turn16view1
一句话建议：
LangGraph = 最强“运行时/编排底座”；Deep Agents = 最强“开箱即用长程 Agent harness”；Claude Agent SDK = 最强 Claude/代码执行专用 harness；LlamaIndex = 最强数据/文档型 Agent 工具链；CrewAI = 最易理解的角色型多 Agent；AgentScope = 中国/Java/多协议/企业分布式场景的强竞争者；OpenAI Agents SDK = 最轻量完整的 Python/OpenAI-first Agent SDK。
研究范围、术语与资料口径
你所写的 “claude code agent”，本文按 Anthropic 当前正式名称 Claude Agent SDK 评估。官方已经把原来的 Claude Code SDK 更名为 Claude Agent SDK；Anthropic 也明确给出了新的 Python/TypeScript package 名称和迁移说明，因此继续将其称作“Claude Code Agent framework”容易与 Claude Code 产品本身混淆。citeturn11view0turn11view1
你所写的 “agentscop”，本文按 AgentScope 评估；当前官方项目为 agentscope-ai/agentscope，另有 Java 2.0 与 TypeScript 实现。citeturn16view0turn16view1turn16view2
本文优先采用官方文档、官方 GitHub、官方产品/定价/安全页面。GitHub Star、Fork、open issue 等属于 2026-10-03 的网页快照，以后会变化。GitHub 未登录页面对部分仓库只显示“Contributors”入口而没有稳定返回总贡献者数量，因此本文对无法可靠取得的“贡献者精确数”统一标为 未公开/本次抓取不可得，不根据头像数量猜测。原始性能数字同理：没有官方或可重复基准时统一写 “未公开”，而不把“production-ready”“fast”“scalable”等营销措辞转换成虚构 QPS。
官方入口如下：
Claude Agent SDK：
官方 Agent SDK 文档 ｜ 生产部署文档 ｜ Python 源码 ｜ TypeScript 源码。官方文档确认 Python 与 TypeScript 是一等公民 SDK；其他语言可以通过 CLI/subprocess 协议调用。citeturn11view0turn20view0
LangGraph：
Python 官方文档 ｜ GitHub。官方同时维护等价 JS/TypeScript 实现 LangGraph.js。citeturn18view0turn18view1
Deep Agents：
Python 官方文档 ｜ Python GitHub ｜ JavaScript/TypeScript GitHub。Python 与 JS/TS 都建立在 LangGraph 上。citeturn13view0turn13view1
LlamaIndex：
Python Framework 文档 ｜ Python GitHub ｜ LlamaParse 文档。核心开源框架与商业 LlamaParse 应区分看待。citeturn13view2turn19search21
CrewAI：
官方文档 ｜ GitHub。核心是 Python。citeturn14view2
AgentScope：
Python 官方文档 ｜ Python GitHub ｜ Java 文档 ｜ Java GitHub ｜ TypeScript GitHub。citeturn15search8turn16view0turn16view1turn16view2
OpenAI Agents SDK Python：
官方中文文档 ｜ GitHub。本文只评估用户指定的 Python SDK；OpenAI 另有 JS/TS 版本，但不把二者的能力简单混合计算。citeturn17view1
横向比较总表
| 框架 | 语言 / Runtime | 核心架构 | 模型与扩展 | 部署 / 伸缩 | 安全与隐私 | 社区 / 许可 | 生产判断 |
|---|---|---|---|---|---|---|---|
| Claude Agent SDK | Python 3.10+、Node 18+/TS；底层运行 Claude Code native binary；其他语言可 subprocess CLI。citeturn11view0turn20view0 | Claude Code agent loop + tools + filesystem + shell + hooks + subagents + sessions + memory + skills + plugins + MCP。citeturn11view0 | Claude-centric；可通过 Anthropic，以及官方部署说明涉及的 Bedrock/Google Cloud Agent Platform 路径使用 Claude；不是 OpenAI/Meta 通用 backend abstraction。citeturn20view0 | 自托管、本地、Docker、Kubernetes、Modal 等；1 session = 1 subprocess。官方初始容量建议约 1 GiB RAM、5 GiB 磁盘、1 CPU/agent；具体延迟/QPS 未公开。citeturn20view0 | 商业用户默认不拿代码/Prompt 训练模型；标准保留期 30 天，符合条件 Enterprise 可 ZDR；本地 transcript 默认也会存在用户目录。应做 sandbox、tenant directory、egress control。citeturn20view1turn20view0 | SDK 组件受 Anthropic Commercial Terms 等条款治理，并非典型 MIT/Apache OSS。TS 仓库约 1.8k Star；生态小于 LangGraph/CrewAI。citeturn5view2turn11view0 | 是，但有条件：Claude/代码执行型 Agent 很强；多模型平台不推荐作为核心抽象。 |
| LangGraph | Python + JS/TS。citeturn18view0 | Graph/State + nodes/edges + checkpoint/persistence + durable execution + streaming + HITL + short/long-term memory。citeturn18view1 | 本体不强制 LangChain；通过 LangChain 获得极广模型、tool、vector DB 生态，可做 provider-agnostic。citeturn18view0turn18view2 | OSS 可自托管；LangSmith 提供 Cloud、BYOC、Self-hosted 与专用 deployment。原始 QPS/延迟 未公开。citeturn18view1turn18view2 | 自托管可以完全控制编排状态；LangSmith 提供组织治理、access control，Trust Center 列出 HIPAA、SOC 2 Type 2、GDPR。citeturn18view2 | MIT；约 42.6k Star、7.2k Fork、580 open issues、235 PR、7,124 commits。官方列举 Klarna、Uber/J.P. Morgan、Replit、Elastic 等采用者。citeturn18view0turn18view1 | 是，强烈推荐：尤其复杂、长运行、状态型生产系统。 |
| Deep Agents | Python + JS/TS；JS 还提供 browser / Node entrypoints。citeturn13view0turn13view1 | 在 LangGraph 上封装 opinionated harness：planning、filesystem、subagents、context management、persistent memory、HITL、skills。citeturn13view0 | 模型无关；官方明确列 OpenAI、Anthropic、Google、开放权重、Ollama、vLLM、llama.cpp；支持任意 MCP server。citeturn13view0 | 本地/容器/普通云均可；JS 可 Node/browser；可配 LangSmith production deployment。裸 Agent 性能/QPS 未公开。citeturn13view0turn13view1 | 官方明确采用“trust the LLM”安全模型：Agent 能做工具允许的一切，因此边界必须由 tool/sandbox 强制。citeturn14view3 | MIT；Python repo 约 29.9k Star、4.2k Fork；JS repo 约 1.6k Star。citeturn13view0turn13view1 | 是：适合长程自主 Agent；确定性流程很强时更建议直接 LangGraph。 |
| LlamaIndex | Python 为主，并有 TypeScript 生态；商业 LlamaParse SDK 还覆盖 Python/TS/Go/Java。citeturn13view2turn19search21 | Data connectors + index + retriever/query engine + RAG + agent/workflow；数据层和文档处理是核心差异化。citeturn13view2 | 300+ integration packages；可替换 LLM、embedding、vector store，官方示例包括 OpenAI、Ollama、Hugging Face/Meta 模型。citeturn13view2 | OSS 可本地/容器/云；LlamaParse 有 SaaS/VPC/hybrid。OSS agent QPS/延迟 未公开；LlamaParse 公开并发 tier 为 5/5/20/100。citeturn20view2 | OSS 自托管由你控制；LlamaParse 宣称 transit/at-rest encryption，缓存默认最多 48h、可关闭，Enterprise VPC；SOC2 Type II、GDPR、HIPAA。citeturn20view2 | MIT；约 52.4k Star、8.3k Fork。但官方明确表示当前公司主战略已转向 LlamaParse/document processing。citeturn13view2 | 是：尤其 RAG/文档；纯通用 orchestration 不一定最优。 |
| CrewAI | 核心 Python；可通过 API 对接其他语言服务。citeturn14view2 | Agents + Tasks + Crews（自主角色协作）+ Flows（event-driven 确定性流程）+ tools/memory/HITL。citeturn14view2 | 多 LLM，并明确支持 Ollama、LM Studio 等 local model；工具和外部 API 易扩展。citeturn14view2 | OSS 本地/容器/云；商业 AMP 提供 managed deployment、monitoring、governance/security，并可 cloud/on-prem。性能数字 未公开。citeturn14view2 | OSS 有匿名 telemetry；完整 task/goal/backstory/context/output 只有 share_crew=True 才进一步分享。AMP 提供企业安全治理。citeturn14view2 | MIT；约 59.3k Star、8.6k Fork、204 issues、319 PR、2,925 commits；官方称课程认证开发者 100k+。citeturn14view0turn14view2 | 是/视情况：快速业务自动化很好；高确定性复杂状态系统需谨慎。 |
| AgentScope | Python 3.11+、Java 17+、TypeScript/Node 18+。citeturn16view0turn16view1turn16view2 | ReAct + Toolkit + Context/Middleware + Memory + Permission/HITL + event bus + sandbox；另有 Agent Service、team orchestration、RAG、persistence。citeturn17view0 | OpenAI、Anthropic、Gemini、DashScope、DeepSeek、Moonshot、Volcengine、xAI、Ollama；MCP、A2A，Java 另支持 AG-UI。citeturn16view0turn16view1 | Python service 支持 multi-tenant/session；Java 支持 local/Docker/K8s/E2B sandbox、Redis/MySQL/PostgreSQL 状态及 cross-replica recovery；TS 官方称支持 local/serverless/K8s。性能数字 未公开。citeturn17view0turn16view1turn16view2 | Permission allow/approve/deny、HITL、sandbox、多租户隔离均为一等能力；核心 OSS 未公布统一 SaaS 数据留存策略。citeturn16view1 | Apache-2.0；Python repo 约 32.7k Star、3.6k Fork、325 issues、244 PR；Java 约 5.9k Star。citeturn17view0turn16view1 | 是/视情况：2.0 工程能力强；版本迭代快，需锁版本并做升级测试。 |
| OpenAI Agents SDK Python | Python 3.10+；另有独立 JS/TS SDK，但本文不计入 Python 包能力。citeturn17view1 | Agent + Runner + Tool + Handoff/agent-as-tool + Guardrail + HITL + Session + Tracing + SandboxAgent + Realtime/Voice。citeturn17view1 | 当前官方仓库称 provider-agnostic、OpenAI APIs + 100+ LLMs；依赖中包括 any-llm、LiteLLM；支持 MCP。citeturn17view1 | 普通 Python app 可本地/容器/serverless；Sandbox 支持 Unix local、Docker 或 hosted sandbox；SDK 自身没有 LangGraph 式独立托管控制平面。性能 benchmark 未公开。citeturn17view1 | Tracing 默认开启，可以关闭；敏感场景必须明确审查 trace 内容和 session backend，而不是假定 SDK “零数据”。citeturn19search16 | MIT；约 29.8k Star、4.8k Fork、2,461 commits；repo 包含 tests/integration_tests，且当前 release 增加 provider-neutral deterministic testing。citeturn17view1turn15search6 | 是：Python/OpenAI-first 尤其合适；复杂 durable workflow 可考虑外层加编排层。 |
这里一个非常重要的工程结论是：“模型无关”与“运行时无关”不是同一件事。 Deep Agents、LangGraph、LlamaIndex、CrewAI、AgentScope 和目前的 OpenAI Agents SDK 都可以在不同程度上换模型；Claude Agent SDK 的价值恰恰来自它和 Claude Code/Claude runtime 的紧密绑定，因此不应该拿“模型兼容数量”作为唯一标准去判定优劣。citeturn13view0turn17view1turn20view0
架构、集成与互操作性
七个框架实际上可以分成四种架构层级：
这张图解释了为什么 LangGraph 和 Deep Agents 并不是直接竞争的同一层产品。官方自己定义得很明确：LangGraph 是 graph runtime；LangChain create_agent 是更小的 harness；Deep Agents 是再往上一层、附带 filesystem、subagents、context management、skills 的 opinionated harness，而且 Deep Agent 最终返回的仍然是 compiled LangGraph graph。citeturn13view0turn13view1turn18view1
因此，一个成熟系统甚至可以同时使用两者：
业务订单状态机 / 审批 / 重试 / checkpoint = LangGraph
其中某个“自主研究”节点 = Deep Agent
官方明确支持把 CompiledStateGraph 作为 Deep Agent 的 sub-agent，因此两者存在天然的组合路径，而不必二选一。citeturn13view0
Claude Agent SDK 则走完全不同路线。它不是让你先定义一个 graph，而是把 Claude Code 已经验证过的 agent loop 和工具环境直接作为 library 嵌入你的 Python/TS 应用。它内置 read/write/edit、shell、web、MCP、subagent、hooks、permissions、sessions、skills、memory 等，因此做“打开 repo → 搜代码 → 修改 → 跑测试 → 迭代”这种任务时，需要自己拼装的基础设施明显更少。代价是运行时与 Claude 强绑定。citeturn11view0turn20view0
LlamaIndex 的轴又不同。它的核心不是“让多个 Agent 更聪明地对话”，而是 让模型访问、结构化、检索和理解你的数据：connectors、indices、retrieval/query、RAG、文档处理始终是架构中心。其 Python repo 当前宣称有超过 300 个 integration packages，可分别换 LLM、embedding 和 vector store。官方甚至在 README 中明确写明，公司现在的重点是 LlamaParse、LiteParse 和解析/提取 benchmarking，而 OSS Framework 仍作为 agent/RAG toolkit 存在。citeturn13view2
CrewAI 更适合从业务组织结构思考：一个 Crew 里有带角色的 Agents 和 Tasks，强调自主协作；需要更强确定性时用 Flows 做 event-driven orchestration，再把 Crew 嵌入 Flow。这个抽象对“研究员—分析师—审核员—写作员”类工作特别直观，但角色数量增加往往也意味着更多模型调用和上下文传递——后者是架构推断，不是 CrewAI 官方公布的性能 benchmark。官方没有公开 CrewAI 与其他框架之间可比较的延迟/QPS 数字。citeturn14view2
AgentScope 2.0 的架构值得特别注意。Python SDK 已包含 ReAct、batched sequential/concurrent tool acting、Toolkit、MCP、context compaction、tool-result offloading、memory、permissions、middleware 和 sandbox；其 Agent Service 又添加 multi-tenancy、multi-session、leader-worker team、RAG service、MCP/skill hub、共享资源和 SQL/NoSQL persistence。citeturn17view0 Java 2.0 则明显面向大型企业运行时：stateless horizontal scaling、多维 tenant isolation、Redis/MySQL/PostgreSQL persistence、cross-replica session recovery、Docker/K8s/E2B sandbox 都已经进入正式 2.0 架构。citeturn16view1
从标准协议和迁移性看，目前最重要的是 MCP 与 A2A：
| 互操作能力 | 评价 |
|---|---|
| MCP | Claude Agent SDK 原生支持；Deep Agents 可接任意 MCP server；AgentScope 支持 HTTP/SSE/stdio MCP；OpenAI Agents SDK 包含 MCP tool；因此这些框架的工具层迁移成本正在下降。citeturn11view0turn13view0turn15search32turn17view1 |
| A2A | AgentScope 2.0 已把 A2AAgent 作为官方能力，Java 版也明确覆盖 A2A/AG-UI，因此跨 Agent runtime 互联方面明显积极。citeturn16view0turn16view1 |
| 普通函数/API tools | 七个框架都能接；差异主要在 schema、生命周期、权限、重试和 tracing，而不是“能不能调用 HTTP API”。citeturn11view0turn13view0turn14view2turn16view0turn17view1 |
| 状态迁移 | 难度远高于 tool 迁移。LangGraph checkpoint/state schema、CrewAI Crew/Flow state、AgentScope RuntimeContext/workspace、OpenAI Session、Claude local transcript/workspace 都是不同抽象，没有通用状态快照标准。citeturn18view1turn20view0turn16view1turn17view1 |
因此，降低未来框架迁移成本的最好做法，不是寻找一个所谓“完全标准化”的框架，而是把领域逻辑、tool contracts、memory storage、model gateway 和 Agent runtime 分层。尤其不要让业务数据库 schema、第三方 API client 和某框架的 Agent class 深度耦合。这是基于上述运行时差异得出的工程建议。
各框架逐项评估
Claude Agent SDK
简短概述：这是 Claude Code SDK 的继任者。其本质是“把 Claude Code 的 Agent 环境作为 SDK 嵌入你的应用”，Python 和 TypeScript 是官方一等接口。它不是传统 graph/workflow engine。citeturn11view0turn11view1
关键优势在于 代码执行型 Agent 的开箱能力非常完整：文件读写编辑、shell、web、MCP、subagent、hooks、permission、session、skills、commands、memory、plugins 都是官方框架的一部分。对于代码库维护、自动修复、DevOps automation、长程编程、软件工程 Agent，它能减少大量自行实现 harness 的工作。citeturn11view0
另一个优势是 Anthropic 对生产部署的运行时特性写得相当透明：一个 session 对应一个 claude subprocess，本地有 transcript、memory 文件和 working directory state；生产环境可以用 Docker、Modal、Kubernetes 等隔离。官方甚至给出了单 Agent 初始容量参考——约 1 GiB RAM、5 GiB disk、1 CPU——并明确指出并发上限受 subprocess 内存限制，需要通过水平扩展处理。citeturn20view0
它的第一大缺点是 vendor/runtime lock-in。虽然 Claude 可以通过 Anthropic 以及部分云托管入口使用，但这不是“把 model= 从 Anthropic 改成 OpenAI/Meta 就继续跑”的抽象。第二个缺点是进程模型偏重：100 个并发长 session，本质上不是 100 个轻量 async coroutine，而是要管理接近 100 个 agent process 及其状态，因此 serverless 超短函数并不是最自然的部署形态。citeturn20view0
第三个风险来自版本和授权。旧 Claude Code SDK 到 Agent SDK 存在 package rename 和 breaking migration；Anthropic 文档还明确说明 SDK 按其 Commercial Terms 等条款治理，而不是一个典型 MIT/Apache 工具。对于重视长期供应商可替换性和 OSS 治理的企业，这一点非常重要。citeturn11view1turn11view0
典型推荐场景：代码生成与修改、自动 bugfix、repo maintenance、CLI/DevOps agent、需要 shell/filesystem/subagent 的长任务。
不推荐场景：核心要求是 OpenAI/Claude/本地 Meta 模型随时切换的通用企业 Agent 平台。
生产环境：是，但视架构而定。 必须容器/沙箱隔离、限制 filesystem、credential 和 network egress，并为 subprocess 并发做容量规划。官方明确提醒默认 Agent 会读取本地设置/记忆，对多租户环境尤其要隔离。citeturn20view0
LangGraph
简短概述：七项中最接近“Agent operating runtime / workflow runtime”的框架。官方将它描述为低层状态化 Agent orchestration framework，可把确定性代码节点和 LLM-driven 节点放在同一张 graph 中。citeturn18view1
它最重要的竞争力不是一个预制 Agent，而是 durable execution、checkpoint、state、streaming、HITL、short/long-term memory 和恢复能力。这意味着你可以明确描述“模型失败怎么重试、人类审批在哪暂停、重启后从哪里继续、哪个节点允许 Agent 自主判断”。对于金融、客服流程、运维、审批、case management 等生产业务，比“让若干 Agent 自由聊天”更容易审计。citeturn18view0turn18view1
模型层面它也最不容易锁死。LangGraph 本身甚至不要求 LangChain；但大多数开发者会通过 LangChain 获得模型、tools 等 integrations。官方明确定位 LangChain 生态为 model-agnostic。citeturn18view1turn18view2
缺点同样鲜明：它太低层。 官方自己建议，如果刚开始做 Agent 或想要高层抽象，应先考虑预构建 agent/harness，而不是直接 LangGraph。你需要设计 state schema、node、edge、routing、checkpoint strategy，以及决定哪些动作 deterministic、哪些 agentic。citeturn18view1
这意味着它的代码量和测试负担通常高于 CrewAI/OpenAI Agents SDK/Deep Agents，但换来的是可控性。对成熟工程团队这是优势；对两三个人做 MVP 可能是过度设计。
社区方面，它约有 42.6k Star、7.2k Fork、580 open issue、235 PR、7,124 commits，并有 Klarna、Replit、Elastic、Uber、J.P. Morgan 等官方列举的采用者，是本组中生产信号最强的项目之一。citeturn18view0turn18view1
典型推荐场景：复杂客服/审批、状态型 workflow、长运行后台 Agent、human-in-the-loop、需要强恢复能力的生产 Agent、多个 Agent 与传统业务逻辑混排。
限制：简单 chatbot 或单一 tool-loop 用它可能太重。
生产环境：是，强烈推荐。 如果团队能够承担显式状态机设计成本，这是本文的通用默认首选。
Deep Agents
简短概述：可以理解为 LangGraph 上的“batteries-included autonomous-agent harness”。其设计目标就是长程、多步骤、自主任务，而不是让开发者从空白 StateGraph 开始。citeturn13view0
默认能力包括 planning、filesystem、subagent、context summarization/offloading、shell、persistent memory、HITL、skills 和 MCP；并且每一层都可以替换，而不需要 fork。它返回 compiled LangGraph graph，因此仍然继承 streaming、persistence 和 checkpointer 能力。citeturn13view0turn13view1
它在模型兼容性上尤其漂亮：官方明确说任何支持 tool calling 的模型均可，包括 OpenAI、Anthropic、Google，Baseten/Fireworks 等托管开放权重模型，以及 Ollama、vLLM、llama.cpp 的自托管模型。citeturn13view0
因此它是 “我想做 Claude Code/Deep Research 一类东西，但不想绑定 Claude” 时非常值得优先验证的方案。甚至官方说明该项目本身受 Claude Code 启发。citeturn13view0
主要限制是 opinionated。它的默认 assumptions 是“长程自主工作 + filesystem/context/subagent”，所以订单审批、支付事务、强 SLA deterministic pipeline 不一定需要这一整套 harness。此时直接 LangGraph 的 graph 往往更清楚。这个结论来自其官方“Deep Agents versus LangGraph”的分层定位。citeturn13view0
安全上官方有一句非常值得重视的话：Deep Agents 采用“trust the LLM”模型，Agent 可以做其 tools 允许做的一切，因此必须在 tool/sandbox 层实施安全边界，而不能靠 prompt 告诉模型“不许做危险操作”。citeturn14view3
典型推荐场景：Deep Research、coding agent、研究助手、跨多文件任务、规划—执行—复盘、subagent delegation、本地模型长程 agent。
限制：强确定性业务流程更适合降到 LangGraph。
生产环境：是。 但 shell/filesystem/MCP 权限应视为真正的安全边界。
LlamaIndex
简短概述：最适合把它理解为 “Agent + Data/RAG/document layer”，而不是首先把它看成多 Agent orchestration framework。其最成熟的积累仍在 data connectors、indices、retrieval、query、embedding/vector store 和 document pipeline。citeturn13view2
模型和基础设施兼容性很强。官方说明有超过 300 个 integration packages，可以按需组合 LLM、embedding 和 vector-store provider；文档同时给出 OpenAI 和 Ollama/Meta Llama 等示例。citeturn13view2
这使它特别适合企业知识问答、PDF/合同/财报理解、文档 Agent、RAG 搜索、数据抽取、document-heavy automation。商业 LlamaParse 又把解析、Extract、Index、Agent workflow、复杂 OCR 等继续产品化。citeturn19search21turn20view2
但长期选型时应注意官方自己披露的战略变化：LlamaIndex README 明确表示公司当前主要聚焦 LlamaParse、LiteParse 和 parsing/extraction benchmark，OSS Framework 仍提供，但企业资源投入中心已发生变化。citeturn13view2 这不意味着开源库“停止维护”，但意味着如果你的项目根本不涉及文档/RAG，把 LlamaIndex 当作纯通用 orchestration 核心，战略匹配度没有过去那么强。
LlamaParse 的商业部署信息在七项中非常透明：Free/Starter/Pro/Enterprise 当前分别包括 10K/40K/400K/custom credits；Starter $50/月，Pro $500/月；1,000 credits = $1.25；Parse/Extract/Index 等并发上限为 5/5/20/100。注意这些数字属于 LlamaParse SaaS，而不是 OSS LlamaIndex Agent runtime 的性能 benchmark。citeturn20view2
安全方面，LlamaParse 宣称数据传输和静态加密，缓存数据默认仅保留 48 小时且可关闭，Enterprise 可运行在客户 VPC，并提供 SOC 2 Type II、GDPR、HIPAA 等。citeturn20view2
典型推荐场景：RAG、知识库、复杂文档问答、金融/保险文档、OCR/抽取、数据 Agent。
限制：数据不是系统核心时优势会明显下降。
生产环境：是。 对 document-centric 产品尤其推荐。
CrewAI
简短概述：核心抽象是 Agent → Task → Crew，再通过 Flow 提供更精确的 event-driven 控制。Crew 面向自主角色协作，Flow 面向确定流程，两者可以组合。citeturn14view2
这是本组中最容易向非平台工程师解释的架构之一：“研究 Agent 负责搜索，分析 Agent 负责分析，Reviewer Agent 负责审核，最后 Writer Agent 输出”。因此在咨询、市场研究、内容、业务运营、销售自动化和 PoC 中很有吸引力。
其模型层并不锁死云 API，官方明确支持 local model，并举出 Ollama 和 LM Studio。核心是独立 Python framework，不依赖 LangChain 才能运行。citeturn14view2
成熟度方面信号不错：GitHub 约 59.3k Star、8.6k Fork、204 open issues、319 PR、2,925 commits；官方还称其社区课程已有 100,000+ certified developers。citeturn14view0turn14view2
生产方面，商业 AMP Suite 提供 managed deployment、observability、governance、security 和 enterprise support，并支持 cloud/on-prem；这弥补了纯 OSS runtime 的治理缺口。citeturn14view2
隐私上需要注意默认 telemetry。官方 repo 说明会收集匿名使用数据，例如功能使用情况、模型类型、tool 名称等；进一步共享完整 goal、backstory、context、task output 需要显式把 share_crew 打开。citeturn14view2 企业合规环境仍建议在上线前审计并显式配置 telemetry，而不是依赖默认值。
CrewAI 的主要局限是：角色模型很自然，但不等于运行时一定最可预测。 当 Crew 数、Agent 数、delegation 和多轮 reasoning 增加时，模型调用数量也可能增长；由于官方没有跨框架性能 benchmark，无法严谨声称它比 LangGraph 慢多少，只能说它的自主协作模式天然需要更严格的 token/latency budget 测试。
典型推荐场景：快速多 Agent PoC、业务流程自动化、研究/分析/内容团队模拟、运营工作流。
限制：高可靠 transactional workflow 不应完全交由角色自治。
生产环境：是/视情况。 Flow 驱动、边界明确的生产应用可以；高度自由的 Crew 必须配评估、guardrail 和预算控制。
AgentScope
简短概述：AgentScope 2.0 已成为一个相当全面的 agent platform，而不仅是 multi-agent experiment framework。Python 要求 3.11+；Java 2.0 要求 JDK 17+；TypeScript 实现要求 Node 18+。citeturn16view0turn16view1turn16view2
Python 版本的模型支持在七项里尤其适合中国团队：OpenAI、Anthropic、Gemini、DashScope、DeepSeek、Moonshot、Volcengine、xAI、Ollama 都在官方模型列表中。框架还原生提供 MCP、A2A、Realtime、Context compaction、memory backends、permission/HITL 和多种 sandbox。citeturn17view0
其 Agent Service 已覆盖 multi-tenancy、multi-session、leader-worker teams、RAG、MCP/skill hub、组织资源共享、SQL/NoSQL persistence、scheduled/background tasks；对于“从 SDK 到服务”之间的空档，官方已经提供比较完整的路径。citeturn17view0
Java 2.0 更值得企业团队关注。官方明确支持 stateless horizontal scaling，session/user/agent/org 多维隔离，local/Docker/Kubernetes/E2B sandbox，以及 memory/state 通过 MySQL、Redis、PostgreSQL 等持久化，允许 rolling deploy 后 session recovery。citeturn16view1 这在本组的 Java 企业应用支持上非常突出。
互操作方面，2026 年 9 月 Python 版已正式加入 A2AAgent；MCP 同时支持 HTTP streamable/SSE 与 stdio；Java 还包含 A2A/AG-UI，因此它对开放协议采用相当积极。citeturn16view0turn15search32turn16view1
风险主要来自 版本速度。2026 年 9 月还在快速加入 SOP、TeamPipeline、model routing、Realtime/A2A 等能力，其中某些明确标记 Experimental。对长期生产系统，应固定 minor version、做 contract tests，不要持续追 main。citeturn16view0
社区信号也已经相当可观：Python repo 约 32.7k Star、3.6k Fork、325 issues、244 PR；Java repo约 5.9k Star。Apache-2.0 对商业二次开发友好。citeturn17view0turn16view1
典型推荐场景：中国企业 Agent、国产/海外模型混合、多 Agent 协作、Java 企业后端、A2A/MCP、Realtime agent、需要分布式 session recovery 的系统。
限制：快速演进提高升级风险；全球第三方教程/插件密度仍不宜简单等同 LangChain 生态。
生产环境：是/视情况。 Java 2.0/稳定 Python API 已有明确 production intent，但需严格锁版本。
OpenAI Agents SDK Python
简短概述：这是一个刻意保持轻量的 multi-agent framework，核心概念包括 Agent、Runner、Tools、Agents-as-tools/Handoff、Guardrails、HITL、Sessions、Tracing，并在 2026 年扩展出 SandboxAgent、Realtime Agent 和 Voice pipeline。citeturn17view1
与早期“OpenAI-only”的刻板印象不同，当前官方 GitHub 明确称 SDK 是 provider-agnostic，除 Responses/Chat Completions 外支持 100+ LLMs；依赖也列出 any-llm 和 LiteLLM。citeturn17view1 但从 feature depth、tracing 和 realtime/sandbox 的设计看，其最顺滑路径依然明显是 OpenAI 生态，这是架构层面的判断，而不是说其他模型不能运行。
它的最大优势是 API surface 小而完整。简单 multi-agent delegation 不必先建 graph；Handoff 与 Agent-as-tool 都是一等概念，Guardrail/HITL 也有标准接口。需要 coding/workspace agent 时，现在又可用 SandboxAgent 访问文件、执行命令和 patch，并支持 Unix local、Docker 或 hosted sandbox。citeturn17view1
另一个很有价值的点是测试。仓库中有 tests 和 integration_tests，当前 release 又增加 provider-neutral deterministic testing，可在不触发模型、sandbox/API 调用的情况下测试 Agent、Sandbox、Realtime、Voice workflow。对 CI 来说这是实用优势。citeturn17view1turn15search6
隐私方面必须特别提醒：SDK 的 tracing 默认开启，会记录 LLM generation、tool call、handoff、guardrail 等运行事件；官方提供关闭 tracing 的方式。高合规应用因此应把 tracing 配置纳入威胁模型，而不能只关注 LLM API 请求。citeturn19search16
它相对 LangGraph 的不足，是框架思维仍更偏 agent loop/handoff，而不是“复杂显式 durable state graph”。虽然 Sessions、Sandbox、long-horizon execution 已越来越强，但如果你的关键需求是跨几十个确定性节点、复杂分支、checkpoint/resume 和人工修改 state，LangGraph 的抽象更自然。这个判断基于两者官方定位的差异。citeturn17view1turn18view1
典型推荐场景：Python AI 服务、tool calling chatbot、多 Agent handoff、customer service、OpenAI-first app、voice/realtime、轻量 coding agent。
限制：大型业务状态机并不是其最自然的抽象。
生产环境：是。 尤其适合希望保持 SDK 简单、又需要 guardrail/tracing/testing 的 Python 团队。
生产工程：部署、性能、安全、维护与成本
性能方面，最重要的结论是：七个框架都缺乏可用于严肃横向排名的统一公开 Agent throughput/latency benchmark。 因此不能说“CrewAI 比 LangGraph 慢 30%”或“OpenAI SDK 吞吐最高”。Agent 系统真实延迟通常由模型推理、tool I/O、网络、RAG、Agent step 数和 context size 主导，框架 runtime 自身只是其中一部分；本文没有发现官方跨框架可复现的数字，因此统一记为 未公开。
可以比较的是运行时结构。
Claude Agent SDK 是最明显的重量级模型：官方说明每个运行 session 对应一个 Claude CLI subprocess，并把约 1 GiB RAM、5 GiB disk、1 CPU/agent 作为初始容量规划参考。因此它的并发扩容更像“长生命周期 worker/container”而不是普通 HTTP handler。citeturn20view0
LangGraph 的优势在 durable execution/persistence，而不是公开的低毫秒 overhead；LangSmith Deployment 则专门面向 long-running stateful workflow 的 deployment/scaling。官方没有披露统一的请求吞吐数。citeturn18view1
Deep Agents 的 context compression、offload 和 subagent isolation 可以帮助控制长任务上下文，但其 raw latency/QPS 同样未公布；并且 subagent 数量增加必然会增加潜在模型调用并行度，因此生产环境仍要设置 concurrency/rate-limit budget。官方定位就是 long-horizon、多步骤工作。citeturn13view0
LlamaIndex 的 OSS runtime 没有统一性能数据；商业 LlamaParse 则有明确服务层指标，例如不同套餐的 parse/extract/index 并发限制 5、5、20、100，以及 99.9% uptime。这些只能用于评估 LlamaParse，不应被误用为 LlamaIndex Agent Framework benchmark。citeturn20view2turn20view3
AgentScope Java 在伸缩架构上公开的信息尤其详细：stateless agent、Redis/MySQL/PostgreSQL state store、cross-replica recovery 和 Kubernetes sandbox 都是为水平扩容设计的，但官方同样没有给出标准 QPS 或 P99 latency。citeturn16view1
安全上，我建议把框架分为三层看：
第一层：模型数据治理
Prompt / Tool output 到底发送给 OpenAI、Anthropic、Google、国产模型还是自托管模型？
第二层：Agent runtime 权限
Agent 能不能执行 shell？能读哪些目录？能联网到哪里？能拿到什么 secret？
第三层：状态与可观测性
memory / checkpoint / transcript / trace 存在哪里？保留多久？谁能访问？
Claude Agent SDK 在第二层风险最高之一，因为强项恰恰是 filesystem/shell。官方要求通过 sandbox、container、tenant directory、egress policy 等建立隔离；数据层方面，商业 Team/Enterprise/API 默认不用于模型训练，标准 retention 约 30 天，符合条件的 Enterprise 可以申请 Zero Data Retention。citeturn20view0turn20view1
Deep Agents 官方对第二层的态度最直接：“Agent 能做 tool 允许的一切”，因此必须把 sandbox/tool authorization 当作真正 security boundary。citeturn14view3
LangGraph 核心开源运行时可完全自托管；需要商业平台时，LangSmith 支持 Cloud、BYOC、Self-hosted，同时官方列出组织 access control/policies 以及 HIPAA、SOC 2 Type 2、GDPR 信息。citeturn18view2 这使它比较适合对数据驻留要求高、但仍希望使用成熟控制平面的企业。
LlamaIndex 的 OSS 路径同样可以自行控制数据；商业 LlamaParse 则公开了 encrypted in transit/at rest、小时缓存、可禁用 cache、private VPC、SOC 2 Type II/HIPAA/GDPR 等细节，是本次商业托管服务中安全资料较透明的一项。citeturn20view2
CrewAI 应特别审计 telemetry。默认匿名 telemetry 和显式 share_crew 是不同层级，后者会包含更详细任务数据；企业 AMP 才承担更完整的 governance/security control-plane 职责。citeturn14view2
AgentScope 在 runtime permission 上很强：Python 有细粒度 resource/tool permission；Java 有 allow/approve/deny、tenant isolation 和 sandbox。但它的 OSS 核心本身不是一个 SaaS，所以“统一数据保留多少天”没有意义，真正的数据政策取决于你接入的模型和部署基础设施。citeturn16view0turn16view1
OpenAI Agents SDK 的一个容易遗漏的点是 tracing 默认启用；因此“我只是自己部署 SDK”不等于“没有 observability 数据流”。高敏数据必须显式配置或关闭 tracing，并独立审核模型 provider 与 session backend。citeturn19search16
在许可与费用方面，应把“框架许可证”和“模型/托管成本”分开：
- LangGraph、Deep Agents、LlamaIndex、CrewAI、OpenAI Agents SDK 的核心库都是 MIT。citeturn18view0turn13view0turn13view2turn14view2turn17view1
- AgentScope 为 Apache-2.0。citeturn17view0turn16view1
- Claude Agent SDK 不是同一类宽松 OSS 许可模式，官方说明其使用受 Anthropic Commercial Terms 以及组件对应许可约束。citeturn11view0
- OSS 免费不等于运行免费。LLM token、embedding、vector DB、web search、sandbox、observability、数据库和 Kubernetes 通常才是生产成本主体。
- LlamaParse 是少数本文可以给出当前确切托管价格的服务：Free $0、Starter $50/月、Pro $500/月、Enterprise custom，另按 credit 计量，当前 1,000 credits = $1.25。citeturn20view2
- LangSmith、CrewAI AMP、AgentScope 托管服务等商业控制平面的具体企业总成本取决于方案/合同；在没有可靠统一当前价的情况下本文标为 未公开/需询价，不进行猜测。citeturn18view2turn14view2turn16view1
从维护性看，我会把七项粗略分为：
“底层能力成熟但需要更多工程投入”：LangGraph。
“快速长程 Agent，但 default opinion 较强”：Deep Agents。
“功能成熟但 provider/runtime 强绑定”：Claude Agent SDK。
“数据生态成熟，但公司战略正进一步向 document platform 倾斜”：LlamaIndex。citeturn13view2
“DX 简单、社区大，但要控制角色自治和 telemetry”：CrewAI。citeturn14view2
“2.0 能力扩张非常快，适合中国/Java，但升级治理要严格”：AgentScope。citeturn16view0turn16view1
“API 小而完整、测试体验好、OpenAI-first 最顺”：OpenAI Agents SDK。citeturn17view1turn15search6
决策流程与最终建议
下面这个流程比按 Star 排名更适合作为实际选型入口：
进一步按组织条件分支，可以得到更实用的结论。
小团队、MVP、目标是最快交付。 如果是普通 tool-calling chatbot，优先 OpenAI Agents SDK；如果明显是多个业务角色协作，优先 CrewAI；如果一开始就是 Deep Research/coding agent，优先 Deep Agents。LangGraph 虽然能力更完整，但很可能让 MVP 提前承担 state/graph/checkpoint 的平台工程成本。OpenAI SDK、CrewAI 与 Deep Agents 都提供更高层默认 abstraction。citeturn17view1turn14view2turn13view0
中大型工程团队、系统预期运行三年以上。 我更推荐把 LangGraph 作为核心 orchestration layer。把 model provider、tools、retrieval 和业务存储做成独立 adapters；需要 long-horizon autonomous step 时，在某个 LangGraph node 内调用 Deep Agents。这样既保留 deterministic state machine，也能获得强 Agent autonomy。Deep Agents 官方明确支持和 compiled LangGraph graph 组合。citeturn13view0turn18view1
预算高度敏感。 首先避免把“框架开源”误认为“系统便宜”。真正应优化的是 Agent turn 数、context token、subagent fan-out、RAG rerank、tool round-trip 和 hosted sandbox。模型可替换性重要时，Deep Agents、LangGraph、AgentScope、LlamaIndex、CrewAI 相比 Claude Agent SDK 更容易做 provider routing；尤其 AgentScope 2026 年已加入 model routing，Deep Agents明确支持本地 Ollama/vLLM/llama.cpp。citeturn13view0turn16view0
强合规 / 数据驻留 / 私有化。 优先评估 LangGraph + 自托管/BYOC LangSmith、AgentScope Java/Python 自托管，或 document-centric 场景中的 LlamaIndex + LlamaParse private VPC。LangSmith 官方提供 Cloud/BYOC/Self-hosted；AgentScope Java 支持企业分布式自托管；LlamaParse Enterprise 提供 VPC 数据驻留。citeturn18view2turn16view1turn20view2 Claude Agent SDK 也可以把 runtime 自托管，但模型请求仍要进入相应 Claude provider，因此应把“Agent 运行在哪里”和“模型数据发到哪里”分开审计。citeturn20view0turn20view1
低延迟交互 / Voice。 OpenAI Agents SDK 和 AgentScope 都已经把 realtime/voice 做成一等能力；OpenAI SDK 明确提供 RealtimeAgent 与 VoicePipeline，AgentScope 2026 年也加入 RealtimeAgent 和 realtime voice。citeturn17view1turn16view0 但双方均没有发布足以跨框架比较的完整 P50/P95/P99 framework latency benchmark，因此最终必须用你的模型、地区、tool stack 做压测。
代码生成 / IDE / repo agent。 如果 Claude 是既定模型，Claude Agent SDK 是首选，因为 filesystem/shell/subagents/context/memory 已来自 Claude Code 同一套 harness。citeturn11view0turn20view0 如果你需要 Claude/OpenAI/Gemini/local model 随时切换，选 Deep Agents；如果还要求业务状态机、审批、确定性 CI pipeline，则考虑 LangGraph 外层 + Deep Agent 内层。citeturn13view0turn18view1
RAG / 数据检索。 如果 RAG 只是 Agent 的一个工具，不必因此选择 LlamaIndex；LangGraph、Deep Agents、AgentScope 都可以调用 retrieval tool。只有当 indexing、connector、document parsing、chunking、embedding、retrieval 本身就是产品核心时，LlamaIndex 的完整数据生态才真正形成决定性优势。citeturn13view2turn17view0
中国大陆团队 / 国产模型 / Java 微服务。 在这组候选中，我会把 AgentScope 的优先级大幅上调。Python 版已经覆盖 DashScope、DeepSeek、Moonshot、Volcengine 等，Java 2.0 又提供分布式 session、Kubernetes sandbox、Redis/MySQL/PostgreSQL state 和 A2A/AG-UI；这是一组 LangGraph/CrewAI 不以同样方式直接提供的企业 Java 能力。citeturn16view0turn16view1
最终可以把选择压缩成下面的优先级：
| 排名含义 | 推荐 |
|---|---|
| 最稳妥的通用生产底座 | LangGraph |
| 最值得作为长程自主 Agent 的通用默认值 | Deep Agents |
| Claude + coding/filesystem 场景最优 | Claude Agent SDK |
| RAG / 企业文档最优 | LlamaIndex |
| 角色型多 Agent / 快速自动化最易上手 | CrewAI |
| 中国生态 / Java / A2A / 分布式能力最突出 | AgentScope |
| Python + OpenAI-first / Handoff / Voice 最简洁 | OpenAI Agents SDK |
在完全没有额外约束的情况下，我会采用一个两阶段 shortlist：
第一候选：LangGraph。 用它验证你的业务是否真正需要显式 state、durable execution、checkpoint、HITL 和多分支。如果需要，就直接保留；它最适合作为长期架构核心。citeturn18view1
第二候选：Deep Agents。 用同一个任务验证高层 harness 是否已经足够。如果 70% 以上逻辑都是“让 Agent 自己规划、搜资料、操作文件、调用工具、委派 subagent”，Deep Agents 通常会比手写 LangGraph 明显降低工程量，同时保留 LangGraph runtime。citeturn13view0
然后只在明确的领域条件出现时替换默认选择：Claude 编码 Agent → Claude Agent SDK；文档/RAG → LlamaIndex；角色自动化 → CrewAI；中国/Java/A2A → AgentScope；轻量 Python/OpenAI/Voice → OpenAI Agents SDK。
从长期架构风险看，最值得避免的是把整个业务直接写进某框架的 Agent prompt、memory object 和 tool decorators 中。更稳健的结构应当是：
Domain Services / Business APIs
│
Tool contracts
│
┌────────┴────────┐
│ Agent Runtime │ ← 可替换 LangGraph / Deep Agents /
│ │ Claude / CrewAI / AgentScope / OpenAI
└────────┬────────┘
│
Model Gateway
│
OpenAI / Anthropic / Gemini /
Qwen / DeepSeek / Local
这样做以后，未来从 CrewAI 迁到 LangGraph、从 Claude Agent SDK 改为 Deep Agents，真正需要重写的主要是 orchestration/runtime adapter，而不是业务 API、数据库、鉴权和所有 tools。结合 MCP/A2A 等标准协议的成熟，这是目前控制 Agent 框架锁定风险最现实的工程策略。Claude Agent SDK、Deep Agents、AgentScope 和 OpenAI Agents SDK 已经不同程度采用 MCP，而 AgentScope 进一步支持 A2A，说明工具和 Agent 接口标准化正在改善；但 checkpoint、memory 和 execution state 仍没有统一标准，因此状态层才是未来迁移的最大锁定点。
有，而且如果你已经熟悉 Python，我建议不要只盯着“Agent Framework”这个名字，而是按业务层级来选：Agent Loop、Workflow、RAG、Memory、Realtime、Durable Runtime 实际上是不同问题。
截至 2026-10，除了你前面列的 Claude Agent SDK / LangGraph / Deep Agents / LlamaIndex / CrewAI / AgentScope / OpenAI Agents SDK，我会重点补充下面这些。
Python 生态里值得重点看的框架
| 框架 | 核心定位 | 最适合的业务 Scene | 我的使用倾向 |
|---|---|---|---|
| Pydantic AI | Typed Agent SDK + Harness | 企业 Copilot、数据分析 Agent、API Agent、Research/Coding Agent | Python 项目非常值得重点学 |
| Google ADK | Agent + Workflow + Multi-Agent Runtime | 企业 Agent、复杂多 Agent、云端 Agent 平台 | 偏完整平台型 |
| Microsoft Agent Framework | Agent + Graph Workflow + Harness | 企业流程、Azure/企业系统、多 Agent | 企业场景很强 |
| Strands Agents | 轻量 Agent Harness SDK | Tool Agent、企业助手、云上 Agent | 简洁，尤其适合云端服务 |
| Haystack | RAG Pipeline + Agent | 企业知识库、搜索、文档问答 | RAG 场景值得看 |
| Letta | Stateful / Memory Agent | AI 员工、个人助手、长期运行 Agent | Memory-first |
| Agno | Agent + Team + Workflow + Runtime | 快速构建 Agent SaaS、内部 Agent 平台 | 开箱即用程度高 |
| smolagents | 极简 Agent / Code Agent | 数据分析、Code Agent、研究实验 | 学 Agent Loop 很好 |
| LiveKit Agents | Realtime Voice/Video Agent Runtime | 电话客服、语音助手、实时数字人 | Voice Agent 首选候选之一 |
其中我尤其建议你关注 Pydantic AI。它现在已经不只是早期的 typed agent SDK，而是扩展到了 Harness、MCP、subagents、context management、memory、guardrails、durable execution、Pydantic Graph 和 Evals；同时仍然保持 Python 类型系统这一核心优势。官方目前把它定位成 typed、extensible agent loop，并提供 Temporal、DBOS、Prefect 等 durable execution 集成。Pydantic Docs
按业务场景选，比按“哪个框架最火”更有效
如果你做的是普通的 企业 Copilot / SaaS 内置 AI 助手，比如“查订单 → 查 CRM → 调内部 API → 生成结果 → 必要时执行操作”，我会优先考虑：
Pydantic AI / OpenAI Agents SDK / Strands Agents
这类业务通常不需要一开始就引入复杂 Graph。核心其实就是：
User
↓
Agent
├─ search_customer()
├─ query_order()
├─ create_ticket()
└─ generate_report()
↓
Structured Result
Pydantic AI 对 Python 开发尤其自然，因为 Tool 输入、依赖注入、Structured Output 都可以跟 Python 类型系统结合。Strands 则比较轻，Agent 就运行在自己的 Python 进程里，并支持多种模型提供商，不要求先部署一个独立控制平面。Strands Agents
如果业务是复杂、有状态、可恢复的业务流程：
用户提交需求
↓
Agent 分析
↓
┌──资料不足──→ 请求用户补充 ─┐
│ │
└──资料完整 │
↓ │
调用系统 │
↓ │
Human Approval │
↓ │
执行 │
↓ │
失败 → retry / compensation ┘
这时候我还是更倾向：
LangGraph / Microsoft Agent Framework / Pydantic Graph + Durable Runtime
因为这里真正的问题已经不是“LLM 会不会调用工具”，而是 state machine、checkpoint、HITL、retry、resume、branching、durability。
Microsoft Agent Framework 现在尤其值得注意：官方明确把它描述为 Semantic Kernel 和 AutoGen 的直接后继者，整合了 Agent、Harness Agent、graph/function workflow、state management 和 HITL 等能力。Microsoft Learn
因此如果你现在准备学一个新的微软系 Python Agent 框架，我不会优先从 AutoGen 开始新项目，而会先研究 Microsoft Agent Framework。
如果你做的是 RAG / 企业知识库 / 文档 Agent：
User
↓
Query Understanding
↓
Hybrid Search
├─ Vector Search
├─ BM25
├─ SQL
└─ Knowledge Graph
↓
Reranking
↓
Agent
↓
Answer + Citation
优先考虑：
LlamaIndex / Haystack
而不是 CrewAI 之类的 multi-agent 框架。
Haystack 现在已经有自己的 Agent component，可以管理状态、Tool/MCP 调用、token usage、exit condition，并且 Agent 可以直接作为 Pipeline 的一个 component，所以它特别适合：
RAG Pipeline → Agentic RAG → 企业搜索 Agent
这条演进路线。Haystack Documentation
LlamaIndex 和 Haystack 与 LangGraph 也不是互斥的：
LangGraph
│
├── Business Workflow
│
└── RAG Node
↓
LlamaIndex / Haystack
↓
Vector DB / Search
这种组合在真实项目里往往比“所有东西都让一个框架做”更合理。
如果你做的是长期存在的 AI 员工 / AI Assistant，例如：
AI Sales
AI PM
AI Researcher
Personal Assistant
Customer Success Agent
我会特别研究 Letta。
它和 LangGraph 的思路不完全一样。
LangGraph 更像：
这个任务执行到了哪里？
Letta 更强调：
这个 Agent 是谁？它长期知道什么？过去经历过什么？
官方现在把 Letta 定位为构建 stateful agents 的平台，重点就在 memory、continual learning 和长期 Agent。Letta Docs
所以如果你的产品是“一次请求一次执行”，没必要专门上 Letta；如果 Agent 生命周期可能是几个月甚至几年，它就值得认真研究。
如果你做的是 Coding Agent / Data Agent / Research Agent，我还会关注 smolagents。
它很有意思的一点是把 CodeAgent 做成一等公民：
LLM
↓
generate Python
↓
execute Python
↓
observe result
↓
generate next Python
而不是全部变成：
LLM
↓
JSON tool call
↓
tool
官方同时提供 CodeAgent 和传统 ToolCallingAgent，并支持 sandboxed execution。Hugging Face
所以如果你做：
数据分析 Agent、科研 Agent、Code Agent、自动化 notebook、模型实验 Agent
smolagents 很适合学习和原型验证。
但大型企业业务 workflow，我不会把它作为第一选择。
还有一个很容易被忽略的特殊赛道：Voice Agent。
如果业务是：
AI 电话客服
AI 销售
AI 外呼
AI 面试官
AI 语音助手
Realtime Digital Human
不要硬拿 LangGraph 去解决音频 runtime。
直接研究 LiveKit Agents。
它解决的是完全不同的一组问题：
┌── VAD
Microphone → │
├── STT
│
├── LLM → Tools
│
├── TTS
│
└── interruption / turn detection
↓
Speaker
包括 WebRTC、STT/TTS、实时模型、打断、turn detection、telephony、multi-agent handoff、agent server、负载均衡等。官方 Python SDK 已经把这些做成专门的 realtime agent runtime。LiveKit 文档
所以 Voice Agent：LiveKit + 你的业务 Agent 层 往往比单独使用传统 Agent Framework 合适。
还有两个“不完全是 Agent Framework”，但 Python Agent 工程师应该学
第一个是 Temporal / DBOS / Prefect 这一类 Durable Execution Runtime。
假设你的 Agent：
Research Agent
↓
搜索 30 分钟
↓
等待人工审批 2 天
↓
调用 API
↓
服务器重启
↓
继续执行
↓
生成报告
这里最大的问题已经不是 Agent Loop，而是：
怎么保证任务不会丢？
所以架构可能变成：
Agent Layer
Pydantic AI / SDK
│
▼
Durable Execution
Temporal / DBOS / Prefect
│
┌────────┴────────┐
▼ ▼
Queue State
│ │
└───────┬─────────┘
▼
Workers
Pydantic AI 现在已经直接提供这类 durable execution 集成。Pydantic Docs
第二个是 DSPy。它更接近“LLM program optimization”，不是传统 Agent Runtime。等你的 Agent 架构稳定后，用它研究 prompt/program optimization、模块化 LM program 会比把它当 LangGraph 替代品更合理。
如果我是 Python Agent 工程师，我会这样建立技术栈
不要试图把十几个框架全部学会。可以形成一个 T 型技术栈：
Agent Application
│
▼
┌──────────────────────┐
│ Pydantic AI / │
│ OpenAI Agents SDK │ ← Agent Loop
└──────────┬───────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
LangGraph LlamaIndex LiveKit
Workflow RAG Voice
│ │
└─────┬─────┘
▼
Temporal / DBOS
Durable Runtime
│
▼
Postgres / Redis / Vector DB
如果让我给你安排学习优先级，考虑到你已经会 Python，而且前面已经关注 LangGraph、Deep Agents、Claude Agent SDK、OpenAI Agents SDK 等，我会这样：
第一梯队：Pydantic AI + LangGraph + OpenAI Agents SDK。
这三个能让你真正理解三种不同思想：typed agent loop、graph orchestration、轻量 agent SDK。
第二梯队：LlamaIndex/Haystack + Temporal。
前者解决知识/RAG，后者解决真正的 long-running production reliability。
第三梯队：按业务选专项。
长期记忆学 Letta；云端多 Agent 可以看 Google ADK / Microsoft Agent Framework / Strands；Voice 看 LiveKit；Code/Data Agent 看 smolagents；快速搭完整 Agent Platform 可以研究 Agno。Google ADK 目前已经覆盖 Python、多 Agent、workflow、evaluation、deployment、Agent Runtime 等完整生命周期。Google GitHub
这里最重要的其实是一个观念：
未来不太可能是“选一个 Agent Framework 解决所有问题”，而更像“Agent Harness + Workflow Runtime + Knowledge + Durable Execution + Observability”的分层组合。
比如你的生产项目完全可以是：
FastAPI
│
├── Pydantic AI # Agent
│
├── LangGraph # complex workflow
│
├── LlamaIndex # RAG
│
├── MCP # tools
│
├── Temporal # long-running task
│
└── PostgreSQL/Redis # state
这比纠结“CrewAI 和 LangGraph 到底谁更好”更接近现在真正的 Agent Engineering。
如果你愿意，我下一步可以直接基于你前面那批 Claude Agent SDK、LangGraph、Deep Agents、LlamaIndex、CrewAI、AgentScope、OpenAI Agents SDK，再加上这里的 Pydantic AI、ADK、Microsoft Agent Framework、Strands、Agno、Letta、smolagents、Haystack，给你整理成一张 「15 个 Python Agent 框架技术选型全景图」，重点标出哪些是竞品、哪些其实可以组合、以及 2026 年新项目优先学哪 5 个。
Python Agent 框架技术选型全景图与分析报告
研究范围： Claude Agent SDK、LangGraph、Deep Agents、LlamaIndex、CrewAI、AgentScope、OpenAI Agents SDK、Pydantic AI、Google ADK、Microsoft Agent Framework、Strands Agents、Haystack、Letta、Agno、smolagents。
研究对象： Python 应用开发者与 Agent 产品/工程团队。
检索截至：2026 年 10 月 3 日。
优先级定义： 下文“推荐学习优先级”采用 5 = 最高，1 = 最低。它是本报告基于通用 Python Agent 工程价值的判断，不是官方排名。
执行摘要
这 15 个项目并不处在同一个技术层级，因此不能简单问“哪个 Agent Framework 最好”。例如，LangGraph 明确把自己定位为低层的 orchestration framework/runtime，强调 durable execution、persistence、HITL 和长运行有状态流程；Deep Agents 则明确是构建在 LangGraph runtime 之上的 agent harness。LlamaIndex 与 Haystack 的核心优势更接近 RAG/Data 层；Letta 的差异化重点是长期存在的 stateful agent；Google ADK、Microsoft Agent Framework、Agno 则越来越接近“Agent + Workflow + Runtime/Platform”的完整栈。citeturn19view1turn18view3turn19view2turn13view0turn13view1turn18view0turn18view1turn13view2
对于一名 Python 开发者，我的核心建议是：先选 Agent Loop，再按业务复杂度叠加 Workflow、RAG、Memory 和 Durable Runtime，而不是一开始就选一个“大一统框架”。 普通企业 Copilot/API Agent，可以从 Pydantic AI 或 OpenAI Agents SDK 开始；当业务出现 checkpoint、暂停恢复、复杂分支、HITL、长任务后，再引入 LangGraph；知识密集型应用增加 LlamaIndex/Haystack；需要完整企业 Agent 平台时重点评估 Google ADK、Microsoft Agent Framework、Agno 或 Strands。Pydantic AI 当前已经覆盖多模型、typed outputs、Harness、Realtime 和 Temporal/DBOS/Prefect 等 Durable Execution 集成；OpenAI Agents SDK 则以较少抽象提供 agent loop、tools、handoffs、guardrails、sessions、MCP、tracing、sandbox 和 realtime/voice。citeturn18view2turn20view0
对于 2026 年以后新项目，本报告给 Python 开发者的综合学习 Top 5 是：Pydantic AI、LangGraph、OpenAI Agents SDK、Google ADK、LlamaIndex。它们并非五个互斥选项，而是分别覆盖了 Python typed agent、durable orchestration、轻量 agent runtime、企业级 agent platform、RAG/data intelligence 五个非常关键的能力面。citeturn18view2turn19view1turn20view0turn18view0turn19view2
有几个容易被营销名称掩盖的重要区别值得特别注意。Claude Agent SDK 实际上是在你的 Python/TypeScript 应用中运行 Claude Code binary，因此它更像一个 batteries-included coding/research harness，而不是纯粹的模型无关 agent-loop 库；Deep Agents 同样属于 harness，但底层 durable runtime 是 LangGraph。citeturn19view0turn18view3 Letta 在 2026 年发生了一个对 Python 开发者很重要的变化：当前新版 Letta Agent SDK 文档要求 JavaScript/TypeScript 项目，而 Python 仍可通过官方 letta-client / V1 API SDK 调用 Letta 服务，因此今天不宜把它和 Pydantic AI、LangGraph、OpenAI Agents SDK 当作完全同类的“Python-native 新 Agent SDK”。citeturn14view0turn15search11 另外，Pydantic AI 的核心能力已经非常广，但其 Harness 文档仍明确提示处在 0.x 版本阶段，minor release 可能发生 API 变化，生产项目应锁定版本并设置升级测试。citeturn17search18
因此，我对这 15 个框架的总体判断可以压缩成一句话：
Agent Loop 选 Pydantic AI / OpenAI Agents SDK；复杂 Workflow 选 LangGraph；RAG/Data 选 LlamaIndex / Haystack；完整企业平台看 Google ADK / Microsoft Agent Framework / Agno；长期记忆看 Letta；Coding/Research Harness 看 Claude Agent SDK / Deep Agents / Strands；最小化 Code Agent 看 smolagents。
技术选型总表
“是否适合生产”一列采取保守口径：只有官方资料明确使用 production-ready、production applications、production deployment 等表述时才标“是”；文档功能丰富但官方没有明确生产就绪声明的，按照你的要求标为“未明确”。
| 框架名 | 核心定位（Agent Loop/Workflow/RAG/Memory/Realtime/Durable/Platform等） | 主要语言/SDK（确认 Python 支持） | 典型业务场景 | 优点 | 局限/风险 | 是否适合生产 | 推荐学习优先级 |
|---|---|---|---|---|---|---|---|
| Claude Agent SDK citeturn19view0 | Agent Harness / Agent Loop / Coding Runtime | Python、TypeScript | Coding Agent、代码库操作、Research Agent、文件/Shell 自动化 | 直接继承 Claude Code 的文件、Shell、Web、session、hooks、subagents、MCP、permission | 强绑定 Claude；库实际运行 Claude Code binary；使用受 Anthropic Commercial Terms 约束 | 是：官方明确“Build production AI agents” citeturn19view0 | 4 |
| LangGraph citeturn19view1 | Workflow / Orchestration / Durable / Stateful Runtime | Python；另有 JS 生态 | 长任务、复杂状态机、审批、retry/resume、多阶段企业流程 | persistence、durable execution、HITL、memory；可混合确定性步骤与 LLM 节点 | 低层抽象，学习/状态设计成本高；简单 Agent 容易过度工程 | 是：官方提供长运行、故障恢复和部署体系 citeturn19view1 | 5 |
| Deep Agents citeturn18view3 | Agent Harness / Context / Subagents / Durable via LangGraph | Python | Deep Research、Coding Agent、文件型 Agent、复杂长上下文任务 | filesystem、sandbox、memory、summarization、context offloading、subagents、HITL；直接使用 LangGraph runtime | 与 LangGraph 不是平级竞品；更 opinionated；使用完整 harness 可能比简单 Agent 重 | 未明确；官方有 production deployment 路径 citeturn18view3 | 4 |
| LlamaIndex citeturn19view2turn17search8 | RAG / Data / Agent / Knowledge Workflow | Python | 企业知识库、文档 Agent、Agentic RAG、Text-to-SQL、数据检索 | ingestion/index/query/rerank/data connector 深；同时支持 Agent state、HITL、multi-agent、structured output | API 面较广；不是以通用 durable business workflow 为第一设计中心 | 是：官方 Framework 定位从 prototype 到 production citeturn17search8 | 5 |
| CrewAI citeturn16view0turn16view1 | Multi-Agent / Crews / Workflow Flows | Python | 角色型多 Agent、研究团队、业务自动化、内容/分析流水线 | Agents + Crews + Flows；state persistence/resume、memory、knowledge、guardrails、observability | 多 Agent 容易增加 token、延迟和调试难度；角色/crew 抽象较 opinionated | 是：官方明确称 production-ready citeturn16view0 | 3 |
| AgentScope citeturn13view3turn14view1 | Agent / Multi-Agent / Workflow / RAG / Realtime / Eval | Python ≥3.10 | Multi-Agent Debate、并发 Agent、Routing/Handoff、RAG、Realtime Agent | 功能覆盖 memory、long-term memory、MCP、A2A、RAG、Studio、tracing、evaluation、TTS | 覆盖面很宽，需要逐模块验证成熟度；官方未给整体 production-ready 明确声明 | 未明确 citeturn13view3 | 3 |
| OpenAI Agents SDK citeturn20view0 | Agent Loop / Handoff / Sandbox / Realtime / Voice | Python-first | Tool Agent、企业 Copilot、多 Agent handoff、Coding/Workspace Agent、Voice Agent | 抽象少；tools、guardrails、Pydantic schema、sessions、MCP、HITL、tracing、sandbox、realtime/voice 完整 | 最顺滑路径仍是 OpenAI 生态；复杂显式状态机不如 LangGraph 自然 | 是：官方明确称 production-ready citeturn20view0 | 5 |
| Pydantic AI citeturn18view2 | Typed Agent Loop / Harness / Realtime / Durable Integration / Graph | Python | 企业 API Agent、Structured Output、数据 Agent、Copilot、Coding/Research Harness | 与 Pydantic 类型体系高度一致；多模型；Harness、guardrails、memory、realtime；Temporal/DBOS/Prefect 等 durable 集成 | Harness 当前仍为 0.x，API 可能在 minor release 变化；能力面快速扩大带来版本治理成本 citeturn17search18 | 未明确 | 5 |
| Google ADK citeturn18view0 | Agent / Graph Workflow / Multi-Agent / Runtime / Realtime / Platform | Python、JS、Go、Java、Kotlin | 企业 Agent 平台、复杂多 Agent、A2A、云端 Agent、Live/Voice Agent | Graph、sequential/loop/parallel、多模型、sessions/memory、A2A、runtime、deploy、observability、evaluation、安全 | 平台面较大；若只做一个简单 Tool Agent，采用整套 ADK 会偏重 | 是：官方明确面向 production agents / enterprise scale citeturn18view0 | 5 |
| Microsoft Agent Framework citeturn18view1 | Agent / Harness Agent / Graph Workflow / Enterprise Integration | Python、.NET；Go 部分能力 Preview | Azure/Foundry 企业 Agent、长流程、企业集成、多 Agent、AutoGen/SK 新项目迁移 | Agent、Harness Agent、functional/graph workflow、session、context provider、middleware、MCP 统一 | 生态正在整合演进；不同语言能力并非完全同步，Go 官方仍标 Public Preview | 是：官方明确用于构建 production applications citeturn18view1 | 4 |
| Strands Agents citeturn16view2 | Agent Harness / Agent Loop / Multi-Agent / Voice / Production Ops | Python、TypeScript | AWS/Bedrock Agent、企业助手、Multi-Agent、Coding Agent、Voice Agent | 从预装 Harness 到低层 Harness SDK；多模型、MCP、memory、sessions、sandbox、HITL、A2A/Swarm/Graph、voice、observability | 虽模型无关，但生产部署与文档重心明显偏 AWS；能力面较宽 | 是：官方明确提供 production lifecycle、部署、安全治理路径 citeturn16view2 | 4 |
| Haystack citeturn13view0 | RAG / Pipeline / Agent / Data | Python | Enterprise Search、RAG Agent、文档 QA、数据检索 Pipeline | Pipeline/Components/Document Store 强；Agent 已具完整 tool loop、typed state、streaming、HITL、multi-agent、MCP | 非主要为复杂长运行业务状态机设计；业务编排复杂后通常还需要外层 workflow runtime | 未明确 | 4 |
| Letta citeturn13view1turn14view0 | Memory / Stateful Agent / Persistent Identity / Platform | Python API Client 支持；新版 Agent SDK 当前为 JS/TS citeturn14view0turn15search11 | 长期个人助手、AI Coworker、Persistent Agent、长期用户记忆 | 把 agent identity 和 long-term memory 作为 durable object；可 cloud/self-host | 对 Python 开发者需特别注意：新版 Agent SDK 当前不是 Python-first；采用其 memory/runtime 模型意味着较深平台耦合 | 未明确 | 2 |
| Agno citeturn14view2turn13view2 | Agent / Team / Workflow / Platform / Runtime | Python SDK | Agent SaaS、内部 Agent Platform、Data Agent、Multi-Agent、Workflow Automation | Agent/Team/Workflow 三原语；memory、knowledge、guardrails、30+ providers、100+ integrations；AgentOS 提供持久化、auth、tracing、background execution | 一体化程度高；采用 AgentOS 后平台依赖和运维面比纯 SDK 更大 | 未明确 | 3 |
| smolagents citeturn19view3 | Minimal Agent Loop / CodeAgent | Python | Code Agent、数据分析、实验、Local LLM、轻量 Research Agent | 逻辑极简；CodeAgent 一等公民；模型无关、tool/MCP 无关；可接 Docker/E2B/Modal 等 sandbox | durable workflow、复杂 state/platform 能力不是核心；代码执行必须严格 sandbox | 未明确 | 3 |
从这张表可以看出，真正形成直接竞争关系的并不是全部 15 个项目。LangGraph 与 LlamaIndex、Letta之间，往往更适合“组合”而非“二选一”；Deep Agents 与 LangGraph甚至存在明确的上下层依赖——Deep Agents 官方说明其 durable execution、streaming、HITL 等由 LangGraph runtime 提供。citeturn18view3turn19view1
全景图与框架关系
下面这张图以主要定位放置框架。一个框架可能横跨多个层，例如 Pydantic AI 同时包含 Agent Loop、Harness、Realtime 和 Durable Execution 集成，Google ADK 横跨 Agent、Graph Workflow、Runtime、Voice、Evaluation；图中只把框架放在其最值得用于选型判断的主层。citeturn18view2turn18view0
关系图读法： 同一主层中的框架才是最值得做 benchmark 的直接替代品；实线表示有明确架构关系，虚线表示本报告建议的工程组合方式，不意味着双方一定存在官方一等集成。
在 Agent Loop/Harness 层，Pydantic AI、OpenAI Agents SDK、Claude Agent SDK、Deep Agents、Strands、smolagents 最接近直接替代关系，但它们的“重量级”不同。OpenAI Agents SDK 强调少量 primitives；smolagents 刻意维持极小抽象；Claude、Deep Agents 与 Strands Harness 则倾向提供 filesystem、shell、memory、session、subagents/context 等更完整的 harness。citeturn20view0turn19view3turn19view0turn18view3turn16view2
在 Workflow/Orchestration 层，LangGraph、Google ADK Graph Workflows、Microsoft Agent Framework Workflows、CrewAI Flows、Agno Workflow、AgentScope Workflow 才是真正需要横向比较的一组。LangGraph最强调低层、持久化和显式状态控制；Google ADK 与 Microsoft Agent Framework覆盖范围更大，从 Agent 一直到 runtime/integration；CrewAI 则同时区分自治的 Crews 与更可控的 Flows。citeturn19view1turn18view0turn18view1turn16view0turn14view2turn13view3
在 RAG/Data 层，LlamaIndex 与 Haystack 是这 15 个框架中最明显的一组直接竞争者。LlamaIndex 官方文档将 indexing、loading、querying、storing、structured data、Text-to-SQL 和 agent building 放在同一框架中；Haystack 则保留强 Pipeline/Component/Document Store 架构，同时已经把完整 tool-calling loop、state、HITL、multi-agent、MCP 纳入 Agent component。citeturn19view2turn13view0
在 Memory/Stateful 层，Letta 的定位最独特：它强调“一次创建 Agent，之后从任何地方 resume”，Agent 自身的 identity 和 long-term memory 才是 durable object。这和 LangGraph 的“流程/状态可恢复”不是同一个问题：前者更接近“这个 Agent 长期是谁、记住了什么”，后者更接近“这次工作流执行到了哪里”。citeturn14view0turn19view1
因此，一个成熟 Python Agent 应用更可能长成下面这样，而不是“全项目只允许一个 Agent Framework”：
┌─────────────────────┐
│ FastAPI / Product │
└──────────┬──────────┘
│
┌───────────────▼───────────────┐
│ Agent Loop / Harness │
│ Pydantic AI / OpenAI SDK / │
│ Claude / Deep Agents / Strands│
└───────────────┬───────────────┘
│
┌─────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌─────────────────┐ ┌────────────────┐
│ Workflow │ │ RAG / Data │ │ Memory │
│ LangGraph/ADK │ │ LlamaIndex/ │ │ Letta / DB │
│ MS AF / CrewAI │ │ Haystack │ │ │
└───────┬────────┘ └─────────────────┘ └────────────────┘
│
▼
┌──────────────────────┐
│ Durable / Runtime │
│ LangGraph native │
│ Temporal/DBOS/... │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Postgres / Redis / │
│ Queue / Object Store │
└──────────────────────┘
Pydantic AI 官方已经把 Temporal、DBOS、Prefect、Restate 等列入 Durable Execution 体系，因此当业务需要真正的长任务恢复语义时，“Agent SDK + 外部 durable runtime”本身就是官方支持的设计方向，而不是必须让 Agent framework 独自承担所有可靠性职责。citeturn18view2
各框架实用建议
下表中的“首选/避免/组合”属于基于上述官方能力边界做出的工程选型判断，而非各厂商官方排名。
| 框架 | 何时首选 | 何时避免 | 最佳组合建议 |
|---|---|---|---|
| Claude Agent SDK citeturn19view0 | Agent 本质是“操作代码库/文件/终端/浏览器”的 Coding 或 Research Harness 时 | 需要模型厂商自由切换，或只是一个非常轻量的 API Tool Agent 时 | 外层 LangGraph/业务 Workflow；知识层接 LlamaIndex/Haystack |
| LangGraph citeturn19view1 | 流程需要显式 state、branch、checkpoint、HITL、暂停恢复、长时间执行 | CRUD + 两三个工具即可完成的 Copilot | Pydantic AI / OpenAI SDK 负责节点 Agent + LangGraph 负责流程；RAG 接 LlamaIndex/Haystack |
| Deep Agents citeturn18view3 | 想快速拥有 filesystem、context compression、subagents、sandbox 的深任务 Agent | 需要自己精细定义每一个 orchestration primitive | Deep Agents + LangGraph + LangSmith；知识层可接 LlamaIndex |
| LlamaIndex citeturn19view2 | 业务价值主要来自文档、数据库、搜索、RAG、Text-to-SQL | 核心难点是订单/审批/补偿事务式业务流程，而不是数据 | LlamaIndex + LangGraph；或作为 Pydantic/OpenAI Agent 的 retrieval/tool 层 |
| CrewAI citeturn16view0turn16view1 | 业务天然适合“研究员/分析师/审核员”等角色协作，且团队喜欢高层抽象 | 任务本质可由一个 Agent + tools 完成，或必须严格控制执行路径 | 优先 Crew + Flow 内部组合；RAG 层再接 LlamaIndex/Haystack，而不是再叠一套多 Agent 编排 |
| AgentScope citeturn13view3turn14view1 | 同时需要 routing、debate、concurrency、memory、RAG、realtime、evaluation 的 Python 多 Agent 项目 | 只需要一个极小 Agent Loop，并希望依赖面最小 | 优先使用其 Studio/Tracing/Evaluation；外部知识可接专业 RAG 层 |
| OpenAI Agents SDK citeturn20view0 | 快速生产 Tool Agent、Handoff Agent、Sandbox Agent、Realtime/Voice Agent | 强依赖复杂图状态机或需要完全自定义 durable orchestration 时 | OpenAI Agents SDK + LangGraph；复杂知识层配 LlamaIndex/Haystack |
| Pydantic AI citeturn18view2turn17search18 | Python 团队强调 typing、Pydantic schema、structured outputs、provider abstraction 时 | 不愿承担快速迭代 API/version pinning，尤其大量依赖 Harness 新能力时 | Pydantic AI + Temporal/DBOS/Prefect；复杂流程可配 LangGraph；RAG 配 LlamaIndex |
| Google ADK citeturn18view0 | 希望一个框架覆盖 Agent、Graph、Multi-Agent、Runtime、A2A、Voice、Eval、Deployment | 一个简单工具 Agent，团队不需要完整平台能力 | ADK 自身已覆盖大量层；专业 RAG 可接 LlamaIndex/Haystack |
| Microsoft Agent Framework citeturn18view1 | Azure/Foundry 企业环境，或准备从 AutoGen/Semantic Kernel 新一代架构出发 | 团队完全不使用 Microsoft/Azure，且只需要很小的模型无关 loop | Agent + Harness Agent + Workflow 优先内部组合；企业身份/中间件继续复用微软栈 |
| Strands Agents citeturn16view2 | AWS/Bedrock 为核心部署环境，或需要从简单 Harness 平滑深入到底层 agent loop | 非 AWS 团队只需要最小、窄功能 SDK 时 | Strands + Bedrock AgentCore/AWS runtime；复杂知识检索外接 LlamaIndex/Haystack |
| Haystack citeturn13view0 | 现有系统已经是搜索/RAG/Pipeline 思维，希望自然演化到 Agentic RAG | 主要难题是长运行、跨天审批、复杂业务状态机 | Haystack + LangGraph 是很自然的 Pipeline/RAG + Workflow 分层 |
| Letta citeturn13view1turn14view0turn15search11 | 产品卖点是 Agent 长期身份、跨 session 长期记忆、AI coworker | Python-only 团队希望直接使用其最新 Agent SDK 做本地原生 harness | Python 中将 Letta 作为状态/Agent 服务，外层可用 LangGraph/Pydantic 编排 |
| Agno citeturn14view2turn13view2 | 希望快速建立 Agent Platform，并需要 Agent/Team/Workflow/API/Auth/Tracing 一体化 | 已有成熟平台层，仅缺一个小型 agent-loop library | Agno SDK + AgentOS 是最自然组合；已有专业 RAG 时再连接外部 data layer |
| smolagents citeturn19view3 | 数据分析、Research、Code Agent、教学/研究，希望明确看到 Agent Loop | 企业核心流程需要 durable state、复杂治理、平台能力 | smolagents + Docker/E2B 等 sandbox；长任务外层加 LangGraph/durable runtime |
其中有几个非常实用的边界判断。
Claude Agent SDK vs Deep Agents： 两者都是“已经替你做好大量 harness 工作”的思路，而不是最薄的一层 SDK。Claude Agent SDK 复用 Claude Code 的 tools、permissions、sessions、hooks、skills、subagents；Deep Agents提供 filesystem、sandbox、memory、summarization、context offloading、task planning、subagent delegation，并明确建立在 LangGraph runtime 上。如果你高度依赖 Claude Code 风格工作环境，Claude Agent SDK 更直接；需要更明显的 provider/framework 可组合性和 LangGraph durable runtime，则 Deep Agents 更自然。citeturn19view0turn18view3
OpenAI Agents SDK vs Pydantic AI： 对 Python 工程师而言，这是非常值得亲自做 PoC 的一组。OpenAI Agents SDK 的哲学是少量 primitives、Python-first，并把 handoff、guardrail、session、tracing、sandbox、realtime 做成一体；Pydantic AI 则更强调 Python type system、Pydantic output/dependencies、多 provider、可扩展 Harness 和外部 durable runtimes。前者对 OpenAI 产品能力采用更直接，后者更适合把 Agent 当作普通 typed Python service 来工程化。citeturn20view0turn18view2
LangGraph vs Google ADK/Microsoft Agent Framework： LangGraph更像专门的 orchestration runtime，不试图替你抽象所有 agent architecture；ADK 和 Microsoft Agent Framework 则试图覆盖 Agent、Workflow、runtime/integration、evaluation/deployment 更完整的生命周期。因此要求“最大控制力”时 LangGraph 很有优势；希望统一平台能力、减少拼装时，ADK/MS Agent Framework 更值得评估。citeturn19view1turn18view0turn18view1
LlamaIndex vs Haystack： 两者都已经不是“只有 RAG”的旧印象。LlamaIndex 当前 Agent 文档包括 state、streaming、HITL、multi-agent 和 structured outputs；Haystack Agent component 已自己管理完整 tool-calling loop、typed state、HITL 和 multi-agent。不过，如果业务的核心竞争力仍是复杂知识检索、ingestion、document/data pipeline，这两个项目依然比纯 multi-agent framework 更应该优先进入 shortlist。citeturn19view2turn13view0
新项目优先学习前五
这里的 Top 5 是按照**“2026 年以后 Python Agent 应用工程师的长期通用收益”**排序，而不是 GitHub 星数、融资或厂商规模排名。
| 排名 | 框架 | 推荐理由（不超过 50 字） |
|---|---|---|
| 1 | Pydantic AI | 类型安全、模型无关，最贴近现代 Python 工程习惯。 citeturn18view2 |
| 2 | LangGraph | 长任务、状态、HITL、持久化与显式流程控制强。 citeturn19view1 |
| 3 | OpenAI Agents SDK | 抽象少，工具、护栏、会话、Sandbox、实时能力齐。 citeturn20view0 |
| 4 | Google ADK | Agent、Graph、Runtime、评测部署一体且支持多模型。 citeturn18view0 |
| 5 | LlamaIndex | RAG 与数据连接深，知识密集型 Agent 的关键能力。 citeturn19view2 |
对你的 Python 背景而言，我认为最合理的学习路径不是按照排名连续学五套 API，而是按层学习：
第一阶段
Pydantic AI
↓
掌握 Agent Loop / Tool / Context / Structured Output / Provider
第二阶段
LangGraph
↓
掌握 State / Graph / Checkpoint / HITL / Durable Execution
第三阶段
LlamaIndex
↓
掌握 Ingestion / Retrieval / Rerank / Agentic RAG / Text-to-SQL
第四阶段
OpenAI Agents SDK
↓
理解轻量 Runtime / Handoff / Guardrail / Sandbox / Realtime
第五阶段
Google ADK
↓
理解大型 Agent Platform / Graph / Multi-Agent / A2A / Deployment
这样学习的好处是，你最终掌握的不是五个框架的 API，而是五种长期稳定的 Agent Engineering 概念。LangGraph 官方自己也强调它是 orchestration runtime，而不是要求用户把所有 agent-building abstraction 都交给它；Google ADK 同时明确区分 simple agents、graph workflows、multi-agent workflows、runtime 和 deployment，这种分层本身正说明“Agent framework”已经逐步演化为多个技术层。citeturn19view1turn18view0
另外，对 Pydantic AI 排第一需要加一个工程限定：这是基于 Python 工程匹配度，而不是因为它在每个维度都最成熟。其 provider 支持、typing、persistence、retries、timeouts、multi-agent、Harness、Realtime 和 Durable Execution 范围非常广，但 Harness 官方目前仍提示 0.x API 可能发生 minor-level 变化。因此生产应用需要 uv.lock/lockfile、固定 minor version、回归测试和明确的升级策略。citeturn18view2turn17search18
团队决策维度
真正做技术选型时，建议不要开会讨论“大家喜欢哪个框架”，而是建立一个加权评分表。下面这些维度至少应该进入 Architecture Decision Record。
| 决策维度 | 团队必须回答的问题 | 选型影响 |
|---|---|---|
| Agent Loop 控制度 | 需要自己控制每一次 model/tool turn，还是希望 framework 自动 loop？ | 越需要细控，越偏 LangGraph/Pydantic/低层 SDK；越希望开箱即用，越偏 Harness |
| Durability | 服务重启、网络失败、运行数小时/数天后能否从 checkpoint 恢复？ | 长任务是 LangGraph、durable runtime 类能力的核心理由 citeturn19view1turn18view2 |
| Statefulness | 只是当前 conversation state，还是需要跨 session、跨用户、长期 identity？ | conversation state 与 Letta 式 persistent identity 是两个问题 citeturn14view0 |
| Multi-Agent | 真需要多个自治 Agent，还是一个 Agent + tools 就够？ | 不必要的多 Agent 会扩大调用链、失败面和调试复杂度 |
| Workflow 可确定性 | 哪些步骤允许 LLM 决策？哪些必须 deterministic、auditable？ | 高合规流程更适合显式 graph/flow，而不是完全自由 multi-agent；LangGraph直接支持二者混合 citeturn19view1 |
| RAG / Data | 核心问题是 Agent 推理，还是高质量 ingestion/retrieval/rerank/data access？ | 数据问题占主导时，LlamaIndex/Haystack 往往应先于 Multi-Agent 框架进入 shortlist citeturn19view2turn13view0 |
| Typed Outputs | Tool 参数和业务结果是否必须有强 Schema、validation、IDE/type-checker 支持？ | Python 强类型团队应重点评估 Pydantic AI、OpenAI SDK 等 schema-first 方案 citeturn18view2turn20view0 |
| Provider-agnostic | 是否必须在 OpenAI/Anthropic/Gemini/Bedrock/local model 间迁移？ | Pydantic、ADK、Strands、smolagents、Agno 等均提供多 provider 路径，但抽象深度不同 citeturn18view2turn18view0turn16view2turn19view3turn14view2 |
| Realtime / Voice | 是文本 Agent，还是低延迟 speech-to-speech / voice workflow？ | OpenAI SDK、ADK、Pydantic、Strands、AgentScope已有 realtime/voice 能力；需单独做延迟测试 citeturn20view0turn18view0turn18view2turn16view2turn13view3 |
| Execution Environment | Agent 会不会读写文件、执行 Shell/Python、访问浏览器？是否需要 sandbox？ | Claude、Deep Agents、OpenAI Sandbox、Strands、smolagents 等都必须把执行安全作为一级设计问题 citeturn19view0turn18view3turn20view0turn16view2turn19view3 |
| Observability / Evals | 能否查看完整 trajectory、tool call、token/cost、state transition，并离线回放评测？ | Agent 随机性比传统后端高，trace/eval 不应等上线后再补；多个框架已原生提供相关能力 citeturn20view0turn18view0turn13view3turn14view2 |
| Security / Guardrails / HITL | 危险工具是否需审批？如何做 prompt injection、权限、PII、secret 隔离？ | 有副作用的 tool execution 必须评估权限/HITL/sandbox，而不能只看模型效果 citeturn19view0turn18view2turn16view2turn20view0 |
| Deployment Complexity | 是一个 Python process，还是还需要 control plane、runtime server、sandbox、queue、state store？ | Agno/ADK 等平台能力更多，同时也意味着更大的运维面 citeturn13view2turn18view0 |
| Cost / Latency | 每个用户任务实际需要几次模型调用、多少 subagent、多少检索、多少 context？ | 应对真实任务做 trajectory benchmark，不能按框架宣传判断成本 |
| License / Commercial Terms | SDK、server、enterprise feature、hosted service 是否属于同一许可证？ | 必须逐组件核验；例如 Claude Agent SDK受商业条款约束，而 CrewAI OSS repo 明确为 MIT citeturn19view0turn16view1 |
| Community / Activity / Stability | release cadence、breaking changes、issue 响应、migration guide、LTS 策略如何？ | 快速发展的 Agent 框架尤其需要版本钉定；Pydantic Harness 0.x 是明确案例 citeturn17search18 |
| Vendor Lock-in | 换模型容易，还是连 session、sandbox、memory、trace、deployment 都依赖厂商？ | “支持多模型”不等于“没有平台锁定”；runtime/state/tooling 也要算迁移成本 |
| Data Residency / Compliance | prompt、trace、memory、文件、sandbox 数据到底运行和保存在哪里？ | 金融、医疗、政府、企业内网项目需要在 PoC 前确认部署边界 |
这里最值得强调的是 Durability 与 Memory 不应混为一谈。
Memory:
“这个用户以前喜欢什么？”
“这个 Agent 过去学到了什么？”
Durability:
“这次任务执行到第 17 步时机器挂了，
重新启动后能否从第 17 步继续？”
Letta更强调前者以及 Agent identity 的长期存在；LangGraph 明确强调 persistence、failure recovery 和 long-running workflow；Pydantic AI 则通过 Temporal、DBOS、Prefect 等后端提供 durable execution 集成。三者可以解决相邻问题，但不是同一个抽象。citeturn14view0turn19view1turn18view2
同样，Provider-agnostic 也不应该只检查“能不能换一个 model name”。一个框架即使支持 OpenAI、Anthropic、Gemini 和本地模型，如果其 session、sandbox、memory、tracing、evaluation、deployment 全部绑在某个平台上，迁移成本仍可能很高。Google ADK、Pydantic AI、Strands 和 Agno 都展示了多 provider 能力，但团队仍应分别评估“模型锁定”和“运行时锁定”。citeturn18view0turn18view2turn16view2turn14view2
综合这些维度，实际项目可以采用下面的决策树：
你的应用主要问题是什么？
│
├── 简单 Tool / API Agent
│ ├── Python typing 很重要 → Pydantic AI
│ └── OpenAI 生态为主 → OpenAI Agents SDK
│
├── Coding / Research / 文件操作
│ ├── Claude 为核心 → Claude Agent SDK
│ ├── LangGraph 生态 → Deep Agents
│ ├── AWS 为核心 → Strands
│ └── 极简 CodeAgent → smolagents
│
├── 长任务 / 复杂状态 / 审批 / Resume
│ └── LangGraph
│ └── 更强 durable 需求 → Temporal/DBOS 等
│
├── RAG / 企业知识 / 文档 / SQL
│ ├── 数据/Agentic RAG → LlamaIndex
│ └── Pipeline/RAG → Haystack
│
├── Multi-Agent / 企业平台
│ ├── Google/跨语言/A2A → Google ADK
│ ├── Azure/Foundry → Microsoft Agent Framework
│ ├── Role-based team → CrewAI
│ ├── Python综合平台 → Agno
│ └── AgentScope体系 → AgentScope
│
└── Agent 本身需要长期身份与长期记忆
└── Letta
对多数 Python 企业应用，我会采用一个更保守的架构原则：先证明一个 Agent + tools 不够，再增加 multi-agent；先证明普通代码不够，再增加 Graph；先证明普通数据库 session 不够，再引入专门 Memory 系统；先证明请求级执行不够，再引入 Durable Runtime。 这与 LangGraph 官方“低层、仅在需要 orchestration 时使用”的定位，以及 Agno 对 Agent、Team、Workflow三种 primitive 的区分是一致的。citeturn19view1turn14view2
参考来源与研究口径
本报告技术事实优先引用官方文档、官方 GitHub 和项目原始资料；没有用第三方排行榜来判断框架能力。绝大多数官方资料为英文，因此正文给出了中文工程摘要。除特别注明外，网页没有稳定的“发布日期”字段，统一记录检索日期 2026-10-03；Microsoft Agent Framework 页面在检索时显示的官方更新信息为 2026 年文档版本。所有“推荐学习优先级”“首选/避免”“最佳组合”均属于基于官方能力边界做出的本报告分析。
| 框架/主题 | 官方/原始来源 | 中文摘要 | 日期 |
|---|---|---|---|
| Claude Agent SDK | Anthropic — Agent SDK Overview citeturn19view0 | Python/TS；复用 Claude Code loop、tools、sessions、hooks、subagents、MCP；运行 Claude Code binary；受商业条款约束 | 检索 2026-10-03 |
| LangGraph | LangChain — LangGraph Overview citeturn19view1 | 低层 orchestration runtime；durable execution、persistence、HITL、long-running stateful agents | 检索 2026-10-03 |
| Deep Agents | LangChain — Deep Agents Overview citeturn18view3 | Agent Harness；filesystem、context management、subagents；底层使用 LangGraph runtime | 检索 2026-10-03 |
| LlamaIndex | LlamaIndex — Python Framework citeturn19view2turn17search8 | RAG/Data + Agent；ingestion、index、query、state、HITL、multi-agent、structured outputs | 检索 2026-10-03 |
| CrewAI | CrewAI Documentation citeturn16view0 | Agents、Crews、Flows；memory、knowledge、guardrails、persistence、resume、observability | 检索 2026-10-03 |
| CrewAI License | CrewAI Official GitHub citeturn16view1 | 官方 repo 标明 MIT License；Python standalone framework | 检索 2026-10-03 |
| AgentScope | AgentScope Documentation citeturn13view3 | Multi-Agent workflow、memory、MCP、A2A、Realtime、RAG、Studio、Tracing、Evaluation | 检索 2026-10-03 |
| AgentScope Python | AgentScope Installation citeturn14view1 | Python ≥3.10；可通过 PyPI 安装 agentscope | 检索 2026-10-03 |
| OpenAI Agents SDK | OpenAI — Agents SDK for Python citeturn20view0 | Python-first；agent loop、handoff、guardrail、session、MCP、tracing、sandbox、realtime、voice | 检索 2026-10-03 |
| Pydantic AI | Pydantic AI Documentation citeturn18view2 | Typed Agent、multi-provider、Harness、memory、guardrails、Realtime、Durable Execution、Graph | 检索 2026-10-03 |
| Pydantic Harness 稳定性 | Pydantic AI Harness Documentation citeturn17search18 | 官方提示 Harness 处于 0.x，minor release 可能产生 API 变化 | 检索 2026-10-03 |
| Google ADK | Google — Agent Development Kit citeturn18view0 | Python/JS/Go/Java/Kotlin；Agent、Graph、Multi-Agent、Runtime、A2A、Voice、Deployment、Evaluation | 检索 2026-10-03 |
| Microsoft Agent Framework | Microsoft Learn — Agent Framework Overview citeturn18view1 | Agent、Harness Agent、functional/graph workflow、session、context、middleware、MCP；Python 支持 | 检索 2026-10-03 |
| Strands Agents | Strands Agents Official Documentation citeturn16view2 | Python/TS；Harness/Harness SDK、MCP、multi-agent、memory、sandbox、voice、production ops | 检索 2026-10-03 |
| Haystack | Haystack — Agents citeturn13view0 | RAG/Pipeline 基础上提供 Agent loop、typed state、HITL、multi-agent、MCP | 检索 2026-10-03 |
| Letta | Letta Documentation citeturn13view1 | Stateful agents、long-term memory、AI coworker、self-host/cloud | 检索 2026-10-03 |
| Letta Agent SDK | Letta Agent SDK citeturn14view0 | 当前新版 SDK 强调 durable agent identity，但要求 JS/TS 项目 | 检索 2026-10-03 |
| Letta Python Client | Letta V1 Client SDKs citeturn15search11 | 官方仍提供 Python letta-client 访问 Letta API | 检索 2026-10-03 |
| Agno | Agno SDK citeturn14view2 | Python；Agent、Team、Workflow；memory、knowledge、guardrails、OTel、background execution | 检索 2026-10-03 |
| Agno Agent Platform | Agno Documentation citeturn13view2 | SDK + AgentOS + Control Plane 的 agent-platform 架构 | 检索 2026-10-03 |
| smolagents | Hugging Face — smolagents citeturn19view3 | Python；极简 agent loop、CodeAgent、ToolCallingAgent、多模型、sandbox code execution | 检索 2026-10-03 |
最终的技术选型不宜形成“全公司只能使用一个 Agent Framework”的标准，而更适合形成分层标准：规定默认 Agent SDK、默认 orchestration runtime、默认 RAG/Data layer、默认 durable runtime、默认 tracing/evaluation 接口，以及什么情况下允许引入第二套框架。官方生态本身已经呈现这种分层趋势：LangChain 明确区分 Deep Agents harness、LangGraph runtime、LangSmith observability/platform；Pydantic AI 将 core agent、Harness、Realtime、Durable Execution 分开；Google ADK 则明确区分 Agent、Graph/Multi-Agent Workflows、Runtime、Deployment、Observability 和 Evaluation。citeturn19view1turn18view3turn18view2turn18view0
因此，对于你的 Python 技术背景，一个较稳健的 2026+ 默认技术栈可以概括为：
默认 Agent SDK
Pydantic AI
或 OpenAI Agents SDK
↓ 只有复杂流程才增加
Workflow / Durable Orchestration
LangGraph
↓ 知识密集业务增加
RAG / Data
LlamaIndex 或 Haystack
↓ 真正长运行任务增加
Durable Execution
LangGraph Native
或 Temporal / DBOS / Prefect 等
↓ 按场景替换 / 加专项能力
Coding Harness → Claude Agent SDK / Deep Agents / Strands
Enterprise → Google ADK / Microsoft Agent Framework / Agno
Long-term Agent → Letta
Multi-Agent → CrewAI / AgentScope / ADK / MS AF
Code/Data PoC → smolagents
这套分层思路最大的价值，是避免把 Agent Loop、Workflow、RAG、Memory、Realtime、Durability、Observability 七个不同的问题误认为一个“Agent Framework 选型”问题；也使团队未来更换模型、RAG 技术或执行 runtime 时，不必整体重写 Agent 应用。
更多推荐
1
0- 0
已为社区贡献2条内容
所有评论(0)