防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践
做电源硬件设计的朋友应该都有过这种体验：拿着一个拓扑方案去问大模型，它给出的电感值计算得头头是道，结果你拿公式反推一遍，发现纹波电流系数根本对不上；或者它信誓旦旦推荐某款MOSFET，说vgs阈值多完美，你去查规格书发现型号压根不存在。这种场景在传统问答里几乎无解，因为大模型本质是“概率补全”，不是“精确计算器”。
我最近在做一个面向电源硬件设计场景的智能体系统，核心思路是把大模型编排框架和防幻觉机制结合起来，让agent在辅助设计时“有据可依、算则有据、错则可查”。整套架构基于Deepseek Harness搭建，底层接入了器件数据库、计算规则库和交叉验证模块，专门用来压制大模型在电源设计中最容易出现的几类幻觉。这篇文章就把这套架构的完整设计思路、核心机制、实操配置和踩坑记录一次性摊开讲，适合正在做AI辅助硬件设计、智能体编排，或者被大模型幻觉折磨过的人参考。
1. 电源硬件设计场景中的幻觉重灾区
1.1 哪些环节最容易让大模型“一本正经地胡说八道”
我先梳理了电源硬件设计全流程里大模型最容易翻车的几个位置，只有把问题定位清楚，才知道防幻觉机制该往哪里使劲。
第一类是参数计算幻觉。这是最致命的一类。比如Buck电路里电感的选取，需要根据输入输出电压、开关频率、纹波电流占比做完整计算，公式链条很长，任何一步系数弄错，最终数值都会偏差很大。大模型在生成这类内容时，表面上看公式完整、步骤清晰，但中间某个系数可能是从别的拓扑“迁移”过来的，或者干脆是它自己“脑补”的标准值。
第二类是器件选型幻觉。电源设计绕不开具体器件，MOSFET的导通电阻、栅极电荷、耐压、封装热阻，电容的ESR、纹波电流能力、寿命参数，这些数据全部存在于规格书中。大模型训练时不可能把每颗料号的参数都准确记进权重里，它经常会“张冠李戴”，把A型号的参数安到B型号头上，或者编造一个听起来很合理但实际上不存在的料号。
第三类是设计规则幻觉。电源设计有大量经验性规则和约束条件，比如降额设计、热设计、环路稳定性裕度要求、PCB布局的电流密度限制。大模型对这些规则往往只学到“大概是这么回事”，具体阈值和适用范围经常出错。
第四类是文档与代码层面的幻觉。比如要求它生成一份电源设计计算书或一份仿真脚本，它可能会生成格式漂亮但公式引用错误的内容，或者在仿真脚本里使用了错误的器件模型参数，导致仿真结果完全不可信。
1.2 为什么通用RAG方案在这里不够用
很多人第一反应是“用RAG把规格书喂给大模型不就行了”，这个思路方向对，但在电源设计场景里远远不够。因为RAG解决的是“知识检索”问题，而电源设计的幻觉大头是“计算过程”和“规则校验”，这两块光靠检索文本是堵不住的。
举个实际例子，你让agent计算某颗电感在特定工况下的温升，它需要同时处理电气参数（电流、频率、磁芯损耗）、热学参数（热阻、散热条件）、几何参数（线圈匝数、磁芯截面积）。这些参数分散在不同文档中，即使RAG把相关段落都检索出来了，大模型在“综合计算”时依然可能算错，因为它本质是语言模型，不是计算器。
所以我的判断是：在硬件设计这种高精度领域，防幻觉的核心思路不是“让大模型回答得更准确”，而是“让大模型少回答、多调用”。把计算交给确定性工具，把规则校验交给规则引擎，把参数查询交给数据库，大模型只负责理解意图、拆解任务、组织流程和生成解释性文本。这是整套架构设计的第一性原则。
1.3 设计目标与选型思路
基于上面的分析，我给这套系统定了几个设计目标：数值计算必须由确定性代码完成、器件参数必须来自结构化数据库、设计规则必须通过规则引擎校验、每一步产出必须可溯源。这四个目标直接决定了后续所有架构决策。
选型上选择Deepseek Harness作为编排框架，主要原因是它对多智能体协作和工具调用的支持比较成熟，工作流定义灵活，可以在不同节点插入自定义校验逻辑，而且与模型本身的耦合度低，后续换模型或升级模型不会牵动整个架构。同时它支持记忆管理和上下文压缩，这对长流程的电源设计任务很重要——一个完整的电源方案设计可能要经历需求解析、拓扑选择、参数计算、器件选型、验证评审几个阶段，上下文会非常长。
2. 防幻觉智能体的整体架构设计
2.1 分层架构：编排层、Agent层、工具层
整套系统分成了四层，每层的职责单一清晰，这也是多智能体系统里最容易踩坑的地方——职责划分不清楚，最后会变成模型在各Agent之间反复横跳，反而增加幻觉概率。
编排层负责接收用户需求，拆解成任务序列，调度各个Agent协同工作。它不参与任何具体计算，只负责任务路由和流程控制。这一层还负责维护全局上下文和会话状态，确保信息在Agent之间正确传递。
Agent层由多个专业Agent组成，每个Agent只负责一个领域。需求解析Agent负责把模糊的自然语言需求转成结构化设计规格书，比如把“做一个48V转12V、10A的隔离电源”解析成输入范围、输出电压精度、效率目标、隔离等级等硬性指标。拓扑推荐Agent根据规格书推荐合适的拓扑结构，并附上推荐理由和备选方案。参数计算Agent负责核心的电路参数计算，这一层是防幻觉机制的重点加固区。器件选型Agent在器件库中筛选符合要求的料号，输出候选清单和选型理由。验证评审Agent对前面的设计结果做交叉检查。
工具层则是所有确定性能力的集合：参数计算器封装了各类电源拓扑的计算公式；器件数据库提供结构化的料号参数查询；规则引擎内置了降额设计规则、热设计规则、环路稳定性规则等；文档生成器负责把计算结果和设计决策整理成规范的设计文档。
知识层是支撑系统长期运行的基础设施，包括向量知识库（存放规格书、应用笔记、设计指南）、规则知识库（存放可执行的校验规则）、以及历史设计案例库（沉淀经验知识）。
2.2 Agent之间的职责边界与协作关系
这里重点说一下Agent之间是怎么协作的，以及为什么要做这么细的切分。
用户输入进入编排层后，首先由需求解析Agent处理。这个Agent只做意图识别和结构化，不输出任何设计参数。它收到“48V转12V 10A”这样的需求后，会输出一份结构化的设计规格书，包含输入电压范围、输出规格、效率要求、尺寸限制、成本约束等字段。如果用户提供的信息不完整，它会主动列出需要补充的问题清单，而不是自作主张去猜测参数。
接下来拓扑推荐Agent拿到结构化规格书，给出拓扑建议。这个Agent同样不做计算，它只做选型推理，比如“输入输出压差较大、功率10A级别，建议采用同步Buck拓扑”，并给出选择理由。为了降低幻觉，拓扑推荐会基于一个内部的拓扑适用场景映射表来做匹配，模型只是把映射结果“翻译”成自然语言解释。
参数计算Agent是整套系统的核心防护区。它收到拓扑决策后，会把计算任务拆解成原子计算步骤，每一步都调用工具层的参数计算器执行，不允许自己在回复中直接给出计算数值。计算器的输入来自结构化规格书和器件数据库的实际参数，输出则是带完整计算过程的数值结果。
器件选型Agent在参数计算结果的基础上，从器件数据库筛选满足电气参数的料号。它的筛选逻辑是数据库查询，不是模型记忆。模型只负责把查询结果按优先级排序并解释选型理由。比如系统计算出某颗电感需要感值15uH、饱和电流15A、DCR小于10毫欧，选型Agent就构造SQL查询，返回满足条件的料号列表，按成本、库存、热性能排序。
验证评审Agent则承担最后一道防线的工作，它会用独立的计算公式重新核算关键参数，检查降额系数是否满足规则，检查器件参数是否在安全范围内。如果发现不一致，会打回给参数计算Agent或器件选型Agent重新处理。
2.3 为什么选择多智能体方案而不是单一大模型
有人可能会问：为什么不让一个大模型完成从需求解析到参数计算到器件选型的全部工作？这样不是更简单吗？
因为一件事做得越多，幻觉风险就累积得越厉害。单一大模型在长流程任务中，早期犯下的错误会被后续步骤继承放大。需求解析阶段把输入电压范围理解错了，后面的拓扑选择、参数计算、器件选型全部白做。而且单一的模型无法承载“计算必须工具化”这一约束，它在生成文本的过程中很容易跳过工具调用，直接凭“记忆”输出结果。
多智能体的价值在于把任务切小，每个Agent的上下文更聚焦，犯错面更窄。更重要的是，不同Agent之间可以互相监督，验证评审Agent的存在本身就是对计算Agent的一种约束。这种“分权制衡”的结构，是防幻觉架构的底层逻辑。
3. 防幻觉的四个核心机制详解
3.1 工具强制调用：数值计算全托管
工具强制调用是整套防幻觉机制的基石。核心原则就一句话：大模型不允许直接输出任何计算结果，所有涉及数值的答案必须由工具层生成。
具体落地方式是在Harness的工作流中配置工具调用节点，并在系统提示词中明确限制模型的输出行为。例如要求“当你需要计算参数值时，必须调用calculator工具，禁止直接给出计算结果”，同时把工具的执行结果注入上下文，让模型基于真实返回值生成解释文本。
这个机制的难点在于“强制”二字。模型在自由对话时，经常不按套路走。你让它调用工具，它偏要直接输出“我算了一下大概是15uH”。针对这个问题，我在校验脚本里加了输出格式检查，对参数计算Agent的回复做解析，如果发现包含数值结论却没有对应的工具调用记录，就判定为非法输出，要求重写。
实际使用中，这个机制的有效性验证来自一组对照实验。我拿同一个Buck电路计算任务分别测试“直接回答模式”和“工具强制调用模式”，前者的电感计算值偏差最大达到40%，后者因为走的是确定性计算器，数值与手算完全一致。这说明在数值敏感场景下，模型的能力边界确实需要靠机制来兜底。
3.2 知识库RAG溯源：让模型“引用”而不是“编造”
RAG在防幻觉架构中的角色不是“给模型找答案”，而是“给模型的解释提供引用依据”。
我构建了两个知识库：一个是向量知识库，用来存放规格书、应用笔记、设计指南等非结构化文档，供模型检索引用；另一个是结构化器件数据库，存放料号、参数、价格、库存等结构化信息，供工具层查询。
向量知识库的构建有几个细节值得注意。首先是文档切分策略，电源设计文档中经常出现公式和参数表格，如果按固定长度硬切，很容易把公式从中间切断，导致检索到的片段不完整。我实验了几种方案，最终采用的是“标题感知切分”，先按文档结构识别章节，再结合语义段落做切分，保证每个片段包含完整的设计逻辑或参数说明。
其次是检索召回策略，单纯的关键词匹配在技术文档场景下效果不好，因为设计文档中有大量同义表达。我引入了查询改写机制，在用户问题进入检索之前，先用一次轻量级模型调用把自然语言问题改写成适合检索的查询语句。比如“这颗料能不能扛住10A电流”会改写成“额定电流 10A 磷酸铁锂 MOSFET 选型”这样的检索式表达。
值得注意的是，RAG检索结果只是给大模型的“参考素材”，不是“最终答案”。我在提示词中明确要求模型在引用知识库内容时必须标注出处，对知识库中不存在的信息，必须如实说明“该信息不在知识库范围内”，而不是自行推断。这一步看似简单，但能显著减少无中生有的情况。
3.3 交叉验证Agent：独立核算二次把关
如果说工具强制调用解决的是“计算正确性”，交叉验证Agent解决的就是“流程正确性”。它用一套独立于主流程的计算逻辑，对主流程的结果做二次核算。
具体实现时，验证评审Agent与参数计算Agent使用不同的代码路径。参数计算Agent走的是“正向设计”流程，从规格书出发计算元件参数；验证评审Agent走的是“反向验证”流程，从元件参数出发反推电路性能。两者互为镜像，任何一方的计算结果异常都会暴露问题。
举个例子，某次测试中参数计算Agent给出了一颗输出电容的容值和耐压建议，验证评审Agent拿到这颗电容的ESR参数后发现，在目标纹波要求下，电容的纹波电流超出了该封装规格的允许范围。这类问题在纯文档问答中几乎无法被检出，但交叉验证机制可以自动拦截。
交叉验证的规则不只是公式比对，还包括“合理性检查”。例如电感感值计算结果异常偏大或偏小，会触发阈值报警，要求重新检查输入参数是否合理；器件的工作电压超过额定电压的80%，会触发降额规则告警。这些规则固化在规则引擎中，由验证评审Agent统一调用。
3.4 规则引擎约束：硬件设计硬约束兜底
规则引擎是防幻觉体系的最后一道物理防线。它的职责是确保任何计算或选型结果都满足硬件设计的基本规则，即使大模型的推理过程存在偏差，规则引擎也能把不符合约束的结果拦下来。
规则引擎的规则来源分两类。一类是行业通用的设计规范，比如电解电容的工作电压降额到80%以下、功率MOSFET的结温不得超过规格书最大值减去安全裕量、PCB铜箔载流能力按1A/1mm宽度粗估等。这些规则不仅是“建议”，在系统中是“硬约束”，不符合就直接判定为不合格。
另一类是项目组自己沉淀的工程经验。比如某系列产品中输入电容的容值下限、环路补偿网络的相位裕度目标范围等。这些经验规则通常来自实测数据和历史问题复盘，对防患于未然非常有效。
规则引擎的实现采用声明式规则定义，每条规则包含适用条件、校验逻辑、触发级别（警告/错误）、处理建议。规则引擎本身是独立服务，Agent通过接口调用，这样规则可以热更新，不需要为改一条降额系数重新部署整套系统。
4. 实操配置过程与核心环节实现
4.1 Harness工作流配置与Agent编排
Deepseek Harness的工作流定义采用声明式配置，我习惯用YAML来编排整个流程。一个完整的电源设计方案生成流程在配置上分为五个阶段：需求解析、拓扑推荐、参数计算、器件选型、验证评审。
工作流中每个节点都绑定了对应的Agent和执行条件，同时定义了节点间的数据传递结构。数据传递是整个工作流配置中最重要的部分，因为Agent之间的协作依赖于结构化数据的正确流转。我给每个阶段定义了明确的输入输出Schema，比如需求解析阶段的输出是一个包含31个字段的JSON结构，覆盖输入输出规格、环境要求、安规等级、热设计约束等。
在Harness的配置中，一个关键参数是温度设置。电源设计场景对输出一致性要求高，我把非计算类Agent的温度设置在0.1到0.2之间，计算类Agent的温度直接设为0，确保输出确定性。这一点与创意写作场景完全相反，但对于工程辅助工具来说，稳定性比创造性更重要。
4.2 工具注册与校验脚本编写
工具层的参数计算器是这套体系里投入时间最多的部分。我封装了Buck、Boost、Buck-Boost、反激、正激、LLC等主流拓扑的参数计算模块，每个模块接收结构化的设计要求，输出经过解析的元件参数清单。
以Buck电路的关键参数计算为例，计算模块需要处理输入电压范围、输出电压、最大负载电流、开关频率、纹波系数等输入参数。电感值的计算取决于输入输出压差、开关频率和纹波电流，而纹波系数本身又根据系统要求取不同的经验值。这些逻辑在计算公式里都是确定性的，但任何一个系数的选择偏差都会导致计算结果产生较大误差。把整套逻辑封装进代码之后，就彻底杜绝了模型在计算过程中的“自由发挥”。
器件数据库设计上也花了不少心思。我采用了SQLite作为底层存储，针对不同器件类型建了独立的表结构，将关键电气参数单独拆列存储。以MOSFET表为例，字段包括料号、厂商、耐压、导通电阻、栅极电荷、封装、热阻、价格、库存状态等二十多个维度，方便SQL查询直接做条件过滤。选型Agent构造查询逻辑时，可以把计算模块输出的电气要求直接映射成SQL条件。
4.3 提示词设计要点与防幻觉约束
提示词在防幻觉架构中的作用不是“教模型回答问题”，而是“划定模型的行为边界”。我在系统提示词中固定了几个约束条款，所有Agent共用同一个约束框架，再按各自职责做细化。
第一个条款是“工具优先，禁止臆算”。模型只有工具调用权，没有计算权。所有数值结果必须以工具输出为准。这个条款对参数计算Agent强约束，对拓扑推荐Agent弱约束，因为拓扑推荐不涉及数值计算。
第二个条款是“引用溯源，禁止编造”。模型在回答中引用任何器件参数或设计规则时，必须标注信息来源。来源有两种，要么是器件数据库查询结果，要么是知识库检索到的文档片段。如果信息不在知识库内，模型必须明确回答“知识库中没有这个信息”，而不是根据训练记忆兜底。这个条款的执行效果和知识库的覆盖度直接相关，知识库不够全时，模型会被迫频繁说“不知道”，虽然体验上有点“笨”，但安全性大幅提升。
第三个条款是“结果自检，禁止硬伤”。在最终输出之前，模型需要对照规则引擎的校验结果做一次自查，对校验不通过的项目进行标注和说明，而不是装作没看见。
4.4 知识库构建与检索链路搭建
知识库构建的素材来源主要是主流电源芯片厂商的应用笔记、设计指南和规格书。文档格式大多是PDF，处理链路包括格式解析、结构识别、公式处理、语义切分、向量化入库。
公式和特殊符号的处理是文档解析中最麻烦的部分。PDF中的公式在用普通的文本解析工具提取时经常变成乱码，我在流程里加了一个专门的公式识别模块，优先把公式区域识别成LaTeX格式单独存储，避免和正文混在一起。这样既保证了检索质量，也方便后续计算逻辑参考。
向量化模型的选择上，我对比了通用型Embedding模型和针对技术文档优化的模型。在电源设计文档的召回准确率上，技术优化版本明显胜出，因为技术文档中的专业术语分布与通用语料差异很大。Embedding模型的分词和语义理解能力直接决定了RAG检索质量，这一块的投入非常值得。
向量检索时的TopK参数也做了调优。TopK太小，关键信息容易漏检；TopK太大，引入的噪声会影响模型判断。我最终设置的是6，也就是每个问题召回6个相关片段，再经过重排后取4个注入上下文。
5. 常见问题与排查技巧实录
5.1 模型绕过工具直接编造数值
这是我在调试过程中遇到最多的问题。模型在参数计算Agent中明明配置了工具调用，但在某些场景下它会“自作聪明”地直接输出计算结果，尤其当用户问题比较简单时，比如“3.3V输出用多大的电感”，模型会倾向于直接凭记忆回答。
排查发现，问题出在提示词的约束强度不够。仅靠“禁止直接计算”这类指令对模型的约束力有限，尤其是在上下文变长后，早期指令的权重会被后续内容稀释。我的解决方案是在工具调用层增加硬校验：解析Agent的输出内容，如果识别到数值型结论，就检查本次会话中是否有对应的工具调用记录。没有记录就直接判定为非法输出并重新生成。
这个机制上线后，模型绕过工具直接编造数值的情况基本被杜绝了。现在模型学乖了，哪怕要回答一个很简单的参数问题，它也会先去查数据库，然后再组织回答，因为不调工具就过不了校验。
5.2 上下文漂移导致早期约束失效
长流程设计中，上下文漂移是个很头疼的问题。一个完整的电源设计流程可能涉及五六轮Agent对话，上下文长度达到数万token。在流程后期，模型可能会忘记早期设定的约束条件，导致输出与设计目标不一致。
比如需求解析阶段明确要求“高度不超过10mm”，但后面的器件选型Agent在筛选电感时，完全忽略了高度限制，选了个15mm高的料号。
我尝试了两种方案来解决这个问题。第一种是“关键信息固化”，把需求解析Agent输出的关键约束抽取成简短的摘要，随工作流数据传递到每个阶段。第二种是“阶段校验门”，在关键节点之间加入校验Agent，专门核对当前处理结果与原始需求约束的一致性。两者结合后，约束漂移问题得到了有效控制。
5.3 知识库覆盖不足导致的“幻觉回退”
知识库的覆盖度直接决定了防幻觉体系的有效性。如果知识库中没有某颗具体料号的详细参数，模型在回答相关问题时就会出现“幻觉回退”，即回到自己的训练记忆去找答案，而不是老老实实承认知识库缺失。
这个问题在前期测试中频繁出现，尤其是一些小众器件的参数查询。排查后发现，不是RAG链路有问题，而是知识库里确实没有这些料号的规格书。因为电源设计方案中使用的器件类型非常多，功率电感、贴片电容、电解电容、TVS管、保险丝、控制IC等，每一种都涉及大量具体料号，要把所有常用料号的规格书都收进知识库，需要持续的积累。
我的处理策略是，在选型Agent的提示词中增加了一个判断条件：如果数据库查询结果为空，必须返回“器件库中暂无可选料号”的明确提示，并列出已经尝试过的查询条件，而不是基于训练数据推荐可能不存在的料号。同时在知识库侧持续扩充料号数据，把历史项目使用过的料号规格书优先入库。
5.4 规则冲突时如何取舍
规则引擎中的不同规则之间偶尔会发生冲突。比如某颗电容的体积满足设计要求，但寿命校验不通过；又比如某颗电感的感值满足电气要求，但饱和电流裕量不足。这时候系统需要一套清晰的决策逻辑来决定“听谁的”。
我采用的方案是给规则设置优先级。安全相关规则（耐压降额、电流裕量、热约束）的优先级最高，不可妥协；性能相关规则（纹波要求、效率目标）次之；成本规则最低。当冲突发生时，优先满足高优先级规则，同时由验证评审Agent生成冲突说明报告，告知设计人员当前的取舍原因和可选的替代方案。
这套冲突处理机制在实际使用中很有价值。它让系统的决策逻辑透明化，设计人员可以清楚知道每个参数是怎么来的、为什么这个方案被选中、存在哪些权衡。这种透明度本身就是对抗幻觉的一种手段——当系统能清晰解释每个决定的依据时，对错误结论的识别和纠偏也会容易得多。
5.5 关于温度参数与输出稳定性的实测记录
温度参数的选择对输出稳定性影响非常大。我在多轮测试中发现，温度设为0时，非计算类Agent的回答也会出现一定波动，但核心计算结果的确定性完全由工具层保障，所以模型侧的微小波动不影响整体可靠性。计算类Agent的温度强制设为0，非计算类Agent的温度区间控制在0.1到0.3之间。
如果追求极致的输出一致性，可以把所有温度都设为0，但部分解释性内容会显得生硬。工程辅助场景我更倾向于“计算彻底确定性，解释适度多样性”的折中方案。
另外提醒一句，Harness本身的上下文管理策略会对长流程Agent的表现产生明显影响。建议开启自动摘要功能，在每轮Agent交互结束后自动压缩历史信息，保留关键约束和已确认参数，丢弃冗余探索内容。这个策略对抗上下文漂移非常有效。
我在实际搭建这套系统的过程中，最深刻的体会是：防幻觉不是靠某一个环节的“银弹”解决的，而是靠“计算工具化、决策透明化、验证独立化、规则约束化”这四个支柱共同支撑起来的。单看任何一个机制都不复杂，但组合起来的效果远超预期。这套架构后续还可以扩展的方向包括：接入电路仿真引擎做更细粒度的验证，引入历史故障案例库做失效模式分析，以及把设计经验沉淀成可执行的设计规则。如果你也在做类似的方向，欢迎交流踩坑经验，这套体系里值得深挖的细节还有很多。