编码智能体在上下文紧张时成绩波动常常比换模型还大。很多团队调优 Agent 时第一反应是换更大的模型或者换更便宜的模型却忽略了一个事实当上下文窗口接近上限模型能力只是成绩下限框架如何筛选、排序、压缩和注入信息才是波动的真实来源。所谓“固定模型、调整框架”就是把模型保持不变只改变上下文管理策略观察编码智能体在复杂任务上的表现变化。这篇文章会拆解这个现象背后的机制给出一套可复现的对照实验设计并落地一个最小的上下文预算系统让上下文紧张时的成绩波动从“玄学”变成可定位、可控制、可优化的问题。1. 先理解“固定模型、调整框架”到底在验证什么1.1 编码智能体的成绩来自模型还是来自框架编码智能体通常由四部分组成大语言模型、上下文容器、工具调用层和编排逻辑。模型负责把 token 序列转换成下一段 token也就是提供生成能力框架负责决定哪些 token 能进入上下文、按什么顺序存放、什么时候淘汰、什么时候压缩、什么时候从外部检索补回。实际调优中这两者的边界经常被混淆。一个任务失败了团队往往归因于“模型能力不够”于是换模型但失败可能只是因为框架把最初的需求说明挤出了窗口模型根本没看到任务目标。反过来一个任务成功了团队可能认为是模型强实际上可能是框架恰好把最相关的文件内容放到了离生成位置最近的地方。所以“固定模型、调整框架”这个实验的本质是把模型这个变量按住不动单独观察框架变量对成绩的影响。这样得到的数据能帮助团队回答一个关键问题当前成绩的瓶颈是在生成能力还是在上下文管理能力。这个区分在预算有限、模型选择余地不大的团队里尤其重要因为换框架的成本通常远低于换模型。1.2 上下文紧张一切波动的共同前提上下文紧张是指编码智能体在完成任务时需要承载的信息量接近上下文窗口的可用容量。典型表现有三种一是任务本身涉及多个文件、多次工具调用执行轨迹很长二是系统提示词、需求说明、参考代码都已经占用了大量 token三是模型输出也需要预留空间可用的上下文已经被压得很小。可以这样理解上下文窗口不是无限内存而是一块有预算的缓冲区。模型只能基于当前窗口内的内容做决策窗口外的一切对它来说都不存在。当窗口充裕时框架随便怎么组织信息模型都能找到需要的内容成绩差异不明显当窗口紧张时框架丢掉哪个信息、保留哪个信息、把信息放在哪个位置就直接决定了模型能不能继续正确执行。这也是为什么“固定模型、调整框架”这个实验必须在上下文紧张的条件下做。上下文充裕时框架的差异被富余空间掩盖上下文紧张时框架的差异才会被放大到肉眼可见的程度。1.3 波动显著不是偶发而是系统性问题波动显著不是指两次运行差一个百分点而是指同样的模型、同样的任务只因为框架策略不同就出现完成与失败、稳定与反复之间的差距。这类波动在长任务、多文件修改、需要多轮工具调用的场景里尤其明显。波动的主要来源有三个。第一信息被截断或淘汰模型缺少关键约束只能靠猜测补全行为而猜测是不稳定的。第二注入的检索片段带有噪声同一轮任务里模型看到的相关代码不同生成的方案就不同。第三压缩摘要的粒度不同摘要丢了细节模型在后续步骤里反复试探。把波动当系统性问题的意义在于它意味着编码智能体的评测不能只看“能不能跑通”还要看“跑通是怎么做到的上下文里到底放了什么”。只有把上下文构成纳入观测范围波动才可能被解释和复现。2. 框架影响成绩的四个作用点2.1 上下文窗口不是无限内存而是有预算的缓冲区模型对上下文的处理方式是注意力机制理论上窗口越大能参考的信息越多但实际使用中要区分“标称窗口”和“有效上下文”。标称窗口是模型 API 允许的最大 token 数有效上下文是模型真正能稳定利用的信息量。当内容接近窗口上限时较早的信息可能被截断也可能因为位置靠后而在注意力计算中贡献衰减。框架的第一个作用就是做预算管理。它要先回答系统提示词占多少、任务说明占多少、历史执行轨迹占多少、检索片段占多少、输出预留多少。没有预算所有内容都往窗口里塞结果就是最先进入窗口的内容被最晚写入的内容挤掉而最先进入的往往是需求说明和用户目标。实际项目中建议在框架里显式记录每个消息的 token 数并定期统计各类内容占用的比例。这样才能在成绩下降时快速判断到底是哪一类内容超预算了。2.2 滑动窗口保留新鲜信息丢掉中间过程滑动窗口是最简单也最常用的上下文管理策略。它的思路是只保留最近 N 轮对话或最近若干条消息把更早的内容全部淘汰。这个思路类似信号处理里的滑动窗口滤波模型只基于最近一段时间的观测做判断忽略历史全部数据。滑动窗口的优点是实现成本低、行为可预期、不容易引入额外噪声。缺点是信息保真度有限如果任务目标在早期消息里窗口滚动后模型就看不到目标了。很多编码智能体出现“做着做着忘了最初需求”的现象就是滑动窗口把早期指令淘汰掉了。所以在使用滑动窗口时要把系统提示词、任务说明等不可丢失的内容放到“保护段”永远不参与窗口淘汰。滑动窗口只负责执行轨迹也就是工具调用记录和对话轮次不负责任务目标。2.3 压缩与摘要用信息密度换上下文长度摘要策略是把较早的上下文交给模型或专门算法压缩成结构化摘要用一小段文字代表一大段历史。它的核心是信息密度换空间用可能丢失细节的代价换取更长任务的可执行性。摘要怎么做直接影响成绩。好的摘要不是简单复述而是要回答四类问题已经完成了什么、还没完成什么、有哪些关键约束、涉及哪些文件路径。如果摘要里没有约束信息模型后续就会在约束上犯错如果摘要里没有文件路径模型就要重新搜索文件增加一轮甚至多轮工具调用。摘要策略适合长流程任务但要注意触发时机。不要每轮都摘要那样会反复压缩最近信息造成信息层层丢失。建议只在上下文使用率达到阈值时触发摘要并且摘要后保留最低限度的原始轨迹作为回退检查的依据。2.4 检索注入与记忆层按需把外部信息拉回窗口检索注入的思路是不把全部代码和历史放进去而是根据当前任务需要从代码索引、历史记忆中检索最相关的片段动态注入上下文。这是典型的 RAG 思路在编码智能体里的应用。在框架层面检索注入通常和记忆层配合。记忆层负责保存跨会话的状态比如任务目标、已完成步骤、重要决策检索层负责按需取回。以 LangGraph 这类智能体框架为例它提供的 InMemorySaver、checkpoint 机制会把执行状态持久化到内存或数据库新的一轮执行可以从保存的状态恢复而不是从零开始。从上下文数据流的角度看整个链路是源代码与历史任务进入索引框架根据当前执行状态生成检索请求检索结果做相关性排序和裁剪再注入到上下文窗口。这个数据流里的每个环节都可能引入噪声检索结果太宽、排序不准、片段裁剪不当都会污染上下文反而不如直接截断。3. 设计一组可复现的对照实验3.1 实验目标固定模型只改框架策略实验设计的第一原则是控制变量。模型要保持完全一致包括模型名称或版本、temperature、max tokens、以及是否开启流式输出。这些参数只要有一个变化实验结果就无法归因。框架变量要定义成可以切换的策略模块而不是一次性写死在代码里。推荐把上下文管理拆成三个可插拔模块轨迹管理模块、摘要模块、检索模块。实验时分别启用不同组合得到四种策略基线全量追加、滑动窗口、滑动窗口加摘要、检索注入加分层记忆。每轮实验使用同一份任务集、同一个种子值、同一套工具调用限制。考虑到模型输出有随机性每组实验至少重复 5 次记录均值和波动范围。这里要强调本文给出的数据方法是示意性的实际结果依赖任务集、模型版本和代码库结构团队要在自己的环境里跑出自己的基线。3.2 任务集与评估指标任务集要覆盖编码智能体的典型使用场景不能只测“写一个函数”。推荐包含四类任务单文件 Bug 修复、多文件功能新增、代码重构、基于 Issue 描述的跨模块修改。每类任务 5 到 10 个任务难度要可区分至少要能让基线策略出现部分失败否则实验没有区分度。评估指标建议分两层。第一层是任务结果包括完成率、测试通过率、人工评分第二层是过程指标包括 token 消耗、工具调用次数、有效步骤率、上下文利用率。过程指标的作用是解释结果差异没有过程指标就只能看到“A 策略比 B 策略好”不知道好在哪里。指标定义评估方式任务完成率在预算内完成主任务的比例人工判定测试通过率修改后代码通过相关测试的比例自动运行测试有效步骤率成功工具调用次数除以总工具调用次数日志统计上下文利用率有效信息 token 数除以总耗用 token 数日志统计波动系数多次运行完成率的变异系数统计计算波动系数是这个实验里最该关注的指标。它直接量化了“成绩波动显著”这句话变异系数越大说明框架策略越不稳定也说明上下文管理还有优化空间。3.3 基线框架全量追加上下文基线框架不做任何上下文管理所有消息全部追加直到达到窗口上限。它的优点是信息保真度最高模型在任何时刻都能看到完整历史缺点是当执行轨迹变长一旦达到上限框架只能硬截断截断往往发生在最前端也就是任务说明所在的位置。硬截断的结果非常有代表性短任务里基线策略表现不错长任务里模型会突然丢失需求开始自由发挥。这个现象本身就是很好的实验素材可以证明上下文紧张时不做管理的框架会让成绩出现显著波动。基线框架也要记录截断点。每次运行后输出日志什么时候触达上限、截断了哪些内容、截断后模型的行为变化。这些日志是后续分析的原始证据。3.4 对照框架 A滑动窗口加摘要对照框架 A 实现两部分能力。滑动窗口负责保留最近 12 轮执行轨迹摘要模块负责把更早的轨迹压缩成结构化摘要。系统提示词和任务说明放入保护段永远不被淘汰。实现时要注意摘要触发条件。推荐设定阈值当上下文使用率达到 75% 时触发摘要摘要后保留最低 2000 token 的原始轨迹作为回退信息。这样既避免了频繁压缩又能保证模型在关键决策点还有原始依据可查。这个策略预计会在中等长度任务上表现稳定但要注意摘要质量。如果摘要模块没有强制提取“关键约束”和“文件路径”长任务后期模型会频繁出现“重新搜索文件”“重复读取同一文件”的无效行为。3.5 对照框架 B检索注入加分层记忆对照框架 B 不依赖完整轨迹而是维护三层记忆系统层保存任务目标和约束执行层保存最近几步的工具结果持久层保存跨会话的决策记录。每次生成前框架根据当前目标检索代码索引注入最相关的文件片段。检索层是这套策略的成败关键。检索粒度不要太大默认取 top 3 个片段每个片段限制在 1500 字符以内超出部分在后续步骤中按需补充。如果一次注入太多片段模型会被无关代码干扰成绩反而不稳定。分层记忆的实现可以借助 LangGraph 这类框架的 checkpoint 和持久化机制把执行状态保存到内存或数据库。这样即使上下文窗口被压缩任务目标、已完成步骤、关键决策仍然能从记忆层恢复。3.6 变量控制与统计方法实验中最容易出问题的变量有三类。第一是模型侧temperature 必须固定推荐 0 到 0.2max tokens 必须固定否则输出长度会影响上下文占用。第二是数据侧任务集顺序要固定工具调用返回的随机内容要记录代码仓库版本要锁定。第三是框架侧prompt 模板顺序不能随意调整保护段内容不能变化。统计上每组策略至少重复 5 到 10 次报告均值、标准差和变异系数。差异是否显著可以用 Bootstrap 或简单 t 检验做判断但团队更应关注实际差距是否达到业务可感知的程度而不只是统计显著。建议实验前先定一个“可接受波动范围”。例如任务完成率的变异系数超过 0.15 就认为波动过大需要调框架低于 0.05 说明当前策略在上下文紧张时也足够稳定。4. 从实验结果反推原因波动是怎么产生的4.1 框架决定了模型能看到什么实验跑完后第一件事不是比较分数而是回放每轮实验的上下文构成。你会发现同一时刻基线框架窗口里是杂乱的完整历史对照框架 A 窗口里是保护段加摘要加最近轨迹对照框架 B 窗口里是目标加检索片段。模型只能基于窗口里的内容生成。所以当两个框架给出不同结果时本质上不是模型变了而是模型“看到”的内容变了。这个认知是定位波动原因的基础所有成绩差异都要先从上下文差异里找解释。4.2 指令与信息的排序影响生成倾向上下文顺序对模型的影响在实验中会表现得非常明显。注意力机制对最近位置的内容更敏感也就是所谓近因效应。如果把需求说明放在窗口最前端又在执行了 30 轮之后没有保护需求说明对模型的约束力会明显下降。这就是为什么框架要在每轮生成前把“当前目标”重新放到靠近输出的位置。很多框架会用“反思”或“当前计划”的方式把目标从历史里提炼出来放到最近的消息里。这个操作本身就是一种上下文重排序能显著减少“模型忘记目标”的问题。4.3 截断带来的隐性错误不是模型笨是信息缺了实验结果里最常见的错误类型不是模型语法错误而是语义层面的“合理但不符合约束”的错误。比如模型改了一个函数但它没有看到另一个文件里对该函数调用方式的约定结果是引用处全部报错。这种错误的隐蔽性在于单看模型输出一切都合理只有回放上下文才发现关键文件内容在截断时被淘汰了。这类错误对成绩波动的影响最大因为不同轮次里截断位置不同模型看到的文件内容不同错误模式也就不同最终表现为成绩忽高忽低。处理办法是把关键约束显式写入保护段或摘要强制字段。框架要能在每轮生成前检查当前窗口里是否还有任务目标、是否还有关键接口约定、是否还有禁止修改的文件列表。缺了就补而不是等模型猜。4.4 波动背后的主要矛盾框架噪声与信息损失从实验数据看波动往往来自两类力量的拉扯。一类是框架噪声检索结果不相关、摘要内容冗余、重复注入同一文件这些都会占用宝贵上下文降低模型注意力质量另一类是信息损失截断、淘汰、摘要过于激进导致模型缺少必要信息。理想框架要做的是在两者之间找平衡。信息保真度高的策略比如全量追加噪声低但损失高信息控制强的策略比如分层摘要损失可控但可能引入摘要噪声。实验的意义不是证明某一种策略永远最好而是找出当前任务特征下哪一类策略的损失和噪声组合最优。5. 落地实现给编码智能体配一个上下文预算系统5.1 确定上下文预算分配表要落地“固定模型、调整框架”第一步是给上下文做预算。预算不是精确到每个 token而是按比例分配让每一类内容有明确上限。下面给出一个适用于 8000 token 预算的分配示例实际项目要按模型窗口、任务复杂度调整。内容类型预算比例8000 token 示例作用系统提示词10%800角色、规则、输出格式任务说明15%1200目标、约束、验收标准记忆摘要20%1600已完成步骤、关键决策执行轨迹35%2800最近对话与工具结果检索片段15%1200当前文件相关内容输出缓冲5%400预留生成空间这个表的核心思想是“执行轨迹不是越多越好”。执行轨迹只占 35%目的是强迫框架及时把旧轨迹压缩成摘要给新的检索片段和输出腾出空间。如果执行轨迹占比过高说明摘要触发机制没有生效。5.2 用滑动窗口保留执行轨迹执行轨迹的管理用滑动窗口实现保留最近的 N 轮消息。窗口之外的消息进入摘要流程窗口之内的消息保持原始状态供模型直接参考。def build_sliding_window(messages, system_prompt, task_prompt, window_size12, summary): 构建带保护段的滑动窗口上下文。 保护段系统提示词、任务说明、记忆摘要永不参与淘汰。 滑动区最近 window_size 轮执行轨迹。 context [] if system_prompt: context.append({role: system, content: system_prompt}) if summary: context.append({role: system, content: 执行摘要\n summary}) if task_prompt: context.append({role: user, content: task_prompt}) recent messages[-window_size:] context.extend(recent) return context关键点在保护段。系统提示词、任务说明、摘要都放在窗口最前面即使执行轨迹滚动这些内容也不会被淘汰。实际项目里可以把这个函数的输出打日志确认每次发送给模型的消息里都包含了任务提示词。5.3 用摘要层保存长期目标和关键约束摘要层在达到触发阈值时执行把窗口淘汰的旧消息压缩成结构化摘要。摘要必须包含四类信息已完成步骤、未完成事项、关键约束、重要文件路径。少任何一类后续执行都可能出问题。def summarize_turns(turns, model_client): 把旧执行轨迹压缩成结构化摘要保留后续执行所需的关键信息。 merged \n.join( f{t.get(role, unknown)}: {t.get(content, )} for t in turns ) prompt ( 请把下面的智能体执行记录压缩成结构化摘要。\n 必须包含四部分\n 1) 已完成步骤\n 2) 未完成事项\n 3) 关键约束用户明确要求、禁止行为、依赖约定\n 4) 重要文件路径。\n 不要输出与执行无关的内容。\n\n merged ) result model_client.complete(prompt) return result注意这里的 model_client 是一个抽象的模型调用接口实际项目中要替换成具体 SDK。摘要本身也会消耗 token所以要控制摘要长度比如限制在 1600 token 以内并对摘要做额外校验如果摘要里没有“关键约束”字段就拒绝使用改用更保守的截断策略。5.4 用检索层按需注入文件片段检索层解决的是“模型需要具体代码”的场景。最简单的实现是关键词匹配生产环境可以升级为向量检索。这里给出一个简化版本目的是说明注入过程的裁剪逻辑。def retrieve_snippets(query, file_index, top_k3, max_chars1500): 按关键词匹配检索相关文件片段并限制总注入长度。 scored [] for path, content in file_index.items(): score sum(1 for keyword in query.split() if keyword in content) if score 0: scored.append((score, path, content)) scored.sort(keylambda item: item[0], reverseTrue) snippets [] total 0 for score, path, content in scored[:top_k]: remain max_chars - total if remain 0: break snippet content[:remain] snippets.append(f# {path}\n{snippet}) total len(snippet) return \n\n.join(snippets)两处要特别注意。第一检索结果必须按相关性排序第二注入总量必须设上限不能因为相关就全塞进去。检索片段超过预算时宁可少注入也不要挤压执行轨迹和输出空间。5.5 组装一个最小上下文管理类把预算、滑动窗口、摘要、检索组合成同一个类对外只暴露一个获取上下文的接口。这样可以保证所有框架策略都走同一套管理逻辑便于后续做对照实验。class ContextManager: def __init__(self, config, model_client, file_index): self.config config self.model_client model_client self.file_index file_index self.messages [] self.summary def add_message(self, role, content): self.messages.append({role: role, content: content}) def should_summarize(self) - bool: used estimate_tokens(self.messages) trigger self.config[summarization][trigger_tokens] return used trigger and self.summary def build(self, query, system_prompt, task_prompt): if self.should_summarize(): self.summary summarize_turns(self.messages, self.model_client) self.messages self.messages[-self.config[sliding_window][max_recent_turns]:] window build_sliding_window( self.messages, system_prompt, task_prompt, window_sizeself.config[sliding_window][max_recent_turns], summaryself.summary, ) if self.config[retrieval][enabled]: snippets retrieve_snippets( query, self.file_index, top_kself.config[retrieval][top_k], max_charsself.config[retrieval][max_chars_per_snippet], ) if snippets: window.append({role: user, content: 参考代码片段\n snippets}) return window对应的配置文件推荐用 YAML 组织便于切换策略context_manager: total_token_budget: 8000 reserved_output_tokens: 1200 strategy: hybrid sliding_window: enabled: true max_recent_turns: 12 summarization: enabled: true trigger_tokens: 6000 summary_max_tokens: 1600 retrieval: enabled: true top_k: 3 max_chars_per_snippet: 1500生产环境里还需要补充 token 统计、日志落盘、配置热更新和异常兜底。这里的示例用于说明核心思路实际项目要结合自己的模型 SDK、路径和依赖版本调整。6. 常见问题与排查链路6.1 模型表现突然下降先查上下文里到底少了什么现象是同一套配置某一次运行突然完不成任务或者完成质量明显下降。碰到这种情况不要急着调 prompt先打印这一轮实际发送给模型的上下文。检查顺序是任务说明是否还在关键约束是否还在最近执行轨迹是否完整检索片段是否包含相关代码。如果发现任务说明被淘汰说明保护段没有生效如果发现关键约束缺失说明摘要模块没有强制提取约束字段。这个排查只需要几步但能避免大量无效调参。6.2 越改越差框架调整引入了噪声另一类常见现象是调整框架后成绩不但没提升反而下降。这时候要怀疑框架噪声检索片段太宽、摘要内容冗余、同一份代码被重复注入多次。检查方式是统计每轮上下文里“有效信息 token”的占比。有效信息是指与当前生成任务直接相关的内容比如当前文件内容、目标约束、最近工具结果。如果有效信息占比低于 50%基本可以断定框架噪声过大需要收紧检索 top_k、加严摘要模板、去重注入内容。6.3 上下文看似够用但成绩持续下滑还有一种更难定位的情况token 统计显示上下文才用了 60%没有截断但模型就是表现不好。这时问题往往不是容量而是有效信息密度太低。多见于基线框架窗口里堆了大量历史对话、冗余工具输出、重复文件内容真正对当前决策有用的信息被淹没。处理思路是主动压缩历史而不是等窗口满了再处理。可以设置一个较低的使用率阈值比如 50%触发一次历史轨迹归档把旧内容转成摘要。6.4 常见问题速查表问题现象常见原因检查方式处理建议模型忘记最初需求需求在滑动窗口中被淘汰打印发送给模型的完整消息序列将任务说明放入保护段多次重复读取同一文件摘要未保存文件路径查看工具调用序列摘要强制包含文件路径字段检索注入后结果变差检索片段噪声大、排序不准统计注入片段的命中率降低 top_k提高相关度阈值工具调用死循环执行轨迹过长、终止条件缺失查看调用链日志设置最大步数和强制终止条件同一任务多次结果差异大上下文构成因截断而不同对比多轮运行的上下文快照固定保护段稳定摘要触发时机摘要后表现下滑摘要丢了关键约束或细节对比摘要和原始轨迹增加约束字段校验摘要不合格则回退6.5 排查清单做任何框架调整前先跑一遍下面的清单能避免大部分“玄学”问题模型 ID、temperature、max tokens 是否完全固定。是否有每条消息的 token 数记录。是否有每次发送给模型的完整上下文快照。任务说明是否在保护段中。摘要是否包含已完成步骤、未完成事项、关键约束、文件路径。检索片段是否按相关性排序并设了长度上限。工具调用是否设置了最大步数和终止条件。每轮实验是否重复至少 5 次并记录变异系数。7. 最佳实践与扩展方向7.1 上下文预算分配的推荐顺序从实验结果看上下文紧张时最值得优先保证的是任务目标和关键约束其次是最近执行轨迹再次是检索片段最后才是完整历史。这个优先级意味着框架设计上保护段必须留给系统提示词和任务说明摘要触发要早于窗口触顶检索注入要克制。一个实用的经验是先把执行轨迹压到预算的 35% 以内再谈检索质量。执行轨迹是增长最快的部分也是膨胀的主要来源。轨迹管理做不好再好的检索也会被历史淹没。7.2 学习环境与生产环境的区别学习环境里跑通单次任务只需要一个滑动窗口或一个摘要函数就够了。生产环境完全不同要额外考虑三件事一是日志每次请求的上下文构成、token 用量、截断点都要落盘否则成绩波动时没有数据可查二是监控上下文利用率、工具调用次数、有效步骤率要定时统计并设置告警三是回滚框架策略要支持配置开关新策略上线时保留旧策略的切换能力。另外生产环境的代码库比实验环境大得多检索层必须用向量索引或增量索引不能每次全量扫描。文件索引的更新频率也要考虑代码变更后索引过期检索片段就会指向旧内容引入新的噪声。7.3 扩展方向模型路由、蒸馏与自动化评测“固定模型、调整框架”只回答了“框架怎么影响成绩”的问题。下一步可以把模型维度重新加回来做两个扩展方向。第一个方向是模型路由。根据上下文紧张程度动态选择模型上下文小而任务简单用轻量模型上下文大而任务复杂用强模型。这个方向需要先积累本文实验里的过程指标才能建立路由规则。第二个方向是蒸馏协作。上下文紧张时与其把所有信息塞给一个大模型不如让轻量模型先做轨迹摘要、目标提炼再交给主模型决策。这本质上是把上下文管理的一部分工作外包给更便宜的模型和模型蒸馏的思路相通但应用在框架层而不是权重层。第三个方向是自动化评测。把任务集、评估脚本、上下文快照都沉淀成评测流水线每次改框架自动跑一轮对比输出完成率和波动系数。只有评测自动化团队才敢持续调整框架而不是调一次怕一次。回到最初的问题编码智能体成绩波动显著不是因为模型不稳定而是因为模型看到的上下文在变。固定模型、调整框架本质是把注意力从“换更强的模型”转移到“给现有模型一个更稳定的上下文环境”。先记录、再实验、后优化这是当前阶段最值得投入的调优路径也是把编码智能体从演示推向生产的关键一步。