AI Agent 如何重构 App 稳定性治理流程

背景与痛点

App 稳定性治理面临多重挑战：问题类型多（Crash、ANR、卡顿等），排查链路长（日志收集→符号化→堆栈分析→代码定位→根因判断→修复验证），跨团队协作成本高（证据分散在不同系统），关键瓶颈依赖专家经验。传统手动流程效率低下，平均耗时数小时至数天。

统一稳定性分析 Agent 方案

核心思路是构建一个统一的 App 稳定性分析 Agent，串联“证据采集 → 推理分析 → 结论输出”全流程。设计上采用平台能力与场景能力解耦：底层实现通用分析底座（日志解析、地址符号化、代码提取、LLM 推理），上层按问题类型扩展场景化分析策略。

多壳架构（Multi-Shell）：Core 负责通用分析能力，通过 CLI / Daemon / IDE Plugin 提供一致化入口。当前优先打磨 CLI 入口，优势在于无环境依赖、脚本化集成、调试友好，并参照 Claude 交互方式提供终端向导。CLI 稳定后，Daemon 和 VSCode Plugin 基于 Core 能力构建。

为什么引入向量数据库：将单次推理升级为持续进化系统。每次分析沉淀结构化证据（崩溃特征、调用链、修复策略、反馈），新问题到来时先命中规则高置信路径，再通过向量相似检索复用历史经验。研发对建议的采纳/拒绝回写 Pattern 反馈，通过衰减与 GC 机制清理低质量模式，形成“数据飞轮”。

首个场景：App 闪退（Crash）分析

选择闪退场景的原因：价值高（直接影响用户体验），数据结构化（Apple crash report、Android tombstone 等格式规范）。

分析链路：

1. crash_log_parser（崩溃日志解析）→ 输入原始日志，输出结构化解析结果（线程/帧/信号）
2. add2line_resolver（地址符号化） → 输入解析结果 + 符号文件，输出函数名+文件+行号
3. code_content_provider（代码上下文提取） → 输入符号化结果 + 源码根目录，输出崩溃函数体+调用链代码+崩溃图谱
4. 可选）RAG 知识检索：精确匹配规则（SQLite）、语义相似检索 Pattern（ChromaDB）、元数据层（SQLite）
5. 可选）LLM 推理分析：综合所有上下文生成根因分析和修复建议（支持 Direct / LangChain / LangGraph 引擎）
6. 可选）自动修复源码：AI 生成修复方案，函数级精确替换，备份原始文件，Git 管理下可直接生成 Patch

Workflow 编排通过 BaseCrashAnalysisWorkflow.solve() 实现，每一步输入输出均为结构化 JSON，便于追踪和调试。

Demo：空指针崩溃自动分析全过程

项目内置多组崩溃样例，覆盖常见崩溃类型（空指针、悬空指针、数组越界等）及多线程数据竞争场景。以空指针崩溃为例：

崩溃代码：crash_nullptr() 函数中对空指针执行写操作 *p = 42，导致 SIGSEGV。

崩溃日志：显示 mangled name 和原始地址，无法直接定位源文件。

运行分析：通过 CLI 工具 sa-agent 一条命令进入交互引导，Agent 自动完成日志解析、地址符号化（0x100546ffc → my_lib.cpp:187）、代码上下文提取、RAG 知识检索、LLM 推理分析，并直接将修复代码写回源文件。修复代码增加了空指针检查与安全返回逻辑，原文件自动备份到 cli_reports/<timestamp>/original_sources/。如果源码由 Git 管理，可直接生成 Patch。

项目已发布 GitHub Release 预编译二进制（无需 Python 环境）和 PyPI 包（pip install stability-analysis-agent）。