14 - Bug 复现 Agent¶

项目背景与目标¶

某 SaaS 平台每周收到约 200 个线上 Bug 报告，复现与定位是耗时大头：环境差异导致难以复现，日志分散在多个服务，开发人员平均花 4 小时才能复现并定位根因。企业希望构建 Bug 复现 Agent，自动完成「日志分析 → 复现步骤推断 → 环境搭建 → 复现执行 → 根因定位」，将平均复现定位时间从 4 小时降至 30 分钟，并输出可交接的复现报告。

核心目标： 1. 自动分析日志与监控，推断复现路径 2. 在隔离环境自动搭建与复现 3. 根因定位到代码文件/函数级 4. 输出结构化复现报告，平均时长 < 30 分钟

预期价值：缩短 Bug 修复周期、降低排查门槛、沉淀 Bug 知识库、提升线上稳定性。

需求分析¶

用户角色与场景 - 开发者：接收 Agent 输出的复现报告与根因，快速修复 - SRE：处理线上故障，需快速定位 - QA：验证修复、补充回归用例

功能需求列表 - 多源日志采集与关联（应用日志、链路 trace、监控指标） - 异常时间线还原（请求路径 + 服务调用顺序） - 复现步骤推断（输入、前置条件、触发序列） - 隔离环境自动搭建（容器化、数据快照） - 自动复现执行与结果捕获 - 根因定位（代码行、依赖、数据、配置） - 结构化复现报告（步骤、日志、根因、建议） - Bug 知识库沉淀与相似案例检索

非功能需求 - 性能：单 Bug 复现 < 30 分钟 - 安全：复现环境隔离，数据脱敏 - 可用性：99% - 准确性：根因定位准确率 ≥ 70%

约束条件：生产数据需脱敏后用于复现；部分 Bug 依赖特定数据状态难以复现。

技术选型说明¶

层次	技术选择	选型理由
Agent 框架	LangGraph	多步骤编排与状态管理
LLM	Qwen2.5-72B + Coder	日志理解与代码定位
日志检索	ELK + Jaeger trace	多源关联
环境编排	Docker Compose + K8s Job	隔离复现环境
代码分析	Tree-sitter AST	根因定位
部署	K8s 私有化	隔离与安全

架构设计¶

flowchart TD
    BUG[Bug 报告] --> AGENT[复现 Agent]
    AGENT --> LOG[日志采集]
    LOG --> ELK[(ELK)]
    LOG --> TRC[(Jaeger trace)]
    AGENT --> TL[时间线还原]
    TL --> INFER[复现步骤推断 LLM]
    INFER --> ENV[环境搭建 Docker]
    ENV --> REPRO[复现执行]
    REPRO --> CAP[结果捕获]
    CAP --> ROOT[根因定位]
    ROOT --> CODE[代码 AST 分析]
    ROOT --> DATA[数据/配置分析]
    ROOT --> RPT[复现报告]
    RPT --> KB[(Bug 知识库)]

核心是「日志关联 → 步骤推断 → 环境复现 → 根因定位」四段式。Agent 从多源日志还原异常时间线，LLM 推断复现步骤，在隔离容器中自动执行复现，结合代码 AST 与数据/配置分析定位根因，输出报告并入库。

关键模块实现思路¶

模块1：多源日志关联与时间线还原¶

思路：通过 traceId 串联跨服务日志与 trace；按时间排序还原请求路径与调用链；标注异常点（错误日志、超时、指标突变）。
关键点：trace 是跨服务关联的钥匙；无 trace 时用时间窗口 + 服务依赖图近似关联。

模块2：复现步骤推断¶

思路：LLM 基于时间线、用户输入、前置条件（如「订单已支付」）推断复现步骤序列；输出可执行的步骤清单（API 调用序列或操作序列）。

示意：

def infer_repro(timeline, context):
    prompt = f"异常时间线:{timeline};用户操作:{context};推断复现步骤"
    steps = llm.parse(prompt)  # [{step, input, expected, actual}]
    return steps

模块3：隔离环境复现¶

思路：根据服务依赖图自动生成 Docker Compose 编排；拉取相关服务镜像；注入脱敏后的数据快照（必要数据）；按推断步骤执行 API 调用并捕获异常。
关键点：数据必须脱敏；环境用完即销毁；复现失败时尝试多组参数变异。

模块4：根因定位¶

思路：复现成功后，结合异常栈用 AST 定位到代码文件/函数；分析依赖（第三方库版本）、数据（脏数据）、配置（错误配置）；LLM 综合给出根因假设与证据链。
关键点：根因需有证据支撑（日志/代码/数据），避免猜测；多假设时列优先级。

核心流程详解¶

流程1：接口 500 Bug 复现¶

Bug 报告：下单接口偶发 500
Agent 采集日志，trace 串联发现调用库存服务超时
推断复现步骤：登录→加购→库存为 0 时下单
隔离环境复现，捕获 NPE 异常栈
AST 定位到库存服务 line 82 空指针
报告：根因为库存 0 时未判空，建议修复

流程2：难以复现 Bug 降级¶

复现多次失败（依赖特定数据状态）
Agent 降级为「静态分析模式」：基于日志与代码分析给出最可能根因假设
报告标注「未复现，根因为推断」，附证据链供开发参考

部署与优化建议¶

部署架构：复现环境用独立 K8s namespace，资源隔离；日志检索复用现有 ELK。
性能优化：日志采集并行；复现环境镜像预热缓存。
成本控制：复现失败次数限制；静态分析优先于环境复现。

常见问题与解决方案¶

环境差异致无法复现 → 数据快照 + 配置版本对齐；无法复现降级静态分析。
数据脱敏成本高 → 自动脱敏规则 + 敏感字段替换为合成数据。
根因误判 → 多假设 + 证据链；开发反馈回流优化。

扩展方向¶

自动修复建议：基于根因生成修复 patch。
回归用例生成：复现步骤自动转为回归测试。
预测性发现：分析日志趋势提前预警潜在 Bug。