1. 引言Agent 上下文管理的三座大山把 LLM 真正变成能干活的 Agent难点往往不在模型本身而在「怎么把该给它的信息塞进上下文」。一个靠谱的 Agent 通常需要三类上下文长期记忆跨会话记住用户偏好、历史决策、任务结论知识库RAG按需检索业务文档、FAQ、内部规范技能包一组可调用的工具、脚本、API 说明。如果把这些内容全都塞进 prompttoken 会爆炸如果塞得太少Agent 又会「失忆」。更麻烦的是这三类上下文管理方式各不相同工程上只能各写一套维护成本很高。volcengine/OpenViking 给出的解法是把问题抽象成一句话把记忆、RAG、技能统一映射成一个虚拟文件系统Agent 像读文件一样按需取用上下文。2. 核心思路一切皆文件OpenViking 的设计哲学非常 Unix既然操作系统能把设备、进程、网络都抽象成文件那 Agent 的上下文为什么不行在 OpenViking 里所有上下文源都被统一为一个viking://虚拟文件系统VFSviking:// ├── memory/ # 长期记忆 │ ├── preferences.md │ ├── decisions/2026-08.md │ └── summary/latest.md ├── knowledge/ # 知识库 / RAG │ ├── docs/ │ ├── faq.md │ └── index.json └── skills/ # 技能包 ├── analysis/ ├── report_gen/ └── api/weather.md不管底层是向量数据库、关系库还是对象存储对 Agent 来说都是「路径 文本」。LLM 天然擅长读文件、按路径找内容这套抽象几乎不用额外解释就能让模型学会使用。这样做有三个直接收益一个心智模型读记忆、查知识、调技能全部统一成「读文件」一套访问接口统一权限、审计、版本、缓存天然可分片文件天然支持按需加载为省 token 打下基础。3. viking:// 虚拟文件系统的分层懒加载OpenViking 省 token 的关键在于它把文件内容拆成L0 / L1 / L2三层按「摘要 → 正文 → 附件」的粒度渐进加载。层级内容token 成本加载时机L0目录树、文件名、一句话摘要极低初始阶段全量注入L1文件正文 / 关键片段中等Agent 主动open/read时L2大附件、完整文档、二进制描述较高明确需要时才拉取工作流程大致是Agent 启动时先拿到 L0 的目录树 摘要知道「有哪些可用的记忆、知识和技能」token 消耗很小它判断需要哪个文件发起一次viking://读请求再加载 L1 正文只有碰到超大文档或附件时才按需展开 L2。这样 Agent 既保持了「知道自己有什么」的全局视野又不必为不相关的内容付费。相比「一次性把 RAG top-k 结果全灌进去」这种先看目录、再读正文的懒加载模式能把无关 token 显著降下来。4. 快速上手用 Python 映射记忆 / RAG / 技能下面是一段最小化示例展示 OpenViking 如何把三类上下文映射进虚拟文件系统。请以项目仓库最新 README 为准调整导入与类名。fromopenvikingimportVikingContext,MemorySource,KnowledgeSource,SkillSource# 1. 创建 Agent 上下文底座ctxVikingContext()# 2. 长期记忆映射成 memory/ 目录ctx.mount(MemorySource(backendsqlite,db_path./agent_memory.db,mount_pointviking://memory,))# 3. 知识库接入向量检索按查询动态生成 knowledge/ 下的文件ctx.mount(KnowledgeSource(backendvector,collectioncompany_docs,mount_pointviking://knowledge,summarizeTrue,# 自动生成 L0 摘要top_k5,))# 4. 技能包把工具说明与可执行脚本映射成 skills/ 目录ctx.mount(SkillSource(registryskills.yaml,mount_pointviking://skills,))# 5. 注入到 prompt默认只注入 L0 目录树与摘要system_promptctx.render(model0)print(system_prompt)# viking://memory/preferences.md —— 用户偏好摘要偏好简洁回答...# viking://skills/analysis/ —— 数据分析技能读取 CSV 并产出报告...# 6. Agent 按需读取 L1 内容contentctx.read(viking://memory/preferences.md)print(content)# 返回该文件的完整正文在这个模型下render(model0)只把目录和摘要放进 prompt真正的正文要等 Agent 通过工具调用ctx.read(...)才展开。记忆、知识库、技能三套体系被收敛成了同一套「挂载 读取」流程。5. 为什么懒加载真的能省 token省 token 不是靠压缩而是靠改变注入时机避免全量灌入传统做法是把 RAG 检索到的若干段落全部拼进 prompt哪怕一半与当前任务无关L0 摘要先行Agent 先看到「我有哪些知识」再有针对性地读取减少盲目检索长文档只取所需遇到 50 页的规范文档先读目录L0/L1命中具体条款再展开 L2跨轮复用已加载的文件可在会话内缓存多轮对话只重复支付必要的 token。对长会话、多工具、大知识库的 Agent 场景这套「目录—正文—附件」的分层策略能把上下文预算花在刀刃上。6. 适用场景与边界OpenViking 特别适合以下场景需要长期记忆的客服 / 个人助理 / 智能体挂载多个知识库、希望统一检索入口的企业 Agent拥有大量工具/技能、需要让模型先「浏览目录再选择」的复杂工作流。同时也要注意viking:// 是逻辑抽象实际读写仍受底层存储性能约束L0 摘要质量直接影响 Agent「找不找得到文件」摘要生成策略需要结合业务调优。7. 总结OpenViking 的价值在于把「Agent 上下文管理」从一个工程堆叠问题收敛成了一个虚拟文件系统问题记忆、知识库、技能统一为viking://路径L0/L1/L2 分层懒加载把 token 从「一次性灌入」变成「按需取用」LLM 只需学会「读文件」就能自然获得长期记忆、RAG 检索与技能调用能力。如果你的 Agent 正被越来越长的 prompt 和越来越复杂的上下文管理拖累值得把「一切皆文件」这个思路认真试一次。 OpenViking 深入浅出：用 viking:// 虚拟文件系统给 AI Agent 装上省 token 的上下文底座
1. 引言Agent 上下文管理的三座大山把 LLM 真正变成能干活的 Agent难点往往不在模型本身而在「怎么把该给它的信息塞进上下文」。一个靠谱的 Agent 通常需要三类上下文长期记忆跨会话记住用户偏好、历史决策、任务结论知识库RAG按需检索业务文档、FAQ、内部规范技能包一组可调用的工具、脚本、API 说明。如果把这些内容全都塞进 prompttoken 会爆炸如果塞得太少Agent 又会「失忆」。更麻烦的是这三类上下文管理方式各不相同工程上只能各写一套维护成本很高。volcengine/OpenViking 给出的解法是把问题抽象成一句话把记忆、RAG、技能统一映射成一个虚拟文件系统Agent 像读文件一样按需取用上下文。2. 核心思路一切皆文件OpenViking 的设计哲学非常 Unix既然操作系统能把设备、进程、网络都抽象成文件那 Agent 的上下文为什么不行在 OpenViking 里所有上下文源都被统一为一个viking://虚拟文件系统VFSviking:// ├── memory/ # 长期记忆 │ ├── preferences.md │ ├── decisions/2026-08.md │ └── summary/latest.md ├── knowledge/ # 知识库 / RAG │ ├── docs/ │ ├── faq.md │ └── index.json └── skills/ # 技能包 ├── analysis/ ├── report_gen/ └── api/weather.md不管底层是向量数据库、关系库还是对象存储对 Agent 来说都是「路径 文本」。LLM 天然擅长读文件、按路径找内容这套抽象几乎不用额外解释就能让模型学会使用。这样做有三个直接收益一个心智模型读记忆、查知识、调技能全部统一成「读文件」一套访问接口统一权限、审计、版本、缓存天然可分片文件天然支持按需加载为省 token 打下基础。3. viking:// 虚拟文件系统的分层懒加载OpenViking 省 token 的关键在于它把文件内容拆成L0 / L1 / L2三层按「摘要 → 正文 → 附件」的粒度渐进加载。层级内容token 成本加载时机L0目录树、文件名、一句话摘要极低初始阶段全量注入L1文件正文 / 关键片段中等Agent 主动open/read时L2大附件、完整文档、二进制描述较高明确需要时才拉取工作流程大致是Agent 启动时先拿到 L0 的目录树 摘要知道「有哪些可用的记忆、知识和技能」token 消耗很小它判断需要哪个文件发起一次viking://读请求再加载 L1 正文只有碰到超大文档或附件时才按需展开 L2。这样 Agent 既保持了「知道自己有什么」的全局视野又不必为不相关的内容付费。相比「一次性把 RAG top-k 结果全灌进去」这种先看目录、再读正文的懒加载模式能把无关 token 显著降下来。4. 快速上手用 Python 映射记忆 / RAG / 技能下面是一段最小化示例展示 OpenViking 如何把三类上下文映射进虚拟文件系统。请以项目仓库最新 README 为准调整导入与类名。fromopenvikingimportVikingContext,MemorySource,KnowledgeSource,SkillSource# 1. 创建 Agent 上下文底座ctxVikingContext()# 2. 长期记忆映射成 memory/ 目录ctx.mount(MemorySource(backendsqlite,db_path./agent_memory.db,mount_pointviking://memory,))# 3. 知识库接入向量检索按查询动态生成 knowledge/ 下的文件ctx.mount(KnowledgeSource(backendvector,collectioncompany_docs,mount_pointviking://knowledge,summarizeTrue,# 自动生成 L0 摘要top_k5,))# 4. 技能包把工具说明与可执行脚本映射成 skills/ 目录ctx.mount(SkillSource(registryskills.yaml,mount_pointviking://skills,))# 5. 注入到 prompt默认只注入 L0 目录树与摘要system_promptctx.render(model0)print(system_prompt)# viking://memory/preferences.md —— 用户偏好摘要偏好简洁回答...# viking://skills/analysis/ —— 数据分析技能读取 CSV 并产出报告...# 6. Agent 按需读取 L1 内容contentctx.read(viking://memory/preferences.md)print(content)# 返回该文件的完整正文在这个模型下render(model0)只把目录和摘要放进 prompt真正的正文要等 Agent 通过工具调用ctx.read(...)才展开。记忆、知识库、技能三套体系被收敛成了同一套「挂载 读取」流程。5. 为什么懒加载真的能省 token省 token 不是靠压缩而是靠改变注入时机避免全量灌入传统做法是把 RAG 检索到的若干段落全部拼进 prompt哪怕一半与当前任务无关L0 摘要先行Agent 先看到「我有哪些知识」再有针对性地读取减少盲目检索长文档只取所需遇到 50 页的规范文档先读目录L0/L1命中具体条款再展开 L2跨轮复用已加载的文件可在会话内缓存多轮对话只重复支付必要的 token。对长会话、多工具、大知识库的 Agent 场景这套「目录—正文—附件」的分层策略能把上下文预算花在刀刃上。6. 适用场景与边界OpenViking 特别适合以下场景需要长期记忆的客服 / 个人助理 / 智能体挂载多个知识库、希望统一检索入口的企业 Agent拥有大量工具/技能、需要让模型先「浏览目录再选择」的复杂工作流。同时也要注意viking:// 是逻辑抽象实际读写仍受底层存储性能约束L0 摘要质量直接影响 Agent「找不找得到文件」摘要生成策略需要结合业务调优。7. 总结OpenViking 的价值在于把「Agent 上下文管理」从一个工程堆叠问题收敛成了一个虚拟文件系统问题记忆、知识库、技能统一为viking://路径L0/L1/L2 分层懒加载把 token 从「一次性灌入」变成「按需取用」LLM 只需学会「读文件」就能自然获得长期记忆、RAG 检索与技能调用能力。如果你的 Agent 正被越来越长的 prompt 和越来越复杂的上下文管理拖累值得把「一切皆文件」这个思路认真试一次。