在实际安全工作中很多想切入 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 的某个版本决定能力上限、上下文长度、运行方式本地或 APISkills以 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 项目再写一套“模型调扫描器”的接口重复劳动多且彼此不兼容。MCPModel 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.3max_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 实际去做。对比项SkillsMCP本质结构化说明文档通信协议作用约束“怎么做”实现“能做什么”是否执行操作不执行只提供指导由 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 渗透测试的基础看似庞杂但本质上就是“理解模型、写好技能、接对工具、组织流程”四件事。把本文涉及的五个概念在实验环境里各跑一遍再组合成最小智能体你会发现后面的工具文档和框架源码都变得容易读懂了。