最近，一组数据引发了广泛关注。

以微软的一个核心业务部门为例，该部门为数千名工程师开通了AI编程工具，期望以此提升开发效率。然而，四个月后财务核算发现，全年的AI算力预算已提前耗尽，实际支出超出预期三倍。这并非管理漏洞或恶意使用，而是由于在未设置额度上限的情况下，数千用户的常规使用导致成本飙升。

技术界对此众说纷纭，但一个关键问题被普遍忽视：当这四个月的预算消耗殆尽，团队的知识库留下了什么？

代码或许得以留存，但大量与AI交互的过程并非最终产物，而是宝贵的中间成果。例如，反复调试的Prompt、运行成功后却被遗忘的Skill配置、历经数十轮优化才稳定的Memory。这些关键信息都存放在工程师的个人AI账户中。一旦员工离职，这些资产便随之消失。

生产者留存，但产物却未沉淀

企业的技术资产历来有明确的存储位置：代码存入Git，文档归入知识库，设计稿置于协作平台。每类资产都有清晰的路径、权限和交接流程。

然而，AI时代产生的过程资产却成为了一个例外。

例如，一位运营人员花费两周时间调试出一套Prompt，将竞品分析时间从三小时缩短至二十分钟。然而，这套Prompt却沉睡在其AI工具的聊天记录中。一位后端工程师开发的Skill能自动进行代码审查并输出结构化意见，但其配置却散落在本地JSON文件中。同样，产品经理花费数月让AI掌握团队规范，但这份Memory却绑定在个人账户上，难以传承。

从另一个角度看，这其实是一种知识蒸馏过程，只是蒸馏的对象并非模型，而是人类的专业判断。

优秀员工与普通员工的差距，往往不在于知识广度，而在于判断力的深度。他们清楚在特定场景下应选用何种模型、如何撰写Prompt以一次成功、怎样编排Skill才能高效运行。这些过去属于隐性经验，仅存于大脑中。但如今，这些经验已被写入Prompt、封装进Skill、输入到Memory。每一段调试指令，都是专业判断的浓缩产物。

然而，问题在于：蒸馏后的宝贵产物，团队并未有效承接。

成本不透明，资产便无法归因

如果说资产沉淀是首要问题，那么第二大问题便是：许多团队对AI费用的流向一无所知。

月初充值的额度，月底剩余多少，这是最常见的监控粒度。但哪个项目消耗最大？谁在利用高性能模型处理简单任务？这些问题均不明确。月底账单仅显示总额，缺乏明细。当AI调用成为日常且多项目并行时，手工统计完全失效。

回顾微软案例，「未设额度上限」仅为表象。更深层的问题在于：消费无法实时追踪，成本未能归因到具体项目和人员，预算消耗速度无人预警。

从治理角度设计AI调用链路

身份注入

在调用链路入口，将用户身份、项目归属、调用意图等元信息注入请求上下文。无论底层接入何种模型，统一签发带有身份标签的派生凭证，所有后续追踪均基于此凭证。这类似于云平台IAM的临时凭证策略——签发有限权限和生命周期的凭证，而非直接暴露主账号Key。

实时计量

每次调用返回结果时，同时完成Token计数和成本估算。关键设计是将「账单口径」与「估算口径」分离维护。估算口径允许少量误差，但延迟控制在秒级，用于实时预警和用量监控；账单口径追求精确，以T+1方式对齐Provider结算数据，用于财务核算。

策略执行

基于前两层的身份与计量数据，在调用链路中插入策略节点：项目预算阈值告警、单个成员日消耗上限、低成本模型自动降级、异常流量自动熔断。这些策略作为中间件实现，无需侵入业务代码。

更关键的是，该架构天然具备资产沉淀能力。当每次Prompt调用、Skill编排、Memory写入均被记录和归因时，「谁创造了它、它是否有效、被复用了多少次」不再是事后手动收集的难题。系统运行时，资产目录自然生长。

Prompt、Skill、Memory——这些资产能否像代码一样入库、归档、复用？当它们从个人账户解放，成为团队可追溯的技术资产时，企业为AI投入的资金才算真正实现了从「消耗」到「积累」的闭环。