先说工具全貌：hmharness 是一个开源的 HarmonyOS/OpenHarmony 开发智能体框架（MIT），把工程创建、检查、构建、签名、安装、启动、日志读取和结果验证接成本地工具链，让 AI 不只是生成代码，还要用本机环境证明结果；自进化行为受审批、预算、canary 和回滚约束。它不是 DevEco Studio 的替代品，而是开发智能体和鸿蒙工具链之间的验证层。本文只展开其中一个功能：v0.23.26 的多会话真并行。
问题的两层
第一层很显性：开发者的真实工作流从来不是单线程------一边跑构建、一边翻日志、一边挂着一个等审批的安装。单会话 CLI 强迫你排队；开多个终端窗口则状态互不相通。
第二层更隐蔽：「多会话共享一个进程」的方案看起来能解第一层，直到一个会话的任务把进程搞崩------全体连坐；或者一个会话收复端口时把别的会话正在用的守护进程（比如浏览器扩展桥）顺手杀掉。
架构取舍：为什么必须子进程
「并行」和「隔离」在单进程架构里是天然矛盾的：要并行就得共享运行时，共享就不能真隔离。共享进程的任何方案------协程、worker、async 任务------都在同一崩溃域里。
v0.23.26 的答案是把隔离做到底：每个会话一个独立子进程，子进程内自带完整的任务队列、审批门和中断处理。会话 A 跑构建时 Ctrl+C 只停 A；会话 B 挂着等你批一个危险操作，A 照跑不误；会话 C 空闲待命。侧栏每个会话一个运行状态点（绿=运行/黄=等审批/灰=空闲），全局状态一眼可见。
端口家族隔离
子进程解决崩溃域，端口冲突还需要第二层设计：每个守护进程带家族标记，会话收复端口时只驱逐自己家族的守护------extension serve 这类公共桥不再被误杀。多会话共存时零误伤。
审批门是最大受益者
对 AI 开发场景，多会话并行的最大价值在审批门：单会话时代，模型提出一个危险操作，整个工具停在那里等你；现在等审批的间隙可以切到另一个会话继续干活------人不再被机器的提问阻塞。这改变了人机协作的节奏：审批从阻塞点变成后台挂起项。
边界与口径
- 对标 dsh/tmux 的多路使用习惯，但每个会话独立到子进程级
- npm @hmharness/cli 0.23.26+（Node ≥ 22）；Release tag 与 npm 完全对齐，检查点 773 项单元测试 CI 全绿
- 与华为、开放原子无隶属关系，净室设计
GitHub: github.com/swsgbl/hmha...