★ FEATURED ARTICLE 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”有的写“L6.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.2528V输入时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电路的参数计算和器件选型做到结果可信、过程可追溯、体验流畅再逐步扩展拓扑覆盖范围和下游环节。这样一步一个脚印走下来系统的可靠性和你的信心都会稳步增长。
阅读完成 · 觉得有帮助？
