最近看 Agent 项目，常会碰到一个很难追的错误。
它记得你上周说过的偏好，也能从知识库找到项目文档，还装了一堆 Skills。你让它改一处代码，它读到了旧接口说明，带着过期约束改完，测试也许还能过。结果出了问题，排查得先从它当时看了什么开始。
这句话听上去有点绕，实际做过 Agent 工作流的人大概都见过。聊天记录会留在那里，模型也会给出一段听起来很完整的解释。可这两样东西都很难还原某一轮任务。几十份文档、几段长期记忆、几项工具说明里，哪几段被放进了上下文，哪一份资料被遗漏，为什么会漏，常常没有答案。
我把 OpenViking 的公开仓库、文档和基准说明对了一遍。它的目标很明确，想把这类零散东西收进一套“面向 AI Agent 的上下文数据库”。项目在 GitHub 上已超过 3 万 stars，支持接入 Claude Code、Codex、OpenClaw、Cursor、OpenCode 等多种 Agent。热度不能证明产品已经成熟，却至少说明很多人都碰到了同一个麻烦，Agent 能拿到的上下文越来越多，管理方式还停在临时拼接阶段。
OpenViking Studio 官方演示界面，图片来源：OpenViking GitHub 仓库。
上下文乱起来，问题不只是 token 花得多
很多团队最早注意到上下文问题，是账单变长了。
一个长期运行的 Agent 每做一步，都要把任务说明、旧对话、工具返回、文件片段、检索结果继续带在身上。上下文越长，调用成本越高，速度也会跟着掉。于是大家开始做摘要、裁剪、压缩，或者每隔一段时间重开会话。
这些办法都合理，但它们解决的是容量。真正棘手的事发生在内容层面。
假设一个 Agent 要处理线上故障。它可能需要读当前服务日志、最近发布记录、历史事故复盘、数据库变更、团队约定，还有这位用户过去对通知方式的偏好。这里面有些东西适合先看摘要，有些必须读原文，有些应该只在获得权限后读取。它们的有效期也不同。上个月的复盘有参考价值，已经废弃的配置说明却可能把排查带到沟里。
传统 RAG 很擅长从一堆文本里找相关片段。问题在于，找到一段话以后，Agent 还得知道它属于哪个项目、旁边有什么约束、有没有更近的版本、能不能把它和私人记忆一起用。向量检索返回几个片段时，这些关系很容易丢。
人类开发者不会把项目资料理解成一袋随机切片。我们打开仓库会先看目录，知道 docs/ 和 src/ 分别放什么，看到一份接口文档也会顺手找它附近的认证说明、迁移记录和更新时间。错了以后，还能回看自己究竟读过哪些文件。
Agent 也需要这种路径感。
OpenViking 把三类东西放进同一个目录
OpenViking 的做法有一点朴素。它没有让 Agent 面对一个只会返回相似度分数的黑盒，而是把资源、记忆和 Skills 都挂到 viking:// 协议下的虚拟文件系统里。
项目文档、代码仓库、网页资料可以放进 resources/。用户偏好、工作习惯、历史经验放在对应用户目录。Skills 也有自己的位置。Agent 可以用类似 ls、tree、find 的方式浏览它们，再决定往下读什么。
这件事会让人想起平时翻一个陌生仓库。你不会只看搜索框弹出的几行结果，通常会先看看目录，弄清 docs/、src/ 和配置文件分别在干什么，再去读眼前那份文档。OpenViking 希望把这种浏览顺序交给 Agent。
当上下文以目录和 URI 的方式组织，调用方能拿到比“这几段文本相似度最高”更多的信息。它知道内容来自哪类资源，挂在哪个项目下面，附近还有哪些文档，也能按目录继续向下找。检索结果因此带着出处。
OpenViking 还把每份内容加工成三层。
L0 是很短的摘要，用来判断要不要继续看。L1 给出概览，适合规划任务。L2 保留原始细节，只有确实需要时才加载。目录本身也带摘要和概览，所以 Agent 可以先在目录级别判断相关性，再进入某个文件。
这套分层并不神奇。一个人查资料时也会先扫目录、标题和摘要，找到方向后再读全文。它的价值在于把这个普通动作写进基础设施里，让每个 Agent 不必靠临时提示词猜测什么时候该读多、什么时候该停。
项目方在 README 中称，OpenViking 0.3.22 在 LoCoMo 长对话记忆和 tau2-bench 多轮 Agent 任务上做过评测。报告里列出了记忆准确率、输入 token 和查询延迟的改善。数字来自项目方，集成方式、数据集设置和对比口径都会影响结果。把它当作一个值得复现的线索比较合适，不能直接套到所有团队身上。
OpenViking 官方基准结果图，指标、测试设置与对比口径见项目的基准说明。
比起具体百分比，我更在意它把“该带什么上下文”从一次模型调用的内部细节，挪到了可以检查的系统层。
能看见检索路径，排错才有起点
OpenViking 文档里有一项功能叫 observable retrieval，也就是可观察的检索。每次查询都会留下目录浏览轨迹。结果不对时，可以回看 Agent 走过哪些路径。
可观察的检索在演示里不如“自动记住你的一切”好看，在真实工作里却很实用。
假如客服 Agent 回答错了退款规则，常见做法是继续改 prompt，或者往知识库再塞一份正确文档。下次它可能答对，也可能又抽到旧资料。旧资料为什么被召回，新的规则为什么没有排在前面，问题仍然挂着。
检索轨迹至少能把排查顺序理出来。先看它有没有进入正确目录。没进去，查索引、命名或检索条件。进了正确目录却读错文件，查摘要层。读到了正确文件仍然执行错，再去看模型理解、工具调用和工作流约束。修这几类问题的人不一样，验证方式也不一样。
这和看应用日志很像。日志不会自动修 bug，但没有日志，大家只能围着最终报错猜。上下文轨迹同样不会让 Agent 立刻可靠，它把“模型为什么这么做”的一部分过程从黑箱里拿出来。
对需要审计的团队，这件事还有另一层意义。Agent 读取私人记忆、内部文档或敏感资料时，系统至少应当留下谁在什么任务里读取了什么。很多产品把记忆功能讲得很轻松，仿佛它只是聊天体验的一个开关。数据开始进入长期存储并参与后续行动以后，读取范围、保留期限和删除记录都需要被认真对待。
记忆会长出来，过期内容也会跟着长
OpenViking 在会话结束后，允许异步提取用户偏好和 Agent 经验，写入长期记忆。这个方向很自然。每次都从零开始的 Agent 很笨，能从任务里留下经验的 Agent 更接近日常工具。
但长期记忆最容易被浪漫化。
一个 Agent 记住“用户喜欢简短回答”，通常没什么问题。它记住“这个项目永远使用某个旧接口”，就可能在数月后制造事故。更麻烦的是，记忆常常带着当时的情境。某次为了应急而跳过的流程，写进经验库以后，可能变成下一次任务的默认捷径。
因此，真正值得管理的并非只有记忆内容，还有记忆的生命周期。
一条记忆从哪里来。是谁或什么流程写进去的。它服务哪个项目。什么时候复核过。是否允许不同 Agent 读取。用户能否查看、修改和删除。项目迁移后谁负责清理。这些问题很琐碎，正因为琐碎，才容易在“先让 Agent 跑起来”的阶段被省掉。
OpenViking 用虚拟文件系统来承载记忆，至少让人有地方处理这些问题。文件和目录可以承载版本、权限和归档。产品实际能否把这些能力做扎实，还要看部署方式、集成实现和后续维护。开源仓库里能看到的接口，不等于每个接入它的团队都会配置好访问控制。
我会把它当作一个提醒。Agent 记忆除了要看召回成功率，也得允许人回头追问，这段经验是谁留下的，它现在还有效吗。
Context Engineering 终于有了更像工程的部分
Context Engineering（上下文工程）这两年很热。系统提示词怎么写，对话怎么压缩，检索结果怎么拼入模型，讨论大多落在调用前的那一小段代码里。
OpenViking 往前多走了一步。它试图把上下文本身组织成可查询、可管理的数据。
数据系统会记录来源、结构、索引、权限、版本、过期策略和查询日志。Agent 每次行动都依赖上下文，这些材料也该逐步拥有类似的管理方式。否则任务越长、工具越多，所谓记忆越容易变成没人收拾的旧聊天记录。
这也是它和 Agent Harness（智能体运行框架）之间的关系。
Harness 管 Agent 怎么行动，工具权限、失败处理、测试、人工确认和验收都在这边。Context Engineering 管 Agent 行动时能看见什么。一个约束动作，一个整理判断依据。两边都得有。权限收得再紧，Agent 还是可能读着旧资料作判断。检索做得再好，Agent 也可能没经验证就把判断执行出去。
OpenViking 更接近后面这一层。它没有替代 Harness，也没有替代模型。它尝试把模型进入行动前需要查看的材料，放到一个更可控的位置。
别急着把所有资料倒进去
看到“上下文数据库”四个字，最容易犯的错误就是把所有东西都导入。
项目文档、会议纪要、个人笔记、聊天记录、代码仓库、网页收藏，全扔进去，随后期待 Agent 自动变聪明。现实通常没有这么省心。资料越多，权限越复杂，过期内容越多，检索错误的成本也越高。
如果团队正考虑这类系统，先拿一个反复出错的场景试就够了。
内部开发助手总找错接口文档，就只放这一项目的文档、版本说明和迁移记录，规定哪些目录可读，并给关键检索留日志。跑一阵子，看看它是否少读旧版本，出错时能否定位到召回路径。结果稳定以后，再把会话记忆和跨项目资源加进来。
个人用户也一样。挑一类重复工作即可。写作素材、代码项目、客户支持都行。先想清楚希望 Agent 记住什么，也把绝不能自动记住的东西划出来。
OpenViking 目前提供开源版，也提供托管与自管方向的商业方案。仓库主项目使用 AGPLv3，部分 CLI 和示例采用其他许可。想接入生产环境的人，除了看功能，还得把许可证、数据驻留、模型提供方和运维成本一起算进去。这些问题不影响它的技术方向，却会决定它是否适合某个团队。
上下文不是越多越好。真正有用的上下文，应该在需要时能找到，在不该出现时能被挡住，出错后还找得到来路。
聊天记录当然不会消失。它仍然适合承载正在进行的对话和临时工作。但当 Agent 开始跨会话、跨项目、跨工具地工作，聊天记录不该再承担全部记忆职责。它更适合退回到会话层，把可长期使用、需要治理的内容交给更明确的系统。
OpenViking 值得观察，因为它认真处理了一个长期被忽略的问题。Agent 每次判断时依据了什么，系统该给它留一个能查到的地方。
参考来源
- OpenViking GitHub 仓库与 README
- OpenViking 官方文档
- OpenViking 上下文数据库设计说明
- OpenViking 基准结果说明
- OpenViking 的 Claude Code 集成文档
以上来源用于核对项目公开功能、发布口径和基准描述。项目方公布的性能数字仍应结合具体版本、集成方式和复现实验理解，不等同于所有环境下的独立测试结果。