你本地模型的实际可用上下文比上下文窗口更小——但问题不在记忆
我一共跑了5个多步代理任务，每个任务重复4次（k=4）。为什么k=4很重要？因为只靠单次成功来评判一个代理几乎毫无意义——你真正关心的是它每次都能成功。所以只有四次全部通过才算该任务通过。
汇总结果：整体通过率80%（16/20次运行），平均每个任务4步，每步约消耗2,000 tokens。
上下文悬崖（Context Cliff）
我把语义无关的散文填充到提示词里，插在工具定义之前，然后重新测量不同深度下的工具调用准确率。
| 提示深度 | 准确率 |
|---|---|
| 704 tok | 100%（5/5） |
| 2,999 tok | 93.3%（14/15） |
| 6,045 tok | 93.3%（14/15） |
| 8,845 tok | 73.3%（11/15） |
在约6k token以内，准确率基本平稳。但到8.8k token时，突然掉了20个百分点。
为什么这不是内存问题
我想着重说这一点，因为这与大多数人设计本地代理时的判断相悖。
- 模型权重：5.3 GB
- GPU可寻址内存：macOS Metal限制下，16GB中可用约11.8GB
- f16 KV缓存下能容纳的上下文：约53,000 tokens（q8_0约107k，q4_0约214k）
- 代理运行时实际使用的最大上下文：1,890 tokens —— 只占了宣称16,384窗口的12%
也就是说，内存足够装下比模型可靠推理能力大五倍的上下文。VRAM计算器告诉我内存绰绰有余，但模型远未触及内存上限就掉链子了。
实际结论是：“能装多少上下文”并不是决定代理能用多少上下文的那个数字。 这两个天花板完全不同，行为上限要低得多，而且更难察觉——它不会主动报告，准确率只是悄悄下滑。