开源AI模型目录：35家厂商数据每天自动刷新|json|元数据|开源ai|自然语言

凌晨三点，你正在调一个多模型路由的Agent，突然发现Claude 4的context window参数和官方文档对不上。去GitHub翻issue？等回复要两天。自己爬API？各家格式五花八门。这种时刻，你最想要的可能只是一份自动更新、格式统一、能直接diff的原始数据。

今天有个团队把这东西开源了。不是浏览器，不是排行榜，是底层数据层——35家以上AI厂商的模型元数据，每天自动抓取，用TOML文件树铺在你面前，随时fork、随时覆盖、随时比对。

事件现场：一个Agent开发者的"数据焦虑"

项目发起人Best在搭建AgentOne时卡住了。他需要让产品支持"用户能调用任意厂商的任意模型"，但发现这件事的阻力不在技术，在数据维护。

成本、上下文窗口、支持的功能、模态类型——这些参数散落在各家API文档里，格式不统一，更新不同步。更麻烦的是，有些厂商今天改个定价，明天扩个窗口，后天加个新模型，手工维护等于给自己找了一份全职工作。

他看了现有的解决方案，都不太对味：

Models.dev体验不错，但数据覆盖和更新频率跟不上；其他渠道要么太碎片化，要么不是机器可读的格式。最终他决定自己造一个：一个像Models.dev一样易用、真正覆盖每家厂商、自动更新且考虑安全的数据基础设施。

这就是AI Model Directory的起源——不是为了做另一个模型浏览器，而是解决Agent开发中最无聊却最致命的一环：元数据同步。

核心图拆解：TOML文件树长什么样

整个项目的骨架可以用一张图概括：一棵按厂商和模型ID组织的TOML文件树，加上每天跑的GitHub Actions流水线。

数据路径是固定的：data/providers///index.toml。每个模型一个文件夹，每个文件夹一个TOML文件。这种设计的妙处在于可读性、可diff性、跨语言消费——Python、Rust、Go、JavaScript都能原生解析TOML，Git的diff能精确显示哪家的哪个参数变了。

如果官方数据有误或缺失，你可以在同一个目录下放一个metadata.toml做覆盖。下次自动刷新时，系统会合并你的覆盖而不是直接覆盖掉。这个细节很务实：承认官方数据会出错，给人工修正留一条低摩擦的通道。

流水线每天跑一次，每个厂商配一个adapter，负责对接该厂商的API或文档，把异构响应洗成统一schema。Schema覆盖的字段包括成本结构、上下文长度、功能标志、模态支持等——全是Agent做路由决策时需要的关键输入。

除了文件树，项目还自动生成两个聚合文件：data/all.json供完整拉取，data/all.min.json省带宽。后者只有几十KB，适合客户端直接嵌入。

目前收录的厂商超过35家：OpenAI、Anthropic、Google、xAI、Mistral、DeepSeek、Cohere、Perplexity、OpenRouter、Vercel、GitHub Copilot、GitHub Models、Hugging Face、Groq、Cerebras、Fireworks、Together、DeepInfra、Baseten、Novita、阿里巴巴、Inception、Venice、Chutes、Friendli……列表还在增长。

新增一个厂商通常只需要写一个adapter文件，社区可以通过issue或PR提交。

前端是赠品，但意外地好用

文件树是给机器用的，人类需要可视化。团队顺手做了一个浏览器：models.agent-one.dev。

界面是一张可排序、可搜索的表格，schema里的每个字段对应一列。搜索是跨维度的——厂商名、模型ID、功能标签、模态类型同时检索。排序支持任意列。点击直接跳转到厂商官网。

典型使用场景：筛选"支持推理+工具调用、输入token单价低于1美元的模型"。这种查询在分散的文档里要翻半小时，在这里点几下表头就行。

前端的存在验证了数据层的价值：当底层结构干净时，上层应用可以做得非常轻。表格加载的是all.min.json，纯静态托管，没有后端服务成本。

为什么这件事值得技术人关注

表面看这是个数据工具，但背后有三层信号。

第一层是Agent基础设施的成熟曲线。当开发者开始为"模型元数据同步"专门造工具，说明多模型架构正在从尝鲜走向生产。单一模型调用不需要这个，但路由、降级、成本优化、能力匹配——这些Agent核心能力都依赖准确的元数据。

第二层是开源数据层的稀缺性。模型厂商提供API，但元数据的机器可读形态是碎片化的。社区需要有人做"数据基础设施"的脏活，而且是用开放格式（TOML/JSON）、开放协议（Git）、开放协作（PR）的方式做。这比封闭的商业API目录更有长期价值。

第三层是GitHub Actions作为数据管道的范式。每天定时跑、版本控制、透明可审计、社区可分叉——这个模式正在被复制到更多需要"持续刷新"的数据集上。天气、股价、供应链、模型参数……任何需要"昨天和今天不一样"的数据都可以这么管。

项目目前的状态是"能用，且在快速迭代"。覆盖35家厂商是个不错的起点，但和OpenRouter这种聚合上百家的比还有差距。真正的考验是社区贡献的可持续性：当官方API变更格式时，adapter能否及时跟进；当小众厂商被收录后，能否维持更新频率。