做电源硬件设计的Agent最怕的不是它答不上来而是它一本正经地给出一份看起来天衣无缝、实际会炸板的设计方案。这句话是我折腾了差不多一个季度的防幻觉架构之后最深的体会。今天想聊的是我们基于Deepseek Harness搭建的一套电源硬件设计agent智能体架构核心目标只有一个让大模型在关键规格、器件参数、热耗和环路稳定性这些要命的地方不敢乱说。这个架构本身并不高深甚至有点“笨”——它把大模型从“设计师”的身份里拽了下来强行降级成一个“只会写方案、不会定参数”的文案员。所有直接影响硬件能否正常工作的数值全部交给确定性工具、仿真器和人工审批门去把关。这篇分享我会把为什么这样做、每个模块怎么落地、实测中踩了哪些坑讲清楚适合正在做LLM Agent落地的工程师也适合对“如何约束模型输出”感兴趣的团队参考。1. 电源设计智能体的“幻觉翻车”现场为什么这件事比通用问答严重得多先讲结论通用场景下大模型偶尔幻觉最多就是回答不够准用户忍一忍也就过去了。但在电源硬件设计里一个数值错位就可能让MOSFET过压击穿、电感饱和烧毁、环路振荡失控。半导体器件的耐压、耐流、结温参数通常只有10%~20%的余量幻觉一次板子就可能炸一次。这不是“体验问题”是安全问题。1.1 三个让我后背发凉的实测案例第一个案例是Buck电感计算。需求参数是输入9V到18V输出5V/3A开关频率500kHz。Agent给出了一版很漂亮的方案47uH电感、SS34二极管、某型号MOSFET看起来结构完整。但当我们用数值计算器复核时发现47uH对应电感纹波电流只有约0.6A纹波率不足0.2电感体积大得离谱而且CCM模式的动态响应会非常迟钝。第二个案例是单位换算翻车。Agent计算MOSFET导通损耗时把Rds(on)从12mΩ写成0.012然后用0.012Ω去推损耗算出来的结果是正确值的百分之一。它还在报告里配了一段洋洋洒洒的热设计分析结论是“散热器可省略”。如果真按这个方案打样MOSFET会在满载工作几分钟后过热。第三个案例是“局部正确、整体错误”。Agent给输入12V~24V的Buck电路选了一颗耐压40V的MOSFET单独看没有任何问题。但它忽略了系统还有电源插拔瞬态实测场景下母线尖峰能到42V器件直接处在击穿边缘。这种跨约束的漏判恰恰是大模型最常见的一种“自信错误”。它不会告诉你“我不确定”它会非常流畅地告诉你“选这个没问题”。1.2 这些案例背后的共同本质表面看是“模型算错了”本质是LLM的生成机制决定的它做的事情始终是“下一个token的概率预测”追求的是语义通顺和模式匹配而不是数学上的精确。训练数据里如果到处都是“Buck电感常见值47uH”它就会在类似场景下优先复现这个值哪怕这套拓扑根本不适合。更麻烦的是电源设计是强耦合问题。输入范围、占空比、电感纹波、环路补偿、热耗、器件应力每一项都会互相影响一个参数的微小偏差会被后续计算放大。人在审查时还能靠经验察觉“这个数值不太对劲”但token预测模型没有这种物理直觉。它的一致性只体现在“文字层面”不在“物理层面”。所以我在架构设计第一天就定了一条铁律不信任任何直接由大模型生成的物理数值。凡是能通过公式算的必须用公式算凡是有器件库的必须查库凡是能仿真的必须仿真。Agent可以提出思路、组织方案、解释过程但最终交付的每一个数值都必须有外部工具背书。这一条是整个防幻觉架构的基石。2. 防幻觉架构总览把Agent当成“会说话的计算流水线”来设计我见过不少团队做LLM Agent上来就让模型“自由发挥”然后寄希望于写一段强约束的提示词就能避免错误。这在通用场景也许够用在电源设计里基本等于裸奔。我们的做法是把整个系统从单Agent改造成三角约束结构让模型只做它擅长的事把不擅长的事全部隔离出去。2.1 三个角色Planner、Executor、Verifier第一个角色是Planner也就是规划Agent。它负责拆解设计任务决定“接下来要算什么、查什么、验什么”。比如用户提出“输入12V输出3.3V/2A要求纹波小于30mV”Planner要输出一份结构化任务清单确定拓扑→计算关键参数→选型→仿真验证→生成物料清单。注意Planner不能直接输出器件参数。第二个角色是Executor工具执行层。它运行在一个受控的沙箱环境里能调用的只有确定的工具数值计算器、拓扑模板库、器件数据库查询、SPICE仿真器、功耗与热阻计算模块。这些工具的输出是可复现的、确定性的。Executor拿到Planner的请求后把参数塞进工具里跑然后把结果写回任务上下文。第三个角色是Verifier校验与审批层。它会针对Executor返回的结果做规则检查比如输入电压是否在器件耐压范围内、开关节点电压是否超过规格、电感纹波率是否在20%到40%的合理区间、环路相位裕度是否满足要求。Verifier拥有一票否决权它说不通过流程就回到Planner重新修正或者在重试次数用尽后转到人工。这种“三角约束”的本质是把大模型从决策中心变成一个中间节点。它产生意图但不产生最终答案。架构上的刻意冗余换来的是幻觉没有机会进入交付物。2.2 Deepseek Harness在我这里的角色这套三角结构我们是基于Deepseek Harness搭的。对我而言它更像一个“编排层容器”不负责具体计算但负责管理Agent的状态流转、工具注册、重试策略和上下文窗口。这些恰恰是防幻觉最容易忽略的地方。比如上下文窗口早期我们曾经把每一轮工具调用结果全部塞进记忆里导致模型越到后面越迷茫。Harness允许我们给每一轮任务配置独立的上下文摘要策略只把“本轮任务目标”和“最近一次失败原因”保留为结构化标签其他原始数据进入工具日志而不进入模型上下文。这个设计在减少上下文污染上起了决定作用。再比如重试策略Harness提供了一种状态机机制我们可以精确控制每个环节最多尝试几次、什么条件下跳到人工。没有这层控制的话Agent很容易陷入“失败—重试—再失败—换一种方式再试”的无限循环看起来在努力实际在浪费token也浪费工程师的耐心。所以我们这套系统的层级关系是Deepseek Harness管编排三角结构管职责边界工具链管数值正确。每一层各管一件事幻觉被压缩到最小可能。3. 数值合规层能不靠模型算的坚决不让模型算这一层是整个系统里我最想分享的部分。它听起来很朴素但实际落地工作量最大、收益也最直接。3.1 拓扑模板化把设计经验变成可执行的规则集我们为常见的Buck、Boost、Buck-Boost、反激等拓扑各建了一份“模板文件”里面不只有文字介绍还有一系列可执行规则。以Buck为例模板里定义了输入输出范围、允许的开关频率档位、占空比计算方程、电感电流纹波公式、CCM/DCM判定条件、输出电容纹波约束以及必须检查的“伏秒平衡”“伏秒积”等约束项。这套模板的核心作用是把多年硬件设计经验沉淀成机器可判定的边界。Agent在平面化文本里读到的“电感不能太大”到了这里就变成“纹波率r必须落在0.2~0.4之间超出则给Red Flag”。LLM擅长生成自然语言描述但自然语言描述不能直接变成checklist模板的作用就是把自然语言“翻译”成规则。我在实际开发中的一个体会是模板别贪多先覆盖最常用的三种拓扑就够了。把Buck的规则打磨到死远比做十个半成品拓扑强。这也是为什么我们的初始版本只用了一周就上线因为八成以上的电源设计需求都能落在Buck和Boost框架内。模板文件大概长这样buck_template: topo: buck vin_range: min: 4.5 max: 36 switching_freq: [100k, 200k, 400k, 500k, 1M] design_equations: duty: Vout / Vin delta_IL: (Vin - Vout) * duty / (L * fsw) output_cap_ripple: delta_IL / (8 * Cout * fsw) boundary_rules: ccm_mode: IL_min 0.3 * Iout ripple_rate: delta_IL / Iout between 0.2 and 0.4 output_ripple_lt: output_ripple user_spec.ripple_max3.2 强插计算器让LLM只给参数Python给结论这是最直接的防幻手段。具体流程是Planner生成设计方案时模型可以写出它认为合适的感值、容值、阻值但这些数值不会直接进入设计输出。我们有一个参数抽取模块会把模型给出的所有关键数值提取出来交给Python数值计算核验。核验模块会调用sympy和numpy重算一遍关键方程然后把“模型估值”和“计算值”放在同一张对比表里。回到前面那个Buck案例模型的47uH会被计算器标成“建议值为4.7uH~15uH按r0.3~0.4推算”随后Dont列表把这个差异显式报给用户。比较的关键在于容差设计所谓“对”不是要求数值完全一致而是要求模型估值落在计算值合理区间内。比如开关频率模型说500kHz模板允许就通过电感值模型说47uH计算合理区间是10uH左右就拦截。这本质上是一种粗粒度“幻觉检测”。我认为这是成本最低、见效最快的防幻觉层。不需要训练模型不需要改权重只需要写几百行解析和计算逻辑。3.3 单位归一化最简单但最容易被忽略的故障源单位翻车在电源设计里太常见了。mΩ和Ω、uH和nH、mA和A、°C和°F模型稍微飘一下就能差出三个数量级。我见过一个方案里把“2.2uH”写成“2.2nH”后面所有关于纹波、饱和电流的计算全部失真而且报告读起来依然很流畅。我们的方案是在参数抽取之后、进入规则引擎之前加一个强制“单位归一化层”。所有数值一律先转成SI基单位电阻转成Ω电感转成H电容转成F电流转成A温度转成K或°C统一。转换完成后做量纲自检比如功耗应该是“W”如果你算出来是“mW”在上下文里标注清楚再进计算。这一步花的时间最多不超过两天但能挡住至少30%的明显幻觉。越是经验丰富的工程师越容易在这种小地方掉以轻心因为人脑对数量级的惯性判断太强了模型也一样。4. 从选型到仿真的闭环校验先让Agent在虚拟世界“炸”三轮数值计算只是第一道防线。真正让方案可信的是把选型放到真实器件库、真实仿真环境里跑一遍。这个闭环跑通之后整个系统的说服力才算立住。4.1 自建元器件库Agent不能发明不存在的器件我们自建了一个器件库目前包含大约两千多个常用电源器件型号覆盖MOSFET、二极管、电感、电容、DC-DC控制器等。每个条目都录入了关键参数最大耐压、最大电流、Rds(on)、封装、热阻、是否在售、厂商推荐的工作电压范围等。库里的数据全部来自器件手册人工录入模型没有权限修改。为什么要这么“死板”因为大模型的一大幻觉特征就是会生造“听起来合理但实际不存在”的器件型号。如果允许模型自由选型你会在BOM里看到一家不确定厂商、不确定封装的“某型号”这在量产里是完全不可接受的。自建库把模型的选择空间锁死在真实可用物料里本质上是一种“穷举约束”。模型在选型时要求必须从库里选出器件并通过查询工具返回参数。如果库里没有合适的耐压等级模型只能如实说“库中暂未找到需要人工补充”绝对不能编一个。4.2 仿真回灌让仿真结果参与下一轮决策选型完成之后流程不是直接输出BOM而是先生成一份可仿真的网表提交给SPICE仿真器做运行验证。我们会跑三个典型场景满载稳态、负载瞬态、输入电压阶跃。仿真器会输出输出电压纹波、器件功耗、开关节点波形和环路Bode图。仿真结果会被回灌给Planner。如果满载纹波超过规格或者相位裕度不足45°Planner必须基于“具体问题清单”做修正而不是盲目重试。修正提示词会被刻意限制例如“上一轮仿真未通过问题为相位裕度38°满载纹波37mV。请仅针对这两个问题进行参数修正不要更改拓扑不要调整与问题无关的器件。”这种限定式修正是关键。否则模型很容易把原本正确的部分也推翻重来陷入“修复一个错误、制造三个新错误”的怪圈。我们还给修正循环设置硬上限最多三轮超过就直接转人工。4.3 评审Agent让另一个LLM专门负责找茬这里有一个反直觉的设计我们不仅用了LLM来干活还用一个独立的评审Agent来“挑刺”。主Agent负责设计评审Agent负责攻击。评审Agent的系统提示词里明确写着“你的唯一目标是从器件应力、热平衡、环路稳定性、EMI风险四个维度找出方案中的隐患不要让礼貌和协作妨碍你质疑。”评审Agent读到的材料是主Agent生成的设计结果、数值核验对比表、仿真报告。它不需要给出修正方案只需要输出“存在的问题清单”。这一层看着像多余实际能挡住不少主Agent的“自我确认偏差”——模型在生成方案时会倾向于维护自己生成的逻辑一致性哪怕方案有明显漏洞它也会在文字层面圆过去。独立的评审人视角能有效切断这种自我确认。当然评审Agent本身也是LLM也可能幻觉。所以它的输出同样要走规则校验给出的每一个问题必须引用仿真报告里的具体数值或器件库里的参数做不到引用就视为无效反馈。5. 实测中的连环坑上下文污染、工具空转和温度设置架构跑起来之后真正折磨人的不是原理而是工程细节。这里记录几个我们踩过的、修复后效果明显的坑希望能帮你少走弯路。5.1 上下文污染历史错误越描越黑最初版本没有做上下文摘要我们把每一轮工具调用的原始结果都塞进上下文让模型在完整历史中做决策。结果非常痛苦Agent一旦在前一轮犯过错后面的判断就很容易被错误数据带偏。比如它在选型时报了一个“48uH”后续所有计算都围绕这个错误值展开哪怕计算器已经标注“超界”模型也会尝试用各种语言去解释“这个值为什么合理”。修复方案是Harness层做了一个结构化摘要器。每一轮任务结束系统只保留三类信息当前设计目标、最近一次未通过原因用标签化文字描述、需要重新计算的参数列表。原始工具日志全部移出上下文只保留在系统的文件日志中备查。改完之后修正循环的速度明显变快模型被带偏的概率大幅下降。5.2 工具空转反复调用却不产出结论另一个高频问题是“工具空转”。模型为了完成任务会反复调用同一类工具比如连续查询某个器件十几次每次只是换一个封装条件或温度档位却不真正落下一个结论。表面上它在努力工作实际上是在用“查询日志”掩盖“没有决策能力”。我们给Harness设置了两个硬性规则单个工具调用次数上限默认6次超过后工具层直接拒绝执行并把状态改为“无法由Agent独立完成建议人工”同时任何工具调用结果如果不在最终报告中显式引用报告就不能生成。换句话说模型必须把“查到的数据”和“据此做出的决策”一一对应才允许输出。这招非常有效直接杜绝了“为了调而调”。5.3 推理参数的分段策略永远不要用同一套温度跑全流程我见过很多团队会困惑为什么同样一个模型在开放聊天里表现不错放到Agent流程里就频繁出错一个重要原因是温度参数没做分段。我们在实测中把整个流程切成三段使用不同的温度配置流程阶段温度设置说明任务规划0.3保留一定的方案发散空间参数生成0.0必须是确定性的、可复现的仿真修正0.1允许微调但不允许偏离约束评审与结论0.0找问题必须严谨不允许“创意发挥”把“发散”限制在规划阶段把“收敛”压在数值与评审阶段这套策略让系统整体的可复现性提升了很多。当然温度调到0不等于消灭幻觉但它确实能显著降低单位写错、数值漂移的风险。5.4 失败转人工的状态机设计最后一层防线是状态机。整个Agent流程明确定义为init→planning→calculation→verification→simulation→review→approved/manual。任何一步失败都会带着明确的失败原因标签进入重试队列。如果同一环节连续失败三次系统不再继续消耗token而是直接把当前所有中间结果打包成一份“待人工审查工单”转给工程师。这个设计做起来很简单但决策价值极高。它明确划定了Agent的能力边界可以自动驾驶但在不确定的路口必须靠边停车并呼叫人工。电源硬件这行工程师宁可自己手动验一遍也不希望Agent在错误方案上“强行完成”。6. 沉淀下来的一些工程化建议系统跑了大半个季度之后我觉得最有价值的不是某个具体模块而是整套“如何评测和约束智能体”的方法论。最后分享几条我们沉淀下来的工程建议。6.1 建立防幻觉回归评测集用历史设计案例做了一个小规模评测集一共二十来个Case覆盖Buck、Boost、反激等常见场景每个Case都有正确答案和关键边界条件。每次修改架构或提示词之后我们都会跑一遍评测集关注三个指标幻觉率、人工介入率、平均修正轮数。我会把“幻觉率”定义为通过所有校验和评审、但在人工抽查中被发现存在实质性错误的设计方案数量除以总方案数量。这个指标听起来很严格但它就是防幻觉系统的核心KPI。没有评测集的收敛一切“感觉效果好多了”都是错觉。6.2 Harness配置文件参考我们的系统配置里最关键的参数其实就上面这些。如果你准备复现可以先抄一份这样的骨架harness: state_machine: max_retry_per_stage: 3 manual_takeover_on_fail: true context: summary_mode: structured keep_last_failure_reason: true tool_guardrails: max_calls_per_tool: 6 enforce_result_reference: true model: temperature_plan: 0.3 temperature_calc: 0.0 temperature_review: 0.0把这些参数写进配置比在提示词里反复强调“不要幻觉”靠谱得多。6.3 个人的几句大实话如果要用一句话总结这大半个季度的体会我会说智能体本身不负责正确架构才负责正确。我一度痴迷于让模型“更聪明”后来发现真正让方案可靠的是那些看起来“很土”的规则数值复算、器件库约束、仿真回灌、中断机制、人工审批。它们没有一个用到花哨的AI技术却把所有幻觉出口都堵住了。所以我的建议是如果你也想搭一个面向硬件设计的Agent不要把精力全花在调教提示词上。先把“哪些数值不能被模型决定”列出来再想清楚“谁来决定这些数值”架构自然就有眉目了。现在这个系统已经在我们团队内部跑起来输出BOM和原理图初稿的效率提升明显。更让我放心的是工程师拿到手的每一份方案背后都有一串强制校验记录而不仅仅是“据AI说”。后续我们还在考虑把这块能力进一步拆成可复用的服务接入更多硬件设计流程。防幻觉这件事永远没有终点但每多一道闸门就少一次炸板的可能。