一、AI 助手的意义

重大保障（重保）期间，蓝队并不缺单点平台：攻击告警有 SOC，主机入侵有主机安全，信誉查询有情报中心，资源水位有监控，处置落地有防火墙。真正折磨分析师的，是决策链被拆碎——

要先开一张控制台找「攻击成功」，再复制 IP 去另一处查情报，再打开主机安全对一下是否有反弹 Shell，最后才敢提封禁；过程繁琐需要打多个平台

「重保蓝队安全助手」要解决的，不是再造一个日志查询器，而是攻击日志，如何稳定、完整、可被理解地交给 AI，让 AI 做研判、给处置建议？ 因此它的意义可以概括为四点：

一句话：AI 是研判中枢，平台是真相来源；助手负责把两者接在同一条对话里。

二、使用场景

这些场景里有一个共同模式：人说意图 → 系统取真实数据 → 加工成「AI 可研判 / 人可读」的交付物 → 再呈现结论。下面各节都围绕「如何交给 AI」展开。

三、系统架构

3.1 设计原则：双通道交付

为了既发挥大模型的理解能力，又避免它在关键事实上「乱说」，助手采用双通道：

1. 研判通道（默认）：取数之后，先做规则化初判与字段 enrich，再格式化成报告交给用户；需要模型编排时，模型看到的是结构化工具结果，而不是自己瞎编日志。
2. 闸门通道：提示词注入、离题闲聊在进入 Agent 之前被拒绝，确保 AI 只在蓝队语境内工作。

3.2 系统架构图（占位）

3.3 技术架构（简述）

技术栈本身并不神秘；真正有工程含量的是：如何规定 AI 只能基于工具结果研判，以及如何先把原始日志加工成「可研判的输入」。

3.4 项目目录结构

核心代码集中在 app/：接口与编排靠上，研判交付靠近 Agent，各安全能力收敛在 tools/。 项目地址:https://github.com/XHSEC01/AI_Agent-

app/├── main.py                 # FastAPI：对话 / 流式接口、健康检查、静态页├── agent.py                # LangChain Agent：意图编排、直连旁路、纠偏入口├── prompts.py              # 系统提示词与拒绝话术（蓝队职责边界）├── config.py               # 统一读取配置├── guardrails_service.py   # 输入注入/离题、输出防泄露├── callbacks.py            # Agent 回调（进度等）├── request_context.py      # 请求上下文（如操作人）├── audit.py                # 封禁等操作审计落库├── soc_report_service.py   # 攻击日志：意图识别、结构化报告、研判纠偏├── edr_report_service.py   # 主机安全：告警报告格式化与纠偏├── dispose_playbook_service.py  # 处置闭环：研判 → 情报 → 询问封禁├── threat_intel_service.py # 情报事实交付与纠偏├── block_service.py        # 确认封禁直连旁路├── static/│   ├── index.html          # Web 聊天界面（会话、快捷指令、SSE 进度）│   └── logo.svg└── tools/    ├── langchain_tools.py  # 封装为 StructuredTool，注册给 Agent    ├── soc.py              # 攻击日志取数 + 误报初判 / enrich    ├── edr.py              # 主机安全告警取数与整理    ├── threatbook.py       # 威胁情报查询与短事实格式化    ├── zabbix.py           # 主机 CPU/内存等监控    └── firewall.py         # 防火墙封禁（二次确认）

阅读代码时建议顺序：main → guardrails → agent → 某一类 *_report_service → 对应 tools。这样和「提问 → 防护 → 编排 → 研判交付 → 外部事实」的架构完全同构。

四、实现流程分析：数据如何交给 AI 做研判

助手的价值在于「一句话调度全链路」，真正落地时却常踩一个坑：模型很会写分析报告，却不一定站在真实告警上写。需求也不一定符合蓝队想要的效果。 因此我们不追求把所有逻辑都塞进大模型，而是拆出一条清晰的交付链：意图理解 → 拿到事实 → 规则/程序先初判 → 再以结构化结果交给 AI 表达。下面先看总流程，再分别看攻击日志、主机安全、情报、监控、封禁，以及把前几步串起来的处置闭环（研判 → 情报 → 封禁）。

4.1 总流程：从意图到「可研判交付物」

一句话进入系统之后，并不会立刻扔给大模型自由发挥。助手先把自己当成「带门禁的调度台」：

1. 问边界：是否在套提示词、枚举工具，或明显离题？命中则直接拒绝，Agent 本身不启动，也谈不上后续研判。

2. 认意图：把话术落进蓝队场景——攻击成功、主机告警、情报核实、负载巡检，还是封禁确认。

3. 取事实：从对应业务系统拿到原始记录。读者不必关心底层协议细节，只需理解：这一步产出的是可核验的事实，不是模型想象。

4. 做初判与 enrich：对攻击类、主机类告警，用规则引擎先补「误报研判 / 置信度 / 建议」等字段，把「表」扩成「带意见的表」。

5. 交付给人，并受控地交给 AI

   ：

• 关键查询优先走结构化报告，避免模型二次摘要时丢掉最重要栏目；
• 需要多工具编排时，模型只能看到工具回传结果与系统角色约束，不得编造条数、成败与情报字段。

另外还有一道「进度可见」：交互层用流式反馈告诉分析师此刻在理解问题、在调哪类能力、还是在生成回复——重保现场不适合面对长时间黑盒等待。

Agent 侧真正决定体验的，不是「会不会聊天」，而是把大模型收成研判与编排器：提示词划定蓝队职责，工具提供事实入口，中间步骤结果被保留，便于纠偏与二次研判。

# 把大模型收敛成「蓝队任务编排器」prompt = ChatPromptTemplate.from_messages([    ("system", SYSTEM_PROMPT),          # 只做蓝队；禁止编造；须基于工具结果    MessagesPlaceholder("chat_history", optional=True),    ("human", "{input}"),    MessagesPlaceholder("agent_scratchpad"),])agent = create_tool_calling_agent(self.llm, self.tools, prompt)self.executor = AgentExecutor(    agent=agent,    tools=self.tools,    return_intermediate_steps=True,   # 保留工具原始结果，供后续纠偏与研判)

这段代码的意义： AI 的输入空间被主动收窄——它只能看到系统角色约束和工具回传的结构，而不是自由发挥的安全幻想。重保场景里，「约束」本身就是产品能力。

4.2 攻击日志 → 交给 AI 的研判链

功能描述与值班痛点

重保最常见的一句话是：「最近一小时有哪些攻击成功？」若助手只是把平台告警原文贴出来，分析师仍要自己点开请求包、对规则、猜是不是业务接口误报；若放手让模型自由摘要，又经常只剩「建议加强防护」这类空话，关键字段与研判结论一起失踪。

因此攻击日志能力要交付的不是「查询成功」，而是一份带结论的告警清单，通常包含三层信息：

• 事实层：攻击方 / 受害方、通信方向上的源与目的、类型、时间、是否失陷、出现次数等；
• 研判层：误报研判（疑似误报 / 实锤 / 待核实）、置信度、依据说明；
• 处置层：结合研判与情报命中，给出是否建议封禁、是否优先排查等意见。

人要的是「这一条值不值得我现在动刀」，而不是「平台里确实有一条记录」。

如何交给 AI / 研判引擎

攻击日志进入系统后，先走过一道「enrich」，再变成报告。核心工程点不是取数，而是：研判函数如何读规则名与请求/响应特征，产出可被报告层稳定引用的字段。

实践中，误报初判会综合规则名称、URI、参数与响应体：挖矿协议、木马通信类往往直接标「实锤」；名叫「空口令」但实际打的是考勤/订单类业务接口、响应却是正常 JSON 的，则倾向于「疑似误报」；响应里出现明确执行/木马特征则抬升为实锤；仅命中规则但证据不足的，留给「待核实」。这样，第一道意见由可解释规则给出，大模型后续只能在这意见之上组织语言，而不是凭空改口。

def_analyze_false_positive(log: dict) -> dict:"""基于请求/响应特征做误报初判，供后续研判与回复引用。"""    rule_name = str(log.get("rule_name", ""))    uri = str(log.get("uri", "")).lower()    param = str(log.get("http_parameter", "")).lower()    rsp = str(log.get("http_rsp_body", "") or"").lower()# ... 综合规则名、URI、参数、响应体 ...if"挖矿"in rule_name or"Stratum"in rule_name:return {"误报研判": "实锤攻击","置信度": "高","误报分析依据": "告警类型为挖矿协议/木马通信，属于明确恶意行为",        }if"空口令"in rule_name and"/api/"in uri and"attendance"in (uri + param):return {"误报研判": "疑似误报","置信度": "高","误报分析依据": "告警为 Web 空口令，但请求实际是业务考勤类接口，缺乏登录凭据特征",        }# 响应含 webshell/执行特征 → 实锤；404/403 → 疑似未真正成功；否则待核实    ...

初判完成后，再嵌进每条记录，并生成面向分析师的处置建议。需要时还可以把 IP 情报拼进来：攻击成功与源 IP 恶意是两件独立事实，分开描述，再交叉给建议，避免「平台标注成功就等于境外黑客」的粗糙逻辑。

def_enrich_soc_record(log: dict, include_intel: bool = False, ip_intel: str = "") -> dict:    fp = _analyze_false_positive(log)      # 规则初判    record = _format_soc_log(log)          # 事实字段整理    record.update(fp)                      # 把研判字段「交」给下游    record["AI误报分析"] = _compose_fp_ai_text(log, fp)if include_intel:        record["IP情报"] = ip_intel        record["AI研判结果"] = _ai_assess(log, ip_intel, fp)  # 研判 + 情报 → 处置建议return recorddef_ai_assess(entry, ip_intel, fp=None) -> str:    verdict = (fp or {}).get("误报研判", "待核实")if verdict == "疑似误报":return"低优先级：……建议观察，暂不直接封禁"if verdict == "实锤攻击":return"极高危：……建议立即封禁并排查受害资产"if"恶意"in ip_intel and verdict != "疑似误报":return"高危：源 IP 命中威胁情报且攻击证据充分……"    ...

报告层接着强制输出「误报研判 / 依据 / 处置建议」等栏目。这等于规定：最终交给人看的，必须是完整栏目，而不是模型写的散文。即便中间曾走过 Agent，结构化结果仍可覆盖被省略的摘要——结构化胜于散文，是重保输出可信的最低保障。

实现意义

对值班同学而言，读完一条报告就应能回答三件事：是什么、真不真、下一步干不干。这正是把攻击日志「交给 AI」之后，我们希望 AI 帮人缩短的那段思考路径。

4.3 主机安全 → 交给 AI 的分析链

功能描述与场景定位

网络侧「攻击成功」回答的是「有没有打进来」；主机侧反弹 Shell。助手把近一时段的主机安全告警整理为分类型报告——主机是谁、进程或木马路径是什么、外连到哪里、何时发现、建议如何处置。 和攻击日志一样，重点不在「怎么从平台拉下来」，而在于：拉下来之后如何变成分析师和 AI 都能直接读的风险画像。原始主机告警字段杂、口径不一，若不做整理，模型很容易压缩成一句「发现了反弹」，丢掉真正支持处置的路径与外连信息。

如何交给 AI / 分析层

主机安全链路同样遵循「结构化记录 → 可读报告」。先把原始告警映射成研判友好字段：告警类型、主机、进程路径与参数、反弹地址、发现时间、威胁说明、处置建议。缺省建议也可以给保守动作（终止可疑进程、排查外连），保证报告至少「可执行」。

def_format_shell_record(row: dict, server_ip: str = "", local_ip: str = "") -> dict:"""把原始主机告警整理成研判友好字段。"""return {"告警类型": "反弹Shell","主机IP": server_ip,"进程路径": row.get("path") or"","进程参数": row.get("args") or"","反弹地址": row.get("reboundAddress") or"","发现时间": row.get("discoveryTime") or"","威胁说明": row.get("harm") or row.get("harmFeature") or"","处置建议": row.get("suggestion") or"建议终止可疑进程并排查外连地址",    }

呈现给用户（同时也是给 AI 上下文的「标准说法」）时，强制按栏目展开：

def_format_shell_line(idx: int, rec: dict) -> str:return"\n".join([f"### 反弹Shell {idx}",f"- 主机IP：{rec.get('主机IP', '')}",f"- 进程路径：{rec.get('进程路径', '')}",f"- 反弹地址：{rec.get('反弹地址', '')}",f"- 发现时间：{rec.get('发现时间', '')}",f"- 威胁说明：{rec.get('威胁说明', '')}",f"- 处置建议：{rec.get('处置建议', '')}",    ])

这里可以对照理解两类交付差异：

• 攻击日志更侧重「请求/响应 + 规则名 → 误报/实锤」——争的是「这条网络告警真不真」；
• 主机安全更侧重「进程、路径、外连 → 威胁说明与遏制建议」——争的是「这台机器上危险点落在哪里」。

二者最终进入同一种对话通道。分析师可以先问攻击成功，再问同时间窗的主机安全告警，让 AI（以及人）在同一会话里对齐「外围打击」与「落地控制」。字段一旦稳定，后续做跨源关联才有输入；若仍是一坨原始 JSON，关联只会变成模型幻觉。

实现意义

主机安全告警天然嘈杂：安装脚本、运维反连、业务健康检查都可能误伤。把字段固定、把建议说清楚，既是给人减负，也是给 AI「可计算的上下文」。重保现场宁可多几行结构化条目，也不要一句听起来正确、却无法落到主机与路径的概括。

4.4 情报中心 → 事实交付给 AI

功能描述

查询某 IP 是否恶意、归属何处、信誉如何。它经常嵌在攻击研判后半段：某条告警看完了，还要问「这个源地址历史上是不是臭名昭著」。若这一步也交给模型凭语料「感觉像黑客」，整条研判链会从中间坍塌。

因此约定很硬：结论必须来自情报中心；AI 只允许复述，并在此基础上给处置建议，不允许改写是否恶意。

如何交给 AI

交付策略是极简、结构化、可机读。固定输出是否恶意、归属地、信誉与标签，并单独带上可供界面消费的恶意标记——恶意 IP 在对话里红色高亮，分析师扫一眼就能分出优先级。系统提示词写明情报字段不得被模型改写；后端还有纠偏逻辑：一旦发现模型偏离真实查询结果，用事实覆盖回去。

def_build_formatted_reply(summary: dict) -> str:    prefix = "[恶意] "if summary.get("is_malicious") else""# 极简交付：事实短句，方便人读，也方便 UI / 后续 Agent 步骤消费return (f"{prefix}是否恶意:…; 归属地:…; 信誉等级:…; …"    )

这种「短事实」看起来不像 AI 的长篇分析，但对后续链路极重要：攻击日志研判可以把情报当作独立输入拼进 _ai_assess，而不会把模型作文再当真相引用一次。情报越短、越可校验，研判越稳。

4.5 主机监控 → 异常判定交给「规则 + 表述」

功能描述

重保不只盯攻击，还要盯「被打的同时会不会把机器打满」。CPU / 内存的当前值、均值、峰值，以及是否超过值班阈值，构成安全与稳定性联查的另一半。这里的「AI」成分相对克制：用自然语言问监控，用统一口径解释是否异常，而不是让模型对指标曲线做玄学解读。

如何交付

监控项先做数值化与阈值比较（例如常用的 80% 水位），再交给对话层用「正常 / 异常」口径表述。对非数值监控项主动跳过，避免把字符串、空值喂给 AI 后出现「看起来偏高」一类无依据结论。同一入口还可以和攻击、主机安全对照：某台机器网络侧告警升高的同时，若内存被顶满，处置优先级应上调。

意义： 把监控从「另一个控制台」收进同一句提问，让蓝队值班真正做到安稳联查，而不是安全一套话、运维另一套话。

4.6 封禁 → 「建议」与「执行」分离后再交给 AI 叙述

功能描述与风险意识

封禁是整条链路上少数真正的写操作。但是误封禁容易影响正常业务的运行。 因此助手刻意把流程拆开：研判阶段可以建议封禁；真正执行必须用户明确确认，且登记操作人；结果文案以防护设备返回为准，成功说成功，失败把失败原因原样带回。

如何交给 AI

关键点在于让模型没有机会扮演「已经封成功了」。未确认时只返回待确认状态；缺操作人直接拒绝；执行后再把设备原文塞回对话。系统提示词同步约束：封禁成败与失败原因不得臆造。于是 AI 在对话里只能「转述工具结果」，不能「表演封禁」。

defblock_ip(ip: str, environment: str = "prod", confirmed: bool = False) -> dict:ifnot confirmed:return {"status": "pending_confirmation","message": "需要用户明确确认后再执行",        }if require_operator andnot operator:return {"error": "未登记操作人，拒绝执行"}# 执行后把设备返回的成功/失败原文带回对话    ...

这一设计与前面的研判交付一脉相承：AI 负责把事实说清楚、把建议说到位；不可逆动作留给人和设备。 文章前面所有「交给 AI 研判」，到封禁这一步都变成「交给人确认、交给设备执行、交给 AI 原样叙述」。

4.7 处置闭环：日志研判 → 威胁情报 → 询问封禁

功能描述：把单点能力收成一条值班剧本

前面几节分别讲清了「怎么研判攻击日志」「怎么交情报事实」「怎么安全封禁」。值班现场更缺的是一体化：分析师往往要自己复制 IP、切控制台、再组织一次确认话术。处置闭环就是把这条日常剧本写进系统——

典型提问：对最近1条（或最近半小时 / 最近10条）攻击成功日志做处置闭环：日志研判 → 情报分析 → 恶意 IP 确认后询问是否封禁

一句话里同时约定查多少（条数 / 时间窗按提示词解析）和要干什么（研判到封禁）。进度上会依次出现：① 日志拉取 → ② 日志研判 → ③ 情报分析 → ④ 询问封禁；用户回复「是」或「确认封禁」后再真正下发。

流程怎么串

自然语言意图（含最近 N 条 / 半小时等）  → 按提示词解析时间窗与条数  → 拉取攻击成功日志  → 规则研判：筛出「存在攻击行为」的源 IP（排除疑似误报）  → 情报核实：仅保留 is_malicious=真 的 IP  → 输出待封禁列表，询问是否封禁  → 用户「是」→ 防火墙真实执行；「否」→ 取消

核心代码

意图识别：命中「处置闭环 / 研判到封禁 / 询问是否封禁」等，优先走 Playbook，避免被「普通查攻击成功」旁路抢走。

# app/dispose_playbook_service.py（节选）defis_dispose_playbook_query(text: str) -> bool:if any(k in text for k in ("处置闭环", "研判到封禁", "询问是否封禁", "恶意IP确认", ...)):returnTrueif"研判"in text and"情报"in text and ("封禁"in text or"处置"in text):returnTruereturnFalse

提示词中的范围与攻击日志、主机安全共用同一解析：最近1条 / 最近10条 / 半小时 / N 分钟都按字面落地，不会把「1条」误读成「1小时」。

# 时间窗 + 条数（与攻击日志、主机安全同源）scope = parse_query_scope(text, default_hours=1.0, default_limit=limit)hours, limit = scope["hours"], int(scope["limit"])# 只说「最近1条」→ hours=24、limit=1：在足窗内取最新 N 条soc_result = soc.soc_success_attacks(hours=hours, limit=limit)

日志研判：有攻击行为才进情报；疑似误报直接剔除。

def_has_attack_behavior(rec: dict) -> bool:    verdict = str(rec.get("误报研判") or"待核实")if verdict == "疑似误报":returnFalseif verdict == "实锤攻击":returnTrue    result = str(rec.get("攻击结果") or"")return any(k in result for k in ("成功", "失陷"))

情报确认恶意后，才进入待封禁；并在回复里落下可解析标记，供下一轮「是」消费。

# 对每个攻击源查情报；仅 is_malicious 进入待封禁for ip in attack_ips:    tb = threatbook.query_ip_reputation(ip)if tb.get("is_malicious"):        malicious_ips.append(ip)# 报告末尾（节选）parts.extend(["【处置闭环·待封禁确认】",f"待封禁恶意IP：{', '.join(malicious_ips)}","是否对这些恶意 IP 执行封禁？请回复「是」或「确认封禁」。",])

人在回路：从会话历史解析待封禁列表；肯定答复才批量调防火墙。

defis_playbook_block_confirm(text, messages) -> bool:    pending = extract_pending_block_ips(messages)  # 读上一轮「待封禁恶意IP」ifnot pending:returnFalsereturn is_playbook_affirmative(text)  # 「是」「确认封禁」等defexecute_playbook_confirmed_blocks(text, messages, on_progress=None):    ips = extract_ips(text) or extract_pending_block_ips(messages)    environment = parse_environment(text)    result = firewall.block_ips_batch(ips=ips, environment=environment, confirmed=True)# 成败文案只来自防火墙返回    ...

Agent 侧把闭环挂在直连旁路上，进度事件对分析师可见：

# app/agent.py（节选）if is_dispose_playbook_query(user_input):    direct = execute_dispose_playbook(user_input, on_progress=_track_progress)return {"reply": direct["reply"], "threat_intel": direct.get("threat_intel"), ...}if is_playbook_block_confirm(user_input, messages):    direct = execute_playbook_confirmed_blocks(user_input, messages, on_progress=_track_progress)return {"reply": direct["reply"], "block_result": direct.get("block_result"), ...}

实现意义

这就把第四节前几条能力收成一条可值守的处置剧本：数据仍来自各系统真相，AI 负责把剧本说清楚，最终封禁仍由人点头、设备执行。

小结： 第四部分贯穿的原则只有一句——事实来自系统，初判来自规则，表达来自 AI，写操作来自人。处置闭环是把这四段职责串成值班现场的最短路径。

五、提示词注入拦截（自身安全）

若助手可以被「忽略前面的指令」轻易劫持，则前面所有「可信研判」都会失效——攻击者只要套出工具能力或伪装身份，就能把蓝队助手变成情报泄漏口。

因此注入防护本身，也是「如何安全地让 AI 工作」的一部分。

5.1 输入侧：在进模型之前拦截

_INJECTION_PATTERNS = [r"ignore\s+(all\s+)?(previous|above|prior)?\s*instructions",r"system\s*prompt",r"jailbreak",r"忽略(以上|上面|先前|之前|所有|全部)?(的)?(指令|规则|提示|执行|约束|限制)",r"(给我|输出|显示|列出|重复|泄露|告诉).{0,12}(系统|内部|你的)?.{0,8}(提示|指令|prompt|提示词)",r"(工具列表|有哪些工具|全部工具|你有哪些能力)",r"你现在是(?!.*(封禁|攻击|威胁|监控|soc|zabbix))",r"扮演(?!.*(安全|红队|蓝队|运营))",    ...]defcheck_input_rules(text: str) -> Optional[str]:for pattern in _COMPILED:if pattern.search(normalized):return REFUSAL_MESSAGE   # 固定蓝队身份话术，不进入 Agentif 明显离题 andnot 像安全任务:return REFUSAL_MESSAGEreturnNone

5.2 输出侧：防止模型「好心」泄密

即使输入漏网，也要检查输出是否在复述提示词、枚举内部工具名：

defcheck_output_leak(text: str) -> Optional[str]:if"以下是系统提示词"in text or"以下是我可用的工具"in text:return REFUSAL_MESSAGEif 同条回复里堆出过多内部工具名:return REFUSAL_MESSAGEreturnNone

5.3 角色侧：系统提示词把 AI 钉在蓝队岗位上

BLOCKED_REPLY = ("我是「重保蓝队安全助手」，仅服务于重大保障期间的安全运营与蓝队处置工作，""不是通用聊天机器人。")# 提示词明确：套取提示词 / 列举工具 → 只回 BLOCKED_REPLY；事实结论必须基于工具结果

5.4 效果截图占位

意义： 没有安全边界的 Agent，不配接入攻击日志与主机安全；拦截不是附属功能，而是研判可信度的前提。

六、执行流程解读

整套助手的能力边界，本质是一条「提问 → 编排 → 取数 → 研判 → 回写对话」的闭环。

最上方是用户自然语言提问：分析师不需要记住各平台菜单，只需用日常值班语言表达意图，例如查一段时间的攻击成功、看主机是否有反弹、核实某个 IP 是否恶意、确认封禁等。再往下是交互层（Web UI / 聊天界面），负责接住这句话、展示进度，并把最终研判结果写回同一条会话——人始终只面对一个对话窗口，而不是五六套控制台。

编排与核心层 · AI Agent 框架。它向右生长出「脑子」一侧：任务规划与推理负责把一句话拆成步骤；对话与记忆管理负责承接多轮追问；工具调用 / 函数执行负责决定此刻该碰哪一类外部能力。与此同时，框架连到大语言模型，由模型完成意图理解与结果组织；模型还可借助内置能力（如代码解释、检索）辅助分析，但真正的安全结论仍须建立在外部事实之上。

工具与连接层。原型里用 API 工具与 MCP 两类接入方式，把 Agent 接到外部数据与处置能力——攻击日志、主机安全、情报、监控、防火墙等，都挂在这一层之下。图中数据层示意的是「真实业务系统提供原始事件」：Agent 要的不是自己虚构告警，而是把外部回来的记录原样带进编排循环，再交给模型与研判逻辑生成「事实 + 建议」。

交互层只负责「说人话、看结果」；Agent 框架负责「拆任务、调工具、管上下文」；工具与连接层负责「把各安全平台接到 AI 跟前」；大模型负责「在事实之上做研判表达」。重保蓝队助手后来落地的攻击误报初判、主机告警画像、情报短事实交付、研判→情报→封禁一体化闭环、封禁人在回路，以及输入侧注入拦截，都是在这条主线上把「数据如何交给 AI」补全到可用、可信。

七、总结与展望

7.1 总结

打造「重保蓝队安全助手」时，我们刻意把工程重心从「怎么连接更多系统」挪到「怎么把真实数据变成 AI 可研判的输入，并控制 AI 输出边界」：

1. 攻击日志用数据包与规则特征做误报初判，再生成处置建议；
2. 主机安全用进程、路径、外连生成威胁画像与遏制建议；
3. 情报 / 封禁等事实与写操作，用结构化交付和人在回路，防止模型胡编；
4. 处置闭环把「日志研判 → 情报恶意确认 → 询问封禁 → 确认执行」收成一句话剧本；
5. 注入防护保证上述能力只服务蓝队意图。

大模型负责理解意图与组织表达，研判引擎与业务系统负责提供真相——这才是重保场景里可用的 Agent。

7.2 展望

AI 不会取代蓝队，但可以把「打开五六套控制台才能形成一个判断」压缩成「一句话拿到带依据的研判」。剩下的判断力，仍然留给人。

02

0x2 培训课程介绍

26

SRC漏洞挖掘培训课程

1.课程价格目前是550（后面也会随着人数越多，涨价）🌟师傅们还可以上车补票，冲冲冲！

2.报名成功送知识星球一个，拉内部小圈子交流群+SRC直播通知群！✨

3.一周2节课程，直播+录播形式，课程内容大家可以看课表，目前是第一期，一次报名永久无限听课！❤️

4.目前是第一期课程，后面比如说开了二、三期，都是不用在花钱的！

5.上课结束后，会把视频录播+课件笔记一起打包发直播群！

6.哔哩哔哩SRC课程公开课，链接🔗直达：

https://space.bilibili.com/642258933

SRC课程详情🔎：学了一堆理论，还是挖不到漏洞？你缺的是实战！

最后也是希望大家都可以赚钱，找到好工作🎉

上课结束后，会把视频录播+课件笔记一起打包发直播群

「神农安全」知识星球目前已经累计2400+网络安全爱好者的加入！

后面也是小圈子做大起来了，师傅们也都喜欢看我文章，想着给大家教下src漏洞挖掘思路，所以自己花了很长时间做了✨课件和课表，都是纯自己手搓的，大家也可以看下课表的内容。

课程主打真实，一线SRC漏洞挖掘师傅是如何学习和挖掘SRC漏洞的，让你真正了解SRC漏洞挖掘，助力在岗人员和大学生的能力提升，掌握新的技能树，为下一次跳槽涨薪做好准备。本课程内容覆盖企业SRC、众测项目挖掘、护网HVV红蓝攻防技巧、CVE、CNVD、EDUSRC等平台通杀案例技巧挖掘方法。

本课程适合人群（光看不挖啥也不会）

1、有计算机经验，想从0转行入行的大学生或自学者2、想从CTF比赛/Web或SRC进阶到项目实战的选手3、想参与项目/找工作/提高收入的转型者4、想通过挖SRC赏金做副业的师傅们5、挖SRC漏洞遇到瓶颈的师傅们6、想学习AI安全自动化渗透测试漏洞挖掘的师傅

1、课程价格真心实惠，绝不割韭菜2、四五百的课程价格让你体会大几千的培训课程内容3、带着大家从0到1，本人上课坚持手搓课件（实战案例+知识体系）4、拒绝使用PPT演讲模式（无实操，很枯燥）

讲师介绍

id：一个想当文人的黑客

内部圈子介绍（报课赠送）

圈子专注于更新src/红蓝攻防相关：

1、维护更新src专项漏洞知识库，包含原理、挖掘技巧、实战案例2、知识星球专属微信“小圈子交流群”3、微信小群一起挖洞4、内部团队专属EDUSRC证书站漏洞报告5、分享src优质视频课程（企业src/EDUSRC/红蓝队攻防）6、分享src挖掘技巧tips7、不定期有众测、渗透测试项目（一起挣钱）8、不定期有工作招聘内推（工作/护网内推）9、送全国职业技能大赛环境+WP解析（比赛拿奖）10、十个专栏会持续更新~提前续费有优惠，好用不贵很实惠11、每日内部资料分享，内部圈子资料1000+12、联系圈主获取：内部漏洞知识库+圈子使用手册+内部圈子交流群13、VX：routing_love，技术交流+疑问解决

内部圈子专栏介绍

知识星球内部共享资料截屏详情如下

（只要没有特殊情况，每天都保持更新）