编码智能体（Coding Agent）跑在大代码库里时，常出现一种隐性开销：每轮都要靠整文件 grep、全量读取来「找回上下文」。SonarSource 把这笔开销称为「Context Tax（上下文税）」，并给出可量化的解法——用统一的代码语义图替代盲读。
问题背景
Agent 没有「项目地图」概念，它靠工具调用逐文件探索。当仓库有上万文件、依赖关系复杂时，重复的全文读取会迅速累积 token：同一份上下文被反复搬运，模型往返次数（round-trip）随之飙升，既烧钱又容易在长上下文中「迷路」导致误改。
机制原理通俗拆解
Sonar Vortex 的核心是一个统一的依赖图（SemSitter），把「文件在哪、谁引用谁、符号定义与调用关系」预先结构化。Agent 不再盲目 grep，而是向这张图发定向查询——「改动这个函数会影响哪些调用方？」图直接返回精准答案。相当于把「翻遍整栋楼找人」变成「查通讯录」。上下文从「整文件搬运」降为「按需取用」，token 与往返次数同步下降。
技术优化点
关键不在模型，而在检索层的工程化：把语义检索从「向量近似」升级为「语法级依赖图」，定位更准、可解释更强。对 Agent 而言，这意味着更少的上下文污染与更低的误操作概率。
工程取舍与局限性
代价是前期需要为代码库构建并维护这张图，索引成本与更新延迟是现实负担；对频繁重构、元编程密集或强动态特性的项目，图的准确性会打折。此外，语义图解决的是「导航」，不解决「业务语义理解」——Agent 仍要自己判断改什么。上述性能降幅为厂商自测口径，暂无第三方独立复现。
开发者适配建议
在单 Agent 工作流里加一组对比实验：相同任务下，开/关代码图导航的 token 用量与 round-trip 数；若差异显著，优先接入图式导航或自建语义索引。把「上下文预算」当成可观测指标来管，往往比换更大上下文窗口更划算。