过去我们的 AI 网关，绝大多数的更新关注点在以下几个方面：
- 如何统一接入 OpenAI、Anthropic、Gemini 等协议
- 如何在多个 Provider 之间路由和故障转移
- 如何管理 API Key、预算、Token、成本与调用日志
但当 Agent 真正进入业务，模型调用只是链路的一部分。它还会搜索网页、抓取正文、做深度检索，甚至调用 AI 率检测等垂直能力。如果这些工具各自维护密钥、价格、账单和日志，系统很快又会回到“每接一个能力，就多一套烟囱”的状态。之前我们已经做了一些 Agent 工具的接入，但是对于统一管控还是远远不足。所以，Octafuse Gateway 2.1.0 的重点，就是把这些模型之外的 AI 能力也纳入网关。
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 已经不只会聊天，而是会搜索、抓取、分析并调用更多外部能力，那么这些调用也值得拥有统一的入口、预算和账本。
欢迎 Star、试用和提交 Issue / PR。
点击加入交流群：为下半场做准备，开个 Agent Infra 交流群
《Octafuse Gateway 2.1 发布：不只管大模型，Agent 的每一次工具调用也都管起来！》 是转载文章，点击查看原文。
