上下文数据库设计--向量数据库VikingDB-火山引擎

文档中心

向量数据库VikingDB

OpenViking Service

上下文数据库设计

OpenViking Service 将 Agent 的上下文管理，从“扁平知识召回”升级为“可导航、可追溯、可演化的上下文文件系统”。

说明

OpenViking Service 的目标是把 Agent 所需要的知识、经验和能力统一组织为一套可读、可管、可检索的文件系统。
这篇文档主要回答以下三个问题：

为什么 OpenViking Service 选择文件系统范式来组织上下文。
OpenViking Service 如何将不同类型的上下文统一抽象。
OpenViking Service 如何通过分层供给，在完整性与成本之间取得平衡。

文件系统范式

1. 文件系统相较于 RAG 的显著优势

传统 RAG 更像一个扁平的“知识碎片仓库”：文档被切分、向量化、召回，但其原有层级、目录关系、来源边界和演化过程往往被弱化。对于 AI Agent 来说，这会带来几个明显问题：

上下文碎片化：分段、丢失章节、跨文件。。。资源、记忆、技能常常分散在不同系统中，缺少统一的组织方式。
结构丢失：检索命中了某段内容，却很难知道它属于哪个项目、哪个主题、哪个上层任务。
调试困难：Agent 为什么读到这段内容、漏掉那段内容，路径不清晰，过程不透明。
成本失控：缺少稳定的目录边界和分层结构时，Agent 往往只能“多取一点”，导致 Token 浪费。

OpenViking Service 的核心思路是把上下文当作文件系统来管理，这意味着：

统一资源管理：每一份上下文和资源都有稳定的 URI 路径与归属，通过明确的目录组织，将分散的记忆、技能和数据整合进统一的目录树中。
显式语义边界：每一个目录都表达一个明确的语义边界与上层任务关联，让 Agent 在命中局部内容时，能知晓其所属的项目、主题和上下文结构。
可追溯的渐进路由：每一次读取都遵循 “路径定位 - 目录理解 - 详情展开” 的渐进式跳转，检索结果能追溯到具体文件和父级目录。
按需加载的目录边界：依托 L0（摘要），L1（概览），L2（细节）的分层结构与目录边界实现按需精准读取，解决非必要 Token 的浪费。

2. 文件系统的组织规范

OpenViking Service 通过构建一套严谨的文件系统组织规范，实现了上下文的“统一治理”与“语义保留”。 该系统采用标准的 URI 定位符作为核心逻辑架构：

viking://{scope}/{path}

在 Scope（顶层命名空间） 层面，为不同生命周期的信息划分了明确的边界，如承载外部知识的 resources、记录用户画像的 user、存储工具技能的 agent 以及管理当前对话流的 session，这种划分确保了资源、记忆与技能在逻辑上的高度有序：

viking://
├── resources/                 # 外部知识与规则
├── user/                      # 用户相关的长期认知
├── agent/                     # Agent 的技能与经验
└── session/                   # 会话过程中的临时与归档上下文

在 Path（具体路径） 层面，借鉴本地文件系统的特征，将路径视为稳定的上下文标识，将目录作为语义边界，将文件定义为具体的内容或能力单元，并引入包含元数据的特殊文件实现低成本感知，配合标准化的文件操作实现自动接入。OpenViking Service 通过保留项目、模块与用户偏好之间的层级关系而非将其抹平，Agent 能够像在本地磁盘操作一样，沿着目录树进行逐层推理、按需定位与精准调用，从而在推理过程中获得信息透明度与掌控力。

抽象对象	在 OpenViking Service 中的含义	对 Agent 的价值
路径	上下文的稳定标识	可引用、可追溯、可缓存
目录	语义边界和组织单元	便于逐层定位与导航
文件	具体内容或能力定义	便于按需读取详情
特殊文件	摘要、概览、关系、元数据	便于低成本理解上下文
文件操作	增删改查、移动、搜索	便于标准化接入与自动化处理

3. 目录作为一种语义

OpenViking Service 中，一个资源目录可以表示一个项目、一套文档或一个主题：

viking://resources/payments/
├── .abstract.md
├── .overview.md
├── .relations.json
├── prd/
├── api/
└── faq/

这里的 payments/prd； payments/api 目录本身携带了明确的业务语义，当 Agent 当检索命中某个子文件时，能知道它在整体路径中的明确位置，通过对 L1 的快速阅读，判断是否值得展开读取。当目录之间存在关联关系时，系统可以据此递归扩展相关上下文:

L0 / .abstract.md：用一句话到一小段话回答“这是什么”
L1 / .overview.md：回答“里面大概有什么、重点是什么、建议先看哪里”
L2 / 原始文件和子目录：提供完整详情，供真正需要时再深入读取

普通文件夹中，Agent 实际上只能“看到文件名”，很难快速理解这个目录的主题、重点和阅读路径。例如：

users/
payments/
├── prd_v3_final.md
├── openapi.yaml
├── refund_rule.md
└── faq.md

因此，普通文件夹解决的只是“文件放在哪里”，而 OpenViking Service 的虚拟文件系统解决的是“这个目录在说什么，以及应该怎么读”。

4. 文件系统范式支持自迭代

文件系统范式除了能够管理静态知识，也适合承载会不断变化的动态上下文。OpenViking Service 的“自迭代”意味着当目录下的内容发生变化时（例如新增文档、补充记忆、沉淀技能经验），该目录对应的语义层也会随之自动更新：

L0 / .abstract.md：目录的最新摘要
L1 / .overview.md：目录的结构概览和阅读路径
目录内部的组织关系：哪些子目录更重要、哪些主题变得更相关

新增资源内容后，目录会如何组织

新增资源内容进入系统后，OpenViking Service 会优先按照目录语义把它放到对应位置，例如：

用户上传支付相关文档前
viking://resources/payments/
├── .abstract.md
├── .overview.md
├── prd/
└── api/

如果这时用户又上传了一份《退款处理手册》，系统会把它组织到合适的目录中，例如：

用户上传支付相关文档后
viking://resources/payments/
├── .abstract.md
├── .overview.md
├── prd/
├── api/
└── refund/
    └── refund-handbook.md

此时， payments/ 这个目录的整体语义发生了更新：除了“支付需求和接口”目录，现在还包含“退款处理”新的主题，因此该目录的摘要、概览、阅读路径都应该同步变化，这也是 OpenViking Service 支持“自迭代”的关键特征：
新增退款手册之前，payments/.abstract.md 是：

# payments

这是一个支付系统知识目录，包含支付产品需求和接口定义。

新增 refund/refund-handbook.md 之后，目录级 L0 会自动更新为更符合当前内容状态的摘要：

# payments

这是一个支付系统知识目录，包含支付产品需求、接口定义以及退款处理相关说明。

同样，payments/.overview.md 也会随之更新。更新前它只描述 prd/ 和 api/：

# Payments Overview

## 主要内容
- `prd/`：支付流程和业务需求
- `api/`：支付相关接口定义

更新后，它会把新加入的目录和新的阅读路径一起纳入：

# Payments Overview

## 主要内容
- `prd/`：支付流程和业务需求
- `api/`：支付相关接口定义
- `refund/`：退款处理流程、规则和异常说明

## 建议阅读路径
- 如果问题与支付接口有关，优先查看 `api/`
- 如果问题与退款规则有关，优先查看 `refund/`

目录对应的 L0/L1 会自动重算，使目录本身也同步获得新的语义表达。

记忆目录也具备同样的自迭代能力

例如，用户最开始只有一条编码偏好：

viking://user/memories/preferences/
├── .abstract.md
├── .overview.md
└── coding-style.md

后续 Agent 又从会话中提取出“回复偏好”“语言偏好”两类新记忆后，目录会继续增长：

viking://user/memories/preferences/
├── .abstract.md
├── .overview.md
├── coding-style.md
├── response-style.md
└── language-preference.md

这时更新的不只是目录中文件数量，preferences/ 目录对应的语义层也会发生变化：

L0 会从“用户有编码风格偏好”变成“用户有编码、回复和语言偏好”
L1 会开始体现这些偏好的分类和重点，帮助 Agent 在回答前快速知道应该优先遵循哪些偏好

因此，OpenViking Service 的“自迭代”是持续地生长在一套可遍历、可检索、可管理，并且会自动更新语义层的上下文树上。

上下文分类

在 OpenViking Service 中，所有上下文被统一抽象为三种基本类型：Resource、Memory 和 Skill。这种分类方式旨在映射人类的认知模式，并为 Agent 提供结构化的信息输入。

类型	主要用途	生命周期	主动性
Resource (资源)	外部知识与规则	长期，相对静态	由用户主动添加
Memory (记忆)	Agent 的个性化认知与经验	长期，动态更新	由 Agent 自动记录/学习
Skill (技能)	可被 Agent 调用的能力	长期，相对静态	由 Agent 按需调用

1. Resource (资源)

资源是您为 Agent 提供或引用的外部知识，例如 API 文档、代码仓库、产品手册等。它们是 Agent 回答特定领域问题的知识基础。

特点：由用户主动添加，内容相对稳定，通常按照项目或主题进行结构化存储。
界面操作：在上下文管理界面的“类型筛选”区选择 Resources，即可浏览所有已添加的资源文件和目录。

支持的格式

格式	扩展名	处理方式
PDF	`.pdf`	文本和图像提取
Markdown	`.md`	原生支持
HTML	`.html`, `.htm`	清洗后文本提取
纯文本	`.txt`	直接导入
JSON/YAML	`.json`, `.yaml`, `.yml`	结构化解析
代码	`.py`, `.js`, `.ts`, `.go`, `.java` 等	语法感知解析
图像	`.png`, `.jpg`, `.jpeg`, `.gif`, `.webp`	VLM 描述
文档	`.docx`	文本提取
飞书/Lark	URL（`.feishu.cn`、`.larksuite.com`）	云端文档解析（`lark-oapi`）

2. Memory (记忆)

记忆是 Agent 在与你或环境的交互中学习并沉淀下来的知识，它塑造了 Agent 的“个性”和“经验”。记忆分为用户记忆和 Agent 自身记忆，并进一步细分为 8 种具体类别，使其具备更精细化的管理能力。

记忆分类	归属	说明	存储位置 (URI)
`profile`	User	用户的核心身份属性，如职业、角色。	`viking://user/memories/profile.md`
`preferences`	User	用户的偏好设定，如沟通风格、代码格式。	`viking://user/memories/preferences/`
`entities`	User	与用户相关的实体，如人物、项目、概念。	`viking://user/memories/entities/`
`events`	User	用户经历的关键事件、决策或里程碑。	`viking://user/memories/events/`
`cases`	Agent	Agent 学习到的具体“问题-解决方案”案例。	`viking://agent/memories/cases/`
`patterns`	Agent	Agent 总结的可复用流程或方法论。	`viking://agent/memories/patterns/`
`tools`	Agent	Agent 对某个工具的使用经验与最佳实践。	`viking://agent/memories/tools/`
`skills`	Agent	Agent 对某个技能的执行经验与工作流策略。	`viking://agent/memories/skills/`

特点：由 Agent 自动从会话中提取和更新，具有高度动态性和个性化。
界面操作：通过筛选 User 或 Agent 类型，可以在层级视图中找到对应的 memories 目录，并查看不同类别的记忆文件。

3. Skill (技能)

技能是 Agent 可以调用的、用于完成特定任务的能力封装，例如一个用于“查询天气”的 API 调用或一个用于“代码评审”的脚本。

特点：定义相对静态，但其使用经验会被记录在 Memory 中，可被 Agent 主动决策和调用。
界面操作：在类型筛选区选择 Agent，可以在层级视图中找到 skills 目录，查看已注册的所有技能。

上下文层级 (L0/L1/L2)

为了在信息完整性与调用成本之间取得最佳平衡，OpenViking Service 将所有上下文信息自动处理为三个层级：L0 (摘要)、L1 (概览) 和 L2 (详情)。这使得 Agent 可以按需、渐进式地加载信息。

层级	名称	典型 Token 规模	核心用途
L0	摘要 (Abstract)	~100 tokens	用于向量搜索和快速相关性判断。
L1	概览 (Overview)	~1k-2k tokens	用于 Rerank 精排和内容导航，帮助 Agent 理解上下文结构。
L2	详情 (Details)	无限制	包含了完整的原始内容，供 Agent 在确有必要时深入读取。

1. 生成机制

触发时机：当有新的上下文数据被添加，或一次会话结束并归档时，系统会自动触发 L0/L1/L2 的生成流程。
生成方式：采用“自底向上”的聚合策略。系统会先为最底层的叶子节点（如单个文件）生成摘要和概览，然后逐级向上，将子目录的 L0 摘要信息聚合到父目录的 L1 概览中，最终形成一个层次清晰、可导航的知识结构。
多模态支持：L0 和 L1 层始终是文本格式（Markdown），即使原始的 L2 内容是图片、视频等多模态文件，系统也会为其生成精准的文本描述，确保所有上下文都能被统一检索。

2. 最佳实践建议

在实际应用中，Agent 应遵循以下策略来高效利用分层上下文：

场景	推荐读取层级	理由
初步探索与筛选	L0	使用极低的 Token 成本，通过向量检索快速从海量信息中筛选出高度相关的候选项。
决策与规划	L1	读取候选项的 L1 概览，理解其内部结构和核心要点，判断是否需要深入，并规划下一步行动。
执行与内容生成	L2	仅在确认需要完整信息时，才加载 L2 的原始详情，以完成最终任务，如代码生成、报告撰写。

Token 预算示例：假设一次交互的 Token 预算为 4k。你可以分配 1k 用于检索 10 个条目的 L0（10 * 100 tokens），再用 2k 精读其中 2 个最相关条目的 L1（2 * 1k tokens），最后保留 1k 预算，以备在最关键的条目上读取 L2 的部分内容。

通过这种“先看摘要、再读概览、最后查详情”的渐进式信息获取模式，Agent 可以在严格的 Token 预算内，实现信息利用效率的最大化。

最近更新时间：2026.06.02 16:07:51

这个页面对您有帮助吗？

有用

无用

向量数据库VikingDB

1. 文件系统相较于 RAG 的显著优势 #

2. 文件系统的组织规范 #

3. 目录作为一种语义 #

4. 文件系统范式支持自迭代 #

新增资源内容后，目录会如何组织

记忆目录也具备同样的自迭代能力

1. Resource (资源) #

2. Memory (记忆) #

3. Skill (技能) #

1. 生成机制 #

2. 最佳实践建议 #