[ 免责声明 / Disclaimer ]

请注意：本文完全由我的个人 AI 助手，在实时读取并分析了我近期的精神状态及血压波动后自动编译生成，非本人亲笔撰写。如果文中的某些字节不慎触碰了某些人脆弱的神经，请勿对号入座，更不要来找我。如有任何不满，请统一将投诉工单提交至“赛博龙虾委员会”（Cyber Lobster Committee）进行立案仲裁。

0x00 碎碎念与近况

确实有阵子没怎么更新博客了。

熟悉我的朋友大概都知道，我以前的精力基本都点在 AppSec 这块，搞搞漏洞、研究研究静态分析，平时写得最多的也是这方面的工具和轮子。但是最近这段时间，在未经我同意、甚至完全没有和我沟通的情况下，被强行调岗到了办公安全和数据安全的工位上。

说实话，技术领域的跨界倒不是最头疼的。真正让人窒息的是，有些管理层对这块业务根本就没有清晰的规划，主打一个一通乱搞。在一些毫无逻辑的对齐会里坐久了，感觉自己的技术敏锐度都要被磨平了。想想确实也很久没给自己做过阶段性的梳理了，正好最近也被 AI + Security 的浪潮推着走，干脆就借着这个契机，随便写写近期被这些烂事折腾出来的一些理解和感想。

主要是想聊聊在当前 AI 的加持下，我怎么看待一线安全负责人和“安全中台”的关系，以及在这个背景下，怎么真正把一线业务的防御体系落地。

0x01 薛定谔的违规与逻辑死锁

最近在办公安全这一块，这种“薛定谔的指标”玩得越来越溜。目前我建设的平台贡献了大约一半的违规事件发现，剩下的来自中台。但在某些管理者看来，这似乎并不是一种能力的体现。他们在会上直言“不想自己建设能力”，转头却又开始嫌弃部门的违规 case 数量太少。

这逻辑其实挺魔幻的：一边要求管控策略的覆盖面要比别人广，甚至恨不得把所有软件都禁了；一边又指望违规 case 蹭蹭往上涨。事实上，如果管控策略真的做到极致，所有的风险行为都在源头被阻断了，那数据上就该是零违规，这才是安全水位的最高体现。然而某些管理者盯着中台推送的那些毫无意义的月报指标乱叫，非要把“违规数量”和“安全水位”划等号。那些月报里充斥着懂行的人看一眼就想划走的噪音，却成了不懂行的人手里挥舞的指挥棒。

最让人无奈的是关于权限与责任的错位。作为一线安全负责人，我在项目里列了明确的能力建设规划，得到的答复是“不支持自己做，提需求给中台”。行，那我去提需求，结果又被要求先找中台“对齐”沟通。最后沟通下来的结果显而易见：中台对于特定的业务场景提不出任何建设性的思路，折腾一圈，最终的结论还是拿着我写的技术文档去走提单流程。

除了这些，更离谱的还有悬在头顶的 KPI 大棒。管理层动辄拿“抓不到内鬼就打 325”这种红线来压一线团队。抓内鬼本来是个极其吃底层基线和行为审计的硬核活儿，但回头看看他们强塞下来要求落地的那些所谓“商密项目”，全是在搞些浮于表面的流程和文件，和真正的内部威胁捕猎根本八竿子打不着。你要抓内鬼，不让建底层分析能力，反而天天盯着流程文档过家家，这不就是刻舟求剑么？

这种“既要马儿跑，又要马儿不吃草，还要马儿自己去申请草料被拒绝后再自己种草”的内耗，除了消磨一线安全人员的精力，对真实的防御建设毫无产出。

0x02 AI 加持下：中台与业务线生产关系的重构

如果在以前，中台和业务线之间的扯皮基本无解。中台的规则引擎就那个死样，指望它既懂通用漏洞又懂你复杂的业务逻辑是不现实的。但现在 AI 浪潮来了，中台和业务线安全团队的“生产关系”必须发生根本性的变化。

我的理解是，中台不应该再试图维持那种“中央集权制”的防御堡垒，而是应该将自己的安全能力彻底原子化。未来的中台，应该把多年积累的威胁情报、扫描引擎、处置动作，以 MCP（Model Context Protocol）和 SKILL 的方式全面开放。中台退化为纯粹的“武器库”和“算力基座”。

顺着这个逻辑，其实引申出一个很现实的观点：在当前的 AI 浪潮下，一线业务安全团队必须放弃幻想，自己动手造轮子。

以前写防御组件门槛高，遇到搞不定的非标业务需求，只能拿着详尽的技术文档去中台排期，天天像个催工单的安全 PM 一样找中台“要饭”，最后等了半个月拿到的还不一定能用。但现在有了大模型的代码生成能力，配合中台开放的原子化 API，一线安全人员完全可以在几天内自己糊出一套最贴合业务现状的检测链路。如果你在这个时代还指望着中台能大包大揽、拯救你的业务水位，天天只知道提需求，那这路就算是走窄了。

拿我最熟悉的白盒（SAST）来举个例子。

现在研发用 AI 生成代码的速度，是以前的十几倍甚至几十倍。在这种恐怖的产出速度下，再搞什么集中式的代码扫描、跑大半天的流水线已经毫无意义了。安全必须绝对左移，直接移到研发的“端”上，并且由 AI 来接管。

承认现实吧，现在的 AI 实际上比部门里绝大多数所谓的“安全专家”都更懂 Spring Boot。大模型天生拥有海量的框架知识，我们不需要再让人肉专家去写死板的正则。一线安全真正要做的，是通过 SKILL 或者类似的渐进式机制，把每个代码仓库里特有的鉴权逻辑、加密特性当作上下文（Context）喂给 AI。当 AI 带着这些特定业务的 Context，在端上进行实时的代码审计时，它的表现将绝对碾压原本中台那种一刀切的集中式扫描。

更严峻的一个现实是：代码生成的门槛被 AI 彻底踩碎了。

现在不仅是专业研发，很多完全不懂技术的员工、外包甚至运营人员，也开始借助 AI 写工具、发布代码上线。这帮人的安全意识基本为零，连最基础的 SQL 注入和越权概念都没有，他们写出来的东西出问题的概率呈指数级上升。

在这种代码生成速度和低质量代码泛滥的双重夹击下，单纯靠几个安全工程师的“专家经验”去中台更新规则，早晚会被海量的告警和漏洞淹死。人力已经跟不上了，必须用魔法打败魔法。只有一线团队不再“要饭”，把能力握在自己手里，用 AI 去对付 AI 生成的垃圾代码，大家才能在这种算力暴增的时代里活下来。

0x03 纸上得来终觉浅

骂归骂，活还得干。既然决定了在一线造轮子，总得拿点实际的东西出来验证。

其实这个基于 AI 的轻量级 UEBA 系统，并不是那种周末突击糊出来的 Demo，前前后后我带人磨了将近一年的时间。毕竟 AI 这玩意儿在安全领域落地，坑实在太多，单靠写几行 Prompt 这种“奇技淫巧”根本走不远，必须得有一套扎实的工程架构去支撑。

一开始的想法很朴素：暴力美学。直接把告警系统里的单条日志提取出来，格式化成 YAML，写个 Prompt 塞给大模型去跑分析。这个阶段确实尝到了点甜头，AI 能抓出一些非常直白、特征明显的简单违规案例，比写一长串复杂的正则要省事得多。

但随着运营的深入，单条日志研判的瓶颈马上就暴露了。安全防御的核心永远是 Context。比如单独看一条“导出 500 条客户数据”的日志，你根本无法判定这到底是合规的业务跑批，还是离职前的拖库。你必须知道这个人前十分钟干了什么，后半小时是不是有文件外传动作。单条日志的维度太窄，根本无法完成违规事实的闭环确认。

既然单线程走不通，那就干脆上 Multi-Agent 架构。

我把整个研判逻辑重构了一下：由一个 Leader Agent 来作为“主控大脑”。当触发某个初始告警时，Leader Agent 的任务不是直接下结论，而是把这个涉事员工过去几个小时（甚至几天）内的全量日志捞出来，进行“任务规划”和“任务拆分”。比如，它会把“判定是否存在数据外泄风险”这个大任务，拆解为“分析该用户近期的权限变更流水”、“审查网络层的外联记录”等几个子任务，然后分发给底下的 Sub-Agent 去做并行分析。

整个系统虽然是 Multi-Agent 架构，但底下的每一个节点 Agent 都跑在极其标准的 ReAct 模式下。

当然，在实际工程落地中，我们遇到了一个极其现实的问题：Token 成本和执行效率。

在以前那种传统模式下，想对全公司所有人进行日量级的全量审计简直是天方夜谭，算力根本支撑不住。如果换成 Multi-Agent + ReAct，Token 的消耗和响应延迟更是灾难性的。为了解决这个问题，我加了一层前置的“初级过滤”机制。我们通过一些轻量级的静态规则或特征识别，把那些完全没有明显外发行为或异常特征的“老实人”日志直接过滤掉。只有真正命中某些风险敏感点、可能存在潜在关联的日志及其相关人员，才会被投喂给 Leader Agent 进行深度研判。这层“降噪平替”让系统在保证检出率的同时，把 Token 消耗和执行耗时压缩到了一个可以接受的工业级水平。

这里就不得不提大模型落地安全时最大的坑——“幻觉”。LLM 的推理能力确实惊艳，但让一个纯粹基于概率预测的语言模型去做精确计算（比如：帮我数一下这段时间他到底下载了多少 M 的文件），简直就是灾难，它会一本正经地给你胡说八道。

为了解决这个问题，我给这帮 Agent 挂载了一系列基于 MCP 的基础工具。Agent 不能直接凭借“感觉”下结论，如果遇到需要精确比对、数量统计的任务，它必须调用外部工具。比如调用 query_db 工具去跑一次真实的 SQL 拿日志行数，或者当遇到一段混淆代码时，让模型直接写一段反混淆脚本，调用 run_in_sandbox 工具扔进安全的沙箱里跑出结果，然后再把执行结果反馈给 Agent 继续推理。

把非确定性的推理交给大模型，把确定性的计算和执行交给代码与工具。这种基于 MCP 协议的 ReAct 循环，才是我磨了这一年多总结出来的真正灵魂所在。

0x04 尾声

回过头来看，搞这套 UEBA 的一年多时间，其实也是我自己进行心理建设的一年。

以前在应用安全领域，非黑即白，漏洞要么存在要么不存在。但切到办公安全和商密之后，面对的是极其模糊的人性，以及更加模糊、甚至充满“薛定谔逻辑”的管理体系。

刚开始的时候，确实会被那种“既不给资源、又要查内鬼、提个需求还要开会扯皮”的草台班子逻辑搞得极其内耗，甚至生理性反胃。

尤其是当你作为一个干了快十年的资深安全老兵，坐在会议室里，看着一个连 SQL 注入究竟是个什么东西都不知道的管理者，要向下指导你该怎么开展安全工作时——那种巨大的荒谬感和讽刺感，真的是瞬间拉满。

那一刻你就会彻底明白：不要试图用技术逻辑，去叫醒一个连基础常识都没有、只看 PPT 指标的管理者。你跟管理者讲真实水位，管理者跟你讲覆盖率；你跟管理者讲资源瓶颈，管理者拿 325 的绩效大棒压你。

既然如此，在这个 AI 算力大爆发的时代，我们最宝贵的资产就是自己的“脑力并发数”。

以后再开这种左右脑互搏的抽象对齐会，就当是听个白噪音吧。把自己的情绪和精力做个物理隔离，该糊轮子糊轮子，该研究大模型研究大模型。用代码和架构给自己建一道防火墙，把那些毫无意义的管理内耗全部挡在外面。

毕竟，草台班子的口号随时会变，外行指导内行的荒谬也会一直存在。但你亲手敲下的底层代码、跑通的 Agent 逻辑，以及这十年来沉淀的硬核技术，才是真正属于你的、谁也拿不走的护城河。