电源硬件设计Agent防幻觉架构：让大模型不敢乱定参数

做电源硬件设计的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_max"

3.2 强插计算器：让LLM只给参数，Python给结论

这是最直接的防幻手段。具体流程是：Planner生成设计方案时，模型可以写出它认为合适的感值、容值、阻值，但这些数值不会直接进入设计输出。我们有一个参数抽取模块，会把模型给出的所有关键数值提取出来，交给Python数值计算核验。

核验模块会调用sympy和numpy重算一遍关键方程，然后把“模型估值”和“计算值”放在同一张对比表里。回到前面那个Buck案例，模型的47uH会被计算器标成“建议值为4.7uH~15uH（按r=0.3~0.4推算）”，随后Don't列表把这个差异显式报给用户。

比较的关键在于容差设计：所谓“对”，不是要求数值完全一致，而是要求模型估值落在计算值合理区间内。比如开关频率模型说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不等于消灭幻觉，但它确实能显著降低单位写错、数值漂移的风险。

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说”。后续我们还在考虑把这块能力进一步拆成可复用的服务，接入更多硬件设计流程。防幻觉这件事，永远没有终点，但每多一道闸门，就少一次炸板的可能。