当前位置：首页 > news >正文

从提示工程（Prompt Engineering）到上下文工程（Context Engineering）

news 来源：原创 2025/6/27 16:12:34

概念革新：从“菜单点菜”到“仪器组装”

传统提示工程（菜单点菜）

本质：用户用自然语言描述需求（如“写一首春天的诗”）
局限：像在陌生餐厅点菜，依赖厨师（LLM）的理解能力

上下文工程（仪器组装）

本质：主动构建信息环境，让LLM在准确数据场中运行
核心组件：
- RAG → 实时知识库（传感器）
- 用户记忆 → 状态缓存（持续校准）
- 工具API → 外部设备接口（如计算器）
- 多模态数据 → 跨介质输入（图像/表格等）

类比：操作微芯片焊接机时，工程师需精确控制温度曲线（环境数据）、焊料供给（知识补充）、历史记录（操作日志）才能成功焊接

技术难点拆解：为什么这是科学？

精确信息配比公式

$\text{有效上下文} = \underbrace{\text{核心任务指令}}_{\text{1\%}} + \underbrace{\text{RAG结果}}_{\text{40\%}} + \underbrace{\text{工具参数}}_{\text{10\%}} + \underbrace{\text{状态记忆}}_{\text{30\%}} + \underbrace{\text{安全护栏}}_{\text{19\%}}$

案例：医疗诊断系统需包含：

context = ["任务：基于症状诊断疾病，输出ICD编码",  # 核心指令retrieve("患者病历：咳嗽3周"),           # RAG结果"工具说明：get_icd_code() 需传递症状列表", # 工具调用规范"历史：上次误诊因忽视吸烟史",             # 记忆校准"安全限制：不得建议未批准药品<guardrail>"  # 安全约束
]

动态压缩技术（解决信息过载）

技术方案：
方法原理压缩率
滑动窗口 保留最近N条对话 50-70%
语义摘要 GPT生成关键点梗概 80%↑
向量过滤 余弦相似度筛除低关联内容 60%

方法	原理	压缩率
滑动窗口	保留最近N条对话	50-70%
语义摘要	GPT生成关键点梗概	80%↑
向量过滤	余弦相似度筛除低关联内容	60%

工业级实践：DeepSeek系统用分层压缩——近期对话原文存储，3天前对话转向量索引

艺术性体现：LLM的“行为心理学”

▎隐式引导技巧

规避负面行为：
- 禁止说： “作为AI我无法...” ➔ 改为 “我们可通过查询FDA数据库解决此问题”
强化合作性：
- 注入协作痕迹：“参考用户上周建议，本次将优先考虑成本因素”

多代理协同设计

实战案例：摩根士丹利财富管理系统部署7个专项Agent分别处理税务/法规/市场数据

应用技术栈全景

在这里插入图片描述

关键模块说明

组件	作用	代表工具
上下文路由	分配任务到合适模型	LangChain RAGAs
记忆管理	维护用户状态历史	LlamaIndex
工具网关	桥接外部API（数据库/计算）	Microsoft Guidance
并行计算层	同时处理多请求	vLLM

为什么“套壳论”已过时？

现代LLM应用的技术复杂度已接近操作系统：

对比维度	ChatGPT交互	工业级LLM系统
上下文构建	单次对话框	动态知识图谱（>10种信息源）
任务处理	独立问答	多步骤工作流（依赖>3个模型）
资源消耗	1-2秒/请求	并行处理100+请求/秒
安全措施	基础内容过滤	合规审计+权限控制+数据脱敏

案例：SAP供应链系统通过上下文工程压缩90%人工审核，但背后需维护：

15个专用微调模型
实时连接ERP的RAG管道
动态合规规则引擎

上下文工程的本质

把LLM看作CPU——上下文工程就是为其设计：
1️⃣ 精准的输入设备（多源数据清洗）
2️⃣ 高效的内存管理（状态/记忆优化）
3️⃣ 安全的执行环境（工具/规则约束）
这需要融合系统架构设计、认知心理学、信息论的跨学科能力，绝非简单“套壳”。

当别人还在研究如何让CPU听懂人话时，真正的工程师已在设计整台计算机

技术演进背景

大模型应用正经历从问答机器人向智能体系统的范式迁移。早期依赖提示工程（Prompt Engineering）优化单次交互的方式，在复杂任务中显露出根本局限——当任务涉及多步骤决策、工具调用和长时记忆时，仅靠精心设计的提问语句如同让飞行员在迷雾中盲飞。这驱动技术焦点转向上下文工程，其本质是通过动态构建信息环境，为模型配备“全景驾驶舱”。

上下文工程的核心定义

上下文工程是构建动态信息生态系统的学科，需同时解决三大问题：

信息完备性：注入任务所需的全部要素
- 基础指令、历史交互、实时数据、领域知识、工具接口
- 工业案例：医疗诊断智能体需整合患者档案（记忆）、检验报告（实时数据）、诊疗指南（知识库）、药品数据库（工具）
结构可解析性：遵循机器可读的格式化表达
- 采用YAML/JSON-LD等结构化语言替代自然语言描述
- 关键设计：错误信息模板化（如{error_code}:{cause}比散文描述更有效）
系统实时性：建立动态响应管道
- 上下文窗口需在200ms内完成：记忆检索→工具调用→数据注入→格式优化

这要求工程师具备系统架构师思维，如同设计实时操作系统般构建信息流。

与传统提示工程的根本差异

提示工程追求“如何问得更好”，上下文工程解决“提供什么信息”。二者差异呈现在三个维度：

信息密度比：提示工程每token信息含量≤0.3bit（含大量修饰词），上下文工程可达2.7bit（结构化数据）
失败归因路径：
- 提示工程失败→调整问题表述
- 上下文工程失败→检查记忆检索覆盖率/工具API可用性/数据新鲜度
技术栈深度：
- 提示工程依赖文本模板
- 上下文工程需掌握：向量数据库索引优化、API网关路由、流式数据处理

典型案例对比：早期电商客服优化“请描述退货问题”提示词（提示工程），现代方案直接注入订单历史+物流状态+退改规则（上下文工程）。

技术实现框架剖析

工业级上下文引擎包含五层架构：

记忆层：向量数据库实现记忆压缩
- 采用Hierarchical Transformer将对话历史压缩至原长度15%
- 创新点：情绪标签索引（愤怒客户对话优先缓存）
工具层：原子化工具注册中心
- 每个工具自带Schema描述：工具名: 功能 | 输入格式 | 输出示例
- 最佳实践：工具响应自动转换为<tool_response format="markdown_table">
路由层：上下文感知的分流机制
- 基于任务复杂度选择模型：GPT-4处理多步推理，Claude-3处理长文档
安全层：动态护栏机制
- 金融场景植入实时合规检查：<compliance_check rule="SEC-2023-09">
呈现层：认知负荷优化
- 采用信息金字塔结构：结论→关键数据→原始证据

# 上下文引擎伪代码示例
def build_context(task, user):# 1. 装载基础任务框架ctx = TaskFramework(task) # 2. 注入个性化记忆ctx.inject(MemoryDB.query(user, task, top_k=3, recency_weight=0.7))# 3. 执行工具调用链if needs_calculation(task):ctx.inject(Calculator.execute(task))# 4. 动态格式优化return CognitiveOptimizer.format(ctx, style="technical_brief")

核心挑战与突破方向

当前面临三大技术瓶颈：

信息过载悖论
- 问题：注入过多上下文导致关键信息淹没
- 解法：研发基于LLM的实时摘要器（如Google的Context Distiller）
工具链协同时延
- 问题：API调用延迟破坏思维连贯性
- 创新：NVIDIA的推测执行引擎预生成候选响应
跨会话状态管理
- 问题：用户多轮对话中的状态漂移
- 方案：采用强化学习维护状态向量（如DeepMind的SMT模型）

突破性案例：Salesforce服务云将客户互动压缩为四维状态向量（情绪值/问题复杂度/专业知识/紧急度），使上下文构建效率提升18倍。

未来竞争制高点

上下文工程正催生新一代技术栈：

上下文感知芯片：Groq LPU加速记忆检索
企业知识操作系统：如Microsoft Fabric实现上下文即服务
标准化接口协议：类似OpenTelemetry的Context Trace规范

工业界趋势表明：2025年头部AI企业将把60%研发预算投入上下文工程建设，该领域人才溢价已达薪资基准的2.3倍。当模型能力趋于同质化，上下文质量成为核心护城河——如同云计算竞争中，数据中心架构决定最终胜负。

本质重构：从交互设计到认知架构

上下文工程标志AI开发范式的根本转变：

过去：视LLM为“魔术盒”，专注Prompt设计
现在：将LLM看作“CPU”，构建完整计算机系统
其终极目标是创建机器可感知的现实镜像——通过精准还原决策场景，释放大模型的推理潜能。这要求工程师掌握新型技能树：数据库优化、分布式系统、认知心理学，乃至人机协作哲学。当技术社区从追求提示词技巧转向构建上下文架构，我们正见证AI工程学的成年礼。

在这里插入图片描述

[1] Dex Horthy. 12-Factor Agents - Principles for building reliable LLM applications. (https://github.com/humanlayer/12-factor-agents/blob/main/content/brief-history-of-software.md)
[2] Dex Horthy. Context Engineering vs. Prompt Engineering: Guiding LLM Agents. (https://www.youtube.com/watch?v=mldfMWbnZTg)
[3] LangChain Team. The rise of “context engineering”. (https://blog.langchain.com/the-rise-of-context-engineering/)
[4] Hailey Joren, et al. Sufficient Context: A New Lens on Retrieval Augmented Generation Systems. (https://arxiv.org/abs/2411.06037)
[5] Walden Yan. Don’t Build Multi-Agents. (https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering)
[6] Dex Horthy. Own your context window. (https://github.com/humanlayer/12-factor-agents/blob/main/content/factor-03-own-your-context-window.md)

https://mp.weixin.qq.com/s/nyD5Vc59FYO_ZUD8fSquJw

技术演进：从交互优化到系统重构

大模型应用的成熟期正暴露传统方法的根本局限。早期以提示工程（Prompt Engineering） 为核心的优化路径，本质是通过语言技巧引导模型行为。这如同为驾驶员提供更精确的导航指令，但当任务复杂度升级至跨时态决策（如多轮医疗诊断）、动态环境响应（如实时金融风控）时，单纯优化“如何提问”已触及天花板。Dex Horthy在《12-Factor Agents》中的实证揭示：依赖工具调用循环（Tool Calling Loop）的智能体在10-20轮交互后崩溃率超90%，核心症结在于上下文熵增——混乱的信息堆积导致模型认知过载。这标志技术焦点必然转向上下文工程，其目标是通过动态信息生态的精密控制，将模型的“认知负担”转化为“决策优势”。

核心矛盾：概率世界与确定需求的碰撞

上下文工程兴起的底层逻辑源于三重结构性矛盾：

模型本质的随机性
LLM的next-token预测机制本质是概率采样。当任务涉及长链条推理（如法律合同审查），微小概率偏差会随步骤累积引发决策漂移。Google论文《Sufficient Context》验证：即使提供充分信息，GPT-4在医疗诊断中的幻觉率仍达7.3%；而缺失关键数据时，模型却能通过模式匹配“蒙对”结果——这种不确定性无法通过提示词消除。
信息管道的不可控性
Nate Jones提出的概率性上下文（Probabilistic Context） 概念揭示：当智能体接入搜索引擎、API工具等外部系统时，返回数据质量波动极大。例如电商价格监控Agent调用爬虫API，可能因网站改版获取残缺HTML，导致后续解析失效。此类噪声在传统提示工程框架下无法根治。
工程交付的可靠性需求
企业级应用要求99.99%的稳定运行率。当智能体在10%场景崩溃（如误关闭客户工单），损失远超效率收益。这要求构建确定性信息护栏——类似飞机黑匣子的实时监控系统，在上下文熵增临界点触发干预机制。

范式跃迁：从语言技巧到系统工程

上下文工程的本质是构建机器可感知的决策沙盘，其技术框架包含三层架构革新：

动态分层信息流
- 确定性层（Deterministic Context）：工程师预设的任务指令、业务规则、格式规范。
  案例：银行风控Agent的“转账金额超5万需二次验证”规则硬编码为JSON Schema注入。
- 概率性层（Probabilistic Context）：外部工具返回的实时数据（如天气API）、RAG检索结果。
  创新设计：为API响应添加置信度标签 <api_response confidence=0.82>，供模型加权参考。
- 记忆层（Context Memory）：向量数据库实现的对话状态压缩。
  技术突破：采用Key-Value注意力机制，将30轮对话压缩至原长度12%且保留决策关键因子。
信息密度引擎
核心指标是单位Token有效信息量（Effective Information per Token, EIT）。工业级系统要求EIT≥1.8bit（传统提示词仅0.3-0.5bit）。实现路径包括：
- 结构化脱糖（Structured Desugaring）：将自然语言描述转为机器友好格式
```
# 低EIT：请解释用户情绪波动原因  
# 高EIT：<sentiment_trend value="anger" delta="+43%" trigger="payment_failed">  
```
- 增量更新协议：仅传递上下文差异量（类似Git Diff），Salesforce实测减少78%冗余Token。
失效熔断机制
当系统检测到上下文混乱指数（Chaos Index）超标时，自动触发：
- 状态回滚：还原至最近稳定对话快照
- 工具链路切换：例如从通用搜索引擎切至企业知识库
- 人工接管申请：发送高优先级告警至运维台

与传统提示工程的分水岭

两者的本质差异体现在四个维度：

维度	提示工程	上下文工程
优化对象	单次输入文本	跨会话信息生态
技术栈	文本模板+关键词替换	向量DB+API网关+状态机
失败归因	模型不理解指令	信息管道失效或记忆污染
核心指标	输出相关性（ROUGE）	任务完成率（Task Completion Rate）

典型案例对比：

提示工程方案：通过添加“逐步思考”提升数学题解答能力，但面对动态数据（如实时股票分析）仍会崩溃。
上下文工程方案：构建三层信息流——
1. 确定性层注入金融公式模板
2. 概率性层接入Bloomberg实时行情（带数据校验）
3. 记忆层缓存用户风险偏好
  实现97%的跨会话任务完成率。

工业级落地：从理论到实践

领先企业正通过三阶段路径推进上下文工程：

上下文感知硬件
Groq LPU芯片新增Context Management Unit (CMU)，专责上下文压缩/解压，使128K上下文加载延迟从秒级降至毫秒级。
企业知识操作系统
Microsoft Fabric集成：
标准化协议
新兴Context Trace协议（类似OpenTelemetry）定义：
- 上下文版本号（Context Versioning）
- 信息源元数据（Provenance Tracking）
- 熵增监控指标（Entropy Metrics）

某跨国银行部署上下文工程后关键收益：

客服工单处理轮次从平均18轮降至9轮
长周期任务崩溃率从11.2%降至0.3%
合规风险事件减少92%

未来竞争制高点：信息效率革命

当模型能力趋于同质化，上下文质量成为决定性变量。这引发三重新型竞争：

信息密度竞赛
Anthropic的Token熵压缩算法Claude 3.5将EIT提升至2.4bit，使同等上下文窗口支持3倍复杂任务。
实时性突破
NVIDIA推测执行引擎预生成上下文分支路径，使工具调用延迟从2.1秒降至0.4秒。
确定性增强
Google的Context Distiller模块通过强化学习过滤噪声信息，将概率性上下文的失效概率降低67%。

本质重构：AI开发的范式迁移

上下文工程标志大模型应用从魔术时代迈入工程时代：

过去：视LLM为神秘黑盒，依赖咒语般提示词
现在：将LLM看作可编程CPU，通过精密信息流控释放潜能
这要求工程师掌握新型技能树——不仅是机器学习，更需精通分布式系统（管理上下文状态）、信息论（优化EIT）、人因工程（设计认知动线）。当技术社区从追求提示词技巧转向构建上下文架构，我们正见证AI工程学的真正成熟：以确定性框架驾驭概率性智能。