别让 Agent 挑 API：treg 把工具市场做成 OpenRouter

一个尴尬的现状

你想让 Agent 做一件很简单的事：给定一个域名，找出它的反向链接（backlinks）。

听起来简单，实际上你要在以下选项里做选择：

• Semrush：$139/月，API 需要企业账户申请
• Moz：$99/月，API 有配额限制
• Ahrefs：$99/月起，API 需要额外付费
• Majestic：$49/月，API 历史数据另算
• Ubersuggest：$29/月，API 功能有限

每个 provider 都要你注册账号、绑卡、读文档、生成 API key、写适配代码。Agent 想用其中任何一个，你得先替它把账号开好、key 配好、代码写好。如果 Agent 想同时用 3 个 provider 做交叉验证？你得重复 3 遍这个流程。

2026 年 9 月 22 日登上 GitHub Trending 的 treg 提出了一个简单粗暴的解决方案：别让 Agent 挑 API，让 Agent 搜任务。

treg 是什么

treg 的定位一句话说清楚：OpenRouter, but for agent tools instead of models。

OpenRouter 做的事是：一个 API 端点，一个 token，你就能调任何 LLM——GPT-4、Claude、Gemini、Llama——按调用计费，不用每个 provider 都开账号。

treg 做的事是：一个 API 端点，一个 token，你的 Agent 就能调任何工具——SEO 反链查询、公司信息查询、社交数据、爬虫、图片生成、视频生成——按调用计费，不用每个 provider 都开账号。

具体数字：3000+ 个 catalogued endpoints，60+ 个 provider，每次调用从 1 分钱起。

"按任务搜，不按工具搜"

treg 最核心的设计理念是这一句：Ask for the task, not the tool。

传统做法是：Agent 知道自己要用 Semrush 的 backlinks API，于是去翻 Semrush 文档，构造请求，处理响应。这要求 Agent（或者写 Agent 的人）知道每个 provider 的 API 细节。

treg 的做法是：

treg catalog search "backlinks for a domain"

treg 返回所有能做这件事的 provider，按价格排列。Agent 选一个，调：

treg call semrush.backlinks.domain --query domain=example.com

Agent 不需要知道 Semrush 的 API 长什么样，不需要知道 Moz 的 API 长什么样。它只需要知道"我想查反链"。treg 把"任务语义"和"API 细节"解耦了。

凭据阶梯：四层 fallback

treg 的另一个关键设计是"credential ladder"——当 Agent 调一个工具时，treg 按以下顺序找凭据：

1. 团队注册了自己的工具（team-owned tool）→ 用团队自己的 key
2. 团队存了 provider 的 secret → 通过虚拟工具注入
3. 都没有，但 endpoint 有验证过的公开路由 → 不需要 provider key，免费
4. 都没有 → 用 treg 自己的 key，从团队预付余额里扣

关键规则：团队自己的 key 永远优先于 treg 的 key。这意味着如果你已经有 Semrush 账号，把 key 配进 treg，调用走你自己的配额，treg 不收一分钱。treg 只在你没有自己的 key 时才充当"中间商"。

这个设计很聪明。它让 treg 既能服务"什么账号都没有的小团队"（用 treg 的 key，按调用付费），也能服务"已经有一堆企业账号的大团队"（用自己的 key，treg 只做路由）。

两种工具，一个 token

treg 把工具分成两类：

Catalog（目录）：treg 自己维护的外部 endpoint。3000+ 个，覆盖 SEO、社交、公司信息、广告、爬虫、图片/视频生成。用 treg 的 key 或你自己的 key 调。

Your own tools（你自己的工具）：团队成员注册的任何东西——一个付费 API 账号、一个 OAuth 连接、一个 vendor CLI（比如 stripe、gh、vercel）、一个 SKILL.md 技能包。

两种工具用同一个 token 访问。Agent 不用知道一个工具是"treg 目录里的"还是"团队自己注册的"——它只管调，treg 负责路由。

机器可读的账单

treg 对 Agent 友好的另一个细节：余额不足时返回 HTTP 402，body 里带：

{
  "balance_micro": 50000,
  "estimated_cost_micro": 200000,
  "topup_url": "https://treg.to/topup"
}

Agent 不用解析错误信息文本，直接读 JSON 就知道：余额 $0.50，这次调用预计 $2.00，充值去 topup_url。Agent 可以自己决定是停下来等人类充值，还是换一个更便宜的工具。

这种"机器可读的经济信号"是 Agent 基础设施成熟的一个标志。OpenRouter 对 LLM 调用做了类似的事，treg 把它扩展到了所有工具调用。

为什么现在出现

treg 出现的时机不是偶然。三个趋势交汇：

1. Agent 能力增强：Agent 现在能做复杂的多步骤任务，但每一步可能需要不同的外部工具。手动集成每个工具的成本太高。
2. MCP 标准化：Model Context Protocol 让 Agent 调用工具有了标准协议。treg 兼容 MCP，可以作为 MCP server 暴露给任何 Agent。
3. 工具市场碎片化：每个垂直领域（SEO、销售、营销、数据）都有几十个 API provider，每个都有自己的认证、配额、定价。这种碎片化让"统一路由层"成为刚需。

这和 2023 年 LLM 市场的情况很像——那时候有几十个 LLM provider，每个都有自己的 API，直到 OpenRouter 把它们统一了。现在工具市场走到了同样的拐点。

它没解决的问题

treg 不是银弹：

1. 中间商信任：你把所有 provider 的凭据交给 treg，treg 就成了单点信任。如果 treg 被攻破，所有凭据泄露。treg 的缓解措施是"凭据服务端注入，不传给客户端"，但 treg 服务器本身仍是高价值目标。
2. 延迟：所有调用经过 treg 中转，多一跳。对实时性要求高的场景，直接调 provider 更快。
3. 目录覆盖：3000+ endpoint 听起来多，但相比整个 SaaS API 市场（光 ProgrammableWeb 就列了 25000+ API），还是一小部分。
4. 价格透明度：treg 在自己的 key 上加价作为利润。这个加价幅度需要透明才能让用户信任。

一个类比收尾

treg 之于 Agent 工具，就像 Stripe 之于支付——在 Stripe 之前，接一个支付系统要和 Visa、Mastercard、PayPal、Apple Pay 各自对接，每个都有自己的协议。Stripe 把它们统一成一个 API。treg 把工具市场的碎片化统一成一个端点。

更深一层：treg 做的是"任务语义路由"。Agent 说"我想查反链"，treg 决定用哪个 provider。这和 LLM router 做的"prompt 路由到最合适的模型"是同一个模式——只是从模型层扩展到了工具层。

当 Agent 生态从"单 Agent + 单工具"走向"多 Agent + 多工具"，一个统一的工具路由层会成为基础设施。treg 是这个方向的早期实现。

项目地址：superdesigndev/treg
在线服务：treg.to
许可证：见仓库
语言：Python