Cloudflare Durable Objects 用于 AI：状态与恢复

Cloudflare Durable Objects 用于 AI，适合助手需要稳定位置来协调会话或任务的场景。困难的设计问题在于这些状态意味着什么。聊天记录、运行中的任务和已批准的业务变更，不应仅因为属于同一助手就变成同一条记录。

使用 Durable Objects 协调身份明确的应用状态，并区分对话历史、任务状态和外部业务结果。中断后根据持久记录重建工作，重连时检查当前权限，将模型上下文与权威状态分开。持久存储是构建模块，并非完整恢复策略。

设想维护助手正在准备服务报告。它收集笔记、起草建议，然后等待主管。等待期间浏览器可能断开，主管可能在其他地方打开任务，而底层设备记录也可能在批准前改变。

本文为这种情况解释建议的状态设计，不声称有必要保留每条对话消息，也不认为对象身份会自动匹配组织的访问边界。

Cloudflare Durable Objects 用于 AI 需要身份模型

Cloudflare 将 Durable Objects 描述为协调有状态应用的平台。为 AI 功能分配对象前，先定义它代表什么：对话、已接受任务、共享资源，还是其他范围明确的单元。

每个对话一个对象，可能方便交互，但服务报告可能需要能够延续到对话之外的身份。如果多位同事共同处理报告，将报告完全绑定到第一个浏览器会话，会使之后的访问和交接难以理解。

根据可信应用上下文推导路由标识符。调用者猜到另一任务的标识符，不应因此获得内容访问权限。对象路由与应用授权是不同责任。

将权威事实保留在对话摘要之外

模型生成的摘要可以帮助助手继续对话，但不应成为主管已批准建议的唯一证据。应将批准事件关联到报告版本与已认证复核者。

同样，应明确保留当前任务阶段。“等待复核”应是应用记录的状态，而不是助手记得曾经说过的一句话。后续模型响应不能因为聊天记录暗示工作大概已完成，就编造状态转换。

Cloudflare 的对话状态与记忆指南 区分了持久对话历史与提供给模型的上下文。这是重要的实现区别：存储的信息不必全部放进下一条提示词。

对于报告，助手可以接收精简任务摘要及选定的允许证据。应用则可单独保留权威来源与事件记录，分别采用自己的访问和保留规则。

设计能够拒绝过时决定的状态转换

为每份可复核报告分配版本。主管的批准应标识这个版本。如果复核页面打开后出现新笔记，应用必须决定它们是否让建议失效，还是可以分开处理。

操作到达时检查当前任务状态。过时标签页不应批准已取消报告，重复点击也不应创建第二次业务操作。对于已接受操作，应返回已经确认的结果。

这些是应用规则。状态平台提供实现位置，却不能决定维护笔记变化是否具有商业意义，也不能决定哪位主管拥有权限。

根据记录恢复，而不是依靠进程内存

将内存值视为临时工作状态。记录恢复任务所需事实，并识别已经发出的外部请求。重启后，应无需将整段对话重新交给模型，就能重建当前阶段。

对于维护报告，保留来源版本、草稿版本、批准状态和目标操作编号。如果目标接受了报告却丢失响应，这个编号比再次生成解释更有用。

区分从未开始的工作与结果未知的工作。只有前者显然可以安全启动。对于后者，在再次提交前，应检查目标系统，或使用其支持的防重复机制。

在有意义的阶段之间中断应用，测试恢复。然后让另一位工程师根据存储证据识别任务并确定下一步。这能暴露普通成功路径演示无法发现的状态缺失。

按当前权限重新连接

同事重连时，按照应用会话规则重新认证，并检查当前任务权限。不要假定持有旧对话标识符就能无限期保留访问。

加载任务已记录状态和观察时间，说明系统是在等待、处理、失败，还是等待核对。如果无法确定进展，应展示不确定性，而不是让模型提供令人安心的答案。

决定哪些记忆有用，哪些应过期

对话历史、来源文档和运维证据可能有不同保留需求。加入自动记忆前，应先定义这些需求。永久保留每项输入，会增加后续删除与权限复核难度。

区分可重复使用的偏好与任务事实。偏好的报告格式可能跨会话仍有用，临时访问令牌或已撤回客户细节则不应成为助手永久记忆。

来源记录被删除或访问被撤销时，也要考虑派生状态。摘要可能包含与来源相同的敏感事实。应用需要为已存草稿、检索段落和面向模型的上下文制定策略。

关于检索型记忆，我们的 RAG 数据时效指南 介绍索引中的更新与移除。不要将向量搜索结果视为当前任务阶段的权威陈述。

选择能够运维的状态边界

在负载尚无需求前，不要将每个关注点都拆成独立对象。边界过多会让简单任务更难追踪。同样，将所有客户和任务放进没有区分的共享状态，也会造成访问和责任问题。

先绘制示意图，说明已认证请求如何到达任务、哪些记录具有权威性，以及外部业务影响在哪里发生。明确哪个组件能够解释每种故障。

Cloudflare 的 Agents 概览 提供更广泛的运行时背景。使用适合所选版本、已有文档的 API，并在将实验性接口纳入支持承诺之前先测试。

验收集应包含并发复核者、重复操作、来源版本变化、重连和目标不可用。有用结果不只是状态得以保留，而是应用以正确权限恢复正确工作。

估算状态设计与交接工作

实施成本取决于任务转换、协作、来源关系和恢复要求。聊天记录存储的范围，远小于具有批准和目标核对的协调任务系统。

要求 GBP 方案报价，明确状态责任归属、访问规则、保留行为与恢复测试。包括应用代码变化时演进已存记录的方案。现有任务不应在部署后变得无法读取。

范围明确的 AI 集成试点 可以围绕一项有用任务建立这些契约。请提供任务生命周期、复核者和关联系统，索取有状态助手方案 。这能让存储设计服从实际工作，而不是偶然让聊天记录定义设计。

常见问题

AI 记忆与持久存储相同吗？ 不同。持久存储保留应用信息，模型上下文则是为某次推理提供的信息。应决定哪些已存事实具有权威性，哪些信息被选择或概括后提供给助手。

每个对话都应该有自己的任务吗？ 只有符合业务流程时才这样做。一个对话可能讨论多个潜在任务，一项已接受任务也可能跨多个对话继续。应为已接受工作分配能够延续到起始界面之外的身份。

对象标识符能证明调用者拥有数据吗？ 不能。返回状态或接受操作前，应检查已认证身份与当前权限。猜测或重用路由标识符，不得扩大访问。

重启后应该保留什么？ 持久保存确定任务阶段所需事实、来源与草稿版本、批准和外部操作编号。临时进程内存不应成为已接受工作的唯一证据。

对话摘要可以记录批准吗？ 可以描述批准，但权威批准应保留为已认证应用事件，并关联精确建议版本。模型生成的句子不应授权业务变更。

过时浏览器操作应该如何处理？ 根据当前状态与版本检查。拒绝或刷新过时决定，并在适当时为已接受操作返回记录结果。不能仅因用户再次点击就产生另一次影响。

怎样的有状态助手试点才有用？ 应演示身份边界、并发操作、中断、重连和目标结果不确定。另一位工程师应能根据存储证据恢复任务，而不必要求模型重建发生过什么。