【震惊】你的LLM为啥总“失忆“？揭秘大模型开发真正瓶颈：上下文工程六大核心组件，小白也能秒变AI架构师！-优快云博客

大多数大语言模型（LLM）的演示一开始都让人感觉很有意思。它们可以起草邮件、重写代码，甚至规划假期行程。在最初的几分钟里，模型似乎真的“理解”了你扔给它的所有东西。但是，当任务变得混乱且真实时，这种滤镜就会破碎。当成功的关键取决于昨天的事故报告、团队的内部文档或一段冗长的 Slack 故障排查记录时，模型突然就开始跌跌撞撞了。它记不住十条消息前说过的话，无法访问你的私有数据，然后便开始胡乱猜测而不是进行推理。

一个炫酷的演示与一个可靠的生产级系统之间的区别，并不在于是否切换到了更“聪明”的模型。区别在于在任务的每一步中，信息是如何被选择、结构化并传递给模型的。换句话说，区别在于上下文（Context）。

所有的 LLM 都受限于有限的上下文窗口，这迫使我们必须对模型一次能“看到”什么做出艰难的取舍。上下文工程（Context Engineering）的核心就在于将这个窗口视为一种稀缺资源，并围绕它设计一切（检索、记忆系统、工具集成、提示词等），以确保模型将其有限的注意力预算仅用于高信号的 Token 上。

什么是上下文窗口？

上下文窗口是模型的活动工作区，它保存着当前任务的指令和信息。每一个单词、数字和标点符号都会占用这个窗口的空间。把它想象成一块白板：一旦写满了，就必须擦除旧的信息来为新的腾出空间，这导致重要的过往细节丢失。用更专业的术语来说，上下文窗口指的是语言模型在生成响应时一次可以考虑的最大输入数据量（以 Token 计量）。这个窗口包括了所有的输入、模型的输出、工具调用和检索到的文档，充当了短期记忆的角色。放入上下文窗口的每一个 Token 都会直接影响模型能“看到”什么以及如何做出反应。

上下文工程 vs. 提示工程

提示工程（Prompt Engineering） 侧重于如何措辞和构建指令，以便让 LLM 生成最佳结果，例如编写清晰/巧妙的提示词、添加示例或要求模型“逐步思考”。虽然这很重要，但单靠提示工程无法解决模型与外部世界断连这一根本限制。

上下文工程（Context Engineering） 则是一门设计架构的学科，旨在正确的时间向 LLM 提供正确的信息。它是关于建立桥梁，将断连的模型与外部世界连接起来，检索外部数据，使用工具，并赋予它记忆，使其回答基于事实，而不仅仅是基于训练数据。

简单来说，提示工程是你“如何提问”，而上下文工程是确保模型在开始思考之前，能够访问正确的教科书、计算器，甚至是你之前对话的笔记/记忆。LLM 的质量和有效性在很大程度上受其接收到的提示词影响，但如果没有精心设计的上下文，单纯优化提示词的措辞作用有限。像思维链（Chain-of-Thought）、少样本学习（Few-shot learning）和 ReAct 等提示技术，只有在结合了检索文档、用户历史或领域特定数据时才最有效。

上下文窗口的挑战

LLM 的上下文窗口一次只能容纳有限的信息。这一根本约束决定了当前的智能体（Agents）和智能体系统（Agentic Systems）的能力边界。每当智能体处理信息时，它必须决定什么保持激活状态，什么可以被总结/压缩/删除，什么应该存储在外部，以及保留多少空间用于推理。人们很容易假设把所有东西都塞进更大的上下文窗口就能解决这个问题，但通常情况并非如此。

随着上下文的增长，会出现以下关键的故障模式：

上下文投毒（Context Poisoning）： 错误或产生幻觉的信息进入了上下文。因为智能体会重用并基于该上下文构建内容，这些错误会持续存在并像滚雪球一样放大。
上下文干扰（Context Distraction）： 智能体被过多的过往信息（历史记录、工具输出、摘要）所累，过度依赖重复过去的行为，而不是进行新的推理。
上下文混淆（Context Confusion）： 不相关的工具或文档挤占了上下文，分散了模型的注意力，导致其使用错误的工具或指令。
上下文冲突（Context Clash）： 上下文中相互矛盾的信息误导了智能体，使其陷入相互冲突的假设之间进退两难。

这些不仅仅是技术限制，更是任何现代 AI 应用的核心设计挑战。你不能简单地通过写更好的提示词或增加上下文窗口的最大尺寸来解决这个根本限制。你必须围绕模型构建一个系统。

这就是上下文工程的全部意义所在！

上下文工程的六大核心组件

上下文工程是一个由六个相互依赖的组件构成的系统，这些组件控制着什么信息到达模型以及何时到达。智能体（Agents） 编排决策，查询增强（Query Augmentation） 优化用户输入，检索（Retrieval） 连接外部知识，提示（Prompting） 引导推理，记忆（Memory） 保存历史，工具（Tools） 赋能现实世界的行动。

1. 智能体 (Agents)

智能体正迅速成为构建 AI 应用的基础。它们既是其上下文的架构师，也是这些上下文的使用者，动态地定义整个系统中的知识库、工具使用和信息流。

智能体的定义

AI 智能体是一个使用大语言模型（LLM）作为“大脑”来进行决策和解决复杂任务的系统。用户提供一个目标，智能体利用其环境中的可用工具，找出实现该目标的步骤。

以下四个组件通常构成一个智能体：

LLM（大语言模型）： 负责推理、规划和编排整体任务。
工具（Tools）： 智能体可以调用的外部功能：例如搜索引擎、数据库、API。
记忆（Memory）： 存储上下文、先前的交互或在任务执行期间收集的数据。
观察与推理（Observation & Reasoning）： 分解任务、规划步骤、决定何时/使用哪些工具以及如何处理失败的能力。

智能体在上下文工程中的位置

智能体位于上下文工程系统的中心。它们既是上下文的使用者（从检索到的数据、历史记录和外部知识中提取信息），也是上下文的架构师（决定呈现、保留或丢弃哪些信息）。

在单智能体系统中，一个智能体处理完整的流程，决定何时搜索、总结或生成。在多智能体系统中，多个智能体各自承担特定的角色，共同致力于更大的目标。在这两种情况下，上下文的构建和共享方式决定了系统的性能。

智能体可以有许多不同的任务和功能，从定义不同的检索或查询策略，到验证响应的质量或完整性，再到从可用选项中动态选择工具。智能体提供了系统所有不同部分之间的编排，以便对信息管理做出动态的、适合上下文的决策。

2. 查询增强 (Query Augmentation)

查询增强是针对下游任务（如查询数据库或向智能体展示信息）优化用户初始输入的过程。不幸的是，这比听起来要难得多，但极其重要。再复杂的算法、重排序模型或巧妙的提示词，也无法真正弥补被误解的用户意图。

主要有两点需要考虑：

用户通常不会以理想的方式与聊天机器人或输入框交互。 大多数演示都假设用户以格式完美的句子输入完整的请求，但在生产级应用中，实际使用情况往往是混乱、不清晰和不完整的。
AI 系统的不同部分需要以不同的方式理解和使用用户的查询。 最适合 LLM 的格式可能与查询向量数据库所用的格式不同，因此我们需要一种方法来增强查询，以适应工作流中的不同工具和步骤。

Weaviate 查询智能体（Query Agent）就是如何在任何 AI 应用中轻松构建查询增强的一个很好的例子。它的工作原理是接收用户的自然语言提示，并根据其对集群数据结构和 Weaviate 本身的了解，决定基于该提示构建数据库查询的最佳方式。

3. 检索 (Retrieval)

在构建 AI 时有一句俗话：垃圾进，垃圾出（Garbage in, garbage out）。你的检索增强生成（RAG）系统的好坏取决于它检索到的信息。如果是基于不相关的上下文，那么写得再好的提示词和再强大的模型也是无用的。这就是为什么第一步，也是最重要的一步，是优化你的检索。

在这里你将做出的最重要的决定是你的分块策略（Chunking Strategy）。这是一个经典的工程权衡：

小分块： 精度高。它们的嵌入（embeddings）非常聚焦，很容易找到精确的匹配。缺点是什么？它们通常缺乏让 LLM 生成有意义答案所需的周围上下文。
大分块： 上下文丰富，这对 LLM 的最终输出非常有利。但是它们的嵌入可能会变得“嘈杂”并被平均化，从而使精确定位最相关的信息变得更加困难。此外，它们在 LLM 的上下文窗口中占用更多空间，可能会挤占其他相关信息。

找到精度和上下文之间的最佳平衡点是高性能 RAG 的关键。如果弄错了，你的系统将无法找到正确的事实，迫使模型退回到“幻觉”状态，而这正是你试图避免的。

为了帮助你找到适合你用例的最佳分块策略，我们创建了一份备忘单，列出了从简单到高级的最常见分块策略：

这份备忘单是一个很好的起点。但是，如果你从基本的概念验证（PoC）转向生产就绪的系统，问题通常会变得更难。你应该预先对所有内容进行分块，还是需要更动态的后分块架构？如何找到最佳的分块大小？

4. 提示技术 (Prompting Techniques)

一旦你完善了检索，你的系统可以在毫秒内提取最相关的信息块。你的工作完成了吗？

不完全是。你不能只是把它们塞进上下文窗口然后祈祷有好结果。你需要告诉模型如何使用这些新发现的信息。这种技术称为提示工程。

在检索系统中，你的提示词是控制层。它是告诉 LLM 如何行为的一组指令。你的提示词需要清晰地定义任务。你是在要求模型：

综合来自多个（有时是相互冲突的）来源的答案？
提取特定实体并将其格式化为 JSON 对象？
仅基于提供的上下文回答问题以防止幻觉？

如果没有清晰的指令，模型将忽略你精心检索的上下文并产生幻觉。你的提示词是让模型尊重你提供的事实的最后一道保障。

你可以选择一整套提示技术工具箱。但要从理论走向生产，你不仅需要知道这些框架是什么，还需要知道如何以及何时实施它们。

5. 记忆 (Memory)

无状态的 LLM 可以很好地回答单个问题，但它不知道五分钟前发生了什么，也不知道这对下一个决策有什么重要性。记忆将模型转变为某种感觉更动态、甚至可以说更“像人”的东西，能够保持上下文、从过去中学习并即时适应。对于上下文工程而言，核心挑战不是“我们能存储多少？”，而是**“此时此刻什么值得出现在模型面前，什么可以安全地放在其他地方？”**

智能体记忆的架构

AI 智能体中的记忆主要是关于保留信息以应对不断变化的任务，记住什么有效（或无效），并进行前瞻性思考。为了构建强大的智能体，我们需要分层思考，通常混合不同类型的记忆以获得最佳结果。

短期记忆（Short‑term memory）： 是实时的上下文窗口：最近的对话轮次/推理、工具输出以及模型推理当前步骤所需的检索文档。这个空间极其有限，所以它应该保持精简，只保留足以维持对话连贯和决策有据可依的对话历史。
长期记忆（Long-term memory）： 相比之下，它存在于模型之外，通常位于向量数据库中以便快速检索（RAG）。这些存储保持信息的持久性，并且可以保存：
情景数据（Episodic Data）： 过去的事件、用户交互、偏好。
语义数据（Semantic Data）： 一般知识和领域知识。
程序性数据（Procedural Data）： 惯例、工作流、决策步骤。

因为它是外部的，这种记忆可以增长、更新并在模型的上下文窗口之外持久存在。

大多数现代系统通常实施混合记忆设置，即混合短期记忆和长期记忆以增加深度。一些架构还添加了工作记忆（Working memory）：多步骤任务期间所需信息的临时空间。例如，在预订旅行时，智能体可能会将目的地、日期和预算保存在工作记忆中，直到任务完成，而不会将其永久存储。

设计不污染上下文的记忆

最糟糕的记忆系统是忠实地存储一切的系统。旧的、低质量的或嘈杂的条目最终会通过检索回来，并开始用陈旧的假设或无关的细节污染上下文。有效的智能体是有选择性的：它们过滤哪些交互被提升到长期存储中，通常是通过让模型对事件进行“反思”并在保存之前分配重要性或有用性评分。

一旦进入存储，记忆就需要维护。定期修剪、合并重复项、删除过时事实，以及用紧凑的摘要替换长篇记录，可以保持检索的敏锐度，防止上下文窗口被历史杂波填满。像“最近性”和“检索频率”这样的标准是简单但强大的信号，用于决定保留什么和淘汰什么。

6. 工具 (Tools)

如果记忆让智能体记住过去，那么工具使用赋予了它在当下行动的能力。没有工具，即使是最复杂的 LLM 也被锁在一个文本气泡里，也就是说，它可以出色地推理、起草和总结，但它无法查看实时股票价格、发送电子邮件、查询数据库或预订航班。工具是思想与行动之间的桥梁，是让智能体走出其训练数据并与现实世界互动的媒介。

工具的上下文工程不仅仅是给智能体一份 API 和指令清单。它是关于创建一个连贯的工作流，让智能体能够理解哪些工具可用，针对特定任务正确决定使用哪一个，并解释结果以推进任务。

编排挑战

给智能体一份可用工具清单很简单。让它正确、安全、高效地使用这些工具才是上下文工程工作开始的地方。这种编排涉及几个活动部分，都发生在有限的上下文窗口内：

工具发现： 智能体必须知道它有权访问的所有工具。这通过在系统提示词中提供清晰的工具列表和高质量的描述来实现。这些描述指导智能体理解每个工具的工作原理、何时使用以及何时避免使用。
工具选择和规划： 当用户提出请求时，智能体必须决定是否需要工具，如果需要，选择哪一个。对于复杂任务，它可能会规划一系列要使用的工具（例如：“搜索天气，然后通过电子邮件发送摘要”）。
参数构建： 选择工具后，智能体必须确定传递的正确参数。例如，如果工具是 get_weather(city, date)，它必须从用户的查询中推断细节，如“旧金山”和“2025-11-25”，并将它们格式化以便调用。
反思（Reflection）： 工具执行后，输出返回给智能体。智能体审查它以决定下一步做什么：工具是否正常工作，是否需要更多迭代，或者错误是否意味着它应该完全尝试不同的方法。

如你所见，编排通过这个强大的反馈循环发生，通常称为**思考-行动-观察（Thought-Action-Observation）**循环。智能体不断观察其行动的结果，并利用该新信息来推动其下一个“思考”。这个循环构成了像我们自己的 Elysia 这样的现代智能体框架中的基本推理循环。

转向使用 MCP 进行标准化

工具使用的演变正越来越趋向于标准化。虽然函数/工具调用（Function Calling）效果不错，但它创建了一个碎片化的生态系统，每个 AI 应用程序都需要与每个外部系统进行自定义集成。Anthropic 在 2024 年底推出的**模型上下文协议（Model Context Protocol, MCP）**通过为 AI 应用程序连接外部数据源和工具提供通用标准，解决了这个问题。他们称之为“AI 的 USB-C”——一种任何兼容 MCP 的 AI 应用程序都可以用来连接任何 MCP 服务器的单一协议。因此，开发人员无需为每个工具构建自定义集成，只需创建通过此标准化接口公开其系统的独立 MCP 服务器。任何支持 MCP 的 AI 应用程序都可以使用基于 JSON-RPC 的协议轻松连接到这些服务器进行客户端-服务器通信。这将 MxN 集成问题（M 个应用程序每个都需要针对 N 个工具的自定义代码）转化为简单得多的 M + N 问题。

随着工具使用集成的标准化，真正的工作变成了设计能够一起思考的系统，而不是把它们硬连线在一起。

示例：使用 Elysia 构建现实世界的智能体

示例涵盖的所有内容——从智能体编排决策、查询增强塑造检索、记忆保存状态，到工具赋能行动——当你构建真实系统时都会汇聚在一起。

与简单的“先检索后生成”管道不同，Elysia 的决策智能体在选择下一步做什么之前，会评估环境、可用工具、过去的行动和未来的选项。树中的每个节点都具有全局上下文感知能力。当查询失败或返回不相关的结果时，智能体可以识别出这一点并调整其策略，而不是盲目地继续。

在这个示例中，我们将构建一个智能体，它可以通过 Elysia 框架的智能决策和编排，搜索实时新闻、获取文章内容并查询你现有的 Weaviate 集合。你可以通过将 Elysia 作为 Python 包安装来开始使用：

pip install elysia-ai

用于上下文感知检索的内置工具

Elysia 包含五个强大的内置工具：query（查询）、aggregate（聚合）、text_response（文本响应）、cited_summarize（引用总结）和 visualize（可视化）。

query 工具使用不同的搜索策略检索特定数据条目，例如混合搜索或简单的对象获取，并通过 LLM 智能体自动选择集合和生成过滤器。
aggregate 工具执行计算，如计数、平均和求和，具有分组和过滤功能，同样由 LLM 智能体辅助。
text_response 和 cited_summarize 直接向用户响应，分别是普通文本或包含环境检索上下文引用的文本。
visualize 工具帮助可视化环境中的数据，使用动态显示，如产品卡片、GitHub Issues、图表等。

在与你的集合交互之前，你需要对集合运行 Elysia 的 preprocess() 函数，以便 Elysia 可以分析模式（schema）模式并推断关系。

from elysia import configure, preprocess# 连接到 Weaviateconfigure(    wcd_url = "...", # 替换为你的 Weaviate REST 端点 URL    wcd_api_key = "...", # 替换为你的 Weaviate 集群 API Key    base_model="gemini-2.5-flash",    base_provider="gemini",    complex_model="gemini-3-pro-preview",    complex_provider="gemini",    gemini_api_key = "..."# 替换为你的 GEMINI_API_KEY)# 预处理你的集合（一次性设置）preprocess(["NewsArchive", "ResearchPapers"])

注意： 此示例假设你已经在 Weaviate 集群中设置了 NewsArchive 和 ResearchPapers 集合，并摄入了一些数据。如果你是从头开始，请查看 Weaviate 关于创建集合和导入对象的文档，以便为 Elysia 准备好数据。

扩展智能体能力的自定义工具

Elysia 还可以使用完全自定义的工具以及内置工具。这使你可以将智能体的触角从本地集合扩展到实时数据、外部 API 或任何其他数据源。

以下是如何使用 Elysia 构建一个简单的智能体，该智能体使用 Serper API 搜索实时新闻，获取文章内容，并轻松查询现有的多个集合：

from elysia import Tree, tool, Error, Resulttree = Tree()@tool(tree=tree)asyncdef search_live_news(topic: str):    """使用 Serper 通过 Google 搜索实时新闻标题。"""    import httpx    asyncwith httpx.AsyncClient() as client:        response = await client.post(            "https://google.serper.dev/news",            headers={                "X-API-KEY": SERPER_API_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)asyncdef fetch_article_content(url: str):    """以 markdown 格式提取完整的文章文本。"""    from trafilatura import fetch_url, extract    downloaded = fetch_url(url)    text = extract(downloaded)    if text isNone:        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 的内置 query 工具通过路由到 NewsArchive 获取过去的文章，路由到 ResearchPapers 获取学术来源，在两个集合中进行搜索。

当你接着问“XYZ 作者的哪些学术论文讨论了这个话题？”时，智能体会识别意图并优先考虑 ResearchPapers 集合，而无需你明确指定。

这就是实践中的上下文工程：决策智能体编排信息流，即时增强查询，从多个来源检索，跨轮次维护状态，并使用工具对世界采取行动——所有这些都在最大化利用有限的上下文窗口，只保留相关的 Token 来驱动推理。

信息： 完整的 Elysia 文档可在以下网址获得：https://weaviate.github.io/elysia/

总结

如果没有来自检索的干净数据，一个强大的智能体也是无用的。如果糟糕的提示词误导了模型，那么优秀的检索也会被浪费。如果没有记忆提供的历史记录或工具赋予的现实世界访问权限，即使是最好的提示词也无法发挥作用。

上下文工程就是要把我们的角色从对模型说话的“提示者（Prompters）”，转变为构建模型所处世界的“架构师（Architects）”。

作为建设者，我们知道更大的模型不一定能创造出最好的 AI 系统，更好的工程设计才行。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述