# 本章小结

### 本章小结

本章系统梳理了上下文工程中的三大类反模式：过度压缩、上下文污染与检索失效。避免这些反模式，往往比“再加更多上下文”更能稳定提升效果与可控性。

#### 关键概念清单

| 概念    | 定义                      |
| ----- | ----------------------- |
| 反模式   | 初看合理但会导致效果退化的做法         |
| 过度压缩  | 为节省 Token 牺牲关键信息与约束     |
| 上下文污染 | 将大量无关信息混入上下文，稀释关键内容     |
| 检索失败  | 把“语义相似”误当作“答案相关”，导致召回偏差 |

#### 核心观点

1. **压缩必须保留关键约束**：压缩不是“变短”，而是“提炼”，关键实体与限制条件不应被摘要吞掉。
2. **上下文越多不一定越好**：All-in Context 往往引入噪声与注入风险，反而让模型更难对齐目标。
3. **相似度不等于相关性**：向量检索对否定、精确匹配与意图差异可能不敏感，需要混合检索与重排序兜底。

#### 常见误区

* **误区一**：只要把历史都摘要成一句就行 **正解**：摘要必须围绕任务保留可执行的约束与结论。
* **误区二**：把所有文档都喂给模型让它“自己找” **正解**：应先做相关性过滤与结构化隔离，把注意力留给真正关键的证据。
* **误区三**：向量检索足够覆盖所有查询 **正解**：应结合关键词检索、Query Rewrite、重排序与元数据过滤。

#### 实践建议

1. **建立反模式回归集**：把历史线上 Bad Case 按“压缩/污染/检索”归因入库。
2. **给关键约束设锚点**：预算、禁止项、合规规则等用显式结构长期保留。
3. **默认启用混合检索**：对专有名词、否定、数字与代码检索尤其重要。
4. **上线前做注入演练**：对抓取数据与用户输入做隔离，验证“指令不可被覆盖”。

#### 预告

### 下一章将进入生产环境最佳实践，聚焦工作流、性能与成本、可观测性、安全治理与故障排查。

> 📝 **发现错误或有改进建议？** 欢迎提交 [Issue](https://github.com/yeasy/context_engineering_guide/issues) 或 [PR](https://github.com/yeasy/context_engineering_guide/pulls)。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/context_engineering_guide/di-san-bu-fen-jin-jie-ji-shu-yu-jia-gou/11_antipatterns/summary.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.