云栖大会的一场企业级 Agent 论坛开场前，一位参会者接到员工的电话：上月上线的一个 AI 应用，原本预估的 Token 费用约一万元，最终结算花了三万。原因并不复杂——一个开关忘了关，应用在后台持续调用模型。关掉开关，支出立刻止住，但问题留了下来：谁启动了那项任务？它运行了多久？这笔钱应该算在哪个部门、哪个应用头上？为什么直到月底对账才发现？
这个故事的价值不在于金额，而在于它暴露的四个问题：归属、时长、责任、可见性。它们都不是模型能力问题，而是治理问题。
一、为什么是 Agent 让这件事变得棘手
传统的问答式应用里，下一轮对话由用户决定。用户不问，就不会产生费用——成本天然被人的行为节奏约束着。
Agent 改变的是这一点。接到一个任务后，它可能连续检索、调用工具、依据中间结果调整计划、发现失败后发起重试。一个任务到底会产生多少次模型调用、占用多少资源，往往要跑起来才知道。
于是企业面对的是双重不确定：结果不确定，成本也不确定。这里有三个容易被低估的特征：
- 自主性：调用由程序决定，而不是由人逐次触发。没有人坐在那里为每一次调用"点头"。
- 放大性：检索、重试、自我修正这些机制本身是必要的，但它们也可能把一次委托放大成几十次调用。
- 延迟性：成本在月末结算时才可见，而事故发生在月中。中间的窗口期里，问题一直在累积。
值得强调的是：更准确的模型能减少误判，却替代不了权限校验、预算约束和故障恢复。Token 单价下降也不意味着完成一项任务的总成本一定下降——如果单价降低让企业敢于把更长、更复杂、权限更高的任务交给 Agent，总成本反而可能上升。原本由人承担的检查、协调与兜底，必须沉淀进系统。
二、用量管控到底要管住什么
把上面的问题翻译成工程要求，大致是五条：
- 1.归属明确：每一次调用都能回答"是哪个应用、哪个员工、哪个项目发起的"。
- 2.额度可控：可以为每个应用、每个员工设定日额度与月额度；达到上限即停止，而不是事后提醒。
- 3.可见可查：每个应用的月度费用清清楚楚，不需要等到财务对账才拼出全貌。
- 4.异常可发现：消耗突然放大时能被及时看到，而不是月末才暴露。
- 5.留痕可审计：谁在什么时候放开了什么权限、调整了什么额度，有记录可查。
这五条里最容易被做错的是第二条。很多团队做的是"监控 + 告警"：费用超过阈值就发通知。但告警依赖人看到并响应，凌晨三点的告警可能第二天上午才被处理。真正能止住支出的，是硬性上限——到额度就拒绝请求。
三、为什么"网关"是承载这些要求的位置
这些要求有一个共同点：它们都需要一个统一的位置来执行。如果每个应用各自直连模型厂商，那么归属信息、额度规则、调用日志就散落在各个应用里，无法汇总，也无法统一执行。
AI 网关的价值就在这里：它是所有模型调用的唯一出口。应用不再直接连模型，而是带着自己的身份经过网关，由网关完成鉴权、计量、限额与转发。
这样带来几个直接结果：
- 身份可以在链路上传递。每个应用、每个员工持有自己的凭据，调用天然带上归属信息。
- 额度的执行点只有一个。日额度、月额度、按应用或按员工的限制，都在同一处生效，不存在绕过。
- 成本可以直接归集。因为每次调用都带着身份标签，月度费用可以按应用、按人、按项目直接汇总，不必事后分摊。
- 密钥不再散落。应用不再各自持有一把高权限的厂商密钥，减少泄露面，也便于轮换。
换句话说，网关把"谁在用、用了多少、该不该继续"这件事，从各应用的自觉，变成了架构上的一次强制检查。
四、几种常见的额度设计
额度怎么切分，取决于企业管理的粒度。以下组合通常够用：
- 按人：每位员工每天或每月一个额度，适合内部工具与个人助理类应用。
- 按应用：每个应用一个额度，适合业务系统；与按人额度叠加使用时，能同时看住"谁"和"什么系统"。
- 按项目或成本中心：把额度与预算科目对齐，让费用可以直接进财务报表。
- 分层级：个人额度之上再设部门或应用总额度，避免个人都在限内、整体却已超支。
这里有一个实践细节值得注意：额度用尽时被拒绝的是一次模型调用，而不是整个任务。如果 Agent 没有处理这一情况的能力，任务会以失败告终，用户看到的是"应用坏了"。因此额度设计需要与应用的错误处理配合——在接近上限时给出预警、在超限时给出明确原因，而不是让调用凭空失败。
五、需要说清楚的能力边界
把网关说成万能方案是不诚实的。以下几件事，网关自己解决不了，需要与其他机制配合：
其一，网关看到的是调用，不是意图。它无法判断一次重试是必要的容错，还是代码里的死循环。它能做的是限制总量与速率，而"这个任务值不值得花这么多"仍需要任务级预算或人工确认来回答。
其二，网关是链路上的一个环节。它应当被设计成可降级、可监控的组件，而不是单点故障来源；这对可用性和运维提出了额外要求。
其三，额度是约束，不是优化。设置上限能防止失控，但不会自动降低单位成本。真正降低成本还要靠提示词与上下文的精简、缓存、模型分级路由这些手段。
其四，治理机制不能替代 Agent 自身的权限设计。一个被授予过宽权限的 Agent，即便费用受控，仍可能造成其他后果。
承认这些边界，反而有助于把网关放在它正确的位置上：它是成本与用量的执行点，而不是全部治理问题的答案。
六、落地时的几个建议
- 1.先做归属，再做限额。如果调用无法归属到人或应用，任何限额都无处落地。
- 2.限额从宽到严逐步收紧。一开始就设得很紧，会频繁打断正常业务，反而促使团队绕过管控。
- 3.把月度账单做成常态视图，而不是月末的一次性动作。费用可见本身就是一种约束。
- 4.为超额设计好用户体验。让用户知道"为什么停了、怎么申请"，比默默失败要好得多。
- 5.保留审计记录。额度调整与权限变更都需要可追溯，否则事后无法复盘。
结语
文章开头那三万块钱，本质上是为"看不见"付的学费。当应用以 Agent 的方式自主行动，企业需要的不只是一次次的模型调用能力，还需要能解释这些调用从何而来、花了多少、是否该继续。身份可传递、状态可恢复、费用可归属、异常可发现——这些要求落在工程上，通常就表现为一个统一收口的位置。这就是 AI 网关的位置。
---
关于 tarogo.com：我们提供企业级 AI 网关服务，主要解决本文所述的用量管控、成本归属与访问治理问题——按应用、按员工、按日与按月设置额度，超额即停，各应用月度费用可清晰归集。若你所在的企业正在经历类似的成本不可见问题，欢迎与我们交流具体场景。