基于Deepseek的电源设计智能体：防幻觉架构与多Agent协作实践
1. 项目缘起与整体设计
1.1 为什么会有这个项目
做硬件设计的朋友应该都有体会，电源设计这件事儿，看着是“选个芯片、搭个外围电路、算几个电阻电容”，实际上每一环都是细节。拓扑怎么选、环路怎么补偿、MOS管驱动电流够不够、电感饱和电流留多少裕量、热耗怎么算，任何一个点拍脑袋，后面打板回来都是改版重来的成本。
我一直在琢磨怎么把大模型真正用进硬件设计流程里。市面上通用聊天机器人问个概念还行，真让它帮我算一个buck电路的电感值、选一个满足纹波要求的输入电容，或者检查一下原理图里反馈电阻的取值合不合理，它要么答得模模糊糊，要么一本正经地给出一个完全没法用的结果。大模型在这种场景下暴露出的最大问题就两个字：幻觉。
后来Deepseek出来之后，我花了挺长时间评估它做硬件设计底座的可能性。推理能力确实能打，尤其在数学计算和逻辑推理这类任务上，和那些需要“硬凑答案”的模型完全不是一个画风。但光有底座不够，要在真实的电源设计流程里用起来，还缺一层能把模型、工具、知识库、校验逻辑串起来的骨架。这个骨架就是标题里的Harness。
这套架构搞了大半年，断断续续迭代了好几版。从最初的“一问一答”脚本，做到现在的多agent协作、带完整防幻觉机制的智能体系统，中间踩坑无数。这篇就把整个架构从头拆一遍，把那些真正有效的设计决策和那些让我返工的坑都整理出来。
1.2 Harness在架构里的定位
先说说Harness这个词。很多人第一次听到会以为是个具体的软件，其实它在AI工程领域更像是一种“装配层”的概念。模型是发动机，Harness是底盘和传动系统。它负责把模型、工具调用、外部数据、执行流程、结果校验这些部件装配到一起，形成一个能稳定干活儿的整体。
我这套架构里，Harness承担了几个核心职责：第一，编排多agent的协作流程，让规划、计算、校验各司其职；第二，管理工具调用，把仿真软件、计算脚本、数据库查询这些外部能力封装成agent可以调用的接口；第三，落地防幻觉机制，在模型输出和最终答案之间加一道硬约束。
为什么不用那种“一个prompt走天下”的简单方式？因为电源设计这个场景对精度的要求太苛刻了。你问“这个buck电路的电感取多大”，一个通用模型可能直接给你一个公式、代几个数、出个结果，看着挺像那么回事儿，但如果你把输入电压范围、开关频率、纹波要求这些边界条件稍微改一改，它的答案可能就彻底不对了。这不是模型笨，是这种开放式问答的结构本身就不适合承载高精度的工程设计任务。
所以我的设计原则很简单：模型负责“理解”和“规划”，工具负责“计算”和“验证”，知识库负责“约束”和“参考”，最后再加一道独立的校验环节。让模型做它擅长的事，但绝不让它成为唯一的信息来源。
1.3 面向的读者和适用场景
这篇分享适合两类人。一类是做AI应用工程、正在研究怎么把大模型落地到专业领域的开发者，你可以看看在硬件设计这种对精度要求极高的行业里，防幻觉体系具体是怎么落地的。另一类是硬件工程师，尤其是做电源设计的，你可以看看agent能帮你处理哪些重复性高、规则明确的工作，以及哪些环节目前仍然需要人来兜底。
这套架构不挑具体领域。防幻觉的思路、Harness的编排方式、工具增强的路径，换到结构设计、热设计、成本估算、PCB布局审查这些场景，骨架完全可以直接复用，只是换一套垂直领域的工具和知识库而已。
2. 防幻觉体系：把错误扼杀在流程里
2.1 幻觉从哪来，先认清敌人
模型在生成token的时候，本质上是在做概率采样——根据前文信息预测下一个最可能的token。它没有一个“从外部数据库查证”的自觉。这就导致一个结果：当训练数据里没有覆盖某个具体场景时，它会倾向于编造一个看起来合理的答案来填补空白。
在通用问答场景里，这种编造最多是误导人。但在电源设计场景里，一个编造的环路增益数据、一个随便算出来的热阻值、一套不匹配的器件参数组合，直接就能毁掉一次设计。更麻烦的是，硬件设计里的错误往往不会当场暴露——原理图审查时看不出来，等到板子打回来测试才发现效率不对、纹波超标、甚至芯片烧了。
所以要建立防幻觉体系，第一步就是改变提问方式。你不能让模型自由发挥写答案，要把它变成一个必须在约束条件下完成任务的执行者。每一道输出都要能追溯到计算过程，每一个数据都要有来源。
2.2 四层防幻觉机制的设计
我在架构里落地了四层防幻觉机制，层层递进，互相兜底。
第一层是结构化约束层。所有发给模型的任务都不是开放式问答，而是填入式的任务单。比如让模型算电感，prompt里明确写清楚输入参数表、输出字段表、计算步骤要求，模型只需要按照指定流程执行。这一层解决的是“自由发挥”的问题。
第二层是计算工具层。所有涉及数值计算的任务，模型自己不直接算，而是生成计算参数、调用封装好的数学工具去算。比如环路稳定性分析，我封装了一个专门的计算模块，模型只需要把开环增益、相位裕度、穿越频率这些参数提取出来传给工具，工具返回结果，模型再基于结果生成分析报告。这一层解决的是“数值精度”的问题。
第三层是知识约束层。我在知识库里维护了一份电源设计规则库，包含降额设计规则、器件选型边界、拓扑适用场景、典型电路参考。模型在生成方案时，必须经过规则匹配，违反规则的方案直接打回。这一层解决的是“领域常识”的问题。
第四层是交叉验证层。关键输出在进入最终报告之前，会经过一个独立的验证agent复核。这个验证agent不知道规划agent的结论，它只拿到原始需求和计算过程，重新走一遍推理，比对两个结果是否一致。这一层解决的是“系统性幻觉”的问题——有时候模型的错误不是单点的，而是一整套听起来自洽但完全错误的逻辑链条，单靠规则很难拦住，双模型交叉验证是目前最有效的手段。
2.3 结构化输出的强制约束
这里展开说说结构化约束层的具体做法。我的prompt模板里，每个设计任务都定义了严格的输出schema，用JSON格式约束字段名和字段类型。比如电感选型任务的输出必须包含：计算依据（选用的公式）、输入参数值、计算结果、器件推荐型号、降额校验结果。
模型只能在这个schema的框架内填空，不能自由发挥。这个设计不是为了好看，而是为了把模型的输出变成可解析、可校验的数据结构。后续的规则引擎、工具调用、交叉验证，全部基于这个数据结构操作。
我试过不约束schema的版本，让模型用自然语言输出计算结果。结果是：十个答案里有八个格式都不一样，有的写“电感值建议取6.8uH”，有的写“L=6.8μH”，有的写“考虑到纹波要求，电感选择6.8微亨”。解析逻辑根本没法写，规则引擎也没法自动化。改成结构化输出之后整个流程才顺畅起来。
2.4 防幻觉硬规则是模型的底线
最后还要强调一点：防幻觉机制不是让模型变得“不撒谎”，而是让模型“没有撒谎的空间”。在四层机制之下，模型即使产生了幻觉，也会在某个环节被拦截。要么参数不合法被规则引擎打回，要么数值异常被工具层发现，要么与验证agent结论不一致被标记复核。
这意味着在架构设计上，你要把“模型直接输出最终答案”的通路彻底堵死。用户看到的每一个数据，一定是经过工具计算、经过知识校验、经过交叉确认之后的产物。这条原则我建议所有做专业领域agent的人牢牢记住：模型输出是半成品，不是成品。
3. 工具层设计：模型的大脑，工具的双手
3.1 为什么必须引入外部计算工具
很多人觉得大模型本身就具备数学能力，Deepseek的推理能力又这么强，直接让它算不行吗？实测下来，让模型算一个简单的分压电阻值，输入10V，目标3.3V，分压电流0.5mA，它给出的结果可能是对的，但你会发现一个问题：它每次给出的计算过程版本都不一样。有时候是精确代公式，有时候是近似估算，有时候直接跳过中间过程给出一个“凭经验”的结果。
对于工程设计来说，过程不可复现就等于错误。你今天让它算电感，它用了一种方法，明天同样的输入可能换了另一种方法——也许结果碰巧一样，但工程上没人敢依赖这种随机正确性。
所以工具层的设计原则是：把计算从模型的概率世界里剥离出来，放到确定性的工具世界里。模型负责理解需求、提取参数、选择计算路径，实际的数值运算全部交给封装好的工具模块。
3.2 工具封装的三层结构
我的工具层分成三层。
最底层是基础计算库，就是纯函数式的计算模块。电感纹波计算、环路增益计算、热阻计算、降额校验、PCB走线载流计算，这些都是明确的公式和算法，输入参数给到位，输出就是确定性的。
中间层是数据接口，把器件数据库、规格书解析结果、参考设计库这些数据源封装成查询接口。agent需要查某个MOS管的导通电阻、某个电容的ESR、某个电感的饱和电流，走的是数据接口而不是靠模型“回忆”。
最上层是仿真封装，封装了对外部仿真软件的调用。比如需要做环路稳定性仿真，agent可以生成仿真输入文件、调用仿真程序、解析仿真结果。这一层目前只做自动化调用，仿真结果的解读仍然需要经过校验环节。
这个分层设计的好处是每一层都可以独立测试、独立替换。基础计算库可以写单元测试保证正确性，数据接口可以单独验证数据源的准确性，仿真封装出了问题不会影响上层逻辑。
3.3 模型和工具的协作模式：先规划后执行
在我的Harness架构里，模型和工具的协作是典型的“先规划后执行”模式。规划agent收到用户需求后，先拆解任务、确定计算路径、识别需要的工具和数据，生成一份执行计划。然后执行器根据这个计划逐步调用工具，每一步拿到确定性结果之后，再交给生成agent汇总。
这里有个关键细节：模型在规划阶段也要输出结构化数据，不能只输出自然语言描述。因为执行器要自动解析计划并执行，所以计划本身必须是机器可读的。我定义了一个计划schema，包含任务列表、每个任务依赖的工具、输入参数映射、输出变量名。
举个例子，一个完整的buck电路参数计算任务，规划agent生成的计划可能是这样：第一步查数据接口获取器件的开关频率范围，第二步调用基础计算库的电感计算公式生成候选电感值列表，第三步对每个候选值做纹波校验，第四步调用热阻计算模块检查电感温升，最后汇总结果生成设计报告。
每一个步骤都是确定性的，模型不参与数值运算，只负责生成计划和解释结果。这套模式下模型的幻觉影响范围被压缩到了“计划选择”这个层面，而计划层面的错误可以在执行阶段被参数校验环节发现。
3.4 工具调用错误的兜底机制
工具调用也不是绝对安全的，至少有三类问题我踩过。第一类是参数传递错误，模型提取的输入参数和用户需求不一致，比如把输入电压范围的上限当成典型值传给计算工具，算出来的结果自然就错了。第二类是公式选型错误，比如算反激变压器时用了正激的公式，结果完全不可用。第三类是数据查询无结果，模型查不到匹配的器件时可能强行推荐一个参数不达标的型号。
针对这三类问题，我在架构里加了三道保险。参数传递错误靠的是规则校验——工具接口定义里写明每个参数的物理范围，比如输入电压必须是正数、开关频率必须在100kHz到2MHz等工业合理范围内，超出范围直接报错打回。公式选型错误靠的是任务类型标记——每个任务在规划阶段就被打上类型标签，执行器根据类型选择对应的公式库，不允许模型自由指定公式。数据查询无结果的处理是让模型必须明确说明查无结果并建议替代方案，不允许编造一个不存在的器件型号。
4. 电源硬件设计的垂直能力注入
4.1 知识库不是资料库，是约束库
做垂直领域agent，大家第一步都会想到搭知识库。但怎么搭、放什么内容，差别很大。很多人把规格书、应用笔记、参考设计一股脑塞进去，让模型自己去检索，结果效果很差——检索出来的内容可能不相关，也可能相关但模型不知道怎么用。
我的做法是把知识库定位成“约束库”而不是“资料库”。里面放的不是公开文档原文，而是经过提炼的规则化知识。每一条知识都是一个约束条件，比如“输入电容的纹波电流额定值必须大于计算出的最大纹波电流”、“电感的饱和电流必须大于最大峰值电流的1.2倍”、“反馈电阻的精度等级选择取决于输出电压精度要求”。
这样做是出于一个考虑：规则才能被机器自动校验，资料不行。你让模型读一篇50页的电源设计应用笔记，它理解到什么程度你完全不可控。但你把里面的关键约束提炼成一条条规则，模型在生成方案时只需要逐条比对，这个过程是可检查、可审计的。
4.2 电源设计核心任务的agent分工
架构里我设计了四个专职agent，每个负责一类任务，避免一个agent什么都干、什么都干不精。
任务理解agent负责接收用户需求，提取关键参数，把自然语言描述转化成结构化的设计输入。用户说“做一个12V转3.3V的buck，输出电流3A，纹波小于50mV”，它需要补全隐含的边界条件——输入电压范围、开关频率选多少、工作温度范围、成本敏感还是效率敏感，这些不确定项会生成澄清问题回问用户。
方案规划agent负责设计路径决策。输入电压范围决定了拓扑结构，输出功率决定了器件选型方向，纹波要求决定了滤波器的设计优先级。它会生成一份方案大纲，包括拓扑选择理由、关键器件选型逻辑、需要计算的项目列表、需要仿真的项目列表。
计算执行agent负责调用工具层完成所有数值计算。电感选型计算、功率管损耗估算、环路补偿参数计算、热设计校验，每一项计算都会记录输入参数、计算公式、计算过程和结果版本，保证全程可追溯。
验证agent负责在最终输出之前把所有计算结果拉通检查。它检查计算过程是否用了正确的公式、参数是否在合理范围内、器件选型是否满足降额要求、多个计算项目之间的数据是否能互相印证。这个验证agent的核心价值在于独立性——它不参与任何计算，只负责挑错。
4.3 从需求到方案的完整任务拆解
用一个实际例子说明整个agent协作流程。假设用户提交需求：“设计一个24V转5V/2A的buck电源”。
任务理解agent先做需求解析，提取的关键参数是：输入电压范围（假设用户说24V输入，需要进一步确认是否允许波动到20V~28V）、输出电压5V、输出电流2A。它会生成澄清问题：输入电压波动范围是多少？纹波要求多少？工作环境温度范围？有没有效率要求？
用户补充之后，方案规划agent生成设计方案：拓扑选同步buck（效率优先）；开关频率选300kHz（在效率、器件体积、环路设计难度之间取平衡）；输入电容和输出电容拓扑选型；电感感值初步根据典型纹波率30%估算；控制芯片候选型号列出来。
计算执行agent执行具体计算：根据输入输出参数计算占空比范围（20V输入时占空比0.25，28V输入时0.179）；根据纹波电流要求计算最小电感值；根据输出纹波要求计算输出电容容值和ESR上限；根据功率计算功率管电流应力并初选MOS管。
验证agent做交叉检查：确认所有计算使用了正确的输入参数；确认电感饱和电流大于最大峰值电流的1.2倍以上；确认输出电容的ESR满足纹波要求；确认所有器件选型的电压、电流、功率降额在合理范围内；生成最终的设计报告。
可以看到，模型在整个流程里只承担“理解”和“决策”类工作——理解需求、选择拓扑、规划路径、解释结果。所有数值类工作全部由工具完成，所有正确性类工作全部由规则和验证环节完成。
4.4 垂直规则库的建设方法与实践
规则库的建设是这个系统比较费功夫的部分。我的做法是把资料分成几类：第一类来自公开的教材和应用笔记，比如开关电源设计相关的经典书籍、芯片厂商的应用笔记；第二类来自在多次设计、改版中沉淀的经验教训，这部分是最有价值的；第三类来自行业标准和设计规范。
每条规则入库时都要明确三件事：适用场景、判定条件、处置动作。比如“电感饱和电流裕量不足”这条规则，适用场景是电感选型，判定条件是“最大峰值电流 × 1.2 > 电感饱和电流”，处置动作是“标记警告并建议重新选型”。
规则入库之后还要定期清理——有些规则在新器件、新拓扑面前已经不适用了，留在库里只会在校验时误伤合理的方案。
5. 架构部署实践与运行观测
5.1 硬件配置与模型部署
架构部署首要考虑的是模型在哪里跑。硬件设计这个场景对数据安全要求比较高，设计数据往往不太可能直接传到云端API，所以核心的推理任务我优先考虑本地部署。
实测下来，Deepseek系列模型在消费级工作站上做推理，关键要卡准显存和内存的平衡。我这边用了两张显卡并行加载模型，结合量化方案把显存占用压了下来，同时保住了推理质量。几个G的模型文件放显存，上下文相关的KV cache放内存，靠框架的调度能力把两者的带宽用起来，跑50~100轮的agent协作推理流程，速度和精度都还能接受。
具体到部署方式，我建议分三层：模型服务层（负责加载模型、提供推理接口）、agent编排层（跑Harness框架、管理多agent协作）、工具服务层（跑计算库、数据接口、仿真封装）。这三层可以部署在同一台机器上，也可以拆开分布式部署，看任务并发量来定。
5.2 单机部署/Docker化与内网部署
为了方便迁移和复现，我把整个系统做了Docker化。镜像里打包了模型推理服务、Harness运行环境、工具库依赖、规则库文件。推到内网私有仓库之后，在任何一台部署了Docker的机器上都能直接启动。
内网部署有几个注意点：第一，模型文件本身比较大，要先传到内网存储再挂载进容器，不要在镜像构建时打进去，否则每次更新镜像都要重新传输。第二，工具层如果依赖外部软件（比如仿真程序），要做好路径映射和权限配置。第三，内网环境往往没有外网访问能力，所有依赖包要在构建镜像时提前拉好。
我的部署脚本里做了两个版本：开发版用docker-compose一键起全套服务，生产版用systemd管理容器生命周期加上自动重启。这套部署方式在后续迁移和扩展的时候会省很多事。
5.3 观测体系：agent的可观测性设计
agent系统比普通应用难观测的地方在于：它不是单线程执行的，而是多agent并行协作，每一步都有模型推理和工具调用，出错的位置可能藏在任何一个环节。
我做的观测体系包含三个维度。第一个维度是流程追踪，每个用户请求生成一个trace_id，贯穿所有agent的调用链，每一步记录了执行时间、输入输出摘要、调用的工具和参数。第二个维度是关键指标，包括工具调用成功率、规则校验被拦截的次数、验证agent发现的差异数、平均响应时间、token消耗量。第三个维度是结构化日志，所有模型输出和工具返回都以结构化格式记录，方便事后回溯和分析。
这套观测体系的价值在排查问题时体现得最明显。有次用户反馈某个计算结果“看着不太对”，我直接按trace_id拉起全链路日志，看到的是计算执行agent生成公式时选了正确的公式，但传入参数时把输入电压范围的上限和下限搞反了，这个错误被验证agent拦截并更正了。如果没有观测体系，这类问题根本定位不到。
5.4 性能优化与并发处理的取舍
如果只是单用户使用，性能压力并不大。但如果你想把agent能力开放给团队使用，就要考虑并发了。我实测发现两个性能瓶颈：第一个是模型推理的并发能力，多请求同时到达时推理服务会排队，影响响应时间；第二个是工具层的计算密集任务，比如批量仿真参数扫描，会占用大量CPU。
在并发优化上我的取舍是：优先保交互体验，把用户无感知的耗时任务放到异步队列里处理。具体做法是：任务理解、方案规划这类需要用户等待的环节走同步推理，计算执行环节如果任务量大，拆成子任务投递到异步队列，完成后推送通知。这样用户体验更平滑，系统的整体吞吐量也上去了。
6. 常见问题与排查技巧实录
6.1 大模型计算的精度问题
这是我最先遇到、也最需要解决的问题。测试阶段用Deepseek直算一个buck电感值，输入同样的参数，跑十次能算出七八个不同的结果。虽然大多数在正确值附近，但对工程设计来说这完全不可接受。
解决方案就是前面说的工具层：模型不再直接算数，而是生成计算参数、调用确定性计算函数。这一步改完之后，同样的输入跑一百次，结果完全一致，精度由计算函数本身保证，不再受模型概率性影响。
如果你的应用场景没法完全剥离模型计算，那至少要在prompt里强制要求“分步计算，每步展示结果，最终结果保留两位小数”，并且加交叉验证环节。但说实话，对于工程精度要求高的场景，工具化计算是唯一可靠的路。
6.2 Agent规划路径出错的处理
有次测试反激电源设计任务，方案规划agent给出的拓扑选择建议是正激。原因是用户需求里有“多路输出”这个特征，模型把它关联到了正激拓扑的多路输出优势，忽略了功率等级、输入电压范围和成本约束这些更关键的决策因素。
这类问题的本质是：模型在做决策时容易被单一特征误导，缺乏全局权衡能力。我的处理方式是给规划agent加了一层规则前置过滤：在模型接收需求之前，先由规则引擎根据硬约束条件筛掉一部分不可能的方案。比如功率超过200W直接排除反激拓扑，输入电压范围超过一定跨度直接排除正激拓扑，这些硬规则在模型之前就把路堵死。
6.3 知识库内容冲突的应对
知识库建到一定规模后，容易出现内容冲突。比如一条规则说“陶瓷电容的DC偏压特性不可忽略”，另一条参考数据给出某个案例里直接忽略偏压特性做了简化计算。这两条同时存在时，模型校验环节可能不知道听谁的。
我的做法是给每条知识加优先级和适用范围标签。专用场景的规则优先级高于通用规则，新版本规则优先级高于旧版本，来源可靠的规则优先级高于经验总结。校验引擎在匹配到多条规则时按优先级决定采用哪条。
6.4 多Agent协作中的“重复劳动”
早期版本的架构里，规划agent和计算agent偶尔会重复做同一件事——规划agent可能顺手算了个粗略的电感值，计算agent不知道这事，又按完整流程算了一遍。浪费token是小事，关键是两遍计算如果出现偏差，可能引起后续校验环节的误判。
解决的方案是明确每个agent的职责边界，用契约接口来约束：规划agent的输出只能是执行计划，不允许包含计算结果；计算agent的输入只能是执行计划，不允许自行假设参数。架构上做了强制隔离，问题就彻底消失了。
6.5 模型推理速度与精度的平衡
这个问题问的人很多：加了这么多防幻觉环节，响应速度会不会慢到没法用？实测下来确实比以前直接问答慢，但慢得值。单轮问答大约1秒，完整的电源参数计算流程大约25秒，包含多次推理和十几次工具调用。
如果觉得慢，可以从三个方向优化。第一，模型本身用更高吞吐的推理框架，吞吐能提升好几倍；第二，减少不必要的交叉验证——不是所有输出都需要第四层验证，只对关键数值类输出开启；第三，并行化——不同计算任务之间如果没依赖关系，可以同时执行，总耗时会大幅下降。
7. 一些补充的收获
7.1 干净数据是agent的地基
做完这个项目之后我最大的感触是：agent的效果上限不取决于模型多聪明，而取决于你把数据整理得多干净。这里的“数据”指的是规则、计算公式、工具接口、验证逻辑，每一条都要有明确的定义、边界和可观测性。数据干净了，模型只需要做轻量的理解和规划，效果自然稳定；数据混乱，模型再强也会被带偏。
7.2 有价值的工具比复杂的模型更重要
第二个体会是关于工具投入的。我一开始把大量精力花在调整prompt、优化模型行为上，后来发现效果提升最明显的其实是把工具层算准、把规则库建全。一旦计算工具稳定了，校验规则覆盖到位了，模型的很多“幻觉问题”根本不会触达最终结果。
7.3 从自动化到流程善后
目前这套架构处理从需求到参数计算的完整链路已经没有大问题，但如果要往更高阶的方向演进，还需要在流程善后方面大量投入。所谓善后，就是设计产出的下游环节——生成原理图、对接PCB布局、输出制造文件。这些环节每一道都可能出错，都需要自己的校验体系。
如果你也想做类似的方向，我的建议是不要一上来就追求一个全能的系统。先把一个最有价值、最容易量化收益的场景做到极致，比如buck电路的参数计算和器件选型，做到结果可信、过程可追溯、体验流畅，再逐步扩展拓扑覆盖范围和下游环节。这样一步一个脚印走下来，系统的可靠性和你的信心都会稳步增长。