本方案旨在利用 LangChain 生态系统，构建一个专门针对 Ascend 310B 等嵌入式系统复杂故障的自动化诊断框架。核心目标是解决海量日志处理慢、大模型对底层硬件知识匮乏以及诊断逻辑不严谨的问题。
1. 核心架构设计
Sentinel-Embedded 采用"感知-检索-辩论"三层架构：
A. 感知层 (Perception - LazyUnpacker)
针对嵌入式系统产生的数 GB 压缩日志包（如串口日志、Kernel Core Log），不再进行全量解压。
- 时间锚定：通过正则流式探测日志包的时间边界。
- 按需解压：仅解压故障时刻相关的日志片段，极大地降低磁盘 I/O 和内存占用。
B. 检索层 (Retrieval - SDK RAG)
通过build_vector_db.py构建的 Chroma 向量库，为 Agent 提供源码级上下文。
- 源码切片：使用
RecursiveCharacterTextSplitter保持 C++ 语法结构。 - 语义搜索：当日志中出现错误码（如
error_code: 0x123）或函数名时，自动检索 SDK 源码中的定义、注释及相关驱动逻辑。
C. 认知层 (Cognition - LangGraph Multi-Agent)
基于 LangGraph 构建"Argue-Verify" (辩论-验证)工作流：
- 诊断代理 (Primary Diagnostic Agent)：分析日志，利用 RAG 检索结果提出初步故障原因（Root Cause）。
- 审计代理 (Audit & Critique Agent)：专门负责“找茬”，质疑诊断代理的结论，要求其提供更多证据（如特定寄存器值、时序对齐证据）。
- 报告代理 (Report Generator)：汇聚多轮辩论结果，生成最终的故障分析报告。
2. 技术栈详细设计
| 模块 | 技术实现 | 关键价值 |
|---|---|---|
| 工作流编排 | LangGraph (StateGraph) | 实现复杂的循环逻辑和 Agent 间的交互冲突。 |
| 向量库 | ChromaDB | 本地化部署，确保红网环境下的数据安全性。 |
| 切分算法 | RecursiveCharacterTextSplitter(cpp) | 保证代码逻辑片段的完整性。 |
| Embedding | ZhipuAI API/BGE-Small (Local) | 灵活切换，兼顾在线性能和离线安全。 |
| LLM | GLM-4/GLM-5.1 | 强大的中文理解能力和代码分析能力。 |
3. 关键节点流程 (preprocess_node)
- 提取时间戳：从用户描述或串口日志首行提取故障时刻 $T$。
- 定位日志包：
LazyUnpacker寻找覆盖时刻 $T$ 的最小日志集合。 - 切片提取：提取 $T \pm 5s$ 范围内的串口和内核日志。
- 上下文注入：从 Chroma 库检索与日志中相关模块对应的 SDK 源码。
- 初始化状态：将上述信息填充进
AgentState，触发后续 Agent 辩论。
