为什么每次云端运行都会重新开始
全新会话是契约，而非故障
Warp 在参考文档和快速入门中两次声明了这一保证，其中快速入门中的表述更加明确：“每次运行都会启动一个全新的、隔离的会话，不会从以前的执行中继承任何状态，并且每次运行都可以在 Oz Web 应用中进行跟踪和审查。”
执行模型的其余部分解释了为什么这是理想的，而不仅仅是方便。“运行在没有人工干预的情况下自动执行。”以及“如果定时运行失败，它不会阻止未来的运行。每次执行都是独立的。”独立性是使无监督调度安全运行的特性 —— 如果一个运行继承了上周损坏的状态，它就会在无人看管的情况下默默地、永远地传播下去。
因此，隔离是刻意设计的。缺失的不是隔离，而是一个通道：一个可以让本次运行存放结论、并允许下次运行读取的地方。
环境是为了可重复性，而非记忆召回
显而易见应该寻找的地方是环境，而这正是大多数团队浪费一天时间的地方。Warp 的定义用一句话排除了它：“环境描述了 agent 如何执行任务，而不是它做什么。”
环境组合了 Docker 镜像、一个或多个 agent 克隆的仓库、设置命令、环境变量和 Agent Secrets。它的目的是保持一致性：“它们每次运行时都为 cloud agent 提供相同的容器、仓库和设置。”然后是彻底关上大门的那句话：“这些设置共同为每次运行创建一个全新的工作区。”
对于构建环境来说，这完全是正确的设计，但作为记忆（memory）则完全错误。每次都有相同的起点与积累知识背道而驰。“除非你的环境显式持久化数据”这一条款是真实的，但这意味着你需要自己连接持久化方案 —— 数据库、agent 提交的仓库、外部存储 —— 而不是环境本身能记住任何东西。
Warp 确实列出了一个相邻的插槽，即单次运行上下文（per-run context），它“提供特定于任务的数据，例如 Slack 线程、PR 元数据或 CI 日志”。这是触发器的有效载荷，而不是存储，并且它的范围仅限于接收它的那次运行。
交接（Handoff）可以恢复运行，但有三个前提条件
交接（Handoff）是人们接下来会发现的机制，它在自身领域确实表现出色。云对云交接（Cloud-to-cloud handoff）允许你向已结束的运行发送后续操作，Warp 对其携带的内容有着精确的描述：“交接保留了足够的状态，使接收方的 agent 能够恢复工作，而不仅仅是读取相关信息。”后续操作会进入“同一个对话”，并且“在 agent 回答你的后续操作之前，先前会话的仓库更改（已跟踪和未跟踪）都会被恢复。”运行身份也会保留 —— ID、任务、创建者、环境、调度触发器和集成源都会被保留。
但这是对某次特定运行的手动延续，在实践中受到三个重要条件的限制：
运行必须以足够干净的状态结束。“运行必须处于终态，例如成功、失败或取消”，并且“处于等待用户输入或审批的受阻运行无法通过云对云交接继续。”“早于 agent 对话模型”的极旧运行也无法继续。
必须有快照。运行“在每个会话结束时捕获工作区快照”，如果没有捕获快照 —— Warp 给出的例子是瞬态存储错误 —— “运行仍会继续，但不会恢复工作区状态。”警告更加直接：“文件上没有快照的较旧云端运行无法进行交接；请启动新的运行。”
并且所有权会限制它：“源自本地到云端交接的云端运行只能由创建它们的用户继续，而不能由其他团队成员继续。”Warp 还指出交接是“尽力而为的” —— 当更改无法干净地应用时，agent 会报告哪些失败并继续处理其余部分。
这并不是在贬低交接。它只是另一种形式：由人类决定延长某次运行，而不是一个能够学习的定时任务。
Warp 自身给出的答案已经存在，目前处于研究预览阶段
Warp 正在构建这个缺失的层，准确了解它的现状非常重要，这样你既不会忽视它，也不会过早地围绕它进行规划。
Agent Memory 被描述为“一个存在于 Warp 上并在每个受支持的 agent harness（包括内置的 Warp Agent、Claude Code、Codex 以及后续添加的其他工具）之间共享的持久记忆系统”。它明确包含了后台工作：“同时支持本地和云端 agent - 支持 Warp 中的交互式本地 agent 和后台云端 agent。”记忆是自动提取的 —— “当对话结束时，Warp 会提取持久的事实、学习成果和结果，并将它们写入记忆”，并且“新知识会与现有记忆合并，或者在冲突时进行覆盖。”它被组织为个人、agent 和团队存储，每个记忆“都会记录其来源”，并且“对记忆的每次更改都会被记录下来，以便团队可以检查记忆随时间的变化情况。”创建和检索在后台运行，因此它们“不会消耗 token，也不会增加活动任务的延迟”。
这是一个非常出色的设计，而且来源追溯（provenance）和可审计性并不常见 —— 请参阅为什么记忆来源追溯很重要以了解为什么这两个特性起到了很大的作用。
现状是其限制因素：“Agent Memory 处于研究预览（research preview）阶段，并针对设计合作伙伴按团队启用”，并设有申请加入的等待名单。如果你运行第三方 harness，还有一个值得仔细阅读的覆盖范围限制：“第三方 harness 在作为云端 agent 运行时受到支持”，以及“（在研究预览期间不支持在本地运行第三方 harness。）”编程式 API 访问和自托管被列为即将推出，目前尚不可用。
因此，正确的总结不是 Warp 缺乏记忆层。而是 Warp 确实有一个记忆层，它针对的正是这个问题，而目前它依赖于成为其设计合作伙伴。
人们尝试过的方法
将状态提交到仓库中。 这种方法可行，对于某些工作来说是正确的答案 —— agent 追加内容的已签入账本是持久的、可审查的且可对比差异（diff）的。但这也意味着每次运行都会针对一个非代码文件发起拉取请求（PR），并且它无法跨仓库发挥作用。
让调度指令更具体。 “跳过你已经处理过的任何内容”听起来很好，但无法执行，因为全新的会话没有它处理过什么内容的记录。
手动链式跟进。 将每周的运行交接给下一次运行。这确实可以携带工作区状态，但每个周期都需要人工干预，这违背了定时调度的初衷，并且会遇到上述的快照和所有权限制。
假设环境保留了某些内容。 上文已提及。环境被定义为“如何”而非“做什么”，并且它会为每次运行构建一个全新的工作区。
得出 Warp cloud agent 完全没有记忆的结论。 如果你只阅读了执行模型，得出这个结论是可以理解的，但它是错误的：Agent Memory 在设计上就覆盖了 cloud agent。准确的说法是，它目前处于研究预览阶段，并且仅对设计合作伙伴团队开放。
关闭定时调度。 这是最常见的结果，也是浪费工作最多的一种。
解决方案：为每次运行提供一个生命周期超越会话的读写场所
Warp 识别出的突破口非常准确：只有当会话外部有东西保存状态时，状态才能跨越运行边界。因此，在会话外部放置一个记忆层，让每次运行在开始时读取它，在结束时写入它。
MemoryLake 就是这样一个层 —— 一个由你拥有的、通过 API 访问的存储，因此无论运行是由定时任务、Slack 提及还是键盘前的人触发，都可以使用相同的知识。只需三个步骤。
步骤 1：创建 API Key
登录并在工作区设置中创建 API Key。将其存储为 Agent Secret，以便在运行时注入，而不是固化到镜像中，这正是 Warp 密钥机制的用途。
步骤 2：上传你的第一批记忆
用你的运行不断重复推导出的结论来初始化它。对于 issue 分类：哪些 issue 已经被判定为重复以及原因，哪些报告者需要特定的跟进问题，你的团队将哪些标签视为终态。对于依赖项工作：已经尝试并放弃的升级及其原因。对于清理工作：看起来已废弃但实际没有的文件。文件可以直接导入，包括多模态文件，因此运行手册图表或所有权电子表格可以直接放入。
步骤 3：连接你的 AI 和 agent
将 Warp 与你运行的其他任何工具连接起来。然后在 prompt 中明确写出读取和写入操作：首先检查之前的运行对该任务得出了什么结论，最后记录未来运行不应再次重复推导的任何内容。因为定时任务的 prompt 是跨运行唯一持久存在的东西，所以该指令就是持久的部分。
三个坦诚的限制。这不会改变 Warp 的隔离模型 —— 每次运行仍然会启动一个全新的会话，这是一件好事。它不会恢复工作区状态；仓库更改是交接（handoff）的工作，而 MemoryLake 保存的是知识，而不是 diff。并且它不能替代环境：镜像、仓库和设置命令仍保持原样。
这在实践中带来了什么改变
第一个改变是定时运行的 agent 不再重复自己。第二次运行会读取第一次运行得出的结论，并针对增量（delta）而不是整个表面进行操作。
第二个改变是运行历史记录变得有用，而不仅仅是可供查看。Warp 会保留所有内容 —— “删除调度会立即停止所有未来的运行。以前的运行及其会话历史记录仍可访问以供检查和审查，”以及“更改仅适用于未来的运行。过去的运行及其会话历史记录保持不变。”这是一个很好的审计追踪，但却是一个糟糕的检索机制，因为在下一次运行时没有任何东西会代表它去读取这些记录。记忆层则是将转录存档转化为 agent 可以咨询的参考资料的关键部分。
当你运行多个 agent 时，第三个改变就会显现出来。Warp 自身的设计也指出了这一点，即与共享 agent 关联的团队存储，同样的逻辑也适用于外部层：一个分类 agent 和一个审查 agent，如果它们都读取同一个存储，就不会再相互矛盾。这就是多 agent 系统的共享记忆中所描述的通用情况。
定时云端 agent 的最佳实践
编写 prompt 时，要假设它将在无人值守的情况下运行一年。 Prompt 是每次运行中唯一能幸存下来的东西，因此它应该说明首先读取什么、如何决定是否有内容值得报告，以及何时停止。
将知识和工作区状态分开。 仓库更改是交接（handoff）的领域。结论、决策和排除项则属于存储。将它们混在一起会产生一个无人能够审查的账本。
不要让存储无序增长。 Warp 提取“持久的事实、学习成果和结果”的模型是一个值得效仿的好过滤器：记录决策及其原因，而不是对话转录。应该给 AI agent 多少记忆进一步探讨了上限在哪里。
记录来源追溯。 Warp 要求对每个附件提供特定于存储的指令，正是为了让 agent 知道存储的用途 —— “每个附件都需要指令，以便 agent 知道每个存储的目的。”在外部应用同样的原则：记录哪个运行得出了结论，以便可以追踪并清除错误的结论。
刻意选择运行身份。 Warp 的默认设置是让运行以调度创建者的身份执行，而 cloud agent 身份则以应用身份进行身份验证。这一决定会影响谁可以审查 agent 的拉取请求（PR），它与记忆无关，但同时也很容易搞错。
在扩大规模之前，注意调度的波及范围。 运行费用将从团队的共享信用额度余额中扣除，并且在没有干预的情况下执行。记忆层通过缩小必须检查的范围，使每次运行的成本更低，这是一个值得衡量的附带好处。
如果它适合你的技术栈，请加入 Agent Memory 等待名单。 如果你的团队符合条件，拥有一个原生的跨 harness 存储是一件好事。只是不要把本季度的计划建立在研究预览版上。
结论
Warp 早就提前告诉了你规则：每次运行都会启动一个全新的会话，除非会话外部有东西保存状态，否则任何状态都不会跨越边界。这是无监督自动化的正确设计，但它留下了一个空白 —— 一个让本次运行为下次运行留下结论的地方。
Warp 正在通过 Agent Memory 填补这一空白，该功能覆盖了 cloud agent，目前处于面向设计合作伙伴团队的研究预览阶段。在它正式发布（GA）之前，其机制与 Warp 自身那句话所描述的完全相同：一个外部存储，在每次运行开始时读取，在结束时写入。全新的会话，积累的知识。只有当知识存在于会话内部时，这两者才会产生冲突。