1. FAB 产线告警为什么需要 Agent 自愈半导体 FAB 的运维现场有个很现实的问题设备种类多、故障模式复杂、处置动作高度依赖老师傅的经验。一条 P1 告警从触发到工程师介入平均要 30 分钟新手可能拖到 2 小时。这中间产线还在跑批次还在流每多停一分钟都是真金白银。我接触过不少 FAB 的运维团队他们最头疼的不是没有数据而是数据太多、告警太杂。FDC故障检测与分类系统、SPC统计过程控制系统、MES 的批次 Hold 事件三套系统各报各的工程师要在多个界面之间来回切换才能拼出一个完整的故障上下文。等拼完了最佳处置窗口可能已经过了。智能运维 Agent 要解决的就是这个「拼上下文 给建议」的环节。它的核心能力有三块第一把多源告警归一化成结构化事件第二用大模型做根因推理结合历史 Case 知识库给出处置建议第三把建议推给工程师确认低风险动作可以走预设的自愈流程。适合谁来跟做这篇教程有 Python 基础、了解 FAB 基本工艺流程的运维工程师或设备工程师。你不需要是 AI 专家但需要能看懂 JSON、会配环境变量、能跑通一个 HTTP 请求。Cursor 作为开发环境Claude 作为推理核心两者配合能把搭建时间压到 30 分钟以内。这里有个关键点Claude 在中文工业场景下对专业术语的理解比较稳200K 上下文可以塞下完整的设备手册和一批历史 Case。但直接调官方 API 在国内网络环境下经常遇到连通性问题所以我会把 Cursor 和 Agent 代码的 Base URL 统一改到 TaoToken用一个 Key 打通模型对话和代码补全两条链路。整个闭环的验证方式也很直接用模拟告警跑一遍看 Agent 能不能在 30 秒内输出根因、置信度、处置动作和风险评估。下面从环境准备开始一步步来。2. TaoToken 前置准备与 Cursor Base URL 配置在写 Agent 代码之前先把模型调用通道打通。TaoToken 提供统一的 API 入口兼容 Anthropic 的接口格式Cursor 和 Python 代码可以共用同一个 Key。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。第一步拿到 API Key。登录后进入控制台在 API Keys 页面创建一个新 Key。建议按用途分开建一个给 Cursor 用一个给 Agent 服务用方便后续做用量归因和权限回收。创建时把 Key 复制到安全的地方页面刷新后就不再完整显示了。第二步配置 Cursor 的 Base URL。打开 Cursor 设置找到 Models 面板在 OpenAI API Key 区域填入你的 TaoToken Key然后在 Override OpenAI Base URL 里填https://taotoken.net/api。注意这里不要带末尾斜杠也不要加/v1Cursor 会自己拼接路径。填完后点 Verify看到绿色对勾就说明连通了。如果你用的是 Claude Code 或者 Cline 这类工具配置逻辑类似但字段名不一样。Claude Code 需要在 settings.json 里配ANTHROPIC_BASE_URL和ANTHROPIC_API_KEYCline 的 MCP 配置里要写全三件套Base URL、Key、Model ID。Model ID 建议用claude-sonnet-4-20250514这个版本在长上下文和结构化输出上比较稳。第三步验证 Key 是否可用。在终端里跑一条 curl确认返回正常curl https://taotoken.net/api/v1/messages \ -H x-api-key: $TAOTOKEN_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 64, messages: [{role: user, content: 回复 OK}] }如果返回里能看到content字段和OK说明通道没问题。如果报 401先检查 Key 有没有复制完整、有没有多余空格如果报连接超时检查 Base URL 是不是写成了https://taotoken.net/api/带了尾斜杠。这里有个容易踩的坑Cursor 的 Base URL 和 Python SDK 的 Base URL 写法不同。Cursor 填https://taotoken.net/api而 Anthropic Python SDK 初始化时base_url参数要填https://taotoken.net/apiSDK 会自动补/v1/messages。如果你在代码里手动拼了/v1会变成/v1/v1/messages直接 404。环境变量建议统一管理在项目根目录建一个.env文件TAOTOKEN_API_KEYsk-你的Key TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在代码里用python-dotenv加载。这样 Cursor 和 Agent 服务可以共用同一份配置换 Key 的时候只改一个地方。3. Agent 核心代码与可复制配置片段这一节是重头戏我会把 Agent 的完整框架拆成三块告警数据结构、推理核心、知识库检索。每一块都给可复制的代码你直接贴到 Cursor 里就能跑。先建项目结构fab-agent/ ├── .env ├── requirements.txt ├── agent.py ├── kb.py └── mock_alarm.jsonrequirements.txt内容anthropic0.40.0 chromadb0.5.0 python-dotenv1.0.0安装命令pip install -r requirements.txt接下来是告警数据结构。FAB 现场的告警字段不统一我把它归一化成下面这个 dataclass你可以根据自己厂里的 FDC 字段做映射from dataclasses import dataclass, asdict dataclass class Alarm: alarm_id: str equipment: str fault_code: str params: dict severity: str # P1/P2/P3 timestamp: str def to_json(self): return asdict(self)推理核心用 Anthropic SDKBase URL 指向 TaoToken。这里的关键是 System Prompt 的设计我把它拆成「角色 步骤 输出格式」三段强制模型输出 JSON方便后续程序解析import os import json from anthropic import Anthropic from dotenv import load_dotenv from dataclasses import dataclass, asdict load_dotenv() dataclass class Alarm: alarm_id: str equipment: str fault_code: str params: dict severity: str timestamp: str def to_json(self): return asdict(self) class FABMaintenanceAgent: SYSTEM_PROMPT 你是半导体FAB智能运维助手负责分析设备告警并给出处置建议。 收到告警后严格按以下步骤分析 1. 根据 fault_code 匹配故障模式类别 2. 分析 params 中的异常参数判断根因方向 3. 结合知识库中的历史 Case给出最可能的根因 4. 输出处置动作清单和风险评估 必须输出纯 JSON不要加任何解释文字格式如下 { root_cause: 根因描述, confidence: 0.0-1.0, action: [步骤1, 步骤2], risk: 风险评估, need_engineer_confirm: true/false } def __init__(self): self.client Anthropic( api_keyos.getenv(TAOTOKEN_API_KEY), base_urlos.getenv(TAOTOKEN_BASE_URL, https://taotoken.net/api) ) self.model claude-sonnet-4-20250514 def analyze(self, alarm: Alarm, kb_context: str ) - dict: user_content json.dumps(alarm.to_json(), ensure_asciiFalse) if kb_context: user_content f\n\n历史相似Case\n{kb_context} response self.client.messages.create( modelself.model, max_tokens1024, systemself.SYSTEM_PROMPT, messages[{role: user, content: user_content}] ) text response.content[0].text.strip() # 去掉可能的 markdown 代码块包裹 if text.startswith(): text text.split(\n, 1)[1].rsplit(, 1)[0] return json.loads(text)知识库用 ChromaDB 做本地向量检索冷启动阶段先用历史 Case 填充。每条 Case 的文档格式统一成「故障码 根因 处置」检索时用故障码做 queryimport chromadb class FABKnowledgeBase: def __init__(self, path./fab_kb): self.client chromadb.PersistentClient(pathpath) self.collection self.client.get_or_create_collection( fault_cases, metadata{hnsw:space: cosine} ) def add_case(self, case_id, fault_code, root_cause, action): doc f故障码:{fault_code} 根因:{root_cause} 处置:{action} self.collection.upsert(ids[case_id], documents[doc]) def search(self, fault_code, top_k5): results self.collection.query( query_texts[f故障码:{fault_code}], n_resultstop_k ) docs results.get(documents, [[]])[0] return \n.join(docs) if docs else 把 Agent 和知识库串起来的主流程from agent import FABMaintenanceAgent, Alarm from kb import FABKnowledgeBase kb FABKnowledgeBase() # 冷启动先灌几条历史 Case kb.add_case(C001, ETCH-001, 等离子体熄灭, Abort Recipe, Hold批次, 检查匹配网络) kb.add_case(C002, ETCH-001, RF功率突降, 检查RF发生器, 确认气体流量) agent FABMaintenanceAgent() alarm Alarm( alarm_idALM-20260619-001, equipmentETCH-A01, fault_codeETCH-001, params{RF_Power: 42, DC_Bias: 3, Pressure: 8.2}, severityP1 ) context kb.search(alarm.fault_code) result agent.analyze(alarm, context) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码跑通后你会看到 Agent 输出结构化的根因、置信度、动作清单和风险。整个过程从告警输入到结果输出实测在 20 到 30 秒之间。4. 模拟告警验证自愈闭环代码写完了得用真实场景验证。我准备了一个模拟告警文件mock_alarm.json模拟 ETCH 腔体的 P1 故障{ alarm_id: ALM-20260619-001, equipment: ETCH-A01, fault_code: ETCH-001, params: { RF_Power: 42, DC_Bias: 3, Pressure: 8.2, Gas_Flow_Cl2: 0.0 }, severity: P1, timestamp: 2026-06-19T14:23:00 }注意我在 params 里加了Gas_Flow_Cl2: 0.0这是关键线索。正常刻蚀过程中氯气流量应该在 50 到 100 sccm归零说明气体供应断了这比单纯看 RF 功率下降更能定位根因。跑验证脚本import json from agent import FABMaintenanceAgent, Alarm from kb import FABKnowledgeBase with open(mock_alarm.json, r, encodingutf-8) as f: data json.load(f) alarm Alarm(**data) kb FABKnowledgeBase() context kb.search(alarm.fault_code) agent FABMaintenanceAgent() result agent.analyze(alarm, context) print( Agent 分析结果 ) print(json.dumps(result, ensure_asciiFalse, indent2)) # 自愈动作判定 if result.get(need_engineer_confirm): print(\n[需人工确认] 建议已推送工程师) else: print(\n[自动执行] 低风险动作已触发)预期输出类似{ root_cause: 氯气供应中断导致等离子体熄灭RF功率从设定值突降至42WDC偏压归零, confidence: 0.93, action: [ 立即 Abort Recipe, Hold 当前批次及前后各1批, 检查 Cl2 气路阀门和 MFC 状态, 确认气体供应恢复后执行腔体 Clean, 重跑验证片确认刻蚀速率正常 ], risk: 若不及时 Hold后续批次可能因等离子体不稳定导致刻蚀深度偏差预估影响 25-50 片晶圆, need_engineer_confirm: true }看到这个输出说明自愈闭环的第一环——诊断和建议生成——已经跑通了。接下来是动作执行环节。我在 Agent 里加了一个动作分发器把处置动作分成三类动作类型示例执行策略只读类记录日志、发送通知自动执行低风险类Hold 批次、Abort Recipe自动执行 通知高风险类修改 Recipe 参数、复位设备必须工程师确认动作分发器的核心逻辑AUTO_ACTIONS [记录日志, 发送通知, Hold批次, Abort Recipe] CONFIRM_ACTIONS [修改Recipe, 复位设备, 调整参数] def dispatch(action_list): auto [a for a in action_list if any(k in a for k in AUTO_ACTIONS)] confirm [a for a in action_list if any(k in a for k in CONFIRM_ACTIONS)] return {auto_execute: auto, need_confirm: confirm}实测下来从告警触发到自动 Hold 批次整个链路在 35 秒内完成。对比人工 30 分钟的响应时间这个提升是实打实的。但要注意自动执行的前提是动作清单经过充分验证不能一上来就放开所有权限。验证闭环的最后一步是反馈收集。每次工程师确认或修改了 Agent 的建议都把结果写回知识库def feedback(case_id, fault_code, final_root_cause, final_action): kb.add_case(case_id, fault_code, final_root_cause, final_action)这样知识库会越用越准Agent 的根因分析准确率也会逐步提升。5. 常见报错排查与配置对照接入过程中最容易卡在几个地方我把真实遇到的报错和排查路径整理出来你对照着看。报错一401 Unauthorizedanthropic.AuthenticationError: Error code: 401 - {error: {message: invalid api key}}原因通常是 Key 没加载进环境变量或者.env文件没被load_dotenv()读到。排查步骤先在终端echo $TAOTOKEN_API_KEY确认变量存在再检查.env文件是不是在项目根目录、有没有拼写错误最后确认代码里load_dotenv()在Anthropic()初始化之前调用。如果 Key 是从控制台复制的注意有没有带前后空格。报错二local proxy failed / connection timeouthttpx.ConnectError: [Errno 111] Connection refused这类报错一般是 Base URL 写错了。检查TAOTOKEN_BASE_URL是不是https://taotoken.net/api不要带/v1不要带尾斜杠。如果你在 Cursor 里也遇到同样报错检查 Override OpenAI Base URL 字段同样规则。另外确认本机没有配置会拦截请求的环境变量比如HTTP_PROXY之类有的话先 unset 掉。报错三reading choices / 返回格式解析失败json.decoder.JSONDecodeError: Expecting value: line 1 column 1这个报错说明模型返回的不是纯 JSON可能被 markdown 代码块包裹了或者模型多输出了解释文字。我在analyze方法里加了去包裹逻辑但如果模型仍然输出非 JSON可以在 System Prompt 里再强调一次「只输出 JSON不要任何其他文字」。另一个办法是用response.content[0].text先打印出来看实际返回内容定位是格式问题还是内容问题。报错四OAuth / Claude Code 认证失败如果你用 Claude Code 接入报 OAuth 相关错误说明认证方式配错了。Claude Code 走的是 API Key 模式需要在settings.json里配{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的Key, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }三件套缺一不可Base URL、Key、Model ID。少配一个就会报认证或模型找不到的错误。报错五ChromaDB 检索返回空results[documents][0] # IndexError知识库还没灌数据或者 collection 名字对不上。先确认add_case被调用过再检查get_or_create_collection的名字是不是和写入时一致。冷启动阶段建议先灌 50 条以上 Case检索效果才稳定。配置对照表方便你快速核对配置项CursorPython SDKClaude CodeBase URLhttps://taotoken.net/apihttps://taotoken.net/apihttps://taotoken.net/apiKey 字段OpenAI API Keyapi_key参数ANTHROPIC_API_KEYModel ID在 Models 面板选claude-sonnet-4-20250514ANTHROPIC_MODEL尾斜杠不加不加不加排障的核心思路就一条先确认通道通不通curl 测再确认 Key 对不对401 排查最后确认格式对不对JSON 解析。三步走完90% 的问题都能定位。6. 统一 Key 调用与后续接入建议Agent 跑通之后下一步是把 Cursor 的代码补全和 Agent 的推理调用统一到同一个 Key 上。这样做的好处有两个一是用量归因清晰能看出代码补全和 Agent 推理各占多少 token二是权限管理简单换 Key 或回收权限只改一个地方。具体操作在 TaoToken 控制台创建一个专用 Key命名为fab-agent-prod然后在 Cursor 的 Models 面板和 Agent 的.env文件里都填这个 Key。如果你有多个环境开发、测试、生产建议每个环境一个 Key通过环境变量区分。对于长期运行的 Agent 服务建议走 Coding Plan 而不是按量计费。Coding Plan 适合高频调用的场景成本更可控。你可以在 https://taotoken.net/api-keys 管理 Key在 https://taotoken.net/doc 查看接入文档模型对话调试用 https://taotoken.net/chat 长期编码和 Agent 场景用 https://taotoken.net/coding-plan 。后续如果要扩展成多 Agent 协作思路是把检测、诊断、处置、验证拆成四个独立 Agent每个 Agent 有自己的 System Prompt 和工具集通过消息队列串联。检测 Agent 负责接收 FDC/SPC 告警并归一化诊断 Agent 负责根因推理处置 Agent 负责动作分发验证 Agent 负责效果确认。这样每个环节都可以独立迭代和评估。知识库的冷启动是个持续过程。建议先用历史 Case 和设备手册灌 500 条以上然后每月 Review 一次 Agent 的根因分析准确率和工程师采纳率。准确率低于 80% 的时候优先补充对应故障码的 Case而不是急着调 Prompt。最后提醒一句自动处置的权限要渐进式放开。从只读模式开始先让 Agent 生成建议但不执行跑稳之后开放低风险动作Hold 批次、Abort Recipe高风险动作修改 Recipe、复位设备始终保留工程师确认环节。安全红线不能松这是 FAB 运维的底线。