大家好，我是 dtsola【IT解决方案架构师 | AI创业者】。
今天我想和大家分享一篇来自 Chris Loy 的精彩内容——《Context engineering Part of Machine Learning for Engineers》。作为一名长期从事解决方案架构设计和AI应用开发的从业者，我深刻感受到当前LLM应用开发正在经历一场重要的范式转变。
为什么要分享这篇内容？
在过去一年多的时间里，我们见证了大语言模型从实验室走向生产环境的快速演进。然而，许多开发者仍然停留在"提示工程"的思维模式中——通过反复试错来寻找"魔法咒语"，期望LLM给出理想的答案。这种方法不仅效率低下，更难以构建可靠、可维护的生产级系统。
Chris Loy 的这篇文章系统地阐述了"上下文工程"（Context Engineering）这一新兴实践，它代表了我们使用LLM方式的根本性转变。作为架构师和创业者，我认为这些理念对于构建真正可用的AI系统至关重要，因此希望通过这篇文章与大家分享这些宝贵的见解。
目录
一、引言：从提示工程到上下文工程的演进
提示工程的局限性
上下文工程的兴起
贯穿全文的示例
二、理解LLM的基础：上下文窗口
2.1 什么是上下文窗口
2.2 LLM的训练与推理机制
2.3 早期应用模式：文本补全
三、聊天框架（Chat Framing）的突破
3.1 聊天模式的引入
3.2 上下文窗口的丰富化
3.3 架构本质未变
四、提示工程时代及其局限
4.1 提示工程的实践
4.2 提示工程的问题
五、上下文学习（In-Context Learning）
5.1 什么是上下文学习
5.2 可编程注入的多种token序列
5.3 上下文窗口的挑战
5.4 从提示工程到上下文工程
六、思维转变：从神谕到分析师
6.1 LLM的本质能力
6.2 使用LLM的思维转变
6.3 实践中的转变
七、智能体行为的上下文工程
7.1 实例：英国电影票房周均收入查询
7.2 上下文工程的多个维度
7.3 设计模式的必要性
八、RAG：上下文工程的一种模式
8.1 什么是RAG
8.2 RAG作为上下文工程模式
8.3 实现考虑
8.4 从RAG到设计模式
九、设计模式：组合优于继承
9.1 软件工程设计模式的启示
9.2 上下文工程的设计模式
9.3 模式的组合应用
十、扩展到多智能体系统
10.1 多智能体架构的必然性
10.2 多智能体电影排名系统示例
10.3 智能体间的交互
十一、总结与实践指南
11.1 上下文工程的定义
11.2 四大核心原则
11.3 实践意义
一、引言：从提示工程到上下文工程的演进
随着大语言模型（LLM）的应用场景从简单的对话聊天机器人转变为复杂系统中不可或缺的决策组件，我们的推理方法也必须随之演进。
提示工程的局限性
"提示工程"（Prompt Engineering）的实践方式是向LLM提交精确措辞的文本，以期获得理想的响应。但这种方法存在严重的局限性：
过度依赖试错和猜测
缺乏系统性和可重复性
难以应对复杂的业务场景
无法保证输出的稳定性
上下文工程的兴起
这种局限性正在催生一种更通用的实践——以更动态、更有针对性、更深思熟虑的方式，考虑输入到LLM中的每一个token。这种扩展的、更结构化的实践，就是我们现在所说的"上下文工程"（Context Engineering）。
贯穿全文的示例
为了更好地理解这些概念，我们将使用一个简单的例子：如何让LLM帮助我们回答一个主观问题——"最佳科幻电影是什么？"
二、理解LLM的基础：上下文窗口
2.1 什么是上下文窗口
LLM是一种机器学习模型，它通过将语言建模为token序列，并从大规模数据集中这些token共现的模式中学习其含义，从而理解语言。
模型能够理解的token数量对于每个模型来说是一个固定值，通常在数十万级别，这被称为上下文窗口（Context Window）：
LLM是理解token序列的模型
2.2 LLM的训练与推理机制
训练过程
LLM通过反复接触连贯的token序列进行训练——通常是从互联网抓取的大型文本数据库。在训练过程中，模型学习token之间的关系和模式。
推理过程
训练完成后，我们通过运行"推理"（即预测）来使用LLM，基于序列中所有先前的token来预测下一个token。这个先前token的序列就是我们过去所说的提示（Prompt）：
在推理时，它们逐个生成新的token
推理过程通过每次向序列中添加一个高概率的token来延续token序列。
2.3 早期应用模式：文本补全
当被提示完成句子"the best sci-fi film ever made is..."时，生成的最高概率token可能是 probably、star 和 wars。
补全模式的局限性
LLM的早期应用专注于这种"补全"模式，接受部分编写的文本，并根据期望的方向逐个预测后续token以完成文本。虽然在当时令人印象深刻，但这种方式在多个方面存在局限，包括难以精确指导LLM如何完成文本。
三、聊天框架（Chat Framing）的突破
3.1 聊天模式的引入
为了解决补全模式的局限性，模型提供商开始训练他们的模型，使其能够理解框架化对话的token序列，并插入特殊token来指示两个说话者之间的切换。
通过学习在生成补全时复制这种"聊天"框架，模型突然在对话环境中变得更加可用，因此也更容易被指导：
大多数模型被调优为在聊天模式下操作
3.2 上下文窗口的丰富化
上下文窗口开始被不同类型的消息更充分地填充：
系统消息（System Messages）：告诉LLM该做什么的特殊指令
聊天历史：来自用户的消息和LLM自身的响应
实际应用示例
通过聊天框架，我们可以在"询问"最佳科幻电影之前，先指示LLM它是"一位电影评论家"。也许我们现在会得到 blade 和 runner 这样的响应token，因为AI扮演的角色更可能反映评论界而非大众的共识。
3.3 架构本质未变
这里需要理解的关键点是：LLM的架构并没有改变——它仍然只是一次预测一个token。但它现在是基于从训练数据集中学到的世界观来进行预测，这个训练数据集将一切都框架化为带分隔符的来回对话，因此模型会始终如一地以相应方式响应。
四、提示工程时代及其局限
4.1 提示工程的实践
在聊天框架的环境下，充分利用LLM涉及找到完美的提示token序列以获得最佳补全。这就是所谓"提示工程"的诞生。
然而，在实践中，往往远不及"工程"那么系统化，更多的是试错和猜测。
4.2 提示工程的问题
这种方法常常感觉更像是念诵神秘咒语并期待魔法发生，而不是真正工程所体现的深思熟虑的构建和系统思维的严格应用。
示例：优化系统提示
我们可能会尝试用更聪明的系统提示来促使AI反映评论界共识，比如：
"You are a knowledgeable and fair film critic who is aware of the history of cinema awards."
（你是一位知识渊博且公正的电影评论家，了解电影奖项的历史。）
我们可能希望这会"欺骗"LLM生成更准确的答案，但这种希望建立在语言概率之上，无法提供任何保证。
五、上下文学习（In-Context Learning）
5.1 什么是上下文学习
随着LLM变得更智能、更可靠，我们能够向它们提供更复杂的token序列，涵盖不同类型的结构化和非结构化数据。
这使得LLM能够产生基于提示中新颖结构的"知识"补全，而不仅仅是从训练数据集中记住的模式。这种向LLM提供示例的模式被称为上下文学习（In-Context Learning），因为LLM似乎纯粹基于其上下文窗口中的示例序列来"学习"如何产生输出。
5.2 可编程注入的多种token序列
这种方法导致我们可能以编程方式在提示中包含的不同token序列呈爆炸式增长：
1. 硬编码示例
来自我们知识领域的示例（文档、人类或生成来源的优质输出示例、玩具示例）
鼓励可预测的输出
2. 非文本模态
表示图像、音频或视频的token
直接作为上下文窗口的一部分，或先转录为文本然后token化
3. 工具和函数调用
定义外部函数，LLM可以告诉调用者调用这些函数以访问外部世界的数据或计算
4. 文档和摘要
通过"RAG"从数据源返回，或由用户上传
向LLM提供其训练数据集之外的知识
5. 记忆和对话历史
浓缩先前聊天的信息
允许单个用户与"聊天机器人"在多次对话之间保持连续性
科幻电影示例的应用
在我们的科幻电影示例中，提示可以包含许多内容来帮助LLM：
历史票房收入
各种出版物的百大电影榜单
烂番茄评分
奥斯卡获奖者的完整历史
等等
5.3 上下文窗口的挑战
突然间，我们那100,000+的上下文窗口看起来不再那么慷慨了，因为我们用来自各种地方的token填充它：
但完整的上下文可以由调用者控制
面临的问题
这种上下文的扩展不仅会耗尽可用于输出生成的上下文窗口，还会增加LLM在任何时刻关注内容的整体占用空间和复杂性。这进而增加了失败模式（如幻觉）的风险。
因此，我们必须开始以更细致的方式来处理其构建——考虑简洁性、相关性、时效性、安全性和其他因素。
5.4 从提示工程到上下文工程
在这一点上，我们不再仅仅是在做"提示工程"了。我们开始工程化生成发生的整个上下文。
六、思维转变：从神谕到分析师
6.1 LLM的本质能力
语言编码知识，但它也编码意义、逻辑、结构和思维。
训练LLM来编码世界上存在什么的知识，并能够产生描述它的语言，因此也产生了一个能够模拟思考的系统。事实上，这是LLM的关键效用，而要利用它需要我们在如何进行推理方面进行思维转变。
6.2 使用LLM的思维转变
旧思维：LLM作为神谕（Oracle）
带着问题接近它
用喃喃的咒语向它祈祷
等待智慧的降临
新思维：LLM作为分析师（Analyst）
向他们提供所有相关信息以供筛选
清晰准确地定义手头的任务
记录完成任务可用的工具
避免依赖过时的、不完美记忆的训练数据
上下文工程将LLM重新定位为分析师，而非神谕
6.3 实践中的转变
在实践中，我们对LLM的集成从"精心设计完美提示"转变为精确构建完成手头任务所需的恰当token集。
管理上下文成为一个工程问题
LLM被重新定位为一个任务解决器，其输出是自然语言
七、智能体行为的上下文工程
7.1 实例：英国电影票房周均收入查询
让我们考虑一个简单的问题，你可能希望LLM为你回答：
"英国电影院的平均每周票房收入是多少？"
"神谕模式"的问题
在"神谕"模式下，我们的LLM会乐于引用从其截止日期之前的训练数据集中学到的值：
"截至2019年，英国票房平均每周收入约为2400万英镑。"
这个来自GPT 4.1的答案是准确的，但不精确且过时。
上下文工程的解决方案
通过上下文工程，我们可以做得更好。考虑在生成响应的第一个token之前，我们可能向上下文窗口中输入哪些额外的上下文：
当前日期，以便使用更新的统计数据（GPT 4.1认为现在是2024年6月）
实际发布的统计数据，如这篇BBC新闻文章
如何告诉调用者进行除法运算的说明
以上内容应该足以让LLM知道如何：
查找2024年的数据
从文档中提取9.79亿英镑的总数字
调用外部函数精确地将其除以52周
假设调用者随后运行该计算并再次调用LLM，提供所有上述上下文，加上它自己的输出，再加上计算结果，我们将得到准确的答案：
"在2024年全年，英国票房平均每周收入为1880万英镑。"
7.2 上下文工程的多个维度
即使这个简单的例子也涉及在生成答案之前通过多种方式工程化上下文：
声明当前日期和期望结果
搜索并返回相关文档
记录可用的计算操作
用中间结果扩展上下文
7.3 设计模式的必要性
幸运的是，我们不需要每次都发明新的方法。我们可以借鉴软件工程中的设计模式思想。
八、RAG：上下文工程的一种模式
8.1 什么是RAG
检索增强生成（Retrieval-Augmented Generation，RAG）是一种流行的技术，用于在推理时将外部知识注入上下文窗口。
撇开如何识别要包含的正确文档的实现细节不谈，我们可以清楚地看到，这是上下文工程的另一种特定形式：
RAG只是上下文工程的一种模式
8.2 RAG作为上下文工程模式
这是一种有用且显而易见的方式，可以在需要访问训练数据集之外知识的上下文中使用预训练的LLM。
在科幻电影示例中的应用
为了获得正确的答案，我们的应用程序需要了解最新的电影评论、评分和奖项，以跟踪模型训练后的新电影和评论意见。
通过在上下文窗口中包含相关摘录，我们使LLM能够使用今天的数据生成补全，并避免幻觉。
8.3 实现考虑
要做到这一点，我们可以搜索相关文档，然后将它们包含在上下文窗口中。
如果这在概念上听起来很简单，那是因为它确实如此——尽管可靠的实现并非易事，需要稳健的工程。
8.4 从RAG到设计模式
复杂的系统可能是脆弱的，构建起来也不透明。我们需要一种方法来扩展复杂性，而不损害我们维护、调试和推理代码的能力。
幸运的是，我们可以应用传统软件设计用来解决同样问题的思维方式。
我们可以将RAG视为上下文工程的众多设计模式中的第一个。就像其他软件工程设计模式一样，未来我们会发现，大多数复杂系统必须采用这些模式的变体和组合才能最有效。
九、设计模式：组合优于继承
9.1 软件工程设计模式的启示
在软件工程中，设计模式通过为常见设计问题提供经过验证的通用解决方案来促进可重用软件。
核心原则：组合优于继承
设计模式鼓励组合优于继承（Composition over Inheritance），这意味着系统是由更小的、可互换的组件构建的，而不是刚性的类层次结构。
设计模式的价值
它们使你的代码库更加：
灵活
可测试
易于维护或扩展
它们是软件设计工具包的关键部分，使工程师能够构建可以随时间扩展的大型功能代码库。
传统软件工程设计模式示例
Factory（工厂模式）：标准化对象创建，使隔离测试更容易
Decorator（装饰器模式）：在不编辑原始代码的情况下扩展行为
Command（命令模式）：将工作作为值传递，类似于lambda函数
Facade（外观模式）：用简单的接口隐藏内部细节以促进抽象
Dependency Injection（依赖注入）：使用配置在外部连接模块
9.2 上下文工程的设计模式
这些模式是在很长一段时间内发展起来的，尽管许多模式最初是在一本书中编纂的。
上下文工程是一个新兴领域，但我们已经看到一些常见模式的出现，这些模式使LLM很好地适应某些任务：
9.3 模式的组合应用
在我们上面的示例中，我们已经使用了其中一些模式：
RAG：获取电影评论、评论家榜单和票房数据
工具调用：精确计算每周收入
其他技术的应用
其他一些技术，如ReAct，可以帮助我们的LLM更仔细地构建和验证其响应，抵消从训练数据中学到的语言概率的权重。
设计模式的优势
通过将每种技术视为上下文工程设计模式，我们能够：
为手头的任务选择正确的模式
将它们组合成一个"智能体"
避免损害我们测试和推理代码的能力
十、扩展到多智能体系统
10.1 多智能体架构的必然性
依赖LLM进行决策和行动的生产系统将自然地演化为具有不同专业化的多个智能体：
安全防护（Safety Guardrails）
信息检索（Information Retrieval）
知识提炼（Knowledge Distillation）
人机交互（Human Interaction）
等等
每个智能体都是一个组件，它解释任务，然后返回指示要采取的行动、检索到的信息或两者兼有的token序列。
多智能体系统相互提供上下文
10.2 多智能体电影排名系统示例
对于我们的多智能体电影排名系统，我们可能需要几个智能体：
1. 聊天机器人智能体（Chatbot Agent）
维护与用户的对话
2. 安全智能体（Safety Agent）
检查用户是否有恶意行为
3. 偏好智能体（Preference Agent）
回忆用户是否想忽略某些评论
4. 评论家智能体（Critic Agent）
综合来源并做出最终决定
10.3 智能体间的交互
专业化的实现
每个智能体都针对特定任务进行专业化，但这可以纯粹通过工程化它们消费的上下文来完成，包括系统中其他智能体的输出。
智能体间的契约
输出随后在系统中传递，并进入其他智能体的上下文窗口。在每一步，需要考虑的关键方面是：
生成token序列的模式
一个智能体的输出如何被用作另一个智能体完成自己任务的上下文
交接token序列实际上是智能体交互的契约——对它应用与你对软件架构中任何其他API相同的严谨性。
十一、总结与实践指南
11.1 上下文工程的定义
上下文工程是一门新兴但至关重要的学科，它管理我们如何有效地引导LLM解决我们输入的任务。
作为软件工程的一个子领域，它受益于系统思维和设计思维，我们可以从应用设计模式中学到经验教训，以生产模块化、稳健和可理解的软件。
11.2 四大核心原则
在使用LLM时，我们必须遵循以下原则：
1. 将LLM视为分析师，而非神谕
给它提供完成任务所需的一切。
不要期待它从虚空中召唤答案，而是为它准备好所有必要的信息、工具和指导。
2. 对整个上下文窗口负责
不仅仅是系统提示和用户提示。
考虑每一个进入上下文窗口的token：
它们的相关性
它们的时效性
它们的准确性
它们的必要性
3. 使用可组合、可复用的设计模式
这些模式可以独立工程化和测试。
就像传统软件开发一样，使用经过验证的模式来构建复杂系统，而不是每次都从头开始。
4. 将智能体间的交接视为API契约
在它们的上下文窗口之间建立契约。
多智能体系统中的每个交互点都应该像设计REST API或微服务接口一样被仔细设计和文档化。
11.3 实践意义
通过遵循这些原则，我们可以以与其他工程软件相同的严谨性控制上下文学习。
这使我们能够构建：
可靠的生产级AI系统
可维护的代码库
可扩展的架构
可测试的组件
可理解的系统行为
参考文献
Chris Loy, "Context engineering Part of Machine Learning for Engineers"
如果这篇文章对你有帮助，欢迎点赞、收藏、转发。也欢迎在评论区分享你的经验，我们一起交流学习！
我是 dtsola【IT解决方案架构师 | AI创业者】 ；专注AI创业、商业、技术、心理学、哲学内容分享。
提供服务：AI项目咨询 | 技术解决方案 | IT项目实施 | 企业技术顾问
博客：https://www.dtsola.com
公众号&VX：dtsola
需提供服务，加微信 dtsola，备注：IT咨询，并说明来意。
#上下文工程 #LLM应用开发 #提示工程 #RAG架构 #大模型应用 #多智能体系统 #LLM架构设计 #LangChain #独立开发者 #AI创业
