写技术教程最怕两件事一是概念讲得云里雾里二是代码拿回去跑不通。之前在业务里接触 Agent 开发时一直觉得上下文管理是个“玄学”——明明对话记录都在模型却总是“失忆”明明上下文窗口还有余量运行效率却直线下降。后来看到 OpenViking 这类把 Agent 上下文设计成文件系统的思路才意识到问题的本质我们一直在用“对话流”的方式管理上下文但真正需要的其实是“文件系统”式的组织能力。这篇文章就围绕 OpenViking 的核心思想展开讲清楚为什么 Agent 上下文需要文件系统抽象、它的目录结构怎么设计、读写语义怎么定义以及怎样在真实工程中落地上层。文章会给出可运行的示例代码也会把常见的坑整理成排查清单适合正在做 Agent 开发、研究 AI 编程助手上下文管理、以及想了解上下文工程Context Engineering的开发者阅读。1. 背景与核心概念1.1 Agent 上下文到底是什么我们先从最基础的问题说起Agent 上下文到底是什么从大模型应用的角度看Agent 上下文是模型在某一轮推理过程中可以访问的全部信息。它不只是用户和助手之间的聊天记录还包括系统提示词System Prompt中定义的规则、人格、工作流。用户在当前会话中提供的输入。Agent 调用工具后返回的结果。模型自己生成的中间推理过程Chain of Thought。从外部存储、数据库、知识库中检索到的片段。代码仓库中的文件内容、执行环境的状态、前端页面结构等环境信息。也就是说上下文是 Agent 的“工作台”是它思考和行动的依据。在传统软件工程里程序的状态可以通过变量、数据库、文件持久化来保存。但大模型 Agent 不一样它每一次推理都要把相关信息塞进上下文窗口。窗口越大能塞的东西越多但同时也会带来两个问题成本增加Token 越多API 调用费用越高。效果下降上下文过长时模型对中间信息的关注度会衰减出现“迷失在中间”Lost in the Middle现象。所以 Agent 上下文管理本质上是在做“如何在有限窗口内保留最有价值的信息”这件事。1.2 上下文管理的经典痛点做过 Agent 开发的读者应该都经历过下面这些场景场景一新开会话丢失记忆用户在使用一个 AI 编程助手时刚写完一段核心逻辑然后新开了一个会话结果助手完全不记得之前的代码了。原因很简单——会话结束了上下文没有持久化。这是当前很多 Agent 工具的通病。场景二上下文过大自动总结也没用对话进行了几十轮程序不断调用自动总结功能把前面的内容压缩成摘要。但总结本身也占 Token而且总结过程中可能丢失细节。最常见的结果是Context length exceeded. Please start a new conversation.有些框架里会报错比如类似 “The agent execution provider did not respond in time”本质都是上下文或者执行链路超过了处理边界。场景三上下文压缩导致信息失真自动总结确实能压缩篇幅但它不是无损的。比如前面有用户明确指定的一个技术选型“不要用 Spring Security用自研过滤器”压缩后可能就变成了“用户对权限方案有要求”细节全没了。Agent 后续的行为就会偏离用户预期。场景四多个上下文之间难以协同一个大型 Agent 项目可能包含多个子 Agent负责代码生成的、负责测试的、负责文档的。每个子 Agent 都有自己的上下文但它们之间如何共享信息目前大多数方案的答案是没有方案各自为战。这些痛点的共同根源是上下文被当作“一条流”而不是“一组有结构的数据”。1.3 为什么选择“文件系统”作为抽象文件系统File System是操作系统中用于管理持久化数据的机制。Linux、Windows、macOS 都有文件系统它们负责把数据组织成文件和目录并提供统一的访问接口。如果把 Agent 上下文比作数据那么我们很自然地会想到一个问题能不能用文件系统的方式来管理上下文OpenViking 的核心思路正是如此。它把 Agent 的上下文建模成一个虚拟文件系统上下文中的每一项信息都可以映射为一个文件或一个目录并通过路径Path来寻址。这种设计带来的价值非常明显统一寻址 所有上下文条目都有固定路径例如/memory/user_preference.md、/workspace/code/main.py。Agent 可以通过路径精准读写不需要在冗长的对话流里搜索。支持增量更新 文件系统支持按需读取。Agent 不需要把整个上下文读进来只需要读取当前任务对应的目录或文件。这天然解决了上下文过大的问题。天然持久化 文件系统本身就是持久化存储。Agent 的任务执行完上下文可以落盘Sync下次启动时自动挂载Mount会话记忆不会因为窗口关闭而消失。灵活的信息组织 目录天然支持层级分类可以把工作区、用户偏好、工具缓存、对话历史分开管理。不同的 Agent 还可以通过目录权限隔离避免互相污染。兼容现有工具链 文件系统的概念已经存在几十年开发者熟悉ls、cat、grep这些操作。如果 Agent 的上下文可以通过类文件系统接口操作那么自定义工具、脚本、CI/CD 流程都可以复用现有经验。这里需要区分一个容易混淆的概念OpenViking 不等于“把上下文保存成磁盘上的文件”。它做的是一种抽象层底层可能确实使用磁盘文件也可能使用数据库、内存或对象存储但对上层暴露的是文件系统的语义。就像 Linux 的 VFSVirtual File System一样它屏蔽了不同底层存储的差异对外提供统一的文件操作接口。2. 环境准备与版本说明2.1 运行环境本文的示例代码基于 Python 3.9 编写不依赖第三方框架核心逻辑使用标准库即可运行。操作系统方面Windows、macOS、Linux 都可以但如果你希望在本地体验“挂载目录、查看文件数”这类操作建议使用 Linux 或 macOS体验更贴近文件系统语义。依赖项Python 3.9 或更高版本。操作系统自带文件系统权限用于演示本地目录读写。如果希望接入大模型 API需要准备对应的 API Key但本文的核心示例不强制调用模型只演示上下文文件系统的构建与检索。版本说明OpenViking 目前还处于快速迭代阶段不同版本的 API 可能有差异。本文的代码以“思路 可运行示例”的方式呈现重点帮助你理解设计模式。真正接入具体项目时需要根据你使用的版本调整包名和调用方式。2.2 需要掌握的基本概念在开始写代码之前先约定几个文件系统领域的术语方便后文阅读。术语含义在上下文文件系统中的对应Mount挂载将一个文件系统连接到某个目录下加载 Agent 历史上下文到当前会话Path路径文件或目录在文件系统中的位置上下文条目的唯一地址Directory目录用于组织文件的容器上下文的分类如工作区、记忆File文件存储具体数据的单元一条具体上下文如一段对话Read读从文件获取数据将某部分上下文放入提示词Write写将数据保存到文件新增或更新上下文Sync同步将内存中的变更持久化将上下文快照写回存储Snapshot快照某一时刻的完整状态上下文版本备份理解这些概念后我们进入核心原理拆解环节。3. 核心原理拆解上下文文件系统的设计思路3.1 挂载点上下文从哪里来在 Linux 中mount命令将一个块设备或远程文件系统挂载到某个目录。在 OpenViking 的设计中挂载点就是 Agent 上下文的“根目录”。假设我们定义根目录为/ctx那么 Agent 的上下文都从这个根目录开始寻址。第一次启动时根目录可能为空如果是恢复上一次会话Agent 会从持久化存储中读取快照并恢复整个目录结构。示例流程Agent 启动。检查是否有历史快照。如果没有创建空目录树如果有从快照恢复。将工作目录挂载到/ctx/workspace。加载用户偏好到/ctx/memory/user_profile.md。加载系统提示词到/ctx/system/prompt.md。这个过程非常像 IDE 打开一个项目先恢复上次的工作区状态再加载各类配置文件。3.2 目录结构上下文的分层组织一个合理的上下文文件系统应该按“关注点”划分目录而不是按时间线平铺。下面是一棵推荐的目录树/ctx ├── system/ # 系统级上下文Agent 运行规则 │ ├── prompt.md # 主系统提示词 │ ├── tools.md # 工具描述说明 │ └── skills/ # 技能定义 │ ├── coding.md │ └── testing.md ├── memory/ # 长期记忆跨会话保留 │ ├── user_profile.md # 用户偏好与画像 │ ├── decisions.md # 项目中做过的关键决策 │ └── facts/ # 领域事实 ├── workspace/ # 当前任务工作区短期上下文 │ ├── code/ # 源代码文件 │ ├── data/ # 数据文件 │ └── output/ # 输出结果 ├── session/ # 当前会话相关的中间状态 │ ├── plan.md # 当前执行计划 │ ├── progress.md # 已完成/待办状态 │ └── cache/ # 临时缓存 └── logs/ # 运行日志与审计 ├── actions.log └── tokens.log这个设计有几点考虑system 和 memory 属于高频引用内容可以常驻上下文窗口或按需加载。workspace 属于任务相关内容任务结束后可以归档或清理。session 是易变状态每次会话都会重写。logs 用于审计和调试不参与模型推理。通过这种分层Agent 可以快速确定“当前任务需要加载哪些目录”而不是把所有内容一股脑塞进提示词。3.3 读写语义open / read / write / close文件系统最核心的操作是打开、读取、写入、关闭。OpenViking 把这种语义搬到了上下文管理中。下面是一个伪代码级的设计示例# 文件路径context_fs.py class ContextFile: def __init__(self, path: str, content: str ): self.path path self.content content self.is_open False def open(self): self.is_open True return self def read(self) - str: if not self.is_open: raise RuntimeError(File is not open) return self.content def write(self, data: str): if not self.is_open: raise RuntimeError(File is not open) self.content data def append(self, data: str): if not self.is_open: raise RuntimeError(File is not open) self.content data def close(self): self.is_open False在这个设计中open类似于把上下文文件“加载到内存”read返回内容用于拼进 Promptwrite更新内容close释放句柄。如果 Agent 只读取了几个文件那么这几个文件的内容才是本轮推理的上下文。这与传统的对话式上下文管理最大的区别在于传统方式通常会一次性把所有历史消息发送给模型而文件系统方式允许按路径精确选择要发送的内容。3.4 同步与落盘sync 的意义文件系统里有一个重要概念叫“脏页”即内存中被修改但尚未写入磁盘的数据页。sync命令的作用就是把脏页写入磁盘防止断电丢数据。上下文文件系统同样需要同步机制。Agent 在一轮推理中可能会写入很多临时信息这些信息最初保存在内存中风险是进程崩溃后所有临时上下文丢失。模型上下文窗口清理后未持久化的数据无法找回。多个 Agent 之间无法共享内存中的数据。引入sync操作后Agent 可以在关键节点主动持久化。比如每完成一个子任务执行一次sync。在调用外部工具前sync防止工具运行失败导致状态丢失。在会话结束时强制sync保存完整快照。类比 Linux VFSOpenViking 的设计可以理解成上层提供统一的sync抽象底层可能调用本地磁盘、远程存储或数据库的写入接口。这一层抽象让上下文管理变得可插拔。3.5 快照与版本回滚文件系统的另一个优势是支持快照。快照是文件系统在某个时间点的完整副本可以用来回滚。在 Agent 项目中快照的价值体现在如果 Agent 执行了一系列错误操作比如改坏了代码可以回退到执行前的上下文状态。如果自动压缩上下文时丢失了细节可以回到压缩前的快照重新压缩。如果调试时发现某个决策有误可以查看当时上下文快照来定位原因。快照不需要做完所有变更建议采用“关键节点 定期”的策略。4. 完整实战案例用文件系统管理 Agent 上下文这一节我们实现一个简化版的上下文文件系统。它包含以下能力创建目录结构和基础文件。按路径读取上下文。增量写入上下文。将内存状态同步到磁盘。创建快照。根据关键词检索上下文。代码可以独立运行不需要连接任何大模型 API。4.1 定义上下文文件系统类# 文件路径context_vfs.py import os import json import shutil from datetime import datetime from pathlib import Path class ContextFile: 上下文文件对应文件系统中的一个文件 def __init__(self, path: str, content: str ): self.path path self.content content self.is_open False def open(self): self.is_open True return self def read(self) - str: if not self.is_open: raise RuntimeError(fFile {self.path} is not open) return self.content def write(self, data: str): if not self.is_open: raise RuntimeError(fFile {self.path} is not open) self.content data def append(self, data: str): if not self.is_open: raise RuntimeError(fFile {self.path} is not open) self.content data def close(self): self.is_open False def to_dict(self): return {path: self.path, content: self.content} class ContextVFS: 简化版上下文文件系统 def __init__(self, root: str /ctx): self.root root self.files {} self.dirty set() self._init_default_tree() def _init_default_tree(self): 初始化默认目录结构 default_files { /ctx/system/prompt.md: 你是专业的技术开发助手。, /ctx/system/tools.md: 可调用工具列表代码搜索、文件读写、命令执行。, /ctx/memory/user_profile.md: 用户偏好Python 技术栈注重代码可读性。, /ctx/memory/decisions.md: 关键决策记录使用 SQLite 存储元数据。, /ctx/workspace/code/main.py: # 主程序入口\n, /ctx/session/plan.md: 当前计划实现上下文文件系统。, /ctx/session/progress.md: 已完成目录设计。\n待办编码实现。, } for path, content in default_files.items(): self.files[path] ContextFile(path, content) def open(self, path: str) - ContextFile: 打开文件如果文件不存在则创建空文件 if path not in self.files: self.files[path] ContextFile(path, ) return self.files[path].open() def read(self, path: str) - str: f self.open(path) try: return f.read() finally: f.close() def write(self, path: str, data: str): f self.open(path) try: f.write(data) self.dirty.add(path) finally: f.close() def append(self, path: str, data: str): f self.open(path) try: f.append(data) self.dirty.add(path) finally: f.close() def list_dir(self, path: str /ctx) - list: 列出某个目录下的文件与子目录 prefix path.rstrip(/) / result set() for p in self.files: if p.startswith(prefix): relative p[len(prefix):] top relative.split(/)[0] result.add(top) return sorted(result) def search(self, keyword: str) - list: 按关键词搜索上下文内容 hits [] for path, f in self.files.items(): if keyword in f.content: hits.append(path) return hits def sync(self, base_dir: str ./ctx_disk): 将内存中的上下文同步到磁盘 os.makedirs(base_dir, exist_okTrue) for path, f in self.files.items(): # 将 /ctx/system/prompt.md 转为 ./ctx_disk/system/prompt.md relative path.lstrip(/) disk_path Path(base_dir) / relative disk_path.parent.mkdir(parentsTrue, exist_okTrue) disk_path.write_text(f.content, encodingutf-8) self.dirty.clear() print(f[sync] 已同步 {len(self.files)} 个文件到 {base_dir}) def snapshot(self, snapshot_dir: str ./ctx_snapshots): 创建当前上下文快照 timestamp datetime.now().strftime(%Y%m%d_%H%M%S) target os.path.join(snapshot_dir, fsnapshot_{timestamp}) os.makedirs(target, exist_okTrue) for path, f in self.files.items(): relative path.lstrip(/) disk_path Path(target) / relative disk_path.parent.mkdir(parentsTrue, exist_okTrue) disk_path.write_text(f.content, encodingutf-8) print(f[snapshot] 快照已保存到 {target}) return target def export_meta(self, path: str ./ctx_meta.json): 将上下文元数据导出为 JSON便于其他工具消费 meta { root: self.root, file_count: len(self.files), total_chars: sum(len(f.content) for f in self.files.values()), files: [f.to_dict() for f in self.files.values()], } with open(path, w, encodingutf-8) as fp: json.dump(meta, fp, ensure_asciiFalse, indent2) print(f[meta] 元数据已导出到 {path}) if __name__ __main__: vfs ContextVFS() print( 初始目录结构 ) for item in vfs.list_dir(): print(f/ctx/{item}) print(\n 读取用户偏好 ) print(vfs.read(/ctx/memory/user_profile.md)) print(\n 追加一条执行记录 ) vfs.append(/ctx/session/progress.md, \n新增写入上下文 VFS。) print(vfs.read(/ctx/session/progress.md)) print(\n 搜索包含“文件系统”的文件 ) for hit in vfs.search(文件系统): print(hit) print(\n 同步到磁盘 ) vfs.sync() print(\n 创建快照 ) vfs.snapshot()运行这个脚本预期输出如下 初始目录结构 system memory workspace session 读取用户偏好 用户偏好Python 技术栈注重代码可读性。 追加一条执行记录 已完成目录设计。 待办编码实现。 新增写入上下文 VFS。 搜索包含“文件系统”的文件 /ctx/workspace/code/main.py /ctx/session/plan.md 同步到磁盘 [sync] 已同步 8 个文件到 ./ctx_disk 创建快照 [snapshot] 快照已保存到 ./ctx_snapshots/snapshot_20250101_1200004.2 生成 Prompt只选择必要上下文有了文件系统我们可以按需生成 Prompt。下面这个示例展示如何只选取“系统提示词 用户偏好 当前计划”三条信息来组织 Prompt而不是把整个上下文全部发送给模型。# 文件路径build_prompt.py from context_vfs import ContextVFS def build_prompt(vfs: ContextVFS, task: str) - str: sections [] system_prompt vfs.read(/ctx/system/prompt.md) sections.append(f[系统指令]\n{system_prompt}) tools vfs.read(/ctx/system/tools.md) sections.append(f[可用工具]\n{tools}) user_profile vfs.read(/ctx/memory/user_profile.md) sections.append(f[用户偏好]\n{user_profile}) plan vfs.read(/ctx/session/plan.md) sections.append(f[当前计划]\n{plan}) sections.append(f[本次任务]\n{task}) return \n\n.join(sections) if __name__ __main__: vfs ContextVFS() prompt build_prompt(vfs, 请实现一个上下文检索工具) print(prompt)执行后模型收到的上下文是高度结构化的而不是一长串无差别聊天记录。这个思路也是 AI Agent 开发中“上下文工程Context Engineering”的核心——不是把所有东西都交给模型而是精心设计交给模型的内容。4.3 上下文压缩与恢复当某个上下文文件过大比如对话历史累积到几万字我们可以对它做压缩并保留原始快照以便恢复。# 文件路径compress_context.py import re from context_vfs import ContextVFS def compress_content(content: str, max_lines: int 100) - str: 简化的上下文压缩保留头尾中间摘要化 lines content.strip().splitlines() if len(lines) max_lines: return content head lines[: max_lines // 2] tail lines[-max_lines // 2:] # 统计中间被折叠的行数 folded_count len(lines) - max_lines summary [ f\n[中间 {folded_count} 行已折叠], 摘要对话主体部分被自动压缩如需完整内容请读取原始快照。, ] return \n.join(head summary tail) if __name__ __main__: vfs ContextVFS() # 模拟一个非常大的会话日志 long_log \n.join([f第 {i} 行用户输入与模型回复的详细内容 for i in range(1, 300)]) vfs.write(/ctx/session/chat.log, long_log) # 压缩前 original vfs.read(/ctx/session/chat.log) print(f压缩前行数{len(original.splitlines())}) # 创建快照 snapshot_dir vfs.snapshot() # 压缩并写回 compressed compress_content(original, max_lines60) vfs.write(/ctx/session/chat.log, compressed) print(f压缩后行数{len(compressed.splitlines())}) # 同步到磁盘 vfs.sync()这里的关键点是压缩不是覆盖原文件而是先生成快照再写压缩版本。一旦 Agent 需要查看被折叠的细节可以从快照目录中恢复原始日志。这种“先快照、再压缩”的方式比直接在上下文窗口里强制截断要安全得多。5. 常见问题与排查思路在实现和使用上下文文件系统时会遇到下面几类典型问题。我们整理成表格方便快速定位。问题现象常见原因解决思路Agent 启动时恢复上下文失败快照目录不存在或快照文件损坏检查快照路径是否存在校验快照元数据考虑保留最近 N 份快照不同会话之间内存状态冲突多个 Agent 实例同时读写同一路径在路径上添加命名空间或会话 ID如/ctx/session/{session_id}/上下文文件越来越大长期追加日志但没有归档策略设计归档任务旧日志移入/ctx/logs/archive/主文件保持精简压缩后上下文丢失关键细节压缩策略太激进直接截断先创建快照再压缩压缩时保留头部规则和尾部最新状态Agent 读取了无用上下文导致 Token 超限Prompt 构建时没有按需选择用read精确指定文件而不是一次性读取整个目录列表同步到磁盘后元数据不一致只同步了文件内容没有同步文件索引同时导出 JSON 元数据文件如export_meta再做校验目录结构混乱开发人员看不懂没有约定目录规范在团队内统一上下文目录规范像约定代码工程结构一样约定上下文结构并发写文件时互相覆盖多个协程或 Agent 同时写入同一个文件引入文件锁或者按任务拆分到不同子目录下面单独说一下最麻烦的“上下文过大导致 Agent 报错终止”的场景。典型报错现象是Agent terminated due to error. You can prompt the model to try again or start a new conversation.这类错误通常不是因为模型能力不足而是执行链路中某一环超出了限制。排查顺序建议如下查看日志确认是上下文长度超限还是工具执行超时。如果上下文超限统计当前 Prompt 实际包含的 Token 量找出占用最大的文件。将占用大的文件拆分成多个小文件并在 Prompt 中按任务选择性加载。为历史会话开启快照然后对旧日志进行压缩归档。重跑任务观察错误是否消失。这里要强调一个原则不要等到 Agent 报错才处理上下文而是在 Agent 每轮执行结束后主动做同步和清理。文件系统的意义不在于“出了问题能修复”而在于“通过结构化管理从源头避免问题发生”。6. 最佳实践与工程建议6.1 路径命名规范上下文文件系统的路径就是上下文的“地址”命名规范非常重要。推荐以下规范目录使用小写字母多个单词用下划线连接如user_profile。文件使用小写字母和点号如prompt.md、session.log。临时文件统一放在/ctx/session/cache/不要散落在根目录。长期记忆统一放在/ctx/memory/和短期工作区严格分离。涉及多个版本的内容在文件名中标注版本号例如plan_v2.md。一个清晰的命名规范能让 Agent 在检索时更快地命中目标也能让调试时人更容易理解目录结构。6.2 按需加载而非全量加载这是上下文文件系统最核心的价值。每次构建 Prompt 之前应该先明确一个问题当前这个任务模型需要知道哪些信息通常 Agent 的任务可以拆成多个子任务每个子任务只加载自己需要的上下文目录。比如代码生成任务加载/ctx/workspace/code/、/ctx/memory/decisions.md。测试任务加载/ctx/workspace/test/、/ctx/system/tools.md。文档任务加载/ctx/workspace/docs/、/ctx/memory/user_profile.md。通过按需加载可以把原本需要 50k Token 的上下文降低到 10k 甚至更少同时模型关注度更高输出质量更好。6.3 关键节点自动同步建议在以下时机触发sync子任务完成后。调用外部工具前。从外部 API 返回结果后。Agent 会话结束前。压缩上下文之前。同步操作可能有一定的性能开销所以不需要每一条消息都同步。重点保证“关键状态不丢失”。6.4 快照策略快照是回滚的保障但不建议每次都全量快照。推荐的策略是每次会话结束时创建一次快照。执行高风险操作如修改代码、删除文件、发布配置前创建快照。设置快照保留数量比如保留最近 20 份防止磁盘膨胀。在快照目录下附带一份meta.json记录快照对应的任务和时间。6.5 安全与权限意识上下文文件系统中可能包含敏感信息比如用户密钥、数据库密码、内部 API 地址。需要注意敏感信息放在独立目录比如/ctx/secret/并在默认 Prompt 构建时排除。给不同 Agent 分配不同目录权限不要所有 Agent 共享同一份完整上下文。在日志中避免打印完整密钥脱敏后再输出。当上下文文件需要跨环境传输时先检查是否包含敏感字段。权限思维在 Agent 开发中常常被忽略。一个子 Agent 本来只应该访问测试环境的配置但如果上下文是全量共享的它就可能把生产环境的密钥也读进窗口带来安全风险。6.6 与现有 Agent 框架的集成思路OpenViking 这类上下文文件系统可以嵌入到常见的 Agent 开发框架中。一段典型的集成逻辑是# 文件路径agent_integration.py from context_vfs import ContextVFS class AgentEngine: def __init__(self): self.vfs ContextVFS() self.model_client None # 假设接入某个大模型客户端 def run_task(self, task: str): # 1. 从上下文文件系统构建 Prompt prompt self.build_prompt(task) # 2. 调用模型 response self.model_client.chat(prompt) # 3. 将模型输出写回上下文 self.vfs.append(/ctx/session/chat.log, f\n用户{task}\n助手{response}) # 4. 同步到磁盘 self.vfs.sync() return response def build_prompt(self, task: str) - str: system_prompt self.vfs.read(/ctx/system/prompt.md) plan self.vfs.read(/ctx/session/plan.md) return f{system_prompt}\n\n{plan}\n\n任务{task}这样Agent 的上下文不再是隐形的“临时变量”而是一个可以随时检查、恢复、迁移的持久化系统。7. 总结OpenViking 的核心思想并不复杂把 Agent 上下文从“对话流”变成“文件系统”。这一抽象带来了四个直接收益上下文可以按路径精确读取避免 Token 浪费上下文可以持久化同步解决新会话丢失记忆的问题上下文可以用快照回滚降低自动压缩带来的风险上下文可以分层组织支持多 Agent 协作和权限隔离。从工程角度看理解上下文文件系统本质上是在理解“上下文工程”的落地方式。无论是做 AI 编程助手还是开发通用 Agent 框架都需要认真思考一个问题模型该看到什么不该看到什么以及这些信息如何被持久化、检索、压缩和恢复。建议下一步从三个方面继续深入第一研究 Linux VFS 的实际实现理解文件系统抽象层是怎么处理性能与一致性的第二调研主流 Agent 框架如 Claude Code、各类 Agent harness是如何管理上下文的对比它们的优劣第三动手改造一个小型 Agent 项目把上下文结构调整成目录树并加上同步和快照机制。如果这篇文章对你有帮助可以收藏备用。你在做 Agent 开发时遇到过哪些上下文相关的问题欢迎在评论区分享大家一起讨论解决方案。
Agent上下文管理新思路：用文件系统抽象解决大模型“失忆”难题
写技术教程最怕两件事一是概念讲得云里雾里二是代码拿回去跑不通。之前在业务里接触 Agent 开发时一直觉得上下文管理是个“玄学”——明明对话记录都在模型却总是“失忆”明明上下文窗口还有余量运行效率却直线下降。后来看到 OpenViking 这类把 Agent 上下文设计成文件系统的思路才意识到问题的本质我们一直在用“对话流”的方式管理上下文但真正需要的其实是“文件系统”式的组织能力。这篇文章就围绕 OpenViking 的核心思想展开讲清楚为什么 Agent 上下文需要文件系统抽象、它的目录结构怎么设计、读写语义怎么定义以及怎样在真实工程中落地上层。文章会给出可运行的示例代码也会把常见的坑整理成排查清单适合正在做 Agent 开发、研究 AI 编程助手上下文管理、以及想了解上下文工程Context Engineering的开发者阅读。1. 背景与核心概念1.1 Agent 上下文到底是什么我们先从最基础的问题说起Agent 上下文到底是什么从大模型应用的角度看Agent 上下文是模型在某一轮推理过程中可以访问的全部信息。它不只是用户和助手之间的聊天记录还包括系统提示词System Prompt中定义的规则、人格、工作流。用户在当前会话中提供的输入。Agent 调用工具后返回的结果。模型自己生成的中间推理过程Chain of Thought。从外部存储、数据库、知识库中检索到的片段。代码仓库中的文件内容、执行环境的状态、前端页面结构等环境信息。也就是说上下文是 Agent 的“工作台”是它思考和行动的依据。在传统软件工程里程序的状态可以通过变量、数据库、文件持久化来保存。但大模型 Agent 不一样它每一次推理都要把相关信息塞进上下文窗口。窗口越大能塞的东西越多但同时也会带来两个问题成本增加Token 越多API 调用费用越高。效果下降上下文过长时模型对中间信息的关注度会衰减出现“迷失在中间”Lost in the Middle现象。所以 Agent 上下文管理本质上是在做“如何在有限窗口内保留最有价值的信息”这件事。1.2 上下文管理的经典痛点做过 Agent 开发的读者应该都经历过下面这些场景场景一新开会话丢失记忆用户在使用一个 AI 编程助手时刚写完一段核心逻辑然后新开了一个会话结果助手完全不记得之前的代码了。原因很简单——会话结束了上下文没有持久化。这是当前很多 Agent 工具的通病。场景二上下文过大自动总结也没用对话进行了几十轮程序不断调用自动总结功能把前面的内容压缩成摘要。但总结本身也占 Token而且总结过程中可能丢失细节。最常见的结果是Context length exceeded. Please start a new conversation.有些框架里会报错比如类似 “The agent execution provider did not respond in time”本质都是上下文或者执行链路超过了处理边界。场景三上下文压缩导致信息失真自动总结确实能压缩篇幅但它不是无损的。比如前面有用户明确指定的一个技术选型“不要用 Spring Security用自研过滤器”压缩后可能就变成了“用户对权限方案有要求”细节全没了。Agent 后续的行为就会偏离用户预期。场景四多个上下文之间难以协同一个大型 Agent 项目可能包含多个子 Agent负责代码生成的、负责测试的、负责文档的。每个子 Agent 都有自己的上下文但它们之间如何共享信息目前大多数方案的答案是没有方案各自为战。这些痛点的共同根源是上下文被当作“一条流”而不是“一组有结构的数据”。1.3 为什么选择“文件系统”作为抽象文件系统File System是操作系统中用于管理持久化数据的机制。Linux、Windows、macOS 都有文件系统它们负责把数据组织成文件和目录并提供统一的访问接口。如果把 Agent 上下文比作数据那么我们很自然地会想到一个问题能不能用文件系统的方式来管理上下文OpenViking 的核心思路正是如此。它把 Agent 的上下文建模成一个虚拟文件系统上下文中的每一项信息都可以映射为一个文件或一个目录并通过路径Path来寻址。这种设计带来的价值非常明显统一寻址 所有上下文条目都有固定路径例如/memory/user_preference.md、/workspace/code/main.py。Agent 可以通过路径精准读写不需要在冗长的对话流里搜索。支持增量更新 文件系统支持按需读取。Agent 不需要把整个上下文读进来只需要读取当前任务对应的目录或文件。这天然解决了上下文过大的问题。天然持久化 文件系统本身就是持久化存储。Agent 的任务执行完上下文可以落盘Sync下次启动时自动挂载Mount会话记忆不会因为窗口关闭而消失。灵活的信息组织 目录天然支持层级分类可以把工作区、用户偏好、工具缓存、对话历史分开管理。不同的 Agent 还可以通过目录权限隔离避免互相污染。兼容现有工具链 文件系统的概念已经存在几十年开发者熟悉ls、cat、grep这些操作。如果 Agent 的上下文可以通过类文件系统接口操作那么自定义工具、脚本、CI/CD 流程都可以复用现有经验。这里需要区分一个容易混淆的概念OpenViking 不等于“把上下文保存成磁盘上的文件”。它做的是一种抽象层底层可能确实使用磁盘文件也可能使用数据库、内存或对象存储但对上层暴露的是文件系统的语义。就像 Linux 的 VFSVirtual File System一样它屏蔽了不同底层存储的差异对外提供统一的文件操作接口。2. 环境准备与版本说明2.1 运行环境本文的示例代码基于 Python 3.9 编写不依赖第三方框架核心逻辑使用标准库即可运行。操作系统方面Windows、macOS、Linux 都可以但如果你希望在本地体验“挂载目录、查看文件数”这类操作建议使用 Linux 或 macOS体验更贴近文件系统语义。依赖项Python 3.9 或更高版本。操作系统自带文件系统权限用于演示本地目录读写。如果希望接入大模型 API需要准备对应的 API Key但本文的核心示例不强制调用模型只演示上下文文件系统的构建与检索。版本说明OpenViking 目前还处于快速迭代阶段不同版本的 API 可能有差异。本文的代码以“思路 可运行示例”的方式呈现重点帮助你理解设计模式。真正接入具体项目时需要根据你使用的版本调整包名和调用方式。2.2 需要掌握的基本概念在开始写代码之前先约定几个文件系统领域的术语方便后文阅读。术语含义在上下文文件系统中的对应Mount挂载将一个文件系统连接到某个目录下加载 Agent 历史上下文到当前会话Path路径文件或目录在文件系统中的位置上下文条目的唯一地址Directory目录用于组织文件的容器上下文的分类如工作区、记忆File文件存储具体数据的单元一条具体上下文如一段对话Read读从文件获取数据将某部分上下文放入提示词Write写将数据保存到文件新增或更新上下文Sync同步将内存中的变更持久化将上下文快照写回存储Snapshot快照某一时刻的完整状态上下文版本备份理解这些概念后我们进入核心原理拆解环节。3. 核心原理拆解上下文文件系统的设计思路3.1 挂载点上下文从哪里来在 Linux 中mount命令将一个块设备或远程文件系统挂载到某个目录。在 OpenViking 的设计中挂载点就是 Agent 上下文的“根目录”。假设我们定义根目录为/ctx那么 Agent 的上下文都从这个根目录开始寻址。第一次启动时根目录可能为空如果是恢复上一次会话Agent 会从持久化存储中读取快照并恢复整个目录结构。示例流程Agent 启动。检查是否有历史快照。如果没有创建空目录树如果有从快照恢复。将工作目录挂载到/ctx/workspace。加载用户偏好到/ctx/memory/user_profile.md。加载系统提示词到/ctx/system/prompt.md。这个过程非常像 IDE 打开一个项目先恢复上次的工作区状态再加载各类配置文件。3.2 目录结构上下文的分层组织一个合理的上下文文件系统应该按“关注点”划分目录而不是按时间线平铺。下面是一棵推荐的目录树/ctx ├── system/ # 系统级上下文Agent 运行规则 │ ├── prompt.md # 主系统提示词 │ ├── tools.md # 工具描述说明 │ └── skills/ # 技能定义 │ ├── coding.md │ └── testing.md ├── memory/ # 长期记忆跨会话保留 │ ├── user_profile.md # 用户偏好与画像 │ ├── decisions.md # 项目中做过的关键决策 │ └── facts/ # 领域事实 ├── workspace/ # 当前任务工作区短期上下文 │ ├── code/ # 源代码文件 │ ├── data/ # 数据文件 │ └── output/ # 输出结果 ├── session/ # 当前会话相关的中间状态 │ ├── plan.md # 当前执行计划 │ ├── progress.md # 已完成/待办状态 │ └── cache/ # 临时缓存 └── logs/ # 运行日志与审计 ├── actions.log └── tokens.log这个设计有几点考虑system 和 memory 属于高频引用内容可以常驻上下文窗口或按需加载。workspace 属于任务相关内容任务结束后可以归档或清理。session 是易变状态每次会话都会重写。logs 用于审计和调试不参与模型推理。通过这种分层Agent 可以快速确定“当前任务需要加载哪些目录”而不是把所有内容一股脑塞进提示词。3.3 读写语义open / read / write / close文件系统最核心的操作是打开、读取、写入、关闭。OpenViking 把这种语义搬到了上下文管理中。下面是一个伪代码级的设计示例# 文件路径context_fs.py class ContextFile: def __init__(self, path: str, content: str ): self.path path self.content content self.is_open False def open(self): self.is_open True return self def read(self) - str: if not self.is_open: raise RuntimeError(File is not open) return self.content def write(self, data: str): if not self.is_open: raise RuntimeError(File is not open) self.content data def append(self, data: str): if not self.is_open: raise RuntimeError(File is not open) self.content data def close(self): self.is_open False在这个设计中open类似于把上下文文件“加载到内存”read返回内容用于拼进 Promptwrite更新内容close释放句柄。如果 Agent 只读取了几个文件那么这几个文件的内容才是本轮推理的上下文。这与传统的对话式上下文管理最大的区别在于传统方式通常会一次性把所有历史消息发送给模型而文件系统方式允许按路径精确选择要发送的内容。3.4 同步与落盘sync 的意义文件系统里有一个重要概念叫“脏页”即内存中被修改但尚未写入磁盘的数据页。sync命令的作用就是把脏页写入磁盘防止断电丢数据。上下文文件系统同样需要同步机制。Agent 在一轮推理中可能会写入很多临时信息这些信息最初保存在内存中风险是进程崩溃后所有临时上下文丢失。模型上下文窗口清理后未持久化的数据无法找回。多个 Agent 之间无法共享内存中的数据。引入sync操作后Agent 可以在关键节点主动持久化。比如每完成一个子任务执行一次sync。在调用外部工具前sync防止工具运行失败导致状态丢失。在会话结束时强制sync保存完整快照。类比 Linux VFSOpenViking 的设计可以理解成上层提供统一的sync抽象底层可能调用本地磁盘、远程存储或数据库的写入接口。这一层抽象让上下文管理变得可插拔。3.5 快照与版本回滚文件系统的另一个优势是支持快照。快照是文件系统在某个时间点的完整副本可以用来回滚。在 Agent 项目中快照的价值体现在如果 Agent 执行了一系列错误操作比如改坏了代码可以回退到执行前的上下文状态。如果自动压缩上下文时丢失了细节可以回到压缩前的快照重新压缩。如果调试时发现某个决策有误可以查看当时上下文快照来定位原因。快照不需要做完所有变更建议采用“关键节点 定期”的策略。4. 完整实战案例用文件系统管理 Agent 上下文这一节我们实现一个简化版的上下文文件系统。它包含以下能力创建目录结构和基础文件。按路径读取上下文。增量写入上下文。将内存状态同步到磁盘。创建快照。根据关键词检索上下文。代码可以独立运行不需要连接任何大模型 API。4.1 定义上下文文件系统类# 文件路径context_vfs.py import os import json import shutil from datetime import datetime from pathlib import Path class ContextFile: 上下文文件对应文件系统中的一个文件 def __init__(self, path: str, content: str ): self.path path self.content content self.is_open False def open(self): self.is_open True return self def read(self) - str: if not self.is_open: raise RuntimeError(fFile {self.path} is not open) return self.content def write(self, data: str): if not self.is_open: raise RuntimeError(fFile {self.path} is not open) self.content data def append(self, data: str): if not self.is_open: raise RuntimeError(fFile {self.path} is not open) self.content data def close(self): self.is_open False def to_dict(self): return {path: self.path, content: self.content} class ContextVFS: 简化版上下文文件系统 def __init__(self, root: str /ctx): self.root root self.files {} self.dirty set() self._init_default_tree() def _init_default_tree(self): 初始化默认目录结构 default_files { /ctx/system/prompt.md: 你是专业的技术开发助手。, /ctx/system/tools.md: 可调用工具列表代码搜索、文件读写、命令执行。, /ctx/memory/user_profile.md: 用户偏好Python 技术栈注重代码可读性。, /ctx/memory/decisions.md: 关键决策记录使用 SQLite 存储元数据。, /ctx/workspace/code/main.py: # 主程序入口\n, /ctx/session/plan.md: 当前计划实现上下文文件系统。, /ctx/session/progress.md: 已完成目录设计。\n待办编码实现。, } for path, content in default_files.items(): self.files[path] ContextFile(path, content) def open(self, path: str) - ContextFile: 打开文件如果文件不存在则创建空文件 if path not in self.files: self.files[path] ContextFile(path, ) return self.files[path].open() def read(self, path: str) - str: f self.open(path) try: return f.read() finally: f.close() def write(self, path: str, data: str): f self.open(path) try: f.write(data) self.dirty.add(path) finally: f.close() def append(self, path: str, data: str): f self.open(path) try: f.append(data) self.dirty.add(path) finally: f.close() def list_dir(self, path: str /ctx) - list: 列出某个目录下的文件与子目录 prefix path.rstrip(/) / result set() for p in self.files: if p.startswith(prefix): relative p[len(prefix):] top relative.split(/)[0] result.add(top) return sorted(result) def search(self, keyword: str) - list: 按关键词搜索上下文内容 hits [] for path, f in self.files.items(): if keyword in f.content: hits.append(path) return hits def sync(self, base_dir: str ./ctx_disk): 将内存中的上下文同步到磁盘 os.makedirs(base_dir, exist_okTrue) for path, f in self.files.items(): # 将 /ctx/system/prompt.md 转为 ./ctx_disk/system/prompt.md relative path.lstrip(/) disk_path Path(base_dir) / relative disk_path.parent.mkdir(parentsTrue, exist_okTrue) disk_path.write_text(f.content, encodingutf-8) self.dirty.clear() print(f[sync] 已同步 {len(self.files)} 个文件到 {base_dir}) def snapshot(self, snapshot_dir: str ./ctx_snapshots): 创建当前上下文快照 timestamp datetime.now().strftime(%Y%m%d_%H%M%S) target os.path.join(snapshot_dir, fsnapshot_{timestamp}) os.makedirs(target, exist_okTrue) for path, f in self.files.items(): relative path.lstrip(/) disk_path Path(target) / relative disk_path.parent.mkdir(parentsTrue, exist_okTrue) disk_path.write_text(f.content, encodingutf-8) print(f[snapshot] 快照已保存到 {target}) return target def export_meta(self, path: str ./ctx_meta.json): 将上下文元数据导出为 JSON便于其他工具消费 meta { root: self.root, file_count: len(self.files), total_chars: sum(len(f.content) for f in self.files.values()), files: [f.to_dict() for f in self.files.values()], } with open(path, w, encodingutf-8) as fp: json.dump(meta, fp, ensure_asciiFalse, indent2) print(f[meta] 元数据已导出到 {path}) if __name__ __main__: vfs ContextVFS() print( 初始目录结构 ) for item in vfs.list_dir(): print(f/ctx/{item}) print(\n 读取用户偏好 ) print(vfs.read(/ctx/memory/user_profile.md)) print(\n 追加一条执行记录 ) vfs.append(/ctx/session/progress.md, \n新增写入上下文 VFS。) print(vfs.read(/ctx/session/progress.md)) print(\n 搜索包含“文件系统”的文件 ) for hit in vfs.search(文件系统): print(hit) print(\n 同步到磁盘 ) vfs.sync() print(\n 创建快照 ) vfs.snapshot()运行这个脚本预期输出如下 初始目录结构 system memory workspace session 读取用户偏好 用户偏好Python 技术栈注重代码可读性。 追加一条执行记录 已完成目录设计。 待办编码实现。 新增写入上下文 VFS。 搜索包含“文件系统”的文件 /ctx/workspace/code/main.py /ctx/session/plan.md 同步到磁盘 [sync] 已同步 8 个文件到 ./ctx_disk 创建快照 [snapshot] 快照已保存到 ./ctx_snapshots/snapshot_20250101_1200004.2 生成 Prompt只选择必要上下文有了文件系统我们可以按需生成 Prompt。下面这个示例展示如何只选取“系统提示词 用户偏好 当前计划”三条信息来组织 Prompt而不是把整个上下文全部发送给模型。# 文件路径build_prompt.py from context_vfs import ContextVFS def build_prompt(vfs: ContextVFS, task: str) - str: sections [] system_prompt vfs.read(/ctx/system/prompt.md) sections.append(f[系统指令]\n{system_prompt}) tools vfs.read(/ctx/system/tools.md) sections.append(f[可用工具]\n{tools}) user_profile vfs.read(/ctx/memory/user_profile.md) sections.append(f[用户偏好]\n{user_profile}) plan vfs.read(/ctx/session/plan.md) sections.append(f[当前计划]\n{plan}) sections.append(f[本次任务]\n{task}) return \n\n.join(sections) if __name__ __main__: vfs ContextVFS() prompt build_prompt(vfs, 请实现一个上下文检索工具) print(prompt)执行后模型收到的上下文是高度结构化的而不是一长串无差别聊天记录。这个思路也是 AI Agent 开发中“上下文工程Context Engineering”的核心——不是把所有东西都交给模型而是精心设计交给模型的内容。4.3 上下文压缩与恢复当某个上下文文件过大比如对话历史累积到几万字我们可以对它做压缩并保留原始快照以便恢复。# 文件路径compress_context.py import re from context_vfs import ContextVFS def compress_content(content: str, max_lines: int 100) - str: 简化的上下文压缩保留头尾中间摘要化 lines content.strip().splitlines() if len(lines) max_lines: return content head lines[: max_lines // 2] tail lines[-max_lines // 2:] # 统计中间被折叠的行数 folded_count len(lines) - max_lines summary [ f\n[中间 {folded_count} 行已折叠], 摘要对话主体部分被自动压缩如需完整内容请读取原始快照。, ] return \n.join(head summary tail) if __name__ __main__: vfs ContextVFS() # 模拟一个非常大的会话日志 long_log \n.join([f第 {i} 行用户输入与模型回复的详细内容 for i in range(1, 300)]) vfs.write(/ctx/session/chat.log, long_log) # 压缩前 original vfs.read(/ctx/session/chat.log) print(f压缩前行数{len(original.splitlines())}) # 创建快照 snapshot_dir vfs.snapshot() # 压缩并写回 compressed compress_content(original, max_lines60) vfs.write(/ctx/session/chat.log, compressed) print(f压缩后行数{len(compressed.splitlines())}) # 同步到磁盘 vfs.sync()这里的关键点是压缩不是覆盖原文件而是先生成快照再写压缩版本。一旦 Agent 需要查看被折叠的细节可以从快照目录中恢复原始日志。这种“先快照、再压缩”的方式比直接在上下文窗口里强制截断要安全得多。5. 常见问题与排查思路在实现和使用上下文文件系统时会遇到下面几类典型问题。我们整理成表格方便快速定位。问题现象常见原因解决思路Agent 启动时恢复上下文失败快照目录不存在或快照文件损坏检查快照路径是否存在校验快照元数据考虑保留最近 N 份快照不同会话之间内存状态冲突多个 Agent 实例同时读写同一路径在路径上添加命名空间或会话 ID如/ctx/session/{session_id}/上下文文件越来越大长期追加日志但没有归档策略设计归档任务旧日志移入/ctx/logs/archive/主文件保持精简压缩后上下文丢失关键细节压缩策略太激进直接截断先创建快照再压缩压缩时保留头部规则和尾部最新状态Agent 读取了无用上下文导致 Token 超限Prompt 构建时没有按需选择用read精确指定文件而不是一次性读取整个目录列表同步到磁盘后元数据不一致只同步了文件内容没有同步文件索引同时导出 JSON 元数据文件如export_meta再做校验目录结构混乱开发人员看不懂没有约定目录规范在团队内统一上下文目录规范像约定代码工程结构一样约定上下文结构并发写文件时互相覆盖多个协程或 Agent 同时写入同一个文件引入文件锁或者按任务拆分到不同子目录下面单独说一下最麻烦的“上下文过大导致 Agent 报错终止”的场景。典型报错现象是Agent terminated due to error. You can prompt the model to try again or start a new conversation.这类错误通常不是因为模型能力不足而是执行链路中某一环超出了限制。排查顺序建议如下查看日志确认是上下文长度超限还是工具执行超时。如果上下文超限统计当前 Prompt 实际包含的 Token 量找出占用最大的文件。将占用大的文件拆分成多个小文件并在 Prompt 中按任务选择性加载。为历史会话开启快照然后对旧日志进行压缩归档。重跑任务观察错误是否消失。这里要强调一个原则不要等到 Agent 报错才处理上下文而是在 Agent 每轮执行结束后主动做同步和清理。文件系统的意义不在于“出了问题能修复”而在于“通过结构化管理从源头避免问题发生”。6. 最佳实践与工程建议6.1 路径命名规范上下文文件系统的路径就是上下文的“地址”命名规范非常重要。推荐以下规范目录使用小写字母多个单词用下划线连接如user_profile。文件使用小写字母和点号如prompt.md、session.log。临时文件统一放在/ctx/session/cache/不要散落在根目录。长期记忆统一放在/ctx/memory/和短期工作区严格分离。涉及多个版本的内容在文件名中标注版本号例如plan_v2.md。一个清晰的命名规范能让 Agent 在检索时更快地命中目标也能让调试时人更容易理解目录结构。6.2 按需加载而非全量加载这是上下文文件系统最核心的价值。每次构建 Prompt 之前应该先明确一个问题当前这个任务模型需要知道哪些信息通常 Agent 的任务可以拆成多个子任务每个子任务只加载自己需要的上下文目录。比如代码生成任务加载/ctx/workspace/code/、/ctx/memory/decisions.md。测试任务加载/ctx/workspace/test/、/ctx/system/tools.md。文档任务加载/ctx/workspace/docs/、/ctx/memory/user_profile.md。通过按需加载可以把原本需要 50k Token 的上下文降低到 10k 甚至更少同时模型关注度更高输出质量更好。6.3 关键节点自动同步建议在以下时机触发sync子任务完成后。调用外部工具前。从外部 API 返回结果后。Agent 会话结束前。压缩上下文之前。同步操作可能有一定的性能开销所以不需要每一条消息都同步。重点保证“关键状态不丢失”。6.4 快照策略快照是回滚的保障但不建议每次都全量快照。推荐的策略是每次会话结束时创建一次快照。执行高风险操作如修改代码、删除文件、发布配置前创建快照。设置快照保留数量比如保留最近 20 份防止磁盘膨胀。在快照目录下附带一份meta.json记录快照对应的任务和时间。6.5 安全与权限意识上下文文件系统中可能包含敏感信息比如用户密钥、数据库密码、内部 API 地址。需要注意敏感信息放在独立目录比如/ctx/secret/并在默认 Prompt 构建时排除。给不同 Agent 分配不同目录权限不要所有 Agent 共享同一份完整上下文。在日志中避免打印完整密钥脱敏后再输出。当上下文文件需要跨环境传输时先检查是否包含敏感字段。权限思维在 Agent 开发中常常被忽略。一个子 Agent 本来只应该访问测试环境的配置但如果上下文是全量共享的它就可能把生产环境的密钥也读进窗口带来安全风险。6.6 与现有 Agent 框架的集成思路OpenViking 这类上下文文件系统可以嵌入到常见的 Agent 开发框架中。一段典型的集成逻辑是# 文件路径agent_integration.py from context_vfs import ContextVFS class AgentEngine: def __init__(self): self.vfs ContextVFS() self.model_client None # 假设接入某个大模型客户端 def run_task(self, task: str): # 1. 从上下文文件系统构建 Prompt prompt self.build_prompt(task) # 2. 调用模型 response self.model_client.chat(prompt) # 3. 将模型输出写回上下文 self.vfs.append(/ctx/session/chat.log, f\n用户{task}\n助手{response}) # 4. 同步到磁盘 self.vfs.sync() return response def build_prompt(self, task: str) - str: system_prompt self.vfs.read(/ctx/system/prompt.md) plan self.vfs.read(/ctx/session/plan.md) return f{system_prompt}\n\n{plan}\n\n任务{task}这样Agent 的上下文不再是隐形的“临时变量”而是一个可以随时检查、恢复、迁移的持久化系统。7. 总结OpenViking 的核心思想并不复杂把 Agent 上下文从“对话流”变成“文件系统”。这一抽象带来了四个直接收益上下文可以按路径精确读取避免 Token 浪费上下文可以持久化同步解决新会话丢失记忆的问题上下文可以用快照回滚降低自动压缩带来的风险上下文可以分层组织支持多 Agent 协作和权限隔离。从工程角度看理解上下文文件系统本质上是在理解“上下文工程”的落地方式。无论是做 AI 编程助手还是开发通用 Agent 框架都需要认真思考一个问题模型该看到什么不该看到什么以及这些信息如何被持久化、检索、压缩和恢复。建议下一步从三个方面继续深入第一研究 Linux VFS 的实际实现理解文件系统抽象层是怎么处理性能与一致性的第二调研主流 Agent 框架如 Claude Code、各类 Agent harness是如何管理上下文的对比它们的优劣第三动手改造一个小型 Agent 项目把上下文结构调整成目录树并加上同步和快照机制。如果这篇文章对你有帮助可以收藏备用。你在做 Agent 开发时遇到过哪些上下文相关的问题欢迎在评论区分享大家一起讨论解决方案。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
