GEO

OpenViking如何重构Agent上下文?2026年文件系统范式解析

2026/3/16
OpenViking如何重构Agent上下文?2026年文件系统范式解析
AI Summary (BLUF)

OpenViking is an open-source Agent context database from Volcano Engine that transforms context management from fragmented vector chunks into an operable file system paradigm, addressing key RAG pain points like token cost control and retrieval explainability.

原文翻译: OpenViking是火山引擎开源的Agent上下文数据库,它将上下文管理从碎片化的向量块转变为可操作的文件系统范式,解决了RAG的关键痛点,如Token成本控制和检索可解释性。

Introduction

OpenViking, an Agent context database open-sourced by ByteDance's Volcano Engine in January 2026, represents a significant paradigm shift in how we manage and utilize context for AI agents. Its core innovation lies not in creating yet another vector database, but in fundamentally reimagining context organization. It moves away from the traditional RAG model's flat, fragmented chunks of text and towards a structured, addressable virtual file system accessible via the viking:// protocol. Within this system, memories, resources, and skills are organized as directories and files, with the underlying vector retrieval capabilities provided by VikingDB.

OpenViking 是字节跳动火山引擎于 2026 年 1 月开源的 Agent 上下文数据库。它的核心创新并非“再造一个向量库”,而是从根本上重构了上下文的组织形式。它摒弃了传统 RAG 模型中扁平、碎片化的文本片段,转向一个通过 viking:// 协议访问的结构化、可寻址的虚拟文件系统。在这个系统中,记忆、资源和技能被组织为目录和文件,底层的向量检索能力则由 VikingDB 提供。

Project Repository: https://github.com/volcengine/OpenViking

The Core Problem: Why Traditional RAG Falls Short for Agents

For developers who have built AI agents, the following pain points are all too familiar. OpenViking is designed to address these fundamental limitations.

对于构建过 AI 智能体的开发者而言,以下痛点都再熟悉不过。OpenViking 正是为了应对这些根本性限制而设计的。

  • Fragmented Context: Retrieval returns snippets, not structure. Semantic "similarity" does not equate to executability. For instance, asking "How is authentication configured?" might retrieve a paragraph about OAuth, but the agent cannot determine which service it belongs to or what modules it is associated with.

    上下文碎片化:检索返回的是片段,而非结构。语义“相似”不等于可执行。例如,询问“认证是如何配置的?”可能返回一段关于 OAuth 的文本,但智能体无法判断它属于哪个服务、与哪些模块相关联。

  • Uncontrolled Token Costs: The typical approach is either to fill the entire context window (expensive) or to truncate it arbitrarily (risking loss of critical information).

    Token 成本失控:常见的做法要么是填满整个上下文窗口(成本高昂),要么是粗暴地截断(可能丢失关键信息)。

  • Unexplainable Retrieval: When errors occur, it's difficult to diagnose whether the issue lies with recall, ranking, or data organization. Traditional vector pipelines operate as a black box.

    检索不可解释:出错时,很难诊断问题是出在召回、排序还是数据组织上。传统的向量检索流程如同一个黑盒。

  • Difficulty in Memory Consolidation: Once a session ends, the context is often discarded. Agents lack a stable, long-term "experience layer," forcing each new conversation to start from scratch.

    记忆难沉淀:会话结束后,上下文通常被丢弃。智能体缺乏一个稳定的长期“经验层”,导致每次对话都几乎从零开始。

The Manus team proposed a compelling viewpoint: the file system is the ultimate form for Agent context. Claude Code has also demonstrated that a simple file system + Bash can be more effective than complex vector indexing in certain scenarios. OpenViking can be understood as an engineering-level implementation in this direction: it transforms "context management" from a set of black-box retrieval operations into a system-layer capability that can be observed, tuned, and governed through engineering practices.

Manus 团队提出了一个引人注目的观点:文件系统是 Agent 上下文的终极形态。Claude Code 也验证了这一点:在某些场景下,简单的文件系统 + Bash 比复杂的向量索引更好用OpenViking 可以理解为在这个方向上进行的工程化实现:它将“上下文管理”从一组黑盒检索操作,转变为一种可观察、可调优、可通过工程实践进行治理的系统层能力

Core Mechanisms: How OpenViking Works

1) The File System Paradigm: Unified Addressing with viking://

OpenViking organizes all context within a unified directory tree:

viking://├── resources/ # External resources: documents, repositories, web pages, etc.│ ├── docs/│ ├── repos/│ └── web/├── user/│ └── memories/ # User memories└── agent/ ├── memories/ # Agent memories └── skills/ # Agent skills

OpenViking 将所有上下文组织在一个统一的目录树中:
viking://├── resources/ # 外部资源:文档、代码仓库、网页等│ ├── docs/│ ├── repos/│ └── web/├── user/│ └── memories/ # 用户记忆└── agent/ ├── memories/ # 智能体记忆 └── skills/ # 智能体技能

This enables deterministic positioning for the Agent. Instead of merely asking "what is the most similar paragraph?", the Agent can explicitly access a specific context level via its URI—for example, directly reading the L1 overview of viking://resources/docs/api/auth.md. This access is precise, predictable, and does not rely solely on semantic similarity.

这为智能体实现了确定性定位。智能体不再仅仅是询问“最相似的段落是什么?”,而是可以通过 URI 明确访问特定的上下文层级——例如,直接读取 viking://resources/docs/api/auth.md 的 L1 概述。这种访问是精确的、可预测的,不依赖于语义相似度。

2) Three-Tiered Context: L0 / L1 / L2 for On-Demand Loading

During the ingestion phase, OpenViking automatically segments content into three distinct tiers:

在数据摄入阶段,OpenViking 会自动将内容分割为三个不同的层级:

Tier Meaning Scale Primary Use Case
L0 Abstract ~100 tokens Rapid filtering, vector recall
L1 Overview ~2000 tokens Planning, decision-making, navigation
L2 Detail Unlimited Detailed reading, execution, final answer
层级 含义 量级 主要用途
L0 摘要 ~100 tokens 快速筛选、向量召回
L1 概述 ~2000 tokens 规划决策、导航定位
L2 详情 不限 精读执行、最终回答

The core purpose of this tiered approach is cost and noise control. The Agent can first use the lightweight L0 abstracts for broad retrieval, then selectively load the more detailed L1 or L2 content only for the most relevant items, significantly reducing token consumption.

这种分层方法的核心目的是控制成本和噪声。智能体可以先使用轻量级的 L0 摘要进行广泛的检索,然后仅为最相关的条目选择性地加载更详细的 L1 或 L2 内容,从而显著降低 Token 消耗。

3) Directory-Recursive Retrieval: Find the Directory First, Then the Content

Unlike traditional "flat search across the entire database," OpenViking employs a combination of "directory navigation + semantic retrieval":

与传统的“全库扁平搜索”不同,OpenViking 采用了“目录导航 + 语义检索”的组合策略:

  1. Parse the query intent and generate multiple search conditions.

    解析查询意图,生成多个检索条件。

  2. Perform a global vector search to identify the top-3 relevant directories as seed candidates.

    执行全局向量搜索,找出前 3 个相关的目录作为种子。

  3. Conduct a secondary search within the seed directories, recursively delving into subdirectories.

    在种子目录内进行二次检索,递归地进入子目录。

  4. Score Propagation: final_score = α × child_score + (1-α) × parent_score. This blends the relevance of a child item with the relevance of its parent directory.

    分数传播final_score = α × child_score + (1-α) × parent_score。这会将子项的相关性与其父目录的相关性结合起来。

  5. Convergence Detection: The process terminates early if the top-k results remain unchanged for a consecutive number of rounds.

    收敛检测:如果 top-k 结果连续多轮保持不变,则提前终止检索过程。

This method is more efficient and often yields more coherent and contextually relevant results than a purely semantic scatter-shot approach.

与纯粹的语义散射方法相比,这种方法效率更高,通常能产生更连贯、上下文更相关的结果。

4) Session Commit and Memory Refinement: session.commit()

A key feature highlighted in the official blog is the direction of "getting smarter with use." When session.commit() is called, the system asynchronously analyzes the task outcomes and user feedback from the current dialogue. It then updates memory entries under user/memories/ and agent/memories/, and refines tool usage experiences, storing them in agent/skills/.

官方博客强调的一个关键特性是“越用越聪明”的方向。当调用 session.commit() 时,系统会异步分析本次对话的任务结果和用户反馈。然后,它会更新 user/memories/agent/memories/ 下的记忆条目,并提炼工具使用经验,将其存储在 agent/skills/ 中。

The design prioritizes high availability and eventual consistency over strong transactional consistency, making it suitable for scalable agent deployments.

该设计优先考虑高可用性和最终一致性,而非强事务一致性,使其适用于可扩展的智能体部署。

OpenViking vs. VikingDB: Clarifying the Relationship

In short: OpenViking is the upper-layer context system, and VikingDB is the lower-layer vector engine.

简而言之:OpenViking 是上层的上下文系统,VikingDB 是下层的向量引擎。

OpenViking handles the high-level organization, governance, and file-system abstraction of context. VikingDB provides the robust, scalable infrastructure for vector indexing, dense/sparse hybrid search, multi-modal retrieval, and other advanced database operations required to power the system.

OpenViking 负责上下文的高层组织、治理和文件系统抽象。VikingDB 则提供强大、可扩展的基础设施,用于向量索引、稠密/稀疏混合搜索、多模态检索以及其他支撑该系统所需的高级数据库操作。

Conclusion: The Significance of the File System Paradigm

OpenViking's introduction of a virtual file system for Agent context is more than a technical implementation detail; it represents a conceptual leap. By treating context as a structured, navigable, and operable file system, it addresses critical pain points in traditional RAG: fragmentation, cost, opacity, and statelessness.

OpenViking 为 Agent 上下文引入虚拟文件系统,这不仅仅是一个技术实现细节,更代表了一次概念上的飞跃。通过将上下文视为一个结构化、可导航、可操作的文件系统,它解决了传统 RAG 中的关键痛点:碎片化、高成本、不透明和无状态。

This paradigm enables:

  • Deterministic Access: Precise URI-based retrieval.
  • Efficient Resource Management: Tiered loading for optimal token usage.
  • Explainable Operations: Transparent directory-based retrieval paths.
  • Persistent & Evolving Intelligence: A framework for long-term memory and skill refinement.

这种范式实现了:

  • 确定性访问:基于 URI 的精确检索。
  • 高效的资源管理:分层加载以实现最佳的 Token 使用。
  • 可解释的操作:透明的、基于目录的检索路径。
  • 持久且进化的智能:一个用于长期记忆和技能提炼的框架。

For developers building complex, reliable, and cost-effective AI agents, OpenViking offers a compelling new architecture to explore, moving beyond the limitations of treating context as merely a "bag of vectorized snippets."

对于构建复杂、可靠且具有成本效益的 AI 智能体的开发者而言,OpenViking 提供了一个值得探索的全新架构,它超越了将上下文仅仅视为“一袋向量化片段”的局限性。

常见问题(FAQ)

OpenViking与传统RAG在上下文管理上有何根本区别?

OpenViking将上下文从传统RAG的碎片化向量块转变为可操作的文件系统范式,通过viking://协议实现结构化寻址,解决了检索不可解释和Token成本失控等痛点。

OpenViking的三层上下文结构L0/L1/L2具体如何工作?

OpenViking采用按需加载的三层上下文结构:L0为元数据索引,L1为结构化摘要,L2为完整内容。这种分层设计实现了精准的Token成本控制与高效检索。

OpenViking如何通过目录递归检索提升Agent执行效率?

OpenViking采用'先找目录,再找内容'的检索策略。系统首先定位相关目录结构,再精确定位具体文件内容,确保检索结果具有可执行性和上下文关联性。

← 返回文章列表
分享到:微博

版权与免责声明:本文仅用于信息分享与交流,不构成任何形式的法律、投资、医疗或其他专业建议,也不构成对任何结果的承诺或保证。

文中提及的商标、品牌、Logo、产品名称及相关图片/素材,其权利归各自合法权利人所有。本站内容可能基于公开资料整理,亦可能使用 AI 辅助生成或润色;我们尽力确保准确与合规,但不保证完整性、时效性与适用性,请读者自行甄别并以官方信息为准。

若本文内容或素材涉嫌侵权、隐私不当或存在错误,请相关权利人/当事人联系本站,我们将及时核实并采取删除、修正或下架等处理措施。 也请勿在评论或联系信息中提交身份证号、手机号、住址等个人敏感信息。