Agent 读网页时把整页吞下去，这篇论文想给它装个节流阀

AI agent 读东西的方式一直很粗。搜到一个页面，往往整页吞进上下文，哪怕它只需要其中两行。仓库、文档、工具返回结果，同样如此。token 和延迟跟着涨，真正有用的证据还被稀释掉。

r/LocalLLaMA 上有人分享了一篇论文，题目叫 Read Less, Solve More，做的就是这个事。作者提出 SparseRead，一个可复用的读取控制层，插在 agent 和外部内容之间，不改模型本身。

它由三部分组成：

• Read Intent Protocol：跟踪任务需求怎么演变、来源覆盖到哪一步
• Adaptive Reader Backends：决定证据用什么方式定位、以什么粒度暴露
• Budgeted Read Gate：给单次任务累计暴露的原始内容设上限，超了就回退到完整视图，不至于漏读

外加一个统一的 Reader 接口，让不同类型的资源可以互换着取证据。

数据部分：在六个模型（含 Claude Opus 5）和五个场景上，SparseRead 把总 token 最多降了 92.9%，实际耗时最多降了 89.0%，97% 的配置下任务质量持平或更好。在 Web 深度搜索任务里，token 降 31.0% 到 43.0%，完成时间降 23.0% 到 37.0%。消融实验分别验证了三个模块，另外还跟三个 agent 框架做了集成，说明这套东西能搬。

• 论文：https://arxiv.org/abs/2608.22237
• PDF：https://arxiv.org/pdf/2608.22237
• GitHub：https://github.com/Liuzedooong/SparseReading
• 项目页：https://sparseread.pages.dev/

有网友把它的机制归纳得很直白：把「读文件」这个动作拦下来，先收集意图和上下文，再由工具决定只从文件里抽需要的那部分。他觉得这个思路很自然，算力越多，这类策略会越常见，几家大实验室大概率早就在模型内部做了。

他的另一个判断更值得抄下来：上下文管理是一块新战场，现在很多 harness 还停在玩具阶段。大家热衷于装扩展、写超长 system prompt、堆一堆 skill，但模型的实际效果大概率跟上下文效率成正比。那些没有贡献的上下文，是在给输出拖后腿。他甚至认为，把大部分工具调用换成上下文优化步骤，可能比等一个更聪明的模型更快提升 agent 能力，对本地模型尤其如此。

也有人提到自己用 Yacy 爬资料，工具本身没问题，问题是抓回来的信息太多，直接把上下文塞满了。

这里没有太多道理可讲。换个更大的模型能解决一部分问题，但读文件这一步的浪费，是接口设计留下的，跟模型聪明不聪明关系不大。