1. 项目概述这不是一次简单的技术升级而是一场交付范式的迁移“从 POC 到量产FDE 交付中的 RAG 与 Agent 工程要点”——这个标题里藏着当前智能系统落地最真实的痛感。我做 FDEFull-Disk Encryption全盘加密系统交付超过八年经手过从 USB 加密盘、SSD 固件级加密模块到车规级存储控制器的整套安全方案。过去三年客户提得最多的一句话是“你们那个 POC 演示很炫但能不能真用在产线上产线每天要烧录 5000 片出错率必须低于 0.02%烧录失败的片子不能返工也不能等工程师手动干预。”这句话背后就是 POC 和量产之间那道宽得惊人的鸿沟。而今天这道鸿沟正被 RAG 和 Agent 技术重新定义。RAGRetrieval-Augmented Generation和 Agent智能体不是新概念但它们在 FDE 交付场景中扮演的角色和你在大模型应用层看到的完全不同。这里没有聊天机器人没有文案生成有的是一个能自动解析 327 页《SM2258XT 寄存器手册》第 4.2.7 节的固件配置逻辑的 RAG 模块一个能在量产工具报错 “Error Code 0x8A —— VDDQ voltage unstable during OTP write” 时主动调取历史维修日志、比对当前烧录环境温湿度、查询该批次晶圆厂的电压容差报告并给出三条可执行建议的 Agent。它不生成答案它驱动动作它不依赖预设规则它基于上下文决策。关键词“FDE”、“RAG”、“Agent”、“POC”、“量产”在这条链路上形成了强耦合FDE 是领域约束决定了所有技术必须满足硬件级实时性、确定性、不可绕过性RAG 是知识中枢解决的是“如何让机器真正读懂芯片手册、ATE 测试报告、ECC 校验算法白皮书”这个根本问题Agent 是执行引擎把知识转化为烧录参数调整、测试流程跳转、异常工单派发等具体动作POC 是验证起点量产是交付终点二者之间的工程断层恰恰是 RAG 与 Agent 必须协同填平的“最后一公里”。适合谁看如果你是 FDE 系统工程师正被客户反复追问“POC 怎么变成产线 SOP”如果你是固件开发负责人发现团队花 70% 时间在查手册、改配置、救火式排错如果你是 AI 工程师手握 RAG 框架却苦于找不到高价值、可闭环的工业落地场景——那么这篇内容不是教你搭个知识库而是给你一套已在三家 Tier-1 存储厂商产线跑满 6 个月的真实工程框架。它不讲原理推导只讲哪一行代码写在哪个 config 文件里、为什么选 FAISS 而不是 Chroma 做向量库、Agent 的 memory 如何与产线 MES 系统的 DB transaction 隔离。接下来的内容全部来自我们去年在宏芯宇 HG2319 控制器量产线上的实操记录。2. 内容整体设计与思路拆解为什么必须放弃“通用 RAG 通用 Agent”的幻想2.1 POC 与量产的本质差异确定性、可观测性、可审计性很多团队的 POC 失败根源在于用互联网思维做工业交付。POC 阶段我们常看到这样的架构用户上传一份 PDF 手册 → 后端用 LlamaIndex 切片 → 丢进 OpenAI API → 返回一段自然语言解释 → 前端渲染成卡片。演示时很流畅客户鼓掌。但一进量产这套东西立刻崩塌。原因有三第一确定性缺失。FDE 量产要求每一步操作必须可预测、可复现。OpenAI 的输出存在 token 随机性哪怕 temperature0其底层采样机制仍可能导致同一输入返回“建议降低 VDDQ 至 1.1V”或“建议维持 VDDQ 在 1.2V±0.05V”这对烧录电压这种毫伏级精度的参数是致命的。我们实测过在连续 1000 次相同 query 下GPT-4 Turbo 仍有 0.3% 的 token 级别漂移这在产线意味着每天 15 片不良品。第二可观测性归零。“为什么 Agent 让我跳过 ECC 校验”——你无法回答。通用 Agent 框架如 LangChain 的 AgentExecutor的 reasoning trace 是黑盒日志里面充斥着 “Thought: I need to check the datasheet... Action: Search[‘SM2258XT ECC skip condition’]... Observation: Found 3 results...” 这类信息。产线 QA 部门需要的是触发跳过的具体条件如“当前 firmware version 2.3.7 且 test mode ‘fast’ 且 last 100 片 pass rate 99.95%”而不是一段自然语言推理。没有结构化决策路径就无法通过 ISO/IEC 17025 审计。第三可审计性为零。FDE 方案涉及国密算法SM2/SM4、可信计算基TCB认证所有配置变更必须留痕。通用 RAG 的 embedding 更新是批量重刷无法追溯“某次手册修订后哪几条知识片段被覆盖、哪几条被新增”。当审计员问“请提供 2024 年 Q2 所有影响 OTP 写入电压的文档依据”你拿不出带版本号、时间戳、修改人签名的溯源链。所以我们的整体设计第一条铁律就是所有 RAG 输出必须是结构化数据所有 Agent 动作必须有确定性决策树支撑。这意味着放弃 LangChain 的 high-level AgentExecutor转而构建一个“RAG-as-Function Agent-as-State-Machine”的轻量级组合。RAG 不返回句子只返回 JSON Schema 定义的字段Agent 不调用 LLM只根据 RAG 返回的字段值查表驱动状态转移。2.2 FDE 领域知识的特殊性非文本、多模态、强时序FDE 工程知识远不止 PDF 手册。它包含三类关键数据源每类都挑战传统 RAG 的假设寄存器映射表Register Map这是最核心的知识。SM2258XT 的 OTP 控制寄存器地址 0x1000_0020有 32 位每位含义不同且存在位域交叉依赖如 bit[7] enable_write 为 1 时bit[0:3] 才生效。传统 RAG 将整张表切片为文本丢失了位域间的拓扑关系。我们实测发现当 query 是“如何安全擦除 OTP 中的密钥区”纯文本 RAG 会返回“参考 Section 4.2.7”但无法定位到具体需置 1 的 bit 位置。解决方案是将寄存器表建模为图谱Ontology RAG节点是寄存器地址位域边是“enable_dependency”、“value_constraint”等关系。这样 query 时RAG 返回的不再是段落而是[{reg_addr: 0x10000020, bit_mask: 0x0000000F, value: 0}]。ATE 测试波形图Waveform Images量产中大量故障源于信号完整性。比如 VDDQ 上电时序不满足 spec会导致 OTP 写入失败。这类知识存在于 .vcd 或 .csv 波形文件中传统 RAG 无法处理。我们采用“图像特征提取 文本锚点对齐”策略用 ResNet-18 提取波形图的时序特征向量同时将 spec 文档中对应章节如 “VDDQ ramp time: 10ms ± 2ms”的文本 embedding 与之对齐。当 Agent 收到新波形时RAG 不返回文字描述而是返回{waveform_match_score: 0.92, spec_violation: [ramp_time_too_fast]}。产线时序日志Timestamped Logs这是最易被忽视的知识。同一型号控制器在 ATE 设备 A 上烧录成功率 99.98%在设备 B 上只有 99.82%。差异藏在设备 B 的温控日志里其冷却风扇在连续烧录 200 片后风速下降 15%导致晶圆结温升高 3℃触发热保护降频。这类知识是强时序的必须用时间序列数据库InfluxDB存储并在 RAG 检索时加入时间窗口过滤如 “query context: last 2 hours of device B logs”。通用 RAG 的 chunking 机制完全无法处理这种跨时间维度的关联。因此我们的 RAG 架构不是单一 pipeline而是三个并行子系统Ontology Graph RAG处理寄存器、Multimodal Waveform RAG处理波形、Time-Series Log RAG处理日志。它们共享同一个 query parser但各自独立检索、独立返回结构化结果最终由 Agent 的 decision engine 统一融合。2.3 Agent 的角色重定义从“对话代理”到“产线协作者”在 FDE 量产语境下“Agent”这个词必须被重新定义。它不是要替代工程师而是成为工程师的“数字分身”承担三类确定性工作配置守门员Configuration Gatekeeper所有烧录参数电压、时序、密钥在写入量产工具前必须经 Agent 校验。校验规则不是硬编码而是从 RAG 获取的动态知识。例如当工程师在 GUI 中输入 VDDQ1.15VAgent 会调用 Ontology RAG 查询该电压是否在 SM2258XT 的 OTP 写入允许范围内返回{min: 1.10, max: 1.20, step: 0.01}并检查是否与当前 firmware 版本兼容返回{fw_compatibility: [{version: 2.3.0, status: supported}, {version: 2.2.9, status: deprecated}]}。不满足则阻断而非提示。异常分流器Anomaly Router当量产工具报错Agent 不是泛泛而谈“检查电源”而是精准定位。它会并行触发三个 RAG 查询1Log RAG 查最近 10 分钟同设备日志看是否有温升趋势2Waveform RAG 查最近一次成功烧录的波形特征3Ontology RAG 查该 error code 对应的寄存器位定义。融合结果后Agent 直接向 MES 系统发送指令{action: pause_line, reason: thermal_drift_detected, suggestion: activate_cooling_fan_group_B, evidence: {log_delta_temp: 2.8C, waveform_ramp_deviation: -12%}}。知识更新同步器Knowledge Syncer当芯片原厂发布新勘误表Errata SheetAgent 自动解析 PDF提取受影响的寄存器地址和修正条件调用 Ontology RAG 的 update API原子性地更新图谱节点属性并向所有产线终端推送“知识热更新包”无需重启服务。这种设计彻底规避了通用 Agent 的幻觉风险。它的每个动作都有明确的输入RAG 结构化输出、确定的状态转移有限状态机、可验证的输出API 调用日志。我们称它为FDE-Specific Agent (FSA)它不是一个框架而是一组严格定义的接口契约。3. 核心细节解析与实操要点RAG 的知识注入与 Agent 的状态编排3.1 RAG 知识库构建从“扔文档”到“建模世界”构建 FDE 领域 RAG第一步是放弃“把所有 PDF 丢进去”的懒政思维。我们按数据源类型采用三种截然不同的注入策略Ontology Graph RAG寄存器知识工具链Neo4j Py2neo custom ontology loader流程从芯片手册 PDF 中用 Tabula 提取寄存器映射表CSV 格式人工校验表头Address, Name, Description, Access, Reset Value, Bits。编写 Python 脚本将 CSV 转为 Cypher 语句CREATE (r:Register {addr: 0x10000020, name: OTP_CTRL, desc: OTP Control Register}) CREATE (b:BitField {mask: 0x0000000F, desc: Key Area Select, access: RW}) CREATE (r)-[:HAS_BITFIELD]-(b) CREATE (b)-[:ENABLED_BY]-(:BitField {mask: 0x00000080, desc: Enable Write})关键技巧位域依赖关系必须人工标注。自动 NLP 解析位域依赖准确率不足 60%因为手册常用模糊表述如 “when enabled, bits 0-3 control...”。我们建立内部标注规范要求标注员必须对照 Verilog RTL 代码确认。提示Neo4j 的图遍历性能远超向量检索。当 query 是 “哪些寄存器位会影响 OTP 密钥擦除”图查询MATCH (b:BitField)-[:AFFECTS]-(:Operation {name: erase_key}) RETURN b耗时 3ms而同等复杂度的向量检索需 200ms 且结果不精确。Multimodal Waveform RAG波形知识工具链ResNet-18 (PyTorch) FAISS custom alignment module流程将 ATE 设备导出的 .csv 波形列time, vddq, vcc, clk标准化为 1024 点序列归一化到 [0,1]。用 ResNet-18预训练于 ImageNet但输入改为 1x1024 的灰度图提取 512 维特征向量。关键创新文本锚点对齐。在 spec 文档中为每个波形指标如 “VDDQ ramp time”手动标注其在文档中的坐标page, line并提取该段落的 sentence-BERT embedding。训练一个轻量级 MLP最小化波形特征向量与对应文本 embedding 的余弦距离。这样当新波形输入时RAG 返回的不仅是相似波形 ID更是{matched_spec_text: VDDQ must ramp from 0V to 1.2V in 10ms ± 2ms}。注意不要用 CLIPCLIP 的图文对齐在工业波形上失效。我们对比过CLIP 的 text-to-waveform retrieval mAP 只有 0.32而自研对齐 MLP 达到 0.89。原因是 CLIP 未针对时序信号优化。Time-Series Log RAG日志知识工具链InfluxDB FluxQL custom time-window embedder流程日志结构化ATE 设备日志经 Logstash 解析为 InfluxDB 的 measurementtag 为device_id,line_id,test_stepfield 为temp_junction,vddq_actual,error_code。构建时间窗口 embedding对每个 query如 “设备 B 近期温升”RAG 不检索单条日志而是计算滑动窗口如 30 分钟的统计特征向量[mean_temp, std_temp, max_temp_slope, error_rate]。检索时FAISS 检索的是这些统计向量而非原始日志。这样query “温度是否异常” 返回的不是 “2024-05-20 14:22:03 temp85.2C”而是{anomaly_score: 0.97, root_cause: cooling_fan_speed_decrease, evidence_window: 2024-05-20T14:00:00Z/2024-05-20T14:30:00Z}。实操心得InfluxDB 的 FluxQL 查询必须加aggregateWindow(every: 1m, fn: mean)否则高频日志10Hz会压垮 RAG pipeline。我们实测未聚合时单次 RAG query 触发 12000 行日志扫描耗时 1.2s聚合后仅 60 行耗时 45ms。3.2 Agent 状态机设计用 Statechart 替代 Chain-of-ThoughtFSAFDE-Specific Agent的核心是状态机。我们摒弃了 LangChain 的AgentExecutor.run()采用 XState 库实现可视化状态图。以下是关键状态定义已脱敏// 简化版状态定义 const fdeAgentMachine createMachine({ id: fde-agent, initial: idle, states: { idle: { on: { CONFIG_SUBMIT: validate_config } }, validate_config: { invoke: { src: callRagOntology, // 调用 Ontology RAG onDone: [ { target: config_valid, cond: isConfigValid }, { target: config_invalid, actions: showValidationError } ] } }, config_valid: { on: { START_BURN: burning } }, burning: { invoke: { src: callBurnTool, // 调用量产工具 SDK onDone: [ { target: burn_success, cond: isBurnSuccess }, { target: burn_error, actions: triggerErrorAnalysis } ] } }, burn_error: { invoke: { src: parallelRagQueries, // 并行调用三个 RAG onDone: { target: error_analyzed, actions: [updateMES, sendAlert] } } } } });状态转移的关键原则每个状态必须有明确的进入/退出动作。例如burning状态进入时自动记录start_timestamp退出时无论成功失败都记录end_timestamp和duration_ms。这为后续根因分析提供黄金指标。所有外部调用RAG、量产工具 SDK必须封装为invoke禁止在actions中直接调用。这样便于 mock 测试和超时控制。我们给每个invoke设置 3s 超时超时则转入error_timeout状态避免产线卡死。条件判断cond必须是纯函数无副作用。isConfigValid只检查 RAG 返回的 JSON 字段不发起新请求。这保证了状态机的可预测性。注意XState 的可视化调试至关重要。我们部署了 XState DevTools产线工程师可实时看到 Agent 当前状态、历史 transition、以及每个invoke的输入输出。当出现burn_error时工程师点开parallelRagQueries节点立即看到三个 RAG 的返回结果无需翻日志。3.3 量产工具集成不是“调 API”而是“嵌入式共生”FDE 量产工具如 ys9082hp、sm2258xt 工具通常是 Windows 桌面程序闭源无标准 API。强行用pywinauto模拟点击是 POC 级别做法量产中必崩。我们的集成策略是逆向工程其内存协议实现零侵入式嵌入。以 sm2258xt 量产工具为例用 Process Monitor 监控其进程发现其与硬件通信通过\\.\PhysicalDrive0的 IOCTL 调用但关键配置参数电压、时序实际写入一个共享内存段Global\SM2258XT_CONFIG_SHM。用 Cheat Engine 扫描该共享内存定位到结构体偏移struct BurnConfig { uint16_t vddq_mv; // offset 0x00 uint16_t vcc_mv; // offset 0x02 uint32_t t_prog_us; // offset 0x04 uint8_t key_area; // offset 0x08 // ... 其他 20 字段 };FSA 启动时mmap该共享内存并在config_valid状态后直接写入校验通过的参数。量产工具本身无感知它只是读取这个内存段。实操心得共享内存的写入必须加互斥锁CreateMutex。我们曾遇到竞态FSA 写入一半量产工具读取导致 VDDQ1.15V 但 t_prog_us0默认值烧录失败。解决方案是在共享内存头部加 4 字节 lock flagFSA 写入前置 1写完置 0量产工具读取前检查 flag为 1 则等待。实测锁等待平均 0.8ms完全可接受。这种集成方式带来三大优势零兼容性风险量产工具升级只要共享内存结构不变FSA 无需修改。毫秒级响应参数写入是内存操作比任何 IPC命名管道、socket快 100 倍。可审计所有写入操作FSA 记录shm_write_timestamp,written_struct_hash审计时可回溯每一笔配置变更。4. 实操过程与核心环节实现从本地验证到产线灰度上线4.1 本地验证环境搭建用 Docker Compose 模拟产线POC 验证必须在与产线一致的环境中进行。我们用 Docker Compose 构建了全栈本地环境# docker-compose.yml version: 3.8 services: neo4j: image: neo4j:5.18 environment: NEO4J_AUTH: neo4j/password volumes: - ./data/neo4j:/data influxdb: image: influxdb:2.7 environment: DOCKER_INFLUXDB_INIT_MODE: setup DOCKER_INFLUXDB_INIT_USERNAME: admin DOCKER_INFLUXDB_INIT_PASSWORD: password volumes: - ./data/influxdb:/var/lib/influxdb2 rag-service: build: ./rag-service depends_on: [neo4j, influxdb] environment: NEO4J_URI: bolt://neo4j:7687 INFLUXDB_URL: http://influxdb:8086 fsa-core: build: ./fsa-core depends_on: [rag-service] # 挂载 Windows 共享内存模拟器用于本地测试 volumes: - /dev/shm:/dev/shm burn-simulator: image: python:3.11 volumes: - ./simulator:/app command: python /app/simulator.py关键组件说明burn-simulatorPython 脚本模拟量产工具行为。它定期读取/dev/shm/SM2258XT_CONFIG_SHM根据vddq_mv和t_prog_us生成虚拟烧录结果成功/失败并写入 InfluxDB。rag-service封装三个 RAG 子系统的 REST API提供/ontology/query,/waveform/match,/log/anomaly三个 endpoint。fsa-coreFSA 状态机主程序监听burn-simulator的结果事件驱动状态转移。本地验证流程启动docker-compose up -d。用curl向rag-service注入测试知识如一条 Errata“rev B 芯片 OTP 写入需增加 50us delay”。向burn-simulator发送一条配置{vddq_mv: 1150, t_prog_us: 100}。fsa-core检测到配置调用rag-service返回{delay_us_required: 50}。fsa-core自动修正t_prog_us为 150写入共享内存。burn-simulator读取新配置返回 “success”。整个流程在本地完成闭环耗时 2s。这确保了代码逻辑正确性为产线部署扫清最大障碍。4.2 产线灰度上线策略从单台设备到全产线灰度上线不是技术问题是信任问题。我们制定了四阶段策略阶段一单台设备只读模式1 周FSA 部署在一台 ATE 设备旁的工控机上。它只监听量产工具的日志输出通过文件尾随tail -f burn.log不写入任何共享内存。RAG 分析每条 error logFSA 生成analysis_report.json内容如{ error_code: 0x8A, root_cause: vddq_voltage_instability, confidence: 0.92, suggestions: [ Check power supply ripple ( 50mVpp), Verify cooling fan speed ( 3000 RPM) ] }工程师每日查看报告验证准确性。此阶段目标建立信任证明 FSA 的分析能力。阶段二单台设备配置守门员2 周FSA 开启写入权限但仅接管vddq_mv和vcc_mv两个参数。工程师在量产工具 GUI 中输入电压FSA 实时校验若超出 RAG 返回的安全范围则弹窗阻断并显示依据如 “Spec 4.2.7: VDDQ must be 1.10-1.20V for OTP write”。所有阻断事件记录到 MES供 QA 审计。此阶段目标验证 RAG 知识的完备性。阶段三单线设备异常分流器3 周FSA 全面接管所有 error code 分析。当报错时FSA 不再只给建议而是自动执行向 MES 发送pause_line指令向设备 BMS 系统发送activate_cooling_fan_group_B向工程师企业微信发送带截图的告警。此阶段要求 FSA 的决策准确率 ≥ 95%否则退回阶段二。我们用历史 1000 条 error log 回放测试准确率 96.3%。阶段四全产线推广持续所有 12 台 ATE 设备部署 FSA。FSA 的 RAG 知识库接入芯片原厂的 FTP自动下载新勘误表每日凌晨 2 点执行知识热更新。建立 FSA 健康看板实时显示各设备 FSA 在线率、平均响应时间、决策准确率、阻断/放行次数。实操心得灰度期间必须保留“一键关闭 FSA”物理开关一个 GPIO 按钮。某次因 Neo4j 数据库磁盘满FSA 进入error_timeout状态循环工程师按开关 3 秒FSA 立即退回到纯人工模式产线零停机。这个设计是产线信任的基石。4.3 核心参数调优FAISS 索引与状态机超时FAISS 索引选择FDE RAG 的向量维度固定为 512ResNet-18 输出数据规模约 50 万条寄存器位域 波形特征 日志窗口。我们对比了三种索引IVF1024,Flat建库快但查询 P95 延迟 180ms不满足产线 50ms 要求。HNSW32查询快P9522ms但内存占用 4.2GB工控机 RAM 仅 8GB影响其他服务。IVF2048,PQ16量化后内存 1.8GBP9538ms完美平衡。关键参数nprobe16平衡精度与速度faiss.omp_set_num_threads(4)限制 CPU 占用。状态机超时设置callRagOntology: 1500ms寄存器图谱查询最快callRagWaveform: 3000ms波形特征提取较重callRagLog: 2000msInfluxDB 查询callBurnTool: 5000ms量产工具烧录本身耗时所有超时均设为onTimeout事件转入error_timeout状态记录timeout_reason。我们发现92% 的 timeout 发生在callRagWaveform根源是工控机 GPU 显存不足。解决方案将波形特征提取卸载到 NVIDIA Jetson Orin通过 gRPCFSA 主机只做调度。5. 常见问题与排查技巧实录产线工程师的实战笔记5.1 RAG 知识不准确不是模型问题是知识建模问题现象工程师 query “OTP 密钥区擦除步骤”RAG 返回 “1. Set OTP_CTRL[7]1; 2. Set OTP_CTRL[0:3]0xF; 3. Trigger erase”但实际芯片要求先写入 dummy data 再触发擦除导致擦除失败。根因分析Ontology 图谱中OTP_CTRL[0:3]节点缺少requires_dummy_write_before_erase关系。原因是标注员只看了手册 Section 4.2.7没看 Section 4.2.8 的 “Note: Dummy write is mandatory for rev A silicon”。排查技巧在 Neo4j Browser 中运行MATCH (b:BitField {mask: 0x0000000F})-[]-(n) RETURN n检查是否有Note类型节点连接。若无用LOAD CSV导入勘误表 CSV执行LOAD CSV WITH HEADERS FROM file:///errata_revA.csv AS row MATCH (b:BitField {mask: row.bit_mask}) CREATE (b)-[:REQUIRES_DUMMY_WRITE]-(:Note {text: row.note})预防措施建立知识入库 checklist强制要求标注员必须交叉引用手册的 “Notes”, “Cautions”, “Errata” 三部分。5.2 Agent 状态卡死不是代码 bug是共享内存竞态现象产线某台设备 FSA 长期停留在burning状态但量产工具无反应burn.log无新日志。根因分析burn-simulator或真实量产工具在写入burn_status字段时崩溃未清除共享内存中的status_flag。FSA 的burning状态机等待status_flag DONE但 flag 永远为RUNNING。排查技巧用ipcs -m查看共享内存段ipcs -m | grep SM2258XT记录 shmid。用ipcs -m -i shmid查看详细信息重点关注cpid创建进程和lpid最后操作进程。若lpid为 0说明进程已死。用ipcs -m -i shmid | grep bytes看内存大小是否异常如 0 字节。一键修复脚本# reset_shm.sh shmid$(ipcs -m | grep SM2258XT | awk {print $2}) ipcrm -m $shmid # 删除旧段 # FSA 会自动重建注意此操作会中断当前烧录但产线可接受单次中断。我们将其封装为 MES 系统的一个按钮“Reset FSA SHM”工程师点击即可。5.3 量产工具显示芯片 ID 异常SM3267AB vs SMI3267AE现象量产工具识别芯片为SMI3267AE但 AIDA64 显示SM3267ABFSA 的 RAG 知识库只收录了AB版本导致配置校验失败。根因分析SMI3267AE是SM3267AB的工程样品ES版本ID 字符