数据的云端同步不是“把文件传上去再拉下来”这么简单。它要保护传输中的隐私，要让云端存储成本可控，要串行化多设备写入，要理解不同数据的结构，还要在危险删除前确认，并在判断出错时保留回退路径。
Orkas 把云同步当作一条产品边界，而不是后台小功能。会话、智能体、技能、任务状态、知识文件和设置都要在设备之间流动，同时保持清晰的责任链：设备准备内容，对象存储保存字节，服务端发布权威索引。
这篇文章按机制梳理 Orkas 的云同步：加密内容流、按内容寻址的存储、账号级同步租约、服务端提交、确定性同步规则、模型辅助冲突处理、删除确认、回收站，以及失败恢复标记。
同步契约
每一轮同步都会回答四个产品问题：哪些内容允许移动，内容如何被保护，谁有权发布下一版云端索引，以及如果判断失误，用户如何恢复。
加密内容流
用户数据到达云端存储前，会先在设备上被整理。同步引擎选择候选内容，计算内容身份，加密载荷，通过短期凭证上传；拉取时再校验内容身份和元数据，确认可信后才写回设备。
存储与索引
Orkas 把文件内容和云端索引拆开。内容对象保存加密字节；云端索引记录哪些数据条目应该存在、它们的内容身份、版本、大小、云端版本号和删除标记。设备还会保存上次成功同步后的基线，用来区分旧状态和新编辑。
一轮同步
同步先低成本检查，只有确实有工作时才进入严格流程。Orkas 先判断是否有变化，再拿到账号级同步租约，在租约有效期内重新计算差异，移动内容，请求服务端提交索引操作，最后更新本机基线。
同步租约、锁与提交
同步租约、服务端锁和提交前版本检查解决的是不同问题。同步租约减少多设备同时跑完整同步轮次的浪费；服务端锁串行化索引写入；提交前版本检查会确认云端索引仍是设备刚刚读取的那一版，防止旧判断被发布成新事实。配额计算和数据版本校验也在同一个服务端提交入口完成。
先规则，后冲突
大多数同步判断并不是冲突。设备同时比较基线、当前设备数据状态和云端索引。只有云端变了就拉取，只有设备变了就推送，两边都变了才按内容类型进入合并；如果发现内容消失，则进入删除安全路径，而不是立刻移除。
冲突处理
当两边确实都发生变化时，Orkas 不会简单采用最后写入者获胜。追加型日志可以按缺失记录合并；列表型数据可以按稳定记录身份合并；结构化 JSON 可以参考版本号和时间戳；Markdown 和二进制文件更保守，无法证明无损时会保留输掉版本的完整副本。
对于语义不清的文本或结构化内容冲突，产品可以把相关版本打包交给模型辅助处理。模型可以解释差异、草拟合并结果，或帮助用户选择。但模型不是唯一防线：确定性校验、原始版本归档和用户可见的恢复路径仍然保留。
删除确认
删除在 Orkas 里是一种状态迁移。远端删除会成为删除标记，设备端删除会成为候选操作。Orkas 会检查最近写入、识别大批删除，并在消失的用户数据看起来有风险时暂停本轮同步，等待确认。
回收站与恢复
一次有效删除真正移除设备副本前，Orkas 会先把它放入同步回收站。冲突中输掉的版本会进入归档以便复查。对象上传成功但提交失败时，下一轮可以复用已上传内容。用户主动清空云端数据后，其它设备会看到清理标记，避免把旧内容重新灌回云端。
这套设计换来了什么
这套同步系统的边界很清楚：设备准备并校验内容，对象存储保存加密字节，服务端发布索引，同步租约和服务端锁让流程有序，规则处理常见变化，模型辅助处理语义不清的冲突，删除确认和回收站保护用户免于最昂贵的错误。
这就是 Orkas 对云同步的要求：不是魔法，也不是盲目镜像，而是一套让用户数据在多设备之间可靠流动、并保持一致体验的机制。