今日三荐：微型虚拟机、代码知识图谱与分布式状态 (2026)

今天可以把三个仓库放在一条学习线上：程序要执行别人的代码时，怎么隔离；要理解一个大代码库时，怎么建立索引；要把状态交给多台机器时，怎么保存和迁移。前两个适合今晚在个人电脑上做出可观察的结果，第三个更适合用一个小部署理解分布式状态的边界。

1. Microsandbox：先把不可信代码关进 microVM

仓库：superradcompany/microsandbox · Rust runtime，多语言 SDK

很多「代码执行器」的第一反应是启动一个进程或容器。Microsandbox 把隔离层再往下推：它在本地 microVM 里运行 AI agent、用户代码、插件、CI 任务和爬虫等不可信工作负载。README 同时提供 Rust、Python、TypeScript 和 Go SDK；SDK 创建的 microVM 是应用的子进程，不需要单独部署一台服务。1

这里最值得拆的机制，是「熟悉的容器工作流」和「硬件级隔离」怎样接在一起。你仍然可以给它一个镜像、执行命令、挂载数据和限制 CPU、内存，但真正需要追的代码路径是：SDK 的 create() 怎样启动运行时，exec() 怎样把命令送进 VM，网络和密钥又在哪一层被限制。

适合学什么

进程、容器和 microVM 的隔离边界分别在哪里。
一个跨语言 SDK 怎样把同一套生命周期操作映射到 Rust、Python、TypeScript 和 Go。
运行不可信代码时，镜像、网络、密钥和资源额度为什么要一起设计。
如何从一个同步的「执行命令」接口，追到异步运行时、输出流和 VM 退出。

复现难度：低到中。最小 CLI 可以直接启动一个 Debian microVM：

npx microsandbox run debian

也可以全局安装 msb，再运行：

msb run debian

README 给出的硬件前置条件是：Apple Silicon 的 macOS、启用 KVM 的 Linux，或启用 WHP 的 Windows。项目仍处于 beta，可能有破坏性变更和未完成的功能；首次运行还会拉取镜像，网络慢时等待时间会更长。1

项目在 2026 年 8 月 16 日仍有依赖更新，8 月 15 日还发布了 0.6.9，维护信号很新，但这也意味着接口需要跟着 README 走。2

最小上手路径：先只运行 debian，在 VM 里执行 uname -a、读取一个临时文件，再退出。第二步再装 SDK，创建一个只分配 1 个 CPU 和 512 MB 内存的 Python sandbox，执行 print()。不要第一晚就接入真实 API 密钥；先观察镜像缓存、标准输出和 stop() 的生命周期。

今晚可以做的最小练习：写一个小脚本，把同一段 Python 代码分别在宿主机和 Microsandbox 中运行。让代码打印当前工作目录、环境变量名和一个随机文件的存在性，比较两边能看到的内容。练习的重点是找出「隔离到底改变了什么」，而不是证明它能跑出一句 Hello World。

2. Code-Graph-RAG：把多语言仓库变成可以查询的图

仓库：vitali87/code-graph-rag · Python，Tree-sitter + Memgraph

读一个陌生 monorepo 时，按文件逐个打开很快会迷路。Code-Graph-RAG 用 Tree-sitter 解析多语言代码，把函数、类、方法、模块和它们的关系写入 Memgraph，再把自然语言问题转换成 Cypher 查询，返回相关代码；它还提供基于 AI 的编辑与优化入口。仓库的主链路可以概括为：源码 → AST 分析 → Memgraph 知识图谱；用户问题 → Cypher → 图查询结果。3

这个项目比「给代码库接一个向量检索」更适合学习。向量相似度告诉你哪些文本看起来相近，图结构则能把「这个函数被谁调用」「这个模块依赖了哪些类型」这类关系保留下来。建议先读 cgr 命令和 codebase_rag/，看解析器、图模型和查询生成各自承担什么职责，再去碰 MCP 接入。

适合学什么

Tree-sitter 怎样把 Python、TypeScript、Rust、Go、Java、C/C++、C#、PHP、Lua、Dart 等语言统一成可查询的结构。
AST 节点如何变成图里的实体和边，以及图查询为什么能回答调用关系问题。
RAG 系统怎样把自然语言转换为 Cypher，而不是只把一堆文件拼进提示词。
索引更新、共享图和 AI 编辑之间的风险边界：查询结果对了，不代表自动改代码就是安全的。

复现难度：中。官方给出的安装方式是安装包含全部 Tree-sitter 语言和语义搜索依赖的 CLI：

uv tool install "code-graph-rag[treesitter-full,semantic]"
cgr daemon up
cgr start --repo-path /path/to/repo --update-graph
cgr start --repo-path /path/to/repo

运行前还需要 Docker、cmake 和 ripgrep，因为 Memgraph 负责保存代码图。它支持混合语言 monorepo，但依赖比普通 Python CLI 多一层；如果只想学习主线，先准备一个几十个文件的小仓库，不要直接索引自己的全部家目录。3

截至 2026 年 8 月 16 日，仓库仍有提交更新。另一个需要记住的边界是：共享图里的 --clean 会删除所有项目，而不是只清掉当前仓库，重新开始前要看清确认提示。3 4

最小上手路径：先索引一个小型课程项目，只问三个可验证的问题：入口函数在哪里、某个类被哪些模块引用、最近一次修改涉及哪些文件。把返回的 Cypher 和图结果保存下来，再手动打开其中一个调用链核对。第二轮再试 --update-graph，观察改动后图中新增或消失了哪些边。

今晚可以做的最小练习：为一个有三层目录的 Python 小项目写五个自然语言问题，故意混合「文件内容问题」和「关系问题」。例如「哪个模块创建了数据库连接」属于前者，「哪些函数会调用它」属于后者。比较两类问题的查询结果，看看知识图谱在哪些地方比全文搜索更有用，又在哪些地方仍需要回到源码确认。

3. celld：每个 Durable Object 都有自己的 SQLite

仓库：denoland/celld · Rust daemon

Cloudflare Durable Objects 的核心想法，是给一个有名字的对象绑定一份持久状态，并让请求回到负责这个对象的执行位置。celld 把这套模型搬到自托管环境：每个对象有自己的 SQLite 数据库，数据库持续复制到你拥有的 S3 兼容存储或 Google Cloud Storage；当对象换到另一台机器，新的所有者从 bucket 恢复 SQLite 后继续执行。真正的持久真相在 bucket，节点可以被替换。5

这条主线适合学习「状态放在哪里」这个分布式系统基本问题。你需要同时看对象命名、部署版本、节点间通信和存储复制，而不是只看一个 HTTP handler。它的设计也把一个常见误区摆到台面上：多台机器并不自动等于高可用，节点之间怎样找到彼此、内部地址能不能访问、对象迁移时怎样恢复，都需要明确配置。

适合学什么

Actor / Durable Object 风格的单对象串行状态，以及它和普通无状态服务的区别。
SQLite 文件如何成为对象的局部状态，bucket 如何承担跨节点恢复职责。
节点地址、内部监听端口和对等 HTTP 通信怎样影响对象迁移。
「部署成功」和「能在真实网络里迁移」之间还差哪些前置条件。

复现难度：中到高。只检查安装是否成功，可以先运行：

docker run --rm ghcr.io/denoland/celld --version

要跑核心流程，README 给出的部署命令需要一个 bucket：

curl -fsSL https://celld.dev/install.sh | sh
celld deploy . --bucket s3://my-cells-bucket
celld --bucket s3://my-cells-bucket \\
  --listen 0.0.0.0:8080 \\
  --internal-listen 10.0.0.12:8081 \\
  --advertise 10.0.0.12:8081

bucket 可以是 S3 兼容服务或 Google Cloud Storage，程序会使用相应的凭据链。对等 HTTP 和 operator API 走内部监听地址，README 明确提醒不要把内部端口直接暴露到公网；因此，没有对象存储和可信私网时，你能完成的是安装与源码阅读，不能把它当成完整的分布式复现。5

项目在 2026 年 8 月 15 日发布了 v0.2.1，8 月 13 日还有 v0.2.0，版本变化很快。6

最小上手路径：先只做 --version 和 README 中的部署参数阅读，画出「对象 → SQLite → bucket → 新节点恢复」四步图。若手头已有 S3 兼容存储，再部署一个节点，创建一个只保存计数器的对象，重启节点后检查计数是否恢复。没有 bucket 时不要用本地某个 SQLite 文件冒充 celld 的完整行为，那只能证明 SQLite 能写入，证明不了对象迁移。

今晚可以做的最小练习：先不部署，写一页纸回答三个问题：一个对象由谁命名，哪一份状态是权威的，节点换人时新节点需要从哪里开始。然后把这张图和一个普通无状态 API 的请求流程并排比较。你会看到，难点从「怎么响应请求」变成了「谁在什么时候拥有这份状态」。

怎么选今天动手的那一个

你现在的状态	更建议先碰	先学哪条主线	关键限制
想先看到隔离后的程序如何运行	Microsandbox	microVM、资源限制、命令生命周期	macOS 要 Apple Silicon，Linux 要启用 KVM，Windows 要启用 WHP；项目仍是 beta。1
手头有 Docker，想理解代码搜索为什么需要结构	Code-Graph-RAG	Tree-sitter、AST、知识图谱、Cypher	需要 Memgraph、`cmake` 和 `ripgrep`；`--clean` 影响共享图里的全部项目。3
想学分布式状态，且能提供对象存储	celld	Durable Object、SQLite 复制、对象迁移	核心流程需要 S3 兼容 bucket 或 GCS，以及可信的内部网络；只装 CLI 不等于跑通迁移。5

如果只安排一晚，优先从 Microsandbox 开始：一条命令就能看到隔离边界。想把「代码搜索」从关键词匹配推进到调用关系，再选 Code-Graph-RAG。celld 值得留给有对象存储条件的实验，或者作为分布式系统的源码阅读题。三项真正连起来的地方，是把程序从「能运行」继续拆成三个问题：它能运行在哪里，如何被理解，以及状态由谁保存。

References

1
Microsandbox README
github.com
2
Microsandbox commit history
github.com
3
Code-Graph-RAG README
github.com
4
Code-Graph-RAG commit
github.com
5
celld README
github.com
6
celld commit history
github.com

1. Microsandbox：先把不可信代码关进 microVM

2. Code-Graph-RAG：把多语言仓库变成可以查询的图

3. celld：每个 Durable Object 都有自己的 SQLite

怎么选今天动手的那一个

References

Related content