2026 年上半年，TypeScript 团队要做一个 AI Agent，绕不开两个名字：Mastra 和 LangGraph.js。
打开各自首页，你会看到几乎一样的卖点——Agent、工作流编排、记忆、人类介入、可观测性、崩溃恢复。功能清单高度重叠，于是很多团队的选型退化成了数 GitHub star、看谁文档好看。
但这两个框架其实长在两套不同的工程哲学上。功能清单会趋同，工程哲学不会。 能决定你三个月后是顺手还是想推倒重来的，是哲学差异，跟功能多少关系不大。
下面这套坐标，我把它拆成三条断层线。每条线都有明确的一边属于 Mastra、一边属于 LangGraph，你站在哪边，答案就出来了。
先快速校准两个框架的坐标
LangGraph 来自 LangChain 团队，2025 年底随 LangChain 一起迈进 1.0，承诺到 2.0 之前不再有破坏性变更。
它在 Uber、LinkedIn、Klarna 这类公司的生产环境里跑了一年多，是这个赛道里少有的把稳定写进版本号的框架。它的 JS 版本是从 Python 主线移植下来的，官方文档也写明：TS 版通常比 Python 版晚 4 到 8 周。
Mastra 出自 Gatsby 原班团队，2026 年 1 月发布 1.0，到 6 月核心包已经迭代到 1.42，主仓库 25k star，npm 周下载量超过 30 万。它从第一行代码就是 TypeScript，主打 serverless 优先，生产用户里有 Replit、Brex。
这里要先泼一盆冷水：别拿 star 数做选型依据。 Mastra 是单仓库，25k 是全部；LangGraph 的 JS 仓库只有约 3k star，但它的 Python 主仓库体量远大于此，整个 LangChain 生态的引力也不在一个量级。跨语言比热度，比出来的是错觉。
断层线一：语言原生 vs 跨语言移植
这是最容易被低估、却最影响日常手感的一条。
Mastra 的 API 是按 TypeScript 的脾气设计的。工作流是 .then()、.branch()、.parallel() 这样的链式调用，类型推断顺着写下来就对了，不需要你脑子里先有一张图。
LangGraph.js 是另一种体验。它把 Python 主线的范式整套搬了过来——可变状态对象、用字符串返回值决定条件边、显式的 builder 编译步骤。这些写法在 Python 里天经地义，落到 Next.js 代码库里就有种说不出的别扭，像是从另一门语言进口来的零件。核心能力其实早已追平 Python，滞后主要落在边缘新特性上，但当你想用 Python 社区昨天讨论的新东西时，往往还得等一等。
有个被广泛引用的对照（来自一位开发者的迁移记录，单一样本，看个量级就好）：同一个六工具、带分支的项目，用 LangGraph.js 写花了 41 小时，换成 Mastra 是 18 小时。数字别当真理，但方向是可信的——对纯 TS 团队，语言原生省下的是每天的认知摩擦，不是用来炫技的。
这条线的判据很干脆：你的团队是清一色 TypeScript，还是 Python 和 TS 两头都要维护？如果后端真理之源在 Python，那么用 LangGraph 让两边共享同一套心智模型，反而比追求 TS 手感更划算。
断层线二：缩到零的 serverless vs 常驻的持久化
这条线藏在部署架构里，却往往是事后最难掉头的。
Mastra 是 serverless 优先的设计，原生支持 Vercel、Cloudflare Workers、Netlify。没有请求时，它能缩到零，不烧钱。这套取向背后是一个判断：大部分 AI 应用的流量是脉冲式的，按需付费比常驻划算。
LangGraph 的取向相反。它的可靠性建立在每执行完一个节点就落一次 checkpoint 上——崩溃自动从最后一个检查点恢复，还能时间旅行式地回放任意历史状态调试。这套机制极其适合长跑的、多天的、必须不丢状态的工作流。代价是，它按设计就跑不了缩到零——官方明确 LangGraph Platform 不兼容 Vercel 和 Cloudflare Workers。 它要的是一个常驻、有持久化后端的运行时。
所以这条线该问的不是谁能持久化（两家都能接 Postgres），而是你的负载形态：是脉冲式、希望闲时不花钱的轻量 Agent，还是需要崩溃零丢失、跑几天审批流的重型工作流？ 前者站 Mastra 这边，后者站 LangGraph 那边。值得注意的是，Mastra 目前没有 LangGraph 那种原生的时间旅行回放，这在调试复杂崩溃时是实打实的缺口。
断层线三：完整工具箱 vs 自由原语
这是最深的一条，也是工程哲学的分水岭。
LangGraph 给你的是一套强大的原语：节点、边、状态、检查点。它几乎不替你做决定——记忆怎么存、Agent 角色怎么分、token 预算怎么管，都要你自己用图显式建模出来。它的自由度就是它的学习曲线。 文档分散在好几个站点，新人上手陡峭，但一旦你需要那种别人封装不出来的精细控制，这套底层原语给得起。
Mastra 给你的是一套有主见的完整工具箱：记忆是一等模块，evals 内置，本地 playground、Swagger UI、OpenAPI 文档开箱即用，还有 Agent Networks 这种由 LLM 动态路由协调多个 Agent 的上层抽象。它的记忆系统（Observational Memory）会在原始消息累积到约 3 万 token 时，把旧消息压成带日期的观察笔记、丢掉原文，再叠一层回收机制控制总量，整个过程对开发者基本透明。那些难的决定，框架已经替你做完了，代价是你得接受它做的选择。 比如非 LLM 的纯分支逻辑写起来偏笨重，部分鉴权包还挂着实验性前缀，自动压缩消耗的 token 也不计入 Agent 的用量统计。
这条线考验的是你的团队气质：你想要一个开箱即用、把你推上生产的脚手架，还是想要一把能削到底层、自己拼装一切的瑞士军刀？
把三条线叠起来看
三条断层线其实指向同一个判断框架——别问哪个框架更好，问自己站在每条线的哪一边：
- • 语言：纯 TS 团队偏 Mastra；Python/TS 双修、后端真理在 Python 偏 LangGraph。
- • 运行时：脉冲流量、要缩到零偏 Mastra；长跑、崩溃零丢失、要时间旅行偏 LangGraph。
- • 控制权：要开箱即用的完整工具箱偏 Mastra；要底层原语和极致控制、且吃得下学习曲线偏 LangGraph。
三条线如果齐刷刷指向一边，选型没有悬念。如果分裂——比如你是纯 TS 团队（指向 Mastra），但要跑多天不能丢状态的审批流（指向 LangGraph）——那分裂点本身就是你最该先想清楚的工程约束，它比框架名字重要得多。
还有第三种答案值得说出来：如果你的流程状态少于十个、LLM 调用范围明确，两个框架可能都是过度设计，一个朴素的状态机就够了。 框架是用来驯服复杂度的，当复杂度还没长出来时，引入框架本身就是负债。
2026 年这个时点，LangGraph 用 1.0 和一长串大厂背书证明了它的成熟与稳定，Mastra 用迭代速度和 TS 原生体验证明了它的势头。它们服务的本来就不是同一批人——各自站在三条断层线的两端，接住被这些断层划到自己这边的团队。选型这件事，看清自己站在哪里，比看清框架强在哪里更要紧。
参考来源
- • Mastra 官方仓库（star / 版本）[1]
- • LangGraph.js 官方仓库[2]
- • LangChain & LangGraph 1.0 里程碑公告[3]
- • Mastra vs LangGraph vs Vercel AI SDK（Particula）[4]
- • AI Agent 框架横评（Speakeasy）[5]
- • 从 LangGraph 迁移到 Mastra 的实测记录（dev.to，单一样本）[6]
引用链接
[1] Mastra 官方仓库（star / 版本）: https://github.com/mastra-ai/mastra
[2] LangGraph.js 官方仓库: https://github.com/langchain-ai/langgraphjs
[3] LangChain & LangGraph 1.0 里程碑公告: https://www.langchain.com/blog/langchain-langgraph-1dot0
[4] Mastra vs LangGraph vs Vercel AI SDK（Particula）: https://particula.tech/blog/mastra-vs-langgraph-vs-vercel-ai-sdk-typescript-agents
[5] AI Agent 框架横评（Speakeasy）: https://www.speakeasy.com/blog/ai-agent-framework-comparison
[6] 从 LangGraph 迁移到 Mastra 的实测记录（dev.to，单一样本）: https://dev.to/jim_l_efc70c3a738e9f4baa7/i-switched-from-langgraph-to-mastra-for-my-typescript-agents-18-hours-vs-41-nah