做过硬件的人都知道电源设计这行最怕的不是你不会算而是你以为算对了。一个Buck电路的占空比算错5%可能只是效率难看一点但一个MOSFET的耐压裕量取错批量回来后就是冒烟、打火、甚至返工整板。这类错误有一个共同特征它们都来自看似合理的推理。而大模型恰好是最擅长产出看似合理内容的工具——所以当我开始用Deepseek做硬件设计辅助时第一诉求不是让它多能干而是让它少犯错。这个项目就是用Deepseek Harness搭建的一套专门面向电源硬件设计的防幻觉Agent智能体架构。它不是简单地把Deepseek的API包一层Prompt而是把模型自由生成改造成流程约束求解让模型只负责推理和决策所有数值计算、器件选型、参数校验全部交给确定性工具链。目标很明确把AI当成一个话很多但手指很准的助理而不是一个什么都敢说的百科。这篇文章我会完整分享这套架构的设计思路、防幻觉的落地手段、关键代码实现以及我在实际调试中踩过的坑。如果你也在做LLM Agent类的工程化项目尤其是垂直领域的医疗、硬件、财务、法律这套约束优先、工具兜底、验证闭环的思路应该能直接抄作业。1. 这个项目到底解决了什么问题1.1 电源硬件设计里的高成本犯错先说场景。电源硬件设计从需求到量产中间要经历规格解析、拓扑选型、器件计算、环路补偿、热设计、PCB布局、仿真验证等环节。每个环节都有大量经验性的数值判断比如输入12V、输出3.3V/5A的Buck变换器开关频率选多少合适电感纹波电流取输出电流的20%~40%但饱和裕量要留多少输出电容的ESR纹波与陶瓷电容的降额系数怎么联合约束环路补偿的穿越频率一般取开关频率的1/10~1/5相位裕量要大于45°功率MOSFET的耐压要按输入电压的1.5~2倍降额。这些规则不是不能写在文档里但新手很容易记混——比如把Buck的占空比公式记成Vout/Vin反激的反射电压算错或者直接把某个参考设计里的电感值抄过来但没核对频率。这些都是典型的看起来对实际上错。大模型的加入放大了这个问题。你问Deepseek12V转3.3V/5A用什么拓扑它会给出正确答案但你问它帮我算一下这个设计里输出电容的容值它可能会基于一个你根本没给出的纹波要求自行假设一个纹波率然后给你算出一个漂亮的结果。这个结果在数学上自洽在工程上完全没有依据——这就是幻觉。1.2 为什么通用Chat类Agent在硬件设计中不可用我最早尝试的方案很简单把Deepseek的API接进来写好系统Prompt让它扮演资深电源工程师然后直接对话设计需求。测下来的结果很有意思拓扑推荐、概念解释这类定性问题回答质量很高涉及具体数值计算时准确率大概只有60%左右更危险的是它会在计算中自己脑补缺失参数比如你只说了输入12V输出3.3V它默认你用了300kHz开关频率、默认电感纹波20%、默认用某款料号——然后给你一串貌似严谨的结果追问它这个电感饱和电流怎么算的它还能一本正经地编一个推导过程。我意识到问题不在模型本身而在架构。你让一个对话模型直接面对需要精确数值输出的任务它一定会用下一个词预测的方式猜一个数值哪怕它背后并没有真正计算。这不是Deepseek的缺陷是所有生成式模型的工作原理决定的。所以方向变了不要试图让模型算得更准而是让它根本不直接计算。所有必须精确的环节全部拆出来交给确定性工具。2. 为什么用Harness而不是直接堆Agent2.1 Harness和Agent的区别先澄清一个概念。很多朋友问我Deepseek Harness是什么和Agent有什么区别这里我先说结论Harness不是Agent它是Agent外面的那层安全带和操作台。Agent是一个智能体它具备感知-决策-行动的循环能力可以自主调用工具、分解任务、决定下一步做什么。而Harness是承载这个循环的工程框架它规定了Agent每一步能做什么、不能做什么、怎么做、做完之后结果如何被验证。你可以这样理解Agent是司机Harness是装了车道偏离预警、限速器、强制制动系统的驾驶舱。司机技术再好该有的约束还是得有——尤其是当他拉着一车高价值货物的时候。在我这个项目里Harness承担了四件事任务编排把做一个电源设计拆成解析规格→选拓扑→算参数→选器件→跑校验→生成报告的固定流程Agent不能跳步工具注册与路由只暴露经过封装的计算函数和数据库接口Agent无法绕过去自行计算输出约束强制Agent以结构化JSON输出中间结果与最终结果所有自由文本必须附在JSON的解释字段里不允许夹带数值结论验证拦截Agent每产出一个关键数值Harness都会调用独立的校验工具做交叉检查不过关直接打回重新生成。2.2 防幻觉的核心把自由发挥变成约束求解折腾了这么久我总结出一句话防幻觉的本质不是提高模型的准确性而是缩小模型的自由空间。模型最喜欢的是开放问题最怕的是强约束问题。所以在Harness里我做了三件事来压缩自由空间用枚举替代填空拓扑类型、器件类型、降额标准、纹波系数范围全部定义成枚举值或者区间值。模型只能从给定集合里选不能自己发明参数。用工具替代口算任何数值输出的背后都是Python函数在算模型只负责提供输入参数和选择公式。比如电感计算模型只需要给出拓扑Buck、Vin12、Vout3.3、Iout5、纹波系数0.3、频率300k剩下的是工具函数的事。用交叉验证替代信任算完之后Harness会从另一个角度复算。比如电感算完了反过来计算该电感下的纹波电流是否在设定范围内如果偏离超过阈值就判定为计算链断裂要求Agent修复。这样一套组合拳下来幻觉空间被压到最小。模型仍然可能觉得某个参数合理但在工程上不适用但那是下游规则校验器要拦截的事不在推理环节里放任。3. 整体架构设计3.1 分层架构总览整套系统我分了五层每一层职责单一方便单独测试和替换层级模块职责交互层需求解析器把用户输入的非结构化需求转换成结构化设计约束Harness编排层流程引擎、状态管理控制Agent执行流程记录上下文与中间产物领域工具层计算引擎、器件库、降额规则库、仿真接口提供确定性的计算与数据查询能力防幻觉校验层Schema校验器、数值边界检查器、一致性复算器对Agent每一个关键输出做强制检查模型层Deepseek推理模型、判别模型负责语言理解、方案决策、文本生成这五层里真正智能的部分只有模型层其余全部是确定性代码。这是我刻意为之的结果智能部分越少越好确定性部分越多越好。交互层做的事情很杂但很重要。用户可能说我要做一个12V输入的模块电源输出3.3V给FPGA供电电流大概5A板子空间有限。需求解析器要把它拆成结构化字段InputVoltage12VOutputVoltage3.3VOutputCurrent5ABoardArea受限LoadTypeFPGA核心供电。其中FPGA核心供电会进一步映射为需要低纹波、快速瞬态响应于是后续的拓扑推荐会偏向Buck而非LDO。3.2 关键设计工具调用优先于模型计算在这个架构里我把工具调用设为Agent唯一合法的数值产出通道。具体规则如下Agent生成的内容分为两类决策性文本和数值声明所有数值声明必须附带tool_call_id表明该数值来自某次工具调用没有工具调用ID的数值一律在Schema校验阶段被标记为未验证来源并拒绝Agent可以建议参数比如建议开关频率300kHz但最终算出来的电感值、电容值必须由工具函数返回。为了实现这个机制我在工具函数的返回里加了来源元数据{ status: success, data: { inductance_uh: 3.3, ripple_current_a: 1.2 }, source: { tool: buck_inductor_calc, inputs: { vin: 12, vout: 3.3, iout: 5, ripple_ratio: 0.3, frequency_khz: 300 }, formula: L (Vin - Vout) * D / (delta_I * fsw) } }这样每一步都有完整的溯源性。后续无论是人类审查还是机器校验都能逐级回溯这个3.3uH是怎么来的、用了什么公式、输入参数是什么。这正是硬件设计行业最看重的可追溯性。3.3 数据来源与溯源电源设计离不开器件选型而器件选型又是模型幻觉的重灾区——大模型会一本正经地推荐一个型号然后这个型号要么停产了、要么封装不对、要么耐压根本不够。我给这个问题的解法是模型只负责表达意图不负责记忆料号。Harness里内置了一个器件数据库检索工具。模型收到需要一颗耐压30V左右的同步Buck上管MOSFET这类需求时它只能调用search_components工具去数据库里查查到什么就用什么查不到就如实说数据库中没有满足条件的物料。更狠的一点是即使用户在Prompt里主动给出了料号比如用TI的TPS54360做个方案模型也必须先去数据库核验这颗料的真实参数核验失败就拒绝采纳不能顺着用户说。这在防幻觉里是一个非常重要的设计原则永远不要让用户输入直接变成Agent的输出。用户的话要经过解析-核验-采纳三道关才能进入设计方案。4. 核心环节实现4.1 Harness编排流程实际跑起来的时候Harness的主流程是这个样子的def run_design_flow(user_request: dict): # 第一步结构化解析 constraints parse_requirements(user_request) # 第二步拓扑选择模型决策 规则校验 topology agent_choose_topology(constraints) if not check_topology_rules(topology, constraints): raise DesignFlowError(拓扑选择不满足约束) # 第三步参数计算工具链 design_params calc_design_params(topology, constraints) # 第四步器件选型数据库检索 components select_components(design_params, constraints) # 第五步防幻觉校验交叉复算 validation_result validate_design(topology, design_params, components) # 第六步生成设计报告 report generate_report(topology, design_params, components, validation_result) return report流程是强制线性的Agent不能跳过校验直接生成报告。我在早期版本吃过这个亏Agent发现校验环节算出来结果和自己想的不一样就很聪明地在报告里写了另一个值还附了一段看起来合理的解释。后来我在流程引擎里加了硬约束——报告中的所有关键数值必须取自design_params对象任何与对象不一致的数值都会被标注并拒绝发布。4.2 防幻觉校验链路的落地细节防幻觉不是靠一个校验函数搞定而是靠一条链路。我的实现里包含四个校验步骤第一层Schema校验。Agent输出的JSON必须满足预定义的schema字段类型、枚举值、必填项都必须符合。例如拓扑字段只能是Buck|Boost|Buck-Boost|Flyback|Forward|LLC|LDO多一个别的词直接失败。第二层数值边界检查。每个关键参数都有工程边界。比如输出电容的ESR不得超过XX毫欧、电感饱和电流至少是最大峰值电流的1.2倍、MOSFET耐压至少要达到输入电压的1.5倍。这些边界来自行业规范和项目经验是最硬的一层约束。第三层一致性复算。独立于Agent的计算引擎按照设计公式重新算一遍。重点检查Agent交付的参数与初始约束条件是否矛盾。举个例子Agent交付的电感值是3.3uH复算函数会代入纹波电流公式算出来的纹波百分比如果超过预设的30%就报警。第四层多候选交叉验证。同一个设计问题让Deepseek用不同的温度参数temperature0.2和temperature0.8各生成一版方案然后比较两份方案的关键参数是否一致。如果差异过大说明模型在该环节处于不稳定推理状态方案需要人工介入。这个方法不是100%准确但能有效筛掉一部分随机性很大的幻觉输出。4.3 一个完整的BUCK电源设计实例拿一个最常见的设计来演示12V输入3.3V输出5A负载开关频率300kHz纹波率取30%。Agent接到任务后Harness按流程走步骤一规格解析。需求解析器输出结构化约束拓扑候选[Buck]Vin12VVout3.3VIout5Afsw300kHzripple_ratio0.3。步骤二拓扑选择。模型判断输入12V输出3.3V降压比约3.6倍电流5A属于典型的非隔离Buck场景。规则校验通过。步骤三计算。这里模型不做算术而是调用工具函数# 占空比 D Vout / (Vin * efficiency_guess) D 3.3 / (12 * 0.9) # 约0.306 # 电感纹波电流 delta_I Iout * ripple_ratio 5 * 0.3 1.5A # 电感量 L (Vin - Vout) * D / (delta_I * fsw) # (12 - 3.3) * 0.306 / (1.5 * 300000) # 8.7 * 0.306 / 450000 # 5.9e-6 H ≈ 5.9uH工具函数实际返回5.9uH并推荐取标称值6.8uH考虑磁芯损耗和直流电阻后取更接近的标准值。步骤四器件选型。模型发起数据库查询输入12V、输出3.3V/5A的Buck设计需要电感饱和电流至少大于峰值电流5 1.5/2 5.75A取1.2倍裕量即6.9A耐压需大于12*1.518V的MOSFET。数据库返回候选器件列表模型筛选后选定型号所有料号都带数据表来源链接。步骤五校验。一致性复算器把6.8uH带回去算纹波电流delta_I (12 - 3.3) * 0.306 / (6.8e-6 * 300000) 8.7 * 0.306 / 2.04 1.31A ripple_ratio 1.31 / 5 26.2%26.2%落在15%~40%的合理范围内通过。步骤六报告生成。模型把上述过程整理成设计报告包含参数计算过程、器件选型理由和校验结论。全程没有任何一步依赖模型心算所有的数字要么来自工具函数要么来自数据库。5. 常见问题与排查实录5.1 幻觉问题排查速查表实际调试过程中我遇到了不少问题整理成一张速查表供大家参考现象根因解决方案Agent推荐了数据库里不存在的料号模型在用训练记忆编造型号禁止模型直接输出料号必须走search_components工具工具返回后模型只能从结果中选择计算参数在两次运行间不稳定采样随机性导致的非确定性降低temperature到0.2以下用带tool_call的确定性工具输出覆盖模型数值交叉复算与Agent交付值不一致Agent在文本中夹带了自己算的数值加强Schema约束只允许读取工具返回字段文本中禁止携带数值校验器把合理设计误判为异常边界规则过于严格或公式不一致将复算公式与工具函数统一为同一代码模块避免两套公式因精度而打架Agent跳步直接生成报告流程编排不够硬在流程引擎中设置状态机前置状态未完成禁止进入报告生成步骤其中两套公式打架这个问题必须单独强调。早期我在工具函数和校验模块里分别写了一遍公式结果工具用的是浮点精确计算校验器用了四舍五入的简化版导致明明参数没问题却报复算不一致。后来把所有公式统一下沉到一个power_math模块工具和校验都调用同一个函数这个问题彻底消失。5.2 工程化避坑经验再分享几个从实操中总结的细节这些坑文档里一般不写第一Prompt里的数值禁忌要写得极其具体。我试过在系统提示词里写请确保所有数值来自工具调用效果几乎为零。真正有效的是在输出Schema里把数值字段全部标记为readonly并让流程引擎在合并模型输出时直接丢弃模型自带的数值字段换成工具函数的返回值。第二防幻觉要防的是局部幻觉而不是全局幻觉。模型大部分时候是靠谱的最危险的是它在某个环节自以为是一下。比如拓扑选对了、频率给对了但电容的ESR限制条件记错了导致选了个ESR偏高的大电容。针对这类局部幻觉我采用环节级校验而不是流程级校验——每个环节结束都要做一次局部检查不等到最后统一验证。第三Deepseek的API并发和稳定性需要兜底。Agent流程长、环节多一次完整设计可能要调用5~8次模型接口。任何一个环节超时或返回异常会导致整个流程重跑成本很高。我在Harness里加了缓存层相同输入的工具结果和模型结果会缓存复用同时给每个环节加了超时重试和降级策略——模型超时时如果该环节是纯文本总结可以降级用模板填充如果是决策环节则直接报错让用户介入不硬扛。第四也是最有体感的一条一定要给Agent设计不知道就直说的通道。这个词用Prompt很难训出来但用架构可以。当数据库检索不到物料、当计算结果显示约束无解、当用户需求自相矛盾比如既要求极低纹波又要求极低成本Agent必须能输出无法满足原因如下而不是硬编一个方案。这个能力我在Harness里是通过一个constraint_conflict_detector实现的它预先检查约束组合是否可行比如纹波要求低于1%但板面积限定极小就直接在Design Flow入口拦住不让Agent进入后续流程。第五关于Harness的状态管理。一次完整电源设计会有大量的中间状态用户输入、解析结果、拓扑选择、计算参数、器件候选、校验结果。如果全塞在模型上下文里很快会超过上下文窗口而且会让模型遗忘早期约束。我的做法是上下文里只保留当前环节的输入摘要和关键约束列表其余全部存到独立的临时存储里模型层只拿摘要做决策。这个做法既省钱又防走偏——模型看到的上下文越精简越不容易自己加戏。6. 写在最后的实操心得搭这套架构我把市面上各种Agent框架试了一圈最后还是回归到一个很朴素的判断标准你这个场景里模型错了会怎样如果答案是会返工那就值得多做一层防幻觉如果答案是无所谓那用裸的Agent就行。电源硬件设计正好是最经不起看似合理错误的领域之一。我做这个项目的最大体会是大模型的角色应该定位在方案空间探索者和文档生成器而不是数值计算器和参数记忆库。前者是大模型的强项后者天然会触发幻觉。如果你也想在垂直领域搭类似的Agent我有几个建议可以直接拿走把所有模型算不准的事全部变成工具函数调用给每个关键输出加上来源追溯没有来源的数值一律不采信校验公式与计算工具必须同源不允许存在两套口径流程状态机化禁止跳步为Agent保留一条我做不到的合法出口。这套架构本身不复杂核心思路就是一句话给模型套上一套约束安全带把自由发挥的空间压到最低剩下的交给工具和规则去兜底。目前这套系统已经支撑了我这边多个12V转低压大电流的模块电源设计项目从方案选型到参数计算再到报告生成全流程可控。后续我打算把分立的仿真验证环节也接进来让仿真-修正-再仿真形成闭环到时候再和大家分享。