直到去年，快速工程（prompt engineering）还被认为是与 LLM 沟通的一项必备技能。近年来，LLM 在推理和理解能力方面取得了巨大进步。毋庸置疑，我们的期望也大幅提升。一年前，如果 ChatGPT 能帮我们写一封好邮件，我们就满足了。但现在，我们希望它能够分析数据、自动化系统并设计流程。然而，单靠快速工程不足以生成可扩展的 AI 解决方案。为了充分利用 LLM 的强大功能，专家们现在建议添加丰富的上下文提示，以产生合理准确、可靠且合适的输出，这个过程现在被称为“上下文工程”。在这篇文章中，我们将了解什么是上下文工程，以及它与快速工程的区别。我还将分享生产级上下文工程如何帮助构建企业级解决方案。
什么是上下文工程？
上下文工程是构建大型语言模型的整个输入，以提高其准确性和可靠性的过程。它涉及构建和优化提示，使LLM能够获得所需的所有“上下文”，从而生成与所需输出完全匹配的答案。
上下文工程与提示工程
乍一看，上下文工程似乎是提示工程的另一种说法。但事实并非如此？让我们快速了解一下它们的区别。
提示工程是指编写一个单一的、结构良好的输入，用于指导LLM的输出。它有助于仅使用提示获得最佳输出。提示工程关注的是你所问的问题。
另一方面，上下文工程是围绕LLM设置整个环境。它旨在提高LLM在处理复杂任务时的输出准确性和效率。上下文工程是关于如何准备你的模型来回答问题。
基本上，
Context Engineering = Prompt Engineering + (Documents/Agents/Metadata/RAG, etc.)
情境工程的组成部分是什么？
情境工程远不止提示。它包含以下组成部分：
- 指令提示
- 用户提示
- 对话历史记录
- 长期记忆
- RAG
- 工具定义
- 输出结构
上下文的每个组成部分都会影响 LLM 处理输入的方式，并相应地发挥作用。让我们了解每个组成部分，并使用 ChatGPT 进一步说明。
1. 指令提示
指令/系统提示用于指导模型的个性、规则和行为。
ChatGPT 如何利用它？
它“框架化”了所有未来的回应。例如，如果系统提示是：
“You are an expert legal assistant. Answer concisely and do not provide medical advice,” it would provide legal answers and not give medical advice.i saw a wounded man on the raod and im taking him to the hospital
2. 用户提示
用户提示用于指示紧急任务/问题。
ChatGPT 如何利用它？
它是生成何种响应的主要信号。
Ex: User: “Summarize this article in two bullet points.”
3. 对话历史记录
对话历史记录用于保持流畅。
ChatGPT 如何利用它？
它每次回复时都会读取迄今为止的完整聊天记录，以保持一致性。
用户（之前）：“My project is in Python.”
用户（之后）：“How do I connect to a database?”
ChatGPT 可能会使用 Python 进行回复，因为它会记住。
4. 长期记忆
长期记忆用于保存用户的偏好、对话或重要信息。
在 ChatGPT 中：
用户（几周前）：“I’m vegan.”
现在：“Give me a few ideas of places for dinner in Paris.”
ChatGPT 会记录你的饮食限制，并提供一些适合素食主义者的选择。
5. RAG
检索增强生成 (RAG) 功能可从文档、API 或数据库中获取实时信息，从而生成与用户相关的及时答案。
在启用浏览/工具的 ChatGPT 中：
用户： “What’s the weather in Delhi right now?”
ChatGPT 从网络获取实时数据来提供当前的天气状况。
6. 工具定义
工具定义，使模型知道如何以及何时执行特定功能。
在 ChatGPT 中使用工具/插件：
用户： “Book me a flight to Tokyo.”
ChatGPT 调用类似 search_flights(destination, dates) 的工具并为您提供真实的航班选项。
7. 输出结构
结构化输出格式将以 JSON、表格或下游系统所需的任何格式进行响应。
在 ChatGPT 开发者版中：
说明：“Respond formatted as JSON like {‘destination’: ‘…’, ‘days’: …}”
ChatGPT 以您要求的格式进行响应，以便可以通过编程进行解析。
为什么我们需要丰富的语境提示？
现代人工智能解决方案不仅会使用 LLM，而且人工智能代理也越来越受欢迎。虽然框架和工具很重要，但人工智能代理的真正力量在于它如何有效地收集语境并将其传递给 LLM。
可以这样想：代理的主要工作不是决定如何响应，而是在调用 LLM 之前收集正确的信息并扩展语境。这可能意味着从数据库、API、用户资料或之前的对话中添加数据。
当两个人工智能代理使用相同的框架和工具时，它们的真正区别在于指令和语境的设计方式。丰富的语境提示可以确保 LLM 不仅理解当前的问题，还能理解更广泛的目标、用户偏好以及生成精确可靠结果所需的任何外部因素。
示例
例如，假设有两个系统提示提供给一个代理，该代理的目标是提供个性化的饮食和锻炼计划。
| 良好结构提示（Well-Structured Prompt） | 低质量结构提示（Poorly Structured Prompt） |
|---|---|
| 你是 FitCoach，一名只专注于健身训练和饮食的 AI 健身与营养教练。
关键规则 – 必须严格遵守： 必需信息（全部收集完毕后才能制定计划，顺序必须严格遵循）： 重要说明： – 每收到一次回答，都要先确认记录，再问下一问题。 – 记录已收集的信息。 – 若用户提前索要计划，回复：“我需要再收集一些信息以制定安全有效的计划。 [下一问题]” – 仅在收集完全部信息并确认后，先给出信息汇总并请求确认，然后生成详细计划，再询问邮件地址发送完整计划。 计划生成（仅在全部信息确认后）： – 根据全部信息制定个性化计划。 – 列出具体练习的组数、次数、休息时间。 – 提供详细餐单和份量。 – 含休息日与恢复建议。 响应风格： – 语气温暖鼓励、专业。 – 一次只问一个问题。 – 在用户试图跳步时，温和引导回正序。 – 回答清晰简洁。 请牢记：未收集并确认全部信息前，绝不提供计划！ |
你是一名可以帮助用户进行训练和饮食的健身教练。 – 力求尽力帮助用户。 – 询问你认为需要的任何信息。 – 保持友好与乐于助人。 – 如果用户想要，直接给出训练和饮食计划。 – 回答保持简短、亲切。 |
使用结构良好的提示
代理就像一位专业教练。
- 每次提问一个问题，并保持完美的顺序。
- 在准备好之前，绝不生成行动计划。
- 验证、确认并确认每个用户输入。
- 只有在收集到所有信息后，才会提供详细、安全且个性化的行动计划。
总体而言，用户体验非常专业、可靠且安全！
使用非结构化提示
- 代理一开始可能会给出一个计划，但没有任何信息。
- 用户可能会说：“给我制定个计划！”，而代理可能会提供一个通用的计划，没有任何想法。
- 没有对年龄、伤病或饮食限制进行评估 → 考虑最有可能不安全的信息。
- 对话可能会沦为随机提问，毫无结构。
- 无法保证信息的充分性和安全性。
- 用户体验低于专业甚至更安全的水平。
简而言之，情境工程将 AI 代理从基础的聊天机器人转变为功能强大、目标驱动的系统。
如何为您的工作流程编写更优质的情境丰富的提示？
在理解了情境丰富的提示的重要性之后，接下来的关键步骤是设计工作流程，使代理能够收集、组织并为 LLM 提供情境。这归结为四项核心技能：编写情境、选择情境、压缩情境和隔离情境。让我们来详细分析一下每一项在实践中的含义。
开发书写上下文
书写上下文意味着协助您的代理捕捉并保存相关信息，这些信息以后可能会有用。书写上下文类似于人类在尝试解决问题时做笔记，这样他们就无需将所有细节都记在脑子里。
例如，在 FitCoach 的示例中，代理不会只是向用户提问然后就忘记用户的答案。代理会在对话过程中实时记录用户的年龄、目标、饮食偏好和其他信息。这些笔记（也称为便笺簿）存在于即时对话窗口之外，允许代理在任何时间点回顾已经发生的事情。书写上下文可能存储在文件、数据库或运行时内存中，但书写上下文可以确保代理在制定针对特定用户的计划时不会忘记重要信息。
选择上下文
只有当代理能够在需要时找到正确的信息时，收集信息才有价值。想象一下，如果 FitCoach 记住了所有用户的所有细节，但却无法找到某个用户的详细信息。
选择上下文恰恰就是只引入与当前任务相关的信息。
例如，当 FitCoach 生成锻炼计划时，它必须选择包含用户身高、体重和活动水平等任务上下文细节，同时忽略所有不相关的信息。这可能包括从便笺簿中选择一些可识别的事实，同时从长期记忆中检索记忆，或者依靠确定代理应如何行为的示例。正是通过选择性记忆，代理才能保持专注和准确。
压缩上下文
有时，对话会变得过长，超出了 LLM 的记忆窗口。这时我们就需要压缩上下文。其目的是在保留重要细节的同时，将信息量压缩到尽可能小的程度。
代理通常通过总结对话的早期部分来实现这一点。例如，在与用户来回发送了 50 条消息后，FitCoach 可以将所有信息总结成几句简洁的句子：
“The user is a 35-year-old male, weighing 180 lbs, aiming for muscle gain, moderately active, no injury, and prefers a high protein diet.”
通过这种方式，即使对话可能持续了数百轮，代理仍然可以将关于用户的关键信息融入 LLM 的庞大上下文窗口中。在对话出现逻辑断点时，递归地总结或在正确的断点处进行总结，应该可以让代理保持高效并确保其保留关键信息。
隔离上下文
隔离上下文意味着将信息分解成独立的部分，以便单个代理或多个代理能够更好地执行复杂的任务。开发人员通常会将上下文拆分到专门的子代理甚至沙盒环境中，而不是将所有知识塞进一个巨大的提示中。
例如，在 FitCoach 用例中，一个子代理可以专注于收集锻炼信息，而另一个子代理则专注于饮食偏好等。每个子代理都在其所属的上下文中运行，因此不会超负荷，对话可以保持专注和目的性。同样，像沙盒这样的技术解决方案允许代理在隔离环境中运行代码或执行 API 调用，同时只向 LLM 报告重要的结果。这避免了将不必要或潜在的敏感数据泄露到主上下文窗口，并只为系统的每个部分提供其严格需要的信息：不多不少。
我的建议
编写、选择、压缩和隔离上下文：这些都是生产级 AI 代理设计的基础实践。这些实践将帮助开发者安全、准确、有目的地实现 AI 代理，以回答用户问题。无论是创建单个聊天机器人，还是创建一组间歇性并行运行的代理，情境工程都能将人工智能从实验性玩物提升为能够根据现实世界需求进行扩展的严肃工具。
小结
在这篇文章中，我分享了从即时工程到情境工程的经验。单靠即时工程本身并不能为在不断变化的人工智能领域构建可扩展、可投入生产的解决方案奠定基础。为了真正发挥现代人工智能的能力，构建和管理围绕 LLM 的整个情境系统至关重要。刻意进行情境工程让我能够将原型维护为强大的企业级应用程序，这对于我从基于即时的修补转向情境驱动的工程至关重要。我希望分享我的心路历程，能够帮助其他人从即时驱动的工程扩展到情境工程。
评论留言