首页 AI科技文章正文

从提示工程到上下文工程:AI Agent时代的核心能力跃迁

AI科技 2025年10月20日 06:14 0 admin

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

从提示工程到上下文工程:AI Agent时代的核心能力跃迁

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

从提示工程到上下文工程:AI Agent时代的核心能力跃迁

图片来自网络

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

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

1.1 定义演进

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

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

1.2 本质差异

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

从提示工程到上下文工程:AI Agent时代的核心能力跃迁

图片来自网络

上表格:

从提示工程到上下文工程:AI Agent时代的核心能力跃迁

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

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

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

其根源在于:

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

应对原则:

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

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

3.1 系统提示设计

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

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

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

从提示工程到上下文工程:AI Agent时代的核心能力跃迁

图片来自网络

例如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

本文由 @千林 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自 Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务

发表评论

长征号 Copyright © 2013-2024 长征号. All Rights Reserved.  sitemap