luxy-aisre 是一个面向 Kubernetes 与云基础设施的 AgenticOps / AI SRE 控制平面，目标是把告警、事件、日志、拓扑、Runbook、模型调用和人工审批串成完整的运维闭环：发现问题、诊断、生成修复方案、预演、审批、执行、验证与沉淀知识。项目采用 Python 后端、TypeScript 前端，支持本地运行、Docker、Helm/Kubernetes 部署，并集成 OpenAI 兼容模型、OAuth 模型网关、Prometheus、Loki、Tempo、Grafana、Rancher、CMDB、Langfuse 等能力。
适用领域
AIOps / SRE / Kubernetes 运维 / 云原生基础设施 / 智能告警诊断 / 自动化故障修复 / 可观测性 / 发布治理 / 知识库 RAG / 运维自动化平台
配置难度
高。该项目不是单一 Python 服务，而是包含前端构建、后端控制平面、多 Agent 服务、模型网关、Kubernetes RBAC、Helm 部署、可观测性系统、知识库、审批流和企业安全配置的复合型平台。个人本地体验难度中等，但生产级落地需要 SRE、Kubernetes、安全、平台工程和大模型工程经验。
商业价值
未知
01
技术亮点
- 定位清晰：不是简单聊天机器人，而是面向 SRE 工作流的控制平面
- 强调证据驱动和受控执行：包含证据收集、变更预览、人工审批、执行、验证、审计、失败重规划等环节
- 适合企业内部落地：支持 OAuth 模型网关、Secret、RBAC、审计、审批、模型配置、多 Agent 服务和私有算法扩展
- 云原生集成丰富：覆盖 Kubernetes、Rancher、Prometheus、Loki、Tempo、Grafana、CMDB、eBPF/data-flow 适配等方向
- 提供较完整部署路径：本地、Docker、Helm、原始 Kubernetes manifests 均有说明
- 考虑中国大陆和内网环境：Dockerfile 和脚本支持 DaoCloud、npmmirror、阿里云 PyPI 镜像等构建参数
- 支持知识库和技能库，可将运维经验、Runbook、日志和文档沉淀为可复用能力
- 提供 Model Lab，可配置多个模型并比较输出结果，适合企业评估不同模型在运维场景下的表现
- 可选 Langfuse，有利于追踪模型调用质量、延迟、Token、成本和工具链路
02
目标用户
- 负责 Kubernetes 集群运维的平台工程师
- SRE 团队
- DevOps 团队
- 需要构建内部 AIOps 平台的企业研发团队
- 需要将大模型接入运维流程的基础设施团队
- 使用 Rancher、Prometheus、Grafana、Loki、Tempo 等云原生工具链的团队
- 对变更审批、审计、回滚、风险控制有较高要求的企业运维团队
03
配置要求
- Python 3.14+
- Node.js / npm，用于构建 TypeScript 前端；README 中 Docker 构建使用 Node 24 slim
- Kubernetes 集群，若使用集群部署需要 kubectl、Helm、可用的 StorageClass 和镜像仓库
- OpenAI 兼容大模型接口，或支持 OAuth client credentials 的企业模型网关
- 必要环境变量包括 LLM_API_BASE、LLM_API_KEY 或 OAuth 凭证、LLM_MODEL、LLM_AUTH_TYPE、LLM_VERIFY_SSL 等
- 如接入企业可观测性，需要配置 PROMETHEUS_URL、Loki、Tempo、Grafana 等相关地址
- 如接入 Rancher，需要配置 RANCHER_URL、RANCHER_TOKEN、RANCHER_CLUSTER_IDS
- 如接入 CMDB 或拓扑能力，需要配置 CMDB_URL 及相关适配器
- 生产环境需要配置 ALLOWED_NAMESPACES、OPS_MUTATION_ENABLED、AUTO_HEALING_ENABLED，限制可操作命名空间和自动修复能力
- 如启用 Langfuse，需要配置 LANGFUSE_ENABLED、LANGFUSE_HOST、LANGFUSE_PUBLIC_KEY、LANGFUSE_SECRET_KEY
- 管理员写权限默认关闭；若启用模型、知识库、Skill 写入能力，需要通过 Kubernetes Secret 配置 CONSOLE_BASIC_AUTH_USERNAME 和 CONSOLE_BASIC_AUTH_PASSWORD
- 生产环境应使用受控 RBAC 模式 rbac.mode=controlled，避免使用 cluster-admin，除非在隔离验证环境中
04
适用场景
- 通过 SRE Chat 以对话方式查询集群、命名空间、工作负载、事件和风险上下文
- 对 Kubernetes Pod 重启、镜像拉取失败、调度失败、PVC、网络、配额、滚动发布异常等问题进行辅助诊断
- 基于证据生成修复计划，并在人工审批后执行变更
- 对修复动作进行 dry-run、审批、执行、恢复验证和失败后的重新规划
- 周期性巡检 Kubernetes/Rancher 资源并生成风险队列
- 通过拓扑和依赖关系分析故障影响面和爆炸半径
- 在发布过程中结合 SLO、错误预算、金丝雀发布和风险门禁进行治理
- 上传 Markdown、PDF、Word、Excel、日志、YAML、Runbook 等资料构建运维知识库
- 对多个大模型网关或 OpenAI 兼容模型进行配置、对比和评估
- 通过 Langfuse 追踪模型调用、Token 使用、延迟、成本和工具调用链路
05
部署与配置
- 克隆仓库：git clone https://github.com/CoscoAI/luxy-aisre.git && cd luxy-aisre
- 复制环境配置：cp .env.example .env
- 在 .env 中配置 LLM_API_BASE、LLM_API_KEY、LLM_MODEL、LLM_AUTH_TYPE 等模型访问参数；如果使用 OAuth 网关，还需要配置 OAUTH_TOKEN_URL、OAUTH_CLIENT_ID、OAUTH_CLIENT_SECRET 等参数
- 构建前端控制台：cd frontend/modern && npm install && npm run build && cd ../..
- 创建 Python 虚拟环境：python -m venv .venv && source .venv/bin/activate
- 安装后端依赖：pip install -r requirements.txt
- 本地启动控制平面：uvicorn backend.app.main:app --host 0.0.0.0 --port 8080
- 访问控制台：http://localhost:8080
- 如需启动本地 Agent 兼容端口，可分别启动 observability_agent、healing_agent、incident_agent、postmortem_agent、mcp_http_server、openwebui_adapter 等服务
- Docker 部署：docker build --target backend-runtime -t luxy-aisre:latest .，然后使用 docker run --env-file .env -p 8080:8080 luxy-aisre:latest 启动
- Kubernetes 推荐使用 Helm：创建 namespace 后执行 helm upgrade --install coscoai-sre ./charts/coscoai-sre --namespace k8s-agent，并配置镜像仓库、存储类、RBAC、Secret 等参数
- 生产环境部署前建议执行 helm lint 和 helm template，审查 RBAC、Secret、NodePort、Ingress、持久化和权限配置
06
风险与注意事项
- 许可证风险：README 显示 PolyForm Noncommercial，意味着商业使用可能受限；仓库元数据 license 为 NOASSERTION，企业使用前必须进行法务确认
- 运维安全风险较高：项目具备 Kubernetes 变更执行和自动修复能力，若 RBAC、命名空间限制、审批和审计配置不当，可能造成生产事故
- README 显示 Python 3.14+，该版本要求较新，部分企业基础镜像、依赖库或 CI 环境可能尚未完全适配
- 项目涉及大模型决策，模型幻觉、错误诊断、错误修复建议不可避免，必须坚持人工审批和 dry-run
- 默认 NodePort 30080 不适合直接暴露到公网，生产环境应使用企业 Ingress/Gateway、TLS 和统一身份认证
- 需要集成 Prometheus、Rancher、CMDB、Loki、Tempo、Langfuse 等多个外部系统，落地复杂度较高
- 公开仓库只包含 baseline 算法模块，若需要更强的生产级故障评分和诊断效果，可能需要自研或接入私有算法
- Star 数较高但 Fork 较少，社区生态和外部贡献活跃度需要进一步观察
- 模型网关、Secret、管理员密码、Langfuse Key、Rancher Token 等敏感信息管理要求较高，必须接入企业 Secret 管理体系
- 自动修复能力如 AUTO_HEALING_ENABLED 和 OPS_MUTATION_ENABLED 一旦配置不当，可能扩大故障影响面
2026-07-17
第13名
新收录 · github_search
2026-07-16
第11名
新收录 · github_search
2026-07-15
第10名
新收录 · github_search
2026-07-14
第11名
新收录 · github_search
2026-07-13
第24名
新收录 · github_search
