CE101 上下文工程技术栈

原文地址：https://ce101.ifuryst.com/basics/context-engineering-stack

一、这个内容真正解决的是什么问题？

真正的问题不在“能塞多少 token”，而在“模型在这一轮推理里究竟被什么信息驱动”。一旦把“更长上下文”当成万能解法，就会在三个具体决策点上频繁出错：该放什么、该不该放、放进来之后会不会把模型的注意力与判断推向错误方向。

二、最容易产生误解的地方

误解 1：上下文窗口越大，效果越稳定

• 常见想法：既然模型能吃 1M token，那就尽量塞满，信息越全越不容易错。
• 诱因：把上下文当作“内存”，直觉上更大内存=更强能力。
• 代价：上下文越长越可能分心、重复历史动作、忽略指令；错误一旦写进去，还会被反复引用，变成“越跑越偏”。

误解 2：只要信息是真的，放进去就不会有副作用

• 常见想法：真实信息不会害人，最多只是冗余。
• 诱因：把问题理解成“缺信息”，忽略“注意力预算”与“冲突成本”。
• 代价：相似但无用的材料会形成干扰，甚至与关键证据竞争注意力，导致模型答非所问或质量下降。

误解 3：多轮交互等价于一次性把话说完

• 常见想法：分几次补充细节没关系，模型会自动整合。
• 诱因：人类交流里“渐进补充”很自然。
• 代价：早期不完整回答会留在上下文里成为后续推理的“锚”，错误更容易固化，最终整体效果反而比单轮更差。

误解 4：提示词、RAG、工具调用是“可选增强”

• 常见想法：模型足够强就不需要这些外设。
• 诱因：把能力完全归因于模型参数与训练。
• 代价：时效性、专业性、可行动性都被锁死在模型权重里；在 Agent 场景下还会因为缺少治理而产生工具选择混乱。

三、支撑正确理解的核心机制

1）上下文窗口是一种资源上限，不是质量保证

• 直观理解：像内存一样，上限决定“最多能放多少”，但不决定“放得对不对”。
• 专业表述：上下文窗口限制输入 token 总量；工程问题从“能装下”升级为“怎样组装、怎样裁剪、怎样避免副作用”。
• 在整体中的位置：约束条件，也是技术栈出现的起点。

2）从“长度问题”走向“语义失败模式”

• 直观理解：同样长度的上下文，有的让模型更聪明，有的让模型更迷糊。
• 专业表述：失败不只来自超长或过短，还来自污染、分心、混淆、冲突；你给模型的是自然语言背景，它会把背景当作推理依据。
• 在整体中的位置：问题诊断框架，决定后续选哪类技术应对。

3）信息污染会把错误复制到更大的范围

• 直观理解：错误一旦写进“工作台”，后面每一步都可能继续用错。
• 专业表述：上下文污染会在目标、摘要、观察等多个位置写入错误状态，导致执念、循环与目标偏离；在 Agent 中还可能外溢到记忆或规范文本。
• 在整体中的位置：风险源，决定需要隔离、校验、清洗与回滚机制。

4）注意力偏移是“越长越不聚焦”的结构性现象

• 直观理解：材料堆得越多，越像在一张桌子上同时摊开几十份文件，关键那一页更难被盯住。
• 专业表述：随着输入长度增加，模型在简单任务上也会出现性能显著变化；相似干扰文本数量增加会进一步拉低效果；在超长历史下，模型可能偏好重复动作而非生成新计划。
• 在整体中的位置：性能与可靠性的上限来源，决定需要“锚定注意力”的工程做法（如目标复述、待办清单）。

5）语义冲突与混乱让模型进入“非确定性选择”

• 直观理解：同一段上下文里出现多个互相打架的说法，模型会像人一样犹豫，甚至随便选一个。
• 专业表述：多轮分片输入会让局部信息驱动局部结论，错误在上下文中持续存在并影响最终答案；大量相似工具描述会诱发随机式工具选择与不稳定输出。
• 在整体中的位置：系统治理问题，直接指向工具治理、上下文结构化与冲突消解。

6）技术栈的三大类手段分别对准三种工程目标

• 直观理解：补信息、管信息、存信息。
• 专业表述：上下文增强负责引入外部信息与能力；上下文优化负责清洗、隔离、压缩与降噪；上下文持久化负责把重要状态跨会话保存并可检索复用。
• 在整体中的位置：架构分层，决定系统模块怎么拆。

四、关键术语与概念对齐

• 上下文窗口：模型单次推理可接收的输入 token 上限，它限制“能放多少”，不保证“放得好”。
• 上下文不足：输入信息不足以支撑目标推理，表现为缺依据、泛化回答或无法按意图完成任务。
• 上下文过多：信息量超过有效注意力承载，表现为分心、忽略指令、重复与质量下降，它不等于“超过窗口”。
• 信息污染：错误或误导性信息在上下文中持续存在，并可能外溢到记忆/规范等外部存储，导致重复错误与目标偏离。
• 注意力偏移：模型注意力从目标/指令偏移到无关或相似干扰信息，导致性能随长度或干扰增加而衰减。
• 语义冲突与混乱：上下文中存在歧义、矛盾、冗余或工具描述相近，导致模型理解困难与选择不稳定。
• RAG：先从外部知识库检索相关信息，再与输入一起生成答案，用于降低幻觉、增强时效与领域性。
• MCP：用于规范模型与外部工具交互的协议，使工具接入更标准化、可复用，并带来工具治理新问题。
• 上下文隔离：通过多智能体/任务分片/记忆分区等手段，让不同子任务在独立上下文中运行以减少干扰。
• 上下文压缩：用摘要、修剪、结构化提取等方式降低上下文体积与噪声，维持可推理性与可持续运行。
• 上下文持久化：把关键用户信息、摘要与任务状态长期保存，以便后续检索与复用。

五、结构全景层：原文笔记

• 上下文窗口是天然限制，也是上下文工程出现的原因之一

  • 现阶段 SOTA 大模型的上下文空间普遍在 1M 以内，窗口上限决定了可注入信息的最大规模。
  • 上下文空间类比计算机内存：访问快但有限，上限推动了分页/置换式的工程思路在上下文侧的映射。

• 围绕长度维度会遇到四类直观场景

  • 上下文可能超过窗口上限，导致无法完整注入并触发截断或重组需求。
  • 上下文也可能过短导致推理支撑不足，而“尽量填满”又会引发模型分心与无法聚焦。

• 上下文问题从长度走向语义失败模式

  • Drew Breunig 提出上下文污染、上下文分心、上下文混淆、上下文冲突四类失败方式，用于解释长上下文失效。
  • 文章将其归并为信息污染、注意力偏移、语义冲突与混乱三类，便于定位与选择应对策略。

• 信息污染会导致错误持续引用与行为死循环

  • Gemini 2.5 Pro 在宝可梦 Agent 情境中出现“context poisoning”，错误游戏状态会污染目标与总结并很难撤销。
  • 污染会让模型执着于不可能或无关目标，并与循环问题相关，表现为重复荒谬动作或采取极端策略。

• 少样本提示在 Agent 场景可能诱发模式化重复

  • Manus 指出模型擅长模仿上下文中的动作—观察模式，样本越同质越容易把自己 few-shot 进套路里。
  • Manus 用结构化的多样性打破重复：替换模板、改写措辞、调整顺序或格式的可控扰动以重新分配注意力。

• 注意力偏移体现为上下文变长后效果不增反降

  • Chroma 的研究指出“模型均匀处理上下文”的假设不成立，输入长度变化会导致性能显著差异。
  • 重复单词复写实验显示随着输入变长输出质量下降，而相似干扰文本数量增加会进一步拉低表现。

• 超长历史会让 Agent 更偏好重复动作而非生成新计划

  • Gemini 报告观察到上下文显著超过 100k token 时，Agent 倾向于复用历史动作而不是综合出新计划。
  • 报告强调长上下文用于检索与用于多步生成式推理并不等同，工程上需要区别对待。

• 长上下文并不总能提升 RAG 表现，收益存在递减与衰退区间

  • Databricks 的评估显示上下文长度增加初期带来准确率提升，但随后小模型可能恶化，大模型趋缓或进入衰减。
  • 失败模式包含重复内容、随机内容、未遵循指令、错误回答与其他类型，说明长度会影响指令遵循与稳定性。

• 在长上下文里需要显式锚定目标以对抗“被淹没”

  • Claude Code 在执行中持续更新目标与 TODO 列表，把全局计划复述到上下文末尾以降低“中段丢失”和目标偏移。
  • Manus 也通过不断重写 todo.md 把目标推入最近注意力范围，平均大量工具调用的长循环尤其依赖这种注意力操控。

• 语义冲突与混乱会在多轮分片与工具密集环境中放大

  • 微软与 Salesforce 的研究显示把单轮拆成多轮会显著下降，因为早期局部信息诱发的错误会留在上下文中持续影响。
  • Agent 挂载大量工具后，工具描述相似会导致模型在相近选项间进行非确定性选择，从而输出不稳定甚至错误。

• 上下文工程技术被归为三大类以对应不同职责

  • 上下文增强用于补充信息与能力，包含提示词技术、RAG 与工具集成/函数调用（以 MCP 为代表）。
  • 上下文优化用于清洗与重组上下文，包含隔离、修剪与压缩；上下文持久化用于长期保存摘要、偏好与任务状态。

• 上下文持久化让系统具备跨会话记忆与断点续作能力

  • 持久化可落在文件、数据库、向量库与 KV 缓存上，用于会话记忆、任务状态与用户偏好记录。
  • 策略可采用自动摘要持久化、关键输入保存与分阶段持久化，以降低遗忘与漂移风险。

六、如何把这个内容讲清楚给别人？

最值得慢下来讲的是这一句：“上下文不是越长越好，关键是它会把模型的注意力与推理依据推向哪里。” 它是理解门槛，因为很多人默认模型“会自己抓重点”，而现实里重点需要被工程化地制造：去噪、结构化、锚定、回滚。

可以快速带过的是“窗口到底多大、谁是 SOTA”，这些数字会变，但不改变核心矛盾：资源有限、注意力有限、冲突不可避免。

最小示例 场景：做一个“批量简历审阅”的 Agent。

• 如果把前 19 份的动作—观察对原样全部塞进第 20 份的上下文，模型会更倾向于“模仿节奏”，重复同样的评语结构，甚至忽略第 20 份的独特亮点（注意力偏移 + 模式化重复）。
• 如果把历史压缩成结构化要点（评分标准、常见硬性红线、已确认的用户偏好），并把“本轮目标与输出格式”复述放在上下文末尾，同时仅检索与该候选人岗位匹配的少量证据片段（压缩 + 锚定 + RAG），模型更可能稳定地产生贴合个体的判断。

七、实践与使用视角的结论

适合用在什么场景

• 长会话、复杂任务、需要持续推进的 Agent 流程，且需要跨轮维护目标与状态。
• 需要时效信息、企业私有知识或领域知识的问答与决策，尤其依赖检索与工具。
• 工具调用密集的自动化任务，需要把“能做什么、该做什么、做到哪一步”管理成可控上下文。

不适合用在什么场景

• 纯短问短答且信息闭环的小任务，把上下文做得很重只会增加成本与噪声。
• 无法容忍错误外溢的场景却缺少校验/回滚机制时，把历史与摘要长期持久化会放大风险。
• 工具生态杂乱但没有治理（命名、描述、权限、去重、路由）时，盲目挂载大量 MCP Server 只会提高混乱概率。

最常见、也最危险的错误用法是什么

• 把“更多上下文”当作默认策略，导致分心、忽略指令与输出漂移。
• 让错误状态进入摘要/目标/记忆后持续引用，形成长期的错误轨迹与循环行为。
• 在多轮分片输入中放任早期错误回答滞留，不做纠偏就继续叠加新信息。

最低使用原则 只要上下文里出现“会驱动决策的内容”，就同时准备好三件事：它为何相关、它是否可信、它如何被锚定在目标之下。

八、最终总结

• 上下文窗口是上限，不是质量；上下文工程解决的是“在有限预算里把模型推向正确推理”。
• 长上下文会带来信息污染、注意力偏移与语义冲突，效果可能变差而不是变好。
• 技术栈可以按增强、优化、持久化分层，分别对应补信息、管信息、存信息。
• 在 Agent 场景中，目标复述与结构化状态是对抗漂移的关键，工具接入越多越需要治理。
• 真正的优化不是“塞满”，而是“让关键信息更近、更清晰、更一致”。