最近几年，Coding Agent 的发展速度非常快。Claude Code、Codex 已经不再只是代码补全，而开始具备理解代码仓库、修改工程、运行测试、定位问题，甚至完成复杂开发任务的能力。

这也带来了一个新问题：

**当通用 Coding Agent 已经越来越强，MCU/DSP 原厂为什么还需要自己的 Coding Agent？**

先看几家原厂现在怎么走。

### TI：把 Claude Code / Codex 接进 CCStudio

TI 在 2026 年发布的 **CCStudio 21** 里已经明确支持 Codex，并持续增强 AI Agent / Skill 相关能力。CCStudio 本身覆盖 C2000、DSP、Sitara、SimpleLink 等嵌入式产品，所以这不是单纯「代码聊天」，而是把 AI Agent 接到真实 IDE、工程、Build / Debug 环境里。TI 官方文档甚至专门提供了 **CCStudio + AI / Code Assistants** 的配置体系。([Texas Instruments][1])

我们也把 Coding Agent 接到了这套生态里。TI 这边仍以 CCS Studio 为主，原厂的开发者习惯已经在 IDE 里，Agent 必须走进这个现场，而不是另开一个窗口。

### Microchip：直接做自己的 MPLAB AI Coding Assistant

Microchip 这条路线更明确：基于开源 Coding 工具做二次开发，持续注入原厂上下文，目标之一就是减少幻觉。

它推出了 **MPLAB AI Coding Assistant**，基于 Continue 做 Microchip 专用版本，直接面向自家产品开发，支持：

- Autocomplete
- Generate / Edit Code
- Review / Explain Code
- Microchip-specific Chat
- 在编辑器里直接访问 Datasheet

Microchip 自己强调，这套工具持续注入 Microchip-specific information，相比公共 AI 工具要**减少幻觉**。([Microchip][2])

更进一步，它已经加入 **Agent Mode + MCP Server**。MCP 可以让 Agent 直接查询 Datasheet、Evaluation Board User Guide、Compiler Guide、Example Projects、Training Videos 等官方资料。([Microchip Developer Help][3])

Microchip 还在 2025 年发布了独立的官方 MCP Server，让兼容的 AI / LLM 获取经过验证的产品规格、Datasheet、库存、价格和交期等结构化信息。([Microchip][4])

所以 Microchip 的路线已经很接近：

> **Coding Agent + 原厂知识接口。**

### ST：先解决「资料太多、找不到正确答案」

ST 当前更偏知识入口，路线和 TI 有相似之处：IDE 已经很成熟，用户习惯已经在那边。接下来要决定的是：做一个全新的 AI 入口，让开发者更快用起来；还是站在现有使用路径上，让原来的工作做得更好。

它推出的 **STM32 Sidekick** 主要基于 STM32 官方资料回答开发者问题，包括产品文档、产品信息和官方内容，给开发者一个自然语言入口去找技术答案。ST 公开说明其底层采用 RAG，把官方资料作为回答依据。([STMicroelectronics][5])

所以 ST 目前更像：

> **STM32 官方可信知识助手。**

再结合原有 STM32CubeMX、CubeIDE、HAL / LL 等开发工具，实际上也是在逐步降低开发者找资料、配置工程和上手 STM32 的成本。

### 乐鑫：开始把 Agent 往 Build / Flash 方向推

乐鑫通过 ESP-IDF，让 AI 更好地理解代码和文档，并进一步进入项目配置、Build、Flash 等真实开发动作。

> **乐鑫已经开始通过 ESP-IDF 的 Agent / MCP 能力，让 AI 不只理解代码和文档，而是进入真实开发执行。**

它代表了另一个方向：

> 从 **AI Coding** 继续往 **AI Development Execution** 走。

## 把四家放在一起看，趋势其实很明显

| 原厂 | AI Coding 方向 |
| --- | --- |
| **TI** | Claude Code / Codex + CCStudio / IDE / Debug |
| **Microchip** | MPLAB AI Coding Assistant + Agent Mode + 官方 MCP |
| **ST** | STM32 Sidekick + 官方可信知识 |
| **Espressif** | Agent / MCP + Build / Flash 等工程执行 |

它们路线不同，但共同点非常清楚：

> **原厂正在把过去给「人」使用的 SDK、文档、IDE、Example 和工具链，逐渐变成 Agent 也可以理解和调用的基础设施。**

这里会分出两条路：一家 AI 公司去做 MCU 场景下的 Coding Agent，还是一家 MCU 公司自己去适配 AI Agent。角度不同，做出来的东西也不一样。

> **我们认为下一步不是再做一个通用 Coding Agent，而是帮助 MCU/DSP 原厂把自己的 Developer Ecosystem 重新组织成 Agent-native 的 Developer Infrastructure。**

[上一篇](/article/analog-chip-company-ai-native)我们也写过：芯片公司对 AI 的认可度，决定了它接下来的产品形态，是围绕 AI 重建，还是只在原有基础设施上加一层 AI。差别很大。

下面按具体场景说清楚：为什么 DSP、MCU 这个场景特别需要 AI。

## MCU/DSP 原厂最大的成本之一，是让客户把芯片真正用起来

这不是拷一个 `hello_world` 就结束。下面是一些真实会卡住项目的环节。

#### 从 Demo / EVM 到客户自研板的 Bring-up

NXP 官方的 Custom Board 流程就要求重新处理 `board.c/h`、Clock、PinMux、CMake / Kconfig、启动配置、Flash runner、Debug runner；Flash / Debug 又涉及 LinkServer、J-Link、Flash Address。客户第一次从原厂开发板迁到自己的 PCB，本身就是一整条工程链。

#### 外设初始化和系统资源配置

GPIO、Clock Tree、PinMux、ADC、PWM、DMA、Interrupt、Middleware 之间有大量约束。STM32CubeMX 之所以专门提供 Pinout 冲突处理、Clock Tree 校验、Peripheral 配置和初始化代码生成，就是因为这部分本身就是 MCU 开发的主要上手成本。ST 官方甚至直接把「降低开发时间」和「减少配置错误」作为 CubeMX 的核心价值。

#### 复杂外设和实时控制功能的二次开发

TI 的 C2000 CLB 可以做自定义 PWM、修改 ePWM、编码器接口、自定义串行协议，甚至替代部分 FPGA / CPLD 功能。官方支持里就有客户问「外部触发的一次性 PWM 怎么实现」，FAE 会定位到具体 CLB Example，再告诉客户怎么把示例迁到自己的器件和 SysConfig 配置。

#### DSP / 实时控制并不是「写几个寄存器」

以 C2000 MotorControl SDK 为例，原厂需要支持 FOC、无感 / 有感控制、Resolver / 增量 / 绝对编码器、电流采样、MTPA、Field Weakening、启动失败恢复、失相保护、振动补偿、CAN / FSI / EtherCAT；CLA 又涉及 CPU 与协处理器之间的内存、消息 RAM、触发和实时任务。客户经常要的不是 API 解释，而是一段能进入真实控制系统的应用方案。

#### SDK 版本、器件迁移和平台迁移

一个 Example 在旧芯片能跑，不代表换一颗料还能直接跑。TI 专门做了 C2000 SysConfig migration；NXP、Infineon 都有 BSP / SDK version、custom BSP 和迁移体系。Infineon 就明确要求自定义硬件时重新处理 clocks、pins、peripherals、BSP 和 library versions。

#### Build / Flash / Debug / 现场故障定位

这是通用 Coding Agent 最容易低估的一块。代码能编译，不等于板子能跑：Boot Mode、Flash 地址、Debugger、UART、时钟、供电、Pin 配置，都可能导致「烧进去了但是没反应」。NXP 的官方 Bring-up 文档就明确涉及 Flash boot mode、debug probe、terminal 设置；Infineon 的真实支持案例里，遇到客户系统异常，官方会要求进一步查看 schematic + software code，才能由 FAE 协助定位。

#### 培训、Example、FAQ、Debug Tips 本身就是 FAE 的巨大重复劳动

TI 的 CLA 官方学习路径非常典型：Workshop → Examples → FAQ / Debugging Tips → System Use Cases。ST 对自己的 FAE 描述也包括 firmware development、customer support、training。原厂今天本来就在花大量人力，把「芯片怎么用」不断解释、演示、迁移、Debug 给客户。

我们的答案是：

> 因为 MCU/DSP 行业真正的竞争，并不只是「谁能生成更多代码」，而是谁能够帮助开发者更快、更低成本地把芯片真正用起来。

对于 MCU/DSP 原厂来说，最大的壁垒之一，并不是芯片设计本身，而是围绕芯片建立起来的 Developer Ecosystem。

## MCU/DSP 最大的成本：让客户真正把芯片跑起来

一颗 MCU 进入客户项目之后，难点才刚开始。真正难的是一整套开发者生态：选型、开发环境搭建、SDK 和 Example 学习、Clock 与 PinMux 配置、外设初始化、自研板迁移、Build、Flash、Debug，以及后续的性能优化和量产问题。任何一个环节出错，都可能让项目卡上几小时、几天，甚至更久。现在很多场景仍然是原厂 AE 驻场，帮客户调试、帮客户快速上手。

一个工程师从拿到芯片，到最终产品运行，中间通常需要经历：

```text
选型
↓
安装工具链
↓
学习 SDK
↓
理解 Example
↓
配置 Clock
↓
配置 PinMux
↓
初始化外设
↓
迁移到自研板
↓
Build
↓
Flash
↓
Debug
↓
性能优化
↓
量产问题处理
```

其中任何一个环节出现问题，都可能导致项目延期。

很多时候，客户遇到的问题并不是：

> 「我不会写这段 C 代码。」

而是：

> 「这个功能应该从哪个 Example 开始？」
>
> 「这个 SDK 版本应该用哪个 API？」
>
> 「为什么开发板可以运行，换成自己的 PCB 就不工作？」
>
> 「这个问题到底是软件问题，还是 Clock、Pin、硬件配置问题？」

这也是为什么 MCU/DSP 原厂需要大量 FAE 和应用工程师支持。

## 原厂最宝贵的资产，其实是 Developer Enablement 能力

原厂最宝贵的资产，其实是一颗 MCU 从出生到客户量产的全生命周期经验。同类客户可以复用，持续沉淀，形成团队资产。

一个优秀的 MCU/DSP FAE，价值并不只是熟悉 Datasheet。

更重要的是，他知道：客户提出一个需求以后，应该参考哪个 Example，应该使用哪个外设模块，应该修改哪些配置，当前 SDK 版本有哪些坑，哪个问题优先检查硬件，哪个问题优先检查软件。

例如，一个客户想实现特殊 PWM、编码器接口或者可配置逻辑功能。

对于普通开发者来说，需要搜索 User Guide、Application Note、Example、SDK 文件和 Forum。

但一个经验丰富的 FAE，可能几分钟就能判断：

- 是否适合使用 CLB
- 哪个 C2000 Example 最接近
- SysConfig 如何配置
- 哪些寄存器需要注意
- 如何迁移到客户工程

这类能力非常宝贵。但问题是，它长期存在于 FAE 个人经验、客户邮件、历史工单、培训材料、示例代码和工程师记忆里，很难规模化复制。

所以我们认为：

> MCU/DSP 原厂真正需要解决的问题，不只是代码生成，而是如何把 Developer Enablement 能力产品化。

## 我们正在做的：原厂定制 Coding Agent

我们的思路不是先做一个 Coding Agent，而是先从评测开始。

我们先把 TI、Microchip 这类原厂公开问题，以及真实 MCU/DSP 开发支持场景中的历史问题，整理成 Eval 数据集，先定义什么叫「回答正确」、什么叫「工程上可用」。在这个基础上，再构建自己的 LLM Wiki / Code Wiki，把 Datasheet、Manual、SDK、Example、版本关系和真实问题，逐步组织成一套可持续迭代的知识基座。

这个知识基座同时服务两个入口：

- **问答**：FAE、AE 日常大量问题，其实通过高质量 Chatbot 就能解决；问答本身也是持续收集真实问题、发现 Wiki 缺口、推动知识回写的入口。
- **Coding Agent**：当任务从「告诉我怎么做」进入「帮我改代码、迁移工程、Build、Flash、Debug」时，再进入真正的生产执行。

我们之所以自己搭 Harness，而不是完全依赖 Claude Code 这类现成 Agent，是因为我们需要看到和控制完整的检索、工具调用、执行轨迹、失败原因和中间状态，才能把这些 Trace 持续回流到 Eval、Wiki 和 Agent 策略里做迭代。

简单说，我们真正做的是一条闭环：

```text
Eval
↓
Wiki
↓
问答 / Coding Agent
↓
Trace
↓
回写
↓
再 Eval
```

Coding Agent 只是其中的执行层。真正长期积累的，是知识基座、评测体系和可观测的 Agent Harness。

这也是我们正在探索的方向：**帮助 MCU、DSP 原厂构建属于自己的 AI-native Developer Ecosystem。**

相关产品见 [Coding Agent](/article/coding-agent) 和 [MCU / DSP 场景说明](/article/mcu-dsp-coding-agent)。如果原厂希望把 SDK、文档和工具链做成 Agent-native 的开发者基础设施，欢迎 [预约沟通](/booking)。

[1]: https://www.ti.com/tool/CCSTUDIO
[2]: https://www.microchip.com/en-us/tools-resources/develop/mplab-x-ide
[3]: https://developerhelp.microchip.com/
[4]: https://www.microchip.com/
[5]: https://www.st.com/en/development-tools/stm32cubemx.html