2026年LLM技术栈：模型、推理、工具与权衡

如果你在2026年构建真正的AI产品，就不会再问“该用OpenAI还是Anthropic？”这种提问方式已经落后两年了。你需要在一个分层技术栈中做出几十项决策，而其中大多数都很重要。

本文从一线架构师的视角审视2026年的LLM技术栈：每一层包含什么、你要做出哪些权衡，以及这个领域正走向何方。我们真希望在自己犯下那些本可避免的错误之前，就有人写出这样一篇文章。

各层概览

技术栈大致如下：

┌────────────────────────────────────┐
│       Application Layer            │  Your product / agent / workflow
├────────────────────────────────────┤
│   Orchestration / Frameworks       │  LangGraph, CrewAI, custom, direct
├────────────────────────────────────┤
│   Prompt + Context Management      │  Prompt templates, context engineering
├────────────────────────────────────┤
│   Retrieval / Memory               │  RAG, vector stores, structured memory
├────────────────────────────────────┤
│   Tool / MCP Layer                 │  Tool calling, MCP servers, function APIs
├────────────────────────────────────┤
│   Model Layer                      │  Specific model selection, routing
├────────────────────────────────────┤
│   Inference Layer                  │  Hosted APIs, self-hosted, edge
├────────────────────────────────────┤
│   Observability / Evals            │  Logging, tracing, eval suites
└────────────────────────────────────┘

每一层都有多种可行方案。某一层的选择会限制其他层的选项。早期决策往往很难改变——模型选择会影响推理方式，推理方式又会影响编排方式。

下面逐层说明。

第1层：模型层

2026年的模型大致可以划分为几个层级。为每次调用选择哪个层级，是整个系统中影响最大的决策。

旗舰推理层级。 当前旗舰模型的思考模式——启用推理的GPT-5.5、启用自适应思考的Claude Opus 4.8、启用思考的Gemini 3.1 Pro——以及DeepSeek R1等专用推理模型。它们非常擅长多步骤问题、数学、代码和复杂分析，但价格昂贵（每百万输入token $3–30，输出token贵得多），速度也较慢（5–60秒）。当推理质量成为瓶颈时，应使用这类模型。

旗舰通用模型。 GPT-5.5、Claude Sonnet 5、Gemini 3.1 Pro。它们能出色完成大多数知识工作，速度快（2–5秒），价格中等（每百万输入token $2–5），是生成高质量用户可见回复时的默认选择。

中端模型。 Claude Haiku 4.5、Gemini 3.5 Flash、OpenAI的中端层级。它们适合简单到中等难度的任务，速度快（1–2秒），价格低（每百万输入token $1–2.50）。生产环境大量使用这类模型完成分类、提取和简单生成任务。

小型 / 经济型模型。 各服务商目前最小的模型层级（例如Gemini 3 Flash Preview）以及小型开源模型。它们足以处理范围明确的结构化任务，价格极低（每百万输入token $0.50–1），速度极快（不到1秒）。适合路由、评分和批处理。

（以上标价已于2026年7月7日对照服务商定价页面核实；模型层级会变化，引用前请重新确认。）

专用模型。 嵌入模型、重排序模型、视觉模型、语音模型和代码专用模型。对于各自擅长的任务，它们通常比通用模型更便宜、效果也更好。遇到相应任务时，务必考虑专用模型。

前沿开源模型。 Llama 4、DeepSeek V3 / R2、Qwen 3、Mistral Large。你可以通过推理服务商（Groq、Together、Fireworks）托管运行，也可以自托管。对于许多任务，它们的价格和质量已能与闭源前沿模型竞争；但在某些任务上仍有差距，尤其是长程推理。

这意味着：

• 系统中的所有调用不可能只靠一个模型。为了控制成本，必须进行路由（参见第5层）。
• 前沿水平每个季度都在变化。系统设计应支持更换模型，而不是锁定某个模型。
• 对许多生产用例而言，开源模型如今已真正可用，不再只是实验选项。

第2层：推理层

你的模型究竟在哪里运行？

闭源API服务商——OpenAI、Anthropic、Google。它们能让你最快投入运行，提供最强的模型和最高的可靠性。代价是支付溢价，并接受其数据处理与安全模式。

开源模型推理服务商——Groq、Together AI、Fireworks、Replicate。它们以不同的调优配置运行开源模型，通常比自托管快得多，价格也有竞争力。（这个市场整合很快：已有多家活跃于2024年前后的服务商不复存在；做出长期承诺前，请核实任何供应商的现状。）

云原生服务——AWS Bedrock、Azure OpenAI、Google Vertex。它们把闭源和开源模型接入你所用云平台的身份认证、计费与合规体系。在许多企业场景中，这是必需的。

自托管——在自己的GPU上运行vLLM、TGI、SGLang或LMDeploy。达到一定规模后，每token成本最低，但运维复杂度最高。通常只有当每月推理支出进入数千欧元的高位区间时，才值得考虑自托管（收支平衡计算参见自托管与托管对比文章）。

边缘侧 / 设备端——Apple Intelligence、MediaPipe、ONNX，以及通过Ollama或llama.cpp运行的GGUF模型。每次调用没有服务费用，但模型能力受限。对于范围明确的用例，这类方案正变得越来越可行。

需要权衡：

• 延迟很重要：语音智能体和对话式用户体验需要尽快输出首个token。Groq、Cerebras和设备端方案在这方面占优。
• 吞吐量对批处理很重要：如果要处理数百万条记录，你需要的是高吞吐量，而不是低延迟。
• 合规很重要：GDPR、HIPAA、SOC 2往往会决定你可以使用哪些服务商和区域。
• 供应商风险很重要：完全依赖一家服务商会形成单点故障。采用多服务商是良好的风险管理措施。

2026年常见的组合是：面向用户、质量要求最高的请求使用托管的闭源模型；量大且更看重成本的任务使用托管的开源模型；范围明确、对延迟敏感的功能使用设备端模型。只有当规模和经济性足以抵消运维负担时，才选择自托管。

第3层：工具与MCP

LLM单独能做的事情并不多。只有能够调用工具后，它们才真正实用。这些工具是你定义的函数，为模型提供访问数据、API和执行操作的能力。

原生函数调用。 所有主流模型都支持结构化函数调用API。你使用JSON Schema定义函数，模型决定何时调用，你执行调用，再把结果返回给模型。

MCP（Model Context Protocol）。 这是一种面向工具服务器的标准化协议，由Anthropic推出，如今已被包括OpenAI、Cursor在内的多方广泛采用。MCP服务器公开工具；MCP客户端（LLM智能体）连接服务器并使用这些工具。这样一来，工具实现便不再与任何特定模型耦合。

直接集成。 对于调用量大且目标明确的用例（例如对接特定CRM或数据库），直接编写适配器通常比开发通用MCP服务器更容易。

2026年的趋势很清楚：MCP正在胜出并成为标准。大多数新工具都应面向MCP开发；直接集成则仍适用于性能敏感的路径。

在实现中还要面对一些现实问题：

• 工具描述极其重要。 描述不清的工具无法被正确使用。编写工具的文档字符串（docstring）时，应像写提示词一样认真。
• 工具数量很重要。 可用工具超过50个的模型，不如只配备5–10个相关工具的模型表现好。应严格筛选。
• 错误处理很重要。 工具错误需要以结构化方式传达给模型，以便模型调整后续行动。
• 授权很难。 在多用户系统中让LLM针对不同用户拥有不同权限，并非易事。不要让LLM做授权决策；授权必须在工具封装层完成。

第4层：检索与记忆

LLM需要获取训练数据中没有的信息。这正是检索层的作用。

向量数据库。 Pinecone、Weaviate、Qdrant、Chroma、带pgvector的PostgreSQL、Turbopuffer。它们存储嵌入向量并提供最近邻查询，技术成熟、理解充分，是语义检索的默认选择。

混合检索。 把向量检索与传统的BM25关键词检索结合起来，同时捕捉语义匹配和词法匹配。可以使用Reciprocal Rank Fusion合并结果。相关工具包括Elasticsearch、OpenSearch、Vespa。

知识图谱。 Neo4j、Memgraph、自定义三元组存储。适合关系丰富的数据，并用于图RAG架构。构建工作量更大，但在高度依赖关系的领域往往能提供更高质量。

专用RAG平台。 LlamaIndex（现已成熟）、LangChain的RAG抽象、Haystack。它们为常见模式提供更高层级的框架。

重排序。 Cohere Rerank、Voyage、自定义交叉编码器。完成初步检索后，使用成本更高的模型对排名靠前的候选项重新排序，以提高准确率。通常能将检索质量提升到原来的2–3倍。

记忆。 智能体和对话可以采用结构化记忆层，例如Mem0、Letta（原名MemGPT）或自定义实现。需要区分短期记忆（当前对话）、中期记忆（近期主题）和长期记忆（有关用户或账户的持久事实）。

架构上的问题是：这一层应该放在哪里？

• 应用内： 由你的团队编写检索逻辑，将其封装在LLM调用外围。
• MCP层： 以工具形式提供检索能力。
• 作为服务： 由各个应用调用专门的检索服务。

对于单体、单产品系统，放在应用内没有问题。对于拥有多个产品的组织，把检索作为服务来提供，并统一质量标准和策略，会带来长期收益。

第5层：提示词与上下文工程

到了2026年，“提示工程”基本已等同于“上下文工程”，也就是管理每次调用放入上下文窗口的内容。

具体组成包括：

提示词。 通常使用带变量的模板，存放在版本控制系统中，通过评估套件测试，并像代码一样对待。

提示词管理。 可以使用Promptfoo、Langfuse、PromptLayer或内部系统，提供版本管理、A/B测试和回滚。（Helicone及类似的LLM代理属于下文的可观测性层，而不是这里；这两个类别很容易混淆。）

上下文策略。 决定每次调用要包含哪些内容：

• 系统提示词（稳定，用于定义行为）。
• 检索到的知识（动态，来自RAG）。
• 对话历史（经过管理，内容过长时通常会摘要）。
• 少样本示例（根据查询动态选择）。
• 工具描述（只保留相关工具）。
• 用户当前的查询。

上下文压缩。 上下文变长后，模型表现会下降。应对策略包括：摘要较早的对话轮次、把关键事实提取到结构化记忆中，以及裁剪无关内容。这仍是一个活跃的研究领域。

长上下文的使用。 当前旗舰模型（Claude、GPT-5.5、Gemini）普遍提供100万token的上下文窗口。这些窗口确实可用，但“上下文退化（context rot）”也真实存在：即使模型在技术上支持长输入，输入变长后质量仍会下降。请谨慎使用长上下文，不要仅仅因为放得下，就把所有内容都塞进去。

第6层：编排

如何协调多步骤LLM工作流和智能体？

直接调用API。 自己用Python或TypeScript编写循环即可。这最适合简单场景，也最有助于理解实际发生了什么。

LangChain / LangGraph。 使用广泛。LangGraph（用于智能体的状态机）已经成熟了许多。它的抽象层较重、学习曲线较陡，但功能强大。

CrewAI。 以基于角色的智能体为重点的多智能体框架。比LangGraph更容易上手，但灵活性较低。

LlamaIndex智能体。 尤其适合高度依赖RAG的工作流。

OpenAI Agents SDK。 更简单、更有明确取舍，并针对OpenAI模型进行了优化。

Anthropic Claude SDK。 与之类似，但针对Claude进行了优化。

自定义实现。 对于交付生产级智能体的成熟团队，自定义编排很常见。框架会带来额外成本，例如抽象负担、调试复杂度和版本频繁变动；这些成本可能超过框架的收益。

2026年常见的做法是：先用框架构建原型，再用自定义代码重写生产版本。框架帮助你摸清模式；掌握模式后，直接编写代码会更简单、更可靠。

第7层：可观测性

没有可观测性，就无法交付严肃的LLM应用。每个生产系统都需要：

追踪。 记录每一次LLM调用，包括时间戳、模型、输入、输出、延迟、成本和成功 / 失败状态；多步骤调用还要以树形结构呈现追踪记录。

成本追踪。 按调用、功能和用户追踪成本。成本很高，而且没有天然上限；如果不追踪，你只能到月底才发现问题。

质量监控。 对生产流量样本自动执行质量检查，并在质量下降时告警。

收集用户反馈。 包括赞 / 踩、明确的文字反馈，以及重试率、放弃率等隐式信号。

调试。 出现故障时，你需要查看完整的调用链。一次失败的智能体运行可能有多个故障点。

可选工具包括LangSmith、Helicone、Arize、Phoenix、Braintrust、Weights & Biases、Datadog LLM Observability。各有优势；应尽早选定一个，并持续使用。

对于小团队，即使只建一张简单的Postgres表，每次LLM调用写入一行记录，也能满足80%的需求。等到规模或功能需求确有必要时，再迁移到专用工具。

第8层：评估

这是严肃生产工作中最重要的一层。

离线评估。 使用定义明确的数据集、预期输出和评分方式，在部署变更前运行，用于发现回归。（我们已在中级内容中详细介绍过。）

在线评估。 对生产流量样本自动评分（由LLM担任评判者），或通过用户信号判断质量，用于发现漂移。

部署前评估。 任何提示词或模型变更上线前，都必须运行并审核评估套件，使之成为CI的一部分。

评估分类。 不同关注点需要不同的评估：

• 行为：是否按预期完成任务？
• 安全：是否拒绝了我们希望它拒绝的内容？
• 质量：输出有多好？
• 稳健性：如何处理对抗性输入？
• 成本 / 延迟：是否控制在预算范围内？

工具包括Promptfoo、Braintrust、LangSmith和自定义套件，各有适用场景；Promptfoo最容易上手。

第9层：应用层

你的具体产品位于这一层。这里需要做出的决策包括：

智能体还是工作流。 智能体（让LLM在循环中调用工具）功能强大，但更难保证可靠性。工作流（按固定顺序执行LLM调用）更容易实现，而且通常已经足够。默认选择工作流，确实需要时再使用智能体。

同步还是异步。 是面向用户的实时处理、后台批处理，还是流式传输？答案会影响模型选择、基础设施选择和用户体验设计。

单租户还是多租户。 客户专属的数据隔离要求会推动重大的架构决策。

本地部署还是云端部署。 合规、安全或成本要求可能会促使你采用本地部署，但其运维复杂度要高得多。

异常场景。 幻觉、提示词注入和滥用。生产系统必须设置防护措施，没有这些措施就不要上线。

真正重要的权衡

以下几项权衡值得明确讨论：

质量、成本与延迟

这是最根本的三角关系。通常可以优化其中两项，第三项则会变差。

• 高质量 + 低延迟 = 昂贵。
• 低成本 + 低延迟 = 质量较低。
• 高质量 + 低成本 = 高延迟（批处理或使用推理模型）。

应针对每项任务确定优先级。不要试图同时优化三者，否则只会让三方面都变得平庸。

自研还是采购

对于每一层，你都可以选择自研或采购。

• 自研： 控制权更多，维护工作更多，成本（工程师时间）更高，但可以构建差异化能力。
• 采购： 起步更快，控制权更少，持续面临供应商风险，但可以把非差异化能力交给外部服务商。

一个实用的经验法则是：采购通用基础层（向量存储、基础可观测性），自研差异化层（你的专用编排、提示词和评估）。反过来——采购差异化能力，却自建通用基础设施——是常见错误。

开源还是闭源

2026年的现实是：开源模型在许多任务上已经具备竞争力。有些任务上，它们表现更好（更快、更便宜）；另一些任务上，闭源前沿模型仍然领先，例如长程推理。

决策因素包括：

• 质量要求。 如果需要某项任务的最前沿水平，闭源模型仍然占优。
• 规模化成本。 调用量大时，自托管开源模型的成本会变得很低。
• 隐私 / 合规。 对于敏感数据，往往需要在自己的基础设施上自托管。
• 定制。 微调和自定义训练需要开源模型。
• 运维能力。 使用闭源API几乎没有运维负担；自托管则需要大量工作。

2026年的大多数生产系统都采用混合方式：根据每次调用的具体权衡，有些调用使用闭源模型，另一些使用开源模型。

延迟还是推理深度

推理层级（GPT-5.5思考模式、带自适应思考的Claude）在解决难题时以更高延迟换取更高质量。有时这种交换值得，有时用户无法等待30秒。

一种常见模式是：把简单查询路由到快速模型，把难题路由到推理模型，并使用路由器（小型模型或启发式规则）做出判断。

长上下文还是RAG

你可以把上下文直接塞进模型（使用100万token的窗口），也可以通过RAG检索相关片段。

• 长上下文：更简单，不需要检索基础设施，但每次调用更昂贵，而且确实存在“上下文退化”。
• RAG：每次调用更便宜，但前期设置更多，检索质量本身也是一个工程难题。

2026年较成熟的答案是：生产环境通常使用RAG；长上下文则用于原型、特殊的一次性任务，或检索质量差到会破坏结果的场景。

智能体还是工作流

前文已经讨论过。默认使用工作流；只有真正需要灵活性时才使用智能体。我们看到的许多所谓“智能体”系统，其实更应该做成工作流。

一套2026年参考架构

为了把上述内容具体化，下面是一个带有AI功能的中型SaaS产品通常会采用的生产系统：

User → Application (React/Next.js)
    ↓
API gateway / auth
    ↓
LLM Service (your wrapper)
    ↓
  Router (small model or heuristic)
    ├→ Simple tasks: a mid-tier model (Claude Haiku 4.5 class)
    ├→ Standard tasks: Claude Sonnet 5 or GPT-5.5
    ├→ Hard tasks: Claude Opus 4.8 or a reasoning tier
    └→ Special: vision/voice/embedding specialists
    ↓
Tool layer (MCP servers + direct integrations)
    ↓
Retrieval layer (Pinecone + hybrid + reranker)
    ↓
Observability (Helicone or LangSmith)
    ↓
Eval suite (Promptfoo, runs in CI)

每位活跃用户每月成本：通常为€1–10，具体取决于使用强度。 构建所需的工程时间：经验丰富的团队需要6–12周。 运维成本：低到中等，具体取决于流量。

常见问题

以下故障模式在生产级LLM技术栈中反复出现：

模式1：所有任务都使用同一个模型。 导致成本超支和质量问题。解决办法：路由。

模式2：没有可观测性。 无法调试、衡量或改进。解决办法：尽早添加观测能力。

模式3：没有评估。 质量在不知不觉中漂移。解决办法：从第一天起就建立评估。

模式4：被框架锁定。 调试LangChain或CrewAI变成一份全职工作。解决办法：除非框架节省的成本高于它带来的成本，否则不要使用；摸清模式后，改写为直接调用的代码。

模式5：自建本应采购的基础设施。 自建向量数据库？很可能是在浪费时间。自建可观测性系统？也很可能是在浪费时间。通用基础层应当采购。

模式6：采购本应自研的基础设施。 把提示词外包给第三方，把评估也外包出去。这些是你的竞争护城河，应掌握在自己手中。

模式7：忽视提示词注入。 生产系统接收用户提供的内容，却不做输入清理，风险很大；应尽早采取防护措施。

模式8：在高风险流程中盲目信任智能体。 让LangGraph智能体在没有人工审核的情况下批准退款，迟早会出问题。对后果重大的操作加入人工审核环节。

模式9：优化了错误的指标。 总成本明明主要来自工程时间，却只优化推理成本；或者用户根本感受不到差别，却执着于优化延迟。应衡量真正重要的指标。

模式10：没有多服务商方案。 主要服务商发生故障不是“会不会”，而是“何时”；如果没有后备方案，系统就会停摆。应提前配置后备方案。

三项有日期的预测（2027年年中再来验证）

预测很廉价；标明日期、可以证伪的预测却不是。以下三项预测，我们愿意公开接受事实检验：

1. 到2027年年中，欧盟托管的中端模型推理服务将实现具有实际意义的价格持平。 符合欧盟主权要求的算力正在快速上线，与美国区域端点相比的溢价也在缩小。如果实现价格持平，我们针对GDPR敏感工作负载的默认建议将从“采用混合方案并遮盖敏感信息”转为“默认采用欧盟托管”。置信度：中等。

2. 框架层会继续整合，协议层会继续胜出。 过去18个月里，Microsoft合并了旗下两个智能体框架，OpenAI则把独立的浏览器智能体产品重新并入ChatGPT；与此同时，MCP从一项公告发展为跨供应商的默认选择。我们会继续把集成工作投入协议（MCP、结构化输出），并保持编排框架可替换。置信度：高。

3. 小型模型路由将不再只是一种优化手段，而会成为默认架构。 如果旗舰模型价格保持不变，而小型层级持续进步，那么“所有任务都用旗舰模型”给人的感觉，将像云工程师眼中的“所有任务都用裸机”一样过时。置信度：对于关注成本的中小企业而言较高。

我们有意不预测模型排名。这里写下的任何具体排名，都会在本页面下次审核日期前过时。

把架构选对

2026年的LLM技术栈确实存在多个层次，而且每项选择都很重要。胜出的团队会：

• 理解完整的技术栈，而不只是自己接触的部分。
• 针对每次调用明确权衡质量、成本和延迟。
• 自研能够形成差异化的部分，采购无法形成差异化的部分。
• 从第一天起就建立观测能力，包括可观测性和评估。
• 保持灵活，做到模型可替换并支持多服务商。

落后的团队则选定一家供应商，把其API硬编码进系统，从不添加观测能力，也从不衡量效果；如今才发现自己的系统成本高昂、脆弱不堪，而且无法改进。

把架构选对，其他一切都会更容易。