刚参加了大连理工大学网络安全竞赛，本来以为比赛是传统ctf赛事的，结果就在开始前几天发布规则的时候突然发现有ai赛道，因为之前研究过智能渗透这边的东西，所以我打算尝试一下，毕竟之前在腾讯云智能渗透黑客松上获得了一些经验，但是开发的那几天考试，导致确实时间比较紧，最后效果其实不太好，但也拿到了第九名，本来之前就像写来着，正好这次完事之后一起复盘。
腾讯云智能渗透黑客松经验梳理复盘
之前在腾讯云那时候写框架，做的是多agent系统+ReAct架构，因为那个主要是做渗透测试也就是web方面其实也和本次不太一样，之前的架构如下
┌─────────────┐ │ START │ └──────┬──────┘ ▼ ┌───────────────────────┐ │ Orchestrator │◄───────────────────┐ │ (协调指挥官) │ │ │ 分析任务、调度专家 │ │ └───────────┬───────────┘ │ ▼ │ ┌──────────────────────────────────────────┐ │ │ dispatch_security_experts │ │ │ (安全专家并行调度) │ │ └──────────────────────────────────────────┘ │ │ │ │ │ │ │ ┌─────────┘ │ │ │ └──────────┐ │ ▼ ▼ ▼ ▼ ▼ │ ┌──────────┐ ┌──────────┐ ┌────────┐ ┌──────────┐ ┌──────────┐ │ │ Web │ │ Network │ │ Code │ │ Mobile │ │ Security │ │ │ Security │ │Penetrate │ │Auditor │ │ Security │ │ Ops │ │ └────┬─────┘ └────┬─────┘ └───┬────┘ └────┬─────┘ └────┬─────┘ │ └───────────────┴───────────┴───────────┴────────────┘ │ ▼ │ ┌──────────────────┐ │ │ parallel_join │ │ │ (结果汇聚) │ │ └────────┬─────────┘ │ ▼ │ ┌──────────────────┐ │ │ Reflector │ │ │ (反思Agent) │ │ └────────┬─────────┘ │ ▼ │ ┌────────────────────┐ │ │ should_continue │ │ └──┬───────┬─────┬──┘ │ │ │ │ │ ┌──────┘ │ └──────┐ │ ▼ ▼ ▼ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ finalize │ │ memory │ │ continue │───────────────-──┘ │ (结束) │ │(记忆压缩) │ │ (下一轮) │ └────┬─────┘ └──────────┘ └──────────┘ ▼ ┌──────────┐ │ END │ └──────────┘思路方面
对于web方面来说，我觉得ai的瓶颈是思路，当ai想不到的时候那么它就不会做不出来这道题，有时候漏洞就是一个小小的脑筋急转弯，但是llm就是不会。那么因为ai的创新能力和联想能力低于人类，那么对这个思路问题的解决只有通过庞大的数据量知识库才能覆盖。
对于ai来说直接使用知识库显然不能很好的检索信息，所以我们可以采用rag的方案，要知道rag是进行语义向量匹配的，因此在召回之前需要做一个提示词加强，比如现在模型要找sql注入的方法，让另外一个节点分析是什么类型的sql注入最后将加强的提示词用于rag检索。这是一方面此外要知道如果rag检索的和题目思路不相关的话更会导致llm的思路走偏，那么为了应对rag目前较低的召回率，可以去做多次检索的结果来做一个意图判断，这样llm的思路正确性更有保障也会有鲁棒性。
除了rag来解决这个问题的话，还有通过skills来进行ai的知识扩充，那么如果skills非常多的情况下，llm如何找到正确的方式又成了问题，很容易我们可以想到将skill按功能、题目类型进行分类变成树状结构，进行渐进式披露，那么也可以进行一定程度的扩充，至此思路问题暂时得到了缓解。
上下文方面
由于在渗透过程中，llm总是需要很多工具，我喜欢用Kali-Security-MCP作为渗透工具，因为这个的懒加载机制很讨喜，不会浪费很多token，工具也不会不知道选哪个比较好，即使做了这种优化上下文在claudecode中200k还是非常容易见底，我们在进行安全工作的时候往往会遇到以下问题，假如工作量是100，那么llm在完成80的时候就会上下文爆炸，由于工具的上下文压缩机制，llm会继续进行工作，但是进度回退到30，之后到了80左右上下文又满了，反反复复烧token，但是就是达不到想要的答案，有人可能会问：“不是进行上下文压缩了吗，llm应该通过智能总结知道当前进度啊，为什么会无法推进呢？”
要知道在智能渗透的时候很多细节是必要的，比如接口怎么用，这里的小思路怎么绕，这两个东西连在一起才能完成漏洞等等细节，在渗透中是重要的，一旦缺失这些细节llm就走不动道了，所以它必须从头做相同已经做过的工作来重新记住那些细节，因此就陷入了死循环。
解决这个的办法可以从基座模型和agent架构两方面说，基模也就是增大上下文容量这个我不多说了，目前最大的1M上下文容量我觉得挺足够的了。对于agent架构来说，首先我们可以想到的是多agent系统，但是这样的话我们需要思考究竟这个架构的功能是什么。你是想要并行做题，还是一道题拆分给多个agent来推进来解决上下文问题，本板块说的就是上下文也就是后者的地方。多智能体系统，可以进行知识共享和同步，可是要知道常规开发任务的话用多智能体将各模块划分开发的话确实会很好。
可是在网络安全任务的过程中，多智能体的效果非常不好，因为无法将任务进行合理的划分界限，Agent直接的通信还会消耗很多资源。我能想到最适用的地方也就是路径探索侦查这种任务交给子智能体，但其实这种工作使用mcp反倒是更轻松一些，还不会浪费token。综上所述多智能体的优势只能体现在并发处理多个漏洞上了。
我最终觉得解决上下文方面的方案应该去采用单智能体+文档实时更新，让agent在一段探索之后将有价值的情报和信息全部写入markdown文档中，之后在每次上下文压缩后通过hook注入到对话中，这样单智能体就可以获得之前所有的进度细节接着向前推进。
大连理工大学网络安全竞赛复盘
很创新的规则，全自动化CTF解题
我本次开发的框架架构如下,项目地址为Damon
┌──────────────────────────────────────────────────────────────────┐│ HERMES AGENT ││ ┌────────────────────────────────────────────────────────────┐ ││ │ CTF DAEMON（调度核心） │ ││ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ ││ │ │ Slot 0 │ │ Slot 1 │ │ Slot 2 │ … 最多 N 个槽位 │ ││ │ │ 工作目录 │ │ 工作目录 │ │ 工作目录 │ 各槽位独立 │ ││ │ │ 超时 │ │ 超时 │ │ 超时 │ 重试互不干扰 │ ││ │ └────┬────┘ └────┬────┘ └────┬────┘ │ ││ │ │ │ │ │ ││ │ ▼ ▼ ▼ │ ││ │ ┌─────────────────────────────────────────────────────┐ │ ││ │ │ Kali-Security-MCP（241 个工具） │ │ ││ │ │ nmap · sqlmap · nuclei · hydra · msf · pwnpasi │ │ ││ │ │ gobuster · ffuf · hashcat · john · radare2 … │ │ ││ │ └─────────────────────────────────────────────────────┘ │ ││ └────────────────────────────────────────────────────────────┘ ││ │ ││ ▼ ││ ┌────────────────────────────────────────────────────────────┐ ││ │ GZCTF 平台 │ ││ │ 登录 · 题目获取 · 容器管理 · flag 提交 │ ││ └────────────────────────────────────────────────────────────┘ │└──────────────────────────────────────────────────────────────────┘架构是Hermes Agent + Kali-Security-MCP + Daemon(本项目)
因为hermes是一个通用agent工具因此我主要为Daemon赋予了以下能力
- 保证hermes不做完所有题的话不停止工作
- 强制解题并发量3题，使用放弃和继续做思路防止agent卡在一道题太久(即使超时放弃但也不代表进度清零，是用了上面提到的实时保存进度的方法)
- 对题目工作区进行隔离操作防止文件过多造成混乱
- GZCTF平台适配，为llm提供一系列工具用于与平台交互
最终效果一般般，感觉是deepseek太蠢用不明白mcp导致的，架构其实没什么问题了
致谢名单
- 并发模型参考 LingXi（灵犀）
- GZCTF API 交互模式来自 Misuzu
- 工具后端：Kali-Security-MCP by SeaC-25
- AI 运行时：Hermes Agent by Nous Research
- 平台提供方： GZCTF社区
- 比赛主办方：大连理工大学网络与信息化中心＆学生服务中心，螺丝工作室
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时