fix: reuse runtime processes across project sessions
Multiple projects could spawn duplicate heavyweight runtimes, while settings changes and remote reconnection could cancel or strand native conversations. Share compatible local OpenCode and DeepSeek Harness process owners and Agent-owned ACP connections, retaining workspace routing, per-session modes, model attribution, question ownership, targeted cancellation and idle cleanup. Restore remote pending questions and terminal task projections across reconnect and desktop restart, and preserve accepted ordinary requests during settings replacement while cancelling expert-team parents with their replaced scheduler. Extend regression coverage and Agent type checks. Record measured resource and real-model validation results, including failures and limitations. Also include the conversation media-generation design drafts (not an implemented feature), documentation entry links and dedicated Linux test-directory guidance. Desktop and Agent changes must be delivered together for shared process results. Validation: typecheck and lint passed; staged content and documentation links checked. Prior full regression and live-model evidence are recorded in progress notes; no new full test suite or model calls were run for this commit. Release note: 多项目会话现在复用兼容的 OpenCode 和 DeepSeek Harness 进程,减少重复启动并保持工作区、工具和取消隔离。修复远端问答在断线、重启及配置更新后的恢复与状态同步问题,Desktop 与 Agent 需配套更新。
This commit is contained in:
@@ -11,7 +11,9 @@
|
||||
| [浏览器多实例技术设计](./browser-tabs-technical-design.md) | 浏览器 Tab 身份、Conversation 绑定、IPC、BrowserService 和 MCP 路由 |
|
||||
| [实现与验证进度](./progress.md) | 工作区与 Runtime 相关改动的实现事实、验证证据与剩余阻塞 |
|
||||
| [执行记录存储与升级回收](./execution-history-storage.md) | 子任务过程差量存储、远程去重、旧库转换、空间回收及升级界面 |
|
||||
| [Runtime 交互边界](./runtime-interactions.md) | 原生权限、结构化问答、后台拒绝、终端交互、托管 Runtime 并行与输出及消息底部请求状态的适配范围 |
|
||||
| [Runtime 交互边界](./runtime-interactions.md) | 原生权限、结构化问答、后台拒绝、终端交互、并行与输出、消息请求状态及资源生命周期规则 |
|
||||
| [Runtime 进程复用技术设计](./runtime-process-reuse-technical-design.md) | 跨 Runtime 资源调研、锁定协议证据、进程与会话拆分、远端模型桥、实施顺序和性能验收 |
|
||||
|
||||
当前尚未拆出独立 User Stories、功能逻辑和 UI 设计文档;相关内容仍保留在两份现有 PRD
|
||||
中。浏览器多实例涉及跨进程身份和工具路由,单独使用技术设计文档维护。
|
||||
当前尚未拆出独立 User Stories、功能逻辑和 UI 设计文档;产品场景与验收保留在现有 PRD,
|
||||
Runtime 资源状态规则由交互边界文档维护。浏览器多实例和 Runtime 进程复用涉及不同的
|
||||
跨进程身份与工具路由,分别使用技术设计文档维护。
|
||||
|
||||
@@ -949,6 +949,41 @@ Electron、ChildProcess、PTY、SSH Client、Socket 或文件句柄。
|
||||
用户级 GoodBuddy Agent Daemon。依赖 Main 模型网关、审批或本机工具的 Run 不能被描述为
|
||||
可以无人值守继续。
|
||||
|
||||
### 14.1 Runtime 资源复用
|
||||
|
||||
2026-09-14 调研确认:多个项目可能各自保留一个重型 Runtime,状态或原生清单读取也会
|
||||
影响其启动与保留。用户需要多项目/多会话自然并行工作,而不是为避免内存增长关闭工具、
|
||||
子代理或删除历史。以下为新需求,**不表示 Desktop 0.13.2 / Agent 0.11.25 已实现**。
|
||||
|
||||
- **FR-RR1**:支持原生多会话的 Runtime,在同一账号和兼容启动配置下跨项目复用重型
|
||||
进程;不得仅因项目目录或会话不同重复启动。等价的默认和显式选择应得到相同复用结果。
|
||||
不兼容的 Runtime、Host、模型连接或插件配置可以分开,不要求全产品只有一个进程。
|
||||
- **FR-RR2**:仅查看被动状态不启动重型 Runtime。显式连接测试、原生清单和执行请求
|
||||
复用兼容的已启动实例;尚未握手时不能显示为已经验证连接。
|
||||
- **FR-RR3**:共享进程仍保持各会话的目录、历史、模型用量、工具、权限和业务问答归属。
|
||||
同一会话顺序执行,不同会话并行;Ask 保持只读,Execute 不增加第二层审批。
|
||||
- **FR-RR4**:请求结束、会话释放与进程退出分别处理。取消一个普通请求、关闭工作栏
|
||||
或释放一个会话不得误停其他健康会话;无会话的空闲重型实例及时释放。正常续聊保留
|
||||
原生上下文,应用退出、配置替换和真实进程故障仍有明确的终态与有界回收。
|
||||
- **FR-RR5**:托管 SSH 独立实现并验证复用,保留 Agent 对活动 Prompt 的所有权、
|
||||
断线续接、事件去重和模型调用结果不确定性规则。不能以本机通过代替远端交付。
|
||||
- **FR-RR6**:对不具备原生多会话 Host 的 Continue 保留正确的请求隔离;直连模型不
|
||||
新增独立模型进程。优化应有前后性能证据,不以删历史、禁用工具、全局串行化或
|
||||
推迟正常用户操作来换取进程/内存指标。
|
||||
|
||||
产品场景验收:
|
||||
|
||||
| 场景 | Given / When / Then |
|
||||
| --- | --- |
|
||||
| US-RR1,首次与热启动 | 同一有效配置的两个项目,分别查看状态、打开清单并开始四个对话;状态不冷启动,后续共用一个可多会话的重型 Runtime |
|
||||
| US-RR2,并行与取消 | 两个项目有同名不同内容文件,四个会话进行真实开发;目录及成果正确,取消其中一个后其余三个继续完成 |
|
||||
| US-RR3,续聊与释放 | 一轮任务完成后继续原会话,再释放其中一个;原生上下文可续用、其他会话不受影响,数据库完整历史仍可查看 |
|
||||
| US-RR4,边界与远程 | 切换不兼容配置、查看 Continue/直连状态或中断 SSH;不串配置、不伪造多会话能力,Agent 已接受工作按现有归属恢复 |
|
||||
|
||||
资源状态规则由 [Runtime 交互边界](./runtime-interactions.md#runtime-资源生命周期)
|
||||
定义;锁定版本研究、实现选择与逐项验收由
|
||||
[进程复用技术设计](./runtime-process-reuse-technical-design.md)定义。
|
||||
|
||||
## 15. 无障碍与响应式
|
||||
|
||||
- 能力目录、所有面板实例、目标选择器、终端控制和进程操作可用键盘完成。
|
||||
|
||||
@@ -1,5 +1,471 @@
|
||||
# 工作栏实现与验证进度
|
||||
|
||||
## 2026-09-14 Runtime 进程复用(实施中)
|
||||
|
||||
对应 FR-RR1–FR-RR6,设计及完整验收清单见
|
||||
[Runtime 进程复用技术设计](./runtime-process-reuse-technical-design.md)。
|
||||
用户已授权实施,本次复用改动尚未整体提交或发布,不包含在正式 Desktop 0.13.2 /
|
||||
Agent 0.11.25 中。最终验证结果见本节末尾,早期失败及中间状态按时间保留。
|
||||
|
||||
- P0–P2:Main 已组合 `LocalRuntimeRegistry`,OpenCode Server 和 DSH Utility 按兼容
|
||||
配置共享,工作区通过轻量适配器传入 Session。无会话 owner 空闲 60 秒回收;
|
||||
适配器淘汰不结束其他会话。DSH 被动状态不再启动 Host,取消超时先释放目标 Session,
|
||||
同时回收对应 Main 工具资源;配置替换期间的原生问题继续交给原请求的 Runtime。
|
||||
- 首轮 Windows 完整 UI 使用当时构建的生产 Main/Preload/Renderer 和隔离 profile,
|
||||
OpenCode、DSH 各两个项目、四个并行会话,通过输入区和发送按钮完成实际开发。
|
||||
OpenCode 工具数为 7、7、6、8;DSH 为 9、13、11、11。独立运行各项目测试合计
|
||||
60 项通过。两类 Runtime 分别共用一个重型进程,本轮未使用原生子代理。
|
||||
- 首轮 UI 提供方请求共 55 次 HTTP 200:OpenCode 23、DSH 32。其中包含驱动选择器
|
||||
失误引发的一条额外默认项目 Ask,工具为 0,不把它计为开发任务验收。
|
||||
同轮 OpenCode 单进程 Private Commit 约 882.88 MiB,工作集约 629.51 MiB;
|
||||
Electron 自身指标另存,不将两者混为整个 App 的测量结论。后续重复运行和空闲
|
||||
证据见下文,不把这一单点与正式用户库直接比较。
|
||||
- P3:生产 Agent 已接入单 ACP decoder/握手、Session → binding/operation 路由、
|
||||
逐 operation Unix 模型桥及空闲回收。共享 stdio 与 Prompt 输入/期限分离;
|
||||
Session 取消结算可如实保留 `processTree: running`。未增加持久进程池账本。
|
||||
- 共享 Linux x64 Host 已通过现有加密凭据与固定 Host identity 连接。使用当前源码、
|
||||
固定 Node 24.19.0 / OpenCode 1.18.29 构建隔离测试包,走真实 prepare/commit、
|
||||
activate、attach 和 Agent-owned Prompt,不改写已有 Host 安装。
|
||||
- Linux 首轮五条 Prompt 共 22 次已完成且已交付模型调用;两个 Execute 分别在正确
|
||||
项目完成修改,各通过 8 项测试,四个会话只启动一个原生进程。但 Ask 的搜索被原
|
||||
`kind === read` 规则误拒,原生子代理工具因权限请求未转发而等待,首轮验收失败。
|
||||
修正采用原生 Session 工具规则;原生子代理只继承父拒绝规则、不继承允许规则这一点
|
||||
已按固定版本源码核实,子 Session 同样设置当前模式,并保留原生显式限制。
|
||||
- 下一轮测试脚本在 transcript 尚有分页时按已完成状态提前结束,误报缺少项目 marker,
|
||||
随后 cleanup 中止了其他三个请求。这是验证驱动缺陷,产品自身已有 `hasMore` 处理;
|
||||
驱动已修正为读完全部分页、等待全部并行结果。该轮共 14 次 dispatch,
|
||||
其中 11 次完成、3 次结果不确定,失败记录保留,不将其计为通过。
|
||||
- 重复测试包构建曾遇到 Host ENOSPC。只清理本轮已确认可重建的 bundle、Runtime
|
||||
staging 和重复 `.gbagent`,保留测试 home、workspace、SQLite 及报告,继续验证。
|
||||
- 后续两轮 Linux 各 7 条 Prompt、35/34 次 dispatch,四个 Ask/Execute 与原生子代理
|
||||
续接均通过,分别取得 483/467 条子会话事件;取消没有关闭共享 owner。重连驱动先后
|
||||
漏发 `controller/resume`、错读 `agent/capabilities.generation`,导致两次后续验收
|
||||
失败;均已修正,保留失败报告。35 次调用一轮包含 1 次结果不确定,34 次一轮全部完成。
|
||||
- 最终当前源码 Linux 生命周期复验:2 条 Prompt、5 次完成且已交付调用,共享一个
|
||||
owner。目标返回 `cancelled / processTree: running`;另一会话跨真实 SSH 断线、
|
||||
controller resume 和重新 attach 继续执行,3 个工具返回正确项目 marker。
|
||||
全部 binding 释放后等待 65 秒,owner 数为 0;停止隔离 Agent 后仍为 0。
|
||||
- 原生 Compact 单独复验:两项目各先完成 3 工具请求,再并行压缩原生 Session。
|
||||
两次压缩分别归到各自的新 operation,各 1 次已交付调用,前后为同一个 owner;
|
||||
总计 4 条 Prompt、8 次完成且已交付调用。释放会话并等待 65 秒后 owner 为 0,
|
||||
Agent 停止后仍为 0。该结果没有用普通聊天返回“已压缩”代替原生 Compact。
|
||||
- 第二轮 Windows 完整 UI 重开同一隔离 profile,四项目八条续接开发请求全部完成,
|
||||
OpenCode 包含原生子代理,DSH 使用已有原生工具。独立项目测试合计 77 项通过。
|
||||
两个 Runtime 仍各一个重型进程。另有四条实际慢工具请求:前两条 30 秒测试在点击
|
||||
停止前已结束,不作为取消通过;后两条 120 秒测试中目标被正常 Stop 取消,另一项目
|
||||
的测试继续完成,DSH PID 未变化。第二个 App 共 12 条任务,11 完成、1 取消;
|
||||
100 次 HTTP 200(OpenCode 24、DSH 76),无失败请求。
|
||||
- 第二轮任务结束后的 631.573 秒采样共 121 点,提供方请求计数始终为 100,
|
||||
DB 始终 2,928,640 字节、WAL 始终 4,268,352 字节。期间查看了项目和截图,属于
|
||||
**无新任务/模型请求**,不是完全无人操作的 UI。原生 Session 有意保留,不要求其
|
||||
Runtime 退出;首个 App 自行退出时的进程消失不计为空闲计时验收。
|
||||
|
||||
| 进程 | Private Commit 起止(MiB) | 范围(MiB) | 区间 CPU 秒 |
|
||||
| --- | ---: | ---: | ---: |
|
||||
| OpenCode | 826.34 → 825.05 | 824.36–830.82 | 12.03125 |
|
||||
| DSH Utility | 98.73 → 98.73 | 98.73–98.73 | 0 |
|
||||
| Main | 184.16 → 185.05 | 182.90–186.77 | 0.953125 |
|
||||
| Renderer | 142.80 → 136.22 | 135.00–142.80 | 0.6875 |
|
||||
| GPU | 120.48 → 138.88 | 120.48–173.52 | 0.0625 |
|
||||
|
||||
Private Commit 不是独占物理内存,工作集相加会重复计算共享页。这组测量未发现两个
|
||||
Runtime 在该空闲区间持续增长,但不是整个 App 无泄漏证明,也不是旧新版本对照。
|
||||
|
||||
- 当前 Linux 六个 ACP/bridge/owner 测试文件为 82 通过、0 跳过,包含 Windows 跳过的
|
||||
Unix broker 并发及旧路由排队拒绝回归。本机完整回归曾为 4,170 通过、67 跳过;
|
||||
首轮唯一失败来自旧测试把 `failed + running` 当成非法,修正后仍保留 `unknown`
|
||||
的拒绝断言,并新增共享失败/取消接受用例。
|
||||
- 标准 `typecheck` 原先没有把部分 Agent 源码作为检查入口。已增加
|
||||
`tsconfig.agent.json`,并修正暴露的 ACP resume capability、spawn stdio 及几个局部
|
||||
类型问题;扩展类型检查、26 项受影响 Agent 回归及 lint 通过,之后已再次进行上述
|
||||
当前源码 Host 生命周期与压缩验证。
|
||||
- 三个只读审查分别检查复用、质量/兼容来源和效率。修复了被动状态刷新不断重置
|
||||
60 秒空闲计时的问题;状态检查不取得执行 owner,Native Session 映射成为唯一会话
|
||||
保留依据,不再另存重复 conversation Set。最后本机定向回归 98 通过、3 跳过,
|
||||
含真实 OpenCode 与 DSH ACP 组合;扩展类型检查通过。该补修仅涉及本机 registry,
|
||||
不改变 Agent/远程路径。当时全量 `npm test` 为 **4,171 通过、67 跳过、0 失败**
|
||||
(356 文件通过、9 跳过,609.57 秒);`npm run typecheck`、`npm run lint`、
|
||||
`npm run build` 均通过。构建仍报告既有 chunk 大小/混合导入警告,不影响成功结果。
|
||||
- 保留 exclusive raw ACP 是已有公开字节流路径,不是为本分支中间形态保留的兼容层。
|
||||
新的共享取消/失败结果需要配套 Desktop/Agent,不声称旧 Desktop 已支持新结果。
|
||||
原生插件两处祖先遍历可局部提取,但没有已证实故障或性能收益,本次不为此扩展改动。
|
||||
- 本轮真实模型调用合计 **273 次**:本机两轮 UI 155 次,Linux 六轮
|
||||
**118 次 dispatch**(29 条 Prompt,114 次完成、4 次结果不确定)。
|
||||
包含所有失败轮次和误发默认 Ask,不重复计算最新报告别名;本机 HTTP 200 不等于
|
||||
Agent ledger 的完整交付证明。原生确定性协议测试不计入真实提供方调用。
|
||||
|
||||
补充的 owner 成本对照使用同一当前源码、同一 Windows 机器、全新空工作区,分别经
|
||||
生产 factory 创建两个独占实例或两个共享适配器。每种组合重复 3 轮,每轮显式连接后
|
||||
再做 5 次双工作区连接检查;共启动 18 个真实 OpenCode/DSH Utility,全部退出,
|
||||
**真实模型和本机合成模型请求均为 0**。测量前全量测试已结束,没有同时运行测试套件。
|
||||
|
||||
| Runtime / owner 方式 | 进程数 | Private Commit 中位数及范围(MiB) | 双工作区首次 ready 中位数及范围(ms) |
|
||||
| --- | ---: | ---: | ---: |
|
||||
| OpenCode 两个独占实例 | 2 | 1,401.17(1,396.15–1,517.91) | 1,195.00(1,184.14–1,213.49) |
|
||||
| OpenCode 一个共享 owner | 1 | 777.59(667.04–802.78) | 1,135.71(1,130.32–1,140.81) |
|
||||
| DSH 两个独占实例 | 2 | 171.62(170.79–173.50) | 167.06(163.36–167.78) |
|
||||
| DSH 一个共享 owner | 1 | 86.64(86.18–87.29) | 155.31(155.28–157.79) |
|
||||
|
||||
这是**进程所有权方式**的对照,不是旧版 App 对新版 App、等规模历史或真实开发负载
|
||||
对照;没有测模型首字节。DSH 后续连接检查读取已缓存握手,不能当作热 Prompt 延迟。
|
||||
最后一个共享 DSH 在无 Session 时每 5 秒读取状态,持续 65 秒,原 Host 已退出且没有
|
||||
重启,证明状态轮询不会续期空闲 owner。探针早期的类型及 CJS/ESM 打包错误均发生在
|
||||
模型调用前;改为正确 ESM 依赖解析并加入启动前语法检查后完成测量,未修改产品以适应驱动。
|
||||
|
||||
清理时,完整 UI 的“关闭窗口”按现有产品行为隐藏到托盘,并不退出 App。随后只对已无
|
||||
活动任务且重新核对启动命令的隔离 App 进程树进行清理;这不作为正常托盘退出验收。
|
||||
命名浏览器会话已关闭,本机按本轮启动路径筛选的进程数为 0。最终通过固定身份 SSH
|
||||
只读核对本轮 Linux 路径下的 `/proc` 进程和各测试安装 owner 数据库,两者均为 0;
|
||||
保留测试 profile、工作区、数据库和报告,未删除用户历史或停止用户 Runtime。
|
||||
|
||||
此时尚未完成的完整 UI、十项目和问答恢复验收,后续结果见以下继续验收记录。
|
||||
旧新版本全 App 对照、完整共享能力组合及 Continue/直连资源分解仍需独立完成,
|
||||
不能将 P0–P4/V1–V8 整体标为完成。
|
||||
|
||||
本机证据位于忽略目录 `.agent-resources/runtime-reuse-implementation-20260914/`,
|
||||
包括 UI 聚合指标、截图、Host 聚合报告及保留的失败轮次。这些不是 checkout 自带资产,
|
||||
不包含可提交的模型或 SSH 凭据。
|
||||
|
||||
### 继续验收:远端完整 UI 与模式切换
|
||||
|
||||
- 用户要求继续后,已从完整生产 Electron UI 启用远程项目、保存两个 SSH 项目并在
|
||||
各项目创建两条会话。仅在测试 SSH 命令入口将 `HOME` 指向既有隔离安装;项目保存、
|
||||
Host/Agent/Runtime 发现、Main Runtime factory、传输、协议、模型和工具均保持生产实现,
|
||||
未伪造 capability、Prompt、事件或权限结果。
|
||||
- 四条正常开发任务均完成,共用一个原生 owner。分别在各自工作区实现 words/prices,
|
||||
独立运行两项目测试为 12 + 13 = **25 项通过**。实际重叠峰值为 2 条请求,
|
||||
不是四条同时运行;四个会话完成后,共享的原生 owner 仍然存活。
|
||||
- 新增真实模型调用 **21 次**,分别为 5、5、5、6,均 completed 且已交付。
|
||||
与上一段 273 次相加,累计 **294 次**;没有把旧 Agent ledger 的 13 次基线重复计入。
|
||||
- 随后在原价格会话中从 Execute 切到 Ask 并发送原生业务问答请求,实际失败,UI
|
||||
显示“没有可安全附加的远端 Agent 请求,且恢复不会重放任务”。Agent 仍把 workMode
|
||||
固定在 binding 首次启动值,拒绝新模式;此次在模型 dispatch 前失败,新增调用为 0。
|
||||
此问题不能由先前“不同 binding 使用不同模式”的通过结果排除。
|
||||
- 当前修正只允许共享 Session 的后续准备变更模式,独占进程仍保持原契约;
|
||||
`AgentOwnedAcpPrompt.start` 显式接收当前请求模式,原生 Session 路由与 ACP 备用权限
|
||||
决策均使用该模式,不再捕获构造时模式。48 项定向回归和扩展类型检查、lint 通过,
|
||||
包含 Execute → Ask → Execute 保留 Session 与原生父/子问答。
|
||||
后续当前源码 Linux 包和完整 UI 复验已通过,见下一节;48 项是当时的定向结果,
|
||||
不是后续全部修正后的全量结果。
|
||||
- 首轮 UI 通过正常 `app.quit()` 进入生产退出清理,本机测试进程退出;
|
||||
隔离 Agent 随后按 installation identity 停止,`/proc` 与 owner 数据库均为 0。
|
||||
首轮报告、失败任务和工作区保留。再次构建前 Host 仅余约 251 MiB,已明确限定只回收
|
||||
更早停止的测试安装软件及重复测试包,不清理状态、历史或工作区。
|
||||
|
||||
### 继续验收:断线、取消、模式续接与 Desktop 重启
|
||||
|
||||
- 四个原生问题同时等待时切断实际 SSH,复现“ACP channel does not exist”,继而出现
|
||||
重复注册 binary channel。诊断确认 Agent-owned Prompt 可能没有 raw ACP journal 行,
|
||||
replay 却对不存在的行 ACK 0。修正只在已有 raw cursor 时确认 journal,不放宽正序号、
|
||||
channel/epoch 或 installation 检查。真实临时 SQLite 回归先失败再通过;94 项后端/
|
||||
journal/channel 测试、当前源码 Linux 六文件 86 项通过,失败报告保留。
|
||||
- 保留旧 Desktop profile 并更换隔离 Agent 后,旧安装的恢复曾无限重试阻塞项目。
|
||||
attach-only 路径现在在打开 channel 前明确报告安装身份不匹配,不重放 Prompt。
|
||||
同一 Agent 的新连接则保留 Runtime,对已有 binding 旋转 transport generation,
|
||||
新 channel 使用实际连接 generation;不同 daemon 或倒退身份仍按原规则拒绝/替换。
|
||||
- 完整生产 Electron UI 再次同时等待四个问题,实际断线重连后原表单和 Session 均保留,
|
||||
没有新增模型调用或 owner。四会话尚在等待时,第五个新 Session 可以执行文件读写;
|
||||
该 Session 的 Execute → Ask → Execute 三轮均完成,各 2 个工具、3 次模型调用,
|
||||
验证实际写入、只读读取、再次写入,不以模型自述代替文件结果。
|
||||
- 取消一个 120 秒原生命令时,其余三个待答会话仍可各自回答并完成。取消后立即在原
|
||||
对话显式发送新请求也完成,使用新的原生 Session,仍共用原 owner。已确认取消通过
|
||||
专用错误进入终态;未确认的 Stop 保留原恢复逻辑,不把网络中断等同于取消成功。
|
||||
曾出现 Task 已取消但 assistant message 仍 streaming,改用既有数据库终态事务
|
||||
同时更新消息、任务和终态事件。最终真实 UI、Desktop SQLite、Agent 状态一致,
|
||||
streaming message 和 active Task 均为 0,共享进程未被误杀。
|
||||
- Desktop 重启前的首次尝试因测试观察 SSH 挂起,实际上未退出,已明确作废该证据。
|
||||
驱动加有界观察超时和 `finally` 退出后,真实重启复现两个缺陷:live question 没有
|
||||
transcript provenance 却被当作持久事件拒绝;同项目串行恢复让第二个待答 Session
|
||||
无法附加。现由 Main 并行恢复任务,live question 使用已有待答 Map 和活动请求租约,
|
||||
只投影到实时会话快照,不伪造 provenance,不写新的问题日志。
|
||||
- 修正后的真实正常退出/重开恢复两个同时待答的 Session,后一个先回答并完成,
|
||||
前一个独立 Stop。两端终态分别 completed/cancelled,UI 无残留活动或恢复提示,
|
||||
仍为同一个原生 owner。到该轮累计真实提供方调用 **348 次**:
|
||||
273 + 首轮远端 UI 21 + 旧隔离安装诊断 6 + 当前隔离安装 48。
|
||||
48 次全部完成并交付;更早 273 次中的 4 次不确定仍保留,Prompt 取消不等同于
|
||||
模型调用交付不确定。后续审查复验的增量另记,不覆盖这一时间点。
|
||||
- 重启修正后的全量回归为 **4,186 通过、67 跳过、1 失败**,唯一失败是
|
||||
`ActivityPanel` 的 501 条历史显示测试;该文件单独重跑 **16 项全通过**。
|
||||
不将单文件重跑写成全量通过,原全量报告保留。此前 4,171 通过的报告早于这些修正。
|
||||
|
||||
### 继续验收:共享能力与配置退役审查
|
||||
|
||||
- OpenCode 生产 factory、真实二进制测试覆盖 2/10 项目,每项目两 Session、两轮原生
|
||||
文件读取并逐项目原生 Compact,manager 容量设为 1,仍只启动一个 Server。
|
||||
DSH 实际 Host/ACP composition 同样覆盖 2/10 项目、每项目两 Session、两轮原生
|
||||
文件读写和平台 Shell,一个 Host。二者使用确定性模型,新增真实提供方调用为 0;
|
||||
这是原生组合测试,不是十项目完整 Electron 性能测试。
|
||||
- DSH 补充双项目共享组合:原生 Skill、实际 stdio MCP、Host 插件清单、不同尺寸的
|
||||
inline 图片和 Execute → Ask 均通过。两项目使用不同 Main ToolProvider 和正确的
|
||||
conversation context,Ask 不调用先前 MCP,图片原始字节分别匹配。该文件当前
|
||||
**9 通过、3 跳过**;Host 在测试进程内实际运行,不能表述为完整 Utility/UI 能力矩阵。
|
||||
- 完整 61 文件复查分别检查复用、质量/兼容来源和效率。没有新增仅服务分支中间形态的
|
||||
兼容层;raw ACP 独占和 Continue 单请求 Host 保留其已有契约。
|
||||
复查发现重启后的回答/跳过未保存到 remote-authoritative assistant message,以及
|
||||
manager reset 后旧 controller 拒绝所属问题的回答。修正复用原消息 `answeredQuestions`
|
||||
metadata 和既有 question owner,不新增 schema、恢复日志或重复历史。
|
||||
- 真实 UI 复验又确认设置保存入口仍主动取消全部请求,不能以 controller 单测通过
|
||||
宣称生产配置切换完整。Runtime 设置、原生定制和能力更新现在只激活/退役配置,
|
||||
不批量 abort 或清除待答确认;已接受请求继续使用原配置。用户 Stop、清除数据和
|
||||
App 退出的原有取消/分离规则不变。真实 SQLite 的三入口回归覆盖并行恢复、反序回答、
|
||||
跳过、重新打开答案和终态;manager reset 回归覆盖旧问题可回答、新工作仍拒绝。
|
||||
最新 **152 项 IPC/controller/manager 测试、typecheck、lint 和生产构建通过**;
|
||||
这次补修的最终真实 UI 复验及全量回归仍在进行。
|
||||
- 后续真实 UI 的设置保存不再取消原生待答 Prompt;一次连接 readiness 超时后,
|
||||
重新启动 Desktop 附加同一请求并回答 `KeepYes`,原 owner 未更换,任务 completed,
|
||||
原消息的 `answeredQuestions` 已落库。再一次正常退出/重开后,“问题与回答”仍显示
|
||||
正确答案和完成状态,截图已检查。该时点累计真实调用 **352 次**,相对 348 新增
|
||||
当前 Agent 3 次及误选默认项目的本机 Ask 1 次;后者未使用问题工具,不计问答验收。
|
||||
当前 Agent ledger 共 51 次,均 completed 且已交付。正常退出 Desktop 后按已核对的
|
||||
隔离 installation 停止 Agent,所属 `/proc` 进程和 active owner 记录均为 0。
|
||||
- 复查设置更新的专家团队分支发现,既有调度器会取消剩余专家,但父请求可能用替换后的
|
||||
模型继续综合。仅对活动团队父请求保留配置替换取消,普通原生请求不受影响;
|
||||
**156 项 IPC/controller/manager/SubagentService 回归通过**。此分支属于 Main 专家
|
||||
调度,不是 Agent 原生子代理;远端普通 Prompt 的 `teamMode` 为 false,先前验证的
|
||||
SSH 问答路径不改变。
|
||||
- 工作区随后出现其他任务的新提交和 Magic Notes API 修改。整仓类型检查曾因其
|
||||
`DesktopApi.magicNotes.onChanged` 与 App 测试 mock 不匹配失败,没有覆盖这些并行
|
||||
改动。冻结 candidate 的 typecheck、lint、生产构建通过,前后性能对照
|
||||
使用该隔离源码,不滚入后来的功能变更;其已带入的按钮位置调整见下节范围说明。
|
||||
- 随后完成 baseline/candidate 两个独立生产构建、相同 seed 历史、三次冷启动及
|
||||
无新任务十分钟的全 App 对照,结果见下节。驱动校准失败不计性能样本,
|
||||
测量期间未并发全量测试;既有 owner-only 数据不替代此结果。
|
||||
|
||||
### 2026-09-15:前后完整 App 对照与剩余 Runtime 检查
|
||||
|
||||
对照基线为 `de14a6157a6c34f1e3ef22619eca374a50a83706`。通过隔离源码构建 baseline
|
||||
和包含本任务改动的 candidate,使用同一 Windows 机器、同一依赖、同一 seed
|
||||
SQLite(四项目、八会话、320 条等量历史消息)和相同工作区 marker。后续其他工作区
|
||||
提交不滚入该冻结对照;这里的冷启动是新的 App/profile/Runtime 进程,不清 OS 文件缓存。
|
||||
|
||||
截图及源码复核发现,candidate 的 `App.tsx` 同时带入了 `fbba2e3` 的工作栏按钮
|
||||
移到主题切换按钮旁的调整。用户明确要求保留,工作区及冻结 candidate 均未剔除,
|
||||
也不为此补跑。以下结果是**包含该 UI 差异的完整 App 实测对照**,不是严格的
|
||||
纯 Runtime 单变量实验;此前“只含本任务改动”的范围描述不准确,现予以更正。
|
||||
|
||||
- 每组 3 次冷启动,各 55 条请求、110 次确定性 loopback 模型请求。每次冷启动包含
|
||||
八会话一轮工具请求和五条热请求,最后一次另加两轮八会话续接。每轮等待八个真实
|
||||
Native Prompt 同时到达提供方再释放响应,随后实际原生 `read` 读取各项目 marker。
|
||||
全部目录结果正确,无全局 Prompt 串行化。该对照新增真实提供方调用为 **0**;
|
||||
自然开发、写入、Shell 和真实模型验收仍以前文证据为准。
|
||||
- baseline 稳态为 3 个 OpenCode Server、2 个 DSH Host;三轮分别累计启动 3/3/3 个
|
||||
OpenCode 和 4/4/6 个 DSH(包含被动状态临时 Host)。candidate 每轮只启动一个
|
||||
OpenCode、一个 DSH;六次 App 正常退出后,本次登记的全部 Runtime 进程均退出。
|
||||
- 早期驱动的必填模型字段、Windows 子进程继承输出管道、Runtime 未就绪时点击以及
|
||||
读到半份 JSON 报告导致的失败均保留,不纳入以下样本。最终报告原子替换,发送前等待
|
||||
实际启用状态并核对 Main 已接收请求;不重放失败/不确定的真实模型请求。
|
||||
|
||||
| 指标 | baseline,中位数(范围) | candidate,中位数(范围) | 样本口径 |
|
||||
| --- | ---: | ---: | --- |
|
||||
| 全 App 采样峰值 Private Commit,MiB | 3,543.18(3,485.58–3,589.01) | 2,040.11(1,698.68–2,085.82) | 每组 3 个 App,分别取采样峰值 |
|
||||
| Runtime 采样峰值 Private Commit,MiB | 2,843.18(2,831.00–2,854.82) | 1,338.93(1,229.31–1,347.63) | 同上,仅 Runtime 进程 |
|
||||
| bootstrap 到首个模型请求到达,ms | 4,519(4,464–4,529) | 3,573(3,519–4,040) | 每组 3 次,包含 UI 启动与操作,不是独立握手计时 |
|
||||
| OpenCode 热请求总时长,ms | 225(198–286) | 200(187–308) | 每组 9 次 |
|
||||
| OpenCode 首个可见事件,ms | 139(118–201) | 124(102–187) | 文本/推理/工具任一事件,不是模型首字节 |
|
||||
| DSH 热请求总时长,ms | 66.5(54–80) | 83(62–104) | 每组 6 次 |
|
||||
| DSH 首个可见事件,ms | 32(28–39) | 38(30–45) | 同上 |
|
||||
|
||||
这批包含上述 UI 差异的样本中,全 App 采样峰值中位数降低 **42.42%**,不能将全部
|
||||
差值单独归因于 Runtime 复用。DSH 的热请求中位数反而增加 16.5 ms,
|
||||
没有隐去该回退,也没有据此增加未经测量的队列优化。Private Commit 不是独占物理
|
||||
RAM,工作集求和会重复统计共享页;5 秒采样不等于捕获了瞬时峰值。两组使用相同
|
||||
测试观察代码,数据不是未插桩 App 或生产大库的性能承诺。
|
||||
|
||||
最后一次各有 **124 个**无新任务空闲样本,覆盖 **610.588 / 610.544 秒**,最大间隔
|
||||
5.149 / 5.068 秒。两组模型请求均固定为 58,active Task 为 0,DB 固定
|
||||
2,007,040 字节、WAL 固定 4,128,272 字节、事件数固定为 276。
|
||||
|
||||
| 空闲组 | baseline Private Commit 起止,MiB / CPU 秒 | candidate Private Commit 起止,MiB / CPU 秒 |
|
||||
| --- | ---: | ---: |
|
||||
| 全部 OpenCode | 2,433.02 → 2,382.73 / 19.359375 | 1,007.88 → 973.12 / 11.609375 |
|
||||
| 全部 DSH | 180.00 → 179.19 / 0.09375 | 86.92 → 87.62 / 0 |
|
||||
| Main | 211.00 → 200.34 / 4.9375 | 205.33 → 197.70 / 4.4375 |
|
||||
| Renderer | 183.32 → 137.40 / 0.265625 | 157.90 → 127.23 / 0.4375 |
|
||||
|
||||
Session 有意保留;DSH 尾端有 0.70 MiB 增量,不把这一段描述为所有点都下降,
|
||||
也不从十分钟数据宣称整个 App 已无泄漏。聚合报告同时保留工作集、堆、句柄和逐进程 CPU。
|
||||
原始数据位于忽略目录 `matched-app-WBCdJL/{before,after}-{10,11,12}`,汇总为 `summary.json`;
|
||||
这些是本机验证资产,不进入版本库。
|
||||
|
||||
其后才运行剩余 Runtime 检查,避免干扰对照:
|
||||
|
||||
- OpenCode 双项目真实 Server 组合通过原生 Skill、真实 stdio MCP 和不同 inline 图片,
|
||||
两轮八次 MCP 调用均用请求 ID 核对原 grant 归属,读取结果仍匹配各自目录;十项目
|
||||
测试仍通过。DSH 的对应共享组合也通过。四文件合计 **114 通过、4 跳过**,
|
||||
跳过的是 3 个显式启用的真实 DSH 模型测试和 1 个真实图像生成测试,不把这些记为通过。
|
||||
- 直连模型的会话 release/dispose 与实际 Shell 完整输出分页检查通过:删除目标会话
|
||||
缓存并释放对应 ToolProvider;dispose 先释放所有已知会话,再释放 provider。实际命令
|
||||
结束后输出可分页,dispose 后句柄失效。没有新增模型进程池、历史字节 LRU 或持久缓存,
|
||||
此处也没有做直连模型整体 retained-heap 泄漏证明。
|
||||
- Continue 使用实际 1.5.47 包和生产 Utility adapter,3 轮各两个并发请求,另 5 次热请求。
|
||||
11 次本机确定性提供方请求全部返回预期内容,11 个请求级 Utility 均退出,真实模型调用
|
||||
为 0。准备耗时中位数:冷准备 **333.93 ms**(326.06–381.94),同 adapter 缓存
|
||||
**0.0031 ms**(0.0010–0.0054),新 adapter 命中磁盘产物仍 **312.97 ms**
|
||||
(276.08–334.63),各 3 次。11 次原生 HTTP ready 中位数 **936.96 ms**
|
||||
(925.60–959.27),首个提供方请求从 run 起算 **980 ms**(969–1,013),总时长
|
||||
**1,353 ms**(1,314–1,373)。准备在 run 前单独测量,不能把它再说成总时长已包含。
|
||||
跨 adapter 重复准备没有消失;本次保留现有检查与缓存,不为约 0.31 秒的准备成本
|
||||
修改单 Session Host 或新增常驻池。
|
||||
- 最终整仓 `npm test -- --reporter=json --outputFile=<本机证据目录>/full-validation-final.json`
|
||||
为 **4,204 通过、67 跳过、0 失败**,耗时约 **733.80 秒**。包括最后加强的
|
||||
OpenCode 逐请求图片互斥断言、共享能力组合、设置退役及专家父请求回归;
|
||||
先前失败的 `ActivityPanel` 本次在全量中 **16 项通过**。早期失败报告仍保留,
|
||||
不将跳过的真实提供方或平台专用测试计为通过。
|
||||
- 全量结束后再次运行 `npm run typecheck`、`npm run lint` 和 `git diff --check`,
|
||||
全部通过,先前并行 Magic Notes mock 不匹配已不再出现。10 个相关文档的
|
||||
**140 个相对文件链接**均可解析,未独立复验标题锚点。全量测试进程及按本次测试
|
||||
路径筛选的本机验证进程均已退出;Linux 隔离安装的清理证据见前文。
|
||||
- 最终门禁及报告修订没有新增真实提供方调用,累计仍为 **352 次**。按钮位置调整及
|
||||
其他并行工作均保留;本次未执行 commit、push、tag 或发布。性能对照仍使用原冻结
|
||||
样本,不把整仓后来通过的回归结果描述成已重新测量该版本的性能。
|
||||
|
||||
验收边界仍需保留:性能对照是 Windows 四项目确定性读取,不是大库自然开发或十项目
|
||||
完整 UI 性能报告;十项目为实际 Native composition 测试。未测所有第三方插件的组合,
|
||||
未证明整个 App/直连模型无泄漏,macOS/Linux arm64 原生运行仍需可用平台或 CI。
|
||||
|
||||
### 2026-09-15:追加真实模型复验与资源观察
|
||||
|
||||
用户要求继续使用真实模型,并监控数据库及内存。此次将 `e1fe1cf` 与当时工作区改动
|
||||
冻结到独立源码目录,构建真实 Main/Preload/Renderer,使用新的隔离 profile 和四个专用
|
||||
项目,预置 320 条合成历史。按钮位置调整保留;没有把正式用户历史送入测试。
|
||||
原始证据位于忽略目录 `.agent-resources/runtime-live-20260915/run-tQ1xtk/`,
|
||||
不是 checkout 自带资产。本轮只调整测试驱动,没有修改 Runtime 产品源码。
|
||||
|
||||
- 独立生产构建通过。冻结快照的类型检查暴露并行附件功能的 App 测试 mock 缺少
|
||||
`getFilePath` / `importFiles`,未覆盖或撤销那部分工作;这一失败不被早先整仓通过
|
||||
的结果覆盖。初次构建取证脚本误用 Preload 扩展名、同步 esbuild 不支持插件等驱动
|
||||
错误均发生在模型调用前,生产构建与 Runtime 未因此修改。
|
||||
- 显式启用 DSH 的三个真实模型专项,全部通过:自定义 Header、Ask 下 Main 代理的
|
||||
Web Search/Fetch、真实 npm 插件在 Ask 被拒绝且在 Execute 执行。共 **7 次**
|
||||
实际模型请求;该次按测试名选择,仅运行这三项,不把其余九项的过滤跳过算作通过。
|
||||
- 完整 App 从输入区发出四项目八条开发任务,实际读写模块、添加边界测试并执行
|
||||
`node --test`。项目选择器曾因模糊名称匹配到路径中的 `live-2` 而选错项目,
|
||||
驱动在发送前被会话身份检查挡住,改用已验证的精确项目文本;没有重复发送已接受任务。
|
||||
- 第一轮六条任务完成、两条 DSH 以 `pi-ai stream idle timeout after 300000ms`
|
||||
失败。一次未观察到上游响应状态,另一条有 HTTP 200 但任务仍超时,不能把 HTTP 200
|
||||
当作交付成功。保留失败与数据库后,正常退出测试 App,将测试转发层改为独立
|
||||
`undici.request` 流式转发,再显式重跑这两条,均完成。由于同时重启了 App,
|
||||
不能据此断言已经唯一定位到转发器或提供方;本轮未盲目修改 Runtime 来规避失败。
|
||||
- 四项目独立执行测试分别 **16、17、18、19 项通过,共 70 项**。每类 Runtime 的
|
||||
项目请求存在重叠,使用同组 owner;本轮开发请求重叠峰值为 OpenCode 4、DSH 2。
|
||||
两类 Runtime 分批发送,不声称八条同时运行。
|
||||
后续真实原生子代理读取模块及测试,父请求执行测试完成;DSH 两个真实慢命令重叠时,
|
||||
只 Stop 其中一个,另一项目继续完成,DSH Host PID 未变。
|
||||
- 直连与 Continue 从同一完整 App 会话各发出一次无工具短请求,分别持久化
|
||||
`LIVE_DIRECT_OK` / `LIVE_CONTINUE_OK`。当前已配置的图像模型另发出一次生成请求,
|
||||
实际得到白底蓝色圆形图片并可在生产预览中打开;不是配置检查,也没有读取提供方
|
||||
返回的图片 URL。这验证当前配置路径,不冒充运行了绑定指定服务商的可选测试。
|
||||
- 此时 App 共 **16 条 Prompt:13 completed、2 failed、1 cancelled**,
|
||||
**67 次模型请求**;加上 DSH 专项 7 次,本机新增 **74 次真实调用(73 次文本、
|
||||
1 次图像)**。计数包含失败及显式重跑。早期累计 352 次暂增至 426 次,
|
||||
后续 Linux 增量另记;本机 HTTP 计数不等于 Agent ledger 的交付证明。
|
||||
- 真实子代理的 **153 条事件**,实际保存 **70,668 字节**,等价完整快照
|
||||
**495,934 字节**,该事件负载减少 **85.75%**。使用生产 codec 逐条还原及重新编码
|
||||
校验通过;6 次工具块 upsert 中无变化重复写入为 **0**,数据库 `quick_check` 为
|
||||
`ok`。这是同批事件的编码差额,不是整个数据库文件缩小 85.75%,也没有删历史。
|
||||
- 模型结束后连续 **610.857 秒、123 个样本**,最大采样间隔 **5.292 秒**。
|
||||
请求数固定为 16,模型调用数固定为 67,活动任务和 streaming 消息为 0;
|
||||
DB 固定 **1,765,376 字节**、WAL 固定 **4,140,632 字节**,消息数 355、
|
||||
事件数 663、事件 JSON 负载 284,577 字节均不变。
|
||||
- 本轮全 App 采样峰值 Private Commit 为 **1,728.79 MiB**,OpenCode + DSH
|
||||
合计采样峰值 **997.66 MiB**。没有同负载的旧版真实模型样本,不能把它与前文
|
||||
确定性对照相减生成新的“节省百分比”,也不把采样峰值称为瞬时峰值或独占物理 RAM。
|
||||
- App 收到正常 quit 后回收了本轮登记的全部 Runtime,OS 核验最终 Main、OpenCode、
|
||||
DSH 和 Continue Utility 均已消失。退出探针曾因等待 `will-quit` 误报超时:
|
||||
生产实现实际在 `before-quit` 清理后调用 `app.exit(0)`。该驱动失败记录保留,
|
||||
后续探针改从独立父进程观察退出,不修改产品退出路径或伪造原始报告中的 phase。
|
||||
关闭后 WAL 为 0,DB 为 **3,125,248 字节**,属于正常 checkpoint,不是空闲增长;
|
||||
已保存图片内容为 **1,351,526 字节**,不能把图片占用与事件差量节省混为一谈。
|
||||
|
||||
| 空闲进程 | Private Commit 起止(MiB) | 范围(MiB) | 区间 CPU 秒 | 句柄起止 |
|
||||
| --- | ---: | ---: | ---: | ---: |
|
||||
| 全 App | 1,345.77 → 1,345.95 | 逐进程样本保留 | 分进程见下 | 分进程见下 |
|
||||
| OpenCode | 750.42 → 746.00 | 741.62–750.42 | 5.984375 | 333 → 333 |
|
||||
| DSH | 89.86 → 89.86 | 89.86–89.93 | 0.015625 | 364 → 364 |
|
||||
| Main | 196.61 → 200.37 | 193.13–205.09 | 5.703125 | 1,137 → 1,137 |
|
||||
| Renderer | 120.66 → 121.51 | 120.64–122.67 | 0.15625 | 337 → 335 |
|
||||
|
||||
Main 堆使用量为 67.27 → 69.44 MiB;Main 与 Renderer 有小幅增量,不能表述为
|
||||
“所有进程都下降”。采样包含测试观察器累积记录的分配,这一窗口未见数据库增长或
|
||||
Runtime 句柄积累,但不构成整个 App 无泄漏证明。
|
||||
|
||||
当前源码 Linux 复验使用 `/root/tmp` 下的专用目录。旧 `/tmp` 测试 Node/依赖缓存
|
||||
已不存在,初次准备因失效链接失败,未发出模型请求。随后只替换本轮创建的失效链接,
|
||||
核验锁定 Node 24.19.0 的 SHA-256,并安装锁定依赖,完成当前源码 Agent/Runtime
|
||||
组包、隔离安装及 OpenCode 1.18.29 激活,不修改旧安装或无关 Host 文件。
|
||||
|
||||
- 两项目各 Ask/Execute 一会话,共四会话使用同一个进程 owner、一个原生 OpenCode PID。
|
||||
Ask 实际读取,Execute 实际修改和运行测试,目录 marker 均正确。后续原生子代理
|
||||
产生 **497 条**子会话事件,同一 Session 续接完成;两项目独立测试各 **8 项通过**。
|
||||
- 两个真实 90 秒慢命令期间,目标 Prompt 明确结算为
|
||||
`cancelled / processTree: running`。另一会话经真实 attach 传输断开、
|
||||
controller resume 和重新附加后完成,原 Session 与 owner 均保留。
|
||||
本轮走生产 SSH/ACP/Agent/模型桥,不是再次运行完整远程 Electron UI 或 Desktop 重启。
|
||||
- 共 **7 条 Prompt:6 completed、1 cancelled**,**36 次模型请求全部 completed
|
||||
且已交付**,逐 operation 归账。取消 Prompt 不等于模型交付不确定。释放全部 binding,
|
||||
等待 65 秒后 owner 为 0;随后停止本轮隔离 Agent,独立 `/proc` 与 owner 表核验均为 0。
|
||||
- Host 共 71 次资源快照,未出现采样错误;所属进程私有驻留页合计采样峰值
|
||||
**1,033.00 MiB**,其中 OpenCode 峰值 **771.60 MiB**。这是 Linux 私有驻留页,
|
||||
不是 Windows Private Commit;也不是 Linux 十分钟空闲或旧新版本对照。
|
||||
退出后 semantic-prompts、model-calls、runtime-owners 数据库分别为
|
||||
**1,634,304 / 36,864 / 24,576 字节**,WAL 均为 0。
|
||||
- 本轮最终新增 **110 次模型请求:109 次文本、1 次图像**,包括本机失败和显式重跑;
|
||||
加上此前 352 次,累计 **462 次**。其中本机一次未观察到上游响应状态,不能把全部
|
||||
110 次写成成功交付。实际开发项目测试合计 **86 项通过(Windows 70 + Linux 16)**。
|
||||
- 收尾时当前工作区 `npm run typecheck`、`npm run lint` 和差异检查通过。
|
||||
238 个 Runtime/Agent/远程适配器文件与冻结快照的文本内容一致,原始字节差异来自
|
||||
checkout 的 CRLF/LF;Main、Preload、Renderer 入口产物哈希未变化。并行附件测试
|
||||
mock 的缺项已在当前工作区消失,不回写冻结快照,也不掩盖其当时的类型检查失败。
|
||||
10 个相关文档的 140 个相对文件链接有效,标题锚点未独立复验。
|
||||
本轮没有产品源码修复,未再次运行全仓 `npm test`;前文 4,204 项通过的报告
|
||||
早于后来的并行附件/窗口改动,不能将其当成这些改动的完整回归结果。
|
||||
- 本机命名浏览器会话及所有本轮测试进程均已关闭;保留隔离工作区、数据库、生成图片、
|
||||
失败诊断及汇总报告,没有清理正式用户历史,也没有 commit、push、tag 或发布。
|
||||
|
||||
## 2026-09-14 Runtime 资源调研与方案(未实施)
|
||||
|
||||
- 按用户要求完成文档与源码调研,方案见
|
||||
[Runtime 进程复用技术设计](./runtime-process-reuse-technical-design.md),对应
|
||||
FR-RR1–FR-RR6。当前工作仅文档和本机忽略目录内的隔离探针,未修改 Runtime/Agent
|
||||
源码、停止用户 Runtime、清理用户数据或准备新发布。
|
||||
- 源码基线 `de14a6157a6c34f1e3ef22619eca374a50a83706`,保留此前活动 UI 修复。
|
||||
manager/controller、OpenCode、Continue、DeepSeek、直连、远程 ACP、Agent backend /
|
||||
owner、模型桥和原生插件均已检查。此前同基线生命周期定向回归为 11 文件、
|
||||
346 通过/1 跳过;不是本方案实施后的产品验收。
|
||||
- 已安装 0.13.2 的 09:10:12–09:15:12 五分钟只读采样:数据库约增加 2.72 MiB,
|
||||
3,367 条新增子代理事件约 1.49 MiB、平均约 465 字节,93 个工具 upsert 中未变化的
|
||||
upsert 为 0;App 相关进程 Private Commit 约 3,229–3,866 MiB,CPU 平均约为
|
||||
16 核整机的 3.15%。后续一分钟又完成两个任务,不能作为真正空闲或泄漏结论。
|
||||
- 两个 OpenCode Server 属于当前 App,启动工作区不同。其中一个原生库 0 Session /
|
||||
0 Message、约 527 MiB Private Commit。源码确认按工作区保留实例、清单可启动执行
|
||||
Runtime、无时间型空闲回收;没有独立调用轨迹证明该空 Server 最早由清单启动。
|
||||
- 首轮两个无真实模型探针中 OpenCode 通过,DSH 驱动误用工具内部 `filePath` 而不是
|
||||
原生 schema 的 `file_path`,断言失败。修正驱动参数后两项通过,未调整产品代码。
|
||||
- 随后完整三探针最终通过,Vitest 3 passed / 0 failed,39.20 秒:
|
||||
- 生产 OpenCode launcher 单次 spawn,两个目录四个原生 Session,文件路由与单会话
|
||||
删除后的其他会话存活通过;没有调用生产 `Runtime.run`。
|
||||
- 真实 DSH Host composition、Agent factory、文件和 PowerShell 工具,两个不同 cwd
|
||||
的 Agent 并行读写各自测试文件;生产控制面拒绝第二工作区也得到断言确认。
|
||||
这不是 Electron Utility/ACP 生产多工作区测试。
|
||||
- 一个 Windows 原生 `opencode acp`、一条 ACP connection、两个工作区 Session,
|
||||
并行完成两个合成 Prompt;`chat.headers` 的 sessionID 与两个 HTTP 请求归属一致。
|
||||
尚未经过 Agent backend、生产模型桥、真实工具/子代理或 Linux Host。
|
||||
- 本次研究真实模型调用 **0 次**;最终 ACP 探针向本机确定性服务发出 **2 次 HTTP
|
||||
请求**。测试服务、原生进程和专用工作区在 finally 中关闭/删除,不操作用户运行中的
|
||||
Runtime 或其临时数据库。
|
||||
- 复现命令:`npx vitest run --config .agent-resources/runtime-reuse-research-20260914/vitest.config.ts`。
|
||||
`probe.test.ts`、`opencode-result.json`、`dsh-result.json`、`acp-result.json` 保留在
|
||||
同一忽略目录,仅为本机证据,不作为他人 checkout 后必然存在的测试资产。
|
||||
- 未实施项及生产验收见技术设计 P0–P4/V1–V8;本次未进行新的 Linux Host 验证、
|
||||
真实模型开发任务或修复前后内存对照,不将原生能力探针描述成修复完成。
|
||||
- 文档核验覆盖 10 个改动文档、131 个相对链接和其中 44 个标题锚点,全部通过;
|
||||
FR-RR1–FR-RR6 的定义唯一且有验收引用,`git diff --check` 通过。研究用 OpenCode
|
||||
二进制剩余进程数为 0。产品源码未改动,因此本轮未重跑全仓 test/typecheck/lint。
|
||||
|
||||
本页下方 schema 35 段落保留当时的失败与未发布记录。其后已随 Desktop `0.13.2`
|
||||
(发布提交 `81ae9e0`)正式交付,Agent `0.11.25` 同期为维护发布;新的进程复用方案
|
||||
不包含在这两个已发布版本内。
|
||||
|
||||
## 2026-09-14 多 Runtime 工具操作摘要
|
||||
|
||||
显示与事件合并规则见[工具操作摘要](./runtime-interactions.md#工具操作摘要)。Continue、
|
||||
|
||||
@@ -10,9 +10,10 @@
|
||||
| DeepSeek Harness | 固定 Host 的 Execute 文件与命令工具不询问目录权限;若收到 ACP 权限请求,活跃 Execute 直接选一次性允许,缺少该选项时使用 Runtime 提供的允许选项,Ask 拒绝,不等待额外 authorizer | 固定 Host 当前未提供通用原生业务问答服务,不把普通模型正文误识别成待答协议。模型以普通回复提问时,用户通过下一条消息回答 |
|
||||
|
||||
托管 SSH OpenCode 的权限、原生问题事件与回复链路由
|
||||
[远程主机技术设计](../remote-host/technical-design.md)定义。本次候选的远端业务问答需要
|
||||
[远程主机技术设计](../remote-host/technical-design.md)定义。该远端业务问答基线需要
|
||||
Desktop `0.13.0`、Agent `0.11.24` 和新启动的托管 Runtime;请先升级 Desktop,再更新
|
||||
Host 环境。任意第三方 ACP 服务及旧 Agent 不因此获得通用问答接口,候选不表示已经发布。
|
||||
Host 环境。2026-09-14 的已发布 Desktop `0.13.2` / Agent `0.11.25` 已包含此前问答修复,
|
||||
但不包含本文末尾尚未发布的进程复用改动。任意第三方 ACP 服务及旧 Agent 不因此获得通用问答接口。
|
||||
|
||||
## 运行与失败
|
||||
|
||||
@@ -30,10 +31,17 @@ Host 环境。任意第三方 ACP 服务及旧 Agent 不因此获得通用问答
|
||||
提交失败时保留输入与重试入口,不生成已回答记录;取消未回答的问题不记为主动跳过。
|
||||
- 提交响应晚于任务结束时仍保存已提交的问答,但不覆盖完成或失败状态;晚于下一轮提问时
|
||||
不清除新的待答卡片。旧版会话未保存的问题与答案无法从“已提交”状态文案恢复。
|
||||
- 待答队列仅保存在当前桌面会话内存中,不写入会话快照。刷新仍在运行的消息时保留整个
|
||||
- 待答队列仅保存在当前桌面会话内存中,不写入持久会话快照。刷新仍在运行的消息时保留整个
|
||||
本地队列;完成、失败、取消事件或持久化终态快照清除整个队列。迟到的提交结果可以保存
|
||||
已回答记录,但不会恢复表单或覆盖终态。本机 Runtime 不恢复重启前未提交的问题;托管 SSH
|
||||
重新附加同一存活 Agent Prompt 时,由 Agent 当前待答列表补发问题,已回答的历史事件不补发。
|
||||
- 未发布的进程复用源码在 Desktop 重启后由 Main 并行附加同项目的存活任务,将待答
|
||||
列表和 Stop 所需的请求 ID 投影到实时 `activeRequest`,不保存该字段或重新发送任务。
|
||||
回答/跳过成功由 Main 写回原远程助理消息的既有问答历史,Renderer 不覆盖远程正文或终态。
|
||||
Runtime 设置、定制和能力更新让旧请求在原配置上结束,已有问题仍可回答;新请求使用
|
||||
新配置。专家团队例外:既有专家调度器在设置替换时取消子任务,团队父请求也随之停止,
|
||||
不使用替换后的模型汇总旧结果。详细实现见
|
||||
[恢复与终态投影](./runtime-process-reuse-technical-design.md#63-恢复与终态投影)。
|
||||
- 后台任务收到结构化提问时,通过现有 Main 路径明确失败并提示改为前台对话,不永久等待。
|
||||
- 请求结束或取消后清除对应待答映射;过期回答明确报错,不转交给后来的请求。
|
||||
- 任意终端程序的密码、OAuth 登录、许可证确认或 stdin 提示不自动回复 `yes`。这类程序应
|
||||
@@ -90,3 +98,46 @@ DeepSeek Harness 按调用 ID 保留名称、输入和摘要,结束事件省
|
||||
Runtime 的重试上限、请求重放或取消策略。
|
||||
|
||||
实现与真实 Runtime 验证证据见[进度记录](./progress.md)。
|
||||
|
||||
## Runtime 资源生命周期
|
||||
|
||||
本节对应 [FR-RR1–FR-RR6、US-RR1–US-RR4](./prd.md#141-runtime-资源复用),
|
||||
定义进程复用的行为规则。当前源码已接入本机共享 owner 和 Agent 共享 ACP;
|
||||
完整验收状态以[进度记录](./progress.md#2026-09-14-runtime-进程复用实施中)为准,不表示已发布。
|
||||
具体 owner、兼容键和协议实现见[技术设计](./runtime-process-reuse-technical-design.md)。
|
||||
|
||||
资源有三个独立维度:进程是否启动/退役,会话是否仍持有原生上下文,请求是否在途。
|
||||
“任务完成”“当前没有选中该项目”“工作栏关闭”均不能直接推导进程可以销毁。
|
||||
|
||||
| 触发 | 请求与会话行为 | 进程行为 | 对应需求/场景 |
|
||||
| --- | --- | --- | --- |
|
||||
| 被动状态读取 | 不取得新执行会话,已有状态可读取 | 不冷启动,不延长无会话 owner 的空闲期限;不为探测替换服务中的进程 | RR2 / US-RR1 |
|
||||
| 显式测试/原生清单 | 取得临时检查引用;清单带明确工作区 | 与执行共用启动 Promise 和 owner;结束只释放检查引用 | RR1、RR2 / US-RR1 |
|
||||
| 首次或并行 Prompt | 取得对应 execution space + conversation 的绑定 | 同兼容组复用,非兼容组分别启动 | RR1、RR3 / US-RR1、RR2 |
|
||||
| 普通请求完成 | 释放请求订阅、临时 token、问题和 callback,保留可续聊 Session | 不因为一个请求完成关闭整个进程 | RR3、RR4 / US-RR3 |
|
||||
| 取消一个请求 | 取消其模型/工具调用并结算,其他会话继续 | 不以 kill 共享进程代替正常会话取消 | RR3、RR4 / US-RR2 |
|
||||
| 关闭面板/切换项目 | 停止非必要 UI 推送;不取消后台任务或抹掉会话所有权 | 不触发隐式关闭 | RR4 / US-RR3 |
|
||||
| 显式释放/删除会话 | 释放该 Session 与会话工具资源;删除历史仍只由原有明确删除操作决定 | 其他引用仍在则保留 | RR4 / US-RR3 |
|
||||
| 无会话、无请求、无检查引用 | 不存在需要保留的原生上下文 | 进入短空闲等待,再关闭;新使用者到来取消等待 | RR4 / US-RR1、RR3 |
|
||||
| 配置替换 | 已接受请求使用旧配置结算,新请求使用新配置 | 旧 owner 排空后退役;不积累只被历史 ID 持有的旧配置进程 | RR1、RR4 / US-RR4 |
|
||||
| 进程故障/不可响应 | 只给该 owner 下受影响请求明确中断;未知结果不自动重放 | 有界终止失效 owner,不伪造逐会话故障隔离 | RR3、RR4 / US-RR2、RR4 |
|
||||
| SSH detach | 保留 Agent 已接受 Prompt 及既有恢复归属 | 关闭传输不关闭 Agent 或活动 Runtime | RR5 / US-RR4 |
|
||||
|
||||
表中 RRn 是 PRD 稳定需求 ID `FR-RRn` 的简写。
|
||||
|
||||
不变量:
|
||||
|
||||
1. 一条请求始终使用接受时的 execution space、工作模式、配置和归属;不能读取后来
|
||||
切换的 UI 选择,也不以进程 cwd 表示所有会话的 cwd。
|
||||
2. 同一会话串行,跨会话不增加全局 Prompt 队列。权限、子代理、问题、用量和最终清理
|
||||
必须沿同一 Session/请求归属,不因共享进程放宽 Ask 或限制 Execute。
|
||||
3. owner 的退出条件依据所有使用者,不依据某个 adapter 的空闲状态。
|
||||
未启动对象的 dispose 不产生冷启动;一个等待者取消不取消其他等待者的初始化。
|
||||
4. 正常会话仍持有原生上下文时,不用任意 TTL 清掉它来声称“空闲内存已回收”。
|
||||
无会话 owner 的短空闲等待为 60 秒;
|
||||
不增加用户配置项。它是进程引用回收,不是聊天历史保留期限。
|
||||
5. 持久历史不因请求结束、进程 idle、配置变化或测试 cleanup 被删除。
|
||||
原生进程确实重启后的续聊沿现有历史重建规则,不新增第二套持久会话快照。
|
||||
|
||||
已明确普通并行、取消、释放、配置替换及断线行为。各项实际通过的场景及尚未完成的
|
||||
组合/性能验证以[进度记录](./progress.md#2026-09-14-runtime-进程复用实施中)为准。
|
||||
|
||||
@@ -0,0 +1,386 @@
|
||||
# Runtime 进程复用技术设计
|
||||
|
||||
## 1. 状态与结论
|
||||
|
||||
| 项目 | 内容 |
|
||||
| --- | --- |
|
||||
| 状态 | 已接入本机与 Agent 生产源码,Windows / Linux x64 验证结果及边界已记录,未发布 |
|
||||
| 日期 | 2026-09-15 |
|
||||
| 调研源码 | `de14a6157a6c34f1e3ef22619eca374a50a83706`;相关 Runtime 与 Desktop 0.13.2 一致 |
|
||||
| 需求 | [工作栏 PRD §14.1,FR-RR1–FR-RR6](./prd.md#141-runtime-资源复用) |
|
||||
| 行为规则 | [Runtime 资源生命周期](./runtime-interactions.md#runtime-资源生命周期) |
|
||||
| 验证事实 | [实施与验证记录](./progress.md#2026-09-14-runtime-进程复用实施中),原始调研记录保留在同页 |
|
||||
|
||||
**修复对象是进程所有权过细,不是工具太多,也不是历史记录应该删除。** 本机 OpenCode
|
||||
和 DeepSeek Harness 应在兼容启动配置内共享重型进程,工作区与会话上下文仍各自独立。
|
||||
远端 OpenCode 必须同时调整 Agent 进程所有权、ACP 连接和模型桥,不能把桌面修复当作远端
|
||||
修复。Continue 的锁定版本是单会话 Host,不做未经验证的常驻进程池;直连模型没有独立
|
||||
模型进程,应检查对象、历史和工具资源的生命周期。
|
||||
|
||||
“一个进程”指一组兼容启动配置对应一个 Runtime Server/Host,不是把不同 Runtime、
|
||||
不同 SSH 账号、不同插件组合强行塞入一个进程。正常工具命令产生的短期子进程不属于重复
|
||||
Server,也不能通过关闭 Shell、子代理或 MCP 来达成进程数指标。
|
||||
|
||||
## 2. 修复前证据与缺陷
|
||||
|
||||
### 2.1 已测现象和解释边界
|
||||
|
||||
Windows 已安装 0.13.2 的只读采样发现两个属于同一 App 的 OpenCode Server:一个原生
|
||||
数据库为 0 Session / 0 Message,约 527 MiB Private Commit;另一个已有会话并执行请求。
|
||||
两个 Server 的启动工作区不同。源码能解释“清单查询也可启动按工作区缓存的 Runtime”,
|
||||
但没有取得能独立证明空 Server 最初由哪一个 UI 操作启动的调用链记录。
|
||||
|
||||
该缺陷不等于整个 App 内存的唯一来源。五分钟活跃采样的 App 相关进程 Private Commit
|
||||
约 3.15–3.78 GiB,CPU 平均占整机约 3.15%;后续一分钟包含新任务,不是空闲回收试验。
|
||||
数据库五分钟增长约 2.72 MiB,新增子代理负载约 1.49 MiB,重复工具 upsert 为 0。
|
||||
schema 35 的存储修复与本方案独立,不能回退或删历史来改善指标。
|
||||
|
||||
同次源数据检查还发现最近 100 个会话的消息 metadata 合计约 107.75 MiB,
|
||||
`listConversations()` 会读入这些会话的全部消息详情。它是 Renderer 大对象加载的明确
|
||||
检查方向,不是堆快照已经证明的泄漏。进程复用不能代替历史按需加载的独立性能工作。
|
||||
|
||||
### 2.2 调研基线的源码归属
|
||||
|
||||
| 位置 | 已确认行为 | 修复含义 |
|
||||
| --- | --- | --- |
|
||||
| [SelectedRuntimeManager](../../../src/main/agent/selected-runtime-manager.ts) | 缓存键包含原始 selection 与 execution-space identity;默认 8 个缓存、16 个保留实例;只在容量压力下淘汰 | 轻量工作区适配器和重型进程不能继续按同一键、同一数量计费 |
|
||||
| [AgentRuntimeController](../../../src/main/agent/runtime-controller.ts) | `canRetire` 同时要求无请求、无 owned conversation;普通完成不移除会话所有权 | 不能把“已完成请求”和“已释放原生会话”混为一谈 |
|
||||
| [本机 OpenCode](../../../src/main/agent/opencode-runtime.ts) | 对象私有 Server/client/初始化 Promise;已有多会话映射;多个入口使用固定 `defaultWorkspace` | 仅删除 manager 的 workspace 键会把后续操作送进错误目录 |
|
||||
| [DeepSeek Runtime](../../../src/main/agent/deepseek-harness-runtime.ts) | 每对象一个 Utility Host;`getStatus()` 调用 `getState()` 启动 Host | manager 的临时状态实例会额外启动、探测并销毁 Host |
|
||||
| [Harness Host](../../../src/main/deepseek-harness-host.ts)、[控制面](../../../src/main/agent/goodbuddy-harness-control-plane.ts) | 根 Provider 有 cwd 默认值;控制面拒绝与 Host workspace 不同的 `newSession.cwd` | 限制主要在 GoodBuddy 创建入口,不是原生工具缺少会话 cwd |
|
||||
| [Continue Host Adapter](../../../src/main/agent/continue-host-adapter.ts) | 每次 run 启动临时 Host,最终 `/exit` 与进程树回收;准备结果已在 adapter 内缓存 | 不重复添加已有缓存;研究跨 adapter 重复准备,不直接共享活动 Host |
|
||||
| [直连模型](../../../src/main/agent/model-runtime.ts) | Main 内 HTTP;历史 Map 按 50 个会话限制,其他归属及工具资源依赖 release/dispose | 没有可合并的常驻模型子进程,按对象和资源检查 |
|
||||
| [远端 ACP](../../../src/main/agent/acp-remote-runtime.ts)、[Agent backend](../../../src/agent-daemon/runtime-acp-backend.ts) | 会话取得 binding/channel;backend 按 binding 拥有进程并拒绝跨 binding 复用 process identity | 必须拆开会话绑定与进程所有权 |
|
||||
| [Agent-owned Prompt](../../../src/agent-daemon/agent-owned-acp-prompt.ts)、[模型桥](../../../src/agent-daemon/model-bridge-helper.ts) | owner 一个 ACP connection/session/当前 operation;helper 固定模型和工作模式并串行 dispatch | 共享进程还要求会话路由、请求归属和取消隔离 |
|
||||
|
||||
原始 selection 的 `auto`、默认 profile 和显式 profile 可能解析为同一有效配置。当前
|
||||
已确认“先按原始 selection 建键、后解析配置”的顺序,但尚未证明全部 UI 调用会实际生成
|
||||
等价重复实例。实施时从 [runtime-selection](../../../src/main/agent/runtime-selection.ts)
|
||||
和调用者验证,不把可能性记为另一次生产复现。
|
||||
|
||||
### 2.3 锁定依赖与协议基础
|
||||
|
||||
以仓库 lock 和本机已安装代码为准,不用最新网页替代锁定版本:
|
||||
|
||||
| 依赖 | 基线 | 本次核验 |
|
||||
| --- | --- | --- |
|
||||
| OpenCode binary / SDK / plugin | 1.18.29 | HTTP API 接受 directory;ACP 接受多个 Session;`chat.headers` 有 sessionID |
|
||||
| ACP SDK | 0.25.1 | 一条连接关联多个 request ID,session notification/permission 带 sessionId |
|
||||
| DeepSeek Harness 包族 | 0.1.2-rc.1 | Agent factory/scoped context、Session header.cwd、真实文件与 Shell 工具 |
|
||||
| Cordis | 4.0.2 | Host 根组件与 Agent scope 的生命周期 |
|
||||
| Continue CLI | 1.5.47 | 实际受管补丁入口的单 `M.session`、QuizService 和权限状态 |
|
||||
|
||||
已通过的三个隔离探针:
|
||||
|
||||
1. **OpenCode HTTP**:调用当前生产 Server launcher,只有一次 spawn;同一个 SDK client
|
||||
在两个目录创建四个 Session,读取各自的同名文件;删除一个 Session 后其余三个仍可取回。
|
||||
没有调用 `Runtime.run`、模型或活动取消。
|
||||
2. **DeepSeek 工具**:当前 Host composition 和真实 Agent factory 在同一 Node 测试进程中
|
||||
创建两个不同 cwd 的原生 Agent;并行执行真正的 `read`、`write` 和 PowerShell,
|
||||
同名相对路径各自命中正确目录。另确认生产控制面仍拒绝第二工作区。没有启动 Electron
|
||||
Utility、ACP Prompt 或模型流,不能据此声称生产多工作区已经可用。
|
||||
3. **原生 ACP 与模型归属**:Windows 上一个 1.18.29 `opencode acp` 进程、一条 ACP
|
||||
connection、两个工作区 Session;分别选模型并发出并行 Prompt。本机确定性 HTTP
|
||||
服务收到两次请求,原生 `chat.headers` 插件传来的 sessionID 分别匹配两个 Session。
|
||||
不经过已发布 Agent backend/helper,没有测试真实工具、子代理、Linux 或断线恢复。
|
||||
|
||||
三个探针真实模型调用均为 **0**,其中第三个有 **2 次本机合成提供方请求**。
|
||||
它们证明方案有原生基础,不替代后文的真实开发任务验收。
|
||||
|
||||
特别纠正:`dsh-tool-fs` 将 `exec.agent.session.header.cwd` 传给 `fs.resolve`;
|
||||
`dsh-tool-bash` / `dsh-tool-pwsh` 也从 Session cwd 补全相对 workdir。
|
||||
`dsh-fs-local` / 本地 Shell 的根 cwd 是非会话调用的默认值,不是工作区隔离边界。
|
||||
不需要为这个已具备的能力新建一套“每工作区 Filesystem/Shell Provider”。
|
||||
|
||||
官方背景资料:[OpenCode Server](https://opencode.ai/docs/server/)、
|
||||
[DeepSeek Harness](https://www.deepseek.com/harness/en/)、
|
||||
[Continue CLI](https://docs.continue.dev/cli/quickstart)。
|
||||
网页只用于核对产品入口;上述版本结论来自本地锁定代码和探针。
|
||||
|
||||
## 3. 选定的结构
|
||||
|
||||
### 3.1 两层对象,不建立通用进程池框架
|
||||
|
||||
```text
|
||||
SelectedRuntimeManager
|
||||
-> 轻量 Runtime adapter(有效 selection + execution space)
|
||||
-> OpenCode process owner / Harness Host owner(兼容启动配置)
|
||||
-> Session binding(execution space + conversationId)
|
||||
-> 当前 requestId / 原生 sessionId / 工作目录
|
||||
```
|
||||
|
||||
- 保留 Main 已解析、校验的 execution space;adapter 每次将其显式交给共享 owner。
|
||||
目录不是 Renderer 新增的任意启动参数,也不依赖 `process.chdir` 或进程级可变 cwd。
|
||||
- owner 持有唯一启动 Promise、client/connection、子进程、会话映射与关闭逻辑。两个
|
||||
工作区同时冷启动时复用同一 Promise;一个调用者取消等待不取消其他使用者的启动。
|
||||
- adapter 的 `dispose` 只释放其引用,不直接关闭同组进程。会话映射由 owner 持有,避免
|
||||
adapter 缓存淘汰丢掉原生续接。会话操作通过 binding 查目录,不从“当前选中项目”反查。
|
||||
- 设置重建沿用现有 reset/drain:新请求取得新配置,旧请求持有启动时的配置直到结算。
|
||||
旧配置不再有在途使用者后释放旧绑定和进程,不能被历史会话 ID 永久钉住。
|
||||
IPC 的 Runtime 设置、定制及能力更新不再主动取消全部请求或清空审批;controller
|
||||
退役仍允许回答其已拥有的问题,但拒绝新请求和未知问题。
|
||||
既有专家调度器仍在配置替换时取消专家子任务,团队父请求一起停止,防止用新模型
|
||||
汇总旧 generation 的部分结果;不为该单独生命周期新建通用退役框架。
|
||||
- 8/16 的旧上限不应继续限制轻量项目 adapter 数量。若保留重型 owner 的容量保护,
|
||||
应统计实际进程配置组及退役进程;不靠提高常数掩盖“一项目一进程”。
|
||||
- 只用进程内 Map、现有 controller、Promise 和普通定时器。会话历史仍以现有 SQLite /
|
||||
Agent transcript 为准,不增加数据库表、迁移、持久化池快照、恢复日志或新配额。
|
||||
|
||||
### 3.2 兼容键与上下文
|
||||
|
||||
先通过 `applyRuntimeSelection` 等现有解析取得有效配置,再生成进程键;公开的 selection
|
||||
仍按现有语义保存,不能把“跟随默认”永久改写成某个显式 profile。
|
||||
|
||||
| 范围 | 参与进程兼容性 | 留在会话/请求 |
|
||||
| --- | --- | --- |
|
||||
| 本机 OpenCode | 本机账号、二进制身份、有效模型连接/配置、启动环境、原生配置和插件组合 | 目录、conversation/session、Prompt、模式、当前权限和问答、请求级 MCP/知识 token |
|
||||
| 本机 Harness | Host/依赖版本、有效模型连接、图片能力、凭据引用、启动环境、启用插件及配置、启动 Skill 集合 | cwd、conversation/session、请求模式、Main Web/MCP 代理与用量归属 |
|
||||
| SSH OpenCode | 已有 Host/SSH 身份、Agent/Runtime installation identity、模型协议/连接、原生插件与启动配置 | Workspace、binding/session、operation、请求凭据和账本归属 |
|
||||
|
||||
第一轮只合并同一有效模型连接及等价默认选择,不顺便支持任意不同模型连接共享:
|
||||
本机 OpenCode 配置使用固定 provider ID,Harness 用量也读取 Host config,跨 profile
|
||||
混用会引入另一项真实风险。不同 profile ID 不通过比较或序列化明文 API Key 来合并;
|
||||
密钥、Header 和插件配置更新通过现有设置失效路径使旧 owner 退役。
|
||||
|
||||
调研基线的 SSH launch profile 把 workMode 写入原生启动配置。当前实现把工作模式
|
||||
放入 Session/当前 Prompt 路由,并设置原生 Session 工具规则,详见 §6.1;
|
||||
不能仅从兼容键中删除 workMode,也不向用户增加逐工具审批。
|
||||
|
||||
## 4. 本机 OpenCode
|
||||
|
||||
在 [opencode-runtime.ts](../../../src/main/agent/opencode-runtime.ts) 中抽出重型 owner,
|
||||
由 [create-runtime](../../../src/main/agent/create-runtime.ts) 的 Main composition 复用。
|
||||
保留工作区 adapter,逐项替换隐式 `options.defaultWorkspace`:
|
||||
|
||||
1. create/get/delete Session、Prompt、历史初始化和压缩。
|
||||
2. 原生能力、工具、文件、Skill、MCP 查询的 directory。
|
||||
3. SSE 订阅、父子 Session 归属、待答 question 的 directory 与原生 ID。
|
||||
4. 权限更新、abort、问题答复/拒绝、MCP 临时注册及最终清理。
|
||||
|
||||
会话绑定记录规范化绝对目录及原生 sessionId。同一 conversation 的请求继续串行,
|
||||
不同 conversation 并行,不引入覆盖整个 Server 的 Prompt 队列。
|
||||
现有 `snapshot: false` 必须保留。
|
||||
|
||||
`mcpMutationTail` 目前属于 Runtime 对象;共享后同一原生目录的变更必须由同一 owner
|
||||
串行协调。注册名称、工具可见性、knowledge token 和清理仍按请求区分,不能用一个全局
|
||||
“当前 MCP 列表”覆盖同目录或跨目录的其他请求。探针未覆盖动态 MCP,这是实施验收项。
|
||||
|
||||
第一轮保留现有按请求消费事件流和结束清理的方式,扩展目录及 Session 过滤即可。
|
||||
只有测出重复 SSE 消费是瓶颈时才另做 owner 级事件分发,不同时引入第二套事件总线。
|
||||
健康检查也读取 owner 的总 activeRequests,不能从一个空闲 adapter 判断整个 Server
|
||||
无任务后重启。异常退出使该 owner 的全部绑定失效,明确结算受影响请求,不重放已执行工具。
|
||||
|
||||
## 5. DeepSeek Harness
|
||||
|
||||
### 5.1 共享 Host 的最小改法
|
||||
|
||||
- 将 `HarnessState`、Utility 启动 Promise、ACP connection 和事件路由提升到兼容配置
|
||||
owner;Runtime adapter 保留请求工作区。
|
||||
- 每个新 Session 在 Main 解析 `realpath`,Host 校验绝对路径格式,
|
||||
不再要求它等于 Host 启动工作区;`meta.cwd` 传入已有 Agent factory。
|
||||
不依赖 Windows 大小写字符串猜测,也不取消路径存在性校验。
|
||||
- 保留一个本地 Filesystem、Subprocess 和平台 Shell Provider。Session 使用原生 cwd
|
||||
路由;非 Session 的清单查询显式传入查询工作区,不能回退到第一个项目。
|
||||
- 保留 `setup(agentCtx)` 注册 Skill 和工具视图、每 Session 的 Ask definition 身份校验、
|
||||
`sessionId + requestId` 准备及事件路由。Main 的 Web/MCP callback 按对应请求找
|
||||
ToolProvider,不挂到某个最先创建的 adapter 上。
|
||||
- 第一轮保持同 profile、图片能力和插件组合共享,`queueUsage` 的模型配置因此仍一致。
|
||||
给用量加跨会话断言,不借本次改造扩大跨模型 Host 能力。
|
||||
|
||||
第三方插件的初始化可能依赖配置中的路径,不能因为内置工具支持 cwd 就声称所有插件
|
||||
天然多工作区安全。已启用插件组合属于进程配置;对实际产品支持的插件验证它使用
|
||||
Agent scope/Session cwd。若某插件确实有项目级初始化状态,将该状态显式作为不兼容
|
||||
启动配置,而不是默认给所有工作区各起一套 Provider 或禁止 Execute 工具。
|
||||
|
||||
### 5.2 状态与取消
|
||||
|
||||
被动 `getStatus` 改为已有 owner 快照或本地配置/Host 资源检查,不调用 `getState()`。
|
||||
没有启动过时不能写“握手已验证”,可表示资源已安装、尚未连接。
|
||||
状态检查不取得执行引用,也不清除或重置无会话 owner 的空闲计时;owner 已回收时,
|
||||
临时配置检查对象用完即释放,不将其登记成新的执行 owner。
|
||||
用户显式连接测试与原生清单可启动共享 owner;已有 owner 时只做有界控制检查,最终
|
||||
释放的是检查引用,不能在 `finally` dispose 掉仍服务其他会话的 Host。
|
||||
|
||||
当前取消超时会 terminate 整个 Utility。共享后先取消并释放目标 Session 的 Agent /
|
||||
工具资源,不因一个请求结算较慢就杀掉仍健康服务其他 Session 的 Host。若真实控制面
|
||||
已失去响应,保留整个 Host 的有界终止,向受影响会话分别报告中断;不得把它说成
|
||||
“取消完全不影响其他任务”。同步插件卡死的进程级故障无法在同一 JS 进程中强行隔离,
|
||||
不为此新增通用恢复框架。普通长工具取消与整 Host 故障必须分开测试。
|
||||
|
||||
## 6. SSH OpenCode 与 Agent
|
||||
|
||||
本节定义当前源码的共享进程改造;当前已发布版本仍见
|
||||
[远程技术设计](../remote-host/technical-design.md)。不能删除或绕过其持久 binding、
|
||||
operation、transcript、ACK 和模型 dispatch 结果不确定性规则。
|
||||
|
||||
### 6.1 连接与所有权
|
||||
|
||||
将 `RuntimeAcpBackend` 的进程 owner 与 binding 分开:
|
||||
|
||||
```text
|
||||
Agent 当前 Runtime installation + 兼容配置
|
||||
-> 一个 process owner / 一条 ACP ClientSideConnection
|
||||
-> sessionId -> binding -> 当前 operation / 原始 Prompt Promise
|
||||
```
|
||||
|
||||
- 一条 stdio 流只交给一套 ACP decoder/connection,不能让几个 ClientSideConnection
|
||||
竞争读取同一 stdout。消息和 permission 按 sessionId 分派给 binding 的当前 operation。
|
||||
- `AgentAcpConnection` 统一连接级握手、stdio 解码与退出监听,Prompt
|
||||
生命周期仍留在 binding。同一 Session 串行,其他 Session 不等待它完成。
|
||||
- `closeAcpChannel`、取消和 release 只释放所属 binding/Session;最后一个 binding
|
||||
离开后空闲 60 秒关闭进程。关闭 Session 时等待原生 `closeSession` 和原始 Prompt
|
||||
结算,不等待排在 backend 控制队列后面的完成回调。只有原生控制面不响应时才有界
|
||||
终止共享进程,并向其余请求报告中断,不声称这类故障可以逐 Session 隔离。
|
||||
- terminal 与物理进程状态分开:取消/失败的 Session 也可返回
|
||||
`processTree: running`,表示进程继续服务其他 Session,不能伪报进程树为空。
|
||||
Desktop 与 Agent 须使用配套的新契约;原始字节透传 binding 仍保留独占进程规则。
|
||||
- 共享 stdio owner 不使用单 Prompt 的累积输入和墙钟期限管理整进程;单次写入、
|
||||
待写队列、输出背压继续有界,Prompt 输入与截止时间由 binding 管理。
|
||||
- SSH attach 仍不拥有活动 Prompt,断线不能取消或重发 Agent 已接受的工作。
|
||||
历史 binding 的语义和原生 sessionId 保留;内存进程索引从当前安装和已有绑定得出,
|
||||
不增加第二份持久进程恢复账本。
|
||||
- 同一 PID 的多个 binding 不代表同一权限或同一 operation。Host/installation identity
|
||||
变化仍使用已有失效和退役规则,不把不同 Host、账号或 Runtime generation 合并。
|
||||
|
||||
原生 `chat.message` 在模型请求前设置该 Session 的工具规则:Execute 允许工具;
|
||||
Ask 只开放原生只读、搜索和读取网络内容的工具,不开放 Shell/编辑/写入。
|
||||
OpenCode 1.18.29 的 ACP 不转发未注册子 Session 的权限请求,且原生子代理只继承父
|
||||
Session 的拒绝规则、不继承允许规则,因此子 Session 也按根 Prompt 设置规则,再
|
||||
保留原生子代理的显式限制。不能只把进程启动配置统一设成 `ask`,否则子代理工具会等待。
|
||||
|
||||
### 6.2 模型桥归属
|
||||
|
||||
选用锁定 OpenCode 已有的 **`chat.headers` 会话标记**,扩展当前受管
|
||||
[原生插件](../../../src/agent-daemon/opencode-subagent-plugin.ts),不靠解析正文、猜测
|
||||
“当前最新 Prompt”或重写用户模型名来路由:
|
||||
|
||||
1. 现有 Agent prepare/start 顺序在 helper 的进程内登记 Session/根 Session 与
|
||||
binding、operation;插件从原生 sessionID 及已建立的父子关系取得精确归属。
|
||||
2. 在请求生成时固定所属 operation,将有界内部归属 Header 加到 loopback 模型请求。
|
||||
归属必须覆盖原生子代理、自动/手动压缩,不能等 HTTP 到达后才绑定“目前活动的请求”。
|
||||
3. helper 检查它是否仍属于已登记的 Prompt,选择对应现有 Agent gateway/凭据上下文。
|
||||
转发真实提供方前剥离内部 Header;不将其当作密钥或新增认证体系。
|
||||
4. 当前 helper 的单 socket/全局 dispatchBusy 改成按 operation 隔离的派发状态;
|
||||
每个 operation 的现有轮次、顺序、字节和结果不确定性规则不变,取消 A 只关闭 A 的
|
||||
提供方流,不关闭 B 的 socket、response 或待处理请求。
|
||||
5. Prompt 终态撤销对应映射及凭据;迟到请求不能借用下一轮 operation。保留
|
||||
`snapshot: false`、关闭不消费的 title 请求和现有父子问题转交。
|
||||
|
||||
普通 ACP 双 Session 的 Header 路由已有探针证据;子代理、压缩和终态竞态的实际
|
||||
验证结果以进度记录为准。若锁定版本某条实际调用路径不触发 hook,先定位那条原生路径,
|
||||
不得悄悄用全局串行 Prompt 或一个共享凭据槽冒充并行复用。
|
||||
内部桥字段如需调整,按既有受管 Agent/Runtime 版本配套交付,不移动发布标签,不给
|
||||
旧 Agent 宣称具备新行为。
|
||||
|
||||
### 6.3 恢复与终态投影
|
||||
|
||||
- Agent-owned 语义 Prompt 不一定产生原始 ACP journal 行。binary replay 仍校验现有
|
||||
cursor 边界,但不存在 raw cursor 时不向 journal ACK 0;不虚建记录来满足 replay。
|
||||
- 同一 Agent 断线恢复后,保留的 Session binding 使用新 transport generation,
|
||||
Runtime 可以同时接纳新 Session。安装身份已经更换的 attach-only 请求明确失败,
|
||||
不能无限重试阻塞项目,也不能借此重发旧 Prompt。
|
||||
- Desktop 重启时,同项目的可恢复任务并行附加,不能等待一个待答 Prompt 结束才附加
|
||||
第二个。live `question`/`question-resolved` 不属于有 provenance 的 transcript,
|
||||
使用既有 pending Map,清除时只影响对应 request/question。
|
||||
- `conversations.list` 将恢复租约的 request/message ID 和待答列表投影为可选
|
||||
`activeRequest`,Renderer 合并表单并使 Stop 指向真实请求。保存 header/消息时不保存
|
||||
这个实时字段。回答/跳过成功由 Main 按 task → assistant message 归属更新既有
|
||||
`answeredQuestions`,不写另一份问题日志,不覆盖流式正文、已完成或失败状态。
|
||||
- 明确确认的取消使用现有消息/任务终态事务一并结算,避免 Task cancelled 而消息仍
|
||||
streaming。仍无法确认的 Stop 保持可恢复;连接中断本身不是已取消或已失败的证据。
|
||||
|
||||
## 7. Continue、直连模型与相邻内存问题
|
||||
|
||||
### 7.1 Continue
|
||||
|
||||
保留每请求 Host 的隔离和最终清理。1.5.47 的单 Session、QuizService/权限队列意味着
|
||||
“一个 HTTP Server”不等于可安全承载多会话;这一例外有锁定源码依据。
|
||||
|
||||
`getPreparedHost()` 已缓存本 adapter 的准备 Promise,磁盘也有按内容确认的补丁产物。
|
||||
先分别测量读取/哈希/补丁准备、Utility 启动、HTTP ready、首个提供方请求和退出耗时。
|
||||
若确认跨 adapter 重复准备明显,再将只读准备结果与启动 Promise 按已验证的 CLI
|
||||
identity/补丁版本放到 Main composition 复用;失败仍允许重试。不得复用临时 config、
|
||||
token、global dir、活动 Session 或权限/问题队列。设置替换及窗口状态刷新也纳入测量。
|
||||
|
||||
不在本次给 Continue 加多 Session 补丁或常驻池。将来只有锁定版本真正支持多 Session
|
||||
且生产桥验证通过,才替换这一实现。
|
||||
|
||||
### 7.2 直连模型及历史详情
|
||||
|
||||
- 不新增模型 Utility 或进程池。检查 `conversations`、`knownConversationIds`、
|
||||
summary、ToolProvider 与 DirectModelProcessService 的实际引用与 release 调用链。
|
||||
- 活动请求、会话可续读的有界输出和数据库历史是不同资源。请求结束回收临时闭包/
|
||||
callback;会话释放才结束其可续读输出和工具资源,不在工具刚完成时删掉用户可查看结果。
|
||||
- 当前 50 个会话的 history 限制不是字节上限。先采堆与 retained size,再决定可从
|
||||
SQLite 重建的历史缓存是否使用字节约束和 LRU,不能先增加一套持久历史副本。
|
||||
- Renderer 最近 100 个会话整包 metadata 加载另做列表摘要、当前会话分页、展开后取
|
||||
详情的性能改造;本方案只记录依赖,不将这一尚未设计完成的 UI 改造算进进程修复交付。
|
||||
必须保持完整历史、搜索、重新打开和当前活动事件可用。
|
||||
- 旧 Runtime 磁盘缓存可单独评估版本清理策略,不在本次研究或进程 idle 时删除安装、
|
||||
用户工作区、数据库、备份或历史。
|
||||
|
||||
## 8. 内部实施顺序
|
||||
|
||||
| 阶段 | 具体工作 | 必须产出的证据 |
|
||||
| --- | --- | --- |
|
||||
| P0 | 固化本次原生探针为聚焦回归;补有效 selection/进程计数和状态启动计数 | 修复前能复现重复启动,失败原因不依赖真实用户配置 |
|
||||
| P1 | Main composition、兼容键、owner 与 adapter 生命周期;本机 OpenCode 全入口目录化 | 真实 UI 两项目四会话同一 Server,文件/工具/问答/取消不串线 |
|
||||
| P2 | DeepSeek 共享 Utility、会话 cwd、被动状态、请求级代理及取消收敛 | 实际 Utility/ACP 两项目四会话,原生工具与插件验证,状态刷新无额外 Host |
|
||||
| P3 | Agent process/session owner、ACP 单连接路由、Header 模型桥、权限和终态清理 | 开发中的真实 Linux x64 Host,含多会话工具、断线/重连和结果不确定性 |
|
||||
| P4 | 全 Runtime 资源回归;Continue 冷启动分解与有证据的准备复用;直连对象释放检查 | 相同输入的前后进程/内存/CPU/磁盘/延迟报告;没有残留测试进程 |
|
||||
|
||||
这是依赖顺序,不是发布一半实现的许可。涉及的正常生产 UI 路径、远端专用修复和下节
|
||||
验收全部完成后,才能称为 Runtime 复用修复。Continue 测量若没有显示重复准备成本,
|
||||
明确记录不改;不要为凑齐阶段增加代码。历史 UI 分页是后续独立工作。
|
||||
|
||||
## 9. 验收与性能比较
|
||||
|
||||
### 9.1 必测场景
|
||||
|
||||
| 编号 | 对应需求 | 场景与通过条件 |
|
||||
| --- | --- | --- |
|
||||
| V1 | FR-RR1、FR-RR2 | 全新 profile 仅查看状态、切换设置,OpenCode/DSH 重型启动次数为 0;已有 Host 时刷新不新建;清单与首个真实请求并发只有一次初始化 |
|
||||
| V2 | FR-RR1、FR-RR3 | 同一有效模型连接,两个独立项目各两会话同时自然开发,OpenCode/DSH 各一重型进程;各项目同名不同内容文件、命令 cwd、Git/测试结果都正确 |
|
||||
| V3 | FR-RR3 | 第二轮复用同一批会话;Ask/Execute 混合,Ask 写入被边界拒绝,Execute 不增审批;Skill、MCP、图片能力、用量和业务问答不串归属 |
|
||||
| V4 | FR-RR3、FR-RR4 | 一会话取消真实长工具/子代理时另外三会话完成并通过独立项目测试;分别检查请求 abort、SSE、问题映射和工具句柄释放 |
|
||||
| V5 | FR-RR4 | 关闭面板不取消工作;释放一个会话不关闭共享进程;无会话 owner 空闲后退出;App 退出后本机受管进程无残留,远端按已有 detach 规则保留 Agent-owned 工作 |
|
||||
| V6 | FR-RR1、FR-RR4 | 等价默认/显式选择复用;不同实际连接/插件配置不串用;配置更新期间旧请求完成,旧 generation 不永久积累;超过八个项目不因轻量 adapter 报重型容量满 |
|
||||
| V7 | FR-RR5 | 当前源码 Desktop → SSH → 当前开发 Agent → 原生 Runtime,两个项目/四会话;断线、重连、取消、重复 ACK/事件、迟到模型请求不重复调用或跨 operation 归账 |
|
||||
| V8 | FR-RR6 | Continue 并发请求仍各自正确清理;直连 HTTP 不生出额外模型进程;会话 release 后工具/分页输出资源释放;性能采样不靠删除历史或禁用工具达标 |
|
||||
|
||||
V2/V4 必须是正常开发任务,模型可自然调用读写、Shell、测试和已支持的原生子代理;
|
||||
不是要求模型“不用工具”后回复一行。验证产出应用本身可运行、独立测试通过,模型口头
|
||||
说完成不算完成。每个 Runtime 只验证它已经支持的能力,不伪造 DSH/Continue 子代理。
|
||||
|
||||
### 9.2 采样口径
|
||||
|
||||
- 使用同一源码变更前后、同一机器、隔离 profile 与等规模历史副本;不改写用户运行库。
|
||||
覆盖至少三次冷启动、五次热请求,以及三轮多项目任务和至少十分钟**确无新任务**的
|
||||
空闲观察。分别记录中位数、范围与实际样本数,不从一次采样推断泄漏已消失。
|
||||
- 记录 Main、Renderer、Runtime 和工具子进程的 Private Commit、工作集/RSS、堆、
|
||||
CPU、PID/启动次数、会话数、活动请求、SSE/ACP 订阅与残留句柄。Windows 工作集求和
|
||||
会重复计算共享页,Private Commit 也不等于独占物理 RAM。
|
||||
- 同时报首轮准备、HTTP/ACP ready、首个模型请求、首次可见输出和总耗时。降低进程数
|
||||
但把不同会话全局串行化,不能通过验收。
|
||||
- 数据库/WAL 字节与新增事件负载分开;进程 I/O 包含管道,不能称为物理磁盘读写。
|
||||
继续检查未变化工具 upsert 为 0,旧历史读取/搜索/展开正常。
|
||||
- 核心硬指标是每个兼容组一重型进程、无额外被动启动、无跨会话错误、无结束后持续
|
||||
增加的活动句柄、无重复提供方 dispatch。没有证据前不承诺“固定省 527 MiB”或
|
||||
“整个 App 降到某个 RAM 上限”;原生 Session 仍保留时必须单独说明其常驻成本。
|
||||
|
||||
### 9.3 源码与平台验证
|
||||
|
||||
定向覆盖 manager/controller、各 Runtime lifecycle、Harness Host/control plane、
|
||||
ACP backend/owner、模型桥与插件,随后执行仓库要求的 `npm test`、`npm run typecheck`、
|
||||
`npm run lint`;生产构建改动在开发阶段按仓库规则构建验证。
|
||||
|
||||
凡改变 Agent 或桌面到 Agent 路径,必须在开发期间按
|
||||
[真实 Host 验证规则](../remote-host/technical-design.md#agent-开发期间的真实-host-验证)
|
||||
使用当前源码的共享 Linux x64 Host 验证。Windows 原生 ACP 探针、旧版本 Host、mock、
|
||||
CI 和将来发布测试都不能替代它。Windows PowerShell 与 Linux Bash 的工作目录及取消
|
||||
分别验证;macOS/Linux arm64 生命周期与原生依赖由可用原生平台和 CI 补齐并明确报告。
|
||||
|
||||
当前源码的真实 Linux Host、完整生产 UI 和最终整仓门禁结果均保留在进度记录;
|
||||
各次失败、修正、模型调用数及未测平台也一并记录,不以本机单测或原生协议探针
|
||||
替代完整产品验收。完整 App 性能样本保留用户要求的按钮位置调整,属于包含该 UI
|
||||
差异的实测对照,不是纯 Runtime 单变量实验。
|
||||
Reference in New Issue
Block a user