我怎样整理自己的 AI 工具链

从一张工具清单开始

2026 年初，我在 Linux.do 原帖里盘点过自己能用到的模型、订阅、API 和客户端。当时最直接的问题是资源很散：每个平台有自己的账号、模型名、额度、接口格式和使用限制。

继续增加工具并没有让事情更简单。我需要一条稳定的调用链，能把不同来源整理好，再交给日常使用的客户端和 Coding Agent。

我的日常 AI 调用链上游会变，分层方法尽量保持稳定

官方 API稳定、规则清楚

模型订阅通过官方客户端或授权接入

兼容接口补充模型与场景

接入层CLIProxyAPI

把适合代理的订阅整理成兼容接口

管理层NewAPI

统一渠道、模型映射、路由和调用入口

CodexClaude CodeCherry StudioOpenWebUI

出现问题时沿着“客户端 → 管理层 → 接入层 → 上游”逐层查看日志和返回。

官方 API 的规则和兼容性通常最清楚，适合对稳定性要求较高的任务。模型订阅往往绑定官方客户端或账号授权，其中一部分可以通过 CLIProxyAPI 整理成兼容接口。OpenAI-compatible 服务则用来补充模型和特殊场景。

这三类来源不能只看模型名称。服务条款、账号安全、上下文长度、工具调用、流式输出和错误格式都可能不同。我会先确认用途，再决定是否接入统一管理层。

我部署了两套 CLIProxyAPI 实例，用来处理不同性质的模型来源。它们把适合代理的订阅和客户端授权整理为兼容 API，再作为 NewAPI 的上游渠道。

这层最常见的问题来自登录态、授权过期、上游模型名变化和协议细节。排障时要先直接请求 CLIProxyAPI，确认它能否拿到上游结果；如果这里已经失败，继续改下游客户端没有意义。

CLIProxyAPI 是我部署和维护的开源项目。我做的是接入、配置、隔离不同来源和处理兼容问题，没有参与其核心代码开发。

NewAPI 位于调用链的中间。上游渠道接入以后，我在这里维护模型映射、路由、额度和统一的 API 入口。Codex、Claude Code、VS Code 插件、Cherry Studio 和 OpenWebUI 可以使用同一套管理层，再按任务选择不同模型。

这套结构减少了重复配置。上游变化时，我先在 NewAPI 调整渠道或模型映射，下游通常只需要保持稳定的地址和密钥。多个来源提供同类模型时，也可以分开观察错误和使用情况。

NewAPI 同样来自开源社区。我的经验集中在 Docker 部署、SQLite 数据备份、渠道维护、模型映射、协议转换和恢复流程。

写代码时我更常用 Codex 和 Claude Code，因为它们能直接读取仓库、修改文件、运行命令和检查结果。日常对话与多模型比较会使用 Cherry Studio 或 OpenWebUI。VS Code 插件适合轻量修改，也便于留在熟悉的编辑环境里。

我不会为了“统一”把所有场景塞进同一个客户端。管理层统一入口，调用端保留各自擅长的交互方式，这样更顺手。

后来我又整理过 OpenCode Go API 的调用。文档没有提供模型列表拉取，需要手动补模型 ID；DeepSeek 渠道接进 NewAPI 后，Claude Code 或 Claude Desktop 还出现过 400 错误。

我把请求拆到不同层测试，发现同一上游通过 CLIProxyAPI 的 OpenAI-compatible 渠道可以被 Claude Code 调用，继续套入 NewAPI 时还要选择合适的渠道协议。为了切换常用配置，我也试过 CC Switch 的本地代理模式。

这类问题没有一条永久有效的配置答案。模型 ID、客户端版本和协议实现都会更新。留下分层排查的过程，比记住某个临时参数更有用。

我通常从最靠近错误的一端开始：

每增加一层便利，也增加一层可能出错的位置。能直接调用上游时，我会先做一个最小请求，把故障范围缩小。

具体模型、额度和活动变化很快，我不会在这里维护价格表。长期需要维护的是账号登录态、渠道健康、模型映射、数据备份和服务升级。

长期不用的渠道会清理，零散旧 Key 不再当作重点资产。数据库与配置的备份要和恢复步骤一起记录。公开分享时只讲结构和方法，不公开真实账号、Token、调用地址和渠道清单。

这套工具链后来被纳入我的数字资产目录。相关服务在哪里、凭据记录属于谁、怎样恢复，都交给 Personal Ops Panel 管理。更完整的背景写在《我怎样盘点和管理自己的数字资产》里。