在实际应用中，上下文类型通常按时间范围或作用划分：
这些上下文类型共同为LLM构建了丰富的情境画面。例如，一个AI日程安排助手在接收"你明天有空吗？"这样的查询时，还会获取用户的日历可用性（外部数据）、过往邮件（短期记忆）、请求者身份（档案）以及"发送邀请"的功能调用权限。有了这些上下文，智能体才能准确回答并采取行动；否则，其回复可能流于表面或出现错误。
现代基于LLM的智能体采用专门的软件框架来处理上下文组装，这些框架体现了将记忆、工具和检索数据注入LLM提示词的架构模式，主要包括：
LangChain / LangGraph：LangChain提供了用于管理上下文的链（chains）和智能体抽象，例如内置的Memory类（如ConversationBufferMemory、LLMMemory）和能自动附加聊天历史或RAG结果等上下文的Chains。其扩展LangGraph甚至提供基于图的流程，每个节点都可访问长期记忆存储或RAG流水线。
LlamaIndex（GPT Index）：专注于构建知识索引和记忆，提供用于RAG的向量存储，以及能持久化信息的高层记忆组件（短期/长期）。例如，LlamaIndex的最新更新引入了记忆块（静态事实、提取的事实、向量记忆）以跨会话保留信息，其智能体框架可将查询路由至RAG流水线和记忆查找，将检索到的段落和记忆融入提示词。
Auto-GPT / 多智能体系统：Auto-GPT是早期的开源系统，通过串联GPT-4调用来分解任务，使用向量数据库实现长期记忆和短期暂存区。IBM将Auto-GPT描述为"多智能体框架"，可为子任务创建智能体，并支持短期和长期记忆（向量存储）。类似地，MetaGPT、OpenAI的Agents SDK和微软的AutoGen等协调器也采用类似模式：规划模块、记忆日志和工具调用框架。
CrewAI：用于多智能体协调的Python框架，引入了团队（Crews，由专业智能体组成）和流程（Flows）的概念。每个智能体可拥有自己的角色、工具和记忆，团队控制器负责在它们之间分配任务。CrewAI文档强调其灵活性（智能体协作、共享见解、管理任务），还内置了智能体的记忆和推理模块，使团队知识等上下文能够持久化并被访问。
DSPy（Declarative Self-improving Python）：较新的框架，将LLM程序逻辑视为代码模块而非原始提示词，允许开发者在Python中定义"模块"和"工具"，并在底层将其编译为带上下文的提示词。在上下文管理方面，DSPy提供History、Tool和Memory等原语抽象，自动跟踪对话并持久化信息。其官网将其描述为"用于构建模块化AI软件的声明式框架"，支持通过编程方式组合和优化提示词。
上下文工程的核心挑战在于如何收集恰当的上下文并保持其更新，同时不超出模型的窗口限制。常用技术包括：
检索增强生成（RAG）：智能体查询外部知识源（如向量数据库、搜索引擎）以获取相关片段或事实，然后将这些检索到的段落增强到LLM的提示词中。例如，针对用户问题，系统可能检索排名靠前的k个文档，并将其附加在"相关信息："部分下，有效将LLM锚定在外部数据上。AWS的RAG概念图显示了这一流程：用户查询被嵌入并与向量存储匹配，获取顶部文档，然后用[查询+检索到的事实]调用LLM。通过将知识卸载到RAG，智能体无需重新训练即可大幅扩展其有效知识库（Lewis等人2020年的研究表明，带有维基百科索引的RAG模型在事实性问答上的表现优于封闭模型）。
向量数据库与语义搜索：RAG通常基于向量嵌入技术，文本源（文档、知识图谱、过往日志）被编码为向量并存储在向量数据库中。查询时，智能体将查询嵌入，通过最近邻搜索找到相似的上下文片段，可扩展至大型语料库。许多框架（LangChain、LlamaIndex、DSPy等）都提供与Pinecone或Weaviate等向量存储的适配器。
记忆缓冲区与日志：对于短期记忆，一种简单策略是维持滚动聊天缓冲区（如最近N条消息），始终前置到提示词中。对于长期记忆，智能体可能定期将较旧的记忆或事实总结为紧凑形式。有些系统使用暂存区（外部日志或文件），智能体可在会话期间写入并按需读取，例如Anthropic的"暂存区"工具允许智能体在推理时将有用信息附加到文件中。LangGraph框架同样会 checkpoint 对话状态，以便在智能体重启时检索。
记忆压缩与总结：为适应有限的token，长文档或历史记录常被压缩，技术包括抽象总结（使用LLM浓缩文本）、提取过滤（仅保留关键句子）或分块（拆分为多个查询）。有些系统甚至采用递归总结，将对话摘要再总结为更高层次的笔记。例如，智能体可在每轮对话中生成当日聊天的一段总结，并仅保留该总结。这些方法以细节为代价换取记忆的持久性。前沿研究正探索神经记忆压缩（学习过往交互的紧凑表示）和检索增强总结流水线。
上下文优先级与评分：当存在多个上下文片段时，智能体必须选择最相关的部分。常用启发式方法包括使用向量数据库的相似度分数、语义重叠或基于机器学习的相关性模型。例如，LangChain支持少样本示例选择或最大边际相关性（Maximal Marginal Relevance）来挑选范例。有些框架允许为记忆添加元数据（时间戳、重要性），使智能体可按新近度或优先级过滤。
这些方法确保了生成时LLM能获得优化的提示词。上下文工程流水线通常自动化数据流：从向量数据库检索、更新记忆存储、必要时进行总结，并格式化最终提示词。许多系统还包含评估循环，例如LangChain的智能体RAG功能允许模型反思是否需要更多上下文或工具，并在必要时调用子智能体。
上下文工程为AI智能体的许多高级应用提供了支持：
多步骤推理与规划：解决复杂任务（如编写代码、设计方案、开展研究）的智能体可通过跟踪中间步骤获益。例如，ReAct智能体框架将思维链推理与工具使用相结合：在每一步，模型决定调用哪个工具（如计算器、日历或搜索API），并将结果存储在记忆中。智能体的上下文因此包含原始目标、工具调用历史和所有获取的数据，支持多跳推理。
工具/插件执行：在带插件的聊天机器人等场景中，上下文工程将工具定义和模式注入提示词，使模型知晓如何使用它们。例如，ChatGPT插件要求智能体在系统消息中看到API描述（JSON模式）。调用工具后，JSON输出会被返回到上下文用于进一步推理。每轮的上下文都动态包含相关工具输出。
实时任务管理：个人助理或机器人等应用需要最新上下文（日历、邮件、传感器数据）。经上下文工程设计的助理可能定期轮询用户日历和新闻源，总结变化，并在提示词前置"最新上下文"块，确保智能体的决策考虑实时世界状态。
文档搜索与问答：用于大型语料库问答的智能体（如企业搜索、法律研究）依赖RAG技术。例如，AI法律助理会检索相关法规、案例观点和用户案件事实，进行总结，并将其与用户问题一同呈现给LLM。这种方法远优于简单提示词。有案例表明，仅让智能体"总结相关判例法"是不够的，必须提供精选文档、压缩摘要和精心组织的上下文，模型才能生成准确答案。
对话智能体：聊天机器人和虚拟助理严重依赖上下文工程维持连贯对话。通过存储长期用户档案（如姓名、偏好）和短期聊天历史，智能体可个性化回复并跟进长对话。例如，日程安排聊天机器人利用用户日历（外部数据）、对话历史甚至来电者身份做出适当响应。缺少这些上下文，机器人的回答会十分肤浅。
尽管取得了进展，上下文工程仍面临重大开放挑战：
上下文窗口限制：即使最大的上下文窗口也有限制。随着任务规模扩大，决定丢弃和保留哪些信息变得困难，模型在超长提示词上的性能仍会下降。研究正探索混合解决方案（如分层记忆或动态上下文窗口）来缓解这一问题。
幻觉与错误信息：即使有检索机制，若上下文缺失或表述模糊，LLM仍可能产生幻觉。确保检索到的证据准确且幻觉不会污染记忆是持续存在的问题。有些研究提出"锚定"机制或事实核查子智能体来检测不一致性。
高效记忆压缩：总结和压缩可能丢失细微差别，寻找无损或自适应压缩方法是活跃研究领域。同时，确保压缩后的记忆仍有用（即不丢失关键细节）也颇具挑战。
检索相关性与速度：RAG依赖语义相似性，而这种相似性并不完美。智能体可能检索到略相关的文档，导致"上下文干扰"。检索技术的进步（如检索增强总结、知识图谱）旨在提高精度。此外，实时智能体需要极低延迟的检索，这是一个工程瓶颈。
个性化与隐私平衡：使用用户档案和对话历史可增强个性化，但引发隐私担忧。平衡上下文丰富性与用户隐私（如仅检索用户同意的上下文）是复杂的政策和技术问题。
评估指标：衡量上下文工程的有效性具有挑战性。如何量化"相关性"或上下文对性能的影响？需要研究评估框架和智能体记忆基准，以及上下文质量的自动诊断方法。
安全性与鲁棒性：上下文注入带来了攻击向量（如提示词注入、恶意上下文污染）。确保智能体能安全处理不可信输入和上下文是一个开放的安全挑战。
端到端学习：当前大多数上下文工程基于规则，人们日益关注学习上下文选择策略（如使用强化学习或检索增强微调），使智能体自动学习获取和保留哪些上下文。
上下文工程处于LLM研究和系统设计的前沿，融合了信息检索、记忆增强学习和人机交互的思想。随着LLM的演进（如更大的上下文窗口或混合专家等新架构），上下文工程也将不断发展，助力构建能在长时范围内可靠推理的真正上下文感知AI系统。
通过精心设计的上下文管理，我们正逐步实现更智能、更可靠、更贴合人类需求的AI助手，它们不仅能理解当前查询，还能铭记过往交互、调用必要工具，并在复杂任务中保持连贯的推理链条。未来，上下文工程的进步将推动AI从简单的问答工具向真正的自主智能体转变，在科研、医疗、教育等诸多领域发挥变革性作用。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |