半导体晶圆厂CIM系统Agent评估方案：从苛刻方法论到MVP实践

摘要：当AI Agent走进半导体晶圆厂的CIM系统，一个错误的工艺参数建议可能导致整批晶圆报废。本文提出一套面向工业级可靠性的Agent评估方法论，并在此基础上从零构建一个可运行的MVP评估系统（Fab Agent Evaluator），将"苛刻"的理论落地为可触摸的代码。全文涵盖评估哲学、五阶段框架、三层指标体系、评分引擎设计与实战演示。

---

github:https://github.com/BumbleBee-ZDS/fab_agent_evaluator

一、为什么通用评估方法在晶圆厂不够用

1.1 代价不同：从"体验差"到"真金白银"

在传统互联网场景中，一个Chatbot回答得不理想，用户最多吐槽一句"这AI真笨"，换个话题继续聊。但在半导体晶圆厂的CIM（Computer Integrated Manufacturing）系统中，Agent犯错的成本是指数级的：

错误类型	可能后果	经济损失量级
工艺参数误设	整批晶圆报废	数十万~数百万美元
调度决策失误	设备闲置、交期延误	每小时数万美元
安全规则违反	人员伤害、有毒气体泄漏	不可估量
数据篡改/泄露	违反ISO/GMP审计、客户信任危机	长期品牌损失

这意味着：通用AI评估中"大致满意就行"的思路，在晶圆厂完全失效。

1.2 通用评估的盲区

当前主流的Agent评估方案（如微软Copilot Studio的四阶段框架、LangSmith的LLM-as-a-Judge）虽然在通用场景表现出色，但面对半导体CIM系统时存在明显不足：

• Copilot Studio 的评分器以语义质量为主，缺乏对数值精度和安全规则硬约束的专门支持。
• LangSmith 的LLM-as-a-Judge虽然灵活，但裁判模型本身的不确定性引入了新的风险——你不能用"可能对的AI"去评估"必须对的AI"。
• 两者都未覆盖故障注入、形式化验证、SEMI合规审计等工业级要求。

1.3 我们需要什么

一句话总结：把"看起来不错"变成"绝对正确"。

这需要一套全新的评估哲学——不是追求平均分好看，而是确保每一个致命错误都被消灭；不是依赖单一评分器，而是构建多层防御体系；不是一次性测试，而是贯穿Agent全生命周期的持续验证。

---

二、六项铁律：评估体系的底层原则

在进入框架之前，先明确六条不可妥协的设计原则：

铁律	含义	在晶圆厂的具体体现
确定性优先于创造性	涉及设备控制、工艺参数、安全规则时，输出必须唯一正确	Agent回答"刻蚀功率"时不能"发挥"，必须给出精确数值
可追溯性	每次推理路径可审计	知道Agent引用了哪个知识库、调用了哪个API、置信度多少
实时性	响应时间有硬约束	设备控制场景P99 < 500ms，超时即失败
鲁棒性	抵抗噪声、并发、故障	传感器抖动、网络波动下仍可靠
领域完备性	覆盖所有已知异常模式和安全规程	每台设备、每种工艺、每个异常码都有对应用例
合规性	不违反SEMI标准和工厂SOP	输出格式、日志记录满足SEMI E10/E30/E40

这六条铁律是整个评估体系的"宪法"，后续所有设计都围绕它们展开。

---

三、五阶段增强评估框架

微软在Copilot Studio培训中提出了四阶段评估框架（Core → Baseline → Expansion → Operationalization），我们在其基础上增加了一个验证与认证阶段，形成适用于半导体CIM的五阶段模型。在此cue一下前司Microsoft微软的agent系统，就把本系统取名为dazhuang（大壮）吧（手动狗头🐶）

3.1 第一阶段：核心阶段（Core）——知识图谱驱动的用例设计

目标：围绕最关键的业务场景，构建第一批测试用例。

实施方法：

1. 构建领域知识图谱：包含设备类型（光刻机、刻蚀机、CVD、CMP等）、工艺节点（7nm/5nm/3nm）、物料属性、工艺流程、异常码、安全规则、SOP文档。
2. 定义质量信号：
   • 精确性：数值、单位、设备ID必须100%匹配
   • 完整性：回答是否涵盖所有必要工序参数
   • 安全性：是否包含安全警告
   • 时效性：是否引用最新版工艺配方
3. 生成测试用例：利用知识图谱的关系推理自动生成组合用例。
4. 验收标准：每条用例附带硬性条件（数值误差<0.1%）和软性条件（语义完整度>95%）。

MVP中的对应实现：

在我们的Fab Agent Evaluator MVP中，这一阶段体现为TestCase模型的设计：

class TestCase(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(200))           # 用例名称
    input_text = db.Column(db.Text)            # 用户输入
    expected_output = db.Column(db.Text)        # 期望输出
    scenario = db.Column(db.String(100))        # 场景标签
    priority = db.Column(db.String(20))         # critical/high/medium/low
    tolerance = db.Column(db.Float, default=0.0) # 数值容差

每条用例都带有priority和tolerance字段——这正是"质量信号"的具象化。priority="critical"的用例（如紧急停机流程）在评估中享有最高权重，任何失败都会触发告警；tolerance则允许对数值型输出设置可接受的浮动范围，体现了"确定性优先"与"工程现实"的平衡。

MVP预置的12条用例覆盖了三大核心场景：

• 工艺参数查询（5条）：刻蚀功率、沉积温度、薄膜厚度、CMP压力、离子注入剂量
• 设备状态管理（4条）：光刻机、蚀刻机、沉积腔室、清洗机状态
• 安全规则（3条）：紧急停机、化学品泄漏、无尘室进入规范

3.2 第二阶段：基线阶段（Baseline）——零缺陷容忍的首轮评估

目标：运行核心用例，建立性能基线。

关键区别：与通用方案不同，晶圆厂场景的基线评估有一条不可逾越的红线——

致命错误率必须为0%。

首次通过率低于50%完全正常（甚至预期如此），但一旦发现A类错误（导致设备损坏、人身安全、批量报废），必须立即冻结Agent版本，不允许进入下一阶段。

失败分类体系：

类别	定义	处置方式
A类（致命）	设备/人员/批次风险	立即冻结版本，强制修复
B类（严重）	效率下降，需人工复核	下一迭代必须修复
C类（轻微）	表述不完善但信息正确	可延后优化

MVP中的对应实现：

MVP的评估执行流程天然支持这一理念。在evaluation_routes.py中，每次执行评估时都会逐条运行用例并打分：

# 伪代码逻辑
for test_case in selected_cases:
    actual_output = agent.invoke(test_case.input_text)  # 调用Agent
    score = scorer_manager.get_best_score(
        actual_output, 
        test_case.expected_output, 
        test_case.tolerance
    )
    passed = (score >= 1.0)  # 满分才视为通过
    
    if not passed and test_case.priority == "critical":
        # A类错误：记录并告警
        log_critical_failure(test_case, actual_output)

虽然MVP中使用的是模拟输出（手动输入或预设值），但架构已经为接入真实Agent预留了接口。当priority="critical"的用例失败时，系统会在结果看板中以醒目的红色标记，并阻止该版本进入"生产推荐"状态。

为什么首次通过率可以低？ 因为基线的价值不是"刷分"，而是建立参照系。知道当前版本在哪些场景不及格，才能有针对性地迭代。MVP的结果看板正是为此设计——Chart.js饼图直观展示通过率，明细列表逐条展示失败原因，工程师可以一眼定位问题。

3.3 第三阶段：扩展阶段（Expansion）——故障注入与压力测试

目标：在核心用例稳定后，系统性扩大测试覆盖面。

在通用框架的四种测试类型基础上，半导体场景需要额外增加故障注入测试和边界条件测试：

测试类型	半导体专用场景	评估方法
核心评估集	回归所有已知工艺异常场景	自动化回归
变体测试	同一问题的不同表述（中英混杂、缩写、方言）	NLP变异引擎
架构测试	多Agent协作、30+轮上下文保持	分布式追踪
边缘用例	空输入、负值、非法字符、SQL注入	模糊测试
故障注入	传感器漂移、API超时、数据库中断、设备离线	Chaos Engineering
边界条件	极限吞吐（100并发）、内存泄漏、P99延迟	性能压测

MVP中的对应实现：

MVP虽然受限于规模，但为扩展阶段预留了架构基础：

• 变体测试：通过scenario字段筛选用例，可以轻松创建"仅工艺参数"或"仅安全规则"的针对性评估运行。
• 边缘用例：TestCase模型的input_text字段支持任意文本，工程师可以手动添加"空字符串"、“超长输入”、"包含特殊字符"等极端用例。
• 故障注入的接口预留：评分管理器的策略模式设计允许未来插入新的评分器（如TimeoutScorer、ExceptionHandlingScorer），无需修改核心代码。

3.4 第四阶段：运营化阶段（Operationalization）——持续评估流水线

目标：将评估嵌入Agent的开发与部署全生命周期。

核心实践：

1. 评估流水线：每次Git提交自动触发全量测试，耗时控制在15分钟内。
2. 金丝雀发布：新Agent版本先在5%生产流量上灰度运行，实时监控关键指标。
3. 自动回滚：若任何指标偏离基线超过3σ，自动回滚至上一稳定版本。

MVP中的对应实现：

MVP通过Flask CLI命令flask init-db实现了一键初始化，配合pytest测试套件（13个测试用例覆盖评分器单元、评分管理器集成和API接口），为后续接入CI/CD流水线做好了准备。当项目从MVP演进到生产级时，只需在GitLab CI配置中添加：

# .gitlab-ci.yml（未来规划）
stages:
  - test

agent-evaluation:
  stage: test
  script:
    - pip install -r requirements.txt
    - flask init-db
    - python -m pytest tests/ -v
  only:
    - main
    - merge_requests

3.5 第五阶段：验证与认证阶段（Validation & Certification）——第三方审计级评估

这是新增的终极关卡，专为半导体行业的高合规要求设计：

1. 形式化验证：对Agent中涉及安全规则的逻辑进行模型检验，证明在所有可能状态下都不会违反规则。
2. 对抗性测试：红队模拟黑客攻击，测试Agent是否会泄露工艺配方或绕过权限。
3. 合规审计：对照SEMI E10/E30/E40标准逐条检查。
4. 人类专家盲评：资深工艺工程师对100个真实场景独立评分，要求平均分≥4.5/5。

MVP中的对应实现：

MVP的priority="critical"用例标记和scenario="安全规则"分类，为后续的形式化验证和对抗性测试提供了基础数据。例如，所有安全规则类用例可以导出为形式化验证工具的输入规范。

---

四、三层金字塔指标体系

4.1 第一层：硬性指标（一票否决）

指标	定义	阈值
致命错误率	导致设备/人员/批次风险的错误占比	0%
响应时间P99	99%请求的响应时间	≤500ms（在线）
可用性	Agent服务正常运行时间比例	≥99.99%
数据准确性	数值、ID、单位匹配率	100%
合规覆盖率	SEMI标准条款满足数/总条款数	≥90%

4.2 第二层：质量指标（持续优化）

指标	定义	目标
语义完整度	回答覆盖必要信息点的比例	≥95%
引用正确率	引用文档/知识库的准确性	≥98%
多轮连贯性	5+轮对话上下文保持率	≥90%
拒答合理性	对超范围请求的拒绝是否有替代方案	≥85%
用户采纳率	工程师采纳Agent建议的比例	≥70%

4.3 第三层：鲁棒性指标（压力测试）

指标	定义	目标
噪声容忍度	输入含20%拼写错误时的准确率	≥80%
并发稳定性	100并发下错误率	≤1%
故障恢复时间	API宕机后恢复服务的时间	≤30秒

MVP如何映射这些指标？

MVP的结果看板直接展示了第一层中的"数据准确性"（通过率）和第二层中的"语义完整度"（语义相似度得分）。虽然MVP运行在单机SQLite上无法模拟100并发，但其评分引擎的设计已经为后续扩展奠定了基础。

---

五、MVP深度解析：Fab Agent Evaluator

理论说完了，现在来看我们如何将这套苛刻的方法论落地为一个可运行的系统。

5.1 架构设计

fab_agent_evaluator/
├── app.py                    # Flask入口 + CLI命令
├── config.py                 # 配置
├── models.py                 # SQLAlchemy模型
├── routes/
│   ├── testcase_routes.py    # 用例 CRUD API
│   └── evaluation_routes.py  # 评估运行 API
├── services/
│   ├── scorers.py            # 三种评分器
│   └── scorer_manager.py     # 评分策略编排
├── templates/
│   └── index.html            # SPA前端
├── static/js/app.js          # AJAX交互
└── tests/test_app.py         # 测试套件

5.2 评分引擎：策略模式的核心实现

评分引擎是整套系统的大脑，也是方法论中"分层验证"思想的直接体现。

三种评分器

# services/scorers.py

class ExactMatchScorer:
    """精确字符串匹配 - 适用于设备状态、安全规则"""
    def score(self, actual: str, expected: str, tolerance: float = 0.0) -> float:
        return 1.0 if actual.strip() == expected.strip() else 0.0


class NumericToleranceScorer:
    """数值容差匹配 - 适用于工艺参数"""
    def score(self, actual: str, expected: str, tolerance: float = 0.0) -> float:
        try:
            actual_num = float(actual.strip())
            expected_num = float(expected.strip())
            return 1.0 if abs(actual_num - expected_num) <= tolerance else 0.0
        except ValueError:
            return 0.0  # 无法转为数字时回退


class SemanticSimilarityScorer:
    """语义相似度 - 基于TF-IDF + 余弦相似度，作为回退"""
    def score(self, actual: str, expected: str, tolerance: float = 0.0) -> float:
        from sklearn.feature_extraction.text import TfidfVectorizer
        from sklearn.metrics.pairwise import cosine_similarity
        
        vectorizer = TfidfVectorizer()
        vectors = vectorizer.fit_transform([actual, expected])
        similarity = cosine_similarity(vectors[0:1], vectors[1:2])
        return float(similarity[0][0])

评分管理器：编排策略管道

# services/scorer_manager.py

def evaluate(actual: str, expected: str, tolerance: float) -> dict:
    """
    分层评估策略：
    1. 先尝试数值容差匹配（如果tolerance > 0）
    2. 再尝试精确匹配
    3. 最后用语义相似度作为回退
    返回最高分及详细评分信息
    """
    results = {}
    
    # 数值容差
    numeric_scorer = NumericToleranceScorer()
    numeric_score = numeric_scorer.score(actual, expected, tolerance)
    results['numeric'] = numeric_score
    
    # 精确匹配
    exact_scorer = ExactMatchScorer()
    exact_score = exact_scorer.score(actual, expected)
    results['exact'] = exact_score
    
    # 语义相似度（始终计算，作为参考）
    semantic_scorer = SemanticSimilarityScorer()
    semantic_score = semantic_scorer.score(actual, expected)
    results['semantic'] = semantic_score
    
    # 取最高分
    final_score = max(numeric_score, exact_score, semantic_score)
    
    return {
        'score': final_score,
        'passed': final_score >= 1.0,
        'details': results
    }

为什么这个设计体现了方法论精神？

以一条真实的工艺参数用例为例：

输入：“PECVD沉积工艺的目标温度是多少？”
期望输出：“350.0”
容差：5.0
Agent实际输出：“大约是352度”

评分过程如下：

1. 精确匹配：“大约是352度” ≠ “350.0” → 0.0分
2. 数值容差：提取352和350，差值2 ≤ 容差5 → 1.0分 ✅
3. 语义相似度：虽然已经满分，但仍计算作为参考

最终得分：1.0（通过）。

如果Agent回答的是"我不知道"，则：

1. 精确匹配 → 0.0
2. 数值容差 → 0.0（无法转浮点）
3. 语义相似度 → 约0.15

最终得分：0.15（失败），且远低于通过阈值。

这套机制确保了：该严的地方绝不放水（安全规则精确匹配），该松的地方留有余地（工艺参数容差匹配），不确定的地方给出合理分数（语义相似度回退）。

5.3 数据库模型：支撑评估全生命周期

# models.py

class TestCase(db.Model):
    """测试用例 - 对应方法论'核心阶段'的用例设计"""
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(200), nullable=False)
    input_text = db.Column(db.Text, nullable=False)
    expected_output = db.Column(db.Text, nullable=False)
    scenario = db.Column(db.String(100))       # 工艺参数查询/设备状态/安全规则
    priority = db.Column(db.String(20))        # critical/high/medium/low
    tolerance = db.Column(db.Float, default=0.0)
    created_at = db.Column(db.DateTime, default=datetime.utcnow)

class EvaluationRun(db.Model):
    """评估运行 - 对应方法论'基线阶段'的评估记录"""
    id = db.Column(db.Integer, primary_key=True)
    run_name = db.Column(db.String(200), nullable=False)
    status = db.Column(db.String(20), default='pending')  # running/completed/failed
    total_cases = db.Column(db.Integer, default=0)
    passed = db.Column(db.Integer, default=0)
    failed = db.Column(db.Integer, default=0)
    created_at = db.Column(db.DateTime, default=datetime.utcnow)

class EvaluationResult(db.Model):
    """单条评估结果 - 记录每次评估的详细数据"""
    id = db.Column(db.Integer, primary_key=True)
    run_id = db.Column(db.Integer, db.ForeignKey('evaluation_run.id'))
    test_case_id = db.Column(db.Integer, db.ForeignKey('test_case.id'))
    actual_output = db.Column(db.Text)
    score = db.Column(db.Float)
    passed = db.Column(db.Boolean, default=False)
    details = db.Column(db.Text)  # JSON: 各评分器的详细分数

这个数据模型的设计直接映射了方法论的评估流程：TestCase是"核心阶段"的产物，EvaluationRun是"基线阶段"的执行记录，EvaluationResult则保存了每次评估的完整证据链——满足铁律中的"可追溯性"要求。

5.4 API设计：RESTful评估接口

方法	路径	功能	对应方法论阶段
GET	/api/testcases?scenario=工艺参数查询	按场景筛选用例	核心阶段
POST	/api/testcases	新增用例	核心阶段
POST	/api/runs	创建评估运行	基线阶段
POST	/api/runs/<id>/execute	执行评估	基线/扩展阶段
GET	/api/runs/<id>	查看评估结果	所有阶段

5.5 前端看板：可视化即洞察

MVP的前端使用Bootstrap 5 + Chart.js，实现了三个核心页面：

1. 测试用例管理：表格展示所有用例，支持按场景筛选、新增、编辑、删除。
2. 评估运行：创建新的评估运行，勾选用例，一键执行。
3. 结果看板：Chart.js饼图展示通过率，明细列表展示每条用例的得分和状态。

这正是方法论中"基线阶段"所强调的——通过可视化建立性能基线。工程师不再需要盯着日志文件，一眼就能看到Agent在哪些场景不及格。

5.6 预置测试用例示例

MVP初始化时自动插入12条用例，以下是几条代表性数据：

用例1：刻蚀功率查询（critical + 精确匹配）

{
  "name": "刻蚀RF功率",
  "input_text": "当前刻蚀工艺的RF功率是多少？",
  "expected_output": "1500W",
  "scenario": "工艺参数查询",
  "priority": "critical",
  "tolerance": 0.0
}

用例2：沉积温度（high + 数值容差）

{
  "name": "沉积温度",
  "input_text": "PECVD沉积工艺的目标温度是多少摄氏度？",
  "expected_output": "350.0",
  "scenario": "工艺参数查询",
  "priority": "high",
  "tolerance": 5.0
}

用例3：紧急停机（critical + 安全规则）

{
  "name": "紧急停机流程",
  "input_text": "洁净室内发生火灾警报，应该怎么做？",
  "expected_output": "立即按下最近的红色紧急停机按钮，所有设备自动进入安全模式，按照疏散路线撤离到安全集合点",
  "scenario": "安全规则",
  "priority": "critical",
  "tolerance": 0.0
}

注意这三条用例的设计差异：

• 刻蚀功率用精确匹配（tolerance=0），因为"1500W"和"1501W"可能意味着不同的工艺结果。
• 沉积温度用数值容差（tolerance=5.0），因为工艺窗口本身允许±5°C的浮动。
• 紧急停机用语义相似度回退，因为安全流程的核心信息正确即可，表述可以有一定弹性。

这种差异化的评估策略，正是方法论"六项铁律"中确定性优先于创造性的具象化。

---

六、端到端实战演示

6.1 初始化与启动

# 1. 安装依赖
cd fab_agent_evaluator
pip install -r requirements.txt

# 2. 初始化数据库（自动创建表 + 插入12条示例用例）
flask init-db

# 3. 启动服务
flask run

访问 http://127.0.0.1:5000 ，

6.2 创建并执行评估

1. 在"评估运行"页面，输入运行名称"基线评估 v1.0"
2. 勾选全部12条用例
3. 点击"开始评估"
4. 系统逐条运行评分器，生成结果

6.3 查看结果看板

评估完成后，切换到"结果看板"页面：

• 饼图：通过率可视化（如 10/12 通过，通过率83.3%）
• 明细列表：每条用例的得分、状态（绿色通过/红色失败）、失败原因
  

6.4 分析失败用例

假设"离子注入剂量"用例失败，Agent返回的是"大约是5e14 cm^-2"，而期望输出是"5.0e14"。

分析过程：

1. 精确匹配：失败（字符串不同）
2. 数值容差：失败（"5e14"无法被Python的float()直接解析）
3. 语义相似度：得分约0.75（语义接近但未满分）

改进方向：

• 方案A：在NumericToleranceScorer中增加对科学计数法的解析支持
• 方案B：在Agent端规范输出格式，要求使用标准浮点表示
• 方案C：添加专门的ScientificNotationScorer

这正体现了方法论中"基线阶段"的核心价值——不是追求高分，而是暴露问题、指导迭代。

---

七、测试验证：确保评估系统自身可靠

一个评估系统的致命弱点在于：如果评估系统本身有bug，那么"通过评估"将毫无意义。

MVP包含13个测试用例，覆盖三个层面：

测试类型	数量	覆盖内容
评分器单元测试	6	三种评分器的边界条件、正常路径、异常输入
评分管理器集成测试	3	策略管道的正确性、最高分逻辑、容差传递
API接口测试	4	CRUD操作、评估执行流程、错误处理

运行方式：

python -m pytest tests/test_app.py -v

示例测试代码：

# tests/test_app.py

def test_numeric_tolerance_within_range():
    """数值在容差范围内应得满分"""
    scorer = NumericToleranceScorer()
    score = scorer.score("352.0", "350.0", 5.0)
    assert score == 1.0

def test_numeric_tolerance_out_of_range():
    """数值超出容差范围应得0分"""
    scorer = NumericToleranceScorer()
    score = scorer.score("360.0", "350.0", 5.0)
    assert score == 0.0

def test_semantic_similarity_fallback():
    """当精确匹配失败时，语义相似度应给出合理分数"""
    actual = "温度大约是350度左右"
    expected = "350.0"
    result = evaluate(actual, expected, 0.0)
    assert result['details']['semantic'] > 0.5
    assert result['details']['exact'] == 0.0

这呼应了方法论中"验证与认证阶段"的思想——评估系统本身必须经过严格验证，才能被信任。

---

八、从MVP到生产：演进路线图

MVP只是起点。要将这套系统从"能跑通"升级为"能上线"，需要按方法论的五阶段框架逐步演进：

阶段	周期	关键任务	产出
MVP（已完成）	-	评分引擎、用例管理、结果看板	可运行的评估原型
第一阶段：核心增强	2周	对接真实Agent API、扩展用例至200+	端到端评估能力
第二阶段：基线建立	2周	致命错误清零、A/B/C分类、迭代闭环	基线报告
第三阶段：扩展测试	4周	故障注入、变体生成、性能压测	鲁棒性报告
第四阶段：运营化	2周	CI/CD集成、金丝雀发布、自动回滚	评估流水线
第五阶段：认证	2周	形式化验证、红队测试、SEMI审计	认证证书

8.1 近期重点：对接真实LLM

MVP目前使用手动输入的actual_output模拟Agent响应。下一步是将Agent.invoke()替换为真实的LLM调用：

# 未来实现
import openai

def get_agent_response(input_text: str) -> str:
    """调用真实Agent（如基于GPT-4o的工艺助手）"""
    response = openai.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "你是半导体晶圆厂的工艺助手..."},
            {"role": "user", "content": input_text}
        ]
    )
    return response.choices[0].message.content

然后将其接入评估执行流程：

# evaluation_routes.py 中的 execute 逻辑
for test_case in selected_cases:
    actual_output = get_agent_response(test_case.input_text)  # 真实调用
    result = evaluate(actual_output, test_case.expected_output, test_case.tolerance)
    # ...保存结果

8.2 中期重点：故障注入与混沌工程

引入Chaos Engineering工具（如LitmusChaos），在评估过程中随机模拟：

• LLM API超时（测试Agent的降级策略）
• 数据库中断（测试评估系统的容错能力）
• 网络分区（测试分布式Agent的协同能力）

8.3 远期重点：Auto Research

最终愿景是实现Andrej Karpathy提出的"Auto Research"概念——让AI Agent自动完成"测试→分析失败→调整Prompt→再测试"的闭环。评估系统将不再是被动的工具，而是主动的优化引擎。

---

九、总结

本文提出了半导体晶圆厂CIM系统Agent评估方案，核心贡献在于：

1. 六项铁律：为工业级Agent评估确立了不可妥协的底线原则。
2. 五阶段增强框架：在微软四阶段基础上新增"验证与认证"阶段，覆盖从用例设计到第三方审计的完整生命周期。
3. 三层指标体系：硬性指标一票否决、质量指标持续优化、鲁棒性指标压力验证。
4. Fab Agent Evaluator MVP：将方法论落地为可运行的代码，验证了分层评分引擎、知识图谱驱动的用例设计和可视化基线的可行性。

最核心的思想只有一句话：在半导体晶圆厂，评估不是锦上添花的环节，而是生死攸关的护栏。

当你听到"这个Agent在生产环境表现还不错"时，请追问一句：你的评估体系够苛刻吗？

如果答案是否定的，那么"还不错"可能只是暴风雨前的宁静。

---

附录：快速开始

# 克隆项目
git clone https://github.com/xxx/fab-agent-evaluator.git
cd fab-agent-evaluator

# 安装依赖
pip install -r requirements.txt

# 初始化数据库（自动插入12条半导体场景用例）
flask init-db

# 启动服务
flask run

# 访问 http://127.0.0.1:5000

附录：项目结构

fab_agent_evaluator/
├── app.py                    # Flask应用入口
├── config.py                 # 配置
├── models.py                 # 数据库模型
├── routes/
│   ├── testcase_routes.py    # 用例管理 API
│   └── evaluation_routes.py  # 评估运行 API
├── services/
│   ├── scorers.py            # 三种评分器
│   └── scorer_manager.py     # 评分策略编排
├── templates/
│   └── index.html            # 前端SPA
├── static/js/app.js          # AJAX交互逻辑
├── tests/test_app.py         # 测试套件
└── requirements.txt          # 依赖清单

---

免责声明：本文所述评估方案和方法论仅供技术交流参考。实际半导体产线部署需结合具体工厂的工艺规范、安全标准和合规要求进行定制化开发，并通过完整的形式化验证和第三方审计。文中提到的部分功能特性可能随技术演进而变化。

关于作者：专注于AI工程化与工业智能化，致力于将大语言模型安全地引入关键基础设施领域。欢迎在评论区交流你的Agent评估实践！