从签名重放到 Agent Harness：一堂安全课程如何把前端逆向、MCP 与工程约束串起来

摘要：这篇复盘从前一阶段的 WebShell 检测绕过回顾切入，依次梳理签名机制导致的请求重放失败、课程 PDF 资源定位、AI 辅助前端逆向，以及 MCP、Skills 与 Harness 的差异。后半部分转向安全 Agent 的状态管理、观察纠偏、工具隔离和循环机制，并结合微调数据质量、开源项目研究与求职表达，呈现课堂中案例推演与工程判断的完整路径。

复盘范围与阅读边界

这段授课内容横跨两个看似不同的方向：一部分讨论 Web 安全测试中的请求签名、前端代码分析和资源定位；另一部分讨论大模型如何借助工具形成 Agent，以及如何通过状态、约束和观察机制控制长任务。两部分的连接点并不是"把 AI 接入扫描器"这么简单，而是把人的判断过程拆成问题定义、工具调用、结果验证、状态沉淀和下一步决策。

课程首先回顾了此前围绕 WebShell 检测的实验，再说明后续课程可能转向常见框架漏洞的代码追踪；随后借助深信服考试材料的访问方式，演示从浏览器网络请求逐步定位 PDF 资源的思路。这个过程又引出请求签名的逆向分析，以及如何在授权场景中使用 AI 协助阅读前端代码。之后，讨论范围扩大到 MCP、Skills、提示词与上下文工程，再进入 Agent Harness、记忆板、观察者和循环执行等设计。

原讲解也穿插了简历、面试和学习路径建议。技术复盘会保留这些意见的语义，同时把个人判断与课堂案例区分开来。涉及密码喷洒、漏洞探测、请求重放、命令执行或自动化渗透的内容，均应放在明确授权的靶场、考试环境或自有系统内理解；以下不把这些讨论扩写成面向未知目标的操作步骤。

一、从 WebShell 检测回顾到框架代码追踪

缓存命中与文件内容差异

课程开头先回顾了前一天对雷池和宝塔环境的复现，并再次提到 WebShell 检测绕过中的缓存命中问题。这里讨论的前提是课堂搭建的实验环境，重点是理解检测结果如何与缓存键关联，而不是提供可直接用于未知站点的绕过流程。

第一类情形是检测侧只根据文件内容缓存结果，没有把文件名纳入判断。讲解者提出的实验构想，是先让某种文件内容经过与其扩展名不一致的解释路径，使检测引擎留下一个"非恶意"的缓存结果；随后再观察另一文件是否可能命中这条结果。这个推理依赖于具体检测器的缓存策略和解释器链路，不能简单推广成普遍有效的结论。

如果检测结果只按内容缓存，文件名又不参与缓存键，那么后续对象可能复用已有判断；如果内容和文件名都参与比较，单靠相同或近似内容就不足以复用缓存。讲解强调了两类缓存键设计之间的差异，提醒复现时要把"检测结果如何缓存"作为前置条件，而不能只观察上传后的表面反馈。

哈希碰撞示例及其边界

作为另一类讨论，课堂提及 GitHub 上名为 fastcoll 的快速碰撞工具，并围绕文件哈希一致而内容不同的示例作解释。讲解中将其描述为利用特定位置的字符差异构造碰撞，再让先后提交的样本与文件名/内容缓存发生关联。原稿中的样本标识包括 EVM、evi 以及 EVAL 一类字符串，但语音转录存在拼写不稳定，复盘保留这些标识的上下文，不将它们整理成未经核实的可执行样本。

这个案例的推理重点有三层：先观察两份样本的哈希值是否相同，再确认文件内容实际上并不相同，最后检查检测器究竟把哪些字段纳入缓存键。若第一步的哈希结果不一致，后面的缓存推理就失去基础；若系统同时校验内容、名称或其他元数据，即便构造出了哈希碰撞，也未必复现预期行为。哈希相同并不等价于文件内容相同，检测器的缓存实现才决定该示例是否成立。

这部分没有给出独立的可复现命令或完整代码，因此更适合被视为缓存设计与检测逻辑的课堂案例。复盘的价值在于把"先发什么、后发什么、缓存保存了什么、第二次请求命中了什么"这些变量逐一拆开，而不是仅记下一个工具名称或一个声称有效的文件对。

复现实验时，至少要把两份样本、两次请求和两次判定分别记下来。第一份样本的文件名与内容是什么，检测端返回什么，缓存是否建立；第二次样本更换了哪些字段，检测端是重新分析还是复用旧结果；最终看到的告警是实时扫描结果还是已有缓存结果。若只记录"第一次没有报、第二次通过"，就无法分辨绕过来自缓存、解析差异、样本本身还是实验环境配置。

这也是课堂回顾中最值得保留的方法论：同一个表面现象可能有多个解释，必须通过改变单一变量逐步排除。若文件名和内容同时变化，就无法判断检测器究竟依据哪一个字段作出决定；若中间还替换了解释器或上传路径，变量就更多。先让实验最小化，再逐项改变输入，是这类安全机制分析能够形成可信结论的前提。

`preg_replace` 相关的规避思路回顾

随后，课程简要回顾了围绕 preg_replace 行为和静态检测的几种变形思路：把字符串表达改为数组形式、使用花括号等替代常见分隔符，以及通过换行、制表或空格改变扫描器看到的文本形态。讲解将这些做法归纳为让检测引擎的文本解析与运行时解释出现差异。

这类讨论同样受具体引擎、语言版本、正则规则和输入规范化步骤影响。若过滤器先统一空白或规范化语法，文本层面的变化可能不再产生预期效果；若运行时解析方式与静态扫描器不同，结果也可能反过来。课程在此处只回顾思路，没有逐一呈现验证结果，因而不能据此断言某一种变形普遍有效。

课堂提到这些变化时，关注点不是"空格、换行或数组形式必然能绕过"，而是检测器看见的文本与解释器实际执行的结构之间可能存在差距。测试时应分别记录扫描器的输入、扫描器输出、运行时行为和告警状态。若测试环境没有真实运行对应代码，文本检测结果就不能代表执行结果；反过来，执行行为发生变化也不自动说明检测规则存在缺陷。这样的区分有助于把"静态特征逃逸"和"运行时语义差异"拆成不同问题。

转向开源框架漏洞与代码路径

完成前情回顾后，讲解提出后续课程可能从 WebShell 主题转向开源框架漏洞，包括 ThinkPHP、织梦（转录中出现 DAILY CMS/DedeCMS 的不稳定识别）、Struts 以及 WordPress 等对象。授课者强调，框架漏洞分析与靶场中直接可见的触发链不同，真实框架的调用往往经过多层封装，可能需要沿十几个乃至更多函数继续追踪，才能理解输入如何到达危险操作。

课程还提到一则 WordPress 核心漏洞的新闻性案例，并称其影响范围很大。由于原稿没有提供漏洞编号、公告来源或独立核验材料，这里仅将它保留为课堂提出的后续研究方向，不把影响数字或技术细节当成已验证结论。对应的学习问题是：漏洞从哪里产生、触发条件是什么、调用链如何经过框架内部函数，而不是只记住"某版本有 RCE"这样的标签。

经验判断：框架漏洞的代码阅读成本通常高于简单靶场复现。先把入口、参数流转和关键函数链条画清楚，再谈触发条件，能避免把结果背下来却无法解释原因。

课程把这些框架列为后续方向，并未在本节开始实际追踪某个漏洞调用链。授课者建议有兴趣的学习者提前查看织梦系统的历史漏洞，以及 WordPress 相关漏洞，重点追问漏洞如何产生、输入如何进入框架、最终在哪个函数触发。这个建议指向代码审计的准备工作，不意味着原稿已经完成了这些漏洞的技术分析。后续复盘应分别记录版本条件、入口、调用路径和可验证结果，避免把不同框架的漏洞机制混为一谈。

二、把 AI 放进项目叙述：前端逆向与受控测试

项目表达从目标与限制开始

课程接下来从漏洞技术转到简历表达。授课者的核心建议是：对于安全岗位，项目经历可以展示 AI 在分析流程中的具体作用，但不能只把"用了 AI"当成成果。课堂随后列举了两个方向：前端逆向辅助密码喷洒，以及通过前端代码分析重建请求签名、支持受控环境下的请求重放测试。

这项建议带有明显的求职经验判断，而不是关于所有招聘流程的客观定律。讲解者认为，安全厂商和面试岗位正在提高对 AI 相关能力的关注，因此项目叙述若能说明 AI 如何帮助完成一段真实分析过程，会比抽象地罗列模型名词更有辨识度。与此同时，课程也承认一些 AI 概念存在包装成分，因此应当能解释项目中实际做了什么、哪些结果经过验证。

授课者把自己的建议说得相当明确：如果简历有多个项目，至少应有一个能说明 AI 与安全工作的结合。他同时承认，市场上存在概念炒作，AI 并非每个项目都能带来实质技术提升；但他的求职判断是，部分面试官会关注候选人是否理解 AI 工具或智能体，因此呈现一段真实、可解释的相关实践，可能有助于通过简历筛选。这个观点属于讲师对招聘环境的经验判断，应作为观点呈现，而不应改写成行业统一标准。

若把项目从头到尾拆开，叙述至少应包含问题背景、原有手段遇到的限制、AI 获得了哪些输入、AI 调用了哪些工具、生成了什么可检查的中间产物、人工如何验证，以及最后解决到什么程度。每一步都应对应证据。例如，脚本"生成成功"与"脚本在授权测试账户上按预期工作"不是一回事；"模型识别出疑似 RSA"也不等于已经验证服务端采用了同样的参数格式。项目故事的可信度来自链路完整，而不是形容词更多。

案例一：RSA 登录参数与前端逆向

第一个案例来自课堂早先演示过的网站登录流程。背景限制是：测试者面对登录界面，原本希望在授权测试中进行密码喷洒，但抓包后发现账号和密码字段并非明文，而是由前端 JavaScript 做了 RSA 加密。若仍把明文直接交给接口，服务器端收到的格式就与页面正常登录请求不同，测试脚本无法按预期工作。

讲解者判断，阻碍不在于密码列表或请求发送本身，而是缺少客户端侧加密过程。由于学习者当时对前端逆向不熟悉，课程展示让 AI 阅读网站的 JavaScript，并借助名为 claude-dev-tools 的 MCP 工具访问浏览器上下文，再让模型协助识别 RSA 逻辑、生成 Python 脚本。原稿将该算法描述为"简单、未混淆"，并称模型较快读出逻辑；这里保留为课堂案例的观察，不把它推广为 AI 总能正确还原加密实现。

讲解中提到，授课者在先前演示里从受控测试中得到两个账号，但没有继续利用，而是向"安康学院"反馈了问题。课程进一步讨论了简历该如何写：可以清楚说明原始限制是登录参数经过 RSA 处理，随后通过前端分析复现客户端参数生成逻辑，并在授权范围内验证脚本能否按正常客户端格式构造请求。授课者还举出"其中一个账号具有较高权限、可以接触学生信息"的写法作为叙述示例；这属于他建议如何组织项目故事，并非课堂已完成的实际数据访问结果，不能被写成真实发现。

案例的技术结论不是"AI 自动完成了渗透"，而是它在已有目标、边界和可观察 JavaScript 的条件下，辅助定位了请求构造逻辑；账号结果与后续影响仍需要独立验证和合规处置。

从排查顺序看，前端加密让原有脚本失效后，仍有几项检查不能跳过：首先确定浏览器正常提交时哪些字段发生了变化；其次定位字段由哪个脚本函数生成，以及函数的输入来自哪里；然后确认加密前后的数据类型、编码和请求结构是否一致；最后只在允许的测试环境中验证生成结果是否与浏览器请求相符。课堂转录没有给出完整函数名、密钥配置或 Python 代码，所以无法把这个案例改写成可复制的实现；但它清楚地呈现了"抓到请求---定位前端逻辑---辅助理解算法---验证脚本"的推理顺序。

授课者强调的另一点是，技术能力与项目边界应同时写进经历。实际演示停止在两个账号并向相关单位反馈，后续关于管理员账号和学生信息的描述只是建议如何构造项目故事。把这两个层次混为一谈，会把假设扩写成事实。对外发布时，应优先描述可核查的实际结果，并将尚未实施的影响分析标注为假设或风险评估。

案例二：签名与时间戳让重放失败

第二个方向从常见抓包工作流切入。授课者指出，请求进入 HTTP 阶段时可能附带签名和时间戳字段；在同一请求被再次发送时，如果签名与服务器期望的完整值不匹配，服务端可能返回 500，并显示签名不正确。课堂将这种响应视为请求完整性校验或时效性限制的线索，而不是简单把重放失败归因于工具设置错误。

在这个案例里，下一步判断是去检查前端 JavaScript 中的签名生成过程。对熟悉代码的人，这可能是直接追踪函数调用；对前端经验较少的学习者，AI 可以协助搜索相关脚本、梳理数据依赖并尝试生成复现代码。原稿没有给出完整签名算法，也未声称单凭截图就能绕过防护，因此文章只保留分析路径：先确认请求确实携带动态签名，再观察重放时的错误，最后在授权环境中逆向客户端生成逻辑并验证。

讲解者以深信服考试平台为例，说明同一思路如何用于查看考试课程资料。这个案例有实际的页面请求与资源定位过程，以下按课堂探索顺序复盘。它展示的是授课者在课程/考试材料访问场景中研究请求结构的经历；将方法迁移到其他系统前，必须有相应授权，不能把"能找到资源地址"理解为拥有访问权。

这个切换也说明，复盘对象不一定是漏洞利用。课程资料如何被前端加载、请求依赖哪些标识、文件服务如何返回内容，同样可以作为工程观察对象。资源分析与访问控制测试需要区分：前者追踪浏览器已经获准查看的内容如何传输，后者则要判断某种访问是否超出了授权范围。即使浏览器能显示一个链接，也不代表可以把链接传播到账号权限之外。

三、从页面请求到 PDF：逐步定位课程资源

先识别页面标识，再比较几种取材方式

背景限制是课程讲义只允许在深信服网站页面中查看，下载并不方便。讲解者先留意到 URL 中类似 Course、3011 的课程标识，并从另一个页面观察到 3009，由此判断课程或章节编号会随页面变化。此处的 3009、3011 是截图中可见的页面标识，不代表固定 API 参数。

最直接的方式是逐页截图；如果页面里有独立 PNG，也可以通过浏览器另存。两种办法都能保存可见内容，但课程页面包含大量材料，逐张处理会带来明显的时间成本，也不利于下次复用。讲解者因此没有停在"截图可行"这个层面，而是转向浏览器开发者工具，观察页面到底从哪里加载 PDF。

图 01：截图记录了课程页面链接中的编号变化，提供了区分课程条目的初始线索。

从首页请求转向文件请求

第一轮检查中，讲解者打开浏览器开发者工具并查看网络请求，发现首页请求本身没有需要关注的签名字段。于是排查方向从首页转到真正承载讲义的文件请求。这个转换很关键：页面成功打开并不意味着文件接口与页面接口使用同一套参数，也不能只查看首页加载结果就判断资源的保护方式。

继续向下检查后，网络列表里出现大量 JavaScript 与资源请求。讲解者通过筛选和逐项查看寻找与 PDF 预览相关的调用；中间一度遇到预览字段为空的情况，因此没有把它当成最终资源，而是继续沿页面初始化和课程参数寻找下游请求。截图中的 code_id_3009、class_id_1826 等字段被用来确认请求关联的课程与班级上下文。

图 02：网络面板展示页面加载阶段的请求列表，排查从此处开始由页面整体转向具体资源。

图 03：请求详情用于区分页面数据与文件数据，避免把首页响应误判为讲义内容。

在继续向下检查时，授课者看到某些请求头中出现类似 JWT 的签名字段，并注意到签名值会变化。接着，他观察到某个请求与课程内容列表有关，但其响应并非 PDF 文件本身；仅得到课程名称或资源元数据仍不足以完成定位。因此，排查继续朝文件链接所在的数据结构推进。

这里连续经历了"首页没有签名""目标文件请求才值得检查""预览字段为空""课程元数据只能确认上下文""候选字段看起来像文件链接"等阶段。每一次都只是缩小搜索范围，并没有单独构成结论。尤其是看到名为 signature、token 或类似 JWT 的字段时，不能只凭名字判断其用途；仍需结合请求路径、响应内容和重复访问结果确认它是否参与了该资源的授权或完整性校验。

图 04：请求头和字段细节帮助辨认请求上下文，但此时尚未确认文件实体地址。

随后，页面数据中出现类似 FAIR URL 的字段。讲解者将它作为可能指向文件服务的线索，而不是立刻认定为最终下载地址；他继续检查关联响应和浏览器是否能实际打开该资源。课程中还通过页面中的课程名与条目编号相互对照，判断相应资源是否与当前讲义匹配。

图 05：课程条目与编号的对应关系用于筛选目标讲义，而非单独证明文件地址有效。

图 06：开发者工具显示脚本和资源数据的关联，排查仍处于定位候选字段阶段。

图 07：字段内容呈现出文件链接的形态，促使排查转向验证实际响应。

图 08：页面上的预览区域用于对照课程内容与候选文件，不把页面显示本身当成资源验证。

验证候选地址，并识别签名约束

当候选字段看起来像文件 URL 后，讲解者让浏览器实际访问该地址。随后页面显示为 PDF 资源，说明定位方向比截图或单独保存页面图片更接近源文件。课程也展示了打开后的资源页面，作为"该地址确实返回 PDF 内容"的可见验证。

图 09：浏览器打开后的内容确认候选地址返回的是 PDF，而不只是课程名称或预览占位信息。

图 10：资源请求与 PDF 页面相互对应，帮助区分真正文件请求和外围页面调用。

图 11：请求细节中出现签名字段，说明资源获取还受请求参数约束。

图 12：页面和请求列表并置显示，便于把用户可见的课程条目关联到网络活动。

在确认资源形态之后，讲解者再次回到请求本身，指出签名值会随请求变化。原稿描述，如果把旧请求单独拿出来再次发送，可能因为签名不正确而返回 500。所以，重复下载或批量处理并不能只靠复制一条链接；课程的下一步问题变成"如何在授权环境中理解该签名的生成规则"。

图 13：调试区域用于继续观察页面脚本和请求之间的关系。

图 14：截图显示讲解中查找相关工具/资料的过程，未表示其中任何结果已被独立验证。

图 15：搜索结果用于找到浏览器自动化与调试工具的候选项目。

从课堂截图和叙述可以看出，文件定位不是一次搜索就完成的。首先看到课程编号，确认页面对象；随后观察首页网络活动，发现它没有目标签名；再把注意力转到 PDF 预览请求，遇到空字段时继续追踪；发现类似 FAIR URL 的候选值后，仍然返回浏览器验证内容。这个推进方式保留了每一次未命中的意义：空预览值排除了一个错误方向，课程名称确认了上下文，候选 URL 则提出了可测试的假设。

从效率比较看，截图和右键保存都不是"错误做法"，而是操作简单但重复成本较高的基线。若只有少量页面，手动保存可能比研究请求结构更省时间；课程材料数量达到百余份时，逐项下载的时间成本才让自动化分析变得值得。授课者描述的一个中间节点是：找到一个真实 PDF 地址后，仍可能要对每一份资料分别处理，因此虽然比截图更有效率，却没有解决批量操作问题。

对签名的定位也有逐步收敛过程。课堂先看到请求头中类似 singer（转录识别如此）或签名值的字段，单独复制后又遇到 500 和签名错误。由此确认，链接本身不是全部条件，重新请求时还要满足平台对签名的检查。这里的失败反馈提供了新的线索，但不能仅凭 500 就断定签名算法，也可能需要进一步观察请求方法、时间字段、关联参数和服务端错误信息。讲解者的下一步设想是借助浏览器工具让 AI 查找生成逻辑，这与前面的 RSA 案例属于同一种"先观察客户端，再解释请求"的方法。

若按排错记录还原这一段，每个候选请求都可以附上它的用途、关键参数、响应类型和是否含签名。首页请求没有目标字段后，就降低其优先级；课程列表请求能返回标题但不含文件体时，就继续找下游资源；预览字段为空时，就先不把空值当下载失败，而是检查它是否需要其他请求补充；候选文件链接在浏览器中返回 PDF 后，才确认资源定位阶段基本完成。一次操作对应一个可观察结果，结果再决定下一步，才构成可复查的排查链。

课上提到课程编号 3009 和 3011，正好说明页面资源可能按课程上下文区分。若忽略编号，只复制某一个成功链接去请求其他文件，可能拿到错误课程、空响应或无权限页面。对每个资源而言，课程标识、班级标识、请求签名和文件 URL 之间的关联都需要分别核对。原稿没有展示脚本批量处理的最终结果，因此复盘止于"单个资源已定位、批量方案仍有改进空间"，不把效率设想写成已完成的自动化成果。

从手动保存转向自动化分析的动机

找到单个 PDF 后，逐个点开并下载当然可以完成任务。讲解者估算，课程材料超过一百份，若每一份都手动操作，即使熟悉开发者工具，也可能需要较长时间；而且下一次遇到结构不同的页面时，还要重新摸索。因此他把效率问题拆成两个部分：一是批量发现资源，二是理解每次请求都变化的签名。

这时，AI 的作用被限定为协助阅读前端脚本和整理签名逻辑。它不替代授权判断，也不自动消除服务端控制；首先要确认访问范围和课程账号权限，其次要理解签名字段如何参与请求，最后才能判断批量操作是否符合平台规则。课堂后续演示更偏向"如何让模型读到页面和脚本"，而不是给出一个可直接迁移到任意站点的下载器。

四、MCP、浏览器工具与 AI 的工作边界

通过浏览器上下文补足模型观察能力

讲解者回忆了此前用过的浏览器 MCP 工具，并在课堂中展示 Google Chrome DevTools MCP 相关资料，以及另一款可让模型操作浏览器的工具。这里的需求很具体：仅靠用户口述，模型未必能看到请求、脚本和页面状态；工具接入后，它才可能在授权浏览器会话中查看这些信息。

图 16：搜索结果中汇集了不同安全测试技能条目，后续讨论将从工具集合转向其内容与调用方式。

讲解者接着展示了 Skills 的搜索结果和示例项目，其中包含文件包含、文件下载、注入、XSS、指纹识别、扫描与报告等分类。课程并未只停留在"安装后就能用"的层面，而是提出一个先决问题：技能包内部到底写了什么？它是如何调用脚本、如何界定目标、如何控制操作范围？如果没有检查这些内容，安装一个名字看似合适的集合，并不能证明它的行为适合当前任务。

图 17：目录截图展示技能条目的分类方式，类别本身不等于已经验证的操作能力。

图 18：页面提供项目安装信息，课堂借此转向"安装后还要审查其实现"的讨论。

图 19：仓库内容帮助检查技能的实际逻辑，而不是只凭简介判断用途。

图 20：页面显示技能说明和相关条目，提示需要核对每项能力的调用条件。

图 21：搜索视图呈现浏览器控制工具的候选信息，供讲解者继续说明 MCP 的角色。

先确认权限，再理解 MCP Server 暴露的能力

课堂强调，MCP 可理解为让模型客户端与外部工具服务建立约定连接的一种协议机制。模型一侧作为客户端，工具一侧运行 MCP Server，并把可调用的能力及其参数描述提供给客户端。对于浏览器场景，工具服务可以暴露页面导航、读取脚本、查看控制台和网络请求、操作表单或鼠标等功能。

讲解者特别提醒，某些启动参数可能会扩大工具权限，未经审查就启用，可能导致 AI 对本机执行不合适的操作。课堂截图中的终端步骤属于展示工具连接和权限配置的过程，并非建议对未知目标执行任何测试。工具接入前应先审阅权限范围、目标边界与可能影响；操作能力越广，越需要限制它可触及的资源。

图 22：终端画面记录 MCP 配置讨论；其中涉及权限的启动选项需要在使用前谨慎核查。

图 23：该画面展示服务连接过程，说明客户端需要通过约定方式连接工具端。

图 24：终端界面列出可供模型调用的浏览器操作类别，展示工具描述如何进入客户端视野。

原稿称浏览器工具大约暴露了 29 项能力，举例包括点击、关闭页面、读取脚本、填写表单、查看控制台和网络请求、检查已打开页面以及导航。讲解者用这些能力解释"模型长出手脚"的比喻：模型本身负责推理，而工具提供观察环境和执行动作的通道。这个比喻并不意味着模型拥有无限权限，工具服务实际暴露什么、客户端允许什么，仍由配置与权限控制决定。

图 25：页面文档展示浏览器工具的能力说明，模型需要先获得这些描述才能选择调用。

图 26：文件内容呈现技能名称与简介等元信息，说明技能可以先以较轻量的描述被发现。

MCP 与 Skills 的上下文取舍

课程把 MCP 的加载方式概括为"集中暴露工具描述"：客户端连接后，模型会看到工具名称、用途、参数及调用定义。这样做的优势是接口清楚、参数明确；代价是工具数量多时，需要放入上下文的信息也会增长。讲解者举了一个浏览器 MCP 提供 29 项能力的例子，并推演同时加载多个 MCP 时，工具说明可能占据大量上下文。

相较之下，Skills 被描述为渐进式披露：初始阶段先向模型提供技能名称和简短说明，只有当任务与某项技能相关时，才继续载入较完整的操作内容。课堂以技能文件中的 name、description 等字段说明这一层次。差异不在于哪一种机制绝对更好，而在于工具说明何时进入上下文、使用者需要多少接口精度，以及系统能否清楚解释实际行为。

讲解中还指出，Skills 可以通过 Python 脚本或其他已有工具完成具体工作，因此同一类任务未必只能依靠 MCP。MCP 的好处是函数和参数边界相对明确；Skills 的灵活性较高，但若描述或内部实现不清楚，模型可能不知道什么时候调用、如何正确使用。选择时应看任务需要和实现质量，不能只根据流行度决定。

原讲解把 MCP 的意义描述为让模型可以连接外部工具：模型先获得工具能力说明，判断当前任务是否需要，然后由客户端向服务端发出调用；服务端完成动作后再把结果返回。浏览器 MCP 的例子把这个抽象过程具象化为读取页面、脚本、控制台和请求，以及执行点击或表单交互。将其用于签名分析时，模型获得的是浏览器可观察信息；它并不会因为接入 MCP 就自动知道签名规则，仍要根据请求变化和脚本内容进行推理并验证。

对上下文成本的讨论也需要放回系统整体来看。讲解者举例说，一个 MCP 若预先暴露几十个工具，每个工具都有名称、说明和参数定义；如果再加载多个服务，启动时的描述内容会持续增加。模型还要保留用户需求、浏览器内容、历史响应以及分析产物，真正能用于任务推理的空间就会受到挤压。课堂把这一点概括为"上下文容易被工具描述占满"，并未对具体产品的 token 使用量作测量，因此更适合视作工程风险，而非固定的容量公式。

渐进加载的 Skills 则把发现和使用拆成两段：初次只让模型知道"有这样一项技能、它大致处理什么"；当任务匹配后，再读取完整说明和脚本。这样可减少尚未用到的细节进入上下文，但也产生另一类依赖：名称与描述必须足够明确，模型才能正确判断何时需要它；脚本内部行为也必须经过审查。若描述过于宽泛或技能目标与当前环境不匹配，渐进加载只能降低初始信息量，不能解决逻辑错误。

因此，MCP 与 Skills 的比较可以按三项具体问题进行：工具是否要求结构化参数、模型是否需要随时掌握全部接口、技能说明是否需要按任务延迟加载。若调用需要严格参数约束，MCP 的工具定义可能更直观；若知识较长、只在少数任务触发，Skills 的分层说明可能更省上下文。课堂还指出，Skills 可以把实际动作交给 Python 等脚本执行，说明"由何种接口暴露能力"与"底层用什么程序完成工作"是两个不同层次。

课程还用"模型只有大脑、工具提供手脚"的比喻梳理了工具调用的变化。较早的交互方式是模型给出建议，由人类自行执行；接入外部工具后，模型可以在客户端能力允许时请求操作，再根据返回结果继续推理。这个变化没有消除人的职责：测试者仍要选择目标、确认权限、审阅动作，并判断工具返回值是否可信。若把工具输出原封不动当作事实，错误页面、缓存内容或误报也可能进入后续计划。

对于浏览器工具，课程列出的能力可以分成观察和动作两类。读取脚本、查看控制台和网络请求、列出页面，主要增加可观察信息；点击、填写表单和导航则会改变浏览器状态。两类能力的风险不同：读取也可能暴露敏感页面内容，动作则可能提交数据或触发业务流程。评估一个 MCP Server 时，除工具名称外，还要检查每个工具的输入参数、作用对象、是否有副作用以及执行结果怎样返回。

五、从提示词工程到 Harness：为什么模型仍会偏航

提示词质量首先取决于目标是否说清楚

讲解者把 AI 应用能力的变化概括成三个阶段：提示词工程、上下文工程、Harness 工程。对提示词阶段的解释很朴素：模型无法读取提问者脑中的隐含条件。若只说"做一个网站"，模型会自行补足主题、布局和内容；如果需求实际是体育网站，却没有描述视觉结构、内容对象或功能边界，结果就只能依赖模型对训练样本的默认猜测。

授课者还把这一变化放进时间线中，称 2023 至 2024 年间提示词工程较受关注，之后人们逐渐意识到还要提供与任务相关的资料和环境信息，到了课程讨论的阶段，又需要通过 Harness 管理模型行为。这个时间线是讲解者用于组织概念的课程叙事，并非完整的 AI 技术史；它的解释作用在于说明：当上一阶段无法解决新出现的问题时，工程关注点就向更完整的系统管理扩展。

课程给出的提示词建议包括：为模型设定合适角色；用简洁、具体的语言描述当前目标和环境；明确希望它执行的工作；在必要时提供示例；并说明禁止事项或边界。安全测试场景尤其需要把范围讲清楚，例如只能访问明确授权的系统、禁止删除数据、避免对真实业务数据做写入操作。这里的边界不是额外装饰，而是任务本身的一部分。

课堂中用于解释提示词的安全测试例子，包含站点地址、API 发现、未授权访问检查以及后续漏洞类别等内容。授课者指出，任务说明还应写清楚"不做什么"，例如不删除数据、不对真实业务内容做写入，以及对 SQL 注入只做允许范围内的低影响验证。本文将这类步骤保留为任务边界设计的讨论，不重复成一段可直接调用的自动扫描指令。项目展示时也应说明测试对象属于哪个授权范围，而非只突出模型能访问网页或调用外部情报 API。

课堂中描述的提示词结构可以还原为一份任务说明：先说正在测试的系统和授权范围，再说希望观察的对象，例如页面脚本或已知接口；然后写出允许的检查动作和禁止动作；最后给出期望的结果格式。若需使用外部 API 或浏览器工具，也要说明这些工具可以访问哪些数据。这样模型得到的不是一句"帮忙渗透"，而是一个包含对象、目标、约束和输出要求的任务。

授课者用"让室友做一个网站"的例子说明隐含需求的问题。需求提出者知道心里想做的是体育网站，还知道需要哪些明星、布局和栏目，但如果只说"做一个网站"，执行者只能按自己的理解补全。对模型也是如此：角色设定能提供语境，却不能替代具体需求；写得简洁也不代表写得完整，重要的是清楚表达系统状态和成功条件。

课堂还建议给出一个样例，让模型知道应如何开展工作。样例可以明确页面、请求和预期分析输出之间的关系，但样例内容必须来自允许提供的数据。若把真实凭证、未公开漏洞细节或用户数据直接贴进对话，虽然可能让模型更快理解请求，也会增加信息泄露风险。提示词质量与输入治理是同一件事的两面：模型能看到的信息越多，使用者越需要确认这些信息可以被送入当前工具或服务。

讲解者进一步建议，若测试依赖子域名来源或外部情报服务，应明确数据来源和 API 使用条件；若后续涉及漏洞检查，也应明确不进行数据导出或破坏性验证。课程里出现了 FoFa、Hunter、API Key、子域名发现等例子，但这些只说明如何描述任务依赖，不构成对任意组织开展侦察的授权。对目标、访问许可、允许动作和停止条件的说明必须先于自动化执行。

上下文不仅是对话历史

随着任务复杂度提升，仅有清晰提示词仍不够。模型还需要与工作相关的资料、环境状态、工具说明、代码片段和前序结果；这些信息共同构成上下文。讲解者用多轮对话作直观说明：每轮问答都会进入历史消息，模型据此延续之前的任务，但上下文不是无限的，信息增加到一定程度后就会触发压缩。

课程用天气和旅行规划作了通俗说明：如果模型不能访问实时数据，它就不能凭训练内容获知当前天气；若接入天气服务或行程 API，工具返回的信息才可以被纳入后续回答。这个例子用于解释外部工具如何补充模型所缺信息，不意味着 MCP 自身负责提供数据，也不意味着任何工具返回值都天然可靠。

从上下文的组成看，除了用户文字和模型回复，至少还包括此前的多轮消息、工具清单、工具返回值以及正在处理的代码或页面内容。实际任务中，浏览器读到的脚本和网络响应可能比提示词本身更长。若一味把所有内容留在历史里，模型虽然"看过更多"，也可能更难集中在当前目标；课程后面所讲的压缩与记忆设计，就是要决定哪些信息需要完整保留、哪些可以提炼成简短事实。

图 27：代码截图对应后续关于模型走入错误推理路径的案例，关键条件是实际判断而非表面字符串。

模型能力强，不等于长任务不会走错

为说明模型在复杂任务中的偏航，讲解者回忆了一个 CTF 题目实验。题目中 flag 位于某个 if 分支之下，分支条件涉及 $_GET 参数与 sha384 结果比较。讲解者判断，人类看到这个结构后不应只尝试暴力寻找与哈希值匹配的输入，而应重新审视条件能否从其他路径满足。

但当时使用的模型没有及时换路，持续在原有判断方向上尝试，最终把账户中的约 200 元调用额度耗尽。原稿提到模型名称为"千问 3.7/3.8"，转录识别不稳定，因此正文只保留为课堂所述的新模型实例。失败并非单纯"模型不够大"，而是缺少能识别低效循环并及时改变策略的控制机制。高能力模型依然可能在错误假设上持续投入资源。

这个实验使讲解转向 Harness：模型需要被放在一套更大的运行结构里，系统负责限定可用工具、任务预算、执行次数和安全边界，并持续观察是否出现重复、无进展或越权倾向。Harness 不替代模型推理，而是为推理和执行提供管理框架。

这个失败还带出了资源控制的重要性。授课者说模型在一个判断路径中持续运行，直到预算耗尽；从工程角度看，费用上限就是停止条件之一，但并非充分条件。系统还可以关注连续多少轮没有新证据、相同请求重复了几次、是否出现错误响应循环，以及目标范围是否已经偏离最初许可。达到任一约束时，应先暂停并要求重新判断，而不是只等待模型自觉改变主意。

在 CTF 环境中，停止无效搜索可能只关系到时间和额度；在真实系统测试里，持续请求还可能对目标造成负载或引发安全告警。因此，Harness 的约束不仅是性能优化，也承担风险控制职责。它需要把预算、频率、工具权限和任务状态变成实际可执行的限制，不能仅将它们写进提示词后期待模型始终遵守。

六、Skills 是否总有帮助：课堂中的经验判断与对照

技能包既可沉淀经验，也可能收窄探索

授课者对 Skills 的看法并非单向推荐。他先承认，把重复经验写成可调用技能可以降低模型执行某类任务的门槛，尤其当技能是由使用者结合自身经验编写时，仍体现出一定工程工作；但他随后提出另一面：预设技能也可能把模型限制在固定流程里，使其过早套用初学者级的模式，而不是根据新线索灵活推理。

这一判断在课程中用一个比赛观察来支撑。讲解者称，某次腾讯云安全竞赛前十团队很少依赖大量 Skills，并举出一名独立开发者完成全部题目、项目中没有安装大量技能的例子。原稿中的比赛届次、名次与团队名称部分识别不清，且没有附完整参赛材料，因此这里将其作为授课者的经验性观察，而不是独立统计结论。

讲解者还描述了另一位同学使用某个技能包和客户端开展漏洞研究的经历：多数尝试没有结果，但最终在一个低关注度的旧站点上发现问题。授课者认为，结果不一定来自 Skills 本身，也可能与目标系统数量、可见面和偶然性有关。原稿中提到共享密钥、论坛账号和用户邮箱等敏感信息，但未提供核实过程；因此本文不复述可识别对象，也不将未经授权的数据访问包装成成功经验。

图 28：页面截图用于讨论漏洞报告的标题和影响描述，讲解提醒报告措辞不能代替影响核验。

图 29：报告文本展示发现者对问题的描述，课堂据此讨论信息披露范围与证据充分性。

图 30：截图呈现论坛页面及活动时间信息；此类页面数据不应在无授权情况下进一步访问或传播。

授课者的经验观点是：在简历或项目展示中，可以如实说明是否使用 Skills，也可以说明自己为何选择不使用；关键是能解释工具的作用、局限和验证方式。他对"Skills 有时会限制模型"的判断属于个人评价，不能被简化成"Skills 已经过时"或"所有 Agent 都不需要技能"。不同任务的可重复程度、工具稳定性和审计要求都可能改变取舍。

围绕"要不要给模型装技能"，课堂实质上提出了一个对照问题：预制技能带来的稳定流程，是否会降低模型探索新线索的自由度？如果技能编写者对当前目标的理解更浅，技能可能把模型锁定在有限检查项里；如果任务高度重复且步骤经过审计，技能又可能改善一致性、减少重复提示。授课者更担心的是把网上搜来的大量技能未经阅读就全部安装，并误以为数量越多能力越强。

这个判断与 MCP 的讨论其实相互呼应：工具越多，模型所见接口与可采取动作越多，但上下文、权限和审计成本也随之增加。与其只关注安装过程是否"一条命令完成"，不如检查技能实际载入了哪些脚本、调用了哪些外部服务、是否会访问文件系统、是否可能改变数据，以及出错时怎样停止。课程中提到技能集合覆盖扫描、XSS 和 SQL 注入等类别，正因为能力范围较广，审查边界尤其重要。

授课者对模型能力的个人判断是，强模型未必需要大量预制技能才能开展工作。他引用比赛观察，认为部分表现靠前的队伍没有依赖大量 Skills，而是给模型一个清晰入口和目标，让它自行探索。这个观点背后的技术取舍是"固定流程"与"开放推理"的平衡：固定流程更容易复用和审计，但可能错过不同问题的特殊线索；开放推理更灵活，却需要更强的运行时约束和结果检查。不能只拿比赛个案推出所有项目都应移除技能，也不能把大量技能的安装数量等同于工程能力。

求职建议与技术结论应分开

课程多次建议学生把 AI 相关实践写入项目经历，理由是岗位描述开始提及 AI 攻防、智能体或自动化能力。授课者也坦言，行业有热潮与概念包装，部分岗位或面试者可能更关注"是否涉及 AI"。这是求职经验判断，不是关于所有公司的普遍规律。

更稳妥的写法应交代边界：项目是否在靶场或授权测试中完成；AI 读取了哪些信息；调用了什么工具；最终脚本或分析由谁验证；哪些结果没有进一步利用。不能把课堂中"可以这样写"的假设，改写成已经发生的漏洞影响，更不能把想象中的管理员权限或数据获取写成事实。

七、把示例拆成流程：受控目标、API 与登录态

先从前端资源识别 API，再验证响应

课程给出一套 AI 协助测试的示意流程：在获得授权并明确目标后，让浏览器工具检查前端 JavaScript 中暴露的 API 路径，再逐项判断接口是否需要认证、权限是否匹配以及响应是否包含不应公开的信息。讲解提醒，代码中出现 API 地址并不等于接口可未授权访问；看到 list、admin 等名称也不能直接推断可读取用户清单。

讲解者对接口结果作了区分：某个 GET 接口若返回列表，可能暴露可读数据；某个 POST 接口若允许创建资源，则需要更谨慎地在授权测试中确认权限检查。原稿提出了"如果 API Key 可创建管理员"一类简历叙述，但这只是课堂构造的可能案例，不是既成事实。端点被发现、端点可访问、端点越权以及数据影响，是不同层次的证据，不能合并为一个结论。

图 31：截图展示课程演示中提及的资产检索服务页面，体现外部数据源需要单独配置和授权。

图 32：页面列出若干发现结果，说明资产清单只是后续验证的候选范围。

图 33：请求列表用于定位网页实际调用的接口路径，发现路径后仍需验证访问控制。

图 34：截图把登录界面和浏览器调试区域并置，演示如何在授权测试中关联页面操作与请求。

图 35：接口路径列表来自前端观察，是否可访问以及允许的权限仍需逐项确认。

图 36：页面展示接口访问反馈，说明端点存在并不意味着访问成功或返回敏感内容。

课堂示意中，AI 可依序读取前端文件、提取路径、观察请求响应，并对授权范围内的结果做分类。若页面没有暴露敏感信息，流程就应如实停在"未发现可确认问题"，不能为了形成项目故事而补造管理员创建或数据泄露结果。

密码喷洒和 RSA 参数重建的课堂示例

课程接着回到登录场景：在经过批准的测试账户与测试范围内，若密码验证需要按固定规则构造请求，浏览器抓包可以提供客户端实际发送的字段；AI 再帮助分析参数与前端 JavaScript 的关系。原稿举出了 Burp Suite、Python、RSA 和延迟控制等名词，并描述了使用假账户验证脚本的过程。

讲解者指出，账户锁定策略会影响测试设计：如果对单个账户连续尝试过多密码，可能触发风控或锁定。因此课堂展示中提到了减少每个账户尝试次数、添加请求间隔等想法。原稿中出现具体延迟值、并发建议和账号/密码测试逻辑；为了不把这段课程讨论变成可直接滥用的操作配方，本文保留其工程教训而不扩展成可执行脚本：必须由系统所有者明确提供测试账户、速率上限和停止条件，任何并发或速率调整都应符合授权范围。

图 37：对话截图显示模型根据给定样例理解请求参数，输入样例不应包含无权处理的真实凭据。

图 38：代理界面用于查看授权测试账户正常登录时的请求形态。

图 37：课堂在随后演示中再次展示同一提示画面，用于延续前端参数分析步骤。

授课者提到，向模型提供一个真实的登录请求样例，比只用自然语言描述"账号密码经过加密"更容易让它定位字段关系；但敏感数据应使用测试账号，且不应把真实 Cookie、口令或密钥直接交给不可信服务。课程随后演示模型调用浏览器打开页面并观察加密逻辑，模型很快将参数识别为 RSA 相关处理。这个结果依赖页面脚本可见、算法实现简单且未混淆等原稿条件。

图 39：扩展菜单展示 Cookie 管理工具，说明登录态可通过浏览器会话进行检查。

图 40：调试窗口用于继续查看授权会话中的脚本与请求，不代表可任意导出或复用他人登录态。

讲解者还说明，在需要检查登录后的页面时，可以先由测试人员完成正常登录，再考虑如何把浏览器会话交给自动化流程。原稿提到 cookie editor 扩展和将 Cookie 导出为文件的方式。由于 Cookie 等同于会话凭证，复盘只记录"登录态是分析前端代码的一种上下文条件"，不提供凭证导出、保存或复用的操作步骤。使用此类数据必须遵循组织凭证管理规则并避免把会话令牌交给未经批准的模型环境。

八、检查脚本结果与岗位要求：不把包装当成证据

测试脚本的验证阶段

课堂截图展示了模型生成 Python 脚本后的测试过程，包括对假账户进行验证、检查生成的请求字段，以及讨论是否设置延迟。授课者认为脚本确实可以缩短逆向和样例编写时间，但同样指出，参数、尝试次数和延迟策略若不符合目标系统的限制，可能触发风控或造成服务负担。

图 41：界面记录模型对脚本流程的说明，代码生成后仍需人工审查边界和副作用。

图 42：代码截图展示脚本结构，复盘重点是审查输入、请求频率和停止条件。

图 43：终端中可见测试参数配置，任何频率设置都必须服从授权方给定的上限。

图 44：结果表格呈现候选测试项的组织方式，不能据此推断真实用户遭到尝试或成功登录。

从复盘角度看，脚本"跑起来"只是中间结果。还要确认测试数据是假账号还是授权账号，目标是否为指定环境，服务器响应是否符合预期，异常是否触发锁定，以及最终是否在范围内停止。课程给出的求职叙述若要可信，就应该明确"分析了 RSA 参数、构造了测试脚本、用假账户验证"，而不是夸大为已获取生产系统权限。

岗位描述提供学习方向，但不能替代事实核验

授课者展示了绿盟科技等岗位信息，指出安全类职位中出现 AI 攻防、Agent 提示词或自动化开发相关要求。讲解者据此建议学生研究安全智能体、自动化漏洞分析项目，并能解释模型、工具和执行环境分别承担什么职责。

图 45：岗位列表截图为课堂讨论提供招聘需求背景，不代表所有企业要求相同。

图 46：职位说明呈现漏洞挖掘、自动化等要求，课程据此推导学习重点。

图 47：搜索结果作为开源项目发现入口，项目质量仍需结合文档和实际实现评估。

图 48：仓库页面展示项目结构与说明，课程提醒不能只凭宣传语判断效果。

授课者拿一个面向 Web 与 API 分析的安全 Agent 项目作例子，认为此类框架可以分析源码、编写利用验证并组织测试流程；同时也提出，许多项目的实际效果可能主要受底层 LLM 能力影响，外部框架所增加的工具接入和状态管理未必自动提高测试质量。

图 49：流程图展示项目组织任务的方式，图示架构不等于实测效果。

图 50：仓库内容用于查看项目依赖、功能说明和实际代码入口。

图 51：文档说明展示项目声称提供的能力，课堂将其与验证结果区分。

比较客户端与专用框架

课程提出一个实用的对照方法：给通用客户端和专用 Agent 相同的授权靶场、同一提示词及相同时间预算，再比较任务完成度、有效证据、误报、请求数量和人工介入次数。授课者的个人判断是，部分包装得很完整的 Agent 项目，实际效率可能不如直接使用模型客户端加少量工具；但原稿没有附这组正式对照测试的完整数据，因此本文把它保留为建议的评估方法，而不称为已验证的普遍结论。

图 52：资料列表展示多种项目与工具条目，可作为后续比较对象。

图 53：导航页聚合项目介绍和资料链接，课堂建议从原始材料而非二手宣传入手。

图 54：仓库文件结构用于判断项目实际包含哪些模块。

讲解者还借助腾讯云安全竞赛的历届材料讨论项目名次、开源情况和后续热度之间的关系。他的观点是：Star 数和宣传热度可作为检索线索，却不能单独证明架构适合真实工作；反过来，一次比赛名次也不足以完整评价一个项目的长期质量。更有价值的是阅读答辩 PPT、架构图和代码，并尝试在受控任务中比较其表现。

课程里的研究路径是先看公开展示材料，了解项目想解决什么问题、比赛约束是什么，再回到代码核对架构图中的模块是否真实存在。若项目开放了演示或 API 文档，可以从输入格式、执行流程和结果返回方式入手；若没有源码，则能形成的结论应停留在文档描述层面。授课者建议挑选一两个竞赛中表现靠前、资料较完整的项目深入阅读，而不是只收集大量仓库链接。

这种研究也可以形成自己的二次开发问题。比如某项目原本针对竞赛题目，使用题目同步和结果提交作为入口；若改造成其他用途，首先要判断其任务输入、状态模型和安全边界哪些仍然适用，哪些需要替换。课程提出将 URI 作为一种可能输入方向，但这并不意味着直接把题目系统改为在线扫描器就完成了迁移。输入范围、授权证明、停止机制和证据留存仍需重新设计。

图 55：招聘页面记录课程中的岗位观察，职责要求应按时间和企业背景理解。

图 56：页面用于定位竞赛答辩材料，是研究项目设计的来源入口。

图 57：列表展示参赛项目条目，便于选取公开材料进行横向研究。

图 58：资源目录显示部分项目开放情况，开源与否不直接等于项目优劣。

图 59：索引页面汇总演示材料和文档，支持进一步核对架构描述。

九、从岗位要求回看 Agent 工程结构

学习内容按目标岗位筛选

课程回到岗位要求，建议先理解安全基础，再补充攻防智能体的构造与研究经验。授课者的学习方法是：从职位说明里的关键词入手，找到相关公开项目，再阅读其架构文档、比赛答辩资料和代码；若看不懂，可以让 AI 帮助解释公开代码，但要回到原文核验关键结论。

这个顺序也回应了课堂对"岗位驱动学习"的强调：先确认目标岗位真正要求什么，再选择值得投入的资料。若职位强调漏洞原理，应该补充常见漏洞与验证方法；若提到智能体研发，则应研究模型与工具的协作、执行隔离、状态维护和异常恢复；若提到微调或数据构建，就要了解数据来源与评估。授课者建议关注一到两个较成熟的竞赛项目，而不是追随所有热点，这样更容易形成完整、可讲述的理解。

对开源项目的学习也不应只摘抄宣传页面。可以先读答辩材料理解作者想解决的问题，再根据目录寻找入口模块，追踪一次完整任务的输入、模型决策、工具执行、结果记录和完成判定。随后对照岗位要求，思考当前设计有哪些部分适用于目标场景、哪些部分需要调整。只有经过这个过程，项目阅读才会从"看过某仓库"变成可展示的分析能力。

这一方法避免了只收集技能名词。比如"熟悉 MCP"需要能说明客户端、服务端、工具定义和调用过程；"研究 Agent"则应能解释模型如何调用工具、任务状态如何传递、失败如何恢复，而不是只会说它能自动化。面试建议也因此与技术学习相连：做过什么、观察到什么、验证了什么、仍有哪些局限，都应能说清楚。

图 60：封面页标示后续分析的架构主题，提供进入具体设计图的上下文。

图 61：页面并列显示若干项目标识，说明课程借多个方案比较共性设计。

图 62：总体架构图呈现控制、执行、协调与状态模块之间的关系。

控制平面、执行平面与消息通路

授课者分析的架构将控制平面与执行平面分开：控制侧负责统一配置、任务规划与调度；执行侧负责调用工具并完成具体任务；消息通路传递指令、状态和结果。讲解者用"司令部与执行单元"的比喻解释解耦：控制逻辑不必与某个具体任务的执行细节混在一起，执行结果再通过消息通路回到控制侧。

把这张架构图转换成运行时问题，可以依次追问：谁创建任务、谁选择模型、谁决定工具清单、谁创建执行环境、结果如何回传、失败由谁重试、任务结束后状态归谁保管。若所有逻辑集中在单一 Agent 里，这些职责容易互相混杂；若分成控制和执行两侧，则消息格式和状态所有权必须定义清楚。课堂称这样的拆分为"解耦"，但也指出消息总线必须可靠地传递执行事件，否则控制侧就无法基于新状态决定下一步。

图 63：图中强调统一配置模块，它可汇集模型、工具及可选技能等运行参数。

图 64：规划与调度模块负责安排任务和执行单元，避免多个任务互相争抢资源。

课程列出统一配置中心可能管理的内容，包括提示词、Skills、工具、MCP 和模型。它们是可配置能力，不应被理解为每次都必须全部启用。调度器则负责把项目任务分配给不同 Agent：一个执行单元忙于当前工作时，控制侧可以考虑把其他工作交给空闲单元。

模块之间的职责边界还能帮助排查失败。如果 Agent 没有调用工具，问题可能出在任务规划、工具描述或权限配置；如果调用了工具但没有执行成功，需要看执行容器与目标环境；如果执行成功却没有更新后续状态，则可能是消息返回或状态汇总出错。课程没有逐一给出故障日志，但架构分层本身提供了定位路径：先问失败发生在哪个阶段，再检查该阶段的输入输出，而不是笼统归因于"模型不好"。

图 65：协调层图示包括题目信息、提示、提交和状态等部分，体现竞赛系统的任务特点。

讲解者指出，架构原本针对竞赛挑战，因此包含题目同步和提交标记等模块；若要用于一般安全评估，需要重新设计输入和任务管理方式。例如可将指定 URI 与授权范围作为任务输入，但这只是可扩展方向，不能直接把竞赛自动化流程用于未授权站点。

挑战协调层尤其值得注意，因为它把业务规则写进了 Agent 的任务生命周期：题目如何分派、执行状态如何显示、什么条件算完成、结果如何提交。迁移到其他领域时，原有的"提交 flag"就不再适用，完成条件可能应变成生成证据包、通知负责人或停止测试。若没有重新定义完成条件，Agent 可能在发现线索后继续扩大动作，或在尚未得到可复查结果时过早宣布结束。

图 66：流程图展开协调层中的交互与结果管理，说明业务场景会影响模块设计。

调度、隔离与执行容器

架构的运行时部分会为并行工作安排多个 Agent。课堂描述为多个相互隔离的 Kali 容器，每个容器内运行客户端并调用所需安全工具。隔离的目标是降低执行环境之间的互相影响，避免对宿主环境造成污染；这种设计本身仍需要配套的权限、网络出口和资源管理。

容器隔离解决的是执行环境之间的部分隔离问题，并不自动保证测试安全。容器仍可能访问配置给它的网络、凭证和挂载文件，因此还要明确它可以访问哪些目标、能否访问宿主资源、工具是否有写入能力以及输出如何保留。课程强调了"容器之间互不污染"的工程优点；完整方案还需把这些权限条件纳入架构审查，不能把容器化当成授权或风险控制的替代品。

图 67：运行时层图示突出容器、调度、事件传递与资源管理等职责。

图 68：拓扑图把控制模块、执行单元与消息总线放在同一视图中。

图 69：图示强调控制面与执行面分工，执行单元通过通路回传状态。

图 70：图中列出并发、工具范围、资源预算和通信方式等约束项。

授课者将 Harness 具体化为几类工程限制：最大并发数、允许使用的工具范围、每个执行单元的 CPU 与内存预算、通信协议，以及不得越界的安全规则。课堂示例把并发限制为三个，理由是过多执行单元可能抢占资源、降低效率。约束不是为了让模型"变笨"，而是为了让执行规模、工具能力和影响范围始终处于可控状态。

这几类约束各自解决不同问题。并发上限控制同时运行的任务数；工具白名单限制执行单元可以采取的动作；CPU、内存和时间预算避免资源无界消耗；通信协议让控制侧与执行侧能够交换状态；安全边界则用于阻止删除、写入或越权访问等不允许行为。若这些限制只是界面上的选项而没有被执行器强制执行，就仍可能被模型生成的计划绕过，因此需要在工具服务或运行时层落实。

课堂把几个 Agent 比作多个员工，调度器负责根据各自忙闲情况分配任务；把消息总线比作前线与指挥中心之间的通信；把共享记忆比作交接记录。这些类比帮助理解模块关系，但实际工程还必须处理任务重复分配、超时、执行失败和状态过期。若一个执行单元已经结束但状态没有标记，调度器可能再次分配相同工作；若消息只传最终结果而丢失中间失败原因，后续 Agent 就无法判断哪些尝试已被排除。

课程提到挑战系统会把题目信息、Hint、Flag 提交和状态展示放在协调层。这个设计体现了业务流程如何嵌入 Agent：输入不只是自然语言，还包括任务对象、运行阶段和完成条件。把它用于安全研究时，应把"完成"定义成收集到可复查证据、按要求结束测试并形成报告，而不是默认以成功利用作为唯一目标。这样的定义能减少 Agent 为追求任务完成而采取超出授权范围动作的风险。

图 71：岗位截图显示智能体研究、模型原理等关键词，呼应前述学习方向。

十、模型微调和数据质量：从概念解释到案例复盘

微调的目标与课堂定义

课堂把模型微调解释为将通用能力进一步适配到垂直领域：当组织内部只能部署参数规模较小的模型时，可以使用领域资料和经验数据进行训练或微调，使其在特定任务上更贴近业务需要。讲解举了医生、律师和网络安全工程师的例子，说明专业数据可能影响模型在领域任务上的表现。

这段解释是面向入门理解的课堂概括，不是对微调方法、数据治理或模型效果的完整技术定义。讲解者同时强调，数据质量会影响最终表现，数量大并不自动意味着质量高。为说明这一点，他分享了一个医学影像项目经历。

低质量报告让模型学会了错误捷径

授课者讲述，曾参与一个病理影像相关项目，使用的 X 光数据来自海外公开集合，规模约十万张，但配套报告质量不理想：在他的观察里，许多报告内容重复，且与影像之间的对应关系不足。微调后的模型出现了明显问题：它似乎学会模仿医生报告的表达方式，而不是识别图像特征；即使输入花草照片，也会以肺部诊断口吻给出描述。

讲解者把这一失败归因于训练数据和监督信号的问题：若报告本身不能可靠说明图像差异，模型仍可能找到更容易获得奖励的语言模式。这个现象让项目团队回到数据准备，而不是继续假设只要模型够大就会自动理解图像。

授课者进一步用奖励机制解释模型为何会学到这条捷径：训练过程中，监督信号会对符合预期的回答给出更好的评价，对偏离目标的回答给出较差评价。如果训练样本里的报告高度重复，模型可能发现模仿医生的措辞就足以获得较好反馈，而无需真正利用图像内容。于是，即便输入图像变化很大，输出仍维持相同的肺部诊断口吻。这个例子强调，监督目标若没有有效区分"看懂图像"和"写得像诊断"，模型就可能优化错误的能力。

图 72：职位描述截图中出现模型和数据构建相关内容，引出对数据质量的讨论。

课程随后描述了数据改进尝试。第一步，使用 YOLO 对 X 光图像中疑似病灶区域进行框选标注；第二步，从十万张图像中挑选约一千张；第三步，借助授课者所称的高能力模型为选取图像生成诊断报告；第四步，把图像标注与新生成报告组合，再进行一次训练或微调。授课者认为这比直接使用原始低质量报告更合理，但也坦言改进后的结果仍然一般，并未达到预期。

图 73：搜索结果展示 LLaMA Factory 项目入口，课程将它作为微调框架的学习线索。

图 74：项目页面说明其面向模型微调，授课者借此介绍可视化工具路线。

图 75：界面截图显示数据集、模型等配置位置，实际训练仍取决于数据、参数和算力条件。

这个案例保留了一个重要的失败结果：即使选择图像、增加标注并生成新的配套报告，模型效果依旧有限。课堂没有给出完整数据集、训练参数、评测集或量化结果，因此无法据此比较模型能力；可确认的复盘经验是，数据构建的合理外观并不能保证有效，仍需用独立评测验证模型是否真正学到目标能力。

案例里至少包含两个容易混淆的目标：让模型识别图像中的异常区域，以及让模型生成符合专业表达的报告。如果训练材料的报告重复，即使文本看起来像专业诊断，也未必携带足够的图像差异信息；模型可能只学到报告口吻。YOLO 标注框的加入试图为图像提供更明确的区域信号，而重新生成报告则试图提高文字标签质量。两种调整针对的是数据链条中的不同缺陷，不能简单归为"多加了 1000 张数据"。

然而，授课者明确说改进方案仍然效果一般。这意味着在数据抽样、标注准确度、报告生成、图文对应关系和训练目标之间，至少仍有未解决因素。若没有独立的测试集和人工复核，就无法判断模型究竟改善了病灶定位、报告一致性还是只改变了输出格式。对外复盘时，保留"方案合理但结果仍一般"比只陈述数据处理步骤更重要，因为失败结果说明下一轮需要回到评估，而不是把尝试误写成成功。

微调参数和岗位准备

讲解者建议学习者了解学习率、训练轮数等常见参数，并熟悉 LLaMA Factory 一类项目的基本用法。课堂指出，可视化界面降低了开始训练的操作门槛，但不意味着使用者可以忽略参数含义。面试中若声称做过微调，应能说明数据来源、预处理、目标任务、评估方法和遇到的失败，而不是只说"点了开始"。

授课者进一步把数据准备与岗位中的日常工作联系起来。他认为，许多模型相关工作并非持续发明新算法，而是需要整理海量原始资料，处理 HTML、PDF 和其他格式中的噪声或重复内容。这个比例判断是他的从业观察，原稿没有给出岗位样本或统计数据；它在课程中的作用是提醒学习者，不要只把 AI 岗位想象成设计模型结构，也要理解数据质量、格式清洗和评估准备等基础工作。

课堂还提到，若面试官问到微调框架，可以查阅项目文档并了解其定位、常用配置和数据输入方式；但"能说出框架名称"与"有微调实践"应区分。对于没有实际做过的内容，适合说明自己研究过流程、能解释参数含义，而不应把学习演示写成独立完成的模型训练项目。授课者提出的框架调研建议，核心仍是把知识落实到能够解释的操作与结果上。

授课者还给出"基础研究与 AI 研究都值得投入"的结论：安全基础仍然重要，AI 相关知识也开始进入岗位要求。对于暑期或求职准备阶段，他建议把 Skills、MCP、微调和 Agent 循环分别弄清用途，花一两天阅读材料并借助 AI 解释不懂的代码或流程。这里的学习建议强调先建立概念地图，再深入一两个项目；不需要把所有名词都包装成实践经历，但应能辨别它们各自解决什么问题。

图 76：参数配置页面呈现训练选项，理解参数含义比单纯完成界面操作更重要。

图 77：资料页用于继续查看项目和训练工具的相关说明。

十一、全局状态、子 Agent 与观察者机制

管理器分配边界，状态层汇总进展

回到安全 Agent 架构后，讲解者把控制中心职责归纳为限制模型行为、调度工具以及规划任务。多个 Agent 分别承担不同工作时，需要有共享状态来记录各自发现和进展；否则某个执行单元完成后，后续单元可能重复探索，或者不知道此前已验证的条件。

图 78：结构图中管理器负责任务、策略和执行协调，支撑多个工作单元并行推进。

图 79：图中展示多个执行单元围绕共享状态开展工作，结果可被其他单元复用。

课程以三个 Agent 为例：一个观察开放端口，一个依据服务信息继续整理待验证问题，另一个负责对已知结果进行受控验证。执行单元各自保留局部过程，再把整理后的信息提交到全局记忆。新的执行单元启动时，可以读取先前的状态，减少重复劳动。

图 80：图示表现局部执行结果汇总至全局状态的过程。

图 81：状态更新后向其他执行单元广播，使后续任务能获得最新进度。

讲解者把新 Agent 读取已有记录比作学习者站在前人积累之上。工程上的重点在于，系统应该传递经过整理的事实和失败边界，而不只是无限累积原始日志。若不区分已验证信息、推测和待办事项，错误也可能随着广播被复制到新的执行单元。

图 82：流程图说明新 Agent 启动后载入共享记忆，以延续此前探索。

图 83：图示以迭代过程展示经验如何成为下一轮工作的输入。

图 84：图中展示局部信息经过提炼后写入全局状态，再同步到后续任务。

观察者识别低效循环，但轻微纠偏未必够

课程继续展示一个 Agent 在渗透挑战中的运行步骤：先做信息收集，再进行目录和参数探测，然后进入漏洞验证与重复扫描。讲解者认为，随着上下文不断增长，模型可能逐渐遗忘早期发现，随后重复尝试已经没有新信息的步骤。

图 85：章节页引出 Harness、记忆和观察者三个设计主题。

图 86：流程图展示从信息收集到重复探测的阶段变化，红色标注指出低效区段。

图 87：图中显示任务在多轮重复操作中推进有限，需识别是否产生新证据。

授课者将观察者（原稿称 hammers，此处沿用课程中的 Harness/Observer 语境）描述为旁路监控组件：它不直接执行任务，而是观察若干轮结果，判断是否反复出现 404、响应无变化或没有新增线索。观察者识别出低价值重复后，可以建议更准确地调整验证方向，或回到已经确认的输入点。

检测低效循环不能只依赖单个状态码。课堂提到反复出现 404 和无变化响应，是因为它们直观地说明当前请求没有带来新线索；更一般的判断还应比较响应内容是否相同、任务状态是否前进、是否发现新端点或新证据，以及此前确认的假设是否已经被验证。若只看到状态码相同就自动生成更多载荷，观察者本身也可能重复制造噪声。

图 88：提示画面记录观察者检测重复后的建议，纠偏仍需检验是否改善进展。

图 89：该截图展示轻量纠偏后的任务状态，课堂指出提示可能把模型引向新的无效分支。

讲解者提到一次具体失败：系统运行到约 96 轮后，观察者建议继续尝试更精准的载荷或更多候选值，结果没有及时停止既定路线，反而延长了搜索。原稿提及 sha384，并称"轻微纠偏"引发了问题。由此得到的工程判断是：观察者只能给出提示，若没有预算上限、进展判据或人工停止条件，它仍可能使循环继续，而不是把模型从死胡同中拉出。

这个失败说明"观察"和"干预"之间存在距离。观察者可以识别某种模式并提出建议，但执行 Agent 仍会根据原有目标解释建议；如果建议只调整参数而没有重新审视假设，它可能把低效循环延长成更大的搜索空间。一个有效的停止或纠偏机制应能升级动作：先标记当前路径低效，再暂停相关执行，回顾已知事实与失败边界，最后决定转向、请求人工判断或结束任务。课堂案例中的轻度提示没有达到这一步，因此保留失败过程比笼统说"有观察者就能解决偏航"更准确。

图 90：架构页展示观察者、局部状态与记忆区域之间的分工。

Idea、Memory、事实与失败边界

课程把原始工具输出、日志、上下文碎片和环境约束视为需要整理的材料，并用双层状态板说明整理后的类别：Idea 用来记录值得继续验证的方向，Memory 用来保存已确认事实。两类信息混在一起，会让后续执行单元把猜测当作结论。

图 91：侧边结构显示观察者记录的类别，为后续双层状态板的介绍作铺垫。

图 92：双层看板分别容纳待探索方向与已确认信息，便于区分假设和事实。

例如，输入单引号后出现错误可以记为一个待分析方向，且标注该现象需要进一步验证；已经确认开放的端口及其服务则可以作为事实保存。若多个授权测试请求均无回显，课堂建议将其记录为失败边界或低优先级方向，而不是无限重复发送相似请求。

图 93：看板截图呈现待验证事项及其状态，提示应跟踪证据而非只保留结论。

图 94：记忆板将已知事实、受限条件和失败尝试区分记录，供后续任务使用。

授课者列出的失败边界包括：命令执行没有回显、XSS 受到过滤、文件上传限制类型等；这些应成为系统停止重复尝试或转向其他验证方向的依据。他还提到 Hint，也就是由人类预先加入的提示。当测试人员对某个现象已有可靠线索时，可以把它作为假设或待查方向交给 Agent，但提示仍需要验证，不能直接写入"已确认"状态。

图 95：流程图展示状态维护者对信息去噪、分类后再同步给新执行单元。

图 96：整体架构图呈现观察者、状态板和执行单元之间的数据流动。

课程还强调访问约束，例如每分钟请求数量上限，用来降低触发封禁或造成服务压力的风险。这个数值是原讲解中的架构示例，不应被视为适用于所有系统的通用速率。真正的限制应由目标所有者与测试计划确定，并由 Harness 在执行时强制实施。

记忆是双刃剑

讲解者指出，持久记忆有助于跨轮次复用经验，但错误记录如果不失效，也会持续影响后续推理。人类会遗忘一部分信息，模型系统则可能把写入的内容反复传给后续执行者，因此记忆需要来源、状态、时间和验证程度等上下文。课堂没有展开具体数据库或数据结构实现，复盘重点是"存什么、何时更新、谁能纠正"。

如果把这一经验转换成工程记录，单条状态至少要区分事实、假设、动作结果和待办事项。事实应能追溯到某次观察或测试；假设应保留置信程度与验证方式；失败记录要说明在什么条件下失败，而不是只写"不可用"；待办则要有继续条件。这样，新的 Agent 才能知道某项信息是已验证证据还是仍需确认的方向，也能在环境发生变化时重新评估旧记忆。

图 97：总体图把观察、记忆整理与下一轮执行连成闭环。

十二、通过简化示例理解 Agent Loop

研究完整系统前，先看最小工作循环

在讲完 Harness 和记忆板后，课程推荐学习者阅读一个简化的 Agent 示例项目。讲解者提到 Claude Code 及其学习材料，并主张通过更精简的 Demo 理解 Agent 的循环，而不是一开始就直接阅读规模庞大、调用链复杂的完整实现。原稿中还提及源码公开或泄露的说法，但未提供来源，因此这里仅保留"阅读简化项目以理解结构"的学习建议，不重复未经核实的来源表述。

图 98：搜索页面显示相关学习资源入口，课程建议从可读性较强的材料开始。

图 99：项目首页用于介绍学习目标，重点是借助缩小后的实现观察核心机制。

图 100：章节列表展示项目讲解范围，可按循环、工具、权限等概念逐步阅读。

图 101：仓库文件列表便于从入口代码开始追踪最小执行路径。

图 102：目录页列出任务、记忆和工具等主题，展示 Agent 不止是单轮提示词。

图 103：页面展示上下文压缩主题，提示有限上下文会影响长对话中的信息保留。

课程列出学习简化 Agent 时需要关注的模块：循环调用、工具使用、权限控制、Hook、待办清单、子 Agent、Skills、错误恢复、记忆管理、上下文压缩和并发。讲解者认为，任务清单有助于模型在长任务中回看当前目标；记忆用于保留已整理的信息；错误恢复则决定失败后是重试、换路还是停止。

图 103：同一课程页面在讲解压缩机制时再次出现，用于强调上下文容量有限这一主题。

对循环的具体解释从一条用户消息开始：模型先读取消息历史，再判断能否直接回答，还是需要调用工具。如果需要调用，客户端执行工具并把结果追加到消息列表，模型重新读取更新后的内容，再判断是否继续调用。只有在模型认定任务已完成时，循环才返回最终答复；如果尚有操作未完成，就会继续下一轮。

图 104：流程图展示消息进入模型后，模型决定直接回答或请求调用工具的主循环。

图 105：标注图补充了消息、模型判断、工具执行与结果回填之间的顺序。

图 106：流程页面显示循环中多个阶段的衔接，可与上一张手绘图互相参照。

图 107：岗位页面再次呈现智能体相关描述，作为课程学习建议的现实背景。

图 108：职位内容与前图属于同一招聘主题，强调理解 Agent 基础而非仅列名称。

消息历史与工具往返

讲解者用一个创建文件的例子解释循环。用户提出"创建 hello.py"后，模型先阅读历史消息并判断是否需要工具；如果要创建，就调用文件工具，工具完成后把结果追加回消息历史，再由模型读取更新后的内容。如果模型判断任务已完成，就生成最终答复；如果还需要写入代码，则会再次发起工具调用。

这个循环也解释了上下文为何会增长：用户输入、模型判断、工具调用和工具返回都会成为后续决策的历史信息。历史让模型记得此前发生过什么，但容量有限，过长时就需要压缩或总结。课程进一步用多步骤任务说明，一个请求可能先创建文件，再写入内容，每次工具执行都要把结果回填，模型才知道下一步是否仍需动作。

课堂用不需要外部资料的问题作了对照：若用户询问新中国成立的年份，模型可直接回答，不需要执行工具，循环随即结束；若用户要求创建 hello.py，就需要调用文件操作工具，等待工具反馈后再判断是否完成。若请求进一步要求"创建文件并写入一段脚本"，则单次创建还不够：第一轮完成创建，工具结果返回后，第二轮还需调用写入能力，完成后再让模型读取新的历史并确认任务状态。每一次调用都是一条新消息加入上下文，模型依据完整消息列表决定继续或停止。

因此，Agent Loop 并不是模型一次性生成一串动作后就结束，而是"读取当前历史---做出决策---必要时调用工具---接收结果---重新判断"的往返。若工具返回失败，失败信息也应进入历史，使模型能够选择修正、重试或终止；若工具返回成功，模型仍需核对它是否完成用户要求。上下文压缩发生在这些往返积累到一定规模之后，其目的不是保留所有原文，而是提炼继续完成任务所需的状态。

图 109：压缩流程图展示长任务中信息如何被精简，并留下可供后续执行的状态。

图 110：总结页呈现保留信息的类别，呼应 Idea 与 Memory 的状态整理方式。

课程特别区分了 Subagent 与 Agent Team：前者的执行单元可由主 Agent 统一调度，但彼此不一定直接通信；后者则允许多个 Agent 之间互相交流。实际产品实现可能有不同命名和拓扑，课堂建议是不要把"并行执行"误当成"执行单元之间可以互通"。阅读项目时需要检查消息路径、状态归属和权限边界。

这一差别会影响任务协作设计。如果采用 Subagent 模式，子任务结果通常要经过主 Agent 汇总，主 Agent 再决定如何把必要信息提供给其他子任务；这使协调关系集中，但主 Agent 也可能成为状态汇总的瓶颈。如果采用可以互相通信的 Agent Team，成员之间能直接交换信息，但同时需要解决消息冲突、共享事实的来源和权限一致性。课堂没有评估哪种拓扑一定更优，结论只是两者是不同的协作模型，应先确认产品实际提供哪一种通信能力。

读代码时可以从最短的调用链开始：用户消息怎样进入历史，模型响应如何区分普通文字与工具调用，调用参数如何校验，工具结果如何作为新消息写回，以及循环在哪个条件下退出。然后再逐步查看任务列表、Hook、并发、子 Agent 和压缩机制。这样的阅读顺序能够从一轮可运行流程建立整体认识，再定位工程扩展点；直接从复杂框架的目录树开始，容易被模块数量淹没而抓不到主链路。

对外介绍 Agent 时，也应避免把它抽象成"自动完成一切的智能体"。课程中的 Agent 至少依赖模型、工具定义、执行环境、状态存储、任务约束和循环控制。模型负责提出下一步，工具负责连接外部能力，Harness 负责限制与观察，记忆负责保存可复用状态。任何一个环节缺失或失效，都可能表现为不调用工具、重复调用、忘记早期结果或越过预设边界。

十三、复盘结论与学习建议

技术路径的共同结构

从签名重放到 Agent 工程，课程不断回到同一套问题分析方法：先描述真实限制，再观察工具给出的证据；一次操作后记录结果，区分成功、失败和未知；据此更新下一步假设；最后把验证过的信息与待查方向分开。PDF 定位案例从页面请求走到资源请求，再从候选 URL 走到浏览器验证；Agent 案例则从工具调用走到状态回填，再从重复响应走到观察与纠偏。

这些案例也说明，自动化不能替代验证。模型能帮助读取 JavaScript、生成脚本或总结开源架构，但是否访问了正确资源、签名逻辑是否复现、接口是否越权、训练数据是否有效，都需要可复查的证据。失败结果不是要从文章中删掉的瑕疵：模型循环耗尽预算、观察者纠偏失效、微调结果仍不理想，恰好揭示了系统边界。

对求职与学习路径的建议

授课者最后提出几项学习建议：理解 MCP 与 Skills 各自如何暴露工具或任务能力；弄清 Agent 的循环、工具调用、记忆和上下文压缩；阅读一到两个安全 Agent 开源项目及其公开答辩材料；如对微调方向感兴趣，则了解数据准备、训练参数和评估方法。学习成果应能转化成具体说明，而不是停留在安装了哪些工具。

原稿末尾还补充了若干可作为项目构想的方向，包括 AI 辅助 IDA 做应急响应、通过 Skills 组织内网授权测试，以及让 Agent 在明确范围内完成自动化任务。这些内容是授课者给出的方向建议，不代表课堂已经完成了这些项目。学习者若采用其中某个方向，应把它进一步限定为一个具体问题，并设计授权数据、测试环境、可观察结果和人工复核环节；否则"AI+某工具"的组合仍只是标题，没有可验证的技术内容。

面试与简历方面，授课者建议围绕真实项目说明 AI 如何参与：它读了哪些前端资源、如何协助重建请求格式、工具权限如何设置、测试范围如何界定、结果如何验证。若某个环节只是设想或演示，就应明确标注为方案或实验，不要包装成生产环境成果。授课者关于"简历里应当加入 AI 项目"的建议，是基于其观察到的岗位变化与个人经验；求职者仍应以岗位实际要求和自身可证明的工作为准。

安全研究也不应把"自动化"当作无限扩大目标范围的理由。任何子域名发现、接口检查、凭证测试、请求重放或漏洞验证，都必须依赖明确授权、限定资产、允许的测试方式、请求频率与停止条件。若无法确认范围，就不应让 Agent 自行扩大扫描；若出现真实数据或权限变化，应按授权方的流程及时停止并报告。

复盘结语

这堂课的主线不是推荐某个 MCP、Skills 包或 Agent 框架，而是借多个案例讨论工具如何进入工程流程。前端逆向案例说明，AI 可以在上下文可见、目标明确时帮助梳理客户端逻辑；Harness 案例说明，多 Agent 并行仍需要约束、记忆、观察和预算；微调案例则说明，数据与评估质量会限制模型表现。

因此，能否把 AI 用好，最终仍取决于工程判断：问题是否定义准确，证据是否充分，权限是否合适，失败是否被记录，结论是否经过验证。把这些环节说清楚，比单纯声称"使用 AI 完成了自动化渗透"更有复盘价值，也更适合对外发布。

回看全篇，课堂给出的技术取舍可以归纳成几个相互关联的判断。浏览器自动化让模型接触到真实页面，但请求签名、会话状态和资源权限仍要逐一分析；MCP 让工具能力可以被结构化调用，但工具描述和权限边界需要控制；Skills 可以沉淀流程，也可能限制探索；Harness 可以观察和约束 Agent，但观察者若只做轻微提示仍可能纠偏失败；记忆帮助跨 Agent 传递经验，却可能固化错误；微调能够面向特定任务，但数据质量和评估决定实际效果。

这些判断共同指向一项复盘习惯：每当工具提供了新能力，都要同步问清楚它新增了什么权限、需要什么上下文、结果怎样验证，以及失败时如何停止。只有把这些问题纳入设计，自动化才会成为可靠流程的一部分，而不是把原有的不确定性放大。