kscz0000 Monte Carlo 自动化分类
本技能帮助你为 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 告警搭建自动化分类流程
- 用户要求运行智能体式分类，或排查最近的告警活动
- 用户希望了解有哪些可用的分类工具以及如何使用它们
- 用户正在为其环境编写或打磨分类提示词
- 用户希望从人工审查告警转向自动化或半自动化分类
何时不要启用本技能
在以下场景下不要启用：
- 用户在排查某个已知的具体事件（请直接协助排查）
- 正在创建或配置监控器（请使用 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 | 更新告警状态，并通过设置严重等级来声明事件 |
set_alert_owner |
default | 按邮箱为告警指派负责人 |
create_or_update_alert_comment |
default | 在告警上发布或更新一条分类备注 |
mark_event_as_normal |
default | 将告警中所有异常事件标记为正常，触发机器学习阈值重校准，以避免对同一模式反复告警 |
如何切入自动化分类
每个阶段的完整说明与定制方式，请阅读 references/triage-stages.md。高层流程如下：
- 拉取告警——确定要分类的告警范围及时间窗口
- 初步调查——使用
alert_assessment对每条告警按事件可能性和潜在影响打分 - 深度排查——对高信号告警运行
run_troubleshooting_agent以获得根因分析 - 分类——结合排查输出对每条告警进行归类
- 执行动作——发布备注、更新状态、推送 Slack 消息、创建工单
分类流程并非一成不变。请阅读各阶段参考文档，理解每一步的选项与取舍，再设计出契合团队需求的工作流。
长远演进方向
大多数团队大致会沿着同一弧线演进，尽管节奏与路径各有不同：
- 从推荐起步。 手动运行，让智能体发布备注，说明它发现了什么以及它打算做什么——不实际改动状态，也不触发任何外部动作。利用这一阶段持续打磨工作流，直到输出与你团队人工响应方式一致。
- 仍处于推荐模式，但实现自动化。 一旦输出符合预期，便把它放到定时任务中。在实时流量上验证其行为良好之前，继续保持推荐模式。
- 用动作替代推荐。 当你足够信任时，把备注里的推荐换成真实动作——状态更新、Slack 消息、工单创建。
不必强求严格遵循这一演进——它只是方向，而非清单。具体路径取决于你的环境表现，以及你希望在每一步之前积累多少信任。
激活流程
本技能被激活后，请按顺序执行以下流程。
第 1 步：检查 MCP 工具
确认 get_alerts、alert_assessment 和 run_troubleshooting_agent 可用。若有任何一个缺失，请检查 Monte Carlo MCP 服务器是否已配置并完成认证，然后停止。
第 2 步：判断意图
询问：
"你是希望现在就分类一些告警（我会用分类工具与你一起排查），还是搭建/打磨一条自动化分类工作流（我会帮你设计一个可按计划运行的流程）？"
如果用户的请求本身意图已经明确——例如"今天分类我的 freshness 告警"与"帮我搭建一个分类工作流"——则直接跳过提问继续推进。
分支 A：交互式分类
用户希望现在就查看具体的告警。直接使用分类工具进行排查并汇报结论，不要把它包装成"工作流搭建"。
- 明确范围（询问时间窗口，以及用户是否关注特定域、受众或告警类型）。
- 使用
get_alerts拉取告警（按步骤 1 中的域或受众进行过滤），对所有告警并行运行alert_assessment，并清晰汇报结果。 - 对事件可能性和潜在影响均为 MEDIUM 及以上的告警，主动提议运行
run_troubleshooting_agent以进行更深入的根因分析。运行前需等待用户确认。 - 汇总结论。除非用户主动提起，否则不要提示保存工作流文件或搭建自动化流程。
交互式分类中的写入工具： 在结论明确之后，主动提供相关操作建议——更新状态、声明严重等级、指派负责人、发布备注，或将事件标记为正常（针对属于自然数据波动的告警）。执行前需征得用户同意。
分支 B：自动化工作流
用户希望搭建、测试或打磨一个可按计划运行的分类工作流。
询问他们希望如何起步：
"你希望从哪种方式入手？
- 使用内置示例——从一个开箱即用、可直接运行的工作分类工作流起步，并在过程中按需调整。
- 改造现有工作流——把你已有的文件指给我，我会一并审阅并运行。
- 从零开始搭建——描述你希望分类流程完成什么，我会帮你量身设计一条工作流。"
使用内置示例：
- 阅读
references/triage-example.md（相对于本技能文件）。简要说明：它会拉取最近 3 小时内的告警，对每条进行打分，对高信号告警运行深度排查，并展示将执行哪些动作——首次运行不会执行任何写入操作。 - 按推荐模式逐步运行（见第 3 步）。无需再行询问。
改造现有文件：
- 读取该文件并确认关键设置：时间窗口、过滤阈值，以及是否包含模式选择步骤。
- 总结该工作流将要做的事，然后询问："是一口气跑完，还是逐步推进？另外选择推荐模式还是动作模式？"
从零搭建：
- 请用户描述其需求：要分类哪些告警、希望执行哪些动作、希望自动化到什么程度，以及任何约束（例如特定域、团队或表）。
- 参考
references/triage-stages.md提出契合其目标的工作流结构。以待讨论的方案而非已成稿的文档形式呈现，迭代至用户满意为止。 - 在推荐模式下逐步运行（见第 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进行微调。 - 排查之后——若故障排查智能体给出了清晰的根因，建议是否声明事件严重等级、指派负责人。
- 执行动作之后——指出默认动作映射可能不适用的情形，例如已确认的事件更适合发 Slack 消息或开单，而不是仅仅更新状态。
针对已有文件运行： 使用用户在第 2 步选定的模式。
第 4 步：收尾
工作流完成后：
询问："要不要把我们的工作流保存一份副本到项目里（例如
triage.md），方便你后续定制？" 如同意，则写入用户指定的路径。然后结合刚才发生的事情以及最初的任务，给出下一步建议。例如：
"接下来你想做什么？
- 打磨工作流——逐阶段审视并调整不顺的部分（过滤、打分权重、排查阈值、动作映射）
- 换一组告警测试——使用不同的时间窗口或日期重新运行，观察其对不同告警集合的处理表现
- 设置定时任务——使用
/schedule技能将其自动化为按固定节奏运行 - 其他——告诉我就行"
根据实际情境调整选项——若本次运行大量告警打分偏低且未触发排查，则倾向于打磨；若结果较为稳健，则倾向于安排定时。
局限性
- 仅当任务与上游来源及本地项目上下文明确匹配时才使用本技能。
- 在应用变更前，请核实命令、生成的代码、依赖、凭据以及外部服务的行为。
- 不要把示例当作环境专项测试、安全审查或破坏性/高成本操作的用户授权的替代品。