AI 网关和 AI 资产治理，有什么不一样？

[01men]

AI 网关和 AI 资产治理，有什么不一样？

上周有人问我一个问题，问得很直接：

「我装了 LiteLLM，也有审计日志，你说的『AI 资产治理』到底多管了什么？」

这个问题不好答，因为大部分回答会滑向营销话术。我试着用我们自己踩过的坑来拆。

先说结论：网关管一次请求，治理管一个资产的整个生命周期。 两者不竞争，但也不是「加了网关就顺便有了治理」——中间有三处结构性断点，网关按设计就不该去补。

网关的模型：请求进来，请求出去

看任何一个 AI 网关的架构图，主轴都是一条线：

client → [鉴权 / 限流 / 路由 / 预算 / 日志] → 上游 provider

LiteLLM、Portkey、Higress、Bifrost 都是这个形状。它们的核心抽象是一次调用（call），围绕这次调用做：

• 这个 key 有没有额度
• 这个模型能不能用
• 这次调用花了多少 token
• 上游挂了要不要降级到备用渠道

这些我们都做了，而且做得不浅。我们的模型网关里，一次调用要过四道：

1. 数据分级路由——渠道登记 dataClassLimit（公开 / 内部 / 秘密）。会话带 dataClass=secret 时，候选渠道按分级上限过滤，涉密数据永远不会路由到公开级渠道，越级直接锁死并给原因
2. 降级链——渠道组按 主 → 备1 → 备2 → 人工 逐级降级，每步 8 秒超时，HTTP 5xx / 超时 / 网络错误触发，每次降级 emit modelgw.degraded 事件
3. 预算熔断——org 级或 agent:<id> / app:<id> 级，日/月两档，warn 阈值告警，block 在调用前熔断（fail-closed），超额联动冻结对应 Agent 并生成解冻审批
4. 用量计量——input/output token 用上游实测值，不估算

到这一步，一次请求已经被管得很细了。但问题从这里开始。

断点一：请求有日志，资产没有档案

网关的日志表长这样：

时间	key	model	tokens	cost
14:02:11	sk-abc	gpt-x	1,842	…
14:02:13	sk-def	claude-y	903	…

现在审计的人问：这个 sk-abc 背后是哪个 MCP 服务？它上一次变更是什么时候？谁批的？当时灰度到多少？上一版回滚过吗？

日志表回答不了。因为**「一次调用」和「一个资产」是两个不同的实体**，日志记录的是前者。

这就是我们做 30 个插件包、把 MCP / Skill / Agent / AI 应用 / 模型渠道这些东西统一成「资产」的原因。每个资产有自己的状态机，MCP 服务的状态是：

draft → verifying → online → gray → unhealthy → offline

gray 这一档是我们特意做进去的。mcp_deploy 支持传灰度比例，也支持 dryRun——先返回影响面预览，告诉你这次变更会波及哪些 Agent、哪些 Skill 依赖它，再决定要不要真的推。

这件事网关做不了，因为它不知道「依赖」这个概念。它只知道流量从哪来，不知道谁在依赖。

断点二：流量有归属，责任没有主体

网关的成本报表通常按 key 或 model 聚合。这能回答「哪个 key 花得多」，回答不了「哪个部门花得多」。

因为 key 是技术凭证，不是组织单元。一个部门可能发了 20 个 key，一个 key 可能被 3 个部门共用。月底账单出来，你手上是一堆 sk-xxx 的消费额，需要人去对「这个 key 是谁的」。

我们的计量事件有四个字段：

org      组织（部门树上的节点）
subject  终点主体：user:<id> | agent:<id>
resource 被消耗的资源：model:<slug> | mcp:<slug> | skill:<id> | app:<id> | nas:<id>

subject 这层是关键。它让「成本按 Agent 拆」变成一句 SQL，而不是一次跨系统对账。成本三维归因 = org × subject × resource，能出「研发部 → 客服 Agent → 某个 MCP 服务」这样的穿透。

这里有个诚实的地方要说：我们不做计费。平台不转售、不分账，价格簿是零价快照（charge 恒 0），只呈现用量与内部成本穿透。原钱包和分账子系统已经下线封存。对私有化部署的企业来说这是对的——它要的是内部成本可见，不是要一个账单系统。

断点三：调用被允许，变更没人批

这一条我觉得是网关和治理最本质的分界。

网关的鉴权模型是逐次判定：这次调用，这个 token 有没有这个 scope？有就放行，没有就 403。

但企业里真正出事的地方，往往不是「某次调用越权」，而是**「某个资产被别人改了权限」**。

举个我们自己代码里的真实教训。/mcp 端点有一个从 token 反查主体的函数 mcpCallerFromToken，它给 machine 类型的主体返回时漏传了 refType / refId。后果不是越权——是 exec_claim 的归属判定失效，任务变成了无主的。日志里能查到这个任务被执行了，查不到它是谁的。

修复只改了十几行。但这件事说明：逐次鉴权判定的正确性，依赖于「主体是谁」这个前提在整个链路上保持一致。而这个一致性不属于任何单次请求，属于资产的身份模型。

所以治理层要做的是把「变更」也变成一等公民：

• MCP 服务上线要审批（我们有 L3 级，含灰度比例决策）
• Agent / App 的生命周期变更要审批（L4 级）
• Skill 上架走两级审批 + 弃用告警
• 每次变更进审计，四类日志分账：操作、认证、数据访问、配置变更

网关看到的是「谁调用了什么」。治理层要回答的是「谁改了什么，谁批的，改之前长什么样」。

那什么时候不需要治理层

写到这里必须说清楚边界，否则就是在卖东西了。

只需要网关的情况：

• 你只有一两个团队在用模型，成本按 key 拆已经够
• MCP 服务数量在 10 个以内，谁在用你脑子里有数
• 没有跨部门审计要求，出事靠人问
• 你更需要的是 trace 深度和 eval —— 这块我们确实不如 Langfuse / LangSmith，我们只有计量和审计，没有调用链追踪和效果评估

需要治理层的情况：

• MCP 服务散在多个部门，出现「这个服务下线了，谁在用它」这种问题
• 成本要按部门/Agent 出报表，且这个报表要能被财务接受
• 有合规要求，需要证明某个 AI 应用的上线经过了审批
• Agent 数量超过 20 个，靠人记已经记不住了

这是一个刚被验证需求的新品类，我不认为它已经成熟。网关上在做流量，可观测在做 trace，构建平台在做 Agent，但「企业里已经建成的那些 AI 资产归谁管」这一层，目前没有标准答案。早期玩家有 Monospace、Busabase、AgentValet，各家切口都不一样。

我们做的选择：统一模型 + 可私有化

如果一定要用一句话说我们和网关的差别：

网关把 MCP 当作「一种要路由的流量」，我们把 MCP / Skill / Agent 当作「要被管生命周期的资产」。

这个选择带来两个具体后果。

一、六类资产共享一套底座。 不是给 MCP 做一套权限、给 Agent 再做一套，而是同一套身份、权限、计量、审计。代价是抽象必须足够强，任何一类资产的特殊性都得塞进同一个模型里。收益是：新接入一类资产（比如我们后加的 NAS 存储和模型渠道）不用重写治理逻辑。

二、完全自托管，MIT。 不是 SaaS，不是「免费版 + 企业版」。因为这一层接触的是企业最敏感的东西——谁有什么权限、哪个部门花了多少钱、出了事谁负责。这些东西放不到别人的云上。

规模说清楚：30 个插件包，94 个权限点，499 条声明路由（其中 458 条受权限点保护），98 个 MCP 工具，1822 项端到端断言全绿，60 秒起得来，无重型依赖。数字不是卖点，但数字能说明这不是一个 PPT。

最后

回到开头那个问题：「装了网关，还缺什么？」

缺的不是功能，是一个把资产当主体建模的层。网关的日志表里没有「资产」这一列，加不上去，因为那不是它的设计目标。

反过来也一样：我们缺 trace 深度、缺 eval、单进程无水平扩展（多节点 HA 要等 Postgres 后端，ADR 还躺在仓库里）。这些是明确的缺口，写在 README 的「诚实边界」章节里。

判断标准其实很简单：如果你的问题是「这次调用花了多少」，网关够了。如果你的问题是「这个东西是谁的、谁批的、改了会影响谁」，那需要的是另一个层。

---

仓库：https://github.com/01men/ybkkasi
免登演示：https://demo.ybkkasi.com

---

完整版（带表格与代码块）：https://ybkkasi.com/blog/ai-gateway-vs-governance/

仓库：https://github.com/01men/ybkkasi · MIT · 免登演示：https://demo.ybkkasi.com