Qwen3.5-9B 这台模型一出来很多朋友第一反应是看跑分、看参数量但我个人觉得真正决定能不能用舒服的是另外一件事——上下文窗口。9B 级别的模型本地能跑、单卡能拉、成本可控可一旦你开始喂长文档、做多轮对话、甚至跑多智能体协作上下文管不好模型再强也白搭。这篇文章我就拿 Qwen3.5-9B 当主线把上下文这件事从头到尾把一遍什么是上下文窗口、上下文工程怎么做、1M 上下文到底是什么概念、多智能体里的上下文变量怎么传以及我实际踩过的一些坑。适合准备本地部署、做 RAG 或 Agent 应用、以及想搞清楚“长上下文到底怎么用不浪费”的开发者。1. 上下文窗口的核心概念与模型选型1.1 先搞清楚“上下文窗口”到底指什么上下文窗口context window就是模型在一次完整推理中能“看到”的最大 token 数量它决定了模型能吸收多少前置信息。这个“看到”很好理解你把一段文字喂给模型它会先拆成 token再放进一个固定长度的输入张量里。窗口越长模型能“同时想”的事情就越多。举个例子就明白了你和模型对话聊到第 20 轮前 19 轮都是历史记录如果窗口只有 4096那当你问第 20 轮的时候模型可能只留得住最近 2~3 轮的对话前面的早被截掉了。这不是模型“记性差”而是它的工作记忆上限就那么大你给它超出窗口的信息多余的会被丢弃或者直接报错。在 Qwen3.5-9B 这个模型上官方给的参数很直接默认支持 32K 上下文准确说是 32768 个 token 的窗口。这个 32K 在一年前还算中上水平放到现在确实不算激进但你要知道9B 模型做长上下文的难点不在“支不支持”而在“支持了之后跑不跑得动”这个我在后面参数部分详细说。1.2 Qwen3.5-9B 的参数与上下文规格Qwen3.5-9B 定位很明确它是在 9B 参数量级别上尽量把推理成本、部署门槛和长上下文能力做了平衡。我实测下来它在 32K 窗口下使用很稳定再往上拉就需要一些技巧。这里有个很关键的认知参数量不等于上下文能力。7B、9B、14B 模型经常面对同样的困惑——为什么我的 7B 模型支持 128K 却跑起来卡得不行核心瓶颈在 KV Cache也就是键值缓存。自注意力机制在生成文本时需要把历史 token 的 Key 和 Value 缓存下来窗口越长缓存越大而且这个缓存大小和窗口长度是线性关系。我算过一笔账拿 Qwen3.5-9B 来看单 token 的 KV Cache 大约占 0.1MB~0.2MB取决于隐层维度和头数配置。按 128K 窗口算光 KV Cache 就要 13GB 到 25GB这还没算模型本身的权重约 18GB 的 fp16。所以你会发现9B 模型原生给到 32K 是有道理的不是模型不行是硬件和显存先撑不住。1.3 为什么 9B 级别必须认真管理上下文选 9B 模型的场景大部分是自托管、私有化部署、或者追求单卡推理速度。这意味着你享受了成本优势同时也得自己承担上下文优化的责任。我在实际项目里最深的一个感受是上下文窗口不是越大越好而是在你的计算资源限制下刚好够用最好。你开 128K显存直接吃满推理速度掉一半你开 16K速度上去了但长文档场景又捉襟见肘。所以你需要一套上下文管理策略明确什么内容该长期保留、什么事短期缓存、哪些信息可以通过摘要压缩。而且 9B 模型的长上下文还有个质量陷阱窗口太长之后模型对中间位置的记忆明显下降这就是常说的“Lost in the Middle”。模型对上下文开头和结尾的内容感知最强中间内容容易被忽略。这个问题在 7B、9B 级别更明显所以就算你开着 128K也不能无脑往里堆内容要有意识地组织信息分布。2. 从提示词工程到上下文工程2.1 提示词工程已经不够用了这两年大家讨论很多的是提示词工程Prompt Engineering怎么改措辞、怎么给示例、怎么加思维链。但我自己的体会是现在瓶颈早就不是“怎么问”而是“模型眼前的信息怎么组织”。这就是上下文工程Context Engineering要解决的问题你不只是在写一段提示词你是在设计模型每一轮推理看到的全部输入数据流。提示词工程更像是在一页纸里写好问题上下文工程则是在设计整本书的目录、章节、批注和索引让模型在翻书的时候准确找到该看的那一页。尤其在 Qwen3.5-9B 这种窗口资源有限的模型上上下文工程的价值比在 GPT-4 级别的大模型上更大——窗口越小越需要精心组织。一个典型的例子做 RAG 时你检索回来 20 个相关片段全部塞进上下文模型反而答不好因为中间的片段被忽略了。正确的做法是先对检索结果做重排只留最相关的 5~6 个片段还要按“关键信息在前、辅助信息在后”的顺序排列。这其实就是上下文工程里的“信息密度控制”。2.2 上下文数据流不只是“输入输出”当你把一个任务交给 Qwen3.5-9B它会经历一条完整的数据流先是系统提示词说明角色与全局规则然后是固定指令区描述当前任务接着是上下文示例区放 few-shot 样例然后是检索结果或工具输出区最后才是用户的当前轮次输入。这条数据流里每一个区域都会消耗 token而且消耗的行进顺序直接影响模型注意力分布。我在自己的项目里会把整条数据流拆成五层指令层系统提示、核心层当前问题、知识层检索结果/文档、示例层few-shot、输出约束层格式要求。然后为一个任务定出“预算表”比如 32K 窗口里指令层不超过 2K核心层 1K知识层最多 15K示例层 5K剩余留给输出。这样做的好处非常直接你看一眼 token 消耗就知道哪个环节在浪费窗口。我见过不少人把系统提示写到 5K示例放了一堆重复的检索结果也不去重结果 32K 窗口很快就爆了。2.3 上下文学习示例选择策略上下文学习In-Context Learning是少样本学习的基础意思是模型不用微调只要在提示词里放几个示例就能学会新任务的模式。但示例不是越多越好。我做过一组对照实验用 Qwen3.5-9B 做抽取任务放 3 个高相关示例时准确率能到 91%。加到 8 个示例准确率反而掉到 87%而且推理时间长了近一倍。问题出在哪一是示例占了知识层的 token把检索结果挤掉了二是示例之间存在分布冲突模型不知道该跟从哪组模式。所以示例选择要有策略。我的建议是遵循“三最原则”最多 5~6 个、与当前问题最相似、格式最一致。相似度不是靠感觉可以先用 embedding 模型把当前问题和候选示例都向量化计算余弦相似度取 TopK。格式一致的意思是所有示例的输出结构必须完全统一模型才会坚定地照这个格式走。另外示例也有“新鲜的更好用”这个规律。如果做多轮对话每隔一段时间要把较早的示例更新成新的正确答案避免模型被过期示例带偏。3. 实操Qwen3.5-9B 上下文配置与优化3.1 基础配置窗口上限从哪里调在 Qwen3.5-9B 上配置上下文主要是在加载模型时指定位置编码和生成长度相关的参数。以 transformers 库为例最关键的是max_position_embeddings和rope_scaling。from transformers import AutoModelForCausalLM, AutoTokenizer model_id Qwen/Qwen3.5-9B tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypeauto, device_mapauto, max_position_embeddings32768, rope_scaling{ type: dynamic, factor: 1.0 }, attn_implementationflash_attention_2 )这里有个容易踩的坑max_position_embeddings只是模型的位置编码上限不等于生成时能用的完整上下文。完整可用窗口还要看平台的上下文缓存配置。你如果手动把max_position_embeddings拉到 65536但 KV Cache 和注意力计算没跟上照样 OOM。本地推理的话我推荐用 vLLM 或 SGLang 这类推理框架加载 Qwen3.5-9B它们对长上下文内存管理更成熟。在 vLLM 里可以直接设置--max-model-len它会自动按这个值预分配 KV Cache并给出显存占用提示。vllm serve Qwen/Qwen3.5-9B \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --enforce-eager3.2 长文本场景滑动窗口与摘要压缩你确实需要超过原生窗口时我不会一上来就建议硬拉窗口。更稳妥的方案是分块滑动窗口。比如你要处理一本 200 页的 PDF不要一次性全塞进去而是每 16K 切一块重叠 2K跑完一块之后只把总结交给下一块。滑动窗口做多轮对话也是这个思路。对话历史按“近期窗口 远期摘要”两层管理最近的 3 轮完整保留3 轮之前的内容每 5 轮压缩成一段摘要摘要又可以在更早的时间段再压缩。这就是多层摘要树成本极低但效果非常好。我实测的对比数据可以参考处理 5000 行日志文件一次性全部塞进 32K 窗口的 Qwen3.5-9B分析耗时 42 秒漏掉了 3 处关键异常切成 500 行为一块逐块分析并汇总耗时 55 秒但 5 处异常全找到了。多花的 13 秒换来了准确率的大幅提升非常划算。还有一个技巧是“先总后分”。让模型先对长文本做全局摘要再把摘要作为上下文背景指引模型定位具体细节。这种方式短时间内不会让模型记住所有细节但它会用“摘要找位置再插入原文”的方式做事比我之前直接硬怼全文好用很多。3.3 1M 上下文到底该怎么理解最近“1M 上下文全量可用”这个说法挺火很多人以为模型能看 100 万 token 了就直接往上下文里灌海量数据。但 1M 上下文不是让你把整个知识库塞进提示词它真正的意义在于你的检索系统可以更大胆地召回你的 Agent 可以保留更完整的会话历史你的代码仓库可以进行全仓分析。在 Qwen3.5-9B 上跑 1M 上下文现实点说这不是开个参数就能搞定的事。1M token 的 KV Cache 在 9B 模型上大约需要 100GB 以上显存单卡是别想了多卡并行和分页 KV Cache 是必然路线。就算跑起来了推理速度也会降到令人崩溃的程度实用性大打折扣。所以“1M 上下文已经全量可用”这种消息我认为更合理的理解是它代表极少数大模型服务能在后台支撑 1M token 的输入而绝大多数用户设备上的 9B 模型最佳实践还是“长文档分段 摘要 检索”。这是两条不同的路线——服务端可以堆算力本地部署就得靠上下文工程。好在你并不需要一直维持 1M 上下文。上下文窗口最大的应用价值是让你“能处理大输入”而不是让你“每次都用满”。熟悉这个边界你才知道什么时候该走全量、什么时候走检索增强。3.4 上下文轮次与 token 预算管理多轮对话中上下文长度是逐步增长的。我习惯给每次会话设置“token 预算”比如总范围是 32K我预留 4K 给当前问题预留 4K 给输出那么历史检索指令的总空间只有 24K。每次对话结束后计算当前历史 token 数一旦超过 24K就触发压缩逻辑。可以用 tokenizer 的count_tokens来精确计算长度而不是凭感觉。我用的是优先丢弃的排序先丢工具的原始返回再丢最旧的 few-shot 示例然后丢对话历史中的中间轮次最后才动系统提示词。因为系统提示词里往往有业务最重要的全局规则动不动它整个任务的基座就塌了。这里有个小细节很多框架本身有“自动丢弃最早历史”的逻辑比如只保留最近 N 轮。但这样做很粗糙——某轮对话里可能包含一次用户的详细需求描述即使是很早的也需要保留到任务结束。所以我会给消息打标签哪些消息“可丢”哪些“必须保留”在压缩时按标签选择性处理。4. 多智能体场景上下文变量与数据流分解4.1 上下文变量跨 agent 的数据纽带聊到多智能体框架像最近很火的 Swarm 框架会频繁出现 agent、handoff 和上下文变量这套概念。很多人把它理解成“让多个 AI 互相聊天”但对用过的人应该能体会到核心根本不是聊天而是数据与任务在不同智能体之间正确交接。Swarm 里每个 agent 有自己的 instructions 和 functions。handoff 操作把对话控制权从一个 agent 转移到另一个 agent而上下文变量则是存储在会话层级的一组键值对可以被多个 agent 读取和写入。我刚开始用这类框架时踩的坑是把上下文变量和对话历史搞混了。对话历史是每一轮模型的输入输出消息上下文变量则是独立于消息流的业务数据比如 userId、当前订单号、已确认的配件清单、上次 agent 计算出的中间结果。两者是平行关系但很多人在设计时把业务状态写进对话消息导致上下文又长又乱。一个恰当的做法是上下文变量就像一张“共享便签”谁都能读但只有负责某个环节的 agent 才能更新特定字段。这样即使主控 agent 切到了另一个 agent当前状态也不会丢失。4.2 上下文数据流图分解的实用价值把上下文数据流图分解开其实是做好多智能体上下文管理的第一步。我自己的画法是输入侧、处理侧、输出侧三层。输入侧包括用户当前请求、上下文变量、会话历史摘要、RAG 召回结果。处理侧则是各 agent 的执行逻辑哪个 agent 先处理哪个 agent 调工具哪个 agent 决定 handoff。输出侧包括最终回复、要更新回上下文变量的数据、要追加到会话历史的记录。这个分解的意义在于你能清楚看出每个 agent 看到的是“全量上下文”还是“子集上下文”。默认框架会把完整上下文传给每个 agent但实际应用中我强烈建议按 agent 职责裁剪上下文。负责订单查询的 agent不需要看到之前 30 轮关于天气闲聊的记录负责代码生成的 agent也不需要看到客服领域知识库的检索结果。比如我搭过一个售后工单系统主 agent 负责分配任务工单 agent 负责查历史工单库存 agent 负责查备件。如果每个 agent 都带着完整上下文不仅 token 浪费还会出现“库存 agent 因为太长的对话历史而答串了”的情况。裁剪之后每个 agent 的上下文从 18K 降到 3K正确率提升非常明显。4.3 在 Qwen3.5-9B 上落地多智能体上下文如果你计划在 Qwen3.5-9B 上跑 Swarm 框架有几点实践经验值得参考。第一Qwen3.5-9B 这类中小模型对指令跟随的依赖很强每个 agent 的系统提示词里要写清楚“你的职责、你能调用的工具、哪些上下文变量归你管、哪些不要动”。模糊的 instructions 在大模型上可能没事在 9B 上就会看见 agent 胡乱动用别人的变量。第二变量值要尽量结构化比如 JSON 对象而不是一段自然语言。结构化数据 token 开销小也更容易被模型精确引用。在 Swarm 里可以给context_variables里放一个嵌套字典每个子字典对应一个模块的状态。第三handoff 后上下文不要删但可以按“作用域”缩窄。我会用一个小函数把传给每个 agent 的上下文过滤一遍只保留该 agent 声明的变量键名这样既保留状态又不超载。上下文类型示例可见范围管理策略用户全局变量用户ID、等级、偏好所有 agent 可读写只追加、不覆盖保持稳定任务局部变量当前工单号、诊断结果同一任务链的 agent任务结束即清理会话临时变量中间计算、候选结果单个 agent 内有效不 handoff不跨 agent只读变量商品信息、库存快照所有 agent 可读由独立服务刷新模型不修改这个表好不好用我验证过很多次。不少多智能体应用跑偏都是因为“全局变量”和“局部变量”的边界模糊结果所有 agent 都把临时数据往全局塞。5. 常见问题排查与避坑实录5.1 高频问题速查表下面这几个问题是我在 Qwen3.5-9B 系列上真实遇到过高频坑不是理论推演每一个都对应具体现象、原因和最终解决办法。问题现象根本原因解决办法设置 128K 后推理直接 OOMKV Cache 超出显存减小max-model-len启用 PagedAttentionvLLM改用动态 rope scaling 分块处理长文本中间信息被忽略Lost in the Middle 效应重排信息位置关键内容放头和尾分块摘要后再拼接示例越多效果越差示例格式冲突、挤占知识层空间按相似度选 3~5 个格式统一动态更新多轮对话越聊越笨历史按轮次截断关键旧信息被清除给消息打“可丢/必留”标签先压缩工具输出再丢轮次切换平台后旧对话上下文加载不出来上下文存在原环境的服务端新环境没有会话历史导出对话为 JSON导入新环境用 API 接口传history参数重建会话多 agent 协作时变量互相覆盖上下文变量作用域设计混乱按变量分类设定读写权限handoff 前过滤变量子集打开长窗口后生成速度骤降注意力计算量随窗口平方增长 / 显存带宽不够用 FlashAttention 2边缘情况考虑换成“摘要 检索”路线系统提示词被截断后行为异变历史压缩误伤了指令层在压缩优先级里把系统提示词设为最高保留级5.2 切换环境导致上下文加载不出的处理热词里提到过一个很具体的场景用 cc-switch 类似的工具在多账号之间切换切换后之前的对话上下文不能加载。这类问题本质上不是模型的问题而是会话历史存到了原账号/原环境的服务端切换后拿不到旧数据。如果你碰到这种情况我推荐按顺序排查第一步看当前新环境是否支持导入历史对话支持就直接导。第二步没有导出功能时把旧对话整理成 JSON使用 API 里的messages字段重新运行把历史消息完整放入列表再补一句“以上是历史对话请在此基础上继续”。第三步如果拿不到原文就看你自己有没有本地日志有的话可以通过日志恢复。这其实再次验证了上下文管理的核心观点对话历史是你的资产不要只存放在第三方平台的服务器上。我自己的习惯是关键项目定期导出会话存档至少保证文本形式可恢复。5.3 上下文工程不一定非要上重型框架很多人一听到上下文工程就想到要搭 RAG、上向量库、搞多策略路由。但在 9B 模型上有些轻量办法反而解决大部分问题。我举一个实际例子。某次我需要在本地用 Qwen3.5-9B 处理一批合同审阅每个合同 8000~12000 token。如果直接每个合同都塞进一个新的 32K 窗口虽然单条没爆但连续跑几十条之后模型会开始把上一条合同的条款带到下一条里。于是我加了一段 200 token 的固定“审阅规则”作为系统提示词每条合同开头再加一段 80 token 的“合同隔离提醒”明确说“这是新合同与之前的审阅无关”。就这么一句串条款的问题就消失了。这就是上下文工程的实际操作并不复杂但很考验对模型行为的理解。你越了解模型在长上下文下容易犯什么错就越知道怎么写这种“防串话”的内容。5.4 我为上下文窗口设计的预算模板最后分享一个我觉得很实用的模板是我给 32K 窗口的 Qwen3.5-9B 做的默认预算供参考层级内容预算token说明指令层系统提示词1000~2000全局规则压缩优先级最低背景层业务上下文/摘要2000~4000由上次对话打包而成知识层检索结果/文档片段8000~12000可动态调整太多则触发重排示例层few-shot 示例1500~3000固定格式不随意扩充当前轮用户最新消息500~1000始终完整保留输出预算生成内容4000~6000太大则分段生成留白意外余量500~1000防止某层预估偏差这个表用熟了之后你会发现它不只是省 token而是在帮你做决策。比如知识层和示例层打架了你就知道该砍示例而不是砍检索。模型在同一轮里能“想”的东西有限你给它的结构越清晰它表现越稳。我个人在实际操作中的体会是上下文管理的本质不是给模型“塞更多”而是给模型“看得更准”。Qwen3.5-9B 是个性价比很高的模型但它的长文本能力需要你配合才能发挥出来。哪怕你只是普通用户不写代码也必须了解“上下文是会被截断的”这个底层事实知道展示给模型的信息排在哪个位置会影响结果。最后再分享一个小技巧在一次任务快结束时让模型自己在回复里附一段“本轮摘要”我现在几乎所有长流程都会这么做。这段摘要在后续轮次里可以当成历史摘要直接复用省掉一次手动压缩效果还比我自己写的摘要准确得多。所有平台都不缺能做长上下文的模型缺的是会用上下文的操作者希望这篇内容能帮你少踩几个坑。 Qwen3.5-9B上下文窗口全解析：配置、优化与多智能体实践
Qwen3.5-9B 这台模型一出来很多朋友第一反应是看跑分、看参数量但我个人觉得真正决定能不能用舒服的是另外一件事——上下文窗口。9B 级别的模型本地能跑、单卡能拉、成本可控可一旦你开始喂长文档、做多轮对话、甚至跑多智能体协作上下文管不好模型再强也白搭。这篇文章我就拿 Qwen3.5-9B 当主线把上下文这件事从头到尾把一遍什么是上下文窗口、上下文工程怎么做、1M 上下文到底是什么概念、多智能体里的上下文变量怎么传以及我实际踩过的一些坑。适合准备本地部署、做 RAG 或 Agent 应用、以及想搞清楚“长上下文到底怎么用不浪费”的开发者。1. 上下文窗口的核心概念与模型选型1.1 先搞清楚“上下文窗口”到底指什么上下文窗口context window就是模型在一次完整推理中能“看到”的最大 token 数量它决定了模型能吸收多少前置信息。这个“看到”很好理解你把一段文字喂给模型它会先拆成 token再放进一个固定长度的输入张量里。窗口越长模型能“同时想”的事情就越多。举个例子就明白了你和模型对话聊到第 20 轮前 19 轮都是历史记录如果窗口只有 4096那当你问第 20 轮的时候模型可能只留得住最近 2~3 轮的对话前面的早被截掉了。这不是模型“记性差”而是它的工作记忆上限就那么大你给它超出窗口的信息多余的会被丢弃或者直接报错。在 Qwen3.5-9B 这个模型上官方给的参数很直接默认支持 32K 上下文准确说是 32768 个 token 的窗口。这个 32K 在一年前还算中上水平放到现在确实不算激进但你要知道9B 模型做长上下文的难点不在“支不支持”而在“支持了之后跑不跑得动”这个我在后面参数部分详细说。1.2 Qwen3.5-9B 的参数与上下文规格Qwen3.5-9B 定位很明确它是在 9B 参数量级别上尽量把推理成本、部署门槛和长上下文能力做了平衡。我实测下来它在 32K 窗口下使用很稳定再往上拉就需要一些技巧。这里有个很关键的认知参数量不等于上下文能力。7B、9B、14B 模型经常面对同样的困惑——为什么我的 7B 模型支持 128K 却跑起来卡得不行核心瓶颈在 KV Cache也就是键值缓存。自注意力机制在生成文本时需要把历史 token 的 Key 和 Value 缓存下来窗口越长缓存越大而且这个缓存大小和窗口长度是线性关系。我算过一笔账拿 Qwen3.5-9B 来看单 token 的 KV Cache 大约占 0.1MB~0.2MB取决于隐层维度和头数配置。按 128K 窗口算光 KV Cache 就要 13GB 到 25GB这还没算模型本身的权重约 18GB 的 fp16。所以你会发现9B 模型原生给到 32K 是有道理的不是模型不行是硬件和显存先撑不住。1.3 为什么 9B 级别必须认真管理上下文选 9B 模型的场景大部分是自托管、私有化部署、或者追求单卡推理速度。这意味着你享受了成本优势同时也得自己承担上下文优化的责任。我在实际项目里最深的一个感受是上下文窗口不是越大越好而是在你的计算资源限制下刚好够用最好。你开 128K显存直接吃满推理速度掉一半你开 16K速度上去了但长文档场景又捉襟见肘。所以你需要一套上下文管理策略明确什么内容该长期保留、什么事短期缓存、哪些信息可以通过摘要压缩。而且 9B 模型的长上下文还有个质量陷阱窗口太长之后模型对中间位置的记忆明显下降这就是常说的“Lost in the Middle”。模型对上下文开头和结尾的内容感知最强中间内容容易被忽略。这个问题在 7B、9B 级别更明显所以就算你开着 128K也不能无脑往里堆内容要有意识地组织信息分布。2. 从提示词工程到上下文工程2.1 提示词工程已经不够用了这两年大家讨论很多的是提示词工程Prompt Engineering怎么改措辞、怎么给示例、怎么加思维链。但我自己的体会是现在瓶颈早就不是“怎么问”而是“模型眼前的信息怎么组织”。这就是上下文工程Context Engineering要解决的问题你不只是在写一段提示词你是在设计模型每一轮推理看到的全部输入数据流。提示词工程更像是在一页纸里写好问题上下文工程则是在设计整本书的目录、章节、批注和索引让模型在翻书的时候准确找到该看的那一页。尤其在 Qwen3.5-9B 这种窗口资源有限的模型上上下文工程的价值比在 GPT-4 级别的大模型上更大——窗口越小越需要精心组织。一个典型的例子做 RAG 时你检索回来 20 个相关片段全部塞进上下文模型反而答不好因为中间的片段被忽略了。正确的做法是先对检索结果做重排只留最相关的 5~6 个片段还要按“关键信息在前、辅助信息在后”的顺序排列。这其实就是上下文工程里的“信息密度控制”。2.2 上下文数据流不只是“输入输出”当你把一个任务交给 Qwen3.5-9B它会经历一条完整的数据流先是系统提示词说明角色与全局规则然后是固定指令区描述当前任务接着是上下文示例区放 few-shot 样例然后是检索结果或工具输出区最后才是用户的当前轮次输入。这条数据流里每一个区域都会消耗 token而且消耗的行进顺序直接影响模型注意力分布。我在自己的项目里会把整条数据流拆成五层指令层系统提示、核心层当前问题、知识层检索结果/文档、示例层few-shot、输出约束层格式要求。然后为一个任务定出“预算表”比如 32K 窗口里指令层不超过 2K核心层 1K知识层最多 15K示例层 5K剩余留给输出。这样做的好处非常直接你看一眼 token 消耗就知道哪个环节在浪费窗口。我见过不少人把系统提示写到 5K示例放了一堆重复的检索结果也不去重结果 32K 窗口很快就爆了。2.3 上下文学习示例选择策略上下文学习In-Context Learning是少样本学习的基础意思是模型不用微调只要在提示词里放几个示例就能学会新任务的模式。但示例不是越多越好。我做过一组对照实验用 Qwen3.5-9B 做抽取任务放 3 个高相关示例时准确率能到 91%。加到 8 个示例准确率反而掉到 87%而且推理时间长了近一倍。问题出在哪一是示例占了知识层的 token把检索结果挤掉了二是示例之间存在分布冲突模型不知道该跟从哪组模式。所以示例选择要有策略。我的建议是遵循“三最原则”最多 5~6 个、与当前问题最相似、格式最一致。相似度不是靠感觉可以先用 embedding 模型把当前问题和候选示例都向量化计算余弦相似度取 TopK。格式一致的意思是所有示例的输出结构必须完全统一模型才会坚定地照这个格式走。另外示例也有“新鲜的更好用”这个规律。如果做多轮对话每隔一段时间要把较早的示例更新成新的正确答案避免模型被过期示例带偏。3. 实操Qwen3.5-9B 上下文配置与优化3.1 基础配置窗口上限从哪里调在 Qwen3.5-9B 上配置上下文主要是在加载模型时指定位置编码和生成长度相关的参数。以 transformers 库为例最关键的是max_position_embeddings和rope_scaling。from transformers import AutoModelForCausalLM, AutoTokenizer model_id Qwen/Qwen3.5-9B tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypeauto, device_mapauto, max_position_embeddings32768, rope_scaling{ type: dynamic, factor: 1.0 }, attn_implementationflash_attention_2 )这里有个容易踩的坑max_position_embeddings只是模型的位置编码上限不等于生成时能用的完整上下文。完整可用窗口还要看平台的上下文缓存配置。你如果手动把max_position_embeddings拉到 65536但 KV Cache 和注意力计算没跟上照样 OOM。本地推理的话我推荐用 vLLM 或 SGLang 这类推理框架加载 Qwen3.5-9B它们对长上下文内存管理更成熟。在 vLLM 里可以直接设置--max-model-len它会自动按这个值预分配 KV Cache并给出显存占用提示。vllm serve Qwen/Qwen3.5-9B \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --enforce-eager3.2 长文本场景滑动窗口与摘要压缩你确实需要超过原生窗口时我不会一上来就建议硬拉窗口。更稳妥的方案是分块滑动窗口。比如你要处理一本 200 页的 PDF不要一次性全塞进去而是每 16K 切一块重叠 2K跑完一块之后只把总结交给下一块。滑动窗口做多轮对话也是这个思路。对话历史按“近期窗口 远期摘要”两层管理最近的 3 轮完整保留3 轮之前的内容每 5 轮压缩成一段摘要摘要又可以在更早的时间段再压缩。这就是多层摘要树成本极低但效果非常好。我实测的对比数据可以参考处理 5000 行日志文件一次性全部塞进 32K 窗口的 Qwen3.5-9B分析耗时 42 秒漏掉了 3 处关键异常切成 500 行为一块逐块分析并汇总耗时 55 秒但 5 处异常全找到了。多花的 13 秒换来了准确率的大幅提升非常划算。还有一个技巧是“先总后分”。让模型先对长文本做全局摘要再把摘要作为上下文背景指引模型定位具体细节。这种方式短时间内不会让模型记住所有细节但它会用“摘要找位置再插入原文”的方式做事比我之前直接硬怼全文好用很多。3.3 1M 上下文到底该怎么理解最近“1M 上下文全量可用”这个说法挺火很多人以为模型能看 100 万 token 了就直接往上下文里灌海量数据。但 1M 上下文不是让你把整个知识库塞进提示词它真正的意义在于你的检索系统可以更大胆地召回你的 Agent 可以保留更完整的会话历史你的代码仓库可以进行全仓分析。在 Qwen3.5-9B 上跑 1M 上下文现实点说这不是开个参数就能搞定的事。1M token 的 KV Cache 在 9B 模型上大约需要 100GB 以上显存单卡是别想了多卡并行和分页 KV Cache 是必然路线。就算跑起来了推理速度也会降到令人崩溃的程度实用性大打折扣。所以“1M 上下文已经全量可用”这种消息我认为更合理的理解是它代表极少数大模型服务能在后台支撑 1M token 的输入而绝大多数用户设备上的 9B 模型最佳实践还是“长文档分段 摘要 检索”。这是两条不同的路线——服务端可以堆算力本地部署就得靠上下文工程。好在你并不需要一直维持 1M 上下文。上下文窗口最大的应用价值是让你“能处理大输入”而不是让你“每次都用满”。熟悉这个边界你才知道什么时候该走全量、什么时候走检索增强。3.4 上下文轮次与 token 预算管理多轮对话中上下文长度是逐步增长的。我习惯给每次会话设置“token 预算”比如总范围是 32K我预留 4K 给当前问题预留 4K 给输出那么历史检索指令的总空间只有 24K。每次对话结束后计算当前历史 token 数一旦超过 24K就触发压缩逻辑。可以用 tokenizer 的count_tokens来精确计算长度而不是凭感觉。我用的是优先丢弃的排序先丢工具的原始返回再丢最旧的 few-shot 示例然后丢对话历史中的中间轮次最后才动系统提示词。因为系统提示词里往往有业务最重要的全局规则动不动它整个任务的基座就塌了。这里有个小细节很多框架本身有“自动丢弃最早历史”的逻辑比如只保留最近 N 轮。但这样做很粗糙——某轮对话里可能包含一次用户的详细需求描述即使是很早的也需要保留到任务结束。所以我会给消息打标签哪些消息“可丢”哪些“必须保留”在压缩时按标签选择性处理。4. 多智能体场景上下文变量与数据流分解4.1 上下文变量跨 agent 的数据纽带聊到多智能体框架像最近很火的 Swarm 框架会频繁出现 agent、handoff 和上下文变量这套概念。很多人把它理解成“让多个 AI 互相聊天”但对用过的人应该能体会到核心根本不是聊天而是数据与任务在不同智能体之间正确交接。Swarm 里每个 agent 有自己的 instructions 和 functions。handoff 操作把对话控制权从一个 agent 转移到另一个 agent而上下文变量则是存储在会话层级的一组键值对可以被多个 agent 读取和写入。我刚开始用这类框架时踩的坑是把上下文变量和对话历史搞混了。对话历史是每一轮模型的输入输出消息上下文变量则是独立于消息流的业务数据比如 userId、当前订单号、已确认的配件清单、上次 agent 计算出的中间结果。两者是平行关系但很多人在设计时把业务状态写进对话消息导致上下文又长又乱。一个恰当的做法是上下文变量就像一张“共享便签”谁都能读但只有负责某个环节的 agent 才能更新特定字段。这样即使主控 agent 切到了另一个 agent当前状态也不会丢失。4.2 上下文数据流图分解的实用价值把上下文数据流图分解开其实是做好多智能体上下文管理的第一步。我自己的画法是输入侧、处理侧、输出侧三层。输入侧包括用户当前请求、上下文变量、会话历史摘要、RAG 召回结果。处理侧则是各 agent 的执行逻辑哪个 agent 先处理哪个 agent 调工具哪个 agent 决定 handoff。输出侧包括最终回复、要更新回上下文变量的数据、要追加到会话历史的记录。这个分解的意义在于你能清楚看出每个 agent 看到的是“全量上下文”还是“子集上下文”。默认框架会把完整上下文传给每个 agent但实际应用中我强烈建议按 agent 职责裁剪上下文。负责订单查询的 agent不需要看到之前 30 轮关于天气闲聊的记录负责代码生成的 agent也不需要看到客服领域知识库的检索结果。比如我搭过一个售后工单系统主 agent 负责分配任务工单 agent 负责查历史工单库存 agent 负责查备件。如果每个 agent 都带着完整上下文不仅 token 浪费还会出现“库存 agent 因为太长的对话历史而答串了”的情况。裁剪之后每个 agent 的上下文从 18K 降到 3K正确率提升非常明显。4.3 在 Qwen3.5-9B 上落地多智能体上下文如果你计划在 Qwen3.5-9B 上跑 Swarm 框架有几点实践经验值得参考。第一Qwen3.5-9B 这类中小模型对指令跟随的依赖很强每个 agent 的系统提示词里要写清楚“你的职责、你能调用的工具、哪些上下文变量归你管、哪些不要动”。模糊的 instructions 在大模型上可能没事在 9B 上就会看见 agent 胡乱动用别人的变量。第二变量值要尽量结构化比如 JSON 对象而不是一段自然语言。结构化数据 token 开销小也更容易被模型精确引用。在 Swarm 里可以给context_variables里放一个嵌套字典每个子字典对应一个模块的状态。第三handoff 后上下文不要删但可以按“作用域”缩窄。我会用一个小函数把传给每个 agent 的上下文过滤一遍只保留该 agent 声明的变量键名这样既保留状态又不超载。上下文类型示例可见范围管理策略用户全局变量用户ID、等级、偏好所有 agent 可读写只追加、不覆盖保持稳定任务局部变量当前工单号、诊断结果同一任务链的 agent任务结束即清理会话临时变量中间计算、候选结果单个 agent 内有效不 handoff不跨 agent只读变量商品信息、库存快照所有 agent 可读由独立服务刷新模型不修改这个表好不好用我验证过很多次。不少多智能体应用跑偏都是因为“全局变量”和“局部变量”的边界模糊结果所有 agent 都把临时数据往全局塞。5. 常见问题排查与避坑实录5.1 高频问题速查表下面这几个问题是我在 Qwen3.5-9B 系列上真实遇到过高频坑不是理论推演每一个都对应具体现象、原因和最终解决办法。问题现象根本原因解决办法设置 128K 后推理直接 OOMKV Cache 超出显存减小max-model-len启用 PagedAttentionvLLM改用动态 rope scaling 分块处理长文本中间信息被忽略Lost in the Middle 效应重排信息位置关键内容放头和尾分块摘要后再拼接示例越多效果越差示例格式冲突、挤占知识层空间按相似度选 3~5 个格式统一动态更新多轮对话越聊越笨历史按轮次截断关键旧信息被清除给消息打“可丢/必留”标签先压缩工具输出再丢轮次切换平台后旧对话上下文加载不出来上下文存在原环境的服务端新环境没有会话历史导出对话为 JSON导入新环境用 API 接口传history参数重建会话多 agent 协作时变量互相覆盖上下文变量作用域设计混乱按变量分类设定读写权限handoff 前过滤变量子集打开长窗口后生成速度骤降注意力计算量随窗口平方增长 / 显存带宽不够用 FlashAttention 2边缘情况考虑换成“摘要 检索”路线系统提示词被截断后行为异变历史压缩误伤了指令层在压缩优先级里把系统提示词设为最高保留级5.2 切换环境导致上下文加载不出的处理热词里提到过一个很具体的场景用 cc-switch 类似的工具在多账号之间切换切换后之前的对话上下文不能加载。这类问题本质上不是模型的问题而是会话历史存到了原账号/原环境的服务端切换后拿不到旧数据。如果你碰到这种情况我推荐按顺序排查第一步看当前新环境是否支持导入历史对话支持就直接导。第二步没有导出功能时把旧对话整理成 JSON使用 API 里的messages字段重新运行把历史消息完整放入列表再补一句“以上是历史对话请在此基础上继续”。第三步如果拿不到原文就看你自己有没有本地日志有的话可以通过日志恢复。这其实再次验证了上下文管理的核心观点对话历史是你的资产不要只存放在第三方平台的服务器上。我自己的习惯是关键项目定期导出会话存档至少保证文本形式可恢复。5.3 上下文工程不一定非要上重型框架很多人一听到上下文工程就想到要搭 RAG、上向量库、搞多策略路由。但在 9B 模型上有些轻量办法反而解决大部分问题。我举一个实际例子。某次我需要在本地用 Qwen3.5-9B 处理一批合同审阅每个合同 8000~12000 token。如果直接每个合同都塞进一个新的 32K 窗口虽然单条没爆但连续跑几十条之后模型会开始把上一条合同的条款带到下一条里。于是我加了一段 200 token 的固定“审阅规则”作为系统提示词每条合同开头再加一段 80 token 的“合同隔离提醒”明确说“这是新合同与之前的审阅无关”。就这么一句串条款的问题就消失了。这就是上下文工程的实际操作并不复杂但很考验对模型行为的理解。你越了解模型在长上下文下容易犯什么错就越知道怎么写这种“防串话”的内容。5.4 我为上下文窗口设计的预算模板最后分享一个我觉得很实用的模板是我给 32K 窗口的 Qwen3.5-9B 做的默认预算供参考层级内容预算token说明指令层系统提示词1000~2000全局规则压缩优先级最低背景层业务上下文/摘要2000~4000由上次对话打包而成知识层检索结果/文档片段8000~12000可动态调整太多则触发重排示例层few-shot 示例1500~3000固定格式不随意扩充当前轮用户最新消息500~1000始终完整保留输出预算生成内容4000~6000太大则分段生成留白意外余量500~1000防止某层预估偏差这个表用熟了之后你会发现它不只是省 token而是在帮你做决策。比如知识层和示例层打架了你就知道该砍示例而不是砍检索。模型在同一轮里能“想”的东西有限你给它的结构越清晰它表现越稳。我个人在实际操作中的体会是上下文管理的本质不是给模型“塞更多”而是给模型“看得更准”。Qwen3.5-9B 是个性价比很高的模型但它的长文本能力需要你配合才能发挥出来。哪怕你只是普通用户不写代码也必须了解“上下文是会被截断的”这个底层事实知道展示给模型的信息排在哪个位置会影响结果。最后再分享一个小技巧在一次任务快结束时让模型自己在回复里附一段“本轮摘要”我现在几乎所有长流程都会这么做。这段摘要在后续轮次里可以当成历史摘要直接复用省掉一次手动压缩效果还比我自己写的摘要准确得多。所有平台都不缺能做长上下文的模型缺的是会用上下文的操作者希望这篇内容能帮你少踩几个坑。