目录一、Agent 的瓶颈正在从模型能力转向上下文能力一大模型并不缺“知道”真正缺的是“此刻该知道什么”1、上下文窗口变大不等于上下文问题消失1.1 容量成本只是表面问题1.2 注意力与权威冲突才是深层问题2、传统 RAG 的问题定义已经不够完整二上下文碎片化是 Agent 工程最隐蔽的系统债务1、检索债务不同数据源无法形成统一查询计划2、粒度债务系统会检索却不会决定读多少3、治理债务权限、版本和来源被埋在外围4、学习债务一次任务的经验难以回流二、OpenViking 的核心抽象把三类上下文放进同一地址空间一统一不是“都存成文本”而是“都能被同一种方式定位与使用”1、Resource不是“文档仓库”而是任务证据空间2、Memory不是会话存档而是经过选择和更新的认知资产3、Skill不是工具本身而是可检索的能力说明与执行约束二viking://统一上下文的逻辑坐标系三、L0、L1、L2真正重要的是“阅读预算”不是多做两份摘要一三层模型解决的是 Agent 的渐进式阅读1、L0低成本的相关性信号2、L1用于计划与导航的结构化概览3、L2在需要证据时读取的细节二500 页 Policy 的价值不在“切成多少 Chunk”而在“怎样缩小阅读面”三分层摘要并非没有代价1、摘要可能丢失关键限定词2、目录结构会影响召回路径3、异步语义生成带来新鲜度窗口四、从 Top-K 到层级检索检索目标开始从“片段”变成“阅读路径”一OpenViking 的检索链路由三部分组成1、意图分析先判断需要哪一类上下文1.1 类型选择决定检索入口1.2 查询数量本身也是成本控制2、层级检索先找起点再递归进入目录3、Rerank在候选范围内做更精细的判断二Context Database 的关键指标不应只有 RecallK1、入口准确率2、路径效率3、证据覆盖率4、可解释与可复现性5、上下文利用率五、Context Database 如何工作写入、存储与读取的完整链路一写入侧解析与语义理解被刻意分开二存储侧内容与索引分离URI 把二者重新绑定三读取侧浏览、搜索与精读形成三种不同动作六、Session 变成 Memory所谓“自进化”必须经过压缩、去重与审计一会话提交不是简单归档而是一次上下文编译二Memory 的质量取决于更新规则而不是存储容量1、记忆写入需要“稳定性门槛”2、记忆读取需要“适用范围”3、记忆更新需要“时间与权威”4、记忆使用需要“可见反馈”三自进化不是自动变好而是建立可验证的反馈闭环七、OpenViking 与现有技术的关系不是替代一切而是把它们编排成上下文层一与 Vector Database从检索引擎上升为使用接口二与 GraphRAG关系结构重要但不一定要把图作为唯一入口三与 Memory Store从“记忆条目”扩展到完整上下文生命周期四与普通文件系统Agent 看到的是目录系统承担的是数据库责任八、Slack 与 OpenViking从组织沟通到 Agent 可用上下文的供应链一Slack 解决“什么值得沉淀”OpenViking 解决“如何组织和按需读取”1、信号识别2、人工或规则确认3、上下文分类4、分层组织5、失效与回溯二组织上下文的真正产品形态是“可维护的判断库”九、企业落地路线先构建可信上下文域再谈全域统一一第一阶段选择一个高价值、可评估的任务域1、定义成功指标2、建立基线二第二阶段设计 Context 信息架构1、确定范围和命名2、确定权威级别3、确定分层质量标准三第三阶段把检索策略嵌入 Agent 工作流四第四阶段引入 Memory 与组织协作信号五治理清单Context Database 不是无权限的公共大脑十、必须正视的边界Context Database 不是 Agent 的“自动真相层”一统一存储不等于统一可信二目录不是世界的唯一结构三摘要是有损压缩不能代替证据四层级检索会把信息架构质量放大五自进化可能演化出错误六项目仍处于快速演进阶段十一、OpenViking 代表的更大趋势Agent 基础设施正在出现“上下文平面”一从数据平面、控制平面到上下文平面二Context Engineering 将从 Prompt 技巧变成数据工程三未来竞争点不是“谁存得更多”而是“谁调度得更准”十二、结语从“检索相似内容”走向“编排可用认知”可参考的文章与资料干货分享感谢您的阅读OpenViking 的价值不只在于把检索做得更精细而在于重新定义 Agent 与上下文之间的关系上下文不再是一批临时塞进 Prompt 的文本片段而是可以被组织、寻址、分层读取、持续更新并审计的数据资产。从分散的知识、记忆与技能走向统一的 Context Database。一、Agent 的瓶颈正在从模型能力转向上下文能力一大模型并不缺“知道”真正缺的是“此刻该知道什么”过去几年Agent 系统的能力提升常被归因于模型参数、推理链、工具调用或更大的上下文窗口。但在真实企业环境里决定任务质量的往往不是模型能否解释一个概念而是它在行动前能否拿到正确、完整、可信且适量的背景信息。一个负责排查线上事故的 Agent可能需要同时理解代码仓库、架构文档、最近一次发布记录、故障群里的讨论、历史复盘结论以及团队约定的处置流程。一个负责撰写销售方案的 Agent也许要同时读取客户资料、过往沟通、报价规则、品牌语气、审批要求和最佳案例。只缺其中一项结果就可能“看起来合理、实际上不可用”。这类失败有一个共同特征模型不是不会推理而是被放进了一个信息不完整或噪声过高的工作现场。换言之Agent 的上限越来越取决于上下文工程而上下文工程的核心问题也从“如何把更多内容塞进去”转向“如何在正确时刻给出正确粒度的内容”。1、上下文窗口变大不等于上下文问题消失更大的上下文窗口确实能容纳更多材料但容量不是免费的。输入越长推理成本越高信息越杂关键约束越容易被稀释材料之间发生冲突时模型也未必知道哪一份更权威。更危险的是当团队把“窗口足够大”当成架构理由往往会把信息治理、版本管理、权限控制和可追溯性推迟到系统上线之后。1.1 容量成本只是表面问题Token 价格与请求延迟可以被量化因此最容易被看到但真正昂贵的是错误信息进入推理链之后造成的返工、误操作和人工复核。一个包含大量无关材料的 Prompt即使没有超过窗口也可能比一个更短、证据更完整的 Prompt 表现更差。1.2 注意力与权威冲突才是深层问题同一窗口中若同时出现旧政策、新政策、聊天意见和个人笔记模型必须自行判断哪一份应优先。没有来源、时间和权威元数据时更大的窗口只是扩大了冲突集合。因此长上下文只能缓解“装不下”不能自动解决“选不准”“看不懂结构”“不知道新旧”“无法解释为什么召回”。Agent 需要的不是一个无限大的背包而是一套能先导航、再判断、最后取证的阅读机制。2、传统 RAG 的问题定义已经不够完整传统 RAG 的典型问题是面对一个查询哪些 Chunk 在向量空间里最相似这个问题很重要却只覆盖了上下文管理的一部分。真实任务还需要回答该查知识、记忆还是技能该从哪个项目、用户或 Agent 空间开始先给摘要还是给全文目录关系是否重要多个片段是否来自同一语义单元结果为什么被选中使用后是否应该沉淀为新的记忆当这些问题同时出现单纯的“Top-K 相似片段”就会显得过于扁平。它善于发现局部相似却不天然理解内容在组织中的位置、不同上下文类型的生命周期以及 Agent 阅读深度应如何随任务推进而变化。很多 Agent 项目实际维护着多套彼此割裂的上下文系统。二上下文碎片化是 Agent 工程最隐蔽的系统债务在常见架构中知识进入向量数据库长期偏好进入 Memory Store技能保存在 Markdown 或代码仓库工具定义由 MCP 或函数注册表管理会话历史又在日志系统里。每个组件单独看都合理但 Agent 面对的是一组接口、权限模型、更新机制和检索语义完全不同的系统。这种碎片化会产生四类债务。1、检索债务不同数据源无法形成统一查询计划当用户说“按我们以前的风格为这个新接口写一份上线方案”时系统需要同时找到“以前的风格”Memory、“新接口资料”Knowledge/Resource和“上线方案写法”Skill。如果三者由三套独立模块管理编排层必须先猜应该调用哪些模块再把不同返回格式拼接成 Prompt。随着数据源增加编排逻辑很快演化成难以维护的条件分支。2、粒度债务系统会检索却不会决定读多少不少系统只有两种状态没召回或召回全文/Chunk。它们缺少从一句摘要到目录概览再到具体证据的中间层于是要么信息不足要么一次性加载过多。对几十页文档尚且如此对数百页政策、跨仓库代码或多年项目资料问题会被成倍放大。3、治理债务权限、版本和来源被埋在外围如果向量库只保留向量和少量元数据而全文、技能、记忆分散在其他系统删除、移动、更新与权限变更就需要跨系统同步。任何一次同步失败都可能导致“文件已删除但仍能被召回”“索引指向旧版本”或“不同用户共享了不该共享的记忆”。4、学习债务一次任务的经验难以回流Agent 完成任务后产生的修正、偏好、成功路径和失败教训通常留在会话日志里。日志不是记忆它过长、噪声大、缺少结构也没有明确的更新和去重规则。如果系统不能把会话转化为可管理的长期上下文所谓“自进化”就只是一种叙事。OpenViking 正是从这些债务出发把项目定位为面向 AI Agent 的开源 Context Database。官方当前描述强调Memory、Resource 与 Skill 被统一组织在viking://虚拟文件系统下Agent 可以像浏览目录一样使用ls、tree、find、abstract、overview和read等操作并按 L0、L1、L2 三层逐步加载内容。OpenViking README二、OpenViking 的核心抽象把三类上下文放进同一地址空间一统一不是“都存成文本”而是“都能被同一种方式定位与使用”把 Knowledge、Memory、Skill 统一起来最容易产生的误解是OpenViking 只是把三者都存进同一目录。真正重要的并不是物理共存而是它们获得了统一的寻址、层级、检索和读取语义。官方将上下文分为三种基本类型Resource、Memory 和 Skill。Resource 是外部知识与规则通常由用户添加、长期保存且相对稳定Memory 是 Agent 从交互和任务中学到的持久信息动态更新并带有个体或 Peer 范围Skill 是可声明、可调用的能力配置定义 Agent 如何完成某类工作或连接外部系统。Context TypesResource 回答“依据是什么”Memory 回答“过去学到了什么”Skill 回答“应该怎样做”。1、Resource不是“文档仓库”而是任务证据空间Resource 包括产品手册、API 文档、代码仓库、研究论文、FAQ、网页和多媒体资料。它们的主要价值是提供任务依据而不是替代模型的通用知识。OpenViking 将资源按项目与主题组织为目录保留层级结构并为目录生成语义摘要使 Agent 可以先理解“这里有什么”再读取具体文件。这一点改变了传统 RAG 的语义。Chunk 通常脱离原始结构独立排序而 Resource 保留了父目录、子目录、文件名和路径。路径本身成为一种低成本语义viking://resources/payment/api/refund/比一个无上下文的文本片段更容易让 Agent 判断它属于哪个项目、哪个模块以及哪类任务。2、Memory不是会话存档而是经过选择和更新的认知资产OpenViking 的 Memory 类型包括 profile、preferences、entities、events、identity、soul、cases、trajectories 和 experiences 等。它们并不是把所有聊天原样保存而是从交互中抽取可能改善未来任务的信息再经过相似记忆预筛、LLM 去重决策以及创建、合并、删除等更新动作写入用户或 Peer 的命名空间。这意味着记忆系统必须同时处理“记住”和“忘记”。一条新偏好可能覆盖旧偏好一次项目更名可能要求合并实体一次临时要求不应被误判为永久偏好。真正可靠的 Memory Store 不是 append-only 的事实袋而是带有生命周期、冲突处理和审计差异的动态知识库。3、Skill不是工具本身而是可检索的能力说明与执行约束Skill 往往以SKILL.md及配套脚本存在描述何时使用某能力、操作顺序、输入输出和边界条件。把 Skill 纳入 Context Database 后Agent 不必在启动时加载全部技能也不必只依赖硬编码工具列表。它可以先检索“完成当前任务需要什么能力”读取技能摘要与概览再在确认相关时加载完整定义。这使 Skill 从“启动配置”变成“按需上下文”。对于拥有数十乃至数百个技能的 Agent 平台这种变化十分关键全部暴露会造成工具选择混乱完全不暴露又无法发现能力。分层检索提供了一条中间道路。二viking://统一上下文的逻辑坐标系OpenViking 用viking://{scope}/{path}作为统一 URI。公开范围主要包括resources、user和agent全局客观资源进入resources用户级记忆、私有资源、技能和会话进入user/{user_id}全局 Agent 能力配置进入agent。当前用户还可以通过viking://~访问自己的用户根目录。Viking URI统一 URI 带来三项工程价值。第一可定位。Agent 的输出不必只附上一段文本还能附上来源 URI后续任务可以沿同一路径继续读取。第二可组合。搜索结果、会话中的 ContextPart、记忆差异和技能引用都能共享同一种标识。第三可治理。权限、租户、移动、删除、备份与恢复可以围绕路径和范围建立一致规则。但统一 URI 不意味着三类上下文失去区别。Resource、Memory 与 Skill 仍有不同的写入主体、更新频率、可信度和权限要求。好的统一层应当统一操作语义同时保留类型差异如果把所有内容混成一个无类型的“超级知识库”反而会丢失治理所需的边界。三、L0、L1、L2真正重要的是“阅读预算”不是多做两份摘要一三层模型解决的是 Agent 的渐进式阅读OpenViking 把目录级信息处理成三个层次L0 是 Abstract默认正文上限为 256 个字符L1 是 Overview默认正文上限为 4000 个字符L2 是原始或完整解析后的文件与子目录没有统一长度限制。L0 和 L1 是目录级 sidecar而不是为每一个普通文件都生成一份对应摘要。Context Layers这一细节非常重要。三层模型不是简单地给同一文件做“短摘要、中摘要、全文”而是让目录本身拥有语义。一个目录的 L1 会汇总其中的文件摘要和子目录 L0形成导航地图L0 再从 L1 中提取最短描述供初筛与向量检索使用。于是Agent 的阅读路径从“命中 Chunk”变成“找到相关目录—理解目录范围—进入具体文件”。同一任务在不同阶段拥有不同的上下文预算。1、L0低成本的相关性信号L0 的目标不是回答问题而是让 Agent 快速判断是否值得继续。它应当像书架标签或章节导语足够短能概括主题和适用范围但不承载完整论证。大量目录都可以用很小的 Token 成本进入候选集帮助系统筛掉明显无关区域。2、L1用于计划与导航的结构化概览L1 提供更完整的范围、关键内容和快速导航。它不是最终证据而是 Agent 制定阅读计划的材料。例如一个“身份认证”目录的 L1 可以说明其中包括 OAuth、JWT 和 API Key并列出对应文件。Agent 看到任务只涉及 OAuth 时就没有必要读取另两份文档。3、L2在需要证据时读取的细节L2 保留完整内容是回答具体条款、代码行为或精确数据的证据层。Agent 应在 L0/L1 已确认相关后再读取 L2。这样做既控制 Token也减少无关细节提前干扰推理。二500 页 Policy 的价值不在“切成多少 Chunk”而在“怎样缩小阅读面”假设企业有一份 500 页政策手册。传统做法通常是分页或按标题切块生成向量后直接搜索。若用户问“新加坡团队将客户日志转交海外供应商前需要哪些审批”向量检索可能返回包含“跨境”“供应商”“日志”的若干片段但这些片段可能分布在数据分类、第三方管理、区域合规和安全例外多个章节。三层阅读则可以先在全局目录 L0 中定位“数据治理”“供应商管理”和“地区附录”再读取对应 L1 确认章节范围最后进入几条具体条款。此时系统优化的不是单个 Chunk 的相似度而是整个阅读路径的总成本和证据完整性。我们可以把它抽象为一个上下文预算问题有效上下文 与任务相关的信息量 × 证据完整度 ÷Token 成本 噪声 延迟三层模型的价值是让系统在不同阶段选择不同的信息密度。初筛阶段追求覆盖率计划阶段追求结构执行阶段追求证据。它与人类阅读长材料的方式一致先看目录和摘要再定位章节最后精读条款。三分层摘要并非没有代价1、摘要可能丢失关键限定词L0 越短越容易把“仅适用于高风险数据”“除非获得法务批准”之类的限定条件省略。因此L0 只能用于相关性判断不能直接作为事实证据。系统若把摘要当答案会把效率优化变成准确性风险。2、目录结构会影响召回路径层级检索依赖目录语义。如果导入后的结构不合理、章节被错误拆分或不同主题被塞进同一目录L0/L1 就会形成模糊导航。OpenViking 在解析阶段会按标题和 Token 长度进行智能拆分但企业仍需要对高价值知识域设计稳定的信息架构。3、异步语义生成带来新鲜度窗口OpenViking 将解析与语义生成分离Parser 不调用 LLM文件先进入存储L0/L1 和向量化由异步队列自底向上处理。这样提高了写入效率却意味着新文件在一段时间内可能已存在但尚未完整可检索。官方文档使用freshness元数据记录采样覆盖和待反映的子项变化并明确指出当前父目录刷新仍可能产生向上写放大未来需要更成熟的合并与调度策略。Context Extraction四、从 Top-K 到层级检索检索目标开始从“片段”变成“阅读路径”一OpenViking 的检索链路由三部分组成官方架构把复杂检索描述为意图分析、层级检索和 Rerank。find()面向简单查询不依赖会话上下文search()面向复杂任务会结合会话压缩摘要、最近消息和当前查询由模型生成 0 到 5 个 TypedQuery并为每个查询指定 Memory、Resource 或 Skill 类型、意图和优先级。Retrieval Mechanism复杂任务先被拆成类型化查询再沿目录递归缩小范围。1、意图分析先判断需要哪一类上下文“帮我按照我们团队的规范修改这个 API 设计”可以被拆成至少三个检索意图Resource 查询 API 设计资料Memory 查询团队偏好与既有决策Skill 查询 API Review 流程。TypedQuery 将这种跨类型需求显式化比让一个向量查询在混合语料里碰运气更可控。1.1 类型选择决定检索入口如果把团队规范误判为 Resource系统可能忽略用户或团队层面的稳定偏好如果把正式 API 标准误判为 Memory又可能让低权威经验覆盖正式规范。因此TypedQuery 不只是查询改写也是一次上下文治理决策。1.2 查询数量本身也是成本控制复杂任务可以拆成多个查询但并非越多越好。查询数增加会扩大候选集、Rerank 次数和后续阅读成本。理想的查询计划应覆盖任务所需类型同时避免把一个明确问题过度分解。更重要的是系统允许生成 0 个查询。闲聊、致谢或不需要外部信息的任务可以跳过检索避免“凡问必搜”造成延迟和无关召回。这体现了一种成熟的上下文观不检索也是上下文调度的一种决策。2、层级检索先找起点再递归进入目录系统先按 Context Type 确定根目录通过全局向量搜索寻找起始目录再使用优先队列递归搜索子项。每一轮都可以根据分数阈值决定是否继续深入并在 Top-K 多轮不变化时收敛。最终结果带有 URI、类型、是否叶子、摘要和分数。这类算法与扁平检索最大的差异是父目录相关性会影响搜索路线搜索过程本身形成可观察轨迹。当答案不理想时开发者可以检查系统从哪个根目录进入、在哪一级偏离、哪些候选被过滤而不是只看到一组无法解释的相似度分数。3、Rerank在候选范围内做更精细的判断向量检索适合快速召回Rerank 用于更精细地比较查询和候选内容。OpenViking 在 THINKING 模式下可使用配置的 Rerank 服务如果服务不可用或返回无效结果则回退到向量分数。工程上这种降级路径比“Rerank 失败即检索失败”更稳健但也意味着线上质量监控不能只看请求成功率还要区分实际使用了哪种评分路径。二Context Database 的关键指标不应只有 RecallK如果系统目标从找 Chunk 变成组织阅读路径评估指标也需要升级。1、入口准确率系统是否把任务引向正确的 Context Type 和根目录如果入口错误后续递归再精细也无法挽救。2、路径效率从查询到有效证据经过多少层、读取多少 L0/L1/L2、消耗多少 Token 与延迟同样答对问题读取 3 个目录和读取 30 个目录的系统价值不同。3、证据覆盖率最终读取的 L2 是否覆盖了回答所需的全部限定条件而不是只命中最显眼的片段多跳问题、政策问题和跨仓库问题尤其需要关注。4、可解释与可复现性给定相同版本的 Context Database 和同一查询系统能否复现相近的检索轨迹当结果错误时能否定位是解析、摘要、向量、Rerank、权限还是会话意图导致5、上下文利用率被加载的内容有多少真正影响了计划、答案或工具调用大量被召回但未使用的上下文代表隐性浪费也可能增加提示注入和信息泄露风险。五、Context Database 如何工作写入、存储与读取的完整链路一写入侧解析与语义理解被刻意分开OpenViking 的写入流程可以概括为Input → Parser → TreeBuilder → SemanticQueue → Vector Index。Parser 负责格式转换和结构化不调用 LLMTreeBuilder 把临时目录移动到内容存储并提交语义任务SemanticQueue 再异步生成目录 L1、提取 L0、写入 sidecar 并向量化。Architecture Overview快速写入与异步语义处理相分离目录语义自底向上生成。这种设计有两个优点。其一解析失败与模型调用失败被解耦系统可以更清楚地定位故障。其二大文件不必等待所有摘要与 Embedding 完成后才返回适合后台导入。但它也要求任务状态、重试、幂等和索引新鲜度成为一等公民否则用户会看到“导入成功却搜不到”的不一致体验。官方解析逻辑会根据 Token 数和标题结构拆分文档较短文档可保存为单文件较长文档按标题分段小节过短时合并过长时形成子目录。代码文件还可以先提取 imports、class、method、function 等骨架再生成摘要。其目标不是把一切切成同样大小而是尽量保留可阅读结构。二存储侧内容与索引分离URI 把二者重新绑定OpenViking 采用双层存储。AGFS/RAGFS 保存 L0、L1、L2 全文及多媒体文件Vector Index 保存 URI、向量和元数据不保存文件全文。VikingFS 位于两者上方提供统一 URI 与文件操作抽象。Storage Architecture这是一项容易被忽略的架构选择。把向量索引当作唯一数据源会让原文更新、目录移动和权限变更变得危险把文件系统当作唯一检索层又无法高效完成语义发现。OpenViking 让内容存储成为事实源向量库承担入口定位并通过 URI、parent_uri 与同步操作维持关联。这也解释了为什么它更像 Database 而不只是“带摘要的文件夹”它提供写入、读取、移动、删除、索引、事务恢复、租户隔离、加密与指标等数据系统关心的能力。文件系统是 Agent 看见的交互形态底层仍需要数据库级的一致性和可运维性。三读取侧浏览、搜索与精读形成三种不同动作在 Agent 的动作空间里ls/tree用于理解结构find/search用于语义发现abstract/overview/read用于逐层读取。这三组动作分别对应导航、定位和取证。如果 Agent 只会调用findOpenViking 很容易退化成普通向量检索如果 Agent 学会先看目录、再看概览、最后读文件层级模型才真正产生收益。因此部署 Context Database 不只是安装一个服务还需要改写 Agent 的阅读策略、提示规则和工具使用习惯。一个可执行的基本策略是简单事实查询优先find复杂任务优先search先读取候选目录 L0过滤明显无关项对高分目录读取 L1形成阅读计划只对需要验证的结论读取 L2输出中保留 URI 与证据关系记录实际使用的 Context作为会话提交与后续评估依据。六、Session 变成 Memory所谓“自进化”必须经过压缩、去重与审计一会话提交不是简单归档而是一次上下文编译OpenViking 的 Session 生命周期是 Create → Interact → Commit。会话记录文本、图片、引用的 Context 和工具调用commit()同步归档当前消息随后在后台生成结构化摘要、抽取长期记忆、更新使用计数并写入完成标记。Session Management不是所有对话都进入长期记忆候选信息需经过策略、去重与变更审计。把这一流程称为“上下文编译”更准确原始对话像高噪声源代码Session Summary 是压缩后的中间表示Memory 是供未来任务复用的长期资产memory_diff 则类似变更记录。编译过程必须保留关键意图、结果、状态和未完成事项同时丢弃寒暄、重复和临时细节。二Memory 的质量取决于更新规则而不是存储容量官方记忆抽取链路是消息经 LLM 生成候选记忆向量预筛找到相似记忆再由 LLM 决定候选是跳过、创建或不创建并对既有条目执行合并或删除。每次 commit 还会生成memory_diff.json记录新增、更新、删除与跳过原因支持审计和回滚。这一设计触及 Memory 系统最难的部分信息会变化。用户过去偏好周报用表格后来明确改为叙事摘要项目旧代号被正式名称替代一次失败经验在流程升级后不再适用。如果系统只会累计旧记忆与新记忆会同时被召回Agent 反而更加混乱。1、记忆写入需要“稳定性门槛”“今天想用深色图表”可能只是一次性要求“以后所有管理层报告都使用深色主题”才更像长期偏好。系统应结合措辞、重复出现次数、任务范围和用户确认程度决定是否写入。2、记忆读取需要“适用范围”个人写作偏好不一定适用于公司法务文件某个 Peer 的沟通习惯不应泄露给另一个 Peer。记忆必须带有用户、对象、项目、时间与场景范围不能只靠语义相似度。3、记忆更新需要“时间与权威”新信息并不自动比旧信息更可靠。系统需要判断它是明确更正、临时例外还是模糊表达。企业场景还应允许管理员或用户检查、锁定和删除关键记忆。4、记忆使用需要“可见反馈”Agent 若因某条偏好改变输出最好能说明“已参考你的 X 偏好”。这既增强用户信任也为纠错提供入口。不可见的记忆最容易成为隐性偏见。三自进化不是自动变好而是建立可验证的反馈闭环“Self-evolving” 很容易被理解为 Agent 会自行增长能力。更严谨的说法是系统把任务轨迹、结果与修正沉淀为未来可检索的 Context从而具备跨会话改进的基础。是否真的变好还取决于抽取准确率、评价信号、冲突处理、遗忘机制和召回策略。官方发布的基准显示在 LoCoMo 长对话记忆测试中接入 OpenViking 的 OpenClaw、Hermes 和 Claude Code 集成均达到约 80% 以上准确率并报告不同程度的延迟与 Token 降低在 tau2-bench 中experience memory 对零售和航空任务成功率也带来提升。Benchmark Update这些结果说明统一记忆与检索链路具有潜力但不能直接外推到所有企业任务。基准中的模型、数据、集成方式和评价协议会显著影响结果。真正的采购或落地决策仍需要使用组织自己的对话、知识库和流程做离线回放与在线 A/B 测试。七、OpenViking 与现有技术的关系不是替代一切而是把它们编排成上下文层一与 Vector Database从检索引擎上升为使用接口Vector Database 仍然是 OpenViking 的重要底座。它负责大规模语义匹配OpenViking 并没有否定向量检索。差异在于向量库通常返回相似记录而 Context Database 还需要保留目录、类型、读取层级、原始内容、会话使用轨迹和更新生命周期。因此更准确的关系是Vector DB 解决“在哪里可能相关”Context Database 解决“Agent 接下来怎样使用”。前者是检索能力后者是围绕 Agent 工作流组织数据、索引和操作的系统边界。二与 GraphRAG关系结构重要但不一定要把图作为唯一入口GraphRAG 擅长实体关系、多跳路径和全局主题总结尤其适合关系密集的知识域。OpenViking 选择文件系统层级作为主要交互模型用目录表达稳定结构用向量寻找入口。这降低了图建模成本也更符合 Agent 熟悉的ls/tree/read操作。但层级不等于关系。一个政策条款可以同时属于“地区合规”“数据安全”和“供应商管理”单一路径难以表达多重归属。OpenViking 的当前版本已经移除实验性的 Resource Relation API这提醒我们目录层级与图关系各有边界。企业若高度依赖实体关系仍可能需要在 Context Database 之上或旁边保留知识图谱能力。三与 Memory Store从“记忆条目”扩展到完整上下文生命周期传统 Memory Store 通常聚焦对话事实、偏好和相似记忆召回。OpenViking 将 Memory 与 Resource、Skill 放在同一检索计划中还把 Session 归档、记忆差异、类型策略和使用计数纳入系统。它不只是记忆数据库而是让记忆成为上下文生态中的一种数据类型。四与普通文件系统Agent 看到的是目录系统承担的是数据库责任普通文件系统具备层级、路径、移动和删除却没有自动解析、语义摘要、向量索引、层级检索和记忆抽取。OpenViking 借用了文件系统的可理解接口但在其下方增加内容存储、索引、语义队列、会话与治理能力。Context Database 更像一个组合层而不是对某一种底层技术的简单替代。能力维度传统 RAG / Vector DBMemory Store普通文件系统OpenViking Context Database主要对象文本片段与向量偏好、事实、历史文件与目录Resource、Memory、Skill语义检索强通常支持弱强且支持类型化查询层级导航通常较弱较弱强强目录具备 L0/L1 语义分层加载通常需自建较少无L0/L1/L2 原生模型会话转记忆外部实现核心能力无内建提交、抽取、去重、审计可观测路径多为 Top-K 结果视产品而定路径可见检索轨迹与 URI 可见数据治理依赖元数据与外围系统以用户范围为主权限与文件操作类型、范围、路径、事务与审计组合八、Slack 与 OpenViking从组织沟通到 Agent 可用上下文的供应链一Slack 解决“什么值得沉淀”OpenViking 解决“如何组织和按需读取”组织知识最常见的源头不是正式文档而是日常协作。项目决策、例外处理、客户反馈、负责人判断和临时修正往往先出现在 Slack、飞书或 Teams。问题在于聊天记录包含大量噪声重复讨论、未定结论、情绪表达、机器人通知和已经失效的方案。如果直接把所有消息向量化Agent 会得到一个庞大但低信噪比的“聊天沼泽”。因此Slack 与 OpenViking 的连接不应只是连接器层面的“把消息导进去”而应形成上下文供应链协作平台负责产生和筛选组织信号Context Database 负责将其转化为可寻址、分层和可治理的资产。从聊天信号到可复用 Context需要抽取、确认、归类、分层与权限治理。1、信号识别系统先识别哪些消息可能具有长期价值明确决策、政策变更、客户承诺、技术结论、复盘经验、负责人偏好和待办状态。点赞数或回复数只能作为弱信号不能代替内容判断。2、人工或规则确认高风险知识应由负责人确认。尤其是法务结论、客户承诺和安全策略不能因为某条聊天看起来权威就自动成为事实源。可以在频道中通过标签、表情或工作流按钮完成确认。3、上下文分类确认后的内容不应全部进入 Resource。正式决策和规范可成为 Resource某位负责人长期稳定的交付偏好可成为 Memory反复出现的操作流程可被整理为 Skill。分类决定后续的权限、更新方式和召回语义。4、分层组织一组讨论可以形成项目目录L0 描述“这次讨论解决了什么”L1 总结背景、参与者、决策、替代方案和待办L2 保留关键消息或正式结论链接。Agent 通常只需读取 L1只有需要审计时才进入原始对话。5、失效与回溯聊天中的结论经常被后续消息推翻。Context Database 需要记录来源时间、确认人、适用范围和替代关系并能沿 URI 回到证据。没有失效机制的自动沉淀会让组织知识越积越错。二组织上下文的真正产品形态是“可维护的判断库”文档库保存显性知识聊天平台承载过程性判断Context Database 则有机会把两者连接起来。对企业而言最稀缺的往往不是事实而是“在什么条件下采用哪个事实、谁做了取舍、为什么这样做”。如果 OpenViking 只被用来导入 PDF 和代码它会成为更好用的 RAG如果它进一步吸收经过确认的组织判断、团队偏好和执行技能它才接近真正的 Agent 上下文底座。也正是在这里Slack 之类的协作系统与 Context Database 形成互补一个捕获组织正在发生什么一个决定未来的 Agent 在何时看到多少。九、企业落地路线先构建可信上下文域再谈全域统一一第一阶段选择一个高价值、可评估的任务域不要从“接入公司所有知识”开始。更合理的起点是选择一个任务边界清晰、资料相对稳定、结果可评估的场景例如内部 API 支持、研发 RFC 辅助、客服政策问答或安全事件复盘。1、定义成功指标除了答案准确率还应记录证据命中率、读取 Token、检索延迟、错误路径、人工纠正次数和未授权召回。Context Database 的收益常体现为更少无关上下文和更短阅读路径单看最终答案可能无法解释提升来源。2、建立基线用现有 RAG 或人工流程跑同一批任务保存输入、检索结果、答案和人工评分。没有基线就无法判断分层与层级检索究竟改善了什么。二第二阶段设计 Context 信息架构先建立可信小闭环再扩展到跨域 Context Plane。1、确定范围和命名为 Resource、用户私有 Resource、Memory 和 Skill 设计清晰路径。目录应反映稳定业务边界而不是短期组织架构组织架构变化频繁用部门名做顶层路径可能带来高迁移成本。2、确定权威级别同一主题可能同时存在正式政策、工作说明、聊天讨论和个人笔记。应为内容记录来源类型、所有者、版本、有效期和权威等级。检索排序不能只看语义相关性还应考虑可信度与新鲜度。3、确定分层质量标准L0 应回答“该目录是否与任务相关”L1 应回答“这里有什么、何时使用、去哪里找细节”L2 保持可验证证据。对关键目录建立人工抽样检查避免摘要漂移。三第三阶段把检索策略嵌入 Agent 工作流只有当 Agent 真正执行渐进式阅读OpenViking 的优势才会出现。需要在系统提示、工具描述或 Skill 中明确以下行为复杂任务先分解 Context Type优先使用 L0/L1 规划关键结论必须回到 L2输出保留 URI检索失败时允许扩大范围或切换根目录不得把低权威 Memory 覆盖正式 Resource。同时应限制一次任务的最大目录展开数、L1 读取数和 L2 Token 预算。预算不是为了机械节省成本而是迫使 Agent 形成更好的信息选择行为。四第四阶段引入 Memory 与组织协作信号在 Resource 检索稳定后再逐步开启 Memory 抽取与 Slack/飞书等协作来源。Memory 是最高风险的上下文类型之一因为它会悄悄改变未来行为。建议先采用“建议写入—人工确认—有限召回”的模式再根据准确率和纠错成本提高自动化程度。五治理清单Context Database 不是无权限的公共大脑企业上线至少需要回答以下问题谁可以写入、修改和删除 Resource、Memory、Skill用户私有记忆与全局 Agent Skill 如何隔离文件移动或删除后向量索引何时完成同步L0/L1 尚未刷新时Agent 是否会读取旧概览Prompt Injection 内容进入知识库后如何标记与隔离记忆抽取使用的模型是否会接触敏感数据用户如何查看、纠正、导出与删除自己的记忆哪些检索轨迹和 memory_diff 需要进入审计日志升级版本时URI、Memory Schema 和检索行为如何回归测试OpenViking 已提供多租户、加密、事务恢复、指标和隐私配置等相关能力文档但企业是否满足特定监管要求仍取决于部署模式、密钥管理、模型供应商、网络边界和运维流程不能仅凭组件名称下结论。十、必须正视的边界Context Database 不是 Agent 的“自动真相层”一统一存储不等于统一可信Resource、Memory 和 Skill 可以共享 URI 与检索接口但它们的可信度完全不同。正式政策可能由法务批准Memory 可能来自模型抽取Skill 可能由开发者编写聊天内容可能只是未确认意见。系统必须在统一接口上保留来源、权威、时间和适用范围否则“统一”会把差异抹平。二目录不是世界的唯一结构文件系统层级简单、可解释、对 Agent 友好但现实信息经常是多对多关系。一个项目可以跨产品、地区与客户一条经验可以适用于多个 Skill一个实体可以拥有多个别名。目录适合作为主导航却不应被误认为完整知识图谱。三摘要是有损压缩不能代替证据L0/L1 的错误可能把检索引向错误目录也可能让正确目录被提前过滤。关键任务必须允许绕过摘要、扩大检索或直接读取已知 URI。对于合规、医疗、金融和安全场景摘要只能用于导航最终判断必须引用 L2 原文并保留版本。四层级检索会把信息架构质量放大扁平 RAG 的问题多表现为 Chunk 质量层级检索则把目录设计、解析策略、摘要质量和刷新机制都变成召回变量。好结构会带来显著效率坏结构也会系统性隐藏信息。企业需要把 Context Information Architecture 视为持续运营工作而不是一次性导入任务。五自进化可能演化出错误如果成功标准定义错误Agent 会把错误轨迹当成经验如果用户纠正没有进入 Memory Diff错误偏好会重复出现如果旧记忆未被删除新旧规则会发生冲突。自进化系统必须配备离线评估、人工抽查、回滚与“停止学习”开关。六项目仍处于快速演进阶段截至 2026 年 8 月 25 日GitHub Releases 标记的最新主版本为 v0.4.16项目仍在快速增加用户级 Memory Policy、异步资源导入、Context Compilation、远程 Skill 与 URI 能力同时也持续修复索引、删除和跨 Session 更新问题。OpenViking Releases快速演进意味着创新活跃也意味着接口、数据结构和行为可能变化。生产环境应固定版本、保存备份、建立升级回归集并避免把实验能力直接当成不可替代的核心依赖。十一、OpenViking 代表的更大趋势Agent 基础设施正在出现“上下文平面”一从数据平面、控制平面到上下文平面云基础设施用控制平面管理资源状态用数据平面承载实际流量。Agent 系统也正在出现类似分层模型和工具负责推理与执行Context Plane 负责组织 Agent 在每一步可见的信息、规则、经验与能力。这个上下文平面至少需要五种能力统一寻址、语义与结构化发现、渐进式读取、生命周期管理、可观察与可治理。OpenViking 把这些能力组合成数据库形态说明行业正在从“为每个 Agent 拼一个 RAG”走向“为整个 Agent 体系建设共享上下文基础设施”。二Context Engineering 将从 Prompt 技巧变成数据工程早期 Context Engineering 常被理解为写好系统提示、选择示例和拼接检索结果。随着 Agent 长期运行并进入组织核心流程它将越来越像数据工程需要采集、清洗、分层、索引、版本、权限、质量监控和成本优化。这也会催生新的角色与指标。团队可能需要 Context Architect 设计目录与类型Context Curator 维护高价值资料Memory Policy Owner 定义可学习范围Context SRE 监控导入任务、索引新鲜度和检索回退。所谓“上下文数据库”不仅是产品类别也是组织能力的重新分工。三未来竞争点不是“谁存得更多”而是“谁调度得更准”当知识、日志、对话和技能都能低成本接入后数据量不再是唯一壁垒。真正的差异将来自系统能否判断当前任务需要哪些 Context Type能否在低成本摘要与高保真证据间动态切换能否根据权限和权威过滤能否将任务结果安全地回流为新上下文。从这个角度看OpenViking 最有启发性的地方不是viking://的命名也不是三层摘要本身而是它把“给模型什么”提升为一个可独立设计、运行和评估的数据库问题。十二、结语从“检索相似内容”走向“编排可用认知”OpenViking 给 Agent 工程提供了一个清晰的新问题框架。传统 RAG 关注哪些 Chunk 最相似Context Database 关注当前任务需要哪些知识、记忆与技能它们应从哪个范围被发现以什么粒度进入模型使用后是否应该沉淀以及整个过程能否被解释和治理。L0、L1、L2 的意义也因此超越了摘要技术它们是一套阅读预算机制。viking://不只是路径格式而是统一上下文的逻辑坐标系。Session Commit 不只是归档而是把高噪声交互编译为长期记忆的入口。层级检索不只是换一种搜索算法而是把答案追踪到目录、来源和阅读路径。但必须保持克制。Context Database 不能自动保证事实正确统一接口不能消除权限与权威差异自进化也不会天然朝正确方向发展。真正成熟的系统需要把摘要当导航、把原文当证据、把 Memory 当可纠正的假设、把 Skill 当受版本控制的执行约束。如果说 Slack 等协作平台解决了“组织中哪些信息值得成为 Context”那么 OpenViking 试图解决的是“这些 Context 如何被组织、发现、按需加载并进入下一次行动”。两者连接起来才可能形成企业 Agent 的长期认知供应链。一句话概括OpenViking 不是把 Memory、Knowledge 和 Skill 简单塞进同一个库而是在尝试建立 Agent 的 Context Plane让上下文成为可寻址、可分层、可检索、可更新、可观察和可治理的数据。可参考的文章与资料OpenViking GitHub 仓库与 READMEOpenViking Architecture OverviewContext TypesResource、Memory 与 SkillContext LayersL0、L1、L2Viking URI 规范Storage Architecture内容与索引分离Context Extraction解析与语义生成Retrieval Mechanism意图分析、层级检索与 RerankSession Management会话压缩与 Memory 提取OpenVikingThe Database Paradigm for Context EngineeringOpenViking Benchmark UpdateVikingMem: A Memory Base Management System for Stateful LLM-based ApplicationsOpenViking Releases