DoraMate 项目(14) - 本地执行架构设计详解: 基于 doramate-frontend 与 doramate-localagent 的真实落地实现

源起之道支持｜Supported by Upstream Labs

---

---

前言

很多“可视化 AI 工作流”产品在介绍本地执行时，容易把愿景、路线图和当前代码混在一起讲。结果就是文档里有安装器、托盘、服务管理器、跨平台发布矩阵，但仓库里实际上只有一个能跑起来的前端和一个能调 DORA CLI 的本地代理。

这篇文章的目标很明确：

• 不讲还没实现的能力
• 不复述抽象架构图
• 只说明当前仓库里已经存在、已经串起来、已经能支撑前后端协作的本地执行链路

如果用一句话概括 DoraMate 当前的本地执行模型，那就是：

浏览器负责可视化编排与状态展示，LocalAgent 负责文件系统与进程边界，真正的数据流执行仍然由本机 DORA 运行时承担。

也就是说，DoraMate 现在不是“浏览器里直接运行节点”，而是一个典型的三层协作结构：

1. doramate-frontend 在浏览器中编辑数据流、生成 YAML、展示运行状态
2. doramate-localagent 在 127.0.0.1:52100 提供 HTTP/WebSocket 能力
3. LocalAgent 调用本机 dora CLI，驱动 coordinator、daemon 和具体节点进程

---

一、当前项目里“本地执行”到底指什么

先把边界讲清楚。

1.1 前端不直接执行节点

doramate-frontend 是一个 Leptos + WebAssembly 应用。它主要做四件事：

• 管理可视化画布中的 Dataflow
• 在 DoraMate 内部格式和 DORA YAML 之间转换
• 通过 HTTP 调用 LocalAgent
• 通过 WebSocket 接收日志和状态流并刷新 UI

前端本身不会直接拉起 Python/Rust/C++ 节点进程，也不会直接访问本地文件系统原生对话框。浏览器沙箱不适合承担这些职责。

1.2 LocalAgent 才是浏览器和本地系统之间的桥

doramate-localagent 当前是一个基于 Axum + Tokio 的单体服务，所有核心逻辑集中在 main.rs 中。这个文件目前约 3103 行，职责包括：

• 健康检查
• DORA runtime 检测与拉起
• YAML 写入与 dora start 调用
• dora stop 停止数据流
• 文件打开/保存/目录选择
• 节点模板配置读写
• 日志广播与状态流推送

1.3 真正执行仍由 DORA 负责

当前实现里，运行按钮最终走到的是本机命令：

dora start --detach ...

停止按钮最终走到的是：

dora stop ...

所以 DoraMate 当前的价值不是替代 DORA runtime，而是把“编辑、保存、运行、日志查看、节点状态观察”这一整套体验封装成可视化工作台。

---

二、整体架构图：当前代码对应的真实链路

这个架构有两个非常现实的特点：

• 前后端都用 Rust 实现，但分工非常清晰
• 本地执行并不神秘，本质是浏览器编排 + 本地代理调命令

---

三、前端侧的真实职责：不是“运行器”，而是“编排器 + 观察面板”

3.1 DoraMate 内部数据模型和运行时数据模型是两套格式

前端的核心类型定义在 types.rs。

当前有两套关键模型：

• Dataflow: 画布编辑使用的内部格式，保存节点位置、标签、端口等可视化信息
• DoraDataflow: 运行时导出的 DORA 格式，包含真正要交给 DORA 的 nodes

其中最关键的一点，是前端在运行前会把画布信息转换成 YAML，但 DoraMate 自己的布局元数据会放在 __doramate__ 字段中。

这也是为什么 LocalAgent 在运行前会调用 extract_clean_dora_yaml，把 __doramate__ 元数据剥掉，只把 DORA 真正能执行的部分写入运行文件。

3.2 工具栏点击“运行”之后，前端会做什么

运行链路主要写在 lib.rs：

1. 从当前画布读取 Dataflow
2. 调用 converter::dataflow_to_yaml 生成 YAML
3. 读取当前 working_dir
4. 调用 api::run_dataflow
5. 启动成功后记录 process_id
6. 把全部节点状态先标成 Starting
7. 建立状态流 WebSocket
8. 启动 HTTP 状态轮询兜底
9. 打开日志面板
10. 启动本地运行时长计时器

这是一条相当完整的 UI 状态链，而不是简单发一个 POST 请求就结束。

3.3 前端同时用了“状态流 + 轮询”两套机制

这点很值得注意。

当前前端不是只依赖 WebSocket，也不是只依赖轮询，而是两者并用：

• StatusWebSocket 连接 /api/status-stream/:process_id
• 同时每 2 秒 调用一次 /api/status/:process_id

这样做的意义很现实：

• WebSocket 负责低延迟状态更新
• HTTP 轮询负责在 WebSocket 断开、丢包或状态流异常时兜底

这不是“最优雅”的设计，但对一个本地代理场景来说非常务实，尤其适合当前 MVP 阶段。

3.4 顶部状态栏展示的是运行时观察结果，不是乐观 UI

status_panel.rs 展示的数据包括：

• 是否运行中
• 运行时长
• 当前 process_id
• 工作目录
• 总节点数 / 运行节点数
• 错误节点数

也就是说，状态面板不是只显示“刚刚点过运行按钮”，而是尽量展示 LocalAgent 反馈回来的运行事实。

3.5 日志面板不是简单文本框，而是一个带过滤器的实时控制台

log_panel.rs 目前已经具备：

• WebSocket 连接状态提示
• 最多保留 1000 条前端日志
• 自动滚动开关
• 错误日志角标
• 错误 toast
• 按日志级别过滤
• 按节点 ID 过滤
• 关键字搜索
• 导出日志

从产品角度看，这意味着 DoraMate 当前已经不只是“能跑起来”，而是开始把本地执行的可观测性做成一个真正可用的界面。

---

四、LocalAgent 的实际接口面：不仅仅是 run / stop / health

旧版本文档最大的问题之一，是把 LocalAgent 写成一个只有三个接口的极简服务。实际代码并不是这样。

当前路由定义在 main.rs 顶部，完整接口面如下：

路由	方法	作用
/api/health	GET	检查 LocalAgent 与 DORA runtime 健康状态
/api/run	POST	写入 YAML 并启动数据流
/api/stop	POST	停止指定或全部数据流
/api/select-directory	POST	打开原生目录选择器
/api/open-dataflow-file	POST	打开原生文件选择器并读取 YAML
/api/read-dataflow-file	POST	按路径读取 YAML 文件
/api/save-dataflow-file	POST	打开原生保存对话框并写入 YAML
/api/write-dataflow-file	POST	按路径写入 YAML 文件
/api/node-templates-config	GET/POST	读取与保存节点模板配置
/api/status/:process_id	GET	查询数据流状态快照
/api/status-stream/:process_id	GET + WS	推送状态流
/api/logs/:process_id	GET + WS	推送日志流

这说明当前 LocalAgent 的角色已经不是“运行代理”，而是：

DoraMate 的本地系统接入层。

它把浏览器没法直接做的事情，统一收束到了 localhost API 中。

---

五、运行态核心：AppState、DoraProcess 与进程注册表

5.1 当前状态存储非常直接

LocalAgent 的应用状态是：

• AppState
• processes: Arc<Mutex<HashMap<String, DoraProcess>>>

这说明当前设计仍然是典型的内存态进程表，没有引入数据库，也没有引入外部状态服务。

5.2 每个数据流的记录内容

DoraProcess 当前保存了这些关键信息：

• yaml_path
• started_at
• dataflow_uuid
• log_tx
• log_backlog

这几个字段足够支撑当前的四类能力：

1. 停止时根据 dataflow_uuid 调用 dora stop
2. 状态查询时根据 yaml_path 反推出节点列表
3. 状态栏根据 started_at 计算运行时长
4. 日志面板通过 log_tx 与 log_backlog 建立实时 + 回放机制

5.3 当前实现没有复杂调度器，只有清晰的局部状态

这也是实际代码的一个特点：

• 没有 actor 系统
• 没有任务编排器
• 没有作业队列
• 没有持久化恢复

但它已经足以覆盖本项目当前需求，因为 DoraMate 目前本质上仍是“单机本地工作流启动器”。

---

六、/api/health：不只是检测服务活着，还顺带探测 DORA runtime

6.1 健康检查返回的信息比前端实际消费的更多

LocalAgent 的 HealthResponse 当前包括：

• status
• version
• dora_installed
• dora_coordinator_running
• dora_daemon_running

也就是说，后端已经可以区分：

• 是否安装了 dora
• coordinator 是否活着
• daemon 是否活着

6.2 但前端目前只反序列化了部分字段

api.rs 中的前端 HealthResponse 只包含：

• status
• version
• dora_installed

这说明当前前后端在健康检查字段上存在一个“后端更丰富、前端尚未完全消费”的状态。

这不是 bug 级别问题，但很值得在架构文档里明确写出，因为它说明：

后端已经开始承担 runtime 诊断角色，而前端的诊断 UI 还没有完全跟上。

6.3 DORA runtime 探测用了端口和命令双重策略

当前 LocalAgent 定义了三个关键端口：

• DORA_COORDINATOR_PORT = 54500
• DORA_CONTROL_PORT = 6012
• DORA_DAEMON_LOCAL_PORT = 54501

运行态检测方式包括：

• 尝试连接本地端口
• dora list
• 在非 Windows 上用 pgrep

这说明它不是只相信单一信号，而是做了较为实用的本地探测。

---

七、/api/run：从可视化 YAML 到 dora start 的完整路径

这是整套本地执行架构最关键的部分。

7.1 输入不是文件路径，而是 YAML 文本

前端提交给 LocalAgent 的请求是：

{
  "dataflow_yaml": "...",
  "working_dir": "..."
}

也就是说，浏览器并不会先把文件落盘后再告诉 LocalAgent 去执行，而是直接把 YAML 文本传过去，再由 LocalAgent 决定如何写入本地文件。

这个边界划分很合理：

• 前端专注于“生成内容”
• LocalAgent 专注于“管理本地文件与进程”

7.2 LocalAgent 会先清洗 YAML 元数据

如果 YAML 中存在 __doramate__ 元字段，LocalAgent 会调用 extract_clean_dora_yaml 去掉它。

这一步非常关键，因为 DoraMate 的布局元数据对运行时是有价值但不可执行的；运行时只需要纯净的 DORA YAML。

7.3 运行文件写到工作目录，不写到全局 temp

当前实现会把运行文件写成：

<working_dir>/doramate_<process_id>.yml

如果前端没有显式设置工作目录，LocalAgent 会退回到当前进程 current_dir()。

这比早期很多 Demo 常见的“直接写系统临时目录”更符合工程化预期，因为：

• 相对路径节点更容易工作
• 调试时更容易定位运行文件
• 与用户当前项目目录更一致

7.4 真正启动前会先确保 runtime 就绪

run_dataflow 在执行 dora start 之前，会先调用：

ensure_dora_runtime_ready().await

它会检查：

• coordinator 是否运行
• daemon 是否运行

如果缺失，则尝试自动启动：

• start_dora_coordinator()
• start_dora_daemon()

这意味着当前 DoraMate 已经不是“假定用户手工把 runtime 都准备好”，而是开始主动补齐运行环境。

7.5 dora start 已经做了超时、诊断和有限重试

当前版本的重要常量如下：

• DORA_START_TIMEOUT_SECS = 20
• DORA_START_MAX_ATTEMPTS = 2
• DORA_START_RETRY_DELAY_MS = 800

运行策略是：

1. 启动一次 dora start
2. 20 秒内等待结果
3. 如果是明显永久错误，比如 YAML 无效、未知节点、文件不存在，则不重试
4. 如果更像瞬时错误，比如 runtime 未就绪、连接拒绝、超时、无输出，则最多再重试一次

这套逻辑的价值在于：它已经从“直接把错误甩给用户”升级到“帮用户吸收一部分可恢复抖动”。

7.6 运行成功后会解析 dataflow UUID

LocalAgent 不只是知道自己生成了一个 process_id，还会尝试从 dora start 的输出中解析真正的 dataflow_uuid。

这两个 ID 的职责不同：

• process_id: DoraMate 前后端内部追踪用
• dataflow_uuid: 调用 dora stop 时与 DORA runtime 对接用

7.7 启动日志会被立即注入日志流

dora start 返回的 stdout 和 stderr 不会被浪费掉，而是会在启动成功时直接通过 publish_log 写入：

• 广播通道
• backlog 缓冲

这样一来，用户即使晚一点才打开日志面板，也能看到启动阶段日志，而不是只看到启动后的新消息。

---

八、/api/stop：不仅停 DORA，还尝试清理残留节点进程

8.1 停止逻辑支持“指定一个”或“停全部”

StopDataflowRequest 的后端定义是：

• process_id: Option<String>

这意味着后端本身支持两种模式：

• 传入 process_id，只停一个
• 不传，停所有已注册数据流

当前前端实际使用的是第一种，也就是停止当前正在运行的那个流程。

8.2 优先按 dataflow_uuid 调用 dora stop

如果 LocalAgent 在启动阶段成功解析出了 dataflow_uuid，停止时会优先走：

dora stop <uuid>

如果没有 UUID，则退化为：

dora stop --all

这是一种合理的降级策略。

8.3 停止之后还会做残留进程清理

当前实现里，stop_dataflow 在 DORA 层停止成功后，还会调用：

cleanup_stale_node_processes(&yaml_path)

它会根据 YAML 中每个节点的 path 和 id 推断可能的进程名，再在不同平台上尝试清理：

• Windows: tasklist + taskkill
• Unix: pgrep + pkill

这很重要，因为现实中的本地节点并不总是能随着控制平面优雅退出。

8.4 当前 stop API 的语义比较“宽松”

当前实现即便出现部分停止失败，也仍然返回：

• success: true
• message: Stopped X dataflow(s) with Y errors
• error_code: STOP_PARTIAL_FAILURE

这说明它的语义更接近“操作已执行，但伴随告警”，而不是严格意义上的全成功 / 全失败二值模型。

这对 UI 来说是可用的，但后续如果要做更精细的运行面板，可能还需要把失败明细继续结构化。

---

九、状态监控：当前不是读 DORA 内部状态表，而是“YAML 反推 + 本机进程探测”

这是当前架构里最值得如实说明的一点。

9.1 GET /api/status/:process_id 返回的是推断后的状态快照

当前状态接口返回：

• process_id
• status
• uptime_seconds
• total_nodes
• running_nodes
• error_nodes
• node_details

表面上看，这像是一个完备的运行状态接口；但它背后并不是直接读 DORA 的官方状态 API，而是本地推断。

9.2 推断过程分三步

第一步，读取运行 YAML。

第二步，解析出其中的 nodes 列表。

第三步，根据节点 path 或推断出的 node_type 在操作系统里查找对应进程：

• Windows 走 Get-Process
• Unix 走 pgrep

最后统计出：

• 总节点数
• 运行中节点数
• 未运行节点数

9.3 当前节点类型识别是启发式的

例如：

• 包含 opencv 或 camera 的路径，会被识别成 opencv-video-capture
• 包含 yolo 的路径，会被识别成 dora-yolo
• 包含 rerun 或 plot 的路径，会被识别成 dora-rerun

否则就退化为路径末尾文件名。

这类规则非常适合当前阶段，但它的定位必须写清楚：

这是实用启发式监控，不是精确的 runtime telemetry。

9.4 WebSocket 状态流每 800ms 推送一次

/api/status-stream/:process_id 的实现是一个固定间隔推送器：

• 周期：800ms
• 推送内容：一次完整的 DataflowStatusResponse
• 当状态变成 stopped 或 not_found 时自动结束

对前端来说，这已经足够驱动：

• 节点颜色变化
• 顶部状态条
• 运行数字变化

---

十、日志系统：广播通道 + backlog 回放，而不是简单 print

10.1 每个数据流都有自己的日志广播器

DoraProcess 当前持有：

• broadcast::Sender<LogEntry>
• VecDeque<LogEntry> backlog

所以日志不是全局共享一个大管道，而是按数据流隔离。

10.2 backlog 限制为 1000 条

当前常量：

const LOG_BACKLOG_LIMIT: usize = 1000;

当新日志写入时，会：

1. 先进入 backlog
2. 超限则弹出最旧消息
3. 再广播给所有订阅者

这让日志系统具备了典型的“近期回放”能力。

10.3 新连接会先收到历史，再收到实时

当前 /api/logs/:process_id 的 WebSocket 建立后，会依次发送：

1. 一条 “Log stream connected” 系统消息
2. 当前 backlog 快照
3. 后续实时广播日志

这也是为什么前端日志面板可以做到“打开即有上下文”。

10.4 LocalAgent 还在尝试从日志中提取 node_id

LogEntry 结构里有一个可选字段：

• node_id

后端会用一系列启发式规则从日志文本中识别可能的节点 ID，比如：

• node_id=...
• node: ...
• [node_xxx]

这使得前端日志面板可以做“按节点过滤”，是一个很实用的小设计。

---

十一、文件系统接入：为什么这些能力必须由 LocalAgent 提供

如果只看运行功能，很多人会误以为 LocalAgent 的存在只是为了调用 dora start。实际上不是。

当前项目里，LocalAgent 还承担了浏览器无法原生完成的文件系统能力。

11.1 原生目录选择

/api/select-directory 使用 rfd::FileDialog::pick_folder() 打开系统目录选择器。

前端在设置工作目录时会先尝试调这个接口；如果用户取消或失败，再回退到手工输入。

这就是现在 UI 中“浏览…”按钮背后的真实实现。

11.2 打开 YAML 文件

/api/open-dataflow-file 会：

1. 打开系统文件选择器
2. 限定 yml / yaml
3. 读取文件内容
4. 同时返回 file_path、file_name、working_dir

前端据此更新当前项目上下文、最近文件和画布内容。

11.3 保存 YAML 文件

当前有两种写文件方式：

• /api/save-dataflow-file: 用原生保存对话框决定路径
• /api/write-dataflow-file: 前端已知路径，直接写入

这两条能力配合使用，正好覆盖“另存为”和“直接保存”。

11.4 所有阻塞式文件对话框都被包进 spawn_blocking

这一点很工程化。

无论是：

• 目录选择
• 文件打开
• 文件保存

LocalAgent 都用 tokio::task::spawn_blocking 包裹同步系统调用，避免把 Tokio runtime 主线程卡死。

---

十二、节点模板配置：LocalAgent 现在已经承担一部分本地持久化职责

除了运行和文件读写，当前 LocalAgent 还有一个容易被忽略但很重要的职责：节点模板配置落盘。

12.1 配置文件不是存在项目目录，而是存在用户配置目录

LocalAgent 会解析系统配置路径：

• Windows 优先 %APPDATA%\DoraMate\node_templates.yml
• 否则退回 %USERPROFILE%\AppData\Roaming\DoraMate\node_templates.yml
• Unix 优先 $XDG_CONFIG_HOME/doramate/node_templates.yml
• 否则退回 ~/.config/doramate/node_templates.yml

12.2 保存前会做标准化和去重

后端会清洗每条模板记录：

• 去掉空白
• 空图标补默认值 🔧
• 空名称回填为 node_type
• 输入输出端口做大小写去重
• 相同 node_type 的模板以后者为准

这说明当前 LocalAgent 已经开始承担“配置裁判”的角色，而不是纯粹当文件仓库。

12.3 前端模板来源其实是三路合并

前端当前模板体系并不只有一种来源，而是三层叠加：

1. 内置模板
2. 浏览器 LocalStorage 中的用户模板
3. LocalAgent 配置文件中的持久化模板

所以从系统设计角度看，DoraMate 当前已经有了“浏览器本地状态 + 本机持久配置”双层本地存储结构。

---

十三、前后端协作的真实时序

如果把一次“打开项目并运行数据流”的全过程串起来，大致如下：

13.1 打开文件阶段

1. 前端点击“打开”
2. 调用 /api/open-dataflow-file
3. LocalAgent 打开系统文件选择器
4. 读取 YAML 并返回内容、路径、工作目录
5. 前端把 YAML 反解成画布内部格式
6. 最近文件列表与当前工作目录同步更新

13.2 运行阶段

1. 前端将当前 Dataflow 转成 DoraMate YAML
2. 调用 /api/run
3. LocalAgent 剥离 __doramate__
4. 将纯运行 YAML 写入工作目录
5. 检查 dora 是否安装
6. 检查或拉起 coordinator / daemon
7. 调用 dora start
8. 记录 process_id、dataflow_uuid、日志通道、启动时间
9. 前端收到成功响应后建立日志与状态连接

13.3 运行观察阶段

1. 状态 WebSocket 每 800ms 推送一次
2. 前端每 2 秒额外轮询一次 /api/status/:process_id
3. 日志 WebSocket 持续推送 stdout / stderr / system 日志
4. 状态面板和节点视觉状态持续刷新

13.4 停止阶段

1. 前端调用 /api/stop
2. LocalAgent 按 UUID 调 dora stop
3. 尝试清理残留节点进程
4. 从 processes 注册表移除对应流程
5. 前端收到结果后清空运行态 UI

---

十四、当前实现的工程价值

基于当前仓库状态，DoraMate 的本地执行架构已经有三个很明确的优点。

14.1 浏览器和系统边界被处理得很清楚

浏览器负责：

• 可视化交互
• 数据模型维护
• 运行状态展示

LocalAgent 负责：

• 文件系统
• 原生对话框
• 进程与命令
• WebSocket 转发

这是一个非常健康的职责切分。

14.2 运行链路已经具备基本韧性

当前不是“拿到 YAML 就盲目跑”，而是已经有：

• runtime 自动拉起
• dora start 超时控制
• 可恢复错误重试
• 启动输出摘要
• 端口快照诊断
• 停止后的残留进程清理

对于本地代理来说，这已经超出了 Demo 水平。

14.3 可观测性做到了产品级可用

当前系统至少已经有：

• 实时状态流
• 实时日志流
• 历史日志回放
• 节点级过滤
• 错误码映射为用户友好提示

这让“本地执行”不再只是黑盒。

---

十五、当前架构的真实约束与后续演进点

既然这篇文章强调“按真实代码说话”，那就不能只讲优点。

15.1 LocalAgent 仍然是单文件单体实现

当前所有核心能力都压在 main.rs 中。

这在 MVP 阶段是高效的，但继续演进时会带来问题：

• 路由、运行时管理、文件操作、模板配置、测试耦合在一起
• 维护成本会越来越高
• 单元测试边界不够清晰

下一阶段很自然的方向，是拆成：

• runtime
• files
• templates
• ws
• status

几个模块。

15.2 节点状态监控还是启发式，不是官方 runtime telemetry

当前 status 的精度受限于：

• YAML 解析是否完整
• 路径命名是否规范
• 本机进程名是否可预测

如果未来要做工业级监控，最好直接接入 DORA 的正式运行状态接口，而不是继续依赖进程名猜测。

15.3 健康检查信息前后端还没完全打通

后端已经能提供：

• coordinator 状态
• daemon 状态

但前端还没有把这些信息做进 UI。后续可以补一个真正的“本地环境诊断卡片”。

15.4 CORS 目前是全放开，但监听地址仍只限 localhost

当前服务绑定：

127.0.0.1:52100

并使用：

allow_origin(Any)
allow_methods(Any)
allow_headers(Any)

这在 localhost 工具场景下可接受，但文档必须明确一件事：

当前安全前提是“服务不暴露到公网”。

如果未来要跨机器访问，本层一定要补鉴权，不然风险会非常直接。

15.5 代码里已经暴露出一些“实现优先于抽象”的痕迹

例如：

• 前后端对 health 返回字段并不完全对齐
• 停止接口的成功语义偏宽松
• 运行和停止的 CLI 参数语义后续值得继续核对

这些都不是否定当前方案，而是说明当前系统已经进入“可用之后需要收敛边界”的阶段。

---

十六、测试覆盖说明：当前实现不是裸奔

doramate-localagent 当前在 main.rs 中已经包含较多测试用例，按当前代码统计约 28 个 #[test] / #[tokio::test]，覆盖方向包括：

• dora start 输出解析
• 可重试 / 不可重试错误判断
• 运行错误码分支
• 停止错误码分支
• 文件读写错误处理
• 节点模板配置标准化
• 状态接口在空流程与缺失 YAML 场景下的行为

这说明 LocalAgent 当前虽然仍是单文件实现，但至少在关键分支上已经开始有系统性保护。

---

十七、总结：DoraMate 当前的本地执行架构已经跑通了哪一层

如果回到本文一开始的问题：“DoraMate 现在的本地执行架构到底是什么？”

最准确的回答是：

它已经不是一个停留在 PPT 层的概念，而是一套真实运行的“浏览器编排 + 本地代理桥接 + DORA runtime 执行”的单机架构。

截至当前代码，DoraMate 已经跑通了这几层能力：

1. 可视化编辑器生成运行 YAML
2. LocalAgent 管理工作目录、文件与模板配置
3. LocalAgent 自动探测并补齐 DORA runtime
4. LocalAgent 执行 dora start / dora stop
5. 前端实时消费运行状态和日志流
6. UI 将本地执行过程转化为可观察、可调试、可停止的交互体验

当然，它还没有到“工业级平台最终形态”：

• 状态监控仍有启发式成分
• 后端尚未模块化
• 本地环境诊断 UI 还可以继续做深

但它已经足够说明一件事：

DoraMate 的本地执行能力不是停留在设想里，而是已经在当前仓库中形成了完整闭环。

---

十八、下一步

📖 第十五章: 工业级 UI 组件库设计详解 - Leptos 高性能可复用组件架构
📖 第十六章: 系统迁移规划详解 - 基于现有资产的 Rust 全栈复用路线与实施策略

---

源起之道支持｜Supported by Upstream Labs
日期: 2025-03-20
系列: DoraMate 项目技术博客系列

上一篇: 13- 验收标准详解 - 当前版本应该如何定义“可交付”