資料的雲端同步不是“把檔案傳上去再拉下來”這麼簡單。它要保護傳輸中的隱私，要讓雲端存儲成本可控，要串行化多設備寫入，要理解不同資料的結構，還要在危險刪除前確認，並在判斷出錯時保留回退路徑。
Orkas 把雲同步當作一條產品邊界，而不是後台小功能。會話、智能體、技能、任務狀態、知識檔案和設定都要在設備之間流動，同時保持清晰的責任鏈：設備準備內容，對象存儲儲存字節，服務端發佈權威索引。
這篇文章按機制梳理 Orkas 的雲同步：加密內容流、按內容尋址的存儲、帳號級同步租約、服務端提交、確定性同步規則、模型輔助衝突處理、刪除確認、回收站，以及失敗恢復標記。
同步契約
每一輪同步都會回答四個產品問題：哪些內容允許移動，內容如何被保護，誰有權發佈下一版雲端索引，以及如果判斷失誤，使用者如何恢復。
加密內容流
使用者資料到達雲端存儲前，會先在設備上被整理。同步引擎選擇候選內容，計算內容身份，加密載荷，通過短期憑證上傳；拉取時再校驗內容身份和元資料，確認可信後才寫回設備。
存儲與索引
Orkas 把檔案內容和雲端索引拆開。內容對象儲存加密字節；雲端索引記錄哪些資料條目應該存在、它們的內容身份、版本、大小、雲端版本號和刪除標記。設備還會儲存上次成功同步後的基線，用來區分舊狀態和新編輯。
一輪同步
同步先低成本檢查，只有確實有工作時才進入嚴格流程。Orkas 先判斷是否有變化，再拿到帳號級同步租約，在租約有效期內重新計算差異，移動內容，請求服務端提交索引操作，最後更新本機基線。
同步租約、鎖與提交
同步租約、服務端鎖和提交前版本檢查解決的是不同問題。同步租約減少多設備同時跑完整同步輪次的浪費；服務端鎖串行化索引寫入；提交前版本檢查會確認雲端索引仍是設備剛剛讀取的那一版，防止舊判斷被發佈成新事實。配額計算和資料版本校驗也在同一個服務端提交入口完成。
先規則，後衝突
大多數同步判斷並不是衝突。設備同時比較基線、當前設備資料狀態和雲端索引。只有雲端變了就拉取，只有設備變了就推送，兩邊都變了才按內容類型進入合併；如果發現內容消失，則進入刪除安全路徑，而不是立刻移除。
衝突處理
當兩邊確實都發生變化時，Orkas 不會簡單採用最後寫入者獲勝。追加型日誌可以按缺失記錄合併；列表型資料可以按穩定記錄身份合併；結構化 JSON 可以參考版本號和時間戳；Markdown 和二進制檔案更保守，無法證明無損時會保留輸掉版本的完整副本。
對於語義不清的文本或結構化內容衝突，產品可以把相關版本打包交給模型輔助處理。模型可以解釋差異、草擬合併結果，或幫助使用者選擇。但模型不是唯一防線：確定性校驗、原始版本歸檔和使用者可見的恢復路徑仍然保留。
刪除確認
刪除在 Orkas 里是一種狀態遷移。遠端刪除會成為刪除標記，設備端刪除會成為候選操作。Orkas 會檢查最近寫入、識別大批刪除，並在消失的使用者資料看起來有風險時暫停本輪同步，等待確認。
回收站與恢復
一次有效刪除真正移除設備副本前，Orkas 會先把它放入同步回收站。衝突中輸掉的版本會進入歸檔以便復查。對象上傳成功但提交失敗時，下一輪可以復用已上傳內容。使用者主動清空雲端資料後，其它設備會看到清理標記，避免把舊內容重新灌回雲端。
這套設計換來了什麼
這套同步系統的邊界很清楚：設備準備並校驗內容，對象存儲儲存加密字節，服務端發佈索引，同步租約和服務端鎖讓流程有序，規則處理常見變化，模型輔助處理語義不清的衝突，刪除確認和回收站保護使用者免於最昂貴的錯誤。
這就是 Orkas 對雲同步的要求：不是魔法，也不是盲目鏡像，而是一套讓使用者資料在多設備之間可靠流動、並保持一致體驗的機制。