Mutil Agent — Development skill for Claude Code

Mutil-Agent

凌晨三点，Prometheus 的一条告警砸进了值班群。人还没醒，系统已经开工了： 读懂告警 → 挑一个处置手册 → 调工具取证 → 交叉验证 → 交出一份能复盘的诊断报告。

这个仓库，就是把上面这套流程完整跑通的多智能体 AIOps 诊断工作台。

    

---

这是什么

一句话版本：**把 OnCall / SRE 的故障处置经验，做成一个能被 LLM Agent 执行的工作台。**

它的输入有两种：

• 一句人话，比如"我电脑很卡，帮我查查 CPU 和内存"；
• 一条 Alertmanager Webhook 告警，比如 Redis 内存使用率 98%。

它的输出是一份**可追溯**的 Markdown 诊断报告——报告里的每个结论，背后都有 ToolCall 和 Evidence 记录支撑，而不是模型的一句"我觉得"。

这是一个阶段性学习项目，覆盖 Agent Workflow、RAG、Skills 路由与渐进式披露、 多 Agent 协作等主题，适合学习和入门参考，**不建议直接用于生产环境**。

诊断流程

以一条 Redis 内存告警为例，看它在系统里会经历什么：

1. 接入：告警或用户描述进入 FastAPI，先落库（Postgres），再进队（Redis Streams）。请求进程不做重活，API 永远秒回。
2. 排队：后台 Worker 从队列里领任务，分发限流、失败重试、死信隔离都有明确分工。
3. 选路：Skill Router 判断这是"资源类"还是"网络类"还是"容器类"问题—— 路由阶段只看得到各 Skill 的名字和用途，命中之后才加载完整 Playbook 和工具约束（渐进式披露，省上下文）。
4. 取证：fast 模式走规划-执行-重规划循环；deep 模式则把任务拆给 Metric / Log / Infra / Runbook 四个专业 Agent 并行取证，它们互不窥探 中间推理，只回传压缩后的 Evidence。
5. 裁决：证据汇总去重、交叉验证，产出根因分析和处置建议。
6. 归档：事件、任务、AgentRun、ToolCall、Evidence、Approval、Report 全部留在 Postgres 里，随时可回放复盘。

`fast` 和 `deep` 怎么选？

	fast	deep
一句话	单兵快查	团队会诊
链路	Planner → Executor → Replanner	证据计划 → 专业 Agent 并行 → RCA
适合	单类故障、即时 SSE 流式	复杂事件、多源证据交叉验证

关键设计取舍

• API 不干活。高并发诊断一律持久化 + 入队，请求进程只负责接活。
• Postgres 是唯一事实源。Redis 只管队列和协调，重启丢了也不心疼。
• 模型的话不是证据。任务是否完成，看可观测状态和落库证据，不看模型自述。
• 工具有等级。只读工具可以运行时放行，写操作、通知类、高风险操作必须走 权限和审批；Docker MCP 里甚至有一个受控重启，默认就是阻断的。
• 副作用要可恢复。能重试的操作要么幂等，要么有明确的不确定态恢复路径。

跑起来

准备

• Docker + Docker Compose
• Python 3.12
• 一个 Chat Model Provider（如 DeepSeek 或 DashScope）的 API Key
• 一个 Embedding Provider：默认用本地 Ollama + bge-m3（先 ollama pull bge-m3）， 也可以改用 DashScope

跑起