Manifest：帮个人 AI Agent 降低模型成本的开源路由器

如果你已经开始长期使用 Hermes、OpenClaw 这类 AI Agent，很快就会遇到一个现实问题：模型能接很多，但成本不太好管。

很多时候，真正浪费钱的地方不是“模型太贵”，而是不同难度的请求都被发给了同一个模型。简单问题用了大模型，复杂任务又缺少稳定的回退链路，最后的结果往往是：钱花了不少，但整体调用方式并不精细。

Manifest 想解决的，就是这件事。

它不是再包一层模型接口，而是把 Agent 和模型提供方之间的“分发逻辑”单独做成一个开源路由层：根据请求复杂度自动选模型，在失败时自动 fallback，同时把 token、成本和耗时记录下来。

一句话定位

Manifest 是一个面向个人 AI Agent 的开源 LLM 路由层，能根据请求复杂度自动选择更合适、也更省钱的模型，把模型成本控制这件事从“手动切换”变成“默认发生”。

基础信息卡片

说明：Star、Fork、活跃度这类数据会持续变化，阅读时请以 GitHub 仓库实时信息为准。

解决什么问题

现在很多 AI Agent 在调用模型时，常见做法其实比较粗暴：

• 要么所有请求都走同一个模型
• 要么手动在便宜模型和大模型之间来回切
• 要么把路由能力直接交给第三方代理平台

问题在于，Agent 的请求天然不是同一种难度。

有些只是简单问答，有些是多步推理，有些是代码、视觉、长上下文任务。如果所有请求都默认走高价模型，成本会很快失控；但如果一味追求低价模型，又会在关键任务上掉质量。

Manifest 想解决的，就是让个人 Agent 也能像成熟系统一样，根据请求复杂度自动选模型。

它的价值不在于“再包一层 API”，而在于把日常最费钱、也最容易被忽略的那一步做成基础设施：

• 简单请求走更快、更便宜的模型
• 复杂请求走更强的模型
• 某个模型失败时自动切到后备模型
• 全部调用过程都能在面板里看到成本、token、耗时和使用情况

如果你平时已经在用多个模型供应商，或者本身就有订阅型模型额度，这类路由层的价值会非常直观。

核心功能

1. 自动判断请求难度，再分配到合适模型

Manifest 的核心不是“模型聚合”，而是“模型分配”。

根据官方说明，它会在每次请求进入时做一次本地评分，并把请求划分到不同层级，例如 simple、standard、complex、reasoning，再路由到对应模型。

对个人用户来说，这件事最直接的意义是：

• 你不需要每次手动想“这一问值不值得上大模型”
• Agent 也不必把所有任务都交给最贵的那一个
• 模型使用变得更像一个自动调度系统，而不是一个固定开关

真正影响长期成本的，往往不是你接了多少家，而是有没有把不同难度的请求分开处理。

2. 支持多层模型回退，不把稳定性压在单点上

除了选模型，Manifest 还强调 fallback。

你可以按层级设置多个候选模型。当首选模型异常、不可用或效果不理想时，请求可以继续回退到下一层备用模型，而不是整条链路直接中断。

这对 Agent 场景尤其重要，因为 Agent 一旦进入多轮任务，单次失败带来的损失往往不是“一次回答没出来”，而是整个流程被打断。

从产品角度看，Manifest 做的不是“给你更多模型”，而是把模型调用从“单点依赖”升级成“可调度、可容错的执行链路”。

3. 内置成本、token、时延追踪

很多人知道自己“模型费用越来越高”，但不知道高在哪。

Manifest 把这一层可视化做成了默认能力。根据官方资料，路由过程中会自动记录：

• 使用了哪个模型
• 消耗了多少 token
• 调用耗时多久
• 每次请求大概花了多少钱

这意味着你不只是“省钱”，而是能进一步看清：

• 哪类任务最消耗预算
• 哪些模型用得最多
• 哪个供应商性价比更高
• 哪些请求其实没必要走高阶模型

对于已经把 AI 工具纳入日常工作流的人，这类数据面板通常不是锦上添花，而是后续持续优化的前提。

4. 同时照顾云端使用和本地自托管

Manifest 目前提供两种典型使用方式：

• 直接使用官方 Cloud 版本
• 用 Docker 自托管部署

如果你更关注上手速度，Cloud 版本会更省事；如果你更关注控制权、链路透明度和本地数据边界，自托管会更有吸引力。

从官方文档和 About 页面可以看到，这个项目非常强调“个人可控”这件事。它把自己和传统第三方云代理服务做了明显区分：

• 开源
• 可自托管
• 路由逻辑透明
• 更强调个人 Agent 的使用场景

对很多重度用户来说，这种差异比“是否再多支持几家模型”更关键。

5. 对个人订阅和多供应商组合更友好

Manifest 一个比较有意思的点，是它不是只围绕 API Key 思路来设计。

官方资料里明确提到，它既支持连接多个主流模型提供方，也支持复用部分已经付费的订阅型入口。对于已经同时购买了不同模型服务的人，这会更容易把现有资源整合起来，而不是重新回到单一平台里重复付费。

如果你已经在 OpenAI、Anthropic、MiniMax、OpenRouter 或本地模型之间切换，这类统一路由层会比“再买一个聚合平台”更像真正可长期使用的基础设施。

适合谁

1. 已经在长期使用个人 AI Agent 的用户

如果你已经把 Hermes、OpenClaw，或者其他 Agent 工具接进自己的日常工作里，那 Manifest 的价值会非常直接。

因为你真正要解决的，不再是“能不能调用模型”，而是：

• 怎么控制长期成本
• 怎么避免每个任务都走高价模型
• 怎么在多个提供方之间保持灵活性

2. 同时在用多个模型供应商的人

如果你手里已经有多家 provider 的 API Key，或者本来就会混合使用不同模型，那你很容易遇到一个问题：模型很多，但调度很乱。

Manifest 更像是把这些分散资源收拢成一层统一入口，让调用逻辑变得更稳定、更有章法。

3. 想自托管 AI 基础设施的个人开发者

如果你不想把所有请求都放进第三方黑盒代理里，又希望保留完整的使用追踪、预算控制和回退能力，那这种可自托管的路由层很有吸引力。

它不是大而全的平台，而是一个比较清晰的中间层：只解决“请求该发给谁、怎么追踪、怎么控成本”这件事。

快速上手

Manifest 的上手路径并不复杂，重点是先把它放到 Agent 和模型提供方之间。

方式一：直接使用官方 Cloud

去官网注册后，把 Agent 的模型入口接到 Manifest，再把你已有的 provider 配进去，就可以开始使用它的自动路由能力。

适合想先验证效果、尽快体验的人。

方式二：Docker 自托管

官方目前主推 Docker 安装方式，自托管也是它比较明确的使用路线。

典型步骤可以理解为：

1. 按官方安装脚本或 Docker 说明部署 Manifest
2. 打开本地面板并创建管理员账号
3. 配置模型提供方
4. 设置不同复杂度层级对应的模型和 fallback
5. 把 Agent 的请求入口切到 Manifest

完成后，后续大部分收益都会来自日常自动路由，而不是频繁手动切换模型。

结论

如果把 Manifest 看成一个“再包装一层模型接口”的项目，会低估它。

它真正有价值的地方在于：把个人 AI Agent 的模型调用，从静态选择变成动态调度。

这件事听起来不像生成式 AI 那么显眼，但对长期使用者非常实际：

• 成本更容易压住
• 模型使用更有层次
• 失败时不容易整条链路中断
• 后续还能基于真实用量继续优化

如果你已经开始认真使用个人 Agent，而不是偶尔玩一玩，那 Manifest 很值得看。