尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

Friend 后端 Memory Continuity Gauntlet Gates:canonical 记忆流水线的六级连续性验证关卡

发布时间:2026/9/15 19:42:09

资讯中心
01
ARTICLE

Friend 后端 Memory Continuity Gauntlet Gates:canonical 记忆流水线的六级连续性验证关卡

Friend 后端 Memory Continuity Gauntlet Gates:canonical 记忆流水线的六级连续性验证关卡
Friend 后端 Memory Continuity Gauntlet Gatescanonical 记忆流水线的六级连续性验证关卡【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend导读本文系统讲解 Friendomi开源仓库后端记忆系统在**记忆连续性memory continuity**维度上设立的一整套关卡Gauntlet Gates验证体系。它回答一个核心工程问题当 canonical memory 从采集capture→ 合并consolidate→ 晋升promote→ 读取read整条流水线被重构、或上线新记忆版本memory v3时如何用可重复、可留痕、可区分的多层测试来证明记忆不会断、不会漏、不会串读完本文你将掌握六类关卡的各自覆盖范围与边界、它们为何不能互相替代、以及如何在 CI 与本地环境实际运行它们含全部命令与关键源码依据。一、背景为什么需要连续性关卡Friend 后端的记忆系统canonical memory不是单条 SQL 语句而是一条跨 Firestore、向量库Typesense、短期晋升 worker、多种读取 surface 的持久化流水线。任何一环的回归——例如 projection 失败时回退读取了遗留格式记忆legacy bleed、晋升绕过了 durable outbox、archive 记忆被默认读取误曝——都会直接破坏用户记忆的连续性与隐私边界。为此仓库在 backend/docs/memory-continuity-gates.md本文关联文档原先是backend/AGENTS.md的一部分因体积门槛独立成文中定义了一套Memory Continuity Gauntlet Gates。文档开头特别强调了两条不可混淆的规则绿色的 live gauntlet 并不证明 hermetic 流水线不变量成立hermetic 测试并不证明部署后端的连续性成立。也就是说这套体系刻意由互补而非互替的多个关卡构成。任何一个关卡通过都不能替代另一个关卡任何人在宣称canonical-memory 上线关卡已满足之前都必须先读完这份文档。二、六级关卡总览覆盖范围与不覆盖边界原文档用一张表格界定了全部关卡这是整套体系的地图完整继承如下关卡覆盖内容不覆盖内容Hermetic pipeline E2Etesting/e2e/test_canonical_memory_pipeline.pycapture→consolidate→promote→read、archive 排除在默认读取之外、surface 默认访问矩阵、projection fail-closed 且无 legacy bleed部署后的 revision 身份、生产 IAM/索引差异、真实 LLM consolidationListen/Pusher durable finalization gauntlettesting/listen_pusher_stack真实持久化会话处理转换、fanout lease、MEMORY_ENABLED解析器/围栏、围栏后的 provider leaf、以及 unset-fence 负面路径provider 输出质量、生产配置身份、inline 协议场景中被 mock 的记忆路径Gauntlet--self-check必需文件、canonical_memory_pipelineworkflow 注册、suite/nonce wiring在 memory-continuity-gauntlet.py 中任何记忆写入或 HTTP 探测Live gauntletmemory-continuity-gauntlet.sh需ADMIN_KEY 可达后端在运行中后端上按 suite 执行结构化/v3/memories探测Gate 2 完整合成矩阵、Gate 3 生产激活Gate 2 dev-cloud proofv3_dev_cloud_proof.py 已部署分支 revision多用户合成矩阵、索引、IAM、auth、dev-cloud 回滚本地 hermetic fakes不等于生产激活Gate 3 production proof按docs/rollout/memory-v3-proof-order.md顺序执行Gate 2 GO 之后的生产特有差异 独立评审替代 hermetic pipeline E2E 或 gauntlet self-checkCI 只运行python3 backend/scripts/memory-continuity-gauntlet.py --self-check。Live suites 在凭据/后端不可用时如实记录NOT_RUN——绝不伪造GO。三、关卡一Hermetic pipeline E2E——闭环流水线与默认访问矩阵这是整套体系中最核心的不变量证明层位于 backend/testing/e2e/test_canonical_memory_pipeline.py。它通过 fakesfakes.firestore、fakes.redis、fakes.storage与FastAPI TestClient在进程内构建隔离后端跑通真实业务代码路径。3.1 capture → consolidate → promote → read 闭环主测试test_capture_consolidate_promote_read_archive_excluded_vectors_and_delete_outboxL223按真实时序验证Capture通过POST /v1/conversations/{id}/reprocess会话入口monkeypatch 掉process_conversation后走真实的write_canonical_extraction_memory写入一条 short-term 记忆断言tier short_term、status activeL233-L237。Consolidate/Promote调用真实的run_canonical_short_term_maintenancepromotion worker 主函数以脚本化 LLM_scripted_consolidation_llm驱动合并决策断言promoted_count 1、tier long_term、graph_ready is True且生成了graph_assertion_idL239-L255。Vector outbox 纪律晋升后立即检查向量存储断言provider_id not in vectorscanonical apply 不得绕过 durable outbox随后显式 drain 真实 canonical outbox_drain_canonical_outbox断言产生vector_upsertaction、向量以用户隔离的canonical_memory_provider_id出现、metadata 携带memory_layer long_termL257-L280。ReadMemoryService.read默认读取能看到晋升后的记忆archive 条目与short-term 之外的默认读取保持正确的可见性集合。Delete 与隐私收据delete_canonical_memory删除条目后必须留下memory_deletion_receipt.v2收据且收据中不得包含 memory_id 本身防止隐私元数据残留向量同步清除L334-L355。3.2 Fail-closedprojection 失败时不得回退泄漏 legacy 记忆第二个测试test_universal_repository_failure_fails_closed_without_historical_bleedL357在 Fake Firestore 中预先种入一条遗留格式记忆legacy-must-not-bleed然后让MemoryService.read抛503 infrastructure_failure断言 API 返回 503、错误 detail 透传、响应体中绝不出现 legacy 记忆内容。这验证了fail-closed 优先于降级兜底的设计。3.3 Surface 默认访问矩阵TestSurfaceDefaultAccessMatrixL433用参数化用例覆盖六种读取 surfacechat_text、chat_list、developer、agent_tools、mcp、product_searchSURFACE_MATRIX_CASESL423-L430。每种 surface 都断言archive 条目被排除、可见条目可检索同时验证无授权 consumer 时read_decision DENY_MEMORYrollout 读门控拒绝。这是archive 不参与默认读取这一产品不变量在全部读取入口上的矩阵式证明。四、关卡二Listen/Pusher durable finalization gauntlet——持久化会话处理转换Hermetic E2E 覆盖的是记忆流水线本身而记忆的采集源头——listen WebSocket 会话 → pusher → finalization worker 的持久化链路——由独立的 backend/testing/listen_pusher_stack 本地 gauntlet 负责。运行方式见其 READMEbackend/testing/listen_pusher_stack/run.sh --keep4.1 真实栈 严格回环该 harness 启动隔离 Redis、本地 ASGI 进程与 Firestore emulator自动挑选独立端口跑的是生产 listen 运行时main:app、真实 pusher router、二进制帧 101/102/103/104/201、真实 Cloud Tasks finalization handler。子进程环境白名单化私有空HOME、无 provider 凭据、拒绝非 loopback Firestore 端点。4.2MEMORY_ENABLED围栏与 post-fence leaf这是该关卡与记忆连续性直接相关的关键设计强制 Cloud Tasks 路径设置MEMORY_ENABLEDon执行生产解析器和围栏fence然后证明围栏之后的 provider leaf 真实运行负面场景 unset 该标志证明 durable job 保持可重试、post-fence leaf 不运行、仅发出无标识符的 boundedmemory_fence诊断。也就是说记忆写入在 finalization 链路中被一个显式的开关围栏fence守护开关关闭时宁可让任务挂起重试也不静默写记忆。Cloud Tasks 入口只替换 provider-side leafLLM 摘要生成、MemoryService.ensure_canonical_mutation_ready之后的 canonical memory 工作、外部集成投递等持久化与内存安全围栏之下全是真实代码。4.3 十一类场景README 列出 11 个场景含 #9960 的 pending-finalization 恢复路径、worker 两attempt 预算耗尽后原子 dead-letter 并标记会话failed/discarded、RECORDING_SESSION_MODEenforce下操作级故障注入等。其定位是确定性本地故障测试明确不测真实 Parakeet 推理、LLM/向量质量、GCS 与外部集成投递。五、关卡三与四Gauntlet--self-check与 Live gauntlet这两个关卡都由统一的驱动脚本 backend/scripts/memory-continuity-gauntlet.py 实现shell 包装 backend/scripts/memory-continuity-gauntlet.sh 只负责exec python3透传参数脚本头部注释里写着全部用法。5.1--self-checkCI 的看门狗python3 backend/scripts/memory-continuity-gauntlet.py --self-checkself_check()L159不做任何记忆写入或 HTTP 探测只做静态结构性校验必需文件存在REQUIRED_SELF_CHECK_PATHSL31-L37包括驱动 py/sh、E2E 测试、backend/tests/unit/test_inv_mem_1_guard.py与backend/testing/workflow_contracts.jsonworkflow 注册canonical_memory_pipelineworkflow 必须存在于workflow_contracts.json且注册testing/e2e/test_canonical_memory_pipeline.pyL186-L192contract 定义见 backend/testing/workflow_contracts.jsonsuite/nonce wiring驱动源码必须包含六个 suite tokencapture/promote/recall/archive/surfaces/resilience、三种 nonce kindCAPTURE/PROMOTE/ARCHIVE以及--self-check自身标志L173-L184。这正是文档表格中--self-check只证明文件与 wiring、不证明任何记忆行为的来源——它是一道成本极低的 CI 闸门防止有人在删文件/改 suite 名时悄悄破坏整套 gauntlet。5.2 六个 suite 与 nonce 证据六类 suiteSUITE_NAMESL39capture、promote、recall、archive、surfaces、resilience别名pipelinecapture→archive与allL40-L43。每次运行生成三种随机 nonceMEMGAUNTLET-{run_id}-{hex}-{KIND}L54-L57写入被写记忆的 content 中——后续 suite 用该 nonce 作为检索 token 验证这条记忆确实经历了 capture→promote→recall从而把连续性变成可断言、可留痕的事实。Hermetic 模式默认无凭据时自动回退复用 E2E 的 fakes 与 TestClient跑完每个 suite 的真实业务函数surfaces在五个 surfacechat_text/chat_list/developer/agent_tools/product_search上逐一断言 archive nonce 不出现、可见记忆出现resilience让MemoryService.read抛 503 后断言/v3/memoriesfail-closed 且 legacy 不泄漏L655-L686。5.3 Live gauntlet运行中后端的结构化探测# 本地起后端后 ./backend/scripts/memory-continuity-gauntlet.sh --suite capture,promote,recall MEM_GAUNTLET_API_URLhttp://127.0.0.1:8080 ./backend/scripts/memory-continuity-gauntlet.sh --live模式决策逻辑resolve_modeL353-L359--live强制要求 live 模式live_env_probeL203-L219检查ADMIN_KEY存在、GET /health可达未传--live时若MEM_GAUNTLET_PREFER_LIVE1且环境可用则走 live否则回落 hermeticMEM_GAUNTLET_FORCE_HERMETIC1强制 hermetic。Live suite 只做结构化探测用Authorization: Bearer {ADMIN_KEY}{uid}请求GET /v3/memories仅接受200/403/503状态L688-L695并摘要响应体items_count或detail写入证据。它不做记忆写入——这正是文档说live gauntlet 覆盖结构探测、不覆盖完整合成矩阵的含义。当 live 不可用时suite 记录NOT_RUN且 manifest 的passed只有在所选 suite 中至少一个达到 GO 且无失败时才为 trueL771-L774从机制上杜绝全部 NOT_RUN 却被标绿。5.4 证据包evidence bundle每次运行在backend/.harness/memory-continuity-gauntlet/{run_id}/下生成manifest.json记录 run_id、git SHA、模式与原因、nonce、每 suite 的 status/mode/steps/failures/warnings。通过时创建latest-green符号链接并追加INDEX.mdL88-L103超过 7 天的非 green 运行目录会被自动清理PRUNE_ABORTED_BUNDLE_DAYS 7。所有证据以时间戳 git SHA 留痕保证谁在哪个 revision 上、以什么模式、断言了什么全程可追溯。六、关卡五与六Gate 2 dev-cloud proof 与 Gate 3 production proof前四道关卡是工程闸门后两道是发布决策关卡Gate 2 dev-cloud proof在 dev-cloud 上以多用户合成矩阵验证完整记忆 v3 语义覆盖索引、IAM、auth并具备回滚预案。它证明这套东西在类生产基础设施上、多用户并发下也成立——这是本地 hermetic fakes 无法提供的证据但 dev-cloud 不等于生产激活。Gate 3 production proof仅在 Gate 2 判定 GO 之后针对生产特有差异真实流量、真实 IAM/索引、真实配置做验证并需要独立评审。它同样不能替代 hermetic pipeline E2E 或 gauntlet self-check——三道关卡各司其职。七、实操速查与设计原则7.1 命令速查目的命令CI 静态看门狗python3 backend/scripts/memory-continuity-gauntlet.py --self-check默认全 suitehermetic 回退./backend/scripts/memory-continuity-gauntlet.sh选择 suite./backend/scripts/memory-continuity-gauntlet.sh --suite capture,promote,recall强制 live 探测MEM_GAUNTLET_API_URLhttp://127.0.0.1:8080 ./backend/scripts/memory-continuity-gauntlet.sh --live强制 hermeticMEM_GAUNTLET_FORCE_HERMETIC1 ./backend/scripts/memory-continuity-gauntlet.shlisten→pusher finalization gauntletbackend/testing/listen_pusher_stack/run.sh --keep查看证据backend/.harness/memory-continuity-gauntlet/INDEX.md与各 run 的manifest.json7.2 核心设计原则关卡互补、绝不互替green live gauntlet 不证明 hermetic 不变量hermetic 测试不证明部署连续性Gate 2 不证明生产激活——这是文档第一原则NOT_RUN 优于假 GOlive 凭据缺失时如实记录NOT_RUN且全部 NOT_RUN永远不能算通过nonce 证据链随机 nonce 贯穿 capture/promote/archive把连续性变成可检索、可断言、可留痕的客观事实fail-closed 纪律projection 失败返回 503 而非降级读取 legacy记忆围栏关闭时任务挂起重试而非静默写入证据可追溯每次运行记录 run_id git SHA 模式 断言步骤green 运行建立索引aborted bundle 定期清理。这套六关卡 两级发布证明的结构为依赖长期记忆的产品提供了一个可复制、可留痕、抗回归的质量模型任何宣称canonical-memory 上线关卡已满足的改动都必须逐关对照本体系举证缺一不可。【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。