Agent 做嵌入式，核心还是把硬件开发接成 API

Wed, 20 May 2026 00:00:00 +0000

Agent 做嵌入式，核心还是把硬件开发接成 API

最近折腾嵌入式工具链，我越来越确定一件事：agent 想真正参与嵌入式开发，光会写几行 C 代码没用。硬件开发里那些原本靠人手操作、靠 IDE 点按钮、靠经验猜的动作，得先变成它能调用的接口。

说白了，要给 agent 一套清楚的 API。

这里的 API 不一定是传统软件接口。构建、烧录、调试、寄存器读写、日志抓取，这些命令本身就可以是接口。只要它们稳定、可复现、能组合，agent 就能接进来。

我现在看工具链，最看重这一点：硬件开发必须先 CLI 化，然后才谈得上 agent 化。

把硬件能力暴露出来

传统嵌入式开发把很多能力藏起来了。

烧录藏在 IDE 的按钮后面，调试藏在某个工程配置里，芯片连接状态藏在调试器窗口里，寄存器值藏在图形界面的某个面板里。人当然可以点开看，但这些东西对 agent 来说几乎是黑箱。

一个动作只能靠人点按钮，就很难自动化，也很难复盘。按钮按下去之后发生了什么，参数是什么，失败原因在哪里，日志去哪儿了，很多时候没人说得清。

写成命令之后，事情就不一样了。

比如通过 DAPLink 和 OpenOCD 接入硬件，把连接、烧录、复位、寄存器访问这些动作都暴露成命令行：

1

openocd -f interface/cmsis-dap.cfg -f target/stm32f1x.cfg

再通过 telnet 或者 gdb 接进去，执行 mdw、mww 这类命令读写寄存器：

1
2
3


telnet localhost 4444
mdw 0x40021000
mww 0x40021018 0x00000004

到这一步，寄存器就不只是 IDE 面板里给人看的值了。它可以被命令读出来，被日志记下来，被脚本检查，也能被 agent 调用。

我认为这才是 agent 接入嵌入式的方向。

不是让它隔着一层 GUI 猜你现在点到了哪里，而是给它明确的工程入口：怎么构建，怎么烧录，怎么连接芯片，怎么读寄存器，怎么判断失败，怎么把结果反馈回来。

传统嵌入式很难自然接收到这些东西

我现在回头看，很多传统嵌入式开发者不是能力不行，而是知识结构被旧开发方式卡住了。

很多人学嵌入式，从单片机、寄存器、外设、手册、例程、IDE 开始。这条路没问题，底层基础也重要。但如果一直停在“我会配寄存器、我会调外设、我会移植库”，就会错过现代工程真正变掉的部分。

现在的重点已经不只是会不会点亮一个外设，而是你能不能把这个动作组织成可维护的系统。

工程结构怎么设计，构建系统怎么统一，调试链路怎么复现，文档怎么沉淀，接口怎么暴露给机器，流程怎么交给 agent 执行，这些东西不是传统嵌入式课本会系统教你的。

所以知识面必须往外扩。

只盯着底层是不够的。你还得理解 CLI、脚本、构建系统、自动化、日志、测试、文档、agent 工作流，甚至要理解一点现代软件工程里的架构和协作方式。因为这些东西加在一起，才决定一个项目能不能长期扩展，而不是只决定某一块板子今天能不能跑起来。

提升工程能力不是课本学习

我现在越来越觉得，工程能力不是把课本从第一页啃到最后一页啃出来的。

课本会给你基础，手册会告诉你寄存器，数据结构和操作系统会给你底层概念，这些当然都要学。但真正让人产生工程能力的，往往是你在真实项目里不断遇到混乱，然后逼自己把混乱整理成结构。

不是所有东西都值得从最底层重新推一遍。

现在有 agent，很多重复工作完全可以交出去。查资料、补脚本、整理命令、定位明显错误、生成模板、做初步排查，这些事情如果还全靠人肉硬扛，本质上是在浪费生产力。

你可以借助 agent debug，也应该这么做。

但这不代表人就可以不懂原理。恰恰相反，agent 介入之后，人更应该把精力放到更高层、更关键的位置：判断它给出的方向对不对，判断模块边界合不合理，判断问题到底是工具链、驱动、时序、内存、任务调度，还是硬件本身。

工具越强，人越不能只当执行者。

Agent 的边界也很明显

agent 很适合处理局部问题，尤其是上下文边界清楚的问题。

一个模块报错，一个脚本跑不通，一个寄存器值异常，一个构建依赖缺失，只要你给它足够明确的命令、日志和背景，它确实可以很快帮你推进。

但当项目规模变大，问题就不是这么简单了。

一万行代码的时候，agent 还能大概读懂项目结构，顺着日志和模块关系做一些推断。可当代码从一万行变成十万行，外设、驱动、协议、任务、状态机、硬件版本、上位机、测试脚本全都搅在一起的时候，它就很容易吃不下。

它不是不会写代码，是上下文有限。

一个复杂嵌入式项目真正难的地方，往往不在某一行代码怎么改，而在整体结构为什么会变成这样。哪个模块本来就不该这样依赖，哪个接口从一开始就设计错了，哪个状态机迟早会失控，哪个底层时序问题会被上层逻辑掩盖，这些判断很难只靠短上下文推出来。

这就是人还不能退场的地方。更准确地说，是有工程经验、懂底层原理、也懂架构设计的人不能退场。

人应该站在更高的位置

所以我现在看 agent 做嵌入式：它不是万能程序员，也不是底层工程师的替代品。它更像一个能执行大量明确工程动作的协作者。

前提是人先把动作整理出来。

你要给它命令，给它接口，给它文档，给它边界，给它可以验证的结果。DAPLink、OpenOCD、CMake、Ninja、GDB、日志系统、测试脚本，这些都不是孤立工具，而是把硬件开发变成可调用流程的组成部分。

真正有价值的工程师，不是守着旧 IDE 和旧流程证明自己会吃苦，而是能把这些东西组织成系统。

该深耕原理的时候要深耕。总线、寄存器、启动流程、异常、中断、调度、内存、时序，这些东西决定你在关键问题上能不能看穿本质。

但也不能只深耕底层。只会底层，不懂工程组织，不懂工具链，不懂现代协作方式，也会被时代甩开。

最重要的还是紧跟潮流，多学一点，把知识面撑开。工程能力不是把自己锁在某个知识点里死磕，而是在真实变化里更新工具、方法和判断。

agent 时代的嵌入式开发，不是人退场，而是人要站到更高的位置。

底层能力要有，架构判断要有，工具链也要能被机器调用。只有这样，agent 才不是一个会胡乱补代码的玩具，而是真的能进入硬件开发流程，成为工程系统的一部分。

OpenOCD on Blog

Agent 做嵌入式，核心还是把硬件开发接成 API

Agent 做嵌入式，核心还是把硬件开发接成 API

把硬件能力暴露出来

传统嵌入式很难自然接收到这些东西

提升工程能力不是课本学习

Agent 的边界也很明显

人应该站在更高的位置