SDC2026议题回顾 | 一次渗透 Agent 的架构减法实践：大模型、工具和Harness谁更重要？

宿悦茨 | AI安全研究员

AI Red Teaming 正受到越来越多关注，相关 Agent 设计也层出不穷。行业中一种常见的范式，是由 Reasoning Agent 接收目标、拆分攻击方向，再把不同方向并发交给多个 Worker 探索，最后汇总结果并进入下一轮调度。

这种设计看起来很自然：方向拆得越细，覆盖可能越全面；并发的 Worker 越多，推进速度似乎也会越快；共享图记录的信息越多，重复探索就应该越少。最初，我们也相信编排能够涌现出更强的渗透能力，并在本地搭建了类似的 Planner—Workers 架构。

但在 TSecBench 等测试中，这套架构并没有带来预期中的效率提升。单题启动和切换速度较慢，部分难题依旧无法解决。更值得注意的是，层级编排还可能带来一种隐蔽的负优化：一次没有成功的尝试，被逐层压缩成确定结论，最终导致整个攻击方向被提前放弃。

假设一个 Explore Agent 尝试某个方向，发出了一批 payload，却没有获得预期结果。它可能据此认为已经穷尽了可能性，并把结论写入共享图。随后，这条结论从“没打出来”，变成“已经穷尽”，再变成“已经证伪”，最后被调度器用于剪枝。

问题在于，“我没打出来”并不等于“这条路不通”。失败可能只是因为参数没有猜对、字典里少了一个词，或者 payload 的编码方式不合适。如果一次覆盖不足的尝试被写成全局事实，后续 Agent 读到的就不再是一次探索的结果，而是一条看似已经确认、实际上无法复核的判决。

在实际黑板数据中，Fact 可能只有 id 和 description 两个字段。例如，某个节点只留下“JWT 算法混淆方向已系统性排查并证伪”这样的描述。想复核这个结论时，却找不到当时尝试过哪些 payload、使用了什么工具和命令、服务器返回了什么原始响应，也无法知道 Agent 当时的判断有多确定。Intent 同样可能只保留方向描述和来源关系。

因此，下一个 Agent 读到的只是上一个 Agent 的判断，无法复核，只能继承。共享图没有消除错误，反而可能给错误盖上了章。真正需要追问的是：AI 记下来的究竟是事实，还是模型当时的判断？如果价值信号本身不可靠，更强的记忆也可能让偏见持续更久。

Agent 当然需要共享信息，问题不在于“共享不共享”，而在于共享什么，以及多早把信息结构化。一次探索过程中，除了结论，还包括发过哪些请求、参数如何变化、某个 payload 为什么没有成功、服务器原始响应和响应长度差异、尚未验证的猜测，以及仍未覆盖的空间。把这些内容直接压缩成图中的一个节点，很多重要细节就会消失。

更合适的方式是分层保存、各司其职：探索历史用 Markdown 或事件日志尽量完整地记录；工具输出和关键响应作为原始证据长期保留；摘要用于降低阅读成本，但不能覆盖原文；当历史变长时，再通过全文搜索或 RAG 按需找回；图则用于导航和索引，而不是充当唯一事实来源。

例如，“/api/import 已证伪，不是 SSRF 入口”只是一句结论。如果它能够指向当时的对话、日志和工具输出，后续 Agent 就可以检查原始证据，必要时推翻此前判断。结构应该帮助检索，而不应该替代证据。任何抽象都应当能回到原文。

为了观察上下文交接的影响，我们在 TSecBench 上对同一任务进行了对照。实验保持模型、初始题目状态、工具权限以及 token 和成本预算一致，每次都新建干净会话；比较重点是“共享什么”，而不是简单比较单 Agent 和多 Agent。

实验设置包括三种方式：A 是连续上下文，由同一个 Agent 看到完整探索过程；B 是只交结论，由 subagent 返回 Fact 或结论摘要；C 是证据交接，在返回结论的同时提供已测试范围、关键原始响应、不确定性和证据指针。

在补充实验 a-03 中，A 在 1,754 秒时独立完成并得到 flag；B 在 600 秒时超时，没有写出 result.md 或 flag.txt；C 在 600 秒内完成，得到本地候选 flag。B 把上游“入口全是 500”的 Fact 当成终局，停在登录入口，没有重新尝试；C 则能够回看完整上下文，质疑过早否定的判断，重新打开 /login，最终验证 SQL 注入并拿到管理员 session。

这个对照表明，在同模型、同预算、同任务、同一份上游材料的条件下，仅改变交接颗粒度，结果就可能不同。它并不证明摘要一定失败，也不证明多 Agent 必然不如单 Agent；实验验证的是交接保真度的影响，而不是 Markdown、数据库或图等存储格式之间的优劣。

过去，我曾把问题理解为 DFS 还是 BFS，或者如何给 Intent 排优先级、如何在探索与利用之间切换。但后来发现，这个问题本身并不完整。DFS、BFS 默认搜索树已经存在，而真实渗透中的树需要被不断发现，边的权重也会被修正，有时还需要现场长出新的分支。

这里至少有三类情况。第一，节点可能根本不可见：如果字典里没有正确的路径或参数，再聪明的排序也无法走到它。第二，节点可能需要被创造出来：多个看似无关的线索组合起来，才能形成新的攻击路径。第三，边本身可能是错的：如果一次失败被误判成“已经排除”，无论怎样搜索，都可能无法找到正确路径。

因此，渗透当然包含搜索，但它并不是在一棵预先确定的树上搜索。工具帮助模型看见节点，模型能够组合线索、生成新节点，而 Harness 需要避免把尚不可靠的判断写死。

在比赛和基准测试中，我经历了四代架构演进。第一代是共享图多 Agent，采用 Reasoning Agent 与 Explore Agent 分工，并通过共享图协调。第二代是轻量化黑板，把图迁移到 Markdown 或状态文件中，但仍然保留较厚的编排和点、边结构。第三代拿掉规划层，采用单 Agent 在连续上下文中完成整条探索链路。第四代是 PentestPi：保留薄核心，同时加入上下文层级指针和工程护栏，让推理和执行尽量在同一个 Agent 中连续进行。

这些历史结果只能作为观察，不能单独证明因果关系，因为工具、提示词、经验和时间预算等变量也可能同时变化。它们提供的线索是：架构减法值得进一步调查，而不是“提升全部来自架构”，更不是“越薄越好”。

在百度 Agent+ 攻防赛中，满分为 23,160 分，单场约 6 小时，同时仅有 3 个题目实例。Pi-v1 采用粗糙黑板并保留厚编排，内部测试得分约为满分的 16%—27%；Pi Recon 使用裸单 Agent，在约 2.4 小时内得到 11,160 分，约为满分的 48%；PentestPi 采用薄核心与上下文层级指针，得到 13,955 分，约为满分的 60%，最终进入前 15。

PentestPi 大约在 4.3 小时后就主动结束了任务，仍有约 1.7 小时没有使用。这也暴露出另一个问题：即使前面的推理和工具已经发挥作用，如果 Harness 没有维持任务生命周期，Agent 也可能提前退出。以上是比赛和内部测试中的实际观察，并非严格受控的消融实验；更稳妥的理解是，较轻的设计帮助能力兑现成了成绩，但不能据此推导出普遍定律。

我的判断是，模型仍然最重要。模型决定拿到线索之后能想到什么、如何组合线索，以及下一步采取什么行动。工具决定哪些线索能够被看见和执行，包括路径与参数枚举、响应差分和原始证据获取。Harness 则负责状态管理、上下文压缩、调度与退出控制，让前两者能够稳定、持续地发挥作用。三者各司其职，而不是相互替代。这里的“模型 > 工具 > Harness”是工程投入的优先顺序，不是关于普遍能力的定律。

TSecBench 的 a-16 案例中，Agent 已经识别出 SSRF，也拿到了 token，攻击链大部分方向正确，但在探测 /admin 下的入口时尝试了 approve、review 等路径，却没有发现 /admin/info。它手工枚举了数百个端点后，认为方向已经证伪。后来接入 Arjun 和离线高频参数表，发现参数 source_url，最终完成利用闭环。

a-05 案例也有类似情况：Agent 已经通过本地文件读取漏洞读取文件，却没有猜中 flag 的正确路径。它尝试了若干常见路径，但实际目标是 /challenge/flag.txt。补充扫描工具并调整字典后，问题很快得到解决。改变结果的不是更精巧的编排，而是让 Agent 看到了原先不在搜索空间里的节点。

同一个 Agent，配备工具和不配备工具，解题效率与成功率可能完全不同。没有工具时，模型只能手工尝试有限的路径或 payload，覆盖范围很窄，却容易误以为已经尝试充分；有了合适的枚举和验证工具，机器可以稳定地跑过成百上千个候选，模型则可以把注意力放在响应差异和利用链上。工具还应当对 AI 友好，让模型能清楚看到发了哪些请求、请求之间有什么差异，以及它们发生的顺序。

a-18 案例体现了模型的另一种作用：创造新的路径。一个 Agent 尝试了空加密绕过、公钥混淆和弱口令等方向，都没有成功；另一个 Agent 找到了本地文件读取线索。两边的细节分散在不同上下文中，共享图又没有保留足够细的颗粒度，最终没能解题。换成单一 Agent 后，相关线索可以留在同一上下文中，模型便有机会把它们组合起来。

案例中，模型将可控的 kid、HS256 密钥可以是任意字节，以及应用文件内容能够被完整读取等线索联系起来，生成了原先没有明确列出的路径。这不是在已知树上遍历，而是通过类比和组合创造节点。

模型之间的能力差异也会直接影响结果。在 CyberGym / TSecBench 的测试中，同一道 hard 题目，GLM（glm-5.3-flash）约 12 分钟拿下并获得 500 分；DeepSeek（deepseek-v4-flash）运行 38 分钟仍未得到 flag、没有提交。这个案例说明模型能力会影响渗透 Agent 的上限。Harness 可以提醒模型检查某个方向，却很难补出模型本身没有想到的利用方式；多跑几轮编排，也不一定能创造出模型本身不存在的安全直觉。

在那场约 6 小时的比赛中，PentestPi 约 4.3 小时后主动交卷，剩余约 1.7 小时没有使用。实际执行中，任务跑完一两轮后就退出了。对于需要持续探索的场景，Harness 应负责确保任务不会无故中断：只要赛程未结束、仍有未解题目，就根据历史记录轮换重试；持续填满平台允许的并发槽位；对单题设置墙钟熔断，避免在一道题上耗死；在压缩上下文前先保存状态和证据。

这些是 Harness 适合承担的确定性职责。它不应该替模型设计微观攻击图，也不应该用僵硬规则规定每个漏洞必须如何利用。重点是让推理和执行能够持续、稳定地发生，而不是把模型的判断提前固化。

上下文变长后，压缩很难避免，但未闭环的线索不能跟着消失。直接依赖原生压缩机制，可能会丢掉渗透过程中的关键细节。因此，我在 PentestPi 中使用 pentest_state.md 保存已验证事实、未闭环线索、证据文件引用和下一步验证条件，并让这些状态指向原始会话和工具输出。

PentestPi 的做法是：压缩前触发自动归档，将完整工具输出复制到 .pi/evidence/；在 state 中保留原始文件位置和 session JSONL 路径；原始记录只追加、不覆盖，让后续 Agent 需要时可以回去检索，也可以推翻此前的结论。摘要负责减轻阅读负担，原始证据负责保真，图和 RAG 负责导航与检索。

模型训练存在瓶颈，不可能见过各种冷门手法和绕过套路。Playbook 可以把这些经验沉淀成外置手册，在出现对应特征时再按需加载。例如，常驻索引 playbooks/INDEX.md，只记录端口或协议特征；当扫描发现 6379、9000 等端口，或响应中出现对应框架指纹时，再加载相应手册，也可以由人工通过 /pentest-playbook 注入。

相比不断增加复杂的 Harness 设计，把经验写成 Playbook，并在需要时提供给模型，可能是补齐技战法更有性价比的方式。

图便于人快速观察主路径和死支，但把非结构化的攻防过程强行压缩成图，可能损失重要信息。可以让主 Agent 正常执行文本和工具操作，同时设置一个后台 Observer，每 30 秒异步读取原始会话与工具回显，生成供人查看的推理树视图。Observer 不打断主 Agent 的执行，图也不再是 AI 唯一的事实来源。

连续上下文、从头探索到尾的单主 Agent，适合单点突破、复杂 CTF、内网横向和未定型漏洞挖掘等场景。这些场景通常状态空间未知、线索相互依赖，需要跨阶段上下文。

资产测绘、合规扫描、SCA 依赖比对和超大规模渗透等任务，边界更明确、结果更容易独立验证、子任务也更容易并行，仍然适合多 Agent 或传统流水线。要避免的不是多 Agent 本身，而是过度设计和信息过度切分；关键是做好复杂与简单之间的平衡。

“方向已穷尽”是高风险判断，不应轻易被写成不可回滚的 nogood。可以记录试过什么、响应是什么，但要为后续复核留出空间。

更好的字典、工具、响应和文件访问能力，往往比多一层 Planner 更有价值，因为它们能够增加模型看得到、走得到的节点。

选择更强的模型，给它连续的执行空间，保留原始证据，并在必要时做好交接。不要为了“多 Agent”三个字，把利用链切碎。

Markdown、日志和原始输出负责保真，摘要负责减负，图和 RAG 负责检索。任何抽象都应当能回到原文，让 Agent 在新证据出现时可以重新判断。

这并不是说架构越薄越好，而是应该把工程投入放在真正影响结果的地方：模型推理、工具可见性、连续执行，以及可复核的证据状态。