自动分诊

Monte Carlo 自动化分诊 (Automated Triage)

此技能可帮助您设计、测试并部署一个用于 Monte Carlo 告警的自动化分诊代理。它不提供固定不变的工作流，而是提供构建块——一套 MCP 工具、每个分诊阶段的描述以及一个运行示例——以便您构建一个与团队实际响应告警方式相匹配的流程。

> Monte Carlo 工具路由（必选）： 请始终通过本插件内置的服务器调用 Monte Carlo MCP 工具，其全限定工具名称为 mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__<tool>（例如 mcp__plugin_mc-agent-toolkit_monte-carlo-mcp__get_alerts）。本技能中使用的简写工具名称（get_alerts, search, get_table, …）均指代该内置服务器。如果会话中还配置了单独的 monte-carlo-mcp 服务器，请不要路由到该服务器，因为它可能指向不同的端点或凭据。

在继续之前，请阅读参考文件：

• 分诊阶段与自定义：references/triage-stages.md（相对于本文件）

• 工作流运行示例：references/triage-example.md（相对于本文件）

---

何时激活此技能

当用户出现以下需求时激活：

• 想要对最近的 Monte Carlo 告警进行分诊或调查（交互式或自动化）

• 想要为 Monte Carlo 告警设置自动化分诊

• 要求运行代理分诊或调查最近的告警活动

• 想要了解有哪些可用的分诊工具以及如何使用它们

• 正在为其环境构建或优化分诊提示词 (prompt)

• 想要从手动审核告警转向自动化或半自动化分诊

何时不要激活此技能

当用户处于以下情况时不要激活：

• 正在调查一个特定的已知事件（请直接提供帮助）

• 正在创建或配置监控项（请使用 monitoring-advisor 技能）

• 在代码变更前运行影响分析（请使用 prevent 技能）

---

可用的 MCP 工具

所有工具均可通过 monte-carlo-mcp MCP 服务器调用。

| 工具 | 工具集 | 用途 |
| :--- | :--- | :--- |
| get_alerts | default | 获取指定时间窗口内的最近告警 |
| alert_assessment | default | 根据事件可能性和潜在影响对告警进行评分（分别评为 HIGH/MEDIUM/LOW） |
| run_troubleshooting_agent | default | 对单个告警运行 Monte Carlo 排障代理；默认异步运行——立即返回，并在结果可用时复用现有结果 |
| get_troubleshooting_agent_results | default | 通过 incident_id 轮询异步排障运行状态；返回状态 (not_found/running/success/failed) 以及完成后的结果 |
| update_alert | default | 更新告警状态或元数据 |
| default | 更新告警状态和/或通过设置严重程度来宣布事件 |
| set_alert_owner | default | 通过电子邮件为告警分配所有者 |
| create_or_update_alert_comment | default | 在告警上发布或更新分诊评论 |
| mark_event_as_normal | default | 将告警中的所有异常事件标记为正常，触发 ML 阈值重新校准，以防止对相同模式再次发出告警 |

---

如何进行自动化分诊 (Triage)

请阅读 references/triage-stages.md 以获取每个阶段的详细描述及其自定义方法。高层级流程如下：

1. 获取告警 — 决定对哪些告警进行分诊以及时间窗口范围。
2. 初步调查 — 使用 alert_assessment 根据事件可能性和潜在影响对每个告警进行评分。
3. 深度排障 — 对高信号告警运行 run_troubleshooting_agent 以获取根因分析。
4. 分类 — 利用排障输出对每个告警进行分类。
5. 执行操作 — 发布评论、更新状态、发送 Slack 消息、创建工单。

分诊流程并非固定不变。请阅读阶段参考文档以了解每一步的选项和权衡，然后设计一个符合您团队需求的工作流。

长期发展方向

大多数团队的演进路径大致相同，尽管速度和路径有所不同：

• 从建议开始。 手动运行，让 Agent 发布评论描述其发现以及将采取的操作 —— 不进行实际的状态更改或外部操作。利用此阶段调整工作流，直到输出结果与您团队的手动响应方式一致。

• 自动化，但仍处于建议模式。 一旦输出结果正确，将其设为定时运行。在验证其在真实流量中表现良好期间，保持在建议模式。

• 将建议替换为实际操作。 当您充满信心时，将评论建议替换为实际操作 —— 如状态更新、Slack 消息、工单创建。

不要强行推进这一进程 —— 这是一个方向，而非检查清单。具体路径取决于您的环境表现以及您在每一步之前希望建立多少信任。

---

激活流程

当此技能被激活时，请按顺序执行以下步骤。

第 1 步：检查 MCP 工具

验证 get_alerts、alert_assessment 和 run_troubleshooting_agent 是否可用。如果缺失任何工具，请检查 Monte Carlo MCP 服务器是否已配置并完成身份验证，然后停止。

第 2 步：确定意图

询问：

> “您是希望现在对某些告警进行分诊（我将使用分诊工具与您一起调查），还是设置/优化自动化分诊工作流（我将帮您设计一个可以定时运行的流程）？”

如果用户的请求已经明确了意图 —— 例如“分诊我今天的 freshness 告警”对比“帮我构建一个分诊工作流” —— 则跳过询问直接执行。

---

#### 分支 A：交互式分诊

用户希望现在查看特定告警。直接使用分诊工具进行调查并报告结果。不要将其定义为工作流构建。

1. 明确范围（询问时间窗口以及用户是否对特定领域、受众或告警类型感兴趣）。
2. 使用 get_alerts 获取告警（应用任何领域或...
2. 对（步骤 1 筛选出的）所有受众运行 alert_assessment（并行执行），并清晰地报告结果。
3. 对于任何“事件可能性”和“潜在影响”均为 MEDIUM 或更高级别的告警，提议运行 run_troubleshooting_agent 以进行更深入的根因分析。在运行前需等待确认。
4. 总结发现。除非用户提及，否则不要提示保存工作流文件或设置自动化。

在交互式分诊中编写工具： 在结论明确后，主动提供相关操作——如更新状态、声明严重程度、指派负责人、发布评论或将事件标记为正常（针对自然数据波动的告警）。执行前需询问。

---

#### 分支 B：自动化工作流

用户希望构建、测试或优化一个可以按计划运行的分诊工作流。

询问他们希望如何开始：

> “您想如何开始？
> - 使用内置示例 —— 从一个现成且可运行的分诊工作流开始，并在过程中进行调整。
> - 适配现有工作流 —— 指向您已有的文件，我们将对其进行审查并运行。
> - 从零开始构建 —— 描述您希望分诊实现的功能，我将帮您设计量身定制的工作流。”

使用内置示例：

1. 读取 references/triage-example.md（相对于本技能文件）。简要描述：它会获取过去 3 小时的告警，对每个告警进行评分，对高信号告警运行深度故障排除，并展示将采取的操作——首次运行时不执行写入。
2. 以推荐模式逐步运行（见步骤 3）。无需询问。

适配现有文件：

1. 读取文件并确认关键设置：时间窗口、过滤阈值以及是否包含模式选择步骤。
2. 总结其执行内容，然后询问：“是直接运行，还是逐阶段运行？以及使用推荐模式还是执行模式？”

从零开始构建：

1. 请用户描述需求：需要分诊哪些告警、希望采取什么操作、自动化程度如何，以及任何限制条件（例如特定的领域、团队或表）。
2. 参考 references/triage-stages.md 提出符合其目标的工作流结构。将其作为建议方案（而非最终文档）提交审核，并不断迭代直到用户满意。
3. 以推荐模式逐步运行（见步骤 3），以便他们在确定设计前验证每个阶段。预计在过程中会进行优化。

步骤 3：运行工作流（仅限分支 B）

严格按照文件中的指令执行工作流。不要随意即兴增加步骤或执行文件中未描述的操作。

操作保护 —— 工作流模式： 在构建或测试工作流时，无论工作流文档如何描述，绝不要调用写入工具（update_alert、set_alert_owner、create_or_update_alert_comment）。仅描述将要执行的操作。此保护机制旨在防止开发期间意外修改真实告警；仅在用户明确切换到生产运行的执行模式时才解除。

对于首次运行（全新开始）： 始终逐步运行 —— 在每个阶段完成后，总结其产出，根据观察结果主动建议替代方案或调整，并在继续前等待确认。

在每个阶段，参考 references/triage-stages.md 中的选项提供具体建议：

• 获取告警后 —— 建议过滤...

如果数据集看起来太宽或太窄，可进行以下调整：使用 NOT_ACKNOWLEDGED 跳过已分诊的告警；如果告警跨越多个团队，可使用域名/受众过滤器；如果需要更多样本，可适当延长初始测试的时间窗口。

• 评分后 —— 建议是否调整故障排查过滤器（例如：只要其中一个分数为 HIGH 即运行，而不仅仅是两者均为 MEDIUM+），或通过 user_instructions 调优 alert_assessment。

• 故障排查后 —— 如果 TSA 找到了明确的根因，建议是否声明事件严重级别或分配负责人。

• 执行操作后 —— 记录默认操作映射不适用的情况，例如：已确认的事件需要发送 Slack 消息或创建工单，而不仅仅是更新状态。

对于现有文件的运行： 使用用户在步骤 2 中选择的模式。

步骤 4：收尾

工作流完成后：

1. 询问：“需要我将此工作流的副本保存到您的项目中（例如 triage.md）以便您自定义吗？” 如果需要，将其写入用户选择的路径。

2. 然后根据刚才发生的情况以及最初的任务要求，提供后续步骤。例如：

> “接下来您想做什么？
> - 优化工作流 —— 梳理各个阶段并调整运行不畅的部分（过滤器、评分权重、故障排查阈值、操作映射）
> - 在不同的告警集上测试 —— 在不同的时间窗口或日期重新运行，观察其处理不同告警集的效果
> - 设置计划任务 —— 使用 /schedule 技能将其设置为定期自动运行
> - 其他 —— 请直接告诉我”

根据上下文调整选项 —— 如果运行结果包含大量低分且未进行故障排查的告警，则倾向于建议“优化”；如果结果看起来很稳健，则倾向于建议“计划任务”。

局限性

• 仅在任务与上游来源及本地项目上下文明确匹配时使用此技能。

• 在应用更改前，请验证命令、生成的代码、依赖项、凭据以及外部服务的行为。

• 不要将示例视为环境特定测试、安全审查或破坏性/高成本操作用户审批的替代方案。