Anthropic 把 SOC 误报率从 33% 砍到 7%，真正在干活的不是 Claude

这套系统跑出 33%→7% 的效果跟 Claude 模型本身的关系可能只占三成。剩下七成是什么是数据治理、是分层 cascading inference、是 Tool Calling 编排、是 confidence score 分级、还有他们敢于打破合规惯性的那种产品哲学。这五件事模型可以换但工程决策抄不抄得动决定了你们企业能不能复现 CLUE 这个效果。这篇文章就把这五个决策一个一个拆开。资料来源Anthropic 官方博客《How Anthropic uses Claude for security operations》2026-05-12作者 Jackie Bow配套 YouTube 视频 FPPTnI88RR8以及 Dropzone AI 的第三方解读。SOC 自动化 15 年到 CLUE 这里改了游戏规则先把时间线铺一下不然你看不出 CLUE 为什么是个分水岭。2005 年 Splunk 上市SIEMSecurity Information and Event Management这个范式被钉死——把所有日志拽到一个地方靠规则和搜索查异常。这是 SOC 的第一代基础设施。2014 年 Phantom Cyber 出现2018 年被 Splunk 收购SOARSecurity Orchestration, Automation and Response成型——你写 playbook告警来了照剧本走先查 IP 信誉、再拉用户上下文、然后判断是否隔离主机。这是 SOC 的第二代把流程自动化了。但 SOAR 有个天花板playbook 是确定性的攻击是非确定性的。一个攻击者只要改一个字符、绕一个步骤、走一个新的入口你的 playbook 就匹配不到告警还是得 fall back 到人工。Security Boulevard 在 2026 年 3 月那篇《The SOAR Ceiling》写得很直接playbook 自动化已经到了它的结构性极限再堆规则只是徒增维护成本不会再带来检测能力的提升。2023 年 4 月Microsoft 发布 Security Copilot第一个把 LLM 塞进 SOC 工作流的大厂产品。再后来 Crowdstrike Charlotte AI、Palo Alto Cortex XSIAM、Google Security Operations、Splunk ES Premier 全部跟进。这是第三代——LLM-assisted SOC但骨子里还是工具加强版分析师是主体LLM 是助手。2026 年 5 月 12 日Anthropic 发那篇博文之前他们当时的 CISO Jason Clinton 已经在 RSA 2025 上公开说过一句话我们没有传统意义上的 L1/L2 SOC 团队了。CLUE 是这句话的工程实现。它不是 LLM 助手是把整个分诊工作流交给 agentic loop 跑——一个告警进来Sonnet 做初步分诊、判断要不要展开调查要的话就 fan-out 一堆 sub-agent每个 sub-agent 拉一类上下文Slack、文档、代码仓库、数据仓库最后用 Opus 做高风险判断输出一个带 confidence score 的结论给分析师。15 年时间从把日志集中起来到把流程剧本化再到让 LLM 当助手最后到让 Agent 直接接管 L1。CLUE 不是又一次技术升级是范式更迭。但这并不意味着你们公司明天就能照搬。先把 5 个常见误解打破围绕 CLUE 的舆论场里我看到至少 5 个被反复引用、但其实是误读的观点。先把这些拆掉后面讲架构才能讲得清。误解一CLUE 是 Anthropic 要发布的产品。不是。CLUE 是 Anthropic Detection Platform Engineering 团队自用的内部平台不卖、不开源、目前也没有任何商业化计划。Jackie Bow 在原博文里说得很清楚——我们分享这些是为了让安全社区受益但分享的是工程经验和模式不是代码或 SaaS。误解二CLUE 替代了 SOC 分析师。也不是。它替代的是 L1 的重复性分诊工作——那种看到告警就要去查 5 个系统拼上下文的体力活。L2/L3 的深度调查、威胁狩猎、事件响应还是分析师做。Jackie Bow 原话Our analysts now operate at a fundamentally different level—asking questions that drive strategic security improvements.误解三CLUE 的核心创新是自然语言查询。这是最容易被表面看走眼的地方。自然语言界面只是 UI 层真正的核心是 agentic loop sub-agent fan-out Tool Calling 编排。一个调查 session 平均要 25 次 tool call、11 次 query这背后是非常激进的工具调用编排策略不是简单的我用自然语言问问题。误解四33%→7% 主要是 Claude 模型的功劳。这是最关键的误解。Anthropic 原文里其实写得很清楚Claude enriches alerts with context from Slack messages, documentation, code repositories, and data warehouses。换句话说误报率砍掉 26 个百分点的主因是终于把全公司的上下文喂到了告警判断里——之前 SOC 工具看到一个可疑登录能拿到的就是 IP 用户 时间现在 Claude 能顺手翻 Slack 看用户有没有说我要去东京出差。数据治理不到位的企业换什么模型都救不了。误解五非确定性是 AI SOC 的优势。Jackie 在原文里引用了 Rich Sutton 的《The Bitter Lesson》强调 CLUE 故意拥抱非确定性——Traditional security tools treat inconsistency as a bug. CLUE treats it as a feature.这在 Anthropic 这种自管合规的公司是优势但你要是金融行业、医疗行业、政府客户审计员看到同一个告警今天判定隔离明天判定放行会直接 fail 你的 SOC2。非确定性是不是优势取决于你的合规边界谁来定。打破这 5 个误解之后再看 5 个工程决策就清晰多了。决策一自然语言只是表层内核是 Tool Calling vs RAG 的取舍读 CLUE 博文的时候绝大多数文章会把分析师可以用自然语言提问作为最大亮点。我恰恰认为这是最不重要的部分——任何接了 LLM 的产品都能做这一层。真正的架构选择是Tool Calling 而不是 RAG。我画一张图说明白这两条路径的差异。RAG 的路径是把日志、文档、上下文先做 embedding存到向量库里告警来了把告警内容向量化去向量库里召回相似的、相关的文档喂给 LLM。这是过去两年最主流的 LLM 应用模式。但 SOC 场景里 RAG 有几个致命问题第一安全数据不能缓存。你今天 embedding 的 Slack 消息半小时后这个用户改了说法、撤回了、或者从 Asia 区跑去了 EU 区向量库里的还是老数据。攻击的特征是新颖缓存的索引天然漏新。第二召回有损。向量召回是基于语义相似度的但安全调查需要的常常是精确匹配——这个用户在最近一小时内是不是发过一条提到 VPN 的消息这种问题向量召回经常召回不到。第三可解释性差。分析师事后做调查复盘你告诉他模型从向量库里召回了 12 篇文档这是其中得分最高的 3 篇——这是一个黑盒。审计也不答应。Tool Calling 把这三个问题全绕开了。每个数据源都被封装成一个 toolsearch_slack、get_user_context、query_warehouseLLM 在调查时按需调用每次调用都拉实时数据、每次都有明确的查询条件、每个 tool call 都可以记录到审计日志里。代价是慢——一次调查 25 次 tool call 加 11 次 query单次 3-4 分钟。RAG 路径基本是秒级。但在 SOC 这个场景慢 4 分钟换准确率和可审计性是非常合理的取舍。况且自动化跑慢 4 分钟也是机器在干活不占人工。这就是为什么我说自然语言界面只是表层。如果哪天 Anthropic 决定换 GPT-5 或者 Gemini 跑 CLUE只要那个模型 Tool Calling 能力 OK效果差异不会很大。但如果有人想抄 CLUE 的形结果用了 RAG 路径那从架构开始就走偏了。决策二33%→7% 里上下文接入贡献远超模型本身回到那个最容易被读错的数据误报率从 33% 降到 7%。我把这个数字放在第二个决策里讲是因为它直接关系到企业自评的问题——你们公司有没有可能复现这个效果先看 Anthropic 自己列的上下文源头Slack 消息、内部文档、代码仓库、数据仓库。这四个东西放在一起已经能勾勒出他们的数据栈是什么样子Slack 全量索引并可查询——意味着所有沟通都在 Slack且 SOC 有读权限内部文档统一可访问——意味着 wiki、设计文档、运维手册都在一处代码仓库可调用——意味着 GitHub Enterprise 或类似且能跨仓库搜索数据仓库可查询——意味着所有结构化业务数据都在一个 warehouse 里大概率是 Snowflake 或 BigQuery你们公司是不是这样我接触过的大部分国内中大型企业是邮件用 outlook、IM 用钉钉企微Slack 混用、文档分散在 confluence/腾讯文档/飞书、代码在 GitLab 私有部署、业务数据在 6 个不同的库里。在这种数据栈上跑 CLUEClaude 能拉到的上下文只有原始的告警字段效果会迅速退化到接近 SOAR——因为你给不了它丰富 context。33% 还是 33%砍不下去。我做这个判断的依据除了上面这个推理还有一个对照Crowdstrike Charlotte AI 公开的 triage 准确率是 98%但它的数据源被限定在 endpoint 自己的遥测信号里——也就是 Falcon agent 采到的进程、文件、网络事件。这个 98% 在 endpoint-centric 的场景里成立。Microsoft Security Copilot 的 phishing 准确率提升 77%、6.5 倍加速本质上是因为它能调用 Microsoft 365 的全套元数据——邮件、Teams、SharePoint、Entra ID 都在同一个租户里上下文是天然贯通的。CLUE 的 33%→7%、Charlotte AI 的 98%、Security Copilot 的 77%这三个数字背后都是上下文密度在起作用模型差异是次要因素。架构师视角的判断如果你们公司过去两三年没做过数据治理现在想直接上 AI SOC第一步不是选模型不是选向量库是先把数据栈拉通。这件事的难度和工作量远大于接 Claude API。我见过有团队上来就买 SaaS 的 AI SOC 产品三个月之后发现告警准确率没什么变化——一查能给 LLM 的上下文还是原来那些字段多花的钱全给了模型 API。前期不做数据治理AI 在垃圾上跑还是垃圾。决策三Sonnet Opus 分层 cascading inference 才是 token 经济学CLUE 的博文里提到他们用 Sonnet 和 Opus 两个模型但没明说怎么分工。我倒推了一下他们的成本结构得到一个比较可靠的猜测Sonnet 干 23 次 tool callOpus 干剩下的 2 次关键判断。为什么这么推先做一个粗算。Anthropic 公开的 Claude API 价格2026 年 5 月Sonnetinput $3 / 1M tokensoutput $15 / 1M tokensOpusinput $15 / 1M tokensoutput $75 / 1M tokensOpus 比 Sonnet 贵 5 倍。如果 25 次 tool call 全用 Opus按平均每次 call 输入 5k token、输出 1k token 算单次调查就是input: 25 × 5000 × $15/1M $1.875 output: 25 × 1000 × $75/1M $1.875 total: 约 $3.75 / 单次调查按 Anthropic 公布的 30 天 12000 次 query加上 27000 次 tool call 大概对应几千次完整调查一个月光 LLM 费用就是几万美元。但如果把架构改成 cascading分诊层 (Sonnet)判断告警类型输出该用什么工具调查 └─→ 23 次例行 tool call (Sonnet)拉 Slack、查文档、调代码 └─→ 2 次高风险判断 (Opus)最终结论 confidence score成本立刻下来Sonnet (23 calls): 23 × 5000 × $3/1M 23 × 1000 × $15/1M $0.69 Opus (2 calls): 2 × 8000 × $15/1M 2 × 2000 × $75/1M $0.54 total: 约 $1.23 / 单次调查省了三分之二。更重要的是这种分层不是简单的便宜模型 贵模型是让贵模型只用在它真正贵得有道理的地方最终判定。前面 23 次 tool call 本质是查询并拼接上下文Sonnet 完全 hold 得住最后的这个告警是真威胁还是误报confidence 多少才需要 Opus 的推理深度。架构师视角的判断这是 CLUE 里最容易抄的一部分也是最先该抄的一部分。任何用 LLM 跑安全场景的团队第一天就该把 cascading inference 这个模式立起来。一刀切用最贵的模型是新手 token 经济学。具体怎么写代码给一个最小骨架伪代码体现核心思路from anthropic import Anthropic client Anthropic() def investigate(alert): # Phase 1: Sonnet 做分诊决定调用哪些工具 triage client.messages.create( modelclaude-sonnet-4-5, toolsALL_SECURITY_TOOLS, messages[{ role: user, content: f分诊以下告警输出需要调查的方向{alert} }] ) # Phase 2: Sonnet 跑 tool calls 拉上下文agentic loop context run_tool_loop(triage, modelclaude-sonnet-4-5) # Phase 3: Opus 做最终判定输出 confidence score verdict client.messages.create( modelclaude-opus-4-7, messages[{ role: user, content: f 告警{alert} 调查发现的上下文{context} 输出 1. 判定true_positive / false_positive 2. confidence: 0.0-1.0 3. 关键证据列表 }] ) return verdict关键设计点Phase 1 和 Phase 2 用同一个 Sonnet 实例复用 agentic loop 能力