Octafuse Gateway 2.1 发布：不只管大模型，Agent 的每一次工具调用也都管起来！

2026/8/2 23:48:18 拓冰建站浏览量

过去我们的 AI 网关，绝大多数的更新关注点在以下几个方面：

如何统一接入 OpenAI、Anthropic、Gemini 等协议
如何在多个 Provider 之间路由和故障转移
如何管理 API Key、预算、Token、成本与调用日志

但当 Agent 真正进入业务，模型调用只是链路的一部分。它还会搜索网页、抓取正文、做深度检索，甚至调用 AI 率检测等垂直能力。如果这些工具各自维护密钥、价格、账单和日志，系统很快又会回到“每接一个能力，就多一套烟囱”的状态。之前我们已经做了一些 Agent 工具的接入，但是对于统一管控还是远远不足。所以，Octafuse Gateway 2.1.0 的重点，就是把这些模型之外的 AI 能力也纳入网关。

开源地址：https://github.com/OctaFuse/octafuse-gateway

1. 新增 AI 率检测工具

在之前的版本中我们已经接入了 Web Search、Web Fetch、Web Deep Search 工具，每个工具都各自接了国内国外最知名的几家供应商，用户只需要去拿 Key 来配置就可以使用。

在这次的 2.1.0 版本中，我们有新增了一个常用工具：AI 率检测

实现端点：POST /v1/tools/ai-detection

调用方只需提交待检测文本，Gateway 会完成：

用户 API Key 鉴权
预算预检
长文本自动分段
调用当前启用的检测引擎
汇总整体评分与分段结果
成功后记录费用并扣减预算
写入统一请求日志

当前已实现腾讯云 TMS 引擎，计费按字符单元计算。技术分段与计费单元彼此独立，后续切换或扩展检测引擎时，客户端不需要跟着理解供应商细节。

在后面的版本中，我们会再持续接入更多供应商和其他工具，敬请期待。如果您也在用 Octafuse Gateway，并且希望增加什么好用的工具，也可以提交 PR 一起增强我们的工具引擎。

2. 四类 Agent Tools，开始使用同一套运营体系

目前 Octafuse Gateway 已支持：

Web Search：联网搜索
Web Fetch：网页正文抓取
Web Deep Search：搜索与正文读取一体化
AI Detection：AI 生成概率检测

它们统一使用 /v1/tools/* 对外提供服务，并共享用户鉴权、预算、计费、日志与审计能力。

对客户端来说，只需要一把 Octafuse 用户 Key。对运营侧来说，可以在 Admin 中分别配置每种工具的引擎、密钥和价格。

这意味着 Agent 不必再直接持有一组搜索服务密钥、一组抓取服务密钥和一组检测服务密钥。能力由 Gateway 管理，客户端只关心稳定的产品 API。

3. 一次工具调用，就能完成三个维度的账本记录

2.1.0 将 Agent Tools 的记账体系向 AI 模型路由的记账体系看齐，统一为三账本：

standard：目录标准价
metered：供应侧实际成本
charged：用户实际计费

只有 charged 会累加到用户的 budget_spent（用户已用额度）。

过去一句“这次调用花了 0.01”，很难说明它究竟是上游成本、公开售价，还是用户最终支付金额。现在三种口径分开记录，运营人员可以更清楚地看到：

上游实际成本是多少？
对外目录价是多少？
用户最终扣了多少？
单次调用留下多少利润空间？

这样用户业务系统可以更关注复杂的业务本身，对于模型、工具的使用和记账完全不用混入业务系统！

4. 门户可以先查价格，再让用户确认调用

2.1.0 为 Gateway 提供的工具引擎提供了一个只读接口：

GET /v1/tools/pricing

用户的门户、系统或客户端可以在发起工具调用前读取：

计费币种
工具计费方式
字符计费粒度
供应成本、目录价和用户价

该接口不会返回引擎密钥，也不会向客户端暴露当前 Active 引擎名称。客户端面向的是稳定的 Octafuse Tools 产品能力，而不是某一家供应商的实现细节。

5. Admin 不只是“能配置”，还要“能运营”

本次 Admin 同步增强：

Tools 配置页支持全局控制敏感凭证显隐
调用记录展示供应成本、目录价、用户计费与利润
Request Logs 区分 Agent Tools 与上游模型调用
日志展示实际引擎 Provider，便于运营排查
Playground / Simulator 支持 AI Detection 联调
删除仍被模型路由引用的 Provider 时会拒绝操作，避免误删造成断路由

从配置、测试，到真实请求、计费和日志核对，工具能力形成了更完整的管理闭环。

6. 为什么我们把工具引擎单独抽成一个包？

2.1.0 新增共享包 @octafuse/tool-engines。

Web Search、Web Fetch、Web Deep Search、AI Detection 的引擎客户端不再散落在 Proxy 内部，而是由 Proxy 和 Admin Playground 共同复用。

这项变化用户不一定直接看得见，却让后续新增引擎、测试能力和维护协议边界更清晰。Docker 构建也已纳入该包，并增加 docker-compose smoke workflow。

写在最后

2.0 解决的是“模型请求该怎么走”；2.1 开始解决“Agent 调用了什么能力、成本多少、该收多少、能不能审计”。

Octafuse Gateway 正在从一个多模型转发层，继续向可自托管的 AI 能力总控服务演进。

如果你的 Agent 已经不只会聊天，而是会搜索、抓取、分析并调用更多外部能力，那么这些调用也值得拥有统一的入口、预算和账本。