我们团队如何选型LLM和AI Agent框架

过去 18 个月，我们的 ML 团队一直在做一些非常有趣的事情：在 PostgreSQL 之上构建 AI 智能体，同时基础设施不断演进、行业逐步成熟、质量期望持续攀升。我们最初在托管云中只使用一块 A100，任务也相当简单，比如"接入 RAG"。如今，我们同时支撑一个生产辅助助手、构建分析型智能体、运行实验、创建自己的智能体基准测试，并且正准备迁移到一台配备 8×H200 的服务器——在那上面你已经可以运行 Qwen3-235B，并对更小的模型进行认真的微调工作。

这篇文章讲述的是我们解决的任务、硬件/模型/框架是如何演进的，以及为什么我们最终不再纠结于哪个模型"最好"，而是更关注上下文管理和智能体架构。文中描述的一切截至 2025 年底至 2026 年初均为最新状态。

塑造技术栈的任务

围绕单一的 LLM 基础设施，一整套应用已经生长起来。为了让描述更具体，以下是主要方向：

面向文档及其他来源的经典 RAG Fusion 我们将内部文档、文章、问答对、SQL 示例、书籍及其他文本索引到 pgvector 中。我们使用 BGE-M3 做嵌入，不使用 BM25，而是采用稀疏向量：构建稀疏文本表示、计算密集向量，通过乘法、排名、折扣及额外启发式方法将一切组合起来。部分非结构化来源的处理委托给 LLM。

将 RAG 演进为具备网页搜索和 SQL 执行器的 MCP 智能体 经典的文档聊天已经不够用了：用户需要一个具备明确角色模型和多种工具的完整助手。于是 RAG 演进为一个 ReAct 智能体，通过 Model Context Protocol（MCP）与 PostgreSQL 对话、调用网页搜索，并在一条推理链中组合多个来源。

分析用 AI 智能体 这是一个面向分析数据的界面：智能体理解"显示去年各地区收入"这样的问题，生成 SQL，解释结果，能返回上一步，生成图表，并逐步增加查询复杂度。

大规模 C 代码库上的 Graph-RAG 智能体（AI copilot） PostgreSQL 内核及相关项目有数百万行 C 代码。我们在 Apache AGE 中构建知识图谱：顶点是目录、文件、函数、结构体、宏、变量；边是依赖和调用关系。智能体回答诸如"某行为在哪里实现"、"哪些改动可能造成破坏"这样的问题，帮助将代码作为知识库而非原始文本搜索来导航。

SQL 生成器 一个完整的 text-to-SQL 流水线，我们使用 EX/EM 指标和 Spider/BIRD 等基准测试以及自有 schema 进行训练和评估。训练时我们使用了带 GRPO/SFT 的 Qwen-0.6B；也实验过在纯 SFT 下对 Qwen2.5-14B 左右的模型进行 QLoRA 微调。

PostgreSQL Hint Set 生成器 核心是 pg_hint_plan 扩展。模型接收查询、统计信息和索引，生成 hint-set 格式的 hint。我们用 GRPO 训练，并用形式化语法约束输出，使 pg_hint_plan 能够解析和应用。

基于 DSL 的 DB schema 和业务逻辑生成器 我们使用的 DSL（领域特定语言）不仅描述实体，还描述 schema 变更的事务 schema。Schema 表示为 JTD（JSON Typedef）中具有层级数据结构的聚合。智能体在遵循 JTD 规范的同时生成表、关系、事务包装器和业务逻辑片段。

测试数据生成器 底层它是一个"简单"的 INSERT 生成器，但有细微差别。智能体拉取看似合理的值列表（城市、姓名、地址），考虑表之间的关系，并用形式化语法约束输出以便轻松验证和回放。

工单摘要与结构化 目标不只是复述对话，而是将其结构化：谁做了什么、验证了哪些假设、运行了哪些命令、最终结果是什么。智能体还会按现有标签对工单进行分类。

大规模代码库可疑片段扫描 LLM 筛选大量代码语料库，按预定义标准标记看起来可疑的片段。这是一种加速人工审计的工具，而非取代人工审计。

我们自己的智能体基准测试 我们形成了一套方案："被测智能体 + 测试智能体 + 验证器"。第一个智能体像在生产环境中那样使用工具完成任务。第二个扮演用户，基于有限的上下文子集提问和澄清。第三个（验证器）分析对话并判断目标是否达成、测试条件是否满足。这测试的是系统行为，而非模型智商。

记忆和形式化约束研究 我们同时探索短期和长期智能体记忆、上下文管理（从简单窗口到摘要、掩码和图），以及形式化语法和严格结构化输出如何影响质量、速度和稳定性。

在整篇文章中我会不断回顾这些任务——正是它们驱动了我们的硬件、模型和框架选择。

第一次技术栈迭代：1x A100、RAG、LangChain 和 Ollama → vLLM

我们的资源故事相当典型。最初只有一台托管云上的 A100 80 GB，需要同时支持实验和产品演示。它足以通过 Ollama 以 Q6_K_M 量化方式运行 30-70B 模型、启动简单的 RAG 场景，并构建早期的 SQL 生成器原型。

后来我们获得了一台配备两块 A100 的内部服务器。这让事情变得简单多了：生产环境运行在其上，多个环境并存，我们保持稳定的流水线，同时并行运行实验。那时我们清楚地意识到，Ollama 适合快速起步，但生产环境需要一个更可控、更高效的推理引擎。就这样我们最终选定了 vLLM。

但为什么是 vLLM 而不是 TensorRT-LLM 或 SGLang？后者似乎有更高的峰值性能？

在你们的具体场景下未必如此。互联网上充斥着各种图表和表格，它们要么互相矛盾（因为基于不同的硬件、不同的模型、不同的时间），要么总体上显示相对持平：

简而言之，这就是常见的基准测试大战。所以选择不取决于图表中的某个数字，而取决于框架对我们具体场景的适用性。

我们需要什么？结构化输出和上下文无关语法的支持——三者都支持。来自 Hugging Face 的多种不同模型的支持——在这方面 TensorRT-LLM 开始失分，因为它支持的模型家族有限，切换时需要编译模型，这会拖慢并复杂化研发流程。我们还需要 CPU 推理，vLLM 和 SGLang 支持，但 TensorRT-LLM 不支持。最终，在 vLLM 和 SGLang 之间的最终选择取决于社区规模——vLLM 胜出。

我们现在期待一台配备 8x H200 的服务器，这可以被视为运行最重型模型的真正平台。运行 Qwen3-235B 及其相近型号变得现实起来，也可以为特定任务启动针对小模型的系统化训练活动：SQL/Cypher/DSL 生成器、语义分类器、向量器、重排器、摘要器、日志分析器等等。在 A100 上我们也能做到这些，但代价是对量化、模型大小和训练时间做出激进的妥协。

至于框架，我们从最简单的组合开始：LangChain、LangGraph、LangFuse、RAGAS 和若干 Qwen2.5 模型。我们需要俄语和英语，所以我们很快放弃了 LLaMA 和 Gemma 系列的部分模型：在我们的任务和语料上，它们在俄语上明显输给 Qwen，而且提示/指令微调更困难。在那个阶段，我们的方案是：LangChain 用于 RAG，LangGraph 用于 Qwen 上的早期智能体图。用这个技术栈我们构建了一个原型助手、测试了基线 RAG、SQL 生成器，以及早期的"生成器 + 批评者 + 验证器"实验流水线。我们使用 RAGAS 来评估 RAG 中的迭代变化——包括流水线/提示/数据变化和基础模型变化。目标指标是 answer_relevancy 和 answer_correctness；基于这些指标我们来判断一个变化是帮助了还是损害了：

与此同时，我们的检索方法也在成熟：我们没有采用常见的 BM25 + 密集向量组合，而是押注 BGE-M3，它具有密集 + 稀疏表示，并开始将稀疏向量作为搜索的全文本部分。对于我们的文本，这更方便、更易于操作。

SQL 生成器和提示集：微调真正合理的场景

"我们对模型进行了微调"听起来很自豪。但很容易忘记，对于大多数应用任务来说，微调大模型更多的是奢侈而非必要。我们实际的经历相当接地气。

对于 80B 级别（尤其是像 Qwen3-235B 这样的模型），典型任务集——RAG、SQL、代码、工具——开箱即用。约 90% 的问题可以通过以下方式解决：

• 扎实的上下文管理；
• 像样的 RAG（BGE-M3、良好的索引、干净的解析）；
• 流水线架构（生成器、批评者、验证器、SGR）；
• 严格的结构化输出。

微调对我们合理的场景有两个。第一，当我们需要一个特定场景的小模型时，例如为没有强大 GPU 的客户进行本地部署。第二，当我们需要一个很难通过提示可靠获得的特定输出格式时。

技术上我们使用经典工具箱：我们尝试过 PEFT/LoRA/QLoRA、LLaMA-Factory 和 LMPO，但最终实际上形成了一个标准——TRL，用于 SFT 和 RL 方法（GRPO、GSPO 及类似方法）的实验。对于 SQL 生成器这样的复杂任务，我们更倾向于先在小模型（例如 Qwen-0.6B）上测试方法论，然后再将选定的轨迹和数据迁移到更大的模型。

主要过滤器很简单：如果我们没有算力、没有适当的带指标的基准测试、没有任务所需的数据，我们就不会为那个任务进行微调。先通过上下文调优，再微调。

SQL 生成器是我们第一个认为"好吧，这里的微调是值得的"的场景。我们希望模型不仅产生有效的 SQL，而且行为可预测、理解 PostgreSQL 方言的细微差别，并在典型用户查询的推理过程中做一些模式链接。

作为测试我们使用了 Qwen-0.6B：我们运行了 SFT 和 GRPO 结合 LoRA，并学会了如何设计奖励。这改善了复杂查询的质量，并表明此类流水线在小模型上是有依据的。我们还在纯 SFT 上用 QLoRA 训练了 Qwen2.5-14B。结果改善了格式稳定性，但没有增加新知识，这在基准测试中表现得很明显。

提示集生成器从相同的逻辑中发展出来，但约束更严格。在这里 pg_hint_plan 是核心，任何提示格式错误都可能导致规划器忽略提示。所以我们立即用形式语法约束了输出，并用 GRPO 训练，仔细选择实际上能加速查询的提示。

值得注意的是，RL 算法有很多，各有优缺点。例如，我们尝试了相对较新的 GSPO，发现它更适合 MoE 架构，而 GRPO 在小型密集模型上收敛更快。

DSL、JTD 和测试数据生成

另一个独立分支是 DSL 工作。我们需要一种描述语言，不仅声明数据模式，还声明变更的事务方案：哪些操作是可能的、哪些不变量必须成立、存在哪些聚合。我们在 JTD（JSON Type Definition）术语中描述了结构：这关联了分层聚合、业务不变量和事务逻辑。使用这个 DSL 的智能体充当从业务语言到形式语言的翻译器，可以提出澄清问题，并在需要时生成所需的变更。你可以在 Habr 上阅读更多关于 DSL 本身的内容。

另一个更接地气的流水线是测试数据生成器。它接收模式和需求，输出一组 INSERT。如果需要，智能体会获取看似合理的值（城市列表、姓名、域名等），跟踪关系和边界情况。它的所有输出都受形式语法约束，因此生成结果在语法上始终正确，对后续测试阶段有效。

从流水线"动物园"到基于 MCP 的智能体

当所有这些组件各自独立运行时，生活并不轻松。RAG 有自己的流水线，SQL 有自己的，代码上的 Graph-RAG 又是另一个。每个都有自己的数据库连接、自己的日志格式、自己的上下文定义。

转向 MCP 给基础设施和思想带来了期待已久的秩序。解释智能体如何与工具协作、存在哪些抽象层、如何扩展它们，都变得容易多了。我们开始用 MCP 服务器来描述数据和工具的访问，并在此基础上构建 ReAct 智能体。最终我们有了一个统一层：

• PostgreSQL、文件系统、网络搜索、图存储和内部 API 都看起来像一组具有清晰契约的工具；
• 不同的智能体可以复用同一组 MCP 服务器，而不需要复制粘贴和一整"动物园"的集成。

在此背景下，模型作为智能体的行为变得尤为重要：它调用工具有多谨慎、如何对错误做出反应、是否能诚实承认数据缺失。起步时你可以使用这样的排行榜，但你还需要在自己的任务上进行评估。这促使我们创建了自己的基准测试，核心是"被测智能体 — 测试智能体 — 验证器"三元组。我们需要的不仅仅是一个"好模型"；我们需要一个在长推理轨迹中行为可预测的系统。

当前技术栈：vLLM、Qwen3-Next-80B 和我们自己的智能体层

今天技术栈大致如下。

最底层是 vLLM，作为开源模型的主要推理引擎。往上一层是 OpenAI 兼容的 MCP 客户端，负责处理流式输出、连接 MCP 服务器、管理智能体循环，并确保所有需要的工具被正确调用、所有上下文按预期传递给 LLM。我们有意避免将复杂场景完全构建在 LangChain/LangGraph 内部——只把它们用于快速原型。这是有原因的：它们在生产场景中仍然粗糙，且存在诸多 bug。我们还在 PostgreSQL 上构建了自己的日志和数据分析系统。此前我们用过 LangFuse，直到发现一个内存泄漏问题导致每周数次生产环境宕机，才弃用了它。

值得注意的是，我们通过 LiteLLM 在团队之间共享资源：它是一个带有 OpenAI 兼容 API 的便捷网关，能根据需要将请求路由到不同的模型——无论是本地还是外部的。

工具和数据源存在于独立的 MCP 服务器层中。这使得我们可以在不重写智能体逻辑的情况下连接和断开服务器，并在不同产品/团队之间共享它们。

在这个配置下，多用户模式的负载测试中，使用文档搜索工具时平均响应时间为 18 秒，p95 约为 60 秒，对于我们的场景来说已经足够了。

量化的本质

在实际应用中，量化最终呈现出一幅相当简单的图景。

当我们在 A100 上运行时，AWQ-4bit 成为了大模型的常规工作形态。以这种形式，Qwen3-Next-80B-A3B 可以塞进一张卡内，在我们的任务上表现出可靠的质量，并且允许构建多阶段智能体而不会将延迟推到难以接受的程度。

我们尝试过更激进的量化模式，但很快发现错误的代价上升了：模型更频繁地漂移到错误的语言、在模板短语上循环，以及破坏工具调用格式（这种情况有时仍会发生）。其中一些问题可以通过提示词和采样参数（temperature、top-p、top-k）来修复，但真正可靠的组合只有在用形式化语法和严格输出规范包装模型时才会出现。

有了 H200，我们会更积极地考虑 FP8 量化和更大的模型，但理念不会改变：量化是质量和速度之间的权衡。我们将基于基准测试和可衡量的标准来选择，而不是排除延迟因素。

关于模型选择我们学到的东西

如果我们把所有经验压缩成一个论点，那就是：模型很重要，但上下文和架构更重要。

是的，如果你拿 GPT-5.2 或 Gemini Pro 3.0，它们在客观上会比任何开源同类模型更聪明。但如果一个智能体无法管理上下文、没有记忆、缺乏可靠的工具编排，再"万亿参数的超大模型"也救不了场。

我们从通过 Ollama 使用 Q6_K_M 量化版的 Qwen2.5-14B/32B，走到了 vLLM 上的 Qwen3-Next-80B-A3B AWQ-4bit，现在我们正在关注 H200 上的 Qwen3-235B。每一步都可以构建出有用的智能体，前提是系统的其余部分跟上：RAG、MCP、智能体层、记忆、语法和基准测试。

所以现在，当为新任务选择 LLM 时，我们首先问的不是哪个模型正处于巅峰。我们关心的是：

• 我们需要哪些数据和上下文来源；
• 我们将如何管理这些上下文；
• 智能体需要哪些工具，以什么形式；
• 我们将如何衡量行为质量。

而模型只是嵌入这个系统中的一个组件。即使是 GPT-5.2，没有上下文和架构，什么也推不动。