压缩可能不是必须：Gnosh.ai 262K 上下文零摘要

功能上下文管理：262K 上下文零摘要的实测

做上下文压缩的团队总在说同一句话。模型窗口有限，对话长了就得压。可如果上下文管理根本不用压缩呢？Gnosh.ai 在真实运行里给出了一个反例。2026 年 10 月 31 日，一台 AMD Ryzen AI Max+ 395 桌面机跑着 Qwen3.8 27B，把一个小型 Go 项目从 klash 重命名为 gnosh，跨了两个会话，六项任务检查全部通过 来源：GNH。这次运行的上下文总量是 262K token，全程没有做摘要，也没有做滑动（slide）。窗口被缩到 2,400 token 的展示空间，那只是为了让小任务也能填满画面，真实运行里压根用不着那些手段 来源：GNH。

我反复核对了这次运行留下的服务器日志。指令和工具大约 15K token，常驻缓存，跨会话复用，不随上下文增长 来源：GNH。真正的关键数据在 pop 操作之后。下一个请求只处理了 2,572 token，而不是完整 20K-token 对话 来源：GNH。这说明上下文被按需裁剪，而不是整体压缩。裁剪的粒度是函数调用。每完成一个函数，它的产物就被弹出（pop）上下文，新的函数进来时只需要处理自己那部分。

HN 用户 jaekwon 看到这套机制后说，“This isn't just another harness。”在他看来，现有 harness 相比之下都是“lossy inefficient tools”，因为 gnosh.ai 改变了模型的使用方式 来源：HN 评论。这句话分量很重。一个 harness 如果只在编排层做文章，它终究是给现有模型调用方式打补丁；gnosh.ai 做的事更像把上下文本身当成一个函数式栈来管理。

量化成本与性能：读取 179 tokens/s、写入 13.3 tokens/s

性能数字从这台机器的 llama-server 日志里来。4,122 个请求，Qwen3.8 27B，覆盖 2026 年 10 月 30 日 20:00 到 10 月 31 日 20:00 的 36 小时。中位数读速 179 tokens/s，写速 13.3 tokens/s 来源：GNH。这两个数定下了每一步成本的底色。读得快写得慢，意味着任何需要重读的机制都会放大成本，这正是压缩方案要面对的账单。

拿摘要来说。一次摘要要读取 1,244-token 的指令，写入并重读 4,504 token。这是该机 24 个真实摘要的中位数，最大的摘要跑到 13,786 token，约合每摘要 6 分钟 GPU 时间 来源：GNH。滑动（slide）的成本等于切割点之后所有 token 的重新读取。新会话首个 prompt 携带约 250 token 的 mem 块 来源：GNH。

Head-to-head 对比以 GPU 时间为准，两栏在约 12 秒真实时间内回放完成（时钟约 80×），六项检查全部通过 来源：GNH。每个 block 的高度对应那次调用的真实大小，约 3.5 字符/token，可视化精确反映了 token 流向 来源：GNH。工具运行时间被排除在外，因为两栏跑的是同样的工具；mem 自身的时间用运行收据“ok · mem · ran 47ms”记录 来源：GNH。

这些数字放在一起看，结论很清楚。摘要和滑动不是免费的。哪怕一次中位数摘要也要约 6 分钟 GPU 时间，而 gnosh.ai 的 pop 机制在日志里只多了 2,572 token 的处理成本。压缩方案花掉的，正是功能式管理省下的。成本不是消失了，是换了个地方消失。

判断与反直觉发现：压缩可能不是必须

我把这次运行的结论说透。262K token 的上下文里，没有摘要，没有滑动，任务完成了。主流路径，无论是 RAG 检索、上下文压缩还是滑动窗口，都在解决同一个问题。模型窗口装不下。Gnosh.ai 的答案是换个思路。把上下文当成函数式栈，用完就弹出，不压起来 来源：GNH。

jaekwon 的判断我基本认同。现有 harness 是“lossy inefficient tools”，因为它们没改变模型被使用的方式，只是把同样的调用流换了个包装 来源：HN 评论。他特别指出 ollama 不修改就无法工作，因为 gnosh.ai 改变的是模型调用本身 来源：HN 评论。这正好解释了为什么这个方案能绕过压缩。它不需要把对话历史压成一个更小的表示，只需要让模型在正确的时间只看到正确的上下文。

官方测量（2,572 vs 20K）和 jaekwon 的评论指向同一个结论。功能性上下文管理优于有损压缩 来源：GNH 来源：HN 评论。两个来源一个来自运行日志，一个来自第三方观察，不约而同地落在“压缩可能不是必须”这个判断上。我对这个结论的把握程度算高，毕竟有真实运行的数据做支撑。

还有一条额外线索。gnosh.ai/peers.html 展示了多用户并行能力 来源：HN 评论。如果这套机制能扩展到并发场景，它可能不只是一个小型项目的演示。它或许是上下文管理的一个新方向。压缩方案在并发下只会更贵，pop 式管理则天然适合并行。

原文：

Gnosh.ai for "Functional AI"; functional context management, no compaction · 来源：Hacker News

参考来源：

• HN 评论区讨论 (item 50329860)

作者：itfan123 值班编辑 · 发布于 2026年11月2日