最近把一套基于 Deepseek Harness 搭建的防幻觉电源硬件设计 Agent 架构跑通了。整套系统的核心目标就一个让大模型在做电源硬件设计这种高风险工程任务时把幻觉率压到工程可接受的范围而不是追求看起来很聪明。文章会从设计动机、Harness 架构、四层防幻觉机制、Skill 体系、内网部署细节到实战排查完整拆一遍适合正在搞 Agent 落地的开发者以及想给硬件研发流程引入 AI 辅助的团队参考。先说清楚为什么要做这件事。电源设计Buck、Boost、LDO、反激这类是参数极度敏感、出错成本很高的工程领域。我试用过几款通用对话式 AI 做方案辅助效果怎么说呢——它能十分钟内给出一份排版漂亮、逻辑连贯、参数齐全的电源方案但你要是真拿这份方案去画原理图大概率会在打样回来后发现电感纹波超标、反馈分压电阻不在标准系列里、陶瓷电容在直流偏压下实际容值掉了一大截。这些错误不是差一点而是模型在一本正经地编数据。所以我的核心结论是LLM 本身没有不犯错的能力只能靠架构把它约束在可控范围。Harness 在这里不是某个商业产品而是一套设计模式——在模型外围加一层控制运行时统一管理工具调用、记忆、权限、校验和审计。模型负责思考Harness 负责把关。这篇分享就是这套模式的完整落地记录。1. 为什么电源设计需要防幻觉Agent1.1 电源设计的容错窗口到底有多小拿最常见的同步 Buck 电路举例。设计目标输入 12V输出 3.3V/2A开关频率 500kHz要求电感纹波电流不超过负载电流的 30%。电感理论值计算公式是L (Vin - Vout) × Vout / (Vin × ΔIL × f)代入数值Vin12VVout3.3VΔIL0.6Af500kHz得到 L 28.71 / 3,600,000 7.975μH工程上取 E24 系列标准值就是 8.2μH。这个计算本身并不复杂但 LLM 在算这一步时容易犯几种错把 kHz 当成 Hz 代入导致结果差三个数量级把分母位置的 Vin 漏掉或者干脆跳步直接回忆出一个 10μH 的常用值。更隐蔽的错误是它会在推导过程里藏一个小数点错误最后结论还写得理直气壮。在电源设计里这种错误意味着什么意味着 PCB 打样回来发现纹波超标要重新选型、改布局、再打一版周期拉长两周费用翻倍。硬件工程师的时间本来就紧如果 AI 助手给的方案还需要人从头到尾重新验算那它其实不如一张 Excel 计算表好用。所以防幻觉在这个领域不是优化项而是准入门槛。1.2 LLM 幻觉在工程领域的三种典型表现我在实际使用中总结工程场景下 LLM 幻觉主要有三种形态。第一种是编造器件型号和参数。LLM 对真实芯片型号有模糊印象但细节会混。比如它知道 TPS54560 是一颗降压芯片但可能把最大输入电压从 42V 说成 60V或者把开关频率范围说错。更麻烦的是它会创造看起来很像的型号比如 TPS54561、TPS54562这些型号可能实际不存在或引脚定义完全不同。工程师照着画备料阶段才发现料号查无此物。第二种是编造计算结果。这类错误最难防因为格式和推导过程太像真的了。模型会列公式、带数字、给结果看着完整但中间某一步代错。通用对话场景里这种错误无所谓在硬件设计里就是一到两版 PCB 的代价。第三种是编造规格书内容。模型被问到这颗芯片的静态电流是多少时如果知识库里没有它不会说不知道而是会给一个合理的数值比如 120μA。这个数值可能来自同系列另一颗芯片也可能纯属编造。认清这三种形态防幻觉的方向就很明确了不让模型替我们计算不让模型凭记忆报参数要求每个引用都有来源。这就是后面整套架构的设计起点。1.3 为什么底座选了 Deepseek选 Deepseek 做底座我并不是因为它热门才选的而是对比之后的工程决策。第一是推理能力。硬件设计场景里LLM 要做的是多步推理——先分析约束再选拓扑再定器件再算参数每一步之间有关联。Deepseek 在数学和逻辑任务上的表现是够用的这一点对让它想清楚再动手很关键。我试过一些轻量模型做同样的事它们在简单问答上没问题但一进入多轮推理就频繁抄近路跳过必要步骤直接给结论这对防幻觉是致命的。第二是工具调用的可用性。Harness 的核心是让模型调用外部 Skill这要求底座支持正规的 function calling 格式并且参数解析稳定。Deepseek 的 API 兼容 OpenAI 格式工程接入成本低实测在工具调用的格式正确率上可以接受。第三是部署可控。权重开源可以放在内网 GPU 服务器上跑推理服务。电源设计涉及公司内部的选型库和未发布产品信息这些数据不可能送到外部 API本地部署是唯一选择。当然 Deepseek 也有缺点长上下文中的指令遵循会漂移比如你要求所有数值引用必须带 calc_id它在前面几轮能遵守到第二十轮就偷懒这个在后面讲。2. Harness 架构给 Agent 装上缰绳2.1 Harness 和 Agent 的边界在哪里先理清一个易混淆的概念。很多人把 Agent 理解成能调工具的 LLM其实不完整。Agent 应该等于模型 记忆 技能 控制循环四者缺一不可。模型提供语言与推理能力技能提供可执行工具记忆保存上下文和设计状态控制循环决定下一步做什么。而 Harness 正是控制循环的工程化实现。我习惯用一个类比模型是发动机Harness 是传动系统、方向盘和刹车。发动机马力再大裸奔的车没法上路因为没有转向、没有制动、没有仪表盘。很多 Agent 项目的问题恰恰是发动机裸奔——模型能力很强但它想干什么就干什么想调工具就调不想调就自己编。在工程场景里这绝对不行。Harness 和模型的边界也值得说清楚。模型只做两件事接收输入、生成输出。Harness 负责除此之外的一切——决定调用哪个技能、校验技能返回值、拦截危险输出、维护记忆、记录审计日志。模型甚至不知道 Harness 的存在Harness 却知道模型的每一步行为。这种不对称是刻意的把所有关键控制逻辑放在确定性代码里而不要放在模型行为里。模型行为不可预测代码行为可预测。2.2 Harness 层的六个核心组件我的 Harness 层由六个组件组成每个都有明确职责。Orchestrator主控循环是整个系统的核心维护一个状态机加消息循环读取当前设计状态构造 prompt 发给模型模型返回文本或工具调用请求Orchestrator 执行工具、把结果写回上下文继续下一轮直到设计任务完成。它不关心电源设计本身只关心循环是否正常推进、有没有超时、有没有陷入死循环。Skill Registry技能注册表保存所有可调用技能的元数据技能名、功能描述、参数 JSON Schema、执行函数入口。模型看到的只是技能描述真正的执行逻辑在注册表里。这样技能内部逻辑可以随时改不影响模型的调用方式。Memory Manager记忆管理器负责上下文组织。电源设计是多轮长对话每一步的计算结果、检索到的规格书片段、用户约束都需要结构化存储。我采用核心状态 对话摘要 原始消息窗口三级结构避免上下文无限增长导致 token 超限。Guardrails护栏层负责输入输出安全。输入侧检查用户 prompt 是否有越权指令输出侧检查模型生成内容是否包含禁止格式或未经验证的参数。在硬件设计场景里它还负责拦截没有 calc_id 引用的数值。Evaluator验证器执行数值一致性检查、规则引擎校验、置信度评估。它不关心文本通顺与否只关心输出是否可验证。Audit Log审计日志记录每轮交互的完整轨迹模型输入、工具调用参数、工具返回值、最终输出、校验结果。当工程师发现一个错误参数就可以回溯到它究竟产生于哪一步是检索错了、计算错了还是模型叙述错了。2.3 控制流设计什么时候信任模型什么时候强制走工具这是整个架构的灵魂。原则只有一句话模型做选择工具做计算规则做校验。具体拆开有三条。第一所有数值计算必须走工具。模型的思考可以被信任但它的算数不行。哪怕只是一个欧姆定律我也要求它调用计算 Skill而不是心算。电源设计里九成以上的幻觉错误发生在模型自己算数这个环节把这个环节彻底关掉幻觉率能降一大截。第二所有器件参数必须来自检索结果。模型记忆中TPS54560 最大输入电压 42V这种信息不可信必须通过 spec_rag_query 工具检索结构化知识库拿到带条件字段的参数值。如果检索结果为空模型必须输出未找到该参数而不是猜一个。第三方案输出前必须过规则引擎。规则引擎内置降额检查、标准值检查、热限检查等硬规则任何违反规则的方案都不能直接输出必须退回重新设计。规则引擎是确定性代码它的判断结果百分之百可预期这是它和模型最大的差别。这三条规则看着简单但实现时有一个隐藏难点怎么让模型知道什么时候该调工具。我靠 system prompt、工具描述、输出模板三重约束再靠 Evaluator 的强制校验兜底才把模型跳过工具直接输出的行为压到低频。3. 防幻觉机制的四层防线3.1 第一层防线RAG 知识注入把规格书变成结构化库防幻觉的第一层是让模型有据可查。我的做法是把常用电源芯片的 datasheet 解析成结构化 JSON存入向量库加参数索引。一开始我犯过一个典型错误把 PDF 整份塞进向量库。效果很差原因是 datasheet 里的参数是条件相关的。同一个最大输出电流在不同输入电压、不同开关频率下是完全不同的值。向量检索只能告诉你这段内容在文档里出现过没法告诉你当前设计条件下该用哪个值。模型拿到一段含混的参数描述最终还是自己判断、自己编。后来我改成结构化抽取。每个参数单独存一条记录带完整的条件字段{ part_number: TPS54560, parameter: switching_frequency, value_min: 100000, value_max: 2500000, unit: Hz, conditions: RT/CLK pin connected to GND, note: 开关频率由外部电阻设定, source_page: 7, doc_hash: a3f9c2... }检索时query 直接精确匹配参数名加条件而不是模糊匹配段落。模型拿到的是参数名 数值范围 适用条件 来源页码的原子化信息它很难再把关断电流和工作电流混在一起因为这两条记录的 parameter 字段不同检索结果里标注得清清楚楚。这个知识库的构建成本不低三十颗常用芯片的解析加人工校对我花了两周时间。但这是值得的它是整个防幻觉体系的地基没有可靠的参数来源后面的一切校验都是空谈。3.2 第二层防线计算引擎外置LLM 永远不做算术第二层是让数值计算彻底脱离模型。原理很简单LLM 做算术的误差率远高于确定性代码那就在架构上禁止它做算术。我实现了一个计算 Skill 包每个函数对应一类电源计算Buck 电感、反馈分压电阻、输出电容纹波电流、热阻温升。模型需要某个数值时不自己算而是调用对应 Skill参数传给函数函数返回计算结果。以 Buck 电感为例def calc_buck_inductor(vin, vout, iout, ripple_ratio, freq): delta_i ripple_ratio * iout l_ideal (vin - vout) * vout / (vin * delta_i * freq) l_std nearest_e24(l_ideal) peak_current iout delta_i / 2 return { calc_id: make_calc_id(), L_ideal_uh: round(l_ideal * 1e6, 2), L_std_uh: l_std, peak_current_a: round(peak_current, 3), delta_i_a: round(delta_i, 3), std_series: E24, formula: L(Vin-Vout)*Vout/(Vin*dI*f) }这里有几个关键设计。第一返回值带 calc_id这是数值指纹。模型在最终输出里引用任何数值必须带上 calc_id。Evaluator 层会检查最终报告里的关键数值能否在之前的工具返回值里找到找不到就拦截。第二函数内部已经做了标准值就近选取返回的 L_std 是 E24 系列的值模型不会自作主张选一个更好看的非标值。第三返回值带公式字符串方便工程师复核也方便模型在解释时引用公式而不是自己重新推导。我把让模型解释计算结果和让模型计算严格分开模型只负责把 calc_id 背后的数值翻译成设计语言比如取值 8.2μH 是因为它是最接近理论值的 E24 标准电感。它没有机会篡改数值本身。3.3 第三层防线设计规则校验硬规则不走商量第三层是规则引擎。电源设计里有一堆硬规则违反就是违反没有商量空间。这些规则我全部写成确定性代码在方案输出前强制执行。规则我分了三个等级。Error 级别的规则直接阻止方案输出Warning 级别的规则允许输出但必须附警告。规则不是越多越好抓主干就行。以下是目前维护的核心规则集规则名等级说明输出电容耐压降额Error电容额定电压 ≥ 1.5 × 实际最大电压陶瓷电容还要考虑直流偏压降额电感饱和电流裕量Error电感饱和电流 ≥ 1.2 × 峰值电流否则重载时电感直接饱和反馈电阻标准值Error分压电阻必须在 E24 系列内禁止输出非标值反馈电阻功耗降额Warning电阻实际功耗 ≤ 额定功耗的 50%必要时提示换封装结温限制ErrorTj Ta θJA × P 必须低于 125°C超过则报错穿越频率约束Warning环路补偿后的穿越频率应低于开关频率的 1/10补偿参数范围Warning补偿电容、电阻在合理范围内避免极端值规则引擎的执行不依赖模型。方案从模型出来之后先经过规则引擎逐条检查全部通过才允许输出。我做过一个测试故意让模型设计一个输出电容耐压不够的方案模型自己检查时发现不了但规则引擎百分之百能拦截。这验证了一个观点防幻觉不能指望模型自查要指望确定性代码来他查。3.4 第四层防线置信度门槛与人工确认最后一层是允许不知道的机制。工程 Agent 和聊天机器人的一个根本区别是聊天机器人必须回应工程 Agent 必须准确。所以我给输出加了置信度评估。置信度由三个维度综合计算结论是否有 RAG 来源、关键数值是否有 calc_id 引用、是否通过规则引擎校验。三者都满足记为高置信度缺任一项降为中或低。低置信度的设计决策比如芯片选型、拓扑选择这些影响全局的步骤系统不直接输出而是进入请求人工确认流程。这个机制有一个副产品——模型开始学会说我不知道。我在 system prompt 里明确写了一句如果你没有足够依据请直接说明缺少哪些信息不要推测。配合置信度机制模型在不确定时会主动要求补充输入参数或者明确说检索不到对应参数而不是硬编一个。这听起来简单但对工程 Agent 来说价值极大。一个会说不知道的助手比一个什么都能答的助手可靠得多。4. 电源设计 Agent 的 Skill 体系搭建4.1 Skill 的定义与注册机制说完了防线再说执行层。Skill 是 Harness 架构里模型和环境之间的接口它的设计直接影响模型调用的稳定性和整个系统的可靠性。我的 Skill 定义包含五个字段name 唯一技能名、description 给模型看的功能描述、parameters 参数 JSON Schema、handler 执行函数引用、permission 调用权限等级。description 写得好不好直接决定模型会不会正确调用。写得太模糊模型会乱调用写得太具体模型又可能漏调用。我一般会让 description 包含使用场景示例和反例。注册机制上我采用装饰器模式registry.register( namecalc_buck_inductor, description计算Buck电路电感量。输入Vin、Vout、Iout、纹波比、频率返回理论值和标准值。当用户询问电感选型时必须调用。, parameters{ type: object, properties: { vin: {type: number, description: 输入电压(V)}, vout: {type: number, description: 输出电压(V)}, iout: {type: number, description: 负载电流(A)}, ripple_ratio: {type: number, description: 纹波电流比例例如0.3表示30%}, freq: {type: number, description: 开关频率(Hz)} }, required: [vin, vout, iout, ripple_ratio, freq] } ) def calc_buck_inductor(vin, vout, iout, ripple_ratio, freq): ...注册之后Orchestrator 会在每轮对话前把所有可见技能的 description 和 parameters 拼进 system prompt 的 tools 字段模型就能知道有哪些技能可用、每个技能是干什么的。模型决定调用哪个技能、填什么参数Orchestrator 负责执行对应 handler。这套机制是 Agent 开发的通用做法但用在电源设计上重点是每个 Skill 的输入参数从哪来——必须由模型从用户需求和上下文中提取绝不能凭记忆补。4.2 核心 Skill 清单与设计要点目前维护了七个核心 Skill覆盖降压电源设计的完整链路。Skill 名功能输入输出topo_selector拓扑选择输入输出电压、功率、隔离要求推荐拓扑加理由buck_inductor_calcBuck 电感计算Vin/Vout/Iout/纹波比/频率理论值加 E24 标准值加电流应力feedback_divider_calc反馈分压电阻计算Vout/Vref/阻值范围偏好E24 标准阻值加实际输出电压加功耗output_cap_check输出电容校验容值/耐压/ESR/纹波电流规格通过加实际纹波估算thermal_check热计算封装热阻/功耗/环境温度结温加降额建议derating_check降额检查器件参数与实际应力通过/警告/错误spec_rag_query规格书结构化检索芯片型号加参数名加条件参数值加条件加来源页码挑两个设计上容易出错的 Skill 细说。feedback_divider_calc 是我调整最多的一个。它的核心是输出 Vref 和上下两个电阻的配比但工程上有两个隐藏约束一是阻值必须在 E24 系列内二是上下电阻比值误差会影响输出电压精度。我的实现是先按目标 Vout 和 Vref 算理论比值然后在 E24 系列里枚举可行的组合选出实际输出电压最接近目标且功耗达标的组合。模型拿到的不是一个公式加一个答案而是一个枚举比较后的工程结果。这就是工具比模型可靠的地方。derating_check 则是一个规则集合把不同元器件的降额要求做成可扩展的检查表。陶瓷电容要查直流偏压特性所以同样标称 10μF 的电容在 12V 偏压下实际可能只剩 6μF电阻要查功耗降额0805 封装在高温下额定功率还要打折。这些经验知识写死在检查逻辑里比让模型去记住可靠得多。4.3 Skill 编排一次完整设计是怎么被调度的七个 Skill 不是各自独立的它们之间存在依赖关系。我用一个阶段状态机来编排用户描述需求 → 需求解析 → 拓扑选择 → 芯片选型 → 外围参数计算 → 规则校验 → 输出设计报告。每个阶段Orchestrator 给模型一个阶段目标模型在这个目标内决定调用哪些 Skill。阶段之间不能跳级。用户直接问帮我算一下反馈电阻Orchestrator 允许模型跳过拓扑选择直接进入参数计算但用户问帮我设计一个 12V 转 3.3V 的电源模型必须按顺序走完整流程不能直接跳到反馈电阻计算——因为在拓扑和芯片都没定的情况下反馈电阻的计算前提根本不存在跳级必然导致幻觉。这个编排有一个实际收益错误的传播被截断了。模型在拓扑选择阶段选了降压架构但芯片选型阶段从 RAG 里找到的是一颗升压芯片Evaluator 会发现芯片类型和拓扑不匹配直接报错退回重新选型而不是带着错误继续往下走。每一阶段的校验都在给后面的阶段排雷。5. 实操从零搭建这套架构5.1 项目结构与环境准备写代码之前先规划清楚项目结构。我目前的目录长这样power-agent/ ├── harness/ │ ├── orchestrator.py # 主控循环 │ ├── guardrails.py # 输入输出护栏 │ ├── memory.py # 三级记忆管理 │ ├── evaluator.py # 验证器 置信度 │ └── audit.py # 审计日志 ├── skills/ │ ├── registry.py # 技能注册表 │ ├── power_calculations.py # 计算类技能 │ ├── rule_engine.py # 规则引擎 │ └── specs.py # RAG检索技能 ├── knowledge/ │ ├── parse_datasheet.py # 规格书结构化解析 │ ├── build_vector_index.py # 向量库构建 │ └── data/ # 结构化JSON ├── config/ │ ├── model.yaml # 模型服务配置 │ └── rules.yaml # 规则集配置 └── main.py # 入口环境上我用 Python 3.11推理服务用 vLLM 跑在单张 A100 80G 上模型是 Deepseek 的量化权重API 兼容 OpenAI 格式客户端直接复用 openai-python 库。向量库用的 Qdrant结构化参数检索用轻量方案——参数名加条件拼成索引字段做精确匹配向量检索只负责找候选参数块不负责理解参数含义。经验提醒不要一开始就追求重架构。我第一版用了完整的 Agent 框架加复杂状态管理调试成本很高。后来砍掉重做用最简单的消息循环 技能注册 校验函数结构反而更快跑通。Agent 系统的复杂度应该跟着需求长而不是上来就堆。5.2 Harness 配置的核心参数model.yaml 里有几个关键配置值得说。temperature 我设为 0.1这个值在少一点创造性、多一点确定性和不要完全机械重复之间比较平衡。电源设计不需要模型的灵感需要的是稳定温度必须低。context window 设置为 64k。我试过更大的窗口但实测在超长上下文中模型的指令遵循会衰减——越到后面越容易忽略必须引用 calc_id这类约束。64k 配合记忆管理能让每轮对话的 token 用量控制在窗口一半以内给模型留出注意力余量。注意大上下文不一定是好事。我在 128k 窗口下测试过多轮电源设计模型在第十五轮之后频繁出现忘记调用工具的情况把窗口缩回 64k 并配合摘要压缩后这个问题明显缓解。还有一个关键配置是 tool_choice。大部分场景设为 auto让模型自己决定是否调用工具但在参数计算和规格检索这类必须用工具的节点我在 prompt 里强约束你此时必须调用工具禁止直接输出数值。Evaluator 再兜底检测到数值出现在最终报告但找不到对应 calc_id直接报错。5.3 内网服务器部署的实操要点部署到内网服务器对电源设计这个场景是硬需求。原因很实际设计过程中的选型库、内部测试数据、BOM 信息都属于公司资产不能出内网。我的部署流程分三步。第一步准备模型文件。从官方渠道下载 Deepseek 的量化权重放到内网 GPU 服务器的模型目录。注意检查模型文件的完整性量化版本和解码配置必须对应tokenizer 配置错位的话后面 API 调用会出现乱码问题还特别难排查。第二步启动推理服务。用 vLLM 起一个 OpenAI 兼容的 HTTP 服务指定模型路径、张量并行参数和最大上下文长度。启动后用简单的请求做一次最小验证确认基本的 chat completion 和 function calling 都正常再往下走。第三步打通 Harness 层。把 model.yaml 里的 base_url 指向内网服务地址实测一轮对话、一次工具调用和一轮多轮对话确认链路完整。这一步我踩过一个坑vLLM 的 function calling 在参数 schema 兼容性上和大模型 API 偶尔有差异需要对 parameters 做一层序列化适配否则会出现工具调用格式正确但参数解析失败的问题。部署完成后强烈建议先跑一遍冒烟测试集——用十组已知正确设计用例去测整套系统确认结果和期望一致再交给工程师试用。没有这一步你永远不知道模型会在真实项目里以什么奇怪的方式出错。5.4 关键代码主循环与数值一致性校验主控循环是系统最核心的代码它决定一个设计需求从进入系统到输出方案的完整路径。核心逻辑是维护一个状态对象循环调用模型处理工具调用校验返回值遇到终结条件退出def main_loop(user_request): state init_state(user_request) while not state.is_finished: messages memory.build_messages(state) resp model.chat(messages, toolsskill_schemas()) if resp.tool_call: tool_result skills.execute(resp.tool_call) rule_result rule_engine.check(tool_result) # 规则引擎兜底 state.append_tool_result(tool_result, rule_result) continue # 模型直接输出文本进入护栏校验 report guardrails.validate(resp.content) if evaluator.pass_all(report, state): state.finish(report) else: state.append_error(evaluator.errors) return state.final_reportEvaluator 里最关键的是数值一致性校验。实现思路很简单从状态对象里提取所有历史工具返回值建立一张可信数值表键是 calc_id 加参数名然后扫描最终报告里的数值凡是在必须验证语义范围内的数值电阻、电感、电压等都在可信数值表里查找匹配。查找不到或不一致直接判为不通过。这个逻辑是我从一次事故里总结出来的——模型在总结结论时会把工具返回值抄错只有靠代码回溯对比才能拦住。6. 常见问题与排查实录6.1 问题速查表跑这套系统以来遇到了一堆问题整理成速查表按现象 → 原因 → 解法排列。现象可能原因解决方案模型给出非标电阻值比如 3.17kΩ模型跳过了 feedback_divider_calc自己算了个值Evaluator 加标准系列检查发现非 E24 值直接拦截最终报告数值与工具返回值不一致模型在总结时凭记忆复述脱离了 calc_id要求总结必须引用 calc_idEvaluator 做一致性校验RAG 检索到的参数被模型张冠李戴检索返回多个候选参数块模型选错上下文检索结果带参数名和单位标签提示模型核对长对话后模型不再调用工具上下文过长指令遵循衰减压缩历史消息保留核心状态缩短 context window规则引擎误报规则边界没考虑温度系数和条件参数规则分级Warning 只警告不阻断沉淀后再升级工具调用格式偶尔解析失败vLLM 的 function calling 参数格式有差异Harness 层加参数序列化适配层6.2 三个印象最深的实战坑第一个坑是模型忠实复述了错误数值。有一次测试模型调用 calc_buck_inductor 返回了 8.2μH但在最终报告里写成了10μH接近标准值。Evaluator 当时没有数值一致性校验错误直接漏过去了。排查发现模型不是恶意造假而是上下文压缩导致的记忆偏差——它记住了选个接近标准值的电感这个意图但把具体数值记混了。修复方案就是给计算 Skill 加 calc_id并在 Evaluator 里强制对比。这个坑直接推动了整个校验体系上线。第二个坑是规则引擎的边界条件。最初输出电容降额规则写的是额定电压 ≥ 1.5 倍最高实际电压但没考虑电容在高温和直流偏压下的同时衰减。有一次方案在 25°C 下校验通过工程师说用在 85°C 环境会出问题原因是电解电容在高温下容值衰减、ESR 升高纹波电流下的发热比常温严重得多。后来规则引擎加入工况条件参数提示工程师补充环境温度再做降额计算。这个教训说明规则需要跟着实际工况持续迭代写完就当金标准是会出事的。第三个坑是长上下文中的指令遗忘。多轮对话到第十五轮左右模型开始不调用工具、直接给计算结果system prompt 里的约束好像失效了。排查后发现不是 prompt 丢了而是上下文里夹杂了大量工具返回的 JSON 和检索片段把 system prompt 的注意力稀释了。解决方案是对话摘要压缩——把不重要的工具返回细节折叠成摘要只保留 calc_id 和最终数值把注意力预算还给系统指令。实测有效长对话后的工具调用率恢复到了正常水平。6.3 一条排查方法论这部分经验比任何单个修复都重要排查幻觉问题时不要盯着模型文本看要盯着系统轨迹看。每次幻觉必然有一个环节偏离预期——要么 RAG 返回了错误上下文要么模型在工具参数上填错要么 Evaluator 的校验规则有漏洞。用 Audit Log 回溯每一步找到偏离点修复对应环节。这套按轨迹定位的方法论比反复调 prompt 效率高得多。我后来把审计日志输出成结构化 JSON每条记录带时间戳、环节名、输入摘要、输出摘要排查问题从猜变成了看。提示如果一次幻觉问题排查超过半小时还没定位别继续猜了去翻审计日志。问题几乎一定藏在某一次工具返回值和模型叙述的差异里。7. 后续还能往哪个方向扩展这套架构目前已经能完成降压电源的辅助设计但要真正成为团队的日常工具还有几个方向值得继续做。一个是知识库的持续更新。现在的知识库只有三十颗常用芯片的参数实际项目里会不断引入新器件。我的想法是把 datasheet 解析做成半自动流水线工程师只需要把新 PDF 放进指定目录跑一次解析脚本人工校对后自动并入知识库。知识库的更新频率直接决定 Agent 能覆盖的设计范围。另一个方向是多域扩展。现在做的是电源硬件设计但Harness 防幻觉 领域 Skill这套模式是通用的。换一批 Skill、换一个知识库就能迁移到电机驱动、传感器选型或者 PCB 布局规则检查。核心的 Orchestrator、Guardrails、Evaluator 完全不用改。还有一块我自己在琢磨的是设计日志和版本管理。每次 Agent 输出一个设计方案都应该能记录完整的设计决策链支持对比不同方案的参数差异。这对团队协作和设计评审很有价值相当于把 Agent 从问答工具升级成设计记录系统。目前还在原型阶段等跑成熟了再单独写一篇。最后给想动手搭类似系统的朋友一个最直接的建议别一上来就追求功能全先实现一个 Skill 加一个校验规则的最小闭环让它在真实场景里跑起来再逐步加。防幻觉不是靠某一个技巧而是靠整套约束互相兜底。四层防线全部落地之后我观察到一个明显变化工程师愿意把 Agent 给出的设计方案直接拿去画原理图了这在以前是不可想象的。系统会犯错但只要每个错误都能被定位、被约束、被修正它就值得进到你的设计流程里。