桌面应用开发者工具人工智能AI 应用AI Agent代码智能体【免费下载链接】warpWarp is an agentic development environment, born out of the terminal.项目地址https://gitcode.com/GitHub_Trending/wa/warp点击查看免费下载导读本篇技术指南围绕 Warpagentic development environment的 Local-to-Cloud Handoff本地到云端会话移交UI 打磨方案展开聚焦 REMOTE-1519 的两大核心目标芯片点击后新打开的云模式窗格立即水合出源会话的全部 AI 交换记录以及移交窗格在云 Agent 启动阶段完整复用 fresh cloud-mode run 的 setup-v2 加载界面。读完本文你将掌握移交时序拆分fork 与 spawn 分离、request_id维度的会话回放去重机制、以及 setup-v2 指示器的渲染与拆除触发链并能在当前仓库中逐行定位对应实现。1. 背景V0 移交流程的两处粗糙边角Local-to-Cloud Handoff 的 V0REMOTE-1486已在 Warp 中提供了一条完整链路用户在本地 Agent 输入栏底部的芯片或/oz-cloud-handoff斜杠命令触发后客户端会在本地窗格旁打开一个全新的云模式窗格提交后续问题时客户端对工作区做快照并派生出一个从本地会话 fork 出来的云 Agent。V0 的完整交互链路出自 specs/REMOTE-1486/TECH.md大致如下点击 Hand off to cloud 芯片 → 本地窗格旁分裂出全新云模式窗格客户端异步遍历 action 历史得到 touched repos / orphan files用户选择环境或接受默认、输入提示词并提交客户端调用POST /agent/handoff/upload-snapshot上传工作区快照客户端调用POST /agent/runs携带fork_from_conversation_id与initial_snapshot_token服务端创建 forked conversation 与 taskAgentConversationID forked_conversation_id云 Agent 在全新沙箱中运行通过--task-id → conversation_id链路恢复会话并应用快照补丁。REMOTE-1519 要修的是这条链路里两个相互关联的粗糙边角详见 specs/REMOTE-1519/PRODUCT.md边角一新窗格在芯片点击与云 Agent 首次响应之间是空白的。V0 中 fork 只在提交时才在服务端物化。在云 Agent 的 shared session 连接并回放会话转录之前新窗格是一片空白——用户失去了上下文只能靠记忆或回看旁边的本地窗格。更糟的是云会话的回放随后会把用户在本地窗格里已经看过的每一条交换再广播一遍。边角二setup-v2 交互在移交窗格中渲染错误。fresh cloud-mode run 会显示 Running setup commands… 可折叠行、queued-prompt 指示器以及 pre-session 窗口期的加载屏由FeatureFlag::CloudModeSetupV2控制。而移交窗格没有这些表面环境启动的 PTY 输出以原始形式裸露渲染。本 spec 没有引入任何新功能它只是把这两条路径fork 物化时机、setup-v2 表面在移交场景下补齐并复用了三块既有积木Cloud→cloud 移交回放抑制attach_followup_session使用SharedSessionInitialLoadMode::AppendFollowupScrollback通过BlockList::append_followup_shared_session_scrollback按 block ID 去重并置位should_suppress_existing_agent_conversation_replay true驱动BlocklistAIController::should_skip_replayed_response_for_existing_conversation跳过重放的响应流fork 进新窗格的恢复BlocklistAIHistoryModel::fork_conversation在本地物化一个 forkedAIConversationrestore_conversation_after_view_creation把它喂进新建窗格并以 live非 restored外观恢复每条交换的 AI block服务端 fork 与会话令牌绑定ForkConversationForHandoff服务端逻辑已端到端实现授权、GCS 数据拷贝与元数据插入viewer 侧BlocklistAIController::find_existing_conversation_by_server_token按 token 把StreamInit.conversation_id映射回本地AIConversation。2. 目标与非目标Goals本 spec 必须达成的即时水合芯片点击的瞬间移交窗格就用源会话的 AI 交换记录完成水合。用户在新窗格里看到的对话历史与刚才在本地窗格看到的完全一致无需等待后续问题提交。回放不重复渲染云 Agent 的 shared-session 回放会把 forked 会话中每一条交换重新广播一遍不得把屏幕上已有的内容二次渲染。只有云 Agent 真正新增的交换会在回放之后出现。加载期 UI 与 fresh cloud-mode run 一致移交窗格在加载阶段使用与全新云模式运行完全相同的 setup-v2 交互——queued-prompt 指示器、Setting up environment 加载屏、Running setup commands… 包裹启动 PTY 输出的可折叠块。Non-goals明确不做避免范围膨胀不做移交后的双向同步forked 会话在芯片点击时刻即分叉此后本地窗格的修改不会传播到云端反之亦然。与 REMOTE-1486 V0 的立场一致。不恢复 shell 命令块只有会话的 AI 交换被水合本地终端上存在的终端输出例如 Agent 轮次之间运行的不相关命令留在本地窗格。不做 Cloud→cloud 的 setup-v2 修复Cloud→cloud 后续路径REMOTE-1290可能有类似缺口但超出本 spec 范围。不在源窗格加已移交到 链接面包屑。3. 行为设计芯片点击时的 Fork 时机与水合3.1 严格有序的打开路径Workspace::start_local_to_cloud_handoff实现在 app/src/workspace/view.rs注释标明由/handoff、compose 模式与 handoff footer 芯片触发变成一条严格有序的打开路径顺序不可颠倒第 1 步同步判定资格。从活跃会话视图的BlocklistAIHistoryModel::active_conversation解析资格若会话缺失、为空、或没有server_conversation_token则在本地方窗格弹出共享错误 toast不打开任何窗格。第 2 步异步调用 fork RPC。ctx.spawn一个 future 调用AIClient::prepare_handoff_fork。新窗格在这一步返回之前不会分裂。一旦出错弹出同样的错误 toast同样不打开窗格——本地会话不受影响用户可以重试。第 3 步成功后回到主线程完成水合。依序执行以下操作BlocklistAIHistoryModel::fork_conversation(source_conversation, FORK_PREFIX, /* preserve_task_ids */ true, ctx)物化本地 forkL。preserve_task_ids: true保留源会话的 task id从而保证云 Agent 的ClientAction引用这些 task id能在L中解析成功pane_group.add_ambient_agent_pane(ctx)分裂出新窗格若斜杠命令提供了参数预填提示输入框terminal_view.restore_conversation_after_view_creation(RestoredAIConversation::new(L.clone()), /* use_live_appearance */ true, ctx)让 AI 交换立即以 live 外观渲染BlocklistAIHistoryModel::set_server_conversation_token_for_conversation(local_fork_id, T_C)——必须在 restore 之后执行restore_conversations会用传入的 token-less 克隆覆盖conversations_by_id提前绑定会丢失播种PendingHandoff { forked_conversation_id: T_C, touched_workspace: None, snapshot_prep: Pending, submission_state: Idle }。注意与 V0 的关键差异V0 是在提交时才调用服务端 fork而 REMOTE-1519 把 fork 提前到芯片点击时——云端视图被冻结在用户选择移交的那一刻两条会话可以独立演进。3.2 提交路径改为 resume 语义由于 fork 与快照上传都在芯片点击的打开路径中完成AmbientAgentViewModel::submit_handoff退化成spawn_agent_with_request的薄封装直接从pending_handoff读取缓存的forked_conversation_id和snapshot_prep。REMOTE-1486 时代用于编排 submit 的 orchestrator 被删除。发送按钮的门控is_handoff_ready_to_submit要求同时满足touched_workspace.is_some()派生完成snapshot_prep已定态Uploaded或SkippedEmptyWorkspacesubmission_state Idle。若提交发生在任一前置条件未满足时输入层弹出 Preparing handoff toast并保留用户的 prompt 与附件不丢失输入。3.3 资格判定与失败回退资格判定PRODUCT.md 第 5 条按会话判定要求活跃会话非空且具备已同步的服务端 token。不满足时芯片在本地窗口弹出错误 toast 且不打开任何窗格本地会话不受影响等源同步完成后可重试。fork 调用失败第 6 条无论何种原因网络、认证、源未同步到 GCS新窗格都不会被打开失败以相同的错误 toast 呈现在本地窗口用户可再次点击芯片重试。3.4 边缘情况提交前关闭窗格芯片点击与提交之间关闭移交窗格服务端 fork 会成为孤儿出现在用户会话历史中但永不运行。V0 不清理这些孤儿。同一源会话连点两次芯片生成两个相互独立的 fork与现有 REMOTE-1486 芯片行为一致本 spec 无改变。本地窗格全程不受影响其会话不会被复制、归档或标注用户可继续在本地窗格输入。4. 云会话回放与去重这是本 spec 技术含量最高的部分。云 Agent 的 shared session 连接到移交窗格时Agent 的会话回放会把 forked 会话中的每一条交换重新广播一遍。由于我们已经预填了同样的交换这些回放事件需要在响应流层面被抑制——这与 cloud→cloud 后续会话处理陈旧回放的方式REMOTE-1290完全一致。4.1 初始连接使用 append 模式TerminalManager::connect_to_session新增append_followup_scrollback: bool标志app/src/terminal/shared_session/viewer/terminal_manager.rs。云模式订阅app/src/terminal/view/ambient_agent/mod.rs传入view_model.is_local_to_cloud_handoff()使移交窗格使用AppendFollowupScrollback而非默认的ReplaceFromSessionScrollback。append 模式同时完成两件事BlockList::append_followup_shared_session_scrollback跳过我们已经拥有的 block IDshould_suppress_existing_agent_conversation_replay true驱动响应流过滤器见下节。4.2 以request_id为键的响应流过滤器should_skip_replayed_response_for_existing_conversation定义于 app/src/ai/blocklist/controller/shared_session.rs从on_shared_init调用将init_event.request_id与本地 fork 现有交换的server_output_id集合比对。响应流被跳过的充要条件为模型处于回放模式is_receiving_agent_conversation_replay should_suppress_existing_agent_conversation_replay传入的request_id与某条既有交换的server_output_id匹配。由此已知交换的回放事件被丢弃去重云 Agent 在本地 fork 之后新增的轮次例如用户首次提交的提示词携带的是我们从未见过的request_id会正常流通。去重的关键洞察在于新轮次与回放轮次走在同一条连接上因此不能简单地回放期间全丢必须以request_id精确限定跳过范围。回放结束后真正的新交换云 Agent 对用户后续问题的首次响应正常追加——用户看到的是从冻结的移交前状态平滑过渡到云 Agent 正在回答我的后续问题。5. Setup-v2 加载界面移交窗格与 fresh run 对齐5.1 提交后渲染PRODUCT.md 第 9 条用户提交后移交窗格呈现与 fresh cloud-mode run 相同的三件套Queued user-query 指示器提交的 prompt 以排队用户查询块呈现REMOTE-1454 的视觉处理无 Send-now / dismiss 按钮Setting up environment 加载屏pre-session 阶段显示Running setup commands… 可折叠行shared session 一旦连接用它包裹环境启动的 PTY 输出。在源码侧DispatchedAgentapp/src/terminal/view/ambient_agent/view_impl.rs在is_local_to_cloud_handoff()为真时通过 REMOTE-1454 的 helperinsert_cloud_mode_queued_user_query_block渲染用户 prompt。5.2 拆除时机PRODUCT.md 第 10 条云 Agent 首次轮次到达时queued-prompt 指示器与 setup-v2 交互在与 fresh cloud-mode run 相同的过渡上拆除Oz 路径AppendedExchange清除 setup-v2 标志与 queued-prompt 块对 Oz 而言等价于harness CLI 已启动的过渡非 Oz 路径HarnessCommandStarted触发拆除。各路径都会调用幂等的remove_pending_user_query_block(ctx)。其他同样触发移除的过渡还包括Failed、Cancelled、NeedsGithubAuth。5.3 成功标准中的字节级一致本 spec 的成功标准第三条写得很硬移交窗格加载阶段的 UI 与 fresh cloud-mode run 逐字节一致仅有的差异是 queued-prompt 指示器上方多出的预填交换。这意味着 setup-v2 表面加载屏文案、可折叠行的展开/收起行为、PTY 输出包裹方式不允许因移交上下文而走任何自定义分支。6. 服务端与客户端改造清单6.1 服务端把 fork 从 spawn 中拆出来新增端点POST /api/v1/agent/handoff/prepare-fork请求/响应形状出自 specs/REMOTE-1519/TECH.mdtype PrepareLocalHandoffForkRequest struct { SourceConversationID string json:source_conversation_id binding:required } type PrepareLocalHandoffForkResponse struct { ForkedConversationID string json:forked_conversation_id }Handler 与PrepareLocalHandoffSnapshotHandler同置于router/handlers/public_api/agent_handoff.go以features.LocalToCloudHandoffEnabled()门控、解析 principal、调用logic.ForkConversationForHandoff并挂在与既有 snapshot prep 端点相同的aiCheckedGroup路由组下。同时从RunAgentRequest移除ForkFromConversationID字段、校验、内联 fork 调用全部删除保留的ConversationID *string继续驱动task.AgentConversationIDresume 语义——客户端现在把它指向预先铸好的 fork id。HandoffSnapshotToken保留快照准备与上传仍走prepare-snapshot和 post-task-creation 的attachHandoffSnapshotToTask只是触发时机从提交时移到芯片点击后的异步阶段。6.2 客户端 API 表面在app/src/server/server_api/ai.rs的AIClienttrait 中新增prepare_handoff_fork实现为POST agent/handoff/prepare-fork镜像PrepareHandoffSnapshotRequest的请求/响应形状模式SpawnAgentRequest上以conversation_id: OptionStringresume 语义替换fork_from_conversation_id: OptionString。6.3 本地 fork 与 token 绑定源码实证fork_conversation定义于 app/src/ai/blocklist/history_model.rsset_server_conversation_token_for_conversation定义于同文件 history_model.rs测试需验证其更新 token→conversation 反查索引使find_conversation_id_by_server_token(T_C)能定位到 forkrestore_conversation_after_view_creation位于 app/src/terminal/view/load_ai_conversation.rs。6.4 特性开关姿态不新增任何 feature flag。客户端沿用 REMOTE-1486 的FeatureFlag::OzHandoff FeatureFlag::LocalToCloudHandoff服务端沿用features.LocalToCloudHandoffEnabled()。7. 风险与缓解芯片点击延迟现在受 prepare-fork RPC 制约此前窗格立即打开现在要等 fork 解析。fork 是提交时已在用的同步元数据 GCS 拷贝往返预期延迟与其它经认证的公共 API RPC 相近300ms p50出错时立即弹 toast。源会话未同步到 GCSForkConversationForHandoff在BatchDoesConversationDataExist为 false 时返回InvalidRequestError客户端以 toast 呈现用户稍候片刻再点即可。回放抑制误杀真正的新交换request_id过滤器把跳过范围限定到特定已知交换新轮次即使在回放窗口期内也正常流通。提交时快照上传仍在进行is_handoff_ready_to_submit阻塞提交直到上传定态用户看到 Preparing handoff toast 且 prompt 与附件被完整保留。8. 测试与验证矩阵单元测试app/src/server/server_api/ai_test.rsPrepareHandoffForkRequest/PrepareHandoffForkResponse的序列化/反序列化测试app/src/ai/blocklist/history_model_test.rs验证fork_conversation之后调用set_server_conversation_token_for_conversation会更新 token 反查索引另有覆盖preserve_task_ids: true的测试确认 task id 跨 fork 保留app/src/terminal/shared_session/viewer/event_loop_test.rs扩展现有 append-mode 测试覆盖本地→云连接路径。服务端测试router/handlers/public_api/agent_handoff_test.go新增TestPrepareLocalHandoffForkHandler_*套件覆盖flag 关闭、缺失source_conversation_id、happy path、源认证失败更新agent_webhooks_test.go::TestHandoff_*中原本走ForkFromConversationID的用例改为先驱动新prepare-fork端点、再在 run 请求里带ConversationID。集成 / 手动验证成功标准对应的实操清单在长 Oz 会话上点击芯片云会话连接前新窗格已可见地填充 AI 交换connect/replay 窗口期无闪烁、无重复块提交后续问题queued-prompt 指示器 Setting up environment 加载屏 Running setup commands… 可折叠块与 fresh cloud-mode run 完全一致云 Agent 首次轮次到达后预填块原位保留、queued-prompt 指示器清除、新交换追加在其下方在无同步 token 的不合格会话上点击芯片不打开任何窗格本地窗口弹出错误 toast芯片点击时手动断网令 prepare-fork RPC 失败不打开任何窗格本地窗口弹出错误 toast。9. 并行化与后续工作并行化改动足够小单人/单 Agent 可按两个 PR 顺序实施——服务端 PRprepare-fork 端点 移除ForkFromConversationID随后客户端 PR水合 load mode 回放流过滤器无需子 Agent。后续工作Cloud→cloud 的 setup-v2 打磨REMOTE-1290明确超出本 spec 范围。结语REMOTE-1519 本质上是一次不新增功能、只修两条渲染路径的体验打磨把服务端 fork 从提交时刻提前到芯片点击时刻用AppendFollowupScrollbackrequest_id过滤器消灭回放二次渲染并让移交窗格的加载界面与 fresh cloud-mode run 逐字节对齐。它验证了 Warp 中一条可复用的架构原则——把会话物化与会话执行解耦并用共享会话的 load mode 与流过滤器统一所有预填 回放场景的去重语义。对照阅读 PRODUCT.md、TECH.md 与 REMOTE-1486/TECH.md 三份文档再结合history_model.rs、shared_session.rs、workspace/view.rs中的实现即可完整还原这条链路的全貌。赞分享桌面应用开发者工具人工智能AI 应用AI Agent代码智能体【免费下载链接】warpWarp is an agentic development environment, born out of the terminal.项目地址https://gitcode.com/GitHub_Trending/wa/warp点击查看免费下载相关推荐Warp 本地 Agent 到云端 Agent 的无缝交接Local-to-Cloud Handoff/handoff 与 Hand off to cloud 完整实现剖析Warp 本地 Agent 到云端 Agent 的无缝交接Local to Cloud Handoff /handoff 与 Hand off to cl桌面应用开发者工具人工智能AI 应用AI Agent代码智能体Warp 本地到云端交接Local-to-Cloud Handoff 前缀入口的设计、交互与实现Warp 本地到云端交接Local to Cloud Handoff 前缀入口的设计、交互与实现 导读 本文基于仓库中 specs/REMOTE 15桌面应用开发者工具人工智能AI 应用AI Agent代码智能体Warp Cloud 到 Cloud 续接Handoff完成态 Cloud 对话在 Cloud Mode 中的可续接 Transcript 实现Warp Cloud 到 Cloud 续接Handoff完成态 Cloud 对话在 Cloud Mode 中的可续接 Transcript 实现 导读 本桌面应用开发者工具人工智能AI 应用AI Agent代码智能体上一篇Kivy 自定义插件Custom Plugins实战用 EventDispatcher 编写可复用的事件与行为模块下一篇CAT 客户端 Spring Boot 集成指南用 CatFilter 编程式注册实现 URL 全链路监控创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
桌面应用开发者工具人工智能AI 应用AI Agent代码智能体【免费下载链接】warpWarp is an agentic development environment, born out of the terminal.项目地址https://gitcode.com/GitHub_Trending/wa/warp点击查看免费下载导读本篇技术指南围绕 Warpagentic development environment的 Local-to-Cloud Handoff本地到云端会话移交UI 打磨方案展开聚焦 REMOTE-1519 的两大核心目标芯片点击后新打开的云模式窗格立即水合出源会话的全部 AI 交换记录以及移交窗格在云 Agent 启动阶段完整复用 fresh cloud-mode run 的 setup-v2 加载界面。读完本文你将掌握移交时序拆分fork 与 spawn 分离、request_id维度的会话回放去重机制、以及 setup-v2 指示器的渲染与拆除触发链并能在当前仓库中逐行定位对应实现。1. 背景V0 移交流程的两处粗糙边角Local-to-Cloud Handoff 的 V0REMOTE-1486已在 Warp 中提供了一条完整链路用户在本地 Agent 输入栏底部的芯片或/oz-cloud-handoff斜杠命令触发后客户端会在本地窗格旁打开一个全新的云模式窗格提交后续问题时客户端对工作区做快照并派生出一个从本地会话 fork 出来的云 Agent。V0 的完整交互链路出自 specs/REMOTE-1486/TECH.md大致如下点击 Hand off to cloud 芯片 → 本地窗格旁分裂出全新云模式窗格客户端异步遍历 action 历史得到 touched repos / orphan files用户选择环境或接受默认、输入提示词并提交客户端调用POST /agent/handoff/upload-snapshot上传工作区快照客户端调用POST /agent/runs携带fork_from_conversation_id与initial_snapshot_token服务端创建 forked conversation 与 taskAgentConversationID forked_conversation_id云 Agent 在全新沙箱中运行通过--task-id → conversation_id链路恢复会话并应用快照补丁。REMOTE-1519 要修的是这条链路里两个相互关联的粗糙边角详见 specs/REMOTE-1519/PRODUCT.md边角一新窗格在芯片点击与云 Agent 首次响应之间是空白的。V0 中 fork 只在提交时才在服务端物化。在云 Agent 的 shared session 连接并回放会话转录之前新窗格是一片空白——用户失去了上下文只能靠记忆或回看旁边的本地窗格。更糟的是云会话的回放随后会把用户在本地窗格里已经看过的每一条交换再广播一遍。边角二setup-v2 交互在移交窗格中渲染错误。fresh cloud-mode run 会显示 Running setup commands… 可折叠行、queued-prompt 指示器以及 pre-session 窗口期的加载屏由FeatureFlag::CloudModeSetupV2控制。而移交窗格没有这些表面环境启动的 PTY 输出以原始形式裸露渲染。本 spec 没有引入任何新功能它只是把这两条路径fork 物化时机、setup-v2 表面在移交场景下补齐并复用了三块既有积木Cloud→cloud 移交回放抑制attach_followup_session使用SharedSessionInitialLoadMode::AppendFollowupScrollback通过BlockList::append_followup_shared_session_scrollback按 block ID 去重并置位should_suppress_existing_agent_conversation_replay true驱动BlocklistAIController::should_skip_replayed_response_for_existing_conversation跳过重放的响应流fork 进新窗格的恢复BlocklistAIHistoryModel::fork_conversation在本地物化一个 forkedAIConversationrestore_conversation_after_view_creation把它喂进新建窗格并以 live非 restored外观恢复每条交换的 AI block服务端 fork 与会话令牌绑定ForkConversationForHandoff服务端逻辑已端到端实现授权、GCS 数据拷贝与元数据插入viewer 侧BlocklistAIController::find_existing_conversation_by_server_token按 token 把StreamInit.conversation_id映射回本地AIConversation。2. 目标与非目标Goals本 spec 必须达成的即时水合芯片点击的瞬间移交窗格就用源会话的 AI 交换记录完成水合。用户在新窗格里看到的对话历史与刚才在本地窗格看到的完全一致无需等待后续问题提交。回放不重复渲染云 Agent 的 shared-session 回放会把 forked 会话中每一条交换重新广播一遍不得把屏幕上已有的内容二次渲染。只有云 Agent 真正新增的交换会在回放之后出现。加载期 UI 与 fresh cloud-mode run 一致移交窗格在加载阶段使用与全新云模式运行完全相同的 setup-v2 交互——queued-prompt 指示器、Setting up environment 加载屏、Running setup commands… 包裹启动 PTY 输出的可折叠块。Non-goals明确不做避免范围膨胀不做移交后的双向同步forked 会话在芯片点击时刻即分叉此后本地窗格的修改不会传播到云端反之亦然。与 REMOTE-1486 V0 的立场一致。不恢复 shell 命令块只有会话的 AI 交换被水合本地终端上存在的终端输出例如 Agent 轮次之间运行的不相关命令留在本地窗格。不做 Cloud→cloud 的 setup-v2 修复Cloud→cloud 后续路径REMOTE-1290可能有类似缺口但超出本 spec 范围。不在源窗格加已移交到 链接面包屑。3. 行为设计芯片点击时的 Fork 时机与水合3.1 严格有序的打开路径Workspace::start_local_to_cloud_handoff实现在 app/src/workspace/view.rs注释标明由/handoff、compose 模式与 handoff footer 芯片触发变成一条严格有序的打开路径顺序不可颠倒第 1 步同步判定资格。从活跃会话视图的BlocklistAIHistoryModel::active_conversation解析资格若会话缺失、为空、或没有server_conversation_token则在本地方窗格弹出共享错误 toast不打开任何窗格。第 2 步异步调用 fork RPC。ctx.spawn一个 future 调用AIClient::prepare_handoff_fork。新窗格在这一步返回之前不会分裂。一旦出错弹出同样的错误 toast同样不打开窗格——本地会话不受影响用户可以重试。第 3 步成功后回到主线程完成水合。依序执行以下操作BlocklistAIHistoryModel::fork_conversation(source_conversation, FORK_PREFIX, /* preserve_task_ids */ true, ctx)物化本地 forkL。preserve_task_ids: true保留源会话的 task id从而保证云 Agent 的ClientAction引用这些 task id能在L中解析成功pane_group.add_ambient_agent_pane(ctx)分裂出新窗格若斜杠命令提供了参数预填提示输入框terminal_view.restore_conversation_after_view_creation(RestoredAIConversation::new(L.clone()), /* use_live_appearance */ true, ctx)让 AI 交换立即以 live 外观渲染BlocklistAIHistoryModel::set_server_conversation_token_for_conversation(local_fork_id, T_C)——必须在 restore 之后执行restore_conversations会用传入的 token-less 克隆覆盖conversations_by_id提前绑定会丢失播种PendingHandoff { forked_conversation_id: T_C, touched_workspace: None, snapshot_prep: Pending, submission_state: Idle }。注意与 V0 的关键差异V0 是在提交时才调用服务端 fork而 REMOTE-1519 把 fork 提前到芯片点击时——云端视图被冻结在用户选择移交的那一刻两条会话可以独立演进。3.2 提交路径改为 resume 语义由于 fork 与快照上传都在芯片点击的打开路径中完成AmbientAgentViewModel::submit_handoff退化成spawn_agent_with_request的薄封装直接从pending_handoff读取缓存的forked_conversation_id和snapshot_prep。REMOTE-1486 时代用于编排 submit 的 orchestrator 被删除。发送按钮的门控is_handoff_ready_to_submit要求同时满足touched_workspace.is_some()派生完成snapshot_prep已定态Uploaded或SkippedEmptyWorkspacesubmission_state Idle。若提交发生在任一前置条件未满足时输入层弹出 Preparing handoff toast并保留用户的 prompt 与附件不丢失输入。3.3 资格判定与失败回退资格判定PRODUCT.md 第 5 条按会话判定要求活跃会话非空且具备已同步的服务端 token。不满足时芯片在本地窗口弹出错误 toast 且不打开任何窗格本地会话不受影响等源同步完成后可重试。fork 调用失败第 6 条无论何种原因网络、认证、源未同步到 GCS新窗格都不会被打开失败以相同的错误 toast 呈现在本地窗口用户可再次点击芯片重试。3.4 边缘情况提交前关闭窗格芯片点击与提交之间关闭移交窗格服务端 fork 会成为孤儿出现在用户会话历史中但永不运行。V0 不清理这些孤儿。同一源会话连点两次芯片生成两个相互独立的 fork与现有 REMOTE-1486 芯片行为一致本 spec 无改变。本地窗格全程不受影响其会话不会被复制、归档或标注用户可继续在本地窗格输入。4. 云会话回放与去重这是本 spec 技术含量最高的部分。云 Agent 的 shared session 连接到移交窗格时Agent 的会话回放会把 forked 会话中的每一条交换重新广播一遍。由于我们已经预填了同样的交换这些回放事件需要在响应流层面被抑制——这与 cloud→cloud 后续会话处理陈旧回放的方式REMOTE-1290完全一致。4.1 初始连接使用 append 模式TerminalManager::connect_to_session新增append_followup_scrollback: bool标志app/src/terminal/shared_session/viewer/terminal_manager.rs。云模式订阅app/src/terminal/view/ambient_agent/mod.rs传入view_model.is_local_to_cloud_handoff()使移交窗格使用AppendFollowupScrollback而非默认的ReplaceFromSessionScrollback。append 模式同时完成两件事BlockList::append_followup_shared_session_scrollback跳过我们已经拥有的 block IDshould_suppress_existing_agent_conversation_replay true驱动响应流过滤器见下节。4.2 以request_id为键的响应流过滤器should_skip_replayed_response_for_existing_conversation定义于 app/src/ai/blocklist/controller/shared_session.rs从on_shared_init调用将init_event.request_id与本地 fork 现有交换的server_output_id集合比对。响应流被跳过的充要条件为模型处于回放模式is_receiving_agent_conversation_replay should_suppress_existing_agent_conversation_replay传入的request_id与某条既有交换的server_output_id匹配。由此已知交换的回放事件被丢弃去重云 Agent 在本地 fork 之后新增的轮次例如用户首次提交的提示词携带的是我们从未见过的request_id会正常流通。去重的关键洞察在于新轮次与回放轮次走在同一条连接上因此不能简单地回放期间全丢必须以request_id精确限定跳过范围。回放结束后真正的新交换云 Agent 对用户后续问题的首次响应正常追加——用户看到的是从冻结的移交前状态平滑过渡到云 Agent 正在回答我的后续问题。5. Setup-v2 加载界面移交窗格与 fresh run 对齐5.1 提交后渲染PRODUCT.md 第 9 条用户提交后移交窗格呈现与 fresh cloud-mode run 相同的三件套Queued user-query 指示器提交的 prompt 以排队用户查询块呈现REMOTE-1454 的视觉处理无 Send-now / dismiss 按钮Setting up environment 加载屏pre-session 阶段显示Running setup commands… 可折叠行shared session 一旦连接用它包裹环境启动的 PTY 输出。在源码侧DispatchedAgentapp/src/terminal/view/ambient_agent/view_impl.rs在is_local_to_cloud_handoff()为真时通过 REMOTE-1454 的 helperinsert_cloud_mode_queued_user_query_block渲染用户 prompt。5.2 拆除时机PRODUCT.md 第 10 条云 Agent 首次轮次到达时queued-prompt 指示器与 setup-v2 交互在与 fresh cloud-mode run 相同的过渡上拆除Oz 路径AppendedExchange清除 setup-v2 标志与 queued-prompt 块对 Oz 而言等价于harness CLI 已启动的过渡非 Oz 路径HarnessCommandStarted触发拆除。各路径都会调用幂等的remove_pending_user_query_block(ctx)。其他同样触发移除的过渡还包括Failed、Cancelled、NeedsGithubAuth。5.3 成功标准中的字节级一致本 spec 的成功标准第三条写得很硬移交窗格加载阶段的 UI 与 fresh cloud-mode run 逐字节一致仅有的差异是 queued-prompt 指示器上方多出的预填交换。这意味着 setup-v2 表面加载屏文案、可折叠行的展开/收起行为、PTY 输出包裹方式不允许因移交上下文而走任何自定义分支。6. 服务端与客户端改造清单6.1 服务端把 fork 从 spawn 中拆出来新增端点POST /api/v1/agent/handoff/prepare-fork请求/响应形状出自 specs/REMOTE-1519/TECH.mdtype PrepareLocalHandoffForkRequest struct { SourceConversationID string json:source_conversation_id binding:required } type PrepareLocalHandoffForkResponse struct { ForkedConversationID string json:forked_conversation_id }Handler 与PrepareLocalHandoffSnapshotHandler同置于router/handlers/public_api/agent_handoff.go以features.LocalToCloudHandoffEnabled()门控、解析 principal、调用logic.ForkConversationForHandoff并挂在与既有 snapshot prep 端点相同的aiCheckedGroup路由组下。同时从RunAgentRequest移除ForkFromConversationID字段、校验、内联 fork 调用全部删除保留的ConversationID *string继续驱动task.AgentConversationIDresume 语义——客户端现在把它指向预先铸好的 fork id。HandoffSnapshotToken保留快照准备与上传仍走prepare-snapshot和 post-task-creation 的attachHandoffSnapshotToTask只是触发时机从提交时移到芯片点击后的异步阶段。6.2 客户端 API 表面在app/src/server/server_api/ai.rs的AIClienttrait 中新增prepare_handoff_fork实现为POST agent/handoff/prepare-fork镜像PrepareHandoffSnapshotRequest的请求/响应形状模式SpawnAgentRequest上以conversation_id: OptionStringresume 语义替换fork_from_conversation_id: OptionString。6.3 本地 fork 与 token 绑定源码实证fork_conversation定义于 app/src/ai/blocklist/history_model.rsset_server_conversation_token_for_conversation定义于同文件 history_model.rs测试需验证其更新 token→conversation 反查索引使find_conversation_id_by_server_token(T_C)能定位到 forkrestore_conversation_after_view_creation位于 app/src/terminal/view/load_ai_conversation.rs。6.4 特性开关姿态不新增任何 feature flag。客户端沿用 REMOTE-1486 的FeatureFlag::OzHandoff FeatureFlag::LocalToCloudHandoff服务端沿用features.LocalToCloudHandoffEnabled()。7. 风险与缓解芯片点击延迟现在受 prepare-fork RPC 制约此前窗格立即打开现在要等 fork 解析。fork 是提交时已在用的同步元数据 GCS 拷贝往返预期延迟与其它经认证的公共 API RPC 相近300ms p50出错时立即弹 toast。源会话未同步到 GCSForkConversationForHandoff在BatchDoesConversationDataExist为 false 时返回InvalidRequestError客户端以 toast 呈现用户稍候片刻再点即可。回放抑制误杀真正的新交换request_id过滤器把跳过范围限定到特定已知交换新轮次即使在回放窗口期内也正常流通。提交时快照上传仍在进行is_handoff_ready_to_submit阻塞提交直到上传定态用户看到 Preparing handoff toast 且 prompt 与附件被完整保留。8. 测试与验证矩阵单元测试app/src/server/server_api/ai_test.rsPrepareHandoffForkRequest/PrepareHandoffForkResponse的序列化/反序列化测试app/src/ai/blocklist/history_model_test.rs验证fork_conversation之后调用set_server_conversation_token_for_conversation会更新 token 反查索引另有覆盖preserve_task_ids: true的测试确认 task id 跨 fork 保留app/src/terminal/shared_session/viewer/event_loop_test.rs扩展现有 append-mode 测试覆盖本地→云连接路径。服务端测试router/handlers/public_api/agent_handoff_test.go新增TestPrepareLocalHandoffForkHandler_*套件覆盖flag 关闭、缺失source_conversation_id、happy path、源认证失败更新agent_webhooks_test.go::TestHandoff_*中原本走ForkFromConversationID的用例改为先驱动新prepare-fork端点、再在 run 请求里带ConversationID。集成 / 手动验证成功标准对应的实操清单在长 Oz 会话上点击芯片云会话连接前新窗格已可见地填充 AI 交换connect/replay 窗口期无闪烁、无重复块提交后续问题queued-prompt 指示器 Setting up environment 加载屏 Running setup commands… 可折叠块与 fresh cloud-mode run 完全一致云 Agent 首次轮次到达后预填块原位保留、queued-prompt 指示器清除、新交换追加在其下方在无同步 token 的不合格会话上点击芯片不打开任何窗格本地窗口弹出错误 toast芯片点击时手动断网令 prepare-fork RPC 失败不打开任何窗格本地窗口弹出错误 toast。9. 并行化与后续工作并行化改动足够小单人/单 Agent 可按两个 PR 顺序实施——服务端 PRprepare-fork 端点 移除ForkFromConversationID随后客户端 PR水合 load mode 回放流过滤器无需子 Agent。后续工作Cloud→cloud 的 setup-v2 打磨REMOTE-1290明确超出本 spec 范围。结语REMOTE-1519 本质上是一次不新增功能、只修两条渲染路径的体验打磨把服务端 fork 从提交时刻提前到芯片点击时刻用AppendFollowupScrollbackrequest_id过滤器消灭回放二次渲染并让移交窗格的加载界面与 fresh cloud-mode run 逐字节对齐。它验证了 Warp 中一条可复用的架构原则——把会话物化与会话执行解耦并用共享会话的 load mode 与流过滤器统一所有预填 回放场景的去重语义。对照阅读 PRODUCT.md、TECH.md 与 REMOTE-1486/TECH.md 三份文档再结合history_model.rs、shared_session.rs、workspace/view.rs中的实现即可完整还原这条链路的全貌。赞分享桌面应用开发者工具人工智能AI 应用AI Agent代码智能体【免费下载链接】warpWarp is an agentic development environment, born out of the terminal.项目地址https://gitcode.com/GitHub_Trending/wa/warp点击查看免费下载相关推荐Warp 本地 Agent 到云端 Agent 的无缝交接Local-to-Cloud Handoff/handoff 与 Hand off to cloud 完整实现剖析Warp 本地 Agent 到云端 Agent 的无缝交接Local to Cloud Handoff /handoff 与 Hand off to cl桌面应用开发者工具人工智能AI 应用AI Agent代码智能体Warp 本地到云端交接Local-to-Cloud Handoff 前缀入口的设计、交互与实现Warp 本地到云端交接Local to Cloud Handoff 前缀入口的设计、交互与实现 导读 本文基于仓库中 specs/REMOTE 15桌面应用开发者工具人工智能AI 应用AI Agent代码智能体Warp Cloud 到 Cloud 续接Handoff完成态 Cloud 对话在 Cloud Mode 中的可续接 Transcript 实现Warp Cloud 到 Cloud 续接Handoff完成态 Cloud 对话在 Cloud Mode 中的可续接 Transcript 实现 导读 本桌面应用开发者工具人工智能AI 应用AI Agent代码智能体上一篇Kivy 自定义插件Custom Plugins实战用 EventDispatcher 编写可复用的事件与行为模块下一篇CAT 客户端 Spring Boot 集成指南用 CatFilter 编程式注册实现 URL 全链路监控创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
