40页的上下文工程ebook「深度拆解」｜weaviate

如果你也在做 RAG 或智能体应用，大概经历过这些瞬间：文档切得太碎，答案失去上下文；切得太大，又召回不准；加了更多提示词，效果可能更不稳定。

Weaviate 团队比我们更早碰到这些问题，这是一家总部在荷兰阿姆斯特丹的向量数据库软件公司，在GitHub上拥有14.9kstar的项目开源数据库（Weaviate OSS），他们每天都在与真实数据和生产流量打交道。久而久之，他们总结了一套完整的方法，并写成《Context Engineering》电子书。

这本书一共才40页，但信息密度极大，主要研究如何为大语言模型（LLM）设计获取信息、组织信息与保持连贯性的整套系统”。书里把一个“能落地的 AI 应用”拆成六大能力：智能体（Agents）、查询增强（Query Augmentation）、检索（Retrieval）、提示词技巧 (Prompting Techniques)、记忆（Memory）、工具（Tools）。

本文将继昨天上海交大的论文继续深入讲解Context Engineering，让我们就沿着这支团队的视角，一层层把书里的技术路径剥开。

核心困境：上下文窗口的“甜蜜”陷阱

Weaviate团队认为问题的真正核心在于：上下文窗口的挑战。

上下文窗口是模型的“活动工作记忆”，一个有限的空间，用于容纳当前任务的指令和信息。就像一块白板，一旦写满，旧信息就会被擦除。

一个诱人但错误的假设是：“只要上下文窗口足够大，问题就解决了。”

Weaviate 的这份电子书明确地驳斥了这一点。它警告说，一味追求更长的上下文（例如 100 万 token）并不能解决问题，反而会引入全新的、更隐蔽的故障模式。

当上下文变得过长时，模型的性能会开始下降，它们会变得困惑、产生更高的幻觉率，或者干脆停止正常工作。这份电子书总结了上下文过载引发的四种主要“故障模式”：

1.上下文中毒 (Context Poisoning)：不正确或幻觉出的信息进入了上下文。由于智能体（Agent）会复用并建立在此基础上，这些错误会持续存在并被放大，导致系统不断重复同样的错误。

2.上下文分心 (Context Distraction)：智能体被太多过去的信息（如历史记录、工具输出）所淹没，导致它过度依赖并重复过去的行为，而不是针对新情况进行“新鲜”的推理。

3.上下文混淆 (Context Confusion)：不相关的工具或文档挤满了上下文，分散了模型的注意力，导致它使用了错误的工具或遵循了错误的指令。

4.上下文冲突 (Context Clash)：上下文中存在相互矛盾的信息，这会误导智能体，使其在冲突的假设之间“卡住”，无法做出决策。

因此，“上下文工程”的真正目标，不是盲目地“塞满”上下文，而是要智能地“管理”它。Weaviate 将这个管理系统拆解为六个协同工作的核心模块。

智能体：系统的“决策大脑”

智能体是整个系统的“决策大脑”，它负责协调其他所有组件，决定“何时”以及“如何”使用信息。

它不是一个固定的“检索-生成”管道，而是一个可以动态决策、保持状态（记忆）、自适应地使用工具，并根据结果修正策略的系统。

其中也分单智能体Single-Agent

以及多智能体Multi-Agent

智能体的核心能力与管理策略

根据这份电子书的定义，一个真正的 AI 智能体拥有四项核心能力：

1. 做出动态决策 (Make dynamic decisions)：它们不是遵循预定的路径，而是根据所学到的东西决定下一步做什么。
2. 跨交互保持状态 (Maintain state across multiple interactions)：它们能记住自己做过什么，并利用这些历史来为未来的决策提供信息。
3. 自适应地使用工具 (Use tools adaptively)：它们可以从可用工具中进行选择，并以非预先编程的方式组合它们。
4. 根据结果修正方法 (Modify their approach based on results)：当一种策略不起作用时，它们可以尝试不同的方法。

智能体最重要的工作，是执行“上下文卫生” (Context Hygiene)即主动监控和管理其自身上下文的质量。这包括一系列关键的“上下文管理”策略：

• 上下文总结 (Context Summarization)：定期将累积的对话历史压缩成摘要，以减少负担，同时保留关键知识。
• 质量验证 (Quality Validation)：检查检索到的信息是否一致且有用。
• 上下文修剪 (Context Pruning)：主动识别并删除上下文中不相关或过时的信息。
• 自适应检索策略 (Adaptive Retrieval Strategies)：当初始尝试失败时，智能体会重新制定查询、切换知识库或更改分块策略。
• 上下文卸载 (Context Offloading)：将细节存储在外部，仅在需要时才检索，而不是始终保持在活动上下文中。
• 动态工具选择 (Dynamic Tool Selection)：智能体不会在提示词中加载所有可用的工具，而是会过滤并只加载那些与当前特定任务相关的工具，从而减少混淆并提高准确性。
• 多源合成 (Multi-Source Synthesis)：结合来自多个来源的信息，解决它们之间的冲突，并生成一个连贯的答案。

如果缺乏这种主动管理，系统就会立刻陷入前文提到的“上下文中毒”、“分心”和“混淆”等故障模式中。

查询增强：翻译用户的“模糊意图”

上下文工程的起点，是理解用户的意图。而用户的请求往往是“混乱的、模糊不清的”。

“查询增强”要解决的就是“垃圾进，垃圾出”的问题。如果系统从一开始就误解了用户的意图，那么后续再强大的检索或提示词也无法弥补。

这份电子书详细介绍了几种从简单到高级的“意图翻译”技术：

1.查询重写 (Query Rewriting) 这是最直接的方法。它将用户模糊的自然语言，转换为精确的、机器可读的意图。

• 原始查询：“我的 api 调用总是失败，这该怎么办？”
• 重写后：query="API call failure, troubleshooting, authentication headers, rate limiting, network timeout, 500 error" 这个过程包括重组问题、删除无关信息和增强关键词。

2.查询扩展 (Query Expansion) 它不是“重写”，而是从一个查询“生成多个”相关查询，以提高检索系统的召回率，尤其适用于模糊或格式不佳的查询。

• 原始查询：“Open source NLP tools”
• 扩展后：[“Natural language processing tools”, “Free nlp libraries”, “Open source language processing platforms”, ...]

3.查询分解 (Query Decomposition) 用于处理复杂的多方面问题，例如需要从多个来源获取信息或涉及多个概念的问题。它将一个大问题分解为多个可以独立处理的子查询，分别检索后再进行合成。

4.查询智能体 (Query Agents) 这是最先进的形式。它是一个专门的 AI 智能体，负责整个查询处理流程。它拥有更高级的能力：

• 动态构建：能决定是运行“搜索”还是“聚合”(aggregation)，并自动添加过滤器。
• 多集合路由 (Multi-collection routing)：能理解你的所有数据集合，并智能地决定查询哪一个（或哪几个）集合。
• 评估与迭代：能评估检索到的信息是否相关。如果不相关或信息不足，它可以决定重新查询或尝试新的知识源。

检索：RAG 的基石与“分块”的艺术

检索（Retrieval）是连接 LLM 与你的特定知识库的“桥梁”。这是实现检索增强生成（RAG）的核心。但原始文档（如 PDF、Word）通常太大，无法直接放入上下文窗口。

因此，RAG 系统中最重要的工程决策就是“分块” (Chunking)——即将大文档分解为更小的、可管理的片段。

核心权衡：“分块的甜蜜点” (The Chunking Sweet Spot)

分块的成败，在于平衡两个相互冲突的目标：

1. 检索精度 (Retrieval Precision)：需要小而专注的块。这会创建独特而精确的向量嵌入，使其更容易被向量搜索系统找到。
2. 上下文丰富性 (Contextual Richness)：需要大而完整的块。如果块只是一个没有上下文的孤立句子，LLM 拿到它也无法生成有意义的回复。

你的目标是找到“甜蜜点”。你必须避开“精确但信息不完整”（块太小） 和“丰富但无法找到”（块太大，向量嵌入“嘈杂”） 的陷阱。

分块技术：从简单到高级

为了达到这个“甜蜜点”，你需要根据文档类型选择合适的分块策略：

• 简单的分块策略
• 固定大小 (Fixed-Size)：最简单的方法，按固定的 Token 数（如 512）分割。缺点是会粗暴地切断句子。使用“重叠”(overlap) 可以缓解这个问题。

递归 (Recursive)：更智能的方法，它会尝试按一个优先的分隔符列表（如：段落、句子、单词）来拆分，以尽可能尊重文档的自然结构。

基于文档 (Document-Based)：按文档的固有结构（如 Markdown 的标题 #、HTML 的标签 <p>）来拆分。

• 高级的分块策略
• 语义 (Semantic)：不按字符数或分隔符，而是按意义拆分。它将语义相关的句子组合在一起，只有当主题转变时才创建新块。

分层 (Hierarchical)：创建多个层级的块（例如：顶层摘要、中层章节、底层段落）。这允许系统从宏观“钻取”到微观。

基于 LLM (LLM-Based)：使用 LLM 来智能地处理文档，生成语义连贯的块，例如识别逻辑命题或总结章节。

延迟分块 (Late Chunking)：这是一种颠覆标准流程的架构模式，它不是先分块再嵌入，而是先嵌入整个文档 ，使用长上下文模型生成具有完整上下文的“Token 级嵌入”。然后，它才将这些上下文丰富的“Token 嵌入”（而非原始文本）分割成块。

智能体分块 (Agentic Chunking)：这是最高级的方法。一个 AI 智能体动态分析文档的结构和内容，并为该特定文档选择最佳的分块策略（或策略组合）。

“何时”分块：预分块 vs. 后分块

电子书还提出了一个关键的架构决策：何时进行分块。

• 预分块 (Pre-Chunking) 这是最常见的方法。在用户查询之前，所有文档都已离线处理、分块、嵌入并存储在向量数据库中。

• 优点：查询时速度极快，因为所有繁重的工作都已完成。
• 缺点：策略是固定的。如果想更改分块大小或方法，必须重新处理整个数据集。
• 后分块 (Post-Chunking) 这是一种更先进、更灵活的实时替代方案。系统首先检索完整的文档，然后在实时中，根据用户的具体查询动态地将该文档分块。

• 优点：高度灵活。你可以制定动态的分块策略，以适应特定查询的上下文。
• 缺点：增加了延迟，因为分块是实时发生的，并且需要更复杂的基础设施。

提示词技巧

如果说“上下文工程”是关于提供信息，那么“提示词工程”就是关于下达指令。它是引导模型推理的技巧。

关键的推理技术

电子书强调了几种对 RAG 和智能体系统至关重要的技术：

• 思维链 (Chain of Thought, CoT)：这是一种经典技巧，要求模型“一步一步地思考”。它通过让 LLM 详细说明其推理过程，来得出更准确、更合乎逻辑的结论。

• 专业提示 1：让 CoT 的推理步骤非常具体以适应你的用例。例如，你可以要求模型：“1. 评估环境；2. 重复任何相关信息；3. 解释此信息对当前请求的重要性。”
• 专业提示 2：为了减少 Token 消耗，可以要求模型以“草稿”形式进行推理，例如“每句话不超过 5 个词”，这既能保留推理过程的可见性，又降低了成本。
• 思维树 (Tree of Thoughts, ToT)：这是 CoT 的进化版。它指示模型并行探索和评估多条推理路径，就像一个决策树。模型可以生成多个不同的解决方案，并从中选择最好的一个。

• ReAct：这个框架将“推理 (Reason)”（即 CoT）和“行动 (Act)”（即使用工具）结合起来。模型以交错的方式生成推理轨迹和动作，使其能够与外部工具交互，并根据返回的“观察”来迭代地调整其推理。

为工具使用编写提示词

对于与外部世界交互的智能体而言，最重要的是“为工具使用编写提示词”。LLM 能否正确使用你提供的工具，几乎完全取决于你如何描述这个工具。一个有效的工具描述必须：

1. 使用主动动词：以清晰的动作开始（例如，用 get_current_weather 而不是 weather_data）。
2. 明确输入：清楚地说明需要的参数及其格式（例如：city (string), date (string, YYYY-MM-DD)）。
3. 描述输出：告诉模型会返回什么（例如：“返回一个包含‘high’, ‘low’和‘conditions’的 JSON 对象”）。
4. 提及限制：如果工具只在特定区域有效，一定要说明（例如：“注意：仅适用于美国城市。”）。

记忆：赋予AI“过去”与“成长”

如果说 LLM 是 CPU，那么上下文窗口就是 RAM（内存）。但 RAM 是易失的、有限的。为了让 AI 拥有“历史感”和“学习能力”，我们必须为其构建一个更持久、更智能的记忆系统。

Weaviate 提出了一个优雅的“记忆分层架构”：

• 短期记忆 (Short-Term Memory) 这就是当前的上下文窗口。它是智能体即时的工作空间，用于“即时”的决策和推理。
• 长期记忆 (Long-Term Memory) 这是将信息存储在外部（如向量数据库）的持久化系统，通过 RAG 在需要时检索。它又分为：
• 情景记忆 (Episodic Memory)：存储过去的具体事件和交互，例如用户的偏好、过去的对话历史。
• 语义记忆 (Semantic Memory)：存储一般领域知识和事实，例如公司文档、产品手册。
• 高级分层：工作记忆与程序记忆 这是专业系统的分水岭：
• 工作记忆 (Working Memory)：一个临时的暂存区或“草稿纸”，用于处理特定的多步骤任务。例如，在预订航班时，它会临时保存目的地、日期和预算，任务完成后即可丢弃，而不会“污染”长期记忆。
• 程序记忆 (Procedural Memory)：帮助智能体学习和掌握例程。通过观察成功的工作流，智能体可以将其内化为“决策工作流”，使其在未来能更快、更可靠地执行相同的任务。

有效记忆管理的关键原则

仅仅拥有记忆层是不够的；糟糕的记忆实践会导致“错误传播”。电子书强调了四个关键的管理原则：

1.有选择地存储 (Be Selective About What You Store)：不是每次交互都值得永久保存。必须实施过滤标准来评估信息的质量和相关性。一个坏信息会导致“上下文污染”。一种方法是让 LLM 在存储前进行“反思”(reflect) 并分配一个重要性得分。

2.修剪和提炼你的记忆 (Prune and Refine Your Memories)：记忆需要定期维护。定期扫描长期存储，以删除重复条目、合并相关信息或丢弃过时的事实。可以使用“新近度”和“检索频率”等指标来决定是否删除。

3.掌握检索的艺术 (Master the Art of Retrieval)：有效的记忆不在于你存储了多少，而在于你能在正确的时间检索到正确的信息。这需要使用重排序 (Reranking)（让 LLM 重新排序检索结果的相关性）和迭代检索（多步骤优化搜索查询）等高级技术。

4.根据任务定制架构 (Tailor the Architecture to the Task)：没有万能的记忆方案。客服机器人需要强大的情景记忆来回忆用户历史，而财务分析机器人则需要强大的语义记忆来填充领域知识。

工具：赋予“大脑”一双“手”

如果说记忆给了智能体“自我感”，那么工具就给了它“超能力”。工具将 LLM 从一个“文本处理器”转变为一个可以“采取行动”并与现实世界交互的执行者。

这得益于“功能调用”（Function Calling）的突破。LLM 不再是猜测答案，而是可以输出结构化的 JSON，来请求调用一个外部函数（例如 search_flights(city, date)）并传入参数。

真正的挑战：“编排” (Orchestration)

给予智能体一个工具很简单，但让它可靠、安全、有效地使用这个工具，才是真正的难题。这就是“编排”的艺术。

电子书将这个编排流程，总结为一个强大的反馈循环：“思考-行动-观察”循环 (Thought-Action-Observation cycle)。

以电子书中一个名为 Glowe 的护肤应用为例：

1.思考 (Thought)：用户提问“我这种肤质最适合哪种洁面乳？”智能体进行推理，决定需要使用 product_agent 工具。

2.行动 (Action)：智能体从用户查询和记忆中提取并格式化工具所需的参数。它制定了搜索查询 “cleanser for dry skin and hydration”。

3.观察 (Observation)：工具执行后，其输出结果（即产品列表）被反馈回智能体的上下文窗口。智能体反思这个结果，并决定下一步行动（即为用户生成最终的推荐答案）。

电子书还展示了一个更高级的“自愈” (self-healing) 案例：当智能体第一次调用工具因参数错误而失败时，它在“观察”到错误后，在下一次“思考”中自动修正了参数，并成功完成了任务。

工具的未来：标准化 (MCP)

当前工具的使用方式（每个应用为每个工具编写自定义集成）造成了一个“碎片化的生态系统”。

电子书介绍了工具使用的下一个前沿：模型上下文协议 (Model Context Protocol, MCP)。

• 这是什么？ 它由 Anthropic 推出，旨在成为“AI 的 USB-C”。它是一个通用标准，用于将 AI 应用连接到外部数据源和工具。
• 它如何解决问题？ 它将 N×M 的集成问题（N 个应用为 M 个工具编写 N*M 个自定义集成） 转变为一个 M+N 的问题。模型和工具只需要集成一次（即支持 MCP 协议），就可以彼此互操作。
• 这意味着什么？ 这代表了 AI 工具的未来：一个由模块化、可互操作的组件构成的、可组合的标准化架构。

最后

把系统想象成一座城市：提示词是路标，检索是道路，记忆是档案馆，工具是公共设施，而智能体就是城市管理者。Weaviate《Context Engineering》这本书教的不是某条捷径，而是城市的规划法。 我们从“RAG切得太碎答不全、切得太大找不准、提示词越写越乱”出发，也以它作结：

• 太碎？ 用递归，语义分块找回上下文；
• 太大？ 让重排与后分块兜底；
• 太乱？ 交给查询增强与上下文卫生。

当检索、记忆与工具在智能体手里形成闭环，系统的稳定与可维护性就回来了。下一次再遇到类似问题，先把信息流理顺，别急着加token。你会发现：变强的不是模型，而是你的工程。

文章来自于“AI修猫Prompt”，作者 “AI修猫Prompt”。