结果显示输入令牌数减少了61%，但延迟并没有明显下降，因为生成时间占了主导

核心洞察

这篇文章最有意思的地方，是作者把一个失败记录当成了主角。上下文压缩省下了 61% 的 token，响应延迟几乎没变，9B 模型在普通笔记本上直接跑不动。这些"不好看"的结果，恰恰是本地小模型落地时最真实的样貌。

我等了三十多分钟。终端就停在那里，光标一闪一闪，一句话都不回。我在自己的笔记本上跑 Gemma2 的 9B 版本，就是普通 Mac，老师学生都会用的那种，模型毫无反应。

这不是 bug。这是这场实验最诚实的回答。

那段让人抓狂的等待，最后成了整个实验里最有价值的发现。我最初关心的是一个很实际的问题：教程里搭出来的 agent，扔到生产环境里还能不能活？

我拿 Gemma 当案例，研究从教学原型到生产落地之间的距离。长对话、普通硬件、真实用户，一层层叠上去，模型会变成什么样。这篇文章就是这段过程的诚实记录：哪些效果好，哪些和我想的不一样，以及为什么那些"没达到预期"的部分，反而比一个干净漂亮的结果更有用。

核心结论

1. 在微服务故障排查对话实验中，朴素管线（累积全部历史）的输入 token 随对话轮次线性增长，仅 4 步就从 107 增至 266 个 token；优化管线（紧凑摘要裁剪）则稳定在约 104 个 token，最终输入 token 减少了 61%。

2. 上下文裁剪并未带来预期的延迟改善：朴素版与优化版的响应时间误差棒在几乎每一步都重叠，原因是 2B 模型在短对话场景下的耗时主要来自生成输出，而非读取输入。

3. 用 Gemma2 9B 在普通笔记本上复现同一实验失败：等待超过 30 分钟没有收到一条完整响应。这说明更大模型对硬件的依赖无法绕过，也印证了本地无 GPU 环境下小模型加高效上下文管理的重要性。

4. 本次实验依赖严格测量才得到可信结论：需先预热模型、使用 Ollama 返回的真实 token 计数（而非估算值）、并每条管线运行 3 次取平均值；单次运行或估算 token 的结论容易失真。

问题根源：教程为什么有点骗人

几乎所有对话式 agent 教程都在做同一件事，只是没人明说：每一轮都把完整的聊天记录原封不动发给模型。

想象一下，你说一句新话之前，得把之前所有内容都重复一遍。每条消息，每次回复，全得再说一次。刚开始没感觉，对话跑到三十轮、五十轮的时候，你每说一句新话就得先复述一整本小说。

这种模式叫线性上下文堆叠，它会带来三个具体问题：

1. 内存饱和。每一轮调用，模型都要处理一份越来越大的上下文。
2. 撞上 token 上限。每个模型都有最大上下文窗口，对话一长，早晚会到。
3. 质量下降。NLP 文献里有个现象叫"中间丢失"：上下文拉长之后，模型对中间部分信息的关注度会明显低于开头和结尾。换句话说，对话变长不只是变慢，还会变笨。

这个问题所有模型都有，但代价因场景而异。你用闭源 API，上下文窗口很大，按 token 计费，那这个问题的代价就是钱，多付就行。但你在本地跑开源模型，拉美很多大学和实验室都是这种环境，代价就落在硬件上：内存有限、没有独立 GPU、想多买算力也没地方买。这时候无界的上下文就不再是个优化细节了，它直接决定 agent 到底能不能跑起来。

实验设计：怎么做的

为了不流于空谈，我用 Gemma 2（2B）在本地跑了一个简单但有对照的实验，工具是 Ollama，不依赖任何付费 API。

具体做法：模拟一段典型的技术对话，场景是微服务故障排查，每一轮对话都会追加新的信息。然后让两套不同的架构分别跑这段对话：

• 管线 A（朴素版）：不做任何压缩，完整累积全部历史。教程式 agent 就是这么写的。
• 管线 B（优化版）：做历史裁剪，不发送整段对话，只发送最新状态的紧凑摘要。

# 管线 A：累积全部历史，不做裁剪
conversation_history += f"\n先前文本 {i+1}: {chunk}\n"
full_prompt = f"{conversation_history}\n{TASK_PROMPT}\n{chunk}"

# 管线 B：只发送最新状态的紧凑摘要
full_prompt = f"先前紧凑上下文: {compact_context}\n{TASK_PROMPT}\n{chunk}"

有三个方法上的决定，我当时差点忽略，后来发现它们才是结果可信的关键。

一、冷启动差点毁掉所有数据。 第一次跑的时候，每条管线的第一步都比后面的步骤慢了好几秒。当时以为是提示词太大，查了才发现是模型第一次被调用时要花时间载入内存。解决办法是先跑一次废弃的"预热"调用，再开始正式测量，让两条管线站在同一起跑线上。

二、用真实 token 数，别用估算值。 我一开始是数单词再乘一个换算系数来估算 token，后来发现这精度损失完全没必要。Ollama 每次响应都会返回真实的计数（prompt_eval_count）。换成这个数字之后，图表的可信度立刻不一样了。

三、只跑一次不够。 每条管线我跑三遍，取平均值，图表里带误差棒。正是这个做法让我看清，早期的某个结果没有第一眼看上去那么扎实。这个后面再展开。

结果：哪条站得住，哪条站不住

token 变化：真正站得住的结果

token 的变化趋势在三次运行里完全一致，没有模棱两可的地方。朴素管线呈线性增长，四步就从 107 涨到 266 个 token，将近三倍。优化管线则压成了一条平线，稳定在 104 左右。

到最后一个步骤，输入 token 减少了 61%。上下文管理在这里确实管用，对话的内存占用不再无限膨胀。

延迟：直觉没猜对

有意思的部分在这里。直觉告诉我，输入 token 越少，响应越快。真实数据没有支持这个判断，至少支持得不够明显。朴素管线和优化管线的误差棒在几乎每一步都是重叠的。

为什么？因为 2B 模型在短对话场景下，响应时间的大头在生成输出，不在读取输入。把上下文缩短，不会自动让生成变快。

这是个"负面"结果，它没有验证最初的假设，但它是整个实验里最有价值的部分。上下文管理和延迟是两个相关但不同的问题，优化前者不保证改善后者。

Gemma2 9B 的失败尝试（为什么不藏起来）

我还想再往前推一步，用 Gemma2 的 9B 版本重复同样的对比。当时的假设是，模型本身越大，处理长提示词的负担就越重，延迟优势会更明显。

我没拿到那份数据。笔记本跑了三十多分钟，一条完整的响应都没有。最后只能取消。

我完全可以把这段从文章里删掉。但它本身就是一个有价值的数据点，而且最贴近我作为拉美研究者的日常：更大的模型需要更好的硬件，这一步绕不过去。我带着明确目标、给了充足时间，都很难在消费级笔记本上跑起 9B 模型。这恰恰说明，用小而容易获取的模型去搭高效 agent，对拉美那些没有 GPU 的大学、实验室和团队有多重要。

实践启示

如果你正在或者打算在本地开源模型上搭 agent，我从这个实验里得到的是这么几条：

• 先测量，再优化。我最初对延迟的判断就是错的，靠严格测量才看清楚：三次运行、预热、真实 token 数，哪一个都不能少，单跑一次的结论很容易带偏。
• 省 token 不等于省延迟。模型大小和对话长度不同，瓶颈可能完全在别的地方。
• 上下文裁剪有代价，它不是什么魔法。我目前的实现只看长度，不看语义相关性，关键的旧信息有可能被切掉。这个局限我得说出来，藏不住。
• 在真实硬件上跑失败的实验，也是一份数据。我在笔记本上跑不动 9B，这个事实和任何一张图表一样，都在支撑这篇工作的论点。

结语

这场实验从一个简单的问题出发：怎么让教程式 agent 活到生产环境？最后给我的答案比我预想的复杂一些。上下文管理很重要，但单靠它解决不了所有性能问题。硬件限制本身就是技术问题的一部分，不该被当成后勤脚注。

代码全部放在仓库里，想复现或者改成自己的场景都可以。里面不仅有 Gemma2（2B）跑通的结果，也有 9B 模型跑失败的完整记录。没跑通的部分和跑通的部分，一样值得摆出来。

如果你也在拉美用开源模型做东西，我很想听听你的经验：你用什么硬件跑，撞到过什么坑，哪些上下文管理手段真的有用。LinkedIn 上找我聊。

这项工作也以海报形式参加了第二届南美 NLP 学校（布宜诺斯艾利斯，2026 年 8 月）。

常见问题（FAQ）

为什么上下文压缩省了61%的token，但延迟却没有明显下降？

因为2B模型在短对话场景下，生成输出时间占主导，读取输入占比小。缩减输入token不会加速生成。上下文管理和延迟是相关但不同的问题，优化前者不保证改善后者。

Gemma2 9B在普通笔记本上跑不动，原因是什么？

9B模型需要更大内存和更强算力，普通笔记本内存有限且无独立GPU。作者等待三十多分钟无响应，说明硬件限制是本地大模型应用的关键瓶颈，小模型更实际。

教程式agent直接上生产环境会有什么隐患？

教程式agent每轮都堆叠全部对话历史，导致内存饱和、撞token上限、质量下降（中间丢失）。在本地硬件上根本无法扩展，需做上下文裁剪或摘要，且要测量真实token数。