尧图网站建设 
Qwen Code Daemon 多工作区会话 Rewind 与 ShellOwner 感知路由的会话文件操作设计解析【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读Qwen Code 的守护进程daemon在多工作区multi-workspace模式下为每个工作区运行时持有独立的桥接bridge但对外仍暴露单一化的会话 REST API。当 live 会话分布在多个工作区时rewind 快照、rewind 与 shell 这三类会话文件操作必须按请求解析出真正的会话属主owner再路由到对应运行时否则合法的二级工作区会话会被客户端误判为不支持的路径。本文基于 daemon-multi-workspace-session-file-ops.md 设计文档结合仓库路由实现与测试用例完整讲解这套 Owner 感知路由的决策、授权模型、行为边界、能力宣告与 SDK 侧约束读完可掌握多工作区 daemon 下会话回退与 shell 的正确使用方式及底层原理。问题背景单数 API 与多运行时之间的错位多工作区 daemon 为每个工作区运行时workspace runtime维护一个 live bridge。绝大多数 live 会话路由已经能够解析会话属主但此前以下三类操作仍被绑定在 primary bridge 上或直接拒绝 secondary ownerGET /session/:id/rewind/snapshots获取 rewind 快照列表POST /session/:id/rewind执行会话回退POST /session/:id/shell在会话工作区执行 shell 命令这造成了一个可观察的缺陷合法的 live secondary 会话与不支持的路径在客户端看来无法区分——客户端收到错误后不知道是该会话本就不支持还是只是自己拿错了 runtime。该设计文档属于最终实现设计Final implementation design它取代了 Phase 2a 中关于 live-session rewind 快照、rewind 与 shell 仅限 primary 的旧声明见 daemon-multi-workspace-phase2a-sessions.md。核心决策保持单数 API按请求解析 Owner设计上不引入任何 workspace-qualified 的会话 REST API也不新增 ACP rewind vendor 方法核心变更收敛为路径路由方式说明GET /session/:id/rewind/snapshotsOwner-aware 只读路由读取型操作只解析属主POST /session/:id/rewindOwner-aware 可变路由 共享会话归档协调器写操作走严格变更门POST /session/:id/shellOwner-aware 可变路由 共享会话归档协调器写操作走严格变更门同时明确不引入的改动不新增 workspace-qualified 会话 REST API不新增 ACP rewind 方法daemon 不对外宣告 ACP rewind vendor method不改动 core、不改动 ACP child不做 FileHistory 迁移~/.qwen/file-history/sessionId目录布局保持不变。关于文件历史布局不变的推论值得单独强调由于布局不变一旦出现 live UUID 冲突系统将通过owner 歧义失败关闭fail closed而不是选择 primary runtime这种带有隐式偏好的行为——这正是宁可报错也不误路由的安全姿态。Owner 归属与授权三态错误语义workspace registry 会在所有 live bridge 摘要中搜索目标 session id精确命中唯一受信 owner 后才把请求派发到该运行时。三种归属结果必须在目标 bridge 操作执行之前返回场景HTTP 状态错误码没有任何 owner404session_not_found命中的 owner 不受信任403untrusted_workspace多个 owner 同时命中UUID 冲突500ambiguous_session_owner持久化persisted会话必须先被加载load或恢复resume进某个运行时才会出现在 registry 的 live 摘要中换言之已落盘但未激活的会话在归属解析阶段视为不存在客户端需要先触发其加载。在请求参数校验层面rewind 与 shell 都保留mutate({ strict: true })严格变更门此外shell还要求有效的会话级 shell 启用状态effective session shell enablement、合法的 session-bound client id、非空 commandrewind转发可选的 client idrewindFiles仅当省略或为布尔值时被接受——省略等价于true其余任意 JSON 类型一律返回400 invalid_rewind_files_flag。这一校验顺序在路由源码中清晰可见session.ts先校验promptId为非空字符串否则400 missing_prompt_id再校验rewindFiles类型然后解析 client id header最后才调用runtime.bridge.rewindSession(sessionId, { promptId, rewindFiles: rewindFiles ! false }, ...)并记录rewind completed日志含rewound、filesChangedCount、filesFailedCount、workspaceId、workspaceCwd。行为边界cwd、可回退范围与 best-effort 文件恢复设计文档明确划定了三类操作的语义边界这些语义直接决定客户端如何使用Shell 的工作目录shell 启动于所属会话工作区的 cwd但它不是文件系统路径沙箱——即 shell 本身并不把命令限制在工作区目录内工作区 cwd 只是初始目录语义。Rewind 的可回退范围rewind只恢复为edit与write_file两类工具动作记录的快照它不会撤销shell、Git、脚本或手动产生的变更。文件恢复为 best-effort会话可能在响应返回rewound: false且带filesFailed[]时已经完成了回退——即会话已回退但部分文件恢复失败是允许出现的中间状态调用方必须以filesFailed为准做补偿判断。并发与目标校验语义保留活跃 prompt 继续返回409 session_busy与Retry-After: 5非法目标继续返回400 invalid_rewind_target。Web Shell 的既有行为Web Shell 继续显式请求rewindFiles: false即不随回退恢复文件。测试层面对上述语义做了逐条钉扎rewindFiles缺省与布尔值通过、非布尔值false、0、null被拒以及 partial restorerewound: falsefilesFailed: [failed.txt]场景均有对应断言见 multi-workspace-sessions.test.ts 与 multi-workspace-sessions.test.ts。能力宣告与客户端 Preflight两个能力位只在满足条件时被宣告multi_workspace_session_rewind仅当存活 runtime 数量 1时才宣告multi_workspace_session_shell除 runtime 数量条件外还要求有效的会话级 shell 启用——即 enable 标志与已配置的 token 两者同时满足。客户端 preflight 是**叠加式additive**的即访问 secondary 会话必须在 primary 能力之上再检查多工作区能力目标必备能力Primary rewindsession_rewindSecondary rewindsession_rewindmulti_workspace_session_rewindPrimary shellsession_shell_commandSecondary shellsession_shell_commandmulti_workspace_session_shell对于 ACP-native 客户端能力通过 initialize 阶段的_qwen.methods获取daemon不宣告 ACP rewind vendor 方法因此 ACP 客户端无法通过 ACP 通道发起 rewind只能走 REST。SDK 侧约束Rewind 强制 RESTShell 保持原传输SDK 层对两类操作施加了不对称的传输约束见 DaemonClient.tsRewind 系列强制走直接 RESTgetRewindSnapshots与rewindSession的fetchWithTimeout调用末尾都显式传入rest传输参数——即使客户端配置的是 ACP 传输也不例外。这是为了保留严格的 REST 变更门strict REST mutation gate避免 ACP 通道绕过mutate({ strict: true })的语义。Shell 保持配置的传输默认 REST 传输获得 owner 路由能力而 workspace-qualified 的 ACP 客户端则继续走_qwen/session/shell。同时ACP workspace 测试保留了一个关键不变式A 连接不能操作 B 会话而 workspace-qualified 的 B shell 可以成功——即跨工作区操作在 ACP 侧被明确禁止只有被授权的 B 会话 shell 被放行。验证矩阵单测与 E2E 覆盖设计文档给出的验证策略分两层单元测试钉扎的维度包括owner 派发正确性与对非所属 bridge 的零调用trust 与 ambiguity 失败路径403/500严格校验顺序参数校验先于 bridge 调用rewindFiles语义缺省 true、布尔透传、非布尔拒绝SDK REST fallback 行为shell 传输不变不因多工作区改造而切换传输条件式能力宣告runtime 数量与 shell enable 状态不存在 ACP rewind 映射。E2E 场景则串起完整用户旅程在 workspace B 创建会话并产生被跟踪的编辑验证快照与 shell cwd 均为 B 作用域检查两种 rewind 文件模式rewindFiles: true/false证明 shell 创建的文件在 rewind 后仍存活即 rewind 不撤销 shell 变更记录 busy、partial restore 与 untrusted-secondary 三类结果。小结该设计的核心思想可概括为API 形状保持不变路由语义升级。多工作区 daemon 通过每个请求实时解析 owner把 rewind/shell 从 primary 绑定中解放出来同时用三态归属错误404/403/500、严格参数校验、条件能力宣告、SDK 强制 REST 回退这一整套机制保证路由的安全性、可诊断性与向后兼容性。对客户端开发者而言掌握 preflight 能力叠加规则与rewindFiles语义即可在多工作区环境中正确驱动会话回退与 shell对二次开发者而言session.ts 中的withOwnerReadSession/withOwnerMutableSession封装与 multi-workspace-sessions.test.ts 的 dispatch 测试是理解并扩展现有路由的最佳起点。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Qwen Code Daemon 多工作区会话 Rewind 与 Shell：Owner 感知路由的会话文件操作设计解析
Qwen Code Daemon 多工作区会话 Rewind 与 ShellOwner 感知路由的会话文件操作设计解析【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读Qwen Code 的守护进程daemon在多工作区multi-workspace模式下为每个工作区运行时持有独立的桥接bridge但对外仍暴露单一化的会话 REST API。当 live 会话分布在多个工作区时rewind 快照、rewind 与 shell 这三类会话文件操作必须按请求解析出真正的会话属主owner再路由到对应运行时否则合法的二级工作区会话会被客户端误判为不支持的路径。本文基于 daemon-multi-workspace-session-file-ops.md 设计文档结合仓库路由实现与测试用例完整讲解这套 Owner 感知路由的决策、授权模型、行为边界、能力宣告与 SDK 侧约束读完可掌握多工作区 daemon 下会话回退与 shell 的正确使用方式及底层原理。问题背景单数 API 与多运行时之间的错位多工作区 daemon 为每个工作区运行时workspace runtime维护一个 live bridge。绝大多数 live 会话路由已经能够解析会话属主但此前以下三类操作仍被绑定在 primary bridge 上或直接拒绝 secondary ownerGET /session/:id/rewind/snapshots获取 rewind 快照列表POST /session/:id/rewind执行会话回退POST /session/:id/shell在会话工作区执行 shell 命令这造成了一个可观察的缺陷合法的 live secondary 会话与不支持的路径在客户端看来无法区分——客户端收到错误后不知道是该会话本就不支持还是只是自己拿错了 runtime。该设计文档属于最终实现设计Final implementation design它取代了 Phase 2a 中关于 live-session rewind 快照、rewind 与 shell 仅限 primary 的旧声明见 daemon-multi-workspace-phase2a-sessions.md。核心决策保持单数 API按请求解析 Owner设计上不引入任何 workspace-qualified 的会话 REST API也不新增 ACP rewind vendor 方法核心变更收敛为路径路由方式说明GET /session/:id/rewind/snapshotsOwner-aware 只读路由读取型操作只解析属主POST /session/:id/rewindOwner-aware 可变路由 共享会话归档协调器写操作走严格变更门POST /session/:id/shellOwner-aware 可变路由 共享会话归档协调器写操作走严格变更门同时明确不引入的改动不新增 workspace-qualified 会话 REST API不新增 ACP rewind 方法daemon 不对外宣告 ACP rewind vendor method不改动 core、不改动 ACP child不做 FileHistory 迁移~/.qwen/file-history/sessionId目录布局保持不变。关于文件历史布局不变的推论值得单独强调由于布局不变一旦出现 live UUID 冲突系统将通过owner 歧义失败关闭fail closed而不是选择 primary runtime这种带有隐式偏好的行为——这正是宁可报错也不误路由的安全姿态。Owner 归属与授权三态错误语义workspace registry 会在所有 live bridge 摘要中搜索目标 session id精确命中唯一受信 owner 后才把请求派发到该运行时。三种归属结果必须在目标 bridge 操作执行之前返回场景HTTP 状态错误码没有任何 owner404session_not_found命中的 owner 不受信任403untrusted_workspace多个 owner 同时命中UUID 冲突500ambiguous_session_owner持久化persisted会话必须先被加载load或恢复resume进某个运行时才会出现在 registry 的 live 摘要中换言之已落盘但未激活的会话在归属解析阶段视为不存在客户端需要先触发其加载。在请求参数校验层面rewind 与 shell 都保留mutate({ strict: true })严格变更门此外shell还要求有效的会话级 shell 启用状态effective session shell enablement、合法的 session-bound client id、非空 commandrewind转发可选的 client idrewindFiles仅当省略或为布尔值时被接受——省略等价于true其余任意 JSON 类型一律返回400 invalid_rewind_files_flag。这一校验顺序在路由源码中清晰可见session.ts先校验promptId为非空字符串否则400 missing_prompt_id再校验rewindFiles类型然后解析 client id header最后才调用runtime.bridge.rewindSession(sessionId, { promptId, rewindFiles: rewindFiles ! false }, ...)并记录rewind completed日志含rewound、filesChangedCount、filesFailedCount、workspaceId、workspaceCwd。行为边界cwd、可回退范围与 best-effort 文件恢复设计文档明确划定了三类操作的语义边界这些语义直接决定客户端如何使用Shell 的工作目录shell 启动于所属会话工作区的 cwd但它不是文件系统路径沙箱——即 shell 本身并不把命令限制在工作区目录内工作区 cwd 只是初始目录语义。Rewind 的可回退范围rewind只恢复为edit与write_file两类工具动作记录的快照它不会撤销shell、Git、脚本或手动产生的变更。文件恢复为 best-effort会话可能在响应返回rewound: false且带filesFailed[]时已经完成了回退——即会话已回退但部分文件恢复失败是允许出现的中间状态调用方必须以filesFailed为准做补偿判断。并发与目标校验语义保留活跃 prompt 继续返回409 session_busy与Retry-After: 5非法目标继续返回400 invalid_rewind_target。Web Shell 的既有行为Web Shell 继续显式请求rewindFiles: false即不随回退恢复文件。测试层面对上述语义做了逐条钉扎rewindFiles缺省与布尔值通过、非布尔值false、0、null被拒以及 partial restorerewound: falsefilesFailed: [failed.txt]场景均有对应断言见 multi-workspace-sessions.test.ts 与 multi-workspace-sessions.test.ts。能力宣告与客户端 Preflight两个能力位只在满足条件时被宣告multi_workspace_session_rewind仅当存活 runtime 数量 1时才宣告multi_workspace_session_shell除 runtime 数量条件外还要求有效的会话级 shell 启用——即 enable 标志与已配置的 token 两者同时满足。客户端 preflight 是**叠加式additive**的即访问 secondary 会话必须在 primary 能力之上再检查多工作区能力目标必备能力Primary rewindsession_rewindSecondary rewindsession_rewindmulti_workspace_session_rewindPrimary shellsession_shell_commandSecondary shellsession_shell_commandmulti_workspace_session_shell对于 ACP-native 客户端能力通过 initialize 阶段的_qwen.methods获取daemon不宣告 ACP rewind vendor 方法因此 ACP 客户端无法通过 ACP 通道发起 rewind只能走 REST。SDK 侧约束Rewind 强制 RESTShell 保持原传输SDK 层对两类操作施加了不对称的传输约束见 DaemonClient.tsRewind 系列强制走直接 RESTgetRewindSnapshots与rewindSession的fetchWithTimeout调用末尾都显式传入rest传输参数——即使客户端配置的是 ACP 传输也不例外。这是为了保留严格的 REST 变更门strict REST mutation gate避免 ACP 通道绕过mutate({ strict: true })的语义。Shell 保持配置的传输默认 REST 传输获得 owner 路由能力而 workspace-qualified 的 ACP 客户端则继续走_qwen/session/shell。同时ACP workspace 测试保留了一个关键不变式A 连接不能操作 B 会话而 workspace-qualified 的 B shell 可以成功——即跨工作区操作在 ACP 侧被明确禁止只有被授权的 B 会话 shell 被放行。验证矩阵单测与 E2E 覆盖设计文档给出的验证策略分两层单元测试钉扎的维度包括owner 派发正确性与对非所属 bridge 的零调用trust 与 ambiguity 失败路径403/500严格校验顺序参数校验先于 bridge 调用rewindFiles语义缺省 true、布尔透传、非布尔拒绝SDK REST fallback 行为shell 传输不变不因多工作区改造而切换传输条件式能力宣告runtime 数量与 shell enable 状态不存在 ACP rewind 映射。E2E 场景则串起完整用户旅程在 workspace B 创建会话并产生被跟踪的编辑验证快照与 shell cwd 均为 B 作用域检查两种 rewind 文件模式rewindFiles: true/false证明 shell 创建的文件在 rewind 后仍存活即 rewind 不撤销 shell 变更记录 busy、partial restore 与 untrusted-secondary 三类结果。小结该设计的核心思想可概括为API 形状保持不变路由语义升级。多工作区 daemon 通过每个请求实时解析 owner把 rewind/shell 从 primary 绑定中解放出来同时用三态归属错误404/403/500、严格参数校验、条件能力宣告、SDK 强制 REST 回退这一整套机制保证路由的安全性、可诊断性与向后兼容性。对客户端开发者而言掌握 preflight 能力叠加规则与rewindFiles语义即可在多工作区环境中正确驱动会话回退与 shell对二次开发者而言session.ts 中的withOwnerReadSession/withOwnerMutableSession封装与 multi-workspace-sessions.test.ts 的 dispatch 测试是理解并扩展现有路由的最佳起点。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考