Python 还是 TypeScript：Agent 开发的语言与运行时选择

生态版图：两个语言的 Agent 地盘

Agent 开发语言的选择，先看清两个生态的版图。Python 生态的地盘：研究与数据侧的统治地位——几乎所有模型与训练工具（PyTorch/HuggingFace）、数据科学栈（pandas/numpy）、评测与研究框架（OpenHands、多数论文代码）是 Python；Agent 框架的 Python 侧更深（LangGraph/LangChain 的 Python 版先于且强于 JS 版、ADK/Agno/CrewAI 原生 Python）；文档与数据的处理工具链（PDF 解析、表格处理、OCR）Python 无可撼动。TypeScript 生态的地盘：Web 与产品侧的统治地位——Agent 的前端（本库 CopilotKit/assistant-ui 全是 React/TS）、全栈应用（Next.js 系）、边缘与服务端 JS 运行时（Vercel/Cloudflare Workers 的 AI SDK 生态）、以及「应用型 Agent」（嵌进 SaaS 产品的助手——交付形态是 Web 应用，TS 天然一栈到底）。版图的历史成因：Python 是 AI/ML 的母语（研究者的语言），TS 是 Web 的母语（产品工程师的语言）——Agent 恰好横跨两者，所以版图两分。

关键差异：运行时、并发与 SDK 的覆盖

运行时与并发的差异直接影响 Agent 的架构选择。Python 的优势：AI 库的生态深度（需要本地跑模型、做数据处理、复现论文——Python 是唯一解）、并发的简化心智（asyncio 加上 GIL 的现实——CPU 密集任务用多进程，IO 密集的 Agent 调用 asyncio 够用）。TypeScript 的优势：事件驱动与流式的天然契合（JS 的事件循环生来就是处理流与回调——流式 UI、实时事件的前后端同构）、前后端同栈（Agent 的类型定义前后端共享、一套团队全栈交付）、边缘部署（Cloudflare Workers/Vercel Edge 上跑轻 Agent——Python 在边缘生态薄弱）。SDK 覆盖的差异（选型的硬约束）：头部厂商的官方 SDK 双语言都有（OpenAI/Anthropic 的 Python 与 TS SDK 同步发布），但能力sometimes 不对称（某些新特性 Python 先上、某些内建工具 TS 独有——选型时核对你用的 SDK 版本）；框架的覆盖（LangGraph 双语言但 Python 更深、ADK 有 Java 与 Python 无官方 TS、CrewAI 纯 Python、Vercel AI SDK 纯 TS）——框架的绑定常决定语言（选定 LangGraph 深度用法基本等于选定 Python）。

选型框架：四个问题定语言

选型框架四问。问题一：你的 Agent 要「吃」什么——大量文档/数据处理（Python）、主要调 API 与服务（两者皆可，看下一问）。问题二：你的 Agent 要「住」在哪——Web 应用里/边缘上（TS）、独立服务/脚本/研究（Python）。问题三：你的团队是谁——数据科学家与研究背景（Python 的舒适区）、全栈产品团队（TS 的舒适区）——团队栈比语言优劣更重要（陌生语言的框架学习成本 × 维护成本，远超语言本身的差异）。问题四：你要接的框架生态——深度依赖某框架时语言跟着框架走。四问的典型答案组合：数据密集的内部智能体 → Python；SaaS 产品的内置助手 → TypeScript；研究原型 → Python；全栈 SaaS 一体交付 → TypeScript。以及一个正在发生的变化：语言的墙在变薄——MCP 与 HTTP 协议让「Python 写的核心 Agent」与「TS 写的前端」无缝协作（跨语言的工具调用是协议的默认能力）；模型提供商的 SDK 双语言拉齐；「语言选型」的重要性正在从「决定能力」降级为「决定舒适度」——协议与 API 正在成为新的「通用语言」。

混合架构的现实：多语言的边界协作

现实中的 Agent 系统常常是多语言的，边界协作的模式值得记录。模式一：Python 内核 + TS 外壳——重数据处理与模型调用的内核用 Python（独立服务），Web 产品与前端用 TS，中间 REST/消息通信（本库 IPC 篇的 UDS/HTTP 原则在服务间）。模式二：TS 全栈 + Python 微服务点缀——主流应用 TS 一体，个别数据任务（文档解析、批处理）用 Python 脚本跑批。模式三：云函数的混合部署——不同语言的云函数按任务分工（各调各的）。混合的成本清单：接口契约的维护（两套类型定义的同步）、部署与运维的翻倍、团队的上下文切换——混合架构要用在「语言的真实优势差异」上，而不是「个人偏好」上。给个人开发者的建议：双栈是 Agent 时代的职业溢价（本库技能迁移篇的延伸）——Python 的数据侧 + TS 的产品侧，两个都站住的人恰好站在版图的交界处，而交界处正是 Agent 应用最密集的地带。给团队的收束：语言选型的正确顺序是「先定部署形态与团队栈，再让语言跟着走」——语言是 Agent 工程里最不值得纠结的变量，却常常消耗最多的争论。

语言选型的实战案例：同一个 Agent 的双语言实现对比

语言选型（正文四问）的实战案例：同一个「文档问答 Agent」的 Python 与 TypeScript 实现对比。Python 版的体验：生态顺滑（LangChain/LlamaIndex 的文档处理件、pandas 的表格处理）、数据任务的深度（PDF 解析库丰富）、部署为独立服务（FastAPI 起服务、容器化）。TS 版的体验：前后端同构（Next.js 应用 + API routes 一体、类型定义共享）、流式 UI 的顺滑（Vercel AI SDK 的流式集成——前端流式渲染的工程量减半）、边缘部署的选项。实测的差异点：文档解析（Python 的库更成熟——PyMuPDF 等的生产级质量；TS 的解析库可用但深度略逊）、开发迭代速度（熟悉哪边哪边快——语言熟练度的权重高于框架差异）、运维（两者容器化后差异不大）。对比的结论：这个场景两个语言都能做到 90 分——差异不在能力在团队（Python 团队选 Python、Web 团队选 TS 都是好决策；混合团队的双栈协作也是好决策——本库正文的多语言边界协作）。对比案例的元价值：它证明了正文的判断——语言选型的四问里，「团队是谁」的权重最高——同一个需求，两个语言的实现都能成功，失败的从来不是语言，是「用不熟的栈硬上」。

多语言协作的工程模式：monorepo 与协议层的实践

多语言协作（正文混合架构）的工程模式：monorepo 与协议层的实践细节。monorepo 的组织。目录结构（packages/agent-core（Python）、apps/web（TS）、packages/shared-types（类型契约））、类型契约的同步——TS 与 Python 的类型定义同步是核心难题（方案：OpenAPI 规范生成两边的类型、或共享 JSON Schema——契约先行，双端生成是标准解）。协议层的设计。Agent 内核（Python）暴露 HTTP/SSE 接口（本库流式篇）、TS 前端消费（SSE 的事件格式是跨语言的通用货币——本库流式篇的事件协议在跨语言场景的价值凸显）。CI/CD 的多语言编排：两条测试线（Python 的 pytest、TS 的 vitest）+ 集成测试（跨语言的端到端）+ 各自的构建发布（monorepo 工具（Turborepo/pnpm workspace）编排多语言的构建依赖）。多语言协作的收束：跨语言的成本集中在「契约的维护」——把契约（类型与协议）做成一等公民并自动化生成，多语言的协作成本就从「持续税」变成「一次性投资」；协议先行（MCP/HTTP/SSE 的标准化）正在让这个投资越来越小。

Agent 团队的招聘与培养：双栈人才的成长路径

Agent 团队（正文团队栈）的招聘与培养：双栈人才的成长路径。岗位的形态变化。传统分工（前端/后端/算法）在 Agent 团队里模糊化——「Agent 工程师」的画像：懂模型行为（提示词、评测）、能搭后端（Python/TS）、能做前端集成、懂数据管线——全栈 + AI 的复合画像。招聘的现实。市场上「现成的 Agent 工程师」稀缺（领域太新）——招聘的策略转向「潜力与基础」：扎实的软件工程功底 + 对 AI 的实践热情（自己的 Agent 项目）+ 快速学习（框架半年一换的适应力）——「做过 Agent 项目」的候选人，问细节（评测怎么做的、上下文怎么管的）能分辨真浅。培养的路径设计。内部工程师的转型路径（现有全栈工程师 + Agent 项目的实践机会——给团队搭一个内部 Agent 项目的机会比培训课程有效）、以及「评测与安全」专家的培养（本库各篇的专项——这两个子领域的人才最稀缺）。团队的配置模式。小团队的万能位（1-2 个全栈 Agent 工程师）、大团队的分层（平台组（基建）+ 应用组（业务 Agent）+ 评测与安全（横切）——本库组织篇的形态）。收束：Agent 团队的核心竞争力，是「把领域知识工程化」的能力——招聘找基础扎实的学习者，培养给真实项目的练兵场，团队的护城河是「Agent 工程的流程知识」——它不在任何简历上，在团队做过的每一个项目里。

Agent 开发的测试策略：多语言系统的测试矩阵

Agent 开发（正文多语言协作）的测试策略：多语言系统的测试矩阵——Python 内核 + TS 前端的测试怎么组织。测试矩阵的分层。层一：单元测试——Python 的 pytest（Agent 内核的逻辑：工具函数、提示词组装、解析）、TS 的 vitest（前端的组件与逻辑）——各栈各测，契约层是边界。层二：契约测试——接口的契约验证（Python 服务暴露的 API 与 TS 消费的类型一致——OpenAPI 契约的自动校验、MCP 工具的 schema 验证——契约测试是多语言系统的生命线：类型不同步是跨语言 bug 的头号来源）。层三：端到端测试——完整链路的冒烟（从前端提问到 Agent 回答的完整路径——playwright 的 e2e + LLM 输出的宽松断言——本库评测篇的语义断言）。层四：评测集成——evals 进 CI（本库评测篇）与 e2e 的结合（真实场景的端到端评测——不是 mock 的 LLM，是真实调用的评测）。测试矩阵的收束：多语言 Agent 系统的测试 = 各语言的单元测试 × 契约测试 × 端到端评测的四层矩阵——契约测试是跨语言的免疫，端到端评测是真实世界的体检；四层都建，多语言才不是负债。

小结

Agent 开发的语言版图两分：Python 统治研究数据侧（AI 库深度、框架更深），TypeScript 统治 Web 产品侧（前后端同栈、流式契合、边缘部署）。四问选型（吃什么、住哪、团队是谁、接什么框架），且「团队栈比语言优劣重要」。协议（MCP/HTTP）正在让语言的墙变薄——混合架构（Python 内核 + TS 外壳）是现实常态。语言选型的正确顺序：部署形态与团队栈先定，语言跟着走——语言是这个领域最不值得纠结的变量。