从 Memory Prize 黑客松评审看 Claude-Mem：17 个提交的接入深度、评分体系与集成陷阱清单

这篇技术指南基于仓库内真实发生的评审文档 05-memory-prize-scorecard.md：为 "$1,000 Memory Prize"（"打造一个真正会记忆的 agentic 工具"）征集到的 17 个黑客松项目，逐个克隆、通读并与 claude-mem 逐行对照后给出的评分与复盘。你可以从中得到两样东西：一套可复用的"记忆类工具集成质量"五维评审方法，以及一份从真实失败里总结出的"如何正确对接 claude-mem worker"的可执行清单——端口公式、路由表、响应信封、检索栈，全部可在本文最后的源码对照小节中验证。

---

评审背景：claude-mem 提供一个"被构建的基座"

评审文档首先明确了 claude-mem 的定位：它是"第二个 agent"——在一旁观察你的主编程 agent 的工作，把结构化的 observations 写入本地 SQLite 数据库，并在下一次会话开始时把一条"标题优先"的 timeline 交还给你。Prize 挑战要求黑客们在这一基座上搭建东西，七大奖项类别为：

• warm boots（冷启动预热，让新会话带上旧记忆）；
• timeline-driven retrieval（时间线驱动的检索）；
• memory UIs（记忆可视化界面）；
• integrations with other tools（与其他工具集成）；
• custom ingestion modes（自定义摄取模式）；
• real-time reactions to observations（对 observations 的实时反应）；
• token-saving speed plays（省 token 的速度玩法）。

加赛决胜标准只有一条：一个真实开发者会在周一早上真的去用它吗（Monday morning test）。

说明：本文全部项目结论均为原评审文档的记载；claude-mem 本身的端口公式、路由与分页信封等实现细节，则以当前仓库源码为准，在文末有逐条对照。

评审方法论：五条轴线，每条 0–5 分

评审团队克隆了全部 17 个仓库，读遍每一个触碰 claude-mem 的文件，并把每一条声称的集成"追到具体那一行代码"。然后按五个问题打分（满分 25）：

1. Integration depth（接入深度）
   • 0：claude-mem 完全没出现；
   • 1：仅在文档里被点名；
   • 2：浅读 SQLite 数据库，或对 worker 做一次 HTTP 调用；
   • 3：在产品核心循环里真正读写 observations；
   • 4：覆盖多个界面（hooks、modes、search、timeline、skills）；
   • 5：claude-mem 本身就是架构，产品离开它就不存在。
2. Category fit（类别契合度）：项目究竟有多正地命中七大奖项类别中的一个或多个。
3. Working（可用性）：0 是 vaporware（空气产品）；3 是能跟着 setup 跑起来；5 是带测试、可端到端演示。
4. Monday morning（决胜项）：一个开发者是否真的会用它。
5. Honesty（诚实度）：README 是否与代码相符。5 = 完全相符；1 = 宣传语描述的东西代码根本没做。

全局最扎眼的发现

在进入逐项目之前，评审先给出一个"前置结论"：

• 没有任何项目在接入深度上拿到 4 或 5 分。 17 个仓库中没有一个真正用上 claude-mem 的 timeline、get_observations 工具、MCP 搜索服务器，或挂进它的 observer。
• 每个仓库都是"黑客松当天的一个 squash 提交"，没有演进历史可查。
• 最常见的失败不是野心不够，而是 plumbing（管道对接）出错：端口号不对、路由名不对、settings 键名不对、worker 调用静默返回空——而 pitch deck 上写着"真实可用"。

这一条"全局发现"本身就是整份报告最有价值的产出：它说明通往 4/5 分接入深度的障碍不在于想象力，而在于对接基础设施的基本功。

---

十七强完整排位与逐项评语

以下是 17 个项目的完整记分卡，保留原文档对每个项目的"做什么 / 为什么能赢 / 为什么该输 / 落位及理由"四段式结构。

1. Temporal（seanowww/temporal-clean）— 20 / 25

做什么。 Temporal 是 PR 评审的 provenance 层：把 GitHub PR/commit 事件与来自 Slack、Jira、Notion、Claude Code、Codex 的证据一并灌入图结构，从 PR 出发做带评分的遍历，最终渲染出一条"证据支持的时间线"，由 GitHub Action 作为 PR 评论发出。卖点是：评审 PR 时你不该只看 diff，还该看到导致这份 diff 的决策、对话与 agent 推理。

claude-mem 只是七个 connector 之一。Temporal 不去摄取原始 agent transcript，而是直接读 claude-mem 已经压缩过的 observations、session summaries 与 user prompts，让 agent 决策以"已经蒸馏过"的形态落到时间线上。

为什么它能赢。 这是唯一一个真正把 claude-mem 数据模型"读懂并用起来"的提交。客户端（lib/claude-mem/client.ts）用与 claude-mem 自身相同的公式推导 worker 端口，翻页遍历 /api/observations、/api/summaries、/api/prompts 并正确处理 hasMore 标志，还正确解包了响应信封。worker 下线时它回退为只读打开 ~/.claude-mem/claude-mem.db，并且对每个列名都用 PRAGMA table_info 做了存在性检查，schema 漂移不会弄坏它。

规范化层想得更深：observation 类型驱动工件重要性（decision 记 5 分、change 记 2 分）；session summary 的 next-steps 变成 QA 检查项；被 private tags 包裹的内容在边界处被剥离；Codex 会话通过读取 claude-mem 的 platform_source 字段被路由到 Temporal 的 Codex source。因为 claude-mem observations 不带分支信息，团队写了 Claude Code 的 SessionStart / PostToolUse hook，把 git 状态记到 sidecar 文件里，再把每条 observation 按其时间戳归因到当时生效的分支。observation 的 files_modified 与 PR 改动文件的重叠会加分。

47/47 个测试全部通过，其中 14 个是 claude-mem 专属，覆盖两种传输、分支解析、private-tag 剥离，以及从 claude-mem export 做端到端工件组装；TypeScript 干净编译；README 的 claude-mem 章节与代码逐行相符。

为什么它该输。 claude-mem 是可选的，产品完全脱离它也能跑；精心打磨的演示 fixtures 里 claude-mem 记录数为零，演示路径根本没走到这个集成。它只读不写，没有回写、没有自定义 mode、没有用 search 或 timeline 检索。端口解析里有一条读 claude-mem 并不存储的 settings 键的死分支。而且它只是七个 connector 之一，不是架构本身。

落位与理由。 第一名。接入深度 3 / 类别契合 4 / 可用性 5 / Monday morning 3 / 诚实度 5。它正面命中"build an integration"，部分命中"ingest anything"，并且是唯一把 claude-mem 的 observation 结构当作"值得理解的东西"而非"用来数数或截断的 blob"的项目。

2. TeamBrain（MrFibonacc1/yc-hacks-greptileFast）— 18 / 25

做什么。 TeamBrain 把多个工程师的记忆汇集成一个共享的"团队大脑"：一个零依赖的 Bun server 摄取每位工程师的 claude-mem 数据库，把每条记忆归因到作者，并在会话开始时注入团队简报。它同时摄取 Greptile 与 PR 评审对话作为记忆，把反复出现的教训"毕业"为跨团队 pattern，并运行一个 PR sentinel——当某份 diff 重复了别的团队已经犯过的错误时给出告警。标语：Claude-Mem 让一个工程师的 agent 变聪明，TeamBrain 让整个团队的 agent 变聪明。

为什么它能赢。 这是最具野心、类别密度最高的提交，同时命中 warm boot、memory UI、integration、ingest-with-custom-mode。claude-mem 集成正确地说出了 claude-mem 的三种数据格式：直接读 ~/.claude-mem/claude-mem.db 带 resume cursor 并拒收敏感类型行；实现了 cmem.ai 云 sync-hub wire API 的客户端，路由和 header 与 claude-mem 的 sync-hub worker 一致；还带一个自定义 mode modes/code--team.json，正确使用 claude-mem 的双横线父级继承——override 里的每个 prompt key、type ID、concept ID 都对照过真实 code.json。

198/198 个测试通过。评审实际启动过服务器、创建过 brain、跑过 SessionStart hook 和 MCP server 端到端。Dashboard 带 "Pool in Claude-Mem" 面板，preflight 代码甚至诚实地给云路径标 "unproven" 而不是声称可用。

为什么它该输。 头条导入路径在真实安装上是坏的：importer（server/src/cmem.ts:430）只要存在就叫 memory_items 表。而 stock claude-mem v13 安装上该表存在但是空的——数据在 observations 里。评审拿一个含十几万条 observations 的真实数据库跑导入，得到 opsScanned: 0, imported: 0。测试 fixture 只建了 legacy 表，所以测试套件抓不住这个 bug。项目作用域过滤还被应用在错误的分支上，导致"防止把全部历史 pool 进当前 brain"的 hook 守卫形同虚设。

除此之外：它是一个"摄取 claude-mem 的兄弟记忆系统"而非"在 claude-mem 上构建"。计划文档直说"implement our own thin hooks and server"。它没用 worker API、没用 MCP 搜索工具、没用 timeline。自定义 mode 格式正确但默认未安装，只留了"手工复制"的注释。云同步路径只在 stub 上测过。

落位与理由。 第二名。接入深度 3 / 类别契合 4 / 可用性 4 / Monday morning 3 / 诚实度 4。团队负责人会真心想要这东西。但奖项应附带一个"一行修复"的条件：当 memory_items 为空时优先用 observations。

3. RegressionForge（KaushikSiva/regression-forge，含 demo-ecom-store）— 16 / 25

做什么。 部署后的回归门禁：FastAPI 后端驱动 Playwright 走完电商结账流程，然后通过 API 验证订单、通过 Mailpit 验证确认邮件、验证履约 webhook、以及在 SigNoz 里核对关联日志，输出确定性的 PASS / FAIL / NEEDS_REVIEW 证书，配 React 证据室。配套仓库 ForgeCart 是刻意可破坏的目标（good / broken / fixed 契约变体 + 阻断 PR 的 GitHub Actions 工作流）。

为什么它能赢。 这是唯一把 claude-mem server-beta 运行时真正搭起来的团队：Dockerfile 把 claude-mem clone 并 pin 到具体 commit，Render manifest 预置了 Postgres、Valkey、带 API-key 认证的 web service 和 worker。Python 客户端打 /v1/projects、/v1/search、/v1/memories，payload 形状与 claude-mem 真实路由 handler 逐一比对、完全一致。调用位于核心 execute() 循环内：浏览器步骤前 recall、运行完成后 save。匹配结果进入 Codex 诊断 bundle，并在 UI 的 MemoryRail 中渲染。单元测试 mock HTTP 层并断言精确 URL、bearer header 与 payload；每个不可用状态都被如实呈现而非伪造。

为什么它该输。 recall 查询是硬编码字面量 "RegressionForge PASS"，不按工作流、部署或失败文本做作用域化。返回的内容是产品自己的 JSON summary 过全文索引的回声，不是 observer 生成的 observations；Chroma 与 generation 双双被禁用，所以没有语义搜索，预置的 Anthropic worker 从未干活。README 架构图显示"记忆喂给门禁"，但门禁实际是 decide(step_results)，记忆根本碰不到它。本地 make demo 完全不接线 claude-mem，记忆路径只存在于一个手工引导的 Render 部署上且无法在线验证。demo store 仓库零 claude-mem 代码。

落位与理由。 第三名。接入深度 3 / 类别契合 3 / 可用性 3 / Monday morning 3 / 诚实度 4。一个接线真实、契约正确但用法浅的提交——把 claude-mem 当托管 key-value / 全文存储，绑在一个很强的部署门禁产品上，而后者换任何数据库都能照样工作。

4. Rewind（Ashutosh-Brain/greptile-fasthackathon-26）— 16 / 25

做什么。 Codex-first 的上下文记录工具：通过 App Server 观察 OpenAI Codex 任务，把证据与 git commit 关联，作为 git note 与 Supabase 双重存储，团队成员可查看决策、加反驳、在隔离 worktree 中 fork 一条修正后的重放。Electron + Next.js，带本地 HTTP 伴生进程。

为什么它能赢。 claude-mem 客户端写得很准：从 settings 或环境变量解析 worker，端口公式正确，依次打 /api/health、/api/stats、/api/processing-status、/api/observations、/api/summaries、/api/prompts——这些路由全部真实存在，字段形状也与它期望的一致。它把一切规范化为类型化的 memory.json，写在每条 Codex trace 旁。README 异常坦率：claude-mem 是 "optional"、"a separate enrichment layer, never over the source trace"。结果文档还明确区分"插件已装 / worker 已连 / hooks 在抓 / 压缩已认证"四个状态，并承认压缩从未运行过——因为一个 OAuth 会话过期了。

为什么它该输。 没有任何东西读 memory.json。评审 grep 了 UI、context record、Codex Q&A、Supabase schema、GitHub 评论生成器：消费者为零。它是"只写不读的死数据"。UI 展示的状态卡只有版本号和计数，从没展示过一条 observation。影片 preflight 用 worker 显示 "Connected" 作为门禁，可它的数据对任何场景都没有贡献——那张卡存在只是为了出现在片尾 lockup 里。按团队自己的结果，唯一真实端到端产物是一条原始捕获 prompt；压缩后的 observations 从未流动过。测试则完全 mock fetch。

落位与理由。 第四名，与 RegressionForge 同分但排后——因为 RegressionForge 至少会读回记忆。接入深度 2 / 类别契合 2 / 可用性 4 / Monday morning 3 / 诚实度 5。一个构建良好的 Codex 工具，挂着一枚诚实、实现正确却只写不读的 claude-mem 徽章。

5. SourceTether（abheeshtroy/sourcetether）— 15 / 25

做什么。 源码验证的记忆门禁：把一条手写的原子声明（如"gravity is a static property initialized to 9.81"）通过结构化的 AST 指纹绑定到一个 TypeScript 声明——对解析树做忽略注释与空白的 SHA-256。释放记忆前先对当前源码重新验证指纹；若声明已变，记忆被扣留，并返回一个精确的"重新阅读目标"。画布上的月球着陆 demo：一条用过期地球重力记忆的控制器耗尽燃料坠毁，而经过再验证的控制器软着陆成功。

为什么它能赢。 这个想法与"记忆过期（staleness）"真实相关——这是赛场上没有第二个人处理的真问题。42/42 测试通过，TypeScript 干净（评审亲自跑过）。唯一一次 claude-mem 调用是 GET /api/observation/{id}，其字段映射对照 worker 的 route handler 验证无误。README 极度坦诚：自称只"fetch one local Claude-Mem observation to establish provenance"、"does not derive the claim automatically"，并附显式 limitations 章节。

为什么它该输。 observation 内容被刻意丢弃：demo 工作流只复制 ID、时间戳、project、session ID，把正文扔掉，存储的 claim 是硬编码字符串常量。有一个测试甚至喂入 "Untrusted Claude-Mem narrative that must never be returned"。claude-mem 依赖可以被任何"带 ID 和时间戳的对象"替换而行为不变。默认端口 37701 是作者自己 uid 推导的端口，覆盖用的环境变量从未写进文档。它绑定一个文件、一个符号、一条声明；无法把任意 observation 绑定到任意符号；也没有任何东西流回 agent 的上下文。

落位与理由。 第五名。接入深度 2 / 类别契合 2 / 可用性 5 / Monday morning 1 / 诚实度 5。一个干净、测试充分、描述诚实的 AST 门禁，把 claude-mem 当"来源徽章"戴在身上，而非当基座使用。

6. Product Git（Luciayuanzhu/product-git）— 14 / 25

做什么。 产品行为的版本控制：一个 stdio MCP server 暴露六个工具，让编码 agent 开始一轮、声明影响、提交产品状态并收尾；localhost web workbench 让人类接受、拒绝或锁定 agent 对 Product Graph 的改动并保存 Product Versions；下一轮 agent 收到一份带锁定逻辑与必带代码 diff 的作用域化 context pack。宿主目标是 Codex。

为什么它能赢。 产品本身真实且测试充分：24 个测试加 MCP smoke test 通过。claude-mem 调用可实时工作（评审对着运行中的 worker 验证过）：每轮开始都会用"包名 + 框架 + 用户请求 + 未决锁定语句"拼查询打 /api/search，把结果作为 "Director Note" 注入 context pack 显示在预览旁。doctor 命令报告 claude-mem 可用性，connect 命令把 worker URL 转发进 Codex MCP 环境。README 坦率："optional, fail-open, one advisory Director Note"。

为什么它该输。 Director Note 是原始 search markdown 的前六百个字符——管道符、emoji、表头原样保留，因为代码是"截断"而非"压缩"。source_refs 数组永远为空，因为代码在找一个 worker 响应里不存在的 results 键。没有传 project filter，无关项目的 observations 会漏进 note（评审亲眼看到发生）。根目录那个名叫 claude-mem-adapter.js 的文件其实是 product-git 自有 API 的遗留浏览器 shim，名字骗人、从不触碰 claude-mem。根部还躺着一份过时 PRD，描述着代码里不存在的 hook 抓取与 demo observations。而且宿主是 Codex——用 product-git 的 agent 并不是 claude-mem 记录其工作的那个 agent。

落位与理由。 第六名。接入深度 2 / 类别契合 2 / 可用性 4 / Monday morning 2 / 诚实度 4。一个真实的 MCP 治理产品，其中 claude-mem 只是一次无作用域搜索调用，输出是侧栏里一张截断的表格。

7. Relay（thehimalayanleo/relay）— 13 / 25

做什么。 交接协议：把一份进行中的调查从一个"人 + agent"组合交接给另一个。把目标、决策、被否决路径、下一步动作的规范化 JSON 胶囊封在 SHA-256 digest 与过期能力 URL 后面，可附工作 pod，为 Codex、Claude Code、Cursor、OpenCode 渲染各自的恢复提示，并记录接收回执。主要集成对象是 Greptile 与 Sail。

为什么它能赢。 交接协议设计周全、边界清晰。claude-mem 调用形状正确：端口公式对、健康检查读真实 payload 字段、搜索调用取 MCP 风格文本响应并抽取 observation ID。server 暴露 status 与 search 端点，会话持久化 ID，状态胶囊显示 "Claude-Mem, N recalled"。README 与产品聚焦文档对"no measured savings"、"empty memory shown honestly"异常坦白。

为什么它该输。 浏览器端把 observation 内容扔掉，只把 ID 号传回；每条胶囊记忆变成字面字符串 "Claude-Mem observation N"。渲染恢复提示的 adapters 干脆完全省略记忆——接收方连 ID 都看不到。客户端把项目名硬编码为 "relay"，所以 recall 只对字面叫这个名字的项目有效。demo 胶囊里"six memories sealed, warm-boots User 2"指的是 Greptile fixtures，不是 claude-mem。两个 claude-mem 测试都 mock fetch。团队自己的胶囊承认代码是 Codex 生成的，完整测试被 Node 24 问题卡住。

落位与理由。 第七名。接入深度 2 / 类别契合 2 / 可用性 3 / Monday morning 2 / 诚实度 4。一个真实但肤浅的"状态 + 搜索探针"，只存 ID 号，从没把任何记忆内容放到交接接收者面前。

8. FDE Harness（greptile-hackathon-demo/fde-harness）— 12 / 25

做什么。 面向 forward-deployed engineer 的 Next.js dashboard + Node pipeline：把 Linear issue 分解为子任务，用带弃权机制、无 embedding 的多轴打分器与从真实合并 PR 挖掘出的 42 条"变更配方"匹配，然后 claude -p 在 git worktree 里搭脚手架代码、TypeScript 验证、开草稿 PR 并写回 Linear。第二个功能是从累积记忆生成客户交接文档。

为什么它能赢。 检索工程扎实，内部文档对删减清单与"什么会构成虚假声明"都很坦诚。claude-mem 在管线四个点通过 worker HTTP API（正确的 per-user 端口公式）被写入：每条蒸馏配方一条 observation、每个计划/弃权决策一条、每次运行结果一条、每次修正一条。而且真有一条读取路径：交接文档生成器直接开 ~/.claude-mem/claude-mem.db，选取该项目下 decision / bugfix / feature / refactor 类型 observation 同时排除敏感项，喂给 prompt 生成交接 markdown。导出数据显示五次真实运行，包括一次真实草稿 PR。

为什么它该输。 被项目描述为其获奖主打的"corrections injected into the next generation"循环，读的是项目自己的 SQLite corrections 表，不是 claude-mem。代码注释坦白原因：claude-mem 的 search 没有精确概念过滤器。于是 claude-mem 收到每一份修正的副本，却从不读回。项目信息文档宣称 claude-mem 有四个"load-bearing roles"，实际只实现了交接这一个，且其中两个描述的是代码里根本不存在的 API 调用。导出数据中修正数为零，头条图表是空的。README 是未改动的 create-next-app 样板。交接脚本依赖 claude-mem 私有 SQLite schema 而非 API。

落位与理由。 第八名。接入深度 2 / 类别契合 2 / 可用性 3 / Monday morning 2 / 诚实度 3。一个强检索项目，claude-mem 被当作 observation 水槽外加一条真实读取路径绑在上面，而不是文档所描述的记忆基座。

9. Pinocchio（akhiping/yc-greptile，部署于 pinocchio-agent-verifier.onrender.com）— 12 / 25

做什么。 agent 验证工具：捕获编码 agent 的 diff 与工具台账，对测试篡改、断言弱化、硬编码字面量、幽灵测试执行、空洞测试跑确定性检测器，输出带"鼻子长度"评分的契约 JSON；可通过 Codex Stop hook 或 git pre-commit 门禁阻断 agent 的回合。已部署站点是重放记录检测器场景的"Agent Truth Game"。

为什么它能赢。 检测器想法确实有用，verifier 声称 66 个测试通过；live 站点在线并服务真实场景数据。README 明确 claude-mem 是 "optional"、"the next integration surface, not a dependency"。它设想的 warm-boot 弧线——上一会话对"断言弱化"的 observation 为下一会话的验证提供信息——恰好就是奖项想要的思路。

为什么它该输。 claude-mem adapter pinocchio/cricket.py 连不上真实安装：它读一个叫 port 的 settings 键，而 claude-mem 存的是 CLAUDE_MEM_WORKER_PORT，所以它在每台真机上返回空；它 POST /api/observations——一个根本不存在于写路径的路由；它解析 observations 没有的 content 字段。而且它只被一个终端 demo 脚本 import，主入口、hooks、门禁、已部署 server 全都不碰它。README 里 warm-boot 终端输出是手写的，不是抓的。团队自己的规划文档显示 claude-mem 轨道被刻意降级："only if prize real"，并有损伤报告："Zero external dependencies. No claude-mem, no Chroma, no worker service." 部署站点运行在 fallback 重放模式，Claude flag 为 false、记忆计数为零。

落位与理由。 第九名。接入深度 2 / 类别契合 2 / 可用性 3 / Monday morning 2 / 诚实度 3。一个扎实的验证器，claude-mem 被当作一个理想化的、非功能的 adapter 绑在上面，且不在任何已发布的代码路径上。

10. Lumina（charveeee/lumina）— 11 / 25

做什么。 单文件 FastAPI app + 一个 HTML 页：读者悬停越久的难懂段落被渐进简化，规则式分句 + 词汇替换，无 LLM。每次改编打一个启发式"struggle pattern"标签，若 claude-mem 已为同一会话记录同一 pattern 三次以上，则直接跳到最强改写。

为什么它能赢。 对一个四百五十行的项目而言，接线是正确的：POST /api/sessions/init 与 /api/sessions/observations 的字段匹配 claude-mem 真实校验 schema，是真正喂进 observer 管线而非编造端点；通过正确信封键从 /api/observations 读回；每个浏览器会话只对应一个 claude-mem project；worker 下线时优雅降级。README 准确写道它"uses Claude-Mem's local worker API, does not maintain its own memory database"。这是"ingest anything"的微缩版：把非编码遥测推过 observer。

为什么它该输。 读取路径用正则对压缩 observations 里的标记字符串计数，而默认 observer 是否在压缩后保留那个字面 token 从未被证明。读取只有一秒超时，而 observer 是异步 LLM 管线，三连击不可能在几次悬停周期内触发。取回的东西只有计数，observation 内容被丢弃。五个样例段落里四个经静态正则触发同样两个 pattern，所以"反复出现"度量的是 fixture 文本而非读者。端口 37701 硬编码。没有测试。还有个多余的 OpenAI 依赖，与"no API key"的声明矛盾。

落位与理由。 第十名。接入深度 2 / 类别契合 2 / 可用性 2 / Monday morning 1 / 诚实度 4。一个诚实、微小、接线正确但肤浅的 worker API 使用，claude-mem 在这里的功能是一个"本来用 Python 字典就能做"的事件计数器。

11. Mayday（Kush614/mayday）— 11 / 25

做什么。 OpenAI Codex 会话的黑匣子飞行记录仪：recorder 把 codex exec 包成 JSONL trace，enricher 抽取每步假设，incident engine 把粘贴的 stack trace 经行历史索引映射到导致它的那一步与错误信念，Modal sandbox 带着修正后的信念重跑 Codex。带 React 重放 UI。

为什么它能赢。 产品是真的：五个文件 29 个测试用例、提交过的重放结果、Playwright UI 检查。文档对 claude-mem 的角色诚实：集成文档直接标注 "pitch garnish (optional, honest)"，claude-mem 注释写"neither is load-bearing for the demo"。主题上它是 claude-mem 的表亲——带时间线拖拽器的 agent 推理持久记录，如果它写入 claude-mem，会天然契合 "ingest anything"。

为什么它该输。 它根本不用 claude-mem。所有提及都只是文档或赞助商卡片。About 页渲染静态条目："claude-mem: build-time memory. Persistent memory across the Claude Code sessions that built Mayday."——这就是它的实际身份：作者写代码时开着跑的 dev 工具。没有代码触碰数据库、worker、MCP 工具、hooks 或 modes；claude-mem 不在任何 package manifest 的依赖里。README 在一张并非如此的卡片上方头条写着 "every one of these is load-bearing"。README 与 CLAUDE.md 称为神圣的"committed golden trace"被 gitignore 了，实际缺席。

落位与理由。 第十一名。接入深度 1 / 类别契合 1 / 可用性 3 / Monday morning 2 / 诚实度 4。一个打磨精良的 Codex 取证项目，把 claude-mem 当作作者自己的开发记忆在使用，并且如实说了。

12. Repo Radio（nithinaru/fasthack-yc-greptile）— 11 / 25

做什么。 每日 AI 播客：按 star 增速挑出最火 GitHub 仓库，用源码核对其 README，让 Qwen 写一段带 HYPE / REAL / MIXED 判定的两分钟电台稿，用 Kokoro 在 Modal 上配音，在卡拉 OK 式 web 播放器播放（主播说话时高亮引用文件行）。Stripe 钱包让听众购买"在播问题"。主持人记忆跨集给出 "previously on" 回调，侧栏显示主持人记忆。

为什么它能赢。 有趣又打磨精良：十一集带音频的成品，live Modal 部署。跨集回调功能真实存在且能听到。第二集讲的就是 claude-mem 本身并给了 MIXED 评价。PRD 预授权"fallback equals memory.json alone; claim only what runs"，这是正确直觉。

为什么它该输。 真正的记忆系统是手搓的 web/memory.json，项目自己读写。claude-mem worker 调用以三种独立方式坏掉：先发 ?q= 而 worker 期待 ?query=；随后回退 POST 一个只接受 GET 的路由；再解析 claude-mem 结果从不包含的 snippet 字段。三个失败都被 catch 吞掉，所以它一直返回空列表。可提交文档却声称"a real, working build: a local worker on 37777 is queried search-before-script"。代码还断言 worker "has no HTTP write endpoint"——这是假的，并成了把所有写入导去 JSON 文件的理由。第一集居然有 "previously on" 回调。PRD 承诺的 claude-mem worker 截图不在仓库里。Greptile 也处于同样的"设计过但没运行"状态。

落位与理由。 第十二名。接入深度 1 / 类别契合 2 / 可用性 4 / Monday morning 2 / 诚实度 2。一个打磨精良的播客产品，claude-mem 只是贴在一个自研 JSON 文件上的赞助商贴纸，而提交文档说的却是另一回事。

13. Versionless（taranggoyal70/versionless，部署于 versionless-navy.vercel.app）— 11 / 25

做什么。 编码 agent 的证明层：克隆目标仓库，对锁定的测试 / lockfile / 配置路径做 SHA-256 哈希，允许 Codex 只编辑一个被允许的文件，然后在第二个干净 clone 中重放 patch 并重跑锁定的测试套件，证明 agent 没有改写测试。live 部署是 Clerk 登录墙后的预录运行托管重放。

为什么它能赢。 锁定哈希的想法确实有用，Codex 证明引擎有真实测试。记录路径 POST /api/sessions/observations，payload 形状匹配 claude-mem 校验 schema，包括带 outcome 与哈希的自定义 VersionlessVerification 工具名——这是合理的 "ingest anything" 姿态。README 坦率："Claude-Mem and Modal are not presented as active integrations because their local runtimes were unavailable during this build."

为什么它该输。 读取路径用 GET /api/health 做门禁，可 worker 提供的是 /health，/api/health 只存在于单独的 server runtime 上——所以对着当前 worker，每次运行无论什么状态都报 "memory unavailable"。没有测试碰这两个 claude-mem 函数。然后是托管重放：src/lib/migration/hosted-replay.ts 硬编码 provider: "Claude-Mem", status: "replayed", itemCount: 3, summary: "Replaying memory captured during the verified local Codex run."。那行渲染在一个标题为 "Repository intelligence and memory are real"、带通过标记的 dossier 之下。README 却说从未捕获过记忆。证据就绪工件数量被这些赞助商行注水。落地页从不提 claude-mem，卡片只出现在登录墙之后。

落位与理由。 第十三名。接入深度 2 / 类别契合 2 / 可用性 2 / Monday morning 2 / 诚实度 3。一个扎实的验证 demo，claude-mem 是装饰性、未测试、坦承从未连接过的旁路调用，而部署的重放伪造了证据。

14. CleanMyAgents（naturetime10/CleanMyAgents）— 10 / 25

做什么。 macOS 菜单栏 Electron app，仿 CleanMyMac 外观，充当 OpenAI Codex 的人机协同守卫。一个 fork 过的 Codex 把每条 prompt、工具调用、工具输出发到本地守卫服务，后者跑关键词规则、噪声跳过表、微型 trigram-cosine 相似度索引，然后弹出刘海 "island" 让人允许或拒绝。React web UI 展示 hook 注入 token 审计、会话轨迹查看器、对 rollout 日志的 Grok 深度扫描。

为什么它能赢。 island UI 好看，实时工具调用门禁与"fire on what it sees"呼应；丢弃 lint 运行与 npm-fund 噪声省 token 呼应 "speed play"。相似度与存储模块有通过的测试。没有顶层 README，文档从不提 claude-mem——所以它没对 claude-mem 撒谎。

为什么它该输。 全仓库没有 claude-mem。连点名都没有，更别说引用或配置。唯一 grep 命中的地方是 vendored 的 97MB OpenAI Codex 仓库副本里、OpenAI 自己的 memories 扩展。自研记忆是 JSON 文件上的字符 trigram embedding，注释写着 "swap for a real embedding model"。两个 server 路由调用未定义函数，运行即崩。Hooks / Scan / Trajectory 三个 tab 由 mock 支撑，其中一个 mock 文件写着 "every value is invented"。backend 目录是空占位符。深度扫描把用户完整 Codex rollout 日志（最多 5MB，含工具输出里可能的机密）发给第三方 Grok 端点。

落位与理由。 第十四名。接入深度 0 / 类别契合 1 / 可用性 3 / Monday morning 2 / 诚实度 4。一个想得挺周全的 Codex 守卫，但任何意义上都不是 claude-mem 项目。

15. Outcome（zkortam/wingman）— 10 / 25

做什么。 TypeScript monorepo，观察已部署支持 agent 的聊天会话，检测重试、重申约束等用户挫败信号，聚簇成 incident，让 LLM 生成一条失败的断言、提出有界的 config diff、验证并作为 per-user 或全局 override 应用到 Supabase——一个自愈式 agent 配置闭环。没有 README，因为 docs 目录被 gitignore。

为什么它能赢。 管线结构良好：18 个测试文件、重放 stub、fixtures、Supabase migration。"prior art" 账本存储 fingerprint / diff / outcome，并按 fingerprint 把 prior art 取回进修复 prompt——这正是一个记忆检索层该有的形状，也是 claude-mem search 本可以插入的槽位。

为什么它该输。 没有东西填这个槽。全代码库唯一的 claude-mem 引用是一个叫 ClaudeMemLedger 的类——一个 17 行的透传，把调用委托给注入的 MemoryAdapter 接口；而该接口没有任何实现。这个类从未被实例化，只被 re-export。每条真实接线都走 in-memory 或 no-op ledger。LLM 栈完全是 OpenAI 的。根目录没有 package manifest 或 lockfile，却有 workspace 依赖，所以 monorepo 按提交状态根本装不起来。给一个类起名 claude-mem 却零 claude-mem 代码，这是为了读起来像集成而做的 name-drop。

落位与理由。 第十五名。接入深度 1 / 类别契合 1 / 可用性 3 / Monday morning 2 / 诚实度 3。一个像样的配置修复管线，在一个标识符里点了一下 claude-mem 的名。

16. LingCode CLI（Xavierhuang/Mac_cli）— 7 / 25

做什么。 LingCode macOS IDE 的 Swift 终端 CLI 伴生，31 个子命令：经 Unix socket 把 prompt 路由到运行中的 app，或独立模式 spawn 一个围绕 Claude Agent SDK 的打包 Node bridge。仓库明说是只读镜像与 release 二进制宿主，不能独立构建；其 package manifest 依赖只在 canonical LingCode 仓库存在的兄弟目录。

为什么它能赢。 它是合法、非平凡的 agent CLI，有真实代码与两个测试 target，且不作虚假声明：README 不提 claude-mem，也坦白镜像不能构建。

为什么它该输。 它与 claude-mem 毫无关系。全部 84 个文件（含 19000 行 vendored SDK bundle）零命中。更广的搜索找到的是 LingCode 自己的无关记忆系统：一个进程内 MCP server，把 markdown 段落写到 .lingcode/memory.md，且在 CLI 代码路径上其请求被显式丢弃。任何地方都没有黑客松框架。它像是被提交、或被爬进了一个错误的池子。

落位与理由。 第十六名。接入深度 0 / 类别契合 0 / 可用性 1 / Monday morning 1 / 诚实度 5。诚实，但在任何有意义的意义上都不是一份提交。

17. Sandhāna（shreekrithi1/epicenter）— 7 / 25

做什么。 一个预先存在的企业专有"运营智能"SaaS：FastAPI + React + Postgres，140+ 连接器目录，Electron 与移动壳，Stripe 计费。仓库根有 245 个条目，含 YC pitch deck、路线图幻灯片、demo 视频、80 个散落 patch 与测试脚本。README 写 "Founded 2024"。它本就有基于正则事实抽取 + Postgres 表的 "Team Memory" 功能。

为什么它能赢。 为黑客松新增的端点确实与奖项类别名一一对应：warm-boot、timeline、observations、ingest-anything、hooks、bench。React 记忆页有 warm-boot 卡与 timeline 面板。营销页标题 "Sandhāna × Claude-Mem, $1,000 Memory Prize Track" 声称拿下全部七类。

为什么它该输。 没有一处碰 claude-mem。每个新端点都查 Sandhāna 自己的 team-memories 表，且当用户真实记忆不足三条时回退到硬编码 seed memories。"Extraction" 是一组正则："we decided"、"action item"、"root cause"。token 计数是字符串长度除以四。"bridge" 脚本把 Claude Code transcript 事件 POST 到 Sandhāna 自己的 localhost:8000 API，从不发给 claude-mem。MCP 工具描述符由 Sandhāna 自己的 MCP 端点提供。pitch 页声称注入 chat 的 warm-boot 在 server 代码里并不存在；在 LICENSE 为 "Proprietary, all rights reserved" 的仓库下声称是 "Apache-2.0 bridge"；还给 claude-mem 编了膨胀的 star 与 commit 数。它自己的 footer 承认 "not affiliated with Claude-Mem, built on its ideas"。Git 历史是单个 squash 提交，黑客松增量无法定年。每条数据库写入都被静默吞异常的包装包裹，所以"extracted N memories"可以在什么都没持久化的情况下报成功。

落位与理由。 垫底。接入深度 1 / 类别契合 2 / 可用性 2 / Monday morning 1 / 诚实度 1。一个预先存在的产品，把自己的正则记忆端点用 claude-mem 词汇表改了个名，并围绕改名搭了张 pitch 页。

---

赛场揭示的四条规律

所有人都在 plumbing 上栽了

• 五支队伍各自独立且正确地重实现了 claude-mem 的 per-user 端口公式；
• 另外两支把 37701 硬编码——那其实是作者自己的 uid 推导端口；
• 一支用 /api/health 做门禁，而 worker 提供的是 /health；
• 两支读了一个 claude-mem 根本不写的 settings 键；
• 一支发了 ?q= 而 worker 期待 ?query=。

评审给出一句结论性建议：如果只能修一份文档，那就是一页 "how to talk to the worker" 参考——端口公式、路由表、响应信封。

"读了就扔"是主导模式

Rewind、Relay、SourceTether、Product Git 都取回了真实 observations 然后扔掉内容，只保留一个 ID、一个计数或一个截断字符串。observation 的标题、facts、narrative——也就是压缩步骤的全部意义——没有任何一个项目把它们送到用户或 agent 面前。

检索栈无人触碰

timeline、get_observations、mcp-search 在全部 17 个项目中零使用。"cheapest first" 的检索纪律（cheat sheet 里描述过）无人尝试。TeamBrain 是唯一带自定义 mode 的，而它还默认未安装。

诚实度整体不错，两个例外点名批评

多数 README 坦承 claude-mem 是可选的。例外是：Versionless 硬编码了它自己 README 说从未存在的重放证据；Sandhāna 搭的 pitch 页与它的 server 代码、license 文件互相矛盾。

最终推荐

• Temporal 获奖：唯一让 claude-mem 数据模型"被理解且承担承重"、有测试、且描述准确的提交。
• TeamBrain 亚军：条件是一行修复，让 import 在真实数据库上能跑。
• RegressionForge 荣誉提名：唯一把 server runtime 用验证过的契约搭起来的团队。

---

对照源码：评审说的这些"坑"，到底对应仓库里的什么

评审文档反复提及的若干实现细节，全部可以在当前仓库源码里逐条核对。这一节把它们整理成一份"可直接复制"的对接参考（可作为评审建议的那份"how to talk to the worker"单页的事实基础）。

端口公式：不是 37777，也不是随机的 37701

worker 默认端口来自 CLAUDE_MEM_WORKER_PORT，其默认值推导逻辑在 SettingsDefaultsManager.ts：37700 + ((process.getuid?.() ?? 77) % 100)。也就是说每个系统用户会得到不同的端口（uid 为 101 的用户得到 37701——这正是 SourceTether、Lumina 硬编码 37701 却被别人机器打脸的根源）。读取侧封装在 worker-utils.ts：getWorkerPort() / getWorkerHost() 读取 settings 并做缓存，URL 拼装由 buildWorkerUrl() 完成。对外部集成者而言，正确做法是从 settings 或环境读取，而不是硬编码。host 默认值同为 uid 推导，见 SettingsDefaultsManager.ts 中 server runtime 的 CLAUDE_MEM_SERVER_URL 一行注释"UID-derived for multi-account isolation"。

路由表与"只读数据面"

评审提到的 GET 数据面路由全部真实存在，集中在 DataRoutes.ts：

• GET /api/observations、GET /api/summaries、GET /api/prompts（均支持 offset、limit、project、platform_source 过滤）；
• GET /api/observation/:id（SourceTether 用的那条）、GET /api/prompt/:id、GET /api/session/:id；
• GET /api/stats、GET /api/projects、GET /api/processing-status。

写入面在 SessionRoutes.ts：POST /api/sessions/init、POST /api/sessions/observations、POST /api/sessions/summarize——这正是 Lumina、Versionless 声称"匹配真实校验 schema"的端点；而 Pinocchio 试图 POST /api/observations 之所以失败，是因为该路由（DataRoutes.ts）只接受 GET。检索面在 SearchRoutes.ts：GET /api/search、GET /api/timeline、GET /api/search/observations、GET /api/search/by-file 等。

注意区分两套宿主：worker 用 GET /api/health、GET /api/readiness（见 worker-utils.ts）；而 Revisionless 门禁所用的 /api/health 与文档中"只有单独 server runtime 才有"的描述，指的正是另一套托管 server 运行时。对接前务必先确认你在跟哪一套说话。

分页信封：hasMore 是真实契约

Temporal 之所以能正确翻页，是因为分页实现确实返回评审描述的字段。见 PaginationHelper.ts：每次多取一条（limit + 1）来判断 hasMore: results.length > limit，配合 offset、limit 返回 { items, hasMore, offset, limit } 结构，三种资源（observations / summaries / prompts）共用同一逻辑。这也是"读了就扔"项目最常见的浪费点——hasMore 翻页接口就在那里，却没有一个提交把多页内容真正聚合起来用。

检索参数：q 与 query 各有各的位置

Repo Radio 发 ?q= 而 worker"期待 ?query="的指控同样可在源码中对照：统一的语义端点 POST /api/context/semantic 确实用 q（SearchRoutes.ts），而主检索路径通过 queryWithPlatformSource 将 request query 原样透传给 SearchManager（SearchRoutes.ts）。对接任何检索端点前，先读对应 handler 的参数提取逻辑，是避免"静默返回空列表"的最便宜办法。

---

结语：把这份记分卡当作"接入教科书"

这份评审的价值不在排名本身，而在它用 17 个真实样本归纳出的、可迁移的教训。如果你要在 claude-mem 之上构建工具，对照下面这份自查清单即可避开赛场上的绝大多数坑：

1. 端口从 settings / 环境读，别硬编码——公式是 37700 + (uid % 100)，见 SettingsDefaultsManager.ts。
2. 读取前先核对路由表与方法：数据面 /api/observations、/api/summaries、/api/prompts 是 GET，写入走 /api/sessions/observations，别 POST 到 GET-only 端点。
3. 尊重分页信封：用 hasMore 翻完整页，而不是截断前几百字符。
4. 把取回的内容真正用起来：标题、facts、narrative 才是压缩步骤的产物——"读了就扔"等于白接。
5. 检索栈是分水岭：17 支队伍没有一支用上 timeline、get_observations 或 mcp-search——这既是遗憾，也是后来者最容易做出差异化的空白地带。
6. README 与代码对齐：评审把诚实度作为正式评分轴，硬编码重放证据与夸大 pitch 是被点名批评的最重过错。

评审文档全文保存在 05-memory-prize-scorecard.md，与之配套的还有七类奖项总览 01-what-is-claude-mem-field-guide.md 与检索速查 02-claude-mem-cheatsheet.md，可作为继续深挖同一主题的入口。