# 3.1 信息环境设计原则

## 3.1.1 信息环境的概念

**信息环境**（Information Environment）是指模型在执行任务时可获取的全部信息的集合与组织方式。上下文工程的本质就是设计和管理这个信息环境。

一个优秀的信息环境应该满足以下特性：

* 包含任务所需的充分信息
* 排除无关的噪声信息
* 以模型易于理解的方式组织
* 能够动态适应任务需求

## 3.1.2 注意力预算与上下文腐烂

在深入设计原则之前，我们先引入两个在业界实践中常用的隐喻性概念，用来帮助理解“为什么上下文需要被当作稀缺资源来设计”。

**注意力预算（Attention Budget）**

这一概念源自对 Transformer 自注意力机制的工程观察：上下文越长，模型需要在更多 Token、位置和噪声之间做选择，关键信息更容易被无关内容干扰。注意力权重不是简单的 `1 / token_count` 平均分配，因此“注意力预算”应理解为工程隐喻，而不是严格公式。

与人类有限的工作记忆类似，大语言模型也有一个“注意力预算”，用于处理上下文中的大量信息。每引入一个新的 Token，都会消耗一定的注意力预算。这意味着：

* 上下文必须被当作 **有限资源** 来管理
* 边际效用递减：更多的 Token 不一定带来更好的结果
* 需要在上下文大小和注意力集中度之间权衡

**上下文腐烂（Context Rot）**

在一些长上下文评测与工程观察中（如“Lost in the Middle”等研究），人们发现：随着上下文窗口中 Token 数量增加，模型对关键信息的提取与回忆稳定性可能下降。本书将这种“有效利用率随长度下降”的现象归纳为“上下文腐烂”（Context Rot），作为一种工程直觉来指导上下文容量的决策。

造成这一现象的原因：

* 长上下文会增加位置偏置、无关证据和指令冲突的暴露面
* 检索或拼接顺序不佳时，关键证据可能被放在模型不稳定利用的位置
* 模型、训练方式和推理系统差异很大，必须用任务级评测验证有效上下文长度

> **核心指导原则**：优秀的上下文工程意味着找到 **最小可能的高信号 Token 集**，以最大化实现期望结果的可能性。

## 3.1.3 设计原则一：相关性优先

**核心理念**：只包含与当前任务直接相关的信息。

相关性是上下文质量的首要指标。经验上，无关信息不仅浪费上下文空间，还可能干扰模型判断，导致输出质量下降。

```mermaid
graph TB
    subgraph "相关性筛选"
        A["全量信息"] --> B{"相关性评估"}
        B --> |"高相关"| C["纳入上下文"]
        B --> |"低相关"| D["排除"]
        B --> |"可能相关"| E["条件纳入"]
    end
```

图 3-1：相关性筛选流程

实践要点：

* 建立任务-信息的映射关系
* 使用语义相似度评估相关性
* 设置相关性阈值，过滤低分内容
* 对于边界情况，宁缺毋滥

## 3.1.4 设计原则二：信息密度优化

**核心理念**：用最少的 Token 传达最多的有效信息。

信息密度定义为：有效信息量与 Token 数量的比值。高密度的上下文意味着：

* 更高的空间利用效率
* 更低的计算成本
* 更快的响应速度

提升信息密度的方法：

* 删除冗余词汇和重复内容
* 使用结构化格式替代散文
* 压缩长文本为摘要
* 提取关键事实而非全文

## 3.1.5 设计原则三：结构化组织

**核心理念**：用清晰的结构组织信息，便于模型理解和定位。

结构化组织的优势：

* 帮助模型快速定位相关信息
* 明确不同信息块的角色和关系
* 减少歧义和误解
* 支持模块化更新和维护

常用的结构化方法：

| 方法       | 适用场景     | 示例                                 |
| -------- | -------- | ---------------------------------- |
| XML 标签   | 区分不同类型内容 | `<instructions>...</instructions>` |
| Markdown | 层级化文档    | 标题、列表、代码块                          |
| JSON     | 结构化数据    | 配置、元数据                             |
| 分隔符      | 简单内容分隔   | `---`、`===`                        |

## 3.1.6 设计原则四：上下文分层

**核心理念**：根据信息的重要性和稳定性，分层组织上下文。

典型的分层结构：

```mermaid
graph TB
    subgraph "上下文分层"
        A["系统层：角色定义、行为准则"]
        B["知识层：领域知识、参考文档"]
        C["任务层：当前任务的具体要求"]
        D["交互层：对话历史、用户输入"]
    end
    A --> B --> C --> D
```

图 3-2：上下文分层结构

* **系统层**：最稳定，定义模型的基本角色和行为边界
* **知识层**：相对稳定，提供任务所需的背景知识
* **任务层**：随任务变化，描述当前的具体目标
* **交互层**：最动态，反映即时的用户输入和对话状态

分层的好处：

* 稳定层可以缓存复用
* 动态层独立更新
* 便于调试和维护

## 3.1.7 设计原则五：显式优于隐式

**核心理念**：明确说明期望，而非依赖模型推测。

模型擅长遵循明确的指令，但对隐含期望的推测可能不可靠。因此：

* 明确输出格式要求
* 显式说明限制条件
* 清楚定义术语含义
* 提供具体的正例和反例

## 3.1.8 设计原则六：渐进式提供

**核心理念**：按需提供信息，避免一次性加载全部内容。

这一原则在智能体系统中尤为重要。渐进式提供的方式：

* **即时加载**：在需要时通过工具获取信息
* **分步展开**：随着任务进展逐步添加细节
* **条件触发**：基于特定条件加载相关内容

渐进式方法的优势：

* 避免上下文过载
* 确保信息的时效性
* 降低初始延迟

## 3.1.9 系统提示词的高度校准原则

系统提示词是上下文的基础，它定义了模型的基本角色和行为。Anthropic 的实践表明，系统提示词的设计存在一个临界的高度校准（Altitude Calibration）问题。

**两个常见失败模式**：

1. **过低的高度（Brittle Logic）**：系统提示词中硬编码复杂的 if-else 逻辑，试图通过冗长的条件语句精确指定每种情况下的行为。这种方法：
   * 导致提示词脆弱且难以维护
   * 增加了系统复杂度
   * 在面对未预见的情况时易于失败
   * 例：`“如果用户说 X，回答 Y；如果用户说 A，回答 B；...”`（包含大量嵌套条件）
2. **过高的高度（Vague Assumptions）**：系统提示词过于宽泛或依赖隐含理解，导致模型无法获得足够的具体信号。这种方法：
   * 假设了过多的上下文共享
   * 给予过少的具体指导
   * 可能导致行为不可控
   * 例：`“你是一个友好的助手”`（太笼统，缺乏任务具体性）

**黄金分割点（Goldilocks Zone）**：

最优的系统提示词应当：

* **足够具体**：给出清晰的行为信号和决策准则
* **足够灵活**：提供启发式原则而非硬规则，允许模型在框架内灵活推理
* **足够简洁**：使用最少的高信号 Token，避免冗余

```xml
<!-- 示例：不同高度的对比 -->

<!-- ❌ 过低：硬编码逻辑 -->
<system_prompt_too_low>
如果用户问价格，说"我们的价格从 $99 开始"。
如果用户问退货，说"7 天内无条件退货"。
如果用户问发货，说"免运费"。
...（数十条规则）
</system_prompt_too_low>

<!-- ❌ 过高：含糊其辞 -->
<system_prompt_too_high>
你是一个有帮助的客服。回答用户的问题。
</system_prompt_too_high>

<!-- ✅ 恰当高度 -->
<system_prompt_optimal>
角色：电商客服代理
目的：帮助用户了解产品和服务，处理常见询问
原则：
- 提供准确的信息（如有不确定，说"我来为你查询"）
- 遵循退货政策（标准 7 天，特殊情况需升级）
- 优先用户满意度，必要时可提供额外折扣
约束：不承诺超出权限的承诺
</system_prompt_optimal>
```

**校准方法**：

1. 从最小提示词开始，测试模型在你的目标任务上的表现
2. 识别失败模式，添加明确的指导原则（不是规则）
3. 测试新版本，迭代改进
4. 定期审视，移除不必要的条件和过度说明
5. 优先使用示例和启发式原则，而非 if-then 条件

关于系统提示词的详细策略，参见[第 4 章](/context_engineering_guide/di-er-bu-fen-he-xin-ji-shu-yu-ce-le/04_write.md)的相关内容。

## 3.1.10 原则的综合应用

这七项原则并非孤立，而是需要综合应用。一个良好的上下文设计应该：

1. 从相关性筛选开始，确定需要包含的信息
2. 对选中的信息进行密度优化
3. 使用合适的结构组织内容
4. 按层级安排信息的位置
5. 显式表达所有重要要求
6. 在系统提示词中校准正确的高度
7. 设计动态加载机制处理变化需求

在实际项目中，可能需要在这些原则之间做出权衡。理解每项原则的目的，有助于在具体场景下做出正确的决策。


---

# 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-yi-bu-fen-ren-shi-shang-xia-wen-gong-cheng/03_framework/3.1_design_principles.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.