大家好 👋，我是 Moment，目前正在使用 Next.js、NestJS、LangChain 开发 DocFlow。这是一个面向 AI 场景的协同文档平台，集成了基于
Tiptap的富文本编辑、NestJS后端服务、实时协作与智能化工作流等核心模块。在这个项目的持续打磨过程中，我积累了不少实战经验，不只是
Tiptap的深度定制、编辑器性能优化和协同方案设计，也包括前端工程化建设、React 源码理解以及复杂项目架构实践。如果你对 AI 全栈开发、文档编辑器、前端工程化或者 React 源码相关内容感兴趣，欢迎添加我的微信
yunmz777一起交流。觉得项目还不错的话，也欢迎给 DocFlow 点个 star ⭐
很多人一上来就问 LangChain.js 到底能不能和 Python 版打，其实这个问题放在 2025 年已经不太成立了。现在的 LangChain.js 和 Python 版早就不是一个能做、一个不能做的关系，而是生态重心、运行时环境、团队技能结构上的差别。官方两边都在围绕 createAgent、create_agent、middleware 和 LangGraph 这套 agent runtime 推进，核心能力的差距相比早期缩小了很多。真正值得讨论的是，在你自己的项目里到底该选哪一边。
核心能力已经很接近
先从能力层面看。两边都提供了生产可用的 agent 入口，Python 侧是 create_agent，JS/TS 侧是 createAgent。两边都把 middleware 作为核心定制机制，用来做上下文工程、摘要、PII 处理、人类审批、工具控制、状态管理这些事。JS 侧的 createAgent 底层基于 LangGraph 的 graph-based runtime，和 Python 侧走的是同一条架构路线。换句话说，做工具调用 agent、工作流 agent、带状态和中间控制的 agent，两边都能胜任，你不会因为选了 TS 就被卡在某个能力边界上。
生态厚度的差别在集成数量上
能力差不多，但生态厚度差得比较明显。官方集成页上 Python 侧的可用集成是 1000+，JS/TS 侧是 100 多个，差了将近一个数量级。
这个差距短期内不会被抹平，因为 Python 天然连着更大的 AI 和数据生态。数据清洗、文本处理、embedding 前处理、实验脚本、评测、离线任务，这些事情在 Python 里通常都有现成的库和现成的示例可以直接抄。你遇到一个冷门的向量库、冷门的模型提供商、冷门的文档解析器，在 Python 侧大概率能找到适配，在 JS 侧可能就要自己包一层。
反过来看，JS/TS 的优势不在集成数量上，而在离 Web 产品更近。如果你本来就在 Node 里做 API、SSE、WebSocket、前后端共享 schema、全栈 monorepo，那用 TS 会让系统边界更简单，省掉大量跨语言胶水代码。
TS 的真正价值是全栈一致
沿着上面这点继续往下说。选 TS 的最大好处其实不是 AI 能力更强，而是能把整个系统打通成一套类型。前端表单类型、后端 DTO、工具入参 schema、Zod 校验、agent 输出结构、SSE 返回类型，甚至日志事件类型，都可以放在同一套类型系统里管。这种一致性在 Python 和 TS 混用的架构里很难做到，常常要靠文档约定或者手写 schema 对齐，维护起来很累。
在 Node 项目里，middleware 这类运行时控制也更容易直接融进现有的 Web 服务，不用额外起一个 Python 子服务再做接口拼接。对做产品的团队来说，这种工程上的顺滑感，往往比多几百个集成更重要。
两边都更规范但仍在快速演进
说完优势再说一下稳定性。LangChain 目前按 semver 管理版本，minor 加新特性，patch 高频修 bug。和 0.x 时期相比稳定了很多，不再是动不动就改 API 的状态。但这个领域整体仍在快速变化，不管你选 Python 还是 TS，做生产项目都要锁版本，不要无脑追最新。这一点两边是一样的，不构成选型差异。
什么时候优先选 TS
把前面几点串起来看，就能得到一个比较清楚的选型判断。下面这几类场景选 TS 会更顺。
- 在做 AI 产品，不是在做 AI 研究。比如聊天、文档编辑 agent、知识库问答、工作流编排、客服后台、内容生成后台这类偏产品交付的系统。
- 主栈已经是
Next.js、NestJS或者纯Node，用 TS 能减少语言切换、减少服务拆分、减少跨语言 schema 漂移。 - 特别在意类型安全和契约一致性，工具参数、结构化输出、前后端共享类型、
Zod校验这些需求都希望一套语言搞定。 - 要把 AI 能力直接嵌进现有 Web 服务，比如 SSE 流式输出、实时 UI、在线编辑器、业务鉴权、BFF 层整合。
什么时候反而该选 Python
反过来，下面这几类场景选 Python 更省事。
- 大量文档 ETL、离线索引、数据实验、批处理。
- 高度依赖更广的第三方 AI、检索、数据生态，需要用到很多冷门集成。
- 团队里 AI 工程师以 Python 为主，notebook 和实验迭代是主工作流。
- 经常要找社区现成示例，希望命中率更高。
这两组判断背后的事实基础其实是同一个，就是 1000+ 和 100+ 这个集成数量差，决定了两边在不同场景下的顺手程度。
混合架构通常是更稳的落地方式
在真实项目里，很多团队不是非此即彼，而是两边都用。尤其是做 Next.js 加 NestJS 加编辑器 Agent 产品的团队，第一选择可以是 TS，但不代表全链路都得 TS。因为你真正要解决的问题不是做最前沿的算法实验，而是下面这几件事。
- 怎么把 agent 接到产品里
- 怎么和编辑器、接口、鉴权、队列、流式返回结合
- 怎么把 schema、状态、工具调用、前后端契约统一起来
这些问题上 TS 比 Python 省很多系统复杂度。但一旦涉及重 ETL、重索引、重离线处理，用 TS 去硬啃生态空缺反而不划算。这时候比较实用的做法是把链路拆成两层。
前台产品层和在线 agent 层用 TS，负责直接面向用户的实时请求。重 ETL、重索引、重离线处理的 worker 单独上 Python，吃 Python 那边的生态红利。两条链路通过消息队列或者存储层解耦，互相不干扰。这种架构通常比一开始全 Python 或者强行全 TS 都更稳。
总结
回到最初那个问题。LangChain.js 和 Python 版今天已经站在同一条架构路线上，核心 agent 能力都够用，真正的差别在生态厚度和运行时环境。Python 胜在 1000+ 集成和更厚的 AI 数据生态，JS/TS 胜在和 Web 产品栈的天然贴合以及一套类型贯穿全栈的工程体验。
所以最后给你的结论是这样。做 Web 产品、编辑器、SaaS、Agent 平台这类偏产品交付的系统，优先 TS。做数据实验、检索管线、研究型系统这类偏数据和研究的工作，优先 Python。如果两头都要做，就按用户实时链路和离线数据链路拆开，让 TS 和 Python 各司其职。这样既能吃到 TS 在产品工程上的顺滑，也能吃到 Python 在 AI 生态上的厚度，不用二选一。