最近我在做一组对比测试规则很简单固定模型、只调框架。同一个编码智能体任务同一个底层模型不同框架去调度结果却出现了一个我不能忽略的现象——一旦上下文接近窗口上限成绩波动变得非常明显。有的框架还能靠中间某段文件完成修改有的框架像是突然失忆反复在无关文件里打转。问题不在模型而在框架如何处理上下文。1. 固定模型却出现成绩波动问题出在“上下文”而不是“模型”1.1 别把上下文当成一个装文字的桶这里说的上下文不是编程语言里的“执行上下文”而是提交给大模型的那段连续输入。很多人把它理解为一只桶能装多少 token就算有多少上下文。但真实使用中它不是一只桶而是一块会被反复擦拭的白板。模型每次预测下一个 token只能基于当前白板上仍然存在的文字。代码片段、工具输出、历史对话、系统指令谁被留下谁被擦掉会直接影响模型能“看到”什么。在上下文充足的时候擦不擦都无所谓因为关键信息还都在。可一旦接近上限框架就必须做删减、压缩、摘要或检索。这个决策做得好不好会直接体现在任务成绩上。所以你会看到同一个模型、同一个任务框架 A 能改对框架 B 彻底跑偏。1.2 模型还是那个模型为什么表现会变模型权重没有变但它的输出是条件概率条件变了输出就会变。假设有一个 bug 藏在某个文件的中段框架 A 选择把整个文件放进上下文框架 B 选择了保留最近几轮对话而把文件摘要成三行。对模型来说这是两个完全不同的任务一个是“读文件找 bug”另一个是“根据摘要猜 bug”。成绩波动自然发生。这个观察也解释了为什么“模型能力”和“任务成绩”不能画等号。模型能力是一个静态属性任务成绩是模型、上下文、框架策略、任务复杂度共同作用的结果。固定模型、调整框架就是把其他变量按住单看上下文管理策略带来的变化。你会发现在短任务上框架之间的差距很小越接近上下文上限差距越明显。2. 框架管理上下文的三种典型策略2.1 全量保留最忠实也最容易先到红线最朴素的框架会按顺序保留所有消息用户需求、工具调用、命令输出、错误日志全部追加进上下文。好处是信息丢失少模型能看到完整过程。代价是 token 涨得很快尤其编码任务中一次 grep、一次编译、一次测试输出就可能吃进几千 token。等到接近上限框架通常会选择从最早消息开始裁剪或裁剪最长的工具输出。于是全量策略变成了“前期全量后期随机失忆”。2.2 压缩摘要省位置但可能丢关键细节更复杂一点的框架会在上下文接近阈值时触发压缩用一段摘要替代旧的对话。摘要可以由模型生成也可以用规则提取。这种方式能明显延长有效窗口但也有代价摘要无法完整保留某个函数的三处细节修改。如果后续修改依赖这些细节模型就只能根据摘要“猜”。压缩策略看起来省 token实际上是把风险转移给了摘要质量。2.3 检索注入按需取用依赖检索质量还有一类框架会先扫描仓库建立文件索引或向量索引然后根据当前任务把相关片段检索出来放进上下文。优点是可以支撑很大的代码库缺点是检索质量和任务结果是强耦合的。如果检索漏掉了关键函数模型再强也无从下手。上下文越紧张检索的取舍越关键因为漏掉的信息不会有第二次进入上下文的机会。策略保留方式主要优势主要风险适用场景全量保留原样追加信息完整token 增长快后期截断随机短任务、小仓库、调试阶段压缩摘要旧消息变摘要省 token延长窗口关键细节丢失长会话、重复探索类任务检索注入按需召回片段支撑大代码库召回缺失直接失败大仓库、有明确文件入口的任务框架的具体实现可能混合使用三种策略先全量再压缩最后靠检索。问题在于多数框架并不会告诉你它到底在哪一步、丢掉了什么。3. 怎样做一次“固定模型、调整框架”的可信对比3.1 先把变量锁死做这个对比最难的不是写 prompt而是确保变量真的可控。需要固定下面这些项模型唯一标识和版本temperature、top_p、max_tokens 等采样参数任务描述、任务顺序、仓库版本重试次数、超时时间、工具调用权限框架版本和底层依赖同样的代理、网关和限流环境。你会发现“同一个模型”在 API 上可能对应多个版本有些框架默认加 system prompt有些框架会使用不同的工具描述格式。这些都不是模型差异而是框架差异。对比的目的本来就是要看框架差异但采样参数不锁死结论就会被噪声淹没。3.2 至少跑三组短上下文、长任务、接近上限建议每组任务至少跑 3 到 5 次取分布而不是取单次最好成绩。测试组可以这样设计短上下文单个文件的小 bug 修复上下文远未到达上限长任务跨文件的新功能开发需要多轮工具调用接近上限在仓库里加入大量无关文档或者在任务开始前注入一段较长背景材料压迫框架必须做筛选或压缩。最后那一组最容易被忽略但它恰恰是“固定模型、调整框架”最有信息量的场景。很多框架在短上下文里看不出区别一旦被压到 80% 以上的窗口占用率策略差异就全部暴露出来。注意上下文紧张测试不是把窗口塞满就行而是要让框架有理由裁掉那些“看起来不关键、实际很关键”的文件。3.3 记录的不只是能不能跑通还有上下文账单结果不能只记“改对了没有”。建议同时记录第一次尝试成功率最终成功率允许重试总输入 token、输出 token是否发生截断、压缩、检索事件关键文件是否出现在最终 prompt 中完成时间。下面是评测骨架的伪代码只表达结构不绑定具体框架def run_task(model_id, agent_builder, task): agent agent_builder(model_idmodel_id) for step in agent.run(task.prompt): step.log_prompt() # 输出本轮实际发送给模型的 prompt step.log_truncation() # 是否有消息被裁剪 step.log_compaction() # 是否触发摘要压缩 step.log_retrieval() # 检索召回了哪些文件 return { pass_at_1: task.check(agent.first_output), pass: task.check(agent.output), input_tokens: agent.total_input_tokens, truncation_events: agent.truncation_events, key_files_in_context: task.required_files agent.files_in_context, }把这个骨架用在所有框架上结果才有可比性。实际运行时很多框架会吞掉内部日志你需要通过 API 网关或代理把请求包体抓出来。这一步不能省因为“框架说它做了压缩”和“我们亲眼看到压缩发生”是两回事。4. 成绩波动背后的三个细节截断、遗忘、位置4.1 截断不是均匀裁剪而是用脚投票当上下文超过窗口框架必须决定先扔谁。常见策略是扔最早的消息、扔最长的工具输出、扔中间轮次的思考过程。对编码智能体来说“最早的消息”里可能包含用户对需求的原始描述也可能包含仓库结构如果这些被扔掉后续模型就会在缺少约束的情况下行动。扔最长的工具输出则可能让模型失去编译错误的完整信息只剩一个干巴巴的“失败”。所以说截断策略不是技术细节它本质上是框架在替我们投票它认为哪些信息不重要。问题是很多框架的默认投票标准是“先来后到”或“长度优先”而不是“对当前任务重要程度”。4.2 丢失中间信息导致“遗忘”用户在智能体跑了几分钟之后最常见的一句评价是“它好像忘了最开始的需求。” 这不一定是模型记忆差而是因为中间过程把早期需求挤出了上下文。比如任务一开始要求“不要动数据库表结构”中间经历了很多轮调试框架为了节省空间把最初约束压缩成“保持兼容”——这个语义在后续代码生成中很容易被忽略。“遗忘”不是心理现象而是信息物理上已经不在上下文里。这也是为什么编码智能体容易在长任务后段出现“自信但错误”的修改它没看到完整约束但当前上下文看起来是连贯的。4.3 关键信息的位置决定了成功率在长上下文评测里有一个现象反复出现大模型对上下文开头和结尾的信息更敏感中间部分更容易被忽略。框架拼装 prompt 的顺序因此不只是排版问题而是性能问题。如果关键文件被放在超长工具输出的中间它可能处于“模型注意力最不友好”的位置如果框架把当前修改目标固定在开头、把最近错误放在结尾成功率通常更高。所以在对比时我建议你额外记录一个指标任务中必须出现的文件分别出现在 prompt 的第几个 token。这个位置信息往往比总长度更能解释为什么某个框架胜出。5. 比上下文长度更重要有效上下文利用率5.1 怎么估算有效上下文利用率既然上下文紧张时成绩波动核心问题就不只是“窗口有多大”而是“窗口里有多少信息是任务真正需要的”。可以粗略用两个指标衡量关键信息覆盖率任务要求的所有文件、函数、约束有多少最终出现在 prompt 里有效上下文利用率任务相关的 token 数除以总 prompt token 数。后者比较难自动算因为“相关”没有统一标准。一个实用的做法是在评测任务里预先把关键信息打上标记比如限定“必须查看 config.py”然后检查结果 prompt 中是否出现该文件。你不需要算得很精细只要能区分出 40% 和 90% 的差距就够了。5.2 框架应该把哪些信息“钉”在上下文里当上下文紧张框架要保证以下内容不被挤掉用户的原始目标和硬性约束当前正在操作的文件路径和最新内容已产生的代码 diff最近一次失败的报错信息验证命令和执行结果不允许触碰的模块或约定。我把这份清单叫“最小有效上下文”。它不应该由模型临时猜而应该由框架显式管理。哪个框架能稳定地保住这些内容它在上下文紧张时的成绩就会更稳定。5.3 参数与压缩策略的取舍很多框架允许配置上下文窗口上限、触发压缩的阈值、摘要模型、检索 top-k。经验上先把触发阈值设得保守一点比如窗口的 70% 到 80%不要等到 98% 才压缩。压缩发生得太晚往往意味着关键信息已经被截断触发得太早摘要又可能显著降低信息保真度。不要等到上下文 98% 才触发压缩关键信息通常在最后 10% 被牺牲掉。滑窗式上下文也好滚动摘要也好本质上都是用一个更小的信息块去替代完整历史。对于编码任务我不建议单独依赖某一种策略。更好的组合是核心文件永远保留历史信息用摘要承载仓库级信息靠检索按需注入三者分开管理。6. 给正在选框架或调框架的人五条落地建议6.1 先复现再评估不要因为一个框架在演示任务里表现得惊艳就立刻迁移。先用五到十个覆盖你真实业务的编码任务做一次小规模复现。演示任务往往上下文很短所有框架都能过真正的差异在长上下文和接近上限时才显现。6.2 在“上下文紧张”场景里选框架如果目标是选型建议把“上下文压力测试”写成固定测试用例。具体做法给每个任务注入 4000 到 8000 字的无关背景材料或者复制一份较大的仓库文档让 token 占用率达到 70% 以上。然后观察框架是否能保住真正的关键文件。这个测试比一百个短任务更能说明问题。6.3 给框架加上可见性框架不应该是个黑盒。它至少要暴露三个信息当前上下文 token 数、哪些消息被截断或压缩、检索召回了哪些文件。如果框架不提供就在外部加日志和代理。没有可见性你就无法解释为什么这次成功、上次失败也无法排除上下文策略的随机性。6.4 当成绩下滑时按这个顺序排查一旦智能体在上下文紧张时表现变差我建议按固定顺序排查避免一开始就调 prompt 或换模型看现象是答非所问、反复无效修改还是直接断在某个工具调用上看实际上下文占比任务开始时的 token 数、是否触发压缩或截断看截断与压缩位置被裁掉的到底是历史轮次还是关键文件看检索召回如果用了检索关键函数或文件是否真的进入了本轮上下文看模型单独能力把关键片段摘出来单独问同一个模型确认它原本能答对最后再看参数temperature、重试策略、工具描述长度、max_tokens 是否限制了输出。这个顺序的好处是从最外层的现象逐步逼近根因避免拿模型能力问题去掩盖框架问题也避免拿框架问题去怪模型。6.5 把“上下文策略”写进框架选型标准选框架时除了看功能列表和支持的模型数量还要追问几个问题它如何处理上下文超限截断时保留哪部分是否支持把指定文件固定在 prompt 里是否开放压缩和检索的触发条件日志里能不能看到每一次 prompt这些问题的答案比“谁宣称的上下文更长”更值得放进决策表。这套对比方法更适合研发和选型阶段不适合直接拿来做线上性能基准。线上环境还有并发、缓存、限流、成本控制和权限隔离这些都会改变结果。你要做的是先在线下把上下文管理策略选明白再谈工程化部署。最后说一句我自己的判断固定模型、调整框架成绩出现波动这件事本身不奇怪。真正值得长期关注的是框架有没有把上下文当成一等公民来管理而不是把它当成一个越用越满的缓冲池。如果你正准备从“能用某个编码智能体”走向“在团队里稳定使用编码智能体”第一步不是换个更大的窗口而是把框架如何处理上下文这件事看清楚。