目录
[一、复盘范围：把 AI 能力落实到可验证的项目](#一、复盘范围：把 AI 能力落实到可验证的项目)
[二、先让 BreachWeave 运行：容器启动与端口占用](#二、先让 BreachWeave 运行：容器启动与端口占用)
[2.1 从源码说明确认启动顺序](#2.1 从源码说明确认启动顺序)
[2.2 端口冲突如何从现象推进到判断](#2.2 端口冲突如何从现象推进到判断)
[三、Cairn 的黑板协作：事实、线索与共享状态](#三、Cairn 的黑板协作：事实、线索与共享状态)
[3.1 从确定目标转向中间路径探索](#3.1 从确定目标转向中间路径探索)
[3.2 事实可共享并不代表结论可靠](#3.2 事实可共享并不代表结论可靠)
[3.3 调度器和执行容器如何分工](#3.3 调度器和执行容器如何分工)
[3.4 比赛成绩、项目评价与学习方法](#3.4 比赛成绩、项目评价与学习方法)
[4.1 先把调度配置和模型连接拆开检查](#4.1 先把调度配置和模型连接拆开检查)
[4.2 在隔离靶场中检查事实到分支的变化](#4.2 在隔离靶场中检查事实到分支的变化)
[4.3 简单题目应当允许快速结束](#4.3 简单题目应当允许快速结束)
[5.1 API 使用与本地部署的条件不同](#5.1 API 使用与本地部署的条件不同)
[5.2 微调和领域数据的作用边界](#5.2 微调和领域数据的作用边界)
[6.1 正则回溯线索与版本条件](#6.1 正则回溯线索与版本条件)
[6.2 用更具挑战性的源码题检验模型边界](#6.2 用更具挑战性的源码题检验模型边界)
[7.1 工具问题和规划问题需要分开处理](#7.1 工具问题和规划问题需要分开处理)
[7.2 四类策略失效在实验中如何对应](#7.2 四类策略失效在实验中如何对应)
[7.3 当前失败如何帮助确定项目的改进方向](#7.3 当前失败如何帮助确定项目的改进方向)
[7.4 停止无效调用、补充提示与检索答案的差别](#7.4 停止无效调用、补充提示与检索答案的差别)
[8.1 从失败分类转到实时决策](#8.1 从失败分类转到实时决策)
[8.2 从量化机制联想到项目成果表达](#8.2 从量化机制联想到项目成果表达)
[8.3 维度一：剩余路径的视野预估](#8.3 维度一：剩余路径的视野预估)
[8.4 维度二：当前分支的历史成功情况](#8.4 维度二：当前分支的历史成功情况)
[8.5 维度三：上下文负载及 GOAD 环境](#8.5 维度三：上下文负载及 GOAD 环境)
[8.6 维度四：当前结论有多强的证据](#8.6 维度四：当前结论有多强的证据)
[九、从 TDI 分数到搜索树：把评估真正接入执行](#九、从 TDI 分数到搜索树：把评估真正接入执行)
[9.1 四个维度怎样组合成任务难度](#9.1 四个维度怎样组合成任务难度)
[9.2 分数如何决定继续利用或返回探索](#9.2 分数如何决定继续利用或返回探索)
[9.3 EGATS 将难度信号接入树搜索](#9.3 EGATS 将难度信号接入树搜索)
[10.1 上下文窗口承担不了全部状态存储](#10.1 上下文窗口承担不了全部状态存储)
[10.2 从过程控制转到结果评估](#10.2 从过程控制转到结果评估)
[11.1 单点任务、长链路靶机与域环境的结果不同](#11.1 单点任务、长链路靶机与域环境的结果不同)
[11.2 GOAD 和新赛季靶场的验证意义](#11.2 GOAD 和新赛季靶场的验证意义)
[11.3 未知协议下，剪枝并不总能带来替代路径](#11.3 未知协议下，剪枝并不总能带来替代路径)
[11.4 创造性、对抗性与长期任务的三道限制](#11.4 创造性、对抗性与长期任务的三道限制)
[十二、Excalibur 的论文与源码核验：名称相同不等于机制已落地](#十二、Excalibur 的论文与源码核验：名称相同不等于机制已落地)
[12.1 先解释项目，再决定改什么](#12.1 先解释项目，再决定改什么)
[12.2 启动文档、项目结构与测试边界](#12.2 启动文档、项目结构与测试边界)
[12.3 在线情报不能只是一个空的 RAG 名称](#12.3 在线情报不能只是一个空的 RAG 名称)
[12.4 指标语义反向会让决策也反向](#12.4 指标语义反向会让决策也反向)
[12.5 能力清单与限制需要同时给出](#12.5 能力清单与限制需要同时给出)
[13.1 比较目标由场景决定](#13.1 比较目标由场景决定)
[13.2 直接客户端是不能省略的对照](#13.2 直接客户端是不能省略的对照)
[十四、IDA MCP 接入：插件安装完成，为何仍然无法连接](#十四、IDA MCP 接入：插件安装完成，为何仍然无法连接)
[14.1 从前端逻辑分析延伸到 EXE 静态分析](#14.1 从前端逻辑分析延伸到 EXE 静态分析)
[14.2 客户端出现条目，不代表 IDA 已经提供服务](#14.2 客户端出现条目，不代表 IDA 已经提供服务)
[14.3 载入样本并启动 GUI 插件，连接仍然失败](#14.3 载入样本并启动 GUI 插件，连接仍然失败)
[14.4 排查从"照文档安装"转向真实依赖与配置](#14.4 排查从“照文档安装”转向真实依赖与配置)
[14.5 旧 GUI 方式与新无头方式混用，改变了排错方向](#14.5 旧 GUI 方式与新无头方式混用，改变了排错方向)
[14.6 样本分析的练习顺序与未验证设想](#14.6 样本分析的练习顺序与未验证设想)
摘要：围绕开源 AI 渗透测试 Agent 的授权靶场实验，梳理黑板协作、PHP 审计停滞及长链路剪枝机制，追踪端口冲突、版本差异、评分实现和 IDA MCP 连接故障。通过逐项区分假设、工具输出、源码改动与实际验证，呈现成功、失败及未验证边界，为框架改造和项目复盘提供依据。
一、复盘范围：把 AI 能力落实到可验证的项目
课程最初关注的是技术实践怎样形成可以被面试讨论的项目经历。讲师认为，简历需要有合理、完整的项目逻辑，AI 相关实践可以成为其中一部分；如果项目描述无法通过初筛，后续面试准备便难以展示。这个判断贯穿后续演示：工具名称只是入口，真正需要积累的是能解释架构、运行过程、失败原因和改动依据的经验。
这次课程并非单独展示某个自动化工具，而是围绕 AI Agent 在安全任务中的使用方式、系统结构和验证方法展开。讨论先从浏览器可访问条件下的前端分析切入：在授权测试范围内，模型可以辅助理解密码校验和请求签名逻辑，也可以借助 MCP 工具检查页面行为、重放流程以及前端函数之间的关系。讲师认为，普通的函数名混淆，例如把可读名称改成十六进制形式，会增加人工阅读成本，却未必足以阻止模型建立代码之间的联系。这里讨论的是课程案例中较直接的逻辑，不意味着所有站点或复杂防护都能自动绕过。
前端分析之后，课程将视角转向 AI Agent 项目本身。重点包括两类开源实现：一类是黑客松参赛队伍的自动解题项目，另一类把事实、线索和探索过程放在共享状态中；随后又引入一篇关于渗透测试 Agent 长链路失败的论文及其代码。讲师此前已经对多个项目做过修改，因此课堂重点不止在于阅读作者的架构描述，还包括启动服务、观察日志、运行靶场、检查模型实际行为，再对照源码判断论文思路是否真实落地。
这条复盘路线有一个明确的判断标准：**项目能启动只说明工程入口可用，不能证明它比直接调用模型更有效。**后续每个案例都会区分输入条件、模型采取的分支、获得的事实、发生的失败以及最终能否到达目标。课程中的攻击行为始终以自建靶场、CTF 题目和隔离实验为背景；涉及外部站点的配置形式只作为目标字段的说明，不构成对未授权对象的测试建议。
二、先让 BreachWeave 运行：容器启动与端口占用
2.1 从源码说明确认启动顺序
复盘首先查看两个项目的源码和配套文档。参赛项目的代码已经被课程讲师多次调整，课堂展示的版本保留着此前修改记录。另一个项目也经过了二次改动。运行之前，先根据仓库说明取得所需容器镜像，再启动项目容器；项目文档已经给出了依赖准备和启动过程，因此第一步不是立即修改模型参数，而是验证项目本身能否按其预期完成初始化。
这项顺序安排的原因很实际：模型配置项可以稍后在 Web 界面中补充，初次运行时应先厘清代码、镜像和服务之间的关系。启动过程会编译一个共享对象，并进一步创建用于实验的 Kali 容器。课堂记录显示该项目会拉起多个容器，因而容器启动阶段的状态信息能够帮助判断程序究竟处于构建、初始化还是服务监听阶段。
图 01 展示 Linux 目录中的 BreachWeave、Cairn 及压缩包，用于确认后续运行的项目资源。
图 02 展示 cairn-server、调度组件及监控容器的运行清单，其中可核对 8000 等端口映射。
第一套参赛框架的仓库为 m-sec-org/BreachWeave。README 区分了面向 CTF 的 main 和面向渗透测试增强的 pentest 分支，说明同一项目在不同任务中并不一定使用相同分支。页面给出的快速启动入口为 bun run install && bun run web：先准备项目依赖，再运行 Web 服务。课堂沿此路径启动，随后才遇到端口占用。
图 03 展示 BreachWeave 仓库的分支用途与启动入口，便于将本地操作与文档对应。
图 04 记录 bun run web 的错误 Failed to start server. Is port 3000 in use?，表明 Web 服务未能按预期占用该端口。
2.2 端口冲突如何从现象推进到判断
容器启动时，服务报告 3000 端口正在使用。单看这条错误并不能说明新容器配置错误，下一步先访问本机的该端口，确认当前占用者提供了什么页面。实际页面属于此前启动的监控可视化工具，用于展示本机 CPU、内存等资源信息。该工具在这次 Agent 实验中暂时没有用途，因此冲突的原因不是 Agent 自身，而是机器上遗留的服务占用了相同端口。
课程中提出两种处理方向：清理暂时不用的旧服务，或调整当前应用的端口映射。演示选择先移除旧服务，减少同时运行的无关组件。**排查重点是先识别占用端口的进程，再决定清理还是改端口；不能把端口冲突直接等同于容器启动失败。**这也让后续检查更聚焦：如果冲突已解除而服务仍不可访问，再去验证监听地址和进程状态。
服务启动完成后，页面可以把一次解题过程中的 memory 和 idea 记录下来，并按时间顺序复现 Agent 的历史路径。课堂查看的示例视频展示了这种回放能力：题目结束后，既可以看到过程记录，也可以回头检查模型如何从已有信息走到最终结果。它的意义是让复盘对象从最终 flag 扩展到中间的探索轨迹；若只保存结果，就无法辨别某个结论来自有效验证、偶然猜中，还是长时间尝试后的偶然成功。
图 05 展示了记录历史步骤的页面，用于回看解题过程而不只查看最终结果。
课堂随后尝试访问本地服务。程序显示连接成功，但实际打开页面时仍不可达；当时对监听地址是否为 127.0.0.1 的猜测不足以解释现象，因为页面仍然无法访问。课程没有继续围绕地址假设反复排查，而是按当时的经验重新启动服务，再次访问后验证。这个操作属于课堂中针对该环境的经验性处理，不能推导为所有网络故障都应通过重启解决。更可复用的部分是：记录"连接状态显示成功但页面不可达"这一矛盾现象，使用一次受控重启验证服务状态是否恢复，并把结果与端口冲突问题分开记录。
三、Cairn 的黑板协作：事实、线索与共享状态
3.1 从确定目标转向中间路径探索
第二个项目的交互方式更直接：任务输入给出待测试对象和预期结果，中间步骤则由模型根据环境信息自行决定。课程将其概括为"事实、线索与人工提示"三类内容。这里的事实是已通过观察确认的状态，例如靶场中某个端口开放；线索则是基于事实提出、仍需验证的下一步方向；人工提示是操作者补充的关注点或已授权的测试条件。
这些信息被写入共享的黑板状态。以 3306 端口为例，端口开放本身先作为事实记录；Agent 可以据此提出与数据库服务相关的后续检查线索，但线索只有在进一步观察后才能变成事实。负责探索的 Agent 根据已有线索行动，拿到新的观测后再写回黑板，于是后来启动的 Agent 也能读取前面的结果。黑板不是把推测自动变成证据的地方；它的价值在于让事实和待验证方向可见、可追踪。
图 06 展示了 Agent 将观测写入共享状态并从中派生下一步探索方向的说明。
图 07 是课堂分析项目逻辑时使用的资料页面，作为架构阅读的起点。
共享状态的推理循环可以用一个与网络无关的例子说明：如果调查中已经确认门窗关闭，这是一条事实；接下来可以提出走访、查看监控或核对手机等线索。只有执行检查并得到对应结果后，线索才会被更新成事实，再据此决定下一轮探索。这个类比对应项目中的工作方式：Agent 先读取黑板，判断当前信息是否足以结束任务；若不足，就认领一条待探索线索，执行后把新事实写回。整个过程会反复进行，直到目标达成或现有路径无法继续。
图 08 展示了起点和目标已知、途中节点仍需发现与验证的探索模型。
图 09 表示模型在已知信息基础上展开候选方向，并通过验证排除无效分支。
图 10 展示了从当前状态继续发现新节点的探索过程。
Agent 之间共享状态，部分缓解了单个上下文窗口可能遗忘前序内容的问题。新来的执行者不必依赖另一个执行者口头转述，而可以读取已累积的事实和线索。人类提示也可以写入黑板，例如在已确认 HTTP 服务后提示优先关注文件上传；该提示提供方向，但不应与验证结果混为一谈。
图 11 用黑板结构展示事实、线索和目标之间的关系。
图 12 展示新 Agent 进入任务后从公共状态中读取上下文的设计。
图 13 展示了围绕端口、服务和文件上传关注点形成的任务状态。
在靶场任务中，目标可以是获取 flag；在更宽泛的授权测试任务中，目标也可能是确认某项安全问题或验证权限边界。两种场景的起点和终点都应明确，Agent 在中间阶段根据已知事实探索。课程借此强调，目标约束能减少漫无目的的遍历，但它并不会消除误判：如果最初目标写得含糊，或模型把错误推测当作已确认事实，搜索就可能偏离原本的测试目的。
3.2 事实可共享并不代表结论可靠
黑板结构带来记忆方面的优势，但仍依赖写入内容的质量。若模型能力不足，可能把错误判断写成事实；接下来的 Agent 又会把这个错误事实用于推理，生成新的线索，再产出更多错误判断。错误由此逐层传递，最终让整个分支越走越远。课程提到，项目作者在使用小模型时也观察到事实和线索不稳定的问题。因此，这一架构并不能替代验证步骤，更不能仅凭状态条目数量判断任务进展。
讲师对这种风险的说明强调了两个层面：首先是每条记录需要保留可核验的依据；其次是 Agent 的能力仍受底层模型影响。模型越弱，错误事实的概率和后续偏差可能越难控制。**共享黑板解决的是信息可访问性，不自动解决信息真实性。**这也是本次实验后来反复出现的经验：即使 Agent 走了很长路径，只要关键状态没有验证，系统仍不能把它作为成功结果。
图 14 展示了共享状态在多个 Agent 之间连续流转的工作循环。
课程接着比较了两类项目中相通的部分：任务都需要保留过程状态，也都依赖先观察、再判断、再执行的循环。黑板项目把循环拆成三种阶段：Bootstrap 先尝试直接解决；Reason 阅读当前图谱并决定下一步；Explore 根据线索执行探索并产生新事实。这里的阶段划分不是单纯为了增加组件，而是为了让简单任务不必一开始就承担完整推理流程，同时让复杂任务在首次尝试失败后有组织地继续。
图 15 展示了初始求解、状态判断和后续探索分别承担的职责。
图 16 展示任务循环如何随着新事实增加节点和分支。
若初始尝试能够直接完成简单题目，系统便可以结束而不必先生成大量线索。只有 Bootstrap 无法解决时，当前搜集的信息才进入黑板，再由 Reason 生成后续方向，随后 Explore 负责验证并回写结果。这个先简单后复杂的顺序是为了避免把容易的问题人为变复杂。课程把它视为比"所有任务一律先构建长推理链"更贴近实际任务差异的一种设计选择。
图 17 展示了流程图界面中一条由初始节点通向目标节点的简单路径。
图 18 记录了直接求解未完成后，流程进入线索生成与后续验证的过程。
图 19 展示探索状态扩展为多个候选分支的界面记录。
3.3 调度器和执行容器如何分工
项目的调度示意中，dispatch 负责分发任务，服务端维护图状态的一致性，执行容器承担具体工作。课堂展示的容器以 Kali 为基础，并安装 Claude Code 与 Codex 客户端。此处的结构关注点在于"谁决定下一步""谁保存共享状态""谁执行命令"，而非把每个功能都写成固定角色。一个模型实例可以根据当前黑板内容决定接下来做信息收集还是验证某条线索；执行环境则提供工具入口。
图 20 展示共享状态服务、任务分发和工作容器之间的分层关系。
图 21 对比了预先分配职责的子 Agent 与根据共享任务状态领取工作的 Worker。
讲师特别关注了项目中"任务来自图，而不是来自角色定义"的主张。传统设计可以预先设置负责收集、利用或横向探索的多个子进程；项目作者则认为，这种分工方式可能把模型限制在预先设定的边界内。另一种做法是让 Worker 先读取完整图谱，再根据事实选择下一步行动。讲师认同减少不必要的中间隔离可能保留更多上下文，同时也指出这是一种架构取舍，并非所有任务都已经证明固定分工没有价值。
图 22 展示了蚁群概念中以路径信息影响后续探索的示意。
蚁群概念用蚂蚁沿路径留下信息来解释协作：个体之间不直接交换全部内容，而是利用路径痕迹影响后续选择。讲师对这一比喻持保留态度，认为它更像是对模型行为的概念化描述，未必需要额外引入一套蚁群术语才能解释 Agent 如何选择分支。相比概念名称，他更看重具体状态如何记录、哪个执行者能读取这些状态，以及系统怎样避免无效线索不断繁殖。
图 23 展示对预定义角色分工及其信息传递代价的讨论。
传统多 Agent 结构通常来自人类组织经验：由不同角色分别承担不同职责。但人类分工往往是因为注意力、记忆和个人上下文有限；课程讨论的模型可以读取更大的共享状态，因此角色边界不一定要照搬人工团队的划分。分工在某些情况下可以让任务更清楚，不过也可能带来信息过滤、上下文残缺和角色边界固化等代价。数据经过转述后，接收方未必知道哪些事实重要，这种信息损耗会影响下一步判断。
图 24 展示任务在多个角色之间传递时可能出现的信息孤岛问题。
图 25 展示执行者根据共享图谱决定后续工作的架构想法。
这类设计的另一个论据是系统简单性。增加一层工具、知识库或技能定义可能帮助特定任务，但也增加状态传递和维护成本。项目作者把"少依赖预先编排"作为核心主张，认为模型本身已经掌握部分安全知识，不必将每项常见技能都写成专门的 skills。讲师将其概括为"少即是多"的架构取向，同时保留了实证要求：只有测试表明简单结构在目标场景中有效，这种简化才有意义。
图 26 展示项目强调简化编排、减少预先定义层级的设计方向。
图 27 展示过多设计层可能引入额外脆弱点的对比说明。
3.4 比赛成绩、项目评价与学习方法
课堂展示了多个参赛队伍的解题数量和比赛统计。资料列出绿盟科技 ai 小分队完成 49/54，天翼安全 Sniper 完成 51/54，京东 ToBeNumberOne 完成 48/54，中电信北京网络安全信息中心完成 52/54；个人参赛者 Bytex 完成 54/54，即全部题目。题目完成数与总排名并不相同：这张阶段资料写的是排名第四，讲师补充后来总排名变为第三，并认为不必纠缠队伍间的争议，学习架构和实现更有价值。
赛事资料给出 610 支战队、1345 名选手，成本 7692 元，token 消耗 10.9 亿，持续五天，代码约一万行，使用 Claude Opus + GPT。作者自述借助 Claude Code 与 Codex 完成代码，在比赛当天凌晨四点才第一次联调，未提前针对靶场训练和测试；还认为开局配置失误影响了排名。讲师保留了这些过程细节，但它们是作者对那次比赛的说明，既不是推荐省去测试，也不能作为任何新目标上的成功保证。
图 28 展示赛事题目完成数量及相关成本、用时数据的汇总。
另一张资料页概括了作者对系统来源的看法：只给模型一个目标、一块共享黑板和一组工具，剩余路径让模型自行探索。讲师将这种主张与学习方法相联系：基础理解扎实之后，学习新框架会更顺畅；如果只记住很多技巧名称，却没有掌握判断逻辑，遇到新问题时很难举一反三。这并不是否定技巧本身，而是强调基础能力与工具编排之间的关系。
图 29 展示作者对系统设计与学习方法的归纳，强调围绕目标共享信息并保留自主探索空间。
讲师的学习建议可以概括为：把基础概念学扎实，再扩展到更多工具和方法。前期看起来慢一些，后续理解新方案时反而更容易建立联系；堆积操作步骤却缺少判断依据，往往会在换一个问题后失去方向。
在结束第一轮项目阅读后，课堂准备转到实际运行。重启之前先处理环境遗留状态：系统中存在此前启动的服务，且旧进程仍可能占用资源。演示中检查并清理了相关进程设置，之后再次运行，以免把历史残留误认成当前代码的问题。
图 30 展示本地环境中的运行文件和容器相关状态。
图 31 展示执行 systemctl stop cups、systemctl disable cups 后的终端输出。
停止服务后，禁用自启动的输出仍提示 cups.socket 可以激活相关服务。也就是说，停止当前进程与阻止以后再次被拉起并不是同一件事：命令完成后还应读完警告，不能只看见一次停止成功就忽略关联单元。截图没有证明 cups 就是此前占用 3000 的监控进程，因此两段环境处理应分开理解，不能拼接成未经验证的单一因果链。
四、第二个项目的运行与任务配置
4.1 先把调度配置和模型连接拆开检查
在进入第二个 Agent 的实验之前，课程再次启动容器项目，并查看启动配置。这个项目由 Docker 运行，容器启动前还需要准备名为 dispatch 的任务分发层。配置内容包括最多创建多少个子 Agent，以及每个工作容器使用哪个模型和接口。演示时项目通常生成两个 Agent，可以分别接入不同模型进行横向比较，也可以让两个 Agent 使用同一个模型；这些取舍都应按项目文档中说明的接口参数配置。
课堂再次执行启动命令时，界面初始没有给出清晰的错误日志，因此无法直接判断应用是否已完成初始化。课程转而查看运行状态和服务监听情况：应用最终监听在本地 8000 端口；如果大模型的连接参数写错，预期会在服务页面或日志中出现具体错误，排查时应回到报错所指出的模型字段，而不是盲目修改其他配置。完整启动步骤以先获取仓库内容、再执行项目给出的命令为前提。
图 32 展示进入 Cairn/ 后执行 ls -al 的结果，可见 dispatch_mock.yaml、dispatch.yaml、docker-compose.yaml 和 Dockerfile。
对应 README 先通过 cp dispatch.example.yaml dispatch.yaml 建立实际配置，再以 docker pull ghcr.io/astral-sh/uv:python3.13-trixie 准备镜像，容器运行入口为 docker compose up --build。这里先生成配置，再启动编排。调度器依赖服务端健康检查；服务端尚未就绪时，不能仅凭调度进程还没出现就断定配置错误。
文档同时标明服务端使用 8000，容器挂载 dispatch.yaml，数据持久化位置为 ./datas/cairn/。这些字段把模型配置、调度行为和状态保存分成了不同检查点。若采用手动方式，两个入口分别为 uv run --project cairn cairn serve 和 uv run --project cairn cairn dispatch --config dispatch.yaml。它们承担不同职责，单独运行服务端不等于已经启动任务分发；反过来，调度层配置正确也不能替代对 Web 监听状态的检查。
图 33 展示仓库提供的运行命令以及执行前需要准备项目文件的条件。
应用启动后，页面要求为任务填写名称、目标对象和期望结果。名称可以用于区分多次实验；目标字段限定测试入口；Goal 则说明希望任务达到什么结果。课程强调，这个目标描述不能含糊：它可以给出需要检查的站点范围、授权账号条件或重点关注的漏洞类型，但这些信息属于实验任务输入，应当来自明确授权的环境。人工 Hint 可以补充关注方向，也可以留空；若存在合法测试账号，可将其作为任务条件提供，避免模型在没有凭据时错误推断。
图 34 展示任务名称、目标入口和结果描述所对应的界面字段。
4.2 在隔离靶场中检查事实到分支的变化
第一个验证使用课程中的内网靶场 Tr0ll，实验地址为 192.168.68.188，目标是在该授权环境中取得 flag。初始 Bootstrap 没有直接完成，任务转入事实记录与分支探索。查看这次已完成任务的历史，可以分别检查输入、第一次写入的事实、替代方向和最后验证，不必只依赖页面顶部的完成状态。
图 35 展示 Tr0ll 的实验起点和任务图，目标地址写在初始事实中。
第一批事实记录了 21/22/80 端口开放，FTP 可匿名登录，且从抓包文件和隐藏目录中找到了进一步线索。随后确认 SSH 账号 overflow 能够登录，当前身份为 uid=1002(overflow)，系统为 Linux 3.13.0-32-generic i686。这些事实使任务从外部服务检查推进到本地权限分析，后续分支不再只是围绕端口进行猜测。
同一条记录还指出 /lib/log/cleaner.py 属主是 root，权限却允许普通用户写入，另有 /var/tmp/cleaner.py.swp。讲师认为，若 root 定时任务执行该可写文件，就存在值得验证的权限关系。日志显示模型已对这个文件做过修改，试图验证提权，但当时没有确认修改是否由 root 执行，也没有确认已获 root 或读到目标内容。写入成功与权限提升成功必须分开记录。
图 36 展示端口、FTP、SSH 身份、内核及 cleaner.py 权限等事实，也明确保留尚未确认 root 的状态。
这条预期路线没有得到成功证明后，模型生成替代本地提权方向。依据已确认的 Ubuntu 14.04 i686 与 3.13.0-32 内核，它继续检查 sudo、SUID、cron 和内核相关条件。关键转折是把"原计划未触发"作为改变方向的理由，再利用已知系统版本缩小范围，而没有把未验证的文件修改直接算作完成。
图 37 展示替代提权线索及其所依据的系统版本，记录中明确把 cleaner.py 路线未生效作为转向条件。
替代分支最终匹配到 CVE-2015-1328，即截图中记录的 OverlayFS 本地提权问题。Agent 将 exploit-db 37292.c 放入实验机 /tmp，在目标环境用 gcc 编译并运行，日志随后确认 uid=0(root)、gid=0(root)，并读取 /root/proof.txt。记录还列出清理临时文件 /tmp/ofs、/tmp/ofs.c、/tmp/ofs-lib*，以及未发现 /etc/ld.so.preload。这些是该靶场里实际记下的结果，不是通用利用条件清单。
图 38 展示替代分支的 root 身份和 /root/proof.txt 读取结果，以及临时文件清理记录。
讲师说明，这次完成过程没有追加人工提示，也没有人工代替执行。其评价并不是"模型按预先规划一路成功"，而是原定思路没有直接完成后，系统还能利用新的事实找到别的路线。初始失败、替代方向、权限证明和目标文件读取构成四个不同环节，缺少任何一个，都不应写成同样完整的成功案例。
这个成功案例并不意味着模型最初就选对了路径。正相反，实验价值在于可以分辨哪条线索有效、哪次尝试失败、模型又如何根据新发现改变计划。讲师指出，黑板中会出现不少并不成功的线索；评估 Agent 时应留意这些失败是否能够被识别和收束，而不能只截取最终成功页面。页面提供 Replay 历史回放功能，可查看各阶段的探索结果，复盘每条线索从提出到验证的变化。
4.3 简单题目应当允许快速结束
接下来课程把目标换成一个难度很低的靶场站点，只要求在预设范围内确认一个 SQL 注入问题。任务创建时还遇到一个地址表达问题：工作 Agent 位于容器中，127.0.0.1 可能指向工作容器自身，不能直接用它代表 Windows 上的实验服务。演示因此改用实验网络里的 Windows 地址 192.168.68.1。这一步先保证输入指向预期环境，再判断漏洞验证表现，否则访问错对象会与分析能力问题混在一起。
该靶场没有 WAF，也没有复杂正则限制。系统以所给起点和目标进行初次尝试，几秒内就找到了目标，没有进入完整的 fact 和 intent 扩展阶段。实验说明，Bootstrap 的直接路径适合简单任务；如果每次都强制建立复杂的黑板推理，反而会给简单问题增加无谓步骤。目标只要求找到一个问题后停止，也避免把同一练习目录的所有入口都重新测试一遍，浪费本次演示预算。
图 39 展示简单任务直接完成时的流程状态，没有展开长链路分支。
讲师明确提醒，这个案例只证明工具可以在容易的靶场中跑通，不足以证明 Agent 对真实复杂环境有优势。如此理想的任务，即使直接调用模型也可能很快得到结果。因此，在验证一个 Agent 项目时，应当选择能体现其架构差异的目标，既不能只靠最容易的练习题展示成功，也不应把一次结果推广到没有测试过的环境。
项目在课程修改版中还加入了更多使用方向，包括内网靶场实验、自动完成 CTF 题目和源码审计。源码审计的输入可以是打包后的项目文件，或通过项目增加上传能力后提供的文件路径。演示中将代码压缩包放到实验网络中可访问的位置，再让系统围绕该源码开展审计。其判断对象是静态代码及其中可能的漏洞利用点，而不是将源代码分析等同于已经完成对目标系统的测试。
图 40 展示课程修改版增加的任务类型入口。
图 41 展示以实验地址 http://192.168.68.1/gift_plus.zip 提供源码包，并要求围绕其中 gift_plus.php 开展审计的任务输入。
若希望工作流更顺畅，可以在二次开发中加入源码上传功能，让项目收到文件后返回可供 Agent 读取的路径，再把该路径交给审计任务。这样做的改动属于课程讲师提出的扩展思路，课堂没有把它描述成所有原版项目都已具备的功能。审计结果也仍需人工核对源码上下文，不能只根据模型报告认定漏洞已经成立。
五、模型部署与微调：成本、能力和数据边界
5.1 API 使用与本地部署的条件不同
课程接着从模型选择转到部署成本。使用顶尖模型的 API 能够获得较强的推理能力，但持续调用会产生费用；在不适合把内部数据发送到外部服务的环境中，本地部署可能更符合数据隔离要求。另一方面，本地运行并不等于没有成本：模型文件本身占用较多存储空间，较大的模型需要更高性能的显卡，还涉及机房、散热、电力和运维资源。课程展示的模型页面显示模型文件规模很大，讲师借此提醒在讨论显卡之前，先确认磁盘容量是否能够容纳目标模型。
图 42 展示课程讨论模型获取和资源选择时查看的平台页面。
图 43 展示同一平台上可供比较的模型条目。
图 44 展示 Kimi-K3 的多个 .safetensors 分片，其中单个文件约 16.57--16.99 GB，说明下载准备本身就需要足够空间。
图 45 展示 Kimi-K3 模型介绍与文件体量信息；讲师由此继续讨论显卡及基础设施投入。
讲师以大型部署作粗略估算，提到两三千万元级的投入和百万元级的电费，随后又把一次性前期投入与后续每年数百万元的运行成本区分开来。这些是用来说明资源门槛的经验估计，并非现场完成的设备采购测算。其核心判断是，大多数团队即使希望减少外部 API 调用，也未必具备相应的设备、机房和人员条件。模型选择需要把能力、数据敏感性、设备与运维放在一起看，不能只比较 API 单价。
课程又以无法连接外网的内部培训场景说明取舍：数据不能对外提供，却也无法承担顶级大模型的完整部署投入，就只能在可负担范围内选择模型。讲师举出 122B 作为较大本地候选，并解释 B 表示 billion；它比 27B、9B 等更大，但不能仅凭参数量就认定它等同于当时讨论的顶尖模型。内部资料仍是这些模型训练时不了解的内容，这才进一步引出领域数据与微调，而不是把微调当作单纯堆大参数的替代说法。
本地部署能力较强的方案可能需要高端卡、多卡资源以及相应机房环境。更小的模型则可以在较普通的设备上运行，课程举例提到 27B、9B 和 4B 等规格，并谈及不同显卡等级下的运行可行性。这里的对比不是对某一型号显卡能承载某个模型的通用保证；讲师要说明的是，模型越小，部署门槛通常越低，但课程观察到的小模型在复杂任务推理上的表现也更容易受限。
图 46 展示可下载模型的候选列表。
图 47 展示从较大到较小模型规格的对照。
5.2 微调和领域数据的作用边界
课程把本地模型的能力差异与微调联系起来。通用预训练主要依赖公开语料，因而模型未必了解某个组织内部的术语、流程或特定资料。若出于数据边界考虑不能调用外部 API，可以先选择能够在本地运行的模型，再用内部允许使用的数据进行微调，使其更熟悉指定领域。不过，微调是补充模型任务知识和表达方式的办法，不会自动让小模型达到顶尖模型的全部推理能力，也不意味着未经筛选的数据可以直接用于训练。
讨论中提到 ModelScope（魔搭）和 Hugging Face 两类模型、数据集平台。课堂更推荐当时网络条件下较容易访问的平台；另一个平台提供的模型和数据集较全面，但连接体验不一定稳定。模型和数据集页面按任务类型归类，包含医疗对话、法律条文、图像识别、分割和生成等方向。课程以这些类别说明，领域微调需要先确定目标，再选择匹配的数据，而不是只把文件数量堆上去。
图 48 展示按任务和领域浏览数据集的页面入口。
图 49 展示课堂讨论的数据样本格式，用于说明微调数据如何组织。
课堂展示的数据示例采用指令和回答对应的形式，屏幕中提到的数据集约为 372 MB。讲师用这个例子解释，领域数据会以样本形式提供给模型学习；数据规模需要结合任务和训练方式评估，不能仅凭"有数据"就断定微调有效。涉及医疗或法律等类别时，数据集名称也不等于模型已经具备可靠的专业判断能力；课程这里只讨论数据来源和训练形式，没有报告新的测评结果。
六、代码审计实验：识别漏洞线索后仍可能选错路径
6.1 正则回溯线索与版本条件
部署讨论之后，课程回到 gift_plus.php 的源码实验。Agent 先抓住 preg_match('/Merry.*Christmas/is', $greeting) 的正则回溯方向，认为超长输入可能使回溯超过 pcre.backtrack_limit，从而改变匹配返回值。它还把这个判断与 !areyouok($greeting)、strpos() 的后续条件联系起来。这个阶段建立了一个具体假设，但还没有证据证明目标已经进入输出 flag 的分支。
日志里的"本地验证有效"对应模型使用的 PHP 8.4 / PCRE2 10.46；实际目标却是 Windows phpStudy 环境中的 PHP 7.3.4 / PCRE 10.32，配置显示 pcre.jit=1、pcre.backtrack_limit=1000000。**两组环境不同，模型自己的本地输出不能代替目标站点的验证结果。**失败之后应先对照版本、配置及实际返回值，不能因为局部实验符合预期，就把靶场任务标记成完成。
图 50 展示模型从源码分析中识别出正则回溯方向的过程。
初步判断出现后，Agent 转向 PHP 类型处理，提出把 greeting 作为数组提交。它的推理是：若 preg_match() 面对数组返回 false，而 strpos() 返回 null，则后者与 false 的严格比较可能让某些条件成立。这个推理只检查了部分表达式，还没有覆盖最外层的控制条件。于是新的线索被写入图中，等待后续请求验证，不能直接作为已确认的绕过结果。
图 51 展示围绕 greeting 数组输入生成的类型处理线索，此时该路径仍是待验证假设。
随后模型分别测试数组、带索引数组和嵌套数组等输入。请求返回 HTTP 200，但响应体为 0 字节，没有输出 flag；普通字符串 Merry Christmas 则返回 Do you know PHP?。状态码正常只说明请求得到 HTTP 响应，空正文既不是进入目标分支，也不是成功取得内容。这些观察要求模型回到实际控制流，而不能只凭函数对数组参数的单点行为继续推断。
图 52 展示模型检查数组等输入条件并重新阅读源码的过程。
重新读代码后，模型确认 is_array() 会先行拦截：数组输入在外层就使流程短路，因此内部有关 preg_match() 和 strpos() 的推断到不了预期位置。数组绕过失败的直接原因是前置判断让后续条件不可达，不能归因于请求没有发送成功。 模型将这一测试保存在 i002_array_bypass_result.txt，并认为应回到正则回溯方向。
下一轮又检查源码包和备份文件。日志指出包内只有 gift_plus.php，对 .swp、.swo、~、.bak 等路径的访问未得到可下载的原始备份。服务器使用 nginx + php-cgi，且 cgi.fix_pathinfo=1；部分附加后缀会被拆分为 PATH_INFO 再交给原 PHP 脚本，因而看似"备份文件有响应"，实际可能仍是脚本执行输出。日志通过不同路径的返回内容核对这一点，而不是把每次 HTTP 200 都当作文件存在。
其中 gift_plus.php.abc 返回 Do you know .swp file?，并不能证明取到了备份源码；nonexist.php.abc 返回 No input file specified.，又提供了区分映射行为的参照。进一步发现源码包之外的 gift.php，其 HTML 注释包含原题作者的利用说明，这是另一个信息来源，但仍不能自动证明当前目标版本可以复现该结果。到这里，模型增加了事实条目，也排除了一些路线，却仍没有完成 flag 条件。
图 53 展示模型继续复核源码，但还没有解释版本差异的页面状态。
图 54 展示提示模型检查 PHP 版本变化与源码行为之间关系的输入。
讲师提出的修正方式是提示检查 PHP 版本变化对源码行为的影响。其经验判断是，旧环境里预期的回溯返回行为在当前 PHP 7.3.4 上已经不同，口头解释涉及返回 1，并认为换到 PHP 5.6 更接近原题条件。这个意见保留了"版本可能改变结果"的排查方向，但演示没有真的切换版本并展示完整对照。因此，目前确认的是 Agent 已发现正则方向、数组方案被前置校验排除、备份检查没有取得预期文件；讲师关于旧版与新版的即时解释，仍不能替代同输入、同配置下的运行验证。
这一段说明，代码审计和动态验证之间需要来回对照。静态分析可以提出可能存在的漏洞，运行结果则验证该假设在当前版本和输入条件下是否成立。当输出与预期不符时，不能只重试请求或不断改写参数；需要检查环境版本、外围校验和执行路径是否与模型的假设一致。发现漏洞名称不等于完成漏洞验证，命中一个方向也不等于任务已经成功。
6.2 用更具挑战性的源码题检验模型边界
课程随后回到一道专门用于测试 AI 推理能力的 PHP 题目。输出 flag 的函数定义处于条件分支内，表面条件涉及输入的 SHA-256 值与预存摘要比较。模型因此把注意力集中在寻找能够满足哈希比较的明文密码上，持续围绕哈希值尝试，却没有意识到题目的重点不是破解密码，而是判断控制流和底层处理之间是否存在绕过条件。
截图中的文件位于 D:\phpstudy_pro\WWW\peihua.php。输入分别经过 trim($_REQUEST['password'] ?? '') 和 trim($_REQUEST['name'] ?? 'viewsource') 处理；默认函数 viewsource() 调用 show_source(__FILE__) 显示源码。随后是涉及 strcmp()、hash('sha256', $password) 和固定摘要的条件，内部定义 readflag()，末尾再执行 $name()。这些位置把输入处理、条件判断、函数定义和动态调用连在一起，题目应从这条执行关系分析，不能只看见 SHA-256 就默认必须破解摘要。
图 55 展示密码哈希条件、readflag() 的条件定义及 $name() 调用之间的关系。
课堂此时又回看了前一个 gift_plus 任务的日志。模型已经提出正则回溯方向，但实际没有进入预期分支；数组方案也因 is_array() 的前置判断失败。讲师估计前一个实验花费约两元，新题则仍待验证。
图 56 展示 HTTP 200、空正文、普通字符串返回值和 is_array() 短路结论，并记录测试结果文件。
为了让后续测试更可控，课程把 PHP 源码作为文件提供，并在本机实验网络中建立任务入口。若 Agent 无法稳定读取动态解析的 PHP 页面，可将代码另存为纯文本供其审阅。任务条件明确要求依据源码分析并在靶场内完成题目，同时将目标设定为取得 flag；这样做减少了模型因页面解析差异而无法看到代码的可能，但不会直接告诉它绕过的具体方式。
图 57 展示重新创建任务并指向实验源码文件的配置。
课程还检查了所用模型 Agent 的使用页面。课堂提及当时的 DeepSeek 服务入口和版本体验，并以此前的 WordPress 源码分析作为对照：给出源码和相关利用脚本后，模型能够较准确地对比代码路径。讲师据此认为模型能力相较此前有所进步，但这个观察依赖具体任务和模型版本，不能直接推出所有复杂源码题都能独立解决。
图 58 展示用于运行代码阅读任务的模型 Agent 页面。
图 59 展示课堂随后引用的论文解读资料入口。
另一方面，当前 PHP 题的调用过程仍沿着哈希尝试和错误分支推进，讲师预判额度耗尽之前可能都无法到达目标。这不是因为工具不可用，而是任务策略没有及时从不成立的假设中退出。长时间调用、输出很多内容和持续生成线索都不是进度指标；是否新增了可靠证据、是否淘汰了错误路径，才是更有用的检查点。
七、从具体停滞转向论文中的失效分类
7.1 工具问题和规划问题需要分开处理
PHP 实验仍在运行时，课程转向一篇讨论真实渗透测试 Agent 的论文解读。讲师先指出一个经常出现的落差：项目介绍会强调自动化，但实际把代码下载到本地运行后，可能在信息收集环节反复循环，也可能在稍微复杂的任务中遗忘已获得的凭据。对这类问题，仅仅继续增加工具数量并不能解释和修复全部失败。
课程材料把失败分成两大类。Type A 是能力或工具层面的缺口，例如需要使用某个工具但环境中没有安装，或者模型知道应该调用工具，却没有正确传入参数。Type B 则涉及规划和状态管理，即使工具齐备、模型也掌握相关知识，仍然无法把多步行动串成有效路径。前者更接近执行条件不完善，后者更接近决策过程失控。先确定失败属于哪一类，才能决定下一步是补工具、修参数，还是调整状态与分支管理。
图 60 展示课程引用的文章开头，关注工具演示与复杂任务表现之间的差异。
图 61 展示工具能力缺口和规划状态缺陷的分类，以及材料中的统计口径。
课堂引用的资料中，Type A 占总失败的 42%。例如模型已经推断存在 SQL 注入，也决定调用 sqlmap，但工具缺失或参数不正确，验证就无法继续。前面展示的项目通过 Kali 容器提供工具环境，已经缓解了其中一部分问题。讲师据此认为，工具层通常比较容易通过工程改造改善；但这不等于只要装好 Kali，所有工具使用错误就会消失，具体调用仍需核对实际日志。
论文解读把 Type B 列为总失败的 58%，并强调其在长链路环境中更突出：资料图中 GOAD 等场景有高达 79% 的失败归因于此。这里采用配图列出的统计，讲师对比例的口头概括则强调其主导地位。比例属于该材料的测试条件，更值得追踪的是规划和状态问题在任务中具体怎样发生。
此时现场实验恰好出现了对应现象：模型围绕 PHP 题中的 SHA-256 值继续尝试破解，并提出使用 rockyou.txt 一类字典。它也尝试在根路径下直接寻找 flag，但未发现题目需要的文件。模型后来意识到可以考虑绕过条件，这个方向更接近题意，却仍没有转向需要深入阅读底层源码的关键路径。工具可以运行，调用也在持续，结果却没有更接近目标，说明瓶颈已经越过工具配置层。
图 62 记录模型提出字典破解方向的日志，与论文所讨论的策略停滞形成对照。
图 63 展示模型检查根路径并重新讨论绕过条件，但尚未完成题目。
【小白通俗注解】工具调用成功，只能证明一次动作执行了。例如命令返回了扫描结果，或者脚本读到了某段代码。任务规划成功则还要求系统判断这些输出是否有用，知道何时继续、何时换路。前一种成功不会自动带来后一种成功。
7.2 四类策略失效在实验中如何对应
长链路靶场需要把多个阶段接起来。课程用账号、服务器访问、凭据和后续权限验证的关系说明：后一步往往必须使用前一步获得的信息。如果中间状态丢失，某个阶段即使局部成功，也可能无法成为下一阶段的输入。论文解读因此把 Type B 再拆成四类，课堂逐项与正在运行的任务对照，而没有把它们简单概括为"模型不够聪明"。
图 64 展示规划和状态问题在多步任务中的影响，并列出其主要表现。
第一类是上下文遗忘 。模型在任务早期发现账号或密码，但执行到后面的阶段时，相关信息已经被压缩、移出上下文或没有被正确保留。结果不是信息从未获得，而是系统在需要使用时无法可靠取回。资料表中这一类占 18%，用"最后阶段忘记先前获得的密码"说明其破坏性。课程关心的并非模型是否还能复述早期文字，而是任务所需的关键资产能否持续供后续步骤使用。
图 65 展示上下文遗忘等四种问题的发生比例及说明。
第二类是过早承诺 ，材料中的英文为 Premature commitment，表中比例为 16%。这里的含义不是操作者过早作出业务承诺，而是 Agent 过早认定某条技术路径可行，持续在同一方向投入，即使已经积累了很多失败证据，也不愿意回头检查其他可能性。课程中的哈希破解就是这个例子的现场映射：最初假设"必须找出明文"之后，模型开始沿着字典方向追加尝试，没有及时重新评估题目是否允许从控制流或底层语义寻找突破。
图 66 记录了模型持续处理既定分支的过程，用于对照过早承诺问题。
第三类是探索与利用失衡 ，材料中写作 Exploration-exploitation imbalance，表中比例为 12%。一种表现是反复做端口扫描和信息收集，却不把已有线索推进到验证阶段；另一种表现则是执着于一个利用方向，缺少必要的补充探索。讲师将其与前面项目的设计相对照：即使优秀实现，也可能发现很多线索，却没有完成有效推进。失衡发生在收集与验证之间，不能仅用收集信息的数量判断进展。
图 67 展示持续收集却不验证、以及链路中间状态断裂的两种问题。
图 68 展示课程回看先前 Agent 流程时用于讨论任务状态和终止条件的架构图。
第四类是多步利用链失败 ，资料表中同样为 12%。单个阶段可能已经完成，但不同阶段之间的状态不能正确衔接，导致整个链路断裂。它与上下文遗忘存在关联，却不完全相同：遗忘强调信息丢失，多步链失败还包括任务状态没有正确传递、局部成果未被下一阶段使用等现象。课堂据此强调，长链路任务的评价不能只统计局部工具的成功率，而要检查从起点到目标的完整证据链。
四种问题需要各自保留，因为对应的修正方向不同。遗忘要求关注关键状态如何存取；过早承诺要求关注退出无效路径的机制；探索与利用失衡要求检查系统是否在收集和验证之间切换；多步链失败则要求把阶段之间的依赖关系串起来。若把这些都合并成"增加更强模型"，就无法解释为何同样的模型在简单任务里表现很好，在复杂任务中却越来越不稳定。
7.3 当前失败如何帮助确定项目的改进方向
课堂重新查看 PHP 任务时，黑板中已经出现两条主要方向：一条继续破解哈希，另一条试图绕过条件。前者在该题设计下并非预期路径，后者虽更接近目标，却要求进入 C 语言底层源码分析。模型没有完成这一步，两个分支因此都未提供可验证的成功结果。日志里的动作很多，不能因此认定已经形成有效的替代思路。
图 69 展示哈希破解与条件绕过两个方向在共享状态中的分支结构。
讲师还提到，使用另一套参赛 Agent 做过同类测试，任务一直运行，消耗约二十元额度后仍没有解出。由此可见，这类问题并非仅属于某一个开源框架，也不能因为项目在赛事中取得好成绩就认为它不会进入死胡同。**比赛成绩和单个复杂题目的独立求解能力需要分开评价。**在项目复盘中，保留失败比只展示成功更能体现对系统边界的理解。
图 70 展示课堂在现场任务失败后重新核对的四类问题。
这一段也引出讲师对项目学习的要求：理解论文分类不等于完成了工程改进。更有价值的问题是，现有项目出现这些现象时，能否识别它、量化它、设计修正并比较前后结果。如果只是重复某个项目的架构名称，面试中遇到没有看过的案例仍可能无法判断；如果能从日志里指出具体的遗忘、反复尝试或分支断裂，就有了可以讨论的实际依据。
讲师高度评价这类顶会论文的研究价值，也谈到其对学术经历的重要性；在课程中，更直接的建议是，即使暂时没有发表论文的能力，仍可以主动阅读，借助其中的失败分类检查日常实验。对安全项目学习而言，阅读成果应落到具体问题上：怎样从本地日志认出相同现象，当前代码缺少哪个机制，又能否围绕它完成可说明的改动。论文提供了分析起点，理解和验证仍需学习者亲自完成。
7.4 停止无效调用、补充提示与检索答案的差别
在当前题目上，讲师决定停止继续消耗余额。模型已经开始搜索根目录中的其他文件，尝试借助 include 等路径获得与题目主旨无关的结果。但该题的成功条件是进入指定代码分支并输出 flag，并不存在一个可任意读取的真实 flag 文件。因此，这些动作即使可能在其他情境中有意义，也不能完成这次实验设定的目标。任务目标必须作为过程检查依据，否则模型可能用"找到另一种做法"的表象掩盖偏离题意。
更强的提示能否帮助模型，需要单独实验。课程提出一种可能的方法：把对应 PHP 7.4 源码放在模型可以读取的位置，明确排除暴力破解，引导分析脚本执行过程和底层函数行为。讲师同时指出，这已经给出重要方向，即使最终成功，也不能视作无提示独立解决。该项补充测试没有在课堂继续完成，现有结果仍然是当前任务停滞。
讲师回忆了此前使用其他模型的经历：已经提供底层源码和分析方向，模型仍未独立解出；后来它在网络上检索到公开题解，才给出了解法。为区分理解与检索，实验曾限制继续搜索，让模型回到源码，结果仍然停滞。最后明确指出三个关键底层函数之后，模型才完成相关分析。这里最有价值的不是最终"解出"二字，而是提示强度逐次增加所揭示的能力边界：原始任务、提供源码、指定分析方向、直接标出关键函数，几种条件之间的难度差别很大。
公开题目还存在题解污染。模型通过题目代码、固定值或函数名检索到既有解法，并不能证明它能处理结构相近但细节改变的新题。讲师提到，修改若干标识、去掉某个函数调用，可能让原有检索线索失效；这类改动的目的在于检验模型是否真正理解底层条件，而非增加未经验证的技术能力。评价模型时必须写清有没有联网检索、提供了多少提示、是否直接指定关键位置。
与此同时，讲师没有因失败而否定模型发展。他转述作者后续重跑公开比赛题目的报告：相隔一段时间后，换用新模型完成同一批题目，成本约五十元、时间约四小时，而先前赛事投入约五天和数千元。作者报告的这一对照让讲师对模型进步保持积极态度，但当前 PHP 题的失败仍需独立解释，不能用另一组题目的成本下降代替这道题的成功验证。
讲师的核心判断是：模型能力正在提高，技术人员仍需保留基础判断能力。能够识别加密类型、代码关键路径和环境差异的人，可以给出更有效的约束，减少模型无目标试探的时间；对工具完全不理解，则容易把错误输出也当成有效进度。
这一判断最终回到学习路径。课程建议先补齐 AI 的基本概念，再阅读黑客松中较优秀项目的 PDF，挑选两到三个开源项目深入理解，在本地部署后做授权靶场实验，并用直接调用客户端的方式重复同一任务。横向比较可以判断框架是否带来额外价值，而不是只依靠界面和"Agent"名称形成印象。讲师还提到先从 learn-claude-code 一类较容易理解的学习项目入手，再研究更复杂的 Agent 设计；关于未正式公开代码的课堂提及，不应成为本次博客另行获取代码的操作要求。
八、任务难度评估：让系统知道何时应该换路
8.1 从失败分类转到实时决策
重新进入论文内容时，课程指出：当时较强的模型仍会出现 Type B 问题，因此仅换模型未必能根治规划失衡。论文所提出的方向，是增加实时任务难度评估，让 Agent 在执行中判断当前分支是否值得继续。讲师先用简单数字相加作类比，说明可以把抽象的困难程度转成能被程序处理的信号；那只是讲解方式，实际论文使用的是随后介绍的四个维度及加权公式，不能把课堂随口举的分数当成真实算法参数。
图 71 展示论文解读对底层模型能力与 Type B 问题关系的判断。
图 72 展示 Agent 缺乏在线难度判断时容易错误分配精力的说明。
人类测试人员面对一个入口时，通常会根据少量验证的反馈形成初步判断：当前道路可能很深，可能只是无效线索，也可能还缺少关键输入。经验不等于每次判断都正确，但能帮助控制投入。相比之下，课堂中的 Agent 不知道当前路径还需要多少步才可能完成，因此无法合理衡量继续投入的代价，最终把上下文和余额都用在同一个分支。论文尝试把这类判断显式化，避免完全依赖模型在提示词里自我提醒。
图 73 展示无法判断路径深浅时，任务资源可能不断消耗在无效分支上的现象。
【小白通俗注解】难度评估不是要求模型准确预测未来每一步，而是给系统一个可比较的信号。某条路反复失败、证据薄弱且上下文负载很高时，继续沿这条路走的价值可能下降；系统需要能把这种变化反映到决策中。
工具层的工程改进与此相互独立。课程材料展示了侦察、Web 漏洞利用、网络利用、凭据相关测试、活动目录和权限验证等工具类别，通过清晰的使用场景与参数定义让模型更容易正确调用。讲师认为，这属于解决 Type A 的必要基础，但真正区别于简单工具包装的部分，是系统对 Type B 的实时判断。若工具已经可用，而同类失败仍然持续出现，就应把排查重点转到任务状态与难度评估。
图 74 展示为模型提供工具使用场景和参数说明的工程层设计。
图 75 展示 Task Difficulty Assessment 的定义和四个可量化维度。
8.2 从量化机制联想到项目成果表达
课程称这一机制为 TDA，即 Task Difficulty Assessment，它试图把抽象的渗透难度拆成程序可读取的指标。讲师特别认可这种"把难度转成可度量信号"的思路，因为它能让系统在运行时作出更一致的调整，而不是只在提示词里写"失败后请换个方向"。如果无法记录失败次数、证据级别和上下文使用状况，就很难解释剪枝为什么在这一刻触发。
在讲解四个维度之前，课程短暂转向项目简历中的量化表达。讲师建议，项目成果不能只罗列漏洞名称，还需要说明验证了多少项问题、不同等级的数量、实际影响范围和数据量等已经得到证据支持的结果。数字的目的在于让读者快速把握成果，而不是为了让项目显得夸张。博客也沿用同一个原则：没有测过的结果不能量化，已失败的尝试应如实记录，模糊表述不能通过编造数字来补足。
这一建议与 Agent 的技术设计相互呼应。难度度量让系统有依据地调整路径，成果度量让复盘者有依据地比较改造前后。两者都需要可靠记录作为基础。讲师还鼓励在表达遇到瓶颈时，用 AI 帮助整理已经真实发生的实验过程，但素材和结果必须来自实际工作，不能把模型生成的故事写成个人经历。
8.3 维度一：剩余路径的视野预估
第一个维度为 Horizon Estimation，记为 H，用于估计距离目标还需要多少步。课程材料指出，模型对绝对步数的预测并不可靠，平均误差可达 4.2 步；不过不同活跃分支之间的相对排序较为准确，资料中给出的 Spearman 相关系数为 0.71。因此，实际使用的是活跃分支之间的归一化排名，而不是把一次预测的步数当成真实路线长度。
图 76 展示视野预估 H 的含义，以及采用相对排名的理由。
讲师用多次估计帮助理解其不确定性，而资料的关键处理是比较活跃分支并归一化。这里需要区分绝对预测与相对排序：系统不必准确说出某条路恰好需要几步，仍可以利用"这一条比另一条更远"的判断分配资源。平均值和排名也不是同一个运算，具体评分应遵循资料给出的相对估计方式。
这一维度对应现场实验里最明显的盲点：Agent 一直尝试破解，却不知道这条路可能离目标非常远。如果系统能在不同候选分支间比较预计剩余深度，就有可能降低对某条长而不确定路径的持续投入。它仍然可能误判，所以 H 不能独立决定成败，需要与后面的证据、历史结果和负载指标一起使用。
8.4 维度二：当前分支的历史成功情况
第二个维度为 Historical Success，记为 S。系统关注当前分支此前成功或失败的记录，并使用 Laplace-smoothed 形式的平滑处理。课程用"连续碰壁应当考虑换路"解释其作用：如果同一分支已经多次失败，继续把它当成最优方向就不合理。这个维度专门回应过早承诺，避免模型只因为最初选择了一个方向，就一直为原假设追加新的尝试。
图 77 展示通过当前分支的历史结果调整继续投入倾向的做法。
在现场 PHP 题里，模型围绕同一个哈希值重复尝试；单次调用可能看起来都有不同参数或不同解释，但从目标层面看，都没有为"当前分支可行"增加有力证据。历史成功指标促使系统把这些失败积累起来，而不是每轮都像第一次尝试一样重新开始。课程将这种反复失败的方向称为 Rabbit Hole，即看起来值得继续、实际却不断消耗资源的路径。
讲师把这一思路与先前项目中的 observe 机制相联系：不同项目都在尝试把模型从无效探索中拉回来，区别在于实现是否明确、依据是什么、触发后如何恢复其他路径。这里只是课程中对设计意图的比较，没有报告这些机制之间的同条件实验排名。有"反思"或"观察"阶段，并不等于已经避免了过早承诺；应检查它是否真正改变了模型后续行为。
8.5 维度三：上下文负载及 GOAD 环境
第三个维度是 Context Load，记为 C，关注当前上下文的使用情况。课程没有直接停留在 token 数字上，而是先介绍用于测试长链路任务的 GOAD 靶场。该环境包含多台服务器、多个域及域之间的关系，大量用户和权限条件使状态管理更复杂。讲师曾手工完成相关练习，耗时约两到三周，并借助作者给出的思路克服中间困难。这个经历用于解释为什么该靶场适合观察长链路问题，不能与自动化评测结果直接等同。
图 78 展示将上下文使用程度纳入任务评估的设计。
图 79 展示课堂查阅 GOAD 资料时的页面。
图 80 展示靶场中服务器、用户与域关系之间的连接。
图 81 展示课程用来说明长链路依赖和复杂状态的靶场拓扑。
环境中的五台服务器与多个域相互关联，具体关系保留在拓扑图中。任务需要跨多个节点持续使用前序发现的信息，远比单台 Web 靶机的一次请求验证更依赖状态衔接。最初获得的信息不一定立刻有用，可能到后面某个节点才成为必要输入；上下文压缩、凭据遗失或阶段衔接不良，都可能使先前成果无法继续发挥作用。
资料报告了在独立 GOAD 靶场上的五十次压力测试。其观察是，模型的理想工作区间约在上下文容量的 40% 以内；超过这一负载后，指令遵循准确率显著下降。图中给出的示例从 94% 降至约 60% 负载时的 78%，再到 80% 负载时的 61%。这些数值来自课堂引用的特定测试，不能扩大为每个模型、每种上下文窗口都适用的硬阈值。
图 82 展示材料中对忽略已有信息、幻觉和错误命令等现象的统计。
课程配图进一步列出负载过高时的典型错误：42% 的情况下忽略已有信息，31% 出现幻觉，27% 出现错误命令。讲师据此强调，名义上很大的上下文窗口并不等于每个位置都能被同样可靠地使用。比如以一百万 token 窗口为例，讨论中的四成负载约对应四十万 token；这只是帮助理解比例的换算，不能理解成只要低于这个值就绝对不会遗忘。
C 的意义在于把"任务进行到一半突然不稳定"转成系统可观测的状态。如果只观察最终是否成功，就很难解释模型为何早期表现合理、后期却反复忽略已知条件。监测负载能够触发后续压缩和状态恢复策略，但压缩本身也可能丢失信息，因此必须与外部记忆存储配合；课程将在介绍完评分和搜索机制后再展开这一部分。
图 83 展示上下文负载指标之后，材料转入证据置信度的页面。
8.6 维度四：当前结论有多强的证据
第四个维度为 Evidence Confidence，记为 E，用于区分不同发现离目标还有多大距离。资料按证据强弱给出等级：已经取得 shell、成功 SSH 登录或完成权限验证的证据较强；可复现的漏洞利用或已确认的注入结果次之；只看到软件版本及可能匹配的历史问题，仍属推断；仅发现端口开放而没有进一步证据，则等级更低。这样可以避免把"存在一个可疑入口"当成"已经有可用路径"。
图 84 展示从开放端口、软件推断到真实执行结果的证据置信度层级。
图中列出的示例分值包括 1.0、0.8、0.5 和 0.3。其中最高级对应真实获取访问能力或完成权限验证，较低级只表明有待确认的线索。分值是论文解读中该机制的设定，不能把同一标准直接套用为所有安全报告的漏洞评分。它在这里承担的是规划信号：证据越不充分，系统越应继续补充验证，或降低对当前利用路线的确信程度。
对照前面的 PHP 实验，这一区别非常关键。模型发现正则回溯方向，是一个有价值的分析线索；但实际返回结果没有让题目达到目标，就不能按完成状态计分。模型尝试查找备份文件，若没有发现文件，也不能把"常见情况下可能存在"写成事实。证据等级要求系统对已经观察到的结果负责，不能让语言上的确定性替代实验中的确定性。
九、从 TDI 分数到搜索树：把评估真正接入执行
9.1 四个维度怎样组合成任务难度
四项指标各自描述当前分支的一个侧面，材料将它们组合为任务难度指数 TDI。图中给出的公式为：
TDI = w_H × Ĥ + w_E × (1 − E) + w_C × C + w_S × (1 − S)
其中 Ĥ 是归一化后的视野估计，E 表示证据置信度，C 表示上下文负载，S 表示历史成功情况。所有权重相加为一。这个公式在方向上有明确约束：剩余路径越远，难度倾向越高；证据越可靠，难度项越低；上下文负载越大，状态风险越高；历史成功情况越差，继续沿该分支前进的阻力越大。因此材料使用 1 − E 和 1 − S，不能把成功率或证据强度直接按"越高越难"的方式相加。
图 85 展示任务难度指数的组成方式及每项变量的方向。
讲师用较直观的方式解释这一关系：如果前方路径很长、手头证据不足、上下文已经拥挤，而且此前尝试连续失败，那么系统应降低对当前分支的乐观预期。反过来，如果任务路径较短、验证结果可靠、负载较低且已有成功记录，就不应把同一分支当成高难度。公式的用途是把这些变化合成一个可供程序读取的数值，而不是用数学形式掩盖缺少证据的问题。
材料列出经过网格搜索调参后的权重：w_H = 0.3、w_E = 0.3、w_C = 0.2、w_S = 0.2。这些参数属于论文解读所展示的实验设置，课堂没有在当前本地任务上重新搜索参数。讲师欣赏它简洁、直观的表达方式，认为复杂问题可以拆成可解释的组成项；同时，这种清晰性使源码审阅更容易，因为后续可以逐项检查代码是否保持了论文中指标的含义。
图 86 展示了各项权重及 TDI 分值随证据、历史和负载变化的解释。
【小白通俗注解】把多个因素加权，就像将几张检查结果合成一个总分。每项先统一方向：困难或风险越明显，总分越高。若某项语义反了，例如把成功率提高也算作困难增加，得到的总分就可能让系统做出相反选择。
9.2 分数如何决定继续利用或返回探索
仅计算 TDI 还不够，系统需要把分数转成后续行为。课堂配图给出三段区间：TDI > 0.6 时转向探索，优先补充信息；TDI < 0.3 时更倾向利用，继续对已有高价值路径进行验证；介于 0.3 和 0.6 之间时，交给模型结合当前上下文选择。这里的边界代表材料中使用的策略，不应脱离任务环境宣布为所有 Agent 的固定最佳阈值。
图 87 展示高难度时返回探索、低难度时继续利用及中间区间交由模型判断的规则。
课程把两种方向分别关联到广度与深度的搜索偏好：当当前路径过难，系统应回到较宽的范围寻找其他信息；当证据已经较充分，则可围绕当前路径深入验证。这不是要求 Agent 在两种模式之间机械地定时切换，而是根据分值变化决定下一步。相较单纯在提示词里要求"不要死磕"，显式阈值让转向行为有了可追踪的触发条件。
这一部分与前面的失败案例形成直接对照。PHP 题里的反复哈希尝试没有提供有效证据，如果把失败历史和证据等级都纳入分值，当前分支的继续投入价值应当下降。课程并没有现场证明新机制已经解决同一道题，而是用它说明一种值得实施并测试的工程方向。理论上的修正路径和已经验证的改造效果必须区分，不能因机制看起来合理就预先宣布任务会成功。
9.3 EGATS 将难度信号接入树搜索
论文解读将搜索框架称为 EGATS。它在模型之外维护搜索树，并将 TDA 的信号纳入节点选择。课堂材料指出，这与只在 Prompt 中写下一句"接下来想做什么"不同：后者把所有路径依赖留在文本里，前者用显式结构记录分支和状态，使搜索过程不完全依赖模型不断自述的记忆。
图 88 展示难度评估结果被用于驱动后续路径选择的说明。
图 89 展示将蒙特卡洛树搜索思想引入渗透任务的架构解释。
配图介绍了基于 MCTS 的搜索思路以及调整后的 UCB 选择公式。课堂没有展开完整算法推导，但明确讨论了三个组成方向。第一部分关注当前路径的期望回报，成功时奖励、失败时扣减，再将分数沿相关路径回传；第二部分鼓励对尚未尝试的分支进行探索，避免只重复已走过的路；第三部分引入 TDI 惩罚，使难度过高的节点即使看起来有潜力，也不会无限优先。
图 90 展示搜索评分中用于平衡已有收益、未知路径和任务难度的三项因素。
在难度惩罚项中，配图出现系数 λ = 0.5，并将它与当前节点的 TDI 相联系。其作用不是证明某条路绝对无解，而是改变继续投入该路的优先级。如果某个节点已经多次表现为非常困难，算法还会进行剪枝。材料中的明确规则是某节点失败超过三次，且 TDI 仍大于 0.8 时，将该分支裁掉。次数条件与难度条件需要同时成立，不能简化成"第三次失败立即剪枝"，也不能只因一次高分就放弃分支。
图 91 展示高 TDI 的重复出现如何触发分支剪枝。
图 92 展示在解释搜索评分时再次引用的任务难度权重。
【小白通俗注解】剪枝可以理解为给当前这条分路设置停止条件：反复失败且难度信号持续很高，就暂时不再沿它继续消耗。剪枝本身不是找到答案，而是为其他路径保留预算；若任务本来只有这一条路，剪错也可能导致失败。
讲师在这一部分特别强调，真正的改造不应止于"新增一个难度字段"。如果分数算出来却没有参与节点排序、模式切换和停止条件，模型后续行为可能完全不变。能够在日志中看到分数变化、触发转向以及被放弃的分支，才说明指标进入了执行闭环。这个判断随后成为源码核验的重要依据：项目文件里出现 TDA 或 TDI 名称，并不能自动证明论文机制已经完整实现。
十、外置记忆：在压缩上下文时保留关键资产
10.1 上下文窗口承担不了全部状态存储
为了降低上下文遗忘的影响，材料继续介绍记忆子系统。它通过独立于模型的 State Store（状态存储库）保存可信状态，在需要时取回相关内容。课程用"上下文不能当数据库"说明原因：窗口会随着长任务不断增加内容，也会压缩、裁剪历史；若把重要账号、已验证路径和当前会话信息都埋在历史文字里，后续任务就可能失去前面成果。
图 93 展示通过外部存储维持可信状态，缓解长链路中信息遗忘的设计。
课程配图列出五类核心状态资产：主机信息，如 IP 和系统指纹；服务信息，如端口、配置；凭据，如密码、Ticket 和哈希；会话信息，如反弹 Shell 和代理通道；漏洞信息，如 CVE 状态。其共同点是会被后续步骤反复使用，或者直接决定任务当前处于什么状态，因此不应仅依赖模型临时记忆。已知主机、已获凭据和当前会话分别描述不同侧面，保存时也不能只用一段笼统的"取得进展"替代。
图 94 展示主机、服务、凭据、会话和漏洞五类需要持续保留的信息。
新信息出现时，系统将其存入状态库，随后只把当前任务需要的核心状态放入 Prompt。这样做的目的不是把全部历史每次重新塞回窗口，而是让当前分支所需的信息能够被检索。TDA 监测负载接近材料中的四成区间时，开始进行渐进式压缩；接近七成负载时，进一步裁掉冗长历史或陈旧分支信息。关键资产已经另存，因此压缩不应把凭据和已证实状态一并抹掉。
这套方案也有实现前提：状态库必须写入正确结果，检索必须能够返回当前需要的内容。它与黑板模式面临的真实性问题相通，不能因为信息已经落到数据库就认为结论可靠。课程关注的是可信状态的持久化，而不是无差别保存每一句模型输出。外部存储解决"以后还能找到"的问题，事实验证解决"找到的内容是否可信"的问题，两者需要一起落实。
10.2 从过程控制转到结果评估
难度评估、树搜索和记忆系统介绍完毕后，课程查看论文报告的评测结果。资料称研究投入约 2760 美元 API 额度，进行了超过一万次评估，覆盖多个模型和不同思考预算。接下来的数字均属于论文解读展示的评测；讲师自己的修改版测试范围较小，不能与这组基准成绩合并。
图 95 展示评估所使用的费用、模型及多次测试规模。
图 96 展示材料对模型任务完成率和比较对象的介绍。
十一、评测表现与仍未解决的边界
11.1 单点任务、长链路靶机与域环境的结果不同
材料中的 XBOW 基准包含 104 个 Web 安全任务，展示了使用 Claude Opus 4.5 时最高约 91% 的任务完成率，平均约 89%。比较对象的最佳基线约为 61%，资料将相对提升记为 49%。这组数字描述的是特定基准和模型组合的结果，不意味着任意现实 Web 环境都有九成成功率。课程口述还推测换更强模型可能继续提升，但没有给出实测数据，因此不能把预测的百分比加入结果表。
另一个基准包括 13 台 HTB 或 VulnHub 靶机，材料报告完成 12 台，对照结果为 9 台。GOAD 的五台主机环境中，资料报告控制了其中 4 台，旧系统最多约为 2 台。相对提升的数字需要结合不同分母理解：单点 Web 任务是任务完成率，单机靶场是完成机器数，GOAD 则涉及跨域、多阶段状态。三者不能直接混成一个"Agent 成功率"。
图 97 展示 XBOW、单机靶场和 GOAD 环境中的结果及各自比较对象。
课程对 HTB 一类长链路靶场表现尤为关注，因为这类任务可能需要十到二十步连续操作，能更明显地暴露规划和状态问题。相比非常简单的演示站点，长任务能检验系统是否保存凭据、能否退出无效分支、是否把某一步成果用于后续验证。因此讲师认为，在评价框架架构价值时，这类任务比一眼就能完成的漏洞练习更有区分度。
图 98 展示模型得到数据库哈希后可能持续破解而无法推进的案例。
材料提到 HTB Falafel 案例：传统基线通过 Web 路径拿到哈希后，持续调用 Hashcat 尝试破解，记录中约有四十七次尝试，最终上下文负载恶化。加入难度评估后，连续失败使当前分支 TDI 升高，搜索机制剪掉该方向，Agent 被要求重新收集信息，再通过 RAG 资料查询发现与 PHP 类型转换相关的另一条路径。课堂将其与刚刚观察到的哈希死磕进行对照，强调转向行为才是案例的重点。
图 99 展示材料中基于难度信号放弃哈希破解分支的结果说明。
新分支涉及 PHP 类型混淆、MD5 零开头值和文件名截断等靶场条件，资料用它们展示路线切换后的推进。案例的关键是，新结果没有来自继续扩大字典，而是来自承认原分支缺乏进展，再回到信息收集与证据检索。也就是说，系统改变了正在解决的子问题，而不仅是在同一破解任务上增加预算。
11.2 GOAD 和新赛季靶场的验证意义
在 GOAD 环境中，材料报告完成五台主机中的四台，涉及横向移动和凭据串联等长链路条件。课程将其视为对记忆和任务管理的更严格检验，因为跨多个节点时，前序信息常常是下一步的必要条件。材料还给出约 28.50 美元的成本记录，讲师借此说明与人工耗时相比的效率差异；这并非人民币价格，也不能据此断言所有同类靶场都只需同等费用。
图 100 展示针对多主机、域环境任务的验证背景。
图 101 展示资料报告的四台主机结果和对应费用信息。
课程随后讨论"是否只是做过旧题"的质疑。如果模型训练资料中已包含公开靶场答案，旧题高分可能混有检索和记忆效应。为检验对新任务的适应性，材料介绍了在答案尚未公开的新赛季靶场中的测试。图中说明这次测试发生于 2025 年 HTB 第八赛季，包含十三台新发布靶机；这种设置比直接重复公开题解更有助于观察当时模型对未知任务的处理。
图 102 展示使用新发布任务减少公开题解影响的测试背景。
资料报告，该系统完成十三台中的十台，完成所有 Easy 和 Medium 靶机，并在 8036 名活跃参赛者中进入前一百。课程将这一结果视为值得关注的进展，但也没有把它扩展为模型已经覆盖全部专家能力。相反，接下来的失败例子恰好说明，即使多数任务已经成功，剩下的特殊条件仍可能成为不可绕过的边界。
图 103 展示资料报告的新任务完成结果，并引出私有协议任务的失败。
11.3 未知协议下，剪枝并不总能带来替代路径
材料中的一台高难度靶机要求对未公开的自定义 Protobuf 协议开展逆向和测试。Agent 在资料库中没有找到足够的协议说明，模型此前的已知模式也无法直接提供答案。TDA 检测到难度持续升高，按照机制裁掉相关分支；然而当前目标没有可替代的道路，因此剪枝并没有帮助任务成功，反而暴露了系统对未知协议缺少进一步创造性分析的问题。
图 104 展示在缺少已知资料且没有其他路径时，难度评估仍无法保证完成任务的例子。
讲师用这个案例说明，自动化系统尚不能被称为已达到通用人工智能水平。它能够把学过的模式迁移到许多具体任务，但遇到真正缺乏资料和既有经验的对象时，可能无法形成新方案。这里是课堂对当前案例的能力评价，不应进一步推导成"所有模型永远不能处理未知事物"的结论。更准确的复盘是：在该私有协议任务上，已有知识、检索与剪枝组合没有补足缺失的分析能力。
剪枝机制的优点与代价因此都需要保留。它可以节省重复失败路径上的消耗，也可能删除唯一值得继续分析的方向；当前材料没有给出这个私有协议失败的完整修复。成功转向与无法转向是同一机制的两面：前者说明资源分配有所改善，后者说明搜索控制不能凭空创造缺失的协议知识或分析能力。
11.4 创造性、对抗性与长期任务的三道限制
课程最后把论文反思归为三个方向。第一是创造力边界：有些任务无法只靠匹配现有漏洞模式解决，需要对未见过的实现进行更深入分析。私有协议案例说明，缺少文档和先验知识时，系统可能无路可走。讲师认为这与仅在公开漏洞训练范围内表现良好不同，不能因若干高分评测就宣布专家经验已失去价值。
图 105 展示材料对创造性推理、对抗环境和长期行动等限制的概括。
第二是对抗性环境。普通靶场常常为了教学保留可见入口，而真实防御环境可能存在 WAF、安全产品、诱饵或防守者的主动干扰。课程在此前简单实验中明确指出没有 WAF，因此不能把同样结果直接带到存在真实防护的网络。配图还谈到蜜罐和 Canary Token 可能污染状态库；如果 Agent 无法区分诱导信息与真实事实，外置记忆也可能持续保存错误状态。
图 106 展示模型在未见过的对象和主动防御环境中可能遇到的问题。
第三是时间尺度。人类在长期任务中可以持续维护目标认知，而模型的上下文和记忆系统是否能够跨更长周期稳定保留状态，仍然是问题。课程以数月尺度作比喻，强调长期计划与一段有限窗口内的连续推理不同。当前资料并没有证明框架已经解决这种长期行为管理，因此不能将短时靶场结果写成长期对抗能力。
图 107 展示资料对长期任务状态维持的反思。
图 108 再次展示成绩表，提醒结果与条件需要一起理解。
讲师最终的态度并不矛盾：一方面承认系统在评测中的进展，另一方面保留它在未知协议、真实防御和长时间任务中的不足。成功数据说明方案值得研究，失败案例则决定使用边界。不因失败否定全部进步，也不因高分抹掉未解决条件，才是技术复盘需要保留的完整判断。
十二、Excalibur 的论文与源码核验：名称相同不等于机制已落地
12.1 先解释项目，再决定改什么
评测讨论之后，课程回到实际代码。讲师介绍自己的习惯：修改项目之前，先让 AI 解释项目如何组织、每个模块负责什么，再以分析为依据决定改动位置。这样可以把架构材料中的名词与源码中真实的数据流对上，避免只看到目录里出现某个模块名，就误以为它已经具备论文宣称的全部功能。
这次阅读发现，手头代码并没有完整实现前述 TDA、TDI 和剪枝逻辑。讲师因此要求 AI 补充相关机制，再准备做后续测试。不过，之后查看的仓库页面也提示，该项目并非原论文作者直接维护，而是收集论文、整理代码的版本。因此"代码与论文不一致"的判断，应当限定在课堂实际获取的仓库或版本，不能进一步归咎为原作者从未实现论文。代码来源和版本是复现条件的一部分，不核对它们，就可能把复刻版缺陷误当成论文结论。
图 109 展示讲师用于核对和修改实现的本地文件位置。
图 110 展示用于查看代码来源与项目结构的仓库页面。
图 111 展示项目介绍，其中包含并非原作者直接维护的来源说明。
课程继续找到论文页面和 PDF，核对引用来源。论文标题为 What Makes a Good LLM Agent for Real-world Penetration Testing?，作者及单位信息保留在 PDF 首页。随后需要比较的是，论文描述的任务难度评估、记忆和搜索机制，是否真的进入当前仓库的数据流与执行过程；论文来源可信，并不意味着手头每个衍生实现都自动完整。
图 112 展示论文原始页面及可下载文档入口。
图 113 展示论文 PDF 首页，用于核对课程引用材料的来源。
讲师认为中文解读材料对理解问题分类和算法意图很有帮助，阅读门槛也较低；原始论文则提供更完整的设计和实验依据。二者的用途不同。解读不能替代源码验证，源码目录也不能替代论文论证。课程实际采用了"先读解读、再看论文、再核对项目"的路径，而不是仅凭其中一个材料作出全部判断。
12.2 启动文档、项目结构与测试边界
仓库文档列出了项目结构，包括记忆、接口、整体管理、提示词和工具等模块。讲师认为目录相对规整，便于二次开发时定位功能。运行入口分为 make install、make config 和 make connect，依次处理安装、配置和连接。启动以后再提供 target 和目标描述，必要时加入人工提示，才进入具体靶场任务。理解这些入口之间的关系，有助于把依赖准备失败与任务执行失败分开。
图 114 展示项目文档中的运行入口和模块组织。
本地测试方面，讲师已经拉取所需镜像，并在一个相对简单的靶场中运行过该项目。最困难的 HTB 场景没有在课堂前完成实测，既有付费环境因素，也有准备时间上的限制。讲师明确说当前探索还不充分，不能据论文成绩认定修改版已经复现所有结果。这一点应完整保留，因为它直接约束后面每项"改进"能够声称到什么程度。
图 115 展示已经准备的运行资源，但不代表全部困难基准均已测试。
图 116 展示课程讲师对项目做过调整后的目录状态。
随后课堂展示了讲师借助 AI 编写的快速启动材料，包括如何构建、如何启动、如何交互以及模型环境变量的配置位置。修改版加入了课堂所需的部分功能，也记录了已知限制。.env 在这里承担模型接口和其他外部服务参数的配置作用；它说明项目需要实际连接条件，不能把界面演示当成完全离线可用的通用方案。
图 117 展示课程补充的快速启动文档及基本准备顺序。
图 118 展示项目通过环境变量配置连接参数的文件位置。
12.3 在线情报不能只是一个空的 RAG 名称
修改的第一个重点是补充实时情报能力。读码时发现 KnowledgeBase 类只是空壳：没有被实例化，没有实际数据源，也没有进入执行过程的调用路径。系统虽然有知识库名称，实际仍主要依赖模型训练时获得的漏洞知识；对训练截止之后的新信息，这个空模块无法补位。讲师因此在 mcp_servers/cve_intel/ 增加 MCP 服务，让模型具备主动查日期、查漏洞资料和查利用仓库的入口。
修改文档列出七个工具，各自的数据源不同。get_current_date 读取系统时钟，先为查询提供当前日期；search_recent_cves 使用 NVD API 2.0 按关键词查找 CVE；get_cve_details 从同一来源取得单条 CVE 详情；search_exploitdb 对接本地 searchsploit；search_github_advisories 查询 GitHub Advisory；get_poc_repos 和 search_poc_repos 对接 PoC-in-GitHub，分别按 CVE 或产品线索查找仓库。区分这些职责很必要：知道当前日期、找到漏洞条目和找到可供审阅的代码，是不同的信息步骤。
图 119 展示课程为情报查询加入的配置和使用条件。
一开始，模型遇到漏洞线索就查询，造成额外等待和调用成本。讲师不满意这种机械行为，改为让模型自行判断：已有把握时可以不查，不确定时再检索；连续失败两次后，系统只是提示可以查询 cve-intel，并不强制调用。**"失败两次后出现查询提示"与"失败两次后必须联网"是不同策略。**这一调整保留了查询能力，也避免给每个节点都绑定相同开销。
文档以 JumpServer 2.28.6 为例：扫描得到软件与版本后，_extract_findings 生成 ACTION 节点，搜索过程选中该节点，模型再决定是否查资料。这是修改说明中的流程示例，不是课堂现场完整复现的利用记录。后面还举出在已获用户 Shell、常规提权失败后查询较新 Linux 漏洞的场景，说明查询可以发生在任务中途，不必只放在任务开始时。两个例子都旨在解释信息何时进入决策，不能借文档中的示意结果扩大本地测试范围。
图 120 展示修改版文档中对在线检索触发时机的调整。
这里的复盘逻辑是先识别数据源缺失，再补接口，观察过度查询，最后收窄触发条件。不同步骤不能压成"增加 MCP 后解决了问题"。接口接通只能说明有了查询可能，结果还需要核对是否与当前软件、版本和环境有关。即使是在线信息，也不应自动成为黑板中的确定事实；它仍需通过当前实验的实际输出确认。
12.4 指标语义反向会让决策也反向
第二个重点是视野估计 H 的实现。读码发现，_estimate_horizon 使用 depth / max_depth 计算数值，衡量的是节点已经走到的深度；论文需要的却是距离目标的剩余步骤。**已走深度不能代替剩余距离。**一条已经深入、可能只差最后一步的路径，会因为深度较大被算成高 H，再被 TDI 当作困难分支降权，甚至剪掉。问题不只是文案把"高"和"低"写反，而是输入评分的量本身含义错误。
修改首先给 AttackNode 增加 horizon_estimate 与 horizon_dirty，分别保存估计结果和是否需要更新的状态。随后由 controller.py 在每轮 EGATS 开始时调用 _batch_estimate_horizon，收集标记为待更新的活跃叶子，通过一次模型调用批量估计各分支的剩余步数，再把结果缓存在节点上。tda.py 的 _get_horizon 读取这些缓存，按活跃分支做 min-max 归一化；出现新 findings 时再把对应状态标记为需要重估。这样既改变了估计对象，也明确了估计在什么时刻更新。
图 121 展示课堂修改版对 H 指标方向的检查与修正。
修改文档用三个活跃分支解释归一化：A 已确认 Nacos 2.0.3 相关线索并有 PoC，估计剩两步；B 刚开始枚举 SMB，估计剩八步；C 已有用户 Shell，估计只剩一步。以当前最小值一、最大值八作归一化，A 为 (2−1)/(8−1)≈0.14，B 为 1.00，C 为 0.00。因此，在这个例子中，C 的剩余距离最短，H 项应降低它的难度贡献，而不是因为它已经走得最深就把它判为最难。
这组数字只是文档中解释代码行为的例子，没有展示三条真实路径的同条件跑分。它的核验价值在于能检查计算方向：输入从"已走深度"改成"预计剩余步数"后，归一化结果才与任务语义一致。相应修改涉及 excalibur/planner/models.py、excalibur/planner/tda.py 和 excalibur/core/controller.py，分别对应字段、计算与执行时机，不能只改其中一个显示值就算完成。
图 122 展示修复视野估计后，文档中对应的工作流程。
之后还检查了证据置信度能否随着真实结果动态升级，以及凭据出现后能否改变此前的剪枝结论。修改文档给出一个场景：某条路径因没有凭据失败并被剪掉，之后其他节点获得新的哈希；_extract_credentials 识别凭据，propagate_credentials 将其传入相关分支，使原本因缺少输入而失败的路线重新具备探索条件。**剪枝基于当时条件，新的关键证据到来后，应允许重新评估。**这与毫无变化地重试旧失败不同，复活的依据是任务状态确实发生了改变。
该场景属于文档演示，不代表课堂现场完成了对应横向过程。修改范围涉及 pruning.py 的匹配逻辑、pivot.py 与 egats.py 的接口，以及 controller.py 中的凭据检测和循环接线。接下来又修正 _extract_findings 只提取 IP、端口而丢失软件名和版本的问题，将软件与版本转成可供搜索选择的 ACTION 节点。否则日志里即使出现 Nacos 2.0.3，搜索树也可能只留下开放端口，无法利用更具体的信息继续推理。
讲师描述这轮改造持续了一到两周，内容还涉及状态记录与数据库中的保存方式。花费时间说明修改并非只增加一个提示词，但不能代替效果验证；能够确认的仍是文档所列改动和此前有限靶场测试，不能据此宣布所有复杂内网问题均已解决。
图 123 展示修改版对证据验证、凭据处理和状态保留等功能的说明。
12.5 能力清单与限制需要同时给出
修改版文档总结了自主靶场探索、查询新漏洞资料、判断利用结果、发现凭据后继续检查、上下文管理以及时间感知等功能。讲师认为这些功能已经能够使用，但仍不完美：非凭据类新证据，例如新网段或配置文件，能否让旧分支复活仍依赖模型判断；Context Load 以字符数量近似，属于当前实现中的简化；Skill Composition 尚未接入完整执行链。它们与文档标为"做不到"的条件也要区分，后者包括完全未知协议的漏洞发现、WAF 或蜜罐等对抗环境的智能处理、多 Agent 并发，以及离线环境中的新 CVE 查询。
图 124 展示功能可以使用的范围，以及未知协议、防御对抗和离线检索等限制。
图 125 展示项目当前不足与相关运行条件的记录。
这部分给出的经验是：项目说明既要写增加了什么，也要写实际测到什么。当前只在普通靶场进行有限验证，就不能写成已经在复杂内网中全面可用。简历中的二次开发描述同样应聚焦真实改动，例如接入实际数据源、修复评分方向、完善凭据和状态处理；若尚未完成对照实验，效果数字就应留待实际验证，而不能从原论文中直接借用。
十三、三个框架如何做有意义的比较
13.1 比较目标由场景决定
课程随后要求把三个项目都运行起来：前两个参赛框架和论文衍生的修改版。它们都可以接收起点和目标，也都能用于一定范围内的 CTF、源码审计和内网靶场实验，但各自的设计重点并不完全相同。讲师建议按主要用途区分：面向较通用目标探索的方案、强调长链路状态管理的方案，以及更贴近 CTF 解题的方案。这样的划分是课堂提出的试验方向，不是已经测出的绝对性能排名。
图 126 展示本地用于比较的多个 Agent 项目目录。
图 127 展示课程回看前一个框架时所用的仓库入口。
在真实测试环境中，安全产品、权限边界和网络限制可能比靶场复杂得多。讲师因此认为，强调长链路的项目当前更适合先放在多阶段内网靶场里验证，不宜只根据论文名称就假定它能够绕过实际防守。另一方面，以目标驱动的框架更容易接入不同任务，但通用入口也意味着需要进一步检查它在某个专门领域是否足够深入。
图 128 展示围绕起点和目标设定任务的方式。
图 129 展示课程区分长链路靶场使用方向时引用的项目资料。
图 130 展示课程讨论 CTF 场景时回看的另一个项目页面。
对于源码审计，讲师提出还可以选择更专注的 Agent 项目，因为通用框架能接受源码，不等于它已经把大型代码审计做好。其设想是把某个 Agent 的任务限制在审计，让它围绕成千上万行源码持续阅读和分析。讲师曾使用过一个专用项目，但旧环境可能因磁盘不足被删除，现场没有找到，因此没有展示项目名称、执行过程或审计结果。当前比较仍以已经拿到的三个框架为基础。
图 131 展示比较框架前核对的本地文件和环境资源。
13.2 直接客户端是不能省略的对照
讲师此前反复强调，框架要与直接使用同一类模型客户端的方式比较。若一个复杂靶场在框架和客户端中都能完成，单凭完成这一事实还不能证明额外编排有价值；如果框架失败而客户端成功，则更需要检查框架是否引入了信息损耗或错误限制。讲师对"框架成功、客户端未完成"的情形最认可，因为这才比较能体现架构改造带来的差异。
这是一条严格的项目评价原则，不能把它误读成只要结果相同，框架在所有方面就毫无意义。课程关心的是自动化能力的新增价值，因而需要围绕同一任务观察过程与结果，而不是拿不同难度的演示互相比较。实际记录时，至少应保留输入条件、模型选择、人工提示、是否允许检索、结果验证和调用成本；这些都是课程案例中已经出现、且可能改变结论的因素。
更复杂目标更适合用于这种比较。简单 SQL 注入演示在几秒内就完成，无法体现黑板、记忆或剪枝的优势；PHP 底层题则暴露了两类项目都会失败的边界；长链路域环境又更侧重状态衔接。不同任务的差异应当成为对照设计的一部分，不能拿一个成功案例遮盖另一个失败，也不能用单个极难题的失败否定所有任务中的实用性。
讲师的项目建议可以概括为：先把优秀实现读懂并跑通，再围绕明确问题做改动，最后用同条件对照证明改动是否有价值。项目应当能解释模块职责、失败原因和改进依据；只有一个名称、一张界面或一段成功日志，仍不足以构成完整的技术复盘。
十四、IDA MCP 接入：插件安装完成，为何仍然无法连接
14.1 从前端逻辑分析延伸到 EXE 静态分析
课程最后把 AI 辅助分析的对象从前端代码扩展到可执行文件。前端案例关注密码、签名以及请求之间的关系；应急响应中的样本分析则希望了解程序可能连接的地址、使用的管道、创建的进程和其他行为。讲师提出，可以用模型调用 IDA 的分析能力，辅助整理这些信息。这里的目标是理解隔离实验样本，不能把"能够发起分析"直接等同于"已经获得可靠的全部行为结论"。
课堂选择的桥接项目是 mrexodia/ida-pro-mcp。它将 IDA 的部分能力提供给模型客户端，使客户端能够围绕已加载的二进制文件调用分析工具。安装前先查看仓库及其客户端接入文档，确认如何把插件加入 Claude Code。课程此前也使用过 Codex，因而这里是在已有经验基础上重新接入另一客户端，并不是第一次接触 MCP。
图 132 展示用于查找 IDA MCP 仓库及相关说明的检索页面。
图 133 展示项目给出的 Claude Code 安装入口，包括添加插件市场和安装插件的步骤。
接着准备 IDA 环境。讲师在讨论第三方安装材料时，特别强调了来源风险：逆向工具本身也可能被夹带后门，不能因为它用于分析样本就默认工具包可信。演示随后查看本地已有程序，开始核对服务端是否存在，以及客户端究竟连接了哪个实例。
图 134 展示课堂查找 IDA 环境资料时的页面，重点对应工具来源与环境准备这一环节。
图 135 展示演示机器上准备使用的 IDA 文件，后续服务端检查以此本地环境为对象。
14.2 客户端出现条目，不代表 IDA 已经提供服务
安装插件后，客户端的 /mcp 列表新增了 IDA 相关条目，但状态没有变成连接成功。讲师先把客户端与服务端区分开：客户端登记了连接方式，只能说明它知道要访问哪个 MCP；如果 IDA 侧没有启动对应服务，新增条目仍然不能工作。安装入口可见、插件已经登记、服务端正在运行，是三个需要分别确认的状态。
课堂又查看了 Codex 接入说明，并返回仓库寻找服务端启动方式。只重复执行客户端安装无法解决服务端未运行的问题，因此排查方向转为：IDA 插件是否安装到实际使用的实例、是否已经在程序里启动、启动后监听在哪里。
图 136 展示另一客户端的接入文档，用于区分客户端配置与 IDA 侧服务的职责。
图 137 展示围绕服务端安装和逆向分析流程继续查阅资料的过程。
图 138 展示用于核对 IDA 侧插件安装及使用步骤的参考材料。
【小白通俗注解】客户端像是发出分析请求的一端，IDA 服务端则实际提供分析能力。列表中有一个工具名称，只相当于记录了联络入口；能否分析，还取决于另一端是否运行，以及双方使用的连接模式是否一致。
14.3 载入样本并启动 GUI 插件，连接仍然失败
在隔离教学环境里，演示向 IDA 载入 mimikatz.exe，随后准备启用插件。原演示为了避免实验文件被防护程序删除，展示了 Windows 防护项关闭的状态。这是当时样本实验的环境记录；讲师在后续建议中明确要求样本放在虚拟机中，不能把这张设置截图理解为日常使用电脑时关闭防护的建议。
图 139 记录当时实验环境的防护设置，所对应的是样本保留条件。
GUI 模式中，IDA 侧服务需要从 Edit > Plugins > MCP 启动，画面还给出快捷键 Ctrl+Alt+M。点击后才出现服务运行信息，因此"IDA 已打开"仍然不足以证明 MCP 服务已启动。只有看到对应输出，才有依据继续核对客户端访问的地址与模式。
图 140 展示从 Edit > Plugins > MCP 启动服务的入口，以及该插件的快捷键。
服务端启动后，演示重新打开 Claude Code，再查看 MCP 状态。预期是客户端能够发现正在运行的服务；实际结果却是仍然无法连接。随后尝试重新连接，故障没有消失。到这里，最初的"服务未启动"已经不能单独解释全部现象，排查必须继续向依赖、版本和具体连接模式推进。
课堂回查项目环境要求，涉及 Python 3.11 和 IDA 8.3 等版本条件；讲师认为本地 IDA 版本足够新，但口述的具体小版本并不稳定，因此不能仅凭这一步就宣布环境完全满足要求。已安装软件版本较新，也不能代替对插件配置和依赖是否齐全的验证。
图 141 展示连接失败后返回项目文档检查依赖和版本条件的过程。
重连时出现的关键信息是 Failed to reconnect to plugin:ida-pro-mcp:idalib: -32000。报错里的 idalib 为后面区分 GUI 与无头方式提供了线索。与此同时，列表中另一个 Chrome DevTools 工具显示已连接，但那只说明该工具自己的链路可用，不能据此判定 IDA 链路也已正常。
图 142 展示错误 Failed to reconnect to plugin:ida-pro-mcp:idalib: -32000，以及不同 MCP 工具各自的连接状态。
14.4 排查从"照文档安装"转向真实依赖与配置
两次安装步骤本身都能对上文档：先添加插件市场，再安装插件。然而，步骤一致并没有消除运行故障。讲师把失败情况、官方安装方式和实际环境交给 AI 辅助检查，排查内容扩展到 Python、IDA 安装位置、激活状态和所需依赖。这样做的重点是让模型查看具体环境差异，而不是继续复述安装文档。
检查画面涉及 uv 的 PATH、注册表和 Hex-Rays 相关配置，也查找了非标准路径下的安装位置。其中一个明确发现是 uv 尚未安装。这条结果让排查从插件是否登记，进一步转到启动依赖是否齐全，并与后续无头模式崩溃的诊断对应起来。
图 143 展示辅助排查环境依赖和安装位置的过程，其中确认缺少 uv。
讲师结合过去的使用经验，认为 IDA 接入有时比一般 MCP 更容易遇到连接问题；在其个人操作中，Claude Code 对连接成功、连接失败和已暴露函数的展示更直观，而此前使用 Codex 时曾多次遇到打开后无法连接的情况。这是特定环境中的体验比较，不是对两个客户端普遍可靠性的测试结论。它所支持的实用判断是：排错时需要看见具体状态和可用函数，而不应只检查配置文件里有没有工具名称。
演示再次返回 IDA，确认菜单里的 MCP 服务已启用。输出中出现 http://127.0.0.1:13337/config.html，同时记录 mimikatz.exe 实例已经注册。截图确认的端口是 13337，后续口述简称端口时出现偏差，应以程序实际输出为准。地址和注册信息证明 GUI 这一路已经有服务运行，但仍需与客户端当前连接的那一路对应起来。
图 144 展示重新检查插件是否启动的菜单位置。
图 145 展示 127.0.0.1:13337 上的服务信息及 mimikatz.exe 实例注册结果。
14.5 旧 GUI 方式与新无头方式混用，改变了排错方向
辅助排查随后指出，环境中存在之前安装的版本，又加入了新的版本，使用方式发生了混合。讲师过去的流程是先打开 IDA、载入文件，再启动 GUI 插件；这次客户端对应的却是新版 idalib 无头方式。按当时的诊断，新方式可以由客户端按需调用分析引擎，未必依赖已经打开的 GUI 窗口。两种方式没有先分清，导致服务端看似已经运行，客户端却仍在另一条启动路径上失败。
这里同时存在两个问题：一个是新旧连接方式没有对齐 ，另一个是无头方式所需的 uv 缺失。后续 AI 报告补装依赖，并给出继续使用无头模式或改用其他模式的备选方案。这个结果解释了为何仅启动 GUI 服务、重新打开客户端和重连都没有立即奏效。它没有证明所有 IDA MCP 版本都按同一种模式运行，具体判断只针对这次演示所用版本组合。
接入排查推进后，演示向客户端提出静态分析桌面指定 .exe 的请求，要求使用 IDA MCP 检查潜在安全隐患。这里传入的是明确的实验文件，目标是让模型使用已暴露的工具读取和分析该对象。此时关注点才从连接排错转回样本分析：工具入口能否列出、能否选择当前样本，以及后续调用是否真正执行。
图 146 展示客户端接收本地实验文件的分析任务，并准备调用 IDA MCP 的过程。
课堂中多次出现调用前需要确认的交互。讲师认为连续确认会打断长过程，因而提到使用减少交互的启动选项。这一效率评价可以保留，但转录中的参数只留下 dangerous、--D 等不完整说法，无法据此还原一个准确命令。连接问题的修复依据仍是版本、依赖和模式核对，不能把减少确认当作解决连接故障的步骤。
后续能够确认的结果是模型已取得部分工具清单和入口，并开始推进分析，完整静态分析报告尚未展示。讲师还担心 DeepSeek 余额不足会中断任务，因此成本和持续调用再次成为实际限制。此次演示验证到工具接入和分析发起阶段，尚未形成完整样本结论。
14.6 样本分析的练习顺序与未验证设想
讲师坦言自身并不擅长深入逆向，但认为工具桥接能降低开始分析的门槛，使不熟悉手工逆向的人也能先观察程序行为。其建议是选择已知来源的 CS 远控实验样本，在虚拟机中让工具辅助检查 C2 地址和其他行为，再与已有认识核对。练习先从相对熟悉的对象入手，逐步建立对工具输出的判断依据。
面向应急响应，课程又举出挖矿木马、银狐等分析对象，希望把 IDA MCP 用于理解样本。讲师推荐了一篇关于"基于 AI 逆向分析百度网盘全流程"的文章：前半段使用火绒剑进行人工观察，后半段才引入 AI 与 IDA 的静态、动态分析。其评价重点是过程组织清楚，而非一开始就完全自动化。先看人工分析怎样建立依据，再观察 AI 接入后的工作方式，能够更具体地理解工具承担了哪些环节。
随后检查是否能复现时，又发现文章没有提供对应样本。**缺少同一份样本，就无法一对一验证文中的完整过程。**因此，这份材料在课堂中主要用作分析方法参考，而不是已经复现的案例。讲师同时反复强调，样本应放在虚拟机中处理，不应直接在日常主机上操作。这个环境限制也是复盘必须保留的一部分。
课程还提出一个与此前"白加黑"实验相关的设想：借助 IDA 比较不同 EXE，判断能否更换原实验中的白文件。它属于免杀研究背景下的用途设想，课堂没有展示候选文件选择、替换验证或效果数据，当前只能归入尚待验证的想法。
十五、把工具试用转化为可解释的项目经验
课程结尾重新落到学习和项目表达。三个 Agent 不是只供观看的演示，而是需要分别运行、阅读架构、观察日志并比较差异的实践材料。讲师要求利用复习时间重新梳理内容：前端分析、CTF 与内网靶场自动化、源码审计，以及应急响应中的可执行文件分析，分别依赖哪些工具，出现过哪些失败，当前又验证到了哪一步。材料很多，单次看完并不足以消化其中的技术关系。
对于两个参赛框架，课堂更集中地演示了其中一个，但讲师明确不把演示篇幅当作优劣排名。其关注度较高，与完成全部题目等比赛表现有关；这不代表另一个项目不值得研究。比较仍应回到实际运行和任务条件。论文衍生项目同样如此，能够阅读论文和启动镜像只是起点，源码里是否真正实现难度评估、记忆管理和剪枝，还需要逐项检查。
讲师保留的一项学习判断是：优秀开源项目已经给出架构和实现，学习重点可以从"完全从零设计"转向"理解原理、运行验证、定位缺口和完成改造"。对项目的解释深度，应当超过启动命令和成功截图。
简历与面试建议也遵循相同原则。讲师希望真实使用过的 Skills、MCP 和 Agent 项目能够体现在技能与经历中，避免只罗列抓包工具名称。更具体的表述应围绕已经完成的工作：是否通过 MCP 扩展了分析入口，是否读懂黑板机制，是否给知识库接上实际数据源，是否发现并修复了视野估计与分支状态的问题。相关技术名称只有和真实任务、操作及结果连在一起，才足以说明经历。
讲师认为 AI 相关岗位存在值得关注的机会，建议安全学习主动结合这些能力，持续完善技能与项目经历。面试中需要解释清楚：某次失败为何没有继续盲试，哪些改动来自源码核验，什么结果只是文档示例，什么结果已经在自己的靶场中出现。能够说明这些差别，比单独列出一个 Agent 名称更有讨论价值；尚未完成的复杂测试，也不能借用论文数字充当个人成绩。
整个实验最终留下的是一组边界清晰的经验。黑板让信息被后续执行者读取，却仍可能传播错误事实；简单靶场成功说明某些流程可用，却没有覆盖 PHP 底层难题；长链路设计试图减少遗忘与死胡同，但手头实现仍需要补数据源、修评分和处理凭据状态；IDA MCP 暴露了分析入口，也仍受版本、依赖和调用成本制约。将成功、失败与尚未验证的部分放在同一份记录中，才构成这些项目可以继续改进的依据。
交付自检
统计口径：原文按 DOCX 正文可编辑文本计数；成稿按本节之前的 Markdown 正文计数，包含标题、摘要、章节和图注。两者均统计 U+4E00--U+9FFF 范围内的中文字符，不计图片像素内文字，本节不参与成稿字数。
| 检查项目 | 核验结果 |
|---|---|
| 原文中文字符数 | 40,729 |
| 成稿中文字符数 | 33,373 |
| 是否达到原文的 80% | 是；实际为 81.94%，最低要求为 32,584 个中文字符 |
| 原文超过一万中文字符时的最低字数要求 | 已满足；成稿超过一万个中文字符 |
| Markdown 图片引用数量 | 146 |
| 提取图片总数 | 146 |
| 独立图片数量 | 146，按图片文件 SHA-256 区分 |
| 重复图片引用数量 | 0；原文没有重复引用同一图片对象，相近截图仍分别保留 |
| 图片路径缺失数量 | 0 |
| 图片顺序是否与原文一致 | 是；逐项按 word/document.xml 的实际出现顺序核对 |
| 提取图片是否与原附件一致 | 是；146 个图片文件均通过内容校验，未裁剪或重编码 |
| 每张图片是否都有标题说明 | 是；146 次引用后均紧跟独立说明 |
| 是否完整保留讲师观点 | 是；保留架构取舍、失败判断、版本经验、成本评价、学习与面试建议，并区分经验判断和已验证结果 |
| 是否存在未完成章节 | 否；未完成的原始实验均交代已验证阶段与尚缺结果 |
| 是否存在过度压缩段落 | 未发现；关键尝试、失败、调试、修正和结果分别展开 |
| 是否仍存在明显转录腔 | 未发现；已清除课堂口头禅、反问与第一、第二人称授课表达 |
| 是否存在大段原句复用 | 未发现；已重新组织段落并核对连续中文片段，技术标识、命令和错误信息按原意保留 |
| 是否改变知识点顺序 | 否；按项目运行、黑板协作、靶场验证、模型部署、PHP 实验、论文机制、源码改造、框架对比与 IDA MCP 的原顺序展开 |
| 是否增加未出现的事实或实验结果 | 否；文档示例、讲师判断、研究设想与现场验证分别标明 |
| 是否保留授权实验与样本隔离语境 | 是；靶场测试、CTF、源码实验及虚拟机样本分析的条件均予以保留 |