FastAPI vs LangServe：全面对比

2026 年的答案很直白：默认选 FastAPI。 LangServe —— LangChain 的“将链作为 REST API 服务”层 —— 在 LangChain 将托管重心转向 LangGraph Platform 后进入维护模式，其文档现在推荐新项目使用 LangGraph Platform。大多数团队今天真正需要做的对比是 *FastAPI vs LangGraph Platform*，本指南涵盖两者。

各自是什么

FastAPI —— 通用异步 Python Web 框架。你编写端点、流式传输、认证。它服务任何 LLM 栈（原始 SDK、LlamaIndex、LangChain、你自己的代码），因为它不知道也不关心什么是 LLM。

LangServe —— add_routes(app, chain)：为任何 LangChain runnable 自动生成 REST 端点（/invoke、/stream、/batch）以及一个 playground UI。它*构建在* FastAPI 之上 —— 对比一直是“手写端点 vs 生成端点”，而不是两个对立的服务器。

LangGraph Platform —— LangChain 当前的答案：托管（或自托管）基础设施，用于部署带有持久化、任务队列、流式端点和 assistants API 的 LangGraph 代理。这是他们部署投入的方向，而不是 LangServe。

LangServe 为何失势

自动生成的端点对于演示确实方便，但生产团队不断遇到同样的障碍：自定义认证意味着无论如何都要逃回 FastAPI 抽象；生成的 API 形状将你的公共契约耦合到 LangChain 的 runnable 接口（重构链 → 破坏客户端）；代理应用需要持久化和后台执行，无状态的 /invoke 无法表达。一旦你写了 FastAPI 的逃生口，LangServe 就变成了一个增加锁定而没有杠杆的薄层。

替代方案：FastAPI + 你的栈直接

在 FastAPI 上服务一个链（或任何 LLM 调用）几乎不比 add_routes 多多少代码，而且你拥有契约：

python
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
from pydantic import BaseModel
app = FastAPI()
class AskIn(BaseModel):
    question: str
@app.post('/ask/stream')
async def ask_stream(body: AskIn):
    async def gen():
        # 无论 'pipeline' 是 LangChain runnable (astream)、
        # LlamaIndex 查询引擎还是原始 SDK 调用，效果相同
        async for chunk in pipeline.astream({'question': body.question}):
            yield f'data: {chunk_to_json(chunk)}\n\n'
        yield 'data: [DONE]\n\n'
    return StreamingResponse(gen(), media_type='text/event-stream')

你的 API 模式是你自己的 Pydantic 模型 —— 内部重构不再是破坏性变更。完整的流式传输机制（断开连接、代理缓冲、客户端代码）见 FastAPI 流式传输配方；异步处理程序基础见 同步 vs 异步 LLM 调用。

何时 LangGraph Platform 值得考虑

如果你正在部署有状态的 LangGraph 代理 —— 长时间运行的任务、检查点状态、人机回环中断、cron 触发器 —— LangGraph Platform 为你提供了预构建的基础设施（持久化层、队列、流式传输、与 LangSmith 集成的监控）。在原始 FastAPI 上构建同样的东西意味着要自己处理 Postgres 检查点、任务队列和可恢复流 —— 数周的基础设施工作，而这些工作直到代理运行在部署后存活下来才可见。代价是平台定价以及将你的运维故事耦合到 LangChain 的生态系统。合理的规则：*无状态请求/响应 LLM API → FastAPI；大规模有状态长时间运行的代理 → 评估 LangGraph Platform（包括自托管选项）与自行构建基础设施。*

现有的 LangServe 部署

不必惊慌 —— 它仍然可以工作并接收维护修复。但计划退出：在同一应用中使用纯 FastAPI 添加新端点（LangServe 路由和你自己的路由可以共存），并机会性地迁移生成的端点。如果你只是为了 playground UI 而使用它，那可以用任何文档/Swagger 设置在一个下午复现。

常见问题

选择 FastAPI 是否意味着放弃 LangChain？ 不 —— LangChain 库可以完美地在手写 FastAPI 端点后面运行。你放弃的是*生成的路由层*，而不是编排。（你是否需要 LangChain：见 LangChain vs LlamaIndex。）

Node/TypeScript 中的等效决策？ Vercel AI SDK vs LangChain.js —— 相同的模式：平台原生服务 vs 框架生成。

AI API 的 FastAPI 替代方案？ 在 Python 中，FastAPI 是此类工作负载的事实标准（异步 + Pydantic + SSE）—— 如果你在权衡生态系统，见 FastAPI vs Express for AI APIs。

---

*最后更新：2026 年 6 月。LangChain 的部署指南变化很快 —— 在做出承诺前查看他们当前的文档。*