自部署还是买平台：LangGraph 部署形态与成本账

TL;DR: 先纠正名词：社区说的「LangGraph Platform」在官方语境里已经演进为 Agent Server（运行时）和 LangSmith Deployment（托管产品），选型文章里还在用旧名词的多半内容也旧了。四种部署形态从轻到重：开源库自写 API（免费）、Agent Server 自托管（自带 PG/Redis）、LangSmith Cloud（按席位）、企业自管控面（Enterprise）。成本上最容易被低估的不是许可费，是自托管的运维清单。

开场：选型会上的两种声音

假设选型会开了两次还没结论。一边是后端负责人：「langgraph 就是个库，我们 FastAPI 包一层就上线了，为什么要为这个付钱？」另一边是平台组：「运行时、扩容、监控全是活，我们自建到一半的坑还少吗？」两边都有道理，吵不清的原因通常有两个：第一，名词没对齐，一方嘴里的 LangGraph 是 pip 里的库，另一方说的是整个平台产品，讨论的根本不是同一个东西；第二，两边都只算了显性账，一边只看到许可费，一边只看到「反正得自己运维」，没有人把两列成本摆到同一张纸上摊开。

这篇文章按这个顺序解决：先对名词，让讨论有共同语言；再过四种形态，说清每一种成立的前提；然后把显性、隐性两列成本都算上；最后给一条按顺序问的决策线。先声明立场：这篇不推荐任何具体形态，因为不知道你的合规约束、团队结构和业务量，给了就是瞎猜，给的是把这三件事问清楚之后的判断材料。读完全篇大概十五分钟，比再开两次会便宜。

部署选型在 agent 领域比传统 web 服务分量更重，原因在状态。无状态的 API 服务，迁移成本基本是零：换个地方跑，代码原样。agent 系统带着 checkpoint 数据（thread 的全部历史、快照、人审挂起状态），数据在哪、格式归谁管，直接决定你下一次迁移要付多少。所以这篇不只是回答「现在用哪个」，更是在回答「数据埋在哪个形态里」，后者比前者贵得多。

名词先对齐

选型前先统一语言，2025 到 2026 年这组名词换过一轮：

• LangGraph（开源库）：pip 装的那个，本系列所有文章讲的东西，免费 MIT。要点是它的形态：一个进程内的库，不是服务。你 import 它、编译图、在自己的进程里 invoke，它不监听端口，没有管理界面，不负责被谁调用。所有「部署」讨论的分歧，都从「把库当成了服务」或「把服务当成了库」开始。
• Agent Server：统一运行时，提供 assistants / threads / runs 这套 API，langgraph dev 本地起的就是它。它解决的问题是真实的：没有它，每个团队都要自己发明一套「线程怎么存、并发 run 怎么排队、流怎么推给前端」的 API，而且每家发明得都不一样。它让 Studio、前端 SDK 有了标准对接面，你的图变成一个有标准 HTTP 接口的服务。
• LangSmith Deployment：托管产品（旧名 LangGraph Platform），跑在 LangChain 管的云上或你的 VPC 里，运行时的运维责任在官方。

中文社区至今大量文章把三者混着叫，引用时先看作者说的到底是哪一层。名词错位的危害是实打实的：拿「LangGraph Platform 价格」去搜索，出来的是旧产品结构的报价；拿「LangGraph 部署」去问 AI 助手，混着库和服务的答案一半能用就不错了。收拢成一张表：

最后一行特意列出来：LangSmith 同时是观测评测平台和托管部署的品牌，两个语境都在用这个名字，聊价格时先问对方说的是哪块业务。鉴别旧内容还有个快捷办法：文中还在把「LangGraph Platform」当云服务讲的、代码里还在用 langgraph.prebuilt.create_react_agent 的，大概率是 1.0 之前的内容，迁移问题第 18 篇有清单，这篇只提醒一句：拿旧名词搜到的价格和形态对比，结论多半已经不成立。这套判断线本身不受改名影响：名词会继续演进，下次也许运行时又换了新品牌，但「数据面在哪、运维谁做、钱怎么算」这三个问题不会变，答案永远落在这张表的三列里。拿到任何新名词，先把它对号入座到表里的某一行，再开始比较，比抓着名词本身争论有用得多。

四种形态，各自成立的前提

形态一：开源库 + 自写 FastAPI。 langgraph 是普通库，编译出来的图在任意 web 框架里 invoke，Postgres 自己接：

@app.post("/runs")
async def create_run(req: RunRequest):
    config = {"configurable": {"thread_id": req.thread_id}}
    result = await app.ainvoke(req.inputs, config)
    return {"output": result}

免费、代码全在自己手里、没有额外 API 面。适合流程简单、请求基本一次进出、不需要线程级 API 和 Studio 的团队。鉴权也从简：内部工具网关一层基本认证，或者干脆只在内网可达，多租户隔离这类问题在这个形态里最好靠「根本没有多租户」来回答。缺点要数得具体，把「自己写」拆开看每项是什么量级：threads 的生命周期管理（谁创建、过期谁清理，状态机自己维护）；并发 run 的排队与互斥（同一个 thread 同时来两个请求怎么办，数据库锁还是应用锁）；流式输出的对接协议（SSE 还是 WebSocket，消息格式自定，前端自己解析）；客户端断线重连（连接断了，跑到一半的 run 怎么续，客户端从哪一步接着看）。这些在形态二里是现成的，在形态一里全是你的代码，每一项单看都不难，叠起来就是一个常驻的维护面。选它不丢人，但要带着这份清单选，而不是带着「不就是个库」的印象选。

形态一还有一个更轻的变体值得知道：连 web API 都不搭。内部低频任务（每周跑一次的报表 agent、人工触发的批处理），一个脚本加 cron 就是全部部署，连 FastAPI 都省了。部署形态的最小单位不是服务，是「能跑起来、坏了有人知道」，按这个标准裁，很多内部工具的形态一其实是形态零。

形态二：Agent Server 自托管。 官方 Docker 镜像跑在你的 K8s 里，自带 Postgres 和 Redis 依赖，你的图变成标准的 threads/runs API，Studio 可以直接连上来调试。这是「要生态但数据不出门」的主答案：前端 SDK、线程管理、并发控制、Studio 调试全部白得，数据面在自己机房。跑起来之后的图景值得建立一下：你的图注册成 assistant，前端每开一个对话就是建一个 thread，每次执行是一个 run，checkpoint 持久化在 Postgres，run 的调度和队列靠 Redis，第 03、13 篇讲的那些 checkpoint 运维知识在这个形态里全部用上，因为那张表真的在你自己的数据库里。注意许可：standalone 部署形态需要 LangSmith license，别以为带 Docker 就是免费自托管。运维义务也是自己的：镜像升级（跟着官方 release 走，升级前在预发跑第 15 篇的录制回放）、依赖的 PG 和 Redis、扩容、备份，一项都不少，清单在下一节展开。

形态三：LangSmith Deployment Cloud。 官方托管，不用管任何运维，控制台和 trace 无缝。前提是 LangSmith Plus 以上的席位，数据进 LangChain 的云。它的边界值得说清楚：你管代码、图定义和业务逻辑，官方管运行时、扩容、备份和可用性。团队没有平台组、或者平台组已经在忙别的事，这个形态把钱花在了最缺的东西上：人力。Studio 连着真实部署调试的体验也值得一提：开发期在本地连 Studio 看图，上线后同一个界面连云端 thread 排查，第 14 篇讲的图视图和时间旅行在线上也是同一套操作，观测经验不用分开学两遍。它和第 14 篇的观测选型还有一层联动：trace 全量接的话，用量账单跟着业务量走，第 14 篇建议的采样和分层策略在这里不只是观测纪律，也是成本纪律。什么信号说明该从这个形态挪走：月账单的增速持续高于业务增速，或者合规审查第一次敲碗要数据出境证明；什么信号说明该留下：团队规模小、故障工单几乎为零、工程师的时间花在业务上。账要两边一起算。真要挪走时，checkpoint 数据的去向提前规划：导出 thread 数据、对齐自托管库的 schema、灰度切流，是一套要排期的迁移工程，不是一次配置变更。

形态四：self-hosted control plane / hybrid。 控制面和数据面拆开：控制面（调度、API、管理）依然由官方产品提供，数据面跑在企业自己的 VPC，合规数据不出门。Enterprise 合同，有报价没公开价。它的典型买家画像很清楚：金融、医疗、政务这些把「数据驻留」写进监管要求的行业，架构评审会上第一条问题就是「数据物理上在哪」，形态三过不了这一关，形态二又满足不了他们对托管可用性的期待，形态四就是为这个缝隙准备的。小团队不用看，它的存在是为「数据主权是硬约束、同时要托管体验」的组织准备的。

成本账，把两列都算上

先把成本观摆正：这个选型的本质不是「买不买软件」，是在三种货币之间做交换。现金（订阅费、license）、人时（运维、升级、值守）、数据主权（数据落在谁的辖区）。四种形态是这三种货币的不同组合，没有一种在三项上全占便宜，算清你手里哪种货币最充裕，选型就有了主轴：大公司人时贵，倾向现金换人时；初创现金紧，倾向人时换现金；金融合规数据主权一票否决，另两种货币让路。

显性成本（2026 年 9 月官方定价页口径，随时会变，决策前自己核对）：LangSmith 按席位订阅（开发者席约 39 美元/月/席），trace 用量另计，百万条 trace 量级在数千美元/月；Deployment Cloud 包含在相应套餐里；自托管的 standalone 形态要 license。这套价格结构有个特点：席位费封顶、用量费不封顶。做个量级感：十个开发者席一年就是四千多美元，还没算 trace 用量；trace 用量随业务量涨，业务翻倍它也翻倍，做预算时按业务增长曲线外推，不要按今天的量定。trace 账单还有一个和第 14 篇直接联动的杠杆：全量收 trace 还是采样收，账单差一个量级，观测策略在这里同时是财务策略。

隐性成本（自托管形态的真实大头），逐项列出来：

• Postgres 和 Redis 的运维：备份策略、恢复演练、扩容、监控告警，每项都要有人负责，不是「装的时候配一次」。
• checkpoint 表的清理策略：第 13 篇整篇在讲表膨胀事故，那张表在业务量上来之后一定会膨胀，清理是运维日程上的常驻项。膨胀不只是磁盘问题，查询变慢会拖累每一次快照写入，直接反映成图执行的延迟，这是运维问题和性能问题在同一张表上会师的地方。
• 版本升级：框架升级要跑回归，checkpoint 库的 schema 变更要演练，第 18 篇的迁移清单就是升级成本的实物。
• 故障值守：形态二没有官方 SLA，凌晨两点图挂了，值班的还是自己人。
• 安全补丁：依赖镜像和中间件的 CVE 跟进，又是一条常驻人力。
• 可观测自建：不用商业 trace 的自托管形态，监控栈（指标、日志、告警）本身就是第 14 篇那套自建方案，它也是要人养的活系统。

形态二省下的许可费，通常以半个工程师的方式花出去。这个「半个工程师」不要按名义工资折算：一个能扛 Postgres 运维和框架升级的工程师，薪酬之外还有招聘成本、管理成本和「他在忙运维所以业务需求在排队」的机会成本。还有一笔账别漏：形态一和形态二的「免费」指的是软件免费，基础设施一点都不少花钱。Postgres、Redis、K8s 节点、备份存储、出向流量，云厂商的账单在两种形态里都在涨，自托管从来不等于零成本，只是把付给软件商的钱换成付给云厂商和自己人的钱。云端形态反过来：钱花在明处，运维归零，但 trace 和运行数据都在别人云上，第 16 篇说的数据审查结论会直接决定这条路能不能走。

一个务实的算例口径：5 人团队、日活千级的应用，形态一 + 自建监控的现金成本最低；加要 Studio 调试体验，形态二的 license + 运维成本往往超过直接上形态三的席位费，除非合规硬性要求。把「除非」读清楚：合规是唯一经常推翻经济性结论的因素，别的因素都会在钱面前让步。四种形态的成本结构收拢成一张表：

表的读法和第 01 篇一样：每一行的成立条件是左边那句，预算结构和数据约束一变，行与行之间就要重新比。

这张表还有一个用途常被忽略：它决定你的产品怎么定价。agent 应用的现金大头（token、trace、运行时）随用户行为走，如果这些成本拆不到 thread 级、租户级，定价就只能拍脑袋：免费额度给到多少会亏、企业客户报价该是成本几倍、哪个客户在亏钱，全都没有数据支撑。做法不复杂，但要在选型时想到：给每个 thread 打上租户标识，放进 metadata 或 state 里的固定字段，账单口径按这个字段聚合。形态三的 trace 天然带 metadata 维度，聚合是个配置问题；形态一和形态二要自己把 thread_id 加租户字段写进监控与账单管道，多一步但完全可控。等销售拿着大客户的账单来问你「这个客户我们赚没赚钱」，能不能十分钟内给出答案，取决于今天部署时有没有留下这个字段。

决策线

按顺序问，问完一题再看下一题：

0. 真的要部署成服务吗？先回到第 01 篇的判断线确认这个系统该存在，再回到本篇开头确认它是不是内部低频任务。很多部署讨论的第一问应该是「要不要省掉这次部署」。
1. 需要标准 threads/runs API 和 Studio 吗？判断材料看交互形态：前端是不是多轮对话、要不要断线恢复、要不要实时流。两个次级信号帮你确认「不需要」：请求都是一次性任务（问完即走，没有后续追问），同一个 thread 不存在并发执行的可能。都不需要，形态一，到此结束，不用往下问。
2. 数据能不能出你的环境？这不是技术问题，是合规问题，问法务而不是问架构师。不能，形态二（有 license 预算）或形态四（Enterprise）。
3. 有没有运维人力？注意问的是「有没有多余的」，不是「有没有会装的」。没有，形态三，把隐性成本变成显性订阅费，这通常是划算的交换。这里还有一种混合形态值得知道：核心业务跑托管，内部工具自托管，按系统的关键等级分配形态，而不是全公司一刀切。

三个问题走完，答案通常就剩一个。还剩两个的话，用可逆性裁决：选退出成本低的那个。形态三是粘性最高的，不是因为它差，是因为数据积累在别人的平台上是单向门；拿不准时选二，未来往三搬容易，反方向搬难。

本地开发不分形态：langgraph dev 起本地 Agent Server，Studio 免费连，这条链路对四种最终形态都是一致的，前期不存在锁死。这一点比看起来重要：团队可以从形态一起步，业务代码不碰内部结构，等需要 threads API 的那天，把图原样搬进 Agent Server，代码不用重写。迁移的具体工作量也交代一下，以形态一迁形态二为例：图定义代码不动；加一个部署描述（Dockerfile 或配置），把图注册成 assistant；checkpoint 数据如果形态一阶段已经积累在 Postgres，要做一次 schema 对齐的迁移；调用方从私有 HTTP 接口换成 threads/runs 标准接口，前端改对接层。四步里最重的是最后一步，这也是「业务代码只用公开 API 面」纪律的价值所在：它保护的是调用方那层。形态之间的迁移成本主要由「当初写得干不干净」决定，不是由形态本身决定。

还有一块职责要跟着形态一起分配：安全与观测。形态一里，第 16 篇的权限闸门（工具分级、dry-run、审批）全部长在你自己的 API 层；形态二和形态三里，运行时是别人的，但权限判定依然在你的代码里跑，工具是你的函数，该有的审批流一样不能少，区别只在审计日志落在你自己的表里还是平台的事件流里，前者随 checkpoint 一起进你的备份策略，后者要确认平台的保留期和导出能力再依赖。观测同理：形态三的第 14 篇 trace 是买来的，形态一是自己搭的，但 state 摘要日志、关键节点埋点这两种，无论哪个形态都得自己写。收拢成一句话：部署形态买得到运行时，买不到治理，治理那部分从来都是你的代码，选型时把它从「平台会替我做」的清单里划掉，你会少踩很多上线之后的坑。

常见误判，四个都见过

这四个论点都在真实的选型会上出现过，各自错在把两个问题混成一个。

把 langgraph dev 当生产方案。 它是本地开发服务器，单进程、无生产级鉴权、无高可用，官方定位就是开发期连 Studio 用的。「本地能跑」和「能上线」之间隔着这一整篇。

忘了 checkpoint 是生产数据。 图部署上线后，checkpoint 表里是用户的对话历史、审批现场、业务中间态，它和订单表是同一敏感级别的数据，要进备份策略、访问控制、保留期管理。把它当缓存数据对待的团队，会在安全审查或磁盘告警那天补上这一课。

用「数据要在自己手里」论证自建运行时。 数据主权约束的是数据面：库在哪、备份在哪、辖区在哪。运行时跑在谁的代码上和数据在哪是两件事，形态二和形态四就是为「数据在自己手里、运行时不必自己写」准备的。拿数据主权当理由拒绝一切官方运行时，通常是把两个问题混成了一个。

指望换部署形态解决质量问题。 平台解决的是运行时的活：调度、扩容、可用性。state 设计错了、评测没建、人审流程没想清，换任何形态都在。部署是让系统能跑的最后一公里，不是让系统变好的那一段，那一段在前面十几篇里。

权衡

最大的选型风险不是选贵了，是形态一的隐藏工作量被低估。团队说「我们就自己写个 API」，三个月后发现自己实现了半个 threads API：断线重连做了个简版、并发 run 用了全局锁、流协议是自定的私有格式，每一个都是补丁摞补丁。这时候迁移到形态二或三，checkpoint 数据要迁（schema 对不上要转换），调用方要改（私有协议换标准 API），等于把系统的地基重浇一次。反过来的风险是形态三的粘性：trace、评测、部署全在一家的云上，用得越深越离不开，商业关系变化时的退出成本要认真评估过再深入：trace 能不能导出、评测集能不能搬走、运行时换自托管要改哪些代码，这三个问题的答案最好在签合同前就知道。评测集的迁移拿第 15 篇的格式来想就具体了：录制用例里存的是 thread_id 和快照引用，运行时换了平台，这些引用全部要重建，工作量随用例数线性涨，评测集越值钱，搬走越疼。

团队阶段和形态的对应关系，给一个定性的经验参考，不构成规则：一两个人的验证期，形态零或形态一，别让部署消耗探索速度；产品有了真实用户、前端开始多轮对话，形态一的压力清单开始报警，此时上形态二或三，业务代码不用动；团队过十人、有专门平台组、业务量起来之后，形态二的运维清单才有人真正接得住，或者留在形态三把人时继续花在业务上。反着走的路径也存在：从形态三退回形态二通常发生在合同或合规节点，前面说的退出三问这时候派上用场。这组对应关系里真正不变的只有一条：代码纪律。形态会随业务换两三次，守住公开 API 面的团队每次换都是搬桌子，守不住的团队每次换都是搬家。

无论选哪个，把这次决策写成一页纸存档：选了什么、当时的三个判断材料是什么、预计什么时候复核。半年后业务变了再翻出来看，是情境变了还是当初就错了，两种情况处理方式完全不同。部署选型最贵的不是选错，是错了没人记得当初为什么这么选，于是继续错着运维一年。

最后把这套账和传统 web 部署选型的差异收拢一下，它建立在三个不同上。第一，有状态：web 服务可以随时重开，agent 的 thread 和 checkpoint 是要带着走的资产，数据面位置是长期承诺。第二，用量型成本：传统部署的成本大头是固定的（机器、带宽），agent 多了一类随 token 和 trace 用量走的产品账单，预算模型里必须有变量项。第三，演进速度：这条产品线的名词和形态两年换了一轮，任何「最终结论」的有效期都以季度计，所以这篇给的是判断线和复核机制，不是答案本身。写进文档的选型记录、守住公开 API 面的代码纪律、每季度翻一次的成本表，这三样东西比选对形态更能保证你一年后还坐在牌桌上。

给中间态留一条路：形态一起步，但业务代码只用公开 API 面。具体三条纪律：不 import 框架的内部模块（下划线开头的都不碰）；不绕过公开接口直接操作运行时对象；state 结构加版本字段，为将来的数据迁移留后门。守住这三条，形态之间的门就一直开着。部署形态可以随团队规模换三次，业务代码一次都不用换，这是这篇选型文章最想留给你的一个结果。

延伸阅读

• Deployment 文档：四种形态的官方说明
• Standalone Server 部署指南：形态二的具体要求
• LangSmith 定价页：当前价格，决策前核对

---

原文出处：91ai / LangGraph 生产实战系列