【AI攻防】红队智能体最难的不是攻击链，是刹车位的设计

原创

xg
xg

安全驾驶舱

2026年9月20日 15:25
广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

0x01 背景

红队智能体这事儿，圈内聊得最多的是\"模型能不能自己挖洞\"。我的看法反着来：攻击链是死知识，ATT&CK 和大模型早就给你摊平了，真正的难点从来不在链上，而是在哪儿踩刹车。for 循环式的 Agent 谁都能写：扫描、打点、提权、横着走，走完收工。但\"什么时候必须停下来问人\"，这个设计几乎没人认真做，而它才是决定一场自动化红队是演练还是事故的分界线。

下面这五条，是我在实际编排里趟出来的判断，不按阶段清单走，按问题走。

0x02 刹车位比油门重要

整套编排里最硬的一条规则，不是\"怎么打\"，是\"目标未确认，不得进入下一阶段\"。初看是句废话：打目标当然先要知道要什么。真正值钱的不是这句话本身，是它点出来的结构——自动化的每一步都必须能回答\"目标和边界是什么\"。

Agent 的优化目标是完成任务。任务描述里一旦没有\"目标\"这个字段，它就会把\"跑完全部步骤\"当成胜利。产出从\"关键数据\"退化成\"能交差的数据\"——前者是结案，后者只是看起来像成果的垃圾。

顺着这个思路推一层，就会遇到一个没人明说的问题：人工干预点的密度怎么定。干预点插得太密，Agent 每走一步都在等审批，自动化变成了人工驾驶；插得太稀，等发现跑飞的时候已经晚了。这个密度不该靠拍脑袋，应该靠历史回放：拿上一次演练的完整日志，找出\"人工介入后动作方向发生改变\"的位置——那些位置天然就是刹车位。没有日志的团队，先补日志，再谈编排。刹车位的每一条，都是拿事故换回来的。

0x03 流程可以回退，上下文必须能重载

编排图里最容易被忽略、却最有价值的一条边，是回退：某个环节发现新的攻击面，跳回更早的阶段重新走。攻击链是网状的——内网里多发现一台机器，涉及该资产路径的前序判断都要重估。流水线逻辑是走完就结束，状态机允许你再拐回去。这是两套世界观的差别，也决定了工作流到底该长成什么样。

回退边有一个工程代价，我第一版没想清楚：上下文必须能重新加载。你不可能把之前二十几轮对话原样倒回给模型——既烧 token，又把注意力稀释在无关的历史里。正确做法是把两类上下文拆开：一类是决策上下文，也就是阶段基线（目标、指纹、已知约束），另一类是执行上下文，也就是当轮证据。回退时只重载决策上下文，让模型基于新的动态重新推理。这个解耦点，才是工作流存在的真正理由——它不是转发请求的代理，是替模型管理它自己管不动的长期状态。

0x04 过程可观测性，才是证据

演练里最常听到的一句话是\"我打进去了\"。真要复盘，这句话等于什么都没说。可核验的证据长这样：做了什么探测、发了什么动作、得到什么结果、什么时候被防守方看见。缺了过程的\"证据\"，是回忆，不是证据。这直接决定了清理动作的顺序：想删的痕迹，先确认它已经被记录成可核验的状态，再动手。顺序反了——先清理、后补截图——产出的复盘每一条都经不起对质。那不叫复盘，叫创作。

复盘这边是一门硬账：MTTD（Mean Time To Detect，平均检测时间）、MTTR（Mean Time To Respond，平均处置时间）、命中检测规则数，三项全部量化，拿去和蓝队对表。两边数字对得上，一次演练才有结论。\"绕过了防护\"是形容词，\"命中检测规则 3 条\"是数据——形容词进不了评审会。做到这一步你再回头看，会发现工作流最大的副产品不是攻击成果，是给防守方留了一份可对账的台账（跑题一句：只看攻击成功率的演练报告，和只看击杀数的射击游戏评测，是同一种幻觉。）

0x05 评分要防自证

打分环节有一条我看了好几遍的规则：命中\"已被检测/告警\"，先降回基础分，再评估其他加分项。翻译过来：被蓝队抓到过的链，其在\"检测避险\"维度（即靠躲避检测获得的加分）上的得分直接取消，不再参与加分；同时整体加分封顶线同步下调。我当时愣了一下——它砍的正是\"我覆盖了七八个战术\"这种自我表扬。覆盖度是纸面努力，被检测是实战结果。评分一旦允许自证，就只是给报告盖章的机器；只有允许被对证方一票否决，它才变成两边的公共事实。

同一条规则背后还藏着另一个判断：同一份技术报告，换到不同业务体量下，根本就不是同一个漏洞。核心业务的网络边界、金融场景的权限模型、涉隐私的数据面，各自决定同一个缺陷能不能发酵。这也是为什么只看 CVSS 基础分、不做业务环境指标（CR/IR/AR）叠加，会误判真实风险。

0x06 资源投入的时机，也要编排

信道建立这件事，在流程里被拆成两个时间点：先建一次撑住后续横向，再专门做一轮抗检测实测。一开始我想把它们合并：同样是建信道，为什么要做两次？后来想明白，这是两类完全不同的问题——前者是\"能不能连上\"，后者是\"连上了会不会被发现\"。验证型 PoC 可能只是证实一条链路，为它搭一套中继，是用高价值信道换低价值探针。先让访问变成控制，再谈信道的抗检测质量。

我把这个判断总结成一条原则：资源投入必须跟目标的稳定度匹配。这个原则在编排里比在任何工具配置里都重要——它决定了你的高价值资产（信道、中继、凭据）是在喂一个可能三分钟就失效的探针，还是在喂一个已经拿稳的控制面。

0x07 收尾

把这些凑到一起，红队智能体工作流的本质就出来了：不是让 Agent 更聪明，是让它在错误的方向上走不远。刹车位的密度、上下文的解耦、过程的台账、评分的反自证、资源投入的时机——每一项都在收窄\"跑飞\"的可能性边界。

但这套设计兜得住\"Agent 出错\"，兜不住另一种情况：它不知道自己不知道——刹车位设计得再好也拦不住自信的幻觉，因为它根本不会主动停下来问。所以最后一道闸不在常规流程节点里，在终止条件的设计上：工作流必须给 Agent 一个明确的\"放弃 / 降级人类接管\"的出口，而且这个出口要有优先级意识。

END