27 子项目、4 阶段分诊 —WeOps 技术团队首次系统披露 AI 工单范式升级历程

从同一个 bug 被排查两次开始，我们如何把 ITSM 和 LLM 缝在一起，把资深工程师的排查直觉，沉淀成团队共享的 AI 能力。

01 我们的起点：一个让人无奈的复盘

故事从一次工单复盘开始。

那是一个最普通不过的故障：一张工单从一线服务台开始，被转到二线工程师手里，二线翻了一上午日志，定性不清，又升到三线。三线研发拿着工单跳进多个仓库，最终在一段不起眼的索引缺失代码里揪出根因。

修复、上线、关单。整个流程花了大半天，团队里三个人参与。

复盘结束，我们翻历史工单，发现同一个根因，3 个月前另一个工程师已经排查过完整的一遍 —— 记录在他的本地笔记本里，没有进系统、没有进 wiki、没有被任何后续工程师看到。

那一刻我们意识到：问题不是这次排查得慢，而是每一次都得从零开始。

嘉为蓝鲸 WeOps 一体化智能运维平台（订阅制）是一个包含 27 + 子项目、跨多种语言的 Monorepo 服务集群。每一张工单背后都可能牵连多个子系统的调用链。在这种规模下，经验是否能沉淀，比单次排查的快慢重要得多。

02 把问题归因：三件事，一道墙

我们把日常排查里反复遇到的现象，归到三件事上：

1. 经验在人脑里，不在系统里。同一个索引缺失问题，3 个月前另一个工程师排查过；这次换了个人，又从零开始。
2. 阶段流转靠人判断，效率低。一线不知道该不该转二线，二线不确定要不要升三线，来来回回浪费时间。
3. AI 工具缺乏业务上下文。直接把工单扔给 ChatGPT，它不知道你的服务拓扑、不知道历史故障模式，给出的建议大多是泛泛而谈。

三件事，本质归到一点：AI 缺少领域记忆。

既缺通用方法论，也缺历史经验，更缺业务上下文。人员流动、Wiki 老化、AI 工具脱节，汇成同一道墙 —— 这就是我们要拆的墙。

03 第一个决策：不重写工单系统，做「薄集成层」

把 AI 接进工单流程，第一个要回答的问题是：要不要重新造一个工单系统？

我们的答案是不要。

嘉为蓝鲸 IT 服务流程・鲸脉（简称：嘉为蓝鲸 ITSM）本身已经能用，团队也熟，强行把工单系统重写一遍只是制造噪音。我们把新建系统的定位明确写在 README 里 ——

QAQ 是 ITSM 与 LLM 之间的薄集成层。

它不接管工单的创建、流转、SLA 这些 ITSM 已有的能力，只在已有流程上叠加一层 AI 会话工作台。嘉为蓝鲸 ITSM 通过两个集成点和 QAQ 对接：

・bk_token 登录态集成。复用蓝鲸的统一认证，用户从 ITSM 跳转过来无需重新登录，同时带上身份和组织信息。

・ITSM MCP Server。把 ITSM 的工单数据能力封装成 MCP 工具，让 Coding Agent 可以直接查询 / 创建 / 更新工单 AI 不再是 "收到一段文本"，而是能主动读写 ITSM 数据。

这两件事一打通，QAQ 就成了一层「贴」上去的 AI 能力，而不是一次伤筋动骨的系统替换。

04 第二个决策：Prompt 全局统一，不按阶段拆分

我们把工单分诊拆成 4 个阶段：

• L1 一线响应 — 快速分类、信息校验

• L2 二线处理 — 经验检索、假说验证

• L3 三线分析 — 源码定位、逻辑流构建

• L4 缺陷验证 — 复现、影响面、修复方案

每个阶段有明确的职责边界 —— 一线不做代码级判断，三线必须先评估证据充分性。

第二个要回答的问题是：这 4 个阶段，要不要用 4 套独立的 Prompt？

我们的答案也是不要。

四阶段分诊指令写在同一份 System Prompt 中，Agent 根据当前工单阶段自行决定执行对应 Stage 的流程。配置存在数据库里，Admin 可热更新，不需要重新发版。

为什么这么选？因为多阶段 Prompt 一旦各自维护，很容易出现「L2 和 L3 的指令互相打架」的情况。统一 Prompt+ 阶段标签，让 Agent 自己判断 "我现在在哪一阶段、该做什么"，也让我们调指令时不必担心阶段之间的耦合。

05 第三个决策：Memory 完全委托给执行器

QAQ 自己不做 token 计数、不做历史截断、不做摘要压缩 —— 这些全部委托给底层执行器（Claude Code SDK 或 OpenCode Server）处理。

QAQ 只负责两件事：首条消息注入工单上下文 + 后续消息透传。剩下的会话状态管理、上下文长度控制，都交给 SDK 自己解决。

这是薄集成层哲学的延续：能让别人做的事不自己做。

06 第四个决策：分诊结果结构化输出，驱动自动流转

我们要求 Agent 在每一次回复的末尾，输出一段固定结构的TRIAGE_ROUTE JSON—— 表示 "我建议这张工单接下来去哪里"。QAQ 后端自动提取这段 JSON，驱动工单的阶段流转。

L1 → L2 → L3 → L4 → 修复方案。

整条流水线，从一线到缺陷验证，全程自动路由。不再需要工程师拍脑袋决定 "该转下一线吗"。

这件事看似小，但带来的结构变化是巨大的：阶段流转从 "人主导" 变成了 "AI 主导、人监督"。原本卡在人判断里的时间，被释放出来。

07 AI 怎么真正介入：三个层级的真实场景

设计哲学讲完了，真正决定这套系统能不能用的，是 AI 在每个层级具体怎么帮工程师。

一线服务台的痛点很明确：用户提单只贴了报错截图，缺日志、缺版本号，一线没有判断依据，往常只能转出。

Agent 在 L1 阶段做的事是 —— 识别缺失项、给出明确收集指引：

「请提供 nginx error log + 最近 30min 的 app.log + 系统版本号，然后再补充到这条工单里。」

用户补全信息后，Agent 配合一线的 SOP 直接给出答案。很多工单就此在一线闭环，根本不用升二线。

2) L2 二线・环境 vs 代码

二线的痛点是定性。现象模糊，难以判断这是环境配置问题还是代码 bug，往往两边都试一遍。

Agent 在 L2 阶段被要求做出明确的二元判断：

• 这是代码问题，根因大概率在 commit abc123，建议升 L3。
• 这是环境问题，请检查 X 配置项是否被运维变更。

二线拿到的不是 "可能 / 也许"，而是带方向的判断。该升的精准升，该自己解决的不绕弯。

三线面对的是复杂调用链的体力活。27 个子项目分布在多个仓库里，根因藏在哪一环不清楚，靠人逐个仓翻代码定位耗时。

Agent 在 L3 阶段通过 MCP 工具自动跨仓追踪： 从工单入口→bk-cmdb 字段定义→MySQL 索引声明→全链路扫描可能的写入路径。

输出的不是 "请你查"，而是一条带可能性排序的根因路径。复杂问题的定位时间被显著压缩。以下是一张真实工单的处理截图 ——Agent 正在自动生成 ESB 排查命令，并逐步缩小根因范围：

08 真正的关键：把每次排查的经验，留下来

分诊流水线解决了怎么流转的问题，但没解决 经验丢失的问题。

如果 Agent 每次都从零开始推理，效率提升有限。所以我们做了 Agent Memory—— 一套结构化的排查记忆系统。

它做三件事：

• 自动沉淀。每次排查闭环后，自动从对话中提取一张 Case Card：症状、调用链路、根因、修复方案、故障模式标签。人审核后入库，避免错误记忆污染推理。

• 自动检索。 每个分诊阶段开始前，Agent 自动检索历史 Case，将相关经验注入当前上下文。遇到相同模块 / 相同代码路径的问题，直接复用历史分析作为起点。

• 自动关联。 新 Case 入库后与历史相似 Case 建链，让 Agent 做链式推理。同时定期从 Case 集群中提炼高频规则（比如当 bk-cmdb 批量查询 > 2s，优先检查 MySQL 索引），作为常驻知识。

核心原则我们想了很久，最后写成八个字：读全自动，写有门控。

检索和关联不增加工程师负担；入库和规则变更必须人审核 —— 因为错误记忆一旦污染，会影响所有后续推理。这是一个为长期主义做的取舍：我们宁愿沉淀慢一点，也不能让 Agent 学到错的东西。

形成正向飞轮

这一切串起来，就形成了一个我们一直在追的飞轮：

• 处理的工单越多→积累的 Case 越丰富
• →Agent 下次排查越快→更多工单一线 / 二线闭环
• →团队整体释放出更多时间。

落到一句话 ——排查得越多，下次排查得越少。The more you solve, the less you'll solve.

我们认为这是 AI 工具应该做到的事：不是替代工程师，而是让团队整体的能力曲线被时间往上拉。

09 团队的反思

把 QAQ+Memory 做出来之后，我们对几件事有了更明确的判断。

1) AI 工具的 "上下文"，比 "模型本身" 更稀缺。

模型已经很强，决定一个 AI 工具有没有用的，是它能拿到多少业务上下文。蓝鲸 ITSM 集成、MCP 工具、Case Card—— 这些都是为了让 Agent 拥有 "真正的领域记忆"，而不只是个聊天框。

2) "薄集成层" 是性价比最高的切入方式。

我们见过太多团队上来就要重写工单系统、要做大平台，最后两年都还在做基础能力。我们的经验是：先把 AI 这一层叠在已有系统上跑通，等价值被验证，再决定要不要做厚。

3) 经验沉淀的 ROI 远大于单次效率提升。

让一次排查快 30% 是好事，但让团队不再重复同一个排查，价值是指数级的。Memory 这条线，是我们后续会持续加大投入的方向

4) 人和 AI 的边界，要写进规则里。

读全自动、写有门控 —— 这八个字不是技术问题，是产品哲学。让人对 AI 留下来的东西负责，是这套系统能长期跑下去的前提。

10 最后

我们最初做这件事的初衷其实很朴素：让一个组织的排查智慧，永不流失。人会离开，AI 不会。资深工程师的排查直觉，不应该跟着某个人的离职信一起消失。它应该被记录、被检索、被复用 —— 成为整个组织的资产，让团队里任何一个工程师，都能站在所有前人的肩膀上排查。这件事我们才刚开始做。

——WeOps 产品研发部