OpenViking：让研发上下文在不同 Agent 与工具之间持续在线
换工具、换模型或换 Agent 时，研发团队最容易丢失的不是代码，而是上下文：项目背景、历史决策、工具能力、失败经验和个人工作习惯。OpenViking 的公开介绍将资源、记忆和技能放进统一的上下文文件系统，目标是让这些内容可以跨工具复用，而不是绑定在某个聊天窗口里。
本文根据字节跳动技术团队《换工具、换 Agent，不换上下文：OpenViking 让研发 Context 始终在线》的周刊摘要整理。摘要明确提到 L0/L1/L2 分层加载、会话结束后的长期记忆提取和检索轨迹保留；本文补充的是通用 Context Engineering 解释，不代表对 OpenViking 内部实现的完整复刻。
一、统一组织三类上下文
| 类型 | 解决的问题 | 典型内容 |
|---|---|---|
| Resource | 项目和外部资料在哪里 | 文档、代码、网页、数据、图片 |
| Memory | Agent 过去知道什么 | 决策、偏好、事件、经验和失败记录 |
| Skill | Agent 应该怎样做 | 工作流、脚本、规则和验证方法 |
将三者分开很重要。资源是被读取的对象，记忆是经过筛选的长期信息，技能是可执行的方法。把所有内容都当作聊天历史，会导致检索、权限、更新和过期管理混在一起。
二、L0、L1、L2 为什么能降低上下文浪费
完整文档一开始不应全部塞入模型上下文。分层加载可以理解为：
L0：极短摘要，先判断是否相关
→ L1：目录或主题概览，决定读取哪些部分
→ L2：完整细节，只在需要时加载
这不是简单的摘要压缩，而是把“是否值得读取”提前到低成本层。一个大型代码库、长篇设计文档或技能目录，如果每次都加载全文，成本和噪声都会快速增长。
三、跨 Agent 复用上下文的前提
上下文要跨工具复用，至少需要：
- 稳定的 URI、路径或资源 ID；
- 明确的资源类型与来源；
- 内容版本和更新时间；
- 访问权限和敏感级别；
- 摘要到详情的可追溯关系；
- 检索命中原因和读取记录。
否则“统一上下文”只会变成另一个无法解释的黑盒搜索框。
四、会话结束后为什么要提取长期记忆
不是所有会话内容都值得保存。建议只沉淀：
- 已确认的决策；
- 可复用的解决方案；
- 反复出现的项目事实；
- 对未来任务有影响的失败经验；
- 用户明确要求保留的偏好或约束。
临时猜测、未验证的建议、一次性输出和包含秘密的日志不应自动进入长期记忆。记忆写入需要来源、时间、置信度和撤销方式。
五、检索轨迹比“命中结果”更重要
当 Agent 给出一个结论时，团队需要知道它为什么看到了某段上下文：查询是什么、命中了哪些资源、摘要如何展开成详情、哪条规则影响了结果。保留检索轨迹可以帮助排查：
- 是知识缺失，还是检索错误；
- 是读取层级太浅，还是上下文过多；
- 是旧记忆压过了新事实，还是冲突没有治理；
- 是技能触发错误，还是任务范围写得不清。
六、在 GPT88 Agent 工作流中落地
可以把项目接入拆成四步：资源登记、摘要索引、按需展开、会话归档。模型负责理解和选择，确定性系统负责权限、版本、脱敏、删除和审计。
来源与边界
原文：字节跳动技术团队｜换工具、换 Agent，不换上下文：OpenViking 让研发 Context 始终在线。本文依据奇舞周刊第 597 期摘要整理，未取得原文全文和原文配图；OpenViking 的具体 API、协议和部署细节应以项目官方资料为准。