2026 AI Agent 框架怎么选：从排行榜转向决策框架

框架对比文章经常试图选出一个赢家，但这本身就是错误的问题。

Agent 框架只是更大系统里的一个运行时选择。完整系统还包括模型、工具、身份、数据、队列、存储、策略、可观测性和运维人员。一个在 Demo 里显得优雅的框架，一旦遇到工作进程崩溃后要恢复、要为一笔退款留下"谁批准的"证据链、或要阻止不可信文档去挑选工具时，可能完全不是好选择。

本文不制造通用排行榜，而是对比七类仍在主动演进的 Agent 运行时，并把 Microsoft AutoGen 单独视为维护与迁移决策，而不是新项目候选。本文提供：

• 区分框架各层次的词汇；
• 以工作负载为中心的决策矩阵；
• 可复现的公平评测流程；
• 常被营销表格遗漏的失败与安全指标；
• 保留业务逻辑、降低框架迁移成本的方法。

2026 年的生命周期已经发生实质变化：LangGraph 进入稳定 1.x，Microsoft Agent Framework 的 Python 与 .NET 核心发布 1.0，Microsoft AutoGen 进入维护模式，AG2 则把新 API 推进到独立 1.x 路线。文末官方资料才是当前 API 的权威依据。

先给结论

从"能表达这条工作流的最简单运行时"开始：

这些只是起始假设。用真实工具做一个两天的验证性原型（Spike），比任何流行度排名都更有证据价值。

先决定是否真的需要 Agent

在比较框架之前，先比较架构。

以下情况优先使用确定性工作流：

• 步骤和分支已知；
• 每个操作有稳定的输入和输出；
• 可审计性比开放式探索更重要；
• 故障恢复可以建模为状态机。

以下情况使用配备窄化工具的单个 Agent：

• 任务需要灵活地理解自然语言；
• 可用的操作数量有限；
• 重要结果可以人工审核；
• 循环可以设置硬性上限。

只有当多个 Agent 真正提供了一道边界时才使用它：

• 不同的凭证或数据范围；
• 不应共享的独立上下文；
• 可以独立评测的专业工作；
• 并行工作的收益足以抵消协调成本。

"Agent 更多"不是一种成熟度等级，而是又一套分布式系统。

先拆分系统层次

很多对比表把不同层次的产品塞进同一行。更清晰的模型是：

模型提供方
    |
Agent 循环 / 运行框架
    |
编排运行时 -------- 状态与持久化
    |
工具与 MCP 适配器 - 身份与策略
    |
外部服务 ---------- 追踪与运营

• **模型提供方：**生成文本、结构化输出或工具调用提议。
• **Agent 循环：**在拿到工具结果后决定如何继续。
• **编排运行时：**表示分支、重试、事件和依赖关系。
• **状态层：**保存工作状态、检查点、记忆和产物。
• **工具层：**在身份和授权约束下执行各项能力。
• **运营层：**提供队列、截止时间、追踪、评测和事故响应。

没有哪个框架能免去对其他层的需求。内置的追踪页面不等于租户级审计日志；检查点 API 也不自动等于事务；MCP 连接器更不是一套授权系统。

七类能力画像

LangGraph：显式的编排运行时

LangGraph 把自己定位为面向长时间、有状态 Agent 的低层编排框架和运行时。它有用的核心抽象，是一张由节点读取并更新状态的图。当前文档强调持久化、持久化执行、流式输出，以及人在回路的中断。

优势

• 拓扑和条件路由可见；
• 检查点可持久化、工作可恢复；
• 状态归约器和子图组合明确；
• 适合审批、回放和运营调试。

成本

• 需要更多的设计和状态建模工作；
• 很容易构建出过于复杂的图；
• 授权、事务和工具策略仍由应用代码负责；
• 周边的 LangChain 生态是可选的，但混用其抽象时要划清边界。

当工作流形状本身就是产品要求、而不仅仅是实现细节时，选择它。

OpenAI Agents SDK：围绕 Agent 循环的轻量运行时

OpenAI Agents SDK 提供一小组原语：Agent、工具、交接（或"Agent 作为工具"）、护栏、会话和追踪。它的文档明确区分了 SDK 与直接调用 Responses API：SDK 在模型调用之上增加了更高层的循环和运行时行为。

优势

• Python 应用的快速落地路径；
• 交接与专家 Agent 的组合直观；
• 函数工具的 Schema 自动生成与校验；
• 内置追踪，并可选用会话或沙箱工作流。

成本

• 需要核验提供方和运行时假设是否满足可移植性；
• 一次交接不等于一笔完整的工作流事务；
• 护栏不能替代对象级授权；
• 长时间运行的持久性仍需独立的运营设计。

当少量原语恰好映射到任务、且团队愿意自己拥有周边服务时使用它。

Strands Agents：代码优先、模型驱动的循环

Strands 提供面向 Python 和 TypeScript 的轻量代码优先 SDK，核心是一个简单的 Agent 抽象和可配置的模型提供方。它模型驱动的循环代码很简洁，但代码简洁并不意味着行为确定。

优势

• 单 Agent 与工具类工作流的仪式感低；
• 提供方和部署方式灵活；
• 从本地原型到服务化的路径直接；
• 适合让模型在少量工具中自主选择的受限任务。

成本

• 由模型选择的路由，比显式的图更难审计；
• 状态持久化和业务事务仍是应用的责任；
• 社区工具需要供应链和权限审查；
• 与 AWS 的适配既可能是优势，也可能形成耦合，取决于部署方式。

在定义好外部预算和策略之后，把它用于边界清晰的工具类任务。

CrewAI：Agent、任务、Crew 与 Flow

CrewAI 围绕 Agent、任务、Crew 和 Flow 组织工作。当前文档还覆盖了状态、持久化、恢复、护栏、回调，以及人在回路的触发点。

优势

• 词汇贴近业务流程；
• 支持顺序、层级和混合的任务流程；
• 原型路径相对易上手；
• Flow 能提供比自由式 Crew 更明确的外层工作流。

成本

• 角色和背景设定不能替代一套权限模型；
• 任务委派可能隐藏延迟、Token 和故障成本；
• 持久性行为必须实测，不能从抽象名称去推断；
• 企业版功能与开源运行时的能力可能不同。

当任务/流程语义确有价值、且团队仍愿意检查底层调用时使用它。

Microsoft Agent Framework 1.0：微软的后继路线

Microsoft Agent Framework 已于 2026 年 4 月为 Python 与 .NET 发布 1.0。微软把它定义为 AutoGen 与 Semantic Kernel 的直接后继，并承诺核心 API 稳定和长期支持。它把模型客户端、Agent Session、Context Provider、中间件、MCP Client 与图工作流放入同一套框架；Workflow API 覆盖类型化路由、嵌套、Checkpoint 和人工介入所需的 Request/Response 模式。

微软还在独立仓库提供 Go SDK。它已覆盖核心 Agent、Tool、中间件、Workflow、OpenTelemetry、MCP、A2A、AG-UI 与 Skill，但仍处于公开预览，并明确缺少 Handoff 编排、Declarative Agent 与部分 Hosting 能力。因此「MAF 支持 Go」不等于 Python、.NET 与 Go 的发布状态或功能完全一致。

优势

• 为 Python 与 .NET Agent 应用提供统一的微软支持路线；
• 同时提供模型驱动 Agent 和显式工作流；
• 包含提供方抽象、中间件、Session 与 OpenTelemetry 集成；
• 为既有 AutoGen 和 Semantic Kernel 项目提供迁移指南。

成本

• 必须按具体语言和软件包版本核验预览集成与 Go 功能是否对齐；
• Foundry 集成有实际价值，但也会引入 Azure 特有的运营选择；
• Checkpoint 仍不能替代应用层幂等和事务设计；
• 迁移不是简单改命名空间，因为状态模型和编排模型已经不同。

新建微软技术栈项目时，应先用稳定的 Python 或 .NET 核心做锁定版本的验证性原型；Go 仍需按预览依赖审批。既有 AutoGen 应用则要比较迁移成本与继续维护成本，不能假设它会自动升级。

Microsoft AutoGen：维护决策

Microsoft AutoGen 已不再是新项目的主动演进框架。官方仓库明确说明它进入维护模式，不再增加新功能或增强，并转为社区维护。已有 autogen-agentchat、autogen-core 与 autogen-ext 应用仍可继续运行，但负责人必须固定版本、评估安全支持期限，并完成至少一个迁移实验。

不要把它与 Microsoft Agent Framework 或 AG2 混为一谈。Microsoft AutoGen 的 AgentChat/Core 状态与消息模型迁移到 MAF Workflow 时需要显式映射；只替换软件包不会保持原有行为。

AG2 1.x：独立的活跃框架

AG2 不是 Microsoft AutoGen。AG2 1.0 已把协议导向的 Beta 架构提升为主线：安装和导入名均为 ag2。旧 autogen 包与 ConversableAgent API 已迁到独立的 AG2 Classic 仓库，只接收安全和关键缺陷修复。AG2 1.x 提供异步 Agent、Event Stream、中间件、Evaluation、MCP、A2A、ACP、AG-UI、Skill 与 Subagent，但每项可选集成仍需做版本和安全审查。

优势

• 活跃开发的协议导向 ag2 包；
• 可组合的 Agent、Event Stream、中间件、Subagent、Tool 与 Evaluation；
• 围绕 MCP、A2A、ACP 与 AG-UI 的显式互操作路线；
• 清楚区分活跃 v1 与维护中的 Classic 代码。

成本

• AG2 1.x 不是经典 autogen 包的原地升级；
• 自由式委派可能成倍增加调用，并让终止条件不透明；
• 快速扩展的协议与集成会扩大兼容性和攻击面；
• 代码执行、序列化状态、远程 Agent 和生成产物必须显式隔离；
• AG2、AG2 Classic、Microsoft AutoGen 与 Microsoft Agent Framework 的代码不能互换。

当其可组合 Agent 与协议模型真正适合工作负载时使用 AG2 1.x。只有在保留现有 ConversableAgent 系统比迁移更低风险时，才继续采用 AG2 Classic。

Claude Agent SDK：与产品绑定的运行时

Claude Agent SDK 应当被当作特定产品运行时来评估，而不是通用的 Function Calling 包装器。当前 Python 包名是 claude-agent-sdk，TypeScript 包名是 @anthropic-ai/claude-agent-sdk；它开放了 Claude Code 背后的文件、Shell、Web、Hooks、Subagents、MCP、Permissions 与 Sessions 能力。

可能适合

• 以 Claude 为中心的应用；
• 受益于内置文件与命令工具的编码、研究和运营任务；
• 愿意接受提供方耦合的组织。

必须先回答的问题

• 允许哪些工具、路径、命令和网络路由？
• Session 保存什么、保存多久、保存在哪里？
• Agent 运行在内置 Sandbox Mode、容器、gVisor 还是虚拟机中？
• 用户身份、审批、取消和审计如何逐层传播？
• 如果运行时或模型发生变化，退出方案是什么？

Anthropic 文档提供权限系统和可选的 Sandbox Mode，并建议高风险部署采用更强的容器、网络、凭证代理或虚拟机边界。SDK 不会替部署方完成这项隔离责任。

不要混用三个 AutoGen 名称

这不是编辑层面的命名讲究，而是运营边界：它决定软件包名称、兼容性、迁移成本和路线图归属。

按决策维度比较

状态不是记忆

要区分：

• **线程状态：**当前这一次运行及其检查点；
• **工作流状态：**业务进度和外部事务 ID；
• **长期记忆：**有自己的同意与删除策略的、可复用的用户或领域信息；
• **产物：**有所有者和保留期限的文件与报告；
• **审计事件：**关于"发生过什么"的不可变证据。

一个框架可能只提供其中一项，把其余的都留给你。

交接不是授权

无论框架把它叫作交接、委派、子 Agent 还是管理者，接收方都必须只拿到一个缩减后的能力集合。传递一个类型化的任务和范围化的上下文，而不是把父 Agent 的环境凭证和完整对话记录整个交过去。

把生命周期决策写成可执行门禁

当团队想把仅维护的软件包用于新项目，或未经批准就引入预览 SDK 时，框架清单应该直接失败。下面的 Go 标准库示例把生命周期风险和迁移证据从主观打分中拆出来：

package main

import (
	"errors"
	"fmt"
)

type Candidate struct {
	Name           string
	Lifecycle      string
	Language       string
	PreviewAllowed bool
	MigrationTest  bool
}

func eligible(candidate Candidate) error {
	if candidate.Lifecycle == "maintenance" {
		return errors.New("maintenance-only runtime is not a greenfield default")
	}
	if candidate.Lifecycle == "preview" && !candidate.PreviewAllowed {
		return errors.New("preview dependency lacks an explicit exception")
	}
	if !candidate.MigrationTest {
		return errors.New("state and side-effect migration are unverified")
	}
	return nil
}

func main() {
	candidate := Candidate{
		Name:           "Microsoft Agent Framework for Go",
		Lifecycle:      "preview",
		Language:       "go",
		PreviewAllowed: true,
		MigrationTest:  true,
	}
	if err := eligible(candidate); err != nil {
		panic(err)
	}
	fmt.Printf("eligible=%s language=%s\n", candidate.Name, candidate.Language)
}

这段门禁不负责评判框架质量，而是让团队在比较开发体验之前，先显式处理生命周期和迁移证据。

安全与运营

把模型输出、工具描述、MCP 元数据、检索到的文档和工具结果，全部当作不可信输入。绝不能让框架把一句有说服力的话自动升级为权威指令。

最低控制要求：

• 位于模型之外的、经过认证的主体与租户上下文；
• 每一次工具调用都做对象级授权；
• 使用窄化的业务工具，而非通用的 SQL、HTTP 和 Shell；
• 为外部来源派生的数据追踪其来源；
• 把确认绑定到规范化后的参数和资源版本上；
• 让生成的代码运行在没有环境默认密钥的沙箱里；
• 出站白名单与重定向控制；
• 写操作使用持久化的幂等机制；
• 步数、时间、Token、成本和并发的预算；
• 把删除操作传播到检查点、记忆、索引和产物。

选型时，加入一个滥用场景来检验：

一份恶意文档要求 Agent 把私有数据发送到一个新地址，而工作进程恰好在审批期间重启了。

真正的赢家不是功能表最漂亮的框架，而是其周边架构能够证明"这一幕不会变成越权副作用"的框架。Agent Harness 架构指南说明了这些控制在模型循环周围的位置。

可复现的评测流程

如果别人无法复现你的实验，就不要发布分数。

1. 固定变量

记录：

• 精确的软件包版本和提交号；
• 模型、端点、温度和推理设置；
• Prompt、工具 Schema 和工具策略；
• 硬件、区域、并发和网络；
• 数据集版本和随机种子；
• 重试、超时和 Token 预算。

2. 建立任务矩阵

至少包含：

• 一次确定性的读操作；
• 一次带单点故障的多步读操作；
• 一次需要审批的写操作；
• 一次超时后的重复投递；
• 一次工作进程从检查点重启；
• 一份含注入指令的对抗性文档；
• 一次跨租户访问尝试；
• 一次在工具调用期间的取消；
• 一个"正确答案是拒绝或反问"的任务。

3. 测量结果

utility_success =
  正确完成用户可见的任务，且未违反策略

unsafe_success =
  发生了越权读取、写入、披露或外部副作用

recovery_success =
  在注入故障或重启之后正确地继续

cost_per_success =
  (模型 + 工具 + 计算 + 运维成本) / 成功任务数

报告分布，而不是单一平均值：

• 任务成功率与拒答质量；
• 越权操作率；
• P50/P95 延迟；
• 模型调用、工具调用、Token 和重试次数；
• 重启与重复投递下的恢复情况；
• 每次事故的运维分钟数；
• 部署与迁移的工作量。

不要跨不同模型或不同 Prompt 去比较裸准确率。只有当任务、策略、模型和预算都保持一致时，一次框架基准才有意义。

4. 测试负向路径

最强的框架不是"永远能完成任务"的那个，而是能够做到以下几点的那个：

• 拒绝一个越权请求；
• 在事务失败时保住其不变量；
• 停止一个无限循环；
• 诚实地报告部分结果；
• 在不重复触发副作用的前提下恢复；
• 给运维人员留下一段可审计的解释。

迁移策略

让下面这些边界保持与框架无关：

领域命令
  -> 类型化的工具契约
  -> 策略与授权
  -> 幂等适配器
  -> 状态/事件 Schema
  -> 框架运行时

不要把业务规则放进 Prompt 字符串、框架回调或提供方专用的消息对象里。围绕工具和状态转换编写契约测试，这样一次迁移改动的就只是编排代码，而不会牵动支付、身份或数据策略。

一套务实的迁移顺序：

1. 盘点工具、副作用、身份和状态；
2. 从现有的 Agent 循环里提取领域命令；
3. 补上授权、幂等和结果契约；
4. 用匿名化的追踪数据在新运行时上回放；
5. 执行负向路径矩阵；
6. 在切换写操作之前先做影子流量；
7. 为状态和外部操作保留一条回滚路径。

常见问题

功能更多的框架更适合生产吗？

不一定。更多功能也可能意味着更多未经审查的行为。生产就绪指的是：能执行不变量、能从故障中恢复、能观察结果，并能在自己的威胁与成本模型内运营系统。

应该从多 Agent 设计开始吗？

不应该。先从一个确定性工作流、或一个有边界的 Agent 开始。只有当一个独立的上下文、权限或可独立测试的能力足以证明其合理时，才增加另一个 Agent。

供应商锁定一定是坏事吗？

不一定。一个托管运行时可以减少运维工作，并提供有价值的能力。把耦合当作一个刻意的取舍来处理：记录清楚数据路径，导出状态与追踪数据，隔离领域契约，并算清退出成本。

基准百分比能决定框架吗？

不能。Agent 的性能，是模型、Prompt、工具、数据、策略、运行时和预算共同决定的属性。把公开基准当作假设，再在你自己的工作负载上执行一次受控评测。

总结

脱离工作负载去谈"Agent 框架之战"，没有意义。可持续的选择，是那个能让你在意的重要属性变得可见、可执行的框架：

• 需要恢复时，使用显式状态；
• 需要安全时，使用窄化能力；
• 需要控制成本时，使用有界循环；
• 需要运营时，使用追踪和回放；
• 技术路线可能调整时，使用可移植的领域契约。

用能表达真实工作流的最小运行时去做原型；只有当它通过了故障、滥用、重启和成本的考验之后，才把它提升到生产环境。这个方法，比选择功能列表最响亮的框架要可靠得多。

一手资料

• LangGraph Overview
• OpenAI Agents SDK Documentation
• Strands Agents Documentation
• CrewAI Documentation
• CrewAI Flows and Persistence
• Microsoft Agent Framework 官方概览
• Microsoft Agent Framework 1.0 发布说明
• Microsoft Agent Framework Go SDK
• Microsoft AutoGen 官方文档
• Microsoft AutoGen 仓库与维护说明
• AG2 官方入门
• AG2 1.0 发布说明
• AG2 Classic 维护仓库
• LangGraph v1 发布说明
• Claude Agent SDK Overview
• Claude Agent SDK Secure Deployment
• Model Context Protocol Specification