JIRA与Trace分析自动化复盘：从Airbag到NVWA的Agent Harness优化

最近这段时间，我在 Codex 里反复做的一类事，不是单纯让 AI 写代码，而是把它丢进更真实的研发场景里：

  • 看 JIRA
  • 找 trace
  • 查日志
  • 理解业务链路
  • 判断根因
  • 必要时改代码
  • 再做 CR 和验证

这件事越做越能说明一个问题：JIRA 排障不是一个问答题，而是一条会分叉、会失败、需要回环的工程链路。

如果只是把 JIRA 描述贴给模型，让它“分析一下”，它大概率能写出一段看起来很像结论的话。但只要 trace 不完整、日志不直接、业务上下文缺失，结论就很容易变成“语言上很顺，证据上很虚”。

所以我这轮更关注的不是 prompt 写得多漂亮，而是 agent harness 到底该怎么搭，才能让 AI 从“会猜”变成“会查、会问、会验证”。

一、这段时间主要做了什么

从最近的 Codex 对话记录看，主线其实很清楚：

方向 代表动作 想解决的问题
JIRA 闭环 jira-one-click、jira-trace-fix-cr 从问题单进入分析、修复、审查、验证
Trace 分析 根据 traceId 查日志、追调用链 让根因判断有证据，而不是只靠描述猜
无 Trace JIRA 分析没有 trace 的问题单该怎么处理 避免 AI 在证据不足时硬给结论
Airbag 对比 研究 Airbag 如何从 JIRA 找 trace、定位仓库 学习更成熟的排障 harness 设计
NVWA 优化 测试 NVWA 的 JIRA 处理效果并调 prompt / SDK 调用 把流程从“能跑”推向“更可靠”

这里面最关键的不是某一次具体 JIRA，而是整个思路发生了变化。

以前更像是：

1
JIRA -> 让 AI 分析 -> 生成结论

现在更像是：

1
JIRA -> 线索抽取 -> trace / 日志 / 代码 / 知识检索 -> 追问补证据 -> 根因假设 -> 验证 -> 修复 / 收口

这两者差别很大。

前者是“回答系统”，后者才更接近“排障系统”。

二、为什么 JIRA 排障不能只靠一个大 Prompt

JIRA 的难点在于，它经常不是信息充分的输入。

一个真实问题单里可能只有：

  • 用户说某个按钮点了没反应
  • 一张截图
  • 一个时间点
  • 一个店铺 ID
  • 一个接口报错片段
  • 或者只有一句“线上有问题，帮看下”

这时候如果模型直接输出结论，本质上是在补脑。

更合理的方式应该是先判断证据是否足够：

情况 Agent 应该怎么做
有 traceId 先查 trace 和调用链，再看日志
没有 traceId 但有时间窗 根据应用、关键词、时间窗反查日志
只有业务描述 先定位可能应用和入口，再生成待确认问题
证据冲突 标注冲突点，不急着下结论
需要改代码 找到代码位置后再进入修复和 CR

我这次看 Airbag 和 NVWA 的差异，最大的感受就是：

好的 harness 不会催着模型马上回答，而是会逼它先把证据链补齐。

这也是为什么我对“没有 trace 的 JIRA 怎么分析”这个问题很敏感。无 trace 并不代表不能分析，但它一定意味着流程要换挡：从“顺 trace 找根因”切到“先构造线索，再逐步缩小范围”。

三、一个更靠谱的 JIRA Agent Loop

我现在更倾向于把 JIRA 排障拆成一个 loop，而不是一条直线。

这里最重要的是两个判断点：

  1. 证据是否足够
  2. 根因是否可验证

很多 AI 排障失败，不是因为模型不会分析，而是因为系统没有给它这两个刹车点。
它会在证据不足时继续往前写，在验证没完成时提前收口。

我现在觉得，一个面向真实研发的 JIRA Agent，至少要有下面几种能力：

  • 线索抽取能力：从问题单里抽出应用、接口、时间、店铺、错误码、traceId。
  • 工具编排能力：按需调用 JIRA、日志、Trace、RDS、代码搜索、Dubbo 等工具。
  • 证据分级能力：区分“日志事实”“代码事实”“业务推断”“待确认假设”。
  • 追问能力：信息不足时不要硬编结论，而是生成最小追问。
  • 回环能力：验证失败后回到前面补线索，而不是直接结束。

这就是我理解的 JIRA Agent Loop。

四、Airbag 给我的启发

Airbag 最值得学的地方，不是某个具体命令，而是它把 JIRA 排障拆成了更稳定的工程步骤。

我关注的几个点是：

  • 它如何从 JIRA 里拿到 trace 线索
  • 它如何判断关联仓库和应用
  • 它如何把问题单、日志、代码上下文串起来
  • 它如何避免只靠单轮 LLM 输出结论

这里面有一个特别重要的设计思想：

LLM 不应该独自承担所有判断，harness 要把可确定的工程动作先做掉。

比如：

  • 能用 API 拿到的 JIRA 字段，不要让模型猜。
  • 能用日志查询拿到的错误片段，不要让模型编。
  • 能用代码搜索定位的类和方法，不要只让模型按关键词幻想。
  • 能用测试集复跑的问题，不要只看一次输出好不好看。

这也是我后面看 NVWA 时最在意的地方：不是它能不能调用 Claude SDK，而是它有没有把“该查什么、怎么查、查不到怎么办、什么时候停下来问人”这些动作设计清楚。

五、NVWA 目前暴露的问题

这轮测试里，我对 NVWA 的直观感受是：它已经具备做 JIRA agent 的雏形，但问题也比较明显。

1. 结论容易来得太早

有些场景里，SDK 还没跑完，AI 就已经给出了“一句话总结”。这会带来一个很大的风险：

用户看到的是结论，但背后的 trace、业务知识和代码证据其实还没完成。

这类问题不是简单调高模型能力就能解决的，它需要 harness 在状态机上约束：

  • 分析未完成时不能输出最终结论
  • 工具调用失败时必须标记证据缺口
  • 关键链路未验证时只能输出阶段性判断

2. 无 trace 场景需要单独流程

没有 trace 的 JIRA 不能走同一套模板。

它应该先进入“问题补全模式”：

  • 识别业务对象
  • 推断可能应用
  • 按时间窗查日志
  • 找接口、任务、消息、配置等可能入口
  • 输出待确认字段

如果一开始就套“trace 分析模板”，最后很容易变成假装有证据。

3. Prompt 不能只写得更长

Prompt 优化当然有用，但我现在更倾向于把它拆成多段：

阶段 Prompt 应该负责什么
线索抽取 只抽字段，不下结论
检索计划 决定先查哪些系统
证据汇总 把事实和推断分开
根因判断 基于证据生成假设
最终输出 给出结论、证据、风险和下一步

如果所有事情都塞进一个大 prompt，模型会更难遵守阶段边界。

六、我沉淀下来的几个原则

这轮实验之后，我对 JIRA / Trace 类 agent 有几个更明确的判断。

1. 先做证据链，再做表达

很多 AI 输出看起来“像那么回事”，但真正有价值的是背后的证据链。

所以报告结构应该优先包含：

  • 结论
  • 证据
  • 推断
  • 未验证点
  • 下一步动作

而不是只给一个漂亮的摘要。

2. Harness 比模型更决定下限

模型决定上限，harness 决定下限。

一个好的 harness 会让模型少犯低级错：

  • 不会在没查日志时假装查过
  • 不会把猜测写成事实
  • 不会跳过代码定位
  • 不会忘记验证修复

这类稳定性，比单次回答惊艳更重要。

3. 排障 Agent 必须有“不会就问”的能力

真实工程里，信息不足是常态。

一个成熟 agent 不应该把“问用户补充信息”当成失败，而应该把它当成正常分支。关键是问得少、问得准、问得有依据。

比如不要泛泛地问“请提供更多信息”，而应该问：

  • 这个问题发生的准确时间窗口是什么？
  • 有没有店铺 ID、订单号或用户 ID？
  • 线上环境是 prod、pre 还是 QA？
  • 你看到的错误截图对应哪个操作入口？

这才是有用的追问。

4. 最终目标不是“会分析”，而是“能闭环”

我现在判断一个 JIRA agent 有没有价值，不看它能不能写一段很长的分析，而看它能不能闭环：

  1. 找到线索
  2. 查到证据
  3. 定位根因
  4. 判断是否要改
  5. 改完验证
  6. 输出可追溯结论

只完成前两步，最多算辅助排查。
能把后面也串起来，才更像真正的研发 Agent。

七、下一步我想怎么改

如果继续优化 NVWA / Airbag 这条线，我会优先做四件事。

1. 把 JIRA 集变成固定评测集

我已经开始把 6 月份的一批 JIRA 当作测试集。后面应该把它们按类型分层：

  • 有 trace 且根因明确
  • 无 trace 但有时间窗
  • 只有业务描述
  • 需要跨应用定位
  • 需要代码修复
  • 只需要业务解释

这样才能比较每次 prompt 和 harness 改动是不是真的变好。

2. 把输出拆成阶段产物

不要让 agent 一上来就生成最终答案。

更合理的是每个阶段都有结构化产物：

  • 线索卡
  • 检索计划
  • 证据表
  • 根因假设
  • 修复建议
  • 最终报告

这样人也更容易介入检查。

3. 给无 trace 流程单独建 skill

有 trace 和无 trace 是两类任务。
它们不应该共用同一个工作流。

无 trace JIRA 更像“问题侦查”，需要先从业务对象、时间窗、入口路径和应用归属里反推。

4. 把 CR 和验证接进同一条链路

排障不是找到根因就结束。

如果要改代码，后面必须继续接：

  • 影响面分析
  • 单元测试或集成测试
  • 代码审查
  • 复查日志
  • 输出修复说明

这也是我为什么一直把 jira-one-click、jira-trace-fix-cr、author-final-review 这些东西放在一起看。它们本质上不是多个孤立工具，而是一条研发闭环的不同节点。

结尾

这段时间做 JIRA 和 Trace 自动化，最大的收获不是“AI 能不能帮我看问题”，而是我更清楚地看到了 agent harness 的价值。

排障这类任务天然复杂：输入不完整、证据分散、路径会分叉、结论需要验证。
如果只靠一个大 prompt，AI 很容易变成一个会写总结的猜测器。
如果把 JIRA、Trace、日志、代码、业务知识、追问和 CR 串成 loop，它才有机会变成真正能参与研发闭环的助手。

所以我现在对这类系统的判断标准也更直接：

不要看它能不能说出一个像样的结论，要看它能不能把证据一步步查出来，并且在证据不足时知道停下来。

这才是 JIRA Agent 真正该追求的方向。