Uteke：给 AI agent 一个不出本机的语义记忆库
AI agent 做真实项目时，最容易丢失的不是某一轮回答，而是跨 session 的小事实。
比如某个 staging 环境的部署步骤、一次事故复盘里的决定、某个项目里“不要再用这个 API”的原因、一个 agent 上次排查到一半的线索。这些信息通常散在聊天记录、issue、笔记和 shell history 里。下一次打开 agent，它又要重新问、重新读、重新猜。
今天想记下的 codecoradev/uteke，就是一个专门给 AI agent 放本地记忆的小工具。它不是完整的 agent 平台，也不是云端 RAG 服务，而是一个 Rust 写的 offline-first semantic memory engine：用 SQLite/FTS5 存文本和 metadata，用本地 ONNX embedding 做语义召回，再通过 CLI、HTTP server、Docker 和 MCP server 暴露给 agent。
按 GitHub repository API、README、release page、license 文件、docs/mcp.md 和 docs/docker.md 在 2026-07-07 能看到的公开信息，Uteke 当前有 33 stars、6 forks。仓库主语言是 Rust，许可证是 Apache-2.0，创建于 2026-05-29，最近 push 时间是 2026-07-06 15:25 UTC。默认分支是 develop。最新 release 是 v0.6.7，GitHub release 页面显示发布时间为 2026-07-06 05:12 UTC。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | codecoradev/uteke |
| 定位 | local-first AI agent memory engine / CLI / MCP server |
| Stars | 33 |
| Forks | 6 |
| 主语言 | Rust |
| 许可证 | Apache-2.0 |
| 仓库创建时间 | 2026-05-29 |
| 最近 push | 2026-07-06 15:25 UTC |
| 最新版本 | v0.6.7 |
| 版本发布时间 | 2026-07-06 05:12 UTC |
| 核心思路 | 把 agent memory 做成本机可搜索、可打标签、可通过 MCP 调用的轻量存储层 |
它处理的是 agent 的“记不住”
现在很多 AI coding workflow 的问题不是缺少模型，而是缺少连续性。
模型能读仓库、跑测试、写 patch，但它通常不知道上次为什么绕开某个文件，不知道某个环境变量对应哪个服务，也不知道团队已经决定不用某条迁移路径。人类开发者会把这些东西留在脑子里、笔记里、review 里；agent 如果没有外部记忆，就只能每次从当前 prompt 和文件系统重新开始。
Uteke 的切入点很小：让 agent 能显式地 remember 和 recall。README 里的快速示例是把一条部署记忆带 tags、entity、category 存进去，然后用自然语言召回。它也支持 room、author、memory type、metadata、relationship graph、pin/unpin 这类更细的组织方式。
这和“把整个聊天记录塞回上下文”不是一回事。更合理的做法是把可复用事实变成小条目，用 tags、room 和语义检索找到相关部分，再由 agent 决定是否采纳。
Local-first 是它最清晰的取舍
Uteke 的 README 反复强调 offline-first 和 single binary。默认路径里不需要 OpenAI key、Qdrant、Postgres、Neo4j 或单独的 Python 服务。第一次运行会下载约 188MB 的 embedding model，之后数据留在本机。
这个选择很适合几类上下文：
- 项目内部决定、部署步骤、客户环境线索，不适合直接丢给云端 memory provider；
- 个人或小团队想给 Codex、Claude Code、Cursor 等 agent 加一层记忆，但不想维护一套向量数据库；
- 需要在离线、内网或敏感代码环境里保存 agent 可搜索记忆；
- 想先从一个命令行工具试起，而不是引入完整平台。
底层设计也比较朴素：SQLite 存储、FTS5 全文搜索、本地 embedding、HNSW vector index。语义检索和关键字检索一起用，比只做向量相似度更适合这类短事实。部署步骤、函数名、环境名、tag 和具体版本号往往需要精确命中。
MCP 接入让它不像孤立笔记本
Uteke 对 agent workflow 有意义，主要是因为它提供 MCP server。
docs/mcp.md 里列了两种接入方式：本地 agent 推荐用 stdio transport，直接运行 uteke-mcp；需要 HTTP 的场景可以先跑 uteke-serve，再通过 http://127.0.0.1:8767/mcp 接入。文档也说得很清楚：MCP 是工具式接入，不会自动把记忆注入每一轮对话，agent 需要决定什么时候调用 uteke_recall、uteke_remember 之类的工具。
这个边界是优点。记忆系统如果每轮都自动塞内容，很容易把无关旧事实带回来，甚至污染当前任务。工具式调用则更像工程上的显式操作：开始改代码前召回项目背景，排查完问题后存一条结论，遇到环境问题时按 tag 查历史记录。
对 coding agent 来说，这比“再开一个笔记应用”更自然。记忆可以留在 repo 或用户机器旁边，agent 在需要时调用，开发者仍然能通过 CLI 和 HTTP API 检查、导入、导出。
接口面比看起来更完整
虽然 Uteke 很小，入口并不少。
CLI 适合个人使用：uteke remember 存一条记忆，uteke recall 做混合检索，uteke stats 看状态。Docker 文档显示它也能作为本机 HTTP server 跑在 127.0.0.1:8767，默认只监听 localhost；如果要开放访问，需要设置 UTEKE_AUTH_TOKEN。
MCP 文档里列出的工具覆盖存储、语义召回、文本搜索、文档、room、graph、pin/unpin 等能力。最近一次 push 的 commit message 也正好是给 MCP 加 pin/unpin tools，这说明项目还在围绕 agent 使用方式快速补功能。
还有一个细节值得注意：它把 memory 当成有类型、有 room、有 author、有 tags 的记录，而不是单纯的文本 chunk。这对多 agent 或长期项目会更重要。比如一个 repository 可以按 feature room 存设计决定，也可以按 author 区分人类和 agent 写入的线索。
适合什么场景
我觉得 Uteke 最适合先放在个人 agent workspace 或小团队共享环境里试。
如果你每天用 Codex、Claude Code 或其他 MCP client 修项目，它可以保存一些重复出现的事实：测试命令的坑、部署环境差异、某个模块的历史决策、上次排查未完成的方向。下次 agent 开始工作前，先按项目或 tag 召回，比把这些东西写进一个越来越长的 prompt 更可维护。
它也适合做轻量的“agent runbook”。比如把常见故障、服务名、排查顺序、禁止操作写成可搜索记忆。Agent 不是自动遵守所有内容，但可以在任务开始时查到更贴近本机和项目的上下文。
对更正式的团队知识库，Uteke 可能还不是最终形态；但对本地 agent memory，它的部署成本和隐私边界都比较舒服。
需要注意的地方
第一，项目非常新。仓库创建于 2026-05-29，目前只有 33 stars，latest release 是 v0.6.7。它适合试用和小范围工作流，不适合未经评估就作为团队关键基础设施。
第二，首次使用会下载 embedding model，README 和 Docker 文档里显示约 188MB。它比纯文本 notes 重，但比维护一套外部向量数据库轻。
第三，memory 不等于事实来源。Agent 记下来的内容可能过期、错误或缺少上下文。真正用于代码修改、部署和安全操作时，仍然要回到 repo、日志、配置和测试里验证。
第四，MCP 是显式工具，不是魔法记忆。文档也强调不会自动 recall 或自动抽取。要让它有用，需要在 workflow 里养成“关键结论写入、重要任务开始前召回”的习惯。
小结
Uteke 值得关注，是因为它把 agent memory 做得足够小：一个本地 binary，一个 SQLite-backed store，一组 CLI/HTTP/MCP 接口。
这类工具不会让 agent 突然拥有长期人格，也不会替代项目文档。但它能解决一个具体问题：那些每次任务都要重新解释、但又不适合上传到云端记忆服务的小事实，可以留在本机，并被 agent 用工具按需查出来。
如果你已经在真实项目里使用 MCP-compatible coding agent，Uteke 适合拿来做一个低风险实验：先存部署步骤、模块约定、排查结论和项目 caveat，再观察 agent 是否少问重复问题、少走旧弯路。它的价值不在“记住一切”，而在把可复用的工程上下文变成可查询的本地资产。