如果你已经开始长期使用 Hermes、OpenClaw 这类 AI Agent，很快就会遇到一个现实问题：模型能接很多，但成本不太好管。
很多时候，真正浪费钱的地方不是"模型太贵"，而是不同难度的请求都被发给了同一个模型。简单问题用了大模型，复杂任务又缺少稳定的回退链路，最后的结果往往是：钱花了不少，但整体调用方式并不精细。
Manifest 想解决的，就是这件事。
它不是再包一层模型接口，而是把 Agent 和模型提供方之间的"分发逻辑"单独做成一个开源路由层：根据请求复杂度自动选模型，在失败时自动 fallback，同时把 token、成本和耗时记录下来。
一句话定位
Manifest 是一个面向个人 AI Agent 的开源 LLM 路由层，能根据请求复杂度自动选择更合适、也更省钱的模型，把模型成本控制这件事从"手动切换"变成"默认发生"。
基础信息卡片
| 字段 | 内容 |
|---|---|
| 项目名称 | Manifest |
| GitHub | https://github.com/mnfst/manifest |
| 官网 | https://manifest.build |
| 项目定位 | 个人 AI Agent 的开源模型路由器 |
| 核心能力 | 智能路由、模型分层、自动回退、预算限制、成本与用量追踪 |
| 支持方式 | Cloud 版本、Docker 自托管 |
| 开源协议 | MIT |
| 主要技术栈 | TypeScript |
| 适合搭配 | Hermes、OpenClaw，以及其他自主 Agent 框架 |
说明：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 安装方式，自托管也是它比较明确的使用路线。
典型步骤可以理解为：
-
- 按官方安装脚本或 Docker 说明部署 Manifest
-
- 打开本地面板并创建管理员账号
-
- 配置模型提供方
-
- 设置不同复杂度层级对应的模型和 fallback
-
- 把 Agent 的请求入口切到 Manifest
完成后，后续大部分收益都会来自日常自动路由，而不是频繁手动切换模型。
结论
如果把 Manifest 看成一个"再包装一层模型接口"的项目，会低估它。
它真正有价值的地方在于：把个人 AI Agent 的模型调用，从静态选择变成动态调度。
这件事听起来不像生成式 AI 那么显眼，但对长期使用者非常实际：
-
• 成本更容易压住
-
• 模型使用更有层次
-
• 失败时不容易整条链路中断
-
• 后续还能基于真实用量继续优化
如果你已经开始认真使用个人 Agent，而不是偶尔玩一玩，那 Manifest 很值得看。