Agent 不只需要模型：上下文基础设施正在成形

最近看 GitHub 上的新项目，有一个方向越来越明显：

Agent 的关键问题，正在从“能不能调用一个更强模型”，转向“能不能持续、可靠、低成本地管理上下文”。

这不是一个单点新闻，而是几个项目同时指向同一件事。

OpenViking 把自己定位成面向 AI Agent 的 context database，用文件系统范式统一管理 memory、resources 和 skills。Mirage 试图把 S3、Google Drive、Slack、Gmail、Redis 这类外部服务挂到同一棵虚拟文件树里，让 Agent 用类 Unix 工具访问不同后端。SkillOpt 则更进一步，把自然语言写成的 skill 当成可以训练、验证和迭代的外部状态，而不是一次性提示词。

这三个项目解决的不是同一个问题，但它们都在回答一个更大的问题：

当 Agent 开始长期执行任务、调用工具、沉淀经验之后，它的“工作记忆”应该放在哪里？应该怎么读、怎么改、怎么调试、怎么复用？

我的判断是：上下文基础设施会成为 Agent 应用接下来最重要的一层。

先认识这三个项目

这篇文章不是要把三个项目混在一起讲。它们处在 Agent 基础设施的不同位置：OpenViking 更像上下文数据库，Mirage 更像工具和数据源的虚拟文件系统，SkillOpt 更像 skill 优化器。

如果用一句话区分：

这三个项目都不只是“又一个 Agent 框架”。它们更像是在补 Agent 长时间工作时缺失的底层能力。

OpenViking：给 Agent 一个上下文数据库

OpenViking 的定位是 The Context Database for AI Agents。

它想解决的问题是：Agent 所需的上下文正在变得越来越碎。项目文档、用户偏好、任务日志、技能说明、外部资源、历史经验，都可能影响一次任务结果。如果这些内容只散落在 prompt、聊天记录、向量库和临时文件里，Agent 很难稳定复用。

OpenViking 的做法是把 memory、resources 和 skills 放到一个统一的 context database 里，并用文件系统范式组织它们。它不是只提供“相似度搜索”，而是强调层级结构、目录递归检索、分层加载和检索轨迹可视化。

可以把它理解成 Agent 的“上下文工作区”：

• memory 用来保存偏好、经验和历史状态；
• resources 用来挂载文档、代码、资料和外部知识；
• skills 用来描述可复用的任务方法；
• 分层加载用来控制哪些上下文应该进入当前任务；
• 可视化检索轨迹用来帮助开发者排查 Agent 为什么读到了这些信息。

它适合关注长期记忆、项目级上下文和多技能协作的 Agent 应用。比如代码助手、企业知识助手、个人工作流 Agent，都可能遇到类似问题。

它的边界也很明确：OpenViking 解决的是上下文组织和检索问题，不等于替你解决权限、安全、任务规划和业务审批。上下文数据库如果接入了敏感信息，仍然需要单独做访问控制和审计。

Mirage：把外部世界挂成一棵文件树

Mirage 的定位是 A Unified Virtual Filesystem For AI Agents。

它关注的是另一个实际问题：Agent 要访问的工具越来越多。今天一个 Agent 可能要读 GitHub、查 S3、看 Slack、读 Gmail、访问 Redis、处理本地文件。每个系统都有自己的 API、权限、分页、错误码和数据格式，Agent 调得越多，失败概率越高。

Mirage 的思路是把这些外部数据源挂载成统一的虚拟文件系统。仓库 README 里给出的例子是让 Agent 在同一棵树下看到 /s3、/gdrive、/slack、/gmail、/redis 这类资源，然后用类似文件操作的方式探索、读取和组合数据。

这个设计有两个价值。

第一，它把工具调用变成 Agent 更容易理解的环境探索。ls、cat、grep、目录、文件、路径，这些抽象比一堆异构 API schema 更稳定。

第二，它给复杂任务提供了一个中间工作区。Agent 可以把不同来源的数据读进来、整理成文件、产生中间结果，再交给下一个步骤使用。

它适合那些“数据源很多，但多数动作是读取、搜索、整理、组合”的 Agent 场景。比如研究助手、数据整理助手、自动化运维助手、企业内部资料查询工具。

但 Mirage 也不应该被理解成万能 API 替代品。涉及转账、删除、审批、发消息这类有副作用的操作，仍然需要更严格的权限、确认和审计。文件系统抽象适合降低读取和组织复杂度，不应该模糊业务动作的风险边界。

SkillOpt：让 skill 可以被训练和验证

SkillOpt 来自 Microsoft Research，定位是 Executive Strategy for Self-Evolving Agent Skills。

它解决的是 Agent 经验复用的问题。现在很多 Agent 系统都有 skills、prompts、playbooks 或 SOP，但这些内容通常靠人写、靠人工试错。一个 skill 改好还是改坏，往往没有稳定评估。

SkillOpt 的思路是：不改模型权重，而是优化外部自然语言 skill。它会根据任务轨迹、反馈和验证结果反复编辑 skill，并只接受能提升验证表现的改动，最终产出类似 best_skill.md 的可部署技能文档。

这个项目值得关注，是因为它把 skill 从“提示词经验”变成了“可训练资产”。

对开发团队来说，这意味着未来可以像维护代码一样维护 skills：

• 为某类任务准备固定评估集；
• 记录每次 skill 修改前后的效果；
• 把失败案例反向写入优化过程；
• 对高风险 skill 设置人工审核；
• 把稳定 skill 发布到真实 Agent 工作流里。

SkillOpt 更偏研究和方法论，不是拿来就能替代现有 Agent 平台的完整产品。但它指向的方向很重要：当 Agent 越来越依赖 skills，skill 本身就需要版本管理、评估、优化和发布流程。

为什么现在才变重要

早期的 AI 应用大多是 chat。

用户给一段输入，模型给一段输出。上下文管理主要是把历史对话塞进窗口里，超长了就截断、总结，或者做一个简单 RAG。

但 Agent 不一样。

一个真正做事的 Agent 会不断产生新的状态：

• 它读过哪些文件；
• 调用了哪些工具；
• 哪些命令失败过；
• 哪些用户偏好已经确认；
• 哪些经验下次可以复用；
• 哪些外部资源只应该按需加载；
• 哪些技能在这个项目里有效，哪些无效。

如果这些信息只是散落在对话历史、向量库、临时文件和工具日志里，Agent 很快就会变得不可控。

问题不只是“记不住”，更是“记住了也不知道怎么用”。

传统 RAG 能解决一部分检索问题，但它通常把信息打平：文档切块、向量化、相似度召回。对于长任务 Agent 来说，这还不够。Agent 需要知道上下文之间的层级、来源、时效、权限和任务关系，也需要在出错时回看“为什么它检索到了这些东西”。

这就是 OpenViking、Mirage、SkillOpt 这类项目值得看的地方。它们不是在堆一个更大的上下文窗口，而是在重新设计 Agent 怎么组织外部状态。

方向一：上下文从向量库变成文件系统

OpenViking 的核心想法很直接：把 Agent 需要的 memory、resources、skills 统一组织成类似文件系统的结构。

它强调的不是“所有东西都向量化”，而是用目录、文件、层级加载、递归检索这些开发者熟悉的方式来管理上下文。README 里提到的几个点很关键：文件系统范式、L0/L1/L2 分层上下文加载、目录递归检索、可视化检索轨迹、自动会话管理。

这背后有一个很重要的工程判断：

Agent 的上下文不应该只是一个黑盒知识库，而应该是可组织、可观察、可调试的工作空间。

如果一个 Agent 因为错误上下文做出了错误决策，开发者不能只看到“模型答错了”。更有价值的是知道：

• 它读取了哪个目录；
• 它用了哪段 memory；
• 它忽略了哪些资源；
• 它为什么选择这个 skill；
• 它在第几轮任务里产生了错误假设。

这会把上下文管理从“检索增强”推进到“上下文工程”。

方向二：外部工具变成一棵虚拟文件树

Mirage 的思路更偏工具访问层。

它把多个服务和数据源挂到同一棵虚拟文件系统里，比如 /s3、/slack、/github、/data。Agent 不需要为每个后端学习一套新的 API 语义，而是用已经熟悉的文件、目录、管道和命令组合来访问它们。

这个设计的价值在于降低 Agent 调工具的认知成本。

今天很多 Agent 工具调用看起来很强，但实际接入成本并不低。每个 MCP server、每个 SaaS API、每个数据库都有自己的参数、权限、分页、错误码和数据结构。工具越多，Agent 越容易在工具选择和参数构造上出错。

如果把后端能力抽象成统一文件系统，Agent 至少可以用一种稳定心智模型来探索环境：

• ls 看有哪些资源；
• cat 读取内容；
• grep 搜索线索；
• cp 或 mv 组织中间结果；
• 用 snapshot/version 管理一次任务的工作空间。

这不是说文件系统能解决所有问题。复杂业务动作仍然需要明确 API、权限和事务边界。但对“读取、搜索、整理、组合”这类 Agent 高频动作来说，虚拟文件系统是一个很自然的抽象。

方向三：skill 从提示词变成可优化资产

SkillOpt 关注的是另一层：Agent 怎么复用经验。

现在很多 Agent 平台都有 skills、instructions、playbook 或 prompt library。问题是，这些东西大多靠人写、靠经验调。写得好不好，通常只能靠几次人工试用判断。

SkillOpt 的思路是把自然语言 skill 当成“冻结模型之外的可训练状态”。它不是改模型权重，而是通过任务轨迹、反馈和验证门槛去迭代 skill 文档，最终产出可部署的 best_skill.md。

这件事很有意思，因为它把 skill 从“提示词片段”抬高成了工程资产。

一个成熟团队未来可能不会只维护代码、测试和文档，还会维护：

• 面向某类任务的 skills；
• 每个 skill 的评估集；
• skill 变更前后的成功率；
• 哪些任务适合自动优化；
• 哪些规则必须人工审核后才能进入生产。

这和软件工程里的测试、CI、灰度发布很像。区别只是优化对象从代码变成了自然语言策略。

这比单个项目更重要

把这几个项目放在一起看，可以看到 Agent 应用栈正在分层：

这说明 Agent 的竞争点会越来越工程化。

未来一个 Agent 产品好不好，不只看它接了哪个模型，而要看它有没有稳定的上下文系统：能不能记住重要信息，能不能忘掉垃圾信息，能不能按需加载，能不能解释自己用了什么上下文，能不能把成功经验沉淀成可复用 skill。

对开发者的实际启发

如果你正在做 Agent 应用，不一定马上要引入这些项目，但至少可以先把上下文当成一等公民设计。

我会优先检查这几个问题：

1. 上下文有没有结构？
   不要只把所有材料塞进 prompt。至少区分用户偏好、项目文档、任务日志、工具输出、长期记忆和临时草稿。

2. 上下文有没有来源？
   每条 memory、资源和 skill 都应该能回到来源。否则 Agent 一旦基于错误信息行动，很难排查。

3. 上下文有没有生命周期？
   有些信息只对当前任务有效，有些可以长期保留，有些必须定期失效。长期记忆不是越多越好。

4. 上下文有没有可观察性？
   至少要能记录一次任务里 Agent 读取了什么、跳过了什么、用了哪个 skill、在哪一步失败。

5. skill 有没有评估？
   如果一个 skill 会影响真实任务结果，就不要只凭感觉改。给它准备几个固定任务，用成功率、耗时、成本和错误类型来判断改动是否有效。

使用边界

这类基础设施也不能被神化。

第一，上下文系统不能替代权限系统。Agent 能看到什么、能调用什么、能写入什么，仍然需要独立控制。

第二，虚拟文件系统不能把所有业务操作都简化成文件读写。涉及交易、审批、删除、外发消息的动作，必须有明确确认和审计。

第三，skill 自动优化不是万能的。评估集设计不好，优化出来的 skill 可能只是过拟合某几个任务，看起来更聪明，实际更脆弱。

第四，开源项目本身还在快速变化。像 OpenViking、Mirage、SkillOpt 这类项目值得关注，但在生产环境使用前，仍然要看协议、数据边界、依赖复杂度和维护节奏。

结论

Agent 的下一阶段，不会只靠更强模型推进。

模型仍然重要，但只解决“怎么思考”的一部分。真正让 Agent 能长期工作的是另一套东西：上下文怎么组织，工具怎么暴露，经验怎么沉淀，失败怎么回放，权限怎么收敛。

OpenViking、Mirage、SkillOpt 的共同信号是：Agent 需要自己的基础设施层。

如果说过去一年大家在追“让模型会用工具”，接下来更重要的问题会变成：

当工具越来越多、任务越来越长、上下文越来越复杂时，Agent 凭什么还能稳定工作？

答案大概率不在某个更长的 prompt 里，而在一套可管理、可观察、可迭代的上下文系统里。

参考

• OpenViking: The Context Database for AI Agents
• Mirage: A Unified Virtual Filesystem For AI Agents
• SkillOpt: Executive Strategy for Self-Evolving Agent Skills
• SkillOpt paper on arXiv