1. 从标题拆解ContextBuilder 到底在解决什么问题第一次看到“9.3在Hello-Agents中的实践ContextBuilder”这个标题很多人第一反应是——这又是个框架里的工具类跟之前见过的 Prompt 拼接器有什么区别我一开始也这么想直到真正在一个多轮对话项目里被上下文管理折磨了整整两周才回头认真研究了这个模块。ContextBuilder直译过来叫“上下文构建器”但这个名字其实低估了它的价值。它真正做的事情是在一个智能体Agent系统里决定“每一轮对话到底该把哪些信息塞给模型”。这件事听起来简单做起来极其麻烦。你可以把 Agent 想象成一个记忆力有限、但每次开口前都要重新读一遍笔记的助手。笔记太薄它记不住之前聊过什么答非所问笔记太厚它读得慢、成本高还容易被无关信息带偏。ContextBuilder 就是那个负责“整理笔记”的角色——它要在有限的上下文窗口里把系统指令、历史对话、工具调用结果、外部检索内容、当前用户输入等一堆来源不同的信息按照优先级和预算裁剪、排序、组装成最终送给模型的那一段文本。为什么这个模块值得单独拿出来讲因为在实际项目里我见过太多人把上下文管理写成简单的字符串拼接system_prompt history user_input跑 demo 没问题一上真实场景就崩。要么是历史越滚越长直接超了 token 上限报错要么是工具返回的一大段 JSON 把关键指令挤没了要么是多轮对话里模型突然“失忆”忘了三轮前用户明确说过的约束条件。ContextBuilder 存在的意义就是把这些零散的、容易出错的拼接逻辑收敛成一套可配置、可扩展、可测试的构建流程。它适合谁来参考如果你正在做 Agent 相关的开发不管是对话机器人、任务自动化还是 RAG 检索增强只要涉及“多轮”和“多信息源”这个模块的设计思路都值得你花时间吃透。哪怕你不用 Hello-Agents 这个框架它背后的分层构建、预算分配、优先级裁剪的思想你完全可以搬到自己的项目里。接下来我会从整体设计、核心细节、实操落地、问题排查几个角度把这个模块拆开揉碎讲清楚尽量让你看完就能动手改自己的代码。2. 整体设计与思路拆解为什么是“分层预算”而不是“拼接”2.1 上下文管理的本质是一个资源分配问题在深入 ContextBuilder 的具体实现之前得先把一个认知建立起来上下文窗口是一种稀缺资源。现在主流模型的上下文长度从 8K 到 128K 不等看起来很多但你要知道Agent 场景下消耗上下文的速度远超普通对话。一次工具调用可能返回几千 token 的原始数据一轮 RAG 检索可能塞进来五六个文档片段再加上系统指令、few-shot 示例、历史对话很容易就逼近上限。我做过一个粗略的统计在一个中等复杂度的任务型 Agent 里单轮对话平均消耗的 token 中真正“当前用户输入”只占不到 10%剩下 90% 都是历史、工具结果和检索内容。这意味着如果你不做任何裁剪和优先级管理上下文窗口会被大量低价值信息占据模型真正需要关注的核心指令反而被稀释了。ContextBuilder 的设计思路本质上就是把这个资源分配问题显式化。它不假设“所有信息都同等重要”而是引入两个关键机制分层Layer和预算Budget。分层解决“信息从哪来、属于哪一类”的问题预算解决“每一类能分到多少 token”的问题。这两个机制组合起来就把一个模糊的“拼字符串”问题变成了一个可量化、可调控的工程问题。2.2 分层设计把上下文拆成可独立管理的模块ContextBuilder 把上下文来源拆成若干层常见的分层包括系统层System Layer系统指令、角色设定、全局约束。这一层通常优先级最高且内容相对固定不随对话轮次变化。记忆层Memory Layer长期记忆或摘要信息比如对早期对话的压缩总结。这一层解决的是“历史太长放不下”的问题。历史层History Layer最近若干轮的原始对话记录。这一层保证短期连贯性。工具层Tool Layer工具调用的请求和返回结果。这一层的特点是单条内容可能很长但时效性强过期后价值骤降。检索层Retrieval Layer从外部知识库检索到的文档片段。这一层与当前 query 的相关性差异很大需要动态筛选。当前层Current Layer用户本轮输入通常必须完整保留。为什么要分层而不是把所有内容混在一起因为不同层的信息其“生命周期”和“价值衰减曲线”完全不同。系统指令可能整个会话都不变历史对话的价值随轮次递减工具结果只在当轮有效检索片段则高度依赖相关性。如果混在一起统一裁剪你没法针对不同层设置不同的策略。分层之后每一层可以独立配置预算、独立选择裁剪算法、独立决定是否参与构建。我在自己的项目里就吃过没分层的亏。早期版本把所有内容塞进一个列表按时间顺序拼接结果有一次工具返回了一个巨大的 JSON直接把前面三轮的对话历史挤出了窗口模型瞬间“失忆”用户追问之前说过的条件它完全答不上来。后来改成分层管理给工具层单独设了预算上限超出部分做摘要压缩问题才解决。2.3 预算机制给每一层分配 token 配额分层之后下一个问题就是每一层到底能占多少 token这就是预算机制要解决的。ContextBuilder 通常会维护一个总预算对应模型的上下文窗口减去输出预留然后按优先级或配置比例分配给各层。预算分配的策略有几种常见做法策略做法适用场景缺点固定比例每层预设百分比如系统 10%、历史 30%、检索 40%信息源稳定的场景无法应对某层突然膨胀优先级抢占高优先级层先用剩余给低优先级系统指令必须完整的场景低优先级层可能被饿死动态调整根据当前 query 类型动态分配任务类型多变的 Agent实现复杂需要额外判断逻辑混合策略固定保底 动态抢占大多数生产场景参数调优需要经验Hello-Agents 里的 ContextBuilder 我实测下来更接近混合策略系统层和历史层有保底配额检索层和工具层则根据实际内容动态竞争剩余预算。这种设计的好处是既保证了核心指令不被挤掉又给了弹性空间应对突发的大量检索结果。这里有个关键细节预算的单位是 token 而不是字符。很多人图省事按字符数估算结果中文、英文、代码混在一起时误差巨大。一个中文字符大约对应 1.5 到 2 个 token一个英文字符大约 0.25 个 token代码里的符号密度又不一样。ContextBuilder 内部会调用 tokenizer 做精确计数虽然多了一点计算开销但避免了“以为没超、实际超了”的尴尬。我在项目里就遇到过按字符估算导致实际超出 20% 的情况模型直接截断把系统指令的结尾都切掉了输出质量断崖式下跌。2.4 为什么不用现成的 Prompt 模板工具有人可能会问市面上不是有很多 Prompt 模板管理工具吗为什么还要单独搞个 ContextBuilder我的理解是模板工具解决的是“格式”问题ContextBuilder 解决的是“内容选择和资源分配”问题两者不在一个层面。模板工具假设你已经知道要放哪些内容它帮你把变量填进去、把格式排好。但 Agent 场景下真正的难点在于“我不知道该放哪些内容”——历史有 50 轮检索有 20 个片段工具结果有 3 个大 JSON我到底该选哪些、放多少这是模板工具回答不了的。ContextBuilder 的核心价值恰恰在于它内置了选择逻辑和裁剪逻辑把“放什么”这个决策过程工程化了。打个比方模板工具像是一个排版软件你给它文字它帮你排得漂漂亮亮ContextBuilder 像是一个编辑它先帮你从一堆素材里挑出最重要的内容再交给排版。两者配合使用效果最好但缺了编辑这一步排版软件再强也救不了内容过载的问题。3. 核心细节解析与实操要点构建流程的每一步在做什么3.1 构建流程的五个阶段ContextBuilder 的一次完整构建我把它拆成五个阶段每个阶段都有明确的输入输出和注意事项收集Collect从各个来源拉取原始内容。系统指令从配置读历史从会话存储读工具结果从执行记录读检索内容从向量库读。这一步的关键是“全量收集、不做裁剪”先把所有可能用到的内容拿到手。标准化Normalize把不同来源的内容统一成内部表示。比如工具返回的 JSON 要转成可读文本检索片段要带上来源标记历史对话要区分角色。这一步不做裁剪但要做格式统一方便后续处理。计数Count对每一层的内容做 token 计数。这一步是预算分配的依据必须精确。我建议用与目标模型一致的 tokenizer不要用近似估算。裁剪Prune根据预算和优先级对超出配额的内容做裁剪。裁剪策略因层而异历史层通常从最旧的开始丢检索层按相关性分数丢工具层做摘要压缩。组装Assemble把裁剪后的各层内容按预定顺序拼接成最终文本。顺序很重要通常系统指令在最前当前输入在最后中间按记忆、历史、工具、检索排列。这五个阶段里最容易出问题的是裁剪阶段。因为裁剪意味着“主动丢弃信息”而丢弃什么、保留什么直接决定了模型的表现。我见过有项目为了省事裁剪时直接按字符数截断结果把一条完整的工具调用结果从中间切断模型拿到半截 JSON解析直接报错。正确的做法是“按语义单元裁剪”要么整条保留要么整条丢弃或摘要不要从中间切。3.2 历史层的裁剪滑动窗口与摘要的取舍历史层的裁剪是最常被讨论的。最简单的做法是滑动窗口只保留最近 N 轮对话更早的直接丢弃。这种做法实现简单但有个明显问题——如果用户在很早之前给过一个关键约束比如“我所有的金额都用美元计算”滑动窗口一滑这个约束就丢了模型后面就会用错单位。更成熟的做法是“滑动窗口 摘要”。最近 N 轮保留原始对话更早的对话压缩成一段摘要摘要里保留关键事实和约束。ContextBuilder 支持这种模式你需要配置两个参数窗口大小保留多少轮原始对话和摘要触发阈值超过多少轮开始压缩。摘要的生成有两种方式一种是用模型生成质量高但有额外成本一种是用规则提取比如只保留用户明确说过的约束、实体和数字。我在项目里用的是混合方式先用规则提取关键实体和约束再用一个小模型做润色压缩。实测下来摘要能把 20 轮对话压缩到 200 token 以内同时保留 90% 以上的关键信息。注意摘要本身也占预算而且摘要质量直接影响模型表现。如果你的摘要生成得不好宁可多保留几轮原始对话也不要塞一段低质量摘要进去。低质量摘要比没有摘要更糟糕因为它会误导模型。3.3 检索层的裁剪相关性分数不是唯一标准检索层的裁剪看起来简单——按相关性分数排序取前 K 个。但实际做起来有几个坑第一相关性分数不可比。不同检索器、不同 query 下的分数分布不一样今天 0.8 分算高明天 0.8 分可能只是中等。所以不能设一个固定阈值而应该用“相对排名 动态阈值”结合。第二片段之间有冗余。检索回来的前五个片段可能都在讲同一件事只是措辞不同。全塞进去浪费预算还容易让模型重复。ContextBuilder 支持去重逻辑我一般会加一个简单的相似度检测相似度超过阈值的片段只保留分数最高的那个。第三片段长度差异大。一个 50 token 的短片段和一个 500 token 的长片段即使分数相同对预算的消耗也完全不同。所以裁剪时要考虑“性价比”用分数除以长度作为排序依据往往比单纯按分数排更合理。我自己的经验参数是检索层预算占总预算的 30% 到 40%保留片段数控制在 3 到 8 个单个片段长度上限 300 token。超过这个范围要么是检索质量有问题要么是 query 太宽泛需要先做 query 改写。3.4 工具层的处理原始结果与摘要的平衡工具调用是 Agent 区别于普通对话的核心能力但工具返回的结果往往是最“占地方”的。一个数据库查询可能返回几十行记录一个网页抓取可能返回整页 HTML。如果原样塞进上下文几轮下来预算就爆了。ContextBuilder 对工具层的处理我总结为“三步走”结构化提取如果工具返回的是 JSON先解析出关键字段丢弃元数据和冗余字段。比如一个天气 API 返回了 20 个字段你实际只需要温度、湿度、天气状况三个其余全丢。摘要压缩如果提取后的内容还是太长做摘要。比如查询返回了 50 条记录压缩成“共 50 条前 5 条为……整体趋势是……”。时效标记给工具结果打上时间戳和轮次标记超过一定轮次的结果自动降级或丢弃。因为工具结果通常只在当轮或下一轮有效三轮前的天气查询结果对当前对话基本没用。这里有个实操心得工具结果的摘要最好保留原始数据的“形状”信息。比如一个列表摘要时要说“这是一个包含 50 项的列表”而不是只说“有很多项”。因为模型需要知道数据的结构才能正确决定下一步怎么处理。我见过摘要把列表压成一句话模型以为只有一条记录后续逻辑全错了。3.5 组装顺序的讲究组装顺序看似小事实则影响很大。模型的注意力机制对开头和结尾的内容更敏感中间部分容易被忽略。所以系统指令放最前确保角色设定和全局约束被优先关注。当前用户输入放最后紧挨着模型生成位置确保模型明确知道要回应什么。关键约束可以重复如果某个约束特别重要可以在系统层和当前层各提一次利用首尾效应强化。工具结果和检索内容放中间这些是“参考材料”放中间符合模型“先看指令、再看材料、最后回应”的阅读顺序。我实测过不同顺序对输出质量的影响在同一个任务上把系统指令从开头挪到中间模型违反约束的概率上升了将近一倍。所以顺序这件事不要随意改除非你有明确的实验数据支撑。4. 实操过程与核心环节实现从零搭一个可用的构建流程4.1 环境准备与依赖确认在动手之前先把环境理清楚。ContextBuilder 本身是一个逻辑模块不依赖特定框架但你需要准备几样东西Tokenizer用于精确计数。如果你用的模型有官方 tokenizer优先用官方的没有的话可以用 tiktoken 之类的通用库做近似但要留 10% 到 15% 的余量。会话存储存历史对话可以是内存、Redis 或数据库取决于你的持久化需求。检索接口如果你要用检索层需要一个能返回片段和分数的检索器。摘要模型如果要用摘要功能需要一个小模型或规则引擎。我一般会先写一个配置文件把各层的预算比例、窗口大小、摘要阈值这些参数集中管理避免散落在代码各处。配置大概长这样context_config { total_budget: 8000, output_reserve: 1000, layers: { system: {min_budget: 500, priority: 1}, memory: {min_budget: 300, priority: 2}, history: {min_budget: 1500, priority: 3, window_size: 10}, tool: {min_budget: 500, priority: 4, max_single: 800}, retrieval: {min_budget: 1000, priority: 5, max_items: 8}, current: {min_budget: 500, priority: 0} } }这里的priority数字越小优先级越高min_budget是保底配额实际分配时高优先级层先用剩余预算再按比例分给低优先级层。output_reserve是给模型输出预留的空间不能算进上下文预算否则模型没地方生成回复。4.2 收集阶段的实现细节收集阶段的核心是“全量拉取、标记来源”。我通常会定义一个统一的数据结构class ContextItem: def __init__(self, content, layer, priority, timestamp, metadataNone): self.content content self.layer layer self.priority priority self.timestamp timestamp self.metadata metadata or {} self.token_count None # 延迟计算每一层的内容都包装成ContextItem带上来源标记和时间戳。这样做的好处是后续裁剪时可以统一处理不用为每层写一套逻辑。收集历史对话时注意要按时间正序排列最新的在最后。工具结果要关联到具体的调用轮次方便后续判断时效。检索内容要带上相关性分数和来源 ID去重时用得上。提示收集阶段不要做任何过滤哪怕你直觉觉得某条内容没用。因为过滤决策应该基于预算和优先级而不是直觉。先收集全再统一裁剪逻辑更清晰也更容易调试。4.3 计数与预算分配的代码实现计数阶段的关键是“精确”和“缓存”。同一条内容可能被多次计数比如调试时反复构建所以计数结果要缓存到ContextItem上避免重复计算。def count_tokens(item, tokenizer): if item.token_count is None: item.token_count len(tokenizer.encode(item.content)) return item.token_count预算分配我用的是一种“保底 按比例分剩余”的算法def allocate_budget(items_by_layer, config): total config[total_budget] - config[output_reserve] allocation {} remaining total # 第一轮满足所有层的保底配额 for layer, cfg in config[layers].items(): allocation[layer] min(cfg[min_budget], remaining) remaining - allocation[layer] # 第二轮剩余预算按优先级加权分配 if remaining 0: total_weight sum(1.0 / cfg[priority] for cfg in config[layers].values()) for layer, cfg in config[layers].items(): weight (1.0 / cfg[priority]) / total_weight allocation[layer] int(remaining * weight) return allocation这个算法的逻辑是先保证每层都有基本配额不至于被完全饿死然后把剩余预算按优先级加权分配优先级高的层拿得多。实际项目中你可能需要根据业务特点调整权重公式比如检索密集型的 Agent 给检索层更高权重。4.4 裁剪策略的具体实现裁剪是核心环节我按层分别说明。历史层裁剪从最旧的对话开始逐条累加 token直到达到预算上限。如果启用了摘要超出窗口的对话先压缩成摘要摘要也占历史层预算。def prune_history(history_items, budget, tokenizer): kept [] used 0 for item in reversed(history_items): # 从最新往回 tokens count_tokens(item, tokenizer) if used tokens budget: kept.insert(0, item) used tokens else: break return kept, used检索层裁剪先按“分数/长度”排序然后逐条累加同时做去重。去重可以用简单的 Jaccard 相似度也可以用向量相似度看你的性能预算。工具层裁剪单条工具结果超过max_single时先尝试结构化提取提取后仍超长则做摘要。摘要保留数据的形状和关键数值。系统层和当前层通常不裁剪但如果系统指令本身超长比如包含大量 few-shot 示例需要把示例部分做成可选的根据剩余预算决定是否加入。4.5 组装与最终校验组装阶段把各层裁剪后的内容按顺序拼接。拼接时要注意分隔符的使用不同层之间用明确的分隔标记比如[系统指令] ... [历史对话] ... [工具结果] ... [检索内容] ... [当前输入] ...分隔符本身也占 token但值得因为它帮助模型区分信息来源。我试过不加分隔符模型经常把检索内容和历史对话混淆输出质量明显下降。组装完成后做一次最终校验总 token 数是否在预算内各层是否都有内容避免某层被完全裁空导致信息缺失关键约束是否还在。如果校验不通过需要回退到裁剪阶段调整参数而不是硬塞。5. 常见问题与排查技巧实录踩过的坑和填坑方法5.1 模型“失忆”的三种典型表现与定位模型失忆是上下文管理最常被抱怨的问题但“失忆”其实分三种原因和解决方法完全不同表现可能原因排查方法解决方向忘记早期约束历史层裁剪把约束丢了打印裁剪后的历史检查约束是否还在把约束提升到系统层或记忆层忘记上一轮工具结果工具层时效标记太激进检查工具结果的轮次标记放宽时效阈值或做摘要保留忘记检索到的信息检索层预算被挤占查看各层实际分配预算提高检索层保底配额我遇到最多的是第一种。用户在第一轮说“所有输出用 JSON 格式”聊了十轮之后模型开始输出普通文本。原因就是历史层滑动窗口把第一轮滑掉了。解决方法很简单把这类全局约束提取出来放到系统层系统层不参与滑动裁剪。这个改动之后类似问题再没出现过。5.2 Token 计数不准导致的截断问题Token 计数不准是个隐蔽但致命的问题。表现是你以为没超预算实际超了模型端直接截断而且截断位置不可控可能把关键指令切掉。排查方法在组装完成后用目标模型的 tokenizer 做一次精确计数和你的预算对比。如果差异超过 5%说明你的计数方法有问题。常见原因包括用了不同模型的 tokenizer比如用 GPT 的 tokenizer 估算 Claude 的没算分隔符和特殊标记的 token中文和代码混合时估算偏差大解决方法统一用目标模型的 tokenizer把所有内容包括分隔符都纳入计数留 10% 的安全余量。如果目标模型没有公开 tokenizer用通用 tokenizer 估算后乘以 1.15 的系数。5.3 检索内容相关性高但答案质量差的怪象有时候检索回来的片段相关性分数很高但模型就是答不好。这种情况我遇到过几次原因通常是第一片段太碎。检索器把一篇文章切成了很多小片段每个片段单独看都相关但缺少上下文模型拼不起来。解决方法是给片段加上前后文或者用更大的切分粒度。第二片段之间矛盾。不同来源的片段说法不一致模型不知道该信哪个。解决方法是在片段上标注来源和可信度让模型自己判断或者在检索阶段做一致性过滤。第三片段太长且重点不突出。一个 500 token 的片段关键信息可能只在中间一句话。解决方法是做片段内的关键句提取把最相关的句子标出来。我一般的处理流程是检索回来后先做一轮“片段质量检查”太碎的合并矛盾的标记太长的提取关键句然后再进入 ContextBuilder 的裁剪流程。这一步额外花的时间远比模型答错后重新检索要划算。5.4 预算分配参数的调优经验预算分配参数没有万能值需要根据你的场景调。我总结了一个调优顺序先保证系统层和当前层这两层是刚需预算给足不要省。再调历史层窗口从 10 轮开始试看模型在多轮对话中的表现逐步调整。然后调检索层检索密集的场景给 40%对话为主的给 20%。最后调工具层工具结果通常可以压缩预算可以给少一点但单条上限要设好。调优时建议做 A/B 测试固定其他参数只调一个观察输出质量变化。我一般用 20 到 30 个测试用例做一轮评估看关键指标约束遵守率、答案准确率、平均 token 消耗的变化。不要凭感觉调感觉往往不准。注意预算调优是个持续过程随着你的 Agent 功能增加、用户使用模式变化最优参数也会变。建议把参数配置化并记录每次调整的效果形成自己的调优日志。5.5 常见问题速查表问题快速排查应急处理模型答非所问检查当前层是否完整保留确保当前输入不被裁剪输出格式错误检查系统层格式指令是否还在把格式指令提到系统层最前响应变慢检查总 token 是否接近上限临时降低检索层预算工具调用失败检查工具结果是否被截断提高工具层单条上限多轮后质量下降检查历史层摘要质量暂时关闭摘要保留原始对话检索内容被忽略检查检索层位置是否太靠前把检索内容移到历史之后这张表是我从多次线上问题中总结的基本覆盖了 80% 的常见故障。遇到问题时先查表能快速定位方向再深入排查。6. 进阶扩展让 ContextBuilder 更贴合你的业务6.1 按任务类型动态切换构建策略固定一套预算参数很难同时服务好所有任务。比如闲聊场景历史层权重要高问答场景检索层权重要高任务执行场景工具层权重要高。ContextBuilder 支持在构建前根据任务类型切换配置。实现方式是在收集阶段先做一次轻量分类判断当前 query 属于哪类任务然后加载对应的预算配置。分类可以用规则关键词匹配或小模型意图识别。我用的是规则加置信度判断规则命中且置信度高直接切换置信度低用默认配置。这个改动让我的 Agent 在不同任务上的表现都提升了一截尤其是任务执行场景工具结果不再被历史对话挤掉成功率明显上升。6.2 上下文压缩的更多可能性除了摘要还有几种压缩思路值得尝试实体替换把长实体名替换成短代号比如“某公司的年度财务报告”替换成“报告A”在系统层维护映射表。结构化压缩把自然语言历史转成结构化的事件列表只保留动作、对象、结果。向量化记忆把历史对话向量化存储需要时按相关性检索而不是全量保留。这些方法各有适用场景实体替换适合实体密集的领域结构化压缩适合任务型对话向量化记忆适合超长会话。我目前用的是摘要加实体替换的组合在保持质量的同时把历史层 token 消耗降低了约 40%。6.3 监控与持续优化ContextBuilder 上线后监控不能少。我一般会记录几个关键指标每轮构建的总 token 数和各层 token 分布裁剪触发次数和裁剪掉的内容量模型输出质量评分人工或自动用户反馈点赞、点踩、追问次数这些数据积累一段时间后就能看出预算分配是否合理、哪一层经常被裁、哪些内容裁了之后模型表现下降。基于数据调参比凭感觉调参靠谱得多。我在一个项目里通过监控发现检索层有 30% 的预算被低分片段占用调整排序策略后同样预算下答案准确率提升了 15%。6.4 与其他模块的协作ContextBuilder 不是孤立的它和 Agent 的其他模块有紧密协作与规划模块规划模块决定下一步做什么ContextBuilder 决定给模型看什么。两者需要对齐比如规划模块说“需要查数据库”ContextBuilder 就要确保数据库 schema 信息在上下文里。与记忆模块记忆模块负责长期存储ContextBuilder 负责短期组装。记忆模块的检索接口要能返回带分数的片段方便 ContextBuilder 裁剪。与工具模块工具模块返回的结果格式直接影响 ContextBuilder 的压缩效果。如果工具返回结构清晰、字段精简压缩就轻松如果返回一大坨非结构化文本压缩就费劲。所以工具设计时就要考虑上下文友好性。我在项目里推动过一次工具返回格式的改造把几个高频工具的返回从“全量字段”改成“核心字段 可选扩展”ContextBuilder 的处理时间减少了近一半上下文利用率也提高了。7. 我个人的实操体会ContextBuilder 这个模块我前后迭代了三个大版本。第一版是简单的字符串拼接跑 demo 够用一上真实场景就各种问题。第二版加了分层和预算稳定性上来了但参数调优很痛苦经常顾此失彼。第三版加了动态策略和监控才算真正好用。最大的体会是上下文管理没有“一劳永逸”的配置它是一个需要持续观察和调整的过程。你的用户会变、任务会变、模型会升级任何固定参数都会过时。所以与其追求一个“最优配置”不如建立一套“可观测、可调整”的机制让 ContextBuilder 能随着业务一起进化。另外一个小技巧在开发阶段把每次构建的上下文完整打印出来人工读一遍。你会惊讶地发现很多问题——比如某层内容重复出现、某条关键信息被裁掉、分隔符用错导致模型混淆。这些问题是自动化测试很难覆盖的但人工读一遍就能发现。我到现在还保持着每周抽几条线上请求把上下文打出来读一读的习惯每次都能找到可以改进的地方。