成本悖论：低价Token引发的支出激增

过去一年，各大模型厂商纷纷降价，token的单价跌了差不多八成。然而，企业花在AI上的钱不仅没有减少，反而不降反增。这种看似反常识的现象背后，是行为模式的改变：便宜的token没有省下预算，反而给了所有人一个理由去跑得更多、跑得更长、跑得更野。原本需要十块钱的任务现在两块就能搞定，团队可能会因此执行五次；如果交给Agent自动运行五十次，单价下来了，总量上去了，账单比以前更吓人。这并非个别现象，而是行业性的拐点。微软Foundry企业副总裁蒂娜·舒赫曼（Tina Schuchman）在博客《Agent优化的经济学：从试点到可衡量的回报》中指出，两年前大家问的是AI到底能不能用，现在领导者问的是一个更尖锐也更让人不舒服的问题：这东西到底赚不赚钱呢？

这一转变标志着AI从白板上的实验走到了预算审核的会议桌上。微软引用IDC数据，超过四千名商业领袖中百分之七十一的人计划增加AI预算。钱在涌进来，但财务纪律是否跟上才是关键。微软直言：决定一个AI试点能不能规模化的不是你选了哪个模型，是你的财务治理能力。传统云支出按计算实例、存储、带宽付费，资源独立且可预测；而AI时代以token为计量单位，每一次API调用都包含输入和输出Token，且模型本身没有状态。这意味着每次请求都要重新发送完整上下文，包括系统提示、对话历史、工具定义和检索内容。用户可能只是问了一个简单的追问，但前面几十轮对话加上工具定义加检索结果全都要再传一次，导致成本随时间增长。

“单价下来了总量上去了，账单比以前更吓人。”

多Agent复杂性：从请求到运行的治理鸿沟

一旦进入Agent场景，成本管理的复杂度呈指数级上升。Agent不是走单一路径，它要评估选项、重试动作、调用多个工具然后才给出一个回答。一个用户请求背后可能触发好多次模型调用，因此工作流设计的重要程度一点都不亚于模型选择。这引出了第一个核心问题：成本可见性。当AI支出在财务报表上只是一行聚合数字时，你是没法管理的。你需要看到的是按应用、按Agent、按工作流、按模型拆开来的成本归因。没有这个颗粒度，你解释不了成本从哪来，排不了优化优先级，也量不出优化措施的效果。光看到还不够，因为AI工作流能快速扩展且存在意料之外的行为。你需要控制手段在成本变成惊喜之前就把它管住。

微软将这套能力体系称为“FinOps for AI”，提炼出四个承诺：让AI可预测地投入、高效设计、规模化优化以及价值验证，覆盖计划、构建、管理和度量整个生命周期。具体落地采用“三速优化”框架： 1. 运行时优化（最快）：核心思路是让简单的工作别为前沿模型的价格买单。通过Microsoft Foundry里的模型路由器，按成本、质量和平衡三种模式路由请求；部署和定价选项匹配成本和延迟需求；提示和语义缓存可以复用重复的上下文而不是每次都花钱重新计算。微调让更小的模型在特定任务上达到大模型效果，降低单token价格并缩短提示。Microsoft IQ组件给Agent提供可复用的、权限感知的知识库，用智能检索只选最相关的上下文。 2. 工作流优化（几天到几周）：核心思路是让每个Agent随着运行变得越来越便宜。Agent优化器可以拿你自己的评估器去测试不同的提示、模型、工具和技能组合然后推最好的配置，往往能在更小更便宜的模型上保持质量。工具箱机制只发送请求真正需要的工具定义而不是把所有工具定义一股脑塞进去。记忆模块分成过程、用户和会话记忆，跨轮次携带上下文而不需要重发完整历史。 3. 支出治理（永不停歇）：在AI端点前放置Azure API Management的AI网关执行token速率限制、配额和缓存。Foundry内部做原生预算和执行功能，结合Azure Cost Management作为系统记录。长远规划中Microsoft Agent 365将治理能力扩展到租户级别，统一管理微软和第三方平台上的Agent成本包括支出策略、预算上限和部门级成本分摊。

“决定一个AI试点能不能规模化的不是你选了哪个模型，是你的财务治理能力。”

TokenOps：解决多Agent共享预算的难题

微软博客未深入展开的关键问题是：当你面对的是一个多Agent协作的工作流不是一个单独的请求你该怎么管理成本呢？ 微软工程师蒂莎·查瓦拉（Tisha Chawla）和苏希姆·库尔（Susheem Koul）在AI Engineer大会上演讲《FinOps for AI Agents：谁花光了所有token》，并开源了AgentPlane项目及TokenOps工具。核心痛点在于：一个多Agent工作流会烧掉十倍于预算的token因为每个Agent各自在本地封顶支出。假设一个从研究到摘要再到审阅的三步工作流，每个Agent有一百块预算上限。研究者觉得离上限远可以多跑几轮，摘要和审阅同理。三个Agent各自看自己的账本都觉得没问题但加在一起整个工作流早就超出了你最初设定的总预算。

现有工具如LiteLLM、Portkey按请求管理，Langfuse做事后追踪。没有一个工具能把一整个Agent工作流当成一个有状态的整体来治理。TokenOps的核心理念是：治理运行不治理请求。一个run_id会跨越工作流中的每个模型调用、每次工具调用、每个Agent到Agent的跳转，所有参与方的支出记在一个共享账本里。在下一个大模型调用执行之前就做检测和决策，而不是事后再看报表。

TokenOps架构分为两层： 1. 控制面：跑在7700端口，负责注册运行、存储预算和策略，底层用SQLite做共享存储。 2. 进程内SDK：在每个边界交叉处执行治理逻辑。入口Agent注册运行拿到run_id，通过HTTP头传递给下游所有Agent。每个Agent在调用模型或工具之前SDK会运行一个从检测到决策再到应用的流程，查询控制面获取当前运行的治理配置，判断是否超出预算。然后决定是放行、修改还是直接停止。

执行器动作包括：HALT是直接停止，MUTATE是修改请求比如换一个更便宜的模型，INJECT是注入额外的上下文或指令，还可以拒绝或排队。演示场景包括双Agent（研究+摘要）共享预算触发暂停；三Agent（规划者-研究者-写作者）共享账本；以及LangChain搭建的场景展示兼容性。

“TokenOps要做的就是这件事：治理运行，不治理请求。”

Chronicle与可回放性：应对非确定性输出

TokenOps的搭档是Chronicle，同样出自AgentPlane开源项目。Chronicle做的是Agent决策图的记录与回放跟TokenOps的成本治理是互补关系。它解决生产环境痛点：Agent运行时出问题无法复现。根源在于大语言模型本质是非确定性的。很多人以为把温度参数设成零就能保证确定性的输出但实际情况不是这样的。苏希姆和蒂莎引用案例：一个交易Agent把卖一千美元的股票理解成卖一千股，执行了导致十九万美元损失的交易。系统返回标准HTTP 200成功状态三十毫秒内完成零异常。从程序的角度来看一切正常但从业务角度来看无疑是一场灾难。温度设零不能保证确定性，原因包括：浮点运算的非结合性、批处理不变性（共享计算资源导致logit值偏移）、混合专家架构的路由机制取决于并发批处理构成。即使同样提示、模型版本和配置，不同时间提交也可能得到不同输出。

正确思路不是追求比特级确定性而是追求可回放性。Chronicle在系统边界做记录，捕获每个推理步骤的输入和输出。你记录的是Agent做了什么决定、为什么做这个决定不是网络传了什么字节。这样就能把一次生产事故完整冻结下来，在不调用模型、不花API费用的情况下重放整个执行过程。更有趣的是切点回放概念：你把事故记录里某个边界标为切点，切点之前的所有内容都可以从记录中回放做到字节级别的一致而在切点位置运行你的新代码看修复有没有效。这样一来，一次生产事故变成了永久的回归测试。但需注意脱敏不是录制路径上的可选项而是必须的一道关卡，在写入之前就得要清洗掉敏感信息保留测试需要验证的结构和形态去掉敏感值。

“正确的思路不是追求比特级的确定性，而是追求可回放性。”

上下文预算：架构资源与合规循环陷阱

Token经济学不只是成本管理问题，也是架构问题。蒂莎提出：上下文预算是一种架构资源需要被分配而不是被反射性地消耗。在规范驱动开发（SDD）领域，对比测试显示：Spec Kit生成大约八百行规格制品OpenSpec生成大约两百五十行结果呢？ Spec Kit的token消耗比OpenSpec多了百分之九十七到一百零九但是产出质量并没有更好。也就是说，更结构化的前期投入几乎把token用量翻了一倍效果却没有提升。更有说服力的是苏黎世联邦理工的研究：测试给Agent一个结构化的代码库概览文件是否帮助完成任务。结果跟直觉相反无论是机器生成还是人工编写的上下文文件都降低了任务成功率同时把推理成本提高了百分之二十以上。Agent没有忽略这些文件，它们很听话进行了更广泛地探索跑了更多的测试遍历了更多文件也在更努力地思考但是产出的补丁并没有更好。作者把这种失败模式叫做合规循环陷阱：指的是Agent把认知预算花在了满足结构性护栏上而不是解决问题上。这两组数据指向同一结论：每一条你塞进Agent上下文的额外规则都在消耗它有限的推理预算如果这条规则没有减少不确定性那它不是治理是税。

“上下文预算是一种架构资源，需要被分配，而不是被反射性地消耗。”

结论

AI Agent时代的成本治理必须从请求级别上升到运行级别，从事后分析前移到执行路径内。微软的FinOps for AI框架及开源项目TokenOps和Chronicle提供了具体解决方案：通过共享账本实现多维度成本归因，利用运行时路由和优化降低单token消耗，借助TokenOps在运行级别对多Agent工作流进行实时预算执行和干预（如HALT、MUTATE），并通过Chronicle实现非确定性输出的可回放性以构建永久回归测试。核心洞察在于，上下文是有限架构资源，过度结构化规则会导致“合规循环陷阱”，消耗推理预算而非解决问题。团队需回答四个问题：支出是否可见？定价是否合理？运行是否高效？限制是否扛得住？只有建立正确的FinOps基建，才能在AI规模化中实现真正的价值回报。