做电源硬件设计的人估计都有过这种“午夜惊魂”为了确认一颗MOSFET在极端工况下能不能扛住抱着规格书翻来覆去地核对SOA曲线或者明明算好了Buck电感的饱和电流结果量产时发现温升超标回头一查当初纹波电流估算就是拍脑袋拍出来的。这两年LLM大火身边不少同事开始尝试让大模型帮忙写代码、写文档但放到硬件设计上很多人试一次就劝退了——原因很简单它会把一个根本不存在的器件型号说得言之凿凿能把公式算错还一本正经展示推导过程。这种幻觉在纯软件场景可能只是多调试几轮在电源设计里是要出大问题的。所以我从去年下半年开始琢磨一件事能不能在LLM外面套一层架构让它老老实实按电源设计规范走该算的用代码算该查的从库里查拿不准就直接说不知道。折腾了小半年最终基于Deepseek Harness搭出了一套面向电源硬件设计的Agent智能体架构核心诉求就两个字防幻觉。这篇文章把这个架构完整拆开来讲包含选型理由、三重防幻觉防线、Skill体系的设计思路、完整搭建过程和踩坑记录适合正在研究Agent落地工程化、或者想用LLM辅助硬件设计评审的同学参考。我会尽量把每个“为什么”讲透而不是只给一堆配置片段。1. 为什么选Deepseek Harness先从电源设计的“硬指标”说起1.1 电源硬件设计场景对Agent提出的四个硬指标很多人一上来就问“Deepseek Harness和Agent到底啥关系”我自己的理解很简单Harness是一个Agent运行时框架Agent是基于它构建出来的智能体应用粗俗点比喻就是“引擎和整辆车”的区别。但真正让我从一堆方案里选中它的是电源设计这个场景对AI提出的四个硬指标。第一个硬指标是数值结果必须可复算。电源设计里大量计算是有明确公式的比如Buck变换器输出电感感值 L(Vin−Vout)×D/(ΔIL×fsw)设计规范里写着你直接套用就行不需要模型“创新”。如果让LLM直接心算它大概率在数字代入和单位换算环节翻车。所以框架必须支持强制工具调用模型只负责选公式、填参数实际计算交给代码执行器。第二个硬指标是知识来源必须可追溯。电源设计涉及的规格书、应用笔记、IPC标准、降额规范这些属于相对封闭的专业知识模型预训练阶段不可能完整覆盖而且容易张冠李戴。框架必须支持外挂知识库检索并且要能控制检索范围防止模型自己“脑补”库外内容。第三个硬指标是流程必须可编排。一个完整的电源设计任务从需求解析到拓扑选型、参数计算、器件选型、设计规则检查、BOM输出是有明确流程的。Agent不能一股脑把活全干完最好拆成多个阶段每个阶段有独立校验点。这要求框架具备稳定的工作流编排能力而不是靠模型自由发挥。第四个是部署环境受限。硬件设计涉及企业知识产权很多公司严格要求内网环境模型和Agent框架都得支持离线或局域网部署数据不能出园区。这个硬指标直接淘汰了一堆纯云端的方案。我早期用裸调API的方式做过一版功能上没问题但工程化很痛苦上下文管理、工具注册、重试机制、记忆持久化全要自己写而且每次模型升级接口都可能变。1.2 Deepseek Harness的核心能力拆解Skill、编排、内网我实际用下来Deepseek Harness对我最有价值的三个能力是Skill插件体系、工作流编排、内网部署友好。Skill体系相当于把“专业知识”和“专业技能”打包成可插拔的模块每个Skill自带意图描述、参数声明、执行脚本和输出模板模型在对话中识别到对应意图就触发生成参数并调用Skill。这正好完美承接了电源设计的知识封装需求。工作流编排方面Harness支持把任务拆成多个节点串联执行每个节点可以挂不同的Skill和校验逻辑。我在搭建时把“需求解析—拓扑选型—参数计算—器件选型—DRC检查—BOM输出”做成一条流水线中间任何一个环节校验不通过就回滚重来不会让错误结论流入下游。这个对硬件设计非常重要因为一个错误参数可能会被后面所有环节“信以为真”地传递下去。内网部署这块Harness的运行时本身不需要外部服务依赖模型可以挂载到内网自建的模型推理服务上。我们最终的生产环境就是纯内网模型权重放内网服务器向量数据库放内网Harness跑在应用服务器上整个链路完全不碰外网。关于依赖安装和模型初始化第一次配置确实有点绕但跑通一次之后后续复制部署就很顺了。1.3 对比裸调API和通用Agent框架差在哪里三种路线我都试过说点个人感受。裸调API适合快速验证单点功能比如写个脚本问模型“这个电路有什么问题”但它撑不起完整Agent。你要自己处理多轮上下文窗口、工具结果回填、异常重试、并发控制更不用说Skill管理和流程编排了。我第一版原型就是这么做的跑了差不多一个月就放弃了随便一个需求变更就要动一堆代码。通用Agent框架比如LangChain这类组件很全但编排复杂Skill复用弱而且很多第三方插件更新频繁版本兼容性问题耗掉大量时间。最头疼的是内网适配一些在线服务组件绕不开网络依赖安全评审过不去。Deepseek Harness的取舍在于它把“Skill”做成了核心抽象而不是把“Agent”做成万能黑盒。我理解它的定位是模型能力可以换但Skill和流程是稳定的资产。这正好符合工程化思维——你不想每次模型升级都在业务层返工。对比下来至少在电源硬件设计这个细分场景Harness是最对路的选择。2. 防幻觉架构的三重防线从源头堵住模型“自由发挥”2.1 第一重防线强制工具调用让模型“没得选”防幻觉不能只靠提示词说“请你谨慎一点”必须在架构层让模型没有自由发挥的空间。第一重防线就是强制工具调用所有涉及电源专业知识的问题模型不直接回答而是以结构化参数的形式触发对应Skill。Skill内部的判断和计算完全由确定性代码完成。我举个例子。用户说“帮我选一个输入12V、输出5V/3A的Buck方案”模型本身不做选型判断而是触发topo_selector这个Skill。Skill内部按约束矩阵筛选输入电压范围、输出电压电流、效率要求、成本优先级、开关频率范围候选结果和推荐理由全部来自规则代码而不是模型记忆。这样做的意义在于模型只能“选路”不能“造路”所有专业判断都落入我们预先定义好的逻辑里。这里有个关键操作细节在Harness的Skill协议里我们给每个Skill声明了参数Schema和必填项。如果模型漏掉了关键参数比如没问清输入电压范围Skill会触发反问而不是自己猜一个值填进去。这个机制要多测试因为模型有时候会自作聪明替你补全参数造成“看着很完整、实际是猜的”局面。我踩过这个坑后面会详细讲。2.2 第二重防线数值计算全走代码执行器模型不碰公式这一重是整个防幻觉设计里最重要的一层。所有涉及数值计算的环节一律由Code Interpreter或预置Python脚本完成LLM只负责识别公式、代入参数、描述物理意义实际加减乘除、单位换算、查表插值全部由确定性代码执行。我在Harness的Skill里预设了一组计算原语电源拓扑计算原语Buck/Boost/Buck-Boost/LDO、热设计计算原语热阻、温升、散热器选型、降额校验原语电压、电流、功率、结温、单位换算原语统一到SI制。以计算Buck输出电容为例任务输入是三组参数Vin12V、Vout3.3V、Io5A、fsw500kHz、纹波要求30mV。模型只负责调用skill_calculate_buck_cout并填入参数真正算的是脚本# buck_output_capacitor.py def calc(L_design, delta_il, fsw, dv_out): # CCM模式Buck输出电容按纹波要求估算 cout delta_il / (8 * fsw * dv_out) return cout # 带中间量输出便于证据链复核 L 3.3e-6 # 感值 delta_il 1.5 # 纹波电流取Io的30% fsw 500e3 # 开关频率 dv_out 0.03 # 输出纹波要求 cout calc(L, delta_il, fsw, dv_out) print(f理论输出电容 {cout*1e6:.1f} uF)算完以后脚本会同时输出纹波电流、峰值电流等中间量比如“L3.3µH峰值电流Ip5.75A理论输出电容Cout12.5µF”。这些中间量模型无法篡改只能引用。一旦计算结果和模型说出来的话对不上证据链就会暴露问题。这也是为什么我说“模型不碰公式”是防幻觉的底线只要你让模型参与过哪怕一次数值运算都要做好它算出错的准备。2.3 第三重防线证据链输出与“拒绝回答”机制最后一层防线在输出端。我在Harness里配置了证据链模板任何结论必须包含四项内容依据的公式或规范条款带出处、代入的实际数值与单位、计算中间量与最终结果、适用性限制说明。这个模板挂在每个Skill的输出节点上强制生效。刚开始我认为有前两重防线就够了直到遇到一个真实的反例。有一次模型一本正经地说“TPS54560的最大占空比是95%”但我们库里的规格书明确写的是92%。第一重防线没拦住因为这个问题绕过了Skill直接走到了通用问答分支第二重防线也没拦住因为这不涉及数值计算。最终是第三重防线发现它的依据栏里写的只有“我记得”置信度评分极低被标记成“待人工复核”这才没把错误结论落到设计文档里。后来我在规则引擎里补了一条“占空比极限值”的约束把常见DC-DC芯片的关键极限参数做成结构化表供模型按型号精确检索才算把这个口子封死。这件事让我意识到防幻觉是体系工程三层防线各有盲区只有叠在一起才能兜住。对于无法在知识库或Skill里找到明确依据的问题Harness里的策略是引导模型输出固定语句“知识库未覆盖该问题建议人工核对”并直接进入待复核队列而不是硬给一个“看起来像答案”的答案。2.4 一个真实案例92%占空比怎么被拦下来的展开说下这个案例。当时我们在测试一个同步Buck设计评审场景用户上传了原理图附带一句“帮我看看这个方案有没有问题”。模型先扫描了一遍然后开始点评其中有一条说“TPS54560的最大占空比是95%低输入电压工况下要注意”。乍一听很专业细查就有问题。我排查的路径是这样的先查对话日志发现这条结论不是通过Skill产出的而是模型在通用回答分支里“顺手”写的第一重防线漏掉。然后我用代码执行器复算了这个场景需要的占空比数据发现设计工况需要的最大占空比其实是88%左右没有超过92%的规格上限但95%这个数字本身就是错的属于模型记住了“大概数值”。最终靠证据链模板把它标记为低置信度并在复核阶段由硬件老工程师一眼看穿。这个案例让我总结出一个经验给模型保留“自由问答”通道是有风险的。如果你无法保证一个领域内所有问题都能被Skill覆盖那就必须对通用问答分支的输出做额外的证据审查或者干脆在专业领域内关闭自由问答只允许“查到什么说什么”。我后来在Harness里设置的是凡是用户提问命中电源设计关键词一律走Skill路由只有闲聊类和管理类问题才允许通用回答效果立竿见影。3. 电源硬件设计Agent的整体架构与Skill体系3.1 五个核心模块编排器、Skill注册中心、规则引擎、验证节点、记忆我搭出来的Agent不是单个Prompt套一个模型而是把职责拆成了五个模块。第一个是编排器负责把用户需求解析成任务分解图决定先调哪个Skill、后调哪个Skill它相当于整个Agent的“项目经理”。第二个是Skill注册中心管理所有已注册的Skill提供能力发现和参数校验模型要触发Skill之前注册中心先做一轮参数合法性检查。第三个是规则引擎内置了电源设计领域的设计规则库。这些规则不是存在模型里的而是以可配置的形式落地比如“陶瓷电容直流偏压降额不低于50%”“MOSFET电压应力不超过额定值的80%”“PCB走线载流能力按1A/1mm算”等等。规则引擎在任务各阶段都会被调用负责硬约束检查。第四个是验证节点在流水线的每个Gate处运行负责核对证据链、复算关键数值、检查输出格式验证不通过就打回。第五个是记忆存储按项目维度保存对话记录、设计决策、参数版本方便后续项目复用和追溯。这五个模块里我认为最容易忽视的是记忆存储。电源设计项目通常持续数周中间会反复修改需求如果Agent没有项目级记忆用户每次都要重新描述一遍约束条件体验很差。我用的做法是把项目关键约束输入电压范围、目标效率、安规等级、成本上限写入持久化记忆每次新会话自动加载相当于给Agent建立了一份“项目档案”。3.2 Skill是防幻觉的基本单元四段式结构解析Skill是整个架构的核心单元我们目前沉淀了十几个每个都遵循四段式结构。第一段是意图描述用自然语言说明这个Skill什么时候触发、不处理什么问题这直接决定了模型路由的准确率。第二段是参数Schema用结构化声明定义输入输出的字段、类型、必填项和约束范围缺了必填参数就不放行。第三段是执行逻辑也就是确定性代码负责实际计算和判断。这里有个原则计算逻辑里不要写任何模糊规则所有分支都要有明确边界。第四段是输出模板定义了证据链格式包括引用依据、代入数值、中间量、置信度和限制说明。四个部分缺一不可任何一个缺失都可能给幻觉留下空间。我列一下当前主要Skill的功能和输入输出方便参考Skill名称功能典型输入典型输出topo_selector拓扑选型Buck/Boost/LDO等Vin范围、Vout、Io、效率、成本优先级推荐拓扑排名及理由buck_designerBuck主回路参数计算Vin/Vout/Io/fsw/纹波要求L、C、关键器件应力thermal_calc热设计计算功率损耗、热阻参数结温、温升、散热建议derating_check降额设计检查器件类型、应力数值降额系数及通过/警告component_matcher从器件库中检索匹配器件类型、额定值、封装、成本候选料号及替代料bom_genBOM生成设计上下文及物料清单结构化BOM、料号、备注signoff_report设计评审报告生成整个会话上下文可交付评审报告3.3 工作流编排一条从需求到BOM的六阶段流水线从实际工程交付角度看我们需要的不是一个“聊天机器人”而是一条能产出设计交付物的流水线。我把它定义为六个阶段每个阶段之间都有校验Gate。第一阶段是需求解析与约束提取Agent从用户的自然语言描述中提取结构化设计约束比如输入电压范围、输出电压电流、效率目标、尺寸限制、成本预算、安规认证要求。提取完成后规则引擎做一轮完整性检查缺失的约束条件自动生成反问清单。第二阶段是拓扑选型调用topo_selector根据约束矩阵推荐拓扑并说明理由。第三阶段是参数计算与应力分析调用buck_designer等计算Skill输出主回路参数和器件应力分布。第四阶段是器件选型从内部器件库中检索可用的器件型号按优先级排序并补充替代料。第五阶段是设计规则检查也就是DRC重点做降额检查、安全间距检查、热设计复核。第六阶段是BOM与评审报告输出生成结构化BOM和设计评审报告进入人工复核队列。六个阶段全部走完才算一次完整的Agent任务闭环。这套流水线最核心的价值在于把错误隔离在源头。每个Gate都会复核上游传下来的关键参数一旦发现某个阶段算出的电感值异常就会回退到参数计算阶段重新执行而不是带着错误继续往下游走。Harness对流程节点的状态管理做得比较清晰节点上下文可以独立回溯配合它的代码回退能力调试时省了不少事。4. 实操搭建全流程从安装到Skill开发到内网部署4.1 安装Deepseek Harness与环境初始化搭建第一步当然是安装。我当时的做法是在一台Linux服务器上做验证Python环境用venv隔离。git clone https://github.com/your-harness-repo/harness.git cd harness python -m venv .venv source .venv/bin/activate pip install -r requirements.txt装完之后要配置模型服务地址。我们生产环境用的是内网自建的模型推理服务所以在Harness的配置文件里指定本地地址即可model: provider: local base_url: http://127.0.0.1:8000/v1 model_name: local-power-design-model这里给个建议首次跑通时先不要接复杂的模型用一个基础配置把Harness起起来再运行一个最简单的Skill验证全链路。我们当时跳过这个步骤直接上复杂场景结果排查了两天才发现是模型服务超时配置问题白白浪费时间。初始化完成后我建议先在Harness自带的示例Skill上跑一遍确认工具调用、上下文传递、输出回填都正常再开始开发自己的Skill。4.2 开发一个降额检查Skill的完整示例我以derating_check这个Skill为例演示完整的开发过程。首先创建目录结构skills/ └── derating_check/ ├── skill.yaml ├── scripts/ │ └── derating.py └── prompts/ └── trigger.mdskill.yaml是这个Skill的元数据定义文件包含触发条件、参数Schema和执行脚本配置。一个简化版本长这样name: derating_check description: 对关键器件进行降额设计检查电压、电流、功率、结温 triggers: - type: intent keywords: [降额, derating, 应力, stress check] inputs: - name: component_type type: enum values: [MOSFET, Diode, Capacitor, Inductor, IC] required: true - name: stress_values type: object required: true properties: voltage_stress: { type: number, unit: V } current_stress: { type: number, unit: A } power_stress: { type: number, unit: W } junction_temp: { type: number, unit: celsius } outputs: - evidence_chain: required - status: enum [pass, warning, review] execution: script: scripts/derating.py sandbox: true然后就是核心的derating.py。降额检查的逻辑其实不复杂核心是根据器件类型读取降额系数标准把实际应力值和额定值做比较。以MOSFET电压应力为例我用的判断逻辑是def check_mosfet_voltage(stress_v, rated_v, derating_ratio0.8): # 电压降额系数一般按0.8军工或高可靠性场景取0.6-0.7 ratio stress_v / rated_v status pass if ratio derating_ratio else warning return { stress_ratio: round(ratio, 3), derating_limit: derating_ratio, status: status, message: f电压应力{stress_v}V / 额定{rated_v}V {ratio:.1%} f超过降额上限{derating_ratio:.0%} if status warning else f电压应力满足降额要求{derating_ratio:.0%} }这类确定性代码的好处是结果稳定、可审计而且方便后续维护降额系数。当降额系数标准更新时只改配置文件不需要动模型和流程。4.3 防幻觉规则在Harness里的具体配置Skill开发完了接下来要在Harness里把防幻觉策略固化成一揽子的配置规则。我目前用的核心配置项如下anti_hallucination: force_tool_call: true # 强制工具调用专业问题禁止自由回答 forbid_free_answer: true # 命中专业关键词时不走通用问答分支 numeric_calc: code_executor_only # 数值计算只能由代码执行器完成 evidence_chain: required # 所有结论必须携带证据链 confidence_threshold: 0.8 # 置信度低于0.8一律进入人工复核 unknown_policy: return_for_review # 知识库未覆盖的问题返回待复核状态这里重点说两个配置的经验。第一个是confidence_threshold这个值不能拍脑袋拍出来。我们是用一批历史问答数据做回归测试把所有结论的置信度得分画出来找出“错误结论”和“正确结论”的分界点再留出余量。最终定在0.8实际拦截效果不错误伤率大概在5%左右。第二个是forbid_free_answer这个开关一开始我犹豫要不要开因为担心用户体验太僵硬后来实践证明在专业域内关掉自由回答反而让用户更信任Agent因为你知道它不会信口开河最多说“这题我不会交给人工”。4.4 内网离线部署的架构取舍与资源规划内网部署是硬件设计企业特别关心的点。我的生产架构是三层模型推理层、Harness应用层、数据存储层全部跑在纯内网环境。模型推理层负责加载和运行模型服务Harness应用层跑编排器和Skill执行环境数据存储层放向量知识库、器件库和项目记忆。资源规划上我们根据实际负载做的估算思路是单次Agent任务平均消耗的tokens大概在4000~8000之间含工具调用和上下文假设每个工作日有30个设计任务、每个任务平均进行3轮交互那么一天的推理请求量大约在90次左右单张GPU足够支撑。并发峰值场景下Harness应用层可以多实例横向扩展模型推理层则需要考虑队列和超时我给模型推理服务配置了并发上限和请求超时避免单个慢请求拖死整个Agent。还有一点要特别注意内网部署不等于没有安全要求。Harness执行Skill时需要读写文件但Skill代码不能随意访问宿主机文件系统必须跑在沙箱环境里只开放白名单目录。我们曾经在Windows测试环境遇到过Skill读取文件报权限错误报错信息是setnamedsecurityinfow failed其实就是沙箱账户没有目标目录的ACL权限解决办法是给Harness的运行账户单独授予该目录的读取权限后来我们干脆把生产环境全部切到Linux这类问题基本绝迹。5. 实测效果与典型幻觉案例排查实录5.1 三个月的实测数据准确率、拦截率、人工复核率系统上线内测三个月我积累了一些有价值的量化数据。先说结论在防幻觉机制加上之前裸调模型处理电源设计问题的专业准确率大约只有61%加上三重防线后提升到94%左右。这个提升不是靠换了更强的模型而是靠架构约束。参考下表指标裸调模型加防幻觉架构后拓扑选型准确率61%94%参数计算错误率32%0%全走代码执行器幻觉类错误被拦截率无机制约90%人工复核率无机制错误直接输出约15%进入复核参数计算错误率归零的原因很简单我们根本没有给模型机会去算数。所有数值计算都走代码执行器模型只做模式识别和参数传递这个功能的防幻觉效果是最确定的。人工复核率15%这个数字看起来不低但都是“低置信度涉及安全裕量”的保守判断属于我们主动设计的结果——宁可多复核不冒险直接交付。5.2 幻觉案例复盘一规格书参数张冠李戴第一个典型案例是规格书参数张冠李戴。用户在一个多路输出电源方案里问“Q2这颗MOSFET的导通损耗是多少”模型给出的回答里用了“IRF540的Rdson为77mΩ”这个数据但项目实际用的是一颗国产替代料Rdson是95mΩ。如果不仔细核对物料号这条错误就会流入损耗估算和散热设计。排查后发现根因在RAG阶段知识库向量检索把两份不同厂家、不同型号的规格书chunk混在一起拼接了模型把A器件的参数安到了B器件上。这个问题的本质不是模型幻觉而是检索增强的精度不够。修复方法是把知识库的chunk单元从“整本规格书”改成“按品牌型号参数类别分组”每个器件规格书作为一个独立的检索最小单元不允许跨文档拼接回答。修复后这类“张冠李戴”明显下降。5.3 幻觉案例复盘二“无中生有”的设计公式第二个案例更典型是模型自己编公式。内测时有人问“怎么估算反激变压器的漏感”模型居然给出了一个“Ls (1-k) * Lp”的表述并进一步推导了一大段。这个公式本身不算错但实际工程估算漏感常用的是“按主电感量的1%~3%估算”或者“结合耦合系数k计算”模型把不同来源的说法杂糅成了一个不严谨的版本。这个问题暴露出第二重防线的一个盲区当问题涉及“估算规则”而不是“确定公式”时代码执行器没有对应的计算原语。我们的处理方式是给知识库增加覆盖检查如果问题在知识库里没有对应的Skill或明确的规范条目直接返回“知识库未覆盖该问题”而不是让模型自由发挥一套“看起来专业”的方法论。同时在Skill列表里补了一个transformer_leakage估算Skill把漏感估算的多种工程方法都做成确定性代码并注明适用条件。5.4 幻觉案例复盘三单位换算错位第三个案例是最让人哭笑不得的模型在描述电流应力时把500mA写成了0.5A听着好像没问题但它在描述另一个参数时把3.3V写成了3300mV后又手动“换算”回3.3V过程绕了一大圈最终由于前两重防线都没拦住因为数值已被模型“包装”为叙述性文字直接出现在给用户的总结里硬是让一个新手工程师差点把电容耐压选错。这个案例让我意识到单位换算必须代码化。模型可以描述物理意义但任何数值只要进入输出文本都必须经过单位原语转换。我在Harness的证据链模板里加了一条强制规则所有结论中的数值必须来自Skill的执行结果不允许模型二次“复述”或“换算”。这一步把模型的文本生成和数值真实性彻底隔离了。5.5 并发与资源开销的实测表现资源开销方面我也做了记录。Agent编排层做了无状态化改造后应用实例可以轻松扛住20个并发会话瓶颈在模型推理层的显存和算力。我们用的是单卡部署量化后的模型并发推理时单次响应时间大概在1.5秒到3秒之间。单个Skill脚本沙箱化的内存开销控制在200MB以内主要是Python解释器和常用库的固定开销。最让我放心的是Harness的代码回退能力。有一次我更新了thermal_calc Skill里的散热器选型算法新算法在某个边界条件上算出来的结果偏激进上线半天就被复核工程师发现了。我们直接回退到上一个版本整个流程在5分钟内完成没有影响正在进行的其他设计任务。这个“后悔药”机制在Agent工程化里非常重要尤其是有状态、有记忆的长周期项目。6. 常见问题速查表与设计经验补充6.1 部署和运行常见问题速查表把我这段时间遇到的高频问题整理成一份速查表对正在搭建类似架构的人应该有用问题可能原因解决办法Skill在Windows下读取文件报权限错误沙箱账户没有目录ACL权限给运行账户授予目录读取权限或改用Linux部署模型总是补全缺失参数Skill参数Schema必填项未配置严格在Harness的Skill协议中声明必填项并开启强制反问检索时跨文档拼接导致参数混淆RAG库chunk粒度过大按“品牌型号参数类别”分组独立检索单元通用问答分支输出未经验证的知识forbid_free_answer未开启专业域内关闭自由问答或额外挂证据链审查高并发时模型推理超时无队列与超时管理为模型服务配置队列上限和超时阈值超过则进入重试Skill输出与模型叙述不一致证据链规则未强制校验开启evidence_chain并把数值字段强制绑定为Skill输出长周期项目上下文丢失记忆存储未按项目隔离按项目维度保存约束和决策记录新会话自动加载6.2 三条关于防幻觉Agent设计的硬经验第一条硬经验是防幻觉不能只靠提示词。提示词写得再好也只是增加模型瞎编的心理门槛架构层面的强制约束才是真正可靠的。评判一个防幻觉设计是否合格标准很简单把模型换成另一个同级别的模型系统表现是否依然稳定。如果答案是不稳定说明你的防线没有真正建立起来。第二条硬经验是Skill粒度要控制在“一个Skill只干一件事”。我早期写过一个“全能设计助手”Skill里面又做选型又算参数又出BOM结果模型经常触发混乱一个任务里带出一堆无关参数。后来把Skill拆细每个Skill聚焦一个职责模型路由准确率大幅提升。设计Skill时如果发现意图描述里出现“并且”这类词基本说明粒度太粗了。第三条硬经验是测试集里要包含“钓鱼问题”。防幻觉系统的测试不能只看正常问题必须专门设计一批容易诱发幻觉的问题来验证拦截能力。比如故意问一个不存在的器件型号、一个库中没有的规范条款、一个超出Skill覆盖范围的估算场景。只有这类“钓鱼问题”被正确拒绝或转人工你才敢说防线是闭环的。最后再分享一个小技巧在Harness里给每个Skill配置输出模板时把“置信度”作为一个结构化字段而不是让模型自己写一段话这样验证节点可以自动解析置信度并与阈值比对实现真正的自动化门禁而不是靠人眼去读模型生成的文字。这一点帮我省了不少复核工作量也是我从几次返工里学到的教训。按照这个架构跑下来我最大的体会是Agent在专业垂直领域能不能用取决于你敢不敢把“不可控的生成”约束在“可控的框架”里。模型依然会说错话但只要我们让它的每句话都有出处、每个数字都有代码背书它就能从“靠谱的聊天对象”变成一个真正能参与设计的工具。en