大多数 LLM 演示一开始都感觉很神奇。它们可以起草电子邮件、重写代码，甚至预订假期，而且几分钟内，似乎模型真正“理解”了所有输入的内容。但当任务变得复杂和真实时，这种幻觉就会破灭。当成功取决于昨天的事件报告、您的团队的内部文档或冗长的故障排除 Slack 线程时，模型突然会失误。它无法记住十条消息之前说过的话，无法访问您的私有数据，并且只是开始猜测而不是推理。
闪亮的演示与可靠的生产系统之间的区别不在于切换到“更智能”的模型。而是关于信息在每个任务步骤中被选择、构建和传递给模型的方式。换句话说，区别在于 上下文。
所有 LLM 都受到有限 上下文窗口的约束，这迫使人们在模型可以“看到”的内容上做出艰难的权衡。上下文工程就是将该窗口视为稀缺资源，并围绕它设计一切（检索、记忆系统、工具集成、提示等），以便模型将其有限的注意力预算仅用于高信号令牌。
但是上下文窗口是什么？
上下文窗口是模型的活动工作区，它保存着当前任务的指令和信息。每个单词、数字和标点符号都会占用此窗口中的空间。把它想象成一个白板：一旦它被填满，旧的信息必须被擦除以腾出空间给新的信息，导致重要的过去细节丢失。更具体地说，上下文窗口是指语言模型在生成响应时可以一次考虑的最大输入数据量，以令牌为单位进行衡量。此窗口包括所有输入、模型的输出、工具调用和检索到的文档，充当短期记忆。放置在上下文窗口中的每个令牌都会直接影响模型可以“看到”的内容以及它的响应方式。
上下文工程与提示工程
提示工程侧重于您如何措辞和构建 LLM 的指令以生成最佳结果，例如编写清晰/巧妙的提示、添加示例或要求模型“逐步思考”。虽然重要，但仅提示工程无法解决模型断开连接的基本限制。
另一方面，上下文工程是设计在正确的时间向 LLM 馈送正确信息的架构。它是构建将断开连接的模型连接到外部世界、检索外部数据、使用工具并使其具有记忆以使其响应基于事实而不是训练数据的桥梁。
简单来说，提示工程是您如何提出问题，而上下文工程是确保模型在开始思考之前可以访问正确的教科书、计算器甚至您之前对话的笔记。LLM 的质量和有效性受到其接收到的提示的很大影响，但仅凭提示的措辞无法走多远，而没有经过良好工程设计的上下文。像思维链、少样本学习和 ReAct 这样的提示技术在与检索到的文档、用户历史记录或特定领域的数据结合使用时效果最佳。
上下文窗口挑战
LLM 上下文窗口一次只能容纳这么多信息。这种基本的约束决定了当前代理和代理系统能够做什么。每次代理处理信息时，它必须决定哪些内容保持活动状态，哪些内容可以被总结/压缩/删除，哪些内容应该被外部存储，以及要为推理保留多少空间。认为将所有内容塞入更大的上下文窗口可以解决这个问题，但这通常不是这种情况。
随着上下文的增长，会出现的关键故障模式如下
- 上下文污染：错误或幻觉信息进入上下文。由于代理会重用并建立在上下文中，这些错误会持续并累积。
- 上下文干扰：代理因过多的过去信息而负担，过度依赖重复过去的行为而不是进行新的推理。
- 上下文混淆：不相关的工具或文档使上下文混乱，分散模型的注意力，导致它使用错误的工具或指令。
- 上下文冲突：上下文中的矛盾信息会误导代理，使其陷入相互冲突的假设之中。
这些不仅仅是技术限制，而是任何现代 AI 应用程序的核心设计挑战。您不能通过仅仅编写更好的提示或增加上下文窗口的最大大小来解决这个基本限制。您必须围绕模型构建一个系统。
这就是上下文工程的全部内容！
上下文工程的六大支柱
上下文工程是一个由六个相互依赖的组件构建的系统，这些组件控制着信息何时到达模型。代理协调决策，查询增强完善用户输入，检索连接到外部知识，提示指导推理，记忆保存历史记录，以及工具实现现实世界的行动。
代理
代理正迅速成为构建 AI 应用程序的基础。它们既是其上下文的架构师，又是这些上下文的用户，动态地定义知识库、工具使用和整个系统内的信息流。
定义代理的内容
一个AI 代理是一个使用大型语言模型 (LLM) 作为其“大脑”来做出决策和解决复杂任务的系统。用户提供一个目标，代理会找出实现该目标的步骤，并使用其环境中的可用工具。
这四个组件通常构成一个代理
- LLM（大型语言模型）：负责推理、规划和协调整体任务。
- 工具：代理可以调用的外部功能：例如，搜索引擎、数据库、API
- 记忆：存储上下文、先前的交互或任务执行过程中收集的数据
- 观察与推理：分解任务、规划步骤、决定何时/使用哪些工具以及如何处理失败的能力。
代理在上下文工程中的位置
代理位于上下文工程系统的中心。它们既是上下文的用户，从检索到的数据、历史记录和外部知识中获取信息，又是上下文的架构师，决定要呈现、保留或丢弃哪些信息。
在单代理系统中，一个代理处理整个流程，决定何时搜索、总结或生成。在多代理系统中，多个代理各自承担专门的角色，从而实现更大的目标。在两种情况下，上下文的构建和共享方式决定了系统的性能如何。
代理可以具有许多不同的任务和功能，从定义不同的检索或查询策略到验证响应的质量或完整性，再到动态地从可用选项中选择工具。代理提供所有不同部分之间的协调，以便对信息管理做出动态的、与上下文相关的决策。
查询增强
查询增强是完善用户初始输入以用于下游任务的过程，例如查询数据库或将其呈现给代理。不幸的是，这比听起来要难得多，但非常重要。无论多么复杂的算法、重新排序模型或巧妙的提示，都无法真正弥补用户意图的误解。
主要需要考虑两点
- 用户通常不会以理想的方式与聊天机器人或输入框进行交互。大多数演示会假设用户以完全格式化的句子形式输入其完整的请求，但在生产应用程序中，实际用法往往混乱、不清晰且不完整。
- AI 系统的不同部分需要以不同的方式理解和使用用户的查询。最适合 LLM 的格式可能与您用于查询向量数据库的格式不同，因此我们需要一种根据工作流程中不同工具和步骤来增强查询的方法。
Weaviate 查询代理是一个很好的例子，说明如何将查询增强轻松构建到任何 AI 应用程序中。它的工作原理是根据其对集群数据结构和 Weaviate 本身的了解，采用自然语言中的用户提示并决定为数据库构建查询的最佳方式。
检索
构建 AI 时常说的一句话：垃圾进，垃圾出。你的检索增强生成 (RAG) 系统的好坏取决于它检索到的信息。即使拥有写得好的提示词和强大的模型，如果它们处理的是无关的信息，也毫无用处。因此，第一步也是最重要的一步是优化你的 检索。
你在这里需要做的最重要的决定是你的 分块策略。这是一个经典的工程权衡。
- 小块 非常适合 精确性。它们的嵌入向量集中，易于找到完全匹配项。缺点？它们通常缺乏 LLM 生成有意义答案所需的上下文信息。
- 大块 富含 上下文信息，这对于 LLM 的最终输出非常有用。但它们的嵌入向量可能会变得“嘈杂”和平均化，使得难以确定最相关的信息。此外，它们会占用 LLM 上下文窗口更多的空间，这可能会排挤其他相关信息。
在精确性和上下文之间找到一个平衡点是实现高性能 RAG 的关键。如果搞错了，你的系统将无法找到正确的事实，迫使模型回退到幻觉，而这正是你试图避免的事情。
为了帮助你找到最适合你的用例的分块策略，我们创建了一份备忘单，它梳理了从简单到高级的最常见分块策略。
这份备忘单是一个很好的起点。但是，如果你从基本的 PoC 转向生产就绪的系统，问题通常会变得更加困难。你应该提前将所有内容预先分块，还是需要更动态的后分块架构？如何找到最佳的分块大小？
我们在这篇深入的博文中涵盖了这些问题，并附带代码示例： 改进 RAG 性能的分块策略
提示词技巧
所以一旦你完善了你的检索。你的系统可以在毫秒内提取最相关的信息块。你的工作完成了，对吧？
还不是完全。你不能只是把它们塞进 上下文窗口，然后寄希望于一切顺利。你需要告诉模型 如何 使用这些新发现的信息。这种技术称为 提示工程。
在检索系统中，你的提示词是控制层。它是一组告诉 LLM 如何 行为的指令。你的提示词需要清楚地定义任务。你是要求模型
- 综合 来自多个，有时甚至是相互矛盾的来源的答案？
- 提取 特定的实体并将它们格式化为 JSON 对象？
- 回答 一个问题，仅基于提供的上下文，以防止幻觉？
如果没有明确的指令，模型会忽略你精心检索到的上下文，并 幻觉 出一个答案。你的提示词是最后的保障，可以确保模型尊重你提供的事实。
你可以选择的提示词技巧工具包有很多。但是，要从理论过渡到生产，你需要知道不仅 是什么 这些框架，还要知道 如何 和 何时 实施它们。在我们的 上下文工程电子书中，你将学习如何实施简单的技术，如思维链 (CoT)，以及更高级的技术，如 ReAct 框架，以构建能够可靠地处理复杂的多步骤任务的系统。
记忆
无状态的 LLM 可以很好地回答一个问题，但它不知道五分钟前发生了什么，以及这对于下一个决策有什么意义。记忆将模型转变为一种感觉更动态、更“人性化”的东西，它能够保持上下文、从过去学习并在飞行中进行调整。对于上下文工程，核心挑战不是“我们可以存储多少？”，而是“现在应该将什么放在模型前面，什么可以安全地存储在其他地方？”
代理记忆的架构
在 AI 代理中，记忆就是为了在不断变化的任务中保留信息，记住哪些有效（或无效），并着眼于未来。为了构建强大的代理，我们需要分层思考，通常将不同类型的记忆混合在一起以获得最佳结果。
短期记忆是实时上下文窗口：最近的对话/推理、工具输出和检索到的文档，模型需要围绕当前步骤进行推理。这个空间非常有限，因此应该保持精简，只保留足够的对话历史以保持线程连贯和决策依据。
长期记忆，相比之下，存在于模型之外，通常位于向量数据库中，以便快速检索 (RAG)。这些存储永久保存信息，并且可以保存
- 情景数据：过去的事件、用户交互、偏好
- 语义数据：通用和领域知识
- 程序化数据：例程、工作流程、决策步骤
由于它是外部的，因此这种记忆可以增长、更新并持续存在于模型的上下文窗口之外。
大多数现代系统通常实现混合记忆设置，即混合短期记忆和长期记忆以获得深度。一些架构还添加了工作记忆：一个临时空间，用于在多步骤任务期间需要的信息。例如，在预订旅行时，代理可能会将目的地、日期和预算保存在工作记忆中，直到任务完成，而无需永久存储它。
设计不会污染上下文的记忆
最糟糕的记忆系统是忠实地存储一切。旧的、低质量的或嘈杂的条目最终会通过检索返回，并开始用陈旧的假设或无关的细节污染上下文。有效的代理具有选择性：它们会过滤哪些交互被提升到长期存储中，通常让模型“反思”一个事件并分配一个重要性或有用性分数，然后再保存它。
一旦存储，记忆就需要维护。定期修剪、合并重复项、删除过时的事实以及用紧凑的摘要替换冗长的记录可以保持检索的敏锐性，并防止上下文窗口被历史杂乱无章所填充。例如，近度和检索频率是简单但强大的信号，用于保留什么和淘汰什么。
我们的电子书的记忆部分更深入地探讨了这些记忆管理策略，包括掌握检索的艺术、选择性地存储内容以及修剪和完善记忆。它还强调了关键原则：始终根据任务定制记忆架构，因为至少目前还没有一种通用的解决方案。
工具
如果记忆让代理记住过去，那么工具的使用赋予了它在当下行动的能力。即使是最复杂的 LLM 也被锁在文本气泡中，也就是说，它可以出色地进行推理、起草和总结，但它无法检查实时股票价格、发送电子邮件、查询数据库或预订航班。工具是思想和行动之间的桥梁，是让代理走出训练数据与现实世界互动的方式。
工具的上下文工程不仅仅是给代理一个 API 列表和指令。它是关于创建一个连贯的工作流程，让代理能够理解有哪些工具可用，正确地决定使用哪个工具来完成特定任务，并解释结果以继续前进。
编排挑战
将可用工具列表交给代理很简单。让它正确、安全和高效地使用这些工具，才是上下文工程工作开始的地方。这种编排涉及多个活动部件，所有这些都发生在有限的上下文窗口内
- 工具发现：代理必须知道它有哪些工具可以使用。这是通过在系统提示中给它一个清晰的工具列表和高质量的描述来完成的。这些描述指导代理了解每个工具的工作方式、何时使用以及何时避免使用。
- 工具选择和规划：当用户提出请求时，代理必须决定是否需要工具，如果是，则选择哪个工具。对于复杂的任务，它可能会计划使用一系列工具（例如：“搜索天气，然后通过电子邮件发送摘要”）。
- 参数公式：选择工具后，代理必须确定要传递的正确参数。例如，如果工具是
get_weather(city, date)，它必须从用户的查询中推断细节，例如“旧金山”和“2025-11-25”，并以适当的格式进行调用。 - 反思：工具执行后，输出将返回给代理。代理会审查它以决定下一步该做什么：工具是否正常工作、是否需要更多迭代，或者错误是否意味着它应该尝试不同的方法。
正如你所看到的，编排是通过这个强大的反馈循环发生的，通常称为“思考-行动-观察”循环。代理不断观察其行动的结果，并利用这些新信息来推动其下一个“思考”。这个思考-行动-观察循环构成了我们自己的 Elysia 等现代代理框架的基本推理循环。
向标准化转变与 MCP
工具使用的演进正朝着标准化的方向发展。虽然函数/工具调用效果很好，但它会创建一个碎片化的生态系统，其中每个 AI 应用程序都需要与每个外部系统进行自定义集成。Anthropic 在 2024 年底推出的模型上下文协议 (MCP) 通过为 AI 应用程序与外部数据源和工具的连接提供通用标准来解决这个问题。他们称之为“AI 的 USB-C” - 任何兼容 MCP 的 AI 应用程序都可以使用的单一协议，用于连接到任何 MCP 服务器。因此，开发人员不必为每个工具构建自定义集成，而只需创建单独的 MCP 服务器，通过这种标准化接口公开他们的系统。任何支持 MCP 的 AI 应用程序都可以使用基于 JSON-RPC 的客户端-服务器通信协议轻松连接到这些服务器。这会将 MxN 集成问题（其中 M 个应用程序每个都需要针对 N 个工具的自定义代码）转换为一个更简单的 M + N 问题。
随着工具使用集成标准化，真正的重点变成设计能够协同思考的系统，而不是将它们连接起来。
示例：使用 Elysia 构建一个真实世界的代理
本文博客中涵盖的所有内容，从编排决策的代理、塑造检索的查询增强、保存状态的记忆到实现行动的工具，都将在你构建真实系统时汇聚在一起。
Elysia 是我们的开源代理式 RAG 框架，它在决策树架构中体现了这些上下文工程原则。
与简单的检索-然后-生成管道不同，Elysia 的决策代理在选择下一步行动之前会评估环境、可用工具、过去的操作和未来的选项。树中的每个节点都具有全局上下文感知能力。当查询失败或返回不相关结果时，代理可以识别到这一点并调整其策略，而不是盲目地继续。
在本例中，我们将构建一个代理，它搜索实时新闻、获取文章内容并查询你现有的 Weaviate 集合，所有这些都通过 Elysia 框架的智能决策和编排来实现。你可以通过将 Elysia 安装为 Python 包来开始使用。
pip install elysia-ai
内置的上下文感知检索工具
Elysia 包含五个强大的内置工具：query、aggregate、text_response、cited_summarize 和 visualize。
query工具使用不同的搜索策略（例如混合搜索或简单的获取对象）检索特定数据条目，并借助 LLM 代理自动进行集合选择和过滤器生成。aggregate工具执行计算，例如计数、平均值和求和，并具有分组和过滤功能，同样借助 LLM 代理。text_response和cited_summarize直接响应用户，分别以常规文本或包含环境中检索到的上下文引用的文本形式呈现。visualize工具帮助可视化环境中的数据，使用动态显示，例如产品卡片、GitHub 问题、图表等。
在与你的集合交互之前，你需要运行 Elysia 的 preprocess() 函数来处理你的集合，以便 Elysia 可以分析模式并推断关系。
from elysia import configure, preprocess
# Connect to Weaviate
configure(
wcd_url = "...", # replace with your Weaviate REST endpoint URL
wcd_api_key = "..." # replace with your Weaviate cluster API key,
base_model="gemini-2.5-flash",
base_provider="gemini",
complex_model="gemini-3-pro-preview",
complex_provider="gemini",
gemini_api_key = "..." # replace with your GEMINI_API_KEY
)
# Preprocess your collections (one-time setup)
preprocess(["NewsArchive", "ResearchPapers"])
用于扩展代理功能的自定义工具
Elysia 还可以使用完全自定义的工具，以及内置工具。这使你可以将代理的范围扩展到你的本地集合之外，扩展到实时数据、外部 API 或任何其他数据源。
以下是如何使用 Serper API 构建一个简单的代理，搜索实时新闻、获取文章内容并使用 Elysia 轻松查询你现有的多个集合。
from elysia import Tree, tool, Error, Result
tree = Tree()
@tool(tree=tree)
async def search_live_news(topic: str):
"""Search for live news headlines using Google via Serper."""
import httpx
async with httpx.AsyncClient() as client:
response = await client.post(
"<https://google.serper.dev/news>",
headers={
"X-API-KEY": SERPER_API_KEY, # Replace with an actual key: https://serper.dev/api-keys
"Content-Type": "application/json"
},
json={"q": topic, "num": 5}
)
results = response.json().get("news", [])
yield Result(objects=[
{"title": item["title"], "url": item["link"], "snippet": item.get("snippet", "")}
for item in results
]
@tool(tree=tree)
async def fetch_article_content(url: str):
"""Extract full article text in markdown format."""
from trafilatura import fetch_url, extract
downloaded = fetch_url(url)
text = extract(downloaded)
if text is None:
yield Error(f"Cannot parse URL: {url}. Please try a different one")
yield Result(objects=[{"url": url, "content": text}])
response, objects = tree(
"Search for AI regulation news, fetch the top article, and find related pieces in my archive and research papers",
collection_names=["NewsArchive", "ResearchPapers"]
)
print(response)
当你使用这种设置运行 Elysia 时，决策树会智能地串联这些操作
search_live_news工具会找到突发新闻并将其添加到环境中，fetch_article_content工具会从有希望的 URL 获取全文，然后- Elysia 的内置查询工具通过路由到
NewsArchive（用于过去的文章）和ResearchPapers（用于学术来源）在两个集合中搜索。 - 当你跟进“XYZ 作者撰写的关于此主题的学术论文有哪些？”时，代理会识别意图并优先考虑
ResearchPapers集合，而无需你明确指定。
这是一种上下文工程的实践：决策代理编排信息流，动态增强查询，从多个来源检索，在轮次之间保持状态，并使用工具来作用于世界 - 所有这些都通过仅使用相关的标记来驱动推理，从而最大限度地利用有限的上下文窗口。
完整的 Elysia 文档可在以下网址获取：https://weaviate.github.io/elysia/
结论
那么，这让我们最终走向何方？
这一切都归结于闪亮演示和可靠的生产系统之间的差距。跨越该差距的桥梁不是单一技术，而是协同工作的上下文工程的 6 个支柱的学科。
一个强大的代理如果没有来自检索的干净数据就没有用。优秀的检索如果一个糟糕的提示误导了模型就会被浪费。即使是最好的提示也无法在没有记忆提供的历史或工具提供的现实世界访问的情况下发挥作用。
上下文工程是关于将我们的角色从与模型交谈的提示者转变为构建模型所居住的世界的架构师。
作为构建者，我们知道更大的模型不一定能创建最好的 AI 系统，而是更好的工程才能。
现在，让我们回到构建。我们期待看到你正在做的事情！ 💚
准备开始构建了吗？
请查看 快速入门教程，或使用 Weaviate Cloud (WCD) 的免费试用版构建令人惊叹的应用程序。