就去挖那几家四类来源：两个第三方聚合站、一个智谱开放平台账号、还有一个本机自建的账号池。账单各记各的，调用方式却完全一样——都是 OpenAI 兼容的 `/v1/chat/completions`。

把它们收进同一个下拉框，靠的是客户端的一个配置文件：`~/.workbuddy/models.json`。每个条目九个字段，这次只聊其中两个：**`id` 和 `name`**。

## 两个字段，两套语言

看第三行和第四行：

```text
id:   cn:auto
name: 积分池-Auto(双池自动)
```

`id` 是给机器看的，`name` 是给人看的。下拉框里显示的是 `name`，所以我可以写中文，把这笔钱从哪来、会自动怎么走，都写在名字里——**选模型的时候不用猜**。

但机器不读 `name`。网关路由的时候只看 `id`：
```python
if model.startswith("cn:"):
    primary, pm = WB_POOL, model      # 花 WorkBuddy 积分
    backup,  bm = ZHIPU, FALLBACK[model]
elif model.startswith("glm-"):
    primary, pm = ZHIPU, model        # 花智谱 tokens
    backup,  bm = WB_POOL, FALLBACK[model]
```

看到问题了吗：**`cn:` 和 `glm-` 这两个前缀，本身就是路由规则的一部分。**

我当初给这两个字段起名的时候，并没有觉得在"设计"什么——`cn:` 表示"走 WorkBuddy 池"，`glm-` 表示"走智谱"，很直觉。但写到网关代码里才发现：**命名参与了调度。** 我改一个名字，钱的流向就变了。名字在这里不是标签，是凭据。

这就是我说的"不同而语"：

- **对机器**，`id` 是一个结构化标识，前半段是路由键，后半段是模型名；
- **对人**，`name` 是一句人话，说明这笔钱从哪来、挂了会怎样。

两拨读者，各取所需。如果只有一个字段，我就得在"机器好解析"和"人好看懂"之间妥协——要么名字里塞机器码，要么路由规则去解析中文。
## 一次请求，两级调度

`cn:auto` 这个名字还有一层意思：它根本不是真实模型，是个**代号**。

实测一次请求（今天下午，本机回环）：

```text
$ curl -X POST http://127.0.0.1:7865/v1/chat/completions \
    -d '{"model":"cn:auto","messages":[{"role":"user","content":"只回复两个字：收到"}]}'

→ 响应头 x-upstream: workbuddy-pool
→ 响应体 model 字段: hy4-preview
```

注意最后两行。我请求的是 `cn:auto`，响应头说这单花的是 WorkBuddy 池的钱，而**实际干活的是 `hy4-preview`**。

中间发生的事：账号池上游收到 `cn:auto` 这个代号，按三因子加权挑出当前有额度的 Top5 候选，再随机抽签选一个号，最终落到具体模型。也就是说，一次请求经过了**两级调度**——第一级按 `id` 前缀决定花谁的钱，第二级在池内决定花哪个号的钱。

而我在下拉框里看到的，始终是那个中文名字：积分池-Auto(双池自动)。**名字负责让我安心，代号负责让机器跑腿。**

## 名字会骗人：一次反向"修复"
这套设计我踩过一次坑，恰恰坏在"名字说了算"的思维惯性上。

前段时间我发现聚合网关（7865）挂了，顺手把 models.json 里两个条目的 `url` 从 `http://127.0.0.1:7865/v1` 改成了 `http://127.0.0.1:7863/v1`——直接指向账号池上游，绕开网关。

功能上，这是降级：自动切换没有了，`cn:` 和 `glm-` 的路由没有了，但至少能跑。

问题是**名字没改**。下拉框里依然显示"积分池-Auto(双池自动)"——一个承诺了"双池自动"的条目，实际只在走单池。每次选模型的时候，这个名字都在对我撒谎。

更讽刺的是备份文件名：`models.json.bak-20261026-port7865fix`。名字里带着 "fix"，但那次改动的方向是反的——把刚建好的调度层整个绕了过去。

今天下午，看门狗恢复上岗（新版心跳日志已经能同时看到三个端口：`7863=up 7864=up 7865=up`），我把两个条目的 `url` 改回了 7865，并用一次真实请求验证：

```text
x-upstream: workbuddy-pool
model: hy4-preview
```

这次名字和事实对上了。
**教训**：当 `name` 描述的是行为（"双池自动"）而不只是身份时，它就和 `url`、和上游的真实状态绑定了。改配置不改名字，等于给用户留一个过期承诺。要么名字只描述身份，要么改行为时必须同步改名字。

## 还有一个字段：`vendor` 一律填 `Custom`

顺手说下九个字段里最不起眼的那个。所有自定义条目的 `vendor` 都填 `Custom`——这是在告诉客户端："这不是官方内置模型，别去官方清单里校验我的 `id`。"

如果没有这个字段，客户端可能会拿 `cn:auto` 去官方模型库比对，比对不上就拒绝显示。一个字段，换来了"我的名字我做主"。

## 小结

回头再看这七个条目，设计要点就三条：

1. **`id` 是机器语言，`name` 是人类语言**，分离让两边都不用妥协；
2. **`id` 的前缀是路由凭据**——命名参与了调度，改名字就是改钱的流向；
3. **`name` 一旦描述行为，就和配置的真实状态绑定**——改配置不改名，名字就成了谎言。

一个 JSON 文件，两个读者。机器和人各说各话，事情反而跑通了——这大概就是"不同而语"的意思。

---

*本文所有配置条目、响应头与日志均取自实机（2026-10-26）。密钥字段已脱敏。*


就去挖那几家四类来源：两个第三方聚合站、一个智谱开放平台账号、还有一个本机自建的账号池。账单各记各的，调用方式却完全一样——都是 OpenAI 兼容的 /v1/chat/completions。

机器认 id，人认 name：我把路由凭据藏进了模型下拉框的一个字段里

id 是机器的路由凭据，name 是人的承诺。两者一旦混用，改名字就成了改钱的流向。

编程语言

利用OpenAI兼容网关，通过`models.json`配置文件将多个AI模型整合至统一下拉框。核心机制：`id`字段作为机器路由凭据（`cn:`前缀花积分池、`glm-`走智谱），`name`字段面向人类展示中文描述。一次请求经历两级调度，实际调用模型与显示名可不同。自定义条目需填`vendor:Custom`。注意：若`name`描述行为（如"双池自动"），改配置时须同步更新，否则名实不符。

代码解释

WorkBuddy 

路由

JSON

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

利用OpenAI兼容网关，通过`models.json`配置文件将多个AI模型整合至统一下拉框。核心机制：`id`字段作为机器路由凭据（`cn:`前缀花积分池、`glm-`走智谱），`name`字段面向人类展示中文描述。一次请求经历两级调度，实际调用模型与显示名可不同。自定义条目需填`vendor:Custom`。注意...

机器认 id，人认 name：我把路由凭据藏进了模型下拉框的一个字段里-腾讯云开发者社区-腾讯云

机器认 id，人认 name：我把路由凭据藏进了模型下拉框的一个字段里

机器认 id，人认 name：我把路由凭据藏进了模型下拉框的一个字段里

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐