Agent 写得越来越顺手，卡住它的地方开始变成"手脚"：要搜网页、抓小红书、查一家公司、找一个人的联系方式、生成一段视频，每一件都对应一家 API，每一家都要单独注册、充值、拿 key、读文档、写适配。
Monid 想把这件事收成一个入口。它给自己的定位就一句话：OpenRouter, but for agent tools，给 agent 用的 OpenRouter。一个 base URL，一个 key，一个余额，背后是网页搜索和抓取、人物与企业数据、社交平台、评论与市场数据、视频图像和语音生成。
Monid 官方头图：OpenRouter for agent tools（图源：monid-ai/monid 仓库）
公司是旧金山的 Monid Inc，9 月 2 日上线，这次在 GitHub 开源了 monid 仓库，MIT 协议，686 星。
01Agent 怎么用它：三个动词，前两个免费
discover 和 inspect 免费，run 按次计费（图源：Monid README）
- ▪discover
：按"要干什么"搜工具，而不是按厂商名。它会把整个目录跨厂商一起排序，每个候选都带价格、实时健康状态、观测到的 p50 和 p95 延迟，还会给提示，告诉你哪个更便宜或更合适 - ▪inspect
：读这个接口的输入结构、价格和文档 - ▪run
：执行，从同一个余额里扣钱
以前一个项目用哪家搜索 API，是几个月前写代码时就钉死的，碰上哪家接进来就用哪家。Monid 让 agent 在调用的那一刻，对着整个目录去选。
接入方式有三种：一个 skill（在 agent 对话里说一句 set up https://monid.ai/SKILL.md）、一个远程 MCP 服务、一个命令行。Claude Code、Codex、Cursor、OpenClaw、OpenCode 都能用。
它的 SKILL.md 写得挺克制：如果你已经有某个服务的专用 MCP、自己的 API key 或现成流程，agent 应该用你自己的，别绕到 Monid 上花钱。Monid 只补你工具栈里的空缺。
02计费：钉在原始响应上
每个连接器在定义里声明自己的计费模型，三种：每次调用固定收费、按返回结果条数收费、按单位计费（比如每千字符、每秒视频）。
每个接口都走同一条流水线，计费在映射输出之前就结算
关键在结算的时机：引擎在原始响应上就把用量算清楚，早于任何输出映射，所以计费的依据就是真正从线上回来的东西。厂商报错、公司没匹配上、人没查到，这些都当作正常数据返回，按零结算。一个厂商的非 2xx 响应，在 Monid 里是数据，不是异常。
官网的收费说明也很直接：按次付费，每个接口标明单价，Monid 在底层厂商价格上加 10%，没有订阅，没有最低消费；请求没有真的给 agent 交付结果，就不收钱。新用户送 1 美元额度。
03开源的是哪一部分
README 说得很清楚：这个仓库是连接器层，也就是描述每个接口的那一套通用框架，包括怎么调、接受什么、返回什么、用量怎么算，以及跑这些定义的引擎。
一个连接器由两个声明式文件组成：provider 声明身份、认证方式和计费模型；endpoint 声明请求和输入结构。README 原话是："这就是全部约定。没有客户端，没有适配器，没有每个厂商各自的执行路径。"
定义编译成一个原子包，再链接成一个密封单元交给引擎执行（图源：Monid README）
编译时，定义里的函数被替换成内容哈希引用，每段源码只存一份，哈希同时兼做防篡改校验。引擎执行的是一个"密封单元"：这个接口的文档，加上它真正引用到的那几个函数，其他东西都不在作用域里。所以同一个产物能不改一行地跑在三个地方：本地用你自己的厂商 key，CI 里对着录好的响应回放、完全不联网，托管平台上则由传输层注入凭证，密钥永远不进引擎进程。
discover 的排序、健康度统计、余额和结算这些属于托管平台，不在这个仓库里。
04想把自家 API 上架，是一个 pull request
开源这一层，是为了把供给侧交给社区。你写好 provider 和 endpoint，录一份测试夹具，本地跑 deno task check && deno task test 通过，提 PR。合并后，你的接口就进了 discover，所有 agent 都能搜到、能付费调用。
而且这件事可以交给 agent 去做。仓库里有一份 AGENT.md，专门写给编码 agent 的说明：把它、你自家的 API 文档、connectors/exa/ 这个参考实现一起交给 Claude Code 或 Codex，它就能写出 provider、接口结构和测试。CI 只做类型检查加离线回放，所以写出来的东西要么符合约定、要么编译不过，人工 review 只需要看"描述得对不对"。Apify 上的 actor 更省事，有一条命令能读 actor 公开的输入结构，直接生成 zod 定义。
README 里有一句写给贡献者的建议：==把 meta.description 当成产品来写，因为对 agent 来说它就是产品==。这是 discover 排序的依据，也是 inspect 返回给 agent 读的内容。写清楚它真正能做什么、不做什么、什么时候该换另一个接口。
05装起来
作为使用方：
npm install -g @monid-ai/cli@latest monid setup monid discover -q "twitter posts"
作为贡献方（需要 Deno 2.x）：
git clone https://github.com/monid-ai/monid.git cd monid deno task check && deno task test # 类型检查 + 188 个回放测试，不联网
06数字对不上的地方
工具数量三处口径不一样：README 写"72 家以上厂商、2000 多个工具"，官网首页写"55 家以上厂商、1700 多个工具"，公开仓库里我数了一下是 31 家厂商、699 个接口。差距主要因为仓库只是连接器层，托管目录里还有没放进仓库的部分（比如大量 Apify actor）。引用时建议按"上千个工具"来说，别拿某个具体数字当定论。
07放到同一条线上看
之前写过的 open-connector 也做 agent 的工具接入，但路子不同：open-connector 是让 agent 用你自己的 SaaS 账号，你授权一次，密钥留在你的边界里；Monid 是 Monid 替你持有各家数据和 API 厂商的 key，按次转卖给 agent，赚 10% 的差价。前者是连接器网关，后者更像一个带结算的工具批发市场。
这个模式成立的前提是 agent 真的在运行时自己挑工具、自己花钱。Monid 押的就是这一点：以后 agent 需要什么工具，当场去市场上买，用完按次结账。
模型已经有了 OpenRouter，工具这一层的"路由 + 结算"才刚开始，谁先把计费做得让 agent 放心花钱，谁就能站住。
项目地址GitHub：https://github.com/monid-ai/monid官网：https://monid.ai给 agent 的 skill：https://monid.ai/SKILL.md
