投降输一半！！腾讯第三届黑客松智能渗透挑战赛初赛决赛复盘

B1uewhit4
B1uewhit4

SecurityPrivacy

2026年10月31日 00:21
广东

去阅读

大家好，我是B1ue，某实验室安全研究员，主攻AGENT安全方向，对AI for Pentest比较感兴趣，基于业余时间，大概15个小时左右的投入，搞出来了这版本的Sliver，侥幸初赛排名第2，决赛第6。

抽象的是，决赛中Sliver虽然能够快速拿到内网权限，但是持久化能力拉完了，后面基本就没拿分，最后我总结模型输出记录，发现我的Harness居然投降了，这也是标题投降输一半的来源。

当前Sliver他的token消耗量是巨大的，总共花了40多亿的dpskv4.1 flash，消耗量430块，6个多小时自己崩掉了，这与当前架构有关，最少我认为鲁棒性还有token消耗是有很大的优化空间的。

写这篇推文主要是与大家分享一下Sliver架构核心思路，把我对当前的观察，还有怎么形成Sliver的构想来说一下。因为测试有限，在我刚搓出来Sliver的时候，他在跑tsbenmark的时候长题收敛效率依然不尽人意，我对他的表现并不满意，我也不能说Sliver一定是优秀的，可能大家有比我更好的思路，也可以交流。

1 、从Cairn开始谈谈当前主流架构玩法

Cairn 是这一方向很有代表性的工作。它将经典的 Blackboard Architecture 引入自主任务执行，通过 Fact、Intent 和 Hint 等共享状态，让不同 Worker 能够围绕同一份外部记忆推进任务。

这套设计解决了一个很重要的问题：Agent 不必完全依赖自己的上下文记忆，也不需要通过彼此反复聊天同步进展。新的 Worker 只要读取 Blackboard，就能知道已经发现了什么、哪些方向有人尝试、还有哪些问题没有解决。

从这个意义上说，Cairn 为自动化渗透测试以及其他长任务中的多 Agent 状态共享，提供了一个非常有价值的工程实践。

这里需要特别说明：Cairn 本身并不是“一个长期 Lead 指挥所有 Worker”的架构。

它虽然有 Dispatcher，但 Dispatcher 主要负责机械调度和运行时管理。Cairn 通过 Reason 任务生成 Intent，再由 Explore 任务认领 Intent 并执行。技术路线并不完全由一个长期存在的模型 Lead 决定。

我真正想讨论的，是另一类常见的衍生架构：

Lead 观察状态 → Lead 拆分并发布任务 → Worker 执行 → Worker 回写结果 → Lead 再次观察。

这套结构直观、易于理解，也确实能够工作。但它把很大一部分决策质量压在了 Lead 身上。

如果 Lead 一开始判断错了怎么办？

随着执行链路不断拉长，Lead 可能最终会意识到方向有问题，也可能根据新的证据进行纠正。但从第一次错误决策，到它真正承认错误并切换方向，中间究竟要消耗多少轮，没有人能够保证。

我以前让 Agent 处理逆向题时，就遇到过这种情况：Agent 很早便进入了一条红鲱鱼路径，此后不断用新的解释为旧结论辩护，甚至跑了二十多个小时，也没有真正跳出来。

为了对冲这种单点决策风险，常见做法之一，是使用不同模型或多个 Agent 副本并行竞速。它们从不同角度独立推进，用模型和路径之间的差异，降低某一次错误判断带来的影响。

但如果没有足够的模型资源，或者用不起多个 SOTA 模型并行运行，怎么办？

另一种办法是增加纠偏机制，例如加入一个 Auditor，定期观察执行轨迹，在发现重复、停滞或长期低信号时进行提醒。

这种设计有一定效果，但也存在新的风险：如果 Auditor 开始决定技术路线、分配具体任务，它就会逐渐变成另一个 Lead，重新形成中心决策点。

所以 Sliver 希望探索的是另一条路线：

保留共享状态和确定性调度，但把具体技术决策交还给每一个执行者；通过不同生命周期的 Agent、FIFO 轮转和只读 Auditor，分散一次错误决策造成的影响。

2 、Sliver的一些构想

渗透测试的前期，本质上是一个不断扩展信息边界的过程：

搜集信息 → 根据证据选择目标 → 尝试推进 → 获得新的信息 → 再次选择目标。

这个循环并不是一条固定流水线。一次执行产生的结果，可能推翻旧结论，也可能暴露出新的资产、入口或者问题。因此，多个 Agent 能否共享事实、看见彼此的尝试，并避免无意义重复，就非常重要。

Sliver 吸收了 Cairn 的 Blackboard 思路，但针对长任务协作做了一些更有倾向性的设计。

Sliver 将共享状态分成两个相互关联的视图：

• Intel Graph

：保存经过证据支持、可以复用的事实和能力。
* Exploration Graph

：保存当前 Intent、历史尝试、执行结果、交接关系和仍未覆盖的盲区。

这两个图不是两个彼此独立的数据库，而是两种不同的观察视角。

Intel Graph 回答的是：

我们目前知道什么？

Exploration Graph 回答的是：

大家做过什么、正在做什么，以及下一步还有什么值得尝试？

Sliver 目前包含四类协作角色：

• 侦查员；
• 快速突破手，也就是端到端执行者；
• FIFO 队列中的轮转任务执行者；
• 只读 Auditor。

侦查员和端到端执行者都是长期存在的 Session，但关注点不同。

侦查员持续扩展信息边界，将新的发现写入 Intel Graph，同时把覆盖范围、探索结果和下一处盲区写入 Exploration Graph。

端到端执行者则从任务开始一直保留一条连续的执行线。它会记录发现，也会记录自己的 Intent、尝试、结果与交接信息。

FIFO 队列中的 Worker 遵守更严格的单轮协议：

读取双图 → 选择一个问题 → 登记当前 Intent → 执行 → 回写结果 → 关闭 Intent → 回到队尾。

所以，Sliver 相对 Cairn 真正不同的地方，并不是“用了 Blackboard”，也不是“允许 Worker 自己选择任务”——这些思想 Cairn 已经具备。

Sliver 的主要区别在于，它为长期任务增加了一种更明确的协作节奏：

• 长期侦查员负责持续扩大信息面；
• 长期端到端执行者保留连续推理和执行上下文；
• FIFO Worker 不断引入新的观察角度；
• Auditor 只负责提醒停滞和重复，不接管技术决策；
• 每个 FIFO Worker 自己完成一次“选择—执行—回写—收口”的局部闭环，减少规划者和执行者之间的信息损耗。

下面对每个角色的职责说明一下：

侦查员：

侦查员是一个从头到尾，只要题目没有结束，那就信息搜集到死的人，为什么单挂一个信息搜集的人呢？这里是因为，我觉得如果你叫执行渗透测试的人还要一直兼顾信息搜集的思考的话，他可能会分神，也可能做不好信息搜集，专门搞一个人根据全局的情报不断地去深入探索，这种付出是值得的。

FIFO循环队列：

对 Sliver 来说，一个核心问题是：如何只使用一种模型，也能降低单次错误决策带来的成本？

我的答案是：让多个独立 Session 围绕同一份共享状态，自主选择不同的问题，并通过 FIFO 节奏持续轮转。

Sliver 默认维护三个轮转 Worker。FIFO 主要约束的是新一轮决策权：队首 Worker 先读取双图，选择本轮问题并登记 Intent；完成规划后进入执行，后续 Worker 再依次获得规划机会。

因此，它不是三个 Worker 从头到尾严格串行。新的规划按顺序进入，但已经完成规划的 Worker 可以同时执行，系统中最多可以存在三条并行执行线。

每个 Worker 在做决策前，都必须先读取 Intel Graph 和 Exploration Graph，了解已经确认的事实、其他人正在做什么，以及哪些方向已经被尝试过。

它应当优先选择一条尚未被覆盖的路线。如果认为前人的尝试不充分，或者现有结论证据不足，也可以重新验证相近方向，但必须说明自己补充的是什么，而不是机械重复。

确定本轮目标后，Worker 会先把 Intent 写入 Exploration Graph，再开始执行。执行结束后，它需要回写结果、证据和下一步建议，关闭本轮 Intent，然后回到队尾，等待下一轮。

这种循环不能保证系统一定解出题目，也不能保证一定收敛到正确答案。它的作用是增加探索覆盖率，让某一个 Session 的错误判断不至于长期垄断整个任务。

初赛版本中，FIFO Worker 每轮都会创建新的 Session，并重新注入合同和上下文。这种做法带来了更多新视角，但也是 Token 消耗巨大的主要原因之一。

决赛内部版本尝试复用原有 Session，通过类似 Resume 的方式继续执行，以降低冷启动和重复注入的成本，目前观察起来还不是很稳定，所以还需要更多的测试。需要说明的是，当前公开版本的正常 FIFO 轮转仍以新 Session 为主，Session Resume 主要用于单轮执行中的异常恢复。

快速突破手：

为了避免简单题也被复杂的协作流程拖慢，Sliver 在任务开始时还会拉起一个长期存在的端到端执行 Session。

它从任务开始持续工作到任务结束，自己规划并执行完整的解题路线，不需要等待 FIFO 队列逐轮推进，也不接受一个长期 Lead 对技术步骤的拆分和指挥。

但它并不是一个与其他角色完全隔离的孤岛。它仍然读取双图，并将自己的发现、Intent、尝试结果和交接信息写回共享状态。

因此，它的技术决策是独立的，但情报仍然与其他角色共享。

这条长期执行线主要用于快速处理模型能够直接看穿的题目，也为任务保留连续的上下文。与此同时，FIFO Worker 从不同角度展开探索，两条路线形成并行竞速。

Auditor:

仅靠 FIFO 将决策权分散给不同 Session，我仍然不完全放心。模型有时会不断为自己的旧判断寻找理由，多个 Worker 也可能在不同措辞下重复同一条低信号路线。

因此，Sliver 加入了一个临时、只读的 Auditor。

默认存在三个 FIFO Worker。当至少两个不同 Worker 分别完成一轮后，系统会拉起一次 Auditor，让它检查双图中的 Intent、尝试、结果和当前盲区。

Auditor 不负责解题，不发布任务，也不能指定下一步技术路线。它只判断系统是否出现了明显的重复、停滞或长期低信号，并在必要时生成一条简短提醒。

这条提醒会注入后续 FIFO Worker 的任务上下文，让新的执行者在决策时重新审视当前方向。

如果 Auditor 开始决定“下一步必须做什么”，它就会变成另一个 Lead。因此，Sliver 刻意将它限制为只读提醒角色，而不是第二个指挥中心。

3 关于技术文档挂载

很多小伙伴一直都在想知识库这个东西有没有必要挂，我的看法是选择性的挂。因为现在开源模型基本安全能力都已经相当可以了，如果加入太多的限制约束，可能会限制模型的发挥。所以在Agent的合同契约里面可以叫他对skill啥的做一个参考即可。

文章最后其实也没啥好说的，以下是Sliver的协作框架，已经剔除了部分安全能力，大家可以指点一下：

https://github.com/Blue-And-White/Sliver_Lightweighting.git

免责声明

本文仅分享面向合法授权 CTF 竞赛的架构设计与工程实践，供学习和交流使用。请在比赛规则及明确授权的范围内使用相关方法和工具。请勿将本文内容用于未经授权的系统探测、入侵、数据获取或服务干扰。任何超出授权范围的使用均违背本文的分享初衷，相关后果由实施者自行承担。