# TriagePilot：Investibook 诊断质量自循环系统

> Status: Draft  
> Date: 2026-05-13  
> Audience: Investibook leadership / project review  
> Scope: Diagnosis quality feedback loop, issue triage, low-risk autofix, regression readiness

## 1. Executive Summary

TriagePilot 是 Investibook 的诊断质量自循环系统。它的目标不是让 Agent 一次性“看起来会回答”，而是让真实用户反馈、诊断失败案例、产品体验问题能够持续进入同一个改进闭环。

这套机制把 Investibook 从一个诊断入口，推进到一个可以持续学习和改进的系统：

```text
用户反馈 / 真实 Workspace
        |
        v
问题复盘和分诊
        |
        v
结构化 Issue 和回归 Case
        |
        v
低风险问题自动修复，诊断问题进入 Skill Evolution
        |
        v
Evaluation 验证和下一轮质量提升
```

一句话定位：

> TriagePilot 是 Investibook 的诊断质量辅助驾驶系统：自动接住反馈、识别问题、修复低风险问题，并把复杂诊断问题交给人类做最终判断。

## 2. 为什么需要 TriagePilot

Investibook 面对的是持续变化的真实诊断场景。用户会不断提交 Jira alert、Clinic URL、workspace 对话和人工反馈，其中既包括诊断质量问题，也包括 UI、Bot、工具链、上下文管理等产品体验问题。

如果这些反馈只靠人工记忆和零散修复，会有三个明显风险：

| 风险 | 影响 |
|---|---|
| 同类诊断错误反复出现 | Agent 质量难以稳定提升，团队无法判断是否真的变好 |
| 用户反馈没有稳定进入修复队列 | 问题被看见但不可追踪，容易丢失优先级 |
| 简单 UX/platform 问题堆积 | 人工 review 和修复成本被低价值问题消耗 |

TriagePilot 的价值在于把这些反馈变成可度量、可追踪、可修复、可回归的工程资产。

## 3. 项目目标

TriagePilot 当前有四个核心目标：

| 目标 | 说明 | 价值 |
|---|---|---|
| 接住反馈 | 从 UI、Bot、GitHub issue、人工指定 workspace 中接收问题 | 避免用户反馈丢失 |
| 结构化问题 | 将问题沉淀为统一的 ISS 条目，包含类型、严重度、背景和修复方向 | 让问题可追踪、可排期、可去重 |
| 自动修复低风险问题 | 对 UX/platform 类问题自动生成 PR | 降低重复修复成本，提高响应速度 |
| 形成质量回归 | 将真实案例沉淀为 evaluation case 和 baseline | 避免同类问题反复出现 |
| 推动 Skill 进化 | 将非 UI 的诊断缺陷转成可 review、可验证的 skill 改进候选 | 让 FLOW / KNOWLEDGE / REASONING 问题也能进入改进闭环 |

这个项目的核心原则是：**不是自动修一切，而是自动处理确定性高的工作，把复杂决策留给人类。**

## 4. 当前进展和已有数据

截至 2026-05-13，TriagePilot 已经形成了可运行的闭环雏形。

| 指标 | 当前数据 | 说明 |
|---|---:|---|
| 真实诊断 Case | 17 个 | 来自 O11Y、TCOC、GitHub feedback 等真实场景 |
| 结构化 ISS 问题 | 73 个 | 跨 case 去重后的诊断质量和产品体验问题 |
| 已修复 ISS | 15 个 | 已通过 PR 或人工修复完成 |
| 修复中 ISS | 6 个 | 已有关联 PR 或正在处理 |
| Open ISS | 52 个 | 主要集中在诊断策略、工具数据源和复杂体验问题 |
| 详细修复计划 | 20 个 | 已写成自包含 plan，方便后续人工或 Agent 修复 |
| Formal evaluation case | 10 个 | 已进入正式 regression registry，可做 live eval |
| Active evaluation suite | 1 个 | `core-daily-demo`，用于日常诊断质量回归 |
| Promoted baseline run | 2 个 | 已有可对比的 repo baseline snapshot |
| 最新 baseline 结果 | 5 pass / 5 fail | 说明 evaluation 已能区分诊断能力缺口，而不只是记录 case |
| TriagePilot Board | 1 个 | 已有 admin 看板展示 ISS backlog、修复状态和 autofix 分类 |

按问题类型分布：

| 类型 | 数量 | 解读 |
|---|---:|---|
| UX | 24 | 用户体验问题是目前最容易自动化消化的收益面 |
| FLOW | 16 | 诊断流程缺口，通常需要 skill 或诊断策略调整 |
| REASONING | 12 | 推理质量问题，需要人工 review 和更强回归 |
| TOOLING | 10 | 外部数据源、API、工具链问题 |
| KNOWLEDGE | 6 | TiDB/TiKV 领域知识缺失 |
| TEMPLATE | 3 | 输出模板或提示格式问题 |
| CROSS-REF | 2 | 跨数据源验证不足 |

按严重度分布：

| 严重度 | 数量 |
|---|---:|
| P1-high | 31 |
| P2-medium | 40 |
| P3-low | 2 |

这组数据说明两件事：

1. Investibook 已经有足够多真实 case，可以开始做持续质量管理，而不是只做单点功能修复。
2. 当前剩余问题并不都适合 autofix。UX/platform 小问题自动化效果较好；诊断推理、数据源、流程策略类问题应该进入 skill-evolution 和 evaluation-gated review。
3. 新的 formal evaluation 已经能输出 pass/fail、failure code、critical evidence 缺口和 baseline 对比信号，可以作为非 UI 问题进入下一阶段自进化的判断依据。

## 5. 已经交付的能力

### 5.1 反馈到 Issue 的闭环

用户可以通过 Investibook UI、Bot 或 GitHub issue 反馈问题。TriagePilot 会将这些反馈转成结构化 ISS 条目，记录问题类型、严重度、出现在哪个 case、是否有修复计划。

这解决了过去“反馈看到了，但没有稳定进入工程队列”的问题。

### 5.2 真实 Case Library

已经沉淀 17 个真实诊断 case，每个 case 可以记录：

- 实际问题是什么。
- Agent 当时怎么诊断。
- 诊断哪里正确、哪里失败。
- 后续回归应该满足哪些条件。

这让诊断质量可以从“感觉变好”变成“有真实样本可回归”。

### 5.3 Autofix 低风险修复

Autofix 已经可以处理一批 UX/platform 类低风险问题，并自动创建 PR。代表性修复包括：

| Issue | PR | 修复内容 |
|---|---|---|
| ISS-0025 | #463 | Download 失败时增加可见反馈 |
| ISS-0026 | #286 | Diagnosis helpful feedback banner 支持关闭 |
| ISS-0028 | #286/#339 | 调整 Thinking / Running 状态展示 |
| ISS-0046 | #292 | SSE 断开后不再误标 failed |
| ISS-0047 | #292 | Not resolved feedback 自动创建 GitHub issue |
| ISS-0048 | #462 | tool-only response 不再误标 failed |
| ISS-0050 | #459 | Assistant message 支持一键复制 |
| ISS-0061 | #461 | Lark bot 支持 merge_forward 消息 |
| ISS-0062 | #458 | Slash command 入口和 discoverability 改进 |
| ISS-0066 | #460 | 中文输入法 Enter 不再误发送 |

这些修复说明：对边界清晰、影响面较小的产品体验问题，TriagePilot 已经可以显著减少人工修复成本。

### 5.4 Evolver 常驻运行

TriagePilot 已经接入 Evolver pod，具备日常自动运行能力：

| Job | 当前默认时间 | 目标 |
|---|---:|---|
| Daily Postmortem | 02:00 UTC | 扫描新反馈，生成结构化问题 |
| Daily Autofix | 06:00 UTC | 消费可自动修复问题，创建 PR |

同时，团队也可以在 GitHub issue 或 PR 中通过 `@evolver-bot` 触发交互式处理。

### 5.5 TriagePilot 看板

最新代码已经提供了 TriagePilot admin 看板，用于展示当前 ISS backlog 和修复进展。这个看板目前聚焦在 replayer registry 侧，已经能展示：

- Total ISS、Open backlog、In progress、Fixed、Fix rate。
- Autofixable open issue 数量。
- 按 type、severity、status、autofix category 过滤。
- issue 对应的 GitHub issue、PR、影响文件和 found-in case 数量。
- tolerant parser，用于在 registry 还没有完全结构化之前先支撑运营查看。

这说明 TriagePilot 已经有基础运营面，不再只是后台脚本。下一步不是“从零做看板”，而是把 evaluation 的 pass/fail、failure code、baseline diff 和 skill-evolution candidate 接入这个看板。

### 5.6 Formal Evaluation 基线

最新代码已经引入正式 evaluation registry 和 baseline 机制。它和 legacy replayer 的定位不同：不是回放旧 workspace，而是为每个 case 创建新的 workspace，运行 live diagnosis，再用结构化 judge 判断结果是否达标。

当前 evaluation 已经具备几类重要信号：

- 每个 case 的 pass / fail / invalid 结果。
- 失败原因，例如 critical evidence missing、evidence partial、diagnosis critical gate failed。
- 分 bucket 的质量判断，包括 workflow、evidence collection、critical evidence、evidence routing、diagnosis。
- baseline snapshot，用于比较后续 skill 或工具改动是否提升或退化。

这意味着 TriagePilot 不再只能依赖人工 postmortem 来判断诊断能力问题。对于非 UI 的 skill 相关问题，可以逐步走向：

```text
Evaluation fail
  -> 聚合 failure reason
  -> 生成 skill-evolution candidate
  -> 人工 review / Agent 提 PR
  -> 跑相关 evaluation case
  -> 通过后合并
```

## 6. 与 Hermes 自进化机制的关系

TriagePilot 的设计灵感来自 Hermes 的 self-evolution 思路：Agent 不应该只完成一次任务，而应该从历史任务中学习，沉淀经验，并通过可验证的方式改进自己。

但 TriagePilot 针对 Investibook 做了更工程化的取舍：

| 方向 | Hermes 更强调 | TriagePilot 更强调 |
|---|---|---|
| 经验沉淀 | Memory / Skill 自维护 | Case / Issue / PR / Regression 可审计闭环 |
| 自我改进 | Agent 自动 patch skill 或 prompt | UX 自动 PR，诊断 skill 走 evaluation-gated review |
| 通用性 | 面向通用 agent workflow | 面向 TiDB Cloud 诊断质量 |
| 风险控制 | Curator 和评估机制 | GitHub issue、PR review、回归 case |

因此，TriagePilot 不是追求“Agent 自己悄悄变聪明”，而是追求“每一次变聪明都可追踪、可 review、可回滚”。

## 7. 项目边界

TriagePilot 会主动避免过度自动化。

适合自动化的范围：

- UI/UX 小问题。
- Bot 输入解析和反馈链路问题。
- 低风险 platform API 修复。
- 明确、单点、可验证的产品体验改进。

不适合默认自动合并的范围：

- Agent reasoning 和 hallucination 问题。
- TiDB/TiKV 诊断策略重构。
- Clinic、Grafana、Loki、TCMS 等外部数据源能力建设。
- 会话生命周期、context compaction 等架构问题。
- 需要长链路回归验证的 diagnosis skill 改动。

这些复杂问题仍然由 TriagePilot 发现、记录和排期。区别在于：过去它们主要进入人工 backlog；下一阶段可以进入 skill-evolution 队列，由 evaluation 结果约束是否值得改、怎么改、改完是否更好。

## 8. 里程碑规划

### M0：闭环雏形完成（已完成）

目标：证明从真实反馈到结构化问题，再到低风险自动修复 PR 的路径可行。

已完成内容：

- 真实 case library 建立。
- ISS registry 建立。
- GitHub issue / PR 作为 review 面。
- Autofix 能处理 UX/platform 类问题。
- Evolver pod 支持 daily postmortem 和 daily autofix。
- TriagePilot admin 看板已能展示 ISS backlog、修复状态和 autofix 分类。

### M1：稳定运行和数据可信（下一阶段）

目标：让 TriagePilot 从“能跑”变成“稳定可信地每天跑”。

计划内容：

- 修正 ISS registry 的结构化格式，确保机器稳定解析。
- 给每个 open ISS 增加清晰分类：autofix、manual review、skill evolution、out of scope。
- 将 evaluation failure code 和 ISS 分类关联起来，区分 UX backlog、tooling backlog 和 skill-evolution backlog。
- 对 open Autofix PR 做质量 review，避免“看起来修了但边界不完整”。
- 将每日运行摘要接入现有看板，方便团队快速了解新增问题和新增 PR。

成功标准：

- 每日 postmortem/autofix 运行结果可追踪。
- ISS 状态和 PR 状态基本一致。
- Autofix PR 的人工 review 成本明显低于手写修复。

### M2：Evaluation 接入和质量趋势

目标：在已有 TriagePilot 看板基础上，让修复结果可验证，让质量趋势可观察。

计划内容：

- 将 regression 结果和 ISS 状态联动。
- 建立 case pass/fail 记录，跟踪同类问题是否减少。
- 将 evaluation 的 failure code、critical evidence 缺口、diagnosis gate 结果汇总到 TriagePilot 看板。
- 在现有看板上补充质量趋势：按 issue 类型、严重度、修复耗时、复发情况、evaluation verdict 展示。
- 对高频 diagnosis failure 建立专项 benchmark。

成功标准：

- 诊断质量问题不只被发现，还能证明是否被修好。
- 高层可以在一个看板里看到 backlog、修复进展和 evaluation 质量趋势，而不是只看到 issue 列表。
- 每次 skill 或工具改动后，都能看到它对 core evaluation suite 的影响。

### M3：诊断 Skill Evolution

目标：在保留人工 review 的前提下，逐步自动化 diagnosis skill 的改进路径。

计划内容：

- 对 FLOW / KNOWLEDGE / REASONING / TOOLING 类问题建立 skill-evolution 队列。
- 将 postmortem triage 和 evaluation failure 聚合成统一的 improvement candidate。
- 对 skill patch 强制跑相关 evaluation case，并和 baseline 比较。
- 将成功修复沉淀为可复用诊断规则。

成功标准：

- 高频诊断失败能逐步转化为稳定诊断能力。
- Skill 改动都有 case 依据和回归结果。
- Skill 改进 PR 不只描述“改了什么”，还要说明“修复了哪些 failure code，哪些 case 通过了验证”。

## 9. 当前风险和应对

| 风险 | 当前状态 | 应对方式 |
|---|---|---|
| ISS 数量增加但状态不够准 | 已出现部分 fixed/in_progress 状态需要人工对齐 | M1 增加状态同步和每日摘要 |
| Autofix 修复边界过宽 | 个别 PR 可能只覆盖部分场景 | 保持人工 review，不自动合并 |
| 复杂诊断问题无法自动修 | 这是预期边界 | 进入 skill-evolution 或人工专项队列 |
| 回归验证还不够自动化 | 目前已有 formal evaluation baseline 和基础看板，但 gate 不完整 | M2 建立 regression 状态联动 |
| 结构化数据仍偏文档化 | 当前 registry 对机器解析不够强 | M1 将 ISS registry 规范化 |
| Skill 改进可能过拟合单个 case | 当前已有 baseline，但 case 覆盖仍有限 | 要求 repeated failures 或强证据 case 才进入 eligible review |

## 10. 价值衡量和经验估算

下面数据不是已经完成的正式量测，而是基于当前 case 数量、ISS backlog、已有 Autofix PR 和日常 review 经验给出的初步估算。它的目的不是替代后续看板统计，而是帮助判断 TriagePilot 的投入产出量级。

基础假设：

- 每月进入 Investibook 的有效反馈 / 诊断质量样本约 20-30 个。
- 其中 30%-40% 是 UX/platform 或低风险 tooling 问题，适合 Autofix 或半自动修复。
- 其余 60%-70% 是 FLOW / KNOWLEDGE / REASONING / 外部数据源问题，适合进入 skill-evolution 或人工 review。
- 人工从零复盘一个 workspace、归因并写出可执行 issue，通常需要 30-60 分钟。
- 人工独立修一个小 UX/platform 问题，通常需要 0.5-1 天；Autofix 生成 PR 后，人工主要做 review 和边界确认。

经验估算收益：

| 方向 | 当前人工模式 | TriagePilot 目标模式 | 经验估算收益 |
|---|---|---|---|
| 反馈分诊 | 每个反馈 30-60 分钟人工复盘 | 自动生成 postmortem / ISS，人工只 review 关键判断 | 分诊人工时间降低 50%-70% |
| UX/platform 修复 | 每个小问题 0.5-1 天人工实现 | Autofix 生成 PR，人工 review | 修复 lead time 从天级降到小时级，人工实现时间降低 60%-80% |
| 诊断 skill 改进 | 依赖人工记忆和零散修 skill | evaluation failure 聚合后进入 skill-evolution 队列 | 高频问题更容易复用，预计 1-2 个迭代后核心 case pass rate 提升 10-20 个百分点 |
| Review 成本 | reviewer 需要重新理解背景 | issue、case、failure code、PR 关联在一起 | review 上下文收集时间降低 40%-60% |
| 质量风险 | 修复后是否退化主要靠人工判断 | skill/tool 改动后跑相关 evaluation case | 关键 regression 更早暴露，预计可减少 30%-50% 的重复失败 |
| Backlog 消化 | open issue 依赖人工主动清理 | Daily postmortem + autofix + 看板跟踪 | UX/platform backlog 可维持在低水位，复杂问题进入明确队列 |

如果按每月 25 个有效反馈估算：

| 项目 | 保守估算 |
|---|---:|
| 每月自动/半自动分诊节省 | 10-18 小时 |
| 每月 UX/platform 修复节省 | 3-6 人天 |
| 每月 review 上下文节省 | 6-10 小时 |
| 综合节省 | 约 1-2 人周 / 月 |

更重要的是，这部分收益会随着 case library 和 evaluation baseline 增长产生复利。早期节省主要来自 UX/platform 小问题；中长期价值来自高频诊断失败被沉淀成稳定 skill、工具和评估基线。

## 11. 对业务和团队的价值

TriagePilot 带来的收益不是单点效率提升，而是 Investibook 质量管理方式的改变。

| 价值 | 具体表现 |
|---|---|
| 用户反馈不丢失 | 每个有效反馈都能进入可追踪队列 |
| 诊断质量可度量 | 真实 case、formal evaluation baseline、ISS 状态共同形成质量账本 |
| 小问题快速消化 | UX/platform 类问题可自动生成 PR |
| 复杂问题更容易 review | plan 和 case 提供上下文，减少人工重新调查成本 |
| 非 UI 问题也能进入闭环 | Evaluation failure 可以转成 skill-evolution candidate |
| 长期能力复利 | 高频失败模式最终沉淀为 skill、工具或产品改进 |
| ROI 可量化 | 人工带宽、修复速度、evaluation pass rate、backlog 健康度都可以进入看板统计 |

## 12. 总结

TriagePilot 的核心价值不是“自动修一切”，而是让 Investibook 有一条持续变好的质量路径：

```text
反馈被接住
  -> 问题被结构化
  -> 简单问题被自动修复
  -> 诊断问题进入 Skill Evolution
  -> 改动被 Evaluation 验证
  -> 同类问题逐步减少
```

这套自循环能力值得作为 Investibook 的独立子项目继续投入。它连接了真实用户反馈、诊断质量、工程修复和人类 review，是 Investibook 从“诊断工具”走向“持续变好的诊断系统”的关键基础设施。