我现在的选择：继续用 NInfer 96K，暂时停掉 KVMem 150K。
对 Coding Agent 来说，真正重要的是连续开发几个小时以后，还能不能把项目正确做完。

01 · NInfer 96K：已经是我愿意长期用的方案

我之前用 96K 跑过一次比较完整的长程项目。不是简单写几个函数，而是接手一个现有项目，完成真实的 Brownfield 全栈任务。

从 Domain、API、SQLite、前端，一路做到测试、浏览器 E2E、Vision 检查和最终报告。

一次 4 小时的完整开发

中间当然也踩过坑：Google Fonts、Playwright、React UI race、Vision timeout、端口残留……

但重要的是：Agent 没有因为跑得久、压缩了 8 次上下文，就把整个项目做崩。

到最后，它仍然能分清：

• 当前业务链推进到哪里，哪些文件已经修改；
• 哪些测试已经通过，哪些问题还需要处理；
• 哪些是业务 bug，哪些只是测试 race condition。

最终，它把整个项目做完了。

我对 compaction 的看法变了

以前我把 compaction 当缺点。现在反而觉得，它可能是 Coding Agent 的一种 “工作记忆整理机制”。

旧代码、旧错误、旧 tool output，以及已经失效的中间状态，会被定期压缩掉。留下来的信息，反而更接近当前真正需要的内容。

适度整理上下文，可能比一直保留所有历史更有用。

02 · 再跑一次 Greenfield：从空目录开始验证

为了排除“之前那个项目本身已经有基础”的影响，我又建了一个完全空白的目录，只给 Agent 一份需求文件。

这次是真正的 Greenfield 从零开发。

目前这轮 96K 的表现让我更满意。大约 50 分钟左右，已经推进到：

即使已经发生 context compaction，项目推进仍然比较稳定。到目前为止，没有明显出现这种严重的状态漂移：

“我记得文件应该是这样，但磁盘里怎么不是这样？”

03 · 为什么又去测试 KVMem 150K？

原因很简单：既然 96K 已经能跑几个小时，那自然会想——把上下文扩大到 150K，是不是就能减少 compaction？

理论上很漂亮，于是我测试了：

NInfer + KVMem + Qwen3.8-27B，150K context。

这也是 KVMem 最吸引人的地方：把更大的历史 KV 放到系统内存，再按需调度，让 16GB 显存的机器也有机会把上下文推到 150K，甚至更高。

但我真正关心的问题是：

150K 里面，到底有多少是真正稳定、有效、可用的上下文？

一个多小时后，开始出现状态混淆

我用 150K KVMem 跑的任务，和现在这轮 96K Greenfield 非常接近，同样从空目录开始。

跑到大约一个多小时以后，出现了一些让我不太放心的现象：

让我介意的不是一次普通 typo，而是：Agent 开始把历史版本代码和当前磁盘状态混淆。

现象看到了，但原因不能直接归给 KVMem

我不能证明这一定是 KVMem 导致的。可能的原因包括：

• 超长上下文本身的 retrieval interference；
• Harness 对 tool result 的压缩；
• 旧版本代码在上下文里长期残留；
• KV 分页、检索或 checkpoint 机制；
• 模型在超长上下文里的 attention dilution。

这些都只是可能的解释，没有完成归因验证。

但对我来说，没有必要一定找到最终责任人：我是拿它干活，不是做论文。

04 · 96K 和 150K，实际用起来差在哪里？

下面是我目前的使用体验，不是严格控制变量的性能结论。

所以我现在越来越怀疑：Coding Agent 的最优上下文，并不是越大越好。

它可能存在一个甜点区。对我这台机器来说，目前这个甜点区很可能就在：

Qwen3.8-27B + NInfer 96K

05 · 为什么暂时停掉 KVMem 150K？

我觉得 KVMem 很有技术价值。它解决的是一个非常现实的问题：本地显存有限，但大家又想跑更长的 context。

这个方向值得继续关注。不过，现阶段我不会把它当作自己的 Coding Agent 主力方案。

这是两个完全不同的问题。

Coding Agent 要反复经历：

代码修改 → 测试 → 再修改 → 浏览器 → API → E2E → 回归 → 报告

任何一次状态混乱，都可能让它把前面已经正确的东西改坏。

因此，在我的使用场景下：

稳定性 > 上下文数字
会正确地忘掉一部分旧东西，可能比什么都不忘更重要。

06 · 我现在的配置和建议

后续我会关注这些方面的打磨：

• Long-context correctness
• Page boundary
• KV retrieval
• Checkpoint / replay
• 超长 Agent session 稳定性

如果你现在也准备部署本地 Coding Agent，我个人的建议是：不要为了 150K、200K 这个数字急着上 KVMem。

如果已经有一套稳定的 64K、96K 或类似方案，先把它跑稳。

真正衡量一个 Coding Agent 的，是跑几个小时以后，它还能不能把项目正确做完。

至少目前我的实测结论是：96K 已经能干活。150K KVMem 更像值得研究的实验方案，还不是我愿意长期依赖的生产方案。