前两篇文章发出去后，很多人问：“你那个工作流里面的‘Agent’到底是个啥？它们怎么配合的？”

今天这篇文章，专门回答这个问题。不讲故事，不抖机灵，就讲一件事：这套系统里的每个Agent分别干什么活，它们是怎么一步一步把外设配置写到量产级别的。

---

先看一张总图：九个Agent，一个闭环

这套系统里一共住着九个AI Agent，各管一摊，分工明确。它们联起手来，把“自然语言一句话”变成“经过逻辑分析仪验证的固件”。

以下就是它们的完整协作链路：

text

你的一句需求
    │
    ▼
ContextManager ──── 判断任务类型，划定修改边界
    │
    ▼
ParseAgent ──────── 把大白话翻译成结构化的外设规格(PeripheralSpec)
    │
    ▼
GenAgent ────────── 根据规格生成C/H初始化和驱动代码
    │
    ▼
BuildAgent ──────── 调编译器编译，出错自己分类并修复
    │
    ▼
PreVerifyAgent(pre)── 烧录前，对源码做静态预验证
    │
    ▼
FlashAgent ──────── 把固件烧进真实的MCU里
    │
    ▼
PreVerifyAgent(post)─ 在线读取寄存器快照，检查配置是否生效
    │
    ▼
VerifyAgent ─────── 驱动逻辑分析仪抓取物理信号，与手册时序图比对
    │
    ▼
MasterAgent ────── 综合分析结果，决定通过、重试、还是警告硬件异常

下面，我们把这九个Agent一个一个拆开看。

---

ContextManager：守门员

你跟系统说的每一句话，第一个接手的永远是ContextManager。

它的职责就一个：判断你要干什么。

是写一个全新外设的驱动？还是修改一个已经存在的配置？如果是在现有工程上改，它会精准锁定相关文件，绝不越界多动一行代码。如果是新开发，它会划出一块干净的区域，保证新生成的代码不会污染已有模块。

这一步看起来简单，但它是保证量产代码不被意外破坏的第一道保险。有过量产经验的人都懂，一个项目跑了大半年，最怕的就是“加个新功能，把老功能改崩了”。

ContextManager的存在，就是让这种事不会发生。

---

ParseAgent：翻译官

你随口一句“写个SHT30驱动，PB6、PB7用IIC”，ParseAgent要把它变成一份严谨的外设配置文档，也就是PeripheralSpec JSON。

这里面包含了：

• 你说了的：IIC主机，SCL是PB6，SDA是PB7，传感器型号SHT30，地址0x44

• 你没说的，它从芯片手册、传感器手册里自动补全的：

  • PB6/PB7要复用为AF4

  • IIC时钟源是PCLK1，默认36MHz，标准模式要配到100kHz

  • SHT30上电后需要1ms稳定时间才能响应命令

  • 如果这些引脚默认被调试口占用，需要先解除

它不是一个关键词提取器。它理解上下文，理解外设之间的关联，理解时序约束。它能从手册的引脚定义表、时钟树、复用功能表、电气特性等多个章节里，把分散的信息拼成一张完整的规格图。

量产级配置的第一步，就是把所有隐性的约束都变成显性的规格。ParseAgent干的就是这个。

---

GenAgent：主程

有了PeripheralSpec，GenAgent开始写代码。

它写的不是Demo级的“点个灯就完事”。它生成的是按量产标准来的工程代码：

• 开始初始化前，先复位外设到默认状态，清掉上次运行可能留下的残留配置

• 时钟使能后，加短暂延时等时钟稳定，再去操作外设寄存器

• 引脚复用配置前，检查引脚当前状态，确保不被别的东西占用

• 每写一个关键寄存器，立刻回读校验，确认写入生效

• 对外接口用完整的错误码体系：超时有超时的码，应答失败有应答失败的码，总线忙有总线忙的码。不是所有错误都返回一个-1

• 功能配置完成后，做一个自检。比如IIC的，发一个空地址，看总线应答逻辑正不正常

这些防御性代码不是AI自己拍脑袋加进去的。每一条都对应PeripheralSpec里的一个约束项。GenAgent的任务，就是把这些纸面约束，原原本本变成可执行的C/H代码。

---

BuildAgent：编译器管家

代码写好了，BuildAgent调起Keil MDK编译器开编。

它有两大能耐：

第一个，编译如果报错，它自己能看错误日志。头文件没找到？它去工程配置里加路径。某个宏没定义？它查依赖关系，看看是哪个模块产生的，自动补上定义。寄存器名字写错了？它去手册里找标准名字，回来自己改。改完重新编译，不用你插手。

第二个，编译通过了，它也不报“搞定”。它知道，编译器只能查出语法错误，查不出逻辑错误。寄存器地址左移了一位，位段掩码写宽了，这种编译器是查不出来的。所以它只把编译通过当作“第一关过了”，然后把控制权交给下一道工序。

---

PreVerifyAgent(pre)：静态安检

烧录之前，先做一次静态预验证。

它在源码层面扫描若干检查项：中断优先级有没有冲突？DMA通道有没有重复分配？某个外设的时钟源是不是真的被使能了，还是只使能了总线时钟，忘了开外设自己的时钟门控？

这些问题是编译查不出来的，是逻辑上的漏洞。在软件层面拦住，比烧进去之后出问题再回头查要省太多时间。

量产代码的一个重要特征，就是“把错误堵在出厂之前”。PreVerifyAgent(pre)做的就是这件事。

---

FlashAgent：快递员

这一步最简单，也最容易被忽视。

FlashAgent通过调试器（DSLite或CCS），把编译好的固件烧进真实的MCU里。它自己要处理好芯片型号识别、调试接口协议、擦除和烧写时序。不管底层是什么调试器，对上层的MasterAgent来说，它就是一个通用的烧录接口。

当FlashAgent完成任务，芯片里已经有我们刚刚生成的代码在跑了。

---

PreVerifyAgent(post)：寄存器核查官

烧录完成之后，PreVerifyAgent马上切换到post模式——它不是看代码，是看真实的芯片内部状态。

它通过调试器在线读取外设相关的寄存器快照：时钟使能位到底写进去了没有？GPIO模式寄存器配成了复用功能吗？IIC的速率控制寄存器数值正确吗？中断使能位和优先级是不是设成了规格要求的值？

这一步是软件和硬件的第一次真实握手。很多代码在逻辑上没问题，但因为某些芯片的勘误表限制，或者硬件本身的特性，寄存器实际写入的值可能和预想的有差异。PreVerifyAgent(post)能在物理信号验证之前，先把这类问题揪出来。

---

VerifyAgent：终极验收

现在，我们才走到了最硬核的一步。

VerifyAgent驱动逻辑分析仪，直接去采集SCL、SDA引脚上的物理波形。采集回来的波形，自动和芯片手册上的IIC标准时序图做比对：

• 起始条件的高低电平持续时间对不对

• 设备地址的每个位和应答位波形是否正确

• 数据传输阶段的时钟沿和数据变化点是否符合建立保持时间

• 停止条件的波形是否规范

比对不是“看着差不多就行”。是每一个时序参数都和手册数值做容差分析。如果所有时序参数都落在手册规定的范围内，通过。如果某一个波形区间偏差超出了手册允许的值，VerifyAgent会标记出具体是哪一帧、哪一个时钟边沿不满足要求。

这才是量产级验证：代码不光要跑得通，还要在所有电气参数上满足芯片手册里的硬性指标。

---

MasterAgent：总指挥

所有Agent的工作结束后，MasterAgent汇总全部报告，做最终决策：

• 所有验证都通过 → OK，闭环成功，交付可发布的固件配置

• 某个环节有问题，但问题类型明确，可自动修复 → ADJUST，把修改意见传给GenAgent，重新生成、重新走一轮验证

• 同一个问题连续出现，但方向还没对 → RETRY，换一种实现路径再试

• 经过反复迭代，问题仍指向硬件本身 → CHECK_HARDWARE，停下来，告诉你“疑似板级问题，请检查电路”

整个闭环最多迭代5次。绝大多数外设配置，三轮以内就能通过。如果五轮都过不了，MasterAgent不会让它无限循环下去。它会给你一份详细的失败分析报告，告诉你它怀疑硬件哪里可能有问题。

这个刹车机制，是量产级的最后一道保险：AI不瞎折腾。

---

这九个Agent协作的结果是什么？

它们产出的不是Demo，是经过以下步骤验证的、可直接用于产品的固件配置：

• 从芯片手册、原理图自动构建硬件模型

• 自动补全用户未提及的时序约束和电气参数

• 按防御性编程规范生成初始化代码

• 编译通过且自动消除语法错误

• 源码静态检查堵住逻辑漏洞

• 寄存器在线核查确保配置写到硬件里

• 逻辑分析仪逐帧比对物理信号与手册要求的时序

这一圈跑下来，外设配置的可靠程度，已经不是“我觉得没问题”，而是“物理信号和芯片手册对得上”。