33.5k Stars！专为DeepSeek打造的Coding Agent，缓存命中率高达99.82%

在上周, 大家伙儿是不是均收到了发送过来的计费调整方面的邮件, 邮件里存在着这样的一句话, 那句话是: 预计涨幅比较大。

啊啊啊啊啊啊，OMG，你吓到我啦！！！

网络之上已然有人着手进行算账, 依据不同的调用结构展开估算, 历经这一轮的涨价之后, 某些长上下文任务的实际成本极有可能显著攀升 , 甚而有人经过测算认为或许会近乎翻番。

实际涨幅还是要以正式通知为准。

这一年内, 对于开发者而言培养出这样种习惯 , 那就是东西价格低廉 , 数量众多 , 能够随意创造。当下忽然宣称要涨价 , 而且涨价幅度颇为大 , 以往那种“肆意而为, 毫无顾忌”的状态恐怕得有改变了。

当我在就此事情进行思量的时候, 瞅见了一个开源的、称作-的Agent项目。

它是冲着那个问题去的, 那个问题是“怎么把用得更省”, 它在上面收获了33.5k stars。

01

一切围绕 Cache设计

极关键的一组设计思路, 乃是依据 的前缀缓存（Cache）稳定性予以设计, 致使 Agent 长时间持续运行之际, 尽可能更频繁地实现缓存命中, 将 Token 成本予以降低。

这句话听起来很技术，但其实很好理解。

那些曾使用过API的人理当明白, 要是接连进行几次请求, 在此之前伴随着一大段同样的上下文情况, 这一部分的内容存在着能够直接命中对应的Cache的几率, 之后依照更低的缓存命中价格来收取费用。

所以前面的内容得尽量保持一致。

当Agent进行干活操作时, 每完成一个步骤, 都必须再次去请求模型, 把工具说明、项目规则、历史对话以及工具执行结果一次一轮地持续不断地往里面填充进去。

倘若 Agent 在每一轮时, 都再次去调整这些内容的顺序, 去改写前面的消息, 或者往前缀里添加时间戳以及其他不断变化的信息, 那么原本已然缓存下来的前缀, 就会很难再继续保持完整匹配了。

因此，- 专门设计了一套缓存感知的上下文维护机制。

它尽可能维持, 与工具, 保持稳定, 使得会话历史, 以追加的形式, 持续增加，防止无意义地重写先前内容。

有开发者, 曾公开了一名真实用户的数据, 经过最终核算下来, 那就是当用户使用的时候, 输入Token, 其缓存命中率达到了99.82%。

除以, 加上的和, 所得结果为99.82%, 此即缓存命中率（输入）。

可Agent 一直运行，上下文窗口总会被塞满。

常见的般做法往往是将以往的内容精简成摘要。可是一旦上下文被重新撰写, 之前持续稳定增长的Cache就会遭受影响。

因此 - 对压缩（ ）做得比较克制。

于当下架构之中, 系统并非一旦察觉到上下文变长便即刻大规模重新书写历史, 而是会先行针对较为陈旧的Tool予以snip以及prune；仅有当上下文进一步趋近阈值之际, 才会开展摘要压缩。

- 并不会拿上一次摘要继续做“摘要的摘要”。

每次进行折叠操作时, 都会再次从当中予以生成, 尽可能地去减少因多轮摘要持续积累从而产生的信息漂移现象。与此同时, 完整的原始会话会依旧被保留下来, 那些被压缩掉的细节能够借助Tool或者通过归档再次进行检索。

有一个全新版本, 它增添了一项相当有趣的功能, 这项功能确切来说可谓的的确确是双模型协作。

尽管仅仅是平常的多Agent分工情况, 然而, 在此处还是回转到了Cache优化方面。

假若两个模型持续于同一个之中来回切换, 那么Model A生成一段消息, 更换为Model B, 再度换回Model A, 原本的上下文结构极易出现变化。

- 让 和  各自维护一条独立 。

负责对问题展开研究、将所需文件予以读取进而形成计划, 随后要把结构化计划交给, 当处于自身的中时要对假设实施验证并执行。由于两个模型的历史不会相互混淆在一起, 所以各自的都能够持续稳定地增长。

02

安装教程

若要运用 - , 能够借助终端, 亦或是桌面端, 还可以通过浏览器, 又或者取道 ACP 接入你的编辑器, 能够依据自身的开发习惯去挑选。

电脑桌面端要从官方所设的下载页面去下载与相应系统适配的安装包, 将其进行安装, 接着启动该安装包, 随后实施配置, 配置好和模型之后便可投入使用。应用的界面呈现情况如同下面所给出的图示:

CLI / TUI 安装指令如下：

npm i -g reasonix                  # 任意系统;自动拉取对应平台的原生二进制brew install esengine/reasonix/reasonix   # macOS

03

总结

将Cache从一个处于API层面的具备缓存与计费功能的机制, 朝着前端方向推进转变成为Agent的一项系统设计原则, 诸如怎样进行放置、工具按何种方式组织、历史消息是否需要重新编写、上下文在何时实施压缩, 甚至是究竟如何划分与分配 并且 到底怎样区分。

这些设计, 看起来彼此是独立的, 然而最后, 都指向了同一件事, 那就是尽可能地让已经建立起来的前缀继续被复用。

模型的价格由厂商来决定, 然而一次任务当中, 到底会浪费多少 Token, 能不能得到缓存, 很大程度上取决于 Agent 自身如何去组织上下文。