8.0
热点
AI SCORE
工具产品2026-10-08 18:07
Treg：面向 Agent 工具的 OpenRouter，按需调用千款 API
dev.to · AI#Agent#API代理#开源
Editor brief · 编辑速览
Treg 作为统一代理层，让 Agent 按需付费调用 Semrush、Crunchbase 等工具，无需订阅，按次计费，已获 4779 star。
Agents 需要数十个 API 才能完成实际工作。Semrush 每月 $139，Crunchbase 每月 $99，Apollo 每个席位 $59。大多数团队不会为了单次 Agent 调用就购买这些订阅。Treg（4,779 星，GitHub Python 趋势榜第 8 名）解决了这个问题——它充当工具的 OpenRouter：一个基础 URL、一个 token、数千个按调用次数计费的端点，价格低至每次一分钱。
架构是一个中继代理，带有服务端凭证注入能力。你让 Agent 指向 treg.to，它在目录中搜索"反链数据"或"公司信息丰富化"，查看价格，然后发起调用。代理在服务端注入上游 API 密钥、OAuth token 或 CLI 凭证，而不处理 Provider 的 schema。Agent 永远不会持有密钥。如果你的团队已经拥有同一个 Provider 的密钥，则该密钥优先，调用不计入计量。
Treg 将工具分为目录工具和团队自有工具两类。
目录工具是 Treg 使用自己的密钥或通过已验证的公开路由服务的端点。代理持有 Provider 账户。你从预付余额中按次扣费。新验证账户创建合规团队时可获得 $1.00 免费额度。无需自行注册 Provider 账号。
团队自有工具是任何团队成员注册的内容：付费 API 账户、OAuth 连接、Vendor CLI 二进制文件（stripe、gh、vercel），或 SKILL.md 配方。使用自有密钥的调用优先于目录密钥，且永不计量。代理在运行时注入凭证，但不会对该调用计费。
这种分离解决了冷启动问题。Agent 可以在没有 Semrush 账户的情况下调用 Semrush。如果团队后续购买了 Semrush 订阅，只需注册一次密钥，每个团队成员的 Agent 都会自动使用。
代理在转发请求时不处理上游 API 的模型。它不解析查询参数、正文 schema 或响应结构，只知道在哪里注入凭证。
每个端点有一个或多个绑定。绑定是一条规则，说明"将此密钥注入请求的哪个部分"。例如：
单个请求可以携带多个绑定。需要同时使用 OAuth 和开发者 token 的端点会在服务端同时注入两者。调用方发送通用请求到 Treg，代理查找绑定、从保险库获取密钥、注入它们，然后转发请求到上游。
这种设计能够应对上游 API 变更。如果 Provider 重命名了参数或添加了新的认证 header，只需更新绑定即可。Agent 代码无需改动。
stripe、gh、vercel 等 CLI 工具是一等公民。代理不将它们包装成 REST API，而是直接运行 Vendor 二进制文件并在运行时注入凭证。
当 Agent 调用 CLI 工具时，Treg 执行以下步骤：
Vendor 二进制文件以原样运行。这避免了对每个 CLI 包装自定义 API 的维护负担。这也意味着 Agent 获取的是 CLI 产生的精确输出，包括错误信息和格式化内容。
凭证永远不会离开服务器。Agent 发送类似 POST /cli/stripe/customers/list 的请求，代理使用团队的 Stripe 密钥运行 stripe customers list 并返回 JSON。
计量边界很简单：目录调用使用预付余额，自有密钥调用不计量。
当 Agent 调用端点时，代理检查团队是否为该 Provider 注册了密钥。如果有，则使用团队的密钥，不计量。如果没有，则使用目录密钥并从团队余额中扣除调用费用。
价格按端点设置，而非按 Provider 设置。Semrush 反链调用可能花费 $0.05，Crunchbase 公司查询 $0.02，抓取调用 $0.01。目录在调用前会显示价格，Agent 可以决定是否继续。
$1.00 免费额度是验证账户创建合规团队时的一次性赠送。这防止了滥用，同时允许匿名验证调用。额度不可续期。消费完后，团队必须充值。
端点是 base_url 加上一个或多个绑定。绑定指定：
同时需要 OAuth 和开发者 token 的 Provider 绑定示例：
{
"endpoint_id": "semrush_backlinks",
"base_url": "https://api.semrush.com/analytics/v1",
"bindings": [
{
"secret_name": "semrush_oauth_token",
"target": "header",
"header_name": "Authorization",
"format": "Bearer {secret}"
},
{
"secret_name": "semrush_developer_token",
"target": "header",
"header_name": "developer-token",
"format": "{secret}"
}
]
}
当 Agent 调用此端点时，代理获取两个密钥、注入 header、转发请求。Agent 只看到 Treg 的 URL 和 token。
Treg 不管理 Agent 状态。它是一个无状态代理。每次调用都是独立的。Agent 负责维护对话上下文、工具调用历史和重试逻辑。
可观测性按调用维度记录。代理记录：
这些日志汇入仪表盘，展示每个团队的用量、每个端点的延迟、每个 Provider 的错误率。仪表盘不暴露上游 API 响应，只显示元数据。
代理不会重试失败的调用。如果上游返回 500，Agent 收到 500。如果上游超时，Agent 收到超时错误。重试逻辑属于 Agent 编排层，不属于代理。
代理强制执行三个边界：
保险库是独立服务。代理按需请求密钥，不在内存中缓存。密钥在静态和传输中均已加密。
代理不验证上游 API 响应。它原样转发。如果恶意上游返回任意数据，Agent 必须在使用响应前自行验证。
Treg 可自托管。参考部署是一个 Python 服务，包含：
代理是无状态的，可水平扩展。每个实例可以服务任意请求。保险库是唯一的有状态组件。
目录是一个 JSON 文件或数据库表。每个条目是一个带有绑定、定价和元数据的端点。目录可以在不重启代理的情况下更新。
treg.to 的在线实例运行在 AWS 上：
最大的运维风险是上游 API 变更。代理不处理上游模型，因此无法检测 schema 变更。如果 Provider 重命名了必需参数，在绑定更新前调用会失败。缓解措施是监控和快速绑定更新。
第二个风险是保险库可用性。如果保险库宕机，代理无法获取密钥。缓解措施是保险库高可用和短期密钥缓存。缓存是一种权衡：它减少了保险库负载，但增加了凭证暴露时间。
代理增加了延迟。每次调用都先经过 Treg 再到达上游。对于延迟敏感的工作负载，直接调用更快。对于 Agent 工作负载（设置时间和凭证管理占主导），代理胜出。
适合使用 Treg 的场景：
不适合使用 Treg 的场景：
架构设计清晰。 relay-without-modeling（不建模的中继）设计避免了对每个 API 包装的维护负担。两类工具模型解决了冷启动和团队共享问题。最大的运维挑战是保持绑定与上游变更同步。如果你能够快速监控和更新绑定，这个代理就是 Agent 工具访问的力量倍增器。