PitCrew AI🚨🏎️
基于MCP编排代理构建的自主SRE系统
PitCrew AI是一个自主的站点可靠性工程（SRE）平台，旨在使用AI代理安全地检测、诊断和补救生产事件。
该项目是以先进系统为重点的黑客马拉松的一部分，旨在展示 现实世界的人工智能基础设施编排，而不仅仅是聊天机器人功能。
该架构强调：
- 控制平面与数据平面分离
- 安全自动化
- 可观察性驱动的决策
- 治理补救
- 生产方式故障模拟
______________________________________________________________________
🎯 项目愿景
现代基础设施需要智能自动化，但不安全的自主性可能是灾难性的。
PitCrew AI旨在回答一个关键问题：
人工智能可以安全地操作生产系统吗？
这个项目不是构建一个简单的人工智能助手，而是专注于创建一个 结构化操作系统 其中代理：
- 检测系统故障
- 调查根本原因
- 咨询操作知识
- 根据策略验证操作
- 执行补救措施
- 生成事故报告
长期目标是模拟生产级自主SRE。
______________________________________________________________________
🧠 核心架构原则
控制平面与数据平面
本项目有意将系统职责分开：
✅ 数据平面（工作负载）
被监控的生产系统。
目前包括：
- API码头化烧瓶
- 健康监测端点
- 受控故障触发器
✅ 控制平面（操作员）
观察和控制系统的智能层。
目前包括：
- 混沌模拟脚本
- 从主机执行Docker命令
- 外部系统控制
这反映了Kubernetes和云平台使用的现实世界基础设施模式。
______________________________________________________________________
🏗️ 建立了什么——Day 1基金会
第一天完全专注于构建一个 现实、可控的生产环境.
在创建AI代理之前，拥有一个能够：
✅ 可预见的失败 ✅ 可靠恢复 ✅ 暴露健康信号
没有这个基础，就无法令人信服地证明可观察性和补救措施。
______________________________________________________________________
🐳 模块化生产服务
一个轻量级的Flask API被容器化作为“生产工作负载”
为什么选择Docker？
Docker通过打包确保服务在跨机器的一致环境中运行：
- 应用程序代码
- 依赖项
- 运行时
- 操作系统级
这消除了经典的部署问题：
“它在我的机器上工作。”
______________________________________________________________________
容器行为
健康状态
/health → HTTP 200 OK故障状态
/health → HTTP 500 SERVICE UNHEALTHY失败是通过文件系统标志触发的：
broken.flag这允许确定性中断模拟。
______________________________________________________________________
💥 混沌工程设置
为了模拟真实的生产事件，创建了一个控制脚本：
chaos.py
运行在 宿主机，不在容器内。
这是故意的。
为什么？
生产系统永远不应该自毁。
故障必须由外部触发，就像运营商或意外事件影响服务的真实基础设施一样。
这强制了适当的架构分离：
控制平面→ 管理
数据平面→ 执行
______________________________________________________________________
混沌能力
中断服务
创建 broken.flag 在容器内部，迫使健康端点返回500。
恢复服务
删除标记并将系统恢复到健康状态。
______________________________________________________________________
示例流程
模拟停机：
python chaos.py
> break恢复服务：
python chaos.py
> fix这使得 一个命令失败演示，这对于可靠的技术演示至关重要。
______________________________________________________________________
📁 当前项目结构
pitcrew-ai/
│
├── victim-app/
│ ├── app.py
│ ├── Dockerfile
│ └── requirements.txt
│
├── chaos.py
└── README.md受害者应用程序
表示生产工作负载。
chaos.py
表示能够控制系统的外部操作员。
______________________________________________________________________
🧱 关键工程决策
确定性故障
随机崩溃不利于演示。
可预测的故障能够实现可靠的测试和演示。
______________________________________________________________________
最小基础设施
故意避免使用Kubernetes，以减少资源开销并提高开发速度。
Docker提供了足够的真实感，没有不必要的复杂性。
______________________________________________________________________
外部控制
自动化脚本保留在容器之外，以反映真实的平台架构模式。
______________________________________________________________________
🔜 接下来会发生什么
有了可控的生产系统，下一阶段将引入智能可观测性。
即将推出的组件：
🔧 机械MCP代理
责任：
- 检查Docker容器
- 读取日志
- 检测不健康的服务
- 表面诊断信号
这就是系统开始从容器演示演变为 人工智能运营的基础设施平台。
未来的代理商将包括：
- 战略家→ Runbook驱动的RAG
- 官方→ 策略验证
- 风险引擎→ 动作评分
- 记者→ 自动验尸
______________________________________________________________________
🚀 长期架构（目标）
Incident Trigger
↓
Observability Agent
↓
Diagnosis
↓
Runbook Retrieval
↓
Policy Validation
↓
Risk Assessment
↓
Autonomous Remediation
↓
Incident Report目标不是创建聊天机器人，而是 自主运营商。
______________________________________________________________________
💡 为什么这个项目很重要
人工智能正在生产环境中迅速获得操作权限。
挑战不再是情报。
它是 信任。
PitCrew AI探索了结构化编排、策略执行和风险感知自动化如何使AI足够安全地操作关键系统。
______________________________________________________________________
✅ 第1天状态
✔ 模块化生产服务 ✔ 健康监测端点 ✔ 确定性失效机制 ✔ 混沌模拟 ✔ 控制/数据平面分离
第2天——自主恢复引擎
第2天升级 PitCrew AI 从故障模拟器到 自主自愈系统.
它现在运行一个闭环工作流：
失败→ 诊断→ 决定→ 补救→ 验证
与现实世界保持一致 SRE自动化.
______________________________________________________________________
建筑
PitCrew推出了一款 数据平面/控制平面 拆分：
- 数据平面： 具有确定性故障+健康遥测的Docker化Flask工作负载
- 控制平面： 机械MCP（FastAPI）+AI驱动程序，用于可观察性和执行性
这使决策保持在工作负载之外，如生产基础设施。
______________________________________________________________________
核心组件
机械MCP（操作层）
- 记录、检查、重启、目标恢复
- 执行行动，从不做决定
人工智能驱动程序（大脑）
- 收集遥测数据
- 通过LLM进行诊断
- 将输出标准化为确定性操作
- 执行补救措施
- 验证恢复
______________________________________________________________________
关键工程获胜
- 上下文工程： 只有关键的日志信号会进入模型
- 确定性行为： 自由文本→ 稳定的命令
- 根本原因恢复： 删除故障触发器+重新启动，而不是盲目重新启动
______________________________________________________________________
结果
PitCrew AI现在可以执行 完全自主的自我修复:
混沌→ 观察→ 理由→ Fix → 验证
在没有人为干预的情况下，模拟真实的SRE行为，而不是演示机器人。
基础完成。
该系统现在已准备好进行智能可观测。
______________________________________________________________________
第3天——治理层和可靠性强化
第3天的重点是通过引入策略执行、执行安全和状态感知事件验证，将PitCrew从自主恢复脚本转变为受治理的基础设施系统。
关键架构升级
实施了一个策略引擎（“官方”），以在执行之前验证所有补救措施。\ 这建立了一个受控的工作流程：
健康→ 诊断→ 政策评估→ 批准的行动→ 恢复→ 验证
该系统现在展示了受控的自主性，而不是不受限制的人工智能驱动的执行。
______________________________________________________________________
策略引擎集成
- 构建了一个专用的FastAPI策略服务。
- 在容器修复之前进行强制批准检查。
- 为高严重性事件引入了人在环超控。
- 防止LLM直接执行到基础设施。
这使平台与现实世界的运营风险控制相一致。
______________________________________________________________________
严重性标准化
检测到词汇漂移导致的治理绕过(CRITICAL 对比 HIGH).\ 实施了严重性规范化，以执行驱动程序和策略引擎之间的严格合同。
结果：
- 消除了意外的自动审批。
- 强化决策决定论。
______________________________________________________________________
确定性解析
用从LLM输出中提取结构化字段代替模糊关键字检测。
优点：
- 减少行动选择中的模糊性。
- 提高自动化可靠性。
- 防止快速出血影响执行。
______________________________________________________________________
虚假事件预防（重大可靠性升级）
观察到历史Docker日志触发了健康服务的恢复。
添加了a 健康预检查门 在运行AI诊断之前：
实时服务状态→ 验证→ 诊断（仅在降级时）
这使系统从日志驱动行为转变为状态感知事件响应——这是一种关键的可靠性模式。
______________________________________________________________________
执行安全改进
- 添加了受保护的恢复流，以防止重复修复。
- 引入了安全的请求包装器，以优雅地处理服务中断。
- 针对依赖失败的强硬驱动力。
控制飞机现在安全地发生故障，而不是不可预测地发生故障。
______________________________________________________________________
操作可追溯性
在每个响应周期中添加事件ID，提高了可观察性，并使系统与真实的事件管理工作流程保持一致。
______________________________________________________________________
结果
PitCrew现在作为一个受管理的恢复平台运行，具有：
- 基于策略的执行控制
- 人为干预高风险行为
- 确定性人工智能行为
- 状态感知事件检测
- 强化编排层
这标志着从原型自动化脚本到面向可靠性的控制平面的过渡。
feat（治理）：添加风险评分、规则归因和审计跟踪
第4天——Runbook智能与决策指导
今天专注于转型 PitCrew 通过引入操作runbook智能，从自主修复系统转变为知识导向的可靠性平台。
一个专用 战略家模块 实现了基于生产日志签名检索相关Runbook。该系统现在不再允许LLM独立推断补救步骤，而是优先考虑结构化的操作知识，大大降低了幻觉风险，并使行为与现实世界的SRE实践相一致。
运行手册与应用程序逻辑分开，以强制执行适当的架构边界——将它们视为知识库而不是可执行代码。随着附加服务和Runbook的引入，这提高了长期可扩展性。
这 司机代理 升级后，将runbook检索直接整合到诊断提示中，明确指示模型将记录的程序优先于自由推理。这创建了一个受控的决策流：
Logs → 运行手册→ 诊断→ 治理→ 机械师→ 恢复
控制台输出经过改进，遵循了专业的工程风格，消除了过多的视觉噪音，同时清楚地显示了每个阶段哪个子系统（战略家、治理者、机械师）正在运行。
第4天的主要成果
- 引入了Strategist检索层
- 实现了确定性runbook匹配
- 在LLM提示符内强制执行runbook优先决策
- 加强车手的稳定性和清晰度
- 改进了知识层和执行层之间的架构分离
- 维护健康门控，防止虚假事件
- 为安全自动化保留确定性动作映射
有了这一补充，PitCrew现在的行为不再像反应式脚本，而更像是一个内部可靠性控制平面，能够在执行生产行动之前咨询作战原则。
该系统现在是稳定的、可解释的、与企业一致的，已准备好进行编排层集成。