Files
CyberGril/docs/rework/hel874/README.md
T
zonggongandmultica-agent e291058754 HEL-882 rework: execution-table caps become real hard gates at the wire, SDK hidden retries and mid-add failures recover without loss, the 8360 release package runs offline, and the HEL-874 embedding evidence is corrected - every real provider exit (create/dialogue/life/gist/judgment/growth/proactive phrasing + mem0's internal extraction LLM) now persistently pre-allocates request count (per-category daily + one-shot totals in request_usage/budget_total, BEGIN IMMEDIATE) and a conservative token estimate before sending, refuses at the tightest cap (BudgetStop, no more downgrade-and-keep-calling) and survives restarts; known usage settles to actual, unknown/disconnect/failure keeps the full reservation; ledger guards gain per-day tops (embed_daily/llm_daily) and verify_ledger_authority rejects a fresh file bypassing the frozen 498/500 prefix; the mem0 SDK client's hidden OpenAI retries are disabled (max_retries=0) so every actual send is gated and answered failures (even 5xx) settle as used with only httpx.ConnectError-grade unsent requests released; embed refusals the SDK swallows into empty adds are re-raised as budget errors so the batch re-queues without burning an attempt and resumes when the cap returns, add_group resumes at vector-store level (src_group anchors: only missing rows resent, crash/restart/concurrency never duplicate), sem coverage is per-backend (stub batches no longer block a real rebuild, real done batches never resend) with backend-scoped batch keys; the release package is offline-executable: fresh-dir git clone, cybergril service account, PYTHONPATH in the unit so the lock-only venv imports the product, shipped caps explicitly 0 (=refuse by design until approved), deploy/mem0-stack.lock + accurate 3.11 wheel gap with a no-download path (hel857-venv is 3.10; never present stub/FTS as the real memory experience), and tools/check_release_offline_hel882.py verifies checkout/import/health/fail-closed/approved-run/data-preservation on loopback with echo stand-ins; evidence corrected per manager review: docs/rework/hel874/erratum-hel882.json + README appendix record that e978e87's verification did real local embeddings from cache (provable lower bound 12, exact total unrecoverable, temp sandbox gone) while zero-real-LLM/zero-download/zero-outbound stand, old JSONs and authoritative ledgers untouched, and tools/verify_mem0_real_hel874.py now installs the deterministic 512-dim stand-in before TextEmbedding construction plus non-loopback socket rejection (zero model loads) with final_embed_rows persisted before temp cleanup; verification: 272 python tests pass on 3.11.16 venv + requirements.lock offline (16 new: manager api repro blocked with 0 provider calls, sdk repro 1-HTTP/max_retries=0/llm_ops=1, mid-add swallow requeued-then-resumed, resume-no-duplicate, stub-to-mem0 rebuild, daily embed cap, unified mem0-LLM gate, authority refusal, restart-persistent counters, tightest-constraint settle/release), ruff clean (src/tests/tools), web tsc + 42 vitest + build via npm ci --offline, pinned-install deterministic re-run 12/12, manager review scripts re-run evidence attached in delivery, dual-target requirement checks 4/4 with handoff-HEL-882.json; zero real calls, zero real embeddings, zero non-loopback outbound, authoritative ledgers and freezes untouched, not deployed, PR not merged, no visual changes
Co-authored-by: multica-agent <github@multica.ai>
2026-10-26 23:20:18 +08:00

4.6 KiB
Raw Blame History

HEL-874 · 实际固定 Mem0 SDK 合同验证证据

运行脚本:tools/verify_mem0_real_hel874.py(仓库根,用 HEL-857 的固定 venv 执行; 零真实出站——LLM 走 127.0.0.1 确定性假网关,嵌入用已有本地 fastembed 缓存, 账本全部写在临时目录,不触权威三账)。

/home/.../hel857-venv/bin/python tools/verify_mem0_real_hel874.py docs/rework/hel874/real-sdk-after.json

固定安装事实(两份 JSON 的 install 字段):mem0ai 2.2.1、qdrant-client 1.20.0、 fastembed 0.9.1;源码 tarball SHA256 9dcef930…dda23 与 HEL-857 记录一致; 关键模块逐文件 SHA256 见 JSON。

结论(before = 31970c4 原适配层,after = 本卡修复后)

检查 before after 事实
C1 构造 失败 通过 before 在同一路径开第二个 QdrantClient,固定 SDK 直接拒绝:Storage folder … is already accessed by another instance of Qdrant client——31970c4 的 mem0 模式根本起不来。after 复用 SDK 自带 vector_store.client,不再另开 client。
C2 add 锚点/作用域 无法到达 通过 metadata(src_group/turn_roles/input_sha256)逐字落进 payload;user_id 作用域随 add 写入。
C2 每次真实开销 无法到达 通过 单行 add 实测 = 1 次提取 LLM + 2–3 条嵌入(phase1 查询嵌入 + phase3 提取批嵌入 + phase7 实体 upsert 嵌入),全部经包装记账。
C3 默认提取输入集 无法到达 通过 第二批 add 的提取提示实测包含第一批的提取记忆(旧记忆通道)与滚动 history——二者全部只来自此前过门批次,同一可证明输入集成立。
C3b 未分享 canary 无法到达 通过 植入主档案的未分享伴侣行经 enqueue/tick 后不出现在任何出站 LLM 请求体,也不进任何锚点。
C4 search 过滤参数 无法到达 通过 mem0 2.2.1 对无 user_id 过滤的 search 直接 ValueError(源码 main.py:1466 起);after 恒带 filters={"user_id": …}。limit= 形参在 2.2.1 被静默忽略,正确形参是 top_k。
C4 单次记账 无法到达 通过 每次 search 恰好 +1 条嵌入(before 设计上外层+包装双记,已在 fake-SDK 测试中证明并移除)。
C5 embed_cap=0 / llm_cap=0 无法到达 通过 任何真实工作前拒绝:假网关在此段收到 0 个请求;内部 LLM 现在过独立 llm_ops 闸(默认 0)。
C6 并发预占 无法到达 通过 8 路并发 search 对 cap=3 临时账,落账永不越 cap(BEGIN IMMEDIATE 预占)。
C7 关闭恢复 无法到达 通过 aclose 后同目录重建实例,数据与锚点完好。

判定为真实缺陷并已修复的项(来源:固定安装源码核对 + 本脚本实跑复现)

  1. 同路径双 QdrantClient → 构造即死(before JSON 的 trace)。
  2. 无过滤 search → 2.2.1 ValueError;limit 形参被忽略。
  3. search 外层+包装双记账。
  4. 内部提取 LLM 不过任何请求闸/账(embed 闸为 0 时也拦不住 LLM——本卡前 LLM 先于嵌入扣账的说法不成立:实测 phase1 嵌入在前,但 LLM 从未被计入 任何账)。
  5. 并发 check-then-debit 竞态可越 cap;失败/取消不回滚预占。

未发现问题的项(如实记录)

  • 真实 fastembed embed(text, memory_action) / embed_batch(texts, memory_action) 表面与适配层包装完全吻合(计数=落账)。
  • metadata 锚点在真实 qdrant payload 中逐字往返。
  • 滚动 history(save_messages 10 条窗)只含本产品此前 add 的原始消息。

勘正(HEL-882,2026-10-26,原文与前后 JSON 不改写)

本目录两份 JSON 的运行(e978e87 版脚本)发生过真实本地嵌入推理:脚本当时 只把 LLM 换成 127.0.0.1 假网关,没有替换 fastembed 边界——FastEmbedEmbedding 构造时加载了缓存模型,首条 add 即逐笔记了 3 笔真实向量推理 (embed_rows_after_first_add)。因此提交信息与执行表中「零真实嵌入」的说法 不成立;「零真实 LLM 请求/零下载/零非回环出站」仍成立。可证下限 ≥12 条真实本地嵌入(各分段合计,详见 erratum-hel882.json);精确总数因 临时目录随任务沙箱清除不可恢复。权威三账未写、未补改。

自 HEL-882 起,tools/verify_mem0_real_hel874.py 在 TextEmbedding 构造前安装 确定性 512 维向量替身(零模型加载、零真实嵌入),socket 层拒绝一切非回环连接 (与总管独立复现口径一致),并在清理临时目录前把逐笔账写进证据 JSON (final_embed_rows / final_llm_used)。