---
name: context-first-design
version: 2.0
framework: 智能体管理学 · 模块三 · 框架F15
type: 设计型
description: >
  上下文优先设计（Context-First Design）。当需要为Agent产品设计信息架构、
  优化上下文窗口、或重构交互流程时触发。关键词：上下文设计、信息架构、
  上下文窗口、Context工程、上下文噪声、感知系统。
governance_nerves: [意图管理, 边界与升级]
upstream_frameworks: [F13-定位框架, F14-需求框架]
downstream_frameworks: [F16-PMF诊断, F17-VERITAS评估, F19-MAS架构]
---

# F15 上下文优先设计（Context-First Design）

## SKILL定位

**核心命题**：上下文是Agent的感知系统，不是配置参数。设计Agent产品时，先定义每个决策点需要什么信息（上下文架构），再设计交互，最后确定提示词——这个顺序不能颠倒。

**颠覆对象**：传统产品设计顺序（用户研究→界面→功能→提示词）。Context-First认为：提示词只是上下文的一种表达形式，真正决定Agent质量的是「在正确的时间、给正确的信息」。

**三个核心原则**：
1. **精准 > 丰富**：上下文噪声是质量杀手。多一个无关信息，准确率可能下降5-15%
2. **先于代码设计**：上下文架构是产品文档，不是技术文档
3. **产品主导而非工程主导**：产品经理定义「每个决策点需要什么」，工程师实现「如何高效传递」

---

## 信息采集（INPUT模板）

```yaml
# === 上下文设计诊断输入 ===
product_name: ""                    # 产品名称
agent_type: ""                      # Agent类型（客服/分析/创作/执行）
current_context_layers:             # 现有上下文分层（如有）
  L1_history: ""                    # 历史记忆：保留了什么用户历史？
  L2_user_input: ""                 # 用户输入：当前轮次如何采集？
  L3_task_context: ""               # 任务上下文：任务定义是否清晰？
  L4_tool_results: ""               # 工具结果：如何筛选和压缩？
  L5_output_constraints: ""         # 输出约束：格式/长度/风格要求？
  L6_system_prompt: ""              # 系统提示：角色/规则/边界定义？
key_decision_points:                # 关键决策点
  - decision: ""                    # 决策描述
    information_needed: ""          # 该决策需要什么信息
    current_info_gap: ""            # 当前信息缺口
main_pain_points:                   # 主要痛点
  - ""                              # 上下文相关的质量问题
token_budget: ""                    # Token预算（如有）
interaction_pattern: ""             # 交互模式（单轮/多轮/长对话）
```

---

## 执行分析引擎（S1-S4）

### S1：上下文审计（Context Audit）

**目标**：盘点当前Agent在每个决策点实际使用了哪些信息，识别冗余和缺口。

**执行步骤**：
1. 列出Agent需要做的3-5个核心决策
2. 为每个决策标注「实际用到的上下文」vs「理想需要的上下文」
3. 识别三类问题：冗余（塞了不需要的）、缺失（需要但没给）、错位（给了但放错了层）

**评分锚点**：
- 5分：每个决策点的信息需求已精确定义，无冗余无缺失
- 3分：主要决策点已定义，但存在1-3处冗余或缺失
- 1分：上下文随意堆砌，未做决策点级分析

**输出模板**：
```yaml
audit_result:
  decision_points:
    - name: ""
      used_context: []      # 实际使用的上下文项
      needed_context: []    # 理想需要的上下文项
      redundant: []         # 冗余项
      missing: []           # 缺失项
      misaligned: []        # 错位项
  overall_score: ""         # 1-5分
```

### S2：六层架构设计（6-Layer Architecture Design）

**目标**：基于S1审计结果，重新设计六层上下文架构。

**六层定义与设计要点**：

| 层级 | 名称 | 职责 | 设计要点 |
|------|------|------|----------|
| L1 | 历史记忆 | 跨会话的用户画像、偏好、历史交互摘要 | 压缩率>90%，只保留影响当前决策的历史；设置衰减机制 |
| L2 | 用户输入 | 当前轮次的原始输入及解析结果 | 区分「显式输入」和「隐含意图」；处理歧义的追问策略 |
| L3 | 任务上下文 | 当前任务的定义、阶段、约束条件 | 任务状态机设计；明确「当前在哪一步」 |
| L4 | 工具结果 | 外部工具/API返回的结果 | 筛选>全量；结构化>自然语言；设置超时和降级策略 |
| L5 | 输出约束 | 格式、长度、风格、合规要求 | 约束冲突时的优先级规则；硬约束vs软约束区分 |
| L6 | 系统提示 | 角色定义、行为规则、安全边界 | 最稳定的一层；变更需走治理审批 |

**评分锚点**：
- 5分：六层职责清晰无重叠，层间信息流有明确设计
- 3分：六层已定义但存在2-3处职责模糊或信息流断裂
- 1分：未做分层，上下文混沌堆叠

**输出模板**：
```yaml
architecture_design:
  L1_history:
    storage_strategy: ""
    compression_method: ""
    decay_policy: ""
  L2_user_input:
    parsing_method: ""
    ambiguity_handling: ""
  L3_task_context:
    state_machine: ""
    stage_tracking: ""
  L4_tool_results:
    filtering_rules: ""
    fallback_strategy: ""
  L5_output_constraints:
    hard_constraints: []
    soft_constraints: []
    priority_rules: ""
  L6_system_prompt:
    role_definition: ""
    boundary_rules: ""
    change_approval: ""
```

### S3：噪声削减与压缩（Noise Reduction）

**目标**：对每层上下文执行「精准>丰富」原则，削减冗余信息。

**执行步骤**：
1. **信息价值评分**：对每条上下文项打分（对决策的贡献度1-5）
2. **阈值筛选**：低于3分的信息项标记为候选删除
3. **压缩策略**：对保留项选择压缩方式（摘要/结构化/关键词提取）
4. **A/B验证**：对比压缩前后的Agent输出质量

**评分锚点**：
- 5分：Token使用效率>80%，每条信息都有明确的决策价值
- 3分：Token效率60-80%，存在5-10%可削减冗余
- 1分：Token效率<60%，大量无关信息占用上下文窗口

**输出模板**：
```yaml
noise_reduction:
  before_tokens: ""
  after_tokens: ""
  efficiency_gain: ""       # 百分比
  removed_items:
    - item: ""
      reason: ""
      risk_if_kept: ""      # 保留的风险
  compressed_items:
    - item: ""
      method: ""            # 摘要/结构化/关键词
      compression_ratio: ""
```

### S4：交互-上下文协同设计（Interaction-Context Alignment）

**目标**：确保交互设计与上下文架构对齐——用户在每个交互节点提供的信息，恰好是该节点决策所需的上下文。

**执行步骤**：
1. **映射交互节点→决策点→上下文需求**
2. **设计采集策略**：主动采集（表单/引导）vs 被动推断（行为/环境）
3. **设计反馈回路**：Agent输出是否为下一轮提供了有效上下文
4. **边界场景测试**：信息不足时的降级策略

**评分锚点**：
- 5分：每个交互节点的信息供给精确匹配决策需求，无冗余采集
- 3分：主要节点对齐，存在1-2处采集不足或过度
- 1分：交互设计与上下文需求脱节

**输出模板**：
```yaml
interaction_alignment:
  node_mapping:
    - interaction_node: ""
      decision_point: ""
      context_needed: []
      collection_method: ""   # 主动/被动/混合
      gap: ""
  feedback_loops:
    - from_output: ""
      to_next_context: ""
      quality: ""             # 有效/部分有效/无效
  degradation_strategy:
    - trigger: ""             # 什么条件下触发降级
      fallback: ""            # 降级方案
```

---

## 输出格式

### 上下文设计报告

```markdown
# 上下文设计报告 — [产品名称]

## 1. 设计摘要
- Agent类型：[类型]
- 核心决策点数量：[N]
- 上下文效率提升：[X]%

## 2. 六层架构图
[每层的核心内容、信息流向、Token预算分配]

## 3. 噪声削减清单
[删除项、压缩项、预期效果]

## 4. 交互-上下文对齐矩阵
[交互节点 × 决策点 × 上下文层]

## 5. 实施优先级
P0: [必须在上线前完成]
P1: [建议在v1.1完成]
P2: [优化项]

## 6. 风险与缓解
[信息不足时的降级策略、上下文污染的防御机制]
```

---

## 治理神经检查

- **意图管理**：上下文设计是否准确捕捉了用户的真实意图（而非表面请求）？
- **边界与升级**：当上下文信息不足以支撑安全决策时，是否有明确的升级路径？

---

## 质量自检

- [ ] 每个决策点的信息需求已精确定义
- [ ] 六层架构无职责重叠
- [ ] 上下文效率（有效Token/总Token）≥80%
- [ ] 交互节点与上下文需求已映射
- [ ] 信息不足时有降级策略
- [ ] 系统提示层（L6）有变更审批流程
- [ ] Token预算在模型限制内

---

## 典型误区

1. **「上下文越多越好」**：错。上下文噪声是Agent质量的第一杀手。每多一条无关信息，幻觉率上升3-8%
2. **「上下文是工程问题」**：错。上下文架构是产品决策——「在什么时机给什么信息」是产品设计，不是技术实现
3. **「一次设计就够了」**：错。上下文架构需要随用户行为数据持续迭代，至少每两周review一次
4. **「系统提示可以解决一切」**：错。系统提示只是L6，如果L1-L5设计有问题，再好的prompt也救不了

---

## 框架衔接

- **上游 → F13/F14**：产品定位和需求定义决定了Agent需要做哪些决策，进而决定上下文需求
- **下游 → F16**：上下文设计质量直接影响任务完成率，是PMF三指标的底层支撑
- **下游 → F17**：VERITAS七维中，有效性V和可靠性R高度依赖上下文设计质量
- **下游 → F19**：多Agent架构中，Agent间的上下文传递是MAS设计的核心挑战