★ FEATURED ARTICLE 做电源硬件设计这几年我越来越依赖大模型来加速方案调研但也被它坑过不止一次。最典型的一次是我让它帮忙给一个12V转1.2V的同步降压电路提供环路补偿参数它居然一本正经地写了一个Type II补偿器传递函数零点位置完全反了还特别自信地标注了仅供参考。那一刻我突然意识到在硬件设计这个容错率极低的场景里模型幻觉不是体验问题是安全等级问题。所以后来我基于DeepSeek Harness搭了一套面向电源硬件设计的agent智能体架构核心目标只有一个防幻觉。这篇文章把整套架构的思路、实现细节、踩坑经验和后续演进方向完整分享一下。适合两类读者一类是正在做agent落地、被模型幻觉折磨得头疼的应用开发工程师另一类是做硬件设计自动化、想引入AI辅助但不敢放手的朋友。我会尽量把架构讲得具体一点包括Harness层到底控制了什么、三道防幻觉防线怎么协作、以及在真实任务里agent怎么一步步把自然语言需求变成带证据链的选型报告。如果你也想给自己的大模型应用装上安全阀这篇文章应该能给你不少可复用的思路。1. 为什么电源硬件设计是大模型幻觉的重灾区1.1 模型很会自信地犯错先说清楚一个很多人忽略的事实大模型的流畅度和事实准确度是两回事。它本质上是一个概率性的文本生成器每输出一个词都只是在上下文条件下选择概率最高的下一个词。这就意味着只要一段话在语料里长得像合理的工程结论它就可能被生成出来哪怕里面的数字、公式、器件型号完全是错的。在电源硬件设计里这种自信地犯错比很多其他领域更致命。我总结了几类高频错误大家可以对照自己遇到过的。幻觉类型具体表现典型后果参数张冠李戴把MOSFET的VDS写成VGS或者把某颗料的热阻参数安到另一颗料上选型错误器件过压或过热烧毁公式错误传递函数形式对但极点位置、符号、量纲错环路补偿参数错误电源振荡器件型号编造给出一个看起来存在的型号规格书数据与实际完全对不上采购不到料或者拿错料打样约束丢失最大纹波10mV被模型当成尽量别超过设计不满足指标无法通过测试文献误引把反激拓扑的心得用来指导正激设计变压器设计错误磁芯饱和我自己踩得最深的一次是在一个demo项目里模型推荐了一颗升压二极管标称耐压60V。我留了个心眼查了下规格书发现实际应用中的开关尖峰已经接近75V真按它的选型直接焊上去上电就炸管。从那次以后我就决定不能直接让模型输出硬件设计结论必须有一种机制让模型的嘴被外部系统管住。1.2 电源设计的约束域极其苛刻电源设计本质上是一堆约束的合成输入电压范围、输出电压精度、纹波指标、效率目标、热设计、EMI要求、安规要求、物料可用性、成本上限、供应链风险。任何一个约束没满足设计都可能在原型阶段失败甚至到了量产阶段才爆雷。这种多约束强耦合的场景恰恰是大模型的短板。模型有很强的归纳能力和语言组织能力但并没有真正去做多约束优化和数值验证的能力。它可以告诉你buck变换器和boost变换器有什么区别可以帮你整理某颗器件的datasheet要点但一旦涉及这个设计是否满足所有约束条件它就只能靠看起来合理来编答案。还有一点大家容易低估硬件设计的迭代成本非常高。软件改一行代码重新部署可能只需要几分钟但硬件打样一次要几周改一次版可能烧掉几万块。如果模型的幻觉出现在环路补偿参数、磁性元件设计或者热耗散估算里等到板子焊好再去调试时发现问题损失已经不可避免。所以在做这套agent架构时我给自己定了一个铁律模型只做它擅长的事——理解需求、翻译约束、拆解任务、组织报告至于事实性输出包括具体数值、器件型号、公式推导结论必须由外部工具链来产出。这个思路贯穿了整个架构设计。2. Harness到底勒住了什么agent架构总览与工具协议2.1 从调API生成答案到受控执行任务很多人在做AI硬件设计辅助时第一反应是给它写一个详细的提示词。但实测下来提示词工程在硬件设计这个高风险场景里根本不够用。原因很简单提示词本质上只是输入文本它能影响模型说话的倾向但不能强制模型引用什么计算什么不输出什么。模型的行事规则再严密它依然是在做下一段文字的概率预测而不是在执行一个可验证的任务。所以我把思路从生成答案换成了受控执行任务。核心载体就是DeepSeek Harness这套框架它负责把一次交互拆成多轮感知-规划-行动-校验循环每一轮里模型都只能做两件事之一——决定下一步调用哪个工具或者产出一段待校验的中间文本。模型确实自由但它的自由被限制在决策空间里而不是直接输出最终设计结论的空间里。这样做的直接好处是每一步都留下审计日志每个结论都能追溯来源每个数值都可以被独立校验。模型再想自由发挥Harness会在输出层拦截它。2.2 五层模块划分整套agent架构我划分成五个模块每一层干一件事边界尽量清楚。输入解析层负责把工程师的自然语言需求、参数表、简短备注解析成结构化规格。比如帮我看一个12V转1.2V、10A的buck方案会被解析成电压、电流、拓扑偏好的键值对。这一层很重要因为后续所有工具调用都以结构化规格为参数规格越干净幻觉的存活空间越小。规划器负责基于当前状态决定下一步动作。规划器的输出不是大段结论而是一个动作序列。例如调用器件库检索函数调用电感计算器生成选型报告请求审批。规划器拿到的上下文是经过隔离的不会把之前所有闲聊都塞给它。工具注册表把所有外部能力统一封装成可调用函数。器件库检索、公式计算器、SPICE仿真封装、文档RAG、审批请求工具全部注册在这里。模型只能看到工具的新增说明和参数Schema不能看到工具背后的实现。记忆隔离区这是防幻觉比较关键的一层。我把记忆分成用户规格区中间结论区证据区日志区。每个区域写入权限严格分离比如中间结论区只能存放工具返回且经过校验的结果模型自己生成的推测性文本只能进日志区不能污染结论区。输出渲染层最终报告不是模型直接写的而是渲染器从结构化数据里生成。报告里的每个关键参数都来自证据区的工具返回字段模型只负责给这些参数配文字说明。整体执行循环我用伪代码表示方便大家理解while not task_done: state gather_state(agents_memory) plan model.decide_next_action(state, tools_schema) if plan.action call_tool: result execute_tool(plan.tool, plan.arguments) validate_result(result) # 校验层 store_to_memory(result, zoneevidence) elif plan.action ask_human: request_approval(plan.pending_item) wait_for_response() elif plan.action finish: mark_step_finished() else: log_free_text(plan.text) # 自由文本只能进日志不能进报告2.3 工具调用协议的设计为了让校验器能检查模型的每一个动作工具调用必须结构化。我给每个工具定义了严格的JSON协议模型生成的参数必须符合Schema校验否则Harness直接拒绝执行并让模型重新规划。举个例子器件库检索工具的调用格式长这样{ tool: parametric_search, action: query, params: { component_type: power_mosfet, vds_min: 40, rdson_max: 15, package: SO-8 }, strictness: hard_constraint }注意参数名必须完全匹配值范围必须合法。如果模型把vds_min填成大约40左右或者漏掉了package字段解析器会直接报错。这个机制看似简单却是防幻觉的基础设施只有结构化的调用才能被程序精确校验自由文本里的任何建议值都是不可校验的。3. 三道防幻觉防线把模型说话权交给检索器、计算器和审批流3.1 第一道RAG检索约束——只允许模型引用有主文档的知识防幻觉的第一步是让模型的语言表达有据可依。我一开始用普通向量库接RAG很快发现问题通用向量检索只按语义相似度打分经常会召回一些看起来相关、其实不适用的文档。比如我让agent查同步整流buck设计向量库召回了三篇文档其中两篇是反激电源的设计心得因为里面也提到了同步整流这个关键词。如果模型足够自觉它会忽略不相关文档但模型不够自觉它可能把反激的变压器设计建议直接用在buck上。所以我把知识库升级成强标签硬过滤的方案。每篇文档在入库时必须打上强制元数据适用拓扑、适用功率段、适用输入电压范围、文档版本、审批状态。检索时除了语义相似度还必须过一遍硬过滤规则。文档标签与应用场景不匹配的直接排除根本不会进模型的上下文。比如当前任务是buck任何标签不含buck的文档都不会被召回。另外我在Harness里加了一个证据引用协议模型在输出任何断言时必须附带来源ID这个ID对应证据区里的某条工具返回记录。没有来源ID的断言在最终报告渲染时会被自动标记为未经证实并默认靠后排版。这一步执行之后模型随口引用的现象明显减少因为它知道没有证据的话会在最终报告里被高亮出来显得很不可靠。3.2 第二道确定性计算器双轨校验——能算的绝不让模型猜这是整套架构里最硬的一道防线也是我认为最核心的一条模型不输出任何具体数值所有数值由确定性计算器产出。让我用一个实际的buck电感计算来说明。假设输入规格是Vin12VVout1.2VIout10A开关频率600kHz电感电流纹波系数取20%。那么占空比D大约等于D Vout / Vin 1.2 / 12 0.1。电感值可以用公式计算L (Vin - Vout) × D / (ΔI_L × f_sw)ΔI_L 20% × 10A 2A代入后L (12 - 1.2) × 0.1 / (2 × 600000) 1.08 / 1200000 ≈ 0.9µH这个计算过程完全由工具链里的电感计算器完成模型不参与数值运算它只负责翻译用户需求告诉计算器纹波系数取20%合理然后计算器返回0.9µH。下一步再调用标准电感库检索工具返回最接近的标准值比如1.0µH并附带这颗电感的额定电流、DCR、饱和电流等参数。整个过程模型只是一个消息路由角色而不是知识库角色。有人会问那模型输出的建议还有什么用有用的地方在于方案层面的判断和解释比如在什么条件下可以考虑用耦合电感代替独立电感或者在环路补偿里Type II和Type III补偿器的选择逻辑。这些是策略性知识模型可以引用文档来组织语言但具体的R、C数值必须由s域计算器或环路仿真工具算出来。3.3 第三道人工审批闸门——关键节点必须挂起就算前面两道防线都到位了仍然不能完全信任自动流程。硬件设计最大的特点就是安全永远优先某些关键决策如果直接让agent拍板一旦出错代价非常高。所以我设计了人工审批闸门。具体来说有三类动作必须挂起等待工程师确认拓扑变更比如从buck拓扑切到buck-boost会影响整个设计方向必须人工审批。新器件导入凡是检索结果里没有历史使用记录的物料必须由工程师确认规格书、封装、货源之后才能加入选型列表。安全边界调整任何涉及电压、电流、温度安全阈值的改动都必须人工确认。agent在执行到这些动作时会调用审批请求工具把相关证据打包成结构化卡片推送给工程师。工程师在界面上可以批准、驳回或修改参数反馈再写回记忆区。这个机制把风险决策牢牢控制在人手里agent只是辅助。我遇到过一种情况agent在检索MOSFET时找到一颗参数更好的器件但它的封装和现有PCB布局不匹配。换了它可能电气性能更好但PCB改动成本很高。这种trade-off决策对模型来说太难了它根本没有成本概念。所以这类边界我不让它自动做决定一律挂起。3.4 三道防线之间怎么协作三道防线不是各管一段而是像流水线一样协同工作。我把完整请求流概括成一张表流程节点执行者防幻觉机制需求解析规则引擎模型结构化规格硬约束字段强制拓扑/器件检索工具链强标签过滤只返回匹配文档数值计算确定性计算器模型不输出数字只路由参数方案组织模型每个断言必须带来源ID报告渲染渲染器纯模板生成关键参数来自工具返回安全决策人工拓扑变更、新器件、安全边界挂起审批实际跑起来的效果是模型的自由发挥被压缩到了方案解释和文字描述这些低风险地带所有高风险输出全部被工具链接管。这也是我说的把模型说话权交给检索器、计算器和审批流的含义。4. 模型死都不听话的排错实录五个典型幻觉漏网案例就算架构设计得再完备真正实现的时候模型也有一百种方式不听你的话。我把这几个月里踩过的典型坑挑五个出来按现象-排查链路-修复方案的结构讲方便大家复现排查思路。4.1 模型绕过程序直接在回答里写参数现象我明明已经在工具注册表里定义了计算器工具也告诉模型电感数值必须由计算器返回但模型在最终报告的文字段落里仍然自己写了一个建议电感值10µH跟计算器返回的0.9µH差了一个数量级。排查链路我回头看每一轮日志发现模型确实调用了计算器工具也正确返回了0.9µH但在生成最终文本时模型并没有从工具返回字段里复制数字而是按照自己的惯性补了一句。这就等于工具逻辑和文本生成完全脱节了。修复在输出渲染层加了一个校验器专门扫描最终报告里的关键参数和证据区工具返回值做比对。不一致的话直接拒绝渲染并把报告打回给模型重写。后来我把报告改成模板渲染模型只提供文字描述具体数值全部以证据区字段填充从根上消灭了这个坑。4.2 RAG召回看起来相关、其实不适用的资料现象某次让agent总结正激变换器变压器设计要点模型在结论里引用了反激变压器的气隙设计建议。反激和正激的变压器工作机理完全不同气隙处理逻辑也不一样这是明显的常识性错误。排查链路我发现检索器确实召回了那篇反激文档原因是文档标题里有变压器设计这个关键词语义相似度打分超过了阈值。模型拿到文档后没有能力判断拓扑是否匹配就直接引用了。修复给知识库文档强制打拓扑标签和多维元数据检索后加硬过滤。同时修改提示词明确要求模型如果检索文档的拓扑标签与当前任务不匹配必须忽略并说明。从此这类交叉引用错误几乎消失。给知识库建索引时的元数据质量决定了整个RAG防幻觉能力的天花板。4.3 多步规划中的结论被覆盖现象agent在前几步已经确认选用某颗MOSFET并且把选型理由写进了中间结论区。但跑到第五步做损耗估算时模型又突然想到另一颗器件在文本里建议替换导致最终报告前后矛盾。排查链路日志显示前一步的工具检索结果和结论都没问题问题出在规划器的上下文。规划器看到的上下文是拼接起来的模型在规划下一步时把之前的所有文本都当成参考结果被一个不太相关的中间推测带偏了。修复引入记忆隔离。每个阶段的结论区是独立锁存的只有显式执行替换器件工具并经过审批确认阶段结论才会被改写。模型在规划时只能读取结论区的只读快照不能自行修改。这意味着模型的突发奇想只能停留在日志区不会污染正式结论。4.4 模型对硬约束的软化现象用户需求里写了输出电压纹波最大10mV这是硬指标不能超。模型在方案里写的是建议将纹波目标控制在10mV以内如果实现困难可适当放宽至15mV。这等于把硬约束直接软化了。排查链路我检查了输入解析层发现解析时把10mV提取成了数值但必须满足这个语义被丢掉了。模型拿到缺失约束语义的规格后自然把10mV当成了软建议处理。修复在输入解析层增加规则引擎专门负责识别硬约束词。解析后生成一个独立的约束声明文件其中包含字段is_hard: true。这个声明文件全局可见并在每一步工具调用前做断言检查。比如硬约束vin_min10.8V检索器件时只要某颗料的VDS低于该值就直接排除。硬约束的识别和传递不经过模型语义规则引擎直出杜绝软化。4.5 长篇报告的数字漂移现象agent生成最终报告时正文里说效率预计88%但前面的损耗估算表格里写的却是效率86.5%。不是模型故意改数字而是模型在写长文本时忘了前面表格里的精确值随手圆整了一下。排查链路报告生成阶段我最初让模型直接写整篇报告虽然每个关键参数都来自证据区但模型在复述时发生了记忆漂移。这其实和agent记忆隔离关系不大纯粹是长文本生成的问题。修复彻底废除模型写整篇报告的模式改成结构化渲染。报告是一个固定模板所有数字字段由渲染器从证据区直接填充模型只负责填充方案说明这类文字字段。你会发现当模型不再承担复述数字任务时数字漂移问题直接从根上消失。以上就是我踩过最深的五个坑。可以看出每一个修复方案的核心都是同一个原则减少模型对关键信息的直接表达权。这听起来有点反直觉但恰恰是硬件设计agent能真正落地的基础。5. 一次完整的防幻觉电源设计任务从自然语言到带证据链的选型报告理论讲再多不如看一次实际运行过程。下面用一个12V转1.2V/10A同步降压电源的完整任务展示agent是怎么一步步走的。5.1 输入解析与约束抽取工程师输入了一段自然语言需要设计一个12V转1.2V的稳压电源输出电流10A纹波尽量小效率要高于88%环境温度最高60度。帮我看看用同步buck合不合适顺便推荐一版关键物料。输入解析层输出结构化规格{ vin_min: 10.8, vin_max: 13.2, vout: 1.2, iout_max: 10, vout_ripple_max: 10e-3, target_eff_min: 0.88, ambient_temp_max: 60, topology_preference: sync_buck, is_hard: [vout_ripple_max, target_eff_min, ambient_temp_max] }注意纹波尽量小这种模糊描述没有被直接采纳规则引擎发现它是一个非硬约束所以最终用的纹波目标是工程师后面补充的10mV并且标记为硬约束。这样后续所有计算和选型都必须让纹波不超过10mV。5.2 拓扑选型与器件检索规划器根据规格决定先查拓扑库。工具链根据占空比D≈0.1和功率等级12W返回了同步buck拓扑的适用性报告证据来源是一篇经过审批的拓扑选型指南。接下来是MOSFET选型检索。工具返回了候选列表每条候选都包含完整参数。模型不直接推荐某颗料它只负责生成检索条件然后按预定义评分规则对结果排序。器件编号VDS(V)RDS(on)(mΩ)栅极电荷(nC)封装SOA判断M1408.512SO-8满足M2406.218QFN满足M3307.015SO-8VDS余量不足排除这个排序和SOA判断由规则代码执行模型完全没有参与数值判断。它只在最后给每颗料的优缺点补充说明文字并且每句话都带来源ID。5.3 计算器计算关键参数电感计算器返回结果0.9µH。标准值库检索返回最接近的标准品1.0µH附带饱和电流15A、DCR 3.2mΩ。输出电容计算器根据纹波约束反推出所需容值和ESR上限。损耗估算器基于上述器件参数计算各部分损耗上管导通损耗、下管导通损耗、开关损耗、电感铜损、驱动损耗等最终累计效率约87.2%。这个数值不满足88%的目标于是agent提出两个优化建议换用栅极电荷更低的M1或者把开关频率从600kHz降到500kHz以减小开关损耗。但这两个建议都被标记为待验证方案没有直接写入最终结果。5.4 报告生成与审批最终报告由渲染器从证据区数据生成。报告里每个设备编号、每个关键参数、每个计算过程都带可追溯证据。同时agent抛出一个审批卡片由于M1这颗MOSFET在历史选型库中没有使用记录属于新器件导入需要工程师确认。工程师在界面上批准了M1替换方案审批意见写回记忆区。agent随后更新结论区最终报告锁定。整个过程从用户输入到审批完成大约用了两分钟其中模型真正参与的部分只占很小一块大部分时间是工具链在计算和检索。这就是我认为这类agent应该有的工作状态模型负责调度和解释工具链负责事实人负责最后拍板。6. 下一步演进我准备把agent推向确定性优先的4个方向这套架构跑通后效果已经比裸用大模型可靠太多但我心里还有几个后续方向想逐步把agent从防幻觉推向更彻底的确定性优先。6.1 把SPICE仿真结果做成最高证据源目前部分关键参数来自公式计算器公式毕竟是对实际电路的一阶近似。下一步我准备把仿真工具封装成agent的一个工具让agent在给出最终建议前先跑一轮SPICE仿真验证环路稳定性和瞬态响应。仿真结果直接作为最高等级证据凡是仿真结果与公式计算差异较大的地方以仿真为准。6.2 从向量RAG升级到知识图谱向量检索擅长找相似的段落但硬件知识是强结构化的拓扑决定公式公式决定器件参数器件参数决定损耗和热设计。这些关系用知识图谱来表达要比向量检索可靠得多。我计划把知识库改造成图谱结构让agent按图遍历来获取知识而不是靠关键词相似度碰运气。6.3 批量设计矩阵现在的agent一次只处理一个设计任务。后续我准备让它支持批量输入规格组合自动遍历几十组Vin/Vout/Iout组合生成候选设计矩阵。工程师只看异常项和边界项正常情况下不需要逐个确认。这会大幅提高前期的方案筛选效率。6.4 给agent写专业测试用例软件工程里有单元测试和回归测试硬件agent也该有。我在计划为每个设计决策写一批断言规则类似当Vout大于Vin时拓扑候选列表不得出现buck当环境温度60度时所有功率器件的结温不得超125度环路相位裕度必须大于45度。这些断言作为硬性检查项挂在agent的每一步工具调用之后相当于给agent装上了一整套硬件设计的自动考官。我个人的体会是做agent开发最难的不是让模型更聪明而是让它学会在关键时刻闭嘴把事实交给代码去说把决策交给流程去管。这个过程有点像锻炼一个能力很强但太爱表现的新人工程师你需要给它一个清晰的作业规范还要在关键节点设置复核岗位。等到它真的能在规范里高效工作时你会发现自己轻松了很多而且再也不用熬夜检查它有没有在一本正经地胡说八道。
阅读完成 · 觉得有帮助？
