ITOps Agent Platform
AI 多 Agent 协作的开源 IT 运维平台，将告警接入、根因诊断、修复命令生成、人工审批、自动执行与结果验证串成一条全闭环流水线。
证据显示平台宣称非root容器、命令安全过滤（7类危险命令策略）、HITL审批闭环、AES-256-GCM加密与JWT三级密钥策略（SECURITY.md与README描述具体可查），但本次提供的源文件中未包含命令过滤、审批引擎或SSH执行的实现代码，最小权限、外部效果防护与回滚均属'有声明无代码'；README仅承诺'自动验证结果，失败告警'，未展示修复失败的回滚机制，而该产品会SSH执行AI生成命令并操作Docker/K8s/vSphere，外部影响面大而证据薄；数据流方面列出多个云端LLM提供商与'本地AI数据不出域'并存，但告警/日志/服务器凭据哪些会发送给LLM未见明确说明；依赖安全无lockfile审计或SCA证据；部署推荐curl|sh远程脚本，属高风险默认。扣分点：关键安全声明缺少对应源码支撑。
CI流程完整（lint/tsc/架构检查/前后端测试/Docker构建验证），认证模块集成测试用真实SQLite内存库且覆盖登录/刷新/黑名单/审计落库，错误响应结构化（success/error + 400/401语义明确），失败消息可得2分；但README自身承认'近期Docker镜像为过渡态，未经验证依赖混乱，不建议直接拉取'，与'5分钟体验完整闭环'的一键部署推荐直接矛盾，自洽性扣分；多模型降级链、熔断器仅有声明，测试证据未覆盖；扣分点：安装路径与稳定性声明相互冲突。
受众与场景描述充分：按运维工程师/SRE/IT主管/中小企业/安全合规分角色列痛点与方案，四条使用路径清晰，可得3分；环境适配方面Docker部署、多种本地/云模型选项、信创友好有具体说明；但能力边界严重失真——'运维的终极形态''边际成本趋近于零''AI承担80%工作量'均为不可证伪的营销断言，未说明AI误诊率、不适用的故障类型或人工监督的最低要求；触发精度方面Webhook三种签名模式有文档，但告警降噪/关联准确性无任何验证证据；扣分点：愿景叙事淹没真实边界。
信息架构优秀：7种语言README、文档导航表、清晰的项目结构图，得3分；已知局限方面坦承重构过渡期镜像不可靠，值得肯定；维护责任明确（SECURITY.md含48小时确认/30天修复SLA，作者实名可联系），得2分；但许可存在实质问题：LICENSE文件为标准MPL-2.0，README却在2026-05-27通知中附加'严禁闭源打包售卖''严禁搭建竞品SaaS'等MPL-2.0本身不包含的额外限制，且MIT到MPL的双时期授权边界未在LICENSE中体现，元数据为NOASSERTION，许可得分1；无CHANGELOG文件，仅版本徽章与3.0.5版本号；示例与FAQ薄弱，无具体配置示例或常见问题；install_notes因curl|sh模式与不稳定镜像警告扣分。
输出可用性有据：结构化JSON修复命令、Markdown报告、自然语言诊断在README中有具体描述，测试也验证了统一响应格式，得2分；边际价值方面'告警→诊断→修复→审批→验证'闭环定位与GrafanaOnCall/Portainer/Rundeck各有分工的对比逻辑成立，方向上有差异化；但成本收益仅1分：完全未提及LLM API成本、自托管资源需求、重构期的不稳定会显著抬高试用成本，'$0年费用'忽略模型调用与运维投入；扣分点：TCO叙事不完整。
声明可追溯性差：68路由/72服务/63页面/32次迁移/21条知识库等数字在本次证据文件中无法核对，'命令安全引擎7类策略''AES-256银行级加密'无对应代码片段；跨源印证有限：README的安全声明与SECURITY.md相互印证，auth集成测试印证了登录/黑名单行为，但仅覆盖产品很小一角；事实与推断严重混杂：Gartner/CNCF趋势、$400亿市场、GitLab类比等推测性内容与功能性描述混排且无来源，'唯一将全链路AI自主闭环工程化落地'为不可验证断言；扣分点：数字声明与营销断言均缺乏可核对的证据链。
- README 附加的'禁止闭源售卖/禁止竞品SaaS'条款不在标准 MPL-2.0 之内，与 LICENSE 文件冲突，商用前需法律审查；MIT（2026-05-27前）与 MPL-2.0 双时期代码混合，边界需按提交逐一核对。
- 官方自述当前 Docker 镜像为'过渡态、未经验证、依赖混乱'，不要用于生产；切勿盲目执行 curl|sh 一键脚本，应先审计 deploy.sh。
- AI 自动修复将 SSH 执行 AI 生成的命令并操作 Docker/K8s/vSphere，命令过滤与审批逻辑在本仓库证据中未见实现代码，生产启用前必须人工代码审计并先在隔离环境演练。
- '数据不出域'仅在使用本地模型时成立，配置云端 LLM（豆包/DeepSeek/OpenAI等）时告警内容、日志和可能的凭据将外发，需明确数据流向。
- 未提供修复失败回滚机制的证据，仅有失败告警；关键系统启用自动修复前应自行准备回滚方案。
- 默认账号 admin/admin，首登后必须立即改密并配置 JWT_SECRET、WEBHOOK_VERIFY_ENABLED=true。
这个 Agent 能做什么，适合哪些场景？
ITOps Agent Platform（GitHub: qinshihu/itops-agent-platform）定位为中国首个企业级多 Agent IT 运维平台，对标 PagerDuty、Rundeck、Portainer 的组合能力，支持 Docker 一键自托管部署。后端为 Node.js + Express + TypeScript，前端为 React 18 + Vite + Ant Design，数据库为 SQLite（better-sqlite3，WAL 模式，AES-256 加密），共包含 12 个预设 Agent、68 个 API 路由、72 个服务和 63 个前端页面。核心执行链路是：接收 Prometheus/Zabbix 告警 Webhook，AI 进行根因分析并生成修复命令，经企微/钉钉推送人工审批（HITL）后通过 SSH 执行修复，最后自动验证并生成报告。除告警修复外，平台还提供工作流拖拽编排、Docker/VMware/Proxmox/K8s 统一管理、IP 子网与 VLAN 管理、机房 3D 数字孪生监控、知识库 RAG 和定时巡检。AI 模型池支持豆包、通义千问、DeepSeek、智谱、OpenAI、Claude 及 Ollama 等本地模型，支持主备降级链。需要注意：项目正基于 4A 架构与 DDD 进行重构，当前过渡态代码和镜像未经验证，README 明确建议普通用户等待稳定版本。
平台通过 Webhook 接收 Prometheus 和 Zabbix 告警，由 AlertProcessor 状态机完成接收、过滤、关联和降噪，随后 AI 多 Agent（含告警处理、故障诊断、日志分析、命令生成专家等 12 个预设 Agent）生成自然语言根因诊断报告和结构化修复命令（JSON）。修复命令经 SSH 命令安全过滤（7 类危险命令策略、按角色拦截）后，通过企业微信或钉钉推送审批，审批人在手机端一键通过后由 ssh2 自动执行，结果自动验证并生成 Markdown 报告。运维自动化域包含 WorkflowEngine 状态机支持拖拽编排工作流与 Cron 定时巡检；基础设施域通过 Dockerode 管理 Docker 多主机，通过适配器管理 VMware vSphere、Proxmox VE、KVM，K8s 支持kubeconfig 导入集群；网络域含 17 家厂商适配器、SNMP 拓扑发现；数据中心模块提供机房机柜建模与 Three.js WebGL 3D 实时监控。MCP 模块提供 6 层 securityGate 的工具协议桥接，知识库模块通过 RAG 语义检索注入 LLM 上下文。所有数据存储在本地 SQLite，支持自动备份与 CSV/JSON 导入导出。
- 运维工程师：半夜收到服务器 CPU 99% 告警，不再手动 SSH 排查，由 AI 诊断根因并在手机上审批一键修复，全程约 3 分钟
- SRE/DevOps 团队：替代 PagerDuty + Rundeck + Portainer 多工具切换，将告警接入、诊断、执行、审批合并在一个自托管平台闭环
- 中小企业 IT：无力承担 PagerDuty/ServiceNow 每年 $50,000+ 费用，需要一个免费开源且数据不出域的替代方案
- 安全合规团队：要求所有修复操作必须经过 HITL 人工审批、全链路审计日志和危险命令拦截，满足审计追溯要求
- 信创/数据敏感企业：通过 Ollama/LM Studio/vLLM 接入本地模型，实现 AI 推理 100% 本地化，数据不出域
- 容器与虚拟化运维：需要统一管理多主机 Docker、VMware vSphere、Proxmox VE、KVM 集群，并进行定时自动化巡检
这个 Agent 有哪些优点和局限？
- 唯一将告警 → 诊断 → 决策 → 审批 → 执行 → 验证全链路 AI 闭环工程化的开源 AIOps 平台，7 节点状态流转已打磨
- 12 个 Agent 协作调度而非单次 API 调用，配合完整推理链可审计、命令安全过滤和 HITL 审批，适合生产环境
- AI 模型池统一管理多提供商（豆包/DeepSeek/通义千问/OpenAI/Ollama 等），带主备降级链和独立熔断器，支持本地模型数据不出域
- 功能覆盖面广：容器/VM/K8s 管理、IP/VLAN 管理、机房 3D 数字孪生、工作流编排、知识库 RAG，一个平台替代多套工具
- 工程成熟度有据可查：32 版本数据库 schema 迭代、68 个 API 路由、72 个服务、CI/CD workflow，远超 Demo 级项目
- 项目正处于 4A/DDD 大规模重构期，近期代码和 Docker 镜像为过渡态、未经验证且依赖混乱，README 自身不建议直接使用，需等待稳定版本
- 许可证在 2026-05-27 前为 MIT，之后新增/修改代码改为 MPL-2.0，且明确禁止闭源封装售卖和搭建同类竞品 SaaS，商用前需仔细评估合规边界
- 依赖 Node.js 22、SQLite 单机数据库等运行时，大规模场景下 SQLite 的扩展性和多节点部署能力 README 未提供证据
- 复杂度高：63 个前端页面、72 个服务、60 个数据库 migration，学习与运维成本显著，出现问题时排障门槛较高
- GitHub License 标记为 NOASSERTION，混用 MIT 与 MPL-2.0 代码的实际情况需使用者自行核验
如何安装或部署这个 Agent？
一键脚本部署（Linux/Mac，需要 Docker 环境）：
curl -sL https://gitee.com/IT_Oline/itops-agent-platform/raw/main/deploy.sh -o deploy.sh && chmod +x deploy.sh && ./deploy.shWindows PowerShell：运行 .\deploy.ps1。
或使用 Docker Compose：
docker compose up -d --build部署后前端访问 http://localhost:8080，健康检查在 http://localhost:3001/health。本地开发可进入 local-dev 目录运行 start-dev.sh（Windows 为 start-dev.bat），前端 3000 端口、后端 3001 端口。重要：项目正处于 4A/DDD 重构的过渡期，README 明确说明近期构建的 Docker 镜像未经验证、依赖混乱，不建议直接拉取，普通用户应等待稳定版本发布。
如何使用这个 Agent？
- 部署完成后浏览器打开 http://localhost:8080，使用默认账号 admin/admin 登录（首次登录强制修改密码）。2. 添加一台服务器，系统自动发现宿主机上的容器和资源。3. 在设置中配置 AI Provider（豆包/通义千问/DeepSeek/OpenAI/Ollama 等）并配置告警 Webhook，触发一条测试告警观察 AI 自动分析。4. 点击"自动修复"，在企业微信或钉钉的移动端审批推送中一键通过，即可完成告警 → 诊断 → 审批 → 执行 → 验证的全流程。5. 可通过工作流编辑器拖拽编排 Agent 与审批节点，配置 Cron 定时执行多服务器巡检并生成报告。
这个 Agent 与同类方案有什么区别？
README 将其与 Grafana OnCall、Portainer、Uptime Kuma、Rundeck、Coolify 对比：这些工具各管一段（OnCall 管告警、Portainer 管容器、Rundeck 管执行），均不具备 AI 多 Agent 协作、自动修复闭环和 HITL 审批。与 PagerDuty + Rundeck、ServiceNow ITOM 等商业方案对比：商业产品年费 $50,000-$100,000+ 且多为 SaaS 强制上云，本平台开源免费、100% 本地部署，但成熟度和企业支持无法与商业产品等同视之。