Mosaic（YC S26）评测：共享 Agent 会话记忆能解决团队上下文问题吗？

Mosaic 值得关注，因为它针对的是团队同时使用多个编码 Agent 后出现的协调成本。 Claude Code、Codex、Cursor 和其他 Agent 单独使用时都可能很高效，但各自的发现、失败尝试和局部决策通常被困在独立会话里。共享会话层可以减少重复调查，并让交接变得可见，但它不会自动形成可信的知识库。

这是一篇基于公开资料的采购评测，不是实际 hands-on 测试。公开产品命名也在快速变化。Y Combinator 当前页面把 Ocean 称为 Mosaic 的主要共享记忆产品，同时把 Mosaic 描述为实时协作编码环境。发布文案仍使用 Mosaic 来描述集中式 Agent 会话同步。需要区分时，本文用“Mosaic/Ocean”指代跨会话共享记忆层。

本文只覆盖一个窄意图：Mosaic 面向团队的共享编码 Agent 会话。如果你关心模型之间可复用的操作手册，请看我们的 Agent 知识迁移指南。如果你关心通用记忆架构，请看 OpenViking Agent Memory 评测。如果你关心 Agent 外围运行时，请看 Agent Harness Engineering。

2026 年 9 月的 Mosaic 是什么？

当前 Mosaic 官方产品页把产品描述为一个持久共享环境，让人和 Agent 可以实时协作。页面展示了共享终端、持久会话、人与 Agent 的结对编程、多 Agent 路由，以及跨组织的 Agent 网络。当前可见的下载入口主要面向 macOS。

Y Combinator 的 Mosaic S26 公司与发布页面对会话记忆这条路线描述得更明确。它说 Ocean 为人和编码 Agent 提供跨会话共享记忆，而 Mosaic 是实时协作编码环境。发布文案称约有 2,000 次安装，以及 37 个组织正在主动同步会话。这些数字来自公司发布材料，不是独立审计的采用率指标。

为什么“Multiplayer AI”突然成为一个类别？

Y Combinator 在 Fall 2026 Multiplayer AI Request for Startups 中指出，严肃工作本来就是协作式的，但 Agent 仍然大多是单人体验。它的观点是，团队成员应该能进入同一个实时 Agent 会话，观察、纠偏并接手，而不是只能传一个不可操作的只读 transcript。

Anthropic 从另一个方向给出了类似的系统观点。它的 Human-Agent Teams 指南把持久记忆、清晰角色和对共享书面上下文的广泛访问列为多人 Agent 的基础能力。Anthropic 还提醒，私有侧通道会割裂团队上下文并制造重复工作。

这些材料并不能验证 Mosaic 的产品质量。它们验证的是问题本身：当 Agent 开始为团队执行长时间任务时，私有会话历史不再只是个人不便，而会变成组织级瓶颈。

真正困难的不是同步会话，而是决定什么能变成可信上下文

Transcript 是发生过什么的证据，不等于下一位 Agent 最应该执行的指令。会话历史会混在一起：已确认事实、过期假设、被放弃的猜测、Secret、Stack Trace、原始 Tool Output，以及偶然进入的 Prompt Injection。把所有这些内容原样塞进以后每个 Context Window，既昂贵又危险。

一个真正有用的共享上下文系统至少需要四层：

1. Capture： 保留原始会话，并带上 Agent、用户、Repository、Branch、时间戳和来源标识。
2. Index： 让会话可搜索，同时保留来源边界。
3. Consolidate： 提取长期有效的决策和已验证 Learnings，同时保留到原证据的链接。
4. Selective Retrieval： 只给新的 Agent 注入与任务、Repository 和权限真正相关的上下文。

这里才是 Mosaic 可以形成长期价值的地方。团队不缺另一个 transcript 仓库，缺的是从私人 Agent 活动到受治理组织记忆之间可靠的桥梁。

Mosaic 与 Claude Code Agent Teams 有什么区别？

它们解决的是相邻但不同的问题。Anthropic 的 团队级 Agent Identity 模型关注的是给共享 Agent 独立的 Workspace 身份和权限，而不是让 Agent 冒用某个人类账户。这首先是授权和运行模型问题。Mosaic 的共享会话路线首先是跨人、跨会话、跨 Agent 产品的上下文连续性问题。

官方 Claude Code Agent Teams 文档通过共享 Task List 和 Agent 间直接消息协调多个 Claude Code 实例。每个 teammate 仍然拥有独立 Context Window，Anthropic 也明确指出 Agent Teams 会带来更高 Token 消耗和协调开销。Agent Teams 解决的是一个协调后的 Claude 工作流内部的多 Agent 协作。Mosaic 的目标则是跨会话、跨团队成员、跨不同 Agent 工具的连续性。

工程团队在采用 Mosaic 前应该测试什么？

不要用“能否搜索到旧会话”来评估共享上下文。真正应该测试的是，它是否能帮助下一位工程师或 Agent 做出更好的决定，同时不泄漏无关或过期信息。

• Coverage： Claude Code、Codex、Cursor 和其他会话格式哪些字段能完整捕获，哪些会丢失？
• Provenance： 每条检索结果能否回溯到确切 Session、Repository、Branch 和时间戳？
• Freshness： 后续会话推翻早期架构决策时，系统如何处理旧上下文？
• Scope： 上下文能否按组织、团队、Repository、客户、Branch 或项目隔离？
• Secrets： Token、环境变量、客户数据和命令输出是否在同步前做 Redaction？
• Deletion： 删除一个会话后，它是否也会从索引和派生摘要中真正消失？
• Access： 权限是否继承来源系统，还是原本无权访问 Repository 的人也可能看到会话？
• Portability： 组织能否导出会话历史和派生知识，并在别的系统中继续使用？

安全边界远大于聊天历史

编码 Agent Transcript 往往不只有 Prompt。里面可能包含文件路径、专有代码片段、Shell 命令、部署输出、客户标识、数据库 Schema、Incident 细节，以及工具意外打印出的 Credential。因此，一旦集中化会话，就新建了一个高价值敏感数据存储。

采购检查应覆盖加密、Tenant Isolation、管理员控制、SSO、Audit Log、Retention、删除、Subprocessor、数据区域、备份行为、Incident Notification 和模型训练条款。公开文档没有回答的内容应该被当成合同评审中的 Unknown，而不是按最安全的方式猜测。

理想架构还应该把 Raw Evidence 和 Promoted Knowledge 分开。原始 Transcript 可以权限更窄、保留更短。像“所有支付写操作必须带 Idempotency Key”这样的已评审决策，可以晋升为带版本、Owner 和 Review Date 的团队规则。

共享 Agent 会话的经济价值怎么计算？

真正有意义的指标不是“同步了多少 Session”，而是在不增加错误的前提下，减少了多少协调工作。

一个简单模型：

月度价值 = 避免的重复调查 + 更快交接 + 更短 Onboarding - 平台成本 - Review 成本 - 上下文诱发错误

如果 5 位工程师每天各花 20 分钟重新理解别的 Agent 已经调查过的内容，一个月就是超过 33 个工程小时。只减少一部分都可能有价值。但如果共享存储让一个过期决策看起来像权威事实，这些节省也可能很快被一次错误抵消。

应该测量重复调查次数、交接后到第一个有效改动的时间、重复失败命令、Review 时间、Context Retrieval Precision，以及由旧上下文或跨项目上下文导致的严重错误。工具必须改善这些 Outcome，而不是只扩大 transcript 仓库。

什么时候应该买 Mosaic，什么时候自己做 Session Sync？

自建系统看起来简单，因为每个 Agent 本来就会写日志。真正昂贵的是格式变化、权限、Secret Handling、去重、索引、Summarization、旧知识失效和删除。只有这些控制本身就是差异化或硬性要求时，自建才值得。

一个 30 天 Mosaic 工程团队 Pilot

1. 选两个 Repository 和两个 Agent 产品。 在 Retrieval Quality 可测之前，不要全公司 rollout。
2. 定义三个交接场景。 Bug 调查、Feature 续做和 Incident Follow-up 都合适。
3. 先测 Baseline。 没有共享上下文时，团队成员重建前一位 Agent 工作需要多久？
4. 带明确 Scope 同步会话。 客户与 Repository 边界必须始终可见。
5. 人为制造冲突。 修改 API Contract 或架构决策，测试旧上下文是否还被当成当前事实。
6. 人为放入 Secret。 用合成 Credential 检查捕获、Redaction、Search 和删除。
7. 测试跨工具 Handoff。 一个 Agent 调查，另一个 Agent 产品只依赖共享上下文和 Repository 继续。
8. 比较 Outcome。 交接时间、重复工作、Retrieval Precision、严重错误和 Review 工作量。

如果要设计更完整的多 Agent 运行方式，可以结合我们的 30/60/90 天 AI Agent Pilot 指南和 Git Worktrees 与 Jujutsu 对比。共享上下文不能替代代码隔离。

Wavect 在这里能做什么？

Wavect 的 AI Enablement 帮助工程团队统一 Agent Workflow、上下文边界、Eval、成本控制和跨工具交接。我们的 Twinsoft AI 案例展示了模型能力之外还需要哪些工程，才能把零散 AI Demo 变成可运营产品。

商业问题不是“要不要自己重做一个 Mosaic？”，而是“哪一层上下文应该由团队掌握，哪一层可以当 Commodity 买？”一个设计良好的 Pilot 能在工具选择变成架构之前回答这个问题。

结论

Mosaic 的方向是合理的：团队规模的 Agent Adoption 会产生 Git Commit 和私人 Transcript 无法解决的上下文问题。最有价值的不是“Multiplayer AI”这个标签，而是把 Agent 工作变成可检查的组织证据，让另一个团队成员或 Agent 能够从真实历史继续。

真正未解决的采购问题是 Session Sync 能否升级成可信 Memory。它需要 Provenance、权限、Stale Context Handling、Redaction、删除和选择性 Retrieval。如果 Mosaic/Ocean 能做好这些层，它可能成为单个编码 Agent 之上的重要基础设施。如果它只是集中 Transcript，团队获得的是可见性，但知识层仍然需要自己构建。

来源与证据边界

本文在 2026 年 9 月 7 日复核了主要产品和类别来源。Mosaic 官方页面与 YC 描述产品方向；约 2,000 次安装和 37 个同步组织来自公司发布数据。YC 与 Anthropic 独立说明了 Human-Agent Multiplayer 正在形成一个类别，但不证明 Mosaic 的可靠性、安全性或商业表现。Wavect 没有安装 Mosaic/Ocean，也没有审计其后台，因此公开资料没有说明的实现细节都被视为未知。