級(jí)多 Agent 系統(tǒng)評(píng)估框架在半導(dǎo)體晶圓廠場(chǎng)景的落地實(shí)踐)
生產(chǎn)級(jí)多 Agent 系統(tǒng)評(píng)估框架在半導(dǎo)體晶圓廠場(chǎng)景的落地實(shí)踐githubhttps://github.com/BumbleBee-ZDS/fab_agent_test關(guān)鍵詞多 Agent 系統(tǒng)、LLM 評(píng)估體系、工業(yè)大模型、半導(dǎo)體 FAB、白盒架構(gòu)、Streamlit一、背景從能用到可上線Agent 評(píng)估的核心矛盾在大模型應(yīng)用從 PoC 走向生產(chǎn)的實(shí)踐中一個(gè)反復(fù)被驗(yàn)證的結(jié)論是傳統(tǒng)評(píng)估指標(biāo)準(zhǔn)確率、BLEU、ROUGE無法支撐多 Agent 系統(tǒng)的上線決策。以半導(dǎo)體晶圓廠Fabrication Plant簡(jiǎn)稱 FAB的工藝缺陷根因分析場(chǎng)景為例。工藝工程師提交一個(gè)問題“批次 W12345 的關(guān)鍵尺寸Critical Dimension, CD超標(biāo)請(qǐng)分析原因?！比绻捎煤诤?Agent 框架如 LangChain / CrewAI系統(tǒng)可能在三種典型失敗模式下看似工作正常資源失控反復(fù)調(diào)用設(shè)備接口單次分析消耗數(shù)萬 Token成本不可控異常崩潰機(jī)臺(tái) API 超時(shí)后直接拋出未捕獲異常工程師被迫切換到人工排查空轉(zhuǎn)反思Reflector 模塊陷入讓我再想想的循環(huán)中20 輪輸出零信息增益。這些問題的共同特征是結(jié)果可能是對(duì)的但過程是危險(xiǎn)的。1.1 評(píng)估視角的根本轉(zhuǎn)變本文基于《生產(chǎn)環(huán)境多 Agent 系統(tǒng)評(píng)估技術(shù)框架》的核心原則提出一套面向工業(yè)場(chǎng)景的評(píng)估方法論并將其落地為一個(gè)可運(yùn)行的 Streamlit MVP。核心轉(zhuǎn)變?nèi)缦略u(píng)估維度傳統(tǒng)視角生產(chǎn)環(huán)境視角過程質(zhì)量關(guān)注最終輸出是否正確關(guān)注規(guī)劃路徑合理性、是否存在無效輪次、是否空轉(zhuǎn)資源成本通常被忽略Token 消耗、工具調(diào)用次數(shù)、端到端延遲系統(tǒng)韌性報(bào)錯(cuò)即視為失敗異常處理與恢復(fù)能力、降級(jí)策略有效性業(yè)務(wù)價(jià)值語義相似度是否產(chǎn)出可執(zhí)行的工藝建議Actionable Insight一句話總結(jié)評(píng)估體系需要從任務(wù)做沒做完升級(jí)為模塊能力是否達(dá)標(biāo)、協(xié)作鏈路是否健康、線上成本是否可控、業(yè)務(wù)價(jià)值是否兌現(xiàn)。二、系統(tǒng)設(shè)計(jì)白盒架構(gòu)與模塊解耦為避免黑盒不可觀測(cè)的問題本項(xiàng)目采用純手寫 Agent 邏輯 標(biāo)準(zhǔn)庫的方案所有模塊在core/包中顯式定義總代碼量約 600 行無外部 Agent 框架依賴。2.1 目錄結(jié)構(gòu)fab_agent_test/ ├── app.py # Streamlit UI 入口僅 UI 層 ├── core/ # Agent 核心模塊白盒 │ ├── __init__.py │ ├── evaluator.py # 評(píng)估指標(biāo)收集器 │ ├── memory.py # 記憶模塊 │ ├── toolset.py # 工具集含不穩(wěn)定接口 │ ├── planner.py # 規(guī)劃器 │ ├── reflector.py # 反思器 │ └── orchestrator.py # 編排器 / 主循環(huán) ├── data/ │ └── mock_data.py # Mock 數(shù)據(jù)層 ├── gen_test_data.py # DeepSeek 批量生成測(cè)試數(shù)據(jù)可選 └── fab_test_data.json # 生成的測(cè)試數(shù)據(jù)2.2 模塊職責(zé)與接口設(shè)計(jì)(1) Memory —— 防遺忘的短期記憶# core/memory.pyclassMemory:def__init__(self):self._store:dict{}defstore(self,key:str,value)-None:self._store[key]valuedefrecall(self,key:str):returnself._store.get(key)Memory 模塊在 Orchestrator 啟動(dòng)的第一幀被寫入 Lot ID確保后續(xù) 5 步執(zhí)行中不會(huì)丟失關(guān)鍵上下文。(2) Planner —— 規(guī)劃與動(dòng)態(tài)調(diào)度規(guī)劃器輸出一個(gè)有序的子任務(wù)列表這是過程質(zhì)量的首要評(píng)估對(duì)象# core/planner.pyclassPlanner:defmake_plan(self,question:str)-list[str]:return[查詢批次基本信息,查詢機(jī)臺(tái)運(yùn)行日志,查詢工藝配方參數(shù),反思校驗(yàn)數(shù)據(jù)一致性,生成根因分析與建議]defadjust_plan_skip_equipment(self,plan:list[str])-list[str]: 失敗自愈將查詢機(jī)臺(tái)運(yùn)行日志替換為查詢批次歷史。 僅允許調(diào)整一次避免無限降級(jí)。 if查詢機(jī)臺(tái)運(yùn)行日志inplan:plan[plan.index(查詢機(jī)臺(tái)運(yùn)行日志)]查詢批次歷史設(shè)備不可用降級(jí)returnplanreturnplan(3) ToolSet —— 工具調(diào)用與不穩(wěn)定接口模擬ToolSet 封裝了 4 個(gè)工具其中設(shè)備日志接口以 30% 的概率模擬超時(shí)用于驗(yàn)證系統(tǒng)韌性# core/toolset.pyimportrandomclassToolSet:EQUIP_TIMEOUT_RATE0.30defget_equipment_log(self,chamber_id:str)-dict|None:ifrandom.random()self.EQUIP_TIMEOUT_RATE:returnNone# 模擬超時(shí)return{chamber_id:chamber_id,pressure_mTorr:round(random.uniform(6.0,8.0),2),rf_power_w:round(random.uniform(1200,1500),0),temperature_c:round(random.uniform(40,60),1)}# ... 其余工具省略(4) Reflector —— 數(shù)值沖突檢測(cè)反思器不做語義理解而是對(duì)關(guān)鍵數(shù)值做一致性校驗(yàn)。在 FAB 場(chǎng)景中工藝配方設(shè)定的壓力值與機(jī)臺(tái)實(shí)測(cè)壓力值的偏差超過閾值即視為矛盾# core/reflector.pyclassReflector:PRESSURE_DELTA_THRESHOLD1.0# mTorrdefcheck_conflict(self,recipe:dict,equipment_log:dict)-dict:conflictFalseifrecipeandequipment_log:deltaabs(recipe[pressure_setpoint]-equipment_log[pressure_mTorr])ifdeltaself.PRESSURE_DELTA_THRESHOLD:conflictTruereturn{has_conflict:conflict,detail:f壓力差值{delta:.2f}mTorr}(5) Orchestrator —— 主循環(huán)與雙重熔斷編排器是整個(gè)系統(tǒng)的心臟內(nèi)置兩道終止防線# core/orchestrator.pyclassOrchestrator:MAX_STEPS6defrun(self,question:str,evaluator:Evaluator)-str:planself.planner.make_plan(question)last_tool_signatureNoneforidx,stepinenumerate(plan):ifevaluator.step_countself.MAX_STEPS:break# 防線①步數(shù)上限signatureself._get_step_signature(step,evaluator)ifsignaturelast_tool_signature:evaluator.dead_loop_flagTruebreak# 防線②死循環(huán)檢測(cè)# 分發(fā)到具體步驟...last_tool_signaturesignaturereturnself._generate_report(evaluator)2.3 死循環(huán)檢測(cè)機(jī)制這是本文最值得強(qiáng)調(diào)的工程細(xì)節(jié)。傳統(tǒng)超時(shí)機(jī)制只能解決卡死無法解決空轉(zhuǎn)。本方案通過工具調(diào)用簽名比對(duì)實(shí)現(xiàn)語義級(jí)重復(fù)檢測(cè)def_get_step_signature(self,step:str,evaluator:Evaluator)-str:生成步驟簽名用于死循環(huán)檢測(cè)tool_namestep.split()[0].split(()[0].strip()argsevaluator.memory.recall(lot_id)ornonesignaturef{tool_name}|{args}evaluator.tool_call_count1returnsignature原理如果連續(xù)兩步的工具調(diào)用簽名完全一致同一工具 同一參數(shù)判定為死循環(huán)并強(qiáng)制終止。這直接對(duì)應(yīng)理論框架中避免空轉(zhuǎn)反思的要求。三、Evaluator生產(chǎn)級(jí)評(píng)估的核心引擎Evaluator是整套系統(tǒng)的靈魂模塊它在 Agent 運(yùn)行的每一個(gè)原子操作之后收集指標(biāo)對(duì)應(yīng)理論中的四大評(píng)估維度。3.1 指標(biāo)清單與采集點(diǎn)指標(biāo)字段數(shù)據(jù)類型對(duì)應(yīng)維度采集位置step_countint過程質(zhì)量每執(zhí)行一步自增reflection_validbool過程質(zhì)量Reflector 返回沖突時(shí)置 Truetool_call_countint資源成本每次工具調(diào)用后token_cost_mockint資源成本每次輸出拼接后累加字符數(shù)retry_countint系統(tǒng)韌性工具超時(shí)重試后dead_loop_flagbool系統(tǒng)韌性簽名重復(fù)時(shí)置 Truetimeout_handledbool系統(tǒng)韌性重試后是否恢復(fù)resilience_scorestr系統(tǒng)韌性流程結(jié)束時(shí)計(jì)算business_valuebool業(yè)務(wù)價(jià)值報(bào)告生成后檢查3.2 韌性評(píng)分邏輯韌性評(píng)分是連接技術(shù)指標(biāo)與業(yè)務(wù)語義的橋梁defresilience_score(self)-str:ifself.retry_count0:return高未觸發(fā)超時(shí)elifself.retry_count0andself.timeout_handled:return高已成功自愈else:return中已重試但未恢復(fù)已降級(jí)3.3 業(yè)務(wù)價(jià)值判定業(yè)務(wù)價(jià)值的判定遵循可操作性優(yōu)先原則——沒有明確建議的分析對(duì)工程師而言是無用的噪音defhas_business_value(self,report:str)-bool:return建議inreport四、Streamlit UI運(yùn)維視角的大屏化呈現(xiàn)UI 采用雙欄布局左側(cè)為執(zhí)行流日志右側(cè)為實(shí)時(shí)評(píng)估面板刻意模擬運(yùn)維監(jiān)控大屏的信息層級(jí)。4.1 左欄執(zhí)行流輸入?yún)^(qū)提供 DeepSeek 生成的示例問題下拉框 自由文本輸入點(diǎn)擊開始分析后日志區(qū)以時(shí)間戳形式實(shí)時(shí)追加每步事件[12:01:03] [Planner] 生成執(zhí)行計(jì)劃5 步 [12:01:03] [Memory] 存儲(chǔ) Lot ID W12345 [12:01:04] [Tool] get_lot_info(W12345) → CD 實(shí)測(cè) 52.8nm / 目標(biāo) 50.0nm [12:01:05] [Tool] get_equipment_log(ETCH-CH-007) → ? 超時(shí) [12:01:05] [Tool] 重試 get_equipment_log(ETCH-CH-007) → 仍超時(shí) [12:01:05] [Planner] 觸發(fā)降級(jí)跳過機(jī)臺(tái)日志改用批次歷史 [12:01:06] [Tool] get_lot_history(W12345) → 返回近 10 批數(shù)據(jù) [12:01:07] [Reflect] ? 發(fā)現(xiàn)壓力設(shè)定(5.0)與歷史均值(6.8)偏差 1.0mTorr [12:01:08] [Report] 根因分析完成4.2 右欄評(píng)估面板右欄使用st.metric展示核心數(shù)字卡片配合狀態(tài)標(biāo)簽呈現(xiàn)質(zhì)性判斷過程質(zhì)量執(zhí)行步數(shù)5/6、反思有效性? 發(fā)現(xiàn)矛盾資源成本工具調(diào)用3 次、模擬 Token~970系統(tǒng)韌性重試次數(shù)0、死循環(huán)? 未觸發(fā)、韌性評(píng)分 高業(yè)務(wù)價(jià)值? 包含可執(zhí)行建議底部以st.json展示完整evaluator.to_dict()便于后續(xù)接入自動(dòng)化評(píng)測(cè)流水線。五、運(yùn)行結(jié)果分析通過反復(fù)觸發(fā)分析系統(tǒng)呈現(xiàn)兩條典型路徑路徑 A常規(guī)路徑未觸發(fā)超時(shí)批次 W12345 → CD 實(shí)測(cè) 52.8nm / 目標(biāo) 50.0nm超標(biāo) 2.8nm 機(jī)臺(tái) ETCH-CH-007 壓力 6.83mTorr vs 配方設(shè)定 5.0mTorr Reflector → ? 發(fā)現(xiàn)壓力數(shù)據(jù)矛盾Δ 1.83mTorr 1.0 最終報(bào)告 → 根因刻蝕壓力偏差導(dǎo)致過刻蝕 → 3 條建議 評(píng)估步數(shù) 5/6 | 工具 3 次 | Token ~970 | 韌性高未觸發(fā)超時(shí)路徑 B超時(shí)自愈全鏈路W12346 CD 偏小批次 W12346 → CD 實(shí)測(cè) 44.1nm / 目標(biāo) 45.0nm偏小 -0.9nm get_equipment_log(ETCH-CH-012) → ? 超時(shí)30% 概率命中 → 重試 1 次 → 仍超時(shí) → 返回 None → Orchestrator 觸發(fā) Planner.adjust_plan_skip_equipment() → 步驟替換為get_lot_history降級(jí) → Reflector 基于歷史數(shù)據(jù)統(tǒng)計(jì)發(fā)現(xiàn)趨勢(shì)性偏差 最終報(bào)告 → 根因結(jié)論基于歷史推斷 2 條建議 評(píng)估步數(shù) 6/6 | 工具 4 次 | 重試 1 次 | 韌性中已重試但未恢復(fù)關(guān)鍵觀察在路徑 B 中系統(tǒng)沒有崩潰、沒有編造機(jī)臺(tái)數(shù)據(jù)、沒有陷入死循環(huán)而是以降級(jí)歷史推斷的方式給出了一個(gè)可靠性中等但可用的結(jié)論。這種誠實(shí)的降級(jí)比強(qiáng)行給出錯(cuò)誤精確答案更接近生產(chǎn)級(jí)行為。六、理論到實(shí)踐的映射總結(jié)下表將本文的理論框架與代碼實(shí)現(xiàn)一一對(duì)應(yīng)體現(xiàn)評(píng)估先行的設(shè)計(jì)哲學(xué)理論原則代碼實(shí)現(xiàn)位置具體機(jī)制模塊級(jí)白盒評(píng)估core/包 6 個(gè)類每個(gè)模塊獨(dú)立可測(cè)接口清晰過程質(zhì)量避免空轉(zhuǎn)Orchestrator死循環(huán)檢測(cè)簽名比對(duì)連續(xù)重復(fù)即終止資源成本可控Evaluator.token_cost_mock字符級(jí)模擬實(shí)時(shí)展示系統(tǒng)韌性失敗自愈Planner.adjust_plan_skip_equipment30% 超時(shí) → 重試 → 降級(jí)業(yè)務(wù)價(jià)值兌現(xiàn)Evaluator.has_business_value報(bào)告必含建議字段分層測(cè)試單文件 MVP 雙路徑覆蓋正常路徑 異常路徑均驗(yàn)證全鏈路可觀測(cè)Streamlit 日志區(qū)每步帶時(shí)間戳的事件流七、結(jié)論與展望7.1 核心結(jié)論本文驗(yàn)證了以下工程原則評(píng)估體系應(yīng)優(yōu)先于 Prompt 工程在寫任何 Agent 邏輯之前先定義Evaluator的采集點(diǎn)和閾值所有模塊設(shè)計(jì)都圍繞可觀測(cè)性展開。白盒架構(gòu)是工業(yè)落地的底線不引入黑盒框架意味著你對(duì)自己系統(tǒng)的每一個(gè) Token、每一次調(diào)用、每一個(gè)降級(jí)決策擁有完全的控制權(quán)。降級(jí)不是失敗是設(shè)計(jì)生產(chǎn)系統(tǒng)的價(jià)值不在于永不出錯(cuò)而在于出錯(cuò)時(shí)能否給出一個(gè)誠實(shí)的、有用的、成本可控的響應(yīng)。7.2 后續(xù)演進(jìn)方向方向具體內(nèi)容接入真實(shí) LLM將_generate_report替換為 DeepSeek / 通義千問調(diào)用保留Evaluator不變用同一套指標(biāo)對(duì)比不同模型持久化評(píng)估日志Evaluator.to_dict()追加寫入runs/yyyMMdd_HHmmss.json支持 A/B 對(duì)比不同 Planner 策略向量化記憶使用 DashScope Embedding 對(duì)歷史批次特征向量化支持相似批次檢索替代純字符串匹配真實(shí)接口對(duì)接mock_data.py與toolset.py保留相同的返回協(xié)議可無縫替換為 MES / EAP / SECS-GEM 真實(shí)調(diào)用更多 Agent 角色新增reporter.py報(bào)告生成 Agent、validator.py建議可執(zhí)行性審核 Agent附錄運(yùn)行方式# 安裝依賴僅 streamlitpipinstallstreamlit1.57# 啟動(dòng)cdfab_agent_test python-mstreamlit run app.py瀏覽器打開 http://localhost:8501輸入默認(rèn)問題或選擇示例問題點(diǎn)擊開始分析即可觀察完整執(zhí)行流與實(shí)時(shí)評(píng)估面板。約每 3 次運(yùn)行會(huì)觸發(fā)一次超時(shí)自愈場(chǎng)景可在右側(cè)面板觀察重試次數(shù)與韌性評(píng)分的變化。 生產(chǎn)級(jí)多 Agent 系統(tǒng)評(píng)估框架在半導(dǎo)體晶圓廠場(chǎng)景的落地實(shí)踐
生產(chǎn)級(jí)多 Agent 系統(tǒng)評(píng)估框架在半導(dǎo)體晶圓廠場(chǎng)景的落地實(shí)踐githubhttps://github.com/BumbleBee-ZDS/fab_agent_test關(guān)鍵詞多 Agent 系統(tǒng)、LLM 評(píng)估體系、工業(yè)大模型、半導(dǎo)體 FAB、白盒架構(gòu)、Streamlit一、背景從能用到可上線Agent 評(píng)估的核心矛盾在大模型應(yīng)用從 PoC 走向生產(chǎn)的實(shí)踐中一個(gè)反復(fù)被驗(yàn)證的結(jié)論是傳統(tǒng)評(píng)估指標(biāo)準(zhǔn)確率、BLEU、ROUGE無法支撐多 Agent 系統(tǒng)的上線決策。以半導(dǎo)體晶圓廠Fabrication Plant簡(jiǎn)稱 FAB的工藝缺陷根因分析場(chǎng)景為例。工藝工程師提交一個(gè)問題“批次 W12345 的關(guān)鍵尺寸Critical Dimension, CD超標(biāo)請(qǐng)分析原因?！比绻捎煤诤?Agent 框架如 LangChain / CrewAI系統(tǒng)可能在三種典型失敗模式下看似工作正常資源失控反復(fù)調(diào)用設(shè)備接口單次分析消耗數(shù)萬 Token成本不可控異常崩潰機(jī)臺(tái) API 超時(shí)后直接拋出未捕獲異常工程師被迫切換到人工排查空轉(zhuǎn)反思Reflector 模塊陷入讓我再想想的循環(huán)中20 輪輸出零信息增益。這些問題的共同特征是結(jié)果可能是對(duì)的但過程是危險(xiǎn)的。1.1 評(píng)估視角的根本轉(zhuǎn)變本文基于《生產(chǎn)環(huán)境多 Agent 系統(tǒng)評(píng)估技術(shù)框架》的核心原則提出一套面向工業(yè)場(chǎng)景的評(píng)估方法論并將其落地為一個(gè)可運(yùn)行的 Streamlit MVP。核心轉(zhuǎn)變?nèi)缦略u(píng)估維度傳統(tǒng)視角生產(chǎn)環(huán)境視角過程質(zhì)量關(guān)注最終輸出是否正確關(guān)注規(guī)劃路徑合理性、是否存在無效輪次、是否空轉(zhuǎn)資源成本通常被忽略Token 消耗、工具調(diào)用次數(shù)、端到端延遲系統(tǒng)韌性報(bào)錯(cuò)即視為失敗異常處理與恢復(fù)能力、降級(jí)策略有效性業(yè)務(wù)價(jià)值語義相似度是否產(chǎn)出可執(zhí)行的工藝建議Actionable Insight一句話總結(jié)評(píng)估體系需要從任務(wù)做沒做完升級(jí)為模塊能力是否達(dá)標(biāo)、協(xié)作鏈路是否健康、線上成本是否可控、業(yè)務(wù)價(jià)值是否兌現(xiàn)。二、系統(tǒng)設(shè)計(jì)白盒架構(gòu)與模塊解耦為避免黑盒不可觀測(cè)的問題本項(xiàng)目采用純手寫 Agent 邏輯 標(biāo)準(zhǔn)庫的方案所有模塊在core/包中顯式定義總代碼量約 600 行無外部 Agent 框架依賴。2.1 目錄結(jié)構(gòu)fab_agent_test/ ├── app.py # Streamlit UI 入口僅 UI 層 ├── core/ # Agent 核心模塊白盒 │ ├── __init__.py │ ├── evaluator.py # 評(píng)估指標(biāo)收集器 │ ├── memory.py # 記憶模塊 │ ├── toolset.py # 工具集含不穩(wěn)定接口 │ ├── planner.py # 規(guī)劃器 │ ├── reflector.py # 反思器 │ └── orchestrator.py # 編排器 / 主循環(huán) ├── data/ │ └── mock_data.py # Mock 數(shù)據(jù)層 ├── gen_test_data.py # DeepSeek 批量生成測(cè)試數(shù)據(jù)可選 └── fab_test_data.json # 生成的測(cè)試數(shù)據(jù)2.2 模塊職責(zé)與接口設(shè)計(jì)(1) Memory —— 防遺忘的短期記憶# core/memory.pyclassMemory:def__init__(self):self._store:dict{}defstore(self,key:str,value)-None:self._store[key]valuedefrecall(self,key:str):returnself._store.get(key)Memory 模塊在 Orchestrator 啟動(dòng)的第一幀被寫入 Lot ID確保后續(xù) 5 步執(zhí)行中不會(huì)丟失關(guān)鍵上下文。(2) Planner —— 規(guī)劃與動(dòng)態(tài)調(diào)度規(guī)劃器輸出一個(gè)有序的子任務(wù)列表這是過程質(zhì)量的首要評(píng)估對(duì)象# core/planner.pyclassPlanner:defmake_plan(self,question:str)-list[str]:return[查詢批次基本信息,查詢機(jī)臺(tái)運(yùn)行日志,查詢工藝配方參數(shù),反思校驗(yàn)數(shù)據(jù)一致性,生成根因分析與建議]defadjust_plan_skip_equipment(self,plan:list[str])-list[str]: 失敗自愈將查詢機(jī)臺(tái)運(yùn)行日志替換為查詢批次歷史。 僅允許調(diào)整一次避免無限降級(jí)。 if查詢機(jī)臺(tái)運(yùn)行日志inplan:plan[plan.index(查詢機(jī)臺(tái)運(yùn)行日志)]查詢批次歷史設(shè)備不可用降級(jí)returnplanreturnplan(3) ToolSet —— 工具調(diào)用與不穩(wěn)定接口模擬ToolSet 封裝了 4 個(gè)工具其中設(shè)備日志接口以 30% 的概率模擬超時(shí)用于驗(yàn)證系統(tǒng)韌性# core/toolset.pyimportrandomclassToolSet:EQUIP_TIMEOUT_RATE0.30defget_equipment_log(self,chamber_id:str)-dict|None:ifrandom.random()self.EQUIP_TIMEOUT_RATE:returnNone# 模擬超時(shí)return{chamber_id:chamber_id,pressure_mTorr:round(random.uniform(6.0,8.0),2),rf_power_w:round(random.uniform(1200,1500),0),temperature_c:round(random.uniform(40,60),1)}# ... 其余工具省略(4) Reflector —— 數(shù)值沖突檢測(cè)反思器不做語義理解而是對(duì)關(guān)鍵數(shù)值做一致性校驗(yàn)。在 FAB 場(chǎng)景中工藝配方設(shè)定的壓力值與機(jī)臺(tái)實(shí)測(cè)壓力值的偏差超過閾值即視為矛盾# core/reflector.pyclassReflector:PRESSURE_DELTA_THRESHOLD1.0# mTorrdefcheck_conflict(self,recipe:dict,equipment_log:dict)-dict:conflictFalseifrecipeandequipment_log:deltaabs(recipe[pressure_setpoint]-equipment_log[pressure_mTorr])ifdeltaself.PRESSURE_DELTA_THRESHOLD:conflictTruereturn{has_conflict:conflict,detail:f壓力差值{delta:.2f}mTorr}(5) Orchestrator —— 主循環(huán)與雙重熔斷編排器是整個(gè)系統(tǒng)的心臟內(nèi)置兩道終止防線# core/orchestrator.pyclassOrchestrator:MAX_STEPS6defrun(self,question:str,evaluator:Evaluator)-str:planself.planner.make_plan(question)last_tool_signatureNoneforidx,stepinenumerate(plan):ifevaluator.step_countself.MAX_STEPS:break# 防線①步數(shù)上限signatureself._get_step_signature(step,evaluator)ifsignaturelast_tool_signature:evaluator.dead_loop_flagTruebreak# 防線②死循環(huán)檢測(cè)# 分發(fā)到具體步驟...last_tool_signaturesignaturereturnself._generate_report(evaluator)2.3 死循環(huán)檢測(cè)機(jī)制這是本文最值得強(qiáng)調(diào)的工程細(xì)節(jié)。傳統(tǒng)超時(shí)機(jī)制只能解決卡死無法解決空轉(zhuǎn)。本方案通過工具調(diào)用簽名比對(duì)實(shí)現(xiàn)語義級(jí)重復(fù)檢測(cè)def_get_step_signature(self,step:str,evaluator:Evaluator)-str:生成步驟簽名用于死循環(huán)檢測(cè)tool_namestep.split()[0].split(()[0].strip()argsevaluator.memory.recall(lot_id)ornonesignaturef{tool_name}|{args}evaluator.tool_call_count1returnsignature原理如果連續(xù)兩步的工具調(diào)用簽名完全一致同一工具 同一參數(shù)判定為死循環(huán)并強(qiáng)制終止。這直接對(duì)應(yīng)理論框架中避免空轉(zhuǎn)反思的要求。三、Evaluator生產(chǎn)級(jí)評(píng)估的核心引擎Evaluator是整套系統(tǒng)的靈魂模塊它在 Agent 運(yùn)行的每一個(gè)原子操作之后收集指標(biāo)對(duì)應(yīng)理論中的四大評(píng)估維度。3.1 指標(biāo)清單與采集點(diǎn)指標(biāo)字段數(shù)據(jù)類型對(duì)應(yīng)維度采集位置step_countint過程質(zhì)量每執(zhí)行一步自增reflection_validbool過程質(zhì)量Reflector 返回沖突時(shí)置 Truetool_call_countint資源成本每次工具調(diào)用后token_cost_mockint資源成本每次輸出拼接后累加字符數(shù)retry_countint系統(tǒng)韌性工具超時(shí)重試后dead_loop_flagbool系統(tǒng)韌性簽名重復(fù)時(shí)置 Truetimeout_handledbool系統(tǒng)韌性重試后是否恢復(fù)resilience_scorestr系統(tǒng)韌性流程結(jié)束時(shí)計(jì)算business_valuebool業(yè)務(wù)價(jià)值報(bào)告生成后檢查3.2 韌性評(píng)分邏輯韌性評(píng)分是連接技術(shù)指標(biāo)與業(yè)務(wù)語義的橋梁defresilience_score(self)-str:ifself.retry_count0:return高未觸發(fā)超時(shí)elifself.retry_count0andself.timeout_handled:return高已成功自愈else:return中已重試但未恢復(fù)已降級(jí)3.3 業(yè)務(wù)價(jià)值判定業(yè)務(wù)價(jià)值的判定遵循可操作性優(yōu)先原則——沒有明確建議的分析對(duì)工程師而言是無用的噪音defhas_business_value(self,report:str)-bool:return建議inreport四、Streamlit UI運(yùn)維視角的大屏化呈現(xiàn)UI 采用雙欄布局左側(cè)為執(zhí)行流日志右側(cè)為實(shí)時(shí)評(píng)估面板刻意模擬運(yùn)維監(jiān)控大屏的信息層級(jí)。4.1 左欄執(zhí)行流輸入?yún)^(qū)提供 DeepSeek 生成的示例問題下拉框 自由文本輸入點(diǎn)擊開始分析后日志區(qū)以時(shí)間戳形式實(shí)時(shí)追加每步事件[12:01:03] [Planner] 生成執(zhí)行計(jì)劃5 步 [12:01:03] [Memory] 存儲(chǔ) Lot ID W12345 [12:01:04] [Tool] get_lot_info(W12345) → CD 實(shí)測(cè) 52.8nm / 目標(biāo) 50.0nm [12:01:05] [Tool] get_equipment_log(ETCH-CH-007) → ? 超時(shí) [12:01:05] [Tool] 重試 get_equipment_log(ETCH-CH-007) → 仍超時(shí) [12:01:05] [Planner] 觸發(fā)降級(jí)跳過機(jī)臺(tái)日志改用批次歷史 [12:01:06] [Tool] get_lot_history(W12345) → 返回近 10 批數(shù)據(jù) [12:01:07] [Reflect] ? 發(fā)現(xiàn)壓力設(shè)定(5.0)與歷史均值(6.8)偏差 1.0mTorr [12:01:08] [Report] 根因分析完成4.2 右欄評(píng)估面板右欄使用st.metric展示核心數(shù)字卡片配合狀態(tài)標(biāo)簽呈現(xiàn)質(zhì)性判斷過程質(zhì)量執(zhí)行步數(shù)5/6、反思有效性? 發(fā)現(xiàn)矛盾資源成本工具調(diào)用3 次、模擬 Token~970系統(tǒng)韌性重試次數(shù)0、死循環(huán)? 未觸發(fā)、韌性評(píng)分 高業(yè)務(wù)價(jià)值? 包含可執(zhí)行建議底部以st.json展示完整evaluator.to_dict()便于后續(xù)接入自動(dòng)化評(píng)測(cè)流水線。五、運(yùn)行結(jié)果分析通過反復(fù)觸發(fā)分析系統(tǒng)呈現(xiàn)兩條典型路徑路徑 A常規(guī)路徑未觸發(fā)超時(shí)批次 W12345 → CD 實(shí)測(cè) 52.8nm / 目標(biāo) 50.0nm超標(biāo) 2.8nm 機(jī)臺(tái) ETCH-CH-007 壓力 6.83mTorr vs 配方設(shè)定 5.0mTorr Reflector → ? 發(fā)現(xiàn)壓力數(shù)據(jù)矛盾Δ 1.83mTorr 1.0 最終報(bào)告 → 根因刻蝕壓力偏差導(dǎo)致過刻蝕 → 3 條建議 評(píng)估步數(shù) 5/6 | 工具 3 次 | Token ~970 | 韌性高未觸發(fā)超時(shí)路徑 B超時(shí)自愈全鏈路W12346 CD 偏小批次 W12346 → CD 實(shí)測(cè) 44.1nm / 目標(biāo) 45.0nm偏小 -0.9nm get_equipment_log(ETCH-CH-012) → ? 超時(shí)30% 概率命中 → 重試 1 次 → 仍超時(shí) → 返回 None → Orchestrator 觸發(fā) Planner.adjust_plan_skip_equipment() → 步驟替換為get_lot_history降級(jí) → Reflector 基于歷史數(shù)據(jù)統(tǒng)計(jì)發(fā)現(xiàn)趨勢(shì)性偏差 最終報(bào)告 → 根因結(jié)論基于歷史推斷 2 條建議 評(píng)估步數(shù) 6/6 | 工具 4 次 | 重試 1 次 | 韌性中已重試但未恢復(fù)關(guān)鍵觀察在路徑 B 中系統(tǒng)沒有崩潰、沒有編造機(jī)臺(tái)數(shù)據(jù)、沒有陷入死循環(huán)而是以降級(jí)歷史推斷的方式給出了一個(gè)可靠性中等但可用的結(jié)論。這種誠實(shí)的降級(jí)比強(qiáng)行給出錯(cuò)誤精確答案更接近生產(chǎn)級(jí)行為。六、理論到實(shí)踐的映射總結(jié)下表將本文的理論框架與代碼實(shí)現(xiàn)一一對(duì)應(yīng)體現(xiàn)評(píng)估先行的設(shè)計(jì)哲學(xué)理論原則代碼實(shí)現(xiàn)位置具體機(jī)制模塊級(jí)白盒評(píng)估core/包 6 個(gè)類每個(gè)模塊獨(dú)立可測(cè)接口清晰過程質(zhì)量避免空轉(zhuǎn)Orchestrator死循環(huán)檢測(cè)簽名比對(duì)連續(xù)重復(fù)即終止資源成本可控Evaluator.token_cost_mock字符級(jí)模擬實(shí)時(shí)展示系統(tǒng)韌性失敗自愈Planner.adjust_plan_skip_equipment30% 超時(shí) → 重試 → 降級(jí)業(yè)務(wù)價(jià)值兌現(xiàn)Evaluator.has_business_value報(bào)告必含建議字段分層測(cè)試單文件 MVP 雙路徑覆蓋正常路徑 異常路徑均驗(yàn)證全鏈路可觀測(cè)Streamlit 日志區(qū)每步帶時(shí)間戳的事件流七、結(jié)論與展望7.1 核心結(jié)論本文驗(yàn)證了以下工程原則評(píng)估體系應(yīng)優(yōu)先于 Prompt 工程在寫任何 Agent 邏輯之前先定義Evaluator的采集點(diǎn)和閾值所有模塊設(shè)計(jì)都圍繞可觀測(cè)性展開。白盒架構(gòu)是工業(yè)落地的底線不引入黑盒框架意味著你對(duì)自己系統(tǒng)的每一個(gè) Token、每一次調(diào)用、每一個(gè)降級(jí)決策擁有完全的控制權(quán)。降級(jí)不是失敗是設(shè)計(jì)生產(chǎn)系統(tǒng)的價(jià)值不在于永不出錯(cuò)而在于出錯(cuò)時(shí)能否給出一個(gè)誠實(shí)的、有用的、成本可控的響應(yīng)。7.2 后續(xù)演進(jìn)方向方向具體內(nèi)容接入真實(shí) LLM將_generate_report替換為 DeepSeek / 通義千問調(diào)用保留Evaluator不變用同一套指標(biāo)對(duì)比不同模型持久化評(píng)估日志Evaluator.to_dict()追加寫入runs/yyyMMdd_HHmmss.json支持 A/B 對(duì)比不同 Planner 策略向量化記憶使用 DashScope Embedding 對(duì)歷史批次特征向量化支持相似批次檢索替代純字符串匹配真實(shí)接口對(duì)接mock_data.py與toolset.py保留相同的返回協(xié)議可無縫替換為 MES / EAP / SECS-GEM 真實(shí)調(diào)用更多 Agent 角色新增reporter.py報(bào)告生成 Agent、validator.py建議可執(zhí)行性審核 Agent附錄運(yùn)行方式# 安裝依賴僅 streamlitpipinstallstreamlit1.57# 啟動(dòng)cdfab_agent_test python-mstreamlit run app.py瀏覽器打開 http://localhost:8501輸入默認(rèn)問題或選擇示例問題點(diǎn)擊開始分析即可觀察完整執(zhí)行流與實(shí)時(shí)評(píng)估面板。約每 3 次運(yùn)行會(huì)觸發(fā)一次超時(shí)自愈場(chǎng)景可在右側(cè)面板觀察重試次數(shù)與韌性評(píng)分的變化。