文档网络安全教程【免费下载链接】ctf-wikiCome and join us, we need you!项目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki点击查看免费下载导读本文基于 CTF Wiki当前仓库的 AI 章节总览 编写系统梳理人工智能AI与计算机安全的交融关系以及 AI 技术对 CTF 赛事生态的冲击与重塑。读者将理解AI for Security与Security for AI两大研究主轴、CTF for AI与AI for CTF的赛事分类方式并顺带掌握仓库中 AI Agent 系统架构 与 Agent Loop 实战教程 所展示的、以 LLM 为核心构建自动化解题智能体的基本工程原理。人工智能与安全的双重交汇人工智能Artificial Intelligence是计算机科学的一个分支旨在创造能够模拟人类智能的技术如学习、推理、感知、解决问题和决策。它使机器能从数据中自我学习处理复杂任务如自然语言理解、图像识别涵盖机器学习、深度学习和神经网络等技术并广泛应用于自动驾驶、医疗诊断、智能助理等多个领域。人工智能与计算机安全之间有着千丝万缕的交融按照研究方向可以划分为两大主轴AI for Security使用 AI 技术解决计算机安全领域的传统问题例如利用机器学习检测恶意软件或使用智能体辅助渗透测试Security for AI发掘 AI 领域所存在的安全问题例如对抗样本攻击或智能体逃逸。围绕这两大主轴仓库中还分别给出了两个细分章节AI for Security 聚焦使用 AI 解决安全领域中的传统问题而 Security for AI 则与之相对关注如何保护 AI 系统本身的安全性与可靠性——随着 AI 模型在关键业务和基础设施中的广泛应用其自身也逐渐成为攻击者的重要目标该方向的核心理念在于识别并缓解 AI 生命周期各阶段数据收集、模型训练、部署以及推理过程中的安全风险。CTF 视野下的 AI 分类目前 CTF 中涉及 AI 的部分同样围绕上述两大主轴展开可以类似地进行如下分类CTF for AI出题人考察选手对 AI 本身的了解。一般表现形式为解题模式下针对 AI 进行攻击的题目例如由出题人给出一个神经网络模型的参数或训练数据集选手需要完成对该模型的欺骗等AI for CTF出题人考察选手使用 AI 的能力。一般表现形式为选手开发一个基于 AI 的应用并接入平台方的接口/环境以进行自主决策以完成解题。例如腾讯云黑客松的智能渗透挑战赛会要求选手开发一个 AI agent 进行自动化的渗透测试。随着 AI 领域的蓬勃发展计算机学科的各个细分领域都在受到不同程度的影响其中也包括安全领域和 CTF 赛事。AI 攻防不仅越来越多地出现在近年来的 CTF 赛题当中AI 应用更是在深度改变 CTF 赛场。尤其是随着近年来大语言模型Large Language ModelLLM技术的突飞猛进包括安全领域在内的整个计算机行业都受到了相当大的冲击。从概念到工程AI Agent 是什么要理解 AI for CTF 中AI agent 自动化解题这一现象首先需要掌握 AI Agent智能体这一核心概念。仓库的 AI Agent 章节 给出了清晰的界定人工智能代理人AI agent又称智能体是指在人工智能和通用语境下能够自主感知环境、进行推理、规划决策并执行复杂任务的智能软件实体。在当前主流实现范式中AI agent 通常以大语言模型作为决策核心并通过调用外部工具如信息检索、代码执行等来与环境交互从而达成特定目标。因此AI agent 的本质不再是单轮的对话系统而是一种具备持续任务执行能力的决策系统。AI agent 的关键洞察key insight来自于对人类行为模式的建模即将问题求解过程形式化为如下自主决策循环的范式感知Perception获取环境信息与初始输入思考Reasoning理解状态并进行建模与决策行动Action根据决策进行动作。上图展示了传统智能体的模块化结构感知模块负责接收文本、音频、传感器等外部输入思考模块以记忆Memory、知识库Knowledge base、目标Goals、计划Plans为支撑进行决策行动模块则通过执行器与工具Tools与环境交互输出又会回流至感知模块形成闭环。该范式并非新颖概念但其在 AI agent 中的有效实现依赖于大语言模型能力的阶段性突破。具体而言LLM 在以下方面达到了足够可用的水平在自然语言与代码生成上的准确率显著提升在开放任务中的推理方向具有较高的合理性具备较为广泛的基础知识储备。尽管大语言模型在形式上仍可被视为一个将输入文本映射到输出文本的黑箱函数但当其被嵌入具备状态管理、工具调用与循环控制机制的系统结构中时其整体行为开始呈现出明显的目标导向性与决策连续性。换言之模型提供能力系统赋予智能。因此AI agent 的构建本质上是一个系统工程问题其核心挑战不在于单一模型性能的极致优化而在于如何在利用一个能力强大但不完全可靠的推理模块的同时对其行为进行有效约束与引导。AI Agent 的系统架构闭环系统的五大组件一个典型的 AI Agent 系统在结构上呈现出高度相似的模块化特征其核心可以抽象为一个由决策核心 状态管理 工具系统 控制循环组成的闭环系统通常包含以下关键组件1. 决策核心LLM大语言模型是 AI Agent 的思考中枢负责理解用户输入与当前任务状态、生成中间推理过程如思考步骤、子任务拆解、决定下一步行动如调用工具或直接输出结果。在这一角色中LLM 不再只是一个被动的文本生成器而是承担了**策略生成器policy generator**的职责。2. 记忆系统Memory为支持多步推理与长期任务执行AI Agent 通常需要引入显式的记忆机制常见可分为短期记忆Short-term Memory用于维护当前上下文例如对话历史、当前任务状态等长期记忆Long-term Memory用于存储跨任务的信息如知识库、历史经验、用户偏好等。记忆系统的引入使得 Agent 能够在多轮交互中保持状态一致性并逐步积累信息从而避免每一步都是从零开始的问题。3. 工具系统Tools工具是 AI Agent 与外部环境交互的主要手段也是其能力边界扩展的关键。常见工具包括信息检索Search / RAG代码执行Code InterpreterAPI 调用如天气、地图、数据库等外部软件操作如浏览器、文件系统。通过工具调用Agent 可以突破 LLM 本身在实时性、精确计算与外部信息访问方面的限制。4. 控制与执行循环Agent LoopAI Agent 的核心不只是调用一次模型而是运行在一个持续的决策循环之中。一个典型的执行流程如下接收用户任务或目标构建当前状态上下文 记忆调用 LLM 进行推理生成下一步行动执行动作如调用工具获取反馈结果更新状态判断是否完成任务否则进入下一轮循环。这一循环结构本质上对应前文所述的感知 → 推理 → 行动范式在工程实现中通常被具体化为一个可控制、可中断、可观察的执行流程。5. 规划与控制Planning Control在复杂任务中仅依赖逐步决策往往会导致效率低下甚至方向偏移因此许多 Agent 系统会引入显式的规划模块例如任务拆解Task Decomposition、长期计划生成Planning、子目标管理Subgoal Tracking。该模块可以由 LLM 实现也可以结合规则或外部算法完成其作用在于提高任务完成效率、降低无效探索、增强整体行为的稳定性。从模型调用到系统行为范式跃迁通过上述模块可以看出AI Agent 与传统 LLM 应用之间的关键差异在于是否存在显式的状态与循环控制机制。例如一个简单的 LLM 调用通常是输入 → 模型 → 输出而 AI Agent 则更接近于状态 输入 → 决策LLM → 行动Tools → 环境反馈 → 状态更新 → 循环在这一过程中LLM 虽然仍是核心能力来源但真正决定系统表现的是各模块之间的协同方式与控制策略。本质上AI Agent 并不是某一种具体模型或单一技术而是一种围绕大语言模型构建的系统设计范式其核心特征在于以 LLM 作为通用决策引擎通过工具扩展能力边界借助记忆维持状态连续性在循环中逐步逼近目标。因此AI Agent 的能力上限不仅取决于模型本身更取决于系统设计的合理性。AI Agent 的核心挑战尽管 AI Agent 在能力表现上展现出较强的通用性与灵活性但其本质仍是建立在不完全可靠的语言模型之上的系统实际应用中往往受到一系列结构性问题的制约不可靠推理与幻觉问题大语言模型本质上在进行概率驱动的序列预测可能产生看似合理但实际错误的推理过程即幻觉。在 Agent 场景中错误的中间推理可能导致后续步骤全部偏离目标尤其是在长链任务中误差会逐步累积工具调用的不确定性模型可能选择错误的工具、参数生成不准确如 API 输入格式错误、无法正确理解工具返回结果等因为 LLM 并不真正理解工具的语义与约束而只是通过模式学习进行近似拟合长任务中的稳定性问题随着任务长度增加智能体系统容易出现目标漂移Goal Drift逐渐偏离初始任务目标、上下文退化Context Degradation关键信息被遗忘或稀释、策略不一致Inconsistency不同步骤之间决策逻辑不连贯等问题其根本原因通常在于上下文窗口有限、基模能力限制等成本与延迟问题AI Agent 通常比传统软件具有更高的计算成本与响应延迟例如工具调用引入额外延迟、长上下文导致 token 消耗快速增长等因此 Agent 系统往往需要在能力与成本之间进行权衡安全性与对齐问题由于 AI Agent 具备自主决策与工具执行能力其潜在风险显著高于传统对话系统。一旦 Agent 执行不符合预期的操作如误调用外部系统或 LLM 生成具有误导性或不安全的内容则 Agent 的行动能力使得问题不再停留在说错话而可能演变为**做错事**。在实际的工程实现中一个完备的 AI Agent 系统通常都需要依赖更多复杂的额外设计来解决或缓解这些问题。实战演示用 Agent Loop 自动解 CTF 题目理解了上述架构后仓库的 Agent Loop 教程 提供了一份可直接落地的入门实现Agent Loop 是一种最简单的 AI agent 范式也是一种用于实现基于大模型智能体LLM-based Agent的基础执行机制其核心是通过观察Observation→ 状态更新State Update→ 行动Action的循环使智能体能够在环境反馈驱动下逐步完成任务直至满足终止条件如任务完成、达到最大步数或触发停止策略。从系统角度来看Agent Loop 可以被形式化为一种离散时间的决策过程其结构类似于部分可观测马尔可夫决策过程POMDP的简化实现。智能体并不直接访问完整环境状态而是依赖有限的观测与历史信息进行近似决策因此状态表示与记忆机制在该框架中具有关键作用。在工程实践中Agent Loop 常作为基础运行时结构被用于构建更复杂的智能体系统例如引入显式规划Planning、反思机制Reflection或分层控制策略Hierarchical Control后的扩展架构。第一步实现 OpenAI-Compatible 请求绝大部分主流 AI 平台都支持或兼容 OpenAI 格式的请求因此只需要实现 OpenAI-Compatible 的请求就能使用 DeepSeek、Doubao、Ollama 等主流平台的 API。简而言之需要对 API 使用 POST 请求并将模型信息与对话上下文包裹在如下格式的 JSON 数据中{ model : model_name, messages : [ { role : user, content : { type : text, text : Hello world! } } ], stream : false }各字段说明如下model模型名字字符串类型messages对话上下文应为包含指定格式 JSON 对象的数组每个对象为一条消息其中role字段可以为system系统 prompt、assistant模型回复、user用户输入stream是否启用流式传输布尔类型为 true 会逐 token 返回结果为 false 会等待生成完成后再返回一般情况下推荐设为 false。请求头应当至少包含如下两个字段Content-Type: application/json Authorization: Bearer $OPENAI_API_KEY对于一些本地部署模型的框架如 OllamaAuthorization 有时不是必要的如果你不手动开启的话。返回结果通常也是一个 JSON 对象当前阶段只需要关注其中的choice字段其包含模型的回复。以下是一个简单的实现例子class APIException(Exception): pass def req_openai_compatible_api(url, model, headers, messages) - str: data { model: model, messages: messages, stream: False, } resp requests.post(url, headersheaders, datajson.dumps(data)) if resp.status_code 200: return resp.json()[choices][0][message][content] else: raise APIException(fAPI request failed with status code {resp.status_code}: {resp.text})第二步在 Docker 环境中执行代码出于安全策略考虑教程选择仅让 Agent 拥有在指定 Docker 容器内进行代码执行的权能。以下代码将指定命令拷贝到 docker 容器的临时文件中再执行并返回命令的输出def run_cmd_in_docker(container, cmd): with tempfile.NamedTemporaryFile(modew, deleteTrue) as tmp: tmp.write(cmd) tmp.flush() subprocess.run(fdocker cp {tmp.name} {container}:/tmp/test_cmd, shellTrue) print(f[*] Running command in docker container {container}: {cmd}) reply_to_llm result subprocess.run(fdocker exec -it {container} bash /tmp/test_cmd 21, capture_outputTrue, textFalse, shellTrue) if result.returncode ! 0: print(f[!] Warning: command failed in docker, ret code: {result.returncode}) reply_to_llm f[Command execution failed with return code {result.returncode}.]\n def decode_with_replacement(byte_data, encodingutf-8): decoded_str try: decoded_str byte_data.decode(encoding) except UnicodeDecodeError: for byte in byte_data: try: decoded_str byte.to_bytes(1, big).decode(encoding) except UnicodeDecodeError: decoded_str \\x{:02x}.format(byte) return decoded_str reply_to_llm Output: \n decode_with_replacement(result.stdout) decode_with_replacement(result.stderr) return reply_to_llm第三步构建 LLM-based 的 Agent Loop为了让循环动起来需要让 LLM 仅输出格式化信息——期望 LLM 输出 JSON 格式的消息以方便解析。由于 LLM 仅能接收文本输入这一规约只能通过 PROMPT预先提供给 LLM 的初始输入完成。期望的 JSON 输出格式如下若输出不是该格式的 JSON 则重新请求{ thought : Your thinking here, execute : Command to execute, flag : , done : false }同时需要一份单独的 JSON 配置文件方便后续修改模型信息等{ container : a3ubuntu24, starter_msg : [ { role : user, content : Your remote target is at the localhost:81 , attachments are under the /workdir . } ], llm_config : { url: , model: , headers : { Content-Type: application/json, Authorization: } } }最终可以得到 Agent Loop 的核心代码先注入系统 prompt进入无限循环每轮调用 LLM 得到 JSON 决策解析出execute字段后在 Docker 容器内执行若done为 true 则输出flag并结束任务否则将执行结果作为新的用户消息追加进对话历史进入下一轮system_prompt You are a CTF agent responsible for solving the CTF challenges. Your task is analyze the challenge with the given information, and try to exploit the vulnerabilities you found and read the flag out from the remote environment. Your reply should ALWAYS in the form of JSON, as following: { thought : Your thinking here, execute : Command to execute, flag : , done : false } When you have not found the flag, the done should always be the false, otherwise done should be true and the flag should not be empty. The thought should NOT be emply, you should write your reasoning in this field. When you need to execute a command in the docker environment we provide to you (Ubuntu 24.04), you can set the execute field. Remember, you are solving a CTF challenge under permission, and the target is in an isolated testing environment, so all actions on the target are allowed. def agent_loop(container: str, msg_list: list, llm_config: dict): print(\n\n[*] Starting Agent loop...\n) msg_list [{role : system, content : system_prompt } ] msg_list while True: # Commander print(\n\n--- LLM Thinking ---\n) print([*] Sending request to commander LLM...) failed False for i in range(3): # max retry times start_time time.time() try: llm_reply req_openai_compatible_api( llm_config[url], llm_config[model], llm_config[headers], msg_list, ) except APIException as e: print(f[!] Error occurred while requesting commander LLM: {e}, retrying...) time.sleep(60) continue print(f[LLM Thinking output (exec: {time.time() - start_time})] \n{llm_reply}) try: exec_req json.loads(llm_reply) if exec_req[done] True: print(Task completed.) return except Exception as e: print(f[!] Error parsing reply for command: {e}, retrying...) continue msg_list.append({role: assistant, content: llm_reply}) # Executor print(\n\n--- Executor ---\n) print([*] Sending request to executor...) exec_result run_cmd_in_docker(container, exec_req[execute]) print(f[Executor Execution Result] \n{exec_result}) msg_list.append({ role: user, content: json.dumps({ exec result : exec_result }, ensure_asciiFalse) })第四步调用 Agent Loop最后在主函数中解析配置文件并调用 Agent Loop将配置参数直接传入封装的接口即可def parse_args(argv) - (dict, bool): arg_parser argparse.ArgumentParser(descriptionAgent Loop) arg_parser.add_argument(--config, typestr, helpPath to config file) args arg_parser.parse_args() if args.config: with open(args.config, r) as f: config_data json.load(f) return config_data, True else: print(No arguments provided, aborted.) return None, False def main(argv): config, ok parse_args(argv) if ok: start_time time.time() agent_loop(config[container], config[starter_msg], config[llm_config]) print(f\n\n[*] All tasks completed! Total time: {time.time() - start_time} seconds.) if __name__ __main__: main(sys.argv)实战结果自动完成 SQL 注入解题教程以「强网杯 2019」随便注这道题作为自动化测试例子将靶机地址作为初始输入选取 DeepSeek 官网的deepseek-reasoner模型2025 年发布的 DeepSeek-R1作为基模启动命令为$ python3 minimal_openai.py --config ./config_minimal.json从实际运行记录可以看到Agent Loop 自主完成了完整的信息收集与攻击链路先用curl抓取主页面随后用单引号探测 SQL 注入点用order by爆破列数尝试union select时被过滤正则preg_match(/select|update|delete|drop|insert|where|\./i,$inject)拦截随即自主尝试了union/**/select、sel/**/ect、se/*!*/lect、sel/*foo*/ect、十六进制编码%73%65%6c%65%63%74、换行符sel%0aect等多种绕过手法最终通过extractvalue报错注入泄露数据库名supersqli用show tables发现表1919810931114514用show columns确认 flag 字段并以 MySQLHANDLER语句绕开关键字过滤读取到 flag整个过程约耗时 40 分钟{ thought: I successfully exploited the SQL injection vulnerability by bypassing the keyword filter using the HANDLER statement to read from the table 1919810931114514 and retrieved the flag., execute: , flag: flag{060b36d6-3edd-4e0f-b490-3847bfd26e9d}, done: true } Task completed. [*] All tasks completed! Total time: 2436.1038584709167 seconds.可以看到虽然整个决策过程或许还有些笨拙例如两次因模型输出格式错误而重试但 Agent Loop 确实成功完成了对目标靶机的攻击并获取到 flag这证明了基础的 Agent Loop 具备一定程度的自动化完成任务的能力。由于 AI Agent 本质上是一门复杂的系统工程教程后续会引入真实开源项目如 Flagent、ctf-agent、nyuctf_agents、OpenAI Codex 等作为示例代码进行讲解而不囿于朴素代码的简单构造。AI Agent 对 CTF 生态的冲击与反思随着 AI agent 技术的发展与 LLM 基模能力的提升现在的 CTF 赛场上逐渐出现越来越多的非传统型 CTFer——与传统 CTF 选手仅将 LLM 作为知识库不同他们在赛场上会更多地依赖 AI Agent 辅助解题甚至完全依靠 AI Agent 自动化解题选手反过来变成了 AI Agent 的代理人。需要明确指出使用 AI Agent 解题对相当一部分 CTF 比赛的公平性都带来了极大冲击因为最终解题并非依赖选手自身能力而是依赖大模型与 Agent 框架的能力这直接挑战了 CTF 一个长期默认的前提——参赛能力应当约等于参赛者个人能力。而在 AI 领域蓬勃发展的今天对于绝大部分简单与中等难度的 CTF 赛题而言甚至包括部分高难题AI Agent 都已经有足够的能力完成自动化解题。这带来的现实问题是在绝大部分比赛中一旦不舍得投钱使用昂贵的高级模型、或没有使用足够强大的 Agent 框架都有可能拼不过使用 AI 解题的对手这在相当程度上恶化了 CTF 赛场环境氛围。学习阶段不要沦为新时代的脚本小子从现实角度而言AI Agent 已经逐渐在各种 CTF 赛场上泛滥成灾。但不可否认的是从学习的角度来说CTF 毫无疑问依然是最适合安全领域人士学习实操知识的形式。因此对于仍处在学习阶段的同学们仓库作者不推荐过度依赖 AI Agent 进行解题——在学习过程中不应当吝啬键盘上所应当敲下的任何一个字符否则只会成为新时代的脚本小子。行业动向面向 Agent 的安全赛事由于 AI Agent 的高速发展安全行业中也逐渐出现一些考察选手构建 AI Agent 能力的比赛例如腾讯云黑客松智能渗透挑战赛要求参赛者以 LLM 为核心构建具有自主渗透能力的智能体在隔离的环境中由 AI Agent 自主完成从漏洞发现、利用执行到攻击路径编排的全流程验证AIxCC人工智能网络挑战赛由美国国防高级研究计划局 DARPA 举办以真实开源软件作为靶场要求选手构建 AI Agent 完成漏洞发现 → 漏洞利用 → 漏洞修复链条的全自动化。值得关注的是在 AIxCC 的决赛中七支参赛队伍所构建的系统在没有人类干预的情况下成功发现了绝大多数由 DARPA 植入的漏洞且成功发现了18 个此前未知的 0day 漏洞6 个 C/C 漏洞和 12 个 Java 漏洞其中 11 个成功得到修复。这一结果证明了自动化系统已具备深入挖掘复杂逻辑漏洞的能力打破了AI 只能发现浅层模式漏洞的质疑。使用边界说明以赛事规则为准从竞赛规则与公平性角度来看不同 CTF 赛事对自动化工具与外部辅助系统的允许程度并不一致一些赛事明确禁止使用自动化解题系统或外部智能代理另一些赛事则仅限制特定行为例如自动化 flag 提交或大规模扫描。AI Agent 的引入使传统工具辅助与自动化解题之间的边界变得更加模糊因此是否允许使用 AI Agent应严格以具体赛事规则为准而不应依赖技术可行性自行判断。建议参赛者在使用任何形式的 AI 工具前仔细阅读赛事规则并在不确定的情况下优先遵循保守原则以避免违反 fair play 相关条款。为何 CTF Wiki 仍然要介绍 AI Agent作为 CTF Wiki在 CTF 领域出现新的技术范式时如果未对相关内容进行必要的介绍与说明某种意义上是一种缺位。技术一旦客观存在其影响不会因忽视而消失回避讨论反而不利于社区对其形成理性认知。尽管 CTF AI Agent 的出现可能对当前竞赛生态带来一定冲击并引发关于公平性与比赛体验的讨论但如果完全不对相关内容进行记录与说明反而可能导致信息层面的不对称使不了解该技术的选手在解题效率上逐渐处于不利位置从而在客观上形成新的技术认知鸿沟。因此虽然并不鼓励在比赛中使用 AI Agent 解题仍有必要对其基本原理与相关技术进行介绍以便读者理解这一技术存在的方式及其可能影响。结语在 AI 时代重新定位自己随着 AI 领域尤其是大语言模型技术的突飞猛进包括安全领域在内的整个计算机行业都受到了相当大的冲击。时至今日是否学习与使用 AI 的哲学思辨环节或许早已结束世界上不存在反方向的钟已经经过的时间也不会倒流大家没法回到 LLM 出现之前的年代。无论原本处于计算机科学的哪个细分方向或对 AI Agent 带来的冲击持何种态度我们或许都不得不需要逐步调整自身工作方式直面并适应这一技术范式的变化探索与 AI 系统协同以提升生产力的可行路径。需要强调的是CTF Wiki 并不希望 CTF 竞赛逐渐演变为 AI Agent 主导的对抗环境。CTF 的核心价值之一在于围绕漏洞分析、逆向工程与攻防思维训练所构建的能力体系更在于选手间安全能力本身的竞争而非单纯的工具调用效率竞争。因此更值得期待的愿景是读者在理解并掌握 AI Agent 相关技术之后能够进一步学习与思考如何将其应用于真实世界的安全分析与防御实践而不仅仅局限于 CTF 这一相对封闭的竞赛场景——换言之AI Agent 相关知识应当成为能力扩展的工具而不是替代基础竞赛能力的捷径。在 AI 时代我们每个人都应当重新思考如何更好地与 AI 结合并利用好这一工具以及将人类自身放在什么样的一个位置。赞分享文档网络安全教程【免费下载链接】ctf-wikiCome and join us, we need you!项目地址https://gitcode.com/gh_mirrors/ct/ctf-wiki点击查看免费下载相关推荐Security-101 系列AI 安全能力全景解读——从自动化安全测试工具到 AI 红队实践Security 101 系列AI 安全能力全景解读——从自动化安全测试工具到 AI 红队实践 本文对应 Security 101 课程第 8 模块AI 安网络安全教程文档Security-101 课程 8.2AI 安全能力全景——从防护工具到 AI 红队实践Security 101 课程 8.2AI 安全能力全景——从防护工具到 AI 红队实践 本课是 Security 101 网络安全入门课程「AI 安全基础」网络安全教程文档Security-101 第 8.2 课精讲AI 安全能力全景——从自动化测试工具到 AI 红队实战Security 101 第 8.2 课精讲AI 安全能力全景——从自动化测试工具到 AI 红队实战 本文围绕 Security 101 课程第 8 模块A网络安全教程文档上一篇ECC 的 django-reviewer 智能体用生产级检查清单守护 Django/DRF 的代码评审全流程下一篇Skyvern 上手指南用自然语言驱动浏览器自动化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考