Warp Cloud Mode 执行接力（Cloud-to-Cloud Follow-up）技术规范：基于 HandoffCloudCloud 的共享会话热切换实现-北京尧图网络

桌面应用开发者工具人工智能AI 应用AI Agent代码智能体【免费下载链接】warpWarp is an agentic development environment, born out of the terminal.项目地址https://gitcode.com/GitHub_Trending/wa/warp点击查看免费下载本文基于仓库内 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。这里引入了一条关键的架构边界也是理解本文的钥匙会话 IDsession 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 APIPOST /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.rsasync 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_runningapp/src/ai/agent/conversation.rs 中的AIConversation只存单一task_id/run_idapp/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_endedapp/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 延续的是同一条本地会话、同一条服务端会话/runAgentConversationsModel应按稳定 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_sessionsubmit_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 会话需要同时满足session ID 存在且可解析根据 run/execution 投影判定为活跃与上一个已结束的会话 ID 不同。这一点在 app/src/ai/ambient_agents/spawn.rs 的轮询逻辑中有体现对返回的session_id与previous_session_id做不相等比较其目的在于规避 7.2 节描述的“陈旧会话就绪”竞态。6. Ambient view model 状态机6.1 扩展AmbientAgentViewModelapp/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)的完整步骤要求HandoffCloudCloud已启用要求已存在 run ID记录 follow-up prompt 用于乐观渲染将状态置为Status::WaitingForSession { kind: Followup }发出 setup/loading 事件让终端显示既有 Cloud Mode setup UI调用 follow-up API轮询新会话就绪时发出FollowupSessionReady { session_id }通过与初始 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启用时对自有ownedambient task只设置SharedSessionStatus::NotShared非自有者仍为FinishedViewer并调用record_ambient_execution_ended与on_ambient_agent_execution_ended与文档边界一致。如果支持多次 follow-uptombstone 插入策略应避免“多张大卡片堆叠、把活跃输入埋掉”。首个 UI PR 最简单的可接受策略是每次终端执行后追加一个 tombstone每次执行都是 transcript 中的真实边界若评审觉得噪音过大备选方案是保留一个 tombstone 视图在下一次 follow-up 提交前原位更新。7.2 热切换接线wire_ambient_agent_session_eventsapp/src/terminal/view/ambient_agent/mod.rs 中的wire_ambient_agent_session_events将 view model 的会话生命周期事件接到 viewerTerminalManager上SessionReady { session_id }初始 run 的会话就绪走connect_to_session本地到云端 handoff 面板会以追加模式回放抑制加入避免复制已渲染的 blockExecutionSessionReady { 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时返回 trueapp/src/terminal/view/ambient_agent/model.rs。8. 会话与 blocklist 连续性follow-up 必须保持同一个本地AIConversationId同一条服务端 conversation ID同一个稳定 run ID。新的 execution 创建的是新的共享会话与新 execution 记录而不是一条新的用户可见会话。新会话加入时使用SharedSessionInitialLoadMode::AppendFollowupScrollback追加会话 scrollbackapp/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 风险与缓解对照风险缓解run/execution 命名混乱到处沿用task_id使 execution 作用域的改动易混淆即便底层 ID 类型在迁移期仍是AmbientAgentTaskId也添加访问器与注释把稳定 run 身份与 execution 作用域的会话/会话状态分开陈旧会话就绪提交 follow-up 后GET /agent/runs/{runId}可能短暂返回已结束执行的旧会话 IDfollow-up monitor 必须记录 previous session ID并要求出现不同的活跃 execution 会话后才发出FollowupSessionReadytranscript 内容重复follow-up 会话可能重放先前 scrollback客户端侧 transcript 恢复也可能渲染会话数据活动面板只用追加模式的共享会话 scrollback按 block ID 去重并要求运行时/服务端保留 block ID 或发送仅续接的 scrollback输入路由到错误传输终端输入可能误把 prompt 经旧共享会话的NetworkEvent::SendAgentPrompt发出两次执行之间提交走 ambient follow-up API 路径且在新会话附加前保持current_network为空特性开关依赖漂移HandoffCloudCloud未随 setup-v2 一起开启在测试中编码 rollout 清单依赖并明确运行时只检查HandoffCloudCloudtombstone 噪音多次执行追加多张大 tombstone先采用按执行追加若产品评审不佳则改为在原位更新最新 tombstone直到下次 follow-up 提交10. 端到端流程文档给出的完整 13 步流程如下用户启动 Cloud Mode ambient 会话以POST /agent/run创建初始 run客户端存储稳定 run ID 与本地 conversation IDspawn_task轮询直到 run 暴露初始活跃 execution 共享会话AmbientAgentViewModel发出SessionReadyviewer manager 加入初始会话执行到达终端状态共享会话结束viewer manager 将该事件作为 ambient 执行边界处理插入/更新 tombstone保持面板与输入可恢复用户点击 tombstone 的 “Continue”通过终端输入提交 promptambient view model 调用POST /agent/runs/{runId}/followups客户端在轮询GET /agent/runs/{runId}的同时显示 Cloud Mode setup-v2 loading UI出现新的活跃 execution 会话 ID 时AmbientAgentViewModel发出FollowupSessionReadyviewer manager 调用attach_followup_session替换 network以追加模式加入新会话新输出流式进入同一终端视图/模型与同一条本地会话步骤 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 3tombstone 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代码智能体【免费下载链接】warpWarp is an agentic development environment, born out of the terminal.项目地址https://gitcode.com/GitHub_Trending/wa/warp点击查看免费下载相关推荐HumanizerAI 写作去 AI 味的 agent skill一次扫完 33 种痕迹HumanizerAI 写作去 AI 味的 agent skill一次扫完 33 种痕迹 Humanizer 是一个纯 Markdown 的 agent sAI 技能AI 写作WinUI 构建版本拆解五个工位看懂整条版本链WinUI 构建版本拆解五个工位看懂整条版本链在 microsoft ui xaml 仓库做完 init 流程后第一次跑构建顺手把 CSWinRT 的版本前端UI组件桌面应用Agno 会话存储接入 Google Cloud Storage基于 GcsJsonDb 的 JSON Blob 持久化完整实战指南Agno 会话存储接入 Google Cloud Storage基于 GcsJsonDb 的 JSON Blob 持久化完整实战指南导读本指南聚焦于 ag人工智能大模型AI AgentAgent 框架多智能体工具调用RAGAgent 工作流Agent 记忆上一篇Slang IR 杂项指令参考与文档一致性校验misc.md gap-intake 缺口审查报告深度解读下一篇Ant Design Vue 2.0 升级迁移实战指南从 1.x 到 2.x 的破坏性变更与 Form 重构全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Warp Cloud Mode 执行接力（Cloud-to-Cloud Follow-up）技术规范：基于 HandoffCloudCloud 的共享会话热切换实现

相关推荐

从单模型到LLM推理平台：vLLM、Triton与K8s部署实战指南

Modern JavaScript Tutorial 精读：数组上下文中的方法调用 arr[2]() 与 this 绑定原理

Zerox 护照类证件 OCR 实战：从英国护照样本页图像到结构化 Markdown 的完整解析

更多资讯

JavaScript数组方法实战：从map到reduce的高频用法与易错点

OpenClaw实战：如何用Skills把重复工作交给AI Agent

Paddle支付接入完全指南：从KYC到支付宝收款

Pygame实战指南：从零开发一个可玩的接苹果小游戏

你跟 AI 聊得越虚，AI 干得越离谱：Trae 内置的三个模式专治这个

商业模式到底在赚什么钱：从供应链、注意力到沉没成本

今日更新

45个经典Linux面试题：从命令到网络排障的完整考点解析

SAP生产预留实战指南：MB21/MB23/MB25协同与MRP集成

编译原理实验：递归下降分析器消除左递归与避坑指南

本周精选

如何彻底离线使用 Laya-CoreML：Hugging Face 下载、缓存机制与 local_files_only 详解

基于1Panel 部署MySQL MCP 服务：TaoToken 统一 Key 接入与 config.toml 配置实战

崇州园区营销网站建设避坑指南：5大注意事项保备案安全

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？