从 cognee 的 Issue 追踪器到 Rust 重写:ai-memory 如何把 2840 号问题的教训变成架构不变量
从 cognee 的 Issue 追踪器到 Rust 重写ai-memory 如何把 2840 号问题的教训变成架构不变量【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory本文基于仓库内调研文档 docs/issues-cognee.md源项目为 Python 的topoteretes/cognee2026-05-21 捕获系统拆解一个「知识图谱 向量 关系库」三存储架构的 Agent 记忆系统在真实 issue 追踪器里暴露的全部痛点并逐条对照 ai-memory 这个 Rust 单二进制重写项目在 docs/ARCHITECTURE.md 中落地的对应设计不变量。读完你将掌握cognee 六大类高频故障的完整 issue 清单、十个引发最多问题的设计选择、十二个「不要重蹈覆辙」的工程教训以及 ai-memory 在源码层面对每条教训的实证响应。文档背景一篇为 Rust 重写服务的「痛点合成」报告docs/issues-cognee.md不是一篇普通的产品介绍而是一份面向重写的架构审查输入。它的标题是Issue PR Pain-Point Synthesis捕获自 GitHub 上的topoteretes/cognee并给出了整个追踪器的画像约 40% 是 feature requests且评论数高约 40% 是 bug且大多能在下一个 release 快速关闭约 20% 是真正棘手、长期停留在架构接缝处architectural seams的未解决问题这份画像本身就是结论一个项目的高频 bug 分布能精确暴露它的架构债务分布。ai-memory 把这份 issue 清单当作「别人用几百个 issue 替你踩过的坑」在重写时以cross-cutting invariants跨切面不变量的形式逐条封死见 docs/ARCHITECTURE.md 的 invariants 一节每条 invariant 都注明了它对应的 prior-art issue 编号。仓库中还有两份同系列的姊妹文档可以交叉阅读docs/issues-agentmemory.mdTypeScript MCP Rust KV 引擎的 agentmemory与 docs/issues-mempalace.mdChromaDB 存储层崩溃密集的 MemPalace以及一份更完整的正面研究报告 docs/research-cognee.md。痛点 ALLM 适配层脆弱量最大、流失最快cognee 的官方口径是 the brain behind your agents其 LLM 网关是LiteLLM Instructor的组合LiteLLM 统一各家 provider 的 wire 协议Instructor 负责把 Pydantic schema 包装成结构化输出。但这份 issue 报告显示2026 年每家 provider 都出过 wire 级 bugAnthropic 适配器连续两个版本损坏#2749、#2782 两次都是因为调用时丢掉了max_tokens参数导致每次调用 HTTP-422——Anthropic 的 SDK 强制要求该参数丢失即全线 422。Ollama / LlamaCpp 适配器缺observe装饰器#2820。vLLM 挂死因为 system message 被发到了 user message 之后#2537。vLLM custom provider 不把LLM_ENDPOINT转发给 LiteLLM#2412、#2430、#2842。LiteLLM 的model_cost表覆盖了用户设置的LLM_MAX_COMPLETION_TOKENS#2608由 #2613、#2582 修复——即内置的成本表静默改写了用户显式配置。HTTP/2 流停滞导致串行 Anthropic 调用出现 60 秒超时#2607。非 OpenAI provider 的预检连接测试永久挂起#2752、#2123、#2380。macOS 上本地 OpenAI 兼容端点LM Studio / Ollama挂死#2119、#1743、#1742。未解决的开放问题 #2840Thinking Tokens Instructor 不兼容导致的严重性能退化。用户补丁揭示了根因链当response_modelstr时Instructor 把str包装成一个 JSON/tool schema而 llama.cpp 不认这个 schema → LLM 返回纯文本 → Instructor 解析失败 →tenacity 重试每次睡眠 8–128 秒。与此同时 LiteLLM 会静默丢弃chat_template_kwargs、reasoning_effort这类非标准顶层 kwargs用户被迫写extra_bodyshim 才能传进去。报告给出的根因判断一针见血LiteLLM Instructor 作为通用 LLM 网关两者迭代都快、都会静默丢弃自己不认识的 kwargs、且在结构化输出路径里都内置了 OpenAI 专属假设。ai-memory 的对应设计ai-memory 的响应是不变量 #7JSON-schema structured outputs only. Native provider JSON modes; no XML, no Instructor wrapping见 docs/ARCHITECTURE.md 的 invariants 列表明确标注cognee #2840。即宁可给每个 provider 写类型化客户端也不用一个通用 Python 式网关来吞参数。相关的行为在配置层也能看到AI_MEMORY_LLM_COMPAT_STRICT默认true关闭即禁用response_formatjson_schema这是对LLM 返回非结构化文本的显式降级开关而不是靠 Instructor 猜。AI_MEMORY_LLM_REASONING_EFFORT对reasoning_effort这类非标准参数做按 provider 显式映射OpenAI 走reasoning_effort、OpenRouter 走reasoning.effort、xAI Grok 走reasoning_effort、Anthropic 走output_config.effort、Codex 走reasoning.effort而不是依赖网关隐式透传宿主不支持的取值会被 clamp 到各 provider 已发布的枚举。这正是对 #2840 中LiteLLM 静默丢弃非标准顶层 kwargs的直接对冲。AI_MEMORY_LLM_BASE_URL只对openai-compat/opencode生效固定端点的 provideranthropic、openai、gemini、OAuth 后端、copilot会忽略它并记录原因——文档明确写着操作者遗留的 Ollama URL 绝不能静默把每个 Gemini 请求改写成 404。痛点 B多存储协调与数据完整性 bug图 向量 关系三存储tripartite store是 cognee 的架构承诺也成了持续产生高严重级 bug 的源头EntityAlreadyExistsErrorEntity(institution)与EntityType(institution)在 UUID 上碰撞#2510第二次cognify直接爆炸。add_data_points并行 DB 操作导致 SQLitedatabase is locked死锁到 1.0.2 仍可复现multiple PipelineRunErrored ... elapsed 561s before crash#2717OPEN。cognify在upsert_edges大批量约 4356 条边时超过 asyncpg bind-argument 上限#2829由 #2798、#2586 的分批修复。add_data_points遇到空字节0x00时 asyncpg 抛CharacterNotInRepertoireError崩溃#2612OPEN。index_data_points对 metadata dict 做浅拷贝只有第一个index_field被嵌入#2529OPEN。get_graph_from_modelcopy_model丢掉用户自定义的 DataPoint id#2633OPEN。retrieve_existing_edges中的边去重形同虚设#2557。delete_dataset在非 public 的 Postgres schema 下失败#2291。共享数据删除串扰从一个 dataset 删除会连带清掉共享同一份数据的其他 dataset#2732OPEN。/api/v1/cognify存在 N1 查询#2532OPEN。KuzuAdapter 在 0.5.1 上写入只在内存可见、不落盘#1981。brute_force_triplet_search的按集合距离归一化产生错误排序#2030修复 #2451 移除了归一化随后又在 #2720 暴露了下游问题。ai-memory 的对应设计针对 #2717 的 SQLite 死锁ai-memory 的不变量 #2 是Single-writer SQLite actor所有写操作通过一个mpscchannel 进入唯一一个专用 OS 线程。源码见 crates/ai-memory-store/src/writer.rs文件首行注释即//! Single-writer SQLite actor.内部以tokio::sync::mpsc传WriteCmd、以oneshot回传StoreResult读走 cloneable 只读连接池。这是从第一个里程碑就内建的单写者模型而不是事后补的锁。针对多存储隐式同步这一整类问题B 节的全部 integrity bug 都源于编排发生在 cognee 内部而不是任何事务层ai-memory 明确文档化边界markdown wiki 是唯一 source of truthSQLite 是派生索引docs/ARCHITECTURE.md 的 Storage architecture 一节wiki 写入走 crates/ai-memory-wiki 的原子写tmp rename fsync不变量 #10。大批量写#2829 的 bind-arg 上限在 ai-memory 侧对应每次 mutation 都进 audit log、观察清理按 batch 事务进行[decay] observation_prune_batch 5000每事务最多删 5000 行防止百万级清理长时间持有写锁。痛点 C召回质量回归——记忆服务最不能承受的 bug#2720OPENGraph-completion retrieval returns identical subgraph regardless of query。用户自建复现证明直接查 LanceDB 不同 query 返回不同 top-K但 cognee 的/api/v1/search返回几乎相同的答案——LanceDB 的 ID 没有传播进图投影。用户把原因归咎于 #2451 的连锁反应brute_force_triplet_search.py里的下游阈值仍按 #2451 之前的 [0,1] 尺度静默回退到不过滤的图。SearchType.CHUNKS静默忽略node_name过滤#2815。CHUNKS/SUMMARIES/GRAPH_COMPLETION在ENABLE_BACKEND_ACCESS_CONTROLfalse时忽略datasets过滤#2867——维护者的回答本质是datasets 只在 access control 开启时有效。cognee-mcp 的 GRAPH_COMPLETION 丢弃除第一个之外的所有 dataset#2617。TemporalRetriever只支持事件堵死了本体全宽的时间过滤#2429以内部 Q2 重设计为由关闭但并未发布。GRAPH_COMPLETION 不搜索自定义 DataPoint 向量集合#2495。ai-memory 的对应设计报告在第 4 条 do-not-repeat 教训里写得很重Treat retrieval filter propagation as a first-class invariant with property tests. Show test cases likeassert different_queries_yield_different_subgraphs. The exact bug in #2720 is what kills a memory product.ai-memory 的检索路径是FTS5 实体匹配 链接邻居 RRF 可选向量 RRF且实体索引派生自页面 frontmatter 的权威entities列表空索引不贡献任何候选或分数见 docs/ARCHITECTURE.md 数据流第 6 步当已编译的 wiki 页面在默认/显式 project/scopes 模式下完全未命中时才退回受约束的原始 observation FTSraw_hits。globaltrue则只搜已编译页面——每个 stream 都是过滤器在查询期强制生效不存在 #2720 那种向量命中到图子图路径上把过滤丢掉的隐式管道。测试侧有 crates/ai-memory-consolidate/tests/recall_eval.rs 的召回评测框架。痛点 D依赖安装地狱macOS arm64 Python 3.14kuzu没有对应 wheelquick-start 直接失败#2753。Docker 镜像自 v1.0.4 起ModuleNotFoundError: No module named kuzu——kuzu 被移除但镜像没重建#2775。fastembed因某个传递依赖不是 Apache/MIT 许可而被整体移出 Docker 镜像#2807。LiteLLMEmbeddingEngine 把BAAI/bge-m3截断成bge-m3#1915。embedding_dimensions默认硬编码为 3072 而不管模型——所有非 3072 维的 embedder 全部损坏#2751修复 #2757。LanceDB lance-file writer schema drift / contained null values RuntimeError 绕过自动迁移#2702、#2768。Pydantic v1/v2 摩擦与 openai-agents 的上界冲突#2019、.json()被弃用#2042、泛型校验问题#1198。Mistral client import error#2481。lru_cache对 Vector/Graph 配置的 hash 失效 bug#2357最终在 PR #2853 里被整体禁用refactor: reduce lru cache。ai-memory 的对应设计ai-memory 的回应是把依赖风险前置到架构层单二进制、静态链接rusqlite默认路径零 LLM 调用不变量 #13。原生重型依赖onnxruntime 之类的 ML 栈、独立原生 sidecar 二进制被明确回避。嵌入向量默认embedding_dim不硬编码OpenAI 1536、Voyage 1024、Google 768且openai-compat必须显式声明AI_MEMORY_EMBEDDING_DIM——文档原话是self-hosted engines have no safe shared model or dimensionality default见 docs/ARCHITECTURE.md Embedder env 一节。这正是 #2751默认 3072 打爆所有非 3072 维模型的解毒剂。sqlite-vec向量扩展被有意推迟到 v0.2见 docs/vector-backend-policy.md目的明确避开原生绑定/平台崩溃这一类依赖风险当前page_embeddings用打包[u8; dim * 4]的 BLOB 存向量见 crates/ai-memory-store/migrations/V04__embeddings.sql朴素余弦在小规模数千页完全够用。未来的本地嵌入M9.5ort打包bge-small-en-v1.5也作为独立里程碑推进而不是一上来就引入重型依赖。痛点 EMCP 服务器与 FastAPI 的落差MCP 包装层始终落后于核心 APIMCPcognify传入有效本地文件路径却返回成功但未创建任何 Data item#2250OPEN。cognee-mcp Quick Start 在 macOS arm64 Py 3.14 失败#2753。cognee-mcpcognify(datastr)因硬编码的data.txt文件名在首次写入后静默丢弃所有写入#2747。MCP recall 在默认配置下失败NoneType object has no attribute id——wrapper 没有把 user 传给cognee.recall#2855。cognee-cli--api-url不支持 remember/recall/improve/forget#2809OPEN。前端 Docker 构建损坏#2832、Turbopack import 大小写不匹配#2605、cognee-cli -uiv0.5.5 缺 3 个 npm 依赖#2413、UI 编译错误#2709。ai-memory 的对应设计ai-memory 的 MCP 表面19 个工具见 docs/ARCHITECTURE.md 的 MCP tool surface 一节由 crates/ai-memory-mcp 的 rmcp 传输 工具路由实现与 HTTP 入口共享同一套 auth、scope resolver 和 tool handler——不存在MCP wrapper 是另一套实现的落差来源。工具语义与文档严格绑定memory_query只读、memory_handoff_accept消耗性、memory_forget_sweep支持dry_runtrue预览类型化McpError变体对应正确的 JSON-RPC 错误码这一条在姊妹文档 docs/issues-mempalace.md 中作为对 MemPalace #1574 的对照被点名验证。痛点 F认证 / 多租户回归Token 刷新机制根本没实现维护者承认我们不得不在自己的云部署里重写它。目前我们抽不出资源。#2065。请求级 LLM 配置不可能实现因为get_llm_config()和get_embedding_config()用了lru_cache——全局单例#2228。关闭认证需要两个 flagENABLE_BACKEND_ACCESS_CONTROLfalse并且REQUIRE_AUTHENTICATIONFalse#2808修复 #2836。cognee.search在按名解析 dataset 时对非 owner 忽略 ACL#2845cognee.add在非 owner 复用同名时静默创建一个 owner 作用域的新 dataset#2846cognify静默跳过非 owner 添加的数据#2847。Agent 显示名泄露用户 ID#2811。GRAPH_DATASET_TO_DATABASE_HANDLER用户拼错的 env var被静默忽略并默认落到 kuzu#2697——env var 名字没有任何校验。ai-memory 的对应设计不变量 #12No global singletons /lazy_staticconfigs. All deps explicit标注cognee #2228。配置只有一条读取路径不变量 #1Config::load()启动时一次解析代码内禁止std::env::var散落调用天然不可能出现 #2697 那种拼错的 env var 被静默忽略的情况——未知键会在启动时失败而不是默认落到某个后端。多租户隔离不依赖一个全局开关文档明确dataset 是每个 retriever 上的硬性查询期过滤器无论 access control 是否开启第 9 条教训且当前项目指针按调用方隔离README 中docs/auto-scope.md的[auto_scope]模式。这与 cogneeaccess control 关掉 → 所有 dataset 级检索静默退化#2867、#2845、#2846、#2847、#2808形成直接对照。ai-memory 的多用户模型密码会话、API key、四档 bearer、审计日志内建于核心users、api_credentials、audit_log、password等模块见 crates/ai-memory-store/src并配合memory_handoff_*工具的 owner-scoped 语义sharedtrue才发布给项目。引发最多问题的十大设计选择报告将 issue 追踪器回溯到 10 个根设计决策lru_cache全局单例配置。破坏多租户#2228、hash 失效 bug#2357最终被回退#2853。LiteLLM Instructor 作为通用 LLM/结构化输出层。#2412、#2430、#2537、#2608、#2613、#2749、#2782、#2820、#2840、#2842 全部由此而来。SQLite 作为默认关系后端 greenlet 并行。#2717并行 cognify 下database is lockedOPEN。维护者打太极sqlite 不是为生产用例准备的。Kuzu 作为默认嵌入式图库。Kuzu 上游归档#2098维护者选择用LadybugPR #2755替换——一个fork。替换后立刻出现 #2768、#2775、WAL 损坏PR #2838。fork 图库的风险已经兑现。LanceDB 作为默认向量库假设 schema 迁移会自动处理 drift。现实是 #2702 的空值绕过迁移、#2720 检索管道在向量命中→图子图路径上丢过滤。三存储 隐式同步图 向量 关系 可选本体。B 节整类 integrity bug 的源头编排在 cognee 内部完成没有任何事务层。lru_cache ContextVar 混合租户隔离模型。#2228 说明db 配置用 ContextVar 模式LLM 和 embedding 配置却不用。brute_force_triplet_search的按集合距离归一化#2030——修复 #2451 移除归一化打破下游阈值假设浮出为 #2720。后端访问控制成了编排平面。ENABLE_BACKEND_ACCESS_CONTROLfalse时所有dataset 级检索静默退化#2867、#2845、#2846、#2847、#2808。默认 LLM 成本耦合embedding_dimensions默认 3072text-embedding-3-large且 litellm 的model_cost表静默覆盖用户的max_completion_tokens。两个 bug 都来自假设 OpenAI 默认值#2751、#2608。维护者的修复动作揭示了什么LRU cache 配置已被悄悄撤退#2853、#2851。新增子进程模式 Redis明确为逃离 SQLite-greenlet 陷阱#2803、#2812。Ladybug 是他们自己拥有的 Kuzu fork已发布 fix: resolve issue with WAL file corruption for ladybug#2838。LanceDB schema drift 自动迁移是事后补的#2703因为 lance-file writer 曾让 worker 崩溃。Anthropic 适配器整整坏了一个版本周期——#2749 修好后在 1.0.5 又被 #2782 弄坏。默认值翻转fastembed移出核心#2807、result-cache 日志默认关闭#2851、embedding 维度改为自动推导而非默认值#2757、认证收敛为单一开关#2836。功能被弃用而非修复TemporalRetriever#2429。维护者尚未解决的开放问题#2717 并行 cognify 下的 SQLite 死锁——跨版本可复现。#2720 LanceDB 过滤不传播到图投影——核心检索路径上的正确性bug无人认领。#2840 Thinking-token Instructor 不兼容。#2532/api/v1/cognify的 N1 查询。#2612 asyncpg 空字节崩溃。#2529index_data_points浅拷贝 bug。#2228 请求级 LLM/embedding 配置架构性问题。#2065 token 刷新推给社区。报告的判断是这些问题的共同特征是全部坐在架构接缝上配置平面、检索管道、异步编排没有一个能靠单个 PR 修完。这正是重写时用架构不变量封死而非逐个 issue 打补丁的理由。依赖 culprits 一览表报告最后给出一张按库归因的表格可作为评估依赖风险时的直接参考库问题Issuelitellm静默丢弃extra_bodykwargsmodel_cost覆盖用户设置#2608, #2613, #2840instructor把response_modelstr包装成本地 LLM 不认的 JSON schema#2840tenacity8–128s 退避放大 instructor 的解析失败#2840asyncpgbind-arg 上限\0触发CharacterNotInRepertoireError#2829, #2612lancedb / lance-file空值 RuntimeError 绕过迁移#2702pyarrowlance 底层#2720 / #2702 schema drift 的上游#2702kuzu上游归档Py 3.14 / arm64 wheel 缺失#2098, #2753ladybugkuzu fork每次新建 DB 都版本映射崩溃WAL 损坏#2768, PR#2838sqlite/sqlalchemy/greenlet并行 cognify 下 database-is-locked#2717anthropic SDKmax_tokens必填连续两版损坏#2749, #2782fastembed传递依赖非 Apache/MIT移出核心#2807pydanticv1/v2 摩擦、弃用.json()、上界冲突#1198, #2019, #2042mistralaiclient import error#2481openai-agents与 pydantic 的 pin 冲突#2019HF tokenizers分块时每个词都触发 HF 请求#729Turbopack / npm前端构建反复损坏#2605, #2413, #2709, #2832给 Rust 重写的 12 条 do-not-repeat 教训与 ai-memory 实现对照以下是原文档的 12 条教训全文每条都附上 ai-memory 在源码与文档中的实证响应不要把 LLM 调用放在一个会静默丢弃 kwargs 的通用 Python 式网关后面。每个 provider 用类型化 Rust 客户端遇到未知字段报错而不是丢弃#2840、#2608、#2782。ai-memory 响应不变量 #7 的 JSON-schema-only 策略 逐 provider 的 reasoning_effort 映射AI_MEMORY_LLM_HEADERS中 ai-memory 自己会设置的 headers 在启动时被拒绝杜绝静默改写。别用 SQLite 承载写并行管道状态。用 Postgres嵌入式场景用 LMDB/Sled/SQLite-with-WAL 前面的单写者 actor 队列串行化#2717。ai-memory 响应不变量 #2 的mpsc单写者 actorcrates/ai-memory-store/src/writer.rsSQLite 开 WAL 模式读走独立只读池。文档另有铁律one server per data directory, never twodocs/deploy.md。别把 fork 的嵌入式图库钉死为默认。要么用久经考验的外部存储Postgres AGE、Neo4j要么直接在关系库上实现图原语。Kuzu→Ladybug 的转向真实地伤害了用户#2098、#2768、#2775、#2753、PR#2838。ai-memory 响应根本不引入图数据库图的邻居关系来自 wiki 页面的 wikilink/实体链接索引links表 entity_page_links见 crates/ai-memory-store/migrations 的 V05/V07/V13/V38图是关系库上的派生结构。把检索过滤传播当作一等不变量用 property test 守护。要有assert different_queries_yield_different_subgraphs这样的用例。#2720 正是杀死一个记忆产品的 bug。ai-memory 响应检索 FTS5 entity-match link-neighbour RRF可选向量 RRF 受约束的 raw fallback过滤器在每个 stream 的查询期强制生效crates/ai-memory-consolidate/tests 下有 recall_eval、search_quality 等召回评测套件。配置从第一天起就必须是请求级的。不要全局单例、不要lru_cache配置用显式传递的请求级上下文类型#2228、#2357、PR#2853。ai-memory 响应不变量 #1单条配置读取路径 不变量 #12无全局单例Config::load()启动解析一次全依赖显式注入。永远不要把embedding_dimensions默认成常量。启动时按(provider, model)推导collection 维度与模型维度不匹配就拒绝启动#2751、#2757。ai-memory 响应不变量 #8 ——{provider, model, dim}反规范化到每条 embedding 行旁边不匹配时警告并忽略陈旧向量直到重嵌入完成agentmemory #469 是另一处引用来源。Schema 实证见 crates/ai-memory-store/migrations/V04__embeddings.sqlprovider TEXT NOT NULL, model TEXT NOT NULL, dim INTEGER NOT NULL CHECK (dim 0)且索引注释写明Used by the refuse-on-mismatch startup check。幂等摄入 显式 id 推导。Node ID 必须是(category, name, dataset)的函数用 property test 守护跨运行确定性#2510、#2557、#2633。ai-memory 响应typed 3-tuple 身份(workspace_id, project_id, path)从第一天起落在每个领域行上不变量 #4页面版本链is_latestsupersedes提供确定性寻址。重复摄入 / pipeline-run 状态必须是状态机不是一个 flag。PipelineRunAlreadyCompleted曾阻止对已删除文件的重新摄入#2097。ai-memory 响应sessions.ended_observation_count作为重开会话可再次结束的稳定代际水位线不依赖墙钟结束路径与补发递送可收敛重放。Dataset 隔离在 access control 开或关时都必须工作。Dataset 是每个 retriever 上的硬查询期过滤器#2867、#2845、#2846、#2847。ai-memory 响应project/scope 过滤内建于查询期FTS 查询带 scope 约束当前项目指针默认按调用方隔离docs/auto-scope.md 进一步提供 session-aware 与 per_actor 模式。批量执行每一次跨存储 mutation。asyncpg bind-arg 上限、SQLite 锁、lance writer flush——全部根源于无界扇出#2829、#2717、#2702。ai-memory 响应观察清理按observation_prune_batch默认 5000 行/事务分批page_access强化写入被节流到每页每分钟至多一次防止检索突发淹没写者 actor。要么单一事务边界要么文档化的最终一致性契约。cognee 在 graph/vector/relational 间的静默跳过是最深的一类 bug必须二选一原文档没有给出明确 issue 编号属于综合判断。ai-memory 响应wiki 是唯一事实源 SQLite 是派生索引的边界被反复强调页面 upsert、embedding、audit 等写入在服务端同一路径内完成避免前台返回成功、后台索引丢失不变量 #3索引与数据同一事务提交。审计日志与结果缓存从第一天起就要有保留策略。cognee 的关系库无界增长——9 天攒了 42k 条缓存结果#2548后来默认关闭。要在第一个用户撞上之前做掉。ai-memory 响应audit_log表记录每一次 mutation可at DESC寻址结果缓存/日志策略在架构文档中明确默认关闭[decay]配置带硬删除与墓碑tombstone语义。校准文档原话按严重度与复现率加权被重复最多的教训是——LLM/结构化输出层LiteLLM Instructor脆弱且多存储同步graph vector relational是正确性 bug 的最深来源。A Rust rewrite that gets either of those wrong inherits cognees tracker.一个 Rust 重写如果在这两者上犯错就会继承 cognee 的 issue 追踪器。结语这份文档在 ai-memory 中的用途docs/issues-cognee.md属于仓库 docs 目录下的research 文档一族README 的 Docs 表格将其归类为lessons-learned from upstream issues它的定位不是功能手册而是架构决策的防错输入——连同 docs/issues-agentmemory.md、docs/issues-mempalace.md 一起构成 docs/ARCHITECTURE.md 中每条跨切面不变量背后的为什么。当你读 crates/ai-memory-store/src/writer.rs 的单写者 actor、crates/ai-memory-store/migrations/V04__embeddings.sql 的维度校验 schema、或 docs/vector-backend-policy.md 中sqlite-vec 推迟到 v0.2的决定时你实际上看到的是 #2717、#2751、#2840 这些 cognee issue 在另一门语言里的反事实答案。延伸阅读完整的正面研究报告见 docs/research-cognee.mdcognify 管道、三存储后端、16 种检索策略、memory lifecycle同类痛点合成见 docs/issues-mempalace.md 与 docs/issues-agentmemory.md不变量总览见 docs/ARCHITECTURE.md。【免费下载链接】ai-memorySolution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors项目地址: https://gitcode.com/GitHub_Trending/ai/ai-memory创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
上一篇/下一篇内容由系统自动关联
返回资讯列表 →