AIPM Context Engineering指南：PM如何优化AI产品

来源：抖音 @Ai产品caicaicai

在AI Agent时代，Context Engineering的重要性日益凸显。工程师的视角关注上下文的存储、提取和压缩等技术问题，而产品经理（PM）的视角则更侧重于如何利用上下文来提升Agent的决策质量，最终达成用户任务。Context对于Agent而言，不仅是其工作的“工作台”，更是其输入决策系统，上下文的改变直接影响Agent的决策输出。

PM视角下的Context

PM在Agent时代的核心职责在于明确“需要什么样的Context才能让用户任务成功”，而非“Agent需要什么Context”。前者是用户视角，后者是系统视角。PM必须且始终站在用户视角来思考问题。

PM如何做好 Context Engineering

PM在进行Context Engineering时，应遵循以下四条核心原则：

原则一：分层设计

Context并非一股脑地塞进Agent的“大脑”，而应至少分为四层进行精细化管理，每层负责不同的职责，拥有不同的生命周期和刷新机制。

PM视角的Context四层架构：

• L1 意图层： 用户此次真正想要什么？(包含隐性约束)
  • 决定 Agent 的目标是否正确
• L2 任务层： 这件事的背景、约束、当前进度
  • 决定 Agent 知道自己在做什么
• L3 用户层： 这个用户的偏好、习惯、能力水平
  • 决定 Agent 用什么方式服务
• L4 系统层： Agent 当前可用的工具、权限、边界
  • 决定 Agent 能做到什么程度

分层的重要性：

不同的Context层级在出问题时的表现和优化方向均不同：

PM的职责是：定义每层context的加载条件。并非所有任务都需要全部四层加载。例如，用户查询天气只需要L4层（系统时间与位置），而撰写竞品分析报告则需要全部四层加载。对于“像上次那样处理”的需求，必须加载L2层的过去任务状态和关键信息记录。

一个可落地的动作是：针对每个功能场景，PM定义一张“Context需求表”，明确各功能场景下，哪些层级的Context是必须加载（✓）、禁止加载（X）或按需加载（△）的。

原则二：最小可用上下文

这是Context Engineering中最为重要且最易被忽视的原则。每条Context都会增加Agent的推理负担。在添加Context前，PM应自问：

1. 这条Context删掉，Agent这次任务会失败吗？
   • 如果不会失败，则删除（进入下一步）
   • 如果会失败，则必须保留，并记录原因。
2. 这条Context有其他Context可以替代吗？
   • 如果能用更轻量的方式替代（如用摘要替代全文），则替换。
   • 如果不能替代，则保留。
3. 这条Context在这次任务里，会被用到的概率有多高？
   • 低于20%则降级为“按需加载”，不默认注入。
   • 高于此则保留。

常见的反模式是，许多产品上线初期Context很干净，但随着时间推移，不断堆叠，最终导致混乱和推理噪声。PM必须守住Context的加入原则，即必须有“最小可用”的审查逻辑。不禁止添加，但添加前必须证明其必要性。

原则三：依据目标优化

Context的边界由任务目标决定，这句话有三层含义：

1. 任务目标决定Context的范围：

   • 快速得到答案： Context要精不多，核心事实即知即用。
   • 深度分析一个问题： Context要全不要漏，背景知识要充足。
   • 完成一个可交付的产出： Context要包含约束和标准，Agent需知晓完成后的具体形态。

   PM要问的：用户完成这个任务，Agent需要知道什么，才不会做错？

2. 任务目标决定Context的保真度要求：

   • 有些Context需要高精度（一个字都不能错），有些Context则允许概括（知道大概就行）。
   • 精确数字、日期、金额： 必须高保真，不能摘要。
   • 用户偏好、风格倾向： 可适度抽象。
   • 行业背景、通用知识： 可以用摘要。

   PM要问的：这条Context，如果被压缩/摘要，Agent还能做出正确决策吗？

3. 任务目标决定Context的时效性要求：

   • 实时行情、库存状态： 必须实时。
   • 用户的项目背景、已完成进度： 最近一次更新即可。
   • 用户的沟通风格偏好： 可相对稳定，不需要实时。

   PM要问的：这条Context，多久不更新就会开始影响决策质量？

原则四：生命周期管理

Context并非一次性加载即完事，它会经历“过期”、“漂移”、“冲突”三个阶段的“死亡”：

• 过期： 信息已不再准确。
• 漂移： Context越来越长，核心信号被淹没。
• 冲突： 新旧Context意思矛盾。

PM必须定义每层Context的生命周期：

Context污染的典型案例：

Agent在L2层保存了一个项目状态（上个月的状态），用户今天继续这个项目，但没有主动说“从这开始”，Agent就用着上个月的Context继续干活。结果是Agent在一个完全过期的项目背景下做决策，用户花了很多时间才发现。PM要设计的：L2Context的过期机制——长时间不更新的项目状态，必须在加载前提示用户“这是上次的状态，是否需要更新？”

闭环结构：Context优化的五步飞轮

Context Engineering不是一次性的工程搭建，而是PM持续管理的系统。它必须形成闭环，让Context体系随用户真实反馈持续进化。以下是Context优化的五步飞轮：

1. 定义Context策略： (分层 + 每层加载条件)
2. 测量核心指标： (召回率 / 信噪比 / 决策命中率)
3. 发现Context问题： (哪层出问题 / 什么问题类型)
4. 调整Context策略： (增删改某层Context)
5. 验证（真实流量）： (指标对比 + 用户满意度变化)
   • 回到1，持续迭代

PM的决策节点：什么时候该改Context策略？

飞轮不会自己转，PM要在三个节点上做出判断：

节点一：发现Context问题后——判断是改Context还是改系统

并非所有问题都是Context问题。以下情况，是Context策略的问题：

• 召回率低： L1/L2 Context没有注入到位。
• 信噪比低： L3/L4 Context给多了，需要按需加载。
• 决策命中率低： Context选对了，但Agent没有正确使用（不是Context问题，是Agent能力问题）。

PM要做的决定：这个问题是Context策略问题，还是Agent本身的Agent能力问题？

节点二：改Context策略后——判断是小改还是大改

• 单层调整： (加一条/删一条Context) -> 小改，直接上线验证。
• 加载逻辑变更： (某个任务类型的Context配置改了) -> 中改，A/B测试验证。
• 架构变更： (四层里某层的职责重新定义) -> 大改，需要完整回归测试。

PM要做的决定：这次调整的影响范围有多大？验证成本是多少？

节点三：验证结果出来后——判断进入下一轮还是接受现状

验证结果有四种：

数据飞轮：让Context体系自己进化

Context Engineering的终态是，让系统从真实用户行为中自动学习和优化。这需要构建三个自动化飞轮：

飞轮一：Context召回率自动优化

• 系统自动记录： Agent在哪个决策点引用了哪条Context。
• 自动分析： 哪条Context被引用频率极低，但一直加载着。
• 自动触发： PM审批后，下线低价值Context。

飞轮二：Context过期自动检测

• 系统检测： L2项目状态，多久没有更新？
• 自动提示： 用户开始新会话时，询问“上次项目的状态需要更新吗？”
• 自动刷新： 用户确认后，用新状态替换旧状态。

飞轮三：Context冲突自动告警

• 系统检测： 新注入的Context，是否和现有Context有语义矛盾？
• 自动告警： 告知PM“这两条Context意思相反，需要人工确认”。
• PM决策： 是删除旧的，还是更新新的，还是两条都保留但分开使用？

结语

Context Engineering不是一次性的工程搭建，而是PM持续管理的系统。PM在这件事上的核心职责，浓缩成三句话：

1. 什么Context，让这个用户的任务成功？(定义层)
2. Context是不是给得刚刚好，不多不少？(优化层)
3. Context体系是不是在持续变好，而不是持续变乱？(闭环层)

Context不是越多越好，最好的Context是Agent在最需要的那一刻，拿到了最对的那一段。做到了这一点，用户会说：“它懂我。”做不到这一点，用户会说：“我好像在哪里讲过这件事。”中间这段距离，就是PM真正该发力改进的地方。