同一任务、同一模型：一次40秒，下一次261秒——我自己设计的"任务完成了吗？"检查反而在拒绝正确答案

我在一台 3090 上用本地 27B 模型（3-bit 量化）运行浏览器智能体。其中一个测试任务是故意设计得很无聊的：在一家韩国书店搜索 "python"，然后把排名前 3 本书的书名、作者和价格整理成表格。即使在修复了另外三个问题之后，连续三次运行分别耗时 40、176 和 261 秒。同样的提示词，同样的机器。我第一个怀疑的是思考模式（thinking mode）。框架会在步骤之间开关思考功能，而每次切换都会改变提示词的开头，导致 KV cache 被重建。我修复了最终回答时切换思考模式、导致模型重新读取 77k token 的一个案例，然后尝试让整个运行过程保持思考状态稳定。在 27 次不同配置的运行中，书店任务的耗时仍然在一分钟以内到六分钟之间波动。接下来我发现了问题：我们的历史记录上限仍然是按 131k 窗口设置的，而实际运行使用的是 192k，所以对话记录在大约 40% 的位置就被折叠了，模型不得不重新读取大量内容。这是个真实的 bug，修复后，还是很慢。然后是页面提取器。该网站有一个隐藏的分类菜单，大约包含 18,000 个字符，它在"主要内容"的判定中胜过了真正的书籍列表。修复这个问题让一次糟糕的运行从 373 秒降到了 124 秒，但那只是一次运行，耗时波动依然存在。真正的原因是：在模型开始之前，有一个小型规则层会把请求转换成框架可以校验的需求。它把"排名前 3 的书，书名、作者、价格"理解成了"打开 3 个条目并逐一阅读"。在那些慢速运行中，模型在第 5 步时就已经从搜索结果中拿到了完整答案。但我的检查器认为任务还没完成，于是模型又去打开了三个它根本不需要打开的书籍页面。在日志里，这看起来和一个困惑的模型一模一样。修复方案很简单：如果所要求的每个字段都是你在列表中就能看到的信息（作者、价格、评分等），那么需求就变成"从列表中收集"。在发布之前，我把日志中的全部 2,810 个请求分别用新旧两套规则跑了一遍。有 14 个发生了变化，全部都是朝我期望的方向变的，没有一个朝反方向变。之后，同一个任务分别耗时 60、64 和 44 秒。一个任务只跑了 3 次，所以我不会做过强的结论，但 4 分钟级别的运行确实消失了。我还没弄清楚的一点是：什么时候应该让模型多思考。运行之间的噪声比任何思考配置之间的差异都大，所以我目前还无法判断这些设置是否有帮助。如果你也在自己的智能体中追踪过运行间的差异，它最终来自哪里？是模型、采样，还是你自己的脚手架代码？