在实际安全工作中，很多想切入 AI 渗透方向的工程师都会遇到同一个瓶颈：不是不会用工具，而是被一堆概念卡住了。LLM、Skills、MCP、模型、智能体，这些词在安全文章里频繁出现，但每一项到底解决什么问题、彼此之间怎么配合、做一次合规的 AI 安全测试要从哪里开始，很少有人能用一段话讲清楚。本文面向完全零 AI 背景的安全工程师、运维人员和测试人员，也就是所谓“负基础”阶段，先把这些核心概念拆开讲明白，再给出环境准备、最小示例、验证方式和常见坑。
整篇文章围绕一条主线展开：理解 LLM 是大脑，模型是大脑的具体版本，Skills 是写好的经验手册，MCP 是大脑连接外部工具和数据的手脚，智能体是把它们组织起来执行任务的调度者。把这五层关系理顺之后，再去看各种 AI 安全工具、框架和平台，就不会被新名词绕晕。
1. 先厘清边界：LLM、Skills、MCP、模型、智能体各管哪一段
1.1 安全从业者学 AI 的认知断层在哪里
传统渗透测试的学习路径通常是“协议、端口、漏洞、工具、报告”这条线，技术栈相对固定。AI 渗透测试则不同，它横跨两个领域：一边是网络安全知识，另一边是大模型应用开发知识。问题是，很多安全资料默认读者已经知道什么是 Token、什么是上下文窗口、什么是 Agent 循环，结果读者从第一步就掉队。
另一个断层在于“工具链的归属搞不清”。比如看到一篇文章说“用 MCP 让 AI 调用 Nmap”，新手容易理解成 MCP 是一种扫描工具，实际上 MCP 只是让大模型能够调用外部工具的协议，真正的扫描逻辑仍在 Nmap 里。再比如“Skills”这个词，经常和“提示词”“插件”“工具”混在一起讲，实际上它有明确的结构化写法。概念错位会导致后面读代码、配环境、看日志时完全对不上。
还有一个实际问题：AI 渗透方向的学习材料很多是英文社区的碎片信息，不同项目对同一概念的定义有差异。与其盲目跟项目，不如先把概念层打通，再带着明确目标去读源码和文档。
1.2 用一句话给五个核心概念定位
为了后面不混乱，先给出一组精确定位：
| 概念 | 一句话理解 | 在 AI 安全测试中的角色 |
|---|---|---|
| LLM（大语言模型） | 一个能根据输入文本预测后续文本的神经网络模型 | 承担理解和生成的核心能力，相当于大脑 |
| 模型 | 训练完成后的具体权重文件和推理实现，如 Qwen、GPT、Llama 的某个版本 | 决定能力上限、上下文长度、运行方式（本地或 API） |
| Skills | 以 Markdown 等结构化文件写的技能手册，描述“遇到某类任务该怎么做” | 把团队的安全测试经验沉淀成可复用的方法步骤 |
| MCP | 一种让模型与外部工具、数据源通信的开放协议 | 让模型能读取文件、执行命令、查询数据库、调用扫描器 |
| 智能体（Agent） | 一个由模型驱动的循环程序：理解任务、规划步骤、调用工具、检查结果 | 把上面的能力组合起来自主完成一项测试任务 |
这五个概念不是并列关系，而是分层关系。模型是底座，LLM 是模型的一种形态，Skills 和 MCP 是模型能力的扩展方式，智能体是这些扩展能力的组织者。
1.3 一次授权测试任务中五者如何配合
用一个实际的合规场景说明。假设你所在团队要对一个内部系统做安全评估，老板要求先用 AI 工具辅助生成测试用例和核查配置基线。整个过程大致是这样：
- 你选一个本地部署的模型，避免把内部信息发送到外部 API。
- 在智能体平台里加载一个名为“配置安全检查”的 Skill，里面写明了你们团队自己总结的检查步骤：先看中间件版本、再看认证配置、再查敏感信息泄露。
- 通过 MCP 连接内部资产清单系统和漏洞数据库，模型可以实时查询目标系统信息。
- 智能体按 Skill 里的步骤逐项执行，每完成一步调用 MCP 工具取数据，再根据模型分析结果决定下一步。
- 最终输出一份带证据的报告，由安全工程师人工复核。
可以看到，单独的模型只会聊天，单独的 Skill 只是一份文档，单独的 MCP 只是一个通信协议。只有把它们组装成智能体，才能形成一条可执行的工作流。这也解释了为什么当前行业讨论的热点从“单个模型”转向了“智能体开发”。
2. LLM 基础：大语言模型本质是“预测下一个 Token”的引擎
2.1 核心机制：模型如何“听懂”人类语言
大语言模型的底层逻辑并不神秘。它做的事情本质上是在给定前面一串文字的情况下，计算下一个词（更准确地说，下一个 Token）最可能是什么。Token 是模型处理文本的基本单位，可以是一个单词的一部分、一个完整单词，或者一个标点符号。不同模型有不同分词方式，这也是为什么同一个问题在不同模型里消耗的 Token 数不一样。
安全从业者理解这个机制很重要，因为很多 AI 安全问题都源于这个“预测”本质。模型没有真正的“理解”，它的输出是基于训练数据中学到的统计规律。当模型被恶意构造的提示词诱导时，它只是在继续“预测”一段看似合理的文本，而不是在“执行”什么独立意志。这个认知能帮助你正确看待提示注入、越权输出等问题，而不是把模型拟人化。
2.2 上下文窗口、提示词与安全测试里最常用的能力
与 LLM 打交道时必须掌握三个基础点：
- 上下文窗口：模型一次能接收的 Token 总量。窗口越大，就能把更多任务说明、日志、配置内容塞进一次请求。实际使用中要估算输入输出长度，避免超出窗口导致报错。
- 提示词（Prompt）：输入给模型的文本，决定了输出方向和格式。安全测试里常用系统提示词限定“你是一名安全测试工程师，只输出 JSON 格式结果”这类约束。
- 输出解析：不要直接用肉眼读模型回复，建议要求模型输出固定结构（JSON、Markdown 表格），再用脚本解析。这样智能体才能把模型输出当作可处理的程序数据。
在授权安全测试场景里，LLM 最常见的用途包括：把一份配置 PDF 整理成检查项清单、把日志中的异常请求分类、根据漏洞描述生成修复建议、把模糊的自然语言需求翻译成结构化测试用例。这些任务都不需要模型具备真正的“黑客能力”，考验的是使用者能否把任务描述清楚、把输出格式约束好。
2.3 本地模型与 API 模型怎么选
选择模型运行方式，是安全从业者一开始就要做的决策。两种方式各有明确适用场景：
| 维度 | 本地模型 | API 模型 |
|---|---|---|
| 部署成本 | 需要 GPU 或较高内存，配置复杂 | 注册即可用，按 Token 计费 |
| 数据安全 | 数据不出内网，适合敏感环境 | 数据会发送到服务商，需评估合规风险 |
| 能力上限 | 取决于硬件和模型大小 | 一般更强，更新更快 |
| 网络依赖 | 无外部网络依赖 | 必须能访问对应 API |
| 典型场景 | 内网测试、涉密数据、离线环境 | 快速验证、非敏感任务、原型开发 |
实际项目里，很多团队采用“双轨”策略：日常研究用 API 模型快速跑通，正式评估内部系统时切换到本地模型。切换时要注意同一段提示词在不同模型上的输出可能差异很大，不能假设某个提示词在 A 模型有效，在 B 模型也一定有效。
3. Skills：把实践经验写成模型能读取的操作手册
3.1 Skills 解决什么问题
如果你只给模型一句“帮我检查这台服务器的安全配置”，结果通常不可控：模型可能给出泛泛而谈的建议，可能漏掉关键项，也可能输出一堆不适用于你实际环境的废话。Skills 要解决的就是这个问题：把“正确做法”固化成模型可以读取的结构化文件。
一个 Skill 本质上是一份带有前置说明的 Markdown 文档，里面写清楚技能名称、适用场景、执行步骤、输出格式和注意事项。模型在遇到相关任务时，会把 Skill 内容作为上下文的一部分加载进来，从而按照你定义的方式来工作。相比每次临时写提示词，Skill 的最大价值是可复用、可版本管理、可团队共享。
3.2 SKILL.md 文件的基本结构
下面是一个 Skill 文件的最小骨架，用于说明结构，实际项目要结合自己的业务流程调整：
--- name: web-config-baseline-check description: 对指定 Web 应用的配置项做安全基线检查 --- # Web 配置基线检查 ## 适用场景 当用户要求检查 Web 应用的安全配置时使用。 ## 执行步骤 1. 先确认目标 URL 和是否获得授权。 2. 检查 HTTP 响应头，关注安全相关字段。 3. 检查是否允许目录列表。 4. 检查敏感文件是否可访问。 5. 汇总结果，按要求格式输出。 ## 输出格式 输出 JSON，字段包括： - target: 目标地址 - items: 检查项数组 - status: pass / fail / unknown - evidence: 证据描述 - suggestion: 修复建议 ## 注意事项 - 只对已授权目标执行。 - 所有测试动作保持非破坏性。 - 不要输出真实凭据或敏感信息。这个文件的关键点在于 description 字段。在很多实现里，智能体选择是否调用某个 Skill，主要看任务描述与 Skill description 的匹配度。description 写得越具体、越覆盖触发场景，Skill 被正确调用的概率越高。执行步骤则要写得可操作，避免“检查安全性”这种无法执行的描述。
3.3 编写 Skill 的原则和常见坑
写 Skill 时最容易犯三个错误。
第一个坑是 description 写得像关键词堆砌。比如“安全、检查、Web、配置”这种写法，模型无法判断具体什么时候该用。推荐写法是“当用户要求检查 Web 应用的安全配置基线，或者询问响应头、目录列表、敏感文件等配置问题时使用”，用完整句子描述触发场景。
第二个坑是执行步骤过于抽象。步骤里写“评估整体安全性”等于没写。正确做法是每一步都能对应一个可执行动作，比如“运行 curl -I 获取响应头并逐项比对”。
第三个坑是忽略输出格式约束。如果 Skill 最后不规定输出结构，模型会自由发挥，下游脚本就没法解析。应该在文件里明确给出 JSON 结构或 Markdown 表格模板。
还有一点值得注意：不同平台对 Skill 的实现有差异。Claude Code、OpenCode、Dify、自研框架等对 Skill 文件的识别方式和加载机制不一定相同，迁移时要先验证。如果原始项目没有说明支持范围，落地前先查当前框架的文档，不要假设所有 Skill 写法都通用。
4. MCP：让模型连接外部工具和数据的统一协议
4.1 MCP 是什么：为什么需要它
在没有 MCP 之前，每个应用要对接大模型都得自己写一套工具调用逻辑：A 项目写一套“模型调数据库”的接口，B 项目再写一套“模型调扫描器”的接口，重复劳动多，且彼此不兼容。MCP（Model Context Protocol）就是为解决这个问题出现的开放协议，它定义了大模型应用与外部工具、数据源之间的标准通信方式。
可以把 MCP 理解为大模型世界的 USB 接口：各种外设（数据库、文件系统、扫描工具、漏洞库）只要实现了 MCP 标准，就能被支持 MCP 的模型客户端（Host）即插即用。对安全团队来说，MCP 的实际价值是让模型能基于真实数据做判断，而不是只凭训练记忆猜测。比如模型要分析一个 Web 请求，通过 MCP 读取本地日志文件或调用 HTTP 请求工具，得到的是真实结果，可靠性比纯文本生成高得多。
4.2 MCP 的三层架构
MCP 的架构分为三层：
- Host（宿主）：用户正在使用的大模型应用，比如 Claude Desktop、自研客户端、IDE 插件。Host 负责管理会话，决定是否调用工具。
- Client（客户端）：运行在 Host 内部，负责与 MCP Server 建立连接、发起请求、接收响应。
- Server（服务端）：实现具体能力的独立进程，比如“读取文件”“查询数据库”“执行命令”的 MCP Server。
每次模型需要使用外部能力时，Host 里的 Client 会按协议向 Server 发送请求。Server 执行完操作后把结果返回给 Client，再由 Host 把结果作为上下文交回模型继续推理。这个过程中，工具的具体实现细节被 Server 隔离，Host 不需要知道每个工具体是怎么写的。
4.3 一个最小 MCP Server 配置示例
很多项目通过配置文件声明要加载哪些 MCP Server。下面是一个常见 JSON 配置结构，用于说明写法，实际路径和工具名要按自己的环境替换：
{ "mcpServers": { "local-file-helper": { "command": "python", "args": ["/opt/mcp-servers/file-helper/server.py"], "env": { "BASE_DIR": "/data/authorized-targets" } } } }这里定义了一个名为 local-file-helper 的 MCP Server，用 Python 启动，并把 BASE_DIR 指定为允许访问的目录。关键点在于 env 参数：通过环境变量限制 Server 能访问的路径范围，是常见的安全隔离手段。如果没有这个限制，模型可能请求读取任意路径，风险很大。
另一种常见方式是使用 MCP 官方或社区提供的基础工具，比如 SQLite 查询 Server、Git 操作 Server。配置好后，需要重启客户端让配置生效。启动后可以在日志里确认 Server 是否连接成功，很多客户端会输出类似 “Connected to MCP server” 的提示。
4.4 MCP 的安全注意事项
MCP 让模型获得执行外部操作的能力，这既是价值也是风险。在学习和测试环境中要特别注意以下几点：
- 权限最小化：MCP Server 只授予完成任务所需的最小权限，不要用管理员身份启动。
- 路径隔离：通过环境变量或配置限制 Server 可访问的目录。
- 命令白名单：如果自定义 Server 包含命令执行能力，必须限定命令列表，而不是透传任意 shell。
- 网络边界：Server 监听的端口不要暴露到公网，只允许本机或内网特定主机访问。
- 操作审计：记录 MCP 请求和响应日志，方便追溯模型发起了哪些操作。
在生产环境中，MCP 引入的权限面比纯聊天模型大得多。安全团队在部署前应把 MCP Server 接入现有审计体系，确保每次外部调用都有日志可查。
5. 模型：理解能力边界，才能做对选型
5.1 模型能力由什么决定
同样是“大模型”，不同模型能力差异巨大。决定能力的因素包括训练数据的规模和质量、参数量、训练方法、指令微调的程度等。对使用者来说，不需要深究所有训练细节，但要建立“模型能力与任务要求匹配”的判断力。
比如参数量大的模型通常推理能力更强，但推理速度更慢、硬件要求更高。经过指令微调的模型更擅长遵循复杂的用户指令，适合做智能体任务。多模态模型能处理图片和音频输入，适合分析截图类证据。安全测试场景里，最常见的需求是长文本分析（日志、配置、代码）和结构化输出，因此上下文窗口和格式遵循能力往往比单纯的多模态能力更重要。
5.2 关键参数速查
使用模型时，最常接触的几个参数如下：
| 参数 | 含义 | 调大的影响 | 调小的影响 | 推荐场景 |
|---|---|---|---|---|
| temperature | 输出随机性 | 输出更多样但更不稳定 | 输出更保守、更可预测 | 测试报告类任务建议 0 到 0.3 |
| max_tokens | 单次最大输出长度 | 可输出更长内容但消耗更多 | 输出可能被截断 | 长报告调高，短结构输出按需控制 |
| top_p | 候选词采样范围 | 多样性增加 | 确定性增加 | 与 temperature 配合使用，一般不同时都调大 |
| system prompt | 系统级指令 | 越具体越能约束行为 | 太短则模型容易自由发挥 | 所有安全测试任务都应设置 |
实际项目中，很多人习惯把 temperature 调得很高，希望模型“更有创意”，这在安全测试里往往适得其反。像生成测试用例、解析日志、写报告这类任务，需要的是稳定和准确，建议先把 temperature 设为 0 到 0.3，再按结果微调。
5.3 安全测试场景的模型选型建议
模型选型没有绝对最优，只有场景适配。这里给出几条保守建议：
- 敏感数据处理：优先本地部署模型，例如基于开源权重的 Qwen、Llama 系列，具体版本以当前官方发布为准。
- 快速原型验证：使用商用 API 模型，重点是确认数据脱敏策略，不要直接传入真实业务数据。
- 长文档分析：选择上下文窗口较大的模型，并注意窗口是输入加输出的总限制。
- 智能体任务：优先选择指令遵循能力强的模型，因为 Agent 循环高度依赖模型按格式输出。
模型融合（模型集成）是另一个常见话题。把多个模型的结果交叉验证，可以降低单一模型的误判。但代价是成本翻倍、延迟增加，适合对准确性要求高的任务，不适合每次请求都做全量融合。不要盲目追求“多个模型叠加一定更好”，要先定义清楚验证标准。
6. 智能体：把能力组装成可执行的工作流
6.1 智能体的核心循环
智能体不是一个新的模型，而是一个程序结构。它围绕模型搭建一个循环：
- 理解任务：接收用户目标，拆解成可执行的子任务。
- 规划步骤：决定先做什么、后做什么、要不要调用工具。
- 调用工具：通过 MCP 执行外部操作，或读取 Skill 中的步骤。
- 检查结果：分析工具返回数据，判断是否达成目标。
- 迭代执行：如果结果不满足要求，调整策略继续执行。
这个循环决定了智能体的自主程度。有些智能体每一步都等用户确认，称为“人工确认模式”；有些则连续执行多个步骤，称为“自动模式”。在安全测试场景，推荐保留人工确认环节，尤其是在执行可能产生实际影响的动作之前。即使测试已获授权，任何自动化的删改、写入或不必要的高频请求都应该被限制。
6.2 Skills 与 MCP 的区别
这是初学者最容易混淆的一对概念。简单说，Skills 是“知识层”，MCP 是“动作层”。
Skill 告诉模型“遇到这类任务应该按什么步骤做、输出什么格式”，它是一份静态文档，不直接执行任何操作。MCP 让模型能够调用外部工具，是动态执行通道。两者经常一起出现：智能体先根据 Skill 中的步骤确定要做什么，再通过 MCP 实际去做。
| 对比项 | Skills | MCP |
|---|---|---|
| 本质 | 结构化说明文档 | 通信协议 |
| 作用 | 约束“怎么做” | 实现“能做什么” |
| 是否执行操作 | 不执行，只提供指导 | 由 Server 执行外部操作 |
| 存储形式 | Markdown 等文本文件 | 独立进程或服务 |
| 变更方式 | 修改文档并重新加载 | 修改代码或配置并重启 |
实际工程中，一个测试任务往往同时依赖两者。比如 Skill 里写着“先获取响应头”，模型通过 MCP 调用 HTTP 工具完成这一步。理解这个配合关系，再看各类 AI 安全工具架构就会清晰很多。
6.3 用 Dify 这类平台搭建最小智能体
自己写 Agent 框架需要处理模型调用、工具管理、状态维护、日志记录等问题，学习成本高。对刚入门的人来说，用 Dify 这类可视化智能体平台搭建最小案例更合适。
在 Dify 中搭建一个最小智能体的流程大致如下：
- 创建应用，选择“Agent”类型。
- 配置模型供应商，填入本地或 API 模型的接口信息。
- 添加工具，比如内置的 HTTP 请求工具，或通过 MCP 方式导入自定义工具。
- 在系统提示词里写清楚角色定位和输出格式。
- 编写一个简单流程：接收用户输入，调用工具取数据，汇总结果。
- 发布后进行对话测试，观察每一步的工具调用日志。
最小案例建议选一个无风险任务，比如“根据用户提供的 URL 获取 HTTP 状态码并输出 JSON”。这个案例能验证三件事：模型连接是否正常、工具调用是否通了、输出格式是否符合预期。跑通之后再逐步加入更多工具和步骤。不要一开始就搭复杂的多步骤工作流，否则出问题时很难定位是模型问题、工具问题还是编排问题。
7. 从概念到实践：一条低门槛学习路径
7.1 环境准备清单
开始学习前，建议按下面表格检查环境。这只是一个通用清单，具体版本以你选用的工具官方文档为准。
| 检查项 | 说明 | 最低要求 |
|---|---|---|
| Python | 运行各类脚本和框架 | 3.10 或以上版本 |
| Node.js | 部分 MCP Server 基于 npm 运行 | 18 或以上版本 |
| 本地模型推理环境 | Ollama、vLLM 等任选一 | 内存 16GB 以上，有 GPU 更佳 |
| API 模型账号 | 用于快速验证 | 按服务商要求注册并配置密钥 |
| Dify 或同类平台 | 搭建智能体 | Docker 或官方提供的一键部署 |
| 测试目标 | 本地搭建的靶机/实验应用 | 只在可控环境使用 |
注意：所有概念验证都应在本地或隔离实验环境进行，不要直接对未经授权的真实系统执行任何测试。
7.2 三个验证实验设计
建议按以下顺序做三个小实验，每个实验只验证一个概念。
实验一：验证 LLM 输出稳定性。用一个固定提示词让模型输出 JSON 格式的测试用例，连问五次，对比格式一致性。这个实验能直观感受 temperature 参数的影响。
实验二：验证 Skill 能否被正确调用。写一个只有三步的 Skill，在智能体平台里提问触发，观察模型是否主动加载 Skill 内容。如果模型一直不调用，先检查 description 是否写得足够具体。
实验三：验证 MCP 工具链路。配置一个最简单的 MCP Server，比如读取指定目录下的文件，然后在客户端提问“帮我列出目录下的文件”，看模型能否通过 MCP 拿到真实数据。
这三个实验跑通后，再把三个能力组合成一个智能体：用 Skill 定义步骤，用 MCP 提供数据，用模型做分析，用固定格式输出结果。这一套组合练习，就是 AI 安全测试方向最基础也最扎实的入门动作。
7.3 推荐学习顺序
如果时间有限，建议按下面的顺序推进：
- 先读 LLM 基础资料，重点是 Token、上下文窗口、提示词、temperature。
- 再用本地模型跑文本分析和结构化解题，不用管框架。
- 然后学 Skills，用自己的测试流程写成 Skill 文件。
- 再学 MCP，从使用现成 Server 开始，不急着写 Server。
- 最后学智能体开发，优先用可视化平台，再读框架源码。
逆向学习是最常见的错误。很多新手直接从 Agent 框架源码开始，结果被工具调用、消息路由、记忆管理等概念淹没。先把每个底层概念单独验证清楚，再组合，效率会高很多。
8. 常见问题排查与安全基线
8.1 常见问题排查表
在学习和配置过程中，以下问题出现频率最高：
| 问题现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| 模型输出截断 | max_tokens 设置过小 | 查看返回长度是否接近上限 | 调大 max_tokens，或让模型分段输出 |
| Skill 不被模型调用 | description 不够具体 | 检查 Skill 描述与实际提问的匹配度 | 用完整句子描述触发场景 |
| MCP Server 连接失败 | 配置文件路径错误或依赖未安装 | 查看客户端启动日志 | 检查 command、args 和 node 依赖 |
| MCP 配置修改后不生效 | 未重启客户端 | 检查进程是否还使用旧配置 | 重启应用并确认连接日志 |
| 本地模型推理很慢 | 量化等级低或内存不足 | 查看 CPU/显存占用 | 换小尺寸模型或增加内存 |
| 同一提示词不同模型结果差异大 | 模型训练和微调方式不同 | 对比两个模型的输出结构 | 不要假设提示词跨模型通用 |
8.2 引入 AI 到安全测试时的合规底线
AI 渗透测试方向始终要守住几条底线，这些不是可选项，而是执业前提：
- 授权优先：任何测试动作都必须基于明确的书面授权，授权范围包括目标、时间、操作类型。
- 非破坏原则：自动化工具不应执行删除、写入、修改配置等可能改变目标状态的操作，除非授权范围明确允许。
- 数据脱敏：不要把真实用户数据、业务数据直接发送到外部 API 模型，必要时应使用本地模型。
- 操作审计：AI 的每一次工具调用都应留下日志，确保事后可追溯。
- 人工复核：AI 生成的测试结论只能作为参考，最终判断和报告应由安全工程师复核。
从防御视角看，了解 AI 渗透的能力和边界同样重要。攻击者可能利用 LLM 生成更高效的钓鱼文案、自动分析目标信息、甚至是半自动化的漏洞利用流程。防守方只有理解这些技术的工作原理，才能设计出对应的检测和防护策略。这也是安全从业者学习这部分知识最重要的正当理由。
8.3 最佳实践清单
最后给出一个可执行的清单，适合团队在落地 AI 辅助安全测试时逐项打勾：
- 概念验证阶段使用本地靶场环境，不要直接连接生产网络。
- 固定一套模型和平台版本，避免每次实验环境漂移。
- 所有提示词、Skill 文件纳入版本管理，记录变更原因。
- 模型输出统一走“原始结果 + 结构化结果”双份保存，方便后续复盘。
- 工具调用设置超时和频率限制，防止模型循环请求打爆目标。
- 敏感系统的测试环境与外部模型网络隔离。
- 定期清理模型输入的临时文件，防止缓存泄露信息。
- 每次测试结束后导出完整日志，归档到项目目录。
把这些清单落到团队日常流程里，比单独研究某个框架更能提升整体质量。AI 渗透测试的基础看似庞杂，但本质上就是“理解模型、写好技能、接对工具、组织流程”四件事。把本文涉及的五个概念在实验环境里各跑一遍，再组合成最小智能体，你会发现后面的工具文档和框架源码都变得容易读懂了。
