bilalhassan-567/mayday-agent-society

# Mayday — 一个自主的 AI 事件响应社会 **使用 Qwen Cloud 的全球 AI 黑客松 · 赛道 3：Agent Society** Mayday 是一个由 AI agent 组成的社会，它们监控一个在线的 Web 应用，当应用出现故障时， 它们会为案件**竞标**，带着质押的信心对根本原因进行**辩论**， 根据真实的健康检查**验证**修复方案，并**结算信任**，从而使整个社会 随着时间的推移有明显的进步。每一次修复都会改变应用*真实的*状态 — 没有 预设的答案，也没有偷看故障答案 key。 ## 在线演示（目前正在 Alibaba Cloud SAS 上运行） | | | | --- | --- | | **War Room**（实时事件流） | | | **Patient Console**（发生故障的应用） | — 登录 `admin@example.com` / `password` |   ## 为什么开发这个项目 我的毕业设计项目（2023–24）是这个想法的一个雏形版本：一个本地的 Linux/Python 脚本，监控数据库的错误日志，将其直接发送给 LLM，并应用返回的任何修复 — 没有辩论，没有验证，只能靠祈祷。它 足够有效，令人兴奋。这样的团队通常需要大约五名 DBA； 我们只靠两名就应付过去了，因为大部分常规的错误解决工作已经 自动化了 — 直到同样的问题不断反复出现，DBA 仍然不得不介入并手动修复 它。Mayday 是在我明白了当初真正缺失的东西——验证、分歧和信任——之后，那个想法现在的样子。 ## 为什么这符合赛道 3 赛道 3 要求一个具备**任务分解**、**冲突 解决**以及**相比单 agent 基线具有效率提升**的多 agent 系统： | 赛道 3 要求 | Mayday 是如何实现的 | | --- | --- | | 任务分解 | Dispatcher 将警报分解为调查简报 + **信任加权拍卖**；每个 Investigator 获得不同的工具子集，因此他们探索的是真相的不同切面。 | | 冲突解决 | Investigators 带着质押的信心进行**辩论**；一个确定性的 **Adjudicator** 通过*针对真实的健康检查试验每个修复方案*来解决冲突（应用 → 检查 → 还原）—— 胜出者是真正治愈 patient 的方案，而不是辩论得最好的一方。 | | 优于单 agent 的效率 | 提供了一个**单 agent 基线**（`baseline.py`）和一个**benchmark**（`benchmark.py`），在相同的故障上运行两者；社会的第二意见 + 裁决机制捕获了单个 agent 可能犯下的错误修复，并且**案件档案记忆 + 信任**使重复事件的处理变得更快（学习曲线）。 | ## 诚信保证（为什么演示是真实的，而不是彩排的） - **故障注入器**会破坏应用*真实的*状态（`app_settings` 中的配置值，或真实的源代码符号）。**修复会修复同一状态**， 这是从证据中发现的。 - Patient 的路由、`/health` 或任何 agent/工具**从不读取 `faults` 账本** — 它的存在仅用于对该次运行进行*评分*。 - Adjudicator 通过**应用每个候选修复方案并运行 真实的健康检查**，然后还原来选出胜出者 —— 因此“已解决”意味着应用真正恢复了。 - 当没有提议的修复方案能治愈 patient 时，社会将返回 **INCONCLUSIVE** 并 **诚实地升级**（重新调查或回滚），而不是假装成功。 - 故障**ground truth**（`faults/manifest.json`）是故意在这个仓库中公开的： 在阻止 agent 访问答案的代码旁边展示答案 key 比隐藏它更有说服力。你自己可以检查一下 —— `agents/tools.py` 的 `ALLOWED_TABLES` 白名单（`users`、`orders`、`app_settings`）从不包含 `faults`，因此 agent 可以调用的任何工具都无法触及它。 ## 架构 完整的架构图请参见 [`docs/architecture.md`](docs/architecture.md)。简而言之： ``` Watchman ──patrols──> Patient (Laravel CRM console) ┌─ MCP tool layer ─┐ │ opens incident │ log.search │ ▼ │ metrics.query │ Coordinator ── Dispatcher (auction) ── Investigator A ─┐ │ config.read │ │ Investigator B ─┤──────│ db.inspect │ │ (debate) │ │ healthcheck.run │ ├─ Adjudicator (trial each fix vs real health) ─────┘ │ recent_errors │ ├─ Verifier (apply · re-check · rollback / human gate) │ code.read/patch │ ├─ Trust store (per-agent, per-category) │ runbook.rag │ └─ Case-file memory (recall similar past incidents) └───────────────────┘ │ ▼ War Room (live SSE UI) ``` - **Patient** — 一个真实的 Laravel CRM（登录、仪表板、用户/订单/报告 CRUD）。 8 个故障破坏了真实的控制台页面（5 个配置/状态故障，3 个源代码故障）。 - **Agents** — Python；运行在 **Qwen** 上的 OpenAI 兼容客户端（本地开发使用 Ollama `qwen2.5`，真实的证明使用 **Qwen Cloud 上的 `qwen-max`**）。 - **War Room** — 无依赖的实时控制台（SSE）：警报器、带有对话气泡的接线员站点、 信任度条、MTTR、人工审批模态框、自动恢复。 ## 本地运行 前置条件：PHP 8.4 + SQLite，Python 3.10+，以及 Ollama（`ollama pull qwen2.5:7b`） 或 Qwen Cloud key。 ``` # 患者 app cd patient && php artisan migrate --seed && php artisan serve --host=127.0.0.1 --port=8000 # Agents — 在 agents/.env 中选择 model provider # local: LLM_PROVIDER=local (Ollama qwen2.5) # cloud: LLM_PROVIDER=qwen + QWEN_KEY=sk-... (Qwen Cloud 上的 qwen-max) # War Room (实时 UI) cd agents && python warroom.py # http://127.0.0.1:8800 # 或者通过 CLI 驱动一个事件： cd patient && php artisan fault:inject db_pool_exhausted cd agents && python run_incident.py --auto ``` 在 War Room 中：选择一个故障 → **Trigger incident** → 观察社会进行诊断、 辩论、验证并实时结算信任。配置修复会自动应用；源代码修复 会暂停，等待**人工审批**点击。 ## Benchmark（相比单 agent 的效率） ``` cd agents python benchmark.py # society vs single-agent baseline, all faults python benchmark.py --learning db_pool_exhausted # repeat a fault → learning curve ``` 写入 `docs/benchmark-results.json`（包含每种模式的解决率 + 平均 MTTR）。在 **`qwen-max`** 上的主要 结果，两种模式运行完全相同的提示词、工具和应用+验证 路径（因此差异在于*机制*，而不是提示词调优）： | 模式 | 已解决 | 比率 | 平均 MTTR | | --- | --- | --- | --- | | **Society** | **6 / 8** | **75%** | 91.2s | | 单 agent 基线 | 2 / 8 | 25% | 40.0s | **解决率提高了 3 倍。** 社会恰好在机制发挥关键作用的地方获胜 —— 所有 三个代码故障和路由故障，在这些情况下，单个 agent 会提前放弃或提交 错误的修复。它用约 50 秒的额外延迟（辩论 + 试验并还原）换取了 可靠性，这正是真实的待命组织所做的权衡。 **学习曲线**（`docs/learning-curve.json`，某类故障的 5 次重复事件， qwen-max）：**5/5 已解决**，并且每个类别的信任度从中立的 0.5/0.5 划分收敛 到 **1.0/0.0** — 拍卖机制学习到了*应该信任哪个 agent*来处理此类故障，同时 案件档案记忆用之前的修复方案为每个新简报做准备。（MTTR 保持在 ~80–97 秒 —— 平稳， 因为模型延迟占据主导地位；我们如实报告，而不是声称速度有所提升。） ## 已测试 - `agents/` 确定性引擎测试 —— 模块，所有 8 个故障（注入 → 破坏 → 修复 → 健康），工具，信任，记忆，事件存储，裁决 + 升级。 - War Room UI —— Selenium 断言（无日志复活，实时自动恢复， 审批 + 未解决模态框，完整事件渲染） + 完整的实时端到端运行。 ## 诚实的局限性 - 本地的 `qwen2.5:7b` 速度较慢（约 10 分钟/事件），并且在最难的 故障上偶尔会选择错误的值；`qwen-max` 快速且准确。所有主要数据 均在 Qwen Cloud 上产生。 - 两个故障的*修复值*是特定于环境的（一个 DB 主机，一个云 key）；它们的 runbook 为每个环境都携带了正确的值。 - 结构性破坏（删除代码）在设计上不属于自动修复范围 — 社会会升级为回滚 + 人工干预，而不是凭空捏造出重构方案。 ## License MIT — 参见 [`LICENSE`](LICENSE)。

标签：AI运维, AI风险缓解, PyRIT, 任务编排, 多智能体系统, 模块化设计, 自动化修复, 逆向工具, 通义千问, 阿里云