Agent 时代，嵌入式软件工程师何去何从
过去半年，身边做嵌入式的朋友聊得最多的一句话是：Agent 是不是要来抢饭碗了。
这种担心有来源。以前要花一周写的寄存器配置代码，现在把数据手册丢给 Agent，几分钟就能出一版能跑的外设初始化。协议解析、状态机骨架、单元测试，这些占掉大量时间的活，它完成得相当可观。
但把镜头拉近，事情没那么简单。
被交出去的，是”确定性”的活
Agent 擅长的，是把明确规则翻译成代码。数据手册第几页、外设时钟怎么配、中断优先级怎么排——只要信息完整、目标清晰，它做得比人快，也比人稳。这类活会加速贬值：纯翻译型的移植、重复度高的驱动模板、照抄参考手册的功能实现。把本事押在”手快”上，价值会被稀释。
但嵌入式有一道门槛，Agent 一时半会跨不过去：它看不见硬件。
板子有没有上电、示波器上的波形对不对、时序差了几纳秒、高低温下这颗芯片会不会飘——这些信息在目标环境里，不在训练数据里。Agent 能给你一份逻辑自洽的方案，却没法告诉你它在这块具体板子上会不会死机。软硬件交界那一层，还是得靠人蹲在工位上一根线一根线地试。
更值钱的，是定义问题和兜底的能力
写代码本身变廉价之后，两件事明显升值。
一是把模糊需求翻译成可执行规格。 客户说”这个设备要更省电”，Agent 没法直接干活。你得拆成：休眠电流压到多少、唤醒延迟控制在几毫秒、要不要牺牲响应速度换续航。规格定得越准，Agent 产出的代码越可用。定规格，就是替整个系统做取舍。
二是为结果负责。 代码是 Agent 写的，但产品烧进去炸了，责任还是工程师的。能不能一眼看出”这段初始化少了电压校准”，比会写代码更要紧——总不能等它在客户现场出问题。
角色正在从”执行者”往”决策者”挪：执行被自动化，判断被凸显。
现在可以做的几件事
主动用起来。 拿 Agent 跑一遍手头最枯燥的驱动移植，看看它哪里行、哪里不行。摸清边界的人，才有资格谈分工。
往纵深走。 越靠近硬件、越靠近实时性和可靠性，越难被替代。RTOS 内核、低功耗设计、EMC、功能安全，这些经验门槛高，Agent 短期内给不了等价答案。
守住工程判断。 Agent 给的东西，先验证再采用。
工具换了几轮，判断力没换
这二十年，嵌入式工程师从汇编换到 C，从裸机换到 RTOS。每次工具升级都有人喊失业，但留下来的，是把工具用到极致、同时守住工程判断的人。
Agent 把一部分”写”的动作直接拿走了，拿不走的是：对硬件的理解、对风险的敬畏，以及在信息不全时做决策的胆量。这些最难被量化和复制。
与其焦虑饭碗会不会被端走，不如先想清楚：哪些活是 Agent 干得更好的，哪些是离了你不行的。把前者交出去，把后者做深。
答案不在 Agent 手里，在你自己的判断里。
*本文为原创观点，图片来自 Pexels 免费图库（Pexels License，可免费用于商业用途）。*