Agent开始为‘工具‘付费了：Treg按次计费背后，API经济的新暗流

Agent开始为工具付费了Treg按次计费背后API经济的新暗流【免费下载链接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn项目地址: https://gitcode.com/GitHub_Trending/treg/treg当行业还在争论按 Token 计费与按席位订阅哪个更合理时另一套计费逻辑正在悄悄成型按调用一次工具计费。开源项目 Treg 把自己定位成OpenRouter for agent tools——模型路由网关负责把多个 LLM 统一到一个 Token 和一个 base URLTreg 则把同样的抽象搬到工具层一个 Token、一个 base URL调用 3000 外部 API 端点覆盖 60 供应商按次计费最低一分钱无需逐个注册供应商账号见 README.md。订阅制假设需求是稳定的月流量Token 计费假设成本正比于思考量而按次计费直接假设一次真实世界中的工具调用就应该是一笔可独立结算的经济活动。这篇文章从 Treg 的源码出发拆解这套按次计费引擎的真实运作方式——预授权reserve、结算settle、失败退款、机器可读的 402、以及供应商与网关之间那层隐形的加价margin并指出开发者最容易踩的账单陷阱。从模型计费到工具计费一次逻辑延伸模型计费的故事已经讲得很清楚GPT 时代之前算力是按小时租的之后推理变成每千 Token 多少钱因为 Token 是推理成本的最小可计量单位。工具调用则在另一端成本不发生在思考里而发生在动作上——查一次邮箱、抓一次广告、生成一段语音供应商按成功交付或每行数据收费。Treg 正是顺着这条线做延伸当 Agent 需要真实数据时它面对的不是一个模型 API而是一堆互相隔离的供应商账号——Semrush、Moz、Crunchbase、Apollo……这些订阅没有谁会为跑一次就买。Treg 把账号集中在自己这端按次转售。README 里写得很直白Ask for the task, not the tool——你不需要知道谁在卖背链数据也不需要持有对方的账号搜索你要做的事、读价格、调用README.md。由此形成两套工具、一个 Token 的分层目录CatalogTreg 用自有 key 或已验证的公共路由服务的外部端点。用团队预充值余额计费匿名调用免费新团队一次性送 $1.00。你自己的工具团队成员注册的付费 API 账号、OAuth 连接、供应商 CLI、SKILL.md。你自己的 key 永远优先于 Treg 的且这类调用永不计量。这第二层是关键Treg 不是抢订阅生意而是聚合订阅。自带 key 的调用走的是忠实中继faithful relay只改三类请求头密钥留在服务端注入README.md。按次计费的引擎先冻结、后结算、失败退款按次计费最核心的工程问题不是定价而是计费与结算的原子性一次调用从发起到返回之间余额可能变化、进程可能崩溃、供应商可能 429。Treg 用一套预授权-结算-释放reserve / settle / release的状态机来解src/treg/domain/money/init.pyreserve预授权按目录价冻结本次调用的预估成本余额同步扣减打开一个 Hold。扣减是一条条件 UPDATE——UPDATE org SET balance_micro balance_micro - :est WHERE id :org AND balance_micro :est——并发下由数据库决定谁拿到最后一个分钱避免了 SELECT-then-UPDATE 的竞态。settle结算按实际成本observed cost关闭 Hold消费积分块先消耗促销/推荐/赠金再消耗付费块把预授权额 - 实际额退还给余额。如果实际成本超过预估差额从余额补扣——下一次 reserve 才是闸门。release释放上游失败时全额退款。这套状态机有两个细节值得注意。其一所有金额都是整数 micro-USD1e-6 美元而不是浮点或分一次目录调用大约 600 micro$0.0006分根本无法表示单次调用浮点累加一年必然漂移。其二结算路径与计费路径在同一个事务里写 LedgerEntry且 Ledger 是 append-only——覆盖计费错误比覆盖账本容易得多。对 Agent 而言最直接的接口是机器可读的 402。余额不足时Treg 不是抛一句人话而是返回携带结构化字段的 402src/treg/application/call/reserve.py{ error: insufficient_balance, message: ..., balance_micro: 123456, estimated_cost_micro: 700000, topup_url: /app#billing, autotopup_enabled: true, provider: ..., endpoint_id: ... }这意味着 Agent 可以在不解析散文的情况下采取行动读balance_micro和estimated_cost_micro判断是否值得触发充值然后跳转到topup_url。计费从人在浏览器里看账单演进为程序在响应头里读账单。三种计费语义per_call、per_success、per_result按次计费听起来简单但一次的定义决定了成本结构。Treg 的目录价目表src/treg/domain/money/settlement.py区分了三种语义写在各供应商 YAML 的cost.type字段里per_call请求发起即计费无论结果如何。例如 Hunter 的邮箱验证hunter.people.email.verify——每次 0.5 验证信用点src/treg/catalog/hunter.yaml。per_success只有成功交付才计费miss 免费。Hunter 的邮箱查找hunter.people.email.find标注1 SEARCH credit, charged only when an email is found; a miss is freeAdyntel 的 Meta 广告库接口则把HTTP 204 定义为免费 miss 信号——One credit for a page with results; HTTP 204 misses are freesrc/treg/catalog/adyntel.yaml。per_result按返回的记录/行数计费例如 Akta 每 50 条评论 1.5 信用点。结算的判定逻辑集中在 src/treg/application/call/settle.py 的_platform_billable2xx 一定可计费4xx 只在per_call语义下、且拒绝原因是调用方输入问题400/404/422时才算钱5xx/3xx/网络错误一律不向调用方计费。被刻意排除的是一组不是调用方过错的状态码_NOT_THE_CALLERS_FAULT {401, 402, 403, 405, 407, 408, 429}——凭证被拒、额度耗尽、限流、超时供应商没有向 Treg 收钱Treg 就绝不该向团队收钱。注释里的判断非常直白charging here would pass OUR expired or over-quota platform key on to a team as real spend——把自家平台 key 的过期成本转嫁给客户是在把自己的坏账塞进别人的账单。为了把 per_result 算准代码甚至直接解析响应体数记录Bright Data 按实际交付的每 1000 条记录 $1.50计费且不返回费用字段只能靠数响应体里的 JSON 数组元素来结算——这个计数修复了一个 39 倍缺口三周内上游实际消耗 $13.61而因为每次 per_result 调用都按1 条记录结算只向团队收了 $0.35。代码注释把这个案例原原本本记录在案src/treg/application/call/settle.py。供应商与网关加价margin藏在哪里按次计费天然产生一个中间层问题谁在赚差价Treg 的答案在 src/treg/domain/money/init.py 的with_margin对任何原始供应商成本按platform_margin加成后向上取整never charge less than the call cost us。加价被应用在预授权和结算两个时刻而不是调用现场——这样每次 reserve/settle 的账目都记录当时生效的 margin费率调整无法追溯改写历史调用的价格a rate change cant retroactively rewrite what a call cost。但加价不是唯一的利益结构。真正的商业模式差异在于凭证阶梯credential ladderREADME.md团队自带该供应商工具 → 用自己的 key不计量团队存了该供应商密钥 → 注入虚拟工具都没有且端点有已验证公共路由 → 无供应商 key免费否则 → Treg 自有 key计入团队预充值余额。这套阶梯把网关转售和网关代管清晰分开自带 key 的调用是纯代理Treg 不碰钱只有用平台 key 的调用才走预授权-结算闭环。对想二次销售的 B2B 构建者Treg 还提供标签预算tag budget机制——调用方通过X-Treg-Meta传递归属标签预授权时按标签写入TagSpend行结算时把标签行从预估额挪到实际消耗额并标记 settled成为可开票依据src/treg/domain/money/init.py。换句话说按次计费不但能对终端客户计费还能把一次调用直接归因到哪个客户、哪个项目。资金侧则是经典的网关三角Stripe 授权支付、Ledger 记账、两边只通过ledger.topup(org, amount_micro, payment_ref)相交。有两个安全细节值得抄作业充值只认 Stripe webhook 回调不认浏览器 Checkout 返回——因为成功跳转 URL 是付款方能控制的把它当支付凭证等于允许任何人键入 URL 铸造余额自动充值auto top-up则由服务端持有 PaymentIntent 的确认状态立即入账且ledger.topup对 PaymentIntent id 幂等Stripe 的 at-least-once 投递重放同一个事件只入账一次src/treg/application/billing.py。自动充值本身被层层守卫需要记录 PSD2/SCA 授权合规要求而非复选框、每月上限、扣款前在 DB 里先打冷却时间戳防止双 worker 重复扣款、连续失败上限以及由阈值穿越派生的幂等键——并发调用同时发现余额不足时恰好只产生一笔扣款。开发者该警惕的账单陷阱按次计费把成本颗粒度降到一次调用但颗粒度小不等于风险小。从源码里能提炼出至少四类真实的账单陷阱陷阱一per_call 的 4xx 也是钱。在per_call语义下即使是供应商因调用方输入拒绝的 400/404只要不在豁免集合里Treg 也会结算。源码记录了一个真实事故Fiber 的 400 body/identifier Required 和 404 profile not found 曾在一周内向一个团队收了二十次 $0.04——因为 Fiber 对架构拒绝也照收钱而 Treg 的结算逻辑是供应商报告了费用才计费src/treg/application/call/settle.py。教训调用参数校验不是免费的尤其是在按次计费的 per_call 工具上。陷阱二per_result 的数数边界。当响应体无法解析时代码明确settle at the estimate——以预授权额为准而不是猜测一个行数。压缩响应gzip无法数行、异步任务返回snapshot_id时记录数为 0记录在下载快照时另行计费。这意味着同一个工具的账单可能依赖响应格式同样的请求formatjson与formatndjson的结算依据不同。开发者应当意识到per_result 不是返回多少就收多少这么直觉化。陷阱三隐形的 margin 与预估缺口。目录显示的价格通常是原始成本 margin后的数值但预授权与结算都应用 margin。当实际成本超过预估时差额直接从余额扣——the next reserve is the gate that stops an overrun from compounding。也就是说余额不足不等于调用失败可能是结算时追扣。对运行长任务async的 Agentsettlement 还区分terminal 响应与response 响应异步任务的 per_call 费用要等任务完成才结算任务永不完成则释放预授权。陷阱四免费午餐的配额是共享的。试炼池trial pool供应商用 Treg 的免费 key 以 $0 价格服务价格本身没有刹车——一个死循环的 Agent 会耗尽所有团队共享的供应商配额。因此试炼池有按团队、按 UTC 日的调用配额且fail-closed读不到当日用量就拒绝调用cannot verify the pool ⇒ do not drain it。共享免费额度意味着别人的失控就是你的 429。结语Treg 的按次计费在工程上给出了一套相当完整的答卷机器可读的 402、预授权-结算-释放的状态机、per_call/per_success/per_result 三种结算语义、append-only 账本与整数 micro-USD 记账、幂等充值与共享配额保护。它把工具调用从 Agent 的副作用变成了可计量、可归因、可转售的经济单元——这正是 API 经济从模型层下沉到工具层的暗流下一个改变成本结构的可能不是更强的模型而是更便宜的每一次动作。对开发者而言真正的功课在于读懂价目表语义per_success 的 miss 免费是设计per_call 的 400 也收钱同样是设计。【免费下载链接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn项目地址: https://gitcode.com/GitHub_Trending/treg/treg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考