1. 项目概述从手动告警到自主SOC的进化如果你在运维一个安全运营中心SOC每天面对成百上千条Wazuh告警从海量噪音中筛选出真正的威胁然后手动查询日志、关联上下文、编写响应计划最后再执行封禁或隔离——这个过程不仅耗时而且极易因分析师疲劳或技能差异导致响应延迟或遗漏。Wazuh-OpenClaw-Autopilot 这个项目就是为了解决这个痛点而生的。它不是一个简单的告警转发器而是一个完整的、由AI智能体驱动的自主安全运营流水线。它的核心目标很明确将你的Wazuh SIEM从一个被动的日志收集与分析平台转变为一个7x24小时不间断工作、具备初步研判与响应建议能力的“自动驾驶”SOC。简单来说它是一套运行在你Wazuh环境旁的智能中间件。当Wazuh产生一条告警时这个系统会像一支训练有素的虚拟分析师团队一样自动接管后续流程。首先一个“分诊”智能体会提取告警中的关键实体IP、主机、用户、哈希值并映射到MITRE ATTCK框架评估初始严重性。接着“关联”智能体会在历史告警中寻找与这些实体相关的其他事件将它们聚合成一个统一的“案件”。然后最关键的“调查”智能体上场它会通过MCP协议调用多达48种Wazuh查询工具自动执行诸如检查认证日志、分析进程树、寻找横向移动迹象等深度调查动作并生成调查笔记。基于这些信息“响应规划”智能体会制定一个包含风险评估和回滚步骤的行动计划。最后所有计划都必须经过两层人工审批确认后才会由“响应执行”智能体在Wazuh中执行具体的主动响应动作如封禁IP、隔离主机等。整个过程中人类分析师的角色从繁琐的重复性劳动中解放出来升级为“决策监督者”和“策略制定者”。系统确保了每一个告警都不会被遗漏每一次调查都遵循了最佳实践每一个响应动作都有据可查。这对于提升平均检测时间MTTD、平均调查时间MTTI和平均响应时间MTTR这些核心安全指标有着立竿见影的效果。无论你是只有一两个人的小型安全团队还是希望优化三级分析师工作流程的大型机构这个项目都能为你带来运维效率和响应质量上的显著提升。2. 核心架构与工作流深度解析2.1 七智能体流水线各司其职的虚拟SOC团队Wazuh-OpenClaw-Autopilot的核心创新在于其基于智能体Agent的微服务化流水线设计。它没有采用一个“全能”的巨型AI模型来处理所有事情而是将SOC工作流拆解成七个高度专业化、各司其职的智能体。这种设计模仿了高效SOC团队的分工协作每个智能体只专注于一件事并通过定义良好的接口Webhook与中央运行时服务通信。这不仅降低了单个组件的复杂度也提高了系统的可靠性和可维护性。分诊智能体这是流水线的第一道关卡。它的任务是从原始的、非结构化的Wazuh告警中快速提取出有安全意义的“信号”。它利用LLM的能力进行命名实体识别精准抓取出源IP、目的IP、用户名、主机名、文件路径、MD5/SHA256哈希等关键信息。同时它会将告警描述与MITRE ATTCK知识库进行匹配初步判断这可能属于“初始访问”、“凭证窃取”还是“防御规避”等战术范畴并给出一个初始的严重性评分低、中、高、关键。这个智能体的输出为后续所有工作奠定了结构化的数据基础。关联智能体单一告警往往只是冰山一角。关联智能体的职责就是发现隐藏在历史数据中的关联性。它接收分诊智能体提取的实体例如一个可疑IP然后在设定的时间窗口如过去24小时、7天内查询Wazuh中所有包含该实体的其他告警。它将相关的告警事件聚合到一个统一的“案件”对象中。这彻底改变了分析师的工作模式——从查看一个个孤立的告警转变为处理一个包含了所有相关证据的完整“故事线”。例如一次失败的SSH登录尝试如果关联上了同一IP发起的Web攻击扫描和可疑文件下载那么其威胁等级将完全不同。调查智能体这是整个系统中“智力”要求最高的部分。当案件形成后调查智能体会扮演资深分析师的角色对案件进行深度挖掘。它通过项目集成的Wazuh MCP Server来工作。MCPModel Context Protocol可以理解为给LLM使用的“工具调用”标准。Wazuh MCP Server将Wazuh强大的API如搜索日志、获取代理信息、执行主动响应命令等封装成了48个可供AI调用的标准化“工具”。调查智能体能够自主决定调用哪些工具、以什么顺序调用、传递什么参数。例如对于一个疑似暴力破解的案件它可能会自动执行以下查询链检查该源IP的历史成功/失败登录记录 - 查看受害主机上是否有异常进程或服务启动 - 检索是否有与该攻击者IP相关的其他恶意文件活动 - 分析网络连接情况寻找C2通信迹象。所有这些查询结果会被整合成一份清晰的“调查发现”报告。响应规划智能体基于调查结果这个智能体需要回答“我们该怎么办”的问题。它会生成一个具体的响应行动计划。这个计划不是简单的“封禁IP”而是一个包含多项内容的方案具体行动如block_ipisolate_host、目标对象如IP地址192.168.1.100、行动理由基于哪些调查发现、风险评估此行动可能对业务造成的影响例如阻断IP是否会影响合法用户、回滚步骤如何撤销该行动以及所需审批等级。规划智能体体现了“人在环路”的设计哲学——它只做建议不做决定。策略守卫这是一个非AI的、基于规则的核心策略执行引擎。它在流水线的多个环节规划后、审批前、执行前进行拦截检查。其策略配置在policy.yaml文件中主要包括行动白名单明确允许系统可以建议哪些Wazuh主动响应动作防止AI提议危险操作。置信度阈值只有调查置信度高于设定值如0.7的计划才会被提交审批。审批人授权指定哪些用户或Slack用户ID有权限审批不同风险等级的行动。时间窗口限制例如禁止在业务高峰时段执行主机重启操作。速率限制防止对同一目标在短时间内重复执行相同操作。幂等性检查确保不会重复执行已生效的相同动作。审批与执行工作流这是人类监督的核心体现。所有计划都处于“提议”状态必须经过两层审批。第一层是“内容审批”由授权人员如SOC组长审查行动计划的合理性和风险可以批准或拒绝。批准后的计划进入“待执行”状态。第二层是“执行审批”通常由另一名人员如值班工程师进行最终确认后触发实际执行。这种职责分离SoD的设计是满足安全合规性要求的关键。报告智能体这是一个后台运行的智能体负责生成运营报告。它定期每小时、每天、每周、每月汇总系统处理的案件数量、各阶段平均耗时、误报率、SLA合规情况等关键绩效指标并生成易于阅读的报告。这为安全管理者提供了持续衡量和优化SOC效率的数据看板。2.2 运行时服务智能体协作的中央调度器所有智能体并非直接相互对话而是通过一个名为“运行时服务”的Node.js核心应用进行协调。你可以把它想象成SOC的指挥控制中心。它提供了一套完整的REST API主要功能包括流水线编排接收来自Wazuh的告警Webhook然后按顺序触发分诊、关联、调查、规划智能体。状态管理维护案件、计划、行动等所有对象的状态机如“开放”、“已分诊”、“调查中”、“已批准”、“已执行”。数据持久化将所有数据原始告警、案件详情、证据包、审批记录存储到本地SQLite数据库中形成完整的审计追踪。策略执行集成策略守卫在每一个状态转换点强制执行安全策略。提供监控接口暴露/metrics端点供Prometheus抓取以及/api/kpis端点供直接查看SLA指标。这个服务是无状态的状态在数据库中并且经过了充分测试项目包含超过500个单元测试确保了作为核心调度器的稳定性和可靠性。2.3 证据包贯穿始终的取证与合规记录在整个流水线处理过程中系统会为每一个案件生成一个结构化的JSON格式“证据包”。这个文件是项目的一大亮点它不仅是机器可读的更是为人类审计和合规检查设计的。一个完整的证据包通常包含案件元数据唯一ID、创建时间、当前状态、严重性、置信度。提取的实体所有相关的IP、主机、用户、文件哈希列表及其角色攻击者、受害者。MITRE映射关联到的ATTCK技术和战术。时间线从原始告警到最终响应所有步骤的时间戳序列。调查发现调查智能体输出的纯文本分析结论。行动计划历史所有生成过的计划、其状态变迁以及审批记录。执行的行动最终在Wazuh中执行了哪些主动响应命令及其结果。MCP调用日志调查过程中AI调用了哪些Wazuh查询工具及其参数和返回结果。这个证据包是事后进行根本原因分析、撰写事件报告、满足合规性审计如ISO 27001, NIST CSF要求的宝贵资产。它确保了自动化过程的透明度和可解释性。3. 从零开始部署与配置实战3.1 环境准备与前置条件检查在开始安装Autopilot之前你需要确保基础环境已经就绪。以下是每个组件的详细说明和检查要点Wazuh 管理器这是你的安全数据源。你需要一个正在运行的Wazuh管理器版本4.8或更高推荐使用最新的4.14.x版本以获得完整功能支持。你需要知道其管理接口的IP地址、端口默认55000、以及一个具有读写权限的API用户凭证。你可以通过以下命令快速测试连接curl -k -u wazuh-wui:yourpassword https://WAZUH_HOST:55000/agents?prettytrue如果返回代理列表则连接正常。Wazuh MCP Server这是连接Wazuh与AI智能体的桥梁。它是一个独立的服务将Wazuh的RESTful API转换成了AI模型可以理解的“工具”集合。你需要从项目的GitHub仓库下载并安装它。安装后确保其服务正在运行并且监听端口默认3000可被Autopilot运行时服务访问。你可以通过访问http://MCP_SERVER:3000/tools来验证它是否正常提供了工具列表。Node.js 环境Autopilot的运行时服务是用Node.js编写的。你需要安装Node.js 20或更高版本推荐22 LTS。使用node -v和npm -v检查版本。对于生产环境建议使用nvm来管理Node版本以确保一致性。LLM 提供商与API密钥这是AI智能体的“大脑”。你需要选择一个LLM服务并获取其API密钥。对于初次尝试和大多数生产场景我强烈推荐使用OpenRouter。原因有三第一它聚合了数百个模型包括Claude, GPT, Llama等你只需一个API密钥第二它作为计费代理完全避免了因在第三方工具中使用Claude Pro或Google AI Ultra订阅令牌而导致账号被封禁的风险第三它配置简单模型名称规范统一。当然你也可以直接使用Anthropic、OpenAI、Groq等官方API或者为了数据主权部署本地的Ollama/vLLM。3.2 执行安装脚本与初始配置项目提供了一个非常完善的安装脚本install.sh。这个脚本不仅自动化了繁琐的安装步骤还内置了安全加固措施。在开始前请确保你位于一个具有sudo权限的用户会话中。# 1. 克隆仓库 git clone https://github.com/gensecaihq/Wazuh-Openclaw-Autopilot.git cd Wazuh-Openclaw-Autopilot # 2. 运行安装脚本这将安装依赖、配置服务、设置OpenClaw sudo ./install/install.sh安装脚本会执行以下操作检查并安装系统依赖如curl, git, sqlite3。安装并配置Node.js运行时。安装Wazuh MCP Server及其依赖。创建系统用户和组以非root权限运行服务。设置OpenClaw框架并部署七个SOC智能体。创建Systemd服务单元文件配置服务开机自启。生成默认的配置文件和环境变量模板。安装完成后最重要的步骤是配置环境变量。配置文件位于/etc/wazuh-autopilot/.env。sudo nano /etc/wazuh-autopilot/.env你需要根据你的环境修改以下关键配置# Wazuh 连接配置 - 这是数据源头 WAZUH_HOSTlocalhost # 如果你的Wazuh管理器在另一台机器改为其IP WAZUH_PORT55000 WAZUH_USERwazuh-wui # 建议使用专为API创建的账户而非默认管理员 WAZUH_PASS你的强密码 # MCP Server 配置 - 这是AI查询Wazuh的通道 MCP_SERVER_HOSTlocalhost MCP_SERVER_PORT3000 # LLM 提供商配置 - 选择一种即可 # 选项1: 使用OpenRouter推荐 OPENROUTER_API_KEYsk-or-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 然后在 openclaw/openclaw.json 中配置模型如 anthropic/claude-3-5-sonnet-20241022 # 选项2: 使用Anthropic直接API # ANTHROPIC_API_KEYsk-ant-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 模型配置为 claude-3-5-sonnet-20241022 # 选项3: 使用本地Ollama完全离线 # 无需API_KEY模型配置为 “ollama/llama3.1”并确保Ollama服务运行 # Slack集成配置可选但强烈推荐用于审批 SLACK_APP_TOKENxapp-1-XXXXXXXXXX-... SLACK_BOT_TOKENxoxb-XXXXXXXXXX-...重要提示关于LLM API密钥务必使用从提供商开发者平台获取的“按量付费”API密钥切勿使用从ChatGPT Plus、Claude Pro等订阅计划中获取的OAuth令牌。Anthropic和Google已明确禁止在第三方工具中使用订阅令牌违者可能导致账号封禁。OpenRouter是规避此风险的最佳选择。配置完成后启动服务并验证# 启动所有服务 sudo systemctl start wazuh-autopilot sudo systemctl start wazuh-mcp-server # 设置开机自启 sudo systemctl enable wazuh-autopilot sudo systemctl enable wazuh-mcp-server # 检查服务状态 sudo systemctl status wazuh-autopilot sudo systemctl status wazuh-mcp-server # 验证运行时服务健康状态 curl http://localhost:9090/health # 应返回 {status:healthy,timestamp:...} # 查看Prometheus指标 curl http://localhost:9090/metrics如果所有服务状态为active (running)且健康检查通过那么核心系统就已就绪。3.3 配置Wazuh告警转发与策略调优现在你需要让Wazuh在产生告警时主动通知我们的Autopilot系统。这通过Wazuh的集成功能实现。登录Wazuh仪表板进入管理-设置-集成。点击添加选择自定义类型。配置集成名称Autopilot WebhookHook URLhttp://AUTOPILOT_HOST:9090/api/alerts(确保端口9090可访问)HTTP方法POSTHeaders可以添加一个认证头例如Authorization: Bearer YOUR_SECRET_TOKEN并在Autopilot的.env文件中配置WEBHOOK_AUTH_TOKEN以匹配。安装脚本通常会生成一个随机令牌。最关键的一步是配置告警过滤规则。你肯定不希望每一条低级别的系统日志都触发一次完整的AI调查流水线那将产生巨额成本和无效负载。点击规则选项卡创建一个新规则。例如一个基础的过滤规则可以设置为level 7只处理严重性为7及以上的告警对应“低”及以上并且rule.groups包含authentication_failed,attack,brute_force,malware,vulnerability等关键安全事件组。 你可以根据你的环境逐步调整这个规则集从最关键的攻击告警开始再逐步扩展到其他类型。策略文件调优安装后的默认策略 (policies/policy.yaml) 是保守的。你需要根据你的组织策略进行审核和修改。主要关注action_allowlist: 明确列出你允许系统建议的Wazuh主动响应命令。例如你可能允许block_ip(防火墙阻断) 和disable_user但暂时不允许isolate_host(主机网络隔离) 或restart(重启)。approvers: 添加你的Slack用户ID或系统用户名并为其分配可审批的风险等级 (low,medium,high,critical)。confidence_thresholds: 设置不同阶段所需的最低置信度。例如你可以要求只有置信度高于0.8的计划才能提交给人工审批。完成这些步骤后你的自主SOC流水线就已经搭建完毕处于待命状态。下一次符合条件的Wazuh告警触发时整个AI驱动的处理流程就将自动启动。4. 核心功能实操与高级用法4.1 告警处理全流程实战演练让我们通过一个模拟的“SSH暴力破解”攻击场景来走一遍系统是如何工作的。假设攻击者IP192.168.1.200正在对服务器web-server-01进行SSH密码爆破。告警触发Wazuh检测到来自192.168.1.200的多次SSH认证失败生成一条严重性为10的告警并通过Webhook发送到Autopilot的/api/alerts端点。分诊阶段运行时服务收到告警调用分诊智能体。智能体解析告警提取出关键实体source_ip: 192.168.1.200,hostname: web-server-01,rule.description: “Multiple failed login attempts.”。它将其映射到MITRE ATTCK的T1110.001 - 密码猜测技术并初步标记为high严重性。这个过程通常在40秒内完成。关联阶段关联智能体被触发。它以192.168.1.200和web-server-01为线索搜索过去24小时内所有相关告警。它可能发现同一IP在早些时候还对另一台服务器db-server-02进行了端口扫描告警ID: 1002。于是它将告警1001和1002聚合到一个新的案件CASE-20231027-abc123中。调查阶段调查智能体接手这个案件。它通过MCP Server向Wazuh发起一系列自动化查询例如search_events: 查询web-server-01上所有与192.168.1.200相关的日志。get_agent_info: 获取web-server-01的详细资产信息OS 关键服务。syscheck_last_scan: 检查该主机最近的文件完整性扫描是否有异常。rootcheck_last_scan: 检查是否有rootkit迹象。 智能体分析返回的数据得出结论“IP192.168.1.200在短时间内对多台主机进行了SSH暴力破解尝试暂无成功登录迹象但攻击意图明显需立即遏制。” 它将此发现写入案件并将案件置信度提升至0.9。响应规划响应规划智能体基于高置信度的攻击判断生成一个响应计划。计划内容可能如下{ “case_id”: “CASE-20231027-abc123”, “actions”: [ { “type”: “block_ip”, “target”: “192.168.1.200”, “reason”: “SSH brute force attack against multiple hosts.”, “risk”: “low”, // 阻断外部IP通常业务风险低 “rollback”: { “action”: “unblock_ip”, “target”: “192.168.1.200” } } ], “required_approval_level”: “high” // 需要高级别审批人 }人工审批与执行计划进入“提议”状态。如果配置了Slack集成相关频道会收到一条消息“⚠️ 高严重性案件待审批针对多主机的SSH暴力破解。建议行动阻断IP 192.168.1.200”。消息附有[Approve]和[Reject]按钮。SOC分析师点击[Approve]完成第一层审批。计划状态变为“已批准”。随后另一条Slack消息提示“✅ 计划已批准等待执行。” 并附有[Execute]按钮。值班工程师点击后响应执行智能体被调用它通过Wazuh MCP Server执行block_ip工具在Wazuh管理器中为该代理添加一个针对192.168.1.200的主动响应防火墙规则。执行结果成功或失败会更新到案件证据包中。至此一个完整的安全事件在极少人工干预下得到了快速、标准化、有记录的处理。4.2 离线与自托管LLM部署指南对于网络隔离环境或对数据出境有严格要求的场景使用云端LLM API是不可行的。项目完美支持完全离线的本地LLM部署。方案一Ollama最简单CPU/内存即可运行Ollama是在本地运行开源大模型的利器。部署步骤如下在Autopilot服务器上安装Ollamacurl -fsSL https://ollama.com/install.sh | sh拉取一个适合工具调用的模型。对于安全分析任务需要模型有较强的逻辑推理和指令遵循能力。推荐从以下开始ollama pull llama3.1:8b # 轻量级适合测试 ollama pull qwen2.5:7b # 工具调用能力较好修改Autopilot的OpenClaw配置 (openclaw/openclaw.json)将模型配置指向Ollama{ “model”: “ollama/llama3.1”, “baseURL”: “http://localhost:11434/v1”, “apiKey”: “ollama” // Ollama本地服务通常无需密钥 }重启Autopilot服务sudo systemctl restart wazuh-autopilot使用项目的--mode bootstrap安装模式可以一键完成离线环境的完整部署包括下载所有依赖和模型文件。实操心得在离线环境中模型的“工具调用”能力至关重要。并非所有开源模型都擅长此道。经过测试Qwen系列和Llama 3.1在工具调用格式遵循上表现更稳定。务必在部署前用一些简单的提示词测试模型是否能正确理解并返回JSON格式的工具调用请求。方案二vLLM高性能需要GPU如果你的服务器有NVIDIA GPU并且需要处理高并发告警vLLM是生产级的选择。它提供了极高的推理吞吐量。安装vLLMpip install vllm启动vLLM服务加载一个支持工具调用的模型vllm serve Qwen/Qwen2.5-7B-Instruct --enable-auto-tool-choice --tool-call-parser hermes --api-key token-abc123 --host 0.0.0.0 --port 8000参数--enable-auto-tool-choice和--tool-call-parser hermes对于OpenClaw智能体的正常工作至关重要。在OpenClaw配置中将模型指向vLLM服务{ “model”: “Qwen/Qwen2.5-7B-Instruct”, “baseURL”: “http://localhost:8000/v1”, “apiKey”: “token-abc123” }vLLM能充分发挥GPU性能将单条告警的处理时间从数十秒缩短到数秒非常适合告警量大的环境。4.3 监控、指标与报告生成一个自动化系统必须可观测。Autopilot运行时服务内置了Prometheus指标导出和专门的KPI API。Prometheus指标服务在:9090/metrics端点暴露了大量指标你可以配置Prometheus来抓取。关键指标包括autopilot_alerts_ingested_total摄入的告警总数。autopilot_cases_created_total创建的案件总数。autopilot_plan_state_changes_total{state“proposed|approved|executed|rejected”}各状态计划的数量。autopilot_agent_invocation_duration_seconds_bucket{agent“triage|correlation|investigation|planner”}各智能体处理耗时的直方图用于分析性能瓶颈。autopilot_mcp_call_duration_seconds_bucketMCP工具调用耗时。SLA/KPI API更直观的是/api/kpis端点。它直接计算并返回SOC的关键绩效指标curl http://localhost:9090/api/kpis?period24h返回的JSON数据包含了mttt平均分诊时间。从告警产生到完成分诊的耗时。mtti平均调查时间。从分诊完成到调查完成的耗时。mttr平均响应时间。从计划生成到最终执行的耗时包含人工审批等待时间。mttc平均闭环时间。从告警产生到案件关闭的总耗时。auto_triage_rate自动分诊成功率。false_positive_rate根据最终案件处置结果反推的初始告警误报率。sla_complianceSLA合规率例如“15分钟内完成分诊”的达成比例。自动化报告报告智能体会根据配置定时运行从数据库中聚合数据生成HTML或Markdown格式的报告并可以通过Webhook发送到Confluence、邮件或指定的文件目录。你可以在策略文件中配置报告生成周期和格式。5. 故障排查、性能调优与安全加固5.1 常见问题与解决方案速查表在部署和运行过程中你可能会遇到一些典型问题。以下是一个快速排查指南问题现象可能原因排查步骤与解决方案服务启动失败1. 端口冲突。2. 环境变量配置错误。3. Node.js模块缺失。1. sudo netstat -tlnp健康检查通过但告警无响应1. Wazuh集成Webhook未正确配置或未触发。2. 网络策略阻止了Wazuh到Autopilot的通信。3. 告警过滤规则过于严格。1. 在Wazuh仪表板检查集成的“最近调用”日志看是否有发送记录。2. 在Autopilot服务器用sudo tcpdump -i any port 9090抓包看是否有POST请求到来。3. 临时放宽Wazuh集成规则测试一条低级别告警是否能触发。智能体处理超时或报错1. LLM API调用失败或超时。2. MCP Server连接失败。3. 模型不支持工具调用格式。1. 查看运行时服务日志 (journalctl -u wazuh-autopilot -f)错误信息通常会指明是哪个API调用失败。检查API密钥余额、网络连通性。2. 验证MCP服务状态curl http://localhost:3000/health。3. 对于本地模型尝试在OpenClaw配置中为模型指定tool_choice: “required”参数或换用工具调用能力更强的模型。Slack审批按钮无反应1. Slack App Token或Bot Token无效。2. Socket Mode连接未建立。3. Slack App权限配置不全。1. 在运行时服务日志中查找Slack连接错误。2. 确认在Slack API控制台中该App已启用Socket Mode并订阅了commands,events,interactivity权限范围。3. 重新安装Slack App确保OAuth重定向URL配置正确。案件堆积在“调查中”状态1. 调查智能体逻辑复杂处理单个案件耗时过长。2. MCP Server查询Wazuh时超时。3. 并发案件过多资源不足。1. 调整调查智能体的“工具调用”复杂度在agents/investigation的配置中减少每次调查默认调用的工具数量。2. 检查Wazuh管理器负载优化其性能。增加MCP Server查询的超时时间配置。3. 考虑水平扩展部署多个Autopilot运行时服务实例并通过负载均衡器分发告警。主动响应执行失败1. Wazuh代理未启用主动响应功能。2. 代理上的防火墙规则阻止了管理器命令。3. 策略文件中的action_allowlist未包含该动作。1. 在Wazuh管理器中检查对应代理的“主动响应”配置是否已启用且规则正确。2. 在代理上检查ossec-logcollector日志查看是否收到并执行了命令。3. 检查Autopilot的policy.yaml文件确保该动作如block_ip在允许列表中。5.2 性能调优与规模化部署建议当你的告警量从每天几百条增长到上万条时需要对系统进行调优。智能体并发处理默认情况下流水线是顺序处理单个告警的。你可以在运行时服务的配置中启用并发处理。修改.env文件设置MAX_CONCURRENT_CASES5根据你的服务器CPU和内存调整。运行时服务会并行处理多个案件但需注意LLM API的速率限制。LLM模型选型与成本优化不同智能体对模型能力的需求不同。你可以在openclaw/openclaw.json中为不同智能体分配不同的模型实现性价比最优。分诊/关联智能体任务相对简单对推理能力要求不高。可以使用速度快、成本低的模型如groq/llama-3.1-8b(Groq的免费层速度极快) 或anthropic/claude-haiku。调查/规划智能体任务复杂需要深度推理和规划。应使用能力最强的模型如anthropic/claude-sonnet或openai/gpt-4o。在OpenClaw配置中你可以通过“agents”字段为每个智能体单独指定模型配置。数据库优化默认使用SQLite在极高负载下可能成为瓶颈。对于生产环境可以考虑迁移到PostgreSQL。项目代码通常使用ORM如Sequelize迁移数据库连接字符串即可。缓存策略对于IP信誉查询如AbuseIPDB等外部API调用项目内置了TTL缓存。你可以调整缓存时间减少重复查询和外部依赖。高可用部署对于关键生产环境可以考虑以下架构将运行时服务、OpenClaw网关、MCP Server分别容器化。使用Docker Compose或Kubernetes进行编排。为运行时服务配置多个副本前面用Nginx做负载均衡。使用共享的PostgreSQL数据库和Redis用于缓存和分布式锁。将Wazuh的告警Webhook指向负载均衡器地址。5.3 安全加固与权限最小化原则将AI引入安全响应循环其自身的安全性至关重要。项目在设计上贯彻了“最小权限”和“深度防御”原则但你仍需在部署时进行加固。网络隔离确保所有组件Wazuh, Autopilot运行时, MCP Server, 数据库之间的通信仅在受信任的网络段进行。理想情况下它们应部署在同一台主机或通过VPN/私有网络互联。将所有服务的监听地址绑定在127.0.0.1而非0.0.0.0。API认证务必启用并强化Webhook和API的认证。安装脚本生成的随机Bearer Token是第一步。对于生产环境可以考虑使用双向TLS认证或在API网关层如Nginx配置更严格的IP白名单和JWT验证。Wazuh API权限为Wazuh MCP Server创建专用的Wazuh API用户并遵循最小权限原则。只授予它执行所需查询和主动响应动作所必需的精确权限例如agent:read,active-response:run避免使用具有管理员权限的默认账户。LLM提示词注入防护AI智能体的指令提示词是代码的一部分。确保这些提示词文件 (agents/*.json) 不被未授权修改。在提示词中应明确加入“仅使用提供的工具”、“不要执行任何未授权的操作”等防御性指令。审批流程不可绕过定期审计policy.yaml文件和数据库中的审批记录确保所有执行过的行动都有对应的、符合策略的两层审批记录。可以编写简单的脚本定期检查“已执行”状态的计划是否都有“已批准”的前置状态。完整的审计日志除了系统自带的证据包确保操作系统层面和应用层面的日志如/var/log/syslog,journalctl输出 运行时服务自身的日志文件被集中收集和长期留存以备溯源。通过遵循上述部署、配置、优化和加固指南你可以将一个实验性的AI自动化项目稳健地落地为一个能够真正承担起7x24小时初级安全运营工作的生产级系统。它将持续学习你的环境不断优化其判断最终成为你SOC团队中一名不知疲倦、严守流程的“虚拟一级分析师”。