AVM 的设计目标很明确：感知 token 的检索、多智能体隔离、追加式语义。但没有数据支撑的设计只是假说。这篇文章对 AVM 进行了系统性的性能评估，涵盖延迟分布、可扩展性、缓存行为、多智能体竞争等多个维度——目标是搞清楚它在哪里表现优秀，瓶颈又在哪里。
所有基准测试在 Apple M2 Pro、16GB RAM、macOS 24.6.0、Python 3.13.12、SQLite 3.45.0（WAL 模式）、all-MiniLM-L6-v2 嵌入模型下运行。
| 指标 | 数值 | 备注 |
|---|---|---|
| 写入吞吐量 | 468 ops/s | WAL + 异步嵌入 |
| 读取吞吐量（热缓存） | 724,000 ops/s | LRU 命中 |
| 读取吞吐量（冷缓存） | 3,300 ops/s | 缓存未命中 → SQLite |
| 搜索吞吐量 | 2,000 ops/s | FTS5 全文检索 |
| 缓存命中率 | 95% | Zipf 访问模式 |
| Token 节省 | 97%+ | 对比加载全部记忆 |
今天我们运行了全面的基准测试，以衡量 AVM 对多智能体协作的影响。结果清楚地表明了持久记忆最能发挥价值的场景，以及我们在哪里实现了显著的性能优化。
多智能体准确率：
| 场景 | 基线 | AVM | 提升 |
|---|---|---|---|
| 上下文溢出 | 50% | 88% | +38% |
| 知识检索 | 47% | 67% | +20% |
| 完整协作 | 100% | 100% | — |
上周我们上线了 sandbox_exec——一个用 224 行 C 代码编写的程序，利用 seccomp-bpf 在 AWS Lambda 里隔离学生代码。当时的诚实回答是：「WASM 更干净，但 Python 生态系统还没准备好。」
这周我们精确地测量了「Python 生态系统还没准备好」在毫秒层面的代价。答案比预期的更加微妙。
在我维护的 OJ 平台 Leverage 上的一次比赛期间，排行榜停止更新了。停了大约半天。学生在继续提交代码、获得评测结果，但他们的排名没有变化。我们最终追踪到一个 15 分钟的定时任务，它严重阻塞了 Node.js 事件循环，导致进程无响应。
这篇文章讲的是哪里出了问题、为什么最直观的修复实际上没有解决任何问题，以及用 Redis 有序集合替换整个定时任务、实现 O(log N) 实时更新的设计。
排名系统的工作方式如下：
// rank.service.ts — 简化版
async rebuildSaAndRank(divisionId: number, ids: number[]) {
// 第一步：加载所有提交
const submissions = await Submission.createQueryBuilder('s')
.where('s.divisionId = :divisionId', { divisionId })
.orderBy('s.createdAt', 'ASC')
.getRawMany()
// 第二步：在内存中为每个用户计算分数
const userDatas: Map<UserId, ScoreAggregate>[] = []
for (const submission of submissions) {
// ... 处理每个提交，更新用户分数 map
// 通过 cloneDeep 创建完整的每日历史记录
}
// 第三步：给所有人排序
const ranked = [...userDatas[0].entries()]
.sort(([, a], [, b]) => compareScores(a, b))
// 第四步：写回结果 — 每个用户一次 UPDATE
for (const [userId, scoreAggregate] of ranked) {
await ContestUser.update({ userId, contestId }, {
rank: /* 计算出的排名 */,
score: scoreAggregate.score,
})
}
}