设计电源硬件这种活儿容错率本来就低。以前做一块DC-DC从拓扑选型到器件参数确定再到仿真验收靠的是经验表和一堆Excel计算。现在大家开始尝试让大模型Agent直接参与设计想法挺好但问题也很明显模型生成出来的参数漂亮得像个满分答卷拿去做PCB却大概率炸板。根本原因就是幻觉。我这次搭建了一套基于某开源推理模型Harness的电源硬件设计Agent重点解决的恰恰不是“模型多聪明”而是“怎么让模型在关键环节没有机会编”。这篇就把完整思路、架构分层、防幻觉机制和实操流程拆开讲清楚顺便把调试期间踩到的坑一并复盘。1. 为什么电源设计Agent必须加一道“防幻觉缰绳”1.1 电源设计场景对幻觉的容忍度为零电源硬件设计和其他代码生成类任务有个本质区别代码写错了编译器能报错但电路设计错了轻则EMI超标、纹波过大重则上电直接冒烟。模型编造一个不存在的器件封装或者把电感饱和电流计算偷换一个单位单看对话过程完全发现不了只有等仿真或者实物测试才会暴露。更麻烦的是这类错误往往带有“局部合理性”——公式看着对、数值也像回事实际却经不起推敲。所以在这个领域我的原则很明确LLM可以负责推理和规划但绝不能让它直接对最终设计数值负责。所有给出电参数的地方要么调用计算工具要么从器件手册里检索原始数据。Harness层要做的就是把模型这种“自由发挥”的天性约束在合理边界内。1.2 传统LLM直接出方案的三种“翻车”现场我在早期用裸模型做实验时遇到过三类典型问题现在回想起来都很有代表性。第一类是器件凭空捏造。让模型选一颗同步Buck控制芯片它给出了一个听起来很专业的型号封装、耐压、开关频率全都有但去数据库检索时发现这个型号根本不存在。第二类是公式中的隐含假设被忽略。比如算Buck电感量时模型把纹波系数设定为0.3但并没有说明这个系数是在CCM连续导通模式下才成立。如果负载已经降到DCM区间整个计算结果就失真了。第三类是上下文遗忘导致的前后矛盾。前面选了低开关频率以降低开关损耗后面算输出电容时又用了高频模型下的ESR假设自己推翻自己。这些问题并非模型能力不足而是缺少一个外部机制去校验、拦截和纠正。Harness框架的价值就在这儿。1.3 Harness的定位不是提示工程是执行约束很多朋友一听“防幻觉”就想到写更长的System Prompt或者用少样本示例来“教”模型。这些手段有效但非常有限。Prompt本质上还是“建议”模型该编还是会编。Harness的定位不同它是把模型放在一套可执行的约束系统里模型提出设想系统负责验证模型调用工具系统负责审查工具的输入输出模型输出结论系统用规则引擎和仿真结果做交叉确认。打个比方Prompt像师傅在开工前叮嘱几句Harness像施工队里的质检员和安全员每道工序都要签确认单。这也是为什么我坚持在“基于某开源推理模型”的基础上再套一层Harness而不是直接依赖模型自身的行为约束。2. 整体架构设计Agent四层骨架与数据流2.1 第一层规划层任务分解与拓扑假设整套系统的顶层是规划层负责理解用户需求并拆分设计任务。例如“设计一个24V输入、12V输出、最大3A的Buck电源”规划层要做的事包括判断输入输出条件、初步确定拓扑类型、列出需要计算的关键参数清单、制定执行顺序。这一层主要用Prompt引导模型做“结构化思考”但不会让它直接输出数值。规划层的结果是一份JSON格式的任务工单包含拓扑类型候选列表如Buck、Buck-Boost、SEPIC以及各自的适用度评分输入输出规格参数表包括电压范围、电流纹波约束、效率目标需要计算的电感、电容、开关频率、环路补偿等参数项每个参数项对应的计算工具或数据检索源这份工单是后续所有环节的“施工图”。它存在的意义在于让模型先展示自己的分析路径Harness再对路径的合理性做初审而不是让模型直接跳到结论。2.2 第二层工具层公式计算、器件检索、仿真脚本工具层是Agent的“手和脚”。这层的设计有一个核心原则模型不直接算数只负责调用工具和解释结果。我用三个工具打通了从计算到验证的链路符号计算工具内置Buck/Buck-Boost等主流拓扑的推导公式库输入电压、电流、纹波率等条件输出电感量、电容容值、环路零极点位置。公式库经过人工逐条验证避免模型临时“默写公式”时写错。器件检索工具对接自建的器件信息库涵盖主流厂商的控制器、MOSFET、电感、电容型号。检索返回的内容是结构化的字段包括耐压、额定电流、封装、热阻、价格、供货状态模型只能从这个工具拿器件数据不能凭印象编造型号。仿真工具生成SPICE网表并调用仿真器做瞬态或交流分析。关键设计参数确定后系统会把参数传给仿真工具计算输出电压纹波、负载瞬态响应、环路相位裕度等。工具层的设计决定了防幻觉能力的上限。器件数据如果来自模型记忆那错误无可避免但器件数据如果来自结构化数据库幻觉就失去了生存空间。2.3 第三层校验层Harness的规则引擎与事实核对校验层是整个架构的“守门员”也是Harness框架最核心的部分。它包括两套并行机制规则引擎对工具计算结果做合法性检查。比如根据伏秒平衡原理验证占空比是否在合理范围、根据电感伏秒积验证磁芯是否可能饱和、根据热阻和功耗验证温升是否超标。规则引擎里的每条规则都是一个独立函数输入参数、输出判据不存在模型“自由裁量”的空间。事实核对器对模型在分析和解释中提到的每一个器件型号、数据手册数值、公式定义做自动核对。模型一旦声称“某芯片的静态电流是50uA”核对器就会去器件信息库查找该型号的真实值不一致则触发告警要求模型重新检索或修正表述。这个机制之所以有效是因为它把“模型说了算”变成了“事实说了算”。模型可以提出任何假设但所有假设在进入下一流程前必须经过规则和事实的双重审阅。2.4 第四层数据层器件库、仿真库、历史设计库数据层是支撑整个系统的底座。我自建了三个数据库都是围绕电源设计场景整理的器件库收录控制器、功率级、无源器件的型号与完整参数。数据来源是各厂商的数据手册和选型表经过人工抽检。每次检索都留有日志方便追溯模型在哪个环节引用了什么器件。仿真库存放常用拓扑的仿真模型和模板网表。以Buck仿真为例模板里已经定义好了输入源、开关管模型、续流二极管模型、负载阶跃参数只需要填参数即可运行避免模型每次生成网表时引入低级错误。历史设计库沉淀通过验证的设计案例包括拓扑结构、参数计算过程、仿真结果和实物测试数据。后续Agent在类似需求上可以直接参考历史设计的“成功路径”减少从零推导带来的不确定因素。数据层的建设比较耗时但它是防范幻觉效果最明显的一环。模型知道得再多都不如让它“查得到、查得准”重要。3. 防幻觉机制的核心设计细节3.1 “先检索后计算”的器件事实约束电源设计里器件参数的准确性比公式推导更致命。公式写错了仿真能看出来但器件参数一旦用错整个设计就建立在错误地基上。我在这里设计了一个强制流程任何涉及器件的决策模型必须先调用检索工具拿到结构化数据再基于这些数据做计算和判断不允许在对话上下文中“回想”器件参数。具体实现上Harness为器件检索工具设定了使用规则工具返回的结果会暂存在一个独立的内存区域模型后续引用时只能从这个区域取数。如果模型在最终输出中提及某器件参数而该参数与检索结果不一致事实核对器会直接判为“事实冲突”并拦截输出要求模型重新生成解释。这套机制只有一次差点出过问题。那次模型试图引用一款未检索过的MOSFET的导通电阻值Harness在核对时找不到对应记录模型被强制改选为已检索器件。整个过程不到两秒但拦下了一个潜在的设计隐患。3.2 四重校验闭环设计单个校验规则只能挡一类错误所以我设计了一个四重校验闭环每份设计方案在输出前都要过四道关卡第一道解析校验。检查模型输出是否符合预定格式、单位是否标全、数值是否有缺失项。这道关最基础但能拦截掉大部分低级错误。第二道公式校验。对每个关键参数的计算过程做“反向验算”。比如电感量计算不仅看结果还要把结果代回纹波电流公式反推纹波率是否落在合理区间。第三道仿真校验。对完整设计方案做SPICE仿真提取关键性能指标与设计目标做偏差对比。比如目标纹波是50mV仿真结果是200mV系统会判定设计不达标要求模型调整参数重试。第四道评审校验。由另一个独立评审Agent对方案做“挑刺式”审核重点看设计余量、元器件应力、失效模式。这个评审Agent使用不同的Prompt和视角避免单一思维路径带来的盲区。四道关卡的数据流是单向的任何一道校验失败方案都会被退回上一环节并附带失败原因和修改建议。这就形成了一个“设计-校验-修正-再校验”的闭环模型几乎没有机会把错误输出到最终方案里。3.3 上下文管理的“记忆围栏”Long-context对话里模型经常出现“前面说A、后面用B”的上下文一致性错误。这在电源设计中非常危险因为设计是一个高度依赖前序决策的链条。比如在拓扑评估阶段选了CCM工作模式后面所有计算都应以CCM为前提一旦模型在后续对话中切换成DCM假设整个方案的参数体系就会崩盘。我用“记忆围栏”来解决这个问题关键设计决策一旦确定就会被固化到系统状态中不受对话历史影响。Harness会在每次工具调用时自动附加当前状态摘要包括拓扑类型、输入输出规格、已选器件、设计目标约束。这样即使对话上下文被压缩或者模型状态波动核心参数依然不会丢。对比测试显示加入记忆围栏后设计过程中的“自相矛盾”类错误从平均每轮2.3次降到了0.4次效果非常明显。4. 实操全流程24V转12V/3A的Buck电源设计4.1 需求理解与任务分解实际操作时用户输入的自然语言是“帮我设计一个24V转12V最大3A输出的Buck电源要求纹波小于50mV效率尽量高。”规划层接收后先做标准化处理输出一份任务工单。工单里明确了几个关键点输入电压范围按22V到26V考虑输出电流的瞬态余量按10%预留纹波目标50mV是“输出电容开关纹波”的综合约束效率目标则按93%以上来评估。工单还进一步拆分出待办事项拓扑确认、开关频率选择、电感计算、输出电容选型、MOSFET与二极管选型、环路补偿设计、仿真验证。这个阶段我特别注意不让模型提前进入“计算模式”。规划层的输出只有任务清单和约束条件不包含任何具体数值结果。这样做的好处是模型在执行任务时不会被自己预先给出的“参考值”锚定减少了一种隐蔽的自我确认偏差。4.2 拓扑评估与参数计算工单下发后规划层先做拓扑筛选。对于24V转12V、功率在36W左右的应用Buck拓扑几乎是最优解无需升压或反压占空比约0.5电感选型空间也充足。但模型必须给出选择理由不能直接宣称“这是标准做法”。Harness会验证输入输出电压差、电流应力、拓扑复杂度、成本等维度是否支持Buck方案。拓扑确定后进入参数计算。开关频率我预设为300kHz左右兼顾效率和体积。电感计算调用符号工具输入条件如下输入电压Vin24V输出电压Vout12V最大输出电流Iout3.3A纹波系数r0.3根据Buck电感公式L(Vout×(Vin-Vout))/(f×r×Iout×Vin)计算代入后得到约30uH。工具返回结果时同时给出了取值范围建议L在22uH至47uH之间都可行取决于优先级是减小电感体积还是降低纹波电流。这个参数计算过程完全由工具完成模型只负责解释结果和调整输入条件。比如模型尝试过把纹波系数改成0.4来缩小电感体积Harness的规则引擎立即提示纹波系数0.4会导致峰值电流接近5A超出预设MOSFET的电流能力建议维持0.3或者降低开关频率到200kHz重新计算。模型接受了这个建议避免了后续选型困难。4.3 器件选型与仿真反馈闭环参数就绪后进入器件选型阶段。模型先检索控制器芯片筛选条件包括输入电压范围、开关频率范围、同步整流能力、封装和供货状态。检索返回三个候选型号Harness的规则引擎对每个型号计算了功耗和热阻约束最终锁定一个热阻参数余量充足的方案。输出电容的选择比想象中更考验防幻觉能力。模型一开始直接给出“输出电容使用2颗22uF陶瓷电容”理由是按经验值。事实核对器立即拦截因为工具返回的器件库中22uF陶瓷电容在12V偏压下实际容值会衰减近40%等效容值只有13uF左右。模型被迫重新检索满足目标容值的电容型号并修改仿真输入参数。这个细节让我印象很深。如果换成人来做设计可能也会凭经验选22uF但系统的价值在于它提供了“偏压下的容值衰减”这一层事实校验。仿真阶段Harness把选定的器件参数写入SPICE网表运行瞬态分析。初次仿真结果输出纹波为78mV超过50mV的目标。系统判定校验失败将仿真波形数据反馈给规划层提示“纹波超额需要调整输出电容或降低ESR”。模型重新检索了低ESR电容型号将电容数量从2颗增加到3颗再次仿真纹波降到42mV校验通过。4.4 评审Agent对设计约束的再确认参数全通过仿真后评审Agent介入做最后的“找茬”。它不检查数值计算而是审查设计本身的鲁棒性。评审Agent提出了两个问题第一输入电压范围的上限26V控制器芯片的绝对最大额定值是28V余量只有2V在输入瞬态尖峰场景下风险偏高。建议要么选用额定值更高的控制器要么在输入端增加TVS管做钳位。第二电感的饱和电流标称6A但设计峰值电流约4.95A余量约21%。对消费级应用够用但如果是工业级建议选8A饱和电流的型号提高过载可靠性。这两个问题都由评审Agent提出Harness汇总后让规划层决策。规划层接受了第一个建议增加了TVS管选型说明但对第二个建议选择了“维持原设计”。理由是应用场景定位为消费级21%的余量已满足可靠性要求且增大饱和电流会导致电感体积和成本上升。这个冲突处理很有价值。评审和规划形成了一对“红蓝对抗”既避免设计过于激进也避免过度设计。Harness在这里扮演的是“仲裁者”角色它没有让模型双方无休止争论而是根据需求约束文件中的可靠性等级字段来裁决。5. 现场实录防幻觉机制修复的四个典型案例5.1 事件一模型“创作”了一个不存在的封装调试早期发现模型在输出设计方案时“无意间”指定了一个容量规格特殊的铝电解电容封装。这个封装代码看起来非常专业格式完全符合行业标准但器件库中根本不存在该规格的批量供货。原因在于模型在生成文本时基于训练数据中学到的封装命名规律自动组合出了一个“听起来合理”的写法。这在纯文本对话中毫无破绽但只要落到采购和生产环节就会出问题。Harness的事实核对器在输出端捕获了这一异常因为器件库检索不到该型号模型被强制重新检索并替换为库中真实的工业标准封装型号同时向用户输出了一条“备选器件修正说明”。这次事件让我认识到一个规律用词和格式再规范的幻觉本质上还是幻觉。校验器不能只看“像不像”必须核对“是不是”。5.2 事件二纹波计算里的单位偷换在一次参数调整时模型输出的输出电容纹波电压为18mV但Harness的公式校验发现它下意识把单位从“mV”写成了“V”参与计算导致ESR估算值差了三个数量级。如果这套参数直接进入ECAD工具输出的滤波设计将完全失效。查日志发现模型在上一轮对话中处理过一个电压单位是“kV”的电源案例单位语境迁移到了当前设计中。记忆围栏当时还没有上线系统只能依靠公式校验拦截。事后我把所有工具接口的参数类型定义改成强类型单位不匹配直接报错彻底杜绝了这类偷换。现在这套系统里所有计算工具的参数都要求带单位后缀比如“3.3A”和“3.3mV”被识别为不同类型。模型想传错单位工具直接拒绝调用。5.3 事件三上下文漂移导致前后矛盾有一次设计多路输出的电源系统模型在第15轮对话后把副路的输出电压要求记成了主路的5V而非实际的3.3V后续计算全部跑偏。如果不是评审Agent发现副路功率与设计目标不符整套方案会带着这个错误进入下一阶段。记忆围栏上线后这类问题大幅减少。现在关键参数在任务开始时就被写入系统状态区每一轮对话都自动附加模型的输出也会被抽取关键字段与状态区作对比。如果模型在解释中提到的电压电流值与状态区不一致Harness会弹出告警并纠正。这个改进也让我意识到上下文长度不是决定Agent稳定性的关键状态管理才是。5.4 事件四评审Agent把设计改崩溃了防幻觉机制也不是越多越好。有一次评审Agent“用力过猛”针对一个已经验证通过的方案连续提出12条修改建议包括把容值翻倍、降低开关频率、更换控制器。规划层全部采纳后仿真结果反而变差纹波从42mV恶化到110mV效率也下降了几个百分点。排查后确认评审Agent提的建议本身都有道理但它们是针对不同约束条件单独提出的没有做全局协同。过多约束同时生效反而破坏了原方案在关键指标上的平衡。修复方式是在Harness中加入建议合并与冲突检测机制评审建议先汇总再由规则引擎评估“采纳后对其他指标的影响”影响不可控的建议会被降级为“可选建议”。从那以后这类“好心办坏事”的问题基本不再出现。5.5 防幻觉效果的量化评估经过三轮迭代我把防幻觉机制的拦截数据做了一次简单统计。在100次设计任务中改动前后对比结果如下器件型号幻觉从平均每任务0.8次下降到0.05次公式参数错误从平均每任务1.1次下降到0.12次上下文矛盾从平均每任务2.3次下降到0.4次仿真不达标的“空跑”轮次从平均每任务4.2次下降到0.6次这个结果说明防幻觉不能指望模型本身“变诚实”而要通过工程手段让幻觉失去输出机会。Harness框架的核心价值就是把这套工程手段系统化了。6. 最后聊一点我实操后的体会这套架构搭建下来的最大感受是与其说我在做Agent不如说我在做一套“面向硬件设计的质量体系”。真正有价值的不是让模型能说会道而是让它在每个关键节点都“说不了谎”。如果你也想复现这套思路我建议从两个最小闭环入手。第一先把器件检索和事实核对跑通哪怕只管两三颗电感和电容的选型第二选定一个你最常用的电源拓扑把公式库和仿真模板建起来。这两个闭环覆盖了电源设计中最容易出现幻觉的两个环节风险控制住了其他环节的容错空间自然就大了。最后再分享一个小技巧Harness的校验规则不要一次写全先从“单位检查”和“字段完整性检查”做起跑一段时间看拦截日志再针对高发错误增加规则。规则不是越多越好覆盖关键风险的规则才有意义。这套系统现在还在持续迭代中后续我计划把物料清单价格和供货稳定性的实时数据接入检索工具让设计出来的方案除了电性能可靠成本和可采购性也能一次性达标。