manifest

🦚 Manifest：让 AI 模型自己"选对路"

想象一下这样的场景：你的 AI 应用每天要处理几千次用户请求——简单问答用 GPT-4o mini 就够了，但系统每次都调 GPT-4o，每个月账单惊人；或者你手头有个闲置的 Claude 订阅权益，却不知道怎么让它参与路由分配。Manifest 解决的就是这个问题——它是一个智能模型路由器，在用户请求到达时自动分析复杂度，然后决定"这条 query 该派哪个模型上场"。

图1：Manifest Web 控制台，支持 300+ 模型的可视化管理

背景故事：从"烧钱"痛点中生长出来的工具

Manifest 的诞生源于一个真实的工程困境：当 AI 应用接入多个模型供应商（OpenAI、Anthropic、Google、DeepSeek……）时，开发者面临两难——要么写死某个模型（省心但费钱），要么在代码里堆一堆 if-else 手动路由（灵活但维护成本高）。更麻烦的是，不同模型在不同时间段的定价、限流政策各不相同，靠人工跟踪几乎不可能。

Manifest 的团队（MNFST Inc.）认为，既然 LLM 调用本质上是一个"输入→路由→输出"的管道，那么路由层的抽象应该是基础设施的一部分，而不是应用层代码的负担。于是他们从 2024 年开始构建这个开源项目，定位是"AI 应用的流量调度层"。

它到底怎么工作的？

Manifest 的核心是一个 /auto 端点。当你把请求发到这个端点时，系统会做以下几件事：

第一步：复杂度评估。 Manifest 内置了一个分析器，会读取用户 query 的长度、是否包含代码块、是否要求多步骤推理，来判断这个请求的大致难度。

第二步：模型匹配。 根据预设的路由规则（比如"中文对话优先 Qwen"、"代码任务优先 Claude Sonnet"），结合各模型的当前可用性和成本，选择最优模型。

第三步：调用并返回。 透明地将结果返回给调用方，调用方无需知道背后用的是哪个模型。

这就好比一个五星级餐厅的前台接待：客人进门，接待员根据人数、特殊需求（忌口、预算）安排到合适的桌位，而不是让客人自己找座位。对于 AI 应用来说，这意味着开发体验接近单模型，cost 优化却是多模型协同的结果。

300+ 模型，一个统一入口

Manifest 目前支持 16 个主流 AI 提供商，涵盖：

• API Key 类：OpenAI（GPT-5、o4）、Anthropic（Claude Opus/Sonnet/Haiku 全系）、Google（Gemini 2.5）、xAI（Grok 4）、DeepSeek（V3/R1）、Mistral、阿里通义（Qwen3）、Moonshot（Kimi K2）、MiniMax 等
• 订阅复用类：ChatGPT Plus/Pro、Claude Max/Pro、Copilot 订阅，可用自己的账号权益
• 本地部署类：Ollama（任何 GGUF 模型）、LM Studio、llama.cpp，连接本地 GPU 资源
• 聚合平台：OpenRouter（300+ 模型统一路由）

所有这些模型，都通过同一个 /auto 接口对外暴露。 调用方无需关心背后选了哪个——一个 API Key，一个端点，N 个模型自动调度。官方声称最高可节省 70% 的 AI 调用成本，核心逻辑是让简单任务走便宜模型，复杂任务才动用高端模型。

成本追踪与告警：每一分钱都看得见

除了路由，Manifest 还内置了完整的成本追踪系统：

• 每个模型、每个 API Key、每个时间段的花费用可视化图表展示
• 支持设置预算阈值和告警通知（超过 $X 或 Token 用量超过 Y 时发邮件/Discord 通知）
• 路由失败时自动 Fallback 到备选模型（类似保险丝熔断机制）

对于 AI 应用的财务负责人来说，这意味着第一次有了实时、可审计的 AI 成本视图——而不是月底收到账单时才知道花了多少钱。

部署体验：零门槛自托管

Manifest 提供了两种使用方式：

云端版本（app.manifest.build）：注册即用，适合不想自己运维的团队。

自托管版本（Docker 一键安装）：一条命令即可部署完整栈，包含前端控制台、后端 API 和 PostgreSQL 数据库：

bash <(curl -sSL https://raw.githubusercontent.com/mnfst/manifest/main/docker/install.sh)

安装脚本会自动生成安全密钥、启动 docker-compose 栈，首次访问 http://localhost:2099 会进入设置向导，引导你创建管理员账号并配置第一个 AI Provider。

Docker 部署采用了多阶段构建（Stage 1 安装依赖 → Stage 2 编译前后端 → Stage 3 运行时精简），生产镜像基于 node:24-slim，同时通过 docker-compose 配置了资源限制（内存 1GB、PID 限制、日志轮转）和安全加固（read-only 根文件系统、cap_drop:ALL、no-new-privileges）。整个部署过程从拉取镜像到服务就绪约需 5-10 分钟，对技术团队来说非常友好。

技术架构：NestJS + SolidJS 的精妙组合

翻看 Manifest 的代码仓库，能看到这是一个 monorepo 结构，四个包分别是：

包	技术栈	职责
manifest-backend	NestJS + TypeORM + PostgreSQL	API 路由、模型代理、成本追踪、数据库持久化
manifest-frontend	SolidJS + Vite	Web 控制台、模型管理、成本可视化
manifest-shared	TypeScript 共享类型	前后端共享的 DTO、接口定义
manifest	（CLI 工具包）	manifest npm 包的遗留代码

后端选择 NestJS 并不意外——它适合构建企业级 API 服务，有成熟的模块化、依赖注入和装饰器模式。ORM 层用的是 TypeORM，数据库为 PostgreSQL。前端选择 SolidJS 相对小众但很有想法：相比 React，SolidJS 没有虚拟 DOM，运行时更轻量，对于一个内部工具类控制台来说，启动速度和交互流畅度优势明显。

值得注意的是后端依赖中包含了 @react-email/components——这是用来生成系统通知邮件（成本告警、验证邮件）的，配合 better-auth 处理认证。整个技术选型务实且专业，没有追赶最新 hype 的痕迹。

上手门槛与适用场景

维度	评估
部署难度	非常简单，Docker 一键，适合有 Docker 基础的团队
集成复杂度	需改造现有 AI 调用代码，将模型直调改为 /auto 路由调用
运维要求	低，PostgreSQL 数据有 docker volume 持久化
适用规模	中小型团队（个人开发者到百人规模 AI 应用团队）
不适合场景	对模型有严格合规要求（如金融、政务）或需要深度定制路由策略的企业

争议与局限

Manifest 也面临一些质疑和挑战：

路由透明度问题。 当一个请求被路由到"某个便宜模型"时，调用方无法控制具体选哪个。对于需要强一致性的场景（比如医疗、法律建议），模型选择的不确定性可能带来合规风险。

Fallback 机制的可靠性。 当主模型调用失败、切换到备选模型时，备选模型的能力边界和主模型可能差距较大，用户体验的一致性难以保证。

多 Provider 管理的密钥安全。 接入十几个 Provider 的 API Key 意味着攻击面扩大。虽然 Manifest 提供了加密存储机制（MANIFEST_ENCRYPTION_KEY），但自托管时仍需严格管理密钥轮换策略。

竞品的直接竞争。 OpenRouter、Portkey、Helicone 等平台也提供类似的路由+追踪能力，且部分已有更大的社区规模和商业化成熟度。Manifest 需要在路由算法的智能化、成本的透明度或开源优势上找到更强的差异化壁垒。

行业意义：AI 成本优化的基础设施

从更大的视角看，Manifest 代表了一个趋势：随着 LLM 调用成本从"尝鲜价"走向"生产级计费"，成本控制正在成为刚需。 2025 年以来，OpenAI、Google、Anthropic 纷纷推出更细粒度的 Token 计费模型，使得"模型路由"这件事从锦上添花变成了降本增效的必备能力。

Manifest 的开源属性让它在技术社区中具有吸引力——任何人都可以审计路由逻辑、部署自己的实例、甚至 Fork 一份做定制。随着 AI 模型数量继续爆炸式增长（目前已有 300+），手动管理模型选择将变得越来越不可持续，而像 Manifest 这样的智能路由层，有望成为 AI 应用架构中的标准组件。

图2：Manifest 亮色主题界面，路由规则配置面板

---

本报告基于 GitHub 公开信息和项目源码生成，仅代表分析时的认知状态，不构成投资或使用建议。