• 桌面应用
• 开发者工具
• 人工智能
• AI 应用
• AI Agent
• 代码智能体

本文基于仓库内 specs/APP-4318/TECH.md 编写，并结合app/、crates/warp_features/中对应源码实现进行佐证与扩充。文章聚焦 Warp 的 Cloud Mode（云端环境中的 Agent 会话）在一次执行（execution）结束后，在同一终端面板内继续发起云端后续对话的完整技术方案：包括服务端 public API 契约、客户端 run/execution 感知模型、共享会话热切换（hotswap）机制、tombstone “Continue” 入口，以及围绕HandoffCloudCloud特性开关的增量落地（PR）计划。阅读完本文，你将理解 Warp 如何在不重建终端视图的前提下，把一条云端 Agent 会话“接力”到下一次执行，并掌握该功能在客户端各层（view model、terminal manager、event loop、tombstone 视图）的落点与测试边界。

1. 背景：从“一次运行一个会话”到“稳定 run、多次执行”

Cloud Mode 的 ambient 对话在改动之前，将一个 ambient task/run 视为一次共享会话执行：首个 Cloud Mode 面板在 app/src/terminal/view/ambient_agent/mod.rs 中以 deferred 共享会话 viewer 形式创建，ambient model 发出SessionReady事件后，viewer manager 才加入该会话。执行一旦结束，会话即终结，对话无法在云端延续。

本规范（APP-4318）的目标是为“同一会话内多次云端执行”奠定客户端基础：TerminalManager::attach_followup_session可以在不更换终端视图的前提下替换当前活跃Network，并以**追加模式（append mode）**加入一个新的共享会话，相关实现位于 app/src/terminal/shared_session/viewer/terminal_manager.rs。

这里引入了一条关键的架构边界，也是理解本文的钥匙：

• 会话 ID（session ID）是传输（transport）作用域的——每次执行对应一个新的共享会话、一个新的网络连接；
• 而用户可见的 ambient 会话、终端视图、终端模型、task/run 身份在整个 follow-up 过程中保持不变。

事件循环已经具备 follow-up 加载模式，TerminalModel::append_followup_shared_session_scrollback只追加未知的新 block ID，而不是整体替换 blocklist，见 app/src/terminal/shared_session/viewer/event_loop.rs、app/src/terminal/model/terminal_model.rs 与 app/src/terminal/model/blocks.rs。

由于改动横跨 public API 客户端、ambient task/run 数据模型、ambient spawn/follow-up 状态转换、云端会话 tombstone、终端输入行为与测试，文档明确要求**以一组可独立合并的 PR 栈（stack of mergeable PRs）**推进，而非单个大 PR。

2. 服务端契约：follow-up API 与 run 执行抽象

2.1 public API：POST /api/v1/agent/runs/{runId}/followups

服务端 public API 新增了POST /api/v1/agent/runs/{runId}/followups，请求体为RunFollowupRequest { message }，被接受后返回一个空的成功对象。客户端应按如下方式观测就绪状态：持续GET /api/v1/agent/runs/{runId}，直到 run 暴露出一个活跃的共享会话。

客户端侧对应的请求体类型与服务接口已经在当前仓库落地：

// app/src/server/server_api/ai.rs #[derive(Debug, Clone, serde::Serialize)] pub struct RunFollowupRequest { pub message: String, }

接口方法签名（见 app/src/server/server_api/ai.rs）：

async fn submit_run_followup( &self, run_id: &AmbientAgentTaskId, request: RunFollowupRequest, ) -> anyhow::Result<(), anyhow::Error>;

2.2 Run 执行（run execution）：新的服务端抽象

“Run executions”是服务端的新抽象：一个稳定的 run/task 可以有多次执行尝试（execution attempts），每次执行各自拥有独立的输入、状态、共享会话、conversation ID 与计算计费。这是 follow-up 得以成立的前提——延续的是 run，变化的是 execution。

当前客户端尚不是 execution-aware 的，文档点名的三处“扁平化”结构（这些位置在后续 PR 中会被访问器逐步取代）：

• app/src/ai/ambient_agents/task.rs 中的AmbientAgentTask：只存一个session_id、一个session_link、一个conversation_id、一个is_sandbox_running；
• app/src/ai/agent/conversation.rs 中的AIConversation：只存单一task_id/run_id；
• app/src/ai/ambient_agents/spawn.rs 中的spawn_task：轮询 task 直到看到单一 session ID。

2.3 云端 tombstone 现状

Cloud Mode tombstone 已存在，能够渲染 artifacts 与 “Continue locally” 动作，见 app/src/terminal/view/shared_session/conversation_ended_tombstone_view.rs。当前它由通用共享会话结束路径TerminalView::on_session_share_ended（app/src/terminal/view/shared_session/view_impl.rs）插入。而新的 ambient 热切换路径有意避开整套 teardown，因此 follow-up 需要一条专门的“ambient 执行结束”UI 路径：插入 tombstone，但不把 viewer 置为只读或永久终结状态。

3. 特性开关：HandoffCloudCloud与CloudModeSetupV2的依赖不变式

新功能必须挂在新的客户端特性开关HandoffCloudCloud之后。启用HandoffCloudCloud必须隐含CloudModeSetupV2已启用：只要HandoffCloudCloud打开，运行时代码即可假定 setup-v2 的行为，因此新调用点只需检查FeatureFlag::HandoffCloudCloud，无需重复检查两个开关（除非仍在保留旧的 setup-v1 行为）。

该开关已存在于仓库 crates/warp_features/src/lib.rs：

/// Redux of the setup/initial user query UI for cloud mode. CloudModeSetupV2, /// Enables continuing cloud mode conversations in the cloud after an execution ends. HandoffCloudCloud,

落地要求：

• 不要把HandoffCloudCloud加入 release/preview/dogfood 清单，直到完整流程对该受众就绪；
• 当它被加入任一 rollout 清单时，若CloudModeSetupV2不在同一清单，必须一并加入；
• 添加一个小型 feature-flag 测试或辅助断言，编码该依赖关系：任何静态 rollout 集合若包含HandoffCloudCloud，则必须同时包含CloudModeSetupV2。

4. Run/Execution 感知的客户端模型

4.1 引入显式的 run 身份与 execution 作用域类型

在 ambient agent 模型层引入显式的 run 身份与 execution 作用域类型，文档给出的最小形状如下：

• AmbientAgentRunId，或在命名从 task 迁移到 run 期间复用AmbientAgentTaskId并配以更清晰的访问器；
• AmbientAgentRunExecutionId：对应服务端 execution ID，待 public API 开始返回后使用；
• AmbientAgentRunExecutionSummary：包含 execution ID（若有）、状态、共享会话 ID/链接、conversation ID、启动/更新时间戳、该 execution 是否活跃；
• AmbientAgentRun（或演进后的AmbientAgentTask）：将稳定的 run 字段与活跃/最新 execution 投影分离。

4.2 Execution-aware 访问器

在首个客户端 PR 阶段，public API 仍可能返回扁平字段，但模型仍应暴露 execution-aware API，用这些扁平字段充当活跃/最新 execution 投影：

• run_id()
• active_execution_session_id()
• latest_execution_session_id()
• active_execution_conversation_id()
• has_active_execution()
• is_terminal_run_state()
• can_submit_cloud_followup()

现有调用方在语义属于 execution 作用域时，不应再直接访问session_id、session_link、conversation_id、is_sandbox_running。这样当服务端未来返回executions数组或active_execution对象时，无需再跨代码库做一次重命名。

4.3AIConversation与AgentConversationsModel的约定

• AIConversation应按服务端 conversation token/conversation ID 保持稳定的会话身份，run/execution 元数据只是辅助信息；当前单一task_id字段可继续充当稳定 run ID 以兼容旧代码，但方法与注释必须区分 “run ID” 与未来的 “execution ID”。follow-up 执行不得分配新的本地AIConversationId——follow-up 延续的是同一条本地会话、同一条服务端会话/run；
• AgentConversationsModel应按稳定 run ID 合并拉取到的 run 数据；详情面板与管理列表继续每 run 一行，聚合状态取自 run，打开/继续动作使用活跃/最新 execution 的会话信息。

5. Public API 客户端与 spawn 流程拆分

5.1 新增AIClient::submit_run_followup

在 app/src/server/server_api/ai.rs 添加RunFollowupRequest { message }与AIClient::submit_run_followup(run_id, message)，实现为对 public API 的POST agent/runs/{run_id}/followups，返回Result<(), anyhow::Error>。

5.2 拆分当前spawn_task流

文档建议把当前spawn_task流拆成三个可复用片段：

• spawn_task(request, ai_client, timeout)：继续负责创建初始 run 并监控它；
• 新的monitor 辅助函数：轮询已存在的 run，直到进入终端错误状态或出现新的可加入 execution 会话；
• 新的follow-up 辅助函数：调用submit_run_followup，然后借助 monitor 等待下一个活跃 execution 会话。

上述拆分在仓库中已有对应实现：app/src/ai/ambient_agents/spawn.rs 中提供了：

• monitor_spawned_task：为已创建的 task 保留spawn_task的事件契约（TaskSpawned、可能的AtCapacity，随后进入poll_run_until_joinable_session）；
• submit_run_followup（同文件）：先发RunFollowupRequest { message }，成功后转入poll_run_until_joinable_session(..., RunPollMode::Followup { previous_session_id }, ...)；
• poll_run_until_joinable_session：带超时（默认永不超时）的轮询循环，直到 task 完成或出现可加入会话。

5.3 follow-up monitor 的关键约束：忽略旧会话

follow-up monitor 必须知道上一个 execution 的会话 ID 并忽略它。一个就绪的 follow-up 会话需要同时满足：

1. session ID 存在且可解析；
2. 根据 run/execution 投影判定为活跃；
3. 与上一个已结束的会话 ID 不同。

这一点在 app/src/ai/ambient_agents/spawn.rs 的轮询逻辑中有体现（对返回的session_id与previous_session_id做不相等比较），其目的在于规避 7.2 节描述的“陈旧会话就绪”竞态。

6. Ambient view model 状态机

6.1 扩展AmbientAgentViewModel

app/src/terminal/view/ambient_agent/model.rs 中的AmbientAgentViewModel需要跟踪：

• 稳定 run ID/task ID；
• 本地 conversation ID；
• 活跃 execution 会话 ID；
• 最近一次已结束的 execution 会话 ID；
• 当前启动类型：初始 run 或 follow-up 执行；
• 当前正在提交、用于乐观渲染的 prompt。

文档要求用显式状态替换原先“如果已是AgentRunning，那么SessionStarted就意味着 follow-up”的隐式逻辑（原位置在 app/src/terminal/view/ambient_agent/model.rs）。推荐形态为Status::WaitingForSession { progress, kind }，其中kind为Initial或Followup。该状态机已落地于当前源码：

pub enum SessionStartupKind { InitialRun, Followup, } pub enum Status { Setup, Composing, WaitingForSession { progress: AgentProgress, kind: SessionStartupKind }, AgentRunning, Failed { progress: AgentProgress, error_message: String }, NeedsGithubAuth { progress: AgentProgress, error_message: String, auth_url: String }, Cancelled { progress: AgentProgress }, }

SessionStartupKind::Followup对应文档中的kind: Followup，可见 app/src/terminal/view/ambient_agent/model.rs 的实现与规范完全对齐。

6.2submit_cloud_followup的九步流程

文档给出公开模型方法submit_cloud_followup(prompt, ctx)的完整步骤：

1. 要求HandoffCloudCloud已启用；
2. 要求已存在 run ID；
3. 记录 follow-up prompt 用于乐观渲染；
4. 将状态置为Status::WaitingForSession { kind: Followup }；
5. 发出 setup/loading 事件，让终端显示既有 Cloud Mode setup UI；
6. 调用 follow-up API；
7. 轮询新会话；
8. 就绪时发出FollowupSessionReady { session_id }；
9. 通过与初始 Cloud Mode setup 相同的 loading/error UI 路径暴露错误。

仓库中的实际实现（app/src/terminal/view/ambient_agent/model.rs）与之对应：submit_cloud_followup先检查FeatureFlag::HandoffCloudCloud是否启用，再调用内部方法submit_run_followup_unchecked；后者校验task_id，取active_execution_session_id.or(last_ended_execution_session_id)作为 previous session，构建submit_run_followup流，设置pending_followup_prompt与Status::WaitingForSession { kind: SessionStartupKind::Followup }，启动进度计时器，发出FollowupDispatched事件，并以spawn_stream_local消费事件流。

当 follow-up 会话就绪后，继续使用TerminalManager::attach_followup_session而不是新建终端视图。执行开始时，把既有会话状态恢复为ConversationStatus::InProgress；执行结束时，根据 run 状态更新会话状态。

7. Ambient 执行结束的 UI 边界与事件接线

7.1 专用路径而非通用 teardown

当前分支的ambient_session_ended（见 app/src/terminal/shared_session/viewer/terminal_manager.rs）应触发终端视图方法on_ambient_agent_execution_ended。该方法必须：

• 每次已结束的执行插入一次 conversation-ended tombstone，或更新既有 tombstone 以代表最近结束的执行；
• 保持既有TerminalView、TerminalModel、ambient view model 与输入模型存活；
• 保持终端面板具备再次附加共享会话的资格；
• 不设置SharedSessionStatus::FinishedViewer；
• 不把编辑器置入永久只读/selectable 状态；
• 不因执行结束而取消本地 ambient 会话。

对比通用结束路径shared_session_ended（同文件）：它会把会话状态置为FinishedViewer、取消进行中的会话并走on_session_share_ended完整 teardown。而end_current_ambient_session在HandoffCloudCloud启用时，对自有（owned）ambient task只设置SharedSessionStatus::NotShared（非自有者仍为FinishedViewer），并调用record_ambient_execution_ended与on_ambient_agent_execution_ended，与文档边界一致。

如果支持多次 follow-up，tombstone 插入策略应避免“多张大卡片堆叠、把活跃输入埋掉”。首个 UI PR 最简单的可接受策略是每次终端执行后追加一个 tombstone（每次执行都是 transcript 中的真实边界）；若评审觉得噪音过大，备选方案是保留一个 tombstone 视图，在下一次 follow-up 提交前原位更新。

7.2 热切换接线：wire_ambient_agent_session_events

app/src/terminal/view/ambient_agent/mod.rs 中的wire_ambient_agent_session_events将 view model 的会话生命周期事件接到 viewerTerminalManager上：

• SessionReady { session_id }：初始 run 的会话就绪，走connect_to_session（本地到云端 handoff 面板会以追加模式 + 回放抑制加入，避免复制已渲染的 block）；
• ExecutionSessionReady { session_id }：follow-up run 在新 VM 上启动、旧执行已结束，走attach_execution_session重新附加新会话。

create_cloud_mode_view在创建 deferred viewer 后订阅这些事件，确保使用与当前视图对应的 manager。

7.3 Tombstone “Continue” 入口与终端输入

在HandoffCloudCloud下，ConversationEndedTombstoneView 对“具有 run ID 且可进行云端 follow-up 的 ambient Cloud Mode tombstone”显示主操作“Continue”，并把 “Continue locally” 保留为次要/兜底动作。仓库中已存在TombstoneCta::ContinueInCloud { task_id }分支，渲染标题为 “Continue” 的主按钮并派发ConversationEndedTombstoneAction::ContinueInCloud。

点击 “Continue” 应揭示/聚焦既有终端输入以输入 follow-up prompt——优先复用现有终端输入/编辑器，而不是在 tombstone 内嵌一个独立文本框，从而保持提交、附件、编辑器状态与键盘行为与 Cloud Mode setup 一致。

提交路径必须走AmbientAgentViewModel::submit_cloud_followup，不能走 shared-session viewer network：上一个共享会话已结束，没有活跃的 sharer 能接收SendAgentPrompt；新的 run execution 由 public follow-up API 创建，待其共享会话就绪后再附加 viewer network。等待期间，current_network应保持为空，避免输入被路由到错误传输（见 9.4 节风险）。

7.4 加载与乐观渲染

setup 期间复用 Cloud Mode setup-v2 的 loading 屏幕与进度 footer/屏幕，而不是新造一套进度 UI。CloudModeInitialUserQuery中的“初始用户查询富内容”模式可以泛化，在环境启动期间渲染乐观的 follow-up 用户 prompt。仓库中pending_followup_prompt()与should_show_followup_progress()即服务于该渲染：前者返回待渲染的乐观 prompt，后者在存在 pending prompt 且状态为WaitingForSession/Failed/NeedsGithubAuth/Cancelled时返回 true（app/src/terminal/view/ambient_agent/model.rs）。

8. 会话与 blocklist 连续性

follow-up 必须保持：

• 同一个本地AIConversationId；
• 同一条服务端 conversation ID；
• 同一个稳定 run ID。

新的 execution 创建的是新的共享会话与新 execution 记录，而不是一条新的用户可见会话。

新会话加入时，使用SharedSessionInitialLoadMode::AppendFollowupScrollback追加会话 scrollback（app/src/terminal/shared_session/viewer/event_loop.rs 定义了ReplaceFromSessionScrollback与AppendFollowupScrollback两种模式）。服务端/运行时契约必须保留先前重水合 block 的SerializedBlock.id，或发送仅含续接内容的 scrollback；否则客户端无法可靠地去重旧输出与新输出。在追加模式下，事件循环还会打开两半回放门（set_is_receiving_agent_conversation_replay(true)与 controller 的set_should_suppress_existing_agent_conversation_replay(true)），因为本地会话已包含先前 transcript，需要抑制旧代理事件的重放。

文档同时强调：现有的热切换追加路径应视为 follow-up 执行输出的唯一 blocklist 变更路径；不要在 follow-up setup 期间把 conversation transcript 数据单独加载进同一视图，否则可能重复 AI block 与 shell command block。

9. 错误处理与风险缓解

9.1 错误处理规则

• 若submit_run_followup在服务端接受 prompt 之前失败：把 tombstone/输入恢复到可编辑状态，并在 Cloud Mode setup 同一区域显示错误；除非服务端已接受，否则不要永久追加乐观 follow-up prompt。
• 若服务端接受了 follow-up，但轮询在出现新会话前到达终端失败：显示 Cloud Mode 的 error/cancelled/auth/capacity 状态；当服务端把 run 标记为可重试后，保留 tombstone/输入供重试。
• 若用户在等待 follow-up 会话期间关闭面板：只取消本地轮询；除非用户显式触发取消动作，否则不得取消 run。

9.2 风险与缓解对照

10. 端到端流程

文档给出的完整 13 步流程如下：

1. 用户启动 Cloud Mode ambient 会话；
2. 以POST /agent/run创建初始 run；客户端存储稳定 run ID 与本地 conversation ID；
3. spawn_task轮询，直到 run 暴露初始活跃 execution 共享会话；
4. AmbientAgentViewModel发出SessionReady；viewer manager 加入初始会话；
5. 执行到达终端状态，共享会话结束；
6. viewer manager 将该事件作为 ambient 执行边界处理：插入/更新 tombstone，保持面板与输入可恢复；
7. 用户点击 tombstone 的 “Continue”，通过终端输入提交 prompt；
8. ambient view model 调用POST /agent/runs/{runId}/followups；
9. 客户端在轮询GET /agent/runs/{runId}的同时显示 Cloud Mode setup-v2 loading UI；
10. 出现新的活跃 execution 会话 ID 时，AmbientAgentViewModel发出FollowupSessionReady；
11. viewer manager 调用attach_followup_session，替换 network，以追加模式加入新会话；
12. 新输出流式进入同一终端视图/模型与同一条本地会话；
13. 步骤 5–12 可重复，支持多次 follow-up 执行。

11. 增量计划（PR 栈）

PR 0：共享会话热切换基础（当前分支，可独立合并）

保持 viewer 资源跨网络复用；新增attach_followup_session；新增追加模式 scrollback 加载；阻止 ambientSessionEnded永久毒化面板。详细内容见specs/REMOTE-1478/TECH.md。

PR 1：特性开关、API 客户端与 run/execution 感知模型脚手架

添加HandoffCloudCloud、submit_run_followup、follow-up 请求/响应测试，以及AmbientAgentTask/run 模型上的 run/execution 感知访问器；把现有调用点改为使用访问器获取活跃会话/会话状态。不暴露 UI，除测试与被禁用的开关外不改变运行时行为。

合并标准：开关关闭时，既有 Cloud Mode spawn、任务列表、详情面板与共享会话 viewer 行为不变。

PR 2：无可见入口的 ambient follow-up 编排

添加AmbientAgentViewModel::submit_cloud_followup、显式的 initial-vs-follow-up 等待状态、新活跃会话轮询、乐观 follow-up prompt 状态，以及FollowupSessionReady到既有热切换 API 的接线；用 mockAIClient添加单元测试。可在开关禁用 + test-only/debug-only 调用路径下合并，暂不需要 tombstone 按钮。

合并标准：模型级 follow-up 能接收 prompt、调用 API、忽略旧会话 ID、发出新会话 ID，并正确处理 API/轮询错误。

PR 3：tombstone Continue UX 与终端输入提交

添加云端 “Continue” tombstone 动作；揭示/聚焦既有终端输入；把提交路由到 ambient follow-up 模型方法；显示 setup-v2 loading UI；渲染乐观 follow-up prompt；保留 “Continue locally”；为“云端继续”尝试、成功与失败添加遥测。

合并标准：HandoffCloudCloud关闭时 tombstone 不变；开启时，terminal-state 的 Cloud Mode 会话可发起 follow-up，并在同一面板附加新共享会话。

PR 4：打磨、详情面板与端到端验证

让会话详情/agent 管理面改用 run/execution 感知辅助函数；确保活跃/历史分节把“带活跃 follow-up 执行的 run”视为活跃；为至少两个执行边界添加集成覆盖；可根据产品评审调优 tombstone 堆叠/更新。

合并标准：重复云端 follow-up 保持单一会话/run 身份，输出按序追加，且不回归普通共享会话 viewer 与本地 “Continue locally”。

12. 测试与验证矩阵

单元测试

• AIClient::submit_run_followup：构造POST agent/runs/{runId}/followups且请求体为{ message }，处理成功/错误响应（可对照 app/src/server/server_api/ai.rs 的实现验证）；
• run/execution 访问器：从当前扁平 API 字段与未来可选的 execution 形态测试夹具中推导活跃/最新会话状态；
• ambient follow-up 模型：调用 API、转入WaitingForSession { kind: Followup }、轮询直至出现新会话 ID、忽略旧会话 ID、发出FollowupSessionReady、处理终端失败态；
• ConversationEndedTombstoneView：依据HandoffCloudCloud、task/run 是否存在、AI 设置与目标平台显示/隐藏 Continue；
• 非 ambient 的共享会话SessionEnded仍走通用 finished/read-only viewer 路径。

Viewer/会话测试

• follow-up 附加替换活跃 network 且不重复外向订阅；
• ambientSessionEnded插入/更新 tombstone 而不设置FinishedViewer；
• 重复 follow-up 会话追加 scrollback 且不重复 block ID。

集成或手动验证

• 启动 Cloud Mode 会话 → 等待执行结束 → 点击 Continue → 提交 prompt → 确认 setup UI 出现 → 确认新共享会话附加到同一面板；
• 再做一次 follow-up，捕捉订阅泄漏与陈旧 session ID 处理；
• 确认同一 tombstone 上 “Continue locally” 仍可从本地 fork；
• 确认普通共享会话 viewer 在会话结束时仍变为只读并显示结束 banner。

在打开或更新该 PR 栈中的任何 PR 之前，需要对受影响的 Rust 代码运行仓库要求的格式化与 clippy 检查，并针对 ambient model、server API client、tombstone view 与 viewer terminal manager 运行定向测试；面向用户的 UI 增量完成后，还需使用verify-ui-change-in-cloudskill 做 UI 验证。

13. 并行化与后续工作

并行化拆分

PR 1 落地后，工作可按三条轨道并行（三个 agent 或分支）：

• API/模型轨道：follow-up 客户端方法、run/execution 访问器、agent 管理与详情模型更新；
• ambient 编排轨道：view-model follow-up 状态机、轮询、热切换事件接线；
• UI 轨道：tombstone Continue 动作、终端输入揭示/提交、乐观 prompt 渲染、setup-v2 loading/error 状态。

三轨在AmbientAgentViewModel::submit_cloud_followup以及create_cloud_mode_view中既有的FollowupSessionReady -> attach_followup_session订阅处汇合。

Follow-ups（后续待办）

• 服务端形态就绪后，在 public API 响应中加入一等executions数组或active/latest execution对象，随后移除客户端访问器中的扁平字段兼容；
• 决定会话详情面板是展示按执行（per-execution）的 runtime/credit 行，还是仅展示 run 级聚合总量；
• 考虑把 execution ID 加入会话分享的 source 元数据，使客户端无需从 session ID 推断即可关联所加入会话与具体执行；
• 云端到云端 follow-up 稳定后，移除HandoffCloudCloud开关。

14. 小结

APP-4318 为 Warp Cloud Mode 引入了“一次 run、多次执行、单一面板、无缝接力”的客户端基础：HandoffCloudCloud开关及与CloudModeSetupV2的依赖不变式、run/execution 感知模型访问器、POST agent/runs/{runId}/followups客户端方法、WaitingForSession { kind: Followup }显式状态机、ambient 专用执行结束边界、tombstone “Continue” 入口，以及 append-mode scrollback 的会话/blocklist 连续性保障。这些改动以四阶段 PR 栈形式推进，每阶段都有明确合并标准与测试矩阵，最终使用户能在同一条本地会话内反复在云端延续 Agent 对话，同时保持普通共享会话 viewer 与本地 “Continue locally” 行为不受影响。

• 桌面应用
• 开发者工具
• 人工智能
• AI 应用
• AI Agent
• 代码智能体