Chroma 將加入 Replit：雲端 11 月停寫、12 月停讀，AI 資料庫用戶要做什麼？

Chroma 宣布將加入 Replit，對使用它建置 AI 搜尋的團隊，最需要先處理的是服務時間表。因為既有雲端版本將停止，應用程式不能只等下一次產品更新。

這件事容易被誤讀成整個資料庫專案關閉。但官方同時承諾繼續貢獻開源版本，所以雲端服務與自行部署的資料庫，受到的影響不同。

2026 年 10 月 23 日，官方公告表示已簽署加入 Replit 的最終協議。這是已簽約的消息，公告沒有提供可據以確認交易交割完成的日期。

對既有 Cloud 用戶，實際影響更明確：11 月 22 日停止寫入，12 月 22 日停止讀取。兩個階段會先影響資料更新，再影響查詢，不能把最後一天當成唯一期限。

如果團隊正在使用這項代管服務，現在就值得盤點依賴與安排遷移。代管服務是由廠商代為運行資料庫，這次時間表針對的正是這個入口。

要知道哪些部分需要搬走，得先弄清楚它在 AI 應用中保存了什麼，以及 Replit 想把這些能力放到哪裡。

Chroma 加入 Replit，要建立什麼樣的上下文能力？

雙方宣布的方向，是為組織內的 AI 代理建立上下文層。上下文是模型執行工作時能讀到的背景，可能包含文件、專案紀錄和先前的決定，並非只有眼前一句提示語。

代理若不知道公司已經決定什麼，就算能寫出流暢答案，也可能使用過期規格。因此，把適當資料找出來交給模型，是從聊天走向持續工作的必要環節。

公告提到將繼續推進 ChromaDB 與 Foundation。前者是資料庫，後者是官方面向組織上下文的工作方向，不能直接理解成每個 Replit 用戶已獲得同樣功能。

Replit 希望讓代理承擔更多工作，因此整合背景資訊有合理用途。但公開願景不等於既有客戶資料已經搬到新服務，也不代表原來的程式連線可以繼續使用。

截至文章查詢日 2026 年 10 月 24 日，最能直接採取行動的資訊仍是 Cloud 停止服務的安排。產品整合若有新的入口、方案或相容性條件，仍應依後續正式文件判斷。

因此，讀這則消息可以分兩個時間尺度。長期看它如何將檢索與組織記憶結合，短期則先確認自己的軟體是否仍依賴即將停止的端點。

延伸閱讀：Replit Self-driving company 是什麼？AI Agent 如何讓工程產出提高 2.9 倍

向量資料庫在 AI 搜尋裡保存了什麼？

向量資料庫讓系統能依意思接近的程度找資料。向量可以想成內容的數字表示，兩段文字的主題相近時，系統就有機會把它們一起找出來。

以公司客服知識庫為例，使用者問「帳單為什麼多收一次」，搜尋結果可能需要找到標題為「重複付款處理」的文件，而不是只比對完全相同的字。

但搜尋不只需要這組數字，還需要原文與來源資訊。否則模型雖然找到相似片段，卻不知道這段內容出自哪份文件、哪個版本，或是否已經失效。

應用也常利用額外欄位縮小範圍，例如只搜尋某個部門或某個客戶可看的內容。這些欄位就是附在文件旁的描述資料，遷移時如果漏掉，搜尋行為就會改變。

因此，搬移系統不能只確認「文字都在」。還需要確認向量、文件識別、附加欄位與查詢方式是否能一起延續，才能保留原本的檢索結果。

這裡沒有一套能套用全部公司的匯出步驟，因為資料怎麼存、權限怎麼實作，取決於原本的程式。但可以先用這個結構盤點，避免快到期限才發現缺少重建搜尋所需的資訊。

這份盤點也能幫忙區分兩種工作：保住現有服務，和採用新公司的未來整合。兩者可以分開規劃，不必因為想體驗新功能而延後必要的資料搬移。

11 月停寫、12 月停讀，分別會影響哪些功能？

官方停止服務時間表將流程分成兩階段。以下列出對程式的直接影響，方便團隊找出最早會出問題的環節。

表格裡的第一階段是改為唯讀，並不是資料立即消失。既有內容仍可讀取，但持續同步新文件的流程，會先失去寫入能力。

假設客服團隊每天更新常見問題，網站可能仍能回答舊問題，讓人誤以為沒有異常。但新政策沒有成功寫進去，答案就可能逐漸落後於實際營運。

如果應用把刪除資料也視為日常同步的一部分，同樣需要在停寫之前安排切換。因為官方將刪除列入禁止的寫入操作，不能只測新增就認為所有工作都已涵蓋。

第二階段則連原有資料的讀取也停止。所以不能把唯讀期當成永久備援，應在最後期限之前完成匯出與新環境驗證。

官方要求用戶提前停止或轉向其他寫入工作，並完成需要保留的匯出。這表示實際計畫應往前排，留出修正資料和測試查詢的時間，而不是等停服當天才開始下載。

先找到「誰還在寫入」，比只看網站能否開啟更有效

資料庫可能同時被後臺排程、人工上傳和代理工具使用。如果只從前臺問幾個問題，仍可能漏掉一個每天晚上才啟動的同步工作。

因此，盤點時可以依原有系統紀錄找出所有讀寫入口。列出每個入口的用途、負責人、更新頻率與切換狀態，才比較容易判斷是否還有依賴藏在背景。

這是一份遷移工作表的建議，不代表本文已檢查任何使用者的系統。具體做法應以團隊實際部署與權限為準，不需要先把所有工具全面重建。

若某個功能只使用唯讀資料，可以安排在保住匯出後再切換。但仍要明確排入十二月前的驗收，否則暫時可用的狀態容易讓人錯過最後的依賴清理。

資料搬完之後，為什麼還要比對搜尋結果？

資料筆數相同，仍可能搜尋出不同內容。因為檢索依賴的不只是原文，還包含向量如何產生、比對方式與額外欄位的篩選條件。

可以先保留一組原本常見的問題，記下應該找到的文件與來源位置。再用新環境跑相同問題，就比較容易發現內容雖已搬過去，檢索順序卻有明顯變化。

如果新環境需要重新產生向量，應另外記錄使用哪個模型與版本。不同模型產生的數字表示未必能直接混用，否則結果異常時會很難找出原因。

文件識別也要保持一致。假設同一份政策每次更新都變成一筆全新資料，卻沒有移除過期版本，模型就可能同時讀到互相矛盾的規則。

有分部門或客戶權限的應用，還要測試隔離條件。因為公開文件找得到只是其中一種成功，受限文件不該被錯誤讀取，也是原本功能的一部分。

接著再檢查更新流程。新增一份文件、修改一段內容和移除一筆資料，都應能反映在後續查詢，否則系統可能只在搬遷當下看起來正確。

若團隊採分段切換，也應決定如何處理兩邊不同步的期間。例如切換前暫停特定更新，或記錄哪些變動需要補寫，避免以為兩邊都有資料就自然一致。

最後才比較延遲與日常成本。因為如果搜尋已經找錯內容，再快的回應也無法補回品質，而模型產生的流暢文字反而可能掩蓋檢索出錯。

驗收應保留可重現的證據

一份實用的驗收紀錄，可以同時保存問題、找到的文件識別、篩選條件和模型使用的片段。這樣當答案改變時，就能區分是搜尋結果還是生成回答造成。

不要只比較兩段最終回答是否文字一樣。因為生成模型即使讀到相同文件，也可能換句話說，真正要確認的是來源正確、重要條件完整，以及過期規則沒有重新出現。

如果發現只有某一類問題退步，就針對該類查詢檢查資料切分與篩選方式。這比立刻更換整個模型或資料庫，更能保留問題與原因之間的關係。

這套驗證可以先選最重要的業務範圍，不必等待全部歷史資料整理完才開始。因為及早找出一個缺欄位的問題，通常比最後一次大量搬完才返工更容易處理。

切換前如何處理設定與憑證？

資料搬到新位置之後，程式仍可能連著舊端點。端點就是服務接收請求的網路位置，因此更新資料庫本身，和更新使用它的程式設定，是兩項需要分別驗收的工作。

可以先從測試環境替換連線，再查詢一份已知文件。確認結果符合預期後，才依團隊既有流程調整正式環境，避免把資料匯入成功誤認為所有使用者都已改走新路徑。

有些系統會把連線資訊分散放在排程、部署設定和內部工具裡。若只改網站主程式，背景工作可能仍向舊服務發送請求，所以盤點時應連同這些設定來源一起記錄。

官方也提醒，完成後移除或更換原有雲端憑證。憑證是證明程式有權使用服務的存取資料，這項清理應在依賴已確認切換後執行，並沿用團隊既有的管理方式。

遷移紀錄不應包含可直接使用的憑證內容。保留是哪個系統、由誰管理以及是否完成更換，就足以讓負責人追查進度，不需要把秘密資料複製進工作表。

如果切換後仍有錯誤，先查是哪一個入口送出的請求，再決定是否回復設定。因為沒有依賴清單時，臨時改回一部分程式可能造成兩邊各有新資料，讓後續補寫更難處理。

這些細節讓遷移從「資料存在新地方」走到「日常工作能繼續」。只有搜尋、更新和背景排程都經過驗證，團隊才比較能安心結束對舊服務的依賴。

開源 Chroma 會繼續，哪些人可以先保持原有部署？

官方表示開源資料庫仍以 Apache 2.0 提供，Replit 也會繼續貢獻專案。這讓自行部署的用戶和 Cloud 用戶，有不同的當前優先順序。

如果系統本來就由自己的基礎設施運行，可以先確認版本、依賴與備份狀態。這次雲端時間表本身，不代表必須把可用的本機部署立即搬去另一家服務。

但開源承諾也不等於每個商業方案或支援條件永遠不變。若團隊依賴代管服務的特定功能，仍要逐一核對新環境能否承接，不應只因底層專案同名就推定相容。

對還沒導入的團隊，則可以把這次變動當成選擇部署方式的具體例子。自己維運能掌握更多環境，但也要承擔升級與備份；選雲端較省管理工作，仍需保留資料可搬移的能力。

這些取捨不需要預測哪家公司將來一定成功。只要先把資料格式、匯出路徑與驗收標準留在自己手上，就能在服務改變時更有把握地選擇下一步。

延伸閱讀：EverOS 記憶怎麼用？本機檔案、Cloud 與 AI 代理跨對話的工作流程

Chroma 加入 Replit 常見問題 FAQ

Chroma 開源資料庫也要停止嗎？

官方表示開源專案繼續，這次停止時間表針對既有 Cloud 服務。

自行部署與使用廠商代管的用戶，應先確認自己屬於哪一種。

11 月 22 日之後資料會立即不見嗎？

官方描述的是變成唯讀，先停止新增、更新與刪除。

原有讀取在下一階段停止，因此需要保留的資料仍應提前完成匯出。

Replit 是否會自動承接原本的連線？

已開啟的官方公告沒有提供可直接推定自動遷移的承諾。

既有客戶應依停止服務時間表安排搬移與驗收，再查後續產品整合文件。

Cloud 用戶先排遷移，自行部署者先查自己的依賴

如果正在使用既有 Cloud，第一件事是把十一月停寫和十二月停讀放進工作安排，並先保住可驗證的匯出。因為新產品願景還在推進，舊服務的期限已經具體。

下一步可依官方時間表列出讀寫入口，再用一組真實問題驗證搬移後的搜尋。免費訂閱 AI 郵報，持續追蹤 AI 基礎設施與工作流程的變化。

資料來源

• Chroma is joining Replit 官方公告。
• Chroma Cloud 官方停止服務時間表。
• Chroma 官方 X 貼文。