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

到了 2026 年，再把 Agent 问题只理解成“哪个模型更强”已经不够了。真正拉开差距的，越来越不是前台交互，而是后台平台层：状态怎么存，任务怎么断点续跑，失败怎么回滚，人工怎么插手，预算怎么追踪，工具怎么通过标准协议接进来。这些能力不会直接让 demo 更惊艳，却决定系统能不能连续工作几小时、几天，甚至跨团队运行。

所以如果要判断谁更可能占住长期生态位，平台层比系统层和工具层更值得深看。系统层更容易先拿入口，工具层更容易先拿社区声量，但平台层一旦成为组织默认的 runtime 和 workflow 底座，就会像数据库、中间件、CI 编排层一样形成很高的迁移成本。这也是为什么我更愿意把这场竞争看成基础设施争夺，而不是单纯的 Agent 框架 PK。

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

如果把平台层的主流玩家都拉进来，名单会很长：LangGraph、Microsoft Agent Framework、OpenAI Agents SDK、AWS Strands、Temporal 相关方案、Inngest、Restate、DBOS，甚至还可以继续把 LlamaIndex workflow、CrewAI enterprise runtime 一类东西往里放。但如果只选“今天真正有代表性、同时具备官方背书、明确产品化方向和现实生态影响力”的平台层玩家，我会先锁定四个：LangGraph、Microsoft Agent Framework、OpenAI Agents SDK、AWS Strands Agents。

它们刚好代表了四条很不一样的路线。LangGraph 代表开放 agent runtime 路线；Microsoft Agent Framework 代表企业 workflow 与大组织工程路线；OpenAI Agents SDK 代表模型平台原生 SDK 路线；AWS Strands Agents 代表云厂商把 agent runtime 向自身平台能力吸附的路线。它们不是所有玩家，但足够构成一个有解释力的横截面。

Text 四家平台层玩家的简版定位 
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 形成完整套件。

这段官方表述的重要性不在宣传口径，而在于它几乎完整命中了平台层真正该做的事：它不把自己说成聊天框，不把自己说成 prompt helper，而是把 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 函数存在”。

第二家：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 两条线合流后的组织能力。
  • 它的不可替代性在微软生态内会非常高，在微软生态外则取决于开发体验与开放程度。

第三家：OpenAI Agents SDK，后劲很大，但今天更像生态连接器而不是完整 runtime

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 并不是一个只有“调用 OpenAI 模型更方便一点”的工具，而是有明确平台化野心：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”，而不是先从 workflow engine 出发。
  • 如果 OpenAI 继续把 SDK、Codex app、automations、MCP 与 durable integrations 打通，它的平台地位会继续快速上升。

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

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

如果只看单个项目，很容易陷入各家宣传口径；但一旦把它们拉到同一张表里，差异就很明显了。LangGraph 最像通用开放 runtime；Microsoft Agent Framework 最像企业 workflow 平台；OpenAI Agents SDK 最像模型平台原生 SDK；AWS Strands 最像云内 agent 平台。它们的生态位不是完全重叠，而是部分重叠、部分错位。

也正因为如此，我不太认同那种简单的“谁会赢下平台层”的问法。更现实的格局，是平台层内部先形成分区：开放通用平台层、企业组织平台层、模型原生平台层、云内平台层。谁最终能跨出自己的初始分区，才真正有机会成为更广义的基础设施。

Text 快照） 
玩家 | stars | forks | 核心路线 | 最强生态位 | 我给的主观判断
LangGraph | 26,309 | 4,547 | durable runtime / graph workflow | 开放通用平台层 | 当前最成熟
Microsoft Agent Framework | 7,888 | 1,309 | enterprise workflow / Azure integration | 企业平台层 | 企业最危险
OpenAI Agents SDK | 19,955 | 3,262 | model-native SDK / guardrails / tracing | 模型原生平台层 | 后劲最大
AWS Strands Agents | 5,302 | 710 | 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 心智；Microsoft Agent Framework 占住大组织 workflow 与企业集成；OpenAI Agents SDK 借助模型平台与 Codex 相关生态继续上探；AWS Strands 在 AWS 体系里建立稳定平台位。

如果只问谁最有可能占据“通用平台层头号生态位”，我现在仍然偏向 LangGraph。不是因为它品牌最大，而是因为它最像一个围绕 long-running、stateful、durable 这些平台问题长出来的系统，而不是后来补 platform features 的 SDK。如果只问谁最有可能占住“企业平台层”，我会更看微软。如果只问谁最有可能在接下来一年里完成位置跃迁，OpenAI Agents SDK 的概率很高。AWS Strands 则很可能成为一个区域性很强、但在自己的区域里非常稳的平台玩家。

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

最有用的地方，不是替你决定投谁，而是让你别在错误的层面重复造轮子。如果你想自己做一套 Agent 系统，平台层这四家的存在意味着你至少要先回答：你要做的是一个新的 runtime，一个新的企业 workflow 平台，一个模型原生开发层，还是一个利用现有平台搭出来的工作系统。如果这个问题不先想清楚，就很容易把别人已经在做且很难撼动的部分重做一遍，却忽略真正的缺口。

所以这篇文章真正想留下的不是一个排行榜，而是一种判断方式：看平台层，不要先问“谁最火”，而要先问“谁在解决哪个最难迁移的问题”。平台层的价值从来不在表面交互，而在于一旦进了组织底层，就会变成别人很难替换掉的那一层。这才是生态位的真正含义。

最后压缩成九条结论

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

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