摘要

  • Snowflake 明确说明：由 CoWork 发起、再调用 Cortex Agent 的请求，使用量归到 CoWork。只覆盖 Agent 标签资源的预算，不会捕获这条路径产生的相应积分消耗。
  • 把 CoWork 纳入预算，可以补上入口范围，但覆盖的也会是更广的 CoWork 活动，而不只是原来那个 Agent。按用户标签划分的共享资源预算，与逐人计算的配额，解决的是不同问题。
  • 资源预算按周期评估，执行动作可能延后；启用后的用户配额封锁按分钟级评估。两者都不能直接等同于逐请求、覆盖全部费用的即时上限。
  • 动态模型路由可能改善单项任务的投入效率，却不会自动决定预算归谁、该停谁。最新披露的 AI 使用账户规模，也不是路由节省费用或预算有效性的证明。

一个团队给 Cortex Agent 设置了标签、月度预算和超额处理动作，很容易由此形成一个直觉：以后无论谁从哪里调用这个 Agent，预算都会跟着它走。

Snowflake 的资源预算文档给出的规则更具体。请求如果从 CoWork 开始，再调用 Cortex Agent，使用量会归到 CoWork。预算若只纳入带有 Agent 标签的资源，就不会捕获这些 CoWork 发起的请求所产生的相应积分消耗。

这里没有一笔被证明凭空消失的费用，也没有一个被发现绕过权限的漏洞。活动仍然有归属，只是归属不必等于最终执行工作的那个组件。技术调用关系与预算计量关系，并不是同一张图。

当企业把一个团队工具放进更广泛使用的 AI 入口，这个区别就会变得重要。工程团队看到的是原来的 Agent 被更多人使用；平台团队看到的是 CoWork 服务扩展；财务团队可能仍以为旧预算已经覆盖新增活动。三方对同一项工作的理解，可以各自合理，却没有落在同一个费用边界上。

补上范围，也可能扩大停用的影响

Agent 资源预算以对象为中心：给 Agent 加标签，把标签与月度积分限额关联，再配置达到阈值时执行的动作。它适合管理围绕这个资源聚合的消耗，并不保证追踪所有抵达它的调用路径。

文档给出的处理方式，是把 CoWork 资源纳入预算，或者另设 CoWork 资源预算。但这里还有后半句话：CoWork 范围的预算覆盖的是归属于相应 CoWork 对象的全部活动，不仅是调用某个 Agent 的那一部分。CoWork 自己的预算说明也以整个服务在账户内的聚合消耗为基础。

因此，扩大范围并不是把原来那条计量线简单延长。它可能同时纳入其他工作。若配置的动作只是通知，后续仍由人或其他系统处理；若动作会撤销某个角色的访问权，影响范围就取决于那个角色能访问什么、还有没有其他授权路径。

这不是说服务级预算不该使用。共同入口本来就需要共同的费用视图。问题在于，共同计量与精细停用是两种能力。企业可以希望把多项活动放在一份预算里，却不希望其中一项超额时，把其他有价值的工作一起中断。

接口改造于是带来了一项容易被忽略的管理变化：谁拥有扩大后的预算，谁有权触发限制，谁批准例外。Agent 的技术负责人未必有权决定整个 CoWork 服务的额度，平台管理员也未必承担被暂停业务的损失。仅仅确认“预算已经打开”，并没有回答这些问题。

按资源、按团队、按个人，并不等价

Snowflake 还提供共享资源预算。它把选定的 AI 资源与用户身上的标签结合起来，让不同团队使用同一服务时，可以按各自用户的消耗分别计量。

这里的单位发生了变化。给 Agent 贴一个部门标签，是围绕资源归集；给用户贴标签，并选择需要纳入的共享服务，则是在限定的人群和服务之间划定范围。一个用户满足任意标签条件就被纳入，还是必须同时满足全部条件，也会改变实际被计量的人群。

逐人配额又是另一回事。它为范围内的每个用户设置日额度、月额度，并分别评估，不是让整个团队共同分享一笔总额度。多名用户都没有超过各自限制，团队总消耗仍可能上升。个人控制正常工作，与部门总预算符合预期，可以是两个不同结果。

这种区别也有积极的一面。按人限制，能够避免因为少数人消耗较多，就停止所有人的访问；团队预算则更接近组织真正拨给一个部门的总资源。二者没有天然的优劣，但不能拿其中一种的名称替另一种的结果作担保。

企业需要先说清楚自己要约束什么：一个资源的总消耗，一组用户使用若干服务的总消耗，还是每个人可以动用多少资源。控制项越多，并不必然意味着控制越准确。若这些单位没有对齐，增加限制只会让停用原因更难解释。

超过阈值，不等于限制已经落地

预算还有一条时间边界。

Snowflake 的AI 成本治理说明指出，资源预算和共享资源预算会周期性计算与执行动作。正常运行条件下，超过阈值后的动作可能需要最多八小时生效；启用低延迟选项时，文档给出最多两小时的范围。它不是说每次都必然等待八小时，更不是一次客户事故的实测结果。

在此期间，已经被允许继续开展的工作可能增加消耗。究竟增加多少，取决于请求规模、并发活动、计量更新和配置的处理动作。没有这些具体数据，就不能把某个假设的每小时消耗乘以八，写成企业确定面临的损失。

用户配额的内置封锁更快：启用后，它在使用事件发生后的分钟级时间内评估，而不是事先为每个请求预留全部潜在成本。文档同样提醒，封锁到达前可能出现超额，大型单次请求尤其需要考虑。因此，不能把资源预算的八小时套到用户配额，也不能把用户配额写成绝不超支的固定价格承诺。

费用种类也有边界。仓库计算与 AI 采用不同的积分单位，不能合在同一份用户配额中；仓库费用可以单独跟踪，但内置 AI 封锁并不负责停止仓库消耗。AI 成本治理说明还提醒，查询执行、仓库时间和其他相关费用都可能进入总运行成本。只盯着 token，并不能得到完整账单。

停用之后还要处理业务状态。配额文档说明，封锁生效后，后续请求会收到相应错误，正在执行的 AI Functions 调用也会终止。但这并不证明所有工具动作都会取消，更不意味着已经完成的工作会自动回滚。停止继续花费，与把一项业务恢复到一致状态，仍是两项任务。

使用规模扩大，不会自动消除边界

这些细节之所以值得从文档里拿出来讨论，是因为 AI 入口正在成为共享服务。9 月 2 日的业绩公告显示，Snowflake 截至 7 月 31 日的季度产品收入约为 14.9 亿美元，同比增长 37%；CoCo 的相关使用账户超过 9,100 个，CoWork 为 5,800 个。

账户指标采用季度最后四周的平均每周功能使用情况，涵盖容量合同和按需账户，并依照公司内部分类。它不是付费个人用户数，也没有证明两组账户互不重叠，更不能相加后称为客户总数。这些数字在本文中的作用，是说明共享 AI 使用已经形成规模，不是证明某种预算被部署得好，也不是证明新路由节省了钱。

Snowflake 在8 月 18 日的动态模型路由公告中，提出按任务选择模型、平衡质量与成本。公告脚注把该功能标为即将进入私有预览。内部测试描述的是效率潜力，不是经独立核验的客户账单；7 月结束的财务季度，也不能证明随后这次公告的效果。

更合适的模型可以降低一次任务所需的投入，却不能代替企业决定这次任务应计入哪个预算、由哪个团队承担、该在何时停止。单项任务便宜后被更多人使用，总费用仍可能增长。这是两种可以同时发生的结果，而不是模型效率改善必然失效。

文档已经给出工具，组织仍要作出选择

把这些限制理解为 Snowflake 没有有效成本控制，同样不准确。公司公开了入口归属差异，提供共享预算、用户配额、执行历史与不同响应速度，也说明了如何选择范围。这些是实质性的控制能力，不只是一个“治理”标签。地区可用性仍需区分：Cortex Agent 资源预算文档明确标注，该功能不在中华人民共和国提供。全球平台的说明，不等于各地区具有完全相同的功能清单。

真正的工作，是把它们连接到清楚的责任分配：新增入口后检查费用计在哪里；选定团队预算后确认哪些用户和服务被纳入；触发停用前知道会影响谁；批准例外后能够说明额度究竟改变了多大范围。

AI 平台让技术调用越来越顺畅，财务归属却不会因此自动变得简单。同一个 Agent 可以被多个入口调用，它的对象预算不必跟随每一次调用。企业需要核实的，不是控制面板上有没有一个限额，而是费用归属、停用对象与生效时间，是否真的对应了自己想做的那个决定。

资料与证据边界

本文依据截至 2026 年 9 月 3 日查阅的上述 Snowflake 官方预算、配额及成本治理文档，以及公司产品公告和季度业绩披露。未访问客户 Snowflake 账户，未独立测试停用延迟、账单或节省金额。文中的组织影响属于对已披露机制的分析，不是客户故障或违规事件报道。