工作原理

跑在开源模型上

模型层如何与智能体层保持分离——能力探测、多后端路由，以及小型开源模型在工具调用上翻车的四种方式，网关都替你挡了。

这里的智能体不是照着某一个模型写出来的。智能体层需要的一切——对话、向量化、工具调用——都走一个说 OpenAI 兼容 HTTP 协议的网关，所以网关背后可以是一个托管的前沿模型 API、一个你自己跑起来的开源模型，或者几个同时用。

本页是这句话背后的工程细节。写它的原因很简单：「支持开源模型」这句话很好说、很难验，而正在评估平台的那个人，理应问一句凭什么。

网关

后端就是表里的一行行记录，按租户划定范围。每一行带着一个 base URL、一个 API 密钥、一个模型名、一个类型（chat 或 embedding）和一个权重。加一个或者换一个，是改配置——不用发版，也不用重写智能体。

整棵依赖树里没有任何厂商 SDK。网关发的是对着 OpenAI 兼容接口的普通 HTTP 请求，所以凡是实现了这套接口的东西——vLLM、Ollama、llama.cpp 起的服务、大多数商业 API——都不需要适配层就能用。

启动时，网关会对一个已启用的后端调用 /v1/models，把这个模型实际提供的东西读回来：上下文窗口、向量维度、声明的能力。

关于模型，没有一个数是写死的。这件事比听上去要紧：一个默认「窗口有前沿模型那么大」的平台，碰上 32K 窗口的开源模型会悄悄溢出，而故障露头的方式是一个被截断的、或者不知所云的回答，而不是一条报错。

如果某个后端不回应这次探测，网关会把窗口记为未知，并且拒绝去裁剪，而不是随手猜一个小数字。猜错了，就是无声地删掉了模型本来用得上的上下文；试了没成，起码是看得见的。

这些都不是假想出来的。每一种之所以被处理，都是因为它真的发生过。

很多开源模型无视结构化的 tool_calls 字段，改把调用写进回复正文。常见的有两种写法：

<tool_call>
  <function=search_docs>
    <parameter=query>refund policy</parameter>
  </function>
</tool_call>

<tool_call>
{"name": "search_docs", "arguments": {"query": "refund policy"}}
</tool_call>

不管的话，什么都不会被执行，而终端用户在对话框里看到的是一堆原始标记。工具循环会把这两种写法都解析掉，照常派发工具；作为兜底，文本发出去之前还会把任何残留的 <tool_call> 标记剥掉。原始的工具调用语法绝不能抵达终端用户，哪怕解析失败也一样。

各家 OpenAI 兼容服务端，对于怎么把工具调用切进流式分片各有各的做法。一次调用可能拆成好几段增量返回，模型一次请求多个工具时，这些片段还可能交错在一起。片段会先按索引累积、重新拼成完整的调用，然后才轮到任何工具执行。

可用的输入预算是推算出来的，不是配置出来的：

input_budget =
    probed_context_window − output_reservation − safety_margin

同时设了一个下限，免得一个过于激进的预留把预算压到零。在一个 32K 的模型上，这算出来的预算和百万 token 的模型完全不同——而这正是全部意义所在：同一份智能体定义，在两边都跑得对。

在会先输出推理、再给最终答案的模型上，一个只按答案大小估的输出预算会被推理吃光，用户收到的是一段被截断的回复。所以输出额度会为推理 token 相应调高，好让答案本身活下来。

同一类型的后端按权重选取，所以流量可以分流——比如大部分请求打到一个自建的小模型，剩下的打到一个更强的托管模型。当一次请求以可重试的方式失败时，网关会先在其他符合条件的后端上试，之后才退回到对着手上这个做指数退避。

现实中好用的分法是看后果，而不是看难度：只读、低风险的活儿交给便宜的模型，凡是要写入或者要落定的，交给强的那个。

把边界说清楚，比列一张更长的功能表有用：

它不会让小模型变得和大模型一样能干。 工具选择——在一个乱糟糟的多步场景里判断该调哪个工具、传什么参数——最能拉开模型质量的差距。把高后果的工作挪到更小的模型上之前，先拿你自己的任务测一遍。
它不替你运维推理基础设施。 自建的话，GPU 容量、模型服务和它的可用性都归你。网关会绕开一个挂掉的后端，但它没法让一个后端变快。
它不认证具体的模型。 兼容性工作针对的是模型会产出哪些形态，不是一份测过的名单。任何 OpenAI 兼容端点都应当能用；至于哪个模型适合你的负载，那是一次该由你自己跑的评测。