嵌入式软件开发正在Agent化

不管你过去多么不相信AI，还是依然坚持“手搓代码”，有一点已经不得不承认：AI正在实实在在地改变软件开发。

于是，一个问题也被越来越频繁地提起：嵌入式工程师会不会被AI替代？答案或许并不复杂。AI不会轻易取代嵌入式工程师，但一定会改变工程师的工作方式。

这种变化已经开始发生。越来越多厂商给IDE中塞进AI Agent，这些Agent不只是帮你“写代码”，也不光是一个“聊天框”，给你搜搜Datasheet，而是开始参与完整的软件开发和验证流程。

可以说，一个翻天覆地的变化，正在IDE中发生。而我们必须知道当下发生的变化。

Microchip采用的是“通用AI能力+Microchip知识”的思路。Microchip在今年2月推出MPLAB AI编码助手（Coding Assistant），这款免费工具作为VS Code的扩展，基于开源AI代码助手Continue开发，并预配置了Microchip的AI聊天机器人，以提供实时支持。

2026年5月发布的官方教程显示，MPLAB AI编码助手已经被纳入MPLAB Extension Pack，开发者可以在VS Code中安装使用。

TI的思路则完全不同，选择CCStudio+主流AI Agent。TI最新的CCStudio已经开始正式支持AI Coding工具。

TI官方文档显示，CCStudio IDE目前正式支持Anthropic的Claude Code和OpenAI的Codex，并通过AI Assistant Configurator进行配置。同时，CCStudio还可以安装其他基于VS Code的第三方AI Coding扩展。

提到TI，就不得不提到Silicon Labs，毕竟年初时TI官宣即将75亿美元收购Silicon Labs。

Silicon Labs的动作甚至比“AI Coding”更激进更有野心。Silicon Labs正在推进Simplicity AI SDK，官方描述中，它并不是单纯的AI代码补全工具，而是希望提供“AI-augmented development experience”，覆盖整个IoT开发生命周期。

Renesas路线更加有意思，已经在e² studio中提供AI Navigator。

官方资料显示，AI Navigator是一组面向e² studio的插件，用于集成AI嵌入式系统开发所需要的功能，以缩短开发周期。AI Navigator可以在e² studio中帮助开发者完成AI模型训练、转换，再进入应用构建和部署流程。

ST目前并没有简单地把一个通用聊天机器人塞进STM32 CubeIDE，而是把AI能力拆成不同工具。2026年2月，ST正式推出STM32Cube AI Studio，用于STM32上的AI模型优化、验证和部署。

而后，ST又推出了STM32 Sidekick，STM32 Sidekick更接近大家理解的AI助手。它可以基于ST官方文档回答STM32相关问题，包括芯片选型、外设工作方式、CubeIDE问题以及应用笔记查询等。ST官方称，其知识来源覆盖STM32产品、开发者专区、支持页面和社区。

乐鑫对于AI Agent的态度一直也很积极，继去年推出乐鑫智能文档AI助手后，今年4月正式发布文档MCP (Model Context Protocol, 模型上下文协议) 服务器，进一步打通官方文档与 AI 开发工具之间的连接能力。

MCP是一项开放标准，旨在让 AI Agent（智能体）能够在运行时直接连接外部数据源，而不再局限于训练阶段所获取到的知识。乐鑫文档 MCP 服务器基于这一标准，将乐鑫官方文档库接入Cursor、VS Code、Claude Code 等集成开发环境 (IDE) 或编码工具，使 AI 能够在实际开发过程中调用权威信息源，提供更准确、可追溯的技术支持。

除此之外，乐鑫的思路发散到了硬件上，在8月19日推出了一款为 Coding Agent（代码智能体）设计的模块化开发板ESP-Mosaico，在Chat Coding模式下，开发者只需通过自然语言描述需求就能完成构建和部署，而在Vibe Coding模式下，AI Agent进一步接入开发、部署和真机验证。

Infineon的动作同样值得关注。2026年5月，Infineon发布ModusToolbox for VS Code扩展，将完整的ModusToolbox嵌入式开发流程带入VS Code。

而目前，在VS Code中，也存在Infineon ModusToolbox AI Assistant这样一个正在预览中的插件，它让GitHub Copilot（以及其他AI助手如Cursor和Windsurf）深入理解ModusToolbox工作区——具体的 MCU、BSP、可用库和外设配置——让你获得相关且可编译的代码，而非泛泛的建议。

从VS Code官网中，EEWorld也查询到ADI的CodeFusion Studio也在预览内测AI调试助手，由模型上下文协议（MCP）驱动，支持GitHub Copilot、Claude Code及其他兼容MCP的AI客户端。

NXP没有直接推出自己的AI Coding Agent，目前的MCUXpresso仍然是围绕SDK、IDE、配置和开发板构建开发生态。不过MCUXpresso也拥有VS Code扩展，可以利用Copilot辅助开发。

Nordic在今年5月推出了一个新的AI辅助开发框架，Nordic通过模型上下文协议（MCP）实现实现这一目标。Nordic MCP服务器为你的AI助手提供了可靠且经过验证的来源，获取真正的北欧语境：SDK文档、API参考、设备配置以及来自nRF云的现场数据。

MIKROE是AI Coding IDE的代表，早在2025年就已经在NECTO中加入AI Code Assistant，用于帮助开发者生成代码。据介绍，NECTO Code Assistant，并不只是一个普通的代码生成工具。它能够结合具体的MCU、Click开发板、传感器模块和显示屏等硬件配置，生成对应的初始化、驱动和应用代码，帮助开发者快速完成多硬件协同开发。

就在刚刚的8月12日，MIKROE宣布其多架构NECTO Studio IDE，现已支持来自12家不同芯片厂商的10000余款MCU。

QT在今年6月正式发布Qt Creator 20，加入了Agent Client Protocol（ACP）支持，可以把Claude Code、Codex、Gemini CLI、GitHub Copilot等AI Coding Agent接进IDE。

在今年Embedded World 2026上，Tasking现场展示了AI Agent通过MCP服务器调用LDRA工具，对代码进行分析、生成测试并根据分析结果修改代码。开发者不需要离开IDE，AI可以在后台调用开发工具，同时保留静态分析、测试和合规结果。

工程师们对AI Coding在嵌入式开发中的价值存在明显分歧。多数人认为，AI确实能够提升效率，尤其适合生成初始化代码、驱动模板和一些明确的小功能，例如配置定时器、生成SPWM等。但与通用软件开发不同，嵌入式代码高度依赖具体MCU、寄存器、外设和硬件环境，AI生成的代码可能存在寄存器配置错误、混淆不同芯片资料等问题，因此不能直接用于生产环境。

有工程师认为，AI Coding真正的瓶颈不只是“会不会写代码”，而是能否理解具体硬件，并对生成结果进行自动验证。理想的嵌入式AI开发流程应该是：AI生成代码→调用真实编译器编译→发现错误并修改→在仿真环境中运行→检查外设行为→反复迭代验证。只有把AI的生成能力与传统编译、仿真、测试工具结合起来，才能真正提高代码可靠性。

此外，工程师还提出了一个更值得关注的方向：未来的嵌入式AI IDE不应该只是一个“AI聊天框”，而应该能够同时理解数据手册、应用笔记、原理图、Gerber、寄存器映射和项目代码，在完整硬件上下文中生成驱动、应用层和网络协议代码，并回答具体的硬件设计和软件开发问题。

不过，也有工程师提醒，AI最大的风险在于“看起来很正确”。如果开发者缺乏足够的硬件和软件基础，就很难判断AI输出是否可靠。对于嵌入式系统而言，AI可以成为工程师的高效助手，但目前还不能替代工程师进行系统设计和最终验证。

知名嵌入式工程师Jacob也认为，AI可以帮助工程师更快开发高质量固件，但最终的软件质量和安全责任仍然在人，尤其是在汽车等安全关键领域，AI生成代码之后，人工审核、测试和验证仍不可替代。目前嵌入式AI Coding竞争重点已经从“AI能不能写代码”，转向“AI能不能调用整个开发工具链”。未来的IDE可能不再只是集成一个聊天机器人，而是让AI Agent能够直接调用编译器、静态分析、测试、仿真、代码检查等工具，形成一个完整的Agentic开发闭环。