上下文层被收编了：Chroma 加入 Replit，Chroma Cloud 60 天内关停

发生了什么：一纸最终协议，和一个 60 天倒计时

2026 年 10 月 23 日，Chroma 首席执行官 Jeff Huber 在公司博客上宣布：Chroma 已签署最终协议（definitive agreement），加入 Replit。同一句话里有两个信息，值得分开读。第一句是战略表述：“我们将共同构建自驱公司的上下文层（the context layer for the self-driving company）：一家 agent 做越来越多的工作的公司，因为它们知道组织所知道的一切。”第二句是立即生效的现实：Chroma 的托管云服务将在未来 60 天内关停。同一篇公告，一半是愿景，一半是截止日期；读这篇新闻的人，恰恰最容易只读前一半。

先把几个基本事实钉死。签署的是“最终协议”，不是意向书：最终协议是买卖双方在尽职调查之后签署的有约束力的合同，意味着交易已经越过谈判阶段，进入执行阶段。但公告没有披露价格、没有披露交割日期，也没有说明 Replit 的产品里何时会出现这个“上下文层”。这三项空白不是疏忽，而是这类公告的常态：价格与交割时间属于交易条款，不披露就不应猜测；上下文层的上线时间属于未来产品计划，没有日期就不应把它写成已上线的功能。任何把这篇公告写成“Replit 已上线上下文层”或“Chroma 被 X 亿美元收购”的报道，都是在公告没有表态的地方替它表态。

在展开之前，先把这篇与本站已有的 Replit 文章划清界线。10 月 17 日那篇讲的是 Replit 把默认模型供应商交给 OpenAI，关键词是“默认位”；10 月 22 日那篇讲的是 Replit 的 Monitoring Agent，关键词是“自主值班工程师”，那篇甚至逐帧核验了官方演示视频。而本篇讲的是第三件不同的事：一家向量数据库公司加入 Replit，以及它的托管云服务随之关停。如果你已经读过前面两篇，本篇不会重复它们；如果你是第一次读 Replit 的文章，本篇也可以独立成立，因为它只依赖 10 月 23 日这一份 Chroma 公告和同一天发布的关停时间表。

Chroma 是什么：从训练数据到 agent 的上下文

Chroma 的起点不在向量数据库，而在训练数据。按 Huber 公告的自述，公司 2022 年成立时要解决的是主动学习（active learning）——为深度学习筛选训练数据；ChatGPT 发布后，公司把焦点从训练转向推理，核心问题变成“如何给 agent 提供上下文”。2023 年 2 月发布的 ChromaDB 正是这个转向的产物：一个开源的、分布式的、无服务器形态的向量数据库。在它最风光的时候，Huber 称公司一度估计自己占据了向量搜索下载量的 95% 以上——这个数字是公司自述，不是第三方审计，引用时必须带上这个限定。但有一点不需要限定：ChromaDB 确实成了几百万开发者第一次接触“给 AI 提供上下文”这个概念的入口，公告列出的客户包括 SpaceXAI、Mintlify、Krea、Paramount、Retool、Coreweave 以及“数以万计的其他客户”。

Chroma 的技术积累也不只是一个数据库。公告提到的几份技术报告——Context Rot（上下文腐烂）、Context-1、Fission 事务、对象存储原生的检索、wal3（基于 S3 的预写日志）以及查询执行引擎——共同指向一个判断：向量检索本身早已不是难事，难的是让检索结果在长时间、大规模、多租户的条件下依然准确、便宜、可维护。2026 年年中，公司把这个判断产品化为 Foundation：一个面向企业上下文的、自改进的上下文解决方案，公告称它在 BEAM 记忆基准上达到最优（SOTA）成绩，并在发布后迅速走红。BEAM 成绩同样是厂商自述，基准本身的公信力需要独立验证；但 Foundation 的出现说明了一件事：Chroma 在被收购之前，已经从“卖一个数据库”转向“卖一层企业上下文服务”，而 Replit 收购的正是这个转向之后的东西，不只是那个开源数据库。

为什么是 Replit？公告给出的关系线索很具体：Replit 总裁 Michele Catasta 与首席执行官 Amjad Masad 都是 Chroma 的早期投资人，两家公司早在 2023 年 3 月就联合推出了 Replit 上的 Chroma 模板。收购不是陌生人之间的交易，而是长期合作关系的收束。Huber 的表述是：Chroma 最先进的上下文与记忆基础设施，加上 Replit 更广泛的 agent 平台技术与规模化的市场拓展能力，是“强有力的组合”。翻译成更直白的话：Chroma 有被几百万开发者验证过的检索技术，但缺乏把这项技术卖进企业的规模化渠道；Replit 有 agent 平台和用户规模，但 agent 越来越需要“知道组织所知道的一切”——而这正是它自己一直缺的那一层。双方各取所需，这也是这笔交易最容易理解的部分。

最紧急的部分：Chroma Cloud 的两个截止日期

对 Chroma Cloud 的现有客户来说，公告里最重要的一段不是愿景，而是关停时间表。Chroma 同一天发布的《Chroma Cloud wind-down timeline》写明了两个里程碑。第一个是 2026 年 11 月 22 日：30 天后，Chroma Cloud 变为只读，应用将无法再创建、更新或删除其中的数据。在此之前，客户需要停止或转移写入 Chroma Cloud 的工作负载，把活跃负载迁移到其他 Chroma 部署或其他数据库，并开始导出和验证需要保留的数据。第二个是 2026 年 12 月 22 日：60 天后，Chroma Cloud 不再响应读取请求。在此之前，客户必须完成所有导出和迁移工作，验证迁移后的应用不再依赖 Chroma Cloud 的端点，并删除或轮换存储在应用与基础设施中的 Chroma Cloud 凭证。

这两个日期的含义需要讲透。11 月 22 日不是“服务关闭”，而是“写入关闭”：读还可以继续 30 天，这 30 天是留给迁移验证的缓冲期，不是留给拖延的宽限期。一个常见的错误是把只读期理解为“还有一个月可以慢慢想”，等到 12 月 22 日前一周才开始导出，结果发现导出量、格式转换或目标库的导入速度跟不上截止日期。正确的做法是倒排时间：11 月 22 日之前完成写入侧的迁移（应用不再向 Chroma Cloud 写新数据），11 月 22 日至 12 月 22 日之间只做读取验证与收尾导出，12 月 22 日之前确认没有任何生产流量还指向旧端点。凭证轮换也要放进清单：即使应用已经迁移，旧凭证残留在代码仓库、CI 配置或环境变量里，本身就是一个安全隐患，关停清单的最后一项应当是“旧凭证已全部删除或轮换”，而不是“应用已迁移”。

还有一个需要澄清的边界：关停的只是 Chroma Cloud 这个托管服务，不是开源的 ChromaDB。公告明确写道，开源 Chroma 依然强劲，每月下载量 600 万次、GitHub 星数接近 3 万，公司已把更多私有仓库的代码提交到 Apache 2.0 开源仓库，并且 Replit 将在为企业上下文扩展该项目时继续回馈开源社区。换句话说，已经在自托管 ChromaDB 的用户，不需要因为这篇公告而迁移；需要行动的，只是把数据放在 Chroma Cloud 托管服务上的客户。把“Chroma 死了”和“Chroma Cloud 关了”混为一谈，是这类收购新闻最常见的误读——前者是错的，后者才是真的，并且后者附带两个写明的日期。

判断：agent 的价值正在从模型层移向上下文层

这笔交易值得写，不是因为又一家公司被收购，而是因为它标出了 agent 价值链上正在移动的位置。过去两年，agent 能力的竞争主要发生在模型层：谁的模型更聪明、上下文窗口更大、工具调用更稳。但模型正在快速商品化：价格在降、能力在趋同、切换成本在降低。当模型不再是稀缺资源时，稀缺的东西就变成了“模型知道什么”——也就是组织内部的数据、文档、历史决策、客户记录，以及把这些东西在正确的时间、以正确的形式交给 agent 的能力。Chroma 所谓的“上下文层”，正是这套能力的名字。Replit 收购 Chroma，本质上是在模型商品化的背景下，向上游买了一张“知道组织所知道的一切”的门票。

这个判断有一个直接的推论，对 vibe coder 尤其重要：如果你正在给自己的产品加 agent 功能，选型时最不应该只比模型。模型可以换，上下文层换起来要难得多：向量库里的数据、嵌入模型的选择、分块与检索策略、权限与租户隔离、以及历史对话的记忆结构，一旦落定，迁移成本远高于换一个 API 地址。这也是为什么 Chroma Cloud 的关停值得所有 agent 开发者警惕——不是因为 Chroma 一家公司的去留，而是因为它演示了一个通用风险：托管的上下文服务可能因为商业原因在 60 天内消失，而你的 agent 功能却建立在它之上。对策不是拒绝托管服务，而是从第一天就保留迁移路径：数据导出格式要是开放的、嵌入向量要能带走、检索逻辑不要与某一家厂商的专有 API 深度绑定。Chroma 的开源版本恰好提供了这样一条退路，但前提是你从一开始就没有把自己锁死在托管端点上。

还有一个判断是关于开源的。公告里对开源的承诺写得很具体：每月 600 万次下载、接近 3 万星、更多私有代码已提交到 Apache 2.0 仓库、Replit 将继续回馈。这些承诺的可信度，需要用未来的提交记录来验证，而不是用公告本身来担保。开源项目被收购后的命运，从来不是由收购公告决定的，而是由收购后 6 到 12 个月的提交频率、维护者去留、以及新功能是先进入开源版还是先进入商业版来决定的。对 ChromaDB 的用户来说，最务实的态度是：继续用开源版，但把“关注提交记录”列入季度检查清单；如果未来几个月开源版的更新明显放缓，再考虑迁移也不迟——而不是在公告当天就恐慌性迁移，也不是在公告当天就假装什么都没变。

给不同读者的行动清单

如果你是 Chroma Cloud 的客户，行动清单只有四项，按顺序做：第一，本周内盘点哪些应用还在向 Chroma Cloud 写入，列出清单；第二，11 月 22 日之前完成写入侧迁移，让生产流量不再依赖旧端点；第三，11 月 22 日至 12 月 22 日之间完成导出验证，确认迁移后的应用在只读期表现正常；第四，12 月 22 日之前删除或轮换所有旧凭证，并确认没有任何定时任务、测试脚本或文档示例还在引用旧端点。需要帮助可以联系公告中留下的支持邮箱（support@trychroma.com），但不要把“联系过支持”当作“已经迁移”。

如果你是自托管 ChromaDB 的用户，什么都不用做，但建议做两件事：确认你运行的版本与数据目录不在任何托管服务的依赖链上；把“每季度看一次开源提交记录”写进团队的检查清单。如果你正在为自己的产品选型 agent 上下文方案，建议在决策表里加三行：数据能不能完整导出、嵌入向量能不能带走、检索逻辑是否与厂商专有 API 解耦——这三行在选型当天看起来是多余的工作，在托管服务宣布 60 天关停的那一天，会变成你最庆幸自己做过的工作。最后，如果你只是关注 agent 行业走向，记住这笔交易的名字就够了：当一家 agent 平台开始收购上下文基础设施时，说明 agent 竞争的下一站，已经从“谁的模型更聪明”变成了“谁更知道你”。

再看一层：为什么是现在

这笔交易的时间点也值得单独问一句：为什么是 2026 年 10 月？公告本身给出了一个线索：2026 年年中，Chroma 意识到增长的下一个拐点来自企业上下文，于是开始做 Foundation。也就是说，Chroma 先是完成了从“数据库”到“企业上下文服务”的产品转向，然后才在转向完成之后被收购——收购方买的不是一个有待验证的想法，而是一个已经跑通企业场景的产品方向。同一周，Replit 还推出了面向企业的 Replit for Business（10 月 26 日的另一则独立公告，主打编排、沙箱与身份控制），两件事放在一起看，Replit 的企业化路线图就很清楚了：一边收编上下文基础设施，一边补齐企业客户要求的管控能力。两则公告是独立的，不要把它们写成同一笔交易，但它们的朝向是一致的：agent 平台正在从“给个人开发者做玩具”转向“给企业做生产力基础设施”，而这个转向需要上下文层和管控层同时到位。

还有一个更宏观的背景：2026 年下半年，agent 基础设施的收购与整合明显加速。模型厂商在降价抢默认位，平台方在收编记忆、检索、沙箱与评审等周边能力，独立工具的生存空间正在被上下游挤压。Chroma 的选择——加入一个更大的 agent 平台，而不是继续独立融资扩张——在这种背景下并不意外：一个每月 600 万次下载的开源项目，完全可以独立存在，但要把“上下文层”卖进企业客户的生产系统，它需要的不只是技术，还有销售渠道、合规背书与客户成功体系，而这些恰恰是平台方现成的东西。对独立开发者来说，这个趋势的含义是双面的：一方面，agent 开发的基础设施会越来越完整、越来越开箱即用；另一方面，关键组件的归属会越来越集中，选型时“如果这家厂商改变策略，我的退路是什么”这个问题，会变得比“这个组件现在好不好用”更重要。

常见误读清单：读这篇新闻时最容易错的五句话

第一句错话是“Chroma 被收购了，所以 ChromaDB 要死了”。错。公告明确写了开源 ChromaDB 继续，每月 600 万次下载、接近 3 万星、更多私有代码已提交到 Apache 2.0 仓库。死的是托管的 Chroma Cloud，不是开源项目。第二句错话是“Replit 已经上线了上下文层”。错。公告说的是“将共同构建”，没有给出上线日期；把未来计划写成已上线功能，是对公告的过度引申。第三句错话是“Chroma Cloud 用户还有 60 天可以慢慢想”。错。60 天是两个截止日期的跨度：11 月 22 日写入关闭、12 月 22 日读取关闭，写入侧迁移必须在第一个日期之前完成，而不是在第二个日期之前才开始。

第四句错话是“这笔交易花了 X 亿美元”。错。公告没有披露价格，任何价格数字都来自猜测或未经证实的报道，不应写进事实栏。第五句错话是“开源承诺写在公告里就等于兑现了”。错。开源的未来要看收购后 6 到 12 个月的提交记录、维护者去留与新功能的投放顺序，而不是看公告里的措辞。这五句话每一句都曾经在类似的收购新闻里出现过，也每一句都曾经误导过读者。读收购新闻时，最省力的办法就是对照公告原文逐句核对：公告写了什么，就写什么；公告没写什么，就留白——留白不是报道的缺陷，而是对读者最基本的诚实。

图：上下文层示意——企业数据 → 上下文层（Chroma 检索）→ agent（Replit）→ 带着组织知识完成工作。