qwen serve 多守护进程并发会话Conversations 所有权切换Ownership Cutover实现解析【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code导读本文围绕 qwen-code 仓库中docs/plans/2026-09-06-conversations-ownership-cutover.md的实现计划及其设计文档 docs/design/2026-09-02-relaxed-standalone-daemon-ownership.md完整讲解 qwen serve 如何从进程级全局 Conversations 所有权切换到会话级 writer lease 并发边界。读完本文你将理解两个更新后的守护进程为何能共享同一用户的 Conversations 根目录、同时列出会话与创建新会话、在不同会话上并发工作同一会话为何始终排他Live 激活为何仍保持单一发布者以及后端、Web Shell 客户端、升级回滚与验收证据之间如何协同。文中所有关键结论均标注了仓库源码与测试依据。背景进程级全局 owner 的瓶颈在旧的实现中第一个触碰 standalone 或 Live 接口的qwen serve守护进程会通过ensureOnce()获取一个长生命周期long-lived的 Conversations 所有者owner记录从而阻塞其他所有存活守护进程对 standalone 的访问。连接到第二个守护进程的 Web Shell 即使只需要共享目录、新建聊天或访问不同会话也会收到503 conversation_runtime_in_use。作为对比普通工作区workspace从不施加进程级运行时所有者约束——多个守护进程可以指向同一个持久化工作区各自维护自己的 ACP bridge、子进程、live-session 索引、缓存与运行时 generation。因此更简单且更一致的策略是让每个守护进程独立服务不同会话用既有的会话级 writer 协议保护真正的共享写入边界。该方向由 Issue #10810 提出设计在 PR #10828 中获采纳强制性的 writer fence 已在 PR #10924 落地对应检查点cf44c778c0775d640560143828d851fa30dbd893。切换后的目标行为Outcome按实现计划切换完成后可验证的端到端结果是共享同一用户 Conversations 根目录的两个更新后的守护进程可以同时列出会话、创建新聊天并在不同会话上并发工作同一会话在其完整加载生命周期内保持排他——第二个守护进程对该会话的操作得到结构化的 writer 冲突Live 激活仍然仅对稳定 locator 记录的精确发布者开放某个会话或 Live 上的失败不会禁用无关的 standalone 会话后端与 Web Shell 的切换在本变更中已在本地实现但这不是发布完成的声明需要在实现分支更新到最终基线后重新核对集成点。交付顺序Delivery order计划明确了四步交付其中步骤 1 与步骤 2 构成一个不可拆分后端交付单元——在隐式职责找到替代者之前就移除 owner不是一个可发布的中间状态在外层 Conversations owner 仍然存在期间实现显式的 Live 启动准入Live-start admission并为后续的 stop/new/toggle 意图补充聚焦测试在同一后端切换变更中用 legacy 兼容检查替代长生命周期 owner将 journal 引导bootstrap与 Live 发布交接handoff移到各自的消费方并将 journal 租约争用按跳过处理交付会话级的 Web Shell 错误呈现与操作者恢复指引可作为伴生 PR允许先于后端切换落地用真实守护进程验证组合发布并文档化协调升级与回滚流程——后端与客户端变更必须一起发布。后端实现地图每个模块改什么区域当前职责要求的变更conversation-runtime-manager.tsensureOnce()在运行时访问前获取长生命周期 owner首次发布前执行 legacy 兼容检查保留精确根目录exact-root、generation、信任、强制 lease 证明与隔离quarantine检查conversation-runtime-ownership.tsowner 创建、校验、存活检测、退役、目录引导、稳定 Live 交接复用严格解析器、受检目录锁、精确陈旧退役、持久性与 inspect-and-retire 的宽限更新路径上永不创建新 owner 记录server.ts 与 serve-app-lifecycle.ts构造并 drain/release Conversations owner接入兼容检查移除生命周期 owner 的注册/释放保留 listener、host、runtime 与子进程的 drainstandalone-deletion-journal.ts依赖此前 owner 获取所执行的 state-parent 引导自主完成最小目录创建与身份校验在每次 read/recover/clear/write 路径上重新校验父目录standalone-session-service.ts生命周期租约与守护进程本地 journal 对账保留租约与现有逐条目 sweep 兜底证明普通争用被跳过而不使触发操作失败直接变更仍保留结构化冲突live/discovery.ts 与 run-qwen-serve.tsLive 发布与自定义 base 交接对稳定 base 也执行经验证的交接保留锁后宽限与最终发布锁发布失败保持 Live 局部化routes/live.ts 与 Live host 协调HTTP 与 Host 动作均可激活 Live在一个准入接缝要求当前协议版本 精确本地 PID/实例 nonce激活前重查 pending action generationConversations 任务再水合与 keepalive恢复绑定任务并事务性绑定未绑定任务保留 #10924 的 fence验证失败的恢复不会触发任务或产生 task-run 结果Journal 目录与权限的既有约束journal 私有的conversations/叶子及其子树在 POSIX 上保持0700。一个既有的、同 owner、非符号链接的稳定根例如0755的 home 目录.qwen仍然有效。移动 bootstrap 时不得 chmod 祖先目录也不得要求 Live 发布必须先发生。父目录校验还必须覆盖 journal read 与 clear 操作中的pendingClears快速路径。现有的对账 sweep 已能捕获逐条目失败先补充争用证据再决定是否需要代码改动。Legacy 兼容检查inspect-and-retireConversationRuntimeManager不再接受长生命周期ConversationRuntimeOwnership依赖也不再在ensure()中调用acquire()。从源码可见 conversation-runtime-manager.ts 的ensureOnce()在首次创建本地运行时之前仅执行this.options.checkLegacyOwner()随后才做根目录重校验、已有运行时采纳或新运行时发布。兼容检查的语义对应 conversation-runtime-ownership.ts 中导出的checkLegacyConversationRuntimeOwner存活的合法 ownerPID 仍存活 → 返回conversation_runtime_in_use迁移期过渡响应精确复验的陈旧记录在目录锁下读取、二次确认记录未变后原子删除并按宽限等待默认handoffGraceMs 1000ms随后守护进程继续畸形/不安全/未知状态保留conversation_runtime_ownership_compromised不可重试或conversation_runtime_unavailable可重试分类检查从不写入新的 owner 记录也不参与 Live discovery 交接检查是该守护进程 generation 的一次性动作在运行时发布后不轮询因此无法检测之后才创建的 legacy owner 记录——这正是所有共享同一 root 的守护进程必须同步升级的原因。在发布路径上兼容检查复用既有 owner 目录身份检查、proper-lockfile目录锁默认stale: 5000ms, update: 1000ms40 次退避重试、严格 V1 记录解析器version: 1, pid, instanceNoncenonce 匹配^[A-Za-z0-9_-]{16,256}$、PID 存活规则、精确记录清理、持久性同步与交接宽限。V1 记录文件要求单链接、0600权限、≤ 4KiB读时以O_NOFOLLOW打开并核对 lstat 与句柄 stat 的一致性。createServeApp只构造兼容检查器不再把 Conversations owner 挂到ServeAppLifecycleController生命周期控制器在关闭后因此没有 Conversations 所有权需要释放其 listener、app、host 与 runtime drain 保持不变。强制 writer lease会话级排他的实现核心切换后的真正排他机制是强制会话级 writer lease。关键设计点在**运行时来源边界runtime-provenance**而非会话来源边界强制当守护进程构建的工作区运行时其已验证来源为live-conversation时其 bridge 会在该运行时的 ACP 子进程环境中附加一个私有、仅启用的标记marker。primary、secondary、scratch 等普通工作区 bridge 不接收该标记CLI 入口在其第一次 await 或任何环境文件加载之前捕获并删除该私有标记仅接受 ACP 模式、仅当对应私有父能力存在、仅当值为精确启用值沙箱重启随私有能力一起携带已接受的标记普通重启不带runAcpAgent将捕获结果折叠进既有进程启动 writer 快照有效值为 true 当且仅当可信运行时标记被接受或用户启动设置启用了 lease。每次请求的设置热加载继续使用该冻结值因此一个 ACP 进程绝不混用已租约与传统两种 writer携带 Conversations 标记的可信托管子进程使用reclaimPolicy: local并保留takeoverPolicy: certified其他可信托管工作区子进程保持reclaimPolicy: never。ConversationRuntimeManager将 bridge 证明纳入其自有运行时校验assertMandatoryLeaseAttestation()要求runtime.bridge.mandatoryLeaseAttested true见 conversation-runtime-manager.ts。缺失或为假的证明是静态运行时契约违背新候选被拒绝并销毁等价的已注册运行时被终局隔离terminally quarantined并保留不可重试的conversation_root_compromised作为终局原因missing_mandatory_lease_attestation见 conversation-runtime-manager.ts此后每次ensure()或当前运行时断言都重抛同一错误绝不降级为可重试的conversation_runtime_unavailable该运行时也绝不会暴露给 standalone、Live、scheduled-task、lifecycle 或维护调用方。ACP 会话必须在配置初始化期间、报告成功创建或恢复之前获取租约并保持到会话关闭复用既有的session_writer_conflict、session_writer_lost、session_transcript_changed、session_writer_unavailable映射。这意味着 standalone 会话无视experimental.sessionWriterLease设置一律使用 writer leaseLive 与 scheduled-task 会话同样无法绕过同会话 fence。只回收可证明陈旧的同域本地活跃 writer在启用local策略之前Core 已加固该策略在 Linux 上活跃的 schema-version-2 记录在 hostname 与process_start_identity含 boot ID 与进程启动 ticks之外增加可选pid_namespace_id。缺失任一身份的旧记录或新记录一律视为存活绝不自动回收一个 Linux 活跃记录仅当其 hostname、boot ID、PID namespace 与竞争者完全一致且在该 namespace 内证明PID 不存在或PID 存在但 process-start 身份不同时才可回收EPERM/EACCES保持存活从不依据锁龄、获取时间、心跳缺失或守护进程响应性作决定Darwin 与 Windows 保留各自的进程启动探测要求精确 hostname 与已记录的启动身份身份不可得时记录保持存活。因此这两个平台依赖一台机器、一个 OS 用户的拓扑边界匹配的存活 PID包括事件循环停摆的进程保持session_writer_conflictforeign-host、foreign-boot、foreign-namespace、无身份、畸形、非普通文件与不确定记录全部 fail closed普通会话关闭移除精确活跃记录优雅托管关闭持久化密封sealed记录其他托管守护进程须验证 transcript 证明后才能接管非协作退出如守护进程父进程被杀而 ACP 子进程仍存活是受身份限定的恢复例外。Live 保持单发布者发布与激活双闸门Live discovery 的所有权协议本身不变见 live/discovery.ts记录由pidinstanceNonce标识校验NONCE_PATTERN与精确 owner 比较。问题在于发布publication过去并不直接限制激活activation旧实现是借 Conversations acquire 间接充当激活闸门。切换必须同时覆盖发布与每一条启动路径发布路径在writeLiveDiscoveryFile()之前对包括稳定 base 在内的每个目标 base 调用handoffLiveDiscoveryOwner()因为不再有 Conversations owner 记录可提交交接传入 no-op 的commitOwner并保留锁后宽限waitForHandoffGrace默认。陈旧 locator 仍可通过既有经验证交接回收活跃的 foreign Live owner 仍阻塞发布发布失败不影响该守护进程的 standalone 路由准入路径在等待发布完成、调用激活之前添加只读的 Live 启动准入——用同一稳定 base 目录身份检查、锁、安全记录解析器与精确 owner 比较重读稳定 locator要求当前协议版本 本地{ pid, instanceNonce }精确匹配。它从不创建、替换、移除或回收记录有效的不同发布者 → 可重试503 conversation_runtime_in_uselocator 缺失或瞬态不可读 →conversation_runtime_unavailable畸形或不安全状态 → 不可重试conversation_runtime_ownership_compromised这些失败是Live 局部的不会隔离 Conversations 运行时或禁用 standalone 路由。/live/start、/live/new与 Host 的toggle/new动作必须在一个异步准入接缝进入LiveHostCoordinator.start()之前汇聚。由于该接缝异步而 Host 动作分发器与 HTTP 路由同步pending 准入必须与后续 start/stop 意图线性化启动进入接缝时捕获 coordinator 动作 generation此后任何 Hoststop/toggle/new与任何/live/start、/live/new、/live/stop都推进该 generation接缝在start()前立即重查 generation被取代的启动直接丢弃——pending 期间到达的 stop 决不允许在准入解析时又启动呼叫被取代的请求不得创建会话、启动麦克风或 Appshot 捕获、也不得调度后续呼叫缺失或不安全的 locator 状态使 Live 关闭但不隔离 Conversations。Deletion Journal 自治引导与校验内聚standalone-deletion-journal.ts 过去依赖 owner 获取时隐式执行的 state-parent 引导。切换后StandaloneDeletionJournal自行负责由稳定 base 推导stateDirectory stableBase/conversations与journalDirectory stateDirectory/deletions见 standalone-deletion-journal.ts每次read/recover/clear/write 路径先做父目录校验inspectStateParent()检查稳定 base 为非符号链接、owned 目录且 canonical 身份稳定inspectPrivateDirectory()要求conversations/叶子为0700且属主为当前用户读取将缺失的 state 目录视为空首次写入安全地以0700创建ensureJournalDirectory()/ensureStateDirectory()已存在的不安全或被替换的父目录使 journal 操作 fail closed记录文件采用delete-uuid.(prepared|staged).json命名V2 记录含 transcriptParent 身份写入走临时文件 rename 目录 fsync 的持久化流程读取以O_NOFOLLOW打开并核对路径/句柄 stat 一致每个 journal UUID 在读取或变更 transcript 前仍进入其会话生命周期租约。后台 sweep 若在租约争用中落败跳过该 UUID 并继续触发操作不把普通租约争用归类为 journal 受损同一会话的直接生命周期请求保持正常结构化冲突。这保持了旧 owneracquire()曾经隐含提供的信任与引导职责同时避免删除逻辑依赖Live discovery 必须先运行。Web Shell 客户端局部错误与显式重试客户端工作有三个既有集成点计划原文档要求逐项改造StandaloneRecents.tsxactive/archived/分页读取与openSession()目前调用全局onError改为使用本地状态与既有 load generation源码中可见loadGenerationRef与sessionError状态并在isSessionWriterBlockedCode(getDaemonErrorCode(error))时走局部呈现路径DaemonSessionProvider.tsx对 standalone attach/restore 中的session_writer_conflict与session_writer_unavailable保留结构化错误码并停止自动恢复重试等待显式重试已建立会话的普通网络/SSE 重连保持不变App.tsx其连接错误 effect 不得对已在 standalone UI 呈现的错误再次通知 host直接链接与初始页面恢复可能绕过 Recents 的点击处理须在抑制 host 通知前呈现该连接 session ID/错误码与 section 级重试并保留loadSidebarSession()传播的原始错误。错误码与重试动作的既有约定客户端测试覆盖见 StandaloneRecents.test.tsx 与 App.test.tsxRecents 列表失败包括过渡性conversation_runtime_in_use在该 section只呈现一次导航触发的 refetch 不弹 toast打开会话时的session_writer_conflict/session_writer_unavailable呈现在受影响的会话或 section 上不得静默创建替代聊天409 session_writer_conflict意味着 writer fence 阻止访问不一定证明第二个进程当前存活复制copy逻辑必须考虑未解决锁且不得把无关的 409 错误归类为 writer 锁批量 archive/delete 保持传输层 200逐项检查errors[]不能把成功信封当作每项都成功。首个发布保留既有身份限定的回收策略并增加本地诊断/恢复指引。精确锁路径只属于本地操作者诊断绝不与 owner token 一起出现在公共 HTTP/ACP 错误契约中诊断必须解析受影响运行时的存储而不是主工作区或猜测的默认目录。恢复指南需区分正常关闭、认证密封接管、同域死活跃 writer、foreign/缺失身份、畸形或残余 claim 状态处理精确残余锁前必须停止或 fencing 一切可能的 writer含 ACP 子进程并保留证据/备份。指南不得建议递归删除锁目录也不得暗示foreign namespace 缺失 PID即死亡证明。跨启动自动回收、TTL、新持久化机器 ID 与 force-unlock API/UI 是独立后续工作。错误契约速查条件结果另一更新守护进程加载了不同会话列表、新建、对该不同会话的操作继续另一更新守护进程加载了该会话open/rename/repair该会话返回409 session_writer_conflict批量 archive/delete 包含另一守护进程加载的会话既有200信封该项errors[].code session_writer_conflict同域内可证明死亡的合法活跃 owner回收、权威 transcript 重载后继续活跃 owner 存活/停摆/foreign/缺失回收身份该会话409 session_writer_conflictwriter 记录畸形或非普通文件、或存在 transition claim该会话503 session_writer_unavailable密封记录匹配 transcript 证明认证接管、权威重载后继续密封记录 transcript 证明不匹配该会话409 session_transcript_changedConversations bridge 缺强制 lease 证明新候选拒绝销毁既有运行时终局隔离所有请求保持不可重试503 conversation_root_compromised安全工作目录新身份且无匹配本地 generation 残留丢弃孤儿 pin、采纳当前身份、经正常 writer/lifecycle 租约继续工作目录身份在其本地 generation 驻留期间变化或经租约生命周期操作捕获后变化既有working_directory_compromised存在存活的 legacy runtime-owner 记录迁移期 standalone 表面503 conversation_runtime_in_uselegacy 状态畸形/不安全/不确定既有conversation_runtime_ownership_compromised或conversation_runtime_unavailable非稳定 Live locator 发布者的守护进程尝试启动 Live/live/start或/live/new返回503 conversation_runtime_in_usestandalone 仍可用启动时稳定 Live locator 缺失/不可读/畸形/不安全Live start fail closedunavailable 或 ownership-compromised 映射standalone 仍可用错误分类常量集中在 conversation-runtime-errors.tsconversation_runtime_in_use可重试、conversation_runtime_unavailable可重试、conversation_runtime_ownership_compromised不可重试、conversation_root_compromised不可重试统一 HTTP 503。升级与回滚drain-and-cutoverREST 与 SDK 对象形状不变daemon 批量序列化器不得再把 session-writer 错误折叠成standalone_session_operation_failed须在受影响项的字符串code中保留既有 writer 错误种类发布是drain-and-cutover不是滚动混合版本升级停止所有无强制 lease 也能托管 standalone的守护进程版本确认其会话已关闭再启动带本变更的守护进程若旧→新顺序被违反新守护进程尊重存活的 legacy runtime-owner 记录并返回503 conversation_runtime_in_use旧守护进程退出后下一次运行时初始化会移除陈旧精确记录并继续无需重启兼容检查在运行时发布后不重复因此无法检测反向旧守护进程在新守护进程之后启动会找不到 owner 记录、写入一条、并在已租约 writer 旁运行未租约 ACP writer。所有共享一个 Conversations root 的守护进程必须一起升级回滚前必须关闭/drain 全部更新后的 Conversations writer确认不存在活跃、密封、claim 或身份扩展记录优雅进程退出本身可能有意留下密封交接记录版本说明应明确多守护进程可为同一用户暴露 standalone 会话活跃会话是 daemon-local受支持拓扑为一台机器、一个 OS 用户跨物理机器共享稳定 base 或 runtime base 不受支持Darwin/Windows 的陈旧回收规则依赖该边界不同会话 ID 可并发活跃同会话第二个 writer 或生命周期变更被 fencestandalone 会话总是使用 writer lease即使实验设置缺失或为 false只有精确稳定 Live locator 发布者可激活 Live同时再水合同一 scheduled-task 绑定会话只准入一个驻留 owner且不提供超出调度器既有持久化语义的 exactly-once 投递。验收证据与验证门禁计划给出了必须用真实守护进程完成的验收矩阵共享一个隔离 home、Conversations root 与 runtime base使用不同工作区与临时回环端口记录 daemon 与 ACP 子进程二进制/PID 以防已安装子进程破坏本地构建测试必要时用确定性本地 provider场景必需观察两个更新守护进程均以 200 列出并读取会话选项两者都不写runtime-owner.jsonA 持有 SB 使用 TB 列出、创建 T 并在 A 保留 S 期间提示不同会话B 竞争 Sload/resume 与直接变更返回 writer conflictarchive/delete 在 200 内逐项返回 conflictA 关闭 SB 在 A 的最后权威记录后恢复并追加验证 parent UUID 连续性优雅关闭或 idle reap认证交接与普通释放均允许后续恢复非协作死亡同域死 ACP writer 可恢复只杀 daemon 而其 writer 存活不允许接管歧义锁Live/停摆/foreign/缺失身份 writer 保持 fenced畸形/claim 状态保留其错误分类并得到准确指引Legacy owner存活 owner 给出过渡 503其退出后下一请求成功且无需重启新守护进程Journal 并发一个 daemon 对账某条目落败者的无关触发操作成功Scheduled tasks一个绑定会话驻留一个未绑定任务绑定胜出、失败孤儿关闭、绑定前无任务触发Live 准入仅精确稳定发布者可通过 HTTP 或 Host 动作激活被 stop 取代的 pending start 保持停止文件系统隔离缺失 journal parent 安全引导被替换/不安全叶子 fail closed 且不回退主工作区Web ShellRecents 点击与直接链接/初始恢复显示本地错误与显式重试无恢复循环或重复 host 通知陈旧错误不泄漏到另一会话升级与回滚新启动前全部旧 writer drain回滚显式处理活跃、密封、claim 与扩展 schema 记录实现侧门禁运行根目录npm run build、npm run typecheck、npm run bundle各变更包的聚焦 Vitest 套件以及npm run check:serve-fast-path-bundle随后执行真实双进程与客户端场景。Linux 特有的 boot/PID-namespace 用例必须由 Linux 证据满足macOS 运行不能替代。评审前按仓库两遍干净自审规则审查完整 diff 与新文件。本地验证记录macOS Node 22真实隔离 daemon 与 ACP 子进程验证了双 daemon 无新全局 owner 即可服务 standalone、不同会话提示重叠、同会话操作保留 writer 冲突、关闭 owner 后另一 daemon 可追加原 transcript 前缀与 parent UUID 连续性不变、停摆存活 ACP writer 在 daemon 被杀后仍 fenced、确认 writer 死亡后可恢复、journal 争用不影响无关创建、竞争任务 watcher 收敛到单一绑定/驻留含重启后、foreign Live 发布者拒绝 HTTP start/new 而 standalone 提示仍工作、严格 V1 owner fixture 配真实持有进程验证过渡 503 与退出后重试。完整服务端套件通过 1,226 项测试最终 Web Shell 运行通过 1,063 项测试core writer-lease 运行通过 99 项10 项平台跳过。发布仍需要 Linux boot/PID-namespace 证据、带凭据的原生 Live Host/audio 验证与协调升级/回滚验证详尽后端/浏览器证据与保留 fixture 路径记录在.qwen/e2e-tests/2026-09-06-conversations-ownership-cutover.md。边界与明确不做的事保留 #10924 的强制 lease、来源provenance、目录 generation 固定与未绑定任务资格行为普通工作区租约设置不变不添加跨 daemon 转发、owner 索引、active-elsewhere 目录提示、共享缓存失效系统、全局生命周期锁、所有权功能开关不同会话可并发同一会话不可并发编辑计划投递仍受既有 at-least-once 窗口约束设计文档还明确否决了 daemon 间代理、客户端重定向到 owner、per-daemon standalone 存储、仅靠用户设置启用 lease、仅对sourceTypestandalone启用 lease、把单发布者 discovery 当作激活 fence、现在加入activeElsewhere列表字段、共享路由/全局事务平面与无身份限定的陈旧回收等替代方案——这些都被视为不同可靠性契约或迁移窗口内的不必要复杂度。结语Conversations Ownership Cutover 将 qwen serve 的并发边界从进程级全局 owner迁移到会话级强制 writer lease Live 单发布者 legacy 迁移闸门使多个更新后的守护进程能共享同一用户的会话目录并在不同会话上并发工作同时把同会话排他、失败隔离与 Web Shell 局部恢复保留为结构化契约。对希望在同一台机器上并行运行多个 qwen serve 实例的开发者本文对应的设计文档 docs/design/2026-09-02-relaxed-standalone-daemon-ownership.md、实现计划 docs/plans/2026-09-06-conversations-ownership-cutover.md 以及 conversations 目录 下的源码与测试是继续深入的最佳起点。【免费下载链接】qwen-codeAn open-source AI coding agent that lives in your terminal.项目地址: https://gitcode.com/GitHub_Trending/qw/qwen-code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考