抡锤者

补一个任务完成的截图

本地 Coding Agent 实测：96K 已经能干活，150K 还需要观察

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

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

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

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

一次 4 小时的完整开发

项目	实测记录
任务类型	Brownfield：接手现有项目，完成全栈业务闭环
运行时长	4 小时 02 分
Agent steps	约 293 个
Cumulative tokens	约 16.5M
Context compaction	8 次
Domain / API 测试	通过
Build	PASS
完整 E2E	40/40，连续两轮 PASS

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

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

到最后，它仍然能分清：

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

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

我对 compaction 的看法变了

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

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

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

---

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

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

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

维度	任务要求
起点	空白目录 + 一份需求文件
前端	React 19 + Vite + Ant Design + ECharts
后端	Node API + SQLite
业务闭环	岗位 → 任务 → 能力 → 课程 → 学习证据 → Rubric → 评价 → 修订 → 学生画像

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

检查项	当时的进度 / 结果
SQLite	完成
Domain	完成
API	完成
前端	基本完成
Build	PASS
完整 E2E	32/32 checks × 2，连续两轮 PASS
生成速度	约 70 tok/s
Cache hit	约 97%

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

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

---

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

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

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

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

项目	实测表现
上下文配置	150K
生成速度	60～70 tok/s
显存情况	没有直接 OOM
能否运行	能跑

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

但我真正关心的问题是：

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

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

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

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

环节	发生了什么
修改 domain.js	按记忆中的代码做 exact edit，返回 old_string was not found
重新读取文件	判断“磁盘上的 domain.js 和我记忆中的不一样”
排查原因	一度怀疑文件被其他东西改过
再次 Read	才意识到自己对当前文件版本的记忆已经不准确
修改 index.js	又出现过类似情况

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

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

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

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

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

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

---

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

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

对比维度	NInfer 96K	KVMem 150K
上下文容量	小一些	更大
Compaction	更多	理论上更少
当前工作状态	比较干净，推进稳定	出现过历史版本与当前状态混淆
历史信息	定期压缩整理	旧代码、旧 tool output、旧状态可能长期残留
错误表现	大部分是正常 coding bug	出现 stale-state / memory drift 风险
修复体验	测试后可以快速自修复	出现过需要重新读取文件、纠正自身记忆的情况
我的当前定位	主力方案	实验方案

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

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

Qwen3.8-27B + NInfer 96K

---

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

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

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

验证目标	它回答的问题
150K 成功加载	上下文能不能装下、能不能运行？
连续开发 3～4 小时	Agent 还能不能稳定知道自己在干什么，并把项目做完？

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

Coding Agent 要反复经历：

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

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

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

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

06 · 我现在的配置和建议

方案	当前选择
Qwen3.8-27B GSQ-RCO IQ3_S-MTP + NInfer 96K	继续作为主力配置
KVMem 150K	暂时停用，等待后续版本再测

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

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

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

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

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

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

5060ti 已经站起来了，完全可以干活了

分享一下我最近用 RTX 5060 Ti 16GB 折腾本地大模型 Coding Agent 的经历。

对我来说，真正有意义的并不是模型单轮聊天能跑多少 token/s，而是它能不能持续完成：

读项目 → 理解需求 → 写代码 → 跑测试 → 看报错 → 修改 → 再测试 → 打包 → 验收

折腾了一段时间以后，目前我体验最好的一套配置是：

Qwen3.8-27B GSQ-RCO IQ3_S-MTP + NInfer + DeepSeek Harness + 96K Context。

我的硬件和当前配置

主机并不是什么高端 AI 工作站：

• CPU：i5-14400F
• GPU：RTX 5060 Ti 16GB
• 内存：32GB DDR5
• 系统：Windows 10 x64

当前本地模型使用 Qwen3.8-27B GSQ-RCO IQ3_S-MTP，推理后端是 NInfer，Coding Agent 使用 DeepSeek Harness。主要参数为：96K 上下文、RK8V4 KV Cache、MTP 4、Thinking Budget 8K、单 Agent 为主、本地 API 服务。

我之前也跑过 48K 的 Q4 模型。实际体验下来，新的 IQ3_S + NInfer 方案不仅把上下文从 48K 提到了 96K，长上下文生成速度还能维持在 60 token/s 左右。这不是标准 benchmark，而是我自己真实开发时看到的运行数据。

我拿它开发了什么？

我直接拿自己在做的「服装色彩造型系统 V3」做长任务测试。这是一个用于人物形象设计和服装色彩教学的 Windows 桌面软件，包含换装、服装分区调色、花型、叠穿和 Look 管理等功能。项目从 9 月初的设计与交接到 10 月初持续迭代，前后约 4 周（断续开发）；截图中的素材栏显示约 35 件服装与配饰素材，并有 4 个独立造型 Look。

它不是只展示图片的 Demo。系统里要处理的功能包括：

• 服装与配饰穿脱、四套 Look 独立编辑
• 服装分区域换色，支持 HSL / RGB / HEX 调色和快捷色板
• 圆点、条纹、格纹、菱纹等花型，以及上传自定义花型
• 平涂 / 光影模式、SVG / Path2D 矢量服装结构、分区编辑与图层遮挡
• 保存、打开作品，Undo / Redo、复制造型、PNG 导出
• 离线授权与 60 天试用、绿色版和 Windows 安装包

所以项目涉及 Electron 桌面应用、状态管理、本地文件、IPC、授权、矢量绘图、服装几何、图层、导出、自动测试、E2E 和 Windows 进程生命周期等多个环节。

为了测试本地模型，我不是只让它在现有代码上补几行，而是整理产品需求，让本地 Qwen 根据需求参与系统实现和后续开发。这更接近测试它能否理解产品、拆分任务、实现功能、修 Bug、跑测试并完成交付。

连续长任务的实际表现

这个项目后来成了一个长链 Agent 压力测试。在一段核心开发过程中，Agent 连续参与了代码修改、测试、打包和视觉优化。一次长链记录显示：

• 9 轮以上、1100+ Agent steps
• 累计处理 6600 万+ tokens
• 生成速度约 60 token/s，缓存命中约 96%

这里的 6600 万 token 不是模型一次生成了 6600 万字，也不是一次塞进了 96K 上下文。Harness 显示的是多轮任务累计处理量，其中有大量重复上下文、工具结果和缓存命中的内容。比如一次统计里，总处理量约 6430 万，缓存读取约 6080 万，未缓存输入约 252 万，实际输出约 95 万。这个累计数不能直接拿去套 API 输出价格，但能看出长任务对上下文和缓存系统的压力。

最终测试做到什么程度？

我要求 Agent 不只写完代码，还要建立自动测试和验收流程。最终工程阶段做到：

• Unit Test：57 / 57 PASS
• E2E：74 / 74 PASS
• 安装测试：17 / 17 PASS
• Build：PASS
• Dist：PASS
• Security Scan：PASS

E2E 覆盖调色、花型、像素颜色断言、保存、打开、Undo / Redo、导出、授权、应用关闭守护、重启恢复和安装版启动。

中间还遇到过一个典型的 Electron / Playwright 问题：软件实际已经退出，但自动测试一直认为应用没有退出。模型一路排查到 Electron → Playwright → V8 Inspector → Process Transport，发现是测试环境停在 “Waiting for the debugger to disconnect...” 导致进程生命周期检测异常，最后修到了完整 74/74。只做几轮聊天很难测出这类问题。

96K 上下文的实际价值

我现在觉得，长上下文最大的价值不是一次塞一本书，而是让 Agent 有更大的工作记忆空间。开发过程中，它需要保留需求、项目结构、前面改过的文件、测试失败信息、Git / Build 状态、工具调用结果和前几轮排错结论。

48K 也能做，但复杂任务里会更早压缩。96K 让我能把一个开发阶段保持得更久。Harness 会自动 compact；有一次上下文接近 97% 后，历史约 31K tokens 被压缩，占用从 97% 降到 65%，Agent 没有重开会话，接着完成后续工作。它不是永远不压缩，而是减少压缩频率，让更多近期工程细节保持原样。

8K Thinking Cap 的作用

刚开始 Qwen 偶尔会进入很长的 reasoning：一直思考，最后把 16K 输出额度消耗得差不多，却没有真正调用工具。后来我给 NInfer 设置 default-thinking-budget = 8192，效果明显好一些。

它不是把整个 Agent 的思考限制为 8K，而是给单次模型调用设一个边界，避免单次推理占满输出空间、迟迟不进入回答或工具调用。

16GB 显存上的限制

5060 Ti 只有 16GB 显存，96K 可以跑，但余量很小。深度压测时最低剩余显存约 180MB；同时开 Electron、Playwright、浏览器、微信等使用 GPU 的程序，有过 Harness 返回 503、inference engine unavailable 的情况。后来重启 NInfer，模型又恢复了。

我现在的判断是：5060 Ti 16GB 跑 96K 可用，但属于比较极限的配置。日常可以考虑留一个约 90K 的稳定档，96K 留给特别长的任务；具体余量仍取决于模型、运行时和同时打开的程序。

本地模型的视觉短板

这套 Qwen 是 Text + MTP，没有 Vision。它能写 SVG / Path2D、算坐标、调服装几何、做图层和像素断言，但看不到自己画出来的东西是否好看。

有一次它重做人台后自动测试全过，截图里人物左肩却伸出一个巨大的米白色三角形。视觉模型检查后，我把反馈交回本地 Qwen；它发现颈部路径控制点少加了 B.cx，导致坐标从人物中心附近飞到 x≈26，Path2D 闭合后就出现了这个三角形。修完后人台恢复正常。

现在我的工作流是：本地 Qwen 连续开发 → 自动测试 → 生成截图 → 视觉模型验收 → 把结构化意见交回本地 Qwen → 继续修改。Coding 能力和视觉能力是两件事，视觉验收仍要有人或视觉模型参与。

一个提高效率的测试流程

一开始每次改一点视觉细节，我都让 Agent 跑完整 Unit、E2E、Build、Dist 和安装测试，一次微调要花四五十分钟。后来改成 Visual Fast Loop：修改 → 快速几何检查 → Build / Smoke → 截图 → 人工视觉检查。视觉确认后，再统一跑 57/57、74/74、Build 和 Dist。

这让我发现，Agent 的效率不只取决于模型 token/s，也取决于任务怎么编排。60 token/s 的模型，如果每次都做不必要的全量测试，一样会很慢。

量化模型带来的取舍

以前我觉得 27B 压到 3bit 左右，能力损失肯定很明显。但这次在长链开发、工具调用、Electron、JS、Windows、自动测试和调试中，IQ3_S 的实际表现比我预想好。更低的权重占用也给上下文和 KV Cache 留出了空间，让我从之前的 Q4 + 48K 转到 IQ3_S + 96K。

对 Coding Agent，我现在会一起看模型质量、上下文、KV Cache、推理速度、工具链、缓存和 compact 机制，而不是只看 Q4 是否一定比 Q3 聪明。对长 Agent 来说，略微量化但能跑 96K、维持约 60 tok/s 的模型，对我的工作流可能更实用。

最后的实际感受

这次折腾以后，我觉得 16GB 显存上的本地模型已经进入“能干活”的阶段。它不能替代最强云模型，也不是所有项目都能全自动完成，但已经能承担我手头的写代码、修 Bug、看日志、跑测试、Electron 开发、文档处理和长时间项目推进。

一个优点是可以让它持续做本地任务，不按云 API 的 token 用量计费；这次项目累计处理了 6000 多万 token。这个数是多轮任务的累计处理量，不等于实际输出量或一次上下文长度。本地使用的成本结构更像硬件投入加电费。

我目前最满意的组合

RTX 5060 Ti 16GB + Qwen3.8-27B GSQ-RCO IQ3_S-MTP + NInfer + 96K Context + RK8V4 KV + MTP4 + 8K Thinking Budget + DeepSeek Harness + Auto Compact。

后面我还准备继续测试 90K 与 96K 的稳定性、多 Agent 工作流、云端与本地模型 A/B、Vision Reviewer，以及多人共享推理服务。

至少对我自己来说，问题已经不是“5060 Ti 16GB 能不能跑 27B”，而是怎么让本地 27B Agent 更稳定、更长时间、更少人工干预地完成一整个任务。