Tokenmaxxing 困局，有立竿见影的改善方案吗？

4个多月前Uber 开始向旗下约 5000 名工程师全面推广 Claude Code该工具迅速在工程师群体中引发热潮但4个月后使用量远超公司财务模型的预期烧光了全年的 AI 编程预算[1]。这一案例引发了的社区的连锁讨论一是控制 Token 消耗的最佳实践二是如何量化商业价值。由此可见鼓励开发者使用 AI 提效、加速产品迭代和创新的同时建立透明的成本管控机制将成为各大企业面临的重要课题。一、Token 都烧在哪里这是一个复杂的问题既依赖严苛的统计学又需要大量的合规样本。我们尝试从以下三类数据源对Token 消耗的分布做一番初探学术论文 arXiv:2604.22750[2]、来自 Vantage.sh 的工程实测 、Jake Nesler[3]、Reddit 1 亿 token 样本的消耗追踪[4]。arXiv:2604.22750《How Do AI Agents Spend Your Money?》[2] 发布于今年4月对 Agent Token 的消耗作了非常系统的研究核心发现是 Agentic 编程任务消耗的 Token 量是普通 Chat 的约 1000 倍而 Input Token 而非 Output Token 主导了绝大部分成本论文同时报告了一个反直觉的结论Token 消耗与任务准确率之间几乎没有相关性r 0.15即花更多钱并不能买到更好的结果。Vantage.shVantage.sh 是一家云成本管理平台公司帮企业看清并优化多云环境下的费用支出并提供成本报告、预算预警、资源优化建议等能力。他们在今年4月发布了《The Hidden Cost Driver in Agentic Coding: It’s Not the Per-Token Price》[3]提供了有关 Token 消耗更加精确的数据Agentic 编程会话的 Input/Output Token 比约为 25:1约 100 万 Input vs 4 万 OutputInput 占总成本约 85%Agentic 会话虽然只占总请求量的 1/10却比非 Agentic 使用贵约 200 倍并识别出会话分为三个阶段探索→实现→测试迭代其中前 10 轮的探索期 Token 消耗密度最高。Reddit 100M Token 追踪这是一位 Claude Code 重度用户在 r/ClaudeAI 发布的个人追踪数据1289 次请求、1 亿 token 样本量[4]其中 99.4% 的 AI 开销来自 Input Token作为独立的、未经过滤的一手使用数据它从实操层面印证了学术论文和 FinOps 报告的方向判断Agent 的成本问题本质上是读太多而非写太多。综合以上来源三份报告的共识是Agent 的 Token 消耗绝大部分是 Input理解/寻找而非 Output生成/输出需要注意的是以上三份报告未涉及多模态的输出若考虑多模态输出占比会显著提升。但它们均未对 Input Token 做进一步的细分归类。然而在实际使用中Agent 读了很多并不能帮我们定位优化方我们需要一个更细的分类框架。下面这张表是我们基于个人使用 Agent 的经验结合行业中对 Agent Input 行为的常见分类共识所做的定性归因分为文件检索、关系追踪、上下文管理、生成循环、工具交互。其中高/中/低排序反映的是日常体感中各类动作对 Token 消耗的相对贡献不是某个实验的精确测量结果。C1文件盲读和 C2依赖探索是消耗最重的两个来源合计构成了 Input Token 的主体。这与 Jake Nesler 的 “80% wasted finding things”、Vantage.sh 的 “re-reading files”、arXiv 的 “input tokens dominate” 三方互证。而 C4生成迭代和 C5工具试错虽然也消耗 Token但在体感上远不如前两者夸张。在这五大成本源中C2依赖探索是最具结构性、最适合作为架构手段干预的一类。为什么这么说文件盲读C1虽然消耗同样重但本质上是搜索问题更好的索引、更精准的文件定位就能缓解。上下文重建C3可以靠更大的上下文缓存、记忆能力来优化。但依赖探索不一样Agent 追踪的是实体之间的关系A 调用 B、B 部署在 C、C 的 SLA 是几级、C 最近变更了什么。这种关系如果不被提前结构化Agent 每次都得在纯文本中现场推断推断失败就重来。接下来我们将以依赖探索为关键词聊聊我们的实践。二、依赖探索的三个范式如果我们只看 Agent 如何获取依赖/关系信息这一条线过去三年差不多走过了三个阶段。每一代都解决了上一代的核心痛点也暴露了新的瓶颈。下面的演进对比中我们用运维场景的例子来串联。场景描述一个名为 shopping-user 服务的告警响了但根因实际在下游的 shopping-cart一个用户 sleep NPE、另一个自旋 500ms。传统根因分析把矛头指向 shopping-user 本身只有在明确知道shopping-user 调了 shopping-cart、shopping-cart 调了 shopping-item这条依赖链的情况下Agent 才能沿着拓扑往下查到真正的故障点。这是一个典型的依赖探索决定了诊断成败的场景用它来展示三代范式如何处理依赖信息这样最直观。Stuffing 卡在容量RAG 用检索把容量打开了RAG 又卡在语义碎片化我们拿到一段相关文本依然不知道它和当前问题里的实体有没有直接的依赖关系Ontology 则是把实体和实体关系提到了一等公民的位置Agent 从在文本里推断关系变成了在图谱上查询关系。三、Ontology 如何降低依赖探索的 Token 消耗我们从代码场景和运维场景两个方向提供两组实证探究有 Ontology和没 Ontology之间的具体差距。代码知识图谱10× Token 压缩2026 年 3 月Martin Vogel 等人发表了 Codebase-MemoryarXiv:2603.27277[5]用 Tree-Sitter 将代码解析为函数/类/调用链的持久化知识图谱存储在 SQLite 中通过 14 个 MCP 工具暴露给 LLM实验结果是在 31 个代码仓库的 hub detection 和 caller ranking 任务上验证有图谱的消耗约 1,000 token、token 消耗压缩 10 倍、工具调用减少 2.1 倍没图谱的消耗了高达 10,000 token实验覆盖 31 个代码仓库、66 种编程语言方法是用 Tree-Sitter 将代码解析为持久化知识图谱存储在 SQLite 中通过 14 个 MCP 工具暴露给 LLM。UModel一行代码实现智能异常检测代码场景的 ontology 只是入门。企业运维场景的 ontology由于领域知识完全不在模型预训练范围内效果会更为显著。阿里云可观测团队在《一行代码实现智能异常检测UModel PaaS API》中给出了一个直白的对比。以下是开发者手动集成可观测数据时需要走的路径。如果让 Agent 在 runtime 重走同样的路径每一步都要消耗对应的 Token。但如果提供了 UModel 这类 ontology就能避免三类任务的 Token 开销。多轮元数据查询不再反复查 EntitySet、MetricSet、Storage 的对应关系。原先每一步都需要回到模型推理一轮现在 ontology 层一次性解析完毕。字段映射的现场推断不需要 Agent 琢磨service_id和acs_arms_service_id是不是同一回事——映射关系已内置于 DataLink。查询语法纠错循环不需要 PromQL/SPL 拼错一次再回来重试。Object 模式下 Agent 只需表达意图get_metric()底层语法对其完全透明。四、模型变强后还需要 Ontology 么到这里一个不可回避的问题浮出水面如果上下文窗口持续变大、推理成本持续下降Ontology 的价值会被蛮力吃掉吗我们的判断是取决于领域。对于代码场景答案确实有些暧昧。代码是模型预训练的主战场随着模型能力持续增强它理解一个新 codebase 的能力确实在变强。在这个领域里ontology 的价值可能逐步被模型内化。但一旦换运维Ops这种企业级领域情况完全不同。我们认为这是一个 Ontology 价值最明确、最不可能被模型吃掉的正面案例。原因有三企业内的实体和实体关系永远不在通用模型的预训练语料中。企业的实例规模、服务拓扑、CMDB 配置、告警规则、变更窗口、值班排班这些实体信息每天都在变。运维的本质是关系推理。告警在 A根因在 B中间经过三层依赖。如果这条依赖链不是结构化地给到 Agent它就得在日志和文档里一段段翻找、一步步猜模型变强能加速推理但不能消灭没有信息这个问题。运维作为严肃场景对准确率的容忍度极低。自主运维误判一次根因可能把正常服务重启掉或者放过真正的故障导致 P0 级事件。在这种场景下83% 的准确率是不可接受的你需要 ontology 来把质量损失逼近零。Palantir 是企业 Ontology商业价值最具说服力的验证案例。他们的核心产品 AIPAI Platform底层就是一套 ontology把企业的人员、资产、流程、数据画成统一图谱让 AI Agent 在上面做推理。Palantir 市值高达3000亿美金本质上是资本市场对企业 Ontology这个能力的定价不只是省 token更关键的是让 AI 输出变得可靠、可审计、可操作。五、阿里云的 Ontology 实践STAROps说到这里我们想把讨论落到一个具体的、已经在线上运行的工程实践上。阿里云近期发布的全域智能运维平台 STAROps它将大模型技术、UModel、RCA、RCA benchmark 进行有机结合是国内在 AIOps 方向上把 Ontology 落地得较为完整的实践。其中UModel 是本体论层负责定义运维世界里的实体以及实体之间的关系。RCARoot Cause Analysis是阿里云可观测团队面向分布式系统故障诊断的实践方法论RCA benchmark 提供了标准化根因分析评估数据集与评估协议体系联合信通院、小鹏汽车、中科院软件共同发起。接下来我们通过一段实操视频感受 ontology 在运维场景故障诊断一个前端应用报错中所发挥的应用。Ontology 在故障诊断场景下的应用实体感知确定需要诊断的实体frontend。自动编排多源查询系统自动生成了一张调查拓扑图展示 frontend 及其上下游服务的调用关系查询 ERROR 级别日志提取具体异常堆栈。深度调查系统自动编排多步观测数据查询包括 Pod 级存储/文件系统指标、K8s Events 查询、资源变更记录查询、下游服务拓扑获取等。给出故障实体症状现象frontend 服务在告警窗口内 HTTP 500 状态码占比极高。证据Trace 差异分析显示 http.status_code500 的 diff 值高达 0.958关键错误堆栈显示 TypeError: Cannot read properties of undefined (reading ‘streetAddress’)发生在渲染 /cart/checkout/[orderId] 页面时这表明前端依赖的某个数据结构预期从 ad 服务获取为空。因果链确认Ad 服务滚动更新 → 部分 Pod 不可达ECONNREFUSED→ Frontend 调用 Ad 服务失败 → Frontend 代码未捕获该依赖失败或处理返回的空数据 → 抛出 TypeError → 用户请求返回 500 错误。数据完整性自评明确数据缺失无。核心链路 Trace、Pod 指标、K8s 事件均已覆盖部分 Pod 的拓扑查询如 obs_117, obs_124未执行但不影响根因判定。处置建议紧急修复检查 ad 服务所有 Pod 状态确保全部 Ready。若有异常 Pod立即重启或回滚 ad 服务 deployment。代码优化修复 frontend 服务代码增加对 ad 服务返回数据的判空处理或添加 try-catch 块防止单点依赖失败导致整个页面崩溃实现优雅降级。配置检查审查 ad 服务的滚动更新策略maxSurge、maxUnavailable及健康探针readinessProbe配置确保更新期间服务可用性。[1] https://www.forbes.com/sites/janakirammsv/2026/05/17/uber-burns-its-2026-ai-budget-in-four-months-on-claude-code/[2] https://arxiv.org/abs/2604.22750[3] https://www.vantage.sh/blog/agentic-coding-costs[4]https://www.reddit.com/r/ClaudeAI/comments/1roxoo5/i_tracked_100m_tokens_of_coding_with_claude_code/[5] https://arxiv.org/abs/2603.27277