开发者在电脑上跑通了 GLM API，把 Key 和 Base URL 发给同事，然后宣布接入完成。

几天后，测试脚本、线上服务和定时任务都在使用同一把 Key。调用量增加了，却说不清是哪一个程序消耗的；有人修改模型配置，另一个项目也跟着出现异常。

这不是模型没有接好，而是测试配置还没有变成能够交付的项目配置。

对于通过 API 中转站使用 GLM 的团队，首次回答成功只是起点。真正上线前，还需要把模型、令牌、分组、费用和责任人对应起来。

一、先形成一张可以交接的连接记录

不要只交付“一个地址加一把 Key”。

建议至少记录：

项目应填写的内容
应用名称实际使用该接口的服务
环境开发、测试或生产
模型 ID请求里实际发送的 GLM 标识
请求协议Chat Completions 或其他已验证协议
Base URL当前客户端要求的基础地址
令牌名称便于识别的标签，不填写密钥明文
账户分组当前实际选择的分组
负责人排查异常与批准变更的人

模型展示名称不一定等于请求 ID。分组名称也不能代替模型名称。

对于基础 GLM 接入，可以沿用已有的 GLM API 集成教程，本篇重点是把已经跑通的配置交付给正式项目。

二、测试与生产使用不同令牌

统一账户不等于所有程序共用一把 Key。

可以采用这样的命名方式：

glm-support-dev
glm-support-staging
glm-support-prod

名称只是识别标签，真正的隔离来自分别创建的凭证及对应配置。

这样做的直接价值是：测试脚本需要停用时，不必同时替换生产服务的 Key；某个项目出现异常消耗时，也更容易缩小排查范围。

但要注意，不同令牌不一定拥有独立账户余额或独立上游容量。它们可以帮助区分凭证和用量，却不能自动视为完整的租户隔离。

如果团队需要不同付款主体、独立余额或更严格的组织权限，应进一步核对平台支持范围。

三、令牌能调用哪些模型，需要明确配置

Treerouter 的创建令牌文档列出了模型限制相关字段。

对于只准备调用 GLM 的项目，可以在控制台检查是否能够限制到项目实际需要的模型，并验证限制是否生效。

不要仅凭令牌名称包含“GLM”，就认为它只能调用 GLM。名称不会自动形成权限边界。

同样，应用配置里写了某个模型，也不代表令牌只能访问该模型。应用选择与凭证权限是两层不同的控制。

具体配置以当前账户界面为准；完成设置后，应做一个允许模型的成功测试，并在隔离环境里确认禁止范围不会被意外放开。

四、测试额度不能直接等同于人民币金额

文档接口中可能出现 remain_quota、unlimited_quota 等字段，但不能根据字段名称猜测计量单位。

一个原始额度数值，不一定代表同样数额的人民币、美元或 Token。

第一次配置时，更稳妥的方式是通过控制台明确显示的额度设置操作，再用一笔调用核对扣减。

额度限制也不能代替并发控制。即使设置了总额上限，同时在途的请求仍可能造成短时间消耗；实际限额执行方式应单独确认。

测试脚本本身也应限制样本数量和循环次数，不要把成本控制全部交给账户设置。

相关操作可以参考令牌参数说明。

五、分组和备用线路应该进入变更记录

中转账户里的分组通常影响请求可用范围或线路选择，因此它也是项目配置的一部分。

上线前记录当前分组。以后调整分组时，应像修改模型 ID 一样留痕，而不是把它当成与应用无关的后台操作。

如果配置了备用线路，还要确认：

  • 切换条件是什么。
  • 切换后模型身份是否保持。
  • 费用口径是否变化。
  • 日志中能否识别相关变化。

不要直接推断“备用线路”等于“备用模型”。

一次线路调整后，原来的文本测试可能仍然成功，但项目依赖的流式或工具能力仍应重新验证。

六、密钥放在服务端，交接记录只放标签

生产 Key 不应放进网页脚本、公共仓库或可以被客户端直接下载的配置文件。

对于后端服务，可以通过部署环境的密钥管理机制注入。例如，应用读取：

GLM_API_KEY
GLM_MODEL
GLM_BASE_URL

这三个变量名只是项目命名示例。

交接文档记录变量名称、配置位置和令牌标签，不复制密钥明文。团队需要替换凭证时，更新部署环境并确认服务已经读取新值。

浏览器需要调用模型时，应通过你自己的后端鉴权与转发，而不是把完整中转密钥交给每个访问者。

这属于应用部署设计，与模型回答能力无关。

七、上线验收要包含一笔可追踪调用

给测试请求一个应用侧记录编号，保存发送时间、请求模型、令牌标签、返回状态和可获取的响应标识。

随后在平台日志中找到对应调用，核对用量和扣费。

Treerouter 的用量查看说明介绍了如何展开单条日志。

如果平台没有提供可以直接对应的请求标识，可先使用独立测试令牌和短时间窗口完成核对。

不要在找不到对应关系时，直接用账户余额变化推断某一笔请求的费用。后台可能同时存在其他程序的调用。

八、Agent 项目还要增加一项真实功能验收

普通聊天项目可以先验证文字请求和业务输出。

Agent 项目则需要增加它实际依赖的能力，例如工具调用、流式结束状态或多轮历史。

如果问题发生在工具结果回传后，可以参考站内的 GLM 多轮工具调用排错文章。

Z.AI 的工具流式输出文档也可以作为上游接口行为的参考，但中转线路仍需要单独验证。

本篇不重新展开工具参数解析，交接时只需要把“哪些功能已经测过、哪些尚未测试”写清楚。

九、注册后先完成一份小型交付记录

准备使用 TreeRouter 接入 GLM 时，可以先注册账号，创建项目专用测试令牌，选定模型与分组，再完成一笔能够追踪的调用。

随后确认模型权限、额度设置、日志记录和项目必需功能。

正式交付的结果应该是一组明确配置：谁在使用、调用哪个模型、使用什么协议、费用在哪里查看，以及出现问题时由谁处理。

这比把一把测试成功的 Key 发进群里，更适合长期运行的项目。