提示工程只是起点，真正的跃迁在于“上下文工程”。本文系统梳理AI Agent时代的能力结构，从提示构造、上下文调度到任务协同，帮助产品人理解如何在“能力不确定”中构建“表达清晰”的产品机制，实现从工具到智能体的角色转变。

Claude Sonnet 4.5发布时，Anthropic也发了一篇文章讲了一下“上下文工程”，他认为随着AI进入Agent时代，构建语言模型的重点正在从“为提示找到正确的词语和短语”转向一个更大的问题：“什么样的上下文配置最有可能产生我们期望的模型行为？”，结合他的观点为基础我也查阅了一些资料，尝试着写下这篇文章，供大家交流指正。

图片来自网络

一、范式革命：为什么上下文工程是AI Agent时代的必修课？

随着Claude、GPT等大模型从“对话工具”进化为“自主Agent”，行业焦点正从单轮交互优化转向持续认知系统设计。Anthropic在最新研究中指出：上下文窗口已成为AI Agent的核心动力源，但其稀缺性与Transformer架构的“注意力预算稀释效应”形成根本矛盾。

1.1 定义演进

提示工程（Prompt Engineering）：聚焦单轮指令设计，通过精炼系统提示（System Prompt）获取理想输出，本质是“语言调优”。

上下文工程（Context Engineering）：管理模型推理时的全量信息流，包括系统指令、工具API、外部数据、历史对话等，目标是构建动态信息生态系统。

1.2 本质差异

用一张对比图展示二者的区别：

图片来自网络

上表格：

案例：电商客服Agent若仅依赖提示工程，可能因无法调用订单数据库而给出错误回复；上下文工程则需整合用户历史订单、退换货政策、实时库存等模块。

二、技术底层：为什么上下文窗口会“腐烂”？

Anthropic揭示的“Context Rot”现象指出：随着上下文长度增加，模型召回关键信息的能力显著下降。

其根源在于：

1. n²关系复杂度：Transformer需为每个token计算与其他所有token的关联，窗口扩大时计算资源被摊薄；
2. 注意力漂移：长文本中模型易被冗余信息干扰，类似人类“走神”。

应对原则：

1. 黄金信噪比法则：用最少token承载最大信息量，如用“ZARA代工厂”替代“厂房面积5000㎡”的表述；
2. 动态剪枝策略：实时淘汰低价值信息，如清理过时的工具调用记录；

三、实战三板斧：构建高效上下文系统的核心组件

3.1 系统提示设计

系统提示是门艺术，需在刚性与柔性间找平衡，避免两个极端

• 过度具体：硬编码复杂逻辑，如强制要求客服Agent按7步流程处理投诉导致脆弱性；
• 过度模糊：仅提供“保持专业”等泛化指导，缺乏行为锚点，简单来讲就是只给出高级别的、模糊的指导，无法为LLM提供具体的行为信号。

最佳实践：找到一个“黄金区域”：指令既要足够具体以有效指导行为，又要足够灵活以赋予模型强大的启发式能力。Anthropic建议模块化指令结构（背景+角色+边界），其核心原则是：力求用最精简的信息，来完整地阐明预期的行为。

图片来自网络

例如Claude面包店客服的提示设计：

# 角色：Claude面包店专属客服

## 核心职责：

1. 解决订单查询/退换货问题（优先使用`order_lookup`工具）

2. 回答产品成分/配送范围等基础问题

## 边界：

– 不承诺超出公司政策的要求

– 涉及食品安全问题立即转人工（触发`escalate_to_human`）

“`[1](@ref)

3.2 工具设计：像开发API一样严谨

优秀工具需符合代码库设计原则：

1）功能内聚：单个工具只解决一类问题，如get_user_order不混入支付功能；

2）鲁棒性：明确处理异常输入，如订单ID无效时返回标准错误码；

案例对比：

• 失败设计：臃肿的“万能工具”导致Agent混淆，如handle_order同时处理查询/退换/投诉；
• 成功设计：阿里电商后台的微服务化工具集（分层管理商品/订单/用户模块）

3.3 Few-shot示例：质量＞数量

错误做法：堆砌边缘案例，如20种退换货特殊情况导致注意力分散；

正确策略：精选3-5个范式级示例，例如：

#优秀示例：退换货流程

用户输入：”收到的蛋糕融化变形了”

Agent行为：

1. 调用`verify_order_status(order_id)`确认签收时间

2. 若＜48小时，触发`refund_process`并发送补偿优惠码

3. 回复模板：”非常抱歉！已为您发起退款，新优惠码已发放至账户。”

“`[1](@ref)[4](@ref)

四、高阶战术：长周期任务的三大解决方案

当任务周期（如产品需求文档编写）超过单次上下文容量时，需采用混合策略：

4.1 压缩策略

• 适用场景：高频对话型任务，如用户访谈记录整理；
• 操作：让模型自主提炼关键信息，如将10轮对话压缩为“用户核心痛点：支付流程步骤过多”；

4.2 结构化笔记

• 案例：Claude玩《宝可梦》时自动生成的地图/待办列表，重启后仍可延续进度;
• 产品化应用：会议纪要–>转化为PRD需求池;竞品分析–>结构化对比矩阵

4.3 子智能体架构

• 模式：主Agent–>负责需求优先级排序，如使用MoSCoW法则；子Agent–>专注技术可行性验证，如调用check_api_feasibility工具；
• 优势：避免单Agent同时处理战略（做什么）与战术（怎么做）导致的认知过载

五、对产品经理的启示

1. 重新定义需求档：将上下文视为“产品”，明确信息输入源，如哪些数据需实时检索而非预加载；
2. 工具设计方法论：参照API文档标准编写工具说明，包括输入校验、错误码定义等
3. 构建记忆系统：为Agent设计“经验仓库”，如自动归档高频用户问题及解决方案；
4. 策略组合选择：

• 简单任务：压缩+少量示例
• 复杂项目：子智能体+结构化笔记

随着即时检索技术成熟，上下文工程将更趋近人类“按需记忆”模式——产品经理需像设计信息架构一样，规划Agent的认知路径。

参考文献

1. Anthropic. Effective Context Engineering for AI Agents. 2025

2. Khalid Saleh. 提高内容转化率的13种技巧. 2016

3. 如何将技术文章转化为产品经理视角. 2025

4. 大厂PM精华贴：产品经理新人如何成长为高阶玩家. 2020

5. 友盟+陈新祥：用数据驱动产品迭代. 2021