Together AI 详解开源 AI 栈：从模型、推理到 harness 与 MCP

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

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

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

MIGHT 技术栈

该技术栈可以拆分为以下几个独立部分：

模型：负责解读你的请求并决定如何行动的部分。
推理：模型实际运行所在的基础设施与推理提供方。
网关与路由器：决定由哪个模型或提供方处理每个请求的层，在成本、速度和能力之间进行权衡。
框架：管理对话、为模型提供工具访问权限，并将其连接到你的代码库的应用程序。
工具（技能与 MCP）：告诉模型如何完成特定任务的知识，包括为模型和框架提供对相关上下文的访问。

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

新模型层出不穷。有些更快，有些更便宜，有些在特定类型的工作上表现异常出色。如果切换模型只需几分钟，而不是重建整个工作流，你就能真正去尝试它们。

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

模型

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

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

大型模型

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

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

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

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

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

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

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

小型模型

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

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

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

一个小型开放模型的例子是 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 密钥，指定一个模型名称，然后开始发送请求。像 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 会把这些文件的内容添加到与模型的对话中。

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

关键在于，模型并没有在搜索你的文件系统或执行 shell 命令。模型决定应该发生什么，而 harness 是让它发生的那个部件。

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

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

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

选择 harness

和模型一样，可供选择的 harness 列表也在不断增长。

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

在理念上也存在很大差异。

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

以下是一些支持开放模型的流行 harness：

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

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

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

工具（skills 和 MCP）

harness 还可以通过 skills 和 MCP 服务器进行扩展。这些是有用的附加组件，提供你的 harness 可以与模型共享的指令和工具。

Skills 是可复用的指令，用于告诉模型如何执行特定任务或使用特定工具。与其把所有内容都塞进一个庞大的提示词中，不如让 harness 在需要时加载 skills，从而为模型提供专门的知识，例如部署应用、审查代码或使用某个框架。你可以在 https://www.skills.sh/ 网站上发现社区 skills。

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

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

管理上下文

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

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

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

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

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

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

新会话

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

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

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

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

规划、实现与审查

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

较大的模型是出色的规划者。它们能够将开放式的提示词分解为定义明确且相互隔离的任务。

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

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

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

为实验而构建

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

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

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

开放技术栈

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

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

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

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

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

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