为何我们放弃Cloudflare Durable Objects

# 我们为何将 Wire 从 Cloudflare Durable Objects 迁移走 来源：https://usewire.io/engineering/why-were-moving-wire-off-cloudflare-durable-objects/ Wire 是为 AI 智能体提供的上下文容器：隔离的知识处理存储（条目、嵌入向量、知识图谱与溯源图谱），可通过 MCP 进行查询。从第一天起，每个容器都由 Cloudflare Durable Object 承载。 但这一情况正在改变。我们从头重构了容器运行时，用完全相同的数据（同一容器、同一问题、同一评估标准 (https://usewire.io/why-wire/architecture-benchmark/)）对旧方案进行了基准测试，首批工作空间已迁移至我们自建的数据平面。本文就是这份基准测试背后的故事。 这不是一篇“我们离开了 Cloudflare”的帖子。我很喜欢 Cloudflare，Wire 的 API、前端、控制面以及所有处理流程仍然运行在 Workers 上。对于成千上万个小型、大多处于空闲状态的有状态单元来说，Durable Objects 近乎完美适配；我也没见过比它构建更快的平台。我们离开是因为四个结构性限制，而非可靠性问题。 ## 1. 向量索引位于对象外部 检索是容器最重要的功能，而嵌入向量存储在独立的服务 Vectorize 中。这意味着最热路径上多了一次网络跳转，还多了一份可能漂移的状态副本。DO SQLite 无法加载扩展，因此索引永远无法整合进来。 ## 2. 我们希望算力紧邻数据 检索是一个多阶段管道：混合候选生成、融合、查询扩展以及宽范围重排序。在 Durable Objects 上，只有其中一小部分能运行在数据所在处；其余部分被导出到对象周围的服务中。智能体在工具循环中调用容器，每一次跳转的波动都会落在关键路径上。 ## 4. 你无法自托管 Durable Object 受监管的团队一直要求将容器运行在自己掌控的基础设施上。一个只在 Cloudflare 上存在的运行时无法满足此需求。 ## 我们构建了什么 每个组织在 Fly Machines 上获得一个宿主进程 (Bun)，用于承载其所有容器。一个容器就是一个 SQLite 文件，通过 sqlite-vec 内嵌了向量索引，因此候选检索在进程内完成；模型调用、查询嵌入和重排序仍然输出到推理服务。快照发送到对象存储，因此容器可在任意位置逐字节重建。一个按区域划分的路由器将容器放置在调用方附近，控制面通过签名请求与数据面通信，且从不接触容器内容。 热工具调用耗时稳定在约 0.3 秒，而之前约 0.4 秒，且偶有超过 2 秒的尖峰。空闲容器端到端唤醒时间为 1.4 秒，之前为 3.7 秒。关于最后这个数字需要精确说明：这从来不是“Durable Object 冷启动”，隔离的 Worker 唤醒仅需毫秒级。那 3.7 秒是我们自己栈的重组时间。 表层没有任何变化。相同的容器 URL、相同的五个 MCP 工具、相同的 REST API、相同的响应格式。智能体继续调用同一地址；对已迁移容器的请求改由新运行时响应。 ## 重新获取持久性 Durable Objects 免费为你提供持久性和单写入者一致性，离开意味着我们必须重新实现它们。Cloudflare 在对所有 DO 存储写入进行确认前会先复制。我们的第一版方案仅能做到“在下一个检查点时持久”，而在负载下杀死机器的浸泡测试清楚地展示了这意味着什么：少量已确认的写入会丢失。真正的解决方案是持续 WAL 传输。一次写入直到其 WAL 帧进入对象存储后才会确认；组提交将此延迟控制在约 100 毫秒，且一台已死的机器无法带走已确认的写入。 如果你不需要上述四点，请继续使用该平台。 ## 关于数据的诚实解读 检索增益（Recall@5 从 78.1% 提升至 89.1%）并非全部来自架构改进；我们还换用了更新的嵌入模型。架构所做的是让昂贵的部分变得低廉：进程内检索允许你过度获取并进行宽范围重排序，而每个容器的索引足够小，足以使用精确最近邻搜索。完整的对比表格和方法论详见基准测试文章 (https://usewire.io/why-wire/architecture-benchmark/)。 ## 当前状态 新运行时处于测试阶段：目前包含我们的预览环境以及选择加入的生产工作空间，随着我们的持久性判断条件保持绿色，将逐步进行完整的生产迁移。一旦迁移完成，我们计划开源该容器运行时。我们应该发布我们实际运行的代码。