gabrielmoreira AI Native 上下文工程 Skill
使用场景
- 产品需要组织复杂的输入信息交给模型
- 需要设计可解释、可替换、可治理的上下文组织方案
- 需要避免"上下文太少—AI不知道自己在做什么"或"上下文太多—AI被噪音淹没"
核心概念
- 上下文工程（Context Engineering）：把任务所需信息按正确顺序、粒度和边界组织给模型的产品化能力
- 提示词：上下文中的一小部分，通常只负责角色、任务或格式约束
- 动态拼装：根据用户、任务、权限和状态，为每次调用临时组装所需上下文
- 上下文层次：目标层、规则层、知识层、记忆层和状态层等不同信息层
为什么上下文工程是核心能力
传统软件的行为主要由代码逻辑决定，而 AI 系统的行为会显著受到上下文影响。相同的模型，在没有背景资料、缺少角色信息、拿不到历史状态的情况下，很可能给出完全不同的结果。
很多 AI 产品问题的本质，并不是模型不够强，而是上下文组织不对。
上下文工程流程
任务进入
→ 目标识别
→ 上下文层选择
→ 动态拼装
→ 生成 / 行动
→ 结果校验与纠偏
一旦上下文层选择错误，后面的生成质量、工具调用和风险边界都会整体失真。
上下文的五个层次
1. 目标层
- 用户现在到底想完成什么
- 例如："查询订单状态"、"申请退货"、"了解售后政策"
2. 规则层
- 这个任务有哪些约束、边界和权限
- 例如：不能承诺赔付、不能暴露其他用户信息、必须保留人工接管点
3. 知识层
- 系统需要引用哪些资料、文档、行业规则
- 例如：售后政策文档、物流规则、商品说明
4. 状态层
- 当前流程进行到哪里，已经做过什么
- 例如：当前会话已提供订单号、已解释过的内容
5. 记忆层
- 与用户或历史案例相关的长期背景
- 例如：用户偏好某种解释风格、过去类似问题的处理方式
这几层不是每次都全部打开，而是要根据任务动态拼装。
上下文工程的四个目标
- 选择真正相关的信息：不是把所有信息都塞进去
- 用模型易于理解的方式组织信息：顺序、结构、格式
- 在有限窗口内控制上下文成本：令牌消耗、延迟
- 随任务阶段动态更新上下文内容：不是固定模板
动态拼装原则
好的上下文不是固定模板，而是动态拼装：
- 根据用户角色决定哪些规则层可见
- 根据任务类型决定哪些知识层需要
- 根据当前状态决定哪些状态层包含
- 根据历史交互决定哪些记忆层激活
常见失败模式
上下文太少
- AI 不知道自己在做什么
- 结果偏题、幻觉、给出表面正确但实际不可用的结果
上下文太多
- AI 被噪音淹没
- 重要信息被淹没在不相关的内容中
- 成本飞涨、延迟增加
层次混乱
- 把规则、知识、状态、记忆混在一起
- AI 无法区分哪些是约束、哪些是参考
时效失效
- 使用了过期的规则或状态
- 结果在错误的世界观里工作
输出物：上下文工程方案
- 上下文层次设计：目标层、规则层、知识层、状态层、记忆层的定义和分工
- 动态拼装规则：根据任务类型、用户角色、当前状态决定哪些层激活
- 窗口与成本策略：如何在有限窗口内优化信息密度
- 失败检测规则：如何判断上下文是否足够、是否过期、是否混乱
- 更新与维护机制：上下文模板如何版本化、如何测试、如何回滚
使用方式
当用户提供任务场景时，自动执行：
- 识别任务目标
- 定义上下文五个层次
- 设计动态拼装规则
- 制定窗口与成本策略
- 设计失败检测规则
- 设计更新与维护机制
- 输出上下文工程方案
示例
示例：AI 客服上下文工程设计
场景描述： AI 客服系统需要为不同咨询类型动态组织上下文，既要包含足够信息，又要避免信息过载。
用户输入： "我们的 AI 客服有时候给出的回答前后矛盾，有时候明明用户已经说了订单号，AI又问一遍"
Skill 执行流程：
- 任务目标识别
用户咨询类型: "物流延误解释"
用户意图: 了解为什么订单还没到，什么时候能到
用户情绪: 轻度焦虑（从用词判断）
- 上下文层选择
| 层次 | 内容 | 是否包含 | 原因 |
|---|---|---|---|
| 目标层 | 查询物流状态+解释延误 | ✅ | 核心任务 |
| 规则层 | 物流规则、赔付政策边界 | ✅ | 约束回复 |
| 知识层 | 物流公司合作政策、常见问题 | ✅ | 提供解释素材 |
| 状态层 | 已提供的订单号、已解释的内容 | ✅ | 避免重复询问 |
| 记忆层 | 用户偏好简洁解释 | ✅ | 个性化风格 |
- 动态拼装示例
# 最终输入给模型的上下文
system_prompt: |
你是电商平台客服助手。
任务：帮助用户理解订单物流状态，提供准确的延误解释和预计时间。
目标层:
用户问题: "我的订单怎么还没到？已经等了一周了"
咨询类型: 物流延误解释
用户情绪: 轻度焦虑
规则层:
- 必须先核实具体的物流信息，不能泛泛而谈
- 延误超过7天的订单，可主动提供补偿方案
- 不可承诺具体的送达时间，只能提供预计范围
- 涉及赔付的必须转人工确认
- 保持安抚但专业的语气
知识层（检索到的相关资料）:
[1] 物流合作方延误常见原因说明
[2] 当前地区物流积压情况（官方公告）
[3] 历史类似案例的有效安抚话术
状态层（当前会话）:
订单号: 123456789
物流状态: 运输中，当前在XX中转站
最新轨迹: 2024-01-10 到达XX中转站（已停留3天）
已解释内容: 无（首次询问）
已提供的安抚: 无
记忆层:
用户偏好: 简洁直接（基于历史会话）
- 成本与窗口控制
总Token数: 约800 tokens
- 系统提示: 100 tokens
- 目标层: 100 tokens
- 规则层: 150 tokens
- 知识层: 300 tokens（检索Top3）
- 状态层: 100 tokens
- 记忆层: 50 tokens
优化策略:
- 知识层只取Top3最相关结果
- 规则层优先显示高优先级约束
- 状态层自动去重（避免重复信息）
成本控制:
- 单次调用成本: ~$0.01
- 响应时间: ~1.5s
- 失败检测规则
检测项:
- 上下文缺失: 检查是否包含必要的状态信息
- 信息冲突: 检查规则层是否有矛盾约束
- 上下文过期: 检查物流信息是否为最新（<24小时）
- Token超限: 如果>2000 tokens，触发压缩策略
自动纠偏:
- 如果缺少订单号 → 先询问订单号，不进入主流程
- 如果物流信息过期 → 触发实时查询更新
- 如果Token超限 → 只保留最核心的规则和知识
输出结果：
# 上下文工程方案：AI 客服
上下文层次定义:
目标层:
内容: [用户原始问题, 意图识别结果, 情绪分析, 咨询类型]
来源: 实时分析
优先级: 最高
规则层:
内容: [业务规则, 权限边界, 禁用操作, 语气要求]
来源: 规则引擎（按咨询类型加载）
优先级: 高
知识层:
内容: [检索到的相关资料, 案例, FAQ]
来源: RAG检索（Top K=3）
优先级: 中
更新: 实时检索
状态层:
内容: [订单信息, 会话历史, 已解释内容, 已承诺事项]
来源: 记忆系统
优先级: 高
生命周期: 当前会话
记忆层:
内容: [用户偏好, 历史问题模式]
来源: 长期记忆
优先级: 低
动态拼装策略:
标准咨询（如物流查询）:
包含: 目标层 + 规则层 + 知识层(Top2) + 状态层
平均长度: ~600 tokens
复杂咨询（如售后纠纷）:
包含: 全部5层
平均长度: ~1000 tokens
简单咨询（如活动规则）:
包含: 目标层 + 知识层(Top1) + 规则层（简化）
平均长度: ~400 tokens
质量保证:
- Token预算: 最大1500 tokens，超预算则压缩知识层
- 重复检测: 自动去重（如订单号已明确不再重复放入）
- 时效检测: 物流信息>24小时则触发更新
- 冲突检测: 规则层如有矛盾，优先显示高优先级规则