生产级多 Agent 系统评估框架在半导体晶圆厂场景的落地实践

生产级多 Agent 系统评估框架在半导体晶圆厂场景的落地实践githubhttps://github.com/BumbleBee-ZDS/fab_agent_test关键词多 Agent 系统、LLM 评估体系、工业大模型、半导体 FAB、白盒架构、Streamlit一、背景从能用到可上线Agent 评估的核心矛盾在大模型应用从 PoC 走向生产的实践中一个反复被验证的结论是传统评估指标准确率、BLEU、ROUGE无法支撑多 Agent 系统的上线决策。以半导体晶圆厂Fabrication Plant简称 FAB的工艺缺陷根因分析场景为例。工艺工程师提交一个问题“批次 W12345 的关键尺寸Critical Dimension, CD超标请分析原因。”如果采用黑盒 Agent 框架如 LangChain / CrewAI系统可能在三种典型失败模式下看似工作正常资源失控反复调用设备接口单次分析消耗数万 Token成本不可控异常崩溃机台 API 超时后直接抛出未捕获异常工程师被迫切换到人工排查空转反思Reflector 模块陷入让我再想想的循环中20 轮输出零信息增益。这些问题的共同特征是结果可能是对的但过程是危险的。1.1 评估视角的根本转变本文基于《生产环境多 Agent 系统评估技术框架》的核心原则提出一套面向工业场景的评估方法论并将其落地为一个可运行的 Streamlit MVP。核心转变如下评估维度传统视角生产环境视角过程质量关注最终输出是否正确关注规划路径合理性、是否存在无效轮次、是否空转资源成本通常被忽略Token 消耗、工具调用次数、端到端延迟系统韧性报错即视为失败异常处理与恢复能力、降级策略有效性业务价值语义相似度是否产出可执行的工艺建议Actionable Insight一句话总结评估体系需要从任务做没做完升级为模块能力是否达标、协作链路是否健康、线上成本是否可控、业务价值是否兑现。二、系统设计白盒架构与模块解耦为避免黑盒不可观测的问题本项目采用纯手写 Agent 逻辑 标准库的方案所有模块在core/包中显式定义总代码量约 600 行无外部 Agent 框架依赖。2.1 目录结构fab_agent_test/ ├── app.py # Streamlit UI 入口仅 UI 层 ├── core/ # Agent 核心模块白盒 │ ├── __init__.py │ ├── evaluator.py # 评估指标收集器 │ ├── memory.py # 记忆模块 │ ├── toolset.py # 工具集含不稳定接口 │ ├── planner.py # 规划器 │ ├── reflector.py # 反思器 │ └── orchestrator.py # 编排器 / 主循环 ├── data/ │ └── mock_data.py # Mock 数据层 ├── gen_test_data.py # DeepSeek 批量生成测试数据可选 └── fab_test_data.json # 生成的测试数据2.2 模块职责与接口设计(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 启动的第一帧被写入 Lot ID确保后续 5 步执行中不会丢失关键上下文。(2) Planner —— 规划与动态调度规划器输出一个有序的子任务列表这是过程质量的首要评估对象# core/planner.pyclassPlanner:defmake_plan(self,question:str)-list[str]:return[查询批次基本信息,查询机台运行日志,查询工艺配方参数,反思校验数据一致性,生成根因分析与建议]defadjust_plan_skip_equipment(self,plan:list[str])-list[str]: 失败自愈将查询机台运行日志替换为查询批次历史。 仅允许调整一次避免无限降级。 if查询机台运行日志inplan:plan[plan.index(查询机台运行日志)]查询批次历史设备不可用降级returnplanreturnplan(3) ToolSet —— 工具调用与不稳定接口模拟ToolSet 封装了 4 个工具其中设备日志接口以 30% 的概率模拟超时用于验证系统韧性# core/toolset.pyimportrandomclassToolSet:EQUIP_TIMEOUT_RATE0.30defget_equipment_log(self,chamber_id:str)-dict|None:ifrandom.random()self.EQUIP_TIMEOUT_RATE:returnNone# 模拟超时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 —— 数值冲突检测反思器不做语义理解而是对关键数值做一致性校验。在 FAB 场景中工艺配方设定的压力值与机台实测压力值的偏差超过阈值即视为矛盾# 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 —— 主循环与双重熔断编排器是整个系统的心脏内置两道终止防线# 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# 防线①步数上限signatureself._get_step_signature(step,evaluator)ifsignaturelast_tool_signature:evaluator.dead_loop_flagTruebreak# 防线②死循环检测# 分发到具体步骤...last_tool_signaturesignaturereturnself._generate_report(evaluator)2.3 死循环检测机制这是本文最值得强调的工程细节。传统超时机制只能解决卡死无法解决空转。本方案通过工具调用签名比对实现语义级重复检测def_get_step_signature(self,step:str,evaluator:Evaluator)-str:生成步骤签名用于死循环检测tool_namestep.split()[0].split(()[0].strip()argsevaluator.memory.recall(lot_id)ornonesignaturef{tool_name}|{args}evaluator.tool_call_count1returnsignature原理如果连续两步的工具调用签名完全一致同一工具 同一参数判定为死循环并强制终止。这直接对应理论框架中避免空转反思的要求。三、Evaluator生产级评估的核心引擎Evaluator是整套系统的灵魂模块它在 Agent 运行的每一个原子操作之后收集指标对应理论中的四大评估维度。3.1 指标清单与采集点指标字段数据类型对应维度采集位置step_countint过程质量每执行一步自增reflection_validbool过程质量Reflector 返回冲突时置 Truetool_call_countint资源成本每次工具调用后token_cost_mockint资源成本每次输出拼接后累加字符数retry_countint系统韧性工具超时重试后dead_loop_flagbool系统韧性签名重复时置 Truetimeout_handledbool系统韧性重试后是否恢复resilience_scorestr系统韧性流程结束时计算business_valuebool业务价值报告生成后检查3.2 韧性评分逻辑韧性评分是连接技术指标与业务语义的桥梁defresilience_score(self)-str:ifself.retry_count0:return高未触发超时elifself.retry_count0andself.timeout_handled:return高已成功自愈else:return中已重试但未恢复已降级3.3 业务价值判定业务价值的判定遵循可操作性优先原则——没有明确建议的分析对工程师而言是无用的噪音defhas_business_value(self,report:str)-bool:return建议inreport四、Streamlit UI运维视角的大屏化呈现UI 采用双栏布局左侧为执行流日志右侧为实时评估面板刻意模拟运维监控大屏的信息层级。4.1 左栏执行流输入区提供 DeepSeek 生成的示例问题下拉框 自由文本输入点击开始分析后日志区以时间戳形式实时追加每步事件[12:01:03] [Planner] 生成执行计划5 步 [12:01:03] [Memory] 存储 Lot ID W12345 [12:01:04] [Tool] get_lot_info(W12345) → CD 实测 52.8nm / 目标 50.0nm [12:01:05] [Tool] get_equipment_log(ETCH-CH-007) → ⚠ 超时 [12:01:05] [Tool] 重试 get_equipment_log(ETCH-CH-007) → 仍超时 [12:01:05] [Planner] 触发降级跳过机台日志改用批次历史 [12:01:06] [Tool] get_lot_history(W12345) → 返回近 10 批数据 [12:01:07] [Reflect] ⚡ 发现压力设定(5.0)与历史均值(6.8)偏差 1.0mTorr [12:01:08] [Report] 根因分析完成4.2 右栏评估面板右栏使用st.metric展示核心数字卡片配合状态标签呈现质性判断过程质量执行步数5/6、反思有效性✅ 发现矛盾资源成本工具调用3 次、模拟 Token~970系统韧性重试次数0、死循环✅ 未触发、韧性评分 高业务价值✅ 包含可执行建议底部以st.json展示完整evaluator.to_dict()便于后续接入自动化评测流水线。五、运行结果分析通过反复触发分析系统呈现两条典型路径路径 A常规路径未触发超时批次 W12345 → CD 实测 52.8nm / 目标 50.0nm超标 2.8nm 机台 ETCH-CH-007 压力 6.83mTorr vs 配方设定 5.0mTorr Reflector → ⚡ 发现压力数据矛盾Δ 1.83mTorr 1.0 最终报告 → 根因刻蚀压力偏差导致过刻蚀 → 3 条建议 评估步数 5/6 | 工具 3 次 | Token ~970 | 韧性高未触发超时路径 B超时自愈全链路W12346 CD 偏小批次 W12346 → CD 实测 44.1nm / 目标 45.0nm偏小 -0.9nm get_equipment_log(ETCH-CH-012) → ⚠ 超时30% 概率命中 → 重试 1 次 → 仍超时 → 返回 None → Orchestrator 触发 Planner.adjust_plan_skip_equipment() → 步骤替换为get_lot_history降级 → Reflector 基于历史数据统计发现趋势性偏差 最终报告 → 根因结论基于历史推断 2 条建议 评估步数 6/6 | 工具 4 次 | 重试 1 次 | 韧性中已重试但未恢复关键观察在路径 B 中系统没有崩溃、没有编造机台数据、没有陷入死循环而是以降级历史推断的方式给出了一个可靠性中等但可用的结论。这种诚实的降级比强行给出错误精确答案更接近生产级行为。六、理论到实践的映射总结下表将本文的理论框架与代码实现一一对应体现评估先行的设计哲学理论原则代码实现位置具体机制模块级白盒评估core/包 6 个类每个模块独立可测接口清晰过程质量避免空转Orchestrator死循环检测签名比对连续重复即终止资源成本可控Evaluator.token_cost_mock字符级模拟实时展示系统韧性失败自愈Planner.adjust_plan_skip_equipment30% 超时 → 重试 → 降级业务价值兑现Evaluator.has_business_value报告必含建议字段分层测试单文件 MVP 双路径覆盖正常路径 异常路径均验证全链路可观测Streamlit 日志区每步带时间戳的事件流七、结论与展望7.1 核心结论本文验证了以下工程原则评估体系应优先于 Prompt 工程在写任何 Agent 逻辑之前先定义Evaluator的采集点和阈值所有模块设计都围绕可观测性展开。白盒架构是工业落地的底线不引入黑盒框架意味着你对自己系统的每一个 Token、每一次调用、每一个降级决策拥有完全的控制权。降级不是失败是设计生产系统的价值不在于永不出错而在于出错时能否给出一个诚实的、有用的、成本可控的响应。7.2 后续演进方向方向具体内容接入真实 LLM将_generate_report替换为 DeepSeek / 通义千问调用保留Evaluator不变用同一套指标对比不同模型持久化评估日志Evaluator.to_dict()追加写入runs/yyyMMdd_HHmmss.json支持 A/B 对比不同 Planner 策略向量化记忆使用 DashScope Embedding 对历史批次特征向量化支持相似批次检索替代纯字符串匹配真实接口对接mock_data.py与toolset.py保留相同的返回协议可无缝替换为 MES / EAP / SECS-GEM 真实调用更多 Agent 角色新增reporter.py报告生成 Agent、validator.py建议可执行性审核 Agent附录运行方式# 安装依赖仅 streamlitpipinstallstreamlit1.57# 启动cdfab_agent_test python-mstreamlit run app.py浏览器打开 http://localhost:8501输入默认问题或选择示例问题点击开始分析即可观察完整执行流与实时评估面板。约每 3 次运行会触发一次超时自愈场景可在右侧面板观察重试次数与韧性评分的变化。