RAG 智能客服：LangChain 实现 vs Vercel AI SDK vs Pydantic AI 实现对比

1. 概述#

本文对比同一 RAG 智能客服系统的三个版本：

三个版本共享相同的业务需求——基于知识库的智能问答、问题推荐和知识库管理——但技术实现路径截然不同。下文将从技术栈、项目结构、RAG 流水线、会话管理、配置体系等维度逐一比较。

2. 技术栈对比#

3. 项目结构对比#

3.1 Vercel 实现（TypeScript）#

src/
├── server.ts                # Express 入口
├── routes/
│   ├── chat.ts              # POST /chat
│   ├── suggest.ts           # POST /suggest_questions
│   └── ingest.ts            # POST /ingest_qa_csv
├── services/
│   ├── chat.service.ts      # RAG 问答逻辑
│   ├── suggest.service.ts   # 问题推荐逻辑
│   └── ingest.service.ts    # CSV 导入 + 分块
├── lib/
│   ├── config.ts            # 环境变量配置
│   ├── llm.ts               # LLM 模型工厂（5 种后端）
│   ├── vector/
│   │   ├── client.ts        # Milvus 客户端单例
│   │   └── milvus.ts        # 嵌入、搜索、插入
│   └── session/
│       └── history.ts       # 内存会话存储
├── prompts/
│   └── index.ts             # 系统提示词 + 构建器
└── types/
    └── index.ts              # TypeScript 接口定义

3.2 Pydantic 实现（Python）#

src/
├── main.py                  # FastAPI 入口 + 路由 + 生命周期
├── config.py                # pydantic-settings 配置
├── models.py                # 请求/响应 Pydantic 模型
├── prompts.py               # 系统提示词 + 构建器
├── session.py               # 内存会话存储
├── agents/
│   ├── base.py               # LLM 模型工厂
│   ├── chat_agent.py         # 问答 Agent
│   └── suggest_agent.py      # 推荐问题 Agent
├── services/
│   ├── chat_service.py       # RAG 问答编排
│   ├── suggest_service.py    # 推荐问题编排
│   └── ingest_service.py     # CSV 导入 + 分块
└── vector/
    ├── client.py              # Milvus 客户端（含重试）
    ├── milvus.py              # 嵌入、搜索、添加
    └── utils.py              # 文本分块 + CSV 解析

3.3 结构差异分析#

4. RAG 流水线对比#

4.1 LangChain 实现：LangChain Runnable#

chain = RunnableParallel({
    "context": RunnableLambda(lambda x: x["question"]) | retriever,
    "question": RunnableLambda(lambda x: x["question"]),
    "history": RunnableLambda(lambda x: get_by_session_id(x["session_id"]))
}) | prompt | chat_llm

chain_with_history = RunnableWithMessageHistory(
    chain, get_by_session_id,
    input_messages_key="question",
    history_messages_key="history",
) | StrOutputParser()

LangChain 实现使用 LangChain 的 RunnableParallel 将检索、问题、历史三个数据源并行组装，再通过管道传入 prompt 和 LLM，最终用 RunnableWithMessageHistory 包装实现多轮对话。这是一个声明式编排风格。

4.2 Vercel 实现：手动编排#

// chat.service.ts
const contextResults = await similaritySearchMultiCollection(
  question, collectionNames, config.retrievalLimit
);
const context = contextResults.map(r => r.text).join('\n\n');
const history = getSessionHistory(openid);
const historyText = formatHistory(history);
const answer = await generateText({
  model: getChatModel(),
  system: CHAT_SYSTEM_PROMPT,
  prompt: buildChatPrompt(context, historyText, question),
});
appendToHistory(openid, question, answer);

Vercel 实现采用命令式编排：先手动调用向量搜索获取上下文，再格式化历史，再拼接 prompt，最后调用 generateText。每一步都由开发者显式控制，流程清晰但代码量更多。

4.3 Pydantic 实现：Agent + 依赖注入#

# chat_service.py
context_results = await similarity_search_multi_collection(
    question, collection_names, settings.retrieval_limit
)
context = "\n\n".join(str(r.get("text", "")) for r in context_results)
history = get_session_history(openid)
history_text = format_history(history)
answer = await run_chat(context, history_text, question)
append_to_history(openid, question, answer)

# chat_agent.py
chat_agent = Agent(
    model=get_chat_model(),
    system_prompt=CHAT_SYSTEM_PROMPT,
    deps_type=ChatDeps,
    result_type=str,
)

@chat_agent.system_prompt
async def build_prompt(ctx: RunContext[ChatDeps]) -> str:
    return build_chat_prompt(ctx.deps.context, ctx.deps.history, ctx.deps.question)

Pydantic 实现与 Vercel 版类似的手动编排，但将 LLM 调用封装为 Agent 对象，通过 ChatDeps 依赖注入传递上下文。Agent 是一个有状态的抽象——持有模型引用、系统提示词和依赖类型——比裸 generateText 更结构化，但仍保持编排逻辑在 service 层。

4.4 流水线对比总结#

5. LLM 集成对比#

三个版本都通过 LLM_TYPE 环境变量支持 5 种后端切换，但抽象层级不同：

5.1 LangChain 实现#

直接使用 LangChain 的 ChatModel 抽象，通过工厂函数返回不同 provider 的实例。

5.2 Vercel 实现#

// llm.ts — 工厂模式，每种 LLM_TYPE 返回不同 provider
function getChatModel() {
  switch (config.llmType) {
    case 0: return ollama('qwen3');
    case 1: return ollama('gpt-oss:120b'); // 云端
    case 2: return deepseek('deepseek-chat');
    case 3: return ollama('gpt-oss:20b');
    case 4: return ollama('gemma4:31b');
  }
}

Vercel AI SDK 的 ollama() 和 deepseek() 返回统一的 LanguageModel 接口，直接传给 generateText()。Ollama 本地和云端通过不同的 baseURL 区分。

5.3 Pydantic 实现#

# agents/base.py — 统一使用 OpenAI 兼容接口
def get_chat_model() -> OpenAIChatModel:
    if settings.llm_type == 0:
        return OpenAIChatModel(model_name="qwen3", provider=ollama_provider)
    elif settings.llm_type == 2:
        return OpenAIChatModel(model_name="deepseek-chat", provider=deepseek_provider)
    # ...

Pydantic 实现的所有后端——无论是本地 Ollama 还是云端 DeepSeek——都走 OpenAIChatModel + OpenAIProvider，仅 base_url 和 api_key 不同。这种统一抽象简化了代码，但意味着所有模型必须兼容 OpenAI API 格式。

5.4 Embedding 对比#

三者都使用 Ollama 的 embeddinggemma 模型，但 Pydantic 版通过 OpenAI 兼容端点调用（/v1/embeddings），而 Vercel 版使用 Ollama 原生端点。

6. 会话管理对比#

三个版本都采用内存存储 + 滑动窗口策略，但实现细节不同：

LangChain 实现利用 LangChain 的 RunnableWithMessageHistory 将历史注入自动化；两个实现版本则选择手动管理——先获取历史、格式化、注入 prompt，再在响应后追加。手动方式代码更直观，但需要开发者自行保证"先取后写"的顺序。

7. 向量数据库操作对比#

7.1 集合 Schema#

三者完全一致：

索引均为 IVF_FLAT，L2 度量，nlist=1024。

7.2 多集合搜索#

三个版本都支持跨多个 Milvus 集合搜索（默认搜索 customer_service_rag 和 scanner），合并结果按 L2 距离排序。对于不存在的集合，LangChain 实现未提及处理方式，Vercel 和 Pydantic 实现都会静默跳过并记录日志。

7.3 异步处理#

Pydantic 实现额外引入了 ThreadPoolExecutor(max_workers=4) 处理 pymilvus 的同步调用，这是 Python 向量客户端生态的特殊处理。

7.4 客户端重试#

Pydantic 实现针对 Docker 容器启动场景加入了重试逻辑，提升了服务启动的健壮性。

8. 配置管理对比#

Pydantic 实现在配置管理上优势明显：pydantic-settings 自动从 .env 和环境变量加载，类型转换和校验一体化，开发者无需手动写 parseInt() 或 process.env.X ?? default。

9. 知识库导入对比#

值得注意的是，LangChain 实现的分块参数（1000/200）比两个实现版本（500/50）更大，实际实现选择了更细粒度的分块策略。两个实现版本都使用中文标点（。、，）作为分块分隔符。

10. 测试与代码质量#

Pydantic 实现是唯一配备测试套件的版本，包含路由测试、提示词测试和工具函数测试。Vercel 实现虽然没有测试，但保留了详细的迁移过程文档，包括从一个关键 bug（向量上下文未传入 LLM）的排查记录。

11. 部署对比#

三个版本的 Docker Compose 结构几乎相同，均为 4 个服务：

主要差异：

• Vercel 实现：Dockerfile 基于 node:20-alpine，应用端口 8000/8080 双端口
• Pydantic 实现：Dockerfile 多阶段构建（python:3.11-slim + uv），Ollama 映射到 11435→11434，并添加了健康检查
• Pydantic 实现：Ollama 有持久化模型存储卷（ollama_data），其他版本未挂载

12. 生产环境评估#

从生产部署的角度，三个版本的差距显著。以下从关键维度逐一分析。

12.1 可靠性#

Pydantic 实现在可靠性上投入最多：Milvus 客户端的重试逻辑解决了 Docker 容器启动顺序问题；Docker Compose 的健康检查确保 Milvus 就绪后再启动应用；Pydantic model 同时校验请求体和环境变量，配置错误在启动时即暴露。Vercel 实现虽然在迁移过程中修复了多个 bug（如向量上下文丢失），但缺乏系统性的启动容错机制。

12.2 可观测性#

Pydantic AI 与 Logfire 同属 Pydantic 团队，可以零配置接入结构化追踪。Agent 的每次调用、依赖注入、模型响应都会被自动记录。对于生产环境中排查"为什么 LLM 给出了错误答案"这类问题，链路追踪至关重要。Vercel 实现仅有 console.log 级别的日志，缺乏结构化追踪能力。

12.3 可测试性#

Pydantic 实现是唯一有测试的版本。更关键的是，Pydantic AI 的 Agent + 依赖注入设计使得 LLM 调用可以被完整替换：测试时传入 mock 的 ChatDeps，无需真实调用 Ollama。Vercel 版的 generateText() 是框架级调用，mock 需要拦截 Vercel AI SDK 的内部模块，侵入性更高。

12.4 可维护性#

可维护性是生产系统长期存活的核心指标。一个系统上线后的生命周期中，维护时间远超开发时间——修复 bug、新增功能、切换模型、调整 prompt 都是日常工作。以下从多个子维度展开分析。

12.4.1 配置安全#

场景：运维人员误将 MILVUS_PORT 写成字符串 "abc"。

• Vercel 实现：parseInt("abc") 返回 NaN，Milvus 连接时才报错——错误在运行时暴露，且报错信息不直观。
• Pydantic 实现：应用启动时 pydantic-settings 立即抛出 ValidationError，明确告知哪个字段、期望什么类型、实际收到什么值——错误在启动时暴露，定位零成本。

12.4.2 变更影响范围#

三个版本在模块边界上差异不大——新增端点都需要改路由和 service，替换向量数据库都需要重写 vector 层。但 Pydantic 的依赖注入在"新增 LLM 后端"场景下有额外优势：Agent 的 deps_type 是显式声明的数据类，新增 provider 不影响 Agent 的接口定义；而 Vercel 版的 getChatModel() 返回类型是 LanguageModel，新增 provider 只需修改工厂函数，两者改动量相当。

12.4.3 代码规范与自动化#

Pydantic 实现的工程化程度最高：pyproject.toml 中配置了 Ruff 格式化（行宽 100）、Ruff lint 规则和 Pyright 类型检查，可以作为 CI 流水线的检查步骤。这意味着：

• 代码风格一致性不需要 code review 逐行检查，Ruff 自动处理
• 类型错误在提交前被 Pyright 捕获，而非运行时才发现
• 测试可以自动回归，变更后 pytest 一条命令即可验证

Vercel 实现缺少这些自动化手段，代码质量完全依赖开发者的自律和 code review。

12.4.4 依赖锁定与可复现性#

两个实现版本都有锁文件，确保不同环境安装相同版本依赖。Pydantic 实现使用 uv 作为包管理器，安装速度比 pip 快 10-100 倍，在 CI/CD 环境中优势明显。

12.4.5 调试体验#

Pydantic AI 与 Logfire 的集成是调试体验的关键差异。在 Vercel 实现中，开发者需要手动插入 console.log 来追踪数据流；而在 Pydantic 实现中，Agent 的每次调用、依赖注入、模型响应都会被自动记录，可以直接在 Logfire Dashboard 中查看完整的调用链。

12.4.6 新人上手成本#

LangChain 和 Vercel AI SDK 都是成熟的框架，社区文档丰富。Pydantic AI 相对较新，但 API 表面积很小（Agent、RunContext、Depends 三个核心概念），学习成本低。加上 Pydantic model 提供的自文档化效果——每个请求/响应的字段、类型、默认值都清晰可见——新开发者理解代码结构的速度最快。

12.4.7 可维护性总评#

Pydantic 实现在可维护性上全面领先。这不是因为它用了 Python，而是因为它在工程实践上的投入：启动校验、测试覆盖、自动格式化、结构化日志、依赖注入——每一项都是长期维护的减负措施。Vercel 实现功能完备，但这些"非功能"维度的缺失，会让维护成本随时间线性增长。

12.5 性能考量#

Node.js 在纯 I/O 密集场景下有天然优势——事件循环天生非阻塞。Pydantic 实现需要 ThreadPoolExecutor 桥接 pymilvus 的同步调用，在高并发下可能成为瓶颈。不过，对于当前的业务场景（客服问答，QPS 通常不高），这个差异可以忽略。

12.6 伸缩性#

三者都有同一个生产瓶颈：会话状态存储在内存中，服务重启即丢失，且无法水平扩展。要支持多实例部署，必须将 Map/dict 替换为 Redis 或数据库。

Pydantic 实现的 session.py 模块化程度更高（独立的 ChatMessage 数据类、get_session_history / append_to_history 函数），替换为 Redis 实现的改动范围更小。Vercel 实现的 session/history.ts 也是独立模块，改动范围类似。LangChain 实现的 RunnableWithMessageHistory 集成度更高，替换需要调整 LangChain 链的组装方式。

12.7 生产环境推荐#

综合判断：Pydantic 实现更适合大多数生产场景。 核心原因：

1. 启动即校验——错误配置不会带到运行时
2. 测试覆盖——唯一有测试的版本，变更可以验证
3. 可观测性——Logfire 集成让线上排查有据可循
4. 依赖注入——Agent + Deps 设计使得 LLM 调用可替换、可测试

唯一的劣势是 Python 运行时的性能，但客服问答场景的瓶颈在 LLM 推理延迟（秒级），而非 API 层处理速度（毫秒级），因此 Python 与 Node.js 的差异在实际体验中可忽略。

如果团队已有成熟的 TypeScript 工程体系（CI/CD、监控、日志）且对 Python 不熟悉，Vercel 实现也是合理选择——只需补上测试和结构化日志。

13. 总结#

从可维护性角度的结论#

LangChain 实现提供了清晰的架构蓝图，LangChain 的声明式编排代码简洁，但作为设计参考而非可运行代码，无法直接投入生产。

Vercel 实现完成了从 Python 到 TypeScript 的完整迁移，命令式编排让每一步数据流透明可控。迁移过程中踩过的坑（向量上下文丢失、集合未加载等）都已修复并记录在案。但从可维护性角度看，它存在三个短板：

1. 配置校验缺失——错误的环境变量只在运行时暴露，排查成本高
2. 无测试覆盖——每次变更只能人工验证，回归风险大
3. 无代码规范工具——代码质量依赖开发者自律，长期项目容易风格漂移

Pydantic 实现是可维护性最优的版本，这不是因为语言选择，而是因为工程实践：

1. 配置安全——pydantic-settings 启动时校验，错误配置零容忍
2. 测试覆盖——pytest 保障每次变更可验证，回归风险低
3. 自动规范——Ruff + Pyright 确保代码风格一致、类型错误提前捕获
4. 可观测性——Logfire 集成让线上排查从"加 console.log"变成"查 Dashboard"
5. 依赖注入——Agent + Deps 设计使 LLM 调用可替换、可测试

如果只看可维护性一个维度，Pydantic 实现是明确的首选。它在配置安全、测试、规范、调试、上手成本上的投入，都是为"系统上线后能低成本迭代"服务的。Vercel 实现功能完备，但如果要达到同等可维护性，需要补上测试、Lint、结构化日志这三块——这并非不可能，但需要额外投入。

当然，如果团队有强 TypeScript 偏好且已有成熟的 Node.js 工程体系，补齐这些工程实践后的 Vercel 实现同样可维护。关键不在语言，而在工程纪律。