DeepSeek-Reasonix 会话运行状态架构从控制器快照到远程同步的完整实践指南【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix导读本文围绕 DeepSeek-Reasonix 中RuntimeState会话运行状态机制展开讲解 Desktop、Serve 与远程会话如何通过控制器提交的运行状态快照统一呈现执行、收尾、等待确认、取消、后台任务等实时状态并剖析其协议契约、同步策略、兼容性边界与验证入口。读完本文你将掌握该机制的完整数据模型、RuntimeStateSnapshot的字段语义、前端订阅与退避重试策略、Serve HTTP/SSE 接口行为以及如何借助源码与测试路径验证整个链路。背景为什么需要运行状态快照在 DeepSeek-Reasonix 中Transcript 事件仍然承担正文与完成结果的内容承载而运行状态正在执行、正在收尾、等待确认等是另一条独立的实时信息通道。运行状态同步具备以下特性docs/RUNTIME_STATE.zh-CN.md不增加模型请求状态刷新不会触发新的模型调用也不会重载历史。不改变持久化格式会话session与 inbox 的落盘格式保持原样。旁路通道运行状态通知不写入 WAL、transcript 或 provider 消息。从源码看这一设计在 internal/event/runtime_state.go 中有明确注释RuntimeStateSnapshotis a host-only, replaceable observation. It is never a transcript or durable turn record.即运行状态快照是仅主机可见、可替换的观测值它不是 transcript也不是持久化的轮次记录而Running字段则保留着传统的 admission gate准入语义internal/event/runtime_state.go。这是理解整个机制的第一把钥匙状态是观测内容是记录两者分离。状态数据模型event.RuntimeStateSnapshotschema version 1运行状态的核心数据结构定义在 internal/event/runtime_state.go当前 schema version 为 1显式包含以下字段字段类型语义runtimeEpochstring运行实例代次标识控制器重建、会话更换路径或 ledger 变化时生成新 epochrevisionuint64单调递增版本号同一版本对应同一不可变内容phasestringidle、executing、finishing、closed四态之一runningbool执行/收尾保护语义继承旧Running()的准入含义turnIdstring当前轮次 ID来自 turn ledgerturnStatusstring当前轮次状态来自 turn ledgerturnEventSequint64当前轮次事件序号来自 turn ledgerpendingPromptbool是否有待确认的提示等待确认cancelRequestedbool是否已请求取消cancellablebool当前是否可取消backgroundJobsint后台任务数量activitystring活动描述streaming流式输出或thinking思考中等此外结构体还提供ActiveWork()方法当Running || PendingPrompt || BackgroundJobs 0时返回 trueinternal/event/runtime_state.go远程 reducer 正是用它来更新routing.running[path]的判定。发布通道是独立的 Sink快照的发布走RuntimeStateSink接口RuntimeStateChanged(RuntimeStateSnapshot)它与普通Emit完全解耦internal/event/runtime_state.go。代码注释明确指出RuntimeStateSinkis independent of Emit: a state refresh must not become a new ledger record, extension invocation, or model-visible message.也就是说一次状态刷新绝不会变成一条新的账本记录、一次扩展调用或一条模型可见的消息。syncSink与coalescer也分别实现了RuntimeStateChanged保证并发场景下状态传播的一致性与合并能力。控制器如何生成并提交快照运行状态由控制器Controller在提交边界commit boundary采样生成。internal/control/runtime_state.go 中refreshRuntimeState的注释是理解实现的关键refreshRuntimeStateis a commit boundary, not a read-side workaround. Every lifecycle and job boundary calls it after releasing its owning locks.采样与提交流程持有内部锁读取状态源读取running、finishing、closed、canceling以及 session path 等标志位。epoch 判定若snapshot.RuntimeEpoch为空、路径变化或 ledger 对象变化则调用newRuntimeStateEpoch()使用crypto/rand生成 16 字节随机数并 hex 编码见 internal/control/runtime_state.go开启新代次。阶段推导running → executingfinishing → finishingclosed → closed否则idleRunning running || finishingPendingPrompt取自有待确认的 approvalCancellable !finishing (running || PendingPrompt || cancelling)BackgroundJobs来自jobs.RunningForSession(...)的计数。稳定性复验采样完成后重新上锁确认各标志位未漂移若在采样期间 admission/close/binding 边界推进则放弃本次提交并递归重试——确保不提交混合状态。内容比较后自增 revision仅在语义变化时Revision并覆盖快照。特别地token 增量不触发通知保持最后一次发布的版本水位watermark直到语义状态改变避免产生第二条 token 流internal/control/runtime_state.go。有界、离锁的异步发布提交后的发布是有界且离锁的pending单槽位、draining标志防止并发叠加go c.publishRuntimeState()在锁外串行排空待发布快照internal/control/runtime_state.go。这保证了观察者永远不会持有控制器锁发布频率天然被合并不会因高频事件风暴打爆下游后台任务jobs在真正关闭 done 之后才发布最终计数。RuntimeStateReader接口是可选的optional so older embedders of SessionAPI keep working见 internal/control/runtime_state.go不实现该接口的旧控制器会回退到RuntimeStatus()的兼容投影——这为旧版嵌入方保留了迁移路径。界面行为状态如何映射为用户可见语义docs/RUNTIME_STATE.zh-CN.md 定义了六种状态的界面契约状态会话与项目指示发送控件正在执行按实际活动显示思考或输出保留已有发送、停止语义正在收尾静态正在收尾不再显示思考动画隐藏本轮停止新输入持久化排队等待确认显示待确认保留原确认入口及保护正在取消继续显示取消中直到控制器结束不重复发送取消后台任务显示任务数量非当前会话也计入项目不把后台任务当作前台模型执行状态待同步保留最后已知事实以静态不可确认状态显示暂停发送和停止恢复连接后重新确认其中正在收尾是一个重要细节收尾期间隐藏本轮停止按钮用户新输入会持久化排队若入队成功显示已排队并清空草稿失败则保留输入并显示错误。相同草稿的显式重试使用相同的幂等键避免重复写请求。在源码中界面状态映射集中在 desktop/runtime_state.go 的runtimeDisplayStatusphase finishing→finishing收尾CancelRequested→cancelling取消中PendingPrompt→topicStatusWaitingConfirmation等待确认phase executing且activity streaming→ 流式输出phase executing→ 思考中BackgroundJobs 0→ 后台任务否则保留错误/暂停/等待交付等结果态activity字段本身由控制器根据事件种类推导internal/control/runtime_state.goText/Message事件置为streamingTurnStarted/Reasoning/ToolDispatch/ToolProgress/ToolResult/CompactionStarted/Retrying等置为thinking。项目指示的聚合规则项目指示汇总该项目所有运行实例同一远程会话通过多个标签页显示时只计一次去重后台任务被取消但尚未实际退出时仍保留计数及原有资源保护。Desktop 端投影、绑定与前端同步完整投影GetRuntimeStateSnapshotDesktop 的GetRuntimeStateSnapshot与runtime-state:changed事件共享同一份完整投影RuntimeStateProjection包含 epoch/revision、sessions 与 topicsdesktop/runtime_state.go每个会话条目RuntimeSessionState携带 tabId、scope、workspaceRoot、topicId、sessionPath、sessionGeneration、open/remote 标志、hostId 与 freshnesssynced/unknown投影 revision 与内容一起分配内容变化时Revisiondesktop/runtime_state.go采样离开 App 锁sampleLocalRuntimeBindings先在App.mu下拷贝绑定集合然后在锁外读取各控制器快照最后复验绑定集合长度与每个绑定相等——若期间控制器轮换了会话、被替换或在 open/detached 之间迁移则重试确保状态绝不会在旧的会话身份下发布desktop/runtime_state.go。复验覆盖控制器、标签、会话代次、路径及打开/分离身份。旧项目树接口由同一投影适配projectTreeRuntimeTopics因此项目树与运行状态天然一致。前端同步调度订阅优先、读取兜底前端同步实现在 desktop/frontend/src/lib/runtimeStateSync.ts 的startRuntimeStateSync遵循先订阅、后读快照的时序订阅runtime-state:changed事件 → 立即应用首次启动与周期任务主动read()Desktop 下优先SyncRuntimeState()失败回退GetRuntimeStateSnapshot()应用级 owner 每 30 秒校验一次每个 Serve 连接在一次校验中只读取一次挂接、焦点恢复、连接变化focus/online/remote-tab:updated触发即时校验在途请求会被合并inFlight标志不并发重复读失败按5、10、20、30 秒指数退避failures ? [5000, 10000, 20000, 30000][...] : 30000失败不清空已知状态desktop:resync事件触发恢复版本号递增、标记失败、必要时排队重试recoveryQueued。前端 reducer desktop/frontend/src/lib/runtimeStateReducer.ts 的acceptRuntimeState与远程端共享同一套版本判定语义返回accepted / duplicate / stale / conflict四种结果旧版本next.revision snapshot.revision→stale丢弃同版本同内容 →duplicate无操作同版本不同内容 →conflict触发合并后的重同步新 epoch 且非权威来源 →conflict需权威读取确认。Serve 端HTTP 与 SSE 接口GET /runtime-states与/statusServe 端实现位于 internal/serve/runtime_state.goGET /runtime-states仅从内存读取前台及 detached分离控制器的快照不列出 transcript、不生成标题、不查询余额。返回runtimeStatesViewschemaVersion、epoch、revision、sessions 列表每个 session 含 sessionPath、current 标志与完整 state。每次读取会分配新的 revision 并做 epoch 惰性初始化16 字节随机 hex见 internal/serve/runtime_state.go。/status增加runtimeState字段当SchemaVersion 1时running、pendingPrompt、backgroundJobs、cancelRequested、cancellable等旧字段同步从新快照取值internal/serve/runtime_state.go保证旧客户端语义不变。指定 session 的读取优先匹配真实拥有该 session 的实例ownedRuntimeStatusView先查前台控制器路径不匹配时再查 detached 控制器internal/serve/runtime_state.go。SSEruntime_state事件SSE 的runtime_state事件复用既有 session taggingBroadcaster.publishRuntimeState将事件帧标记sessionPath与sessionCurrentinternal/serve/runtime_state.go。新的会话状态不会越过session_changed屏障sessionTagSink在 session 激活/同步完成前将快照暂存为pendingRuntimeState就绪后才发布internal/serve/runtime_state.go保证订阅方先看到 session 建立、再看到其运行状态。外部接管takeover与只读镜像继续遵守原有 ownership 规则。远程会话GET/SSE 双通道 reducer 与重同步远程标签页remote tab同时消费 GET 与 SSE 两个来源其合并逻辑集中在 desktop/remote_runtime_state.go合法性校验validRuntimeState要求SchemaVersion 1、epoch 非空、revision 0、BackgroundJobs 0、phase 属于四态之一desktop/remote_runtime_state.go权威性判定首次发现某 path 或 epoch 变化的快照非权威来源SSE不采纳必须等权威 GET 确认晚到的 GET 不能覆盖更新的 SSE 状态或新绑定previous ! target.states[path]时放弃见applyRemoteRuntimeSnapshot版本判定同 epoch 下旧 revision 丢弃计入 stale 计数、同 revision 同内容为无操作、同 revision 不同内容判冲突计入 conflicts 计数并触发SyncRuntimeState()重同步连接代次围栏acceptRemoteRuntimeFrame复验tab.gen、client与selectionRevision防止过期帧写入一次校验一个连接只读一次SyncRuntimeState以hostID\0workspace\0base为连接键合并同一 Serve 连接下的多个目标tab每个连接在一次同步中只发一次 GETdesktop/remote_runtime_state.go能力降级旧 Serve 返回 404/501 时unsupported能力键会在当前连接代次内被记住此后回退到原有/status接口RemoteTabStatus不再反复探测解码失败 → 未知状态decode 失败调用markRemoteRuntimeUnknownLocked并把 freshness 置为unknown触发立即重同步未知路径清理GET 结果中不再出现的 path在事实未变的前提下从runtimeStates删除避免僵尸状态。诊断计数器stale / conflicts / failures使用原子变量统计仅记录状态来源、匿名代次epoch 截断为 8 位十六进制、版本、阶段、同步原因及丢弃/冲突/失败计数不逐 token 输出、不记录提示词、凭据或完整路径desktop/remote_runtime_state.go。兼容性边界旧协议字段与旧看门狗旧Running()保护语义不变执行/收尾准入逻辑继续由running字段承担新快照只是提供更丰富的可观测信息。缺失字段不作为零值旧负载legacy payload缺失字段不会被当作零值处理也绝不猜测收尾阶段。旧 Serve 的 404/501 能力缺失按连接代次记忆并回退旧接口不影响已有功能。所有旧协议字段保留/status中 running/pendingPrompt/backgroundJobs/cancelRequested/cancellable 等继续存在。旧看门狗退役新契约可用后旧的逐会话运行 watchdog 不再判定运行真值十分钟沉默清理ten-minute silence cleanup也不再决定项目活动状态——项目活动只由运行状态投影判定docs/RUNTIME_STATE.zh-CN.md。验证入口如何完整回归这条链路文档 docs/RUNTIME_STATE.zh-CN.md 给出的验证矩阵覆盖四层1. 根模块Go 控制器/事件/Servego test ./... go test -race ./internal/control ./internal/jobs ./internal/event ./internal/serve控制器快照提交、epoch/revision 单调性、activity 推导见 internal/control/runtime_state_test.go事件层RuntimeStateChanged旁路发布见 internal/event/runtime_state_test.goServe HTTP/SSE 投影与接管路由见 internal/serve/runtime_state_test.go 与 internal/serve/multisession_test.go。2. Desktop 独立模块Gogo test ./... go test -race . -run RuntimeState|RemoteRuntime|ProjectTreeRuntime|SessionRuntime|RuntimeBinding对应测试文件desktop/runtime_state_reconcile_test.go、desktop/runtime_state_binding_test.go、desktop/remote_runtime_state_test.go后者用真实http.Client 夹具服务器模拟远端 404/501、stale、conflict 等场景见 desktop/remote_runtime_state_test.go。3. 前端TS/TSXpnpm test:remote pnpm test:app-lifecycle pnpm build专项套件runtime-state-store.test.tsstore 与 reducer 版本判定、desktop/frontend/src/tests/composer-inbox-recovery.test.tsx收尾排队、幂等重试、失败保草稿、项目树专项。4. 浏览器与原生桌面node bench/runtime-state.mjs pnpm test:app-browserdesktop/frontend/bench/runtime-state.mjs 使用真实 Chromium 与可控帧runtime fixtures覆盖收尾、排队、失败重试、后台任务、远程断线/恢复及会话切换——浏览器帧夹具不能替代控制器及 HTTP/SSE 集成回归两者互为补充原生桌面需另外验证macOS 的本地隔离应用 loopback 测试模型可验证真实 Electron 壳内的发送、完成及侧边栏清除Windows/Linux 不能由浏览器结果推定通过需各自平台单独验证。小结DeepSeek-Reasonix 的运行状态机制以event.RuntimeStateSnapshotschema version 1为统一数据契约在控制器提交边界采样、经有界离锁通知旁路发布Desktop 通过完整投影与 30 秒周期 事件即时触发的前端同步保持界面鲜活Serve 通过/runtime-states、/status.runtimeState与 SSEruntime_state对外暴露内存快照远程标签页则以 GET/SSE 双通道 reducer 配合连接代次围栏、权威读取与退避重试保证最终一致。整个链路坚持状态是观测、内容是记录的分离原则不产生模型请求、不改写持久化格式并保留了全部旧协议字段的兼容语义。【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考