Agent 上下文这层，四家开源方案各管一摊：记忆库、窗口瘦身、知识框架、工作树隔离

#GitHub趋势#Agent上下文#横向对比

先说本期为什么是合集：日 / 周 / 月三榜扫下来，干净又没写过的单项目基本清零了——剩下的只有一个离题的复古终端模拟器。但「Agent 的上下文到底怎么管」恰好是最近最高频的共性痛点，我挑了四个方向正交、且都已在前面单写过一遍的开源方案做横向对比：OpenViking（统一上下文数据库）、context-mode（上下文窗口瘦身）、WeKnora（企业知识框架）、worktrunk（并行 Agent 工作树隔离）。

项目	管的是哪一层	语言	许可
OpenViking	记忆 / RAG / 技能 → viking:// 文件系统	Py / Rust / TS	AGPL-3.0
context-mode	工具输出沙箱 + 会话连续性	TS / Node	ELv2（源码可用）
WeKnora	RAG + ReAct Agent + Wiki 长期记忆	Go / Vue	MIT
worktrunk	并行 Agent 工作树 / 工作区隔离	Rust	MIT OR Apache-2.0

OpenViking（volcengine/OpenViking）：把上下文做成文件系统

定位最「整」：把 Agent 的 记忆、RAG、技能 统一成一套挂在 viking:// 下的虚拟文件系统，分 L0（目录摘要）/ L1（概览）/ L2（全文）三层按需加载；提交一个 session 会后台抽取、合并记忆，这就是它叫「Self-evolving Context Database」的地方。

安装与启动（README 原文）：

pip install openviking --upgrade
openviking-server init      # 配置 provider 与模型
openviking-server doctor    # 自检配置与连通性
openviking-server           # 启动服务

坑：主体 AGPL-3.0（强 Copyleft），只有 crates/ov_cli 与 examples 是 Apache-2.0；自进化记忆会自己改写自己，没审记忆策略就上生产有「记忆漂移」风险；且必须自备 embedding 模型 + VLM。本轮回 REST API 实测 36,905★ / 2,830 fork / 707 issue / 108 watch。

context-mode（mksglu/context-mode）：专治上下文窗口被淹没

它解决的是另一半痛点：每次 MCP 工具调用都把原始数据倒进上下文窗口——一个 Playwright 快照 56 KB，二十个 GitHub issue 59 KB，半小时后 40% 的上下文没了。context-mode 把工具原始输出进沙箱（315 KB → 5.4 KB，98% 缩减），会话状态进 SQLite + FTS5（BM25 检索），靠 MCP + hooks 覆盖 Claude Code / Codex / Cursor / Copilot 等 17 个客户端。

以 Claude Code 为例（README 原文）：

npm install -g context-mode
claude mcp add context-mode -- npx -y context-mode
/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode

坑：许可证是 Elastic License 2.0（ELv2），源码可用但 不是 OSI 开源——你不能把它当托管 / 管理服务提供，也不能去掉许可声明；它选 ELv2 正是为了挡掉「打包成竞品闭源 SaaS」。想闭源集成要先掂量这条。本轮回 Trending 周榜快照 22,603★ / 1,628 fork / +1,936 本周。

WeKnora（Tencent/WeKnora）：给企业搭一套知识框架

腾讯开源的 LLM 企业知识框架，三大件：RAG 快问、ReAct Agent（编排检索 / MCP 工具 / 技能沙箱 / 联网搜索）、Wiki 模式（把原始文档蒸馏成自维护、互链的 Markdown 知识库）。带跨会话长期记忆、20+ LLM provider、RBAC、全自托管。

安装与启动（README 原文，Docker 全家桶）：

git clone https://github.com/Tencent/WeKnora.git
cd WeKnora
cp .env.example .env
docker compose pull
docker compose up -d

坑：一上来就是容器栈（核心 + 可选 neo4j / minio / langfuse），最轻也得跑几个容器；MIT 可商用，但企业部署的运维面不轻。最新 v0.8.0 移除了本地宿主进程沙箱后端。本轮回 Trending 周榜快照 22,847★ / 3,263 fork / +1,168 本周。

worktrunk（max-sixty/worktrunk）：让并行 Agent 不互相踩文件

它管的是最底层——仓库层的工作区隔离。并行跑 5–10 个 Agent 时，每个 Agent 一个独立 git worktree，互不覆盖改动；wt switch / create / list / remove / merge 把 worktree 用得跟分支一样顺，hash_port 给每个 worktree 唯一端口、共享构建缓存。

安装（README 原文）：

brew install worktrunk && wt config shell install
# 或
cargo install worktrunk && wt config shell install

坑：它解决的是「Agent 互相覆盖文件」，不是记忆 / RAG——你若缺的是跨会话经验，它帮不上。许可 MIT OR Apache-2.0，四个里最干净的一个。本轮回 Trending 周榜快照 7,506★ / 269 fork / +257 本周。

我的判断：先想清楚你缺的是哪一层

▪想要一层统一的「上下文抽象」，让 Agent 像翻文件一样管记忆 / RAG / 技能 → OpenViking（接受 AGPL-3.0）
▪痛点是上下文窗口被工具输出淹没、压缩后丢状态 → context-mode（接受 ELv2 源码可用）
▪要给企业搭一套能问答 + 推理 + 自维护知识库的平台 → WeKnora（接受 Docker 运维面）
▪并行跑多个 Agent 怕互相踩文件 → worktrunk（最轻、许可最干净）

四家都在「Agent 记忆 / 上下文」这层各自造词（viking://、context window、Wiki Mode、worktree），没有统一标准。选型前先定位你缺的是 记忆？窗口？知识库？还是隔离？，别一上来全堆——堆错层，上下文照样爆。

本期为横向对比合集：四者此前均已作为单项目写过，本回合统一实抓 README 与 Trending / REST API 复核。

OpenViking：36,905★（API 实测）/ 2,830 fork / 707 issue / 108 watch / AGPL-3.0 / Py-Rust-TS / 月榜 +8,682。

context-mode：22,603★ / 1,628 fork / +1,936 本周（Trending 周榜快照）/ ELv2 / TS-Node。

WeKnora：22,847★ / 3,263 fork / +1,168 本周（Trending 周榜快照）/ MIT / Go-Vue / v0.8.0。

worktrunk：7,506★ / 269 fork / +257 本周（Trending 周榜快照）/ MIT OR Apache-2.0 / Rust。

数据来源：GitHub Trending 官方页面 + GitHub REST API + 各仓库 raw README ｜抓取时间：2026-09-14 (GMT+8)

你们现在管 Agent 上下文，是靠「多写几个 skill」硬撑，还是已经上了一层专门的上下文 / 记忆中间件？

更尖锐一点：context-mode 用 ELv2 把「打包成闭源 SaaS」挡在门外，OpenViking 主体 AGPL-3.0——你愿意为这套上下文能力付出「改了就得开源」的代价吗？

下期预告：三榜若继续被写过项目占满，做「AI 视频生成全家桶」横向合集（OpenMontage / hyperframes / 其他 text-to-video）；出现高动量干净新面孔 → 回单项目精读。

#GitHub趋势#Agent上下文#横向对比