去年年底，我在调一块 12V 转 3.3V 的 DC-DC 降压板时，随手让大模型帮忙算了一组输出电容参数。它很干脆地给出了建议：100uF 电解电容，25V 耐压，ESR 0.1 欧姆。乍一看没毛病，但等我把这套方案丢进仿真，输出纹波直接飙到 80mV，再细查才发现，它把 Buck 电路的占空比公式用成了 Boost 的。这种错误放在写代码的场景里，无非是改一行重新部署；放在电源硬件里，就是打样回来冒烟、BOM 返工、项目整体延期一周起步。
这件事让我开始认真琢磨：能不能搭一个专门服务电源硬件设计的 agent 智能体，让它在吐出设计方案之前，先被一套"防幻觉"机制层层兜住？我最后选定了 Deepseek Harness 作为编排底座，把需求解析、拓扑选型、参数计算、元件校核、方案评审串成一条可控流水线。这篇文章就把整套架构、防幻觉的具体做法、以及落地过程中的权限、部署、并发这些坑原原本本分享出来。适合正在做垂直领域 agent 开发的朋友，也适合被大模型坑过的硬件工程师——哪怕你不写代码，看完也会明白为什么"AI 写的硬件方案不能直接用"。
1. 先说说为什么是电源硬件设计：这行最不能容忍"一本正经地胡说"
1.1 一个让我决定做防幻觉的翻车案例
上面提到的电容参数，其实只是翻车现场里的一个缩影。我把那次对话完整复盘了一下，发现大模型在电源设计上犯的错极其典型：
第一，拓扑混用。它先按 Buck 电路给我算了电感，后面算输入电容时又套用了 Boost 的纹波公式，导致输入侧电压纹波被低估了一倍多。第二，降额完全没概念。输出 3.3V，它推荐 25V 耐压电容，看似留了 7 倍余量，但对陶瓷电容来说，直流偏压特性会让有效容值在 25V 附近掉到标称值的三成不到，反而成了最薄弱环节。第三，ESR 是拍脑袋给的。0.1 欧姆在铝电解里算正常，但如果是 MLCC 就明显偏高，而且它自己都分不清两种电容的适用场景。
这几个错误没有一个是"查不到资料"导致的，全都是模型在"自由发挥"。硬件设计恰恰是最怕自由发挥的领域。
1.2 硬件错误的放大效应：从原理图到量产，每一层都在加倍
软件出错的修复链路是：CI 报错、改代码、重新构建、滚动发布，分钟到小时级别。硬件出错的链路完全不是一回事：原理图评审发现问题，改一版；PCB 打样回来上电冒烟，查半天找到根源，改一版；到了量产阶段才发现某一颗料的耐压或温漂不满足，那就是整批返工甚至召回。
我把两者做了个对比，每次给团队讲防幻觉设计时都会放这张表：
| 环节 | 软件错误 | 硬件错误 |
|---|---|---|
| 发现时机 | 编译、单测、CI 可自动发现 | 仿真、打样、老化后才能暴露 |
| 修复成本 | 改代码，分钟级 | 改 BOM/PCB，周期以周计 |
| 放大倍数 | 基本线性 | 原理图错 1 处，PCB、结构、产线全跟着返工 |
| AI 参与风险 | 错了能被测试兜住 | 错了可能直接冒烟、炸机 |
所以做电源硬件方向的 agent，首要目标不是"生成的方案有多惊艳"，而是"生成的方案出错率有多低"。这决定了整个架构必须把防幻觉放在功能之前。
1.3 电源领域最容易出现幻觉的四个环节
我跑了几十组测试，总结出电源硬件设计里大模型最容易胡说八道的四个位置：
- 拓扑公式与波形关系。Buck、Boost、Buck-Boost、Flyback 的占空比、电感电流纹波、输出纹波公式长得像但系数完全不同，模型经常张冠李戴。
- 元件参数随意拍板。饱和电流、耐压、ESR、温漂、直流偏压特性，这些参数在真实手册里都有曲线和数据，但模型没有"查"的强制动作时，会直接凭记忆生成。
- 引脚定义和封装。某颗芯片的引脚顺序记错一点，PCB 画出来就是镜像的，轻则飞线，重则烧片。
- 环路补偿的估算。穿越频率、相位裕量这些需要基于具体控制方案算的东西，模型给的数量级经常离谱。
这四个环节有一个共同点：都存在"标准答案"，而且标准答案在 datasheet 和计算工具里，就是不在模型的参数里。所以防幻觉的本质，是逼着 agent 每一句话都找到出处，每一个数字都走一遍计算工具。
2. Deepseek Harness 在这场架构里到底扮演什么角色
2.1 为什么不干脆裸调 DeepSeek API 自己拼 ReAct
我最早是用裸的 ReAct 循环做的原型：一个 while 循环里塞 system prompt、工具列表、模型调用、结果解析。跑起来没问题，但一上真实场景就露馅。工具返回的 JSON 偶尔被截断、多轮对话里上下文越滚越大导致模型"忘记"之前选定的拓扑、每次迭代想调整工具参数都要改代码。最难受的是没有版本概念，某天改坏了一个工具函数，想回退只能靠 git 翻历史。
市面上通用 agent 框架我也试过几个，强在通用性，弱在领域约束。它们默认场景是"能上网、能写文件、能执行代码"，但我需要的恰恰是"严格按电源设计规则走、只查我给的资料、算错了要能回退"。通用框架的开放性反而成了负担——模型能访问越多，幻觉空间越大。
2.2 Harness 的核心能力刚好卡在硬件场景的痛点上
Deepseek Harness 吸引我的地方在于，它不是"又一个大模型封装"，而是一套把 agent 资产化的编排层。几个能力实测下来非常关键：
第一是 Skill 机制。可以把"电源设计检查规范""元器件选型流程"这类领域知识打包成 skill，在任务启动时按需加载。这解决了硬件场景里最头疼的问题：每次对话都要重新灌输一遍规则，而且常常灌输不彻底。
第二是工作流编排。Harness 允许我把"需求解析→拓扑选型→参数计算→元件筛选→规范评审"这一串动作固化成流程节点，而不是让模型自由选择先做哪步。对电源设计来说，流程顺序本身就是防错的一部分——你不可能还没确定拓扑就去挑电容。
第三是代码回退。Harness 对运行的脚本、生成的结果有版本快照能力，某一步算错或者插件改坏了，可以直接回退到上一个可用状态。调试 agent 的过程中这个功能救了我很多次。
第四是它的插件生态。社区里有不少实用插件，比如提示词优化插件，会自动把长规则清单整理成模型更容易遵守的结构化约束；还有针对代码任务的工作流插件。这些不用自己从头造。
2.3 本地化与数据边界：桌面版、内网服务器部署
选型时我还有一个硬约束：硬件公司的原理图、BOM、选型经验属于核心资产，绝对不能因为用 AI 而把这些数据送到公网。Deepseek Harness 支持桌面版，也能把 skill 和工作流部署到内网服务器，整个链路可以在离线局域网里跑通。这意味着模型推理可以接内网已有的模型网关，知识库存在公司文件服务器上，agent 的所有工具调用都在内网完成。
这一点在硬件团队里特别好说服领导：数据不出内网，方案审计算得清账。我后面会专门讲内网部署时遇到的文件权限问题，这里先按下不表。
横向对比一下三种做法：
| 对比项 | 裸调 DeepSeek API | Deepseek Harness | 通用 agent 框架 |
|---|---|---|---|
| 领域规则沉淀 | 靠 system prompt 硬塞 | Skill 资产化，按需加载 | 自己实现，成本高 |
| 流程可控性 | 完全自由，易跑偏 | 工作流编排，节点固定 | 灵活但需自建 |
| 回退能力 | 无 | 内置代码/结果回退 | 依赖外部版本管理 |
| 离线内网运行 | 可，但工具链要自己拼 | 支持，含 skill 管理 | 视框架而定 |
| 二次开发成本 | 高 | 中低 | 中高 |
3. 防幻觉不是提示词技巧，是三层约束架构
3.1 第一层：知识检索接地，输出必须带证据链
大多数人对防幻觉的理解停留在"把规则写在 system prompt 里，告诉模型别乱说"。实测下来，这玩意儿作用有限。模型在生成时并不会逐条对照规则，它只是在"概率上"更倾向遵守。
我的做法是把检索接地做成硬约束。Harness 的 skill 里挂了一个检索工具，但它只检索我预先筛过的语料库，包括原厂 datasheet PDF、厂商应用笔记、权威参考手册。任何设计输出，必须附带证据链：用的哪个型号的手册、第几页、哪个参数表。
关键细节是置信度阈值。我让检索工具返回 top-1 命中分数，当分数低于设定阈值时，agent 不允许继续回答，必须输出"资料库中未收录该器件的官方手册，无法给出该参数建议"。这一条直接堵死了模型"凭印象编 datasheet 参数"的路。你可能觉得这样会降低可用性，但恰恰是这种"拒绝回答"让方案可信度大幅提升——硬件工程师看到"不知道"会去查手册，看到一串编造的参数才真的会出事。
3.2 第二层：把数学交给工具，模型只做参数抽取
LLM 做定性判断还行，做定量计算就是灾难，尤其电源设计里那些带平方、带微积分关系的公式。我在架构里立了一条铁律：模型不准算数，只准抽参。
具体流程是：模型从需求中抽取 Vin 范围、Vout、Iout、开关频率、纹波目标等参数，填入一个固定结构的 JSON，然后调用独立的计算工具完成全部数学运算。计算工具是普通 Python 脚本，公式写死，输入参数来自模型抽取结果，输出回填到方案里。
以 Buck 电感计算为例，工具内部用的是：
def calc_buck_inductor(vin, vout, iout, fsw, ripple_ratio=0.3): # 电感纹波电流取输出电流的 30% 作为常见经验起点 delta_i = iout * ripple_ratio # Buck 拓扑电感计算公式：L = (Vin-Vout)*Vout / (fsw*ΔIL*Vin) l_value = (vin - vout) * vout / (fsw * delta_i * vin) # 峰值电流 = 输出电流 + 1/2 纹波电流 i_peak = iout + delta_i / 2 return { "inductance_h": round(l_value, 9), "peak_current_a": round(i_peak, 3), "ripple_current_a": round(delta_i, 3) }模型的任务只是判断"这是 Buck 拓扑"并正确抽取参数，公式和数值运算完全由脚本负责。这样即使模型把某个数值看错，计算工具也会基于错误的输入算出确定性的结果，至少不会出现"公式抄错"这种低级但致命的幻觉。更重要的是，评审阶段可以直接对账：每个输出数字都能追溯到"哪条公式、哪个输入"，而不是模型嘴里蹦出来的。
3.3 第三层：评审 Agent 与规则引擎的双重把关
有了证据链和工具化计算，方案一般已经比较靠谱了。但我还是加了第三层保险：评审回路。
设计 agent 生成方案后，第二个"评审 agent"以完全不同的角色提示词启动。它的任务不是重新设计，而是拿着规则清单逐项挑毛病。规则清单包括降额系数检查、标准值检查、热约束检查、物料可用性检查。
三层结构的价值在于互相兜底：检索接地挡住"编造参数"，工具计算挡住"算错公式"，评审回路挡住"逻辑不自洽"和"违反规范"。我实测下来，三层都走完的方案，拿到板子上电后需要返工的概率显著低于裸模型输出——这也是我愿意把它写成文章分享出来的原因，这套思路本身是强于具体工具的。
4. 从需求到 BOM：电源设计 Agent 的完整工作流
4.1 需求解析：把一句话需求扩展成规格矩阵
agent 接到任务的第一个动作，不是急着选芯片，而是把手里的原始需求拆成一张规格矩阵。比如用户说"做一个 9-18V 输入，5V/2A 输出的车载电源"，agent 会输出：
- 输入电压范围：9V~18V（考虑冷启动 6V 和抛负载 36V 需要确认）
- 输出电压/电流：5V / 2A，持续 2A，峰值需确认
- 纹波目标：<50mV 或 <1%，需用户确认
- 效率目标：>90% 最好，未指定则按默认
- 工作温度：车载环境 -40℃~85℃，需明确
- 隔离要求：非隔离，默认
- EMC 等级：车载 CISPR25，需确认
这里有个关键设计：所有"未明确"的项，agent 必须列出并标注"需人工确认"，而不是自己拍一个。这是从源头防幻觉——需求侧的模糊不清，到了后端全都会变成错误的假设。
4.2 拓扑选型与参数计算工具链
规格矩阵确认后，agent 进入选型阶段。选型逻辑用规则引擎预置，不靠模型自由发挥：
- Vout 远低于 Vin 且压差大 → Buck
- Vin 与 Vout 接近 → LDO（优先看压差和功耗）
- Vout 高于 Vin → Boost
- 需要隔离 → Flyback / LLC（功率不同选型不同）
选定拓扑后，调用参数计算工具链生成关键参数：电感值、峰值电流、输出电容容值、输入电容容值、反馈电阻分压。这些参数全部来自上一节讲的工具化计算。然后 agent 会基于这些电参数，去语料库中检索满足条件的电源控制芯片型号，优先看厂商应用笔记里推荐的参考设计。
4.3 元件筛选：从厂商库到真实库存约束
这里分享一个我在实际项目里才领悟到的细节：电气参数最优的元件，不一定是最该选的。硬件设计永远受制于库存、采购周期和成本。
所以我在 agent 的元件筛选环节加了一个约束条件：候选元件必须同时满足电气参数、封装偏好、库存状态三项。agent 会在方案里标注每个推荐料的替代料和货期风险。比如某颗 10uF/25V 的 MLCC 电气参数完美，但仓库只有 300 颗，而项目需要 2000 颗，agent 就会降级推荐另一颗参数略低但库存充足的型号，并在备注里写明"直流偏压下有效容值需要实测确认"。
这一步把 agent 从一个"参数计算器"升级成了"懂供应链的硬件助手"，也是它在团队里能被接受的重要原因。
4.4 输出物：BOM、原理图要点与人工确认点
工作流跑完之后，agent 输出一份结构化的方案包。我们定义的最小输出集包括：
- 规格矩阵（含已确认与待确认项）
- 拓扑与关键计算过程（每个数字带公式出处）
- 候选 BOM 表（型号、关键参数、库存、替代料）
- 原理图设计要点（引脚接法、去耦、反馈网络）
- 人工确认点清单（哪些地方必须工程师拍板）
输出用固定 JSON 结构，方便后续对接内部系统。示意如下：
{ "spec": { "vin_min": 9, "vin_max": 18, "vout": 5, "iout": 2 }, "topology": "buck", "key_params": { "inductance_h": 4.7e-6, "inductor_peak_current_a": 2.8, "output_cap_uf": 47, "output_cap_voltage_derating": 2.0 }, "bom": [ { "ref": "L1", "part": "XAL4040-472", "spec": "4.7uH, Isat 3.4A", "stock_ok": true } ], "review_points": [ "输入电容需按抛负载电压校核耐压", "反馈电阻需选 E96 系列并确认精度" ] }这个输出物格式的好处是：工程师拿到手能直接评审，而不是看一大段模型生成的小作文。
5. Skill 与知识库的落地细节：资料分级、权限坑、版本回退
5.1 知识库语料分级：什么能进、什么必须在规则里
搭建知识库时，我踩过的最大坑就是"什么都往里塞"。论坛上的经验贴、自媒体的选型文章，看着有用，但一旦被 agent 当成依据，幻觉风险比不检索还大。
我把语料分成三级：
| 级别 | 内容 | 定位 |
|---|---|---|
| A 级 | 原厂 datasheet、厂商应用笔记、权威设计手册 | 唯一可作为证据的输出引用来源 |
| B 级 | 团队内部经验、历史项目复盘 | 可作为参考建议，不可作为参数依据 |
| C 级 | 论坛帖、自媒体、个人博客 | 一律不进知识库 |
这个分级不是嘴上说说，而是通过检索工具的权限配置落地的：agent 的检索接口只开放 A 级索引，B 级内容单独存放在另一个命名空间，需要明确调用才能访问，C 级完全不建索引。这样才能保证证据链的纯净度。
5.2 Skill 文件结构与读取权限坑
我最初把 skill 组织成这样的目录结构：
skills/ power_design/ SKILL.md # 技能说明与工作流入口 rules/ # 评审规则清单 derating.yaml checklists.md calc/ # 计算工具脚本 buck.py boost.py refs/ # A 级语料索引想法很清晰，落地时第一个坑就来了：agent 在读取 skill 文件时反复报一个 Windows 权限错误，日志里写着SetNamedSecurityInfoW failed。我一度以为是 Harness 本身的问题，排查到最后发现是路径权限和文件同步导致的：把 skill 目录放在 OneDrive 同步目录下，文件 ACL 被反复重置，agent 进程拿不到稳定读取权限。
解决办法很朴素：把 skill 目录挪到非托管的本地路径，比如D:\projects\harness_skills，然后用管理员权限执行一次目录权限重置：
icacls D:\projects\harness_skills /reset /T /C icacls D:\projects\harness_skills /grant "everyone:(OI)(CI)R" /T注意这里everyone仅限单人开发环境，团队环境建议按服务账号精确授权。这个问题在 Linux 内网服务器上基本不会出现，Windows 桌面版遇到的可能性更大，先说清楚免得后来人绕远路。
5.3 提示词优化插件与代码回退机制
社区里的提示词优化插件我一开始觉得是花架子，直到有一次评审 agent 漏检了一个降额问题才发现价值。原因是规则清单太冗长，模型在生成长上下文时把后半段规则"遗忘"了。提示词优化插件会把规则压缩成结构化约束优先级，并重排顺序，让关键硬约束排在注意力权重最高的位置。装完之后同一份清单的漏检率明显下降。
代码回退机制则是调试阶段的神器。我改过一次计算脚本里的纹波系数，结果导致后续所有方案的电容值偏大，当时连续跑了好几个任务都没发现。如果没有回退功能，我得靠 git 翻旧版本再重新部署；有了回退，直接在 Harness 里把该 skill 的计算模块恢复到上一个正常版本，重新验证一次就解决。对 agent 这种"会积累状态"的系统来说，回退能力不是可选项，是安全底线。
6. 内网部署、并发实测与一段真实对话复盘
6.1 内网服务器部署与离线使用
部署到内网服务器有几个关键步骤，按顺序走能少踩很多坑：
- 在内网服务器安装 Harness 服务端，Windows 或 Linux 均可，建议 Linux。
- 配置模型接入。离线局域网环境下，要么接内网已有的模型推理网关，要么提前部署本地模型服务，确保 agent 进程访问的模型地址是内网可达的。
- 上传 skill 包。把验证过的
skills/目录打包，通过管理界面或命令行导入，注意保留目录结构和文件权限。 - 验证权限。用最小技能包跑一次文件读取，排除前文说的权限问题。
- 跑通一条端到端工作流，确认模型服务、检索服务、计算工具三个环节都正常。
离线环境还有一个额外收益：模型的 temperature 设置可以调得很低，反正没有联网干扰，输出稳定性比在线服务更好。
6.2 并发与 token 成本实测
电源硬件设计不是高频场景，团队里同时用的也就几个人。但我在压测时发现，评审回路会让 token 消耗翻倍——一份方案的设计部分和评审部分基本各占一半。单次完整流程实测大约消耗 8000 到 12000 token，其中评审 agent 占比接近一半。
并发方面，内网服务器上同时跑 3 到 4 个设计任务是没问题的，主要瓶颈在模型推理服务的吞吐，不在 Harness 本身。建议把长任务（比如批量评审）丢到队列里异步执行，避免前端等待。token 优化的小技巧是：把评审清单和设计规则中恒定不变的部分做成 skill 内缓存，而不是每次重新发送，能省不少上下文长度。
6.3 一段真实对话复盘：它怎么拒绝了一次幻觉
最后分享一段让我印象深刻的真实对话。我故意测试：让 agent 推荐一款 "TPS54331" 的输出电容，而这颗料的 datasheet 在语料库里只有旧版本。
agent 的回答被我全程录下来了，大意是：
"资料库中收录的 TPS54331 手册为 2016 年版本，未收录最新版本。基于现有手册，参考设计使用的是 47uF 陶瓷电容。但请注意：陶瓷电容在 5V 输出下的直流偏压效应显著，建议选用 50V 耐压规格，并在实物上实测有效容值。若需确认最新版手册中的推荐值，请将新手册加入知识库后重新查询。"
这段话放在防幻觉架构里看，堪称标准答案：它明确区分了"资料里有什么"和"资料里没有什么"，对不确定的地方直接标注，没有为了显得专业而编造。这正是二层约束共同作用的结果——检索层告诉它手册版本不全，规则层提醒它直流偏压风险，它选择了把不确定性摊开在桌面上。
做了这么久，我的体会是：防幻觉的终极目标不是让 agent 永远正确，而是让 agent 永远诚实。错误不可避免，但"可追溯的错误"在硬件设计里是可以被评审流程接住的，"莫名其妙的正确"才是真正危险的。现在这个 agent 已经在我们团队里承担了前期方案评审和 BOM 预检的工作，每次它说"我不确定"的时候，我反而比它给出笃定答案时更放心。
如果你也想在自己的领域搭类似的 agent，建议从最痛的一个环节切入，先把"拒绝回答"和"证据链"这两条规则立住，再逐步加计算工具和评审回路。工具会迭代，模型会升级，但"所有输出必须有出处、所有数字必须经过计算"这个原则，值得一直保留下去。
