为什么平台层才是真正决定长任务上限的那一层

到了 2026 年，再把 Agent 竞争理解成“哪个模型更强”，已经不够了。真正决定系统能不能连续跑上几小时、几天，甚至跨团队运作的，往往是后台平台层：状态怎么存，任务怎么断点续跑，失败怎么回滚，人工怎么插手，预算怎么约束，工具如何接入统一协议。

这些能力不会让 demo 更像魔术，却会决定系统能不能真正进组织。系统层更容易先拿入口，工具层更容易先拿社区声量，平台层一旦占住 runtime 和 workflow 底座，迁移成本就会迅速抬高。所以这场竞争更像基础设施争夺，不该被理解成又一轮 Agent 框架排行。

今天最值得看的四个主要玩家，以及我为什么只挑这四个

如果把候选名单完全摊开，平台层玩家远不止四家。Temporal、Inngest、Restate、DBOS、LlamaIndex workflow，甚至一些企业运行时方案，都能被放进同一张大表里。但这篇文章不打算做百科全书式罗列，我更关心的是哪几条路线已经足够成形，能把平台层的主要分叉照出来。

基于这个标准，我更愿意先看四个玩家：LangGraph、Microsoft Agent Framework、OpenAI Agents SDK、AWS Strands Agents。它们分别代表开放 runtime、企业 workflow、模型平台原生 SDK，以及云厂商把 agent runtime 吸附进自己平台能力的路线。四家的生态位并不完全重叠，也正因为这样，比较才更有意义。

四家平台层玩家的简版定位，可以先这样记：

  • LangGraph：开放 runtime、graph workflow、durable execution。
  • Microsoft Agent Framework：企业 workflow、type-safe orchestration、Azure 与 M365 整合。
  • OpenAI Agents SDK：模型平台原生 SDK、handoffs、guardrails、tracing、sessions。
  • AWS Strands Agents：model-first SDK、MCP、AWS 服务整合、云内平台路线。

第一家：LangGraph，为什么它现在最像开放生态里的平台层头号选手

先看事实。LangGraph 官方 overview 直接把自己定义成一个聚焦 underlying capabilities 的 orchestration framework，重点能力包括 durable execution、human-in-the-loop、comprehensive memory、production-ready deployment。LangChain 官方还明确写到：LangGraph 是用于构建、管理和部署 long-running、stateful agents 的低层 orchestration framework 和 runtime，并且它可以 standalone 使用，但也能与 LangSmith、LangChain、Studio 形成完整套件。

这段官方表述的重要性，不在宣传口径，而在于它几乎完整命中了平台层真正该做的事：把 stateful、long-running、durable 这些 platform primitives 放在中心位置。LangGraph 的判断很早就对准了问题核心，这在平台层里并不常见。

再看数据。截至 2026 年 3 月 13 日，我用 GitHub API 拉取到的仓库快照里，LangGraph 大约有 26,309 stars、4,547 forks、432 个 open issues，仓库创建于 2023 年 8 月 9 日，最近更新时间就在 2026 年 3 月 13 日。这说明它既有热度，也仍处于非常活跃的演进期。它的社区体量在平台层里明显领先，这件事对生态位很重要，因为平台层除了企业销售，还需要开发者愿意围绕它写模板、案例和适配层。

团队与出身也很关键。LangGraph 背后是 LangChain Inc，而 LangChain 本身已经在 LLM 框架时代率先占住过开发者心智。很多人对 LangChain 过去的评价褒贬不一，但不能否认的一点是：LangChain 团队在“把一类新范式做成一个开发生态”这件事上，执行力非常强。LangGraph 实际上是在 LangChain 第一阶段经验之上，更准确地对准了 agent runtime 问题。

  • 技术领先性主要体现在 durable execution、stateful memory、HITL 和部署调试闭环都比较完整。
  • 社区热度在平台层里领先，而且这种领先仍在持续演进。
  • 它最强的平台气质，来自 runtime 身份本身，不只是若干 helper 函数。

如果用更直白的话概括 LangGraph：

  • 它最强的地方，是 durable execution 定位很准，stateful workflow 抽象也足够成熟。
  • 它的短板，是偏底层，学习曲线不低，而且与 LangChain 生态绑定较深。
  • 它的机会，是继续长成开放生态里的默认 agent runtime，并向企业交付和团队协作平台上探。
  • 它面对的压力，主要来自云厂商和模型厂商把部分 durability 能力内建，以及更轻量的 SDK 路线分走早期开发者。

第二家：Microsoft Agent Framework，最危险的企业平台层玩家

Microsoft Agent Framework 的强势之处，不在于它今天 stars 最多，而在于它的官方定位非常清楚，并且几乎天生站在企业平台层的语境里。Microsoft Learn overview 页面明确写到：Agent Framework 提供两大类能力，Agents 与 Workflows。Workflows 被定义成 graph-based workflows，支持 type-safe routing、checkpointing 和 human-in-the-loop。更关键的是，官方还直接写明：Agent Framework 是 AutoGen 与 Semantic Kernel 的 direct successor，由同一批团队打造，是下一代统一基础。

这段表述的含义很重。它意味着微软并非在试一个新项目，同时正在把 AutoGen 的 agent abstraction 和 Semantic Kernel 的企业特性合并成一条新的平台层路线。官方文档反复强调的关键词包括 session-based state management、type safety、middleware、telemetry、workflow orchestration、long-running scenarios。这些词放在一起，已经很接近企业会采购、会标准化、会长期依赖的平台层能力。

再看数据。根据 2026 年 3 月 13 日的 GitHub API 快照，microsoft/agent-framework 大约有 7,888 stars、1,309 forks、723 个 open issues，仓库创建于 2025 年 4 月 28 日。单看 stars 它不算最热，但考虑到它非常新，而且仍处在 public preview 阶段，这个速度已经不慢。更重要的是，它背后不是一个独立开源项目在试图长成平台；微软主动在为 Azure、M365、Foundry、MCP 与多语言企业开发者提供新的 agent/workflow 统一底层。

从团队维度看，它几乎是四家里“组织能力”最强的一家。AutoGen 与 Semantic Kernel 团队本来就已经分别掌握了多 agent 抽象和企业集成经验，现在把这两条线合在一起，再叠加微软在企业销售、云、开发工具链和办公软件上的入口，意味着它具备一种很少有开源框架能拥有的优势：它不需要先说服组织定义这个问题，组织本身已经在微软体系里。

  • 技术优势集中在 workflow、checkpoint、type safety、middleware、telemetry 与 Azure/M365 整合。
  • 团队优势来自 AutoGen 与 Semantic Kernel 两条线合流后的组织能力。
  • 它在微软生态内的不可替代性会非常高，在微软生态外则取决于开发体验与开放程度。

如果把微软这条路线说得更直白一些：

  • 它最强的地方，是企业 workflow 与 state management 能力成熟，Python 和 .NET 双栈也更容易进大组织。
  • 它的短板，是当前仍处于 preview 阶段，社区自发生长速度也还不如 LangGraph。
  • 它的机会，是把 workflow、telemetry、approval、MCP 做成 Azure 体系内的默认配置。
  • 它的风险，是一旦开发体验偏重，独立开发者会更愿意流向轻量开放框架；绑定 Azure 太深，也会拖累跨云吸引力。

第三家：OpenAI Agents SDK，后劲很大，今天更像生态连接器

OpenAI Agents SDK 的独特之处，在于它一开始就不只是一个 narrow wrapper。GitHub 官方 README 把它定义成 lightweight yet powerful framework for multi-agent workflows，并且明确写到它是 provider-agnostic，支持 OpenAI Responses 和 Chat Completions，也支持 100+ other LLMs。官方列出的核心概念包括 agents、handoffs、guardrails、sessions、tracing；长任务方面，官方又给出 Temporal integration 与 human-in-the-loop 的耐久执行说明。

这套能力组合很有意思。它说明 OpenAI Agents SDK 的目标不只在让模型调用更顺手，也已经朝平台化迈了一步：sessions 处理跨 run 记忆，guardrails 处理输入输出校验，tracing 处理可观察性，handoffs 处理 agent 之间的控制转移，Temporal/Restate/DBOS integrations 再把 durable execution 延伸到外部基础设施层。这是一种很典型的“生态连接器”打法。

数据上，2026 年 3 月 13 日 GitHub API 快照里，openai/openai-agents-python 大约有 19,955 stars、3,262 forks、60 个 open issues，创建于 2025 年 3 月 11 日。单看增长速度和 issue 控制，它表现非常强。相比 LangGraph，它的优势不在 runtime 身份更清晰，而在于它站在 OpenAI 自家平台之上，和 Responses API、Codex app、trace viewer、MCP 的距离都更近。这会给它带来很强的战略后劲。

也正因为这个原因，我暂时不会把它排到第一。到今天为止，它更像一个战略位置极佳的 agent SDK，还没有完全长成被广泛承认的 durable workflow runtime。它的平台潜力极强，但平台完成度还没有收敛到 LangGraph 那种程度。换句话说，它离未来很近，离今天的独立平台层头名还有一点距离。

  • 优势在于模型平台原生性、轻量 abstractions、guardrails、sessions、tracing 齐全，以及与外部 durability 系统的连接能力。
  • 技术路线更像把 Agent 所需能力拼成统一 SDK，再向平台层延展。
  • 如果 OpenAI 继续把 SDK、Codex app、automations、MCP 与 durable integrations 打通，它的平台地位会继续快速上升。

如果把 OpenAI 这条路线说得更清楚一些：

  • 它最强的地方，是 provider-agnostic、handoffs、guardrails、sessions、tracing 这组能力已经很完整，而且离 OpenAI 平台和 Codex 生态非常近。
  • 它的短板，是更像 SDK，durable execution 也更多依赖外部 integration。
  • 它的机会，是把 Codex app、automations、tracing、MCP 连成一个强闭环，长成模型平台原生的默认开发层。
  • 它面对的压力，是容易被看作 OpenAI 专用开发框架，同时也可能在 runtime 深度上被更专注的平台层继续拉开。

第四家：AWS Strands Agents，最像云内稳步长大的平台层选手

AWS Strands Agents 的路线和前面三家都不完全一样。AWS 官方 Prescriptive Guidance 页面把它定义成 an open-source SDK，最初由 AWS 发布，并强调它是 model-first approach，同时支持 MCP integration、multi-agent collaboration patterns、AWS service integration、foundation model selection 和 multimodal capabilities。GitHub 官方 README 进一步强调它支持 Amazon Bedrock、Anthropic、Gemini、LiteLLM、Ollama、OpenAI、Writer 等多种 provider，同时原生带 Built-in MCP。

这说明 Strands 并非一个简单的 Bedrock SDK 衍生物，它代表的是“云厂商试图定义 agent SDK 与工具协议入口”的路线。它的最大优势，不在社区最热，更在天然可以与 Bedrock、Lambda、Step Functions、AgentCore、样例库、AWS 行业解决方案一起被打包使用。AWS 很擅长做这种事：单看一个项目，未必最热；一旦放进它的云产品矩阵里，生存能力就会强得多。

2026 年 3 月 13 日 GitHub API 快照中，strands-agents/sdk-python 大约有 5,302 stars、710 forks、425 个 open issues，创建于 2025 年 5 月 14 日。对比 LangGraph 或 OpenAI Agents SDK，这个社区规模还明显偏小；但如果你把它放到 AWS 语境里去看，它并不需要先赢下所有独立开发者，它只需要先在 AWS 客户体系内成为 agent runtime 的顺手默认选项。

所以我对 Strands 的判断是：它未必会成为全市场最强的平台层候选，但很可能会成为 AWS 世界里的稳定平台位。尤其一旦 AWS 把 AgentCore、MCP、Bedrock 工作流与行业解决方案更紧密地打包在一起，Strands 的不可替代性就会更多来自云生态，而不只来自单个 repo 的热度。

  • AWS Strands 的核心，在于能否和 AWS 更大的平台能力一起被卖出去、被默认采用。
  • MCP 原生支持和 provider 覆盖宽度，是它区别于传统云内 SDK 的重要点。
  • 它在 AWS 内生态位很稳，但在外部通用平台心智上还明显落后于 LangGraph 和 OpenAI Agents SDK。

如果把 Strands 的位置说得更直白一些：

  • 它最强的地方，是 AWS 官方推动、云内整合位清晰，model-first、MCP 和多 provider 支持也都到位。
  • 它的短板，是社区热度和外部默认心智还不够强，显式 workflow 控制感也弱于 LangGraph 和微软。
  • 它的机会，是长成 AWS 客户默认的 agent SDK 或 runtime 路线，并借助 MCP 与云内工具体系放大粘性。
  • 它面对的压力，是很容易被视作 AWS 专属框架，在开放社区里也会被更成熟的平台层压住。

把四家放在一张表里看，很多差异会立刻清楚

单看一家，最容易被它自己的叙事牵着走；把四家并排看，很多差异就会立刻收口。LangGraph 最像开放通用 runtime，微软最像企业 workflow 平台，OpenAI 最像模型平台原生 SDK，AWS 则更像云内 agent 平台。它们的竞争关系并不完全重合，更像先各守一块，再慢慢试探边界。

因此，我不太认同“平台层最后只会剩一家”的说法。更可能发生的，是平台层先分区稳定，再看谁能跨出自己的初始分区。真正值得追的，也不该只看谁声量最大，而要看谁能从自己的优势地带出发，继续补齐别的关键能力。

如果把四家放在同一张心智地图里：

  • LangGraph：26,309 stars，4,547 forks，核心路线是 durable runtime 与 graph workflow。我会把它看作当前最成熟的开放通用平台层。
  • Microsoft Agent Framework：7,888 stars，1,309 forks，核心路线是 enterprise workflow 与 Azure integration。我会把它看作企业平台层里最危险的选手。
  • OpenAI Agents SDK：19,955 stars，3,262 forks，核心路线是 model-native SDK、guardrails、tracing。我会把它看作后劲最大的模型平台原生路线。
  • AWS Strands Agents：5,302 stars，710 forks，核心路线是 model-first SDK、MCP、AWS integration。我会把它看作 AWS 体系内最稳的平台位。

从团队、技术、热度、生态、不可替代性五个角度，谁最强

如果按团队与组织能力来看，我会把微软放得很高，因为它直接承接了 AutoGen 与 Semantic Kernel 两条线的积累，并且有 Azure、M365、Foundry 这些现成入口。按技术完成度与问题命中度来看，我会先给 LangGraph，因为它最早、也最持续地把 durable execution、stateful workflow、HITL、deployment 这些平台能力做成显式产品。按战略后劲看，OpenAI Agents SDK 很值得重视，因为它离 OpenAI 自己越来越完整的 agent product stack 太近了。按云内粘性看，AWS Strands 最有机会在 AWS 用户体系里稳稳占住一块。

但如果一定要把这些维度压缩成一句话，那就是：LangGraph 现在最成熟，Microsoft 最有企业组织优势，OpenAI 最有战略后劲，AWS 最有云内落地势能。真正的胜负，往往不取决于单维度最强，而在于谁最先把两个维度同时做厚。例如一个平台既有 runtime 深度，又有入口整合；或者既有企业 workflow，又有开发者社区热度。

  • 团队与组织能力：微软最强。
  • 技术问题命中度：LangGraph 最强。
  • 模型平台战略后劲：OpenAI 最强。
  • 云内生态粘性：AWS 最强。

我的最终判断：平台层不会只剩一家，但头部格局已经开始清晰

如果你问平台层最后会不会收敛成单一胜者，我现在的判断仍然是否定。平台层太贴近组织结构、云生态和开发者习惯了，它更像数据库、云或工作流引擎，不像天然通吃的消费产品。更现实的走向，是头部格局先逐渐清晰：LangGraph 守住开放 runtime 心智，微软守住企业 workflow，OpenAI 借模型平台与 Codex 生态继续上探，AWS 在自家云体系里把位置坐稳。

如果只问“通用平台层头号生态位”最像谁，我现在仍然偏向 LangGraph。原因很简单，它确实围绕 long-running、stateful、durable 这些硬问题长出来。如果只问企业平台层，我会更看微软；如果只问未来一年的位置跃迁，OpenAI Agents SDK 的后劲最值得继续跟；AWS Strands 则很可能长期保持一种区域性很强、但在自己区域里极稳的平台地位。

对准备自己下场的人来说，这篇分析真正有用的地方在哪里

这篇分析真正有用的地方，不在替你选边站，而在帮你避开最昂贵的误判。如果你自己也想下场做 Agent 系统，就得先想清楚，你要补的是新的 runtime、新的企业 workflow、新的模型原生开发层，还是基于现有平台长出的工作系统。这个问题不先答清楚，最常见的结果就是在别人已经占住的位置上重做一遍，却漏掉真正还没人补好的缺口。

所以看平台层，最好别先问“谁最火”，而要先问“谁在解决最难迁移的哪一层问题”。平台层的价值从来不在表面交互，而在于一旦进入组织底层，就会变成最难被替换掉的那部分。

最后压缩成九条结论

如果把整篇平台层分析压缩成最后的结论，我会留下下面这九条。

  • 平台层决定的是 Agent 能不能长期、稳定、可治理地工作。
  • LangGraph 目前最像开放生态里的平台层头号玩家。
  • Microsoft Agent Framework 是企业平台层里最危险的竞争者。
  • OpenAI Agents SDK 现在更像强力 SDK，但后劲极大。
  • AWS Strands 很可能在 AWS 体系内形成稳固生态位。
  • GitHub stars 只能看社区热度，不能直接等同于最终生态位。
  • 平台层的真正护城河来自状态、恢复、审计、协议和工作流，不在单次模型表现。
  • 未来平台层更可能是多强并存，不会很快收敛成一家通吃。
  • 自己下场之前，先判断自己是在补平台缺口，还是在重复造别人已经有强生态位的那一层。

更新附注

  • 版本：v1.2

更新日期：2026-03-31 更新原因：收紧四家路线对比的转折句，减少重复的对照骨架，让整篇更像分析文章，而不再像赛道备忘录。

  • 版本：v1.1

更新日期：2026-03-31 更新原因：重写开头、四家玩家的选择逻辑、对照判断、最终结论与收束段，减少“赛道报告”腔调，让平台层比较更像一篇有主线的分析长文。