很多 coding agent 的“记忆”问题，并不是模型忘了上一轮对话，而是它没有一个能解释来源、范围和新鲜度的代码上下文层。Sverklo 的定位值得按这个工程问题来审视：它是一个本地优先的 MCP 服务，把仓库索引、符号图、依赖关系、差异审查和持久化记忆放在同一套工具面上。它的价值假设不是“搜索更聪明”，而是让 Agent 在进入陌生仓库、追踪影响面和跨会话工作时，能拿到可复核的上下文。

上游仓库给出的入口是 npm install -g sverklo，目标运行时是 Node.js >= 24。安装完成只能证明 CLI 可以被找到，不能证明索引正确，也不能证明 MCP 客户端拿到的是当前仓库。第一轮应该在一个可丢弃的测试仓库里做，不要一开始把真实工作区和全局注册表绑定起来。

我会把首轮验收拆成四个可观察对象。第一是文件发现：索引器是否只收录预期路径，忽略规则是否生效，重新索引后文件数量是否合理。第二是代码结构：一个已知符号能否被 lookup 找到，refs、deps 和 impact 是否能沿调用关系返回，而不是只返回文件名。第三是上下文交付：context 工具能否以一次调用返回项目概览，并在传入 budget 时给出受 token 预算约束的 PageRank 代码地图。第四是记忆账本：一条带项目范围、类型、关联文件和时间信息的记忆，能否被 recall 找回，文件变化后是否明确显示为 stale。

Sverklo 的检索并非单一向量召回。人工手册描述的是 BM25 关键词、ONNX embedding 和 PageRank 符号图的多信号融合；命中结果还会暴露 found_by，让调用者判断多个检索器是否一致。这里有一个重要的操作边界：精确字符串仍然应该用 Grep/Read；Sverklo 更适合探索、影响面、依赖图和语义问题。把所有查询都交给向量检索，会损失可预测性，也不符合它自己的 MCP 指令。

一个可重复的验收脚本可以这样设计：

1. 建一个只有几个模块的临时仓库，分别放入函数、测试、README 和一条故意断开的依赖。
2. 运行 sverklo init，再注册项目并等待索引完成；记录 Node 版本、项目名、索引时间和文件数量。
3. 用 context 做一次 onboarding，给 budget 传一个小值，检查返回的项目地图是否随预算收缩。
4. 用 lookup 找已知符号，用 refs、deps、impact 追踪同一符号的调用者、依赖和变更影响。
5. 用 remember 写入一条指向具体文件的决策，再修改该文件，检查自动注入的 sverklo://context 或 recall 是否标记过期。
6. 用 review_diff 检查一个小改动，确认输出既有可读的 Markdown 结论，也有可以锚定到 path/line/severity 的结构化数据。

真正容易出错的是生命周期。Sverklo 把已注册项目写入 ~/.sverklo/registry.json；手册记录的 issue #74 指出，reindex 完成后 lastIndexed 可能仍是旧值，所以列表里的时间只能当作提示，不能当作索引完成证明。实际自动化里，reindex 后应重新 register，或直接读取索引状态和文件证据。issue #73 还指出 unregister 需要内部名称而不是绝对路径，这对销毁临时 worktree 的脚本很关键：先从 sverklo list 解析名字，再执行注销。

MCP 接入也有一个不显眼但会影响生产的命名边界。Sverklo 内部工具已经带 sverklo_ 前缀；如果宿主又按服务器键名自动加前缀，可能出现 sverklo_sverklo_impact 这样的重复命名。接入后不要只看服务器显示为 connected，要实际列出工具并调用一次 context、lookup 或 status，确认宿主调用的名称和返回结构都对。

我的判断是：先把 Sverklo 当成可观察的本地代码上下文候选，而不是“装上就会记住一切”的 Agent 大脑。进入真实工作区前至少要保留四类证据：索引范围与时间、符号/依赖查询结果、记忆的 stale 行为、差异审查的结构化输出。缺少这些回读，就只能说 CLI 启动过，不能说代码记忆链路可信。

这是 Doramagic 制作的独立 AI 能力资源包，不代表 Sverklo 官方发布或背书。项目页：https://doramagic.ai/zh/projects/sverklo/；Human Manual：https://doramagic.ai/zh/projects/sverklo/manual/；上游：https://github.com/sverklo/sverklo。