★ FEATURED ARTICLE 1. Context-Mode给大模型装上可控的“工作记忆”最近在调一个多轮对话应用发现效果忽好忽坏明明模型本身没问题但回答就是不对味。排查到最后问题出在一个词上——上下文。我团队里一个中台同学提了个方案内部代号就叫 context-mode。合作了两周我们把这套模式从一句口号落地成了真能用的工程实践也把上下文这个黑盒翻了个底朝天。这篇文章就是把这段落地过程讲透从核心思路到具体实现再到踩过的坑适合正在做Agent、对话系统或者RAG应用被上下文反复折磨的开发者参考。很多人看到“上下文模式”第一反应是不就是把聊天历史一股脑丢给大模型吗我一开始也是这么想的。但实际跑起来你会发现上下文的管理远不止“塞进去”这么简单——窗口有限、预算有限、顺序有讲究、优先级有差异。context-mode 本质上是一套从业务需求出发、系统化控制大模型输入内容的工作机制目标不是记录所有对话而是在有限的上下文中塞进最该被模型看到的信息。我在某个模拟项目X里需要同时支持资料问答、多轮闲聊和工具调用三种场景对上下文的需求完全不同。资料问答要把长篇文档的核心段落稳稳塞进上下文闲聊要保留足够久的用户偏好工具调用则必须在上下文中维护最新的状态快照。同一个模型、同一个业务三种诉求叠加不做模式隔离就会互相污染。context-mode 就是为这种真实场景设计的把上下文从单一的历史文本升级为一套有结构、有优先级的输入流水线。这篇文章会按照我实际落地的顺序来写先讲设计思路和方案选型再拆一个可运行的实现骨架然后给出一套完整的接入方法最后把我翻车过的几个问题列成清单。不搞那些虚的都是可以直接抄走的方案。2. 上下文管理的核心矛盾与设计思路2.1 无限对话历史与有限窗口的天然冲突大模型的上下文窗口是硬约束哪怕你用的是支持超长上下文的模型窗口也永远是有限的。可业务场景里的对话历史是近乎无限的——用户聊了三个月记录有几十万token你不可能全部塞进去。这个矛盾是 context-mode 存在的第一性原因你真正想要的不是“完整记录”而是“让模型在回答的瞬间拥有足够的信息”。换句话说上下文管理本质上是信息筛选不是信息存储。打个比方上下文窗口就像你的办公桌每次只能摊开有限的资料。你要做的是在每次回答前快速判断桌上该放哪几份文件而不是把整个档案柜搬过来。这个认知看似简单但绝大多数团队都会栽在这里。我见过很多项目上线后模型效果变差不是模型退化而是对话轮次增多、塞入的垃圾信息越来越多真正有用的内容被稀释了。设置了长上下文窗口就万事大吉不是的窗口越长意味着你更要管理因为塞进去的无效内容会直接压低模型对关键信息的注意力占比。2.2 三种常见的上下文组织方式对比在正式设计 context-mode 之前我先对比了市面上常见的几种组织方式方式核心做法优点致命伤全量拼接把所有历史消息拼起来塞入上下文实现简单信息无损失窗口迅速耗尽成本高长尾信息淹没关系滑动窗口截断只保留最近N轮对话实现简单保持时效性早期关键信息全部丢失用户意图无法保持关键信息提取每次从历史中抽取重要内容针对性强节省空间提取逻辑复杂抽错了就全错分区预算管理将窗口按功能区划分片各有预算稳定性高可预测需要提前设计好分区规则我在实际项目中最终选择的是“分区预算管理”为核心框架这也是 context-mode 的核心思想。原因很直接它把不确定性变成了确定性。全量拼接和滑动窗口最大的问题在于你不知道下一轮对话会占用多少空间、丢什么信息、模型会怎么理解。而分区预算管理把窗口当成一块固定大小的硬盘每个分区系统指令、动态指令、记忆摘要、会话历史、工具状态都有明确的容量上限谁超了谁收缩优先级明确行为可以预测。当然纯粹的分区管理也有笨拙的地方——如果某个场景对历史依赖特别强固定预算就不够用了。所以我在落地时结合了动态提取的思路分区优先级固定但每个分区内部的内容会根据用户当前意图动态选择。这就是 context-mode 全貌底层是预算控制系统上层是内容选择器。2.3 设计 context-mode 的四个关键决策真正动手设计时我们做了四个关键决策直接决定了这套模式的可用性。第一个决策是明确上下文分区的默认顺序。在 context-mode 中上下文输入的顺序不是随意的我采用固定顺序系统指令在最前、动态意图指令紧随其后、长期记忆摘要居中、短期对话历史靠后、突发临时信息放最后。这个顺序来自于一个已被验证的经验——LLM 对上下文前部和尾部的关注度天然高于中段。把最重要的指令放在开头把临时的、本轮新增的信息放在尾部中段留给记忆摘要这种容错度较高的内容。第二个决策是确定 Token 预算分配比例。我们用一个基础模型做了测试在支持 8K 上下文的情况下系统指令分配 800、动态指令分配 800、长期记忆分配 1200、短期历史分配 3500、临时内容分配 800、留出 900 作为安全缓冲。这个比例的背后逻辑是短期历史给的是当前对话语境需要相对阔气长期记忆给的是摘要信息密度高需要的空间反而小。第三个决策是内容分区内部采用差异化保留策略。短期对话历史用原始的滑动窗口记忆摘要用定期压缩临时内容用单轮淘汰。这个问题很多产品没想清楚结果把原始历史压缩成摘要后做模糊匹配匹配错了还浑然不知。第四个决策是把上下文组装做成可观测的。我们在工程上给每次请求记录了上下文的实际组成包括各分区占用了多少 token、哪些信息被丢弃了、摘要最近一次更新时间。没有这个可观测性后面调试问题会寸步难行。提示如果你只记住了这一节的一个内容那就记住预算管理这件事。与其苦恼怎么把上下文塞满不如先决定哪个区域放什么各占多少。后面的所有内容都是对这句话的展开。3. 基础数据结构的工程定义与实现3.1 ContextUnit最小的上下文携带单位要对上下文做工程化的管理不能用裸字符串到处传效率太低改一个字段就要把所有调用点翻一遍。我定义了一个最小单位ContextUnit。# context_unit.py from dataclasses import dataclass, field from typing import Any, Optional dataclass class ContextUnit: unit_id: str # 单元唯一标识便于追踪 unit_type: str # 类型instruction / summary / history / state content: str # 实际内容 token_count: int 0 # 预估token数 priority: int 5 # 优先级0-10数值越大越重要 created_at: float 0.0 # 创建时间 expires_at: Optional[float] None # 过期时间 metadata: dict field(default_factorydict) # 额外元信息为什么不用字典dataclass 在类型提示、序列化和代码补全上体验好很多后续如果要加字段只需要在这个类里扩展不用满项目找字典 key。token_count 这个字段值得单说一句它不需要极其精确粗略估算即可。我用的估算方法是字符数除以4中文场景下这个估算偏差在20%以内足够做预算规划了。精确计算交给具体的tokenizer做但那是在组装最终上下文时才执行每次业务调用都做精确计算性能撑不住。3.2 ContextWindow带预算的容器模型有了最小单位之后需要一个容器来管理这些单位。ContextWindow 就是扮演这个角色的类。# context_window.py from collections import OrderedDict class ContextWindow: def __init__(self, hard_budget: int): self.hard_budget hard_budget # 硬性预算上限比如8000 self.units OrderedDict() # 保持插入顺序便于控制输入顺序 def push(self, unit: ContextUnit): # 简化版直接加入 self.units[unit.unit_id] unit def remove(self, unit_id: str): if unit_id in self.units: del self.units[unit_id] def current_usage(self) - int: return sum(u.token_count for u in self.units.values()) def is_overflow(self) - bool: return self.current_usage() self.hard_budget这里使用 OrderedDict 是为了保证组装顺序可控。模型看到的上下文顺序就是输入顺序所以容器的顺序特性必须保留。如果你用的是普通 dict在 Python 3.7 里插入顺序其实也能保证但 OrderedDict 更显式语义更清晰。hard_budget 是硬上限这个预算必须留出至少 10% 的余量。为什么因为你估算的 token 数和模型实际 tokenizer 计算的结果有偏差加上模型有时候会在生成时预留额外空间如果每次都用满预算很容易触发400错误或者生成中途截断。我在项目里 8K 窗口实际配置的 hard_budget 是7200留了800余量稳定跑了两周没有触发过截断。3.3 预算分配器如何落地有了容器下一步是预算分配。这块是整个 context-mode 最容易写乱的部分。我的做法是先定义一个分配表然后按配额生成各分区。# budget_allocator.py from typing import Dict class BudgetAllocator: def __init__(self, total_budget: int, ratio_config: Dict[str, float]): self.total_budget total_budget self.ratio_config ratio_config def allocate(self) - Dict[str, int]: base int(self.total_budget * 0.9) # 预留10%缓冲 result {} total_ratio sum(self.ratio_config.values()) for name, ratio in self.ratio_config.items(): result[name] int(base * ratio / total_ratio) return result # 使用示例 config { system: 0.1, # 系统指令 dynamic: 0.1, # 动态指令 summary: 0.15, # 长期记忆摘要 history: 0.45, # 短期对话历史 temp: 0.2 # 临时信息 } allocator BudgetAllocator(8000, config) quota allocator.allocate() print(quota) # 输出示例{system: 720, dynamic: 720, summary: 1080, history: 3240, temp: 1440}基于比例分配的好处是后面如果要升级到更大上下文窗口比如从 8K 升到 128K只需要改 total_budget不用重新规划各分区的绝对值。这个决策在后来模型版本升级时帮我省了整整一个下午。不过也要提醒一句比例配置是个粗略起点不是终点。实际业务跑一段时间后你要根据每个分区的溢出频率来微调比例。比如历史分区经常溢出但摘要分区经常空着那就要把 history 的 ratio 调高、summary 调低。我把这个微调过程做成了一个配置文件每次调整都能审计。4. 核心机制Summary记忆压缩与历史滑窗4.1 为什么要压缩记忆而不是保留原文我一开始天真的想法是既然模型支持长上下文那我就不压缩了把所有历史直接塞进去。结果上线测试时发现对话超过20轮之后模型开始重复用户的问题甚至把早期对话中的错误信息当成当前事实来用。原因我在第2节说过信息被稀释。但具体机制比我想象的更底层——Attention机制对长文本的注意力分布天然不均中间位置的信息常常被忽略。与其依赖模型的这种不稳定性不如我先把历史压缩成高密度的摘要再塞进去。这就好比人类开会时比起翻三个月的聊天记录一张写满要点的速记卡更有用。模型也一样给它一份高质量摘要比给它一堆原始记录更可靠。4.2 层次化摘要的实现方案我采用的方案是层次化摘要先对单轮对话生成摘要然后定期将多轮单轮摘要合并成更大粒度的摘要。为了避免每次都把全部历史重新处理只是增量更新摘要。# summarizer.py class HierarchicalSummarizer: def __init__(self, llm_func, max_summary_tokens: int 800): self.llm_func llm_func self.max_summary_tokens max_summary_tokens self.round_summaries [] # 每轮摘要 def summarize_new_round(self, user_msg: str, assistant_msg: str) - str: # 单轮摘要保留核心事实、用户偏好、未完成事项 prompt f请总结这轮对话保留以下信息 1. 用户的关键事实信息如姓名、偏好、目标 2. 待办事项和未完成的任务 3. 重要的时间节点 用户消息{user_msg} 助手回复{assistant_msg} summary self.llm_func(prompt, max_tokens150) self.round_summaries.append(summary) return summary def merge_summaries(self) - str: # 批量合并控制总量 if len(self.round_summaries) 10: recent self.round_summaries[-10:] old self.round_summaries[:-10] old_merged self.llm_func( f合并以下对话摘要为一段话保留事实、偏好与待办\n \n.join(old), max_tokensself.max_summary_tokens ) self.round_summaries [old_merged] recent return \n.join(self.round_summaries[-5:])这里面有个细节很多人会忽略摘要不是“越短越好”。摘要的价值在于保留决策相关的事实。比如“用户喜欢喝美式”是很重要的偏好但如果摘要压缩后变成了“用户今天点了咖啡”这个信息就废了。所以在设计摘要prompt时我把用户偏好、待办事项、时间节点单独列为必保留项这是用血泪换来的经验。另一个细节是合并策略——保留最近几轮的原生对话因为最近的信息往往最相关而把更早的历史逐步合并到摘要中。这算是一种两层记忆近期用原文保证精度远期用摘要保证覆盖。4.3 历史滑窗的取舍与参数选择与摘要互补的是短期历史滑窗。滑窗逻辑简单但参数选择有讲究。我在项目里采用的默认规则最多保留12轮对话如果超出优先丢弃最早且不包含关键实体如用户偏好、项目代号的消息。这里有个非常重要的优化点不要只按轮数截断而要结合消息重要性标记。我的实现是给每条历史消息打了一个 keep_score规则如下消息中包含用户明确表达的需求词如“我要”“我需要”2消息中包含专有名词如产品名、人名1消息是系统生成的错误提示或失败重试-1消息超过3轮且没有上述特征-2每次触发截断时移除 keep_score 最低的消息而不是直接砍掉最早的消息。这个策略实测下来比纯滑动窗口在连续任务类对话中的成功率提升了约15%虽然不是巨大的飞跃但在不增加额外成本的情况下已经很划算了。4.4 一个完整的上下文组装流程把前面所有模块拼到一起上下文组装流程大概是这样的# assembler.py def assemble_context(user_input: str, state: dict) - list: window ContextWindow(hard_budget8000) allocator BudgetAllocator(8000, config) quota allocator.allocate() # 1. 系统指令 sys_unit ContextUnit( unit_idsystem, unit_typeinstruction, contentload_system_prompt(), token_countestimate_tokens(load_system_prompt()), priority10 ) window.push(sys_unit) # 2. 动态指令基于用户当前意图生成 dynamic_prompt generate_dynamic_instruction(user_input, state) window.push(ContextUnit( unit_iddynamic, unit_typeinstruction, contentdynamic_prompt, token_countestimate_tokens(dynamic_prompt), priority8 )) # 3. 长期摘要分区配额内截断 summary_content get_latest_summary() if estimate_tokens(summary_content) quota[summary] * 0.8: summary_content truncate_to_token_limit(summary_content, quota[summary] * 0.8) window.push(ContextUnit( unit_idsummary, unit_typesummary, contentsummary_content, token_countestimate_tokens(summary_content), priority6 )) # 4. 短期历史滑窗优先级 recent_history select_short_term_history(keep_score_strategyTrue, max_lenquota[history]) for idx, msg in enumerate(recent_history): window.push(ContextUnit( unit_idfhistory_{idx}, unit_typehistory, contentf{msg[role]}: {msg[content]}, token_countmsg[token_count], prioritymsg.get(keep_score, 0) )) # 5. 当前用户输入临时分区 user_unit ContextUnit( unit_idcurrent_input, unit_typestate, contentfuser: {user_input}, token_countestimate_tokens(user_input), priority9 ) window.push(user_unit) # 6. 溢出防护如果仍然超预算按优先级收缩最低分区内容 final_messages enforce_budget(window) return final_messages这段代码的逻辑就是 context-mode 的完整运行时组装顺序固定、各分区配额控制、溢出时按优先级淘汰。这里要特别说一下溢出防护的实现逻辑不直接丢弃 user_input而是在历史分区和摘要分区中递归收缩。为什么因为当前输入是用户本轮的最高意图丢弃它等于让模型“盲答”。每次溢出时先压缩历史再压缩摘要最后才考虑砍掉动态指令。这个优先级顺序我写在代码注释里防止后面接手的人随意改动。我当时没有写这个注释后来同事调整了顺序线上立刻出现了一堆“模型忽略了本轮问题”的工单那是我那周最黑暗的半小时。5. 工具调用与状态注入context-mode 的高级玩法5.1 工具返回结果一份吃空间的大户很多 Agent 应用卡在上下文管理上不是历史太多而是工具返回结果太占地方。比如一次搜索引擎调用返回了5000 token的页面内容模型只需要其中一句话但你为了保险全塞了进去窗口瞬间爆炸。在 context-mode 里增加了一种新的分区类型tool_result专门管理工具返回数据。核心逻辑是先压缩后注入# tool_handler.py def process_tool_result(raw_result: str, tool_type: str, target_tokens: int 500) - str: if estimate_tokens(raw_result) target_tokens: return raw_result if tool_type search: # 搜索场景提取标题摘要高亮片段 prompt f从以下搜索结果中提取与用户问题最相关的3条每条保留标题和关键信息 用户问题{current_query} 搜索结果{raw_result[:6000]} compressed llm_extract(prompt, max_tokenstarget_tokens) return compressed if tool_type database: # 数据库查询转换为结构化描述 prompt f将以下数据库查询结果转成简洁描述保留关键数字和标签 {raw_result[:4000]} compressed llm_extract(prompt, max_tokenstarget_tokens) return compressed # 默认策略截断保留头部 return raw_result[:target_tokens]为什么用 LLM 压缩而不是简单截断因为工具返回结果往往是半结构化文本直接截断可能会把最重要的结论切掉。用 LLM 压缩相当于做了一次信息蒸馏把原始结果中对当前任务最相关的内容提取出来。代价是多一次 LLM 调用耗时大约增加200-400ms但换来的是窗口空间的有效利用和最终的稳定表现这笔账是划算的。5.2 状态感知的注入策略动态指令层context-mode 的另一个高级玩法是动态指令层。静态系统指令告诉你“你是谁”动态指令告诉你“当前是什么情况”。动态指令解决的问题是模型在工具调用多轮之后会忘记当前处于哪一步。比如用户问“帮我查一下明天上午十点的天气”Agent 调用了天气API返回了结果但模型在组织回复时又把明天的日期搞错了。原因就是上下文里堆积了太多中间工具状态模型抓不住重点。动态指令就是在用户输入和系统指令之间插入一条类似“当前时间 2025-06-15目标日期是明日即 2025-06-16仅需汇报天气信息不要扩展建议”的高度结构化指令。实测下来插入这条指令后日期类错误的概率降低了大约三成。这个技巧成本极低收益明显属于典型的“小改动大提升”。动态指令的生成方式有两种规则模板和LLM生成。对于状态简单、字段固定的场景用规则模板就够了对于场景复杂、状态变化多的场景可以用 LLM 生成但要注意把生成 LLM 的输入控制在小范围内否则动态指令生成本身也会成为一个消耗 token 的怪物。我实际采用的是混合方式90%的场景走规则模板只有跨场景切换时才用 LLM 生成一次动态指令。这既保证了速度又保留了灵活性。5.3 时间线与轮次标识帮助模型建立顺序感还有一个很老套但很有效的小技巧在注入历史消息时给每条消息加上时间戳和轮次序号。比如[轮次1 | 09:12:03] 用户我想订一张后天去北京的机票 [轮次1 | 09:12:05] 助手好的请您稍等正在查询航班信息 [轮次2 | 09:15:40] 工具查询到航班3个价格从780到1200元不等 [轮次3 | 09:16:22] 用户帮我选最便宜的加上这些前缀模型对顺序的感知会明显增强尤其是当多个工具结果交错出现时这种显式的轮次标注能减少模型把不同时间点的状态混为一谈的问题。这个方法不改变上下文内容只是加了格式层面的元信息成本为零。但效果很实在尤其是在多工具、多轮次的 Agent 场景下混淆错误真的少了很多。我是在一次看模型日志时发现它把工具顺序搞反了才想到加轮次标识的属于被事故逼出来的优化。6. 常见问题与排查技巧实录6.1 上下文溢出是最常见的翻车现场报错信息就那么几行比如“This models maximum context length is 8192 tokens, however you requested 8500 tokens”。真因往往是预算估算不准确或者某个工具结果没有压缩就注入了。我的排查路径是这样的第一看溢出报错发生前最后一次请求的组装记录确认是哪个分区超了。这需要你在日志里记录每个分区的实际 token 用量这就是第2节说的可观测性价值。第二如果是历史分区超了检查滑窗截断逻辑是否生效。有一种情况是消息的 token_count 估算偏低导致实际用量比预期多得多预算控制失效。第三如果是 tool_result 分区超了检查工具返回内容压缩逻辑是否被跳过。很多时候是异常路径下直接返回了原始结果。排障的核心思路就是不要对着报错猜要看组装链路里哪一步放了过量的内容。我为此专门写了一个小工具输入 request_id 就能拉出那次请求的上下文组装详情90%的溢出问题在10分钟内就能定位。6.2 模型答非所问问题可能出在摘要里如果你的对话历史明明是全的、也没超预算但模型就是“失忆”优先检查摘要。因为摘要一旦产生就会长期驻留上下文如果摘要压缩时丢失了关键约束比如用户强调“不要推荐辣的食物”模型后续就会疯狂推荐火锅而你翻历史又翻不到了——历史早被滑窗丢掉了。这个问题的根源是摘要prompt设计不周全。我在单轮摘要prompt中把“用户限制条件和偏好”单独列为必保留项优先级高于一般事实。排障技巧当你发现模型一直重复某个错误时把当前上下文组装结果打印出来检查摘要里有哪些内容。如果摘要里根本就没出现过用户偏好问题就出在摘要而不是模型。6.3 上下文漂移模型前后矛盾怎么办上下文漂移指的是模型在长对话中逐渐偏离早期设定的行为准则。典型的例子系统指令说“只允许使用已授权的工具”但聊到第30轮模型开始编造不存在的工具。我分析下来的原因是早期系统指令在长历史中被稀释了。修复方案有两个方向一是把系统指令在关键节点重新注入。比如每10轮对话结束时在上下文的临时分区末尾追加一条“提醒请遵守系统指令中关于工具使用范围的限制”。相当于给模型定个闹钟。二是把约束写成动态指令每次组装时都注入。虽然占用了一点预算但效果比只放系统指令稳得多。实测下来动态指令方式的效果更稳定。系统指令适合放长期不变的元信息动态指令适合放当前轮次的约束。不要让一份系统指令承担所有职责这也是 context-mode 分区的思想在约束管理中的延伸。6.4 单独场景调优的两个实用案例案例一文档问答场景上下文的核心压力在文档内容注入。文档太长需要分块检索时如果不做上下文管理每次只想到从向量库返回 top3 片段但 top3 的匹配度和用户问题往往不是最优的。我用 context-mode 的方式先把文档块排序按 token 预算决定注入多少块而不是固定返回 top3。这样在预算分配上更理性答案质量也更稳定。案例二客服多轮对话场景上下文压力在用户画像和历史订单。我把用户画像和最近订单状态做成结构化的 summary每次注入时直接拼接而不是依赖模型从历史消息中自行理解。客服机器人经常需要回答类似“我之前买的XXX还在保修期吗”的问题如果每次都要从历史里翻既浪费预算又容易翻错。把它们提取成摘要后准确率提升明显。这两个案例说明同一个道理context-mode 不是技术花活而是对具体业务场景的信息筛选策略——不同场景需要不同的分区和优先级没有万能的模板。6.5 排查速查表现象优先排查点快捷处理上下文溢出工具返回结果未压缩走 processed_tool_result 压缩后再注入模型失忆摘要质量低或过期检查摘要prompt加入必保留字段模型违反指令系统指令被稀释升级为动态指令每轮注入模型混淆工具状态历史消息缺少轮次标识给消息加时间戳和轮次序号回答越来越差历史分区超配导致垃圾信息堆积调低历史配额调高摘要配额7. 持续运营 context-mode 的三个建议7.1 每次升级模型都要重新测一次预算不同模型的 tokenizer 差异可能很大同一个文本用 A 模型计费是1000 token换到 B 模型可能是1200 token。如果你的预算基于估算值而非实际 tokenizer模型升级后容易出现系统性溢出。我在项目里把上下文组装测试做成了CI流水线的一部分每次模型版本升级自动跑一遍组装测试检查各分区用量是否仍在预算内。项目刚跑到第三个版本这套流水线就抓了两次预算超标问题。7.2 日志里一定要记录上下文组装快照生产环境的问题几乎都是“复现不了”的。因此你必须在请求日志里记下哪个 request_id 用了什么上下文组装结果各分区实际 token 多少。否则出事之后你只能靠猜。具体做法组装完成后把每个单元的 unit_id、token_count、priority 写入日志。不上传完整内容保护隐私但元信息必须完整。排查时能精确还原当时的上下文结构这是所有调优工作的前提。7.3 不要过度设计先跑通最小闭环最后一点是给新手的建议context-mode 的完整体系很丰满但对刚起步的项目来说完全按这套框架来可能反而是负担。最小可行版本只需要三步定义分区、设定预算、实现历史截断。这三步能解决80%的上下文问题。摘要压缩、工具结果蒸馏、动态指令是第二步再考虑的事。我就是从最小版本起步的刚开始只有系统指令和历史滑窗后面遇到具体的摘要问题时才加了层次化摘要遇到工具结果占空间时才加了压缩逻辑。渐进式落地的风险小、收益快每加一个模块都能明显感觉到效果变化。8. 从 context-mode 到上下文成本治理写在最后聊聊我踩过几次坑之后的体会context-mode 表面上是在管理模型输入本质上是在治理信息和成本。一样都是8K窗口装的是高密度摘要还是原始日志回答质量和花费的成本完全是两码事。过去我们总把上下文看成模型的“内存”觉得越多越好但从工程的角度上下文更应该是你的“取舍”——决定给模型看什么同时决定不给模型看什么。前者决定能力上限后者决定稳定性与成本下限。在实际项目中我把 context-mode 的配置做成了一套可调参的档案每个业务场景一个档案。新场景接入时先复制现有档案改参数而不是从零开始这样落地快也便于沉淀最佳实践。如果你也在做一个对话应用或 Agent我建议你从“分区预算管理”这个概念入手哪怕不写代码先把上下文按功能分好类、设好预算你的模型表现就会上一个台阶。这也是我为什么把这些内容写出来的原因——它帮我少走了很多弯路希望也能帮你少踩一些坑。
阅读完成 · 觉得有帮助？
