AI幻觉会烧板子？用Deepseek Harness构建防幻觉电源设计Agent

去年我在开发一个面向硬件设计场景的辅助工具时，遇到了一个非常有代表性的“AI幻觉”案例：模型在为我推荐输入滤波电容时，给出了一个耐压、容量、ESR看起来都极其合理的器件方案，但等我拿着型号去供应商库里核对，这个型号根本不存在。这种问题在软件领域顶多算一段逻辑瑕疵，在电源硬件设计里就是潜在的安全事故。后来我基于Deepseek Harness搭建了一套完整的防幻觉电源硬件设计agent智能体架构，把“模型生成内容”从“直接结论”改成“可验证的中间建议”，这才真正把问题压住。这篇文章会把这套架构的设计思路、防幻觉机制、工作流配置、踩坑记录和评测方法完整拆开讲，适合正在做AI辅助硬件设计，或者想把Agent真正落地到工程场景中的开发者和电源工程师参考。

1. 为什么电源设计场景必须做防幻觉

1.1 硬件设计的幻觉不是“说错”，而是会烧板子

在软件开发领域，AI生成一段逻辑错误的代码，至少还有编译错误、单元测试、代码评审几道关卡拦住；但电源硬件设计里，AI一旦生成一个虚构的器件型号、一组错误的RC参数或一个耐压余量不足的电容，问题往往要等到PCB打样、上电测试甚至小批量试产阶段才会暴露。我最早做原型验证时做过一次对比实验：让通用大模型回答一组中等难度的电源设计问题，内容覆盖LDO选型、buck电感计算、输出电容纹波估算、MOSFET耐压选择，结果20个问题里有7个给出了“公式结构完全正确、代入数据却是错位或编造的”答案。麻烦的是，模型在输出这些内容时始终保持高度自信，不会给出任何“我不确定”或“需要查证”的信号。

这种幻觉在硬件场景里有一个很隐蔽的特征：它对工程师的识别成本极高。一个电源方案如果整体看起来合理，几乎没有人会逐项核对每个参数的来路和计算过程。等到仿真不过或者样机失效，返工成本已经不是“改一行代码”能覆盖的，板子重做、物料重新采购、测试周期翻倍，都是实打实的损失。所以我后来对这套agent的第一条要求是：不能依赖模型自我纠正，必须在架构层面把幻觉的生存空间压到最低。

1.2 通用大模型为什么会一本正经地编数据

要防幻觉，得先理解幻觉从哪来。大语言模型的本质是一个基于概率的token预测器，它不是在“查数据库”，而是在“猜下一个字”。电源设计相关的专业知识在互联网语料里的占比非常低，模型在生成器件型号、电气参数、计算公式的时候，本质上是在统计相邻词的共现关系，很容易生成“听起来很专业但经不起推敲”的内容。

举一个我在调试中遇到的典型例子：问模型“输入12V、输出5V/3A的buck电路，电感取值多少合理”，模型会给出标准公式 L = (Vin - Vout) * D / (f * ΔI)，看着完全正确；但如果你仔细看它的代入过程，D算错了，或者频率凭空用了500kHz而输入条件里根本没有。更离谱的是器件选型，模型会理直气壮地输出一个“外形、参数都非常合理”的型号，但这个型号在真实供应链里根本不存在。这种幻觉不是模型“笨”，而是它的训练目标和工程事实之间天然存在偏差——它负责语言流畅，不负责事实正确。

这一点的结论很明确：在电源硬件设计这种“错了会烧板子”的领域，不能把模型当作知识库，只能把它当作一个擅长拆解任务和生成推理路径的引擎；所有事实性信息，都必须要从外部可信数据源获取，并经过独立校验后才能进入交付物。

2. 基于Deepseek Harness的智能体架构怎么搭

2.1 为什么需要一层Harness而不是裸模型

最初我也想走捷径，直接调用大模型接口，在prompt里反复强调“请确保数据准确，不要编造型号”，结果一点用都没有。模型确实会在回复里加上“本方案仅供参考，请以实际数据手册为准”之类的免责声明，但里面的器件参数依然会错。后来我想明白一个事情：大模型本身不具备任何自我校验能力，它只是一个生成器。你不可能通过prompt“禁止幻觉”来消除幻觉，你只能在它和最终交付物之间架设一层强制校验与控制逻辑。

Deepseek Harness在我这套系统里扮演的正是这个控制层。它不是简单包装API，而是一个完整的agent运行框架，包含任务编排、工具注册、输出校验、记忆管理、状态控制这几个核心模块。它负责决定模型什么时候说话、什么时候必须调用工具、生成结果之后怎么校验、校验不通过怎么重新生成。换句话说，大模型是“大脑”，Harness是“中枢神经系统”，它不允许大脑跳过任何该走的流程。

这种做法的好处很直接：所有防幻觉规则落在框架代码里，而不是落在prompt的“期望”里。prompt的约束是软性的，模型随时可能违背；代码里的校验是硬性的，不满足条件就没有输出。

2.2 五层架构的分工与协作

这套agent整体分成五层，每层职责非常明确，我用一张表格来梳理：

以“设计一个DC-DC降压电路”为例，流程是这样的：编排层收到用户需求，自动拆解为拓扑选择、器件选型、参数计算、损耗估算、物料整理等多个子任务；每个子任务触发工具层的对应工具，比如器件选型必须调用本地器件库查询，参数计算必须调用独立的计算模块；模型在中间负责做推理判断和方案解释，比如根据输入输出条件决定用同步整流还是异步整流；生成的结果出来后，校验层立刻介入，公式复算、边界检查、数据源核对，全部通过才交给输出层；同时，整个过程中的设计约束会写入记忆层，防止后续步骤遗忘或篡改初始条件。

2.3 核心设计原则：可溯源、可复算、可推翻

我在搭建这套架构时给自己定了三条原则，它们比任何具体模块都重要。

第一，可溯源。交付物里的每一个器件型号、每一个电气参数，都必须能追溯到它来自哪个数据源、哪条查询记录。没有来源的数据一律标记为“未验证”，不能进入最终文档。第二，可复算。模型给出的所有公式计算结果，必须经过独立的代码模块重新计算一遍，模型自己的计算过程只能作为参考。第三，可推翻。任何结论都是暂时的，都可以被后续校验环节或工程师反馈推翻。整套流程不是一次生成就完事，而是一个不断“生成—校验—改写”的循环。

这三条原则直接决定了系统的容错方式：我把幻觉率从“追求0”改成了“可拦截”，因为模型一定会错，但系统能保证它错了之后不会流到最终交付物里。

3. 防幻觉机制逐项拆解：每个模块在做什么

3.1 强制“先查后答”：数据源锁定机制

这是整个防幻觉体系里最硬的一招：器件型号和相关参数不允许模型自由发挥，必须通过工具调用从本地器件库获取。我在编排层写死了规则，任何涉及“选型”的任务，第一步必须调用器件库查询工具，模型只能从查询结果里做筛选和对比，不能凭空写出型数据库里不存在的器件。

实现上我用了结构化输出约束。给模型的任务单里明确要求输出一个JSON对象，其中“器件型号”字段的值必须包含“source_db”标识，标识的内容必须是本次任务中工具实际返回的某个ID。校验层会对应检查这个字段，如果模型擅自生成一个没有来源的型号，直接判定校验失败并触发重新生成。这种做法虽然会略微增加延迟，但效果立竿见影，虚构型号率直接从百位百分数降到了个位数以下。

3.2 公式独立复算：不让模型自己验算自己

模型在算数上经常犯低级错误，更麻烦的是它会用自己的错误结果做后续推导，一错到底。所以我在校验层加了一个公式复算器，本质上是把“计算”从模型手里剥离出来。模型的任务只是识别场景、确定公式、提供已知参数，真正的数值计算由独立的代码模块完成。

以buck电感计算为例，模型输出的内容格式是这样的：识别出这是一个连续导通模式的降压电路，选择了公式 L = (Vin - Vout) * D / (f * ΔI)，给出了Vin=12V、Vout=3.3V、f=500kHz、ΔI=1A。到这里为止，模型的作用结束。复算器拿到这些字段后，先独立计算占空比 D = Vout / Vin = 0.275，再代入公式算出 L = (12 - 3.3) * 0.275 / (500000 * 1) = 4.785µH，然后把这个值和模型自己算的L值做比较。误差超过1%就直接判定该步骤失败，要求模型重新生成。这个机制的核心思路是：模型可以“选公式”，但不能“算数字”，因为计算必须由确定性代码完成。

3.3 工程边界守卫与降额规则校验

光有数值正确还不够，工程上还要求“参数在安全范围内”。我在校验层里维护了一套边界规则库，包括电压应力、电流应力、温度范围、降额系数等。任何输出参数都要经过这层检查，超过手册上限的，直接拒绝；没有达到降额要求的，降级为“需人工评审”。

比如功率MOSFET的耐压选择，模型很可能根据稳态电压选了50V耐压的管子，但实际开关过程中漏极会产生电压尖峰，通常是输入电压加上振铃电压。边界守卫会按照一定比例自动计算最小耐压要求，如果模型选的管子不满足，校验层直接给出“不满足电压降额要求，建议选择更高耐压等级”的提示，并把这个问题标记为高风险项。这个过程不需要人工参与，全部是规则化的自动检查，也是我对抗硬件设计隐患最有信心的一道防线。

3.4 置信度分级与“不知道”的表达

模型最大的问题之一是过度自信。为了让工程师能快速判断哪些结论需要重点复核，我在输出层加入了一套置信度评级体系。高置信度：数据源明确、公式复算通过、边界检查通过；中置信度：数据源单一且存在假设条件，比如“根据典型应用电路推测，需要用户确认实际工作条件”；低置信度：无法找到可靠数据源，或者多个数据源互相矛盾。

这个分级机制的一个重要细节是：我给模型训练了一套“不知道怎么说”的行为模式。当任务条件不完整时，比如连负载电流都没给，就要求模型直接列出“缺失参数清单”，而不是假设一个值继续算。这一点看似简单，但真正调通之后，整个系统的可信度提升了一个量级——工程师拿到输出时会清楚知道哪些可以直接用，哪些需要自己再确认。

4. 一次完整工作流：12V转3.3V电源设计任务实录

4.1 Agent配置中的关键参数经验值

在展示真实工作流之前，先分享一下这套agent运行时的关键配置参数，都是实测调优后的经验值。

• 最大工具调用轮次：默认为8轮。超过这个次数还没有收敛的任务，自动转人工处理。这个参数我一开始设成20，结果模型经常在错误的路径上反复尝试，浪费大量时间还容易把上下文撑爆；8轮是一个比较合理的平衡点。
• 校验失败后的最大重试次数：2次。每次重试会携带上次的错误信息，引导模型换一个方向；超过2次说明模型已经陷入死胡同，直接转人工。
• 上下文长度管理策略：每完成一个子任务，就把详细的中间过程压缩成结构化摘要，只保留关键结论和约束条件，防止设计文档把上下文撑爆。
• 不可变约束清单哈希：所有初始设计约束会在记忆层生成一个哈希值，后续每个生成步骤都会校验这个值，防止模型在长对话中“遗忘”最初的输入条件。

4.2 从任务输入到输出交付物的全过程

我以“设计一个12V转3.3V、5A输出的DC-DC降压电源模块”为例，展示这套智能体的完整运行过程。

第一步，编排层接收任务后，先做条件完整性检查。模型列出几个必须明确的问题：输入电压范围是否有波动、输出纹波要求是多少、负载是静态还是动态、工作环境温度范围、目标效率和成本约束。用户补充“输入9V到18V，输出纹波小于50mV，环境温度-20℃到60℃”后，约束清单写入记忆层。

第二步，任务分解为拓扑选择与器件选型。模型判断使用同步整流buck拓扑以提高效率。因为输出5A属于中等电流，同步整流相比二极管整流效率提升明显。随后进入工具调用环节，器件库查询工具返回候选控制器和MOSFET清单。请注いう这个环节里，模型只能基于返回的清单做选择，不能自己“编”一个型号；它可以对多个型号的导通电阻、栅极电荷、开关频率做对比和推荐。

第三步，关键参数计算。以电感计算为例子任务为例：模型识别占空比条件，选择公式和参数，复算器独立完成数值计算并核对误差。这个电感参数接着进入后续损耗估算和纹波计算环节，每个参数都经过同样的独立复算流程。

第四步，校验层做全链路检查。包括电容耐压是否满足降额要求、MOSFET功耗和温升是否在允许范围内、PCB布线的电流密度是否合理等。我加了一个很实用的规则：输出电流超过3A的走线宽度建议会通过工具直接给出参考值，避免模型凭感觉给一个脱离实际的数字。

第五步，交付物生成。输出层自动组装一份设计说明文档，包含拓扑选择理由、计算过程摘要、器件清单、风险提示清单。其中风险提示部分是系统根据校验层的检查结果自动标注的，比如“输入电解电容在低温环境下ESR会增大，建议确认实际容值余量”。

4.3 交付物里有哪些内容是模型生成的、哪些是工具生成的

很多用agent做设计工具的人会忽略一个问题：最终文档里的内容来源到底是什么。我在最终交付物里做了明确的来源标记，每个段落都有元数据，标记是模型推理、工具计算结果还是数据库查询结果。这个标记不是为了调试方便，而是为了让使用者知道哪些部分需要人工关注：模型推理部分比如“选用同步整流是因为效率优先”，可以接受一定的主观判断；工具计算结果比如电感值、效率曲线，是确定性计算，可信度最高；数据库查询结果比如器件型号和规格，需要确认数据源的更新时间。

这种来源标记也让工程师可以快速跳过高信任度内容，把精力集中在需要判断力的推理内容上，效率提升非常明显。

5. 实际调试中踩过的坑与排查心得

5.1 模型把虚构型号说得比真的还真

这是我最早期遇到、也是最头疼的问题。模型的自信程度和正确程度完全不成正比，它会把一个编造的型号用非常自然的语气给出，甚至能配上“该器件在市场中应用广泛”这类看似权威的补充说明。我最初试图通过prompt约束解决，毫无效果；后来改成强制本地库查询后才根治。在调试过程中我还发现一个反直觉的现象：如果让模型在数据库之外补充“推荐替代型号”，它依然会开始编造。最终我把规则收紧成“所有替代型号必须从备选料库中筛选，禁止模型自行组合参数描述”，才彻底堵住这个口子。

5.2 校验规则太严，agent陷入“自证循环”

有一段时间我把校验规则调得非常严格，每一条输出都要经过多个维度的交叉验证。结果agent开始频繁陷入“自证循环”：校验失败，模型根据错误提示重新生成，又一次不完全满足条件，再重新生成，再失败。浪费大量token和时间，最后用户拿不到结果。后来我增加了“失败原因分类”机制，区分两类错误：一类是计算错误，允许重试；一类是缺失数据源或数据冲突，直接停止生成并请求人工或用户补充信息。这样避免模型在一个不完整条件下无限尝试。经过调整后，无效转弯明显减少，任务完成率也提升了不少。

5.3 长上下文里的约束漂移：智能体“忘记”初始条件

在长流程任务中，我发现了另一个问题：模型到后面的步骤时，会逐渐“忘记”初始的设计约束。比如前面明确要求输入电压范围是9V到18V，到了发热计算环节，它用12V固定值算了一整轮，导致结果不可用。这个问题在会话一长就很明显。我的解决办法是在记忆层维护一个“不可变约束清单”，用这个清单生成哈希并在每个工具调用请求中携带；模型每次发起请求前，编排层都会重新注入约束摘要，确保它不会在长对话中丢失关键信息。同时在最终交付物里设置自动检查项，对比所有计算结果所使用的参数是否一致，不一致直接报错。

5.4 工具调用超时与失败兜底

工具链越长，就越容易遇到某个工具调用失败的情况。比如器件库接口临时不可用，或者某个仿真工具响应超时。我之前没有做兜底逻辑，结果整个agent流程直接挂起，什么结果都出不来。后来我设计了一套超时重试和降级策略：数据库查询最多重试2次，还不成功就标记“数据源超时”，该步骤转为人工处理，而不是让模型自由发挥去猜一个参数；仿真工具不可用时，暂时用公式计算替代复算，并在交付物中标记“未经仿真验证”。这套策略的核心原则是：宁可交一个带着缺口的半成品，也不能让模型自己补全缺口。

6. 落地之后：评测方法与持续迭代

6.1 评测集怎么构造才能测出真实水平

搭建好防幻觉机制之后，下一步就是建立评测体系。我的经验是不要只看“最终结果能不能用”，要拆细来看。评测集需要包含三类内容：

第一是标准设计题，就是有明确标准答案的基础计算和选型题，用来检验公式复算和边界校验是否正常。第二是模糊约束题，比如用户需求里故意漏掉负载电流或输入电压范围，用来检验模型会不会编造条件继续做。第三是对抗性样本，我会故意给出一些“看起来专业但内核荒谬”的输入，比如“输入电压1000V、输出1.8V的隔离电源”，看模型能不能识别异常并触发风险提示，而不是一本正经地开始计算。对抗样本是评估防幻觉水平最可观的部分，因为它在模拟真正的意外场景。

6.2 三个关键指标，比准确率更有用

具体实践中，我不太关心模型回答的“准确率”，因为那是一个太笼统的概念。我日常盯三个指标：幻觉率（最终交付物里出现无数据源或复算失败内容的比例）、工具命中率（实际触发工具的任务次数占总任务次数的比例）、一次通过率（不经过人工介入就完成整个流程的任务比例）。幻觉率是最硬的安全指标，工具命中率是为了防止模型跳过工具直接回答，一次通过率则是衡量系统效率和智能体完成度的关键指标。我自己的优化目标是幻觉率小于5%，工具命中率大于90%，一次通过率大于70%，这三个数同时达标，系统才算真正可用。

6.3 从误设计反哺规则库：让系统越用越稳

防幻觉规则库不是一次性建好的，每次出现新的误设计案例，我都会把它沉淀成一条新的校验规则。比如有一次模型把某个电容的直流偏压特性忽略掉，导致高压场景下实际容值严重不足。这个案例后来被浓缩成一条规则：“容值大于1µF的陶瓷电容，选型时必须考虑直流偏压降额，否则直接标记为高危项”。

逐步积累之后，规则库会变成一个非常有价值的资产。与此同时，每一次人工介入的修正记录也会进入教训库，后续如果模型再次遇到类似场景，系统会主动把历史教训注入prompt提示词中，相当于给它一份“上次在这里摔过跤”的提醒。这个反馈闭环让整个系统在实际使用中越来越稳，而不是停留在最初的水平。

最后再分享一个我实际操作中很有效的细节：给智能体加了一个“交付前反问机制”。所有主要设计任务完成之后，模型必须输出三个问题，要求用户或工程师关注：一是本次设计中最需要被复核的假设是什么，二是有什么条件变化会导致当前方案失效，三是如果批量生产还需要补充哪些验证步骤。经过这个环节，模型的输出在很大程度上从“给一个答案”变成了“引导思考”，让设计人员即使是接手别人的工作也能够快速理解方案的边界和风险，这对实际工程协作的价值很大，远比一个完美的自动输出要实用得多。