你家AI每次读7千字废稿，我逼它只看73字精华！SMELT编译器免费开源：点击标题！
OpenClaw每次对话都重复读取7千多令牌的固定文件，SMELT编译器通过查询相关性筛选，只发送真正需要的几十个令牌，最高节省95%成本。
OpenClaw每次聊天都重复发送同样的四份文件，这简直是在用你的钱放烟花
Reddit上有个叫u/TooCasToo的老哥，他实在看不下去了。他说每次你在OpenClaw里发一条消息，不管问什么，系统都会把USER.md、SOUL.md、MEMORY.md和AGENTS.md这四份文件原封不动地塞给AI模型。
注意，不是只在启动时干一次，是每条消息都干一次。
这是什么概念呢？就好像你每次问朋友“今天吃了吗”，他都要先把整本百科全书从头到尾念一遍，然后才回答“吃了”。这哥们自己用的是一台M3-Ultra芯片的电脑，跑的是Qwen 3.5 122B这个模型。
他实际测了一下，光启动那一堆固定文件就占了7268个令牌。如果你跟他聊50条消息，那就是35万多个令牌全浪费在重复读取那些完全没变化的内容上。模型连你问了啥都还没看见呢，钱包先瘦了一圈。
真实数据对比：问“谁是Sally”从1373个令牌压到73个，省了94.7%
这老哥不光吐槽，他还真动手做了个东西叫SMELT。这名字听着像某种黑暗魔法，其实就是个编译器，专门把你的工作区里的Markdown文件重新打包成更密实的格式。
最关键的是第四层，叫查询条件式检索。这一层会根据你实际问的问题，只挑出相关的记录发出去，而且连带着保留它所在的父章节上下文。比如你问“谁是Sally”，系统不会傻乎乎地把整个灵魂设定文件都扔过去，而是只把跟Sally有关的那一小块摘出来。
他自己跑出来的数字特别提神：问“谁是Sally”的时候，原始Markdown要1373个令牌，SMELT只用了73个，省了94.7%。问“John什么时候出生”，1374个令牌变成62个，省了95.5%。哪怕是宽泛地问“跟我说说Alex”，也从1373个令牌降到了328个，省了76.1%。启动时候的首次生成时间从14121毫秒降到了13273毫秒，快了6%。别小看这6%，你想想本地跑大模型的时候那个等待有多煎熬。
缓存不是万能药：就算成本便宜了，注意力稀释的问题照样让你AI变智障
评论区有人提出一个听起来很专业的反驳。
u/Ok_Mammoth589说，这些文件虽然每次都会发，但很多模型API是有缓存的。缓存过的令牌价格便宜很多，所以实际花费并没有那么夸张。而且如果你不把这些文件发给AI，那你要它们干嘛？你根本不知道AI会用到灵魂文件里的哪一部分，那个东西之所以叫灵魂，就是因为它会潜移默化影响模型的行为。
这说法乍一听挺有道理。但TooCas的回应特别到位。他说缓存确实能省钱，但缓存对本地模型一点用都没有。本地跑模型根本没有缓存层这种东西，每条消息的每一个令牌都得重新走一遍预填充过程。
更重要的是，缓存解决不了注意力稀释的问题。哪怕你花的是折扣价，模型依然要把注意力权重平均分配到那7000多个令牌上。你问的是“我叫什么名字”，模型却要同时盯着7000个不相关的字。这就像你去餐馆点一份蛋炒饭，服务员端上来一整桌满汉全席，说反正你付的钱一样，慢慢找吧。
层四的神操作：不是瞎删东西，而是每个记录都跟问题打分，只放相关的进来
很多人一听到压缩就以为是在瞎删内容。TooCas专门强调，SMELT的第四层不是那种暴力截断。它会对每一条记录跟当前的实际查询做相关性评分。得分高的记录才被发送，而且发送的时候会连带着它所在父章节的上下文一起打包。
如果你问的问题确实涉及到灵魂设定里的某一条，那这条记录就会通过。如果问的是“今天天气怎么样”，那整个灵魂文件根本不会出现在发送列表里。这跟你自己手动删文件最大的区别在于，它保留了结构化的关联关系。你不用担心AI因为缺了某段背景就胡说八道。因为它只删那些跟当前问题八竿子打不着的内容。
换句话说，SMELT不是在帮你省钱，而是在帮AI省脑子。注意力预算就那么点，你让它少看点废话，它就能多想想正事。
开发者的自白：我测了实际tokenizer，字节压缩和令牌压缩根本不是一回事
TooCas在帖子里特别提到一个很多搞压缩的人容易踩的坑。
他说字节压缩和令牌压缩是完全不同的两码事。如果你不用你实际使用的那个tokenizer来测量，那你的数字就是在撒谎。
什么意思呢？就是你用gzip把一个文件压小了，不等于这个大模型读它的时候令牌数就少了。因为不同tokenizer的分词规则不一样，同一个字节序列在不同模型眼里可能会被切成完全不同的令牌。有些人拿字节级别的压缩率出来吹牛，结果换个模型就露馅了。
TooCas说他所有的测量都是对着实际跑模型的那个tokenizer来做的。所以他的94.7%和95.5%是实打实的令牌节省，不是字节层面的数字游戏。
这一点对于任何打算自己搞上下文压缩的人来说，都是个血泪教训。别拿压缩软件的指标去骗AI，AI不认那一套。
目前的短板：schema还是手写的，任意Markdown需要机器学习来学结构
SMELT现在还不是万能药。
TooCas自己交代得很清楚，目前这套schema是针对OpenClaw工作区文件的手工打造版本。他专门研究了OpenClaw那几份固定文件的写法习惯，然后根据这些习惯设计了压缩和检索规则。如果你丢给他一个完全没见过的Markdown文件，结构乱七八糟的，那他目前还搞不定。
他计划下一步是让SMELT能够自动学习任意Markdown文档的schema。这本质上是个结构识别问题，需要用到一些轻量级的机器学习或者启发式规则。但现在这个版本对于用OpenClaw的人来说已经够用了。你不是刚好就在用OpenClaw吗？那就正好。
你要是不用OpenClaw，那这个工具对你来说就是个参考，你可以自己照着思路改。TooCas说得很实在，他就是一个人，没有团队，这玩意儿就是个概念验证的alpha版本，放出来就是给大家玩的。
许可证问题引发争议：CC-BY-NC-ND让想贡献代码的人直接扭头就走
评论区有个叫u/StargazerOmega的用户，说话挺狠的。他先肯定了问题的真实性和SMELT的实用性，但紧接着就开炮了。他说你把东西传到Zenodo上不等于通过了同行评审，那就是个存文件的地方，谁都能传。你在一台机器上测了一个模型，这不叫研究论文。而且你说的那个95%节省，本质上就是从“发所有东西”变成“只发相关块”，这在检索增强生成领域是常规操作，不是什么突破。最狠的是最后一句，他说你这个CC-BY-NC-ND许可证让任何人都没法在你基础上继续开发。NC是非商业，ND是禁止衍生。也就是说别人不能改你的代码拿去用，也不能商用。那谁还愿意给你贡献代码？
TooCas赶紧回复说那是笔误，他其实不在意别人修改或者用于个人用途。
但StargazerOmega直接回了一句，你想让人帮忙就改许可证，不然谁有闲工夫理你。
这段对话特别真实地反映了开源社区的潜规则。你放个限制太多的许可证，大家会觉得你不是来开源的，你是来秀肌肉的。
RUNE技术预告：模型自己就能做压缩，跟SMELT配合起来效果更炸裂
TooCas在他的回复里反复提到另一个项目叫RUNE。他在好几个地方都贴了链接，说这个RUNE是一种能让模型自己执行压缩的技术。
如果说SMELT是在外面把文件压好了再喂给模型，那RUNE就是让模型在推理过程中自己动态压缩。
这两个东西绑在一起用，效果会更夸张。
他放了一份RUNE的说明PDF，里面讲了一种算法，具体怎么实现的他没细说，但口气挺大的。他说模型本身就能学会这种压缩模式，不需要外部工具。
这意味着什么？意味着未来你的AI在聊天的时候，会自动识别哪些信息是重复的，哪些是废话，然后自己把它们压缩成更紧凑的形式再处理。这就像你训练一个快递员，一开始他每次送件都要翻遍整个仓库，后来他自己学会了哪些货架最常去，直接走到那几排前面。
TooCas说这两个项目都是他一个人在做，目前处于开发状态，不是商业成品，但足够让那些有技术底子的人拿来玩出花。
个人使用完全免费，API调用者也能自己动手集成
TooCas在帖子最后明确写了，这个SMELT编译器个人使用完全免费。
他还在跟评论区的对话里说，这东西也可以用在Codex、OpenCode或者Claude Code上。
虽然他现在这个版本是针对本地模型写的，但那些会写代码的人完全可以自己改一改，把它接到API上去用。原话是“你们这些有超级技能的人知道怎么给API实现”。他把自己放在一个提供原始技术的位置，不打算组团队搞商业化，就是放出核心技术，让你们自己折腾。
这种态度在开源社区里其实挺讨喜的。不装大佬，不端着，就是东西我做出来了，你们拿去用，有问题你们自己改，改完了你们开心就行。
实测本地模型的真实痛：没有缓存层，每条消息都是从头算
那些只用闭源API的人可能不太理解TooCas为什么这么激动。因为像Claude和GPT的API是有提示缓存的。你重复发送同样的内容，API后台会识别出来，然后只收你一个很低的缓存价格。但本地跑模型完全是另一回事。你在自己的M3 Ultra或者RTX 4090上跑Llama或者Qwen，没有任何缓存层。每一条消息，每一个令牌，都要重新走一遍完整的预填充和生成流程。7268个令牌的固定文件，在50条消息的对话里，意味着你的显卡要多算35万多个令牌的预填充。
这些预填充本身不产生任何有用的输出，它们只是在重复加载同样的背景信息。
这就是TooCas说的“你看着模型在烧电，它看着自己在读废话”。本地跑模型的兄弟们最懂这种痛苦。电费是你自己交的，风扇噪音是你自己听的，等待时间是你自己熬的。SMELT把这7000多个令牌压到几十个，相当于每次推理都帮你省掉了一本中篇小说的工作量。
论文DOI和GitHub都已公开，搜索SMELT Schema Aware Markdown就能找到
TooCas在帖子里给出了明确的查找方式。他说去GitHub搜TooCas/SMELT就能找到代码和那篇解释文档。去Zenodo搜“SMELT Schema-Aware Markdown”就能找到带DOI的发表版本。他还特意说明这篇论文是跟GPT、Claude和Codex合作完成的，并且明确表示要给他们署名，因为他们应得的。
这个细节很有意思。现在越来越多开源开发者会主动承认AI辅助编程工具的帮助，这在几年前还是被很多人藏着掖着的事情。
TooCas的态度很坦荡，我就是用了这些大模型帮我写代码，我不觉得丢人，我还要专门提一嘴。这种诚实反而让人觉得这哥们靠谱。