OpenAPI Gateway for Agent Products

面向内部 Agent 产品的鉴权、计费、限流、工具路由、trace、fallback 和 Prompt 批量评测。

Context#

OpenAPI Gateway 是面向内部 AI / Agent 产品的一层统一网关。它负责把内部模型服务、工具能力、解析服务和科研工作区能力暴露给上层产品，同时处理权限、额度、计费、限流、日志和观测。

它不是 BohrClaw。BohrClaw 是上层科研 Agent 产品，而 OpenAPI Gateway 是底层基础设施。

What it handled#

我参与和主导过其中一部分网关能力，包括：

• 鉴权；
• 产品分层；
• 计费和后扣费；
• Redis 滑动窗口限流；
• Coding Plan 配额；
• 工具路由；
• 日志和 trace；
• 灰度；
• fallback；
• Prompt 版本管理；
• Prompt 批量回归评测；
• 巡检和告警。

Billing and deadlocks#

一个很真实的问题是高频扣费。

某些解析服务或工具调用需要按量计费。如果每一次请求都实时扣费，在大客户高频调用时，中台数据库事务锁会变成瓶颈，甚至可能出现死锁风险。

后来我们引入更偏账单聚合的方式，把实时高频扣费压力转化为可统计、可审计、可核销的账单流。这件事让我意识到：AI 产品上线以后，系统问题经常不在模型本身，而在计费、限流、日志、事务和链路治理这些地方。

Observability#

Agent 产品链路很长。一个请求可能经过网关、模型服务、工具服务、计费服务、解析服务和业务服务。

如果没有统一 trace，很难知道到底是哪一层慢了、哪一层失败了、哪一层重试了。线上排障时，日志和 trace 不是锦上添花，而是基本生存工具。

Prompt evaluation#

我也参与过轻量级 Prompt 版本管理和批量回归评测能力。

Prompt 改动看起来像“改一句话”，但实际上它会影响真实产品效果。我们希望产品和运营同学在改 Prompt 后，能跑一批固定样例，看线上回答是否变好、是否引入新的失败模式。

这件事让我形成了一个判断：Prompt 也应该被当成工程资产管理，而不是只靠手感迭代。

What I learned#

Agent Gateway 真正难的不是转发请求，而是承接一个 AI 产品上线后会遇到的治理问题：权限、计费、限流、trace、fallback、prompt regression 和用户计划。

这些问题不一定出现在论文里，但会真实决定产品能否长期运行。