AI Agent 接入几十个工具总要重写适配器？Monid 用一个路由层统一调用
当一个 AI Agent 需要搜索网页、抓取页面、查公司资料或生成媒体时，最容易失控的不是模型，而是工具集成：每接入一个供应商，就要写一套鉴权、请求参数、错误处理和价格记录。换供应商时，Agent 的工具定义也跟着改。
Monid 是一个 MIT 许可的 TypeScript/Deno 项目，定位很直接：做“面向 Agent 工具的 OpenRouter”。它把不同提供商的能力包装成统一目录，并在每次调用时按任务选择端点。项目 README 当前宣称目录覆盖 72+ 个提供商、2,000+ 个工具；这类数量会变化，实际接入前仍应以在线目录为准。
先理解它解决的是什么
传统接入方式通常是：Agent 绑定 search_google、search_exa、scrape_firecrawl 等多个工具，代码里还写死了供应商和鉴权。Monid 的思路则是把“供应商”和“端点”拆成声明式连接器：Provider 描述身份、认证和计费方式，Endpoint 描述 HTTP 请求、输入 Schema 和超时。
它还把一次调用拆成三个动作：discover 负责发现候选，inspect 查看某个端点的完整契约，run 才真正执行。README 明确说明前两个动作免费，run 按实际使用计费；发生供应商错误、查无结果等情况时，原始响应仍会按零使用量结算。
更重要的是，discover 不只是返回一个静态列表。它会综合候选端点的价格、实时健康状态以及观测到的 p50/p95 延迟，再给出更便宜或更适合的替代提示。这样，路由决策从“几个月前写进代码的供应商”变成“本次调用时的选择”。
本地跑通连接器与测试
Monid 的仓库要求 Deno 2.x。先取得源码并运行不依赖网络的检查：
git clone https://github.com/monid-ai/monid.git cd monid deno task check && deno task test
README 给出的测试流程包含类型检查和 188 个 replay tests，测试使用录制的 fixture，不要求 CI 持有供应商密钥。需要真实调用时，再将供应商凭据放入环境变量：
export TINYFISH_CREDENTIALS_API_KEY="your-provider-key"
deno task engine:run 'tinyfish#search' \
--query-params '{"query":"solid-state battery suppliers","domain_type":"news"}'
仓库同时提供目录浏览命令。它们适合先了解当前有哪些 Provider 和 Endpoint，再决定要不要把能力暴露给 Agent：
deno task catalog providers deno task catalog endpoints --provider exa deno task catalog endpoints --category web-search deno task catalog inspect 'exa#search'
示例中的密钥使用环境变量，而不是把真实令牌写进脚本。实际使用时不要把变量再赋值给自己；这里保留这种写法只是为了强调凭据来源应在 shell 环境中管理。
连接器为什么适合 Agent 生成
一个 Provider 的核心声明可以很短：
export default defineProvider({
name: "tinyfish",
meta: {
displayName: "TinyFish",
summary: "Zero-cost live-web search and clean multi-URL fetch.",
homepageUrl: "https://tinyfish.ai",
categories: ["web-search"],
},
auth: { inject: presets.auth.header("X-API-Key") },
usage: { model: { kind: UsageModelKind.FREE } },
});
Endpoint 再声明请求方法、地址、输入 Schema 和超时：
export default defineEndpoint({
meta: {
displayName: "TinyFish Web Search",
summary: "Search the live web, news, or research papers.",
categories: ["web-search", "news-search"],
},
endpoint: "/search",
request: {
method: "GET",
path: "/",
baseUrl: "https://api.search.tinyfish.ai",
},
input: { schema: { queryParams: zTinyfishSearchQueryParams } },
timeouts: { requestMs: 15_000, runMs: 20_000 },
});
这套结构的价值在于：Agent 可以根据 API 文档生成 Provider、Endpoint、输入校验和测试 fixture，而不是凭空编写一套私有工具协议。仓库的 AGENT.md 也把连接器格式、API 文档和参考实现作为交给编码 Agent 的输入。
和直接写 MCP Server 怎么选
Monid 并不是所有场景下都替代 MCP。若团队只维护一个内部数据库工具，直接写 MCP Server 往往更简单；若要把几十个外部 API 统一放进多个 Agent，声明式连接器和目录发现会减少重复工作。
| 场景 | 更合适的方式 | 原因 |
|---|---|---|
| 一个内部系统、少量固定工具 | MCP Server | 部署边界和权限更直观 |
| 多供应商同类能力 | Monid 连接器 | 可以按目录、价格和健康度选择 |
| 需要本地完全控制请求 | 本地适配器或 MCP | 凭据和流量不必经过第三方路由 |
| 需要让 Agent 扩展工具目录 | Monid | Provider/Endpoint 是声明式结构 |
Monid 的另一个工程化优点是计费模型写在连接器里。连接器可以声明按调用、返回结果或单位用量计费，执行引擎在原始响应层结算，再做输出映射。这比在业务代码里到处维护“这个供应商一次调用多少钱”更不容易漂移。
落地时的三个边界
第一，统一路由不等于供应商故障消失。外部 API 的限流、数据质量和区域可用性仍需监控；健康度与延迟只是选择依据，不是可用性保证。
第二，目录规模不是你应该一次开放给模型的工具规模。先按任务类别筛选，例如只暴露 web-search，再用 inspect 审核参数和权限，避免把大量相似工具塞进上下文。
第三，凭据注入必须单独审计。连接器示例使用 presets.auth.header 注入请求头，生产环境仍应确认密钥作用域、日志脱敏和失败重试策略。对于高风险写操作，建议先在本地或隔离环境中验证，再开放 run。
如果你的痛点是“每增加一个 API 就增加一套 Agent 工具协议”，Monid 值得作为路由层原型评估；如果需求只是几个稳定的内部函数，直接使用 MCP 或本地函数调用可能更轻量。