物界前沿用Go给Agent的上下文瘦身，这个思路有意思
这篇文章最有价值的信息，是它选的切入角度：在工具输出进入模型上下文之前，先做一次无损修剪。Tokencompress本身有多快倒在其次。这个角度比「优化提示词」「买更大的上下文窗口」都更接近问题的本质，因为Agent的上下文膨胀，根源恰恰在工具层，不在对话层。
我这边用Kimi K3跑复杂任务的时候，经常会碰到一个现象：第一轮对话还能保持清醒，到第三轮、第四轮，模型就开始忘事。模型的注意力被稀释了。你让它调一次API，返回的JSON可能有一万五千个token，但真正有用的字段可能就两三百个。模型得在这堆噪音里捞针，捞着捞着，前面聊的东西就沉下去了。
这个问题的严重程度，我上周在HN上看到一组数据才真正有体感。一个MCP server暴露30个工具，每轮对话光工具schema就要吃掉大约3600个token，不管模型这次用不用这些工具，这笔账都得付。MCP协议的设计初衷是标准化，把工具定义、调用方式、返回格式都统一起来，这个思路没问题。但它有一个隐性的「context tax」，每个MCP server都在往上下文里塞东西，塞得多了，模型能用来思考的空间就少了。
有开发者做过对比，同样一个任务，用MCP方式跑下来，模型可能要发150次工具调用，上下文越滚越大；改成CLI方式，模型一个for循环就搞定了，token消耗直接少一个数量级。
这也是为什么现在有人喊「用CLI取代MCP」，我自己用下来觉得，这个说法只对了一半。MCP的优势在于标准化和生态，它能连的东西多，配置一次就能用；CLI的好处是轻，但你要给模型配一堆命令说明，而且不是所有工具都有好用的命令行接口。Tokencompress走的是第三条路：MCP该用还用，但往上下文里塞东西之前，先做一次瘦身。
它的做法是，把工具返回的原始输出，不管是JSON、终端日志还是HTML，先压缩修剪一遍再喂给模型。修剪的代价不能高，否则省了token费了时间，得不偿失。所以这个「sub-2ms」的性能指标很关键，它意味着修剪的成本可以忽略不计了。我这边测下来，大多数工具返回的JSON都有大量冗余字段，有的字段名都比值长，压缩之后能砍掉一半还多。
不过这里有一个技术难点，不同工具的返回格式差异很大。终端的构建日志有大量重复的输出行，HTML更是有一堆样式和脚本噪音，JSON还可以按schema提取。Tokencompress要用一套通用方案处理所有这些格式，难点是怎么保证压缩之后模型还能理解。过度压缩会丢失语义，压缩不够又省不了多少token，这个平衡点很微妙。
我在想，这类工具的出现，其实反映了Agent开发的一个趋势转移。早期大家拼的是模型能力，模型不够聪明，写出来的Agent就蠢。后来拼的是工程架构，各种框架、编排方式层出不穷。现在大家开始拼context engineering，也就是怎么在有限的上下文窗口里，让模型看到最该看的信息。上下文窗口再大也是有限的，按现在这个膨胀速度，再翻一倍也撑不住。
Gemini那边已经有人在做类似的探索，让agent在复杂的调试循环中主动修剪自己的上下文，而不是等到系统级的auto-compression触发。这个思路和Tokencompress是同一个方向，一个在agent运行层面做，一个在工具接入层做。我个人觉得，工具接入层更务实，因为agent的上下文膨胀是累积性的，你在源头就减掉一批垃圾，后面每一轮对话都能受益。
BitNet那个帖子我上周写过，也是在讨论token成本的问题。当时我觉得，如果BitNet的量化路线跑通，推理成本会大幅下降，调度玩法会变。但后来想明白了，成本下降是硬件层面的，上下文膨胀是软件层面的，两个问题不在同一个维度上。就算推理便宜了，模型在噪音里找重点，该丢的信息还是会丢，这个物理规律改不了。
所以我很看好这类「上下文减脂」工具的定位。它们不改变模型的智力水平，但能帮模型把智力用在正确的地方。Tokencompress现在还很初级，零依赖、单文件、只做修剪，但方向是对的。如果能把修剪规则做成可学习的，针对不同工具自动适配，那就更值钱了。
不过我也很好奇，这种方案的天花板在哪里。工具的返回信息被修剪之后，如果模型发现自己需要被剪掉的那部分信息，它怎么办？重新调用一次工具，拿到了完整输出，又要重新修剪。这个往返的成本，有可能吃掉修剪省下的所有收益。不知道项目后面会不会做「按需复活」的机制，把这个往返的代价压到最低。
本文编译自 Hacker News，原文：GitHub - dburnett11155-rgb/Tokencompress · GitHub
版权归原作者所有，本文为基于公开报道的编译与独立分析。
