一个同时付钱用着 Claude Code 和 Codex 的开发者，过去大多是各开一个窗口、各记各的记忆，等一个 agent 撞到额度上限，再靠自己在脑子里把上下文搬过去交叉验证。10 月 4 日，Sno AI 发布 sno-station（Apache-2.0），想把这套交叉验证直接搬进工具里：它给 Claude Code、Codex、OpenClay、Hermes Agent 等多个编码智能体，接上同一份本地加密记忆，并加上 agent 间消息通道与交叉互审。仓库显示两周内收获 402 颗星、322 次复刻，初次提交可追溯到 9 月 19 日。
它具体把什么搬进了工具
sno-station 的运行模型很轻：一个你机器上的共享文件夹，没有守护进程、没有服务器、没有云端——云侧即便将来加上也是可选项，且产品本身不依赖它。在这份共享存储之上叠了三样机制：Sno Reach 是 agent 之间的消息通道，让一个 agent 能把任务连同完整工作上下文，交接给另一个；Squad skills 是写好一次、所有 agent 都读的共享指令，保证交接时带着和前者相同的规则；夜间循环会分析当天会话、提议改写这些技能，但每次改动都要人点头。README 明确点名的四个被协调对象是 Claude Code、Codex、OpenClaw 与 Hermes Agent，它们读写同一份本地存储，互不隔绝。
真正划算的是互审那一步
这套设计里最实用的，是交叉互审：一个 agent 干完活，另一个来自不同厂商的 agent 会读它的 diff、测试输出和共享记忆，要么放行，要么写出审查意见，发起的 agent 必须回应。一个同时跑两个编码 agent 的人，本来就在两者答案不一致时靠自己脑子里比对；sno-station 把这道核对从人脑挪进工具，疲劳的人不再卡在验证环节，漏掉的错也就更少。项目自报了若干记忆基准分数——在 Memora 上遗忘感知记忆准确率为 87.2、遗忘成本 3.76 分（约 4.1%），在 1542 道题的 LoCoMo 上报告 96.76% 准确率，在 LongMemEval-S 上 top5 召回 95.4%，自建的 Sno Memory Bench 23 项全过。这些数字属于厂商自报，应按自报口径看待，而非独立复现结果。
共享记忆也带来新盲区
辩证地看，共享记忆是把双刃剑。若两个 agent 读的是同一份（可能已有误的）记忆，交叉互审很可能把错误一起放大，而不是互相纠错——互审有效的前提，是两者确实从不同的视角独立判断，而非共享同一套偏差。更该警惕的是夜间技能改写循环：让 agent 自己重写自己的技能，即便每次都要人批准，批准动作本身也可能变成惯性点头，久而久之把错误固化进共享指令。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态；但 sno-station 在记忆运行时层给出的施工图，比又一篇记忆论文更贴近工程——它要和同周 Cognition 把记忆存成 git Markdown 的规范思路对照着看：一个管「运行时怎么共享与互审」，一个管「持久化记忆长什么样、人能不能读」。对正在多 agent 协作的团队，这类工具的真正门槛不是接上几个 agent，而是共享记忆的「脏数据如何被发现、被纠正」，否则协作越深，错得越一致。
也别把它当成银弹。sno-station 的价值建立在「两个 agent 确实互补」之上，如果接进来的几个都是同一路线、同一偏好的模型，共享记忆只会让它们错得更整齐。更现实的限制是，它目前偏向本地、偏向编码场景，能不能扩展到云端多租户、能不能接进非编码的工作流，仍是未知数。对买家而言，这类工具最该问的是：当共享记忆里混进一条错的事实，系统靠什么把它捞出来，而不是靠两个agent 互相点头假装没事。