动手搭建一个上下文工程工作流

Build a Context Engineering workflow

接下来，我们会运用上下文工程的原则，搭建一个多智能体（multi-agent）研究助手。

这个智能体会从 4 个来源收集上下文：文档、记忆、网络搜索，以及 arXiv。

下面是我们的工作流：

• 用户提交查询。
• 从文档、网络、arXiv API 和记忆中获取上下文。
• 把汇总后的上下文交给一个智能体进行筛选。
• 把筛选后的上下文交给另一个智能体，生成最终回答。
• 把最终回答保存进记忆。

技术栈：

• Tensorlake：从复杂文档中提取出可直接用于 RAG 的数据
• Zep：负责记忆
• Firecrawl：负责网络搜索
• Milvus：作为向量数据库
• CrewAI：负责编排调度

开始吧！

CE（上下文工程）的核心，是构建能够提供以下要素的动态系统：

• 正确的信息
• 正确的工具
• 以正确的格式呈现

这能确保 LLM 有效地完成任务。

#1）Crew 流程

我们会采用自上而下的方式来理解这份代码。

下面是我们整个流程的大致框架：

请注意，这只是实现上下文工程工作流的众多蓝图之一。你实际的流水线，很可能会因具体使用场景而有所不同。

#2）为 RAG 准备数据

我们用 Tensorlake 把文档按章节转换成可直接用于 RAG 的 markdown 分块。

提取出的数据无需再做额外处理，就可以直接进行 embedding 并存入向量数据库。

#3）索引与检索

现在我们已经有了带元数据的、可用于 RAG 的分块，接下来该把它们存进一个自托管的 Milvus 向量数据库了。

我们会检索出与查询最相似的 top-k 个分块：

#4）搭建记忆层

Zep 是我们这套工作流的核心记忆层。它会构建带时间维度的知识图谱，用来组织和检索每一次交互的上下文。

我们用它来存储和检索来自对话历史与用户数据的上下文。

#5）用 Firecrawl 做网络搜索

我们用 Firecrawl 的网络搜索功能，获取与用户查询相关的最新资讯和进展。

Firecrawl 的 v2 接口提供了快 10 倍的抓取速度、语义级抓取，以及图片搜索能力，能把任何网站都转换成可直接供 LLM 使用的数据。

#6）ArXiv API 搜索

为了进一步支持研究类查询，我们使用 arXiv API，根据用户的查询从其数据仓库中检索相关结果。

#7）筛选上下文

接下来，我们把汇总好的上下文，交给「上下文评估智能体」，由它过滤掉不相关的内容。

筛选之后的上下文，再交给「合成智能体」，由它生成最终的回答。

#8）启动工作流

最后，我们用一个查询来启动整套上下文工程工作流。

根据这个查询的结果可以看到，由 Tensorlake 驱动的 RAG 工具，是 LLM 生成回答时最相关的信息来源。

我们还把这套工作流做成了一个 streamlit 应用，它能：

• 提供带链接和元数据的引用来源。
• 呈现与相关信息来源有关的洞察。

以上讲解的这套工作流，只是众多蓝图之一。你自己的实现方式完全可以有所不同。