本文基于笔者在安全告警研判系统中的实践经验，聊聊把 LLM 和 Agent 引入安全运营后踩过的坑、想明白的事。不是教程，单纯个人思考、发现，希望对你有启迪。

先说结论

• • 用 LLM 做安全运营，我经历了三个阶段：代笔期（LLM 帮写代码）、共生期（代码调用 LLM 自动生成规则）、自主期（Agent 自主分析告警）。共生期效果最好，自主期太不可控。
• • 能不能落地，关键看一件事：你能不能用代码来校验 LLM 的产出？ 能校验的场景就大胆上，不能的就别指望它全自主。
• • 想约束 Agent 的行为，用代码，别用 Prompt。能用规则判定的，尽可能内化为规则。Prompt 里写一百遍「不许」、「应当」，不如代码层面来的实在。
• • Agent 最有价值的定位不是「永远在线的分析师」，而是「规则的自动化生产者」——和人运营一样，它的成功标志就是让自己要分析的case越来越少。
• 下面具体展开讲讲～

一、用 LLM 做安全运营的三个阶段

在安全运营中引入 LLM，我经历了三个阶段，每个阶段对 LLM 的定位完全不同：

这三个阶段不是替代关系，而是叠加关系——做到第三阶段，你仍然需要前两个阶段的能力作为基础。

代笔期：用 LLM 帮你写代码

用 Copilot、Claude 这类工具写代码，效率提升实实在在，一个人能干三个人的活。

拿我做的告警研判系统来说，规则引擎、数据库交互、API 对接这些模块，大量借助了 LLM 完成。整个规则引擎（支持 IP 匹配、关键词匹配、频率检测、威胁情报联动等十几种条件类型）加上配套的 YAML 规则配置体系，一个人半天就写完了，以前可能得一两周。

但本质没有变化——LLM 只是个更高效的 IDE 插件。你不提需求它不动，你不审代码它不知道对不对。

加速编码，但不改变运营模式。

共生期：代码调用 LLM，让系统学会自我进化

真正有意思的变化从第二阶段开始——LLM 不再只是开发阶段的工具，而是运行时系统的一部分。

安全运营有个核心痛点：告警类型千变万化，人工写规则永远追不上新模式。某天出现 20 条新告警，全是爬虫遍历金融接口参数导致的。你需要写一条规则来自动处理这类场景——条件要精确覆盖这 20 条，又不能误伤正常告警。手工写，半天起步。

于是我做了一个叫 rule_iterate 的模块。它是一个手写的 ReAct 模式状态机——执行路径由代码严格控制，LLM 只在「生成规则」和「反思原因」两个节点被调用，不会跑偏。

它的工作方式是这样的：

输入: 20 条待覆盖的告警样本（goodcase） + 不能误伤的样本（badcase）Step 1: LLM 分析 20 条告警的共性，生成一条候选规则Step 2: 代码拿这条规则去跑所有 goodcase，看覆盖率是不是 100%Step 3: 没覆盖的，LLM 反思为什么，再补一条规则Step 4: 循环……直到 100% 覆盖 goodcase 且 0% 命中 badcase输出: 一份可直接使用的 YAML 规则文件

关键在于：LLM 负责「想」，代码负责「验」。 规则好不好，不靠 LLM 自己说，靠代码在真实数据上跑一遍来判断。迭代该不该继续，也不靠 LLM 来决定，靠覆盖率指标说话。LLM 的每一次输出都会被代码「检验」，不合格就打回重来。

跑一次实际的 rule_iterate，你就能直观感受到这个「想-验-改」的循环是怎么运作的。下面是一次真实运行的缩影（7 条爬虫告警作为 goodcase，34 条其他类型告警作为 badcase）：

第 1 轮：LLM 生成初始规则  LLM 分析 7 条告警的共性，生成了一条 6 个条件的规则  代码验证 → goodcase 覆盖率 0/7 = 0%（param_pattern 条件过严，全部未命中）  LLM 反思：「条件设置过于严格，未能涵盖这些事件的特征」  决策 → 生成补充规则第 2 轮：LLM 放宽条件，生成补充规则  LLM 移除了过严的 param_pattern 条件，保留核心特征  代码验证 → goodcase 覆盖率 7/7 = 100%   但 badcase 命中了 5 条！（都是「爬虫-新闻接口」类型，特征太相似）  决策 → 进入第二阶段，修正规则以规避 badcase第 3 轮：LLM 重新收紧，精确区分  LLM 分析 goodcase 和 badcase 的差异，把两条规则合并  重新加回 param_pattern 作为区分条件——这是 goodcase 独有的特征  代码验证 → badcase 命中 0/34 = 0%   风险评估 → 整体风险: low，建议: approve  输出 → 生成 YAML 规则文件，耗时约 40 秒

整个过程很有意思：LLM 先放得太松（覆盖不了），再放得太宽（误伤别人），最后在代码的反复校验下找到了精确的平衡点。它不是一次就做对的，而是在确定性指标的约束下，被「逼」着一步步做对的。

这个模式效果很好——产出稳定，质量可量化，每轮迭代的覆盖率变化都有迹可循。

自主期：让 Agent 主动发现问题——踩了坑

理想中的第三阶段是：Agent 自己巡检运营数据，发现聚集性事件，自动触发 rule_iterate 生成规则。

我做了一个尝试：基于 claude-agent-sdk 做了一个叫 secops-analyzer 的 Agent。和 rule_iterate 不同，它是一个黑盒 Agent，基于Skills——你通过 Skills（一份描述分析流程和约束的文档）告诉它「你是一个安全分析师」，然后把告警丢给它，它自主决定查什么数据、怎么分析、给什么结论。你不控制它的执行路径，LLM 自己驱动整个过程。

效果不好。核心问题两个：

一是 结果不收敛。明明日志数据已经足够判定是爬虫了，它还要去查威胁情报、查历史告警、查资产信息，越查越发散，结论反而更模糊。

二是 约束不住它。我在 Skills 里写了「绝对不允许创建新脚本，只能调用现有工具」，用了加粗、emoji、各种强调。结果呢？它还是自己创建脚本来「辅助分析」。它不是不理解你的约束，而是在具体执行中，「写个脚本跑一下」对它来说是更顺手的做法——你的约束在上下文变长之后就被「遗忘」或者「变通绕过」了。或者说，这里的主要问题是，它对我来说，是黑盒的。我不知道它是怎么想的，这让我有种不安全感。

二、回头看，想明白了什么

踩完坑回头看，我发现了一个贯穿三个阶段的规律。

确定性校验才是锚

这三个阶段能不能落地，关键不在于 LLM 多聪明、Agent 自主性多高，而在于一个容易被忽略的问题：

你能不能为 LLM 的产出，建立一套确定性的校验机制？

rule_iterate 之所以好使，是因为它的场景天然带有确定性指标——覆盖率 100%、误报率 0%。这是二值判断，LLM 再怎么发散，最后都被这个硬指标拉回来。

secops-analyzer 之所以效果差，是因为「这个告警到底是爬虫还是攻击」本身就是模糊的，连人工分析师之间都可能有分歧。没有硬性的校验标准，Agent 的发散就没有锚点。

推广一下：想用 LLM 自动化任何场景之前，先问自己——LLM 的产出，你能用代码判断对不对？能，就大胆上；不能，那 LLM 就只是个「提建议的助手」，别指望它完全自主。

能用代码管住的事，别指望 Prompt

顺着想下去，还有一个更实际的教训：我们到底应该用代码来约束 Agent，还是用 Prompt 来约束？

我的体感是，这两者完全不是一个量级的东西。

rule_iterate 的约束全在代码里——状态机控制执行路径、覆盖率决定是否继续、最大迭代次数到了就停。这些约束 LLM 绕不过去，因为它压根接触不到控制逻辑。

secops-analyzer 的约束全在 Prompt 里——Skills 文档里的「不许创建脚本」「只能调用指定工具」。这些约束本质上是自然语言级别的「拜托」，LLM 随时可以「例外处理」。

能用代码控制的——Agent 能调什么工具、输出格式是什么、什么时候该停——绝对不要用 Prompt 去拜托它。Prompt 适合做软引导（分析思路、关注重点），硬约束必须交给代码。

这个点，其实和yhy有篇文章里提到的，我们应该更多的去用黑盒Agent还是可控的手搓Agent的思考有点相通写了很多 Agent 之后，我重新思考了一件事：我们到底在“造什么样的 Agent”？。在我这个场景，我还是希望他是可控的。不过，在类似bas的场景，我更希望它是完全不可控的，只给目标，手法不限的持续攻击。

三、最有价值的发现：好的 Agent 会让自己变得不再被需要

聊完了坑和教训，说说我觉得这个项目里最值得分享的一个设计。

整个系统形成了这样一个闭环：

告警涌入  → 规则引擎处理（确定性判定，不需要 LLM）  → 没命中规则的告警，交给 Agent 分析  → Agent 分析结果足够好的那些  → 通过 rule_iterate 固化为新的确定性规则  → 下次同类告警，直接被规则处理，不再需要 Agent

Agent 每成功分析一类场景，就把自己的「理解」蒸馏成一条确定性规则。从此以后，这类告警就不再需要 Agent 了。

这是一个「Agent 把自己炼没」的过程。

换个角度想，这其实就是一个从不确定到确定的过程。LLM 擅长处理模糊的、没见过的信息，但它的最终交付物应该是确定性的东西——规则、代码、策略。把不确定变成确定，然后用确定性去覆盖更多的不确定性，这才是 LLM 在运营场景中最有价值的定位。

实际效果也印证了这一点：项目初期规则覆盖率 0%，每条告警都要人工看；引入规则引擎后覆盖率到了 60%；rule_iterate 持续跑了一段时间后，覆盖率到了 80% 以上。需要 Agent 介入的告警越来越少，成本在降，可控性在升。

Agent 的成功指标不是「它处理了多少告警」，而是「它让多少告警不再需要它处理」。

我觉得这个思路不只适用于安全运营，任何运营场景可能都可以参考——让 LLM 做「规则的自动化生产者」，而不是做「永远在线的分析师」。

四、一个发散的思考：怎么管理一个「全职 Agent」？

最近 OpenClaw 很火，我琢磨了一下它和 Claude Code 这类工具的区别，想到了一些有意思的事，顺便聊聊。

起因

我在想一个具体的问题：如果我想让 Claude Code 主动去翻运营数据——看看最近哪类告警积压最多、现有规则有没有覆盖不足的地方——然后自己写代码来优化流程，技术上其实是可行的。

但问题是：怎么让它主动触发这个流程？ Claude Code 本质上是「你说它做」，你不说它就不动。

OpenClaw 不一样。你可以给它设定时任务、它可以主动发起操作、可以持续跟进一件事。这就像一个「全职员工」和一个「按需请的顾问」的区别——顾问你不叫他他不来，员工可以自己琢磨事情。

但全职员工也有风险

最近各种视频展示了 OpenClaw 的翻车场景——自行删除使用者的邮件、擅自操作文件等。这让我联想到一件事：如果把这类持续运行的 Agent 当作「员工」，是不是可以借用公司管理员工的经验来管理它？

比如：

• • 权限管控——员工不能直接动生产数据库，Agent 也不该有这个权限
• • 审批流程——重大操作需要上级审批，Agent 的高风险操作也应该有审批
• • 操作审计——关键操作有日志可追溯
• • 试用期——新 Agent 先在沙箱里跑，稳了再上生产

但这个类比也有边界

员工不删库，不是因为技术上做不到，而是因为社会后果太严重——会被开除、会被追责。Agent 没有这层约束，它不会「害怕」任何后果。所以对 Agent 的约束必须是硬性的、代码级别的，不能指望它「自觉」。

还有一点：你可以随着时间逐步信任一个员工——他连续三个月表现好，你自然放心给他更多权限。但 Agent 不一样，今天分析得好不代表明天换个数据分布还行。对 Agent 的信任，不能像信任员工一样线性累积。 每一步放权都必须有代码级别的校验兜底。

这些想法还没有结论，但我觉得，随着持续运行的 Agent 越来越多，「如何管理 Agent」可能真会变成一个和「如何管理团队」同等重要的课题。

五、几条实在的建议

1. 1. 先做好共生期，再想自主期。 代码调用 LLM、用状态机约束执行路径，已经能解决大部分自动化需求，而且可控、可追溯。自主期（Agent 全自主）当前更适合做辅助，不适合做主力。
2. 2. 先找确定性指标，再引入 LLM。 想自动化的场景，先问：LLM 的产出能用代码校验吗？能，就先做。不能，就慎做。
3. 3. 能用代码管住的事，别指望 Prompt。 工具白名单、输出格式校验、迭代终止条件——全部用代码实现。Prompt 只做分析思路引导。
4. 4. 让 Agent 做「规则生产者」，而不是「分析师」。 成功指标不是「处理了多少告警」，而是「产出了多少可用规则、让多少场景不再需要 Agent」。
5. 5. 渐进放权，每步都要有兜底。 先 Agent 建议人执行，再 Agent 执行人抽检，最后 Agent 执行 Agent 校验。每一步放权，都要有对应的确定性校验机制。

本文基于 RCA Handler 项目实践。该项目使用 Python + ReAct 模式 + claude-agent-sdk 构建安全告警研判系统，实现了从自动入库、规则匹配、Agent 分析到规则自动迭代的完整闭环。