OpenViking：企业 Agent 真正缺的是上下文数据库，不是更长 prompt

企业真正开始做 Agent 后，很快会发现一个比模型选择更麻烦的问题：上下文没有统一管理。用户记忆在一处，知识库在另一处，工具说明写在 prompt 里，技能散落在仓库，历史会话只能靠日志翻，检索命中错了也说不清原因。

OpenViking 的价值就在这里。它不是把 RAG 包装成聊天界面，而是把 Agent 所需的上下文抽象成 Context Database。它用类似文件系统的范式统一管理 resources、user memory、agent skills、sessions，再通过 L0/L1/L2 分层降低 token 成本，通过 MCP 暴露给外部 Agent。

企业 Agent 最缺的不是 prompt，而是上下文治理

很多团队的 Agent 原型能跑，生产却难。原因通常不是模型不会回答，而是上下文来源混乱：旧文档和新文档混在一起，不同用户共享了不该共享的记忆，工具调用失败后没有轨迹，Agent 下次任务不知道哪些经验该继承、哪些只是临时状态。

OpenViking 把这些内容放进 viking:// 命名空间：resources 管客观资料，user 管用户级数据和会话，agent 管技能和能力配置。这个设计让权限、检索、归档、迁移都更容易工程化。

L0/L1/L2 是成本控制，也是质量控制

OpenViking 的三层上下文模型非常实用。L0 是短摘要，用于快速过滤；L1 是导航摘要，用于判断是否进入详情；L2 是原文详情，只有必要时才加载。相比把所有 chunk 扔进向量库，这套机制更适合长文档和长期任务。

在企业知识库里，很多错误来自“读了相似但不该读的内容”。L1 作为导航层，可以告诉 Agent 某个目录包含哪些章节、哪些信息已过期、该从哪里读取全文。它实际上把检索从盲目相似度，推进到带结构的上下文浏览。

落地方式：先做一个项目级上下文库

最稳的落地不是全公司一把梭，而是选择一个项目：导入架构文档、API、运行手册、事故复盘、常见问题、部署约束。路径类似：

viking://resources/payments/
viking://resources/payments/api/
viking://resources/payments/runbooks/
viking://resources/payments/incidents/

然后把 Agent 的规则和能力分开放：

viking://agent/skills/release-checklist
viking://agent/skills/incident-triage
viking://user/memories/preferences/engineering

这样 Agent 处理发布、排障、文档问答时，可以先检索项目上下文，再决定是否读取全文或调用工具。

部署和安全边界

试用可用 Docker：挂载 ~/.openviking，开放 1933，访问 /health 和 /studio。生产环境必须启用 API key 或 OAuth，MCP endpoint 不能裸露公网。OpenViking 支持 API key header，也支持 Claude Desktop/Claude.ai 所需的 OAuth 2.1 路线。

上下文数据库一旦接入 Agent，就等同于保存了企业知识、用户偏好和操作轨迹。备份、权限、审计、删除策略都要提前设计。

结论

OpenViking 值得关注，不是因为它又发明了一种 RAG，而是因为它把 Agent 的上下文治理变成了独立基础设施。未来真正能长期工作的 Agent，不会只依赖更长上下文窗口，而会依赖可组织、可检索、可观测、可授权的上下文数据库。