旗舰节 17.3 用一条可疑登录告警，把 L4 自主调查的形态交代完整了：完整轨迹、人在回路 gate、成本分层、失败回滚、如何评估。本节做的是另一件事——用同一把自主等级标尺，量三个不同安全域的场景：看它在不同的爆炸半径、数据条件、组织成熟度下，分别该停在哪一级、又会在哪里绊倒。这是一节关于怎么给一类工作选对自主等级的对照，而不是把旗舰轨迹换个场景重走一遍。
这不是"成功案例集"。三个案例分别停靠在不同的自主等级：告警研判类推到了 L4，合规取证类停在 L3，而反欺诈那个是上错了等级的反面教材。案例 A 与旗舰节 17.3 同构，只作对照条目（L4 的完整机理见 17.3）；案例 B、C 各带一条轨迹与失败回滚，因为它们分别演示 L3 的克制、以及"上错等级"的代价。
关于数据的说明：本节所有企业、告警编号、指标数字均为脱敏后的构造示例，用于说明工程形态与决策逻辑，不代表任何真实企业，也不代表行业平均水平。出现的具体框架（AWS Strands Agents、Hermes Agent）只是当前的一种承载，换成 ADK / Claude Agent SDK / LangGraph 不影响案例的骨架。这些自托管 agent 自身的攻击面（供应链、记忆注入、MCP 信任边界）其防御深度归 第18章 Security for AI，本节只用其正面用途。
| 案例 | 安全域 | 停靠的自主等级 | 智能体做的事 | 关键看点 |
|---|---|---|---|---|
| 案例 A | 安全运营 / 钓鱼响应 | L4(自主调查)+ 阻断式 gate | 一封被举报的钓鱼邮件，自主查发件源、附件、受影响范围 | 多步取证轨迹如何驱动处置分级 |
| 案例 B | 治理合规 / 审计取证 | L3(固定编排)+ 通知式 gate | 按审计要求自动收集、核验、归档证据 | 为什么这里不该上 L4 |
| 案例 C | 业务安全 / 反欺诈 | 上错等级的反面教材 | 把秒级、高误伤代价的决策错误地交给 agent 自主执行 | 上错等级要付的学费 |
这张表和 17.3 的自主等级表同理：关键不在找"最高那一档"，而在看每个场景为什么停在它该停的地方。案例 C 之所以失败，根子就在于它把一件本该停在"ML 打分 + 规则兜底"的工作，硬推到了 agent 自主执行——上错等级和不上 agent，是同一枚硬币的两面。
案例 A 和旗舰节 17.3 的可疑登录调查是同一种形态：L4 自主调查、只读多步取证、按爆炸半径分级的 gate、失败回滚、进回归集。L4 的完整机理、gate 分级的"可逆性 × 爆炸半径"标尺、以及"可追溯证据链是人在回路能真正把关而非橡皮图章的前提"，17.3 已经写清楚，这里不复述。本案例只补 17.3 没覆盖的那一面——钓鱼场景特有的"范围界定"（campaign scoping），以及它带来的一种独特失败形态。
为什么值得上 L4 而非加一条规则，理由和 17.3 相同：同一封邮件是不是钓鱼，要看发件域注册时间、附件沙箱行为、是否定向投递多人这些需多步取证才能拼出的证据，下一步查什么取决于上一步查到什么——这正是 L4 相对 L3 的分水岭。
钓鱼场景独有的一步是范围界定。查实是钓鱼之后，L4 agent 的调查重心会自主从"它是不是钓鱼"切到"谁中招了"。对举报工单 PH-40271，agent 在确认发件域是 6 天前新注册的伪装域、附件是钓凭据而非投木马之后，用发件域加主题模糊匹配圈定同批投递范围，发现同批投了 23 个邮箱、4 人点击、1 人（t.zhao）在仿冒页发生了表单提交——t.zhao 因此成为最高优先级。这个"据钓凭据这一结论临时把调查重心切到范围排查"的自主转向，正是 L3 固定 playbook 覆盖不到的地方。随后 agent 按爆炸半径给出分级处置建议：召回邮件可自动执行、拦截发件域走通知式 gate、重置 t.zhao 密码走阻断式 gate；agent 停手交人工，分级依据与 17.3 的标尺一致。
范围界定也带来一种特有的失败形态。campaign-scoping 靠发件域加主题模糊匹配圈范围。某次攻击者在同一波投递里换了两个发件域、微调了主题（一批"待处理发票"、一批"账单待确认"），agent 只圈到第一批 23 人，漏掉了第二批 9 人——其中就有真正泄露了凭据的那个。没酿成大祸，是因为"召回邮件"这一档本就可逆（补一次召回即可），而真正危险的"重置密码"走阻断式 gate、需人工触发，agent 没圈到人、gate 也就没误触发。教训不在 agent 不够自主，而在取证工具的召回率：修复方向是给 campaign-scoping 补上附件哈希、发件基础设施（IP/ASN）的关联维度，而不是让 agent"更自主"。这次漏报作为"多域加主题变体的同一波投递"黄金样例，进了轨迹级回归集（见 17.3 与 17.2 评估与回归）。
一句话：案例 A 相对 17.3 的增量，就是"范围界定"这一步及其失败形态；L4 的完整轨迹、gate 分级与证据链要求，去看 17.3，本节不重复。
某受监管机构每年要应对多轮合规审计。每轮审计，合规团队要按审计清单收集上百份证据(访问控制配置、日志留存记录、变更审批单、加密策略截图……)，人工收集耗时以天计，且不同人收的格式还不统一。
这看起来是个"上 agent"的好场景，但关键判断恰恰相反：它该停在 L3，不该推到 L4。 理由是 17.3 那把尺子——审计取证的工作特征是需求清晰、可枚举、稳定：审计清单每年变化很慢，"证据 X 该从系统 Y 的哪个接口取、取来长什么样算合格"是预先就能写死的固定流程。这种场景没有"下一步查什么取决于上一步查到什么"的自主研判需求。
按上 agent 前那道必答题来核对：这里并不需要 agent 的多步自主推理。一个 L4 自主 agent 用在这里，只会带来两个坏处：① 每份证据都走多次 LLM 推理，成本比固定编排贵几个量级，而收益为零；② 自主性带来不可预知性——审计场景最忌讳"这次取的证据和上次不一样"，而固定编排正好保证可复现、可审计。把可预测、可枚举的工作压在 L3，是省钱也是省心。（合规审计本身的纵深实战——完整审计流程、证据体系、GRC 运营——见 17.5 AI 治理风险合规；本案例只讲它的自主等级选型：为什么该停在 L3。）
所以案例 B 的智能体是一个 L3 固定编排 agent:流程是人预先写好的 DAG,LLM 只在需要语义判断的单个节点(比如"这份配置截图是否覆盖了清单要求的控制项")上被调用一次，不做跨步自主决策。
L3 的轨迹长得和 L4 不一样：它是预先编排的固定序列，agent 不自主决定下一步，只在固定的节点上执行取证与核验。以证据项"访问控制：特权账号 90 天审阅记录"为例：
取证编排 · AUDIT-2026Q3 · 证据项 AC-07(特权账号审阅)
════════════════════════════════════════════════════════════
编排类型: L3 固定 DAG(流程预先写死,非 agent 自主)
── 节点 1: 采集 ──────────────────────────────────────────
工具调用: iam.export_pam_review(period="last_90d")
返回: 特权账号审阅记录 CSV,含 14 个特权账号、审阅人、审阅日期。
(纯确定性动作,无 LLM 参与)
── 节点 2: 完整性核验 ────────────────────────────────────
工具调用: rule.check_coverage(records, checklist_item="AC-07")
返回: 14 个账号中 13 个有 90 天内审阅记录,1 个(svc-backup)
无记录。规则判定: 覆盖率 13/14,不达标(要求 100%)。
(纯规则判定,无 LLM 参与)
── 节点 3: 语义研判(唯一调用 LLM 的节点)─────────────────
LLM 任务: 判断 svc-backup 缺失审阅是"证据缺口"还是
"该账号本轮已停用、无需审阅"。
输入: svc-backup 的账号状态、最后活跃时间、停用工单(若有)。
返回: 该账号 45 天前已停用并留有工单,属"无需审阅"的合理豁免,
非真实缺口。建议在证据包中附停用工单作为说明。
(LLM 只做这一次单点语义判断,不决定下一步)
── 节点 4: 归档 ──────────────────────────────────────────
工具调用: evidence.package(item="AC-07", files=[csv, 停用工单],
note=<节点3 生成的说明>)
返回: 证据包已生成,标记状态"待合规官确认"。
─── [人在回路 GATE:通知式] ───────────────────────────────
证据包自动入库并即时通知合规官。合规官可在提交监管前
复核/驳回节点 3 的豁免判断。
════════════════════════════════════════════════════════════
对比案例 A 的轨迹，差别一目了然：这里没有"据上一步结果决定下一步查什么"的自主循环。节点 1→4 是预先编排死的，LLM 只在节点 3 被调用一次做单点语义判断。这就是 L3——人写好流程、AI 填空，而不是 A 案例里的 AI 自己决定流程。
案例 B 的 gate 是通知式的：证据包自动生成入库，同时通知合规官复核。这一档在编排层的实现是 17.3 3.5 里的 notify_policy 段——通知通道与超时、回退窗口与到期动作、以及允许开启它的五条前置条件都在那里；本案例满足这五条（证据包是草稿态、可整项驳回、作用域是单个证据项、对外提交权限不在 agent 手上、被拒调用留痕）。为什么不像案例 A 的重置密码那样用阻断式？还是那把爆炸半径的尺子：
- 生成一份待提交的证据包，本身不改变任何生产状态，也不对外产生法律效力——真正有爆炸半径的是"把证据包提交给监管方"这一步，而那一步根本不在 agent 的动作权限里，是合规官人工完成的。
- 所以 agent 能做的最危险的事，不过是往证据包里放了一份判断有误的说明(比如把真实缺口误判为合理豁免)。这可逆(合规官驳回即可)、且有人工复核兜底，故用通知式即可。
把 gate 分级和动作权限设计绑在一起看：案例 B 真正的安全设计不只是 gate 的类型，更是根本不给 agent"对外提交"这个动作的权限——最危险的那一步被从 agent 的能力边界里切了出去。这呼应 17.2.9 讲的"落地 agent 必须消费的安全控制"里的权限最小化，其攻防深度见 第18章。
案例 B 的失败形态很具体：节点 3 的 LLM 把一个真实的证据缺口误判为合理豁免。设想 svc-backup 那张"停用工单"其实是一次被撤销的停用申请(账号事后又被启用),LLM 没读出工单状态的这层反转，把它当成有效停用，于是把一个真实的"特权账号 90 天未审阅"缺口，包装成了合理豁免写进证据包。
回滚与止损：
- 通知式 gate 是第一道保险丝：证据包入库即通知合规官，合规官在提交监管之前复核节点 3 的判断。这次误判会在人工复核环节被拦下——前提是合规官真的看了证据链里节点 3 的推理依据，而不是橡皮图章式点通过。这再次说明可追溯证据链是 gate 起作用的前提。
- 回滚成本低，因为证据包是草稿态：被驳回的证据项退回"待补充"状态，补一份真实审阅记录即可，不涉及任何不可逆的对外动作。这正是 L3 固定编排在合规场景的优势——每一步可复现、可回退、可审计。
- 进回归集的方式："被撤销的停用工单"作为一条边界样例进 LLM 节点的黄金测试集，并给节点 3 的输入补上"工单当前状态"字段。修复方向依然不是"让 agent 更自主"，而是让单点语义判断的输入更完整。
案例 B 的整体教训：它的成功就在于克制。 没有把它推到 L4，而是老老实实用固定编排 + 单点 LLM，换来了可预测、可审计、便宜——这在合规场景里比"更聪明"重要得多。能用 L3 解决的，不要上 L4；这和"能用规则解决的不要上 LLM"是同一条纪律。
前两个案例展示了 agent 停对等级的样子。案例 C 是反过来的：一个把工作推到了错误的自主等级而失败的项目，它比任何成功案例都更能说清"什么时候不该上 agent"。
某电商平台的支付风控，面对的是秒级、海量的交易决策：一笔订单进来，必须在几十毫秒内判"放行 / 拦截 / 转人工"。团队被 agentic 的能力打动，做了一个大胆的设计：让一个 LLM agent 在每笔可疑交易上自主调查——查用户历史、查设备指纹、查关联账号图谱，然后自主决定拦不拦，试图复刻案例 A 那种"多步取证 + 自主判定"的漂亮轨迹。
这个设计从第一天起就错了，而且错在最根本的等级判断上。用 17.3 那几个"上 agent 前先问"的问题一量，全是红灯：
| 判断维度 | 反欺诈这个场景的真实答案 | 结论 |
|---|---|---|
| 延迟能否承受多步 LLM 推理？ | 不能。决策窗口几十毫秒，一次 LLM 推理就超了 | 红灯 |
| 单条决策成本能否承受？ | 不能。日均数百万笔，每笔上 agent 是天文账单 | 红灯 |
| 结论的可逆性 / 误伤代价？ | 极高。误拦一笔正常订单 = 得罪一个真实用户 | 红灯 |
| 规则 / ML 能不能先定大部分案？ | 能。绝大多数交易用 ML 打分秒级可定 | 红灯 |
四个红灯，任何一个都足以否掉这个设计。这里根本不该上自主 agent——问题不在 agent 的能力，而在场景本身：延迟、成本、误伤代价三重约束和 L4 自主调查的特性完全对不上。这类工作的正确停靠点是 L1 的 ML 打分 + 规则兜底：XGBoost 一类的树模型在几毫秒内给出欺诈分，高分转人工、低分放行，又快又便宜又可预测。
团队还是上线了。下面这条"轨迹"本身就是问题所在——它展示了 agent 在一个错误场景里，即便每一步看起来都合理，整体也是灾难：
Agent 处置 · TXN-9931122 · 一笔被判可疑的支付
════════════════════════════════════════════════════════════
致命设计: agent 被授权在无人 gate 的情况下自主拦截交易
── Step 1 ── user.get_history(uid) ── 耗时 ~800ms
返回: 该用户近 30 天无异常,但今日下单频次偏高。
── Step 2 ── device.fingerprint(uid) ── 耗时 ~600ms
返回: 设备为新设备,与历史常用设备不符。
── Step 3 ── graph.related_accounts(uid) ── 耗时 ~1200ms
返回: 关联到一个 3 个月前有过争议的账号。
推理: 新设备 + 高频 + 关联可疑账号 → 判为高风险。
决策(致命): 直接拦截交易。无 gate。
════════════════════════════════════════════════════════════
实际情况: 该用户只是换了新手机、赶大促多下了几单,
那个"关联账号"是三年前的室友,早无往来。
后果: 一笔正常大额订单被拦,用户投诉;单次决策耗时 2.6 秒,
远超支付窗口,大促高峰期大量交易超时堆积。
每一步的工具调用都不算错，但整个设计错到骨子里：① 2.6 秒的决策延迟在支付场景等于不可用；② 让 agent 无 gate 自主拦截，把一个高误伤代价、不可逆(得罪用户)的动作交给了概率性判断——这违反了案例 A、B 反复强调的"高爆炸半径动作必须有 gate"的铁律。
这个项目的"回滚"要做的是整体退回到它本该停靠的自主等级，而不是修一次误判：
- 降级到 L1 主链路：恢复 ML 打分 + 规则引擎作为秒级决策主力，承接 99% 以上的交易。这是又快又便宜又可预测的正解。
- agent 退回到它真正有价值的位置——离线，而非在线：LLM 的多步推理能力有用，只是用错了地方。它真正的价值在离线的对抗分析：定期让 agent 自主复盘一批已确认的欺诈样本，探索黑产的新手法、生成新的规则假设交风控专家评审。这里没有秒级延迟约束、没有实时误伤风险，agent 的自主探索恰好用在刀刃上。这与 17.3 讲的威胁狩猎"智能体自主探索假设空间"是同一个道理。
- 在线动作永远保留人 gate:即便对少数 ML 判为高风险的交易，最终"拦截"这个高误伤动作也走转人工而非 agent 自主——延续那条铁律。
案例 C 最该记住的一句话：它的失败不是"agent 不行"，而是"agent 被放错了位置"。 同一个 LLM 自主推理能力，放在案例 A 的钓鱼研判(可容忍数秒延迟、只读取证、处置有 gate)是恰到好处，放在秒级支付拦截就是灾难。
这把 17.3 贯穿全节的那条纪律落到了最实处：
- 凡上 agent 处，必须先答"为什么不用更便宜的 ML/规则"。 反欺诈这个场景，这个问题的答案是"ML 完全够用"，于是就不该上 agent。
- 延迟、成本、可逆性任何一个亮红灯，自主 agent 就要让位。 秒级、海量、高误伤代价的决策，是 ML 和规则的主场，不是自主 agent 的主场。
- LLM 的自主推理最该花在：模糊的、高价值的、可容忍延迟与成本的、且动作有 gate 兜底的少数场景。反欺诈里符合这个描述的，是离线对抗分析，不是在线拦截。
把三个案例并排看，最该带走的不是任何单一结论，而是那把反复出现的统一标尺——用价值、风险、可逆性判断每类工作该停靠的自主等级：
| 维度 | 案例 A 钓鱼研判 | 案例 B 审计取证 | 案例 C 反欺诈(反面) |
|---|---|---|---|
| 停靠等级 | L4 自主调查 | L3 固定编排 | 错推到 L4，应在 L1 |
| 为什么是这级 | 需多步因果取证，下一步依上一步 | 需求可枚举、稳定，无需自主 | 秒级 + 海量 + 高误伤，ML 才对 |
| 延迟容忍 | 数秒可接受 | 分钟级可接受 | 几十毫秒，LLM 直接出局 |
| 最危险动作的 gate | 阻断式(重置密码) | 通知式 + 无对外权限 | 错误地无 gate 自主拦截 |
| 失败形态 | 取证范围召回不足漏受害者 | 语义豁免判错 | 上错等级，延迟与误伤双爆 |
| 回滚方式 | 补召回 + 工具补关联维度 | 草稿态驳回 + 补输入字段 | 整体降级回 ML 主链路 |
三条贯穿始终的纪律：
- 停对等级，是 agentic 落地的第一决策。 要回答的问题是"这类工作该停在哪一级"，而非"能不能上 agent"。案例 C 的失败全在这一步判错。
- gate 分级跟着爆炸半径走，且要和动作权限设计一起看。 只读自动执行、可逆通知式、不可逆阻断式；更彻底的做法是像案例 B 那样，直接不给 agent 最危险动作的权限。
- 每个 agent 都要能讲清自己怎么失败、怎么回滚、失败样例怎么进回归集。 讲不清失败的 agent 方案不可信；修复方向通常是"给它更好的工具、更完整的输入、更严的 gate"，而非"让它更自主"。
这三条，连同旗舰节 17.3 的完整方法论、17.2 的评估与回归、17.9 的落地路径，构成了本章对"如何把安全智能体真正用起来"的完整回答。而这些 agent 自身作为攻击面的防御设计，是 第18章 Security for AI 的主题。
← 上一节：17.10 演进与展望 | 返回章节目录 | 下一章：第18章 Security for AI →
© 2025-2026 AISecOps Project. Licensed under CC BY-NC-SA 4.0