文章总结： 本文复盘了作者参加腾讯云智能渗透挑战赛的经历，重点分析了Agent架构设计中的问题。比赛更贴近真实渗透场景，要求长攻击链连续作战能力。作者采用orchestrator+solver双层架构，但存在状态管理不足、工具协议选择失误（未用MCP导致token浪费）等问题。建议未来需加强Agent的连续作战能力和MCP工具集成。 综合评分： 85 文章分类： 渗透测试,AI安全,实战经验,安全工具,安全运营

记一次腾讯云智能渗透挑战赛复盘

原创

洛天二 洛天二

末影安全

2026年4月19日 01:38 安徽

在小说阅读器读本章

去阅读

1. 比赛背景

本届腾讯云智能渗透挑战赛共设置两个赛场。为了表述方便，下面我统一称为主赛场和“零界”平行分赛场：

• 智能渗透主赛场：聚焦 AI 智能体的自主渗透能力。
• “零界”平行分赛场：聚焦 AI 智能体之间的社交博弈、内生安全与协作能力。

我主要备战的是主赛场。因为是第一次参加这类比赛，前期准备主要参考了上一届腾讯云比赛和一些公开资料。赛前我一直以为题型会更偏向 XBOW benchmark 这种单点能力验证，真正开赛后才发现完全不是一回事。

这次比赛明显更贴近真实渗透场景。它考的已经不是 CTF 里单个 flag 的突破，而是要求 Agent 沿着一条更长的攻击链持续推进。题目里甚至出现了多层网络、域控相关场景，本质上考的是连续作战能力。

现在回头看，我成绩不理想的核心原因其实很简单：一开始方向就偏了。整个系统被我设计成了“单题速解”型选手，却没有长链路攻击和状态管理的能力。

2. 成绩总结

• 主赛场最终排名 50。总共 54 个 flag，我解出 34 个，拿到 2810 分，止步第三赛区。第三赛区题目我只拿了 1 个 flag，这基本就是设计失误了。
• “零界”平行分赛场最终排名 20。这个赛场我几乎没做专门准备，只是临时写了个简单策略，挂了 4 个 Agent 一直跑，算是用极低投入换来了一个还算体面的结果。

3. 设计反思

核心架构：orchestrator + solver 的双层结构

整个 Agent 的结构，本质上是一个简化版的主从系统：

• 主 Agent（orchestrator）：负责获取题目信息、调度子 Agent、提交 flag、验证结果，以及挑战的启动、停止和并发控制。
• 子 Agent（solver）：负责进入具体题目执行渗透。

默认配置下，orchestrator 会同时维护多个 solver，最多并发拉起 3 个。这个设计实现成本低，流程也简单，本质上就是“发现题目 -> 起环境 -> 启动求解 -> 提交结果”。

但它的问题也很明显。主 Agent 更像一个任务分发器，不理解 solver 当前卡在什么地方，也帮不上 solver 解决问题。它能调度，却没有中长期规划能力。什么时候该继续深挖，什么时候该切换攻击手段，这些它基本做不到。

子 Agent 相对复杂一点。它主要使用 read、edit、write 和 bash，其中 bash 负责执行 Python 脚本、安全工具和临时自动化。为了让子 Agent 不只是“跑命令”，我额外加了几层轻量状态沉淀：

• stoploss：可配置的止损条件，用来防止重复失败或长时间无进展。
• fact：对攻击面、凭证、可利用入口和当前攻击链的结构化记录。
• artifacts：bash 执行产生的原始证据，包括扫描结果、命令输出、脚本和中间数据。

单题场景下，这套设计已经够用，至少能避免 Agent “完全失忆”地反复试错。可一旦放到真实渗透场景里，它离连续作战还有很大距离。现在的 fact、artifacts，甚至多 flag 题里的 continuation 思路，本质上都更像运行结果记录，还不是能驱动下一步决策的状态系统。

工具接入：一个明确被打脸的决定

这次我完全没有接入 MCP，而是选择了 skills + bash。原因很现实：之前做 AI 工作流时，我一直觉得 MCP 的 token 开销太高，所以刻意绕开了。

现在回头看，这是最明确的败笔之一。

MCP 固然存在一些问题，但是只用bash问题更大，Agent 需要先读懂技能文档，再自己拼命令、补参数、解析输出，推理预算被大量消耗。更要命的是，我原本以为 bash 会更省 token，结果真实比赛里完全相反。bash 的无效输出、冗长回显和噪声，反而吃掉了更多 token，还持续污染上下文。

就现阶段来说，Agent 的工具协议层，MCP 仍然是唯一合理的选择。

bash 执行隔离：容器化

这是我这次投入精力最多的一块。为了防止模型提示词注入、越权执行，或者误用恶意命令把宿主机搞崩，我把所有 bash 命令都放进了独立的 Docker 容器。每个子 Agent 启动时都会创建独立 workspace，并映射到容器里的固定路径 /workspace。

这样一来，read、edit、write 和 bash 就能在同一份工作区里无缝协同，扫描结果、截图、导出数据、命令输出也都能统一沉淀到 artifacts 里。

从安全性上看，这个方案问题不大，基本隔绝了模型误操作把宿主机搞坏的可能。

4. 成本情况

• 中转站充值 400 元。
• 火山 Coding Plan 充值 200 元。体验比较差，用量虚标很明显，开赛 2 小时就把“5 小时额度”跑完了，后面直接 429，对我零界分赛场的成绩影响很大。

主赛场全程使用 gpt-5.4 xhigh，零界分赛场混用了 glm5、deepseek3.2 和 doubao seed 2 pro。

5. 最后

如果只看结果，这次比赛不算彻底失败，主赛场第50名，分赛场第 20 名。但如果对比我赛前的预期，以及我真正想验证的那套系统能力，这次结果显然谈不上满意。

我的 Agent 设计很大程度上受到了上一届比赛中 chainreactors 团队（tinyctfer）的启发。从工程实现角度看，这确实是一条优雅、简洁、容易落地的路线，我现在依然认可它的价值。

但这次比赛也让我彻底看清一件事，简洁不等于足够。面对真实渗透场景里的多阶段推进、跨节点复用、长攻击链维护和多 flag 连续场景，单纯靠“主控调度 + 子 Agent 跑工具”远远不够。

本次代码大部分由codex编写，底层使用了openclaw同款pi-mono库，后面我应该会整理一下发出来（真的有人想看吗）。

好了，对我来说，比赛已经结束了，接下来就等前 10 名大佬的技术分享了，让我学习一下如何让agent具备连续作战能力。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：末影安全 洛天二 洛天二《记一次腾讯云智能渗透挑战赛复盘》