文章目录
一、“上下文工程”提出的时代背景
传统的人机交互方式,在 Software 1.0 时代依赖详尽的编程指令,在 Software 2.0 时代则依赖数据训练模型,而到了 Software 3.0 时代,我们开始使用 Large Language Models(LLMs)作为基本构建单元,构建 AI 应用。
然而,Karpathy 指出,这个新型操作系统——LLM——有其独有的“OS 特性”:
- 上下文窗口有限;
- 记忆力较短(只有“短期”内存与外挂数据,像 RAG);
- 容易产生幻觉、偏见,甚至被注入恶意指令;
- 如何让 LLM 稳定、可控、信任地执行复杂任务,已经成为这个范式的终极挑战。
顺势而生的,就是**“上下文工程”**。
Karpathy 在 Y Combinator AI 启动营上直言:
“我们不能继续使用‘提示词工程’这种术语了。它误导了人们对这些问题复杂性的理解。现在,我们正在进入真正构建软件系统的时代——也就是我看作 Software 3.0 的时代。”
二、上下文工程是什么?定义与构成
根据两篇文章的联合解读,上下文工程是构建和优化 LLM 应用中 LLM 所“看到”、“感知”到的一切信息与工具的系统过程。
它不仅仅是“那个提示你该输入什么”,而是:
- 一个系统,而非一个字符串:上下文是被精确动态构建、汇编出来的输入集;
- 动态生成的:没有一劳永逸的模板;
- 强调“时机”的重要性:什么时候呈现哪些信息、以什么格式;
- 强调“相关性”与“格式”:信息是否不当、分不清主次、结构是否清晰,将直接影响 LLM 的输出质量;
一句话概括:上下文工程,是一门在恰当时机、以恰当格式、提供恰当信息与工具的艺术与科学。
上下文包括哪些要素?
主要可分为以下几个层面:
上下文要素 | 具体举例 | 功能说明 |
---|---|---|
指令/系统提示(Instruction/System Prompt) | 系统角色设定、调用规则、示例 | 定义模型在当前任务中的行为策略与表现风格 |
用户查询(User Prompt) | 立即任务、用户说话 | 触发上下文组装与流程控制系统 |
状态/历史(State/History) | 对话记录、当前情景 | 帮助 LLM 理解对话流程,避免过度或疏离反应 |
长期记忆(Long-term Memory) | 用户偏好、历史任务、角色设定等 | 提供背景知识和个性化信息,使系统有‘记忆’ |
检索信息(Retrieval-Augmented) | 实时数据库查询、API调用结果 | 满足事实性要求,增加系统实时能力 |
可用工具(Available Tools) | 编排器、搜索、调用外部系统接口等 | 扩展 LLM 的“手眼”,实现任务闭环 |
结构化输出(Structured Output) | 输出应为 JSON、表格等结构化格式 | 规范输出格式,增强可控性 |
三、“上下文工程”为何是本次 AI 行业的核心突破?
在历史的长河中,AI 经历了从计算量驱动 → 参数量驱动 → 数据量驱动 → 到当前的 “上下文工程驱动”的范式转变:
- 解决智能体(Agent)构建的瓶颈
💡 两篇文章均指出:AI 智能体的失败,根本原因多不是模型能力不够(用户以为是模型不行,其实是上下文不对),而是“上下文质量不足”或“上下文配置错误”。
- 想象一个会议安排场景:没有背景记忆支持的 AI 可能会显得呆板无语,但提供了“历史邮件”“办公室日历”“语气设置”等上下文,助手就能自然、智能地回复。
- 大幅降低对“提示词”的依赖
过去,“提示词工程”是主要的玩法。但在真正的工业应用中,列出不同来源的信息、调整上下文结构,比单纯“如何设计 prompt”更加复杂也更加关键。
“提示词工程”只是上下文工程中的最浅层部分,背后涉及的数据抽取、计算调度、格式控制是一整套复杂工程。
- 应对模型自身“特性”的工具
LLM 被比喻为“有才华的傻子”——他们拥有超常的能力,但缺乏常识、长期记忆、行为验证机制。通过构建合适的上下文,人类正在引导 LLM 提升输出质量、降低风险、增强安全性。
- 推动向「可部署、可控、尽力智能」的迈进
把好软件工程的方法引入到 LLM 应用系统中,甚至模拟了传统操作系统的调度机制,使得部署可信、可扩展、可控 LLMAgent 成为可能。
Karpathy 并不希望“上下文工程”取代一切,而是想借它,来应对当前 LLM 应用中最棘手的部分,并构建上层应用。
四、上下文工程的创新与突破
这种范式转变带来了真正意义上的“工程化革命”:
1. 从提示到“叙事”:构建 AI 应用的范式跃迁
上下文工程改变了我们构建复杂任务的方式:
过去
:使用 prompt 询问:“帮我预订会议?”现在
:构建数据流、指令流、模型调用链,让 LLM 自然知道:- 目前对话中用户的意图
- 用户是否正在一个会议中
- 需要的工具是什么(预约系统、邮件接口、通知系统等)
如何降低这种上下文工程的复杂性?——工具如 dspy、llama-copilot 正在兴起。
2. 打破模型能力瓶颈,即刻获得可信“推理”
得益于上下文工程的完善,LLM 开始从“最大可能生成一切”进化为“基于可靠上下文推理”。即便模型本身容易产生幻觉,通过“切掉低质量上下文”、“引导参数输入”等方式,也能提升结论可信度。
3. 安全、对接、可控,成为可能
当构建了平衡的信息流后,不仅能降低模型幻觉,降低甚至消除提示注入攻击的风险,也可以测定输出结果的相关性,实时验证 LLM 是否在“循道而行”。
4. 开启软件即服务的新形态:充分感知用户场景
上下文越多、越智能,虚拟助理就不是简单重复问答,而是懂得用户工作流的人智能助手:
- 自动从日程中识别“本周有 Team A 的会议”;
- 从分布式系统中整合事件状态;
- 根据对话状态调整语调和行为方式。
甚至有人将上下文看作 AGI 最终拼图的核心:全面、高维度、动态的理解现实世界,是通向“强人工智能”的关键。
五、总结与未来
上下文工程是一场软件理念的大转变:
- 从“脚本化互动” → 转为“环境感知任务执行”;
- 从“临时提示” → 转为“工程系统建构”;
- 从“模型加数据” → 转为“模型 + 工程 + 数据上下文”的三方协作;
现在硅谷为何流行上下文工程?
因为进入 2025 年,AI 应用不再是“ChatGPT 网页版”,而是用户每天依赖的一线系统,而支持这些系统运行的不再是提示词,而是上下文工程这一隐藏在管道中的底层能力。
它的目标很明确:构建真正智能的 AI Assitant,而不是 Cot++ 大法的半成品。
“信息越相关,模型越好用 → 信息越精确,是我们叫停 ChatGPT 套壳的时机已经到来了。”
这不是一篇文章能说完的话题。
但,请注意:上下文工程,已被证明是当下构建强大、可靠 LLM 应用的真实路径。
它正在悄然重塑软件开发范式,甚至未来 AGI 的人机融合形态。
如果未来属于我们引导 LLM 去探索、构建与决策的 Software 3.0 世界,那么上下文工程,就是我们手中那把打开现实船只和想象力风帆的钥匙。🚀
2025-07-08(二)