Context Engineering 范式

• 区分 Prompt Engineering 与 Context Engineering 的范畴
• 理解上下文（信息选择、组织、压缩）与提示词（指令表达）的协同关系
• 认识到模型能力的发挥受上下文质量的硬约束

Context Engineering 与 Prompt Engineering 的边界并不在于"谁的文本写得好"，而在于分工不同：Prompt Engineering 聚焦"如何把指令表达清楚"，即用词、格式、few-shot、chain-of-thought 等，让模型理解任务要什么；Context Engineering 聚焦"给模型喂什么信息、以什么顺序、保留多少、压缩哪些"，即系统规则、任务状态、知识证据、工具结果、记忆的选择、排序、压缩与隔离。之所以上下文质量常决定能力上限，是因为模型的阅读和推理能力是有限的，无论提示词写得再漂亮，只要窗口里的关键信息缺失、被埋没在噪声中、或顺序不合理，模型就拿不到做对任务所需的证据。提示词只是"方向盘"，上下文才是"油箱"，两者需要配合，且后者往往更先是瓶颈。

一个常见的误区是遇到效果差就堆提示词，但实际上很多失败是因为关键事实没进上下文，或进了但被淹没。工程上应把"信息层"和"指令层"分开治理：先做上下文评估（哪些信息用了、哪些没用），再优化指令表达。这样能更系统地定位问题，也避免把上下文问题误判为提示词问题。

• 按信息类型划分上下文的不同"区"
• 理解各类信息的优先级与稳定-动态差异
• 掌握压缩、隔离的手段（KV Cache、命名空间、遮挡）

对五类信息采取"分类治理"：系统规则属于稳定、高优先级、应常驻且很少被覆盖的内容，应放在最前并尽量保持字节稳定以命中 Prompt Cache；任务状态属于动态但必须准确的部分，应结构化、可增量更新，避免用自然语言反复复述；知识证据属于按需注入的部分，应通过检索决定放哪些、何时放，并附来源；工具结果属于临时性强、占用大、可信度待验证的内容，应压缩、去重并标记是否可信；记忆属于跨会话、需分层隔离的内容，应区分用户明示事实、Agent 推断与会话衍生上下文，设独立命名空间防串味。排序总原则是"稳定在前、动态在后、高价值优先、大块降噪"；压缩是丢掉无关细节保留关键承诺与实体；隔离是用命名空间/遮罩/权限分隔不同用户或敏感域。

分层的关键是认识到不同信息对模型行为的约束力不同：系统规则与个人事实对回答起"硬约束"作用，若被长对话或工具结果稀释，就容易发生指令被覆写或事实串味。把信息按"稳定性×价值×体积"三个维度分区，是 Context Engineering 的通用方法论。

• 理解 Note-Taking 模式（Agent 显式维护结构化工作笔记）
• 区分"工作摘要"与"长期事实"两种状态
• 掌握事实校验与晋升机制

Note-Taking 模式让 Agent 在工作过程中显式维护一份结构化笔记（如 JSON 或 Markdown），记录当前任务状态、已完成步骤、待办、关键结论与引用，而不是把整段对话反复塞进上下文。这样既能保持状态新鲜，又能显著压缩上下文。防止未经验证的笔记变成长期事实，关键是引入"暂存-校验-晋升"机制：笔记中的内容默认是"工作草稿"状态，只有经过外部验证（如工具返回、用户确认、权威来源核对）或明确标注为"已确认"后才晋升为长期事实；同时给笔记打上来源、时间戳和置信度标记，并允许后续各轮引用时校验来源，避免把 Agent 自己的推断当成事实。

风险在于 Agent 会"自我强化"——它先写下某条推断，后续轮次又把这条推断当作事实依据，形成循环污染。暂存/晋升机制从状态机层面切断这条回路，让"事实"必须有外部锚点，这是 Note-Taking 模式工程化的关键。

• 区分三种机制的定位：RAG=检索被动知识、Function Calling=调用外部能力、Tool-Augmented=把工具结果注入上下文
• 理解三者的协作与优先级
• 掌握决策顺序（先背景查询、再按需检索、再工具调用）

三者边界：RAG 是从向量库/文档库检索"被动的、预先存在的知识"注入上下文；Function Calling 是让模型调用外部函数/API 获取"实时、动作性的能力"，如查库存、下单、执行运算；Tool-Augmented 上下文是指把工具返回的结果有组织地写回上下文，供后续推理使用，它更像是一种"结果回收"机制而不是独立的信息源。三者同时存在时，可按"先背景、后证据、再动作"的顺序决策：先判断是否需要检索背景知识（RAG），再决定是否需要实时数据或动作（Function Calling），最后把工具结果作为 Tool-Augmented 上下文回收并校验。优先级上，事件驱动链条通常为"识别意图→检索补充→调用工具→结果回注"，避免先在上下文硬塞大量静态知识再决定动作。

边界不清最容易导致"重复检索"或"检索与工具矛盾"。区分的关键词是：RAG 回答"我该知道什么"，Function Calling 回答"我要做什么并获得什么"，Tool-Augmented 回答"我如何把做过的结果用起来"。决策顺序本质是控制信息流，避免上下文膨胀和结果冲突。

• 理解 File-Based 模式（把大块数据落到文件，窗口只留引用）
• 掌握文件命名、版本化与清理策略
• 避免上下文膨胀与孤儿文件

File-Based 模式把大型中间产物（如长文档、表格、日志、生成的大段代码）写入磁盘或对象存储，模型的上下文里只保留文件路径、摘要和关键引用，需要时再按路径读取。这样窗口只装"指针+摘要"，体积大幅下降。文件命名应采用可读且有语义的约定，如 {任务ID}-{类型}-{时间戳}.{ext}，并带上版本号区分同一产物的不同草案；版本管理可通过递增后缀或独立版本目录实现，必要时保留终稿与回滚指针。清理策略要按生命周期定义：临时产物在处理完成后删除、中间产物按保留期归档、最终产物才长期保留，并配合定时任务扫描过期文件，避免"孤儿文件"堆积和磁盘膨胀。

移出窗口的核心收益是"窗口只存引用，不存内容"，代价是"读取时要有延迟"。因此命名、版本、清理就是一个"可寻址性"工程：命名保证可定位，版本保证可回溯，清理保证不失控。典型的"孤儿文件"是任务失败后残留的临时文件，需要可观测的清理机制兜底。

• 理解按需/惰性读取（lazy load）策略
• 认识工具结果的体积与可信度风险
• 掌握 Token 预算与不可信输入缓解

Tool-Augmented 上下文采用"按需读取"（lazy load）：只有当推理确实需要某块数据时才通过工具抓取并注入上下文，而不是一次性把所有可能用到的数据全读进来。读取前先评估所需字段、裁剪列、限制返回条数，并对结果做压缩后再写入。工具结果仍需预算处理的理由是：工具返回可能非常大（如 10 万行日志），直接塞入会立刻耗尽上下文；同时工具结果来自外部，属于不可信输入，可能包含注入指令、恶意文本或格式错误。因此要设 Token 预算上限（如结果超过预算则截断/摘要/抽样），并对工具结果做不可信输入处理——剥离可能被当作指令的文本、转义、限制长度、绝不直接执行工具返回的命令。

"按需"与"预算"是同一枚硬币：按需避免读得太多，预算限制读得下去。不可信输入处理则是安全底线，因为工具返回内容会和我们的指令混在同一个上下文里，若把工具输出当可信命令执行，就会形成提示注入缺口。

• 理解按需检索（Just-in-Time）触发时机
• 掌握检索内容的选择标准
• 明确停止条件与兜底策略

Just-in-Time Retrieval 的核心是"在需要时才检索"，避免一开始就把所有知识灌进窗口。何时检索：当模型在当前上下文中对某主题缺乏足够信息、出现不确定性或需要事实锚点时触发，而不是在任务开头盲目全量检索。检索什么：根据当前问题解析出检索意图与关键实体，选择相关来源、限定时间范围与字段，返回最相关的 top-k 片段而非全文档。何时停止：当已获得足够证据支撑回答、置信度达到阈值、或达到检索预算上限（次数/时间/Token）时停止；若预算耗尽仍不足，则进入兜底，如明确告知"信息不足"、给出基于已有信息的保守回答或请求用户补充，而不是无限检索或编造。

检索本身是"带成本的动作"（延迟+Token+可能的错误），所以必须是"Minimal Sufficient"：够用就停。停止阈值是工程调参点，既要避免"检索不足导致瞎编"，也要避免"检索过度导致冗余与高延迟"。把"何时停"显式化，是 Just-in-Time 区别于普通 RAG 的关键。

• 区分"中间状态"与"最终答案"
• 理解草稿沉淀的时机
• 掌握事实校验的手段

当结论是"过程的中间产物"——即为了后续推理而保存的临时状态、待核实的假设、或需要跨回合复用的中间值——应写回 Note-Taking 草稿，而不是直接作为最终回答输出。判断标准是：该信息是否只是"推导过程中的一步"而非"最终要交付给用户的结果"。直接输出会污染最终回答、且无法在后续回合复用。事实校验应分层进行：对数值/事实类结论，用工具或权威来源交叉核对；对推断类结论，标注"推测"并说明依据；对用户相关事实，需用户确认后才晋升为长期事实；校验结果要回写标记（verified/unverified），并记录来源与时间，供后续引用时判断可信度。

核心是把"写回草稿"与"生成回答"解耦：草稿是 Agent 私有的工作记忆，回答是面向用户的交付物。事实校验则是防止草稿状态被误当事实用于最终回答的"闸门"。校验失败就留在草稿并标注，不晋升。

• 明确压缩的"保留清单"
• 区分"截断"与"压缩"
• 理解可回溯性要求

压缩的目标不是"删到最短"，而是"保留下足够支撑后续任务的信息"。必须保留：承诺/约定（用户提出过什么要求、Agent 承诺过什么，如"我会检查你发的文件"）；关键实体（人名、公司、产品、ID、日期等做后续判断的锚点）；未完成任务（to-do、待办、pending 项）；引用与来源（证据来自哪个文档/工具/时间，便于回溯）；以及关键决策与结论。压缩后应保留"原文指针"——即每条摘要或结论能对应回原始上下文位置，方便需要时回查原文。这比简单截断（直接丢掉后半段）更稳健，因为截断会破坏承诺与任务连续性。

简单截断的致命问题是"有损无索引"——丢掉的恰好是完成任务的承诺与待办。有效压缩是"有损但有索引"：丢掉细节，但保留结构化事实与指向原文的引用。前者是暴力，后者是工程。

• 明确停止检索的触发条件
• 区分两种失败场景的兜底
• 掌握阈值与回退设计

停止检索的触发条件包括：证据充分（已获得足以支撑可靠回答的信息）、达到置信度阈值（模型对答案的把握足以交付）、或达到检索预算上限（检索次数/时间/Token 用尽）。兜底分两类：预算耗尽时，不能再发起新检索，退化为"基于已有信息做保守回答"，并明确告知用户信息可能不完整，而不是继续耗尽预算或编造；置信度不足时，即使预算未耗尽，也应停止盲目检索，转而通过"澄清问题"（反问用户补充信息）、"降低语气"（给出带不确定性的回答）或"显式失效声明"（说明无法确定）来处理，而不是强行给出看似确定的答案。

预算耗尽与置信度不足是两种不同的失败：前者是"资源不够"，后者是"信息不够"。预算耗尽要"止损"，置信度不足要"暴露不确定性"。工程上两者都应有显式信号，避免模型在低置信度下胡编或用尽预算做无意义检索。

• 理解命名空间隔离
• 掌握版本号与并发控制
• 设计清理策略防孤儿文件

命名空间把不同任务、不同 Agent、不同租户的文件隔离到独立目录或前缀，避免彼此不可见或互相覆盖；版本号给同名产物追加递增标识，配合"先写临时文件再原子重命名"或乐观锁（写前校验版本），可避免多 Agent 并发写同一路径时互相覆盖产生脏数据。清理策略分两类：一是按约定生命周期删除过期/临时文件（如任务结束清理临时目录），二是定时扫描"生成后长期未更新且不属于任何活跃任务"的文件——即伪孤儿文件——并删除或归档。同时用"所有权标记"（写入时记录所属任务/Agent）让清理程序能识别文件是否仍被引用，避免误删。

孤儿文件是"不再被引用但未被清理"的残留，多 Agent 写冲突是"并发写同一路径"覆盖。前者靠命名空间+生命周期+所有权扫描解决，后者靠版本号+原子写+锁/乐观并发解决。两者背后都是"可寻址 + 可回收 + 可并发"三个工程属性。

• 定义各类上下文失败的具体症状
• 掌握检测手段（观测、日志、测试）
• 建立失败分类与告警

检测上下文工程失败需要"可观测性 + 针对性测试"。上下文空白：模型回答明显缺失必备信息或答非所问，可通过检查关键实体是否出现在上下文中、输出是否引用了未提供的信息来检测。提示注入污染：工具返回/文档中夹带指令并影响了输出，可通过在上下文中注入"蜜罐标记"（埋入无害却可识别的指令，看模型是否执行）或对输出做指令模式检测。循环重复：模型反复做同一动作/重复同一段话，可通过动作序列去重、检测重复检索调用或重复输出 n-gram。指令被覆写：系统规则被后续长上下文稀释，可通过"关键约束复现率测试"——在上下文末尾注入冲突指令，看模型是否仍遵守系统规则。这些失败检测应沉淀为自动化测试与监控指标，而非依赖人工抽查。

失败检测的前提是把"成功信号"定义清楚：定义了"必须遵守的系统规则"就能测覆写，定义了"必须出现的实体"就能测空白，定义了"唯一动作序列"就能测循环。把上下文失败变成可度量的测试用例，是工程化落地的基础。

• 理解位置偏差（尤其是 Lost-in-the-Middle）
• 掌握显式控制顺序的手段
• 稳定布局以保证可复现

模型对上下文不同位置的敏感度不一致，典型表现是 Lost-in-the-Middle：对窗口开头（primacy）和结尾（recency）的信息利用较好，而埋在中间的信息容易被忽略，这是注意力机制与上下文编码位置的固有特性。中部信息被"淹没"在长段内容中，检索与推理能力下降。显式控制顺序的手段包括：把关键约束与证据放最前（系统 Prompt 区）、按重要性排序、把最相关的证据放在开头或结尾附近、对关键信息重复强调/加粗标记、用检索式证据重组把相关片段提前、以及稳定前缀保证位置稳定。控制顺序的收益是"让模型先看到最重要的"，并让布局可复现、可测试。

位置偏差不是"模型 bug"，而是可用性工程问题：既然知道中间信息容易被忽略，就把高价值信息放到开头/结尾，或通过强调标记补偿。显式控制顺序 = 把"位置"当作一个可调参数来管理。

• 区分三种压缩方式的丢失特征
• 理解压缩的"有损性"
• 设计压缩回归测试

Pruning 直接丢弃低优先级片段，可能丢失"看似无关实则关键"的上下文（如跨段引用、隐式约束）；摘要把内容浓缩，可能丢失细节、精确数字、措辞与原文引用，且摘要本身可能引入模型幻觉；分层把信息按层级组织（如高层摘要+底层细节），可能丢失精细事实或层级间一致性（高层摘要与底层内容矛盾）。三者都是有损的，只是损失模式不同。验证应使用"回归任务"：在压缩前与压缩后跑同一批任务，对比关键指标（关键实体召回率、承诺完成率、指令服从率、答案准确率）；再搭配"关键信息留存测试"——用压缩后的上下文回答"某具体数字/某实体/某承诺"类问题，看是否仍能答对。若压缩后关键指标显著下降，说明压缩损失过大，需调策略。

压缩风险的共性在于"我们不知道哪些细节会在未来被用到"。回归测试的意义是把"压缩是否可信"从主观判断变成可量化指标。重点不是"压缩后上下文短了多少"，而是"压缩后任务成功率掉了多少"。

• 建立多维度选型指标体系
• 理解各指标在业务中的权衡
• 量化对比不同模式

应从四个维度对比：质量维度，包括回答准确率、事实召回率、相关性与一致性；延迟维度，包括首 token 延迟、总响应时间、检索/工具调用带来的额外延迟；成本维度，包括 Token 消耗（输入+输出）、Prompt Cache 命中率、存储与向量索引成本；可审计性维度，包括是否可追溯信息来源、是否可复现、是否有日志与版本记录。选型时不能只看单一指标：例如全量塞入上下文延迟低但成本高、质量受位置影响；RAG 成本低但延迟受检索影响；File-Based 成本低但需额外读取。应结合业务对"质量 vs 延迟 vs 成本"的权重做加权比较，并保证可审计性不牺牲。

选型本质是"多目标权衡"，没有全胜模式。关键是把指标量化并固定评测集，让不同模式在同一数据上可比。可审计性往往被忽略，但在合规场景（医疗、金融）是硬约束。

• 理解笔记生命周期管理
• 掌握过期、淘汰、撤销机制
• 防止错误记忆跨任务污染

笔记需要生命周期管理来防止"错误记忆固化"。过期：给笔记打时间戳和有效期，超过有效期即标记过期，不再默认作为事实使用；淘汰：当笔记被新信息覆盖、或不再相关时，将其降级或移出活动记忆，避免占用上下文与干扰判断；撤销：当发现某条笔记是错误或已被推翻时，显式将其标记为"已撤销/失效"，并更新索引，确保后续检索不会把它拉回来当事实。实现上可给每条笔记加状态字段（active/expired/retracted）、来源与时间戳，并配合"撤销即传播"——撤销时要同步更新依赖它的摘要、Embedding 与派生数据，避免撤销后旧版本仍被检索到。

错误记忆的污染源是"回捞"：即使标记了错误，若检索层仍能把它召回，污染就继续。所以撤销必须"删除+传播"：不仅改状态，还要从索引/Embedding 中失效或更新，防止旧版被重新激活。这是记忆工程与普通缓存的关键区别。

• 明确"策展（curation）"的适用场景
• 设计质量差测量方法
• 权衡策展成本与收益

当上下文窗口有限、信息量大、或大量无关信息会稀释注意力（并推高成本）时，应只把精选信息送入上下文。策展尤其适合：长文档、大量检索结果、或信息含大量噪声的场景。衡量"策展 vs 全量"的质量差，应固定同一评测集，分别用"策展后的精简上下文"和"全量上下文"跑任务，对比准确率、相关性与关键事实召回率，同时统计 Token 成本与延迟差异。若策展后质量下降可接受（在阈值内）而成本/延迟显著下降，则策展值得；若策展丢失关键信息导致质量跌破阈值，则需改进策展策略或回退全量。量化指标应包括"策展误杀率"（被策展丢掉的关键事实占比）。

策展不是"越少越好"，而是"在可接受质量损失内最大化效率"。质量差测量给出决策依据：如果全量只是多花 Token 却不多涨质量，策展就是净收益；反之若全量能显著提质量（如极端长上下文场景），则全量更优。关键是用"误杀率"捕捉策展的隐性损失。

• 理解上下文隔离的粒度
• 掌握片段级遮罩与权限控制
• 防止跨任务/跨 Agent 泄露

多 Agent 共享上下文时，核心是"最小可见 + 片段级隔离"。手段包括：按命名空间/租户划分上下文，不同 Agent 只能访问自己命名空间内的片段；对敏感片段做字段级遮罩（如脱敏姓名、卡号、密钥），使 Agent 看到的是脱敏数据而非明文；对片段打访问控制标签（ACL），写入和读取都校验权限；传递时只传"引用+摘要"而非原始明文，需要时再按权限读取；对输出做脱敏校验，防止 Agent 把敏感片段"带出来"暴露到其他任务。同时要设计"防止跨任务串味"的隔离：任务状态、工具结果、记忆都按任务隔离，禁止默认全局共享。

泄露往往发生在"桥接"环节：Agent A 把 Agent B 的敏感片段带进了自己的上下文或输出。隔离的关键是把"共享"变成"按需、带权限、脱敏"的共享，而不是把敏感信息直接铺进共享栈。脱敏+引用+ACL 三件套是常见实现。

• 理解多语种上下文布局的挑战
• 掌握 Code-Switch 检测方法
• 处理语言边界与语义分裂

需要额外处理。中英混排或多语种长文档中，Token 化、不同语言的语义片段、以及位置偏差会与语言边界叠加，导致模型在跨语言切换时上下文利用不充分，且检索/摘要可能把不同语言的内容搅在一起。处理手段包括：按语言分块组织上下文、保留语言标签与翻译对照、检索时按语言过滤或增加语言字段、对混合文本做语言分段。Code-Switch 检测是指识别一句话中从一个语言切换到另一个语言的边界，常用方法：语言分类模型按 token/短语标注语言；基于字符 n-gram 或词表重合度判定语言；利用语言模型困惑度（perplexity）判断某段属于哪种语言；或用正则/字典匹配常见双语短语。检测结果用于：决定该段用哪种语言处理、检索哪个语言的分片、以及摘要时保持语言一致性。

多语种的核心风险是"语言边界被当作语义边界"或"语义被语言混淆"。Code-Switch 检测是把"语言"维度显式建模，让上下文的分块、检索、摘要都尊重语言边界，而不是把所有文本当单一语言处理。

• 理解"放更多"的局限（成本、位置偏差、稀释）
• 强调信息选择与组织优先
• 建立"质量优先"的工程观

"放更多"是有代价的：长窗口会推高 Token 成本与延迟、放大位置偏差（Lost-in-the-Middle）、用无关内容稀释关键信息，且并不保证相关内容被正确利用。因此上下文工程的核心不是"容量最大化"，而是"信息质量最优化"——先解决"该放什么"（选择：哪些信息真正相关、优先级最高），再解决"怎么放"（组织：顺序、压缩、隔离、强调）。只有把对的信息放到对的位置，模型才"用得到"，否则窗口再大也只是"放得下"。这是一种"以少胜多"的工程观：精准的信息策展胜过无脑的全量填充。

这是一个方向性的纠偏：把"窗口多大"当作手段而非目的。真正的瓶颈是"信息可达性"——相关证据是否被模型有效读取。放更多往往付出成本而得不到收益，甚至让注意力更分散。优先解决"放什么、怎么放"才能把有限窗口用足。

• 设计 A/B 测试框架
• 构建覆盖长尾、跨会话、多语言的评估集
• 控制变量与统计显著性

A/B 测试需要：固定同一任务集与评测指标，只有上下文策略作为变量，其余（模型、温度、评测器）保持一致；用同一输入分别跑策略 A 与策略 B，对比可量化指标（准确率、召回、延迟、成本），并做显著性检验而非凭印象。评估集要刻意覆盖三类场景：长尾（罕见意图、低频实体、极端输入，避免只测高频典型样本）；跨会话（多轮、跨 session 的上下文继承与记忆，验证状态是否延续）；多语言（中英、多语种混排，验证语言边界与 Code-Switch 处理）。具体做法：按比例分层抽样，确保长尾与多语言样本占比达标；构造跨会话用例（session 1 建立事实，session 2 验证是否可用）；用线上日志补充真实长尾分布。评估集应版本化，随策略迭代更新。

A/B 测试的价值取决于评测集的代表性。只测高频典型样本会高估策略质量，掩盖长尾与跨会话的退化。覆盖长尾、跨会话、多语言就是把"策略在真实世界的表现"变成可测，避免"测试集上有、线上没有"的偏差。