第2章：上下文工程技术栈

​

2.1 上下文窗口限制与问题分类

​

2.1.1 长上下文 ≠ 好上下文

​

上下文窗口

• 上下文太长，超过上下文窗口限制
• 上下文太短，不足以支撑推理
• 上下文很长，但是还没超过上下文窗口限制
• 上下文适中

​

从长度到语义

1. 上下文污染（Context Poisoning）：幻觉等错误进入上下文，被模型反复引用，导致持续的错误
2. 上下文分心（Context Distraction）：上下文太长，模型反而忽略了训练中学到的东西
3. 上下文混淆（Context Confusion）：无关的上下文被模型用来生成低质量回答
4. 上下文冲突（Context Clash）：上下文中的不同信息或工具互相矛盾

1. 信息污染（Information Poisoning）：错误信息持续留在上下文中，其实不局限于当前的上下文，这个信息污染是有可能从运行时的上下文外溢到外部存储的，比如长短期记忆，或者一些 Specification。容易造成重复错误行为、目标偏离和行为死循环。
2. 注意力偏移（Attention Misalignment）：上下文长度增加会导致效果变差，其中的核心是上下文分心，模型被上下文分散了注意力，并且还会进一步让注意力从目标或指令转向无关的上下文，容易造成忽略指令、回答随机和无法聚焦。
3. 语义冲突与混乱（Semantic Conflict & Confusion）：上下文存在歧义、矛盾或冗余等情况，导致模型难以理解和识别，导致最终效果不符合预期。容易造成误解、矛盾回答和答非所问。

​

2.1.2 常见问题分类

​

信息污染（Information Poisoning）

Fixations on delusions due to goal-setting and also due to the Guidance Gemini instance are not an uncommon occurrence in watching Gemini Plays Pokémon - the TEA incidence is hardly the only example of this behavior. An especially egregious form of this issue can take place with “context poisoning” – where many parts of the context (goals, summary) are “poisoned” with misinformation about the game state, which can often take a very long time to undo. As a result, the model can become fixated on achieving impossible or irrelevant goals. This failure mode is also highly related to the looping issue mentioned above. These delusions, though obviously nonsensical to a human (“Let me try to go through the entrance to a house and back out again. Then, hopefully the guard who is blocking the entrance might move.”), by virtue of poisoning the context in many places, can lead the model to ignore common sense and repeat the same incorrect statement. Context poisoning can also lead to strategies like the “black-out” strategy (cause all Pokémon in the party to faint, “blacking out” and teleporting to the nearest Pokémon Center and losing half your money, instead of attempting to leave).

在观看 Gemini 玩《宝可梦》的过程中，常常会看到因为设定目标或受到”指导版 Gemini 实例”的影响而产生的执念式妄想，这并不是个别现象，TEA 事件也只是其中一个例子而已。其中一种更严重的情况被称为”上下文污染”（context poisoning）——即大量关于游戏状态的错误信息被写入到上下文中（包括目标设定、总结等部分），这类污染往往需要很长时间才能纠正。一旦发生这种情况，模型可能会执着于实现一些根本不可能或毫无意义的目标。这种错误还常常伴随着”死循环”现象。尽管这些行为对人类来说明显是荒谬的，比如模型可能会不断尝试”进出一座房子，希望门口的守卫因此移动位置”，但由于上下文中的错误信息大量存在，它会使模型忽视常识，不断重复错误的判断。上下文污染甚至会导致模型采取一些极端策略，比如所谓的”黑屏策略”：故意让队伍中所有宝可梦全部昏迷，从而”黑屏”被传送回最近的宝可梦中心，同时损失一半的钱，而不是尝试正常离开当前区域。

Language models are excellent mimics; they imitate the pattern of behavior in the context. If your context is full of similar past action-observation pairs, the model will tend to follow that pattern, even when it’s no longer optimal. This can be dangerous in tasks that involve repetitive decisions or actions. For example, when using Manus to help review a batch of 20 resumes, the agent often falls into a rhythm—repeating similar actions simply because that’s what it sees in the context. This leads to drift, overgeneralization, or sometimes hallucination.

Few-shot 提示是一种常见的技术，用于提升大语言模型（LLM）的输出质量。但在智能体（agent）系统中，它有时却会在不经意间带来反效果。 语言模型擅长”模仿”，它们会学习和复刻上下文中呈现的行为模式。如果你提供的上下文里充满了相似的”动作—观察”对，模型往往会机械地遵循这些模式，即便这些行为已经不再是最优选择。 在需要重复决策或执行操作的任务中，这种问题尤为明显。比如，当使用 Manus 帮助审阅一批共 20 份简历时，智能体很容易陷入”节奏”中——重复执行同样的操作，只因为它在上下文中看到类似的例子。这种现象会导致”漂移”、过度泛化，甚至出现幻觉（hallucination）。

The fix is to increase diversity. Manus introduces small amounts of structured variation in actions and observations—different serialization templates, alternate phrasing, minor noise in order or formatting. This controlled randomness helps break the pattern and tweaks the model’s attention. In other words, don’t few-shot yourself into a rut. The more uniform your context, the more brittle your agent becomes.

解决方法是引入更多的多样性。Manus 通过在动作和观察中加入少量有结构的变化来实现这一点——比如使用不同的序列化模板、替换措辞、在顺序或格式上加入细微扰动。这种”可控的随机性”有助于打破固定模式，重新调整模型的注意力焦点。 换句话说，别让 few-shot 提示把你困在一种套路里。上下文越单一、越一致，你的智能体就越脆弱。

​

注意力偏移（Attention Misalignment）

Large Language Models (LLMs) are typically presumed to process context uniformly—that is, the model should handle the 10,000th token just as reliably as the 100th. However, in practice, this assumption does not hold. We observe that model performance varies significantly as input length changes, even on simple tasks.

Simply replicate the following text, output the exact same text: apple apple apple apple **apples** apple apple apple apple apple apple apple apple apple apple apple apple apple apple apple apple apple apple apple apple

While Gemini 2.5 Pro supports 1M+ token context, making effective use of it for agents presents a new research frontier. In this agentic setup, it was observed that as the context grew significantly beyond 100k tokens, the agent showed a tendency toward favoring repeating actions from its vast history rather than synthesizing novel plans. This phenomenon, albeit anecdotal, highlights an important distinction between long-context for retrieval and long-context for multi-step, generative reasoning.

虽然 Gemini 2.5 Pro 支持超过 100 万个 token 的上下文，但如何在智能体（agent）系统中有效利用这一能力，仍是一个新的研究前沿。在这类 agentic 设置中，有观察发现：当上下文显著超过 10 万 token 时，智能体往往倾向于重复其历史中的动作，而不是生成新的计划。这种现象虽然仍属经验观察，但它揭示了一个重要的区别：长上下文在检索任务中的应用，与在多步生成式推理中的作用，其实并不相同。

• 重复内容(repeated_content)：当大模型的回答是完全重复的词语或字符（无意义的重复）。
• 随机内容(random_content)：当模型生成的回答完全是随机的、与内容无关，或在逻辑或语法上不通顺。
• 未遵循指令（fail_to_follow_instruction）：当模型没有理解指令的意图，或未按照问题中指定的要求作答。例如，指令要求根据给定上下文回答问题，而模型却去总结上下文。
• 错误回答（wrong_answer）：当模型试图按照指令作答，但提供的答案是错误的。
• 其他（others）：当失败情况不属于上述任何一种类别时使用。

If you’ve worked with Manus, you’ve probably noticed something curious: when handling complex tasks, it tends to create a todo.md file—and update it step-by-step as the task progresses, checking off completed items. That’s not just cute behavior—it’s a deliberate mechanism to manipulate attention. A typical task in Manus requires around 50 tool calls on average. That’s a long loop—and since Manus relies on LLMs for decision-making, it’s vulnerable to drifting off-topic or forgetting earlier goals, especially in long contexts or complicated tasks. By constantly rewriting the todo list, Manus is reciting its objectives into the end of the context. This pushes the global plan into the model’s recent attention span, avoiding “lost-in-the-middle” issues and reducing goal misalignment. In effect, it’s using natural language to bias its own focus toward the task objective—without needing special architectural changes.

如果你用过 Manus，可能会注意到一个有趣的现象：在处理复杂任务时，它常常会创建一个 todo.md 文件，并在任务执行过程中逐步更新，勾选已经完成的项目。 这并不是一种”可爱”的行为，而是一种有意设计的注意力操控机制。 Manus 处理的典型任务平均需要调用大约 50 次工具。这是一个非常长的执行链——而由于 Manus 的决策依赖 LLM，它在上下文很长或任务很复杂的情况下，容易出现跑题或忘记最初目标的问题。 通过不断地重写这份待办清单，Manus 实质上是在将任务目标”复述”到上下文的结尾处。这样做可以把全局计划强行推入模型最近的注意力范围，避免”上下文中段丢失”问题，同时减少目标偏移。换句话说，它是在用自然语言主动引导模型关注核心任务目标——无需修改模型结构，就能实现注意力的偏置。

​

语义冲突与混乱（Semantic Conflict & Confusion）

​

2.2 上下文工程技术（Techniques in CE）

1. 上下文增强（Context Augmentation）：主要目的是补充信息，比如提示词技术、RAG 和 MCP
2. 上下文优化（Context Optimization）：主要目的是清洗和优化上下文，会包括隔离、修剪和压缩等手段
3. 上下文持久化（Context Persistence）：主要目的是保留信息，涉及一些外部记忆模块的持久化服务

​

2.2.1 上下文增强（Context Augmentation）

​

提示词技术（Prompting）

​

RAG（Retrieval-Augmented Generation）

1. 减少幻觉（Hallucination）
2. 提升信息的时效性
3. 专业或领域信息增强

• 索引：切分策略（语义/结构化切分）、元数据（时间、作者、标签）、多索引（向量 + 倒排）、段落-表格-图片多模态
• 查询加工：重写（Query Rewriting）、多路查询（Multi-Query）、分解（Decomposition）、意图判别（是否需要检索）
• 检排：向量召回 + 交叉编码器重排（Rerank）；MMR/多样性；新鲜度与时效权重
• 变体：多跳/链式 RAG、Agentic RAG（规划 + 迭代检索）、GraphRAG（图结构汇总）、结构化检索（SQL/知识图谱）

​

工具集成与函数调用（MCP）

​

2.2.2 上下文优化（Context Optimization）

​

上下文隔离（Context Isolation）

• 任务分片（Task Sharding）：将任务分成多个子流程或阶段，每一阶段单独运行于自己的上下文中，避免累积无关信息
• 记忆系统分区（Memory Partitioning）：通过将长期记忆和短期记忆隔离管理，只在需要时引用跨区域记忆，避免上下文污染
• 领域专属上下文（Domain-specific Context Pools）：为不同的任务域（如法律、医疗、编程）配置专属上下文池，确保大语言模型使用最相关的信息

​

上下文压缩（Context Compression）

• 提取式摘要（Extractive Summarization）：直接选出原文中最相关的段落、句子
• 抽象式摘要（Abstractive Summarization）：用自己的话总结信息，常结合 LLM 实现
• 结构化摘要（Structured Summarization）：提取出知识点、任务、目标等结构化信息，如 To-do 列表、决策路径
• 自我总结（Self-summarization）：模型每一轮对话之后，自动总结这轮信息并作为输入传递，形成压缩上下文链
• 摘要记忆（Summarized Memory）：结合记忆机制，将历史摘要作为长期记忆引用
• 时间窗口裁剪（Time-based Pruning）：仅保留最近或关键时段的上下文，剔除历史冗余信息，提升推理精度

Your task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions.
This summary should be thorough in capturing technical details, code patterns, and architectural decisions that would be essential for continuing development work without losing context.

Before providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure you've covered all necessary points. In your analysis process:

1. Chronologically analyze each message and section of the conversation. For each section thoroughly identify:
   - The user's explicit requests and intents
   - Your approach to addressing the user's requests
   - Key decisions, technical concepts and code patterns
   - Specific details like:
     - file names
     - full code snippets
     - function signatures
     - file edits
  - Errors that you ran into and how you fixed them
  - Pay special attention to specific user feedback that you received, especially if the user told you to do something differently.
2. Double-check for technical accuracy and completeness, addressing each required element thoroughly.

Your summary should include the following sections:

1. Primary Request and Intent: Capture all of the user's explicit requests and intents in detail
2. Key Technical Concepts: List all important technical concepts, technologies, and frameworks discussed.
3. Files and Code Sections: Enumerate specific files and code sections examined, modified, or created. Pay special attention to the most recent messages and include full code snippets where applicable and include a summary of why this file read or edit is important.
4. Errors and fixes: List all errors that you ran into, and how you fixed them. Pay special attention to specific user feedback that you received, especially if the user told you to do something differently.
5. Problem Solving: Document problems solved and any ongoing troubleshooting efforts.
6. All user messages: List ALL user messages that are not tool results. These are critical for understanding the users' feedback and changing intent.
6. Pending Tasks: Outline any pending tasks that you have explicitly been asked to work on.
7. Current Work: Describe in detail precisely what was being worked on immediately before this summary request, paying special attention to the most recent messages from both user and assistant. Include file names and code snippets where applicable.
8. Optional Next Step: List the next step that you will take that is related to the most recent work you were doing. IMPORTANT: ensure that this step is DIRECTLY in line with the user's explicit requests, and the task you were working on immediately before this summary request. If your last task was concluded, then only list next steps if they are explicitly in line with the users request. Do not start on tangential requests without confirming with the user first.
                       If there is a next step, include direct quotes from the most recent conversation showing exactly what task you were working on and where you left off. This should be verbatim to ensure there's no drift in task interpretation.

Here's an example of how your output should be structured:

<example>
<analysis>
[Your thought process, ensuring all points are covered thoroughly and accurately]
</analysis>

<summary>
1. Primary Request and Intent:
   [Detailed description]

2. Key Technical Concepts:
   - [Concept 1]
   - [Concept 2]
   - [...]

3. Files and Code Sections:
   - [File Name 1]
      - [Summary of why this file is important]
      - [Summary of the changes made to this file, if any]
      - [Important Code Snippet]
   - [File Name 2]
      - [Important Code Snippet]
   - [...]

4. Errors and fixes:
    - [Detailed description of error 1]:
      - [How you fixed the error]
      - [User feedback on the error if any]
    - [...]

5. Problem Solving:
   [Description of solved problems and ongoing troubleshooting]

6. All user messages:
    - [Detailed non tool use user message]
    - [...]

7. Pending Tasks:
   - [Task 1]
   - [Task 2]
   - [...]

8. Current Work:
   [Precise description of current work]

9. Optional Next Step:
   [Optional Next step to take]

</summary>
</example>

Please provide your summary based on the conversation so far, following this structure and ensuring precision and thoroughness in your response.

There may be additional summarization instructions provided in the included context. If so, remember to follow these instructions when creating the above summary. Examples of instructions include:
<example>
## Compact Instructions
When summarizing the conversation focus on typescript code changes and also remember the mistakes you made and how you fixed them.
</example>

<example>
# Summary instructions
When you are using compact - please focus on test output and code changes. Include file reads verbatim.
</example>

你的任务是创建一份当前对话的详细总结，需特别关注用户的明确请求以及你之前的操作记录。
这份总结必须详尽，准确捕捉技术细节、代码模式和架构决策，以确保继续开发工作时不丢失上下文。

在提供最终总结之前，请将你的分析过程包裹在 `<analysis>` 标签中，用以组织你的思考，并确保你已覆盖所有必要内容。在分析过程中：

1. 按时间顺序分析对话的每条消息和每个部分。对每个部分请详细识别：
   - 用户的明确请求和意图
   - 你是如何响应用户请求的
   - 关键的决策、技术概念和代码模式
   - 包括以下内容在内的具体细节：
     - 文件名
     - 完整代码片段
     - 函数签名
     - 文件修改情况
   - 出现的错误以及你是如何修复的
   - 特别注意用户反馈，尤其是用户要求你更改做法的地方

2. 仔细检查技术准确性和完整性，确保每个要素都得到详尽处理。

你的总结应包含以下部分：

## 1. Primary Request and Intent（主要请求与意图）
详细记录用户所有明确的请求与意图。

## 2. Key Technical Concepts（关键技术概念）
列出所有讨论过的重要技术概念、技术框架等。

## 3. Files and Code Sections（涉及的文件与代码部分）
列出查看、修改或创建的具体文件与代码片段。特别注意最新的消息，提供完整代码片段并说明其重要性。

## 4. Errors and fixes（错误与修复）
列出出现的所有错误及其修复方式，尤其是用户给出的反馈和修正指示。

## 5. Problem Solving（问题解决）
说明已解决的问题和仍在进行的问题排查工作。

## 6. All user messages（所有用户消息）
列出所有用户的非工具使用消息。这对于理解用户反馈和意图变化至关重要。

## 7. Pending Tasks（待办任务）
列出用户明确要求你继续完成的任务。

## 8. Current Work（当前工作）
详细说明在本次总结请求前你正在处理的具体任务，尤其要关注 assistant 和 user 最近的互动内容，并附带文件名和代码片段（若有）。

## 9. Optional Next Step（可选的下一步）
列出与你最近正在进行的工作直接相关的下一步行动。**必须**确保此步骤完全符合用户的明确请求，并引用最近对话中的原话作为依据。若上一任务已结束，仅在用户有明确指示时列出下一步。

---

## 示例结构（Example Structure）

以下是你的输出应遵循的结构示例：

​

2.2.3 上下文持久化（Context Persistence）

• 文件系统（如.json, .txt）
• 数据库存储（PostgreSQL, MongoDB 等）
• 向量数据库（用于检索式记忆）
• Key-Value 缓存（如 Redis）

• 会话记忆（Chat Memory）：例如对话中用户提到”我下周要去东京”，可以在后续对话中继续引用；
• Agent 任务状态保存：例如 Agent 正在处理一个流程任务，下次接入可从断点恢复；
• 用户偏好记录：如用户喜欢 markdown 格式、喜欢精炼回答等。

• 自动摘要持久化（如每天一次自动保存摘要）
• 用户关键输入保存（如计划、目标等）
• 分阶段持久化（如每完成一个任务后存储）

​

小结