本体论优化：Agent依赖探索效率提升指南

Uber在4个多月前向旗下约5000名工程师全面推广Claude Code，该工具迅速在团队中引发使用热潮。然而4个月后，实际用量远超财务模型预期，直接烧光了全年的AI编程预算[1]。这一事件在业界引发激烈讨论，焦点集中在两个核心问题：如何制定Token消耗的最佳实践，以及如何量化其商业价值。鼓励开发者借助AI提升效率、加速产品迭代固然是好事，但企业若想真正用好这类工具，必须先把成本管控的账算清楚。

Token 到底消耗在哪里？

这个问题并不简单，既需要严谨的数据分析，也需要大规模的合规样本。我们从三个维度切入：学术论文[2]、来自Vantage.sh的工程实测数据，以及Reddit上一个1亿Token样本的消耗追踪[4]。

arXiv:2604.22750

《How Do AI Agents Spend Your Money?》[2]发表于今年4月，系统研究了Agent的Token消耗模式。关键发现：Agent处理编程任务消耗的Token量约为普通Chat任务的1000倍，且成本大头来自Input Token（输入）而非Output Token（输出）。更反直觉的是，论文指出Token消耗与任务准确率之间几乎没有相关性——多花钱未必能获得更好的结果。

Vantage.sh

Vantage.sh是一家专注于云成本管理的公司，帮助企业监控和优化多云环境下的费用。他们4月发布的报告《The Hidden Cost Driver in Agentic Coding: It's Not the Per-Token Price》[3]提供了更精确的数据：Agent编程会话的Input/Output Token比约为25:1（约100万Input对应4万Output），Input占总成本的85%左右；Agent会话虽然只占总请求量的十分之一，但费用比非Agent会话贵了约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（生成/输出）。需要说明的是，这三份报告均未考虑多模态输出——若加入图像、视频等，Output占比会大幅提升。但它们都没有对Input Token做更细粒度的分类。问题在于，实际使用中，只知道Agent读了多少并不能帮助定位优化方向，我们需要一个更精细的框架。

下表基于我们的使用经验，并结合行业对Agent Input行为的常见分类共识，做了定性归因：文件检索、关系追踪、上下文管理、生成循环、工具交互。高/中/低排序反映的是日常实践中各类动作对Token消耗的相对贡献，并非实验室的精确测量。

C1（文件盲读）和C2（依赖探索）是消耗最严重的两个来源，两者合计构成了Input Token的主体。这与Jake Nesler所说的“80%浪费在找东西”、Vantage.sh的“重复读文件”、以及arXiv论文中“Input Token主导”的结论完全吻合。C4（生成迭代）和C5（工具试错）虽然也消耗Token，但从实际体验看远不及前两者明显。

在这五个成本源中，C2（依赖探索）是最具结构性、最适合通过架构手段干预的一类。为什么？文件盲读（C1）虽然消耗大，但本质是搜索问题——更好的索引、更精准的文件定位就能缓解。上下文重建（C3）可以依靠更大的上下文缓存或记忆能力来优化。但依赖探索不同——Agent需要追踪实体之间的关系：A调用B、B部署在C、C的SLA等级、C最近的变化。如果这些关系没有被提前结构化，Agent每次都要在纯文本中现场推断，推断失败就重来。下面，我们就以依赖探索为核心，探讨具体的实践。

依赖探索的三个范式

只看Agent如何获取依赖/关系信息这条线，过去三年大致经历了三个阶段。每一阶段解决了上一阶段的核心痛点，但也暴露了新的瓶颈。我们用运维场景的例子来串联：

场景描述：一个名为shopping-user的服务告警触发，但根因实际在下游的shopping-cart（一个用户sleep加NPE，另一个自旋500毫秒）。传统根因分析可能直接指向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-Memory（arXiv:2603.27277）[5]。他们使用Tree-Sitter将代码解析成函数/类/调用链的持久化知识图谱，存储在SQLite中，通过14个MCP工具暴露给LLM。实验在31个代码仓库的hub detection和caller ranking任务上验证：有图谱的消耗约1000个Token，Token消耗压缩了10倍，工具调用减少了2.1倍；无图谱的消耗高达10000个Token。实验覆盖了31个代码仓库、66种编程语言。

UModel：一行代码实现智能异常检测

代码场景的Ontology只是入门。企业运维场景的Ontology，由于领域知识完全不在模型的预训练范围内，效果会更加显著。阿里云可观测团队在《一行代码实现智能异常检测：UModel PaaS API 架构设计与最佳实践》中给出了直白的对比：这是开发者手动集成可观测数据时需要走的路径。如果让Agent在运行时重走同样的路径，每一步都要消耗相应的Token。

但如果提供了UModel这类Ontology，就能避免三类任务的Token开销。

• 多轮元数据查询：无需反复查询EntitySet、MetricSet、Storage的对应关系。原先每一步都需要回模型推理一次，现在Ontology层一次性搞定。
• 字段映射的现场推断：Agent无需判断service_id和acs_arms_service_id是否一致——映射关系已内置于DataLink。
• 查询语法纠错循环：无需因为PromQL/SPL拼错而重试。Object模式下Agent只需表达意图（get_metric()），底层语法对Agent完全透明。

模型变强后，还需要 Ontology 吗？