AI Native 上下文工程 Skill

使用场景

• 产品需要组织复杂的输入信息交给模型
• 需要设计可解释、可替换、可治理的上下文组织方案
• 需要避免"上下文太少—AI不知道自己在做什么"或"上下文太多—AI被噪音淹没"

核心概念

• 上下文工程（Context Engineering）：把任务所需信息按正确顺序、粒度和边界组织给模型的产品化能力
• 提示词：上下文中的一小部分，通常只负责角色、任务或格式约束
• 动态拼装：根据用户、任务、权限和状态，为每次调用临时组装所需上下文
• 上下文层次：目标层、规则层、知识层、记忆层和状态层等不同信息层

为什么上下文工程是核心能力

传统软件的行为主要由代码逻辑决定，而 AI 系统的行为会显著受到上下文影响。相同的模型，在没有背景资料、缺少角色信息、拿不到历史状态的情况下，很可能给出完全不同的结果。

很多 AI 产品问题的本质，并不是模型不够强，而是上下文组织不对。

上下文工程流程

任务进入
  → 目标识别
    → 上下文层选择
      → 动态拼装
        → 生成 / 行动
          → 结果校验与纠偏

一旦上下文层选择错误，后面的生成质量、工具调用和风险边界都会整体失真。

上下文的五个层次

1. 目标层

• 用户现在到底想完成什么
• 例如："查询订单状态"、"申请退货"、"了解售后政策"

2. 规则层

• 这个任务有哪些约束、边界和权限
• 例如：不能承诺赔付、不能暴露其他用户信息、必须保留人工接管点

3. 知识层

• 系统需要引用哪些资料、文档、行业规则
• 例如：售后政策文档、物流规则、商品说明

4. 状态层

• 当前流程进行到哪里，已经做过什么
• 例如：当前会话已提供订单号、已解释过的内容

5. 记忆层

• 与用户或历史案例相关的长期背景
• 例如：用户偏好某种解释风格、过去类似问题的处理方式

这几层不是每次都全部打开，而是要根据任务动态拼装。

上下文工程的四个目标

1. 选择真正相关的信息：不是把所有信息都塞进去
2. 用模型易于理解的方式组织信息：顺序、结构、格式
3. 在有限窗口内控制上下文成本：令牌消耗、延迟
4. 随任务阶段动态更新上下文内容：不是固定模板

动态拼装原则

好的上下文不是固定模板，而是动态拼装：

• 根据用户角色决定哪些规则层可见
• 根据任务类型决定哪些知识层需要
• 根据当前状态决定哪些状态层包含
• 根据历史交互决定哪些记忆层激活

常见失败模式

上下文太少

• AI 不知道自己在做什么
• 结果偏题、幻觉、给出表面正确但实际不可用的结果

上下文太多

• AI 被噪音淹没
• 重要信息被淹没在不相关的内容中
• 成本飞涨、延迟增加

层次混乱

• 把规则、知识、状态、记忆混在一起
• AI 无法区分哪些是约束、哪些是参考

时效失效

• 使用了过期的规则或状态
• 结果在错误的世界观里工作

输出物：上下文工程方案

1. 上下文层次设计：目标层、规则层、知识层、状态层、记忆层的定义和分工
2. 动态拼装规则：根据任务类型、用户角色、当前状态决定哪些层激活
3. 窗口与成本策略：如何在有限窗口内优化信息密度
4. 失败检测规则：如何判断上下文是否足够、是否过期、是否混乱
5. 更新与维护机制：上下文模板如何版本化、如何测试、如何回滚

使用方式

当用户提供任务场景时，自动执行：

1. 识别任务目标
2. 定义上下文五个层次
3. 设计动态拼装规则
4. 制定窗口与成本策略
5. 设计失败检测规则
6. 设计更新与维护机制
7. 输出上下文工程方案

示例

示例：AI 客服上下文工程设计

场景描述： AI 客服系统需要为不同咨询类型动态组织上下文，既要包含足够信息，又要避免信息过载。

用户输入： "我们的 AI 客服有时候给出的回答前后矛盾，有时候明明用户已经说了订单号，AI又问一遍"

Skill 执行流程：

1. 任务目标识别

用户咨询类型: "物流延误解释"
用户意图: 了解为什么订单还没到，什么时候能到
用户情绪: 轻度焦虑（从用词判断）

2. 上下文层选择

层次	内容	是否包含	原因
目标层	查询物流状态+解释延误	✅	核心任务
规则层	物流规则、赔付政策边界	✅	约束回复
知识层	物流公司合作政策、常见问题	✅	提供解释素材
状态层	已提供的订单号、已解释的内容	✅	避免重复询问
记忆层	用户偏好简洁解释	✅	个性化风格

3. 动态拼装示例

# 最终输入给模型的上下文

system_prompt: |
  你是电商平台客服助手。
  任务：帮助用户理解订单物流状态，提供准确的延误解释和预计时间。

目标层:
  用户问题: "我的订单怎么还没到？已经等了一周了"
  咨询类型: 物流延误解释
  用户情绪: 轻度焦虑

规则层:
  - 必须先核实具体的物流信息，不能泛泛而谈
  - 延误超过7天的订单，可主动提供补偿方案
  - 不可承诺具体的送达时间，只能提供预计范围
  - 涉及赔付的必须转人工确认
  - 保持安抚但专业的语气

知识层（检索到的相关资料）:
  [1] 物流合作方延误常见原因说明
  [2] 当前地区物流积压情况（官方公告）
  [3] 历史类似案例的有效安抚话术

状态层（当前会话）:
  订单号: 123456789
  物流状态: 运输中，当前在XX中转站
  最新轨迹: 2024-01-10 到达XX中转站（已停留3天）
  已解释内容: 无（首次询问）
  已提供的安抚: 无

记忆层:
  用户偏好: 简洁直接（基于历史会话）

4. 成本与窗口控制

总Token数: 约800 tokens
  - 系统提示: 100 tokens
  - 目标层: 100 tokens  
  - 规则层: 150 tokens
  - 知识层: 300 tokens（检索Top3）
  - 状态层: 100 tokens
  - 记忆层: 50 tokens

优化策略:
  - 知识层只取Top3最相关结果
  - 规则层优先显示高优先级约束
  - 状态层自动去重（避免重复信息）
  
成本控制:
  - 单次调用成本: ~$0.01
  - 响应时间: ~1.5s

5. 失败检测规则

检测项:
  - 上下文缺失: 检查是否包含必要的状态信息
  - 信息冲突: 检查规则层是否有矛盾约束
  - 上下文过期: 检查物流信息是否为最新（<24小时）
  - Token超限: 如果>2000 tokens，触发压缩策略
    
自动纠偏:
  - 如果缺少订单号 → 先询问订单号，不进入主流程
  - 如果物流信息过期 → 触发实时查询更新
  - 如果Token超限 → 只保留最核心的规则和知识

输出结果：

# 上下文工程方案：AI 客服

上下文层次定义:
  
  目标层:
    内容: [用户原始问题, 意图识别结果, 情绪分析, 咨询类型]
    来源: 实时分析
    优先级: 最高
    
  规则层:
    内容: [业务规则, 权限边界, 禁用操作, 语气要求]
    来源: 规则引擎（按咨询类型加载）
    优先级: 高
    
  知识层:
    内容: [检索到的相关资料, 案例, FAQ]
    来源: RAG检索（Top K=3）
    优先级: 中
    更新: 实时检索
    
  状态层:
    内容: [订单信息, 会话历史, 已解释内容, 已承诺事项]
    来源: 记忆系统
    优先级: 高
    生命周期: 当前会话
    
  记忆层:
    内容: [用户偏好, 历史问题模式]
    来源: 长期记忆
    优先级: 低

动态拼装策略:
  
  标准咨询（如物流查询）:
    包含: 目标层 + 规则层 + 知识层(Top2) + 状态层
    平均长度: ~600 tokens
    
  复杂咨询（如售后纠纷）:
    包含: 全部5层
    平均长度: ~1000 tokens
    
  简单咨询（如活动规则）:
    包含: 目标层 + 知识层(Top1) + 规则层（简化）
    平均长度: ~400 tokens

质量保证:
  - Token预算: 最大1500 tokens，超预算则压缩知识层
  - 重复检测: 自动去重（如订单号已明确不再重复放入）
  - 时效检测: 物流信息>24小时则触发更新
  - 冲突检测: 规则层如有矛盾，优先显示高优先级规则