技术速递｜Token 经济学：智能体 AI 时代的新 FinOps

作者：卢建晖 - 微软高级云技术布道师

排版：Alan Wang

在 AI 应用中，Token 就是成本------Token 经济学值得从架构层面认真思考

很长一段时间以来，AI 应用的设计都是从模型能力出发：模型会不会写代码？能不能推理？是否支持工具调用？能否处理长上下文？这些问题依然重要，但在智能体应用时代，它们已经不足以回答生产环境中的关键问题。真正更值得关注的问题是：完成一个真正有价值的任务，这套架构究竟会消耗多少 Token？

传统聊天应用通常是一轮用户输入对应一次模型调用。而智能体系统则完全不同。一个用户目标，可能会触发规划、检索、工具选择、工具执行、结果解释、反思、修复以及总结等一系列流程。用户看到的只是一个简单的指令，而系统背后却可能已经完成了数十次模型调用。因此，Token 已不再只是衡量文本长度的单位，它开始成为衡量系统架构、运行时行为、开发流程以及业务成本的重要指标。

GitHub Copilot 在 2026 年推出基于 GitHub AI Credits 的按使用量计费模式，正清晰地体现了整个行业的发展方向。如今，计费已经与 Token 消耗直接挂钩，包括输入 Token、输出 Token 以及缓存 Token。这一变化意义重大，因为 GitHub Copilot 已经从最初的编辑器代码补全助手，演进为一个能够跨仓库完成长时间、多步骤开发任务的智能体平台。在这样的体系下，一个几十个 Token 的简单提示词，与持续数小时、能够自主完成编码任务的智能体工作流，显然不应该采用同一种成本衡量方式。

因此，Token 经济学并不是简单地要求开发者"写更短的提示词"。它真正关注的是如何设计一种更加经济、高效的系统，使其能够做到：

保留真正有价值的上下文，同时去除无效信息；
对重复上下文进行缓存或去重，而不是反复发送；
简单任务无需调用能力最强、成本最高的前沿模型；
用结构化方式管理短期状态，而不是不断复制上下文；
让每一次模型调用都能够被计量、比较，并接受统一治理。

归根结底，Token 经济学，就是让智能体 AI 在经济上实现可持续发展的工程实践。

场景化思考：GitHub Copilot 计费、Copilot SDK、GPT-5.5、Anthropic 与 MAI-Code Model

GitHub Copilot 全新的计费模式，为开发者提供了一个非常具有代表性的思考框架。今天的 Copilot 已不仅仅是代码自动补全工具，而正在演变为一个可编程的智能体平台。它能够调用不同的大模型，使用各种工具，跨多个文件协同工作，流式返回响应，参与长时间运行的软件开发工作流。随着 GitHub Copilot SDK 的推出，开发者还可以将这一智能体运行时嵌入自己的应用、服务以及开发工具之中。

这无疑极大拓展了 Copilot 的能力，同时也彻底改变了成本模型。当一个 Agent Loop 可以被编程时，Token 成本同样需要能够被编程。如果系统能够自主规划、调用工具、修改文件、重试失败步骤、修复问题并生成总结，那么它同样需要具备 Token 计量、智能路由、上下文缓存、内容压缩、效果评估等能力。

EvalAgentic 项目很好地展示了这一理念。它按照成本与能力，将模型划分为不同层级：

层级	示例模型	每 1K Token 示例价格	典型用途
LARGE	claude-opus-4.8、gpt-5.5	$0.030	智能体、代码生成、多步骤推理
MID	gpt-5.4-mini	$0.012	对话、摘要、信息抽取
TINY	gpt-5-mini	$0.001	分类、关键词匹配、规则型任务

这种模型分层，让我们能够更加理性地思考真实的软件开发场景。例如：

GPT-5.5 这一类前沿模型，非常适合处理复杂推理和软件工程任务，但并不应该成为所有步骤的默认选择。使用最先进的大模型去完成简单分类任务，就像请一位首席架构师专门负责给文件夹贴标签一样，成本远高于收益。
Anthropic 的高性能模型在复杂推理和代码生成方面表现十分出色，但同样需要合理的模型路由策略。需求分析、测试结果解读、部署说明以及代码生成，并不一定都需要使用同一个模型层级。
MAI-Code Model 这一类代码专用模型，更应该被视为智能体系统中的专业能力层。它们真正的价值不仅在于"代码生成得更好"，更重要的是能够决定整个智能体流水线中的哪个环节最适合调用代码专用智能能力。

真正值得思考的问题，从来都不是："哪个模型最好？"而是："对于工作流中的当前步骤，哪个模型能够以最低的成本、最高的可靠性完成任务？"

四种节省 Token 的工程实践

上下文压缩：将长文本转化为可执行的结构

实现原理

上下文压缩的核心目标，是将冗长的自然语言上下文，转换为智能体真正需要的结构化信息。在实际业务中，文档往往非常冗长：简历、合同、产品手册、需求文档、客服日志等，通常包含大量叙述性文字、模板化内容、重复说明以及低价值上下文。而智能体的下一步操作，可能只需要其中几个关键字段。

EvalAgentic 就展示了这一思路：系统会将一段类似长简历的输入，压缩为一个紧凑的 JSON 对象。这样一来，无需在每一次提示词中反复注入完整原文，而是提取关键字段，并根据当前任务动态注入真正需要的数据。

一个实用的上下文压缩流水线通常包括：

冗余检测 ------ 识别长尾文本、重复描述、过期历史记录以及低价值上下文。
结构化提取 ------ 使用 Copilot 或中等规模模型，将自然语言转换为 JSON、表格或类型化 Schema。
动态注入 ------ 仅向下一步任务注入所需字段。
可恢复引用 ------ 保留源数据指针，使压缩后的上下文仍具备可审计性。

如何评估

可以从以下几个维度进行评估：

压缩前后提示词 Token 的减少量；
回答质量与任务成功率；
Schema 保真度与缺失字段率；
延迟改善情况；
单个成功任务的平均成本。

压缩并不等于摘要。摘要是为人类阅读而设计的；而结构化压缩则是为智能体执行任务而设计的。

提示词去重与缓存：避免为相同的上下文重复付费

实现原理

许多智能体系统之所以会浪费大量 Token，是因为它们不断重复发送相同的上下文。同一份简历、合同、仓库 README、用户画像、API 文档或业务规则，可能会在多个对话轮次甚至多个智能体之间被反复复制和发送。

提示词去重与缓存的核心原则非常简单：如果某段上下文已经处理过，并且内容没有发生变化，就不要再次为处理它付费。

一个典型的实现方案通常包括以下几个方面：

为源上下文计算哈希值或语义标识，用于判断内容是否相同。
复用已经提取好的结构化结果，当内容完全一致或语义等价时，无需重新解析。
为重复实体设置 TTL，例如 EvalAgentic 中展示的 24 小时缓存机制，避免频繁重复计算。
组织稳定的提示词前缀，在支持提示词缓存的模型服务中，充分利用提供商的缓存能力。
将共享上下文存储到 Artifact Store 或 Memory Layer 中，使多个智能体能够共享同一份上下文，而不是各自复制同一大段内容。

如何评估

可以通过以下指标评估提示词去重与缓存的效果：

缓存命中率
缓存 Token 占比
重复提示词比率
启用缓存前后的成本变化
缓存情况下的正确性，尤其要关注因缓存过期导致的错误。

缓存并不是"把所有内容永久保存"。真正优秀的缓存机制，关键在于知道什么时候应该复用，什么时候应该失效并重新计算。

按需模型路由：让任务复杂度决定模型层级

实现原理

按需模型路由的核心思想是：将每个请求路由到能够可靠完成当前任务且成本最低的模型。路由入口可以采用规则树、轻量级分类器，或结合多种因素计算的任务复杂度评分来完成决策。

EvalAgentic 提供了一个非常直观、易于理解的模型路由树：

plain 复制代码

INCOMING REQUEST
  └─ Prompt < 500 tokens? ── YES ─→ TINY: classify / extract
  └─ NO ──→ multi-step reasoning?
        ├─ NO ─→ MID: dialogue / summary
        └─ YES ─→ LARGE: agent / code

其背后的工程逻辑十分明确：

简单的分类和关键词匹配，交由 TINY 模型处理；
摘要生成、结构化转换等任务，交由 MID 模型完成；
多步骤推理、代码生成、跨文件修改以及智能体编排等复杂任务，则交由 LARGE 模型负责；
像 MAI-Code Model 这样的代码专用模型，应作为编码阶段的专业能力层，在需要编写代码时调用，而不是贯穿整个智能体流水线。

如何评估

可以通过以下指标评估模型路由策略的效果：

路由准确率
各路由路径的平均成本
不同模型层级带来的质量变化
从小模型升级到大模型的比例
端到端任务成功率

模型路由并不意味着"永远使用最小的模型"。它真正的目标是：只在能够真正改变任务结果的关键步骤，才使用能力最强的前沿模型；而对于其他步骤，则尽可能使用成本更低、更高效的模型。

短期记忆：保存状态，而不是重放历史

实现原理

短期记忆的作用，是控制多轮对话和多智能体工作流中的上下文增长。如果没有短期记忆机制，智能体往往会在每一次交互时，重复发送完整的对话历史，完整的工具输出，完整的中间推理过程。结果就是：上下文越来越长，模型质量未必提升，而 Token 成本却一定会持续增加。

一种更合理的设计方式，是以结构化状态的形式保存信息，例如：

用户目标
当前执行计划
工具输出及其引用
失败原因
下一步行动
智能体之间交接的工作产物

例如，在一个多智能体的软件开发流水线中：需求智能体应当交付一份结构化需求规格，编码智能体应直接读取这份规格，而不是重新阅读此前的全部对话历史，测试智能体应基于可测试的工作产物开展测试，而不是重新消费编码智能体生成的所有内容。通过这种方式，整个工作流中的每个智能体都只获取自己真正需要的信息，而不是不断重复传递完整历史上下文。

如何评估

可以通过以下指标评估短期记忆机制的效果：

多轮对话中的上下文增长曲线
记忆检索准确率
因状态缺失导致的返工率
任务失败后的恢复质量
每轮平均输入 Token 数

短期记忆并不是要记住所有内容。它真正的目标是：记住下一步真正有用的信息，而不是记住所有历史。

EvalAgentic：一个具体的评估实践示例

EvalAgentic 之所以是一个有效的传播型项目，是因为它将 Token 经济学转化为一个可以清晰观察"前后对比"的系统。

其整体架构分为五层：

前端层 ------ frontend/index.html 提供 A / B / C 三个 Tab、实时 SSE 日志以及前后对比图表。
API 层 ------ backend/server.py 基于 FastAPI 提供接口，并支持 Server-Sent Events 流式输出。
编排层 ------ eval.py 负责 A/B 测试评估，coding_agents.py 负责多智能体编码场景。
核心层 ------ compressor.py、router.py、gh_models.py、token_meter.py 分别实现上下文压缩、模型路由、Copilot SDK 调用以及 Token 计量。
模型与能力提供层 ------ GitHub Copilot SDK 与 Microsoft Agent Framework 提供模型访问与智能体编排能力。

Tab A：上下文压缩对比

Tab A 展示的是"长文本上下文在压缩前后"的对比结果。其核心信息是：Token 节省并不是来自"写得更简洁的一句话提示词"，而是来自将冗长上下文转换为下游智能体可以高效消费的结构化产物。

Tab B：按需模型路由

Tab B 证明了一个关键观点：成本不仅仅取决于 Token 数量本身。如果系统能够将简单任务路由到更便宜的模型层级，并为复杂推理保留高成本模型，那么即使某些 Token 使用量增加，整体成本仍然可能下降。这是一个非常重要但容易被忽略的点：Token 经济学不是"减少 Token 使用"，而是"优化模型组合"。它的本质更接近于一种模型资产组合优化，而不是单纯的节流策略。

Tab C：编码场景------基于 Agent Framework 的多智能体系统

Tab C 是最具说服力的演示。在该场景中，同一个交付目标------构建一个类似淘宝商品列表的网站（包含 HTML + JavaScript 前端、Flask 后端以及 Docker 部署）------通过四智能体流水线分两次生成：

需求智能体
编码智能体
测试智能体
部署智能体

优化前的流水线没有使用任何压缩机制，并将所有智能体统一路由到 GPT-5.5 / LARGE 模型。

优化后的流水线则引入了压缩后的 JSON 规格，并采用按需模型路由策略：需求阶段可使用 MID 模型，编码阶段使用 LARGE 模型，测试阶段使用 MID 模型，而部署阶段则使用 TINY 模型。

这一设计很好地映射了真实的企业级软件开发流程：架构设计与复杂代码生成确实可能需要前沿大模型的能力，而测试结果解读、部署打包以及简单校验等任务，往往并不需要同等级别的模型支持。

基于项目图的总结与优化

EvalAgentic 的 README 中描述了三张关键图：架构流程图、路由决策树以及 Token 计量设计图。三者共同构成了一个完整的治理闭环：

plain 复制代码

User Scenario
   ↓
Context Compression
   ↓
Prompt Deduplication / Cache
   ↓
On-Demand Model Routing
   ↓
Short-term Memory
   ↓
Token Metering & Budget Actions
   ↓
Before / After Evaluation

优化路径，而不仅仅是提示词

许多团队在进行 Token 优化时，往往从"改写提示词语句"开始。这确实有一定效果，但最大规模的浪费通常并不在提示词本身，而在执行路径中调用了多少次模型，上下文是否被重复发送，工具是否频繁重试，每一步是否都使用了同一个高成本模型。EvalAgentic 的价值在于，它通过 A/B 对比让整个执行路径变得可视化。

Token Meter：成本治理的控制平面

EvalAgentic 的 token_meter.py 采用了一种非侵入式拦截器模式：

plain 复制代码

INTERCEPTOR (@token_meter)
  ↓
COUNTER CORE: accounting / budget threshold / trigger
  ↓
ACTION HUB: throttle (>80% budget) / rollback (>budget)

这种设计非常关键。在生产系统中，必须具备阈值控制、限流机制、回滚能力以及完整的可追踪性。否则，一个看似普通的重试循环，就可能在无声无息中把一个小请求变成一次预算事故。

成本指标必须与质量指标一起评估

如果一个系统将成本降低 80%，但同时成功率下降 50%，那么它并不是优化，而是以更低成本的方式把系统搞坏了。因此评估体系必须同时考虑成本、质量、延迟与可靠性：

维度	指标	意义
成本	每个成功任务成本	衡量真实单位经济性
Token	输入 / 输出 / 缓存 Token	识别压缩与缓存机会
质量	通过率 / 回归率	确保低成本不会破坏结果
效率	延迟 / 重试次数	防止低价模型导致高成本重试
治理	预算超限 / 回滚次数	验证运行时控制能力

一个简洁的叙事总结

在演示中，一个三行叙事通常非常有效：

Token 不再只是技术细节，而是架构的真实账单。
EvalAgentic 展示了同一场景在成本感知设计前后的差异。
优化目标不是让模型更便宜，而是让智能体系统具备经济可治理性。

面向开发者的更精炼版本：

一个优秀的智能体系统，不会在所有地方都使用最大模型，而是在正确的步骤，用正确的智能，在正确的上下文中，并在正确的预算约束下运行。

面向真实项目的实践建议

**先建立 Token 基线。**在优化之前，必须先测量清楚：输入 Token、输出 Token、重试次数、工具调用次数，以及每个场景的真实成本。
**让"压缩"成为系统组件，而不是提示词习惯。**明确定义 Schema、缓存策略以及失败兜底机制，而不是依赖开发者在提示词中手动优化。
**引入模型路由矩阵。**根据任务类型、复杂度、风险等级、延迟要求与成本约束进行路由决策，而不是固定使用单一模型。
**定义智能体之间的交接契约。**在智能体之间传递结构化产物，而不是无限增长的对话历史。
**对所有优化进行 A/B 测试评估。**同时对比成本、质量、延迟与系统稳定性，避免"只优化成本"的片面结论。
**加入预算控制机制。**在达到阈值时进行限流，在超出预算时执行回滚，并为失败重试加入熔断机制。

结语：Token 经济学是智能体工程的第二曲线

AI 应用开发的第一阶段，是"调用模型"；第二阶段，是"把模型用在产品里"；而智能体 AI 的下一阶段，则是让这些系统能够可靠、经济且可治理地运行。

EvalAgentic 的意义在于，它把上下文压缩、提示词去重与缓存、按需模型路由以及短期记忆这些机制，变成了开发者可以运行、对比和解释的系统工程能力，从而将 Token 经济学从"观点讨论"推进到"工程可观测性"。

未来的 AI 应用不会只问：这个智能体有多聪明？而会问：

每完成一个任务消耗了多少 Token？
使用了哪一类模型？
是否命中缓存？
重试是否失控？
是否把最强模型用在了真正值得的步骤上？

技术速递｜Token 经济学：智能体 AI 时代的新 FinOps

在 AI 应用中，Token 就是成本------Token 经济学值得从架构层面认真思考

场景化思考：GitHub Copilot 计费、Copilot SDK、GPT-5.5、Anthropic 与 MAI-Code Model

四种节省 Token 的工程实践

上下文压缩：将长文本转化为可执行的结构

实现原理

如何评估

提示词去重与缓存：避免为相同的上下文重复付费

实现原理

如何评估

按需模型路由：让任务复杂度决定模型层级

实现原理

如何评估

短期记忆：保存状态，而不是重放历史

实现原理

如何评估

EvalAgentic：一个具体的评估实践示例

Tab A：上下文压缩对比

Tab B：按需模型路由

Tab C：编码场景------基于 Agent Framework 的多智能体系统

基于项目图的总结与优化

优化路径，而不仅仅是提示词

Token Meter：成本治理的控制平面

成本指标必须与质量指标一起评估

一个简洁的叙事总结

面向真实项目的实践建议

结语：Token 经济学是智能体工程的第二曲线

参考资料