1 项目概述与核心价值
1.1 OpenViking 简介
01.项目定位
a.专为 AI Agents 设计的上下文数据库
a.功能说明
OpenViking 是一个开源的、专为 AI Agent 设计的上下文数据库（Context Database）。它旨在为 Agent 定义一套极简的上下文交互范式，让开发者彻底告别上下文管理的烦恼。OpenViking 摒弃了传统 RAG 的碎片化向量存储模式，创新性地采用“文件系统范式”，将 Agent 所需的记忆、资源和技能进行统一的结构化组织。
b.代码示例
---
# OpenViking: The Context Database for AI Agents
# GitHub: https://github.com/volcengine/OpenViking
---
02.开发团队
a.字节跳动 Viking 团队
a.功能说明
OpenViking 由字节跳动 Viking 团队开发。该团队在上下文工程领域具有深厚的技术积累与商业化实践，其愿景是提供用户友好的上下文工程产品矩阵。Viking 团队的产品还包括 VikingDB 向量数据库、Viking 知识库和 Viking 记忆库等。
b.代码示例
---
# 团队愿景: 提供用户友好的上下文工程产品矩阵
# 团队产品: VikingDB, Viking Knowledge Base, Viking Memory Base, OpenViking
---
03.开源协议与社区
a.Apache-2.0 许可证
a.功能说明
OpenViking 采用 Apache-2.0 开源许可证，这是一个对商业友好的许可证，允许用户自由地使用、修改和分发软件。社区活跃，拥有超过 2.9k 的 GitHub Stars 和 200+ 的 Forks。
b.代码示例
---
# License: Apache-2.0
# GitHub Stars: >2900
# GitHub Forks: >200
---
1.2 核心价值主张
01.解决 Agent 开发痛点
a.应对上下文管理挑战
a.功能说明
AI Agent 的发展面临着上下文碎片化、需求激增、检索效果差、不可观测和记忆迭代有限等挑战。OpenViking 通过其创新的设计，旨在系统性地解决这些问题，为开发者提供一个坚实的上下文底座。
b.代码示例
---
# 挑战1: 上下文碎片化 (Fragmented Context)
# 挑战2: 上下文需求激增 (Surging Context Demand)
# 挑战3: 检索效果差 (Poor Retrieval Effectiveness)
# 挑战4: 上下文不可观测 (Unobservable Context)
# 挑战5: 记忆迭代有限 (Limited Memory Iteration)
---
02.创新的文件系统范式
a.一切皆文件
a.功能说明
OpenViking 的核心创新在于其“文件系统范式”（Filesystem Management Paradigm）。它将记忆（Memory）、资源（Resource）和技能（Skill）统一抽象为文件，并通过虚拟文件系统进行管理。这种范式使得上下文的管理变得直观、可追溯，就像操作本地文件一样简单。
b.代码示例
---
# 核心理念: Memory, Resource, Skill. Everything is a File.
# 虚拟协议: viking://
---
03.统一的上下文管理
a.打破信息孤岛
a.功能说明
通过文件系统范式，OpenViking 打破了传统架构中记忆、资源和技能分散存储的信息孤岛。所有上下文都被整合到一个统一的、层次化的结构中，使得 Agent 能够拥有全局视角，并进行更高效的上下文操作。
b.代码示例
---
# 传统模式: 记忆在代码中，资源在向量库，技能分散各处
# OpenViking: 统一存储，统一管理，统一访问
---
1.3 技术背景与发展历程
01.AI Agent 的发展趋势
a.从简单任务执行到复杂目标完成
a.功能说明
随着大模型能力的飞速提升，AI Agent 正在从简单的任务执行者，演变为能够感知环境、自主规划、并调用工具完成复杂目标的智能实体。这一趋势对上下文管理提出了更高的要求，需要 Agent 能够处理长周期任务、海量多模态数据和复杂的协同需求。
b.代码示例
---
# Agent 演进: 简单任务执行 -> 复杂目标完成
# 上下文需求: 长周期、多模态、复杂协同
---
02.上下文管理的挑战
a.从 RAG 到上下文工程
a.功能说明
传统的检索增强生成（RAG）在处理复杂上下文时显得力不从心。业界开始探索更先进的上下文工程（Context Engineering）方法。Manus 提出的“文件系统是上下文的终极形态”、Claude Code 的成功以及 Anthropic 的 Skills 系统都验证了文件系统范式在特定场景下的潜力。
b.代码示例
---
# 业界探索: Context Engineering
# 实践启发: Manus, Claude Code, Anthropic Skills
---
03.Viking 团队的产品历程
a.深厚的技术积累
a.功能说明
Viking 团队在数据库和上下文工程领域拥有多年的积累。从 2019 年支撑字节内部业务的 VikingDB 向量数据库，到 2023 年在火山引擎公有云上商业化，再到 2025 年开源 MineContext 和 2026 年开源 OpenViking，团队在不断探索和引领上下文管理技术的发展。
b.代码示例
---
# 2019: VikingDB (内部使用)
# 2023: VikingDB (公有云商业化)
# 2025: MineContext (开源)
# 2026: OpenViking (开源)
---
1.4 应用场景与目标用户
01.适用场景
a.构建强大的 AI Agent
a.功能说明
OpenViking 适用于各种需要强大上下文管理能力的 AI Agent 开发场景，包括但不限于：
- **智能问答机器人**: 构建能够理解复杂对话历史和外部知识的问答系统。
- **自动化工作流**: 开发能够执行长周期、多步骤任务的自动化 Agent。
- **代码生成与修复**: 为编程助手提供仓库级的代码理解和上下文管理能力。
- **个人知识助手**: 构建能够管理和检索个人知识库的智能助手。
b.代码示例
---
# 场景1: 智能问答机器人
# 场景2: 自动化工作流
# 场景3: 代码生成与修复
# 场景4: 个人知识助手
---
02.目标开发者群体
a.面向广泛的 AI 开发者
a.功能说明
OpenViking 的目标用户是所有致力于构建高级 AI 应用的开发者，包括：
- **AI Agent 开发者**: 专注于构建下一代智能体的开发者。
- **RAG 应用开发者**: 希望突破传统 RAG 限制，构建更强大检索应用的开发者。
- **上下文工程师**: 负责设计和优化 AI 应用上下文管理策略的工程师。
- **企业技术决策者**: 寻求为企业引入高效、可扩展 AI 解决方案的决策者。
b.代码示例
---
# 用户1: AI Agent 开发者
# 用户2: RAG 应用开发者
# 用户3: 上下文工程师
# 用户4: 企业技术决策者
---
03.行业应用案例
a.潜在的行业应用
a.功能说明
凭借其强大的上下文管理能力，OpenViking 在多个行业都具有巨大的应用潜力，例如：
- **软件开发**: 提升代码生成、Bug 修复和文档生成的效率与质量。
- **金融服务**: 构建能够理解市场动态和客户需求的智能投顾。
- **客户服务**: 打造能够处理复杂客户问题和长对话历史的智能客服。
- **教育科研**: 辅助研究人员进行文献检索、数据分析和知识管理。
b.代码示例
---
# 行业1: 软件开发
# 行业2: 金融服务
# 行业3: 客户服务
# 行业4: 教育科研
---
2 核心理念与设计哲学
2.1 文件系统管理范式
01.虚拟文件系统结构
a.层次化组织
a.功能说明
OpenViking 的核心是其虚拟文件系统结构。所有上下文，无论是记忆、资源还是技能，都被组织在一个层次化的目录树中。这种结构模仿了我们熟悉的本地文件系统，使得上下文的管理变得直观且易于理解。根目录为 `viking://`，其下可以创建任意层级的子目录来组织不同类型的上下文。
b.代码示例
---
# 根目录
viking://
# 子目录示例
viking:///memory/user/
viking:///resources/project_docs/
viking:///skills/code_analysis/
---
02.viking:// 协议
a.统一资源标识符
a.功能说明
`viking://` 协议是 OpenViking 中用于定位所有上下文资源的统一资源标识符（URI）。每个文件或目录在虚拟文件系统中都有一个唯一的 URI。这种设计确保了 Agent 可以精确、无歧义地引用和操作任何一个上下文条目，是实现确定性上下文管理的基础。
b.代码示例
---
# 引用一个资源文件
uri = "viking:///resources/project_docs/architecture.md"
# 引用一个记忆条目
uri = "viking:///memory/agent/2026-02-19/session-001.json"
---
03.统一的 URI 管理
a.精确操作上下文
a.功能说明
通过统一的 URI 管理，Agent 可以像开发者使用文件路径一样，对上下文进行精确的操作。无论是读取一个文档、列出一个目录的内容，还是查找特定的技能，都可以通过其唯一的 URI 来完成。这使得上下文的管理从模糊的语义匹配，演变为直观、可追溯的“文件操作”。
b.代码示例
---
# 使用 URI 读取文件内容
content = client.read("viking:///resources/project_docs/architecture.md")
# 使用 URI 列出目录
file_list = client.ls("viking:///skills/code_analysis/")
---
2.2 分层上下文加载
01.L0 层：摘要 (Abstract)
a.一句话概括
a.功能说明
L0 层是上下文的最高层摘要，通常是一句话的概括。它的主要作用是让 Agent 能够快速判断一个资源或记忆条目是否与当前任务相关，而无需加载任何详细内容。这在处理海量上下文时，可以极大地减少不必要的 Token 消耗和模型推理时间。
b.代码示例
---
# 获取资源的 L0 摘要
abstract = client.abstract("viking:///resources/project_docs/architecture.md")
# -> "该文档描述了项目的微服务架构设计。"
---
02.L1 层：概述 (Overview)
a.包含核心信息和使用场景
a.功能说明
L1 层提供了比 L0 层更详细的概述信息，通常包含资源的核心内容、关键信息和典型的使用场景。Agent 在进行任务规划和决策时，主要依赖 L1 层的信息来评估不同上下文的价值和相关性，从而做出更合理的规划。
b.代码示例
---
# 获取资源的 L1 概述
overview = client.overview("viking:///resources/project_docs/architecture.md")
# -> "本文档详细介绍了系统的微服务划分、各服务职责、API 接口以及服务间的通信协议。适用于需要了解系统整体架构的开发者。"
---
03.L2 层：详情 (Detail)
a.完整的原始数据
a.功能说明
L2 层是上下文的完整原始数据。只有当 Agent 在 L0 和 L1 层确认某个上下文与当前任务高度相关，并且需要深入了解其细节时，才会加载 L2 层的内容。这种按需加载的机制确保了在绝大多数情况下，只有最必要的信息被送入模型的上下文窗口。
b.代码示例
---
# 读取资源的 L2 完整内容
detail_content = client.read("viking:///resources/project_docs/architecture.md")
# -> "# 微服务架构设计\n\n## 1. 概述\n\n本文档... (完整内容)"
---
04.按需加载机制
a.显著节省成本
a.功能说明
分层上下文加载机制是 OpenViking 节省成本的关键。通过 L0/L1/L2 的三层结构，系统实现了上下文的按需加载。Agent 首先通过轻量的 L0/L1 层进行筛选和决策，避免了将海量无关信息一次性塞入提示词，从而显著降低了 Token 消耗和模型推理成本，同时减少了噪声对模型判断的干扰。
b.代码示例
---
# Agent 的决策流程
# 1. 浏览 L0/L1 摘要和概述
# 2. 判断相关性，决定是否需要读取 L2 详情
# 3. 仅在必要时加载 L2 内容
---
2.3 目录递归检索
01.意图分析与检索条件生成
a.超越单一向量检索
a.功能说明
单一的向量检索难以应对复杂的查询意图。OpenViking 设计了一套创新的目录递归检索策略。它首先通过意图分析，将用户的复杂查询分解为多个独立的检索条件，这可能包括关键词、语义相似度、文件类型、时间范围等多个维度。
b.代码示例
---
# 用户查询: "查找最近一周关于架构设计的 Markdown 文档"
# 意图分析后生成的检索条件:
# 1. 语义: "架构设计"
# 2. 文件类型: "*.md"
# 3. 时间范围: "last 7 days"
---
02.高分目录定位
a.先定位目录，再探索内容
a.功能说明
生成检索条件后，OpenViking 利用向量检索快速定位到与查询意图最相关的初始切片所在的高分目录。这种“先锁定高分目录、再精细探索内容”的策略，避免了在整个知识库中进行无差别的扁平化搜索，大大提高了检索效率和准确性。
b.代码示例
---
# 1. 向量检索找到包含"架构设计"的切片
# 2. 定位到该切片所在的目录: viking:///resources/project_docs/
# 3. 将该目录标记为高分目录
---
03.二次检索与递归策略
a.逐层深入，精准获取
a.功能说明
在高分目录中，OpenViking 会进行二次检索，并将更相关的结果更新至候选集合。如果该目录下仍然存在子目录，系统会逐层递归，在每个子目录中重复二次检索的步骤。这种递归策略使得检索过程能够深入到最相关的目录层级，从而找到最精准的上下文信息。
b.代码示例
---
# 1. 在 viking:///resources/project_docs/ 中进行二次检索
# 2. 发现子目录 viking:///resources/project_docs/microservices/
# 3. 递归进入该子目录，继续进行检索
---
04.全局语境理解
a.超越片段，理解整体
a.功能说明
目录递归检索策略不仅能找到语义最匹配的片段，更能理解信息所在的完整语境。通过返回与高分结果相关的整个目录结构和上下文信息，Agent 能够更好地理解信息的全局背景，从而做出更准确的判断和决策。
b.代码示例
---
# 传统 RAG 返回: "...微服务通过 API Gateway 对外提供服务..."
# OpenViking 返回:
# - 路径: viking:///resources/project_docs/microservices/gateway.md
# - 内容: "...微服务通过 API Gateway 对外提供服务..."
# - 相关上下文: 同目录下的其他文档 (service-discovery.md, auth.md)
---
2.4 可观测性与自迭代
01.检索轨迹可视化
a.打破黑箱，清晰追溯
a.功能说明
传统 RAG 的检索过程如同一个黑箱，出错时难以归因和调试。OpenViking 打破了这一模式。由于其层次化的文件系统结构和目录递归检索策略，每次检索的目录浏览、文件定位轨迹都被完整地记录下来。这使得开发者可以清晰地观测到问题的根源，并指导检索逻辑的优化。
b.代码示例
---
# 检索轨迹示例:
# 1. Query: "用户认证流程"
# 2. Initial Search -> viking:///resources/project_docs/auth.md (score: 0.92)
# 3. Enter Directory -> viking:///resources/project_docs/
# 4. Recursive Search -> viking:///resources/project_docs/microservices/auth.md (score: 0.95)
# 5. Final Result: viking:///resources/project_docs/microservices/auth.md
---
02.会话自动管理
a.自动压缩与记录
a.功能说明
OpenViking 能够自动管理会话过程中的上下文。它会自动压缩对话中的内容、记录 Agent 对资源的引用和对工具的调用，并将这些信息结构化地存储在会话历史中。这为后续的记忆提取和自迭代提供了原始数据。
b.代码示例
---
# 会话记录示例 (session.json)
# {
# "user_query": "...",
# "agent_response": "...",
# "resource_references": ["viking:///..."],
# "tool_calls": [{"tool_name": "...", "params": {...}}]
# }
---
03.记忆自迭代闭环
a.从经验中学习
a.功能说明
OpenViking 内置了记忆自迭代的闭环机制。在每次会话结束时，通过调用 `session.commit()` 方法，可以主动触发一个异步分析过程。系统会分析任务执行的结果和用户反馈，从中提取有价值的经验，并自动更新到 Agent 的记忆库中。
b.代码示例
---
# 触发记忆自迭代
session.commit()
# 异步过程:
# 1. 分析会话历史
# 2. 提取成功经验或失败教训
# 3. 更新到 viking:///memory/agent/experience/
---
04.session.commit() 机制
a.主动触发的进化
a.功能说明
`session.commit()` 是实现 Agent 自我进化的关键。它不仅会更新与用户偏好相关的记忆，使 Agent 的回应更贴合用户需求，更重要的是，它能从任务执行经验中提取操作技巧、工具使用方法等核心内容，助力 Agent 在后续任务中做出更高效的决策。这使得 Agent 能够在与世界的交互中“越用越聪明”。
b.代码示例
---
# 示例: 从一次成功的代码修复中学习
# session.commit() 后，Agent 记忆库中可能新增:
# - 记忆条目: "当遇到 'ModuleNotFoundError' 时，检查 'sys.path' 是一种有效的调试方法。"
# - 存储路径: viking:///memory/agent/skills/python_debugging.txt
---
3 快速开始指南
3.1 环境准备
01.Python 版本要求
a.需要 Python 3.10 或更高版本
a.功能说明
OpenViking 需要 Python 3.10 或更高版本的运行环境。这是因为项目利用了 Python 3.10 及之后版本中引入的一些新特性和性能优化。在开始安装前，请确保您的 Python 版本符合要求。
b.代码示例
---
# 检查 Python 版本
python --version
# Python 3.10.12
---
02.操作系统支持
a.跨平台支持
a.功能说明
OpenViking 提供了良好的跨平台支持，可以在以下主流操作系统上运行：
- **Linux**: 推荐用于生产环境部署。
- **macOS**: 适用于开发和测试环境。
- **Windows**: 支持开发和测试，部分功能可能存在差异。
b.代码示例
---
# 支持的操作系统
# - Linux (e.g., Ubuntu, CentOS)
# - macOS (Apple Silicon & Intel)
# - Windows (WSL2 recommended)
---
03.网络连接要求
a.需要稳定的网络连接
a.功能说明
在安装和运行 OpenViking 的过程中，需要稳定的网络连接。这主要用于：
- **下载依赖**: 从 PyPI 下载 OpenViking 包及其依赖项。
- **访问模型服务**: 调用 VLM 和 Embedding 模型的 API 服务。
- **添加网络资源**: 使用 URL 作为 `add_resource` 的输入时，需要网络访问。
b.代码示例
---
# 测试网络连接
ping pypi.org
ping api.openai.com
---
3.2 安装方式
01.Python 包安装
a.使用 pip 安装
a.功能说明
最简单和推荐的安装方式是使用 pip 从 Python Package Index (PyPI) 安装。这将自动处理所有必要的 Python 依赖。
b.代码示例
---
# 安装 OpenViking
pip install openviking
# 升级到最新版本
pip install --upgrade openviking
---
02.Rust CLI 安装 (可选)
a.提供更快的命令行体验
a.功能说明
除了 Python CLI，OpenViking 还提供了一个使用 Rust 编写的命令行工具 `ov_cli`，它提供了更快的执行速度和更低资源占用的命令行体验。这对于需要频繁进行命令行操作的场景非常有用。
b.代码示例
---
# 使用安装脚本安装
curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/crates/ov_cli/install.sh | bash
---
03.从源码构建
a.获取最新功能或进行二次开发
a.功能说明
如果您希望体验最新的未发布功能，或者希望对 OpenViking 进行二次开发，可以从 GitHub 克隆源码并进行构建。对于 Rust CLI，您可以使用 cargo 进行安装。
b.代码示例
---
# 克隆仓库
git clone https://github.com/volcengine/OpenViking.git
cd OpenViking
# 安装 Python 包
pip install .
# 构建和安装 Rust CLI
cargo install --path crates/ov_cli
---
3.3 模型服务配置
01.VLM 模型提供商
a.支持多种主流模型
a.功能说明
OpenViking 需要 VLM (Visual Language Model) 模型来进行图像和内容的理解。它通过灵活的 Provider Registry 机制，支持多种主流的 VLM 模型提供商，如 Volcengine (豆包)、OpenAI (GPT)、Anthropic (Claude) 等。
b.代码示例
---
# ov.conf 中 VLM 的配置示例
"vlm": {
"provider": "openai",
"model": "gpt-4-vision-preview",
"api_key": "your-openai-api-key"
}
---
02.Embedding 模型支持
a.用于向量化和语义检索
a.功能说明
Embedding 模型用于将文本和图像内容转换为向量，以便进行高效的语义检索。目前，OpenViking 主要支持 Volcengine (豆包) 和 OpenAI 的 Embedding 模型。
b.代码示例
---
# ov.conf 中 Embedding 的配置示例
"embedding": {
"dense": {
"provider": "volcengine",
"model": "doubao-embedding-vision-250615",
"api_key": "your-volcengine-api-key",
"dimension": 1024
}
}
---
03.API Key 获取
a.从模型提供商平台获取
a.功能说明
要使用这些模型服务，您需要从相应的模型提供商官方平台获取 API Key。请参考各平台的文档来创建和管理您的 API Key，并确保其安全。
b.代码示例
---
# 平台示例:
# - OpenAI: https://platform.openai.com/
# - Volcengine: https://www.volcengine.com/product/ark
# - Anthropic: https://console.anthropic.com/
---
3.4 第一个示例程序
01.配置文件创建
a.创建 ov.conf
a.功能说明
首先，在您的用户主目录下创建一个名为 `.openviking` 的文件夹，并在其中创建一个 `ov.conf` 文件。这个文件将用于存放您的模型服务配置。
b.代码示例
---
# 创建目录和文件
mkdir -p ~/.openviking
touch ~/.openviking/ov.conf
# 写入配置 (以 OpenAI 为例)
echo '{
"embedding": {
"dense": {
"provider": "openai",
"model": "text-embedding-3-large",
"api_key": "sk-...",
"dimension": 3072
}
},
"vlm": {
"provider": "openai",
"model": "gpt-4-vision-preview",
"api_key": "sk-..."
}
}' > ~/.openviking/ov.conf
---
02.环境变量设置
a.指定配置文件路径
a.功能说明
设置 `OPENVIKING_CONFIG_FILE` 环境变量，使其指向您刚刚创建的 `ov.conf` 文件。这样 OpenViking 客户端就能找到并加载您的配置。
b.代码示例
---
# 在 Linux/macOS 上设置环境变量
export OPENVIKING_CONFIG_FILE=~/.openviking/ov.conf
# 在 Windows PowerShell 中设置
# $env:OPENVIKING_CONFIG_FILE = "$HOME/.openviking/ov.conf"
---
03.示例代码运行
a.体验核心功能
a.功能说明
现在，您可以运行一个简单的 Python 脚本来体验 OpenViking 的核心功能，包括初始化客户端、添加资源、浏览目录、读取内容、等待处理、获取摘要和进行语义搜索。
b.代码示例
---
# example.py
import openviking as ov
client = ov.SyncOpenViking(path="./data")
client.initialize()
# 添加 README 文件作为资源
add_result = client.add_resource(path="https://raw.githubusercontent.com/volcengine/OpenViking/main/README.md")
root_uri = add_result['root_uri']
# 浏览目录结构
print(client.ls(root_uri))
# 等待语义处理
client.wait_processed()
# 搜索
results = client.find("what is openviking", target_uri=root_uri)
for r in results.resources:
print(f"{r.uri} (score: {r.score:.4f})")
client.close()
---
04.结果验证
a.确认程序正常运行
a.功能说明
运行 `python example.py`。如果您的配置正确，程序将成功添加资源，打印出目录结构，并返回与查询相关的搜索结果。这表明您已经成功地运行了您的第一个 OpenViking 程序。
b.代码示例
---
# 预期输出:
# Directory structure:
# ... (目录列表)
#
# Wait for semantic processing...
# Search results:
# viking:///... (score: 0.9...)
---
4 模型提供商与配置
4.1 支持的 VLM 提供商
01.Volcengine (Doubao)
a.火山引擎豆包大模型
a.功能说明
OpenViking 对火山引擎的豆包大模型提供了原生支持。作为推荐的提供商之一，豆包模型具有成本低、性能好的特点，并且为新用户提供免费额度。在配置时，`provider` 应设置为 `volcengine`。
b.代码示例
---
"vlm": {
"provider": "volcengine",
"model": "doubao-seed-1-8-251228",
"api_key": "your-volcengine-api-key",
"api_base": "https://ark.cn-beijing.volces.com/api/v3"
}
---
02.OpenAI (GPT)
a.GPT 系列模型
a.功能说明
支持 OpenAI 的 GPT 系列模型，特别是具备视觉能力的多模态模型，如 `gpt-4-vision-preview`。配置时，`provider` 应设置为 `openai`。
b.代码示例
---
"vlm": {
"provider": "openai",
"model": "gpt-4-vision-preview",
"api_key": "your-openai-api-key",
"api_base": "https://api.openai.com/v1"
}
---
03.Anthropic (Claude)
a.Claude 系列模型
a.功能说明
支持 Anthropic 的 Claude 系列模型。配置时，`provider` 应设置为 `anthropic`。
b.代码示例
---
"vlm": {
"provider": "anthropic",
"model": "claude-3-opus-20240229",
"api_key": "your-anthropic-api-key"
}
---
04.其他提供商
a.广泛的生态支持
a.功能说明
OpenViking 还支持一系列其他主流模型提供商，包括 DeepSeek, Gemini, Moonshot (Kimi), Zhipu (GLM), DashScope (Qwen), MiniMax, OpenRouter 等。配置方式类似，只需将 `provider` 设置为对应的名称即可。
b.代码示例
---
# DeepSeek
"provider": "deepseek"
# Moonshot (Kimi)
"provider": "moonshot"
# Zhipu (GLM)
"provider": "zhipu"
---
05.vLLM (本地模型)
a.支持本地部署的模型
a.功能说明
对于希望使用本地私有化部署模型的高级用户，OpenViking 支持通过 vLLM 进行集成。您需要先启动一个 vLLM 服务，然后在配置中将 `provider` 设置为 `vllm`，并指定服务的地址。
b.代码示例
---
# 启动 vLLM 服务
# vllm serve meta-llama/Llama-3.1-8B-Instruct --port 8000
# ov.conf 配置
"vlm": {
"provider": "vllm",
"model": "meta-llama/Llama-3.1-8B-Instruct",
"api_key": "dummy",
"api_base": "http://localhost:8000/v1"
}
---
4.2 Embedding 模型配置
01.Volcengine Embedding
a.豆包向量化模型
a.功能说明
推荐使用火山引擎的豆包向量化模型，它在成本和性能上都具有优势。配置时，`provider` 设置为 `volcengine`。
b.代码示例
---
"embedding": {
"dense": {
"provider": "volcengine",
"model": "doubao-embedding-vision-250615",
"api_key": "your-volcengine-api-key",
"api_base": "https://ark.cn-beijing.volces.com/api/v3",
"dimension": 1024
}
}
---
02.OpenAI Embedding
a.OpenAI 向量化模型
a.功能说明
支持 OpenAI 的 Embedding 模型，如 `text-embedding-3-large`。配置时，`provider` 设置为 `openai`，并需要指定正确的向量维度。
b.代码示例
---
"embedding": {
"dense": {
"provider": "openai",
"model": "text-embedding-3-large",
"api_key": "your-openai-api-key",
"api_base": "https://api.openai.com/v1",
"dimension": 3072
}
}
---
03.向量维度设置
a.确保与模型匹配
a.功能说明
在配置 Embedding 模型时，必须正确设置 `dimension` 参数，使其与所选模型的输出向量维度相匹配。错误的维度设置会导致向量存储和检索失败。
b.代码示例
---
# doubao-embedding-vision-250615 -> dimension: 1024
# text-embedding-3-large -> dimension: 3072
# text-embedding-3-small -> dimension: 1536
---
4.3 Provider Registry 机制
01.自动提供商检测
a.简化模型切换
a.功能说明
OpenViking 内部实现了一个 Provider Registry 机制，用于统一管理对不同模型服务的访问。该机制能够根据模型名称中的关键词，自动检测并选择对应的提供商。这使得用户可以在不同的模型服务之间无缝切换，而无需修改代码，只需更新配置文件即可。
b.代码示例
---
# 模型名称中包含 "doubao" -> 自动选择 "volcengine" provider
# 模型名称中包含 "gpt" -> 自动选择 "openai" provider
# 模型名称中包含 "claude" -> 自动选择 "anthropic" provider
---
02.模型名称关键词
a.基于约定进行匹配
a.功能说明
Provider Registry 的自动检测功能是基于约定的模型名称关键词。例如，只要模型名称中包含 `gpt`，系统就会默认使用 `openai` 提供商的客户端进行 API 调用。这种设计大大简化了多模型环境下的配置复杂性。
b.代码示例
---
# ov.conf 中可以省略 provider 字段
"vlm": {
"model": "gpt-4-turbo", # 包含 gpt，自动识别为 openai
"api_key": "..."
}
---
03.无缝切换
a.只需修改配置
a.功能说明
得益于 Provider Registry 机制，当您想从一个模型切换到另一个模型时（例如从 GPT-4 切换到 Claude 3），您唯一需要做的就是修改 `ov.conf` 配置文件中的 `model` 和 `api_key` 等相关信息。应用程序代码无需任何改动，即可实现模型的无缝切换。
b.代码示例
---
# 从 OpenAI 切换到 Anthropic
# 只需将
# "model": "gpt-4-turbo"
# 修改为
# "model": "claude-3-opus-20240229"
# 并更新 api_key
---
4.4 特定提供商配置说明
01.Volcengine 端点配置
a.支持模型名称和端点 ID
a.功能说明
在使用火山引擎（Volcengine）服务时，`model` 字段既可以填写模型名称（如 `doubao-seed-1-6-240615`），也可以填写在火山方舟（ARK）控制台获取的端点 ID（如 `ep-20241220174930-xxxxx`）。推荐使用模型名称，更为简洁。
b.代码示例
---
# 使用模型名称 (推荐)
"model": "doubao-seed-1-6-240615"
# 使用端点 ID
"model": "ep-20241220174930-xxxxx"
---
02.Zhipu Coding Plan
a.使用专用的 API 端点
a.功能说明
如果您正在使用智谱 AI (Zhipu) 的 Coding Plan，需要将 `api_base` 配置为专用的编码 API 端点地址，以确保能够访问到正确的模型服务。
b.代码示例
---
"vlm": {
"provider": "zhipu",
"model": "glm-4-plus",
"api_key": "...",
"api_base": "https://open.bigmodel.cn/api/coding/paas/v4"
}
---
03.MiniMax 中国大陆平台
a.指定 API Base
a.功能说明
对于 MiniMax 的中国大陆平台 (minimaxi.com)，需要明确指定其 API 端点地址 `https://api.minimaxi.com/v1`。
b.代码示例
---
"vlm": {
"provider": "minimax",
"model": "abab6.5s-chat",
"api_key": "...",
"api_base": "https://api.minimaxi.com/v1"
}
---
04.vLLM 本地部署
a.配置本地服务地址
a.功能说明
当使用 vLLM 部署本地模型时，`api_base` 需要配置为 vLLM 服务监听的地址和端口，通常是 `http://localhost:8000/v1`。`api_key` 在这种情况下可以填写任意虚拟值。
b.代码示例
---
"vlm": {
"provider": "vllm",
"model": "meta-llama/Llama-3.1-8B-Instruct",
"api_key": "dummy",
"api_base": "http://localhost:8000/v1"
}
---
4.5 配置文件详解
01.ov.conf 结构
a.JSON 格式
a.功能说明
`ov.conf` 文件是一个 JSON 格式的配置文件，主要包含 `embedding` 和 `vlm` 两个顶层对象，分别用于配置向量化模型和视觉语言模型。
b.代码示例
---
{
"embedding": { ... },
"vlm": { ... }
}
---
02.配置项说明
a.各字段含义
a.功能说明
- **provider**: 模型提供商，如 `openai`, `volcengine`。
- **model**: 具体的模型名称或 ID。
- **api_key**: 从提供商获取的 API 密钥。
- **api_base**: API 服务的端点地址。
- **dimension**: (仅限 embedding) 向量维度。
b.代码示例
---
# 示例配置项
# "provider": "openai"
# "model": "gpt-4-turbo"
# "api_key": "sk-..."
# "api_base": "https://api.openai.com/v1"
# "dimension": 3072
---
03.环境变量设置
a.OPENVIKING_CONFIG_FILE
a.功能说明
OpenViking 通过读取 `OPENVIKING_CONFIG_FILE` 环境变量来定位配置文件的路径。推荐将此变量设置在您的 shell 配置文件中（如 `.bashrc` 或 `.zshrc`），以便长期生效。
b.代码示例
---
# 将配置加入 .bashrc
echo 'export OPENVIKING_CONFIG_FILE=~/.openviking/ov.conf' >> ~/.bashrc
source ~/.bashrc
---
5 核心功能与 API
5.1 客户端初始化
01.SyncOpenViking 客户端
a.同步客户端
a.功能说明
`SyncOpenViking` 是 OpenViking 的同步客户端，适用于常规的脚本和应用。它的所有 API 调用都是阻塞式的，即程序会等待 API 调用完成后再继续执行。
b.代码示例
---
import openviking as ov
# 初始化同步客户端，指定数据存储路径
client = ov.SyncOpenViking(path="./my_agent_data")
# 初始化客户端（会加载配置、连接数据库等）
client.initialize()
---
02.AsyncOpenViking 客户端
a.异步客户端
a.功能说明
`AsyncOpenViking` 是异步客户端，适用于需要高并发处理的场景，例如在 FastAPI 或 aiohttp 等异步 Web 框架中使用。它的所有 API 方法都是 `async` 的，需要使用 `await` 来调用。
b.代码示例
---
import asyncio
import openviking as ov
async def main():
client = ov.AsyncOpenViking(path="./my_agent_data")
await client.initialize()
# ... 异步操作
await client.close()
asyncio.run(main())
---
03.数据目录设置
a.指定持久化路径
a.功能说明
在初始化客户端时，必须通过 `path` 参数指定一个本地目录。这个目录将用于持久化存储 OpenViking 的所有数据，包括向量索引、元数据、文件内容等。请确保该目录具有读写权限。
b.代码示例
---
# 使用相对路径
client = ov.SyncOpenViking(path="./data")
# 使用绝对路径
client = ov.SyncOpenViking(path="/var/lib/openviking/agent_data")
---
5.2 资源管理
01.add_resource()
a.添加资源
a.功能说明
`add_resource()` 是将外部信息源添加到 OpenViking 中的核心方法。它支持多种类型的资源输入。
b.代码示例
---
# 1. 添加网络 URL
client.add_resource(path="https://en.wikipedia.org/wiki/AI_agent")
# 2. 添加本地文件
client.add_resource(path="./docs/my_project.md")
# 3. 添加本地目录 (会递归处理所有文件)
client.add_resource(path="./src/")
---
02.ls()
a.浏览目录结构
a.功能说明
`ls()` 方法用于列出指定 URI 路径下的文件和目录，功能类似于 Linux 的 `ls` 命令。可以用于探索虚拟文件系统的结构。
b.代码示例
---
# 添加资源后会返回根 URI
add_result = client.add_resource(path="./src/")
root_uri = add_result["root_uri"]
# 列出根目录内容
directory_listing = client.ls(root_uri)
print(directory_listing)
---
03.glob()
a.模式匹配查找
a.功能说明
`glob()` 方法支持使用通配符模式来查找文件，类似于 Python 的 `glob` 库。这对于快速找到特定类型或名称的文件非常有用。
b.代码示例
---
# 查找所有 Markdown 文件
glob_result = client.glob(pattern="**/*.md", uri=root_uri)
for match in glob_result["matches"]:
print(match)
---
04.read()
a.读取文件内容
a.功能说明
`read()` 方法用于读取指定 URI 路径的文件的完整内容（L2 详情）。
b.代码示例
---
# 读取上一步 glob 找到的第一个文件的内容
if glob_result["matches"]:
content = client.read(glob_result["matches"][0])
print(f"Content preview: {content[:200]}...")
---
5.3 语义处理
01.wait_processed()
a.等待处理完成
a.功能说明
当一个资源被添加后，OpenViking 会在后台进行一系列异步的语义处理，包括文件解析、内容分块、向量化、生成 L0/L1 摘要等。`wait_processed()` 方法会阻塞程序，直到所有后台处理任务完成。在进行语义搜索或获取摘要前，通常需要调用此方法。
b.代码示例
---
print("Adding resource...")
client.add_resource(path="./docs/")
print("Waiting for semantic processing to complete...")
client.wait_processed()
print("Processing finished!")
---
02.abstract()
a.获取摘要
a.功能说明
`abstract()` 方法用于获取指定 URI 资源的 L0 摘要（一句话概括）。
b.代码示例
---
# 获取整个资源目录的摘要
summary = client.abstract(root_uri)
print(f"Abstract: {summary}")
---
03.overview()
a.获取概览
a.功能说明
`overview()` 方法用于获取指定 URI 资源的 L1 概述（包含核心信息和使用场景）。
b.代码示例
---
# 获取整个资源目录的概述
overview_text = client.overview(root_uri)
print(f"Overview: {overview_text}")
---
04.自动分层处理
a.后台智能处理
a.功能说明
L0 摘要和 L1 概述的生成是 OpenViking 后台语义处理流程的一部分。系统会自动调用 VLM 模型来对资源内容进行理解和总结，并将结果与资源关联存储，无需用户手动干预。
b.代码示例
---
# 这个过程是自动的，在 wait_processed() 完成后即可使用
# User -> add_resource() -> OpenViking Backend
# OpenViking Backend -> Parse -> Chunk -> Embed -> Summarize (L0/L1)
---
5.4 检索功能
01.find()
a.语义搜索
a.功能说明
`find()` 是 OpenViking 的核心检索方法。它接收一个自然语言查询，并在指定的 `target_uri` 范围内进行语义搜索，返回最相关的资源片段列表。
b.代码示例
---
# 在整个资源中搜索 "what is openviking"
results = client.find("what is openviking", target_uri=root_uri)
print("Search results:")
for r in results.resources:
print(f" {r.uri} (score: {r.score:.4f})")
---
02.目录递归检索
a.智能的搜索策略
a.功能说明
`find()` 方法的背后是强大的目录递归检索策略。它不仅仅是简单的向量相似度匹配，而是会结合目录结构进行智能的、多层次的搜索，以提供更精准、更具上下文的检索结果。
b.代码示例
---
# 搜索会自动利用目录结构
# 例如，在 /src 目录下搜索 "database connection"
# 会优先返回 /src/db/connection.py 而不是 /src/utils/http.py
---
03.检索结果评分
a.相关性度量
a.功能说明
`find()` 方法返回的每个结果都包含一个 `score` 字段，表示该结果与查询的相关性分数。分数越高，表示相关性越强。这个分数可以用于对结果进行排序或过滤。
b.代码示例
---
results = client.find("what is openviking", target_uri=root_uri)
# 过滤掉分数低于 0.8 的结果
high_confidence_results = [r for r in results.resources if r.score > 0.8]
---
04.检索轨迹追踪
a.可观测的检索过程
a.功能说明
为了增强可观测性，OpenViking 记录了每次 `find()` 操作的内部检索轨迹。虽然这在 API 返回中不直接体现，但可以通过日志或未来的可视化工具进行分析，以理解和调试检索行为。
b.代码示例
---
# (内部机制，非直接 API 调用)
# LOG: Query -> "..." -> Start find()
# LOG: Vector search found 10 candidates.
# LOG: Entering directory /docs/.
# LOG: Reranking results in /docs/.
# LOG: Final results returned.
---
5.5 记忆管理
01.add_memory()
a.添加记忆
a.功能说明
`add_memory()` 方法用于向 Agent 的记忆库中添加新的记忆条目。这些记忆可以是关于用户偏好、任务经验、或者任何 Agent 需要长期记住的信息。
b.代码示例
---
# 添加一条关于用户偏好的记忆
client.add_memory(
path="viking:///memory/user/preferences.txt",
content="用户偏好使用中文进行交流。"
)
---
02.用户记忆与 Agent 记忆
a.区分不同的记忆主体
a.功能说明
OpenViking 的记忆库在文件系统层面通过目录结构来区分不同的记忆主体，通常分为 `/memory/user` 和 `/memory/agent`。这使得 Agent 可以分别管理和查询关于用户的信息和关于自身的经验。
b.代码示例
---
# 用户记忆路径
USER_MEMORY_PATH = "viking:///memory/user/"
# Agent 经验路径
AGENT_MEMORY_PATH = "viking:///memory/agent/experience/"
---
03.长期记忆提取
a.自动化的知识沉淀
a.功能说明
通过 `session.commit()` 机制，OpenViking 能够从对话历史和任务执行结果中自动提取长期记忆。这个过程是异步的，会将有价值的信息沉淀到 Agent 的记忆库中，实现知识的持续积累。
b.代码示例
---
# 一次成功的对话后，系统可能自动提取并添加以下记忆
# client.add_memory(
# path="viking:///memory/agent/skills/api_usage.txt",
# content="调用 'get_weather' API 时，'city' 参数是必需的。"
# )
---
04.记忆自迭代
a.实现 Agent 的成长
a.功能说明
记忆管理是实现 Agent 自我迭代和成长的核心。通过不断地添加新记忆、更新旧记忆，并能在未来的任务中检索和利用这些记忆，Agent 的表现会随着时间的推移而变得越来越好，真正实现“越用越聪明”。
b.代码示例
---
# 未来的任务中，Agent 可以通过 find() 方法查询自己的记忆库
# query = "如何使用 'get_weather' API？"
# memory_results = client.find(query, target_uri="viking:///memory/agent/")
---
6 文件系统范式详解
6.1 虚拟文件系统结构
01.目录层次设计
a.灵活的树状结构
a.功能说明
OpenViking 的虚拟文件系统采用了灵活的树状目录结构。用户可以根据自己的业务需求，创建任意深度和广度的目录层次，来组织和管理不同类型的上下文。这种设计提供了极高的灵活性，能够适应从简单到复杂的各种应用场景。
b.代码示例
---
# 一个可能的目录结构示例
viking://
├── memory/
│ ├── user/
│ └── agent/
├── resources/
│ ├── project_a/
│ │ ├── docs/
│ │ └── src/
│ └── project_b/
└── skills/
├── python/
└── shell/
---
02.URI 命名规范
a.清晰且唯一的路径
a.功能说明
每个文件和目录都通过其唯一的 URI (Uniform Resource Identifier) 进行标识。URI 遵循标准的路径格式，以 `viking://` 开头，并使用 `/` 作为路径分隔符。推荐使用有意义的、人类可读的名称来命名目录和文件，以便于管理和理解。
b.代码示例
---
# 合法的 URI 示例
viking:///resources/project_a/docs/api.md
viking:///memory/user/preferences.json
# 不推荐的命名方式 (虽然技术上可行)
viking:///res/p1/d/a.md
---
03.viking:// 协议
a.内部寻址协议
a.功能说明
`viking://` 是 OpenViking 内部专用的寻址协议。它标志着一个路径属于 OpenViking 的虚拟文件系统，而不是本地文件系统。所有 OpenViking 的 API 方法，如 `ls`, `read`, `find` 等，都使用 `viking://` URI 来定位操作的目标。
b.代码示例
---
# 使用 viking:// URI 进行操作
client.read("viking:///resources/project_a/docs/api.md")
# 与本地文件路径的区别
# client.add_resource(path="./local/docs/api.md") # 本地路径，用于添加资源
---
6.2 上下文组织方式
01.Memory 目录结构
a.存储长期记忆
a.功能说明
`/memory` 目录是专门用于存储 Agent 长期记忆的地方。通常会进一步划分为 `/memory/user` 和 `/memory/agent` 两个子目录。
- `/memory/user`: 存储关于用户的信息，如偏好、历史交互总结等。
- `/memory/agent`: 存储 Agent 自身的经验和学习成果，如技能使用技巧、任务成功/失败的经验教训等。
b.代码示例
---
# 示例 Memory 目录结构
viking:///memory/
├── user/
│ ├── profile.json
│ └── chat_summary_001.txt
└── agent/
├── experience/
│ └── successful_task_abc.md
└── skills/
└── python_debugging_tips.txt
---
02.Resource 目录结构
a.管理外部信息源
a.功能说明
`/resources` 目录用于管理所有通过 `add_resource()` 添加的外部信息源，如文档、代码、网页等。OpenViking 会在 `/resources` 目录下为每个添加的资源创建一个唯一的子目录，并保留其原始的目录结构和文件名。
b.代码示例
---
# 添加本地目录 ./my_project/src
# client.add_resource(path="./my_project/src")
# 可能生成的 Resource 目录结构
viking:///resources/
└── src_a1b2c3d4/
├── main.py
└── utils/
└── string_helper.py
---
03.Skill 目录结构
a.定义和组织技能
a.功能说明
`/skills` 目录用于定义和组织 Agent 可以使用的技能。每个技能可以是一个文件，其中包含技能的描述、输入输出、以及可执行的代码或调用指令。通过将技能文件化，Agent 可以在运行时动态地发现和使用技能。
b.代码示例
---
# 示例 Skill 目录结构
viking:///skills/
├── web_search/
│ ├── description.md
│ └── implementation.py
└── get_weather/
├── description.md
└── api_call.json
---
6.3 文件操作命令
01.list
a.列出目录内容
a.功能说明
`ls()` API 提供了类似于 Linux `ls` 命令的功能，可以列出指定 `viking://` URI 路径下的所有文件和子目录。这是探索和导航虚拟文件系统的基本操作。
b.代码示例
---
# 列出 /skills 目录下的所有技能
skills_list = client.ls("viking:///skills/")
print(skills_list)
---
02.find
a.查找文件
a.功能说明
`find()` API 是文件系统中最强大的命令之一。它不仅仅是按名称查找，而是进行语义搜索。你可以用自然语言描述你想找的内容，`find()` 会在指定的目录范围内（甚至整个文件系统）为你找到最相关的“文件”。
b.代码示例
---
# 在 /resources 目录中查找关于"数据库连接池"的文档
results = client.find("数据库连接池的配置方法", target_uri="viking:///resources/")
---
03.read
a.读取文件
a.功能说明
`read()` API 用于读取指定 `viking://` URI 路径的文件的完整内容。这是获取上下文详细信息（L2 详情）的标准方法。
b.代码示例
---
# 读取一个技能的描述文件
skill_description = client.read("viking:///skills/web_search/description.md")
---
04.write
a.写入文件
a.功能说明
虽然 `add_memory()` 是写入记忆的推荐方式，但 OpenViking 也提供了更底层的 `write()` 或类似 API（具体名称可能演进）来直接写入或修改文件内容。这为实现更复杂的上下文操作（如动态修改技能实现）提供了可能。
b.代码示例
---
# (示例 API，具体以官方文档为准)
# 更新一个技能的描述
# client.write(
# path="viking:///skills/web_search/description.md",
# content="更新后的技能描述..."
# )
---
6.4 上下文统一管理
01.统一的数据抽象层
a.屏蔽底层复杂性
a.功能说明
文件系统范式本质上是一个统一的数据抽象层。它将不同来源、不同格式的上下文（文本、代码、JSON、记忆片段等）都抽象为“文件”和“目录”。这使得 Agent 可以用一套统一的、简单的接口（`ls`, `read`, `find`）来操作所有类型的上下文，而无需关心其底层的存储和索引细节。
b.代码示例
---
# 无论是资源、记忆还是技能，都使用相同的 API 进行操作
client.read("viking:///resources/doc.md")
client.read("viking:///memory/user/profile.json")
client.read("viking:///skills/search/desc.md")
---
02.跨类型上下文关联
a.建立信息间的联系
a.功能说明
在统一的文件系统下，不同类型的上下文可以很容易地建立关联。例如，一个 Agent 的经验记忆（Memory）可以引用它在执行任务时使用过的特定资源（Resource）和技能（Skill）。这种关联是通过在文件内容中包含其他文件的 `viking://` URI 来实现的，形成了一个上下文的“超链接网络”。
b.代码示例
---
# 一个经验记忆文件的内容示例
# Title: 关于修复数据库连接错误的经验
# Date: 2026-02-19
#
# 在处理任务 [TASK-123] 时，我参考了文档 viking:///resources/db_docs/connection.md，
# 并使用了技能 viking:///skills/db/restart_pool.sh，成功解决了问题。
---
03.上下文版本管理
a.追踪上下文的演变
a.功能说明
虽然当前版本可能未完全实现，但文件系统范式为上下文的版本管理提供了天然的基础。就像 Git 管理代码版本一样，未来 OpenViking 可以对文件系统的变更进行快照和版本控制。这将允许 Agent 追踪上下文的演变历史，甚至在需要时“回滚”到某个特定的上下文状态。
b.代码示例
---
# (未来特性展望)
# 获取某个文件在特定时间的版本
# content = client.read("viking:///.../api.md", version="v1.2")
# 比较两个版本之间的差异
# diff = client.diff("viking:///.../api.md", from="v1.1", to="v1.2")
---
7 检索与查询机制
7.1 检索策略概述
01.向量检索
a.语义相似度匹配
a.功能说明
向量检索是 OpenViking 检索机制的基础。它通过将查询和文档内容都转换为高维向量，然后在向量空间中计算相似度，来找到与查询语义最相关的文档片段。这是实现语义搜索的关键技术。
b.代码示例
---
# 1. Query: "如何配置数据库连接？"
# 2. Embedding(Query) -> Vector_Q
# 3. 在向量数据库中搜索与 Vector_Q 最相似的 Vector_Doc
---
02.目录定位
a.利用结构化信息
a.功能说明
与传统的扁平化 RAG 不同，OpenViking 充分利用了其文件系统的目录结构。在检索时，系统不仅考虑语义相似度，还会考虑信息所在的路径。这使得检索更加精准，能够区分不同上下文中的同名或相似内容。
b.代码示例
---
# 查询: "main.py 的入口函数"
# 如果在 viking:///resources/project_a/src/ 中搜索
# 系统会优先返回该目录下的 main.py，而不是其他项目的同名文件
---
03.递归搜索
a.逐层深入探索
a.功能说明
递归搜索是 OpenViking 的核心创新之一。当定位到一个高分目录后，系统会逐层深入其子目录进行二次检索，从而能够发现隐藏在深层结构中的相关信息。这种策略确保了检索的全面性。
b.代码示例
---
# 搜索 "API key management"
# 1. 找到高分目录 /resources/project_a/
# 2. 在 /resources/project_a/ 中二次检索
# 3. 发现子目录 /resources/project_a/security/ 并递归进入
# 4. 在 /resources/project_a/security/ 中找到最终结果 api_keys.md
---
04.混合检索
a.多种策略的融合
a.功能说明
OpenViking 的检索机制是一种混合检索策略，它深度融合了向量检索、关键词匹配、目录定位和递归搜索等多种方法的优点，以应对复杂的查询意- 意图，并提供最精准、最全面的检索结果。
b.代码示例
---
# 混合检索流程:
# 1. 意图分析 -> 生成多维检索条件
# 2. 向量检索 -> 定位初始高分目录
# 3. 递归搜索 -> 深入探索目录结构
# 4. 关键词匹配/元数据过滤 -> 精细筛选
# 5. 结果重排 -> 返回最终结果
---
7.2 意图分析
01.查询意图解析
a.理解用户的真实需求
a.功能说明
在执行检索前，OpenViking 会首先对用户的自然语言查询进行意图分析，尝试理解用户查询背后的真实需求。这可能涉及到识别查询中的核心实体、问题类型、以及隐含的约束条件。
b.代码示例
---
# 查询: "给我找一下上周张三写的关于性能测试的报告"
# 意图解析:
# - 核心主题: "性能测试报告"
# - 作者: "张三"
# - 时间: "上周"
---
02.多条件生成
a.将自然语言转换为结构化查询
a.功能说明
意图分析的结果是生成一组结构化的检索条件。这些条件可能包括语义向量、关键词、作者、文件类型、修改时间等多个维度。这使得后续的检索过程可以更加精准和高效。
b.代码示例
---
# 根据上述查询生成的多维检索条件:
# {
# "semantic_query": "performance testing report",
# "metadata_filter": {
# "author": "Zhang San",
# "created_at": { "gte": "2026-02-12", "lte": "2026-02-19" },
# "file_type": ["md", "pdf", "docx"]
# }
# }
---
03.检索范围确定
a.缩小搜索空间
a.功能说明
用户的查询通常会包含对检索范围的限定，例如在 `find` API 中指定的 `target_uri`。意图分析也会帮助进一步缩小搜索空间。例如，如果查询明显是关于代码的，系统可能会优先在 `/resources/.../src/` 目录下进行搜索。
b.代码示例
---
# 查询: "修复数据库连接池 bug 的代码在哪里？"
# 意图分析 -> 识别为代码相关查询
# 自动将搜索范围聚焦于 `**/*.py`, `**/*.go` 等代码文件
---
7.3 目录递归检索流程
01.初始切片定位
a.向量检索先行
a.功能说明
目录递归检索的第一步是通过高效的向量检索，在全局范围内快速找到与查询语义最相似的一批初始文档切片（chunks）。这一步的目标是快速定位到可能包含答案的“高潜力区域”。
b.代码示例
---
# 1. Query -> Embedding -> Vector_Q
# 2. ANN Search in Vector DB -> Top K similar chunks
---
02.高分目录识别
a.从切片到目录
a.功能说明
找到初始切片后，系统会分析这些切片所在的目录，并将这些目录识别为“高分目录”。这些目录被认为是最有可能包含最终答案的地方。
b.代码示例
---
# Chunk 1 -> in /docs/db/
# Chunk 2 -> in /docs/api/
# Chunk 3 -> in /docs/db/config/
#
# 高分目录: /docs/db/, /docs/api/, /docs/db/config/
---
03.二次检索执行
a.在目录内精细搜索
a.功能说明
接下来，系统会进入每个高分目录，在目录内部进行二次检索。这次检索会综合考虑语义相似度、文件名、以及目录内的其他元数据，以获得更精准的结果。二次检索的结果会被更新到最终的候选集合中。
b.代码示例
---
# 在 /docs/db/ 目录下进行二次检索
# 发现 db_connection.md 与查询高度相关
# 将 db_connection.md 加入候选集
---
04.递归深度控制
a.平衡效率与全面性
a.功能说明
如果高分目录下还包含子目录，系统会递归地进入子目录重复二次检索的过程。为了防止无限递归并保证检索效率，系统会有一个递归深度的限制。这确保了检索能够在效率和全面性之间取得良好的平衡。
b.代码示例
---
# 1. 进入 /docs/db/
# 2. 发现子目录 /docs/db/config/ (深度 1)
# 3. 递归进入 /docs/db/config/
# 4. 如果还有子目录，但已达最大深度，则停止递归
---
7.4 结果重排与多样性
01.相关性重排 (Reranking)
a.优化最终结果顺序
a.功能说明
在收集到所有候选结果后，OpenViking 会进行最后一步的重排（Reranking）。这一步会综合考虑多种因素，如原始的语义相似度分数、关键词匹配度、文件路径的重要性、以及结果的多样性，来确定最终呈现给用户的最佳结果顺序。
b.代码示例
---
# 重排考虑因素:
# 1. 原始向量相似度分数
# 2. 结果是否来自高分目录
# 3. 结果是否包含所有查询关键词
# 4. 避免返回过多来自同一文件的片段
---
02.多样性控制
a.避免信息冗余
a.功能说明
为了避免返回的结果过于集中和冗余（例如，返回的 Top 5 结果都来自同一个文件的相邻段落），重排算法会引入多样性控制。它会适当地降低来自同一来源的相似结果的排名，提升来自不同来源、能够提供不同视角信息的结果的排名。
b.代码示例
---
# 初始结果:
# 1. doc1.md (chunk 3, score 0.95)
# 2. doc1.md (chunk 4, score 0.94)
# 3. doc2.md (chunk 1, score 0.90)
#
# 多样性重排后:
# 1. doc1.md (chunk 3, score 0.95)
# 2. doc2.md (chunk 1, score 0.90) -> 排名提升
# 3. doc1.md (chunk 4, score 0.94) -> 排名下降
---
03.上下文感知
a.理解结果的语境
a.功能说明
重排过程是上下文感知的。它不仅看重片段本身的内容，更看重片段所在的“语境”。一个位于结构清晰、命名规范的目录下的文件，其权重会高于一个位于混乱、无组织目录下的文件。这使得返回的结果不仅相关，而且可靠。
b.代码示例
---
# /docs/api/v2/auth.md 中的片段
# vs
# /tmp/test/doc1.md 中的片段
#
# 前者的权重会更高
---
7.5 可观测性与调试
01.检索轨迹记录
a.让检索过程透明化
a.功能说明
OpenViking 的一个核心优势是其可观测性。每一次 `find` 操作的内部执行轨迹，包括意图分析、初始定位、目录进入、二次检索、最终重排等步骤，都会被详细地记录下来。这打破了传统 RAG 的黑箱模式，使得开发者可以清晰地理解检索行为。
b.代码示例
---
# (内部日志示例)
# [FIND] Query: "..."
# [INTENT] Parsed conditions: {...}
# [VECTOR_SEARCH] Found 20 initial chunks.
# [DIR_RECURSION] Entering high-score directory: /docs/db/
# [RERANK] Reranking 50 candidates.
# [RESULT] Returned 5 resources.
---
02.问题归因与分析
a.快速定位问题根源
a.功能说明
当检索结果不符合预期时，详细的检索轨迹记录为问题归因提供了极大的便利。开发者可以回溯整个检索过程，分析是在哪个环节（如意图理解错误、初始定位不准、还是重排逻辑有偏）出了问题，从而进行针对性的优化。
b.代码示例
---
# 分析场景: 为什么没有找到预期的文件？
# 查看日志 -> 发现初始向量检索结果中就没有包含该文件相关的切片
# -> 问题可能出在 Embedding 模型或文档分块策略上
---
03.检索逻辑优化指导
a.数据驱动的迭代
a.功能说明
通过分析大量的检索轨迹数据，开发者可以获得关于如何优化检索逻辑的宝贵洞见。例如，可以发现哪些类型的查询意图分析得不好，或者哪些目录结构对检索更友好，从而数据驱动地迭代和优化整个上下文管理和检索系统。
b.代码示例
---
# 发现大量关于"配置"的查询都定位到了 /examples/ 目录
# -> 优化策略: 提升 /docs/config/ 目录的权重
---
8 记忆与自迭代机制
8.1 记忆的类型与结构
01.用户记忆 (User Memory)
a.记录用户偏好与信息
a.功能说明
用户记忆用于存储与特定用户相关的信息，使得 Agent 的交互更具个性化。这可以包括用户的基本信息、沟通偏好、历史问题总结、以及对 Agent 的特定要求等。通常存储在 `/memory/user/` 目录下。
b.代码示例
---
# 用户偏好文件: /memory/user/preferences.json
# {
# "language": "zh-CN",
# "response_style": "concise",
# "name": "Alice"
# }
---
02.Agent 记忆 (Agent Memory)
a.沉淀 Agent 的经验与知识
a.功能说明
Agent 记忆用于存储 Agent 自身在执行任务和与世界交互过程中学习到的经验和知识。这包括成功的操作流程、失败的经验教训、对工具使用技巧的总结等。这是 Agent 实现自我进化的核心。通常存储在 `/memory/agent/` 目录下。
b.代码示例
---
# Agent 经验文件: /memory/agent/experience/fix_db_bug.md
# Title: 修复数据库连接超时 Bug 的经验
#
# 1. 检查防火墙规则。
# 2. 使用 `telnet` 测试端口连通性。
# 3. 查看数据库连接池配置，增加 `timeout` 参数。
---
03.会话记忆 (Session Memory)
a.短期上下文的载体
a.功能说明
会话记忆是短期的、与当前对话或任务直接相关的上下文。它包括当前的对话历史、Agent 的中间思考过程（Chain of Thought）、以及在当前会话中引用的资源和工具。会话记忆是 `session.commit()` 进行长期记忆提取的原始素材。
b.代码示例
---
# (内存中的数据结构，或临时文件)
# Session {
# history: [("user", "..."), ("agent", "...")],
# scratchpad: "我需要先找到相关文档，然后调用代码分析工具...",
# references: ["viking:///.../doc.md"]
# }
---
8.2 会话管理
01.会话开始与结束
a.明确的生命周期
a.功能说明
每个与 Agent 的交互都可以被视为一个会话（Session）。会话有明确的开始和结束。在 OpenViking 中，这通常由一个会话对象的创建和关闭来管理。这为上下文的隔离和后续的分析提供了清晰的边界。
b.代码示例
---
# (概念代码)
# session = client.new_session()
# try:
# # ... agent 交互 ...
# finally:
# session.close()
---
02.上下文自动压缩
a.应对长对话挑战
a.功能说明
在长对话中，完整的对话历史很快会超出模型的上下文窗口限制。OpenViking 的会话管理器能够自动对早期的对话历史进行压缩和总结，提取其中的关键信息，从而在保留核心上下文的同时，有效控制 Token 的使用量。
b.代码示例
---
# 原始对话:
# User: "你好"
# Agent: "你好，有什么可以帮您？"
# User: "我想查一下天气"
# ... (10轮对话后)
#
# 自动压缩后的历史摘要:
# "用户 Alice 进行了问候，并查询了北京的天气。"
---
03.资源与工具调用记录
a.追踪 Agent 的行为
a.功能说明
会话管理器会精确记录 Agent 在当前会话中引用的所有资源（`viking://` URI）和调用的所有工具（技能）。这些记录是分析 Agent 行为、理解其决策过程、以及进行经验提取的关键依据。
b.代码示例
---
# 会话记录中的行为追踪
# {
# "references": [
# "viking:///resources/weather_api/docs.md"
# ],
# "tool_calls": [
# { "tool": "get_weather", "params": {"city": "beijing"} }
# ]
# }
---
8.3 记忆自迭代闭环
01.session.commit() 机制
a.触发记忆提取
a.功能说明
`session.commit()` 是启动记忆自迭代闭环的关键方法。当一个会话成功结束（例如，Agent 成功完成了一个任务），调用此方法会触发一个后台进程，该进程负责分析整个会话的记录，并从中提取有价值的信息以形成长期记忆。
b.代码示例
---
# 任务成功完成后调用
if task_is_successful:
session.commit()
---
02.异步分析过程
a.不阻塞主流程
a.功能说明
记忆提取和分析是一个相对耗时的过程，因为它可能需要调用 VLM 模型进行总结和反思。因此，`session.commit()` 触发的分析过程是异步执行的，不会阻塞当前的交互流程，确保了 Agent 的响应速度。
b.代码示例
---
# session.commit() 立即返回
# 后台启动一个独立的任务执行记忆提取
# BackgroundJob.enqueue(extract_memory_from_session, session_id)
---
03.成功经验提取
a.学习如何做对事情
a.功能说明
对于成功的任务，异步分析过程会重点分析 Agent 的决策链、资源引用和工具调用序列，从中总结出可复用的成功模式或操作技巧，并将其存入 Agent 记忆库（`/memory/agent/`）。
b.代码示例
---
# 从一次成功的代码调试会话中提取的经验
# -> "当 Python 程序出现 ImportError 时，检查虚拟环境和 `sys.path` 是有效的解决步骤。"
# -> 存入 /memory/agent/skills/python_debugging.txt
---
04.失败经验总结
a.学习如何避免错误
a.功能说明
对于失败的任务，分析过程会关注失败的原因，并总结出需要避免的错误操作或错误的推理路径。这些“失败经验”同样是宝贵的财富，可以帮助 Agent 在未来避免重蹈覆辙。
b.代码示例
---
# 从一次失败的 API 调用中总结的教训
# -> "调用 `send_email` API 时，如果没有提供 `recipient` 参数，会导致调用失败。这是一个必需参数。"
# -> 存入 /memory/agent/experience/api_usage_errors.md
---
8.4 Agent 的成长与进化
01.知识的持续积累
a.越用越聪明
a.功能说明
通过记忆自迭代的闭环，Agent 的知识库（包括用户记忆和自身经验）会随着与用户和世界的交互而不断增长。这种持续的知识积累是 Agent 能够“越用越聪明”的根本原因。
b.代码示例
---
# Day 1: Agent 知识库有 10 条记忆
# Day 10: Agent 知识库有 100 条记忆
# Agent 的能力和表现得到显著提升
---
02.决策能力提升
a.基于经验做出更优选择
a.功能说明
当 Agent 在未来遇到类似的任务或问题时，它可以通过检索自己的记忆库来获取相关的成功经验或失败教训。这些历史经验会作为重要的上下文信息，帮助 Agent 的规划模块（Planner）做出更优的决策，选择更有效的执行路径。
b.代码示例
---
# 新任务: 调试一个新的 Python bug
# Agent -> find("python debugging tips", target_uri="/memory/agent/")
# -> 找到关于检查 `sys.path` 的记忆
# -> Planner 优先选择执行 `print(sys.path)` 的操作
---
03.个性化与适应性
a.更好地适应用户
a.功能说明
通过不断积累用户记忆，Agent 能够更好地适应每个用户的独特需求和偏好。它会记住用户的名字、喜欢的沟通方式、以及过去关心的问题，从而提供更加贴心和个性化的服务。
b.代码示例
---
# User: "你好，我是 Bob"
# Agent -> session.commit() -> 记忆: "用户的名字是 Bob"
#
# 下次对话
# Agent: "你好，Bob！今天有什么可以帮您？"
---
9 命令行工具 (CLI) 使用
9.1 Python CLI
01.安装与配置
a.通过 pip 安装
a.功能说明
Python CLI 是 OpenViking 的标准命令行工具，它通过 `pip install openviking` 自动安装。使用前，需要确保 `OPENVIKING_CONFIG_FILE` 环境变量已正确设置，指向您的 `ov.conf` 配置文件。
b.代码示例
---
# 安装
pip install openviking
# 配置环境变量
export OPENVIKING_CONFIG_FILE=~/.openviking/ov.conf
# 验证安装
openviking --version
---
02.主要命令
a.管理上下文的核心操作
a.功能说明
Python CLI 提供了一系列命令来管理 OpenViking 的上下文数据库。
- `openviking add <path>`: 添加资源。
- `openviking ls <uri>`: 列出目录内容。
- `openviking find <query>`: 进行语义搜索。
- `openviking abstract <uri>`: 获取摘要。
- `openviking overview <uri>`: 获取概述。
b.代码示例
---
# 添加当前目录为资源
openviking add .
# 列出根目录
openviking ls viking:///
# 搜索
openviking find "什么是 OpenViking"
---
03.使用示例
a.完整的操作流程
a.功能说明
一个典型的 CLI 使用流程如下：首先初始化一个数据目录，然后添加资源，等待处理，最后进行查询。
b.代码示例
---
# 1. 初始化数据目录 (通过 --path 指定)
openviking --path ./my_data add https://github.com/volcengine/OpenViking
# 2. 等待处理 (CLI 会自动等待)
# 3. 搜索
openviking --path ./my_data find "how to install"
---
9.2 Rust CLI (ov_cli)
01.安装方式
a.使用安装脚本或 cargo
a.功能说明
Rust CLI (`ov_cli`) 提供了比 Python CLI 更快的性能。可以通过官方提供的安装脚本或使用 Rust 的包管理器 cargo 进行安装。
b.代码示例
---
# 使用安装脚本
curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/crates/ov_cli/install.sh | bash
# 或者使用 cargo
# cargo install --git https://github.com/volcengine/OpenViking ov_cli
# 验证安装
ov_cli --version
---
02.性能优势
a.更快的执行速度
a.功能说明
由于 Rust 是编译型语言，`ov_cli` 的启动速度和执行效率都显著高于基于 Python 解释器运行的 `openviking` CLI。对于需要频繁进行命令行操作或在自动化脚本中调用的场景，`ov_cli` 是更好的选择。
b.代码示例
---
# 性能对比 (概念)
# time openviking ls viking:/// -> 0.5s
# time ov_cli ls viking:/// -> 0.05s
---
03.命令对比
a.与 Python CLI 基本一致
a.功能说明
`ov_cli` 的命令设计与 Python CLI 保持了高度的一致性，降低了用户的学习成本。主要命令的名称和参数基本相同。
b.代码示例
---
# Python CLI vs Rust CLI
# 添加资源
# openviking add . -> ov_cli add .
# 列出目录
# openviking ls <uri> -> ov_cli ls <uri>
# 搜索
# openviking find <q> -> ov_cli find <q>
---
9.3 常见用例
01.快速查询知识库
a.作为个人知识管理工具
a.功能说明
你可以将自己的文档、笔记、代码片段等添加到 OpenViking 中，然后通过 CLI 快速进行语义搜索，将其作为一个强大的个人知识管理工具。
b.代码示例
---
# 1. 添加你的笔记目录
openviking add ~/Documents/MyNotes/
# 2. 随时查询
openviking find "上次关于微服务架构的会议记录"
---
02.自动化脚本集成
a.在 CI/CD 或其他脚本中使用
a.功能说明
CLI 工具可以方便地集成到自动化脚本中。例如，在 CI/CD 流程中，可以自动将最新的代码和文档添加到 OpenViking，然后运行一个 Agent 来检查文档是否需要更新。
b.代码示例
---
# (在 a .sh 脚本中)
#!/bin/bash
echo "Updating knowledge base with latest code..."
ov_cli add ./src
echo "Running agent to check for documentation updates..."
python run_doc_check_agent.py
---
03.数据导入与导出
a.管理 OpenViking 数据
a.功能说明
CLI 提供了数据管理的基本能力。通过 `add` 命令可以方便地导入数据。虽然当前版本可能没有直接的导出命令，但由于数据是存储在本地目录的，可以直接通过备份整个数据目录来实现数据的导出和迁移。
b.代码示例
---
# 备份数据
tar -czf openviking_backup.tar.gz ./my_data
# 在另一台机器上恢复
# tar -xzf openviking_backup.tar.gz
# openviking --path ./my_data find "..."
---
10 最佳实践与未来展望
10.1 最佳实践
01.目录结构设计
a.有意义的层次结构
a.功能说明
一个良好设计的目录结构对于发挥 OpenViking 的优势至关重要。建议创建有意义的、能够反映信息内在逻辑的层次结构。例如，按项目、按模块、按日期等方式组织资源，将极大提升目录递归检索的效率和准确性。
b.代码示例
---
# 不好的结构 (扁平化)
# /resources/doc1.md
# /resources/doc2.md
# 好的结构 (层次化)
# /resources/project_x/api/v1.md
# /resources/project_x/db/schema.md
---
02.上下文粒度控制
a.平衡信息密度与检索效率
a.功能说明
在添加资源时，需要考虑上下文的粒度。将一个巨大的文件（如几百页的 PDF）作为一个单元添加，可能会导致 L0/L1 摘要质量下降。如果可能，将大型文档拆分为逻辑上独立的章节或部分，再分别添加，通常能获得更好的检索效果。
b.代码示例
---
# 原始文件: large_book.pdf
# 拆分后:
# client.add_resource(path="./chapters/chapter1.md")
# client.add_resource(path="./chapters/chapter2.md")
# ...
---
03.充分利用记忆机制
a.主动进行 session.commit()
a.功能说明
要让 Agent 实现成长，最关键的是要充分利用记忆机制。在 Agent 成功完成任务或获得有价值的用户反馈后，应主动调用 `session.commit()` 来触发记忆提取。这将把临时的会话经验转化为可长期复用的知识。
b.代码示例
---
# 在任务循环的关键节点调用 commit
# while True:
# task = get_new_task()
# result = agent.run(task)
# if result.is_success:
# agent.session.commit()
---
10.2 性能优化
01.选择合适的模型
a.平衡成本与性能
a.功能说明
VLM 和 Embedding 模型的选择对 OpenViking 的整体性能和成本有直接影响。对于需要高质量摘要和复杂推理的场景，应选择能力更强的 VLM 模型（如 GPT-4, Claude 3 Opus）。对于简单的检索任务，可以选择成本更低的 Embedding 模型。
b.代码示例
---
# 高性能配置:
# VLM: gpt-4-vision-preview
# Embedding: text-embedding-3-large
# 高性价比配置:
# VLM: doubao-seed-1-8
# Embedding: doubao-embedding-vision
---
02.使用 Rust CLI
a.提升命令行效率
a.功能说明
在需要进行大量命令行操作或在自动化脚本中调用时，强烈推荐使用 Rust CLI (`ov_cli`)。它的启动速度和执行效率远超 Python CLI，能够显著提升整体的自动化流程效率。
b.代码示例
---
# 在脚本中优先使用 ov_cli
# for dir in $(find . -maxdepth 1 -type d); do
# ov_cli add $dir
# done
---
03.硬件资源配置
a.保证充足的内存和磁盘
a.功能说明
OpenViking 的数据存储在本地，会占用一定的磁盘空间。同时，向量索引和部分缓存会加载到内存中。为了保证良好的性能，需要为 OpenViking 运行的环境提供充足的内存和快速的磁盘（如 SSD）。
b.代码示例
---
# 推荐配置 (根据数据量调整):
# - CPU: 4 Cores+
# - Memory: 16 GB+
# - Disk: 100 GB+ SSD
---
10.3 未来展望
01.多模态支持增强
a.超越文本和图像
a.功能说明
未来的 OpenViking 将进一步增强对多模态数据的支持，除了现有的文本和图像，还将逐步支持音频、视频等更丰富的上下文类型。这将使得 Agent 能够理解和处理更加复杂和多样化的信息。
b.代码示例
---
# (未来特性)
# client.add_resource(path="./meeting_recording.mp3")
# client.find("会议中关于 Q3 预算的讨论")
---
02.上下文版本控制
a.实现上下文的 Git
a.功能说明
一个令人兴奋的未来方向是引入上下文的版本控制系统，实现“上下文的 Git”。这将允许开发者追踪上下文的变化历史，比较不同版本间的差异，甚至在需要时回滚到某个历史状态，为 Agent 的开发和调试带来革命性的变化。
b.代码示例
---
# (未来特性)
# client.history("viking:///.../api.md")
# client.diff("viking:///.../api.md", from="v1", to="v2")
# client.checkout("viking:///", version="yesterday")
---
03.更智能的 Agent 协作
a.多 Agent 共享上下文
a.功能说明
未来的 OpenViking 将探索支持多 Agent 之间的上下文共享和协作。多个 Agent 可以挂载同一个上下文数据库，或者通过协议相互分享和引用各自的上下文。这将为构建复杂的、由多个专业 Agent 组成的协作系统提供基础。
b.代码示例
---
# (未来特性)
# Agent A: "@AgentB，请帮我分析一下 viking:///resources/data.csv"
# Agent B: (接收到 URI，读取内容并执行分析)
---
04.与 VikingDB 的深度集成
a.企业级的解决方案
a.功能说明
OpenViking 作为开源项目，将与火山引擎商业化的 VikingDB 向量数据库、知识库和记忆库产品进行更深度的集成。这将为企业级用户提供从本地开发到云端部署、从原型验证到大规模生产的全链路、高性能、高可用的上下文工程解决方案。
b.代码示例
---
# (未来特性)
# 将本地 OpenViking 数据无缝同步到云端 VikingDB
# client.sync_to_cloud(endpoint="volcengine_cloud_instance")
---