大家好，这里是最佳拍档，我是大飞。不知道大家有没有注意到一个相当反常识的现象？过去一年，各大模型厂商都在降价，token的单价跌了差不多八成。但是企业花在AI上的钱，不减反增。便宜的token没有省下预算，反而给了所有人一个理由：去跑得更多、跑得更长、跑得更野。

一个原来花十块钱的任务，现在两块就能搞定，那团队就跑五次；然后交给一个Agent自动跑五十次。也就是说，单价下来了，总量上去了，账单比以前更吓人。而且这不是个别现象。微软最近发了一篇博客，标题叫《Agent优化的经济学：从试点到可衡量的回报》。

作者是Microsoft Foundry的企业副总裁蒂娜·舒赫曼（Tina Schuchman）。她开篇就点出了整个行业的拐点：两年前大家问的是AI到底能不能用，现在领导者问的是一个更尖锐也更让人不舒服的问题：“这东西到底赚不赚钱呢？”

这个转变很关键，因为它意味着AI已经从白板上的实验，走到了预算审核的会议桌上。微软引用了一组IDC的数据：超过四千名商业领袖的调研显示，百分之七十一的人计划增加AI预算。钱在涌进来，但是真正的问题在于：财务纪律有没有跟着一起长？

微软的说法很直白：决定一个AI试点能不能规模化的，不是你选了哪个模型，是你的财务治理能力。那么AI的成本到底跟传统的云支出有什么不同？这要从token这个计量单位说起。

在传统云时代，你按计算实例、按存储、按带宽付费，每个资源都是相对独立的，成本曲线也比较可预测。但是到了AI时代，token成了新的技术支出单位，它的行为模式跟传统资源完全不一样。

每一次API调用都包含输入token和输出token：输入端有系统提示、对话历史、工具定义、检索回来的内容；输出端是模型生成的回答。关键在于，模型本身是没有状态的。也就是说你每次发请求，都得把完整上下文重新发一遍。

用户可能只是问了一个简单的追问，但前面几十轮对话加上工具定义加检索结果，全都要再传一次。成本会随着时间增长，哪怕用户问的问题越来越短。这还只是单次调用的情况。

一旦进入Agent场景，复杂性又上了一个台阶：Agent不是走单一路径，它要评估选项、重试动作、调用多个工具，然后才给出一个回答。一个用户请求背后可能触发好多次模型调用。所以工作流设计的重要程度，一点都不亚于模型选择。

这就引出了第一个核心问题：成本可见性。当你的AI支出在财务报表上只是一行聚合数字的时候，你是没法管理的。你需要看到的是按应用、按Agent、按工作流、按模型拆开来的成本归因。

没有这个颗粒度，你解释不了成本从哪来、排不了优化优先级，也量不了优化措施到底有没有效果。但是光看到还不够：AI工作流的特点是它能快速扩展，而且一些意料之外的行为会在短时间内把消耗拉高。

所以你还需要控制手段：在成本变成惊喜之前就把它管住。微软把这个能力体系叫FinOps for AI。FinOps这个词本身不是新的，它最早是云时代的产物，核心理念是把财务问责制引入弹性的云支出。

让工程、财务和产品团队在同一套数字上对齐。微软把它延伸到AI领域，提炼出了四个承诺：分别是让AI可预测地投入、高效设计、规模化优化以及价值验证。对应覆盖的是计划、构建、管理和度量整个生命周期。

那具体怎么落地呢？微软给出了一个三速优化的框架，每个决策在不同的时间尺度上运行。最快的是运行时优化：在每次请求执行的当下做决策，核心思路是让简单的工作别为前沿模型的价格买单。

微软Foundry里的模型路由器可以把每个提示按成本、质量和平衡三种模式路由，简单请求不走最贵的模型。部署和定价选项能够根据成本和延迟的需求进行匹配，覆盖全球部署、数据区域部署和区域部署。

以及标准、优先、预留吞吐和批处理几种模式。提示和语义缓存可以复用重复的上下文，而不是每次都花钱重新计算。微调可以让一个更小的、经过调优的模型在特定任务上达到大模型的效果，降低单token价格的同时还能缩短提示。

还有一个叫Microsoft IQ的共享企业智能层：它的Foundry IQ组件给Agent提供可复用的、权限感知的知识库，用智能检索只选最相关的上下文。在提升准确性的同时，减少不必要的输入token。

慢一点的是工作流优化：在几天到几周的时间尺度上做，核心思路是让每个Agent随着运行变得越来越便宜。Agent优化器可以拿你自己的评估器去测试不同的提示、模型、工具和技能组合，然后推最好的配置。

往往能在更小更便宜的模型上保持质量。工具箱机制只发送请求真正需要的工具定义，而不是把所有工具定义一股脑塞进去。记忆模块分成过程记忆、用户记忆和会话记忆，跨轮次携带上下文而不需要重发完整历史。

最持续的是支出治理：永不停歇。今天很多团队在AI端点前面会放一层Azure API Management的AI网关，用它来执行token速率限制、配额和缓存。微软还在Foundry内部做原生的预算和执行功能，让支出限制更贴近Agent运行的地方。

再加上Azure Cost Management作为预算、告警和计费成本的系统记录，更远的规划里Microsoft Agent 365会把同样的治理能力扩展到租户级别：统一管理微软和第三方平台上的Agent成本，包括支出策略、预算上限和部门级成本分摊。

听起来是一套很完整的体系，但是这里有个关键问题：微软的博客没有深入展开的就是当你面对的是一个多Agent协作的工作流，不是一个单独的请求，你该怎么管理成本呢？这恰好是蒂莎·查瓦拉（Tisha Chawla）和苏希姆·库尔（Susheem Koul）这两位微软工程师在做的事情。

他们在AI Engineer大会上做了一个演讲，标题就叫：FinOps for AI Agents——谁花光了所有token。他们不只是讲理念，还开源了一个叫AgentPlane的项目以及TokenOps工具。

他们解决的核心问题是什么？AgentPlane项目的GitHub主页上写得非常清楚：一个多Agent工作流会烧掉十倍于预算的token。因为每个Agent各自在本地封顶支出，什么意思呢？

假设你有一个从研究到摘要再到审阅的三步工作流，每个Agent都有自己的一百块预算上限。研究者Agent会觉得：我离上限还远，可以多跑几轮；摘要Agent也觉得自己的预算还有余量；审阅Agent同样如此。

三个Agent各自看自己的账本都觉得没问题，但加在一起整个工作流早就超出了你最初设定的总预算。问题的根源在于：现有的成本治理工具都是按请求来管理的，不是按运行来管。

LiteLLM、Portkey这些网关类工具，它们管的是每个请求、每个key或每个团队的消费上限。而Langfuse这类可观测性工具，它们做的是追踪和事后分析。但是没有一个工具能把一整个Agent工作流当成一个有状态的整体来治理。

TokenOps要做的就是这件事：它的核心理念一句话就能说清——“治理运行，不治理请求”。一个run_id会跨越工作流中的每个模型调用、每次工具调用、每个Agent到Agent的跳转，所有参与方的支出记在一个共享账本里。

在下一个大模型调用执行之前就做检测和决策，而不是事后再看报表。具体架构上：TokenOps是两层，一层是控制面，跑在7700端口，负责注册运行、存储预算和策略；底层用SQLite做共享存储。

另一层是进程内的SDK：在每个边界交叉处执行治理逻辑。入口Agent注册一个运行，拿到一个run_id；然后这个run_id通过HTTP头传递给下游的所有Agent。每个Agent在调用模型或工具之前，SDK会运行一个从检测到决策再到应用的流程：查询控制面获取当前运行的治理配置。

判断是否超出预算，然后决定是放行、修改还是直接停止。这个检测到决策在到应用的过程是实时的，发生在下一个大模型调用之前。执行器有几种动作可以选择：HALT是直接停止；MUTATE是修改请求，比如换一个更便宜的模型。

INJECT是注入额外的上下文或指令；还可以拒绝或排队。这样一来，不只是事后看分析报表，而是真正能在运行过程中干预。他们做了几个演示场景来展示这个能力：最简单的是双Agent场景，一个研究Agent做完检索把结果交给一个摘要Agent做总结。

两个Agent共享一个预算，当摘要Agent快要超支的时候，预算上限会在运行中途触发暂停后续支出。更复杂一点的是三Agent场景：从规划者到研究者再到写作者，三个Agent各有分工但是共享同一个账本。

还有一个用LangChain搭的场景：从侦察到分析再到编辑，展示了TokenOps跟主流Agent框架的兼容性。值得一提的是TokenOps的对比定位：在他们的GitHub README里有一张很清晰的对比表。

TokenOps跟LiteLLM、Portkey、AI Gateway这些网关工具的区别在于：后者关注的是请求，TokenOps关注的是运行——一个有状态的、跨多个Agent和工具调用的完整工作流。后者不支持把多Agent工作流作为整体单元来治理，但是TokenOps可以；后者在key或团队级别做预算执行，但是TokenOps在运行级别做。

后者能做路由和回退，但是TokenOps能修改和注入下一个调用。跟Langfuse相比：后者用于事后追踪和分析，不支持在路径内做预算执行也不支持转向下一个调用。这个定位很重要：因为它说明TokenOps不是要替代你现有的网关或追踪工具，而是填补了一个空白。

在运行级别对多Agent工作流做有状态的、实时的成本治理：你仍然可以用LiteLLM做请求路由，用Langfuse做事后追踪。而TokenOps就坐在它们旁边：负责把整个运行关在一个预算笼子里。

TokenOps还有一个重要的搭档叫Chronicle，同样出自AgentPlane开源项目。Chronicle做的是Agent决策图的记录与回放：跟TokenOps的成本治理是互补关系。Chronicle记录决策边界，TokenOps在这个边界上做成本和治理的观察。

Chronicle本身解决的是另一个生产环境的痛点：就是Agent在运行时出了问题的话，你没法复现。这个问题的根源在于大语言模型本质上是非确定性的。很多人以为把温度参数设成零就能保证确定性的输出，但实际情况不是这样的。

苏希姆和蒂莎在AI Engineer大会上的另一个演讲专门讲了这个问题：他们引用了一个案例，一个交易Agent把卖一千美元的股票理解成了卖一千股，执行了一笔导致十九万美元损失的交易。系统返回了标准的HTTP 200成功状态，三十毫秒内完成零异常。

从程序的角度来看一切正常；但是从业务角度来看无疑是一场灾难：而且这个bug你还没法靠温度归零来修复，因为问题不在随机采样上而是在Agent对指令的理解逻辑上。那温度设零为什么不能保证确定性呢？有几个架构层面的原因：首先是浮点运算的非结合性，矩阵运算顺序的微小变化就足以翻转token选择结果。

其次是批处理不变性：你的请求跟其他流量打包在一起处理时，共享计算资源会导致logit值偏移。第三：混合专家架构的路由机制取决于并发批处理的构成，而不是仅仅取决于输入内容。这些因素叠加在一起意味着即使你用同样的提示、同样的模型版本、同样的配置参数在不同时间提交，也可能得到不同的输出。

所以正确的思路不是追求比特级的确定性而是追求可回放性：Chronicle的做法是在系统边界做记录，捕获每个推理步骤的输入和输出。而不是去抓网络层的数据包：你记录的是Agent做了什么决定、为什么做这个决定，不是网络传了什么字节。

这样你就能把一次生产事故完整冻结下来：在不调用模型、不花API费用的情况下，重放整个执行过程。更有意思的是他们提出的切点回放概念：你把事故记录里某个边界标为切点，切点之前的所有内容都可以从记录中回放做到字节级别的一致。

而在切点位置运行你的新代码看修复有没有效；切点之后的也实时运行观察修复对后续流程的影响。这样一来，你不需要重新跑整个Agent：你只需要把新代码插进一个被冻结的事故中间。问一个问题：“在之前完全一样的情况下，我的修改有没有做对？”

这样一来，一次生产事故就变成了一个永久的回归测试：提交到代码仓库里。半年后有人重构了工具路由器，你的防护逻辑可能悄悄失效了这个测试会在他的pull request上变红而不是在客户的数据库上爆掉。从不可复现的事故到永远在线的回归检查，这就是可回放性给生产可靠性带来的根本变化。

当然这里有一个不能忽视的环节那就是脱敏：一次运行记录忠实地复制了生产环境的数据，包含提示的完整内容、检索到的文档块和工具参数。这里面可能有客户姓名、邮箱以及API密钥：你不能把这种东西直接提交到git，所以脱敏不是录制路径上的可选项而是必须的一道关卡。

在写入之前就得要清洗掉敏感信息：保留测试需要验证的结构和形态，去掉敏感值。现在让我们把视角拉回来把这些技术细节放到一个更大的图景里看：Token经济学不只是成本管理的问题，它也是一个架构问题。

蒂莎在另一篇文章里提出了一个很有洞察力的观点：上下文预算是一种架构资源，需要被分配而不是被反射性地消耗。她讲了一个很实际的现象：在规范驱动开发（SDD）这个领域，有人做了一组对比测试。

用同一个任务跑两个不同的SDD框架：一个是Spec Kit生成大约八百行规格制品，另一个是OpenSpec生成大约两百五十行。结果呢？Spec Kit的token消耗比OpenSpec多了百分之九十七到一百零九，但是产出质量并没有更好。

也就是说：更结构化的前期投入几乎把token用量翻了一倍，效果却没有提升。更有说服力的是苏黎世联邦理工的一项研究：他们测试了一个直觉上很合理的假设——给Agent一个结构化的代码库概览文件应该能帮助它更好地完成任务。

但是结果跟直觉相反：无论是机器生成还是人工编写的上下文文件都降低了任务成功率，同时把推理成本提高了百分之二十以上。Agent没有忽略这些文件：它们很听话进行了更广泛地探索，跑了更多的测试遍历了更多的文件也在更努力地思考。

但是产出的补丁并没有更好：作者把这种失败模式叫做合规循环陷阱，指的是Agent把认知预算花在了满足结构性护栏上而不是解决问题上。这两组数据指向同一个结论：每一条你塞进Agent上下文的额外规则都在消耗它有限的推理预算。

如果这条规则没有减少不确定性，那它不是治理是税：这跟TokenOps的理念是一脉相承的。你需要在正确的颗粒度上做治理，在运行级别而非请求级别做预算控制；在真正减少不确定性的地方花token在其他地方把口子收紧。

回到微软的那篇博客：它给AI领导者总结了四个问题，我觉得值得每一个在搞AI落地的团队认真想一想。第一个：你知道你在为什么付费吗？你的支出应该按模型、按Agent、按工作流可见，而不是藏在一行发票里。

第二个：你的每笔请求付的价格合理吗？大多数请求不需要前沿模型，你应该有能力把每个请求匹配到它真正需要的能力级别上。第三个：你的Agent运行得高效吗？Agent的成本应该随着工作流的改进而下降而不是一直原地踏步。

第四个：当使用量飙升的时候你的限制扛得住吗？快速扩张的使用量需要扛得住的控制手段。这四个问题每一个都在TokenOps和Chronicle的框架里有对应的答案：可见性对应共享账本和多维度成本归因；合理定价对应运行时的模型路由和修改能力。

运行效率对应工作流级别的持续优化和工具箱精简；限制扛得住对应在路径内的预算执行和HALT机制。大飞多说一句：这些内容对于正在做AI产品落地的团队来说参考价值是很实在的。我也并不是在给微软做广告：不管你是用微软的Foundry还是自己搭开源方案，核心逻辑是一样的。

Agent的成本治理必须从请求级别上升到运行级别：从事后分析前移到执行路径内。这跟传统软件工程里从事后打补丁到CI/CD持续集成的转变是一个道理：最后我想留一个开放性的问题给大家。

如果你的团队现在有一个多Agent工作流跑在生产环境：你能回答上一次运行花了多少token、花在哪里、有没有超出预算这三个问题吗？如果不能，也许现在是时候想想你的FinOps基建还缺什么。感谢收看，我们下期再见。