开源 AI 技术栈

随着开源模型的质量逐渐缩小与闭源模型之间的差距，许多开发者和组织正寻求转向开源模型，以获得更强的自主权、控制力和经济效益。本文深入探讨了开发者在从闭源转向开源时所需要考虑的开放模型 AI 技术栈。

使用开放模型进行智能体软件开发，并不需要学习如何训练模型、购买一整架 GPU，或成为机器学习专家。从应用开发者的角度来看，这个技术栈与使用闭源模型惊人地相似。你有一个回答提示词的模型，以及一个管理你和该模型之间交互的框架。

如果你已经知道如何使用 Claude Code，那么你距离使用开放模型比你想象的要近得多。

MIGHT 技术栈

• 模型（Model）：解释你的请求并决定做什么的组件。
• 推理（Inference）：模型实际运行的基础设施和推理提供商。
• 网关与路由器（Gateways and routers）：决定由哪个模型或提供商处理每个请求的层，在成本、速度和能力之间进行平衡。
• 框架（Harness）：管理对话、为模型提供工具访问权限，并将其连接到你的代码库的应用程序。
• 工具（Skills 和 MCP）：告诉模型如何完成特定任务的知识，包括为模型和框架提供对相关上下文的访问权限

这些层彼此独立，这为每一层的技术决策打开了大门，使其更好地适配你的开发工作流。反过来，这也让你能够在新模型发布后立即进行实验。

新模型不断涌现。有些更快。有些更便宜。有些在特定类型的工作上异常出色。如果切换模型只需要几分钟，而不是重建整个工作流，你就能够真正地对它们进行实验。

在本文中，我们将逐一探索技术栈的每一层，解释它的作用，并研究如何对它进行定制。让我们从模型层开始。

模型

模型接收你的提示词，并基于其训练数据预测最可能的下一个 token 来生成回复。在我们的技术栈中，它充当智能层，负责推理、决策，以及决定在你的代码库中做出哪些更改。

模型有多种规模，一般来说，更大的模型往往具有更强的能力、更好的推理能力，以及在复杂任务上更可靠的表现。目前大多数领先的开放模型都是混合专家（MoE）模型，它们包含许多专门的“专家”，但在每次生成 token 时只激活其中一小部分。这使得它们可以拥有更大的参数量，但只激活较少的参数，因此运行所需的计算量更少。

大型模型

大型模型通常由其包含的参数量以及训练所用的计算量来定义。这些模型具有非凡的能力，能够从其训练数据中识别模式、关系和抽象概念。在实践中，“大型”通常也意味着该模型在更多数据上训练了更长时间，并使用了显著更多的计算资源。

这种额外的容量带来了几个重要的好处。大型模型往往更擅长多步推理，即需要同时跟踪多个约束条件，并做出依赖于问题早期部分的决策。这使得它们在面对模糊或描述不充分的任务时成为极佳的选择，因为它们能够利用更广泛的学习模式来填补缺失的细节。

Kimi K3 是一个很好的大型开放模型示例，它拥有 1.8T 总参数量和 104B 激活参数量。当你需要执行复杂任务时，可以选用像 Kimi K3 这样的大型模型，例如：

• 重构现有的认证系统
• 将你的代码库升级到新框架
• 审查拉取请求
• 理解为什么一个 SQL 数据库突然变慢了

大型模型的一个优势在于它们对不同类型工作的稳健性。它们可以在编写代码、解释系统、调试问题和规划变更之间切换，而不需要范围 tightly scoped 的指令。这使得它们在 agent 式工作流中特别有用，因为模型必须决定下一步做什么，而不是简单地遵循单一指令。

大型模型也能更好地利用较长的对话。当它们一次性获得许多文件、日志或信息片段时，能够保持连贯性，并在整个输入中连接相关细节。

这可能会让你认为更大的模型总是更好，但在实践中，大模型和小模型之间存在权衡。接下来，我们将看看选择小模型而非大模型的一些理由。

小模型

小模型和大模型之间的区别与其说在于质量，不如说在于它们能轻松处理多少模糊性。

当任务定义明确且范围 tightly scoped 时，小模型的表现可以与比它大得多的模型相当。如果你通过明确说明你想要什么来消除模糊性，它们会变得极其有效。

小模型擅长明确指定的工作，因为它们不需要猜测你的架构、推断隐藏需求，或探索多种可能的解释。它们只是按给定指令执行。

一个小型开放模型例子是 GLM 5.3 Flash，它有 320B 总参数和 18B 激活参数。与 Kimi K3 相比，它大约小 6 倍，便宜约 20 倍。

• 更新此函数以接受另一个选项。
• 为此文件编写测试。
• 解释一个特定错误。
• 审查这个 50 行的函数是否有 bug。
• 重命名此 API 并更新其调用方。

这些任务中没有太多模糊性。模型不需要对你整个代码库建立详细理解，也不需要在几种不同的架构方法之间做决定。

小模型最重要的优势是它们运行起来明显更快、更便宜。

它们生成每个 token 所需的计算更少。在实践中，这意味着更低的延迟响应和每次请求低得多的成本。对于许多日常编码任务，这种速度差异会立刻显现，因为模型响应迅速，迭代发生得更快，而且你可以负担得起反复运行它而不必担心成本。

与其认为更大的模型比较小的模型更好，不如把这些模型看作工具箱中两种不同类型的工具。

模型作为工具

更大的模型可能更可靠地解决问题，但它也可能慢好几倍或贵好几倍。如果一个小模型能正确地完成同样的单文件修改，那就几乎没有理由去用更大的模型。

随着时间推移，开始把模型选择更多地当作选择工具，而不是挑选赢家。

从几个大模型和小模型开始，通过反复使用了解它们的能力和局限。你很快会对你代码库中哪些任务可以委托给不同规模的模型形成看法。

接下来，我们将看看寻找模型的最佳去处。

选择模型

新模型每周都在发布，模型太多，你无法自己评估所有模型。

像 The Open Frontier 和 Artificial Analysis 这样的排行榜有助于发现有哪些可用模型，并大致了解模型在智能、编码能力、速度和价格方面的比较。

不要花太多时间试图找出排行榜上单一最好的模型。基准测试把大量行为压缩成一个分数，而你的实际工作负载要具体得多。一个总体排名略低的模型，可能非常擅长你每天做的那种编码工作。

作为参考，目前该领域最流行的开放模型是 GLM 5.3 Flash、DeepSeek V4 Flash、Kimi K3 和 MiniMax M3。不过这些变化非常快。

在你挑选了几个想尝试的模型之后，下一步是找一个托管这些模型的提供商。

推理提供商

由于开放模型并不局限于单一生态系统中，你可以选择在哪里运行它们。最简单的入门方式是使用云端推理提供商和云端网关。

这些提供商的工作方式是，你向它们发送 API 请求，它们在自己的 GPU 上运行模型。你为发送给模型的输入和模型生成的输出付费，按 token 计量。

这使得云端提供商非常适合实验。如果你想尝试一个新模型，可以创建一个 API key，指定一个模型名称，然后开始发送请求。Together AI 等提供商提供了庞大的模型目录，因此一个账号就能让你访问许多不同的大大小小的模型。

两个运行同一模型的提供商通常应该产生相似的结果，尤其是当你使用相同的模型版本和采样设置时。性能、价格、延迟和 API 功能可能有所不同，但底层模型仍然是同一个。

这种分离意味着，你可以因为喜欢某个模型的行为而选择它，然后根据价格或性能来选择提供商或网关。

网关和路由器

模型并非由所有推理提供商统一托管，这不幸地意味着你无法为每个模型都使用同一个推理提供商。网关和路由器通过让你跨多个推理提供商访问许多不同模型来解决这个问题。如果你想在闭源模型和开源模型之间进行路由，这尤其有用。

网关位于多个推理提供商之前，将它们聚合在一个 API 之后，让你能够跨不同后端路由请求、比较价格和延迟，并在不修改代码的情况下切换模型。它充当你和底层推理提供商之间的翻译与路由层。两个值得探索的流行云端网关是 https://openrouter.ai/ 和 https://vercel.com/ai-gateway。

你也可以使用 https://www.litellm.ai/ 之类的工具，在本地或自己的服务器上运行自己的路由器。这些路由器为你提供一个单一的 API 端点，让你能够在已经用多个推理提供商设置好的不同账号之间进行路由。

一旦你选好了推理提供商或云端网关，下一步就是设置你的 harness。

Harness

Harness 是技术栈中你直接交互的部分。它通常是运行在你电脑上的一个程序，位于你、你的代码库和模型之间。它维护对话，并为模型提供可以用来与现实世界交互的工具。

这个代码库中的认证是在哪里处理的？

Harness 把这个问题发送给模型。

模型可能会判断，要回答这个问题，它首先需要做的是在代码库中搜索 auth、session 或 login 之类的词。它通过要求 harness 运行这些搜索来作出回应。

Harness 在你的电脑上运行搜索命令，并把结果发送回模型。

基于这些结果，模型要求 harness 读取几个文件中的代码。Harness 把这些文件的内容加入与模型的对话中。

经过几轮这样的交互后，模型已经有了足够的信息来回答你的认证问题。它可以给出代码库中所有包含认证代码的文件和行。

重要之处在于，模型并不是在搜索你的文件系统或执行 shell 命令。模型决定应该发生什么，而 harness 是让它发生的那个部分。

这意味着编码 agent 的质量不仅仅取决于模型。

一个好的 harness 知道如何暴露工具、收集相关上下文、管理长对话、应用补丁、显示更改、在适当的时候请求许可，以及在命令失败时恢复。

同一个模型在两个不同的 harness 中可能会给人明显不同的感觉。

选择 harness

与模型一样，可选择的 harness 也在不断增加。

这些 harness 形式各异，包括基于终端的 CLI harness、在 IDE 内运行的编辑器扩展，以及提供更直观界面的网页或桌面应用。

它们在理念上也存在巨大差异。

一个 harness 可能提供数十种功能、集成、后台代理和项目管理工具。另一个则可能刻意只提供对话、shell 和文件编辑。两种方式本身并无优劣之分。

• PI: https://pi.dev/
• OpenCode: https://opencode.ai/
• Amp: https://ampcode.com/

大多数 harness 都能轻松地从一家提供商或模型切换到另一家。事实上，这往往是开源 harness 的一大卖点。切换模型通常只需一条命令或一次配置更改。

对于 Claude Code 和 Codex 这类闭源 harness，你可以使用 TogetherLink 等工具将它们连接到当今流行的开放权重模型。

选定 harness 后，下一步就是根据你的工作流对其进行定制。

工具（技能与 MCP）

Harness 还可以通过技能和 MCP 服务器进行扩展。这些实用的附加组件提供了 harness 可以与模型共享的指令和工具。

技能是可复用的指令，告诉模型如何执行特定任务或使用特定工具。技能无需将所有内容塞进一个庞大的提示词中，而是可以由 harness 在需要时加载，为模型提供部署应用、审查代码或使用某个框架等方面的专业知识。你可以在 https://www.skills.sh/ 网站上发现社区技能。

MCP 是 Model Context Protocol 的缩写，是一种通过通用接口将 AI 代理连接到外部工具和数据源的标准。这些服务器让 harness 能够与数据库、API、文件系统和开发者工具等交互，而无需为每一项单独构建自定义集成。你可以在 https://mcp.so/ 网站上找到现有的 MCP 服务器。不同提供商也有自己的 MCP 服务器。例如，Together AI 的在这里。

接下来，我们将探讨如何在 harness 中有效地处理上下文。

管理上下文

一旦你开始在不同模型之间切换，上下文就变得重要起来。

上下文是当前对话中与模型共享的一切内容。它包括你的提示词、模型之前的回复、harness 附加的文件、shell 输出、搜索结果、工具调用，以及会话期间积累的其他任何内容。

模型能够处理的上下文有上限。即使在达到这一硬性限制之前，非常长的对话也可能变得不那么有用。

一次编码会话可能从一项定义明确的任务开始，最终却积累出二十个文件、若干失败的尝试、数页测试输出，以及不再相关的讨论。

模型现在每次回复时都必须对所有这些内容进行推理。

改善模型输出最简单的方法之一，就是知道何时停止当前会话并开启新对话。

新会话

你能对代理工作流做的最简单的改进之一，就是更频繁地开启新线程。

例如，如果你完成了一项任务，请确保在开始下一项任务前开启新会话。或者，如果你尝试了一种方法，想从不同角度重新审视问题，那就重新开始。

如果你切换了模型，最好也在那里重新开始。

这是因为对话本身会影响模型处理问题的方式。一个新模型被放入漫长的调试会话中，会继承上一个会话的所有假设、实验和死胡同。

规划、实现与审查

一个值得尝试的工作流是将提示词分配到三个不同的模型中，每个模型都有特定目标。第一个模型负责规划，第二个模型负责实现，第三个模型负责审查。

更大的模型是出色的规划者。它们能够将开放式提示拆解为定义明确、彼此隔离的任务。

在此基础上，使用一个小模型，开始一次实现一个任务。为每个任务创建一个新会话，以保持上下文小而专注。如果某个任务对较小的模型来说过于复杂，就切换到更大的模型，让它完成工作。

最后，当任务完成后，可以让一个大模型审查所有工作。如果审查过程中出现问题，整个过程可以重复进行。可以根据审查反馈创建一个新的规划会话，使整个过程循环回到自身。

这种方法的一个好处是，你不需要把它变成一个正式系统。习惯于使用不同模型，可以让你在代码库中工作时，全天在规划、实现和审查之间快速切换。

为实验而构建

理解技术栈的各层，使你能够轻松尝试不同的模型、提供商和运行框架，而无需改变整个工作流程。在大多数情况下，替换模型就像更改一个配置值一样简单。切换提供商只是把同一个运行框架指向不同的 API 端点。甚至更结构性的变化，比如引入路由器或网关，也可以在不触及你实际日常工作方式的情况下添加。

这种分离消除了采用新模型时通常伴随的摩擦。你不必承诺使用单一系统，而是可以把模型视为稳定工作流中可互换的组件。你的运行框架保持一致，你的工具和快捷方式保持不变，只有底层的智能层发生变化。这使得在真实任务上试驾模型、在实践中比较成本和延迟，并逐渐建立对哪些模型最适合哪类问题的直觉变得很容易。

你可以通过升级模型、切换提供商或添加路由层来持续迭代你的技术栈，而不会在日常开发工作中失去势头。

开放技术栈

开放模型最令人兴奋的部分，不仅仅是你有更多模型可供选择。而是整个技术栈变得可组合。

你可以根据任务选择模型，根据价格和性能选择提供商/网关，根据你喜欢的工作方式选择运行框架，并用你的工作流所需的任何技能和工具扩展该运行框架。

例如，你的编码技术栈可以是：OpenCode 作为运行框架，在 Together AI 上运行的 GLM 5.3 Flash，用于构建出色 UI 的 grill-me 和 hallmark 技能，以及用于浏览器自动化的 Playwright MCP。

这些部分都不必来自同一家公司。如果下周出现了更好的模型，你可以直接替换它，而无需更换其他任何东西。对于开放权重模型，你还可以选择把模型带到别处，甚至自己运行它（甚至可以在自己的笔记本电脑上使用像 ollama 这样的工具运行）。

这就是开放模型更大的承诺。

你不必选择一个 AI 编码产品，而是可以构建你自己的 AI 编码技术栈。