OpenViking 如何组织检索与复用 Agent 上下文

一个研发助手排查接口故障时，可能同时需要产品文档、代码仓库、用户的部署约束，以及上一次排障留下的经验。检索到一段语义相似的文字，只完成了其中一步。它还需要确定材料属于哪个项目和版本，决定读取摘要还是原文，并辨别哪些历史结论仍然适用。

OpenViking 将 Resource、Memory 和 Skill 纳入统一的上下文管理机制，提供目录组织、语义检索和分层读取能力。它所回应的痛点，是 Agent 在多来源、长周期任务中难以持续获得合适的上下文。

企业 Agent 的上下文通常散落在几个地方：知识库保存业务资料，聊天记录保存用户要求，项目目录保存工作文件，技能文件描述操作方法。随着任务变长，系统需要反复回答三个问题：材料在哪里，当前需要读多少，过去的经验能否继续使用。

例如，用户要求“沿用上次的部署限制，排查新版本的鉴权问题”。这里既有需要跨会话保留的限制，也有只对本次任务有效的版本信息。把两者都作为普通文本召回，容易出现旧结论覆盖新证据、通用文档混入项目特例，以及大量无关原文占用上下文的问题。这个场景说明，检索质量还取决于材料的归属、时效和用途。

因此，评估 OpenViking 时，应关注四个维度：能否找到正确材料、读取成本是否可控、历史经验是否可靠、错误能否定位和修正。单次相似度分数无法覆盖这些要求。

统一入口保留不同用途

OpenViking 用 viking:// URI 标识上下文，使 Agent 可以通过 ls、tree、read 等接口浏览和读取材料。三类上下文共享访问方式，但各自承担不同职责。

这样的统一有一个直接价值：同一项任务可以同时寻找“应该参考什么”“需要遵守什么约束”和“应该怎样操作”。Skill 被检索出来之后，仍需要 Agent 或上层运行框架解释其内容并执行相应工具；上下文数据库提供的是管理与访问能力。

内容和索引分开承担职责

在存储层，VikingFS 提供 URI 与目录访问抽象，AGFS 承担文件内容存储，向量索引用于查找候选。索引保存向量、URI 和用于过滤或展示的元数据，原始文件由内容存储层提供。文件系统式接口与向量检索因此可以同时存在。

对接已有知识库时，需要确认文档如何导入、怎样保留版本和章节关系，以及更新后如何维护摘要与索引。仅接入一个现有向量库，并不会自动补齐这些上下文组织工作。

L0 L1 L2 控制读取深度

当前文档明确指出，L0/L1 主要是目录级附属文件，并不为每个普通文件都生成一套独立摘要。文件摘要可参与所在目录的概览生成，子目录摘要再汇入上层。L2 保留需要进一步读取的具体内容。

这使 Agent 可以先判断范围，再读取细节。例如，先查看鉴权目录概览，再打开与当前版本有关的配置和故障说明。只有当调用方确实限制展开范围时，分层才会减少进入模型的无关内容；将所有命中的 L2 全部拼接，仍然可能产生很大的输入开销。

摘要也有维护成本。官方实现说明，大目录的语义生成可能采用抽样，子项更新与父目录摘要刷新之间也可能存在时间差。对频繁变化的项目，应同时关注摘要覆盖范围和更新状态。

先区分查询规划和候选检索

理解 OpenViking 时，容易把“使用 search 接口”“进行意图分析”和“执行目录递归”混为一谈。当前源码将它们分开处理：find 明确使用 QUICK 模式；search 在具有有效会话上下文且启用意图分析时，可以生成带类型的查询，随后再交给检索器。

QUICK 路径在指定范围内检索候选，经阈值过滤和去重后返回；THINKING 路径进一步采用目录起点、递归展开与重排。实际是否走目录递归，需要核对调用路径和配置。接口名称本身不足以说明执行过程。

多个起点共同参与有限搜索

在目录递归路径中，系统先对目录级语义表示进行全局检索，再把命中目录与搜索根目录合并为起点。多个起点进入同一个优先队列，相关性较高的目录优先展开；搜索过程可以在不同分支之间切换。

展开某个目录时，系统检索其直接子项。满足条件的结果进入候选池，目录可以继续入队，L2 文件作为终点候选。这个过程并不意味着模型此时已经读过全部原文：返回的 URI 和预览，与后续按需读取 L2，是不同操作。

去重也分不同位置处理。起点合并会去重；目录弹出时通过 visited 避免重复展开；结果池按 URI 保留较高分的候选。因此，“一个目录只展开一次”并不意味着优先队列里从未出现过重复项。

除队列耗尽外，Top-K 集合稳定或候选池停滞的计数也会触发停止，当前阈值为 3 轮。这是控制搜索开销的启发式条件，不能保证已经找到整个搜索空间中的全局最优结果。

另一个容易被概念图掩盖的细节是分数传播。实现支持混合子项分数与父目录分数，但当前 score_propagation_alpha 默认值为 1.0，意味着默认只使用子项自身分数。目录结构仍然影响搜索范围和顺序，父目录高分却不会因此自动抬高子项分数。

Dense、Sparse、Rerank 与目录层次承担的工作也不同：向量表示帮助匹配候选，目录约束控制范围，重排调整已有候选的相关性顺序。稀疏向量是否实际参与，需要结合所选 embedding 与后端确认；“支持混合检索”不能直接解释某次运行的效果。

判断一 目录设计已经是检索策略的一部分

假设鉴权规则分散在产品文档、网关代码和历史故障记录中。多个全局起点有助于找到不同分支，但如果某个目录摘要遗漏了关键概念，或者资料版本关系没有保留，该分支就可能在有限搜索中被忽略。对根本没有进入候选集的证据，后续重排没有机会纠正。

因此，目录应尽量贴近实际任务的项目、版本和模块边界；摘要应交代适用范围与关键限制。排查漏召回时，建议先看目标 URI 是否进入候选、所在目录是否被展开，再判断是否需要更换 embedding 或 rerank 模型。这样才能区分组织问题、召回问题与排序问题。

从会话记录到可复用信息

会话记录保存了交互过程，长期记忆则服务于未来交互。OpenViking 的 commit 流程先完成会话归档，再在后台生成摘要、抽取记忆并记录变化。提交被接受后，仍需关注后台任务是否完成。

当前记忆更新实现包含一个可使用工具的抽取循环：获取已有记忆上下文后，模型可以继续查找和读取，再输出更新操作，由执行器落到存储中。这让新增信息有机会与已有内容合并、修正或建立关联。

但重复信息判断和事实冲突判断是不同问题。“上次部署使用版本 A”和“当前部署使用版本 B”可能同时成立；如果只保留一句没有时间和环境条件的经验，就会把正常变化误判为冲突。我们的建议是让高价值记忆保留来源、时间、适用条件与结果状态，并把尚未验证的推断单独标明。

链接与反向链接可以帮助组织关联。当前实现将 links 写入起点文件，将 backlinks 写入终点文件；这些关联有利于追踪上下文，但并不自动保证每次检索都会沿所有关联展开。是否需要继续读取关联材料，仍取决于具体检索与 Agent 行为。

跨会话召回需要区分三种需求

Session A 能够召回 Session B 形成的长期记忆，前提是这些记忆已经完成写入和索引，并处在 A 的身份与查询范围内。这里的“全局”始终受到租户、用户和授权范围约束。

对于 Session B 的 messages.jsonl 原文，应采用另一种判断方式。当前标准会话流程保存消息和归档，而重建索引实现明确跳过会话路径。因此，仅凭会话文件存在，不能断言普通 find/search 就能语义召回它。有权限时可以通过会话接口或文件读取访问；若产品需要按语义追查历史原话，应另行设计会话索引或把选定记录纳入可检索资源。

判断二 经验复用与任务恢复需要分别验证

以中断后继续排障为例，“检查过代理配置”是一条经验性记录，但接续任务还需要知道检查了哪台机器、使用了哪个配置版本、命令是否成功，以及修改是否已经写入。摘要保留下来的概念可以正确，实际工作状态仍可能缺失。

因此，面向长程任务的产品应保留可恢复的检查点：任务标识、已完成动作、失败证据、待办项、产物位置和外部状态。OpenViking 可以承担其中的上下文管理工作，接入方还应验证恢复协议是否完整，避免把一次记忆问答测试当作任务接续能力的证明。

OpenViking 团队在 2026 年 5 月 29 日发布的报告覆盖用户记忆、Agent 经验和知识库问答。以下摘取 HotpotQA 的结果，保留报告中的 Accuracy 与 Tokens / QA 口径。

数据来源：OpenViking 官方公开评测。表中 token 为报告的单问答口径，不能直接视为包含摄取、维护与重试的系统总成本。

按上述数值计算，top-5 提高到 top-20，Accuracy 增加 18.25 个百分点，Tokens / QA 增至约 3.97 倍。这组结果说明，召回更多内容可以换取更高成绩，同时也会增加上下文开销。“按需加载”提供了调节空间，最终取舍仍由配置和任务决定。

同一报告中，加入经验记忆后，tau2-bench 的 Retail 成绩从 70.94% 增至 77.81%，Airline 从 54.38% 增至 66.25%。这些结果支持在重复任务中测试经验复用的价值。这里使用的是 tau2-bench，不能直接与其他任务集或 tau3 的结果拼接比较。

从这些系统级结果中，仍无法单独归因出目录递归、记忆抽取或模型选择各自贡献了多少收益。官方 RAG 评估框架也将检索、生成和评判作为不同环节，并区分 Recall、F1 与经评判得到的 Accuracy；迁移到业务场景时，应明确评价对象和计算口径。

我们的判断是，公开成绩足以支持开展针对性的试点；是否值得长期运行，要看实际任务中正确证据的覆盖率、失败率和每个成功任务的总成本。尤其是低频知识库，摘要生成与维护开销可能很难被有限的查询次数摊薄。

先选择能够体现结构和复用价值的任务

值得优先验证的场景包括：多版本产品资料问答、跨文档研发排障，以及需要长期保留用户约束的业务助手。这些场景中，材料有较明确的归属，任务也存在重复使用上下文的机会。若业务只有小规模、低频、单轮 FAQ，应先确认统一管理层能带来什么额外收益。

如果主要需求是对历史原话逐条追溯，试点重点应放在会话归档与检索入口；如果主要需求是中断后继续工作，重点应放在检查点恢复。场景选错，即使平均问答成绩提高，也可能没有解决原来的业务痛点。

用一个项目完成首轮对照

建议先选一个真实项目，准备 40 至 60 条经人工核对的任务，覆盖单文档事实、跨目录证据、版本变更和跨会话接续四类问题。每条任务标注正确证据及适用版本；恢复类任务另外标注应接续的状态。这是用于试点的建议规模，需要根据业务差异继续扩充。

保持生成模型、embedding、提示词、任务集和输入预算一致，先比较现有方案与 OpenViking 接入方案；再分别改变是否使用目录递归、是否启用记忆及摘要读取策略。已有记忆应来自独立历史任务，避免把评测答案提前写入记忆。测试结束后保留失败样例和检索轨迹，检查变化发生在哪个环节。

成本统计应包括资料摄取、摘要生成、向量化、查询规划、重排、答案生成和失败重试。长期记忆的维护成本应在实际复用次数上摊销，同时观察用户少重复了多少说明、任务少走了多少无效步骤。

扩大接入范围的条件，应由业务验收标准决定：正确证据更容易被找到，旧信息能够被修正，任务成功率提高，并且总体投入可接受。对 OpenViking 而言，最有价值的下一步，是在一个有明确资料边界和重复任务的项目里，把这些收益与代价测清楚。

参考文献

1. OpenViking docs
2. OpenViking Team — OpenViking Benchmark Update
3. OpenViking — RAG 评估框架与指标说明。