1. 項目緣起與整體設計1.1 為什么會有這個項目做硬件設計的朋友應該都有體會電源設計這件事兒看著是“選個芯片、搭個外圍電路、算幾個電阻電容”實際上每一環(huán)都是細節(jié)。拓撲怎么選、環(huán)路怎么補償、MOS管驅動電流夠不夠、電感飽和電流留多少裕量、熱耗怎么算任何一個點拍腦袋后面打板回來都是改版重來的成本。我一直在琢磨怎么把大模型真正用進硬件設計流程里。市面上通用聊天機器人問個概念還行真讓它幫我算一個buck電路的電感值、選一個滿足紋波要求的輸入電容或者檢查一下原理圖里反饋電阻的取值合不合理它要么答得模模糊糊要么一本正經地給出一個完全沒法用的結果。大模型在這種場景下暴露出的最大問題就兩個字幻覺。后來Deepseek出來之后我花了挺長時間評估它做硬件設計底座的可能性。推理能力確實能打尤其在數(shù)學計算和邏輯推理這類任務上和那些需要“硬湊答案”的模型完全不是一個畫風。但光有底座不夠要在真實的電源設計流程里用起來還缺一層能把模型、工具、知識庫、校驗邏輯串起來的骨架。這個骨架就是標題里的Harness。這套架構搞了大半年斷斷續(xù)續(xù)迭代了好幾版。從最初的“一問一答”腳本做到現(xiàn)在的多agent協(xié)作、帶完整防幻覺機制的智能體系統(tǒng)中間踩坑無數(shù)。這篇就把整個架構從頭拆一遍把那些真正有效的設計決策和那些讓我返工的坑都整理出來。1.2 Harness在架構里的定位先說說Harness這個詞。很多人第一次聽到會以為是個具體的軟件其實它在AI工程領域更像是一種“裝配層”的概念。模型是發(fā)動機Harness是底盤和傳動系統(tǒng)。它負責把模型、工具調用、外部數(shù)據、執(zhí)行流程、結果校驗這些部件裝配到一起形成一個能穩(wěn)定干活兒的整體。我這套架構里Harness承擔了幾個核心職責第一編排多agent的協(xié)作流程讓規(guī)劃、計算、校驗各司其職第二管理工具調用把仿真軟件、計算腳本、數(shù)據庫查詢這些外部能力封裝成agent可以調用的接口第三落地防幻覺機制在模型輸出和最終答案之間加一道硬約束。為什么不用那種“一個prompt走天下”的簡單方式因為電源設計這個場景對精度的要求太苛刻了。你問“這個buck電路的電感取多大”一個通用模型可能直接給你一個公式、代幾個數(shù)、出個結果看著挺像那么回事兒但如果你把輸入電壓范圍、開關頻率、紋波要求這些邊界條件稍微改一改它的答案可能就徹底不對了。這不是模型笨是這種開放式問答的結構本身就不適合承載高精度的工程設計任務。所以我的設計原則很簡單模型負責“理解”和“規(guī)劃”工具負責“計算”和“驗證”知識庫負責“約束”和“參考”最后再加一道獨立的校驗環(huán)節(jié)。讓模型做它擅長的事但絕不讓它成為唯一的信息來源。1.3 面向的讀者和適用場景這篇分享適合兩類人。一類是做AI應用工程、正在研究怎么把大模型落地到專業(yè)領域的開發(fā)者你可以看看在硬件設計這種對精度要求極高的行業(yè)里防幻覺體系具體是怎么落地的。另一類是硬件工程師尤其是做電源設計的你可以看看agent能幫你處理哪些重復性高、規(guī)則明確的工作以及哪些環(huán)節(jié)目前仍然需要人來兜底。這套架構不挑具體領域。防幻覺的思路、Harness的編排方式、工具增強的路徑換到結構設計、熱設計、成本估算、PCB布局審查這些場景骨架完全可以直接復用只是換一套垂直領域的工具和知識庫而已。2. 防幻覺體系把錯誤扼殺在流程里2.1 幻覺從哪來先認清敵人模型在生成token的時候本質上是在做概率采樣——根據前文信息預測下一個最可能的token。它沒有一個“從外部數(shù)據庫查證”的自覺。這就導致一個結果當訓練數(shù)據里沒有覆蓋某個具體場景時它會傾向于編造一個看起來合理的答案來填補空白。在通用問答場景里這種編造最多是誤導人。但在電源設計場景里一個編造的環(huán)路增益數(shù)據、一個隨便算出來的熱阻值、一套不匹配的器件參數(shù)組合直接就能毀掉一次設計。更麻煩的是硬件設計里的錯誤往往不會當場暴露——原理圖審查時看不出來等到板子打回來測試才發(fā)現(xiàn)效率不對、紋波超標、甚至芯片燒了。所以要建立防幻覺體系第一步就是改變提問方式。你不能讓模型自由發(fā)揮寫答案要把它變成一個必須在約束條件下完成任務的執(zhí)行者。每一道輸出都要能追溯到計算過程每一個數(shù)據都要有來源。2.2 四層防幻覺機制的設計我在架構里落地了四層防幻覺機制層層遞進互相兜底。第一層是結構化約束層。所有發(fā)給模型的任務都不是開放式問答而是填入式的任務單。比如讓模型算電感prompt里明確寫清楚輸入參數(shù)表、輸出字段表、計算步驟要求模型只需要按照指定流程執(zhí)行。這一層解決的是“自由發(fā)揮”的問題。第二層是計算工具層。所有涉及數(shù)值計算的任務模型自己不直接算而是生成計算參數(shù)、調用封裝好的數(shù)學工具去算。比如環(huán)路穩(wěn)定性分析我封裝了一個專門的計算模塊模型只需要把開環(huán)增益、相位裕度、穿越頻率這些參數(shù)提取出來傳給工具工具返回結果模型再基于結果生成分析報告。這一層解決的是“數(shù)值精度”的問題。第三層是知識約束層。我在知識庫里維護了一份電源設計規(guī)則庫包含降額設計規(guī)則、器件選型邊界、拓撲適用場景、典型電路參考。模型在生成方案時必須經過規(guī)則匹配違反規(guī)則的方案直接打回。這一層解決的是“領域常識”的問題。第四層是交叉驗證層。關鍵輸出在進入最終報告之前會經過一個獨立的驗證agent復核。這個驗證agent不知道規(guī)劃agent的結論它只拿到原始需求和計算過程重新走一遍推理比對兩個結果是否一致。這一層解決的是“系統(tǒng)性幻覺”的問題——有時候模型的錯誤不是單點的而是一整套聽起來自洽但完全錯誤的邏輯鏈條單靠規(guī)則很難攔住雙模型交叉驗證是目前最有效的手段。2.3 結構化輸出的強制約束這里展開說說結構化約束層的具體做法。我的prompt模板里每個設計任務都定義了嚴格的輸出schema用JSON格式約束字段名和字段類型。比如電感選型任務的輸出必須包含計算依據選用的公式、輸入參數(shù)值、計算結果、器件推薦型號、降額校驗結果。模型只能在這個schema的框架內填空不能自由發(fā)揮。這個設計不是為了好看而是為了把模型的輸出變成可解析、可校驗的數(shù)據結構。后續(xù)的規(guī)則引擎、工具調用、交叉驗證全部基于這個數(shù)據結構操作。我試過不約束schema的版本讓模型用自然語言輸出計算結果。結果是十個答案里有八個格式都不一樣有的寫“電感值建議取6.8uH”有的寫“L6.8μH”有的寫“考慮到紋波要求電感選擇6.8微亨”。解析邏輯根本沒法寫規(guī)則引擎也沒法自動化。改成結構化輸出之后整個流程才順暢起來。2.4 防幻覺硬規(guī)則是模型的底線最后還要強調一點防幻覺機制不是讓模型變得“不撒謊”而是讓模型“沒有撒謊的空間”。在四層機制之下模型即使產生了幻覺也會在某個環(huán)節(jié)被攔截。要么參數(shù)不合法被規(guī)則引擎打回要么數(shù)值異常被工具層發(fā)現(xiàn)要么與驗證agent結論不一致被標記復核。這意味著在架構設計上你要把“模型直接輸出最終答案”的通路徹底堵死。用戶看到的每一個數(shù)據一定是經過工具計算、經過知識校驗、經過交叉確認之后的產物。這條原則我建議所有做專業(yè)領域agent的人牢牢記住模型輸出是半成品不是成品。3. 工具層設計模型的大腦工具的雙手3.1 為什么必須引入外部計算工具很多人覺得大模型本身就具備數(shù)學能力Deepseek的推理能力又這么強直接讓它算不行嗎實測下來讓模型算一個簡單的分壓電阻值輸入10V目標3.3V分壓電流0.5mA它給出的結果可能是對的但你會發(fā)現(xiàn)一個問題它每次給出的計算過程版本都不一樣。有時候是精確代公式有時候是近似估算有時候直接跳過中間過程給出一個“憑經驗”的結果。對于工程設計來說過程不可復現(xiàn)就等于錯誤。你今天讓它算電感它用了一種方法明天同樣的輸入可能換了另一種方法——也許結果碰巧一樣但工程上沒人敢依賴這種隨機正確性。所以工具層的設計原則是把計算從模型的概率世界里剝離出來放到確定性的工具世界里。模型負責理解需求、提取參數(shù)、選擇計算路徑實際的數(shù)值運算全部交給封裝好的工具模塊。3.2 工具封裝的三層結構我的工具層分成三層。最底層是基礎計算庫就是純函數(shù)式的計算模塊。電感紋波計算、環(huán)路增益計算、熱阻計算、降額校驗、PCB走線載流計算這些都是明確的公式和算法輸入參數(shù)給到位輸出就是確定性的。中間層是數(shù)據接口把器件數(shù)據庫、規(guī)格書解析結果、參考設計庫這些數(shù)據源封裝成查詢接口。agent需要查某個MOS管的導通電阻、某個電容的ESR、某個電感的飽和電流走的是數(shù)據接口而不是靠模型“回憶”。最上層是仿真封裝封裝了對外部仿真軟件的調用。比如需要做環(huán)路穩(wěn)定性仿真agent可以生成仿真輸入文件、調用仿真程序、解析仿真結果。這一層目前只做自動化調用仿真結果的解讀仍然需要經過校驗環(huán)節(jié)。這個分層設計的好處是每一層都可以獨立測試、獨立替換。基礎計算庫可以寫單元測試保證正確性數(shù)據接口可以單獨驗證數(shù)據源的準確性仿真封裝出了問題不會影響上層邏輯。3.3 模型和工具的協(xié)作模式先規(guī)劃后執(zhí)行在我的Harness架構里模型和工具的協(xié)作是典型的“先規(guī)劃后執(zhí)行”模式。規(guī)劃agent收到用戶需求后先拆解任務、確定計算路徑、識別需要的工具和數(shù)據生成一份執(zhí)行計劃。然后執(zhí)行器根據這個計劃逐步調用工具每一步拿到確定性結果之后再交給生成agent匯總。這里有個關鍵細節(jié)模型在規(guī)劃階段也要輸出結構化數(shù)據不能只輸出自然語言描述。因為執(zhí)行器要自動解析計劃并執(zhí)行所以計劃本身必須是機器可讀的。我定義了一個計劃schema包含任務列表、每個任務依賴的工具、輸入參數(shù)映射、輸出變量名。舉個例子一個完整的buck電路參數(shù)計算任務規(guī)劃agent生成的計劃可能是這樣第一步查數(shù)據接口獲取器件的開關頻率范圍第二步調用基礎計算庫的電感計算公式生成候選電感值列表第三步對每個候選值做紋波校驗第四步調用熱阻計算模塊檢查電感溫升最后匯總結果生成設計報告。每一個步驟都是確定性的模型不參與數(shù)值運算只負責生成計劃和解釋結果。這套模式下模型的幻覺影響范圍被壓縮到了“計劃選擇”這個層面而計劃層面的錯誤可以在執(zhí)行階段被參數(shù)校驗環(huán)節(jié)發(fā)現(xiàn)。3.4 工具調用錯誤的兜底機制工具調用也不是絕對安全的至少有三類問題我踩過。第一類是參數(shù)傳遞錯誤模型提取的輸入參數(shù)和用戶需求不一致比如把輸入電壓范圍的上限當成典型值傳給計算工具算出來的結果自然就錯了。第二類是公式選型錯誤比如算反激變壓器時用了正激的公式結果完全不可用。第三類是數(shù)據查詢無結果模型查不到匹配的器件時可能強行推薦一個參數(shù)不達標的型號。針對這三類問題我在架構里加了三道保險。參數(shù)傳遞錯誤靠的是規(guī)則校驗——工具接口定義里寫明每個參數(shù)的物理范圍比如輸入電壓必須是正數(shù)、開關頻率必須在100kHz到2MHz等工業(yè)合理范圍內超出范圍直接報錯打回。公式選型錯誤靠的是任務類型標記——每個任務在規(guī)劃階段就被打上類型標簽執(zhí)行器根據類型選擇對應的公式庫不允許模型自由指定公式。數(shù)據查詢無結果的處理是讓模型必須明確說明查無結果并建議替代方案不允許編造一個不存在的器件型號。4. 電源硬件設計的垂直能力注入4.1 知識庫不是資料庫是約束庫做垂直領域agent大家第一步都會想到搭知識庫。但怎么搭、放什么內容差別很大。很多人把規(guī)格書、應用筆記、參考設計一股腦塞進去讓模型自己去檢索結果效果很差——檢索出來的內容可能不相關也可能相關但模型不知道怎么用。我的做法是把知識庫定位成“約束庫”而不是“資料庫”。里面放的不是公開文檔原文而是經過提煉的規(guī)則化知識。每一條知識都是一個約束條件比如“輸入電容的紋波電流額定值必須大于計算出的最大紋波電流”、“電感的飽和電流必須大于最大峰值電流的1.2倍”、“反饋電阻的精度等級選擇取決于輸出電壓精度要求”。這樣做是出于一個考慮規(guī)則才能被機器自動校驗資料不行。你讓模型讀一篇50頁的電源設計應用筆記它理解到什么程度你完全不可控。但你把里面的關鍵約束提煉成一條條規(guī)則模型在生成方案時只需要逐條比對這個過程是可檢查、可審計的。4.2 電源設計核心任務的agent分工架構里我設計了四個專職agent每個負責一類任務避免一個agent什么都干、什么都干不精。任務理解agent負責接收用戶需求提取關鍵參數(shù)把自然語言描述轉化成結構化的設計輸入。用戶說“做一個12V轉3.3V的buck輸出電流3A紋波小于50mV”它需要補全隱含的邊界條件——輸入電壓范圍、開關頻率選多少、工作溫度范圍、成本敏感還是效率敏感這些不確定項會生成澄清問題回問用戶。方案規(guī)劃agent負責設計路徑決策。輸入電壓范圍決定了拓撲結構輸出功率決定了器件選型方向紋波要求決定了濾波器的設計優(yōu)先級。它會生成一份方案大綱包括拓撲選擇理由、關鍵器件選型邏輯、需要計算的項目列表、需要仿真的項目列表。計算執(zhí)行agent負責調用工具層完成所有數(shù)值計算。電感選型計算、功率管損耗估算、環(huán)路補償參數(shù)計算、熱設計校驗每一項計算都會記錄輸入參數(shù)、計算公式、計算過程和結果版本保證全程可追溯。驗證agent負責在最終輸出之前把所有計算結果拉通檢查。它檢查計算過程是否用了正確的公式、參數(shù)是否在合理范圍內、器件選型是否滿足降額要求、多個計算項目之間的數(shù)據是否能互相印證。這個驗證agent的核心價值在于獨立性——它不參與任何計算只負責挑錯。4.3 從需求到方案的完整任務拆解用一個實際例子說明整個agent協(xié)作流程。假設用戶提交需求“設計一個24V轉5V/2A的buck電源”。任務理解agent先做需求解析提取的關鍵參數(shù)是輸入電壓范圍假設用戶說24V輸入需要進一步確認是否允許波動到20V~28V、輸出電壓5V、輸出電流2A。它會生成澄清問題輸入電壓波動范圍是多少紋波要求多少工作環(huán)境溫度范圍有沒有效率要求用戶補充之后方案規(guī)劃agent生成設計方案拓撲選同步buck效率優(yōu)先開關頻率選300kHz在效率、器件體積、環(huán)路設計難度之間取平衡輸入電容和輸出電容拓撲選型電感感值初步根據典型紋波率30%估算控制芯片候選型號列出來。計算執(zhí)行agent執(zhí)行具體計算根據輸入輸出參數(shù)計算占空比范圍20V輸入時占空比0.2528V輸入時0.179根據紋波電流要求計算最小電感值根據輸出紋波要求計算輸出電容容值和ESR上限根據功率計算功率管電流應力并初選MOS管。驗證agent做交叉檢查確認所有計算使用了正確的輸入參數(shù)確認電感飽和電流大于最大峰值電流的1.2倍以上確認輸出電容的ESR滿足紋波要求確認所有器件選型的電壓、電流、功率降額在合理范圍內生成最終的設計報告?？梢钥吹侥Ｐ驮谡麄€流程里只承擔“理解”和“決策”類工作——理解需求、選擇拓撲、規(guī)劃路徑、解釋結果。所有數(shù)值類工作全部由工具完成所有正確性類工作全部由規(guī)則和驗證環(huán)節(jié)完成。4.4 垂直規(guī)則庫的建設方法與實踐規(guī)則庫的建設是這個系統(tǒng)比較費功夫的部分。我的做法是把資料分成幾類第一類來自公開的教材和應用筆記比如開關電源設計相關的經典書籍、芯片廠商的應用筆記第二類來自在多次設計、改版中沉淀的經驗教訓這部分是最有價值的第三類來自行業(yè)標準和設計規(guī)范。每條規(guī)則入庫時都要明確三件事適用場景、判定條件、處置動作。比如“電感飽和電流裕量不足”這條規(guī)則適用場景是電感選型判定條件是“最大峰值電流 × 1.2 電感飽和電流”處置動作是“標記警告并建議重新選型”。規(guī)則入庫之后還要定期清理——有些規(guī)則在新器件、新拓撲面前已經不適用了留在庫里只會在校驗時誤傷合理的方案。5. 架構部署實踐與運行觀測5.1 硬件配置與模型部署架構部署首要考慮的是模型在哪里跑。硬件設計這個場景對數(shù)據安全要求比較高設計數(shù)據往往不太可能直接傳到云端API所以核心的推理任務我優(yōu)先考慮本地部署。實測下來Deepseek系列模型在消費級工作站上做推理關鍵要卡準顯存和內存的平衡。我這邊用了兩張顯卡并行加載模型結合量化方案把顯存占用壓了下來同時保住了推理質量。幾個G的模型文件放顯存上下文相關的KV cache放內存靠框架的調度能力把兩者的帶寬用起來跑50~100輪的agent協(xié)作推理流程速度和精度都還能接受。具體到部署方式我建議分三層模型服務層負責加載模型、提供推理接口、agent編排層跑Harness框架、管理多agent協(xié)作、工具服務層跑計算庫、數(shù)據接口、仿真封裝。這三層可以部署在同一臺機器上也可以拆開分布式部署看任務并發(fā)量來定。5.2 單機部署/Docker化與內網部署為了方便遷移和復現(xiàn)我把整個系統(tǒng)做了Docker化。鏡像里打包了模型推理服務、Harness運行環(huán)境、工具庫依賴、規(guī)則庫文件。推到內網私有倉庫之后在任何一臺部署了Docker的機器上都能直接啟動。內網部署有幾個注意點第一模型文件本身比較大要先傳到內網存儲再掛載進容器不要在鏡像構建時打進去否則每次更新鏡像都要重新傳輸。第二工具層如果依賴外部軟件比如仿真程序要做好路徑映射和權限配置。第三內網環(huán)境往往沒有外網訪問能力所有依賴包要在構建鏡像時提前拉好。我的部署腳本里做了兩個版本開發(fā)版用docker-compose一鍵起全套服務生產版用systemd管理容器生命周期加上自動重啟。這套部署方式在后續(xù)遷移和擴展的時候會省很多事。5.3 觀測體系agent的可觀測性設計agent系統(tǒng)比普通應用難觀測的地方在于它不是單線程執(zhí)行的而是多agent并行協(xié)作每一步都有模型推理和工具調用出錯的位置可能藏在任何一個環(huán)節(jié)。我做的觀測體系包含三個維度。第一個維度是流程追蹤每個用戶請求生成一個trace_id貫穿所有agent的調用鏈每一步記錄了執(zhí)行時間、輸入輸出摘要、調用的工具和參數(shù)。第二個維度是關鍵指標包括工具調用成功率、規(guī)則校驗被攔截的次數(shù)、驗證agent發(fā)現(xiàn)的差異數(shù)、平均響應時間、token消耗量。第三個維度是結構化日志所有模型輸出和工具返回都以結構化格式記錄方便事后回溯和分析。這套觀測體系的價值在排查問題時體現(xiàn)得最明顯。有次用戶反饋某個計算結果“看著不太對”我直接按trace_id拉起全鏈路日志看到的是計算執(zhí)行agent生成公式時選了正確的公式但傳入參數(shù)時把輸入電壓范圍的上限和下限搞反了這個錯誤被驗證agent攔截并更正了。如果沒有觀測體系這類問題根本定位不到。5.4 性能優(yōu)化與并發(fā)處理的取舍如果只是單用戶使用性能壓力并不大。但如果你想把agent能力開放給團隊使用就要考慮并發(fā)了。我實測發(fā)現(xiàn)兩個性能瓶頸第一個是模型推理的并發(fā)能力多請求同時到達時推理服務會排隊影響響應時間第二個是工具層的計算密集任務比如批量仿真參數(shù)掃描會占用大量CPU。在并發(fā)優(yōu)化上我的取舍是優(yōu)先保交互體驗把用戶無感知的耗時任務放到異步隊列里處理。具體做法是任務理解、方案規(guī)劃這類需要用戶等待的環(huán)節(jié)走同步推理計算執(zhí)行環(huán)節(jié)如果任務量大拆成子任務投遞到異步隊列完成后推送通知。這樣用戶體驗更平滑系統(tǒng)的整體吞吐量也上去了。6. 常見問題與排查技巧實錄6.1 大模型計算的精度問題這是我最先遇到、也最需要解決的問題。測試階段用Deepseek直算一個buck電感值輸入同樣的參數(shù)跑十次能算出七八個不同的結果。雖然大多數(shù)在正確值附近但對工程設計來說這完全不可接受。解決方案就是前面說的工具層模型不再直接算數(shù)而是生成計算參數(shù)、調用確定性計算函數(shù)。這一步改完之后同樣的輸入跑一百次結果完全一致精度由計算函數(shù)本身保證不再受模型概率性影響。如果你的應用場景沒法完全剝離模型計算那至少要在prompt里強制要求“分步計算每步展示結果最終結果保留兩位小數(shù)”并且加交叉驗證環(huán)節(jié)。但說實話對于工程精度要求高的場景工具化計算是唯一可靠的路。6.2 Agent規(guī)劃路徑出錯的處理有次測試反激電源設計任務方案規(guī)劃agent給出的拓撲選擇建議是正激。原因是用戶需求里有“多路輸出”這個特征模型把它關聯(lián)到了正激拓撲的多路輸出優(yōu)勢忽略了功率等級、輸入電壓范圍和成本約束這些更關鍵的決策因素。這類問題的本質是模型在做決策時容易被單一特征誤導缺乏全局權衡能力。我的處理方式是給規(guī)劃agent加了一層規(guī)則前置過濾在模型接收需求之前先由規(guī)則引擎根據硬約束條件篩掉一部分不可能的方案。比如功率超過200W直接排除反激拓撲輸入電壓范圍超過一定跨度直接排除正激拓撲這些硬規(guī)則在模型之前就把路堵死。6.3 知識庫內容沖突的應對知識庫建到一定規(guī)模后容易出現(xiàn)內容沖突。比如一條規(guī)則說“陶瓷電容的DC偏壓特性不可忽略”另一條參考數(shù)據給出某個案例里直接忽略偏壓特性做了簡化計算。這兩條同時存在時模型校驗環(huán)節(jié)可能不知道聽誰的。我的做法是給每條知識加優(yōu)先級和適用范圍標簽。專用場景的規(guī)則優(yōu)先級高于通用規(guī)則新版本規(guī)則優(yōu)先級高于舊版本來源可靠的規(guī)則優(yōu)先級高于經驗總結。校驗引擎在匹配到多條規(guī)則時按優(yōu)先級決定采用哪條。6.4 多Agent協(xié)作中的“重復勞動”早期版本的架構里規(guī)劃agent和計算agent偶爾會重復做同一件事——規(guī)劃agent可能順手算了個粗略的電感值計算agent不知道這事又按完整流程算了一遍。浪費token是小事關鍵是兩遍計算如果出現(xiàn)偏差可能引起后續(xù)校驗環(huán)節(jié)的誤判。解決的方案是明確每個agent的職責邊界用契約接口來約束規(guī)劃agent的輸出只能是執(zhí)行計劃不允許包含計算結果計算agent的輸入只能是執(zhí)行計劃不允許自行假設參數(shù)。架構上做了強制隔離問題就徹底消失了。6.5 模型推理速度與精度的平衡這個問題問的人很多加了這么多防幻覺環(huán)節(jié)響應速度會不會慢到沒法用實測下來確實比以前直接問答慢但慢得值。單輪問答大約1秒完整的電源參數(shù)計算流程大約25秒包含多次推理和十幾次工具調用。如果覺得慢可以從三個方向優(yōu)化。第一模型本身用更高吞吐的推理框架吞吐能提升好幾倍第二減少不必要的交叉驗證——不是所有輸出都需要第四層驗證只對關鍵數(shù)值類輸出開啟第三并行化——不同計算任務之間如果沒依賴關系可以同時執(zhí)行總耗時會大幅下降。7. 一些補充的收獲7.1 干凈數(shù)據是agent的地基做完這個項目之后我最大的感觸是agent的效果上限不取決于模型多聰明而取決于你把數(shù)據整理得多干凈。這里的“數(shù)據”指的是規(guī)則、計算公式、工具接口、驗證邏輯每一條都要有明確的定義、邊界和可觀測性。數(shù)據干凈了模型只需要做輕量的理解和規(guī)劃效果自然穩(wěn)定數(shù)據混亂模型再強也會被帶偏。7.2 有價值的工具比復雜的模型更重要第二個體會是關于工具投入的。我一開始把大量精力花在調整prompt、優(yōu)化模型行為上后來發(fā)現(xiàn)效果提升最明顯的其實是把工具層算準、把規(guī)則庫建全。一旦計算工具穩(wěn)定了校驗規(guī)則覆蓋到位了模型的很多“幻覺問題”根本不會觸達最終結果。7.3 從自動化到流程善后目前這套架構處理從需求到參數(shù)計算的完整鏈路已經沒有大問題但如果要往更高階的方向演進還需要在流程善后方面大量投入。所謂善后就是設計產出的下游環(huán)節(jié)——生成原理圖、對接PCB布局、輸出制造文件。這些環(huán)節(jié)每一道都可能出錯都需要自己的校驗體系。如果你也想做類似的方向我的建議是不要一上來就追求一個全能的系統(tǒng)。先把一個最有價值、最容易量化收益的場景做到極致比如buck電路的參數(shù)計算和器件選型做到結果可信、過程可追溯、體驗流暢再逐步擴展拓撲覆蓋范圍和下游環(huán)節(jié)。這樣一步一個腳印走下來系統(tǒng)的可靠性和你的信心都會穩(wěn)步增長。