Coding Agent 通过 MCP 接入 Keil：可编译、烧录与调试

在嵌入式开发里，让 AI 写几段驱动代码并不难，难的是把代码真正编译进工程、烧进板子，再从寄存器里确认它跑起来了。电子工程专辑近日介绍了一个名为 dsh-keil-mcp 的社区项目，试图用 MCP 把本机 Keil 环境接进 Coding Agent 的会话，让编译、烧录和调试不再完全依赖工程师手动切换窗口。

按照文章的描述，dsh-keil-mcp 是一台跑在开发者本机的 MCP Server，而不是云端服务。它把已经安装好的 UV4.exe、*.uvprojx 工程文件，以及 ST-Link、J-Link、CMSIS-DAP 这类调试探针封装成 Agent 可以调用的工具，仓库 README 宣称提供约 27 个工具，覆盖工程发现、编译、错误解析、源码修改、烧录和探针调试。

项目作者特别说明，它既不是 ARM 或 Keil 的官方插件，也不是能替代 Keil Debug 窗口的成熟 IDE。工具采用 MIT 开源协议，版本仍处于 Alpha 0.1.0，GitHub 仓库由 ZMC1011 维护，创建时间是 2026 年 8 月，Star 数量还很少，定位更接近一块早期社区拼图。

它规划的典型闭环是：先运行 doctor 检查环境，再发现工程、配置 Target、执行编译；如果编译失败，就把日志拆成文件、行号、错误码和消息，并尝试解释常见的 armcc、armclang 报错；需要改代码时，source_edit 会先把原文件备份到工程旁的 .keil-mcp-backups/ 目录，再按行范围替换。

烧录和擦除被当作破坏性操作处理。flash_firmware 与 erase_flash 都要求显式确认，烧录优先调用 UV4 的 -f 参数使用工程内配置的算法，失败后再回退到 pyocd load，并用 verify_flash 校验镜像；探针侧则提供连接、暂停、单步、断点、读取寄存器和 RTT 日志等工具，还通过租约机制尽量避免 UV4 与 pyOCD 抢占同一个调试口。

接入条件并不轻松：需要 Windows、本机已装好 Keil MDK、Python 3.10 以上，以及能被 Keil 识别的开发板和下载器驱动。当前包还没有发布到 PyPI，实际安装要从 GitHub 克隆源码并做 editable 安装，然后在 Cursor、Claude Desktop 等客户端里配置 stdio 形式的 mcpServers JSON，指定 UV4.exe 和工程目录的绝对路径。

文章花了不少篇幅提醒权限边界。作者建议先只开放编译和错误解析，跑一段时间后再考虑源码修改；烧录只应在非关键板卡上、保持每次确认并留好可回滚镜像的前提下开放；量产板或客户板则默认不给 Coding Agent 烧录权限。工具本身也做了只读并发、变更串行和探针租约等防护，但这些设计不能替代工程师对芯片、Target 和镜像的确认。

从更大的视角看，这类项目的意义不在于让 Agent 一键接管硬件，而在于把 Coding Agent 的边界从“生成代码”推进到“调用真实工具链”。嵌入式工具链长期绑定 Windows 桌面软件和厂商探针，接入难度远高于 Web 开发；dsh-keil-mcp 只是一个 Alpha 阶段的尝试，但它指出了一个明确方向：未来的 Coding Agent 需要理解编译产物、烧录流程和板上反馈，而不只是文本补全。接下来值得观察的是 PyPI 发布、更多 MCU 与探针的适配，以及团队是否愿意为这类高权限工具建立白名单和审计机制。