MCU Agentd
MCU Agentd 是可配置 MCU 管理工具，包含每项目 daemon/CLI mcu-agentd 和用户级辅助 daemon mcu-managerd。README.md 明确它通过 mcu-agentd.toml 定义多个 MCU target，并基于 espflash 与 probe-rs 执行操作，当前 v1 只支持 ELF artifact 和固定策略。
- Ops tool
- Rust web service
- Embedded admin UI
- React app
- Service ports
- Storybook component QA
- Config-driven ops
- MCU flashing integration
- Embedded USB control plane
目录
技术栈
运行与交付
- CI 工作流
- ci.yml
- 能力标记
- cargo_toml
- github_actions
配置与质量
- 配置文件
- .gitignore
- Cargo.toml
其他信息
- Cargo
- 开发依赖
- http-body-util
- tempfile
- tower
- Deps main
- axum
- clap
- ctrlc
- espflash
{
"cargo": {
"deps_dev": [
"http-body-util",
"tempfile",
"tower"
],
"deps_main": [
"axum",
"clap",
"ctrlc",
"espflash",
"fs2",
"include_dir",
"inquire",
"libc",
"semver",
"serde",
"serde_json",
"serialport",
"thiserror",
"time",
"tokio",
"tokio-stream",
"toml",
"which"
]
},
"ci_workflows": [
"ci.yml"
],
"configs_root": [
".gitignore",
"Cargo.toml"
],
"markers_present": [
"cargo_toml",
"github_actions"
]
}Purpose
MCU Agentd 是可配置 MCU 管理工具，包含每项目 daemon/CLI mcu-agentd 和用户级辅助 daemon mcu-managerd。README.md 明确它通过 mcu-agentd.toml 定义多个 MCU target，并基于 espflash 与 probe-rs 执行操作，当前 v1 只支持 ELF artifact 和固定策略。
Taxonomy
- Tags: Ops tool, Rust web service, Embedded admin UI, React app, Service ports, Storybook component QA, Config-driven ops, MCU flashing integration, Embedded USB control plane
- Why / evidence: 这些 tags 来自 checked-out repo 和 catalog record。主要证据包括
README.md、Cargo.toml、src/、tests/、web/package.json、web/.storybook/main.ts、web/scripts/test-storybook.ts、web/scripts/test-storybook-ci.ts。Topic token 的大小写以对应技术/工作流的官方写法为准；slug 只作为稳定 ID，不直接充当项目标题。
Repository map
Cargo.toml是 Rust daemon/CLI manifest，依赖espflash、serialport、probe-rs相关调用、Axum、Tokio、TOML。src/保存 daemon、CLI、registry、monitor lifecycle 和 HTTP API。web/是 React 管理 UI，web/.storybook和web/scripts/test-storybook*.ts提供 component QA。docs/保存 design/plan 记录，tests/覆盖服务行为。
Runtime and delivery
运行模型是 per-project agent + user-level manager。项目通过 mcu-agentd.toml 声明 MCU、backend、chip、artifact_elf、selector cache 和 backend-specific 参数。Web UI/HTTP API 服务于跨项目资源仲裁、日志、monitor 生命周期和升级协调。
Architecture notes
关键抽象是 config-driven MCU target：上层命令不透传底层任意参数，而是根据固定配置执行 flash/monitor/log。这样能把安全边界留在配置和策略里，避免每个项目脚本随意拼接 espflash/probe-rs 命令。
Workflow and quality gates
.github/workflows/ci.yml 是当前 CI 入口。Web 子项目有 build-storybook、test-storybook、test-storybook:ci；因为 .storybook/main.ts 没有 accessibility addon，Topic 应是 Storybook component QA。
Reusable decisions
- 用
mcu-agentd.toml作为跨项目硬件操作 contract，减少一次性脚本。 - 限制底层参数透传，优先固定策略，适合多 Agent 操作真实硬件。
- 把 manager UI 与 daemon 放在同仓库，方便协议同步。
Risks and open questions
- 真实硬件操作有副作用，自动化 Agent 必须尊重配置和串口选择。
- espflash/probe-rs 版本变化会影响 flashing/monitor 行为。
- Storybook 只能证明 UI states，不能证明硬件操作安全。
Evidence index
README.mdCargo.tomlsrc/tests/web/package.jsonweb/.storybook/main.tsweb/scripts/test-storybook.tsweb/scripts/test-storybook-ci.tsdocs/.github/workflows/ci.yml
相关内容
Config-driven ops
主题Config-driven ops 表示操作命令、硬件目标、端口、artifact、backend 或运行策略优先通过 checked-in 配置声明，而不是让维护者每次手写临时命令。它适合 MCU flashing、服务端口、部署资源和多 Agent 协作场景。
Embedded admin UI
主题Embedded admin UI 表示 operator/admin UI 不是独立部署的前端产品，而是主服务交付物的一部分，通常由同一个 release binary、同一个镜像或同一个部署单元一起提供。这里的重点是交付和边界耦合，而不是框架选型。 这个 Topic 用来回答“控制台为什么要随服务一起发、一起验、一起部署”。
Embedded Rust
主题Embedded Rust 表示 Rust 代码运行在 MCU、driver、firmware 或硬件 bring-up 环境中，通常涉及 no_std、Embassy、esp-hal、STM32/ESP32、probe-rs、espflash 或 embedded-hal。它不是所有 Rust 项目的泛化标签。
Embedded USB control plane
主题Embedded USB control plane 表示把 MCU 的 USB CDC / USB Serial-JTAG 当成本地设备控制面，而不是普通调试串口。它要求运行态控制协议、设备身份、日志/trace、secret 脱敏、串口 ownership，以及 flash/reset/monitor 等生命周期操作被同一个本地 owner 模型管理。
MCU flashing integration
主题MCU flashing integration 表示项目通过 espflash 管理 ESP32 系列，通过 probe-rs 管理 STM32/其他 probe-supported MCU，并把这些 backend 接入项目配置或明确的本地操作入口。Topic token 使用可复用工程模式命名；espflash 与 probe-rs 作为具体工具名放在定义和证据里。 这个 Topic 关注的是“硬件操作入口可复现且可审计”。
Ops tool
主题Ops tool 表示项目的核心价值在于运维自动化本身：部署、升级、监控、编排、设备管理、触发器或共享工作流，而不是面向终端用户的业务功能。这里的主语是“帮维护者安全地操作系统”，不是“恰好带个管理后台”。 这个 Topic 用来回答一个问题：系统真正的产品是不是一套可复用的操作能力。
React app
主题React app 标记 React 是主要用户界面、管理台、控制台或嵌入式操作面 runtime。这里关心的是 route、component tree、client state、表单流、dashboard 交互和前端构建后的真实运行边界，而不是“项目依赖里有 React”。 这个 Topic 用来回答“用户实际操作的是不是一个 React runtime，以及它在系统里承担什么职责”。
Rust web service
主题Rust web service 表示 Rust binary 承担长期运行的服务职责：提供 HTTP API、proxy、SSE、docs/data service、admin backend 或 ops daemon，并对外暴露稳定的网络、存储和部署边界。这里的关键词不是“Rust”，而是“服务进程”。 这个 Topic 不只是“语言是 Rust”。
Service ports
主题Service ports 表示端口号、bind 地址、dev/prod 暴露方式和多组件端口分工本身就是仓库的稳定 contract。它不是“服务都会有端口”这种空泛事实，而是说端口设计会直接影响本地预览、反向代理、权限边界、自动化脚本和故障排查。 这个 Topic 关注的是端口作为系统边界的那一面。
Storybook component QA
主题Storybook component QA 表示仓库把 Storybook 当作组件级文档、状态枚举、视觉检查或 interaction smoke 的稳定入口。它不等同于 Storybook accessibility：只有项目明确引入 a11y addon 或等价 Axe sweep 时，才同时打 accessibility Topic。这个拆分用于避免“只要有 Storybook 就叫 a11y”的误判。