最近把一套基于 Deepseek Harness 搭建的防幻觉电源硬件设计 Agent 架构跑通了。整套系统的核心目标就一个：让大模型在做电源硬件设计这种高风险工程任务时，把幻觉率压到工程可接受的范围，而不是追求"看起来很聪明"。文章会从设计动机、Harness 架构、四层防幻觉机制、Skill 体系、内网部署细节到实战排查完整拆一遍，适合正在搞 Agent 落地的开发者，以及想给硬件研发流程引入 AI 辅助的团队参考。
先说清楚为什么要做这件事。电源设计（Buck、Boost、LDO、反激这类）是参数极度敏感、出错成本很高的工程领域。我试用过几款通用对话式 AI 做方案辅助，效果怎么说呢——它能十分钟内给出一份排版漂亮、逻辑连贯、参数齐全的电源方案，但你要是真拿这份方案去画原理图，大概率会在打样回来后发现电感纹波超标、反馈分压电阻不在标准系列里、陶瓷电容在直流偏压下实际容值掉了一大截。这些错误不是"差一点"，而是模型在一本正经地编数据。
所以我的核心结论是：LLM 本身没有"不犯错"的能力，只能靠架构把它约束在可控范围。Harness 在这里不是某个商业产品，而是一套设计模式——在模型外围加一层控制运行时，统一管理工具调用、记忆、权限、校验和审计。模型负责思考，Harness 负责把关。这篇分享就是这套模式的完整落地记录。
1. 为什么电源设计需要"防幻觉"Agent
1.1 电源设计的容错窗口到底有多小
拿最常见的同步 Buck 电路举例。设计目标：输入 12V，输出 3.3V/2A，开关频率 500kHz，要求电感纹波电流不超过负载电流的 30%。电感理论值计算公式是：
L = (Vin - Vout) × Vout / (Vin × ΔIL × f)
代入数值：Vin=12V，Vout=3.3V，ΔIL=0.6A，f=500kHz，得到 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%，必要时提示换封装 |
| 结温限制 | Error | Tj = 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( name="calc_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_calc | Buck 电感计算 | 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, tools=skill_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_id，Evaluator 做一致性校验 |
| 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 给出的设计方案直接拿去画原理图了，这在以前是不可想象的。系统会犯错，但只要每个错误都能被定位、被约束、被修正，它就值得进到你的设计流程里。
