> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](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).

# 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 条件

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

## 3.1.10 原则的综合应用

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

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

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