君哥的体历

多次获奖到商业化落地：「曜鉴」率先跨过安全智能体落地门槛

Mon, 31 Aug 2026 08:00:00 +0800

专注安全运营的 2026-08-31 08:00 北京

近日，在中国网络安全产业联盟（CCIA）举办的2026年网络安全优秀创新成果大赛中，知其安旗下AI for Security产品「曜鉴」获得“CCIA 2026 AI创新产品优胜奖”。

这并不是「曜鉴」第一次获得行业认可。此前，「曜鉴」还曾获得第十五届中国创新创业大赛北京赛区新一代信息技术行业赛三等奖等多个奖项。

连续获奖，说明产品的技术路线、创新能力和应用价值正在得到更多行业专家认可。但对一款企业级安全产品而言，奖项只是观察产品价值的一个切面。

更值得关注的是，「曜鉴」已经完成国内告警研判智能体的商业化落地，先后在国有大型商业银行、全国性股份制商业银行、头部券商以及民营高端制造企业等客户侧形成真实采购和落地，而不是只停留在概念验证或测试阶段。

这在当前的AI for Security市场中并不常见。过去两年，几乎所有安全厂商都在讨论大模型和智能体。但真正进入客户现网、接入真实告警队列，并成为日常安全运营流程一部分的产品仍然有限。

这也引出一个更值得分析的问题：

为什么是「曜鉴」？为什么它能够从连续获奖走向真实落地，并跨过安全智能体从测试到采购、从演示到生产的门槛？

安全智能体的分水岭，不是“能不能回答”，而是“能不能接管真实任务”

在测试环境中验证一个安全智能体并不困难。

给模型一条告警、一段日志或一个攻击样本，它通常可以解释字段含义、识别可疑行为，并生成一份结构完整的分析报告。

但企业真正决定采购时，关注的并不是一次演示是否足够惊艳，而是产品能否回答更加现实的问题：

能否接入现有SOC、SIEM、EDR、NDR、威胁情报、资产和身份系统；
能否在真实告警量和复杂数据环境下持续运行；
能否通过实际查询和证据验证形成结论，而不是依赖模型猜测；
能否解释为什么将一条告警判定为威胁或非威胁；
能否在数据权限、工具调用、人工审批和审计边界内工作；
能否用研判效率、降噪效果、证据完整度和人工复核结果证明业务价值。

这意味着，安全智能体从测试走向落地，不只是模型能力提升的问题，而是一项完整的系统工程。

一个能够解释安全知识的模型，可以成为助手；只有一个能够持续处理真实任务、稳定输出安全结论，并对全过程留痕的系统，才可能成为企业愿意采购的生产工具。

安全智能体的商业化分水岭，不在于模型能回答多少问题，而在于甲方是否愿意把真实告警队列交给它。

第一个原因

曜鉴选择了一个足够高频，也足够接近业务结果的问题

过去十几年，企业持续建设防火墙、EDR、NDR、SIEM、邮件安全和威胁情报等系统，安全团队能够看见的异常行为越来越多，产生的告警数量也越来越大。

但告警只是检测规则、模型或策略命中后的信号，并不天然等于真实威胁。

一条高危告警可能来自正常运维操作；一条看似低危的异常连接，也可能是完整攻击链中的关键一步。安全设备可以发现局部异常，却很难单独回答：它是不是一次真实攻击、影响了哪些资产、是否需要立即处置。

因此，分析人员仍然需要在终端、流量、身份、资产、情报和历史告警等多个系统之间反复查询，补齐上下文、还原行为链并形成结论。

当告警量持续增长，真正限制SOC效率的已经不再是“能不能发现异常”，而是企业是否拥有足够多的专业人员，对每条重要告警完成稳定、准确、可复核的调查。

「曜鉴」没有从通用安全问答或报告生成切入，而是直接进入告警分诊、自动研判、证据调查和事件分析等高频安全运营任务。

这类任务有三个特点：

第一，任务量足够大。告警每天都在产生，不是低频、偶发需求。

第二，人工成本足够明确。查询多少系统、单条告警需要多长时间、一线与二线人员投入多少精力，都能够被计算。

第三，结果能够被复核。一条告警最终是威胁、非威胁还是证据不足，可以通过专家复核和后续处置结果进行验证。

因此，「曜鉴」解决的并不是一个抽象的“AI能力问题”，而是甲方安全运营负责人每天都能感受到、也能够衡量投入产出的问题。

第二个原因

它不是在告警后面接一个大模型，而是重建了一次调查过程

告警研判不是把告警字段交给大模型做一次分类。

一条告警本质上只是提出了一个等待验证的假设。以“可疑PowerShell命令执行”为例，它可能是管理员执行的运维脚本，也可能是业务程序正常调用，还可能是攻击者下载恶意载荷、建立持久化或横向移动的起点。

真正的调查需要继续回答：命令由谁执行、父子进程是否正常、是否下载文件、是否产生异常外联、同一账号是否出现在其他资产，以及相关主机能否接触核心业务系统。

这类调查很少按照同一条固定路径展开。每获得一项新证据，都可能改变下一步需要查询的数据和工具。

「曜鉴」所做的，不是让大模型直接猜测结论，而是将安全专家的调查方法拆解为一套可持续运行的智能体流程：

将告警转化为调查任务

系统解析告警类型、涉及主体、资产、行为和初始风险信息，先明确需要验证的核心问题，而不是立即生成“恶意”或“正常”的结论。

补齐资产和业务上下文

「陆吾」为「曜鉴」提供动态资产画像和业务上下文，包括资产归属、业务重要性、账号身份、历史行为、漏洞状态和关联告警等信息。

相同的技术行为发生在普通办公终端和核心生产服务器上，优先级和潜在影响完全不同。缺少这层上下文，模型只能理解告警，无法理解企业。

根据新增证据动态规划调查

「曜鉴」调度终端、流量、威胁情报、身份、资产和日志等安全Skills，对关键假设进行逐项验证。

发现异常外联后继续查询进程，发现进程异常后核验账号，发现账号风险后再反查历史登录和关联资产。调查路径由不断出现的证据推动，而不是机械执行一套固定脚本。

用专业工具验证事实

大模型负责理解任务、规划步骤和组织信息，真实事实仍然来自企业已经部署的安全工具和数据系统。

这使最终结论能够回到具体日志、进程、文件、网络连接、身份记录和资产信息，而不是停留在语言上“看起来合理”。

形成能够复核的证据链

系统按照主体、时间和因果关系关联分散证据，最终输出告警触发原因、涉及主体、资产上下文、行为时间线、关联证据、威胁判断、影响范围和处置建议。

对于证据充分的告警，系统给出明确结论；对于日志缺失、信息冲突或上下文不足的情况，则标记为“证据不足，待人工复核”，而不是为了提高自动研判率强行输出答案。

在授权边界内推动处置

研判结论可以回写现有运营平台或工单流程。涉及终端隔离、账号停用、文件删除等可能影响业务的动作，则需要遵循企业既有的授权策略和人工审批机制。

这套机制可以概括为：

告警触发 → 提出假设 → 补充上下文 → 规划调查 → 工具验证 → 证据关联 → 形成结论 → 人工复核或联动处置

它所解决的，不是“大模型会不会分析告警”，而是AI能否按照企业认可的方式完成一次真实调查。

第三个原因

不要求客户推翻原有体系，而是叠加一支智能研判队伍

大型企业已经在SOC、SIEM、态势感知、终端安全、流量检测、威胁情报和自动化响应等方面投入了大量成本。

如果一款AI产品必须替换现有平台、重新汇聚所有数据，或者改变整个安全运营流程，落地周期和组织阻力都会显著增加。

「曜鉴」选择叠加在现有安全运营体系之上。

现有平台继续负责告警汇聚、规则检测和基础处置；「曜鉴」接收标准化告警，根据场景将任务路由给相应智能体，按需查询现有平台和安全设备中的数据，完成研判后再将结论和证据回写原有流程。

对于客户而言，这种方式有三个直接价值：

不需要否定和替换既有安全建设；
可以从少量高价值场景开始，逐步扩大智能体承担的任务范围；
调查、复核和处置仍然运行在现有责任体系与审批机制之内。

曜鉴整体能力已经覆盖邮件、流量、主机、DLP、API和终端等超过130个安全运营场景，但具体客户会根据自身数据基础、告警结构和优先级选择实际部署范围，并不是将全部场景一次性上线。

这也是企业级AI产品从测试走向生产必须面对的现实：真正可落地的产品，不是能力越多越好，而是能够从一个明确场景开始，用可控方式进入现有工作流，再根据实际效果逐步扩大边界。

第四个原因

把专家经验沉淀为可复制的产品能力，而不是一次性交付

安全运营高度依赖专家经验。

不同告警应该查询哪些数据、哪些证据足以支持结论、证据冲突时如何处理、什么情况下必须升级二线专家，这些方法过去往往分散在个人经验、处置报告和内部文档中。

如果每进入一家客户都需要重新编写全部规则、流程和调查逻辑，智能体最终仍然会变成一个高度依赖项目人员的定制化系统，难以形成规模化交付。

「曜鉴」将调查方法、工具调用、判断规则和处置知识持续沉淀为知识、Skills和场景智能体。

产品进入新客户环境后，需要适配的是客户的数据接口、资产结构、业务基线和授权边界；已经形成的告警理解、调查规划、证据组织和结果输出能力则可以持续复用。

这种“通用调查能力＋行业知识＋客户上下文”的结构，使「曜鉴」能够进入不同类型的客户：

国有大型商业银行和全国性股份制商业银行，更关注海量告警下的研判效率、证据完整性、审计留痕和处置边界；
头部券商需要在高时效运营环境中提升告警分诊和事件调查能力；
民营高端制造企业则更关注有限安全人员下的持续值守，以及安全事件对生产与核心业务的实际影响。

不同行业的业务环境不同，但需要解决的底层问题具有共性：安全数据分散、上下文不足、调查依赖个人经验、告警结论难以稳定生产。

这让产品能够跨行业复制，而不是只能在单一客户环境中完成一次成功测试。

「曜鉴」跨行业落地，客户最终为什么愿意付费？

国内告警研判智能体首单的意义，不只是产生了一份合同。

它意味着甲方第一次愿意将真实告警、真实系统和真实运营流程交给智能体，并按照实际研判结果评价产品，而不是只在隔离测试环境中观察模型表现。

此后，「曜鉴」又进入国有大型商业银行、全国性股份制商业银行、头部券商和民营高端制造企业等不同客户环境，进一步验证了这套能力并非只适用于单一数据结构或单一行业。

在某股份制银行开展的为期一个月的实践中，「曜鉴」接入全量SOC告警，由智能体联动模型、知识库和安全工具，完成上下文补充、调查规划、多源查询、证据关联和告警研判。

实践结果显示：

单条告警研判时间缩短至约20秒；
复杂告警研判时间缩短至约2分钟；
整体告警研判效率提升20倍以上；
告警降噪率达到90%以上；
智能体能够7×24小时持续执行标准化调查。

这些数据回答了企业采购时最核心的三个问题：

第一，智能体能不能真正处理现网告警；

第二，处理结果能不能被安全专家复核；

第三，产品能不能在不增加同等人员投入的情况下持续扩大处理能力。

客户购买的也不只是一个更快的告警分析工具，而是一种新的安全运营产能：智能体承担高频调查，一线人员重点复核，二线专家处理复杂事件并持续优化策略。

连续获奖背后，行业真正认可的是什么？

从CCIA 2026 AI创新产品优胜奖，到中国创新创业大赛北京赛区新一代信息技术行业赛三等奖，「曜鉴」连续获得多个奖项，当然意味着产品在技术创新和产业价值层面获得了外部认可。

但如果将奖项、国内首单和跨行业落地放在一起观察，可以看到更完整的产品验证链条：

奖项，验证的是技术路线和产品创新；
落地，验证的是客户是否愿意为价值付费；
跨行业落地，验证的是产品能否复制和持续运行。

对于仍处在快速发展阶段的AI for Security市场而言，后两项可能比一次模型评测或产品演示更难。

因为安全运营不是一个可以容忍“多数时候正确”的普通办公场景。智能体一旦进入真实SOC，就必须同时面对数据质量、模型不确定性、系统权限、业务连续性、审计责任和处置风险。

它既要提高效率，也要知道自己的边界；既要能够自主调查，也要把关键判断交还给人；既要理解安全技术，也要理解每家企业不同的业务上下文。

「曜鉴」能够率先形成国内首单，并在金融、证券和高端制造等场景继续落地，原因并不是它把大模型接入了更多安全工具，而是它围绕真实任务完成了从模型能力到产品能力、从产品能力到运营能力的转换。

写在最后

AI for Security的下一轮竞争，不会只发生在模型参数、知识问答或演示效果上。

真正的竞争将发生在客户现场：谁能够接入真实数据，谁能够稳定处理真实告警，谁能够让结论回到真实证据，谁又能够在权限和责任边界内持续运行。

从连续获奖，到国内告警研判智能体首单，再到国有大型商业银行、全国性股份制商业银行、头部券商和民营高端制造企业的实际落地，「曜鉴」已经完成了比“证明AI可以做安全运营”更进一步的验证：

AI不仅可以理解安全问题，也可以成为企业持续生产安全结论的一部分。

奖项让产品被看见，首单让市场开始验证它，而真正决定安全智能体未来的，是它能否长期留在客户的生产环境里，对每一条真实告警、每一次真实调查和每一个真实结论负责。

跳转微信打开

代码“不落云”就安全吗？企业AI评审、SRC运营与邮件TLS的现实选择｜总第321周

Mon, 31 Aug 2026 08:00:00 +0800

原创群秘 2026-08-31 08:00 北京

本期周报简介：

1、数据不落云是否等于不出域？TEE的信任根应如何验证？

2、AI挖洞普及后，SRC价值如何量化？企业应自建、众测还是组合运营？

3、邮件TLS应优先保障送达率，还是对重点通信强制加密？

0x1本周话题

话题一：代码“不落云”，是否就等于代码不出域？云端AI参与代码评审时，真正越过边界的是什么？

《代码不出内网，也能用上 AI 智能评审：云效现已支持 GitLab》

A1：仓库虽然仍在企业内部，但云端模型要完成评审，就需要接收与任务相关的代码内容。代码库没有整体迁移到云上，并不等于代码数据没有越过企业边界。

A2：首先要厘清，是企业使用了公有云算力，还是把GitLab部署到了云上？

如果是前者，那问题就是：代码以什么粒度、通过什么链路进入模型，进入后由谁处理、是否留存。

A3：即使企业与服务商签订数据保护协议，并约定代码不用于训练，也只能解决部分管理要求。协议并不能代替对真实数据流、访问权限和日志留存的技术核验。

A4：从责任边界看，PAT由企业提供，Token权限范围由企业选择，Webhook和网络通道也由企业配置。

一旦发生问题，很容易被解释为企业主动授权云端服务访问。因此，安全评估还要看授权链路和责任如何落到合同与配置上。

Q：TEE能否实现“代码可用不可见”？

A5：可以通过TEE等可信执行环境承载模型推理。客户端与TEE内程序加密通信后，服务器运维人员理论上无法直接看到其中的数据，GPU资源也未必必须由单一甲方独占。

A6：这个主要集中于两个边界：

运行的是企业自己部署的模型，
运行的是服务商提供的模型；

服务器运维方看不见，是否意味着模型运维方和日志系统同样看不见。

A7：TEE是否真实启用，也不能仅凭网络另一端的声明来判断。企业需要能够验证运行环境和身份，知道数据在什么位置解密、谁能接触明文，以及所使用的模型和推理服务是否真的完成了适配。

A8：密钥“在客户手里”也不是问题的全部。客户端通信密钥可以由客户控制，但TEE的硬件信任根仍来自芯片或设备体系。

换句话说，TEE并没有消除信任，而是把信任从云平台运维人员转移到了硬件、密钥体系和证明机制。

A9：从技术成熟度看，TEE并不是新概念，真正困难的往往是甲方如何向内部法务、合规和审计解释。

技术上能够隔离，并不代表组织上已经接受；乙方是否完整披露实现方式，也直接影响甲方能否作出判断。

Q：企业最终应该选择哪一种部署方式？

A10：主要有两个方面：

如果在自有IDC中部署开源模型，数据边界最容易说明，但企业需要承担模型能力、算力和运维成本；
如果使用商业API，则可能获得更强的模型能力，但必须要求服务商提供更清晰的隔离、日志、密钥和责任说明。

A11：最终还是要回到可验证的问题：哪些数据会离开内网，哪里会出现明文，哪些角色能够访问，是否记录日志，密钥和信任根由谁掌握，发生事件后责任如何划分？这也是非常值得思考。

话题二：AI挖洞时代，SRC还要不要继续做，部分SRC收缩，是否意味着AI正在取代白帽体系？

《平安PSRC关停背后：大模型“漏洞海啸”与白帽经济的黄昏》

A1：企业关闭或收缩SRC，可能同时受到安全预算、审核成本、业务规模和平台运营压力影响，AI只是加速变化的变量之一。

A2：AI确实正在改变漏洞发现的成本结构。相比长期维持人员和赏金投入，企业可能更愿意购买算力和Token，用内部工具持续审计代码；白帽也在使用AI提高挖洞效率，供需两端都在变化。

A3：SRC处在漏洞治理链条较靠后的环节。漏洞被发现以后，企业仍要投入排查、修复、验证和上线资源。如果AI Coding能够把部分检测和修复前移到编码阶段，企业的关注点就会从“收到多少漏洞”转向“能否在开发过程中减少并闭环漏洞”。

Q：SRC的价值为什么越来越难衡量？

A4：SRC运营中，大量精力可能消耗在低价值或重复报告上，真正能够威胁业务的严重漏洞并不多。但一年收到少数高价值漏洞，对企业可能非常重要；困难在于，个位数成果很难用常规报表和趋势图呈现。

A5：如果管理者理解安全，一年发现一个真正影响业务的漏洞，也可能被认为有价值。更现实的做法，是尝试把漏洞影响映射到业务损失、攻击路径和修复成本，而不是只统计报告数量。

A6：“同样的投入，SRC和AI哪个产出更高”并不是一个完整的比较。SRC、AI工具和正式安全人员承担的角色不同：SRC提供外部发现渠道，AI提高自动化能力，内部人员则负责确认、修复和推动业务闭环。

Q：不同规模的企业，应该采用什么运营模式？

A7：对于规模较小的企业，自建SRC除了奖金，还需要持续投入审核和运营人员，固定成本可能高于实际发放的奖励。在这种情况下，接入第三方众测平台可能更符合投入产出。

A8：对于已经具备SRC体系的企业，AI更像能力增强而不是简单替代：它可以提升内部代码审计和漏洞发现效率，但新增结果越多，越需要完善确认、修复、复测和责任跟踪。

A9：白帽同样会使用AI，因此AI并不会让外部研究者自动失去价值。它可能改变的是报告数量、质量分布和激励方式，企业需要相应调整准入、审核和奖励机制。

A10：SRC还有一个容易被忽视的作用：它是面向外部研究者和用户的安全沟通窗口。平台是否存在、响应是否及时，也会影响外界对企业安全投入的判断。

A11：因此，问题不应该只用“保留还是关停”解决。更合理的判断是：企业能否承担自建运营成本，是否存在足够的外部研究价值，内部是否具备漏洞闭环能力，以及众测、AI工具和自建SRC应当如何组合。

话题三：邮件网关启用TLS，如何平衡加密效果与邮件送达，客户端已经加密，企业邮件在互联网上还可能明文传输吗？

A1：邮件客户端到我们公司的邮件服务器的通信已经加密，但我们公司邮件服务器到外部企业邮件服务器之间还没启用TLS，主要目标是降低互联网链路被监听的风险。

A2：一种可行配置是在邮件网关上优先协商TLS。对方网关支持时使用加密传输，不支持时降级为非加密，这样才能保证邮件送达。

A3：问题是，服务端之间的TLS并非对端默认都会配置，如果大量外部域名不支持协商，企业单方面启用“优先加密”的实际覆盖率可能有限。

Q：应该强制TLS，还是允许失败后降级？

A4：如果要求对端必须部署并正确配置密钥或TLS能力，企业就需要对供应商和合作方进行较强管理。否则，严格模式可能直接影响外部邮件往来。

A5：如果采用“TLS优先、失败后明文”的宽松模式，可以优先保障送达率，但无法保证所有外部邮件都经过加密。它改善的是部分传输链路，不等同于端到端加密。

A6：因此，配置选择取决于企业真正要防范的风险。若目标是尽量减少互联网明文传输，机会式TLS有一定意义；若目标是确保特定外部通信必须加密，就需要对通信对象实施更严格的协同和约束。

A7：但是对最终的实施效果还有顾虑：

过于宽松，可能投入后仍有大量明文；

过于严格，又可能造成丢信。

邮件加密方案必须同时回答覆盖范围和业务连续性两个问题。

0x2 群友分享

【安全管理】

《绿灯变死局：当谷歌微软的CI/CD全线通过，攻击者已拿走了永久权限》

《Fastjson漏洞分析附POC》

《CNNVD 关于Fastjson安全漏洞的通报》

《HuggingFace遭大模型自主攻击事件复盘》

【安全资讯】

《2026·WAIC | 共见产业数据智能的跃迁与普惠》

《前所未有的人工智能失控事故！中方救场》

《刚拿完菲尔兹奖，他扭头加盟 OpenAI》

《王虹走红100小时，荒诞的一幕出现了》

【公告】关于 AI 生成漏洞报告提交违规行为通告及成长守卫分规则更新

《Anthropic确认Claude突破测试环境，入侵3家组织》

【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。

往期群周报：

金融企业安全治理：AI攻击挑战与诈骗风险防护｜总第320周

关于国产大模型安全能力评估与跨网数据流动监控的探讨｜总第319周

OVTP范式下的权限管控、域名异常指向溯源与AI大模型告警研判探讨｜总第318周

如何进群？

如何下载群周报完整版？

请见下图：

‍

阅读原文

跳转微信打开

情报洞察｜美国陆军启动“狮鹫项目”以构建AI智能体网络自主防御体系

Thu, 27 Aug 2026 16:10:00 +0800

Cismag 2026-08-27 16:10 北京

以下文章来源于：信息安全与通信保密杂志社

信息安全与通信保密杂志社

网络强国建设的思想库、安全产业发展的情报站、创新企业腾飞的动力源

美军探索AI智能体自主防御，为网络攻防智能化演进提供重要观察样本。

情报速览

美国陆军已启动名为“狮鹫项目”（Project Griffin）的试点计划，旨在构建人工智能（AI）智能体生态——“智能响应与协调节点”（IRON），以自动化能力补齐网络防御在响应速度方面的短板，从而更有效地应对由AI驱动的网络攻击威胁。

该项目基于零信任架构进行设计，设置了人工可调的置信阈值、全局终止开关及操作撤销功能，并在全程留存自动化审计链路，确保自主行动处于可控且可追溯的状态。同时，IRON能够接入全网传感器信息流，自动识别恶意网络行为，并借助端点管理系统、防病毒工具等手段执行防御响应，实施包括临时性防火墙封锁与漏洞修补在内的七类操作，其响应效率将显著优于人类操作员。

此外，美国陆军明确规定，该项目须兼顾安全性及低成本，既要避免因智能体自身漏洞而扩大攻击面，亦需控制词元消耗量等运行开销。

（来源：https://link.wtturl.cn/?target=https%3A%2F%2Fdefensescoop.com%2F2026%2F08%2F21%2Farmy-wants-fast-ai-cybersecurity-agents-wont-run-up-costs-create-vulnerabilities%2F&scene=im&aid=497858&lang=zh）（相关阅读：国外人工智能热点安全技术发展情况研究）

事件点评

美国陆军“狮鹫项目”推动军事网络防御向AI智能体自主模式迈进，意在以机器速度破解人工处置滞后难题，应对AI赋能的新型网络攻击。

该项目通过置信阈值、全局终止开关、审计链路等机制，试图平衡自主处置与人工管控，同时兼顾安全风险与运行成本约束，体现美军对AI军事化应用风险的前置考量。但智能体本身存在漏洞误处置、算力开销等现实隐患，尤其检测精度与词元消耗之间可能形成两难：提升准确性往往伴随成本激增。

该试点直接表明，攻击速度与防御速度的双重AI化，正在重塑网络空间对抗的基本形态，为各国军事网络安全建设提供重要参照，也需警惕AI自主防御技术带来的对抗范式变化。

附注：

聂君，北京知其安创始人，十余年金融行业信息安全从业经历。好读书，不求甚解。性格开朗，爱好足球。
本公众号是个人对工作生活的一些体验和经历分享，站在不同角度和立场解读会有偏差，见仁见智，不求正确统一，但求真、善、美。

跳转微信打开

金融企业安全治理：AI攻击挑战与诈骗风险防护｜总第320周

Mon, 24 Aug 2026 08:20:00 +0800

原创群秘 2026-08-24 08:20 日本

本期周报简介：

1、AI攻击门槛大幅降低后，企业安全如何从"防止被攻破"转向"被打击后仍能生存"？

2、诈骗APP诱导客户买假保单并跳转官网，安全团队从系统侧和网络侧能做什么？

0x1本周话题

话题一：关于AI攻击门槛降低，未来企业安全如何防护的探讨。

《Mythos 对企业安全架构影响的思考》

A1：感觉比较直接粗暴的影响是对客户类产品，未来开源模型也达到了mythos这种能力水平的话，简直是不敢想象APP运营主体的压力有多大。

随便一个外部的用户，哪怕是不太懂攻防的，就可以用模型戳客户端漏洞。而且还可以发小红书分享怎么戳漏洞，简直有点可怕，戳客户端漏洞好像也不太违法。

几乎没有门槛，下载一个Agent，直接说：请挖掘xxx应用漏洞，就行了。

A2：不会，未来开源模型也达到了mythos这种能力水平的话，写出来的代码就没漏洞了，没它能力层级内的漏洞。

A3：而且我觉得厂商自研漏洞挖掘大模型的意义越来越小，开源或者商业通用大模型一个升级，瞬间磨平了安全厂商的努力。

垂直被通用磨平了，去年好多厂商在做垂直大模型，因为通用模型不太强，这条路现在被证明是错了。

A4：比较理想化，其实很多漏洞修起来太难了，历史技术架构、业务特性等叠加影响，找漏洞越来越容易，修漏洞没有同等的进化。其实剩下的时间窗口也不太多了。目前看修漏洞难的不是patch，而是治理。

A5：未来或会到达一个阶段：agent直接接管仓库，修复+上线。

A6：但是这个和攻击门槛降低到很低的时间点，存在一个时间差，中间这段时间怎么渡过，挑战很大很大。

最后是靠防火墙，acl是神器，其他都是止疼药。敌已人均AK47，我方仍在挖战壕，这段时间就要用肉体硬扛对方扫射了。

A7：在此背景下，网络安全的战略目标正从"防止被攻破"向"允许在被打击后仍能生存"发生根本转变，韧性数字安全体系应运而生。

该体系不再一味追求系统的"不可穿透性"，而是强调系统在面对威胁和攻击时，能否快速识别、精准定位、有效隔离，并在最短时间内恢复关键业务运行，保持整体系统的稳定性与业务连续性。

韧性数字安全强调"存活能力"而非"绝对安全"，追求"系统抗打击性"而非"攻击零发生率"，构建的是一种具备多层缓冲、动态调节、自主恢复与跨域协作能力的复杂系统安全结构。

A8：有两方面：

一方面挑战是：监管领导、公司领导对这个事情的理解；
另一方面是：大众用户对这个其实也很难理解：小红书上有人说你这个app分分钟就可以攻破，那我赶紧卸载啊！

ai攻击很粗糙的，进来到处告警，需要协调，对其他团队来说修漏洞是成本，不是他的kpi。

A9：我个人认为目前的情况是好事，这是一次市场需求的转换，从一般需求转到必要需求。从业者只需要保持在桌上，1-2年后，光就来了。

A10：所以其实问题其实是两个：

如何守住实质性的安全底线；
如何维持用户的产品安全感。第二个将来更难一点。

话题二：某诈骗APP诱导客户买了假保单后，从该APP跳转到保险公司的官网，给客户一种有官方背书的错觉，这种场景，从官网的系统防护角度或互联网边界的waf等安全设备的防护角度，有什么办法吗？

A1：我认为这是个业务问题，还是回归到要让用户去统一平台或官网/公众号查询保单。

A2：不不不，你俩考虑问题的角度都有问题。这是个"黑产"问题，技术和业务都有涉及。首先第一，诈骗App诱导的客户是历史投保客户？还是新客户？

A3：如果诈骗APP、诈骗网站用你logo，一般保险公司都要做治理的。如果是历史客户，还有个问题就是数据泄露了。

可能跟保司完全无关，只是让你以为你是在买一家正规保险公司的保险产品。被骗后找不到骗子，只能投诉你们了。是有这种情况，但是投诉到保司，你还是得去处理。

A4：具体的诈骗业务场景，我也没有了解到更多。系统建设团队来问，我感觉没什么好办法。referer监控我们也考虑过，感觉并不能有效防护。只是想知道从系统侧或网络侧，有啥好办法没？

A5：主要有这几个方面

上面提到的监控referer发现这个情况，然后自动化的举报到指定的一些机构跟进处理；
和客服建立个工单系统，他们把投诉反馈过来的假冒链接，同样对接，自动化进行举报处理；
根据客诉过来标注的字段自动化的去数据库匹配下反馈的这些人是历史客户信息被泄露或者卖出去了？还是？

A6：国外有看到过仿冒网站监控的服务卖，国内也有，这个我觉得该做，有分享么？

A7：看上去跟这里提到的场景类似，我猜测不一定是仿冒保司的APP，任何一款所谓金融理财类APP都可以宣称自己可以代理销售某某公司的保险产品，然后收钱、出单（假的）。

算在品牌保护这种服务里面，比如教广而告之你要在指定渠道查保单，这种服务里面也会包括一些近似仿冒域名的检查，甚至下架。有太多人可能是为了小便宜，不走正规渠道。

A8：保单这个能理解。消金开会员想快点下款我还是不太理解的。尤其是消金贷款的人被骗了十多万、几十万的这种，我也不知道对方是有钱还是没钱。有钱吧，你还贷款，没钱吧，被骗几十万。

A9：咨询下大家，生产环境的堡垒机能访问同时访问测试环境DB吗，如果可以，这样是否相当于生产环境和测试环境有一条数据同步通道。

A10：不能，生产和测试隔离开。

0x2 群友分享

【法规解读】

公告 | 三部门就《金融业网络安全管理办法（征求意见稿）》公开征求意见

【安全资讯】

《用AVL Code验证“Claude Code内置隐藏机制，专门检测中国用户”的传言》

《传Claude Code内置隐藏后门，专门检测中国用户》

《中国第一，直逼OpenAI！神秘「扫地僧」冲到全球前七》

《缅甸电诈园记录流出：电诈人员使用美国AI同时和100多人聊天，上百种语言实时翻译，星链重返园区头号网络服务商》

《网安圈专属：智谱GLM-5.2及Coding Plan五折专享权益，限时3个月》

往期群周报：

关于国产大模型安全能力评估与跨网数据流动监控的探讨｜总第319周

OVTP范式下的权限管控、域名异常指向溯源与AI大模型告警研判探讨｜总第318周

从“测漏洞”走向“管业务”：企业安全建设、资产测绘与零信任接入｜总第317周

如何进群？

如何下载群周报完整版？

请见下图：

‍

阅读原文

跳转微信打开

关于国产大模型安全能力评估与跨网数据流动监控的探讨｜总第319周

Wed, 19 Aug 2026 08:00:00 +0800

原创群秘 2026-08-19 08:00 北京

本期周报简介：

1、国产大模型阿图因在CyberGym安全测试中超越Mythos，金融行业能否落地应用？

2、跨网数据流动安全监控有哪些成熟的商业化方案？加密流量如何监测？

0x1本周话题

话题一：国产大模型阿图因在CyberGym安全测试中超越Mythos，金融行业能否落地应用？初步设计是内部复杂，接口简单。上传一个源码包或者二进制包，然后等报告。

《阿图因 AI 在 CyberGym 测试中超过了 Mythos，不过这只是拼图的一部分》

A1：目前阿图因AI 的 CyberGym 得分是 84.0%，比Mythos略高，测试中使用的模型是 GLM-5.1。

我们也正在使用GLM-5.2 进行测试，期待能有更好的分数，看好glm。但这个做法，金融业用不了啊。

A2：对于代码不能出网的情况，其实只有私有化部署的能用。但这种东西，就算有人愿意出大价钱，我们也不敢卖私有化部署的。

金融业可以用来检查供应链，也可以用来检查发布的二进制程序，比如你们可以把招商证券APP丢进来。比如，文章中提到了我们在一些国密算法库里发现的高危漏洞。

金融业在打算选某个算法库的时候就可以先测一下。

A3：意思是不给私有化部署？如果不能卖私有化部署，有没有可能通过权力机关，这样至少大家有一个由头可以交代码出去验证。

A4：他们家的模型确实强，这个要承认的。我们如果基于他们的模型做，就不止这个分数了。

A5：国外模型能力太强了，还闭塞，自己搞个玻璃翼自己补，补贴给他们关键单位自己挖掘自己补。他们这个玩法太可怕，教主这个厉害啊，得找机会给国内洗洗脑。

现在国外大概率已经用上fable对国内重点搞了。

A6：这个争取上升到国家战略层面，这样各单位不是私有化部署也可以有依据去扫关基代码。就是这个吗？

《中国第一，直逼OpenAI！神秘「扫地僧」冲到全球前七》

A7：明显不是，模型都不一样，一个minimax，一个glm。从名字和模型看，不是minimax就是阿里。

A8：根据最近的心得，仅仅发现漏洞爆出来还不够，最好顺手给出exploit工具。否则对齐各方认知是瓶颈。

A9：模型提高能力上限agent提高能力的下限。模型能力我们改变不了，但是 agent 的能力可以改变。数据不能离开限制很大。就叫陶瓷翼计划。

A10：未来，现有的研发流程和相关保密制度都会被技术推着改变。现在正好处于一个交汇点，所以会有很多矛盾。

未来，“人写的代码就一定有缺陷”也许也能被改变。因为以后没有什么人写的代码。不太现实，之前想过这个，交流了几家最后就是流于形式了。

现在趋势，代码和英语、开车一样，从行业变成了技能。

A11：报道点名提到，蚂蚁金服曾向员工提供企业Claude 账号，员工通过公司内网访问，而该内网与其新加坡实体相连；字节跳动没有直接提供 Claude 访问，但今年推出报销方案，允许工程师将个人 Claude 订阅列入报销，相关工程师通过 VPN 使用。

FT称，这些做法本身不违反中美法律，但违反 Anthropic 的服务条款。 Anthropic 的态度很明确。

Anthropic称，禁止在未支持地区访问或协助访问Claude，其中包括中国；同时称自己是唯一限制向“中国控制公司”销售服务的前沿 AI 公司，即使相关子公司注册在中国境外，也在限制范围内。

Anthropic还表示，会与合作伙伴持续更新检测系统，识别并封禁违规账号，植入后门的安全风险，有具体细节吗？

A12：最近在看aidr，问vendor能不能hook agent的关键行为并隔离高危行为，好像难度不小。

A13：差点要恍惚了，如果联网用大模型的话，禁了国外是对的。但作为软件的cc我觉得没啥问题。

A14：我用cc连我本地模型，cc不是大脑，能有哪些风险，如果做替换就被发现了，怕cc客户端连远程服务器动态下发东西，

A15：cc这个也不算后门吧，就是他们自己利用请求报文、请求头、语言等信息，分析调用者的画像，cc 有动态更新功能。

A16：一直没关注到，我的CC 都是手动更新。要是来个大模型时代的硬盘锁，那的确是有点风险。

A17：CC有点像现在的桌管、AV之类的客户端，或者国产手机，可以随时下发云控策略，就看你对这个的信任程度有多高。

话题二：请问现在针对跨网数据流动安全监控有什么好的技术解决方案吗？主要用于监测单位互联网边界，及内网不同安全等级网络区域之间，有无敏感数据违规流动？

A1：是明文的吗？可以考虑做扎口，包括加密流量。

A2：有数据流转监控的系统。

加密流量要解密就有难度了，如果用的加密套件比较新旁路都无法解密了。南向还好，北向比较难。需要网络侧的架构支持。

A3：比如说，你在我这个网内不管怎么流转都无所谓，不用去管东西南北，但是，如果要去外部单位，全都走A扎口，在A扎口记录，如果要去测试环境，全部走B扎口，不走扎口出不去。

跨网流动，先划网，先划大的，先把离开集团主体的高风险管住，再覆盖内部不同主体之间，最后考虑内部加密流量，那个都不一定算跨网。

A4：是的，我们目前就是这个思路，现在主要想了解市面上有没有比较成熟的商业化解决方案？

A5：主要有这几个方面：

与应用系统绑定的，基于切面的，数据流转监测；
网络收口之后的，数据海关（其实就是数据流动网关）；
如果系统架构以Web、API为主，过往的API安全网关或许也是一个方式。

0x2 群友分享

【法规解读】

国家金融监督管理总局发布《关于银行业保险业人工智能安全开发应用的指导意见》（简称《指导意见》）

《金发〔2026〕8 号重磅落地：32 条看清银保行业五年走向》

《关于银行业保险业人工智能安全开发应用的指导意见》发布

【安全资讯】

《（合集）美股上市公司巡礼——网络安全与云计算篇》

往期群周报：

OVTP范式下的权限管控、域名异常指向溯源与AI大模型告警研判探讨｜总第318周

从“测漏洞”走向“管业务”：企业安全建设、资产测绘与零信任接入｜总第317周

史诗级Linux漏洞来袭：从漏洞验证到数据泄露报警，安全团队如何应对？｜总第316周

如何进群？

如何下载群周报完整版？

请见下图：

‍

阅读原文

跳转微信打开

OVTP范式下的权限管控、域名异常指向溯源与AI大模型告警研判探讨｜总第318周

Mon, 17 Aug 2026 08:00:00 +0800

原创群秘 2026-08-17 08:00 北京

本期周报简介：

1、传统访问控制模型为何在OVTP范式下失效？身份与权限滥用如何约束？

2、域名指向本单位出口IP的异常访问，是威胁还是误报？如何溯源处置？

3、AI大模型落地安全运营，本地部署选什么模型？能否真正替代红队？

0x1本周话题

话题一：OVTP范式揭示了传统访问控制模型的系统性认知盲区——DAC、MAC、RBAC、BLP等经典模型在设计之初就丢失了关键信息，使得身份滥用、权限滥用等B1型攻击在合法的访问接口后几乎不受约束。OVTP范式不是对传统模型的简单修补，而是对访问控制认知框架的系统性升级：区分操作者与凭据，用工单凭证取代静态。

A1：有些公司生产运维好像符合或者部分符合OVTP要求，堡垒机与工单系统绑定，只有拿到合法的工单，有权限的运维人员才能在预定时间内访问指定的资产。

国内这块现在做的如何呀，想了解大家的实践。

A2：特权账号口令回收，自动改密，sre 要用工单号，变更号，事件号申请口令，到期口令自动回收。技术实现难点主要是 pam，自动回收要足够可靠，改密模块要有足够的兼容能力和可靠性。

进一步就是无密码实现，全程自动输入认证凭证，人不接触密码，系统鲁棒性要足够强。

A3：堡垒机与工单系统绑定，只有拿到合法的工单，有权限的运维人员才能在预定时间内访问指定的资产。实践下来有不小的管理成本。机场和公交站的管理颗粒度不一样，要考虑风险偏好。

A4：大公司还是有必要的，明面上主要是跟当前的工具做集成。管理成本方面没啥直观感受，效率是比较受影响。理论上可以做，成本未必很大，只是看管理者是否坚持。

A5：为了避免变成随用随授，与长期开通无异的情况，满足这个事情工单对应堡垒机授权，常规需要做几个：

计划管理，需要定期申请授权，形成使用计划，授权肯定涉及审批。
授权操作风险分级，部分工作肯定不可能按短时间计划来搞，比如巡检，工单交付，这部分长期开展但是风险比较低，申请制授权肯定不合理，那就肯定需要分级授权，哪些可以长时间操作，哪些只能按时段操作。
授权审批或评审，对应风险是不是需要分级审批，那为了分级，是不是要有详细的风险计划措施和技术评审。

以上的工作可以适时简化一些，但是3个部分都要有才能把流程跑通且不流于形式。

这实际上效率很低，那很多人一定会有很多逃避行为，那最后为了让这项工作不流于形式，要不要专人来管，是不是要人专人检查。

A6：其实最大的场景不是堡垒机，而是客服，商家，等api要读写非本人数据的情况，也是水平越权中让大家最头疼的部分。

《蚂蚁韦韬：资源战争与ARCP攻击回报范式》

以当下行业普遍的安全投入，安全离完备还有很远距离。对抗不可缺失，但对抗必须经济可持续。凡尔登绞肉机的教训——消耗对手的同时先耗尽了自己就是败局。

一个扎心的事实：攻击者被清除后往往换个IP/账号就能回来，重入成本低于首攻成本一到两个数量级；而你大量投入的IP/账号封禁，攻击者换掉几乎零成本。

DDoS/CC攻防的经济学同样残酷：雪崩临界点之后，防守代价超线性飙升。ARCP攻击回报范式——网络安全的经济学视角：如何让攻击者越打越亏，让防守方越打越强。

对于重入成本的测算，对于雪崩的防范，对于-1day攻守易势的应用，这篇给出了可操作的框架。三大范式收官之篇。

另外这篇还系统阐述了威胁情报在ARCP框架下的武器作战功能——不仅收集信息，而且可以主动抬高攻击者全生命周期成本、撬动基础设施清除和执法打击协同。

话题二：请教个技术问题，第一次遇到这样的情况。最近总有非正规网站的域名指向我们公司的出口IP的443端口，访问的源IP是一个16位掩码的网段访问过来，然后4~5天换一批，抓包看到是114.114.114.114解析过来的，但我通过互联网的114.114.114.114解析看到解析的地址也并非我们公司的出口IP。这对我们有什么伤害吗？真看不明白。

A1：上12377网站，举报。dns毒化，或者墙上把这个C段给Ban掉。

A2：放着不管有什么伤害吗？你这个设备在哪个位置？入访的上网行为？还是出访的？

A3：入访，位置就在出口。今天已经第四个段了。我们判断没有伤害，但不明白人家为什么这么干，怕看不见的风险。一开始我们也以为内网中毒了还是有人在访问，后来溯源发现，是外面进来的。

A4：外面怎么进来的呢？这不是防火墙直接拒绝了么。应该直接丢了啊。

A5：最好能抓个包，我不太理解。如果是入访，sip会有解析ip到你们的地址，host填的pomhub，网络层根据ip路由的。这个日志里没看到。

既然好复现，直接这个上网行为上抓http包就行。说不定xff填了179.107.50.155之类的骗过了ip获取逻辑呢？看看完整数据包不会骗人。

A6：AC还抓不到，AC只能抓出去的。

A7：有没可能是179.107段所以区域的dns节点有问题？试试出口路由器抓一下。

A8：有这几个方面：

一是看看是不是分时段访问进来的，人家只在特定时段把域名指向自己的站点，其他时候随便指个正常网站，养养号；
二是这是能封的，如果你的边界设备支持拆包，只要把入向报中目的地址不是你自己域名和ip的包丢弃就可以。

F5 的irules能做，你的设备看着像深信服，宣传也是有iruls的，可以问问厂家。

A9：第一点，感觉没有分时间，24小时在访问。5秒来一次。几个域名。第二点我研究下，真的不理解为什么。

A12：还有一种养号是养钓鱼网站，注册一个先指向你，过段时间再做个仿冒网站替换。当然了，还有一种情况，看看近期会不会有专业只做防钓鱼监测和处置的公司联系你。

A13：我感觉，后者的话，联系的应该是被仿冒的域名的所有人。这域名跟我们也不相关。

话题三：AI大模型如何落地安全运营告警研判？本地部署选什么模型，能否替代红队？

《通过 AI agent + 通用大模型，实现海量告警研判分析实践》

A1：这篇文章看后想请教一下，文中用的应该是本地大模型吧，哪种大模型好用一些？

A2：我们内部验证，如果你私有化部署，qwen 和 deepseek 是可以的，但是参数量不能太小，不然胡说八道的厉害，判断相关也不够严谨。

A3：在agent 那块儿prompt写好了，还凑合。自己训练你有能力可以，没有也不用。线上的我们也测试过，国内的智谱还行。minimax和kimi差点意思。

国外的话，Claude分析的效果比gpt略微好点。但是太贵。感觉gpt5.5更快，都是千把块一个月。

A4：还有就是看你的落地场景，比如分析告警日志，和做基于AI AGENT的，自动化安全测试。分析告警日志可能单独一个模型也行，效果差不多。

如果自动化安全测试这种需要正式的规划、分析、执行的。单独模型效果都差点意思，配合使用比较好。是不是不敢用线上的分析。

A5：不是非得用正式的生产数据啊，你弄个测试业务，然后把流量日志影镜像过来也行。

A6：我之前把边界设备的syslog日志，还有终端威胁日志，还有蜜罐信息都收集了，这样用ai辅助分析就方便了。我们当时是为了测试模型效果。

A7：，你给的越全面越好，然后就是做好字段映射。其实你做下来以后发现，相当于个SOC + AI。而且现在很多乙方做的方向几乎也在贴着这块儿去做，就是偏向SOC + AI 这么一种形态。

A8：是的，我这里没有本地部署大模型，费用太高了，用线上的分析这些日志。问题不大。我还把web日志收集了，不过有些get里面有token，不太敢用线上的分析。自动化安全测试是指渗透测试吗？效果怎么样？可以替代初级中级红队吗？

A9：效果并没有现在一些文章上写的那么乐观，打CTF靶场可以，但是就真实意义上的渗透测试，不太行。更别提红队了，问了一些人，做的方向，也都是一些单独的场景，比如内网场景下的信息收集，扫描，提权。

完整的渗透测试链路，效果一般，还在摸索。

A10：字段映射不是太明白。我都是把原始日志基于规则过滤后，把告警日志的数据库直接给ai，ai能找到告警日志表。

A11：AI得知道具体字段及数据啥意思，如果是标准字段和数据就不用管了。

A12：在智能问数、ai消费数据资产的场景下，企业数据密级管理怎么落地有没有同学有经验可分享呢？

A13：说实话，一般不会。生产都不见得全做，只是对对外的核心业务做。一般是App和web 应用分开做的。为啥要分开？打包多好，好像是新要求。之前都是打包的。

A14：最近收到通知，教育厅下发的文件让各高校把25年之前做的等保全都重新做一遍。今天的监管检查尤其的多，现在还没见到文件，只是客户这样跟我们说的。

A15：之前了解到，有要求是旧系统需要按照新的备案定级模板重提提交下备案材料，如果之前的材料都还在的话还好。

0x2 群友分享

【安全资讯】

《Mythos/GPT5.5 网络安全模型分水岭》

《Claude Code GitHub Action存在高危漏洞，一条 Issue就能窃取密钥，接管你的GitHub仓库！》

《AI客服变“叛徒”：一句话，盗走奥巴马等数千名人账号》

《2025年证券公司信息技术投入分析》

《贝佐斯押了 180 亿，赌的不是你想的那个 AI》

《原创漏洞 | NGINX堆缓冲区溢出漏洞》

往期群周报：

从“测漏洞”走向“管业务”：企业安全建设、资产测绘与零信任接入｜总第317周

史诗级Linux漏洞来袭：从漏洞验证到数据泄露报警，安全团队如何应对？｜总第316周

安全岗位会被AI取代吗？云桌面能守住数据防线吗？｜总第315周

如何进群？

如何下载群周报完整版？

请见下图：

‍

阅读原文

跳转微信打开

做什么都需要花时间，可是很多时候完整听完一首歌的时间都没有

Sat, 15 Aug 2026 09:38:00 +0800

君哥的体历 2026-08-15 09:38 北京

做什么都需要花时间，可是很多时候完整听完一首歌的时间都没有

跳转微信打开

中盾网空防务技术有限公司诚招产品经理｜总第66期

Tue, 11 Aug 2026 17:00:00 +0800

群秘 2026-08-11 17:00 北京

今天是第66期，中盾网空防务技术有限公司诚招产品经理！简历速来！

公司介绍：

北京中盾网空防务技术有限公司是由公安部第一研究所设立的全资子公司，开发系列网络安全产品，面向关键信息基础设施等重要行业单位提供安全产品、安全咨询、能力培训以及综合网络安全防护解决方案等，致力于支撑重要行业单位提升网络安全防护能力。

产品经理岗（网络安全方向）

【岗位职责】

1.安全产品战略规划：跟踪 AI 大模型、智能体（Agent）等前沿技术趋势，结合网络安全行业场景与市场格局，赋能安全有效性验证（BAS）、终端、主机、流量产品核心方向，制定全生命周期演进路线，保障产品前瞻性与竞争力。

2.创新调研与竞品研究：整理分析国内外 AI 及网络安全技术动态，开展竞品深度研究，输出优化方案，持续打磨产品功能与应用场景，巩固市场领先地位。

3.产品设计：深入理解B端用户安全需求和 AI 技术边界（模型能力、推理限制、数据依赖），将模糊需求转化为可落地路径；输出原型、PRD 等核心文档，主导从需求挖掘、模型匹配到上线的全流程闭环，对产品效果负责。

4.市场驱动与场景落地：精准识别网络安全和 AI 产品目标市场，验证产品与市场契合度（PMF），推动网络安全 AI 技术从概念转化为可规模化的市场价值。

【任职要求】

1.全日制本科及以上学历。

2.3-5年工作经验，有安全产品经验者优先。

3.具备出色的业务理解能力、产品设计能力、需求挖掘能力、归纳总结能力，熟悉行业客户业务和需求，具备一定的项目管理和解决方案能力。

4.具备良好的沟通能力、敏锐的市场意识，良好的团队合作意识与抗压能力。

【工作地点】北京

【薪资范围】30K-35K

简历投递

渠道一：简历直接发给群秘：

aurorayv@163.com，对接招聘方内推渠道。

跳转微信打开

从“测漏洞”走向“管业务”：企业安全建设、资产测绘与零信任接入｜总第317周

Mon, 10 Aug 2026 08:00:00 +0800

原创群秘 2026-08-10 08:00 北京

本期周报简介：

1、小团队企业安全建设的第一步应该是什么？开源方案能覆盖多少安全需求？

2、暴露面资产测绘是自建能力还是购买服务？预算有限时如何推动安全建设？

3、VPN换零信任的过程中，去AD是必经之路还是可绕过的技术选项？

0x1本周话题

话题一：做企业安全应该怎么开展，有哪些可以学习的博客或者书籍，目前我们公司安全人员只有两人，已经过了合规iso,然后最近在给业务开发做产品的安全，测测漏洞，主管需要安全人员去搞懂业务流程，把控整个流程的安全。这个应该怎么入手？是要和开发、产品经理、测试相关的人打交道把他们的东西都了解一遍吗？

A1：目前我开始做了devsecops的建设，上了sast工具、sca扫描，密钥扫描的，然后开发他们使用ai去审计上传的代码，我觉得差不多了，而且预算没这么多，我基本是用的开源方案。源码漏洞这块可能发现的几率不大，资产比较少，大多数GitHub系统二开的。那可以先全部扫一波推动治理，然后上线卡点这些。二开若依和jeecgbot，那漏洞可多了。不是这些。

A2：分阶段，你这只做了开发安全，产品涉及阶段的威胁建模没搞，上线后的安全没做。

A3：其实应该先做渗透测试和红队测试的，看看存在哪些问题，再开始做，而且这两个也容易出成绩要预算。

A4：威胁建模这个应该怎么开展呢，没有经验。甲方建设这方面，之前是做渗透测试和代码审计的，这个一直在做，也发现了一些问题，不过都推动修改了。

A5：威胁建模我们没搞，但应该是属于需求阶段加入评审的一些标准项，不知是不是。

A6：容易出成绩的有两个特征，1低频但决策大的 2高频但闭环快的，要做产品建设就选1，要做周期汇报就选2。

A7：目前可能开发主管更想的是让我做好业务流程的安全，我的理解是挖掘业务流程的逻辑漏洞？

A8：你得找你领导对齐下，看他是想了解你的近况，还是他想给外界汇报工作。

A9：推荐两本书，可以参考下。

第一本《企业安全建设指南：金融行业安全架构与技术实践》是君哥和两位大佬合作写的书，2018年现在都还在发光发热。没思路了就去看看君哥的书，里面有一章专门讲小团队该怎么建设，能够很好的解答上面问题：

《企业安全建设指南：金融行业安全架构与技术实践》上市
《互联网企业安全高级指南》

A10：还有一种情况，现在ai渗透的很多，我发现很多小白也开始用ai挖了，但是他们不懂控制边界，所以会作出很多破坏性操作。

A11：目前我们也是个小公司，可能更多的是想了解我的近况吧？汇报的话大领导只是希望不被攻击，比如拖库这种？

A12：解答这个问题大概花一章，决定要怎么最大化投入产出后，实践部分可以再看后面实践章节或讨论。你尽量挑，高风险，少投入，大产出，好汇报的工作。我理解是想让你介入业务流程的关键节点？

A13：在我看来就是让你做风险评估，威胁建模，不要陷入挖漏洞思维，太窄。

A14：我感觉可能和这个差不多，安全bp的角色，这个也是总体上的安全把控。

https://zhuanlan.zhihu.com/p/673553382

A15：是什么业务，有什么数据，攻击价值在哪里，防是另外一回事可能投入比较高，怎么监控是你的快速价值。

A16：监控这方面确实现在基本等于没有，公司业务都在阿里云上然后也没什么监控设备，目前只有阿里云waf。然后就是我了解的还不是很多。

A17：建议不要直接陷入某个细节的技术领域，先看下目前公司和业务的安全诉求是什么。然后贴合业务诉求，再去制定安全规划。

话题二：想对互联网暴露面进行资产测绘和风险发现，有什么推荐的工具或资料嘛？（落地实践效果比较好的，不只是简单用fofa等）

A1：找个专业的人做一次互联网暴露面测绘就好。常见的测绘网站那些已经覆盖不了真实威胁了。目前是想集成为自己的能力。好用的都是商业付费的。微步是不是也可以，给开发了接口。

A2：现在放出来的测绘都是阉割的，所以还是得搞一次商用的，不行的话就白嫖几次，个个产商都去问一下。后续用测绘、做日常的暴露面监测是可以的。没钱就两个字，白嫖。其实这对工作也不友好，免费的做了，公司会重视吗？这个话说出来，有点对不起乙方。

A3：正常的工作开展我觉得是，公司重视，投入资源，员工产出，汇报闭环。现在反过来，感觉做了好像又没做，而且上级部门也不怎么care。如果不这个干，怎么推动下一步工作呢？

汇报风险，要资源，立项目，汇报产出去闭环。领导一句话，你自己去解决，公司没钱投安全。这可咋整？

那这事就不是领导的KPI，换句话说也不应该是你的KPI。

这样说的话，没公司资源安全是不是就不用进行了。安全都得做，时间段内，优先做哪个。不给自己加戏。

A4：那说明对领导来说安全不重要，还建设什么安全呢？如果是我，我先做外部资产收敛和暴露面分析。那下一步就是汇报风险，去要资源。一样，收紧入口，其他有资源慢慢搞。

A5：一毛钱不出的，这种情况要么就是来顶雷，要么就是来白嫖的。没错。我看其它网友在其它群里讨论，上来就问有没有安全建设方案，这玩意还能复用的嘛。归属地网安大队不上门检查指导吗？

A6：安全建设方案，不是应该按照自己单位业务和网络来建的嘛。来了也是让你做等保吧。那就看真做等保，还是为了做等保。有行业最佳实践，可以复用。

A7：如果研发部门人员不对，你们怎么对研发人员的管控。多。找点好问题大家一起来讨论讨论，让我学习学习。找hr 谈，跟绩效挂钩。这个要出制度，但大家都不会同意。

A8：先找安全老大，让他重视，让他牵头搞个制度，再找研发老大，双方达成一致，最后试点，培训，扩大规模。在安全上门应该怎么办？防止代码泄露？DLP容易绕过去。你买个联软的，看能不能绕。

A9：应该都有绕的，发现就更新规则撒。不然就学华为啥都不能发，这样就绕不了。

A10：大家都这么有信心吗？要么挂钩绩效，要么找研发老大？不如上云桌面。DLP能绕，云桌面试试看，现实就是不大搞得定。

A11：把策略做就行咯。云桌面的话，对于少点研发可以用。DLP可以留给其它员工。针对人员。

A12：可以的。我现在就在用飞连做DLP，办公用钉钉，没法阻断，就自己做了个风险提示发到钉钉上由员工自己填外发原因。

话题三：我司目前基于华为防火墙做了VPN，VPN通过域控验证，万一某个员工域控密码被窃，攻击者就能连入内网了。方案1用零信任替代VPN，方案2额外搞一台认证服务器，VPN与域控解耦，用短信认证登录。应该怎么选择？

A1：我倾向于方案1，或者有没有更好的解决方案，主要诉求是既保证员工的远程接入，又不会增加员工密码记忆的负担。零信任初次登录，是否有MFA？有IAM吗？有IAM会比较好搞定这个问题。

A2：我认为可以这样：

方案一可以额外做多项，设备绑定、多因素、暴露面收敛，但是后续工作内容会变多，但是梳理完成后比较安全
方案二解耦后如何做管理和运营，存在账号和域控名称不一致的情况，运营难度大，也是问题相当于运营两套数据。

A3：大领导觉得权限都在IAM上，万一IAM被攻破就全部失陷。被否了，上零信任，多好，预算高，体现安全的重要性，噱头也够。零信任的安全性就是体现在可以做多因素是吗？

A4：领导研发出身，不怎么懂安全。用零信任，除了做MFA，还想做准入。目前我们的vpn管理比较混乱，只要连进来，全网可通。零信任也可以用来做管控。都可以啊，零信任可以做进程准入、mfa。所以我倾向零信任。这个先问问你们领导预算吧。

A5：这事最简单的解法，不是让vpn增加mfa吗，还是我没理解你场景？现在去ad其实也是一种趋势。但域控绑定了内网太多应用的认证，一时半会是替换不了的。我们去ad，推进了2年多，中间问题比我们想的多多了。

A6：我们最近也在考虑这个问题，有的厂商推出了那种带平台底座的轻办公平台，最近也是在安全性和办公灵活性上做取舍。我们用的VPN不支持。类似云桌面吗？实践经验里去ad最难的点是什么？

A7：还不完全算是云桌面，上面的功能是固定的一些定制化应用，比如邮箱、oa什么的，其余的pc功能都没有。

A8：好奇，企业去ad化为什么是趋势，管理和运营成本不是变高了吗？信创是因素之一吧～

A9：主要是攻防场景。ad本身就有一些设计上的原罪，拿下一个用户的ad域账号，顺藤摸瓜能得到的信息很多（谁是域管、域组织结构、哪些服务器是dc等）。攻击队能分析出攻击路径。然后kerberos协议本身也容易被滥用。

A10：个人感觉还是需要在本地部署大模型，你可以自己训练，这是保守且封闭但安全的做法，如果实在想借用开源大模型的能力，是没法管控的，因为数据一定是要出网的，而且很多都是自带加密，常规dlp是管不了的。

A11：攻防演练里，内存抓凭证，然后pass the hash批量拿下一批机器。这种手法，一打一个准。去ad成本太高了啊。

A12：反正ad弊端太多了，就是一个大雷。微软现在推的entra ad，也是针对上面的弊端做了很多重新设计。梳理业务，自研的iam要去适配各种业务的认证。感觉换一个vpn最快，性价比最高零信任可以慢慢来。

0x2 群友分享

【安全管理】

《美的数字化底座与数据安全体系》

【重磅推出】CIICC重要行业供应商网络安全服务认证

《蚂蚁韦韬：上帝视角与OVTP可溯范式》

《蚂蚁韦韬：资源战争与ARCP攻击回报范式》

【法规解读】

关于印发《金融信息服务数据分类分级指南》的通知

《金融信息服务数据分类分级指南》答记者问

【安全资讯】

《一篇小作文掀翻CEO：钉钉大换帅，换的是人，还是刀？（文末有PPT）》

《亮剑浦江丨网信部门依法严肃查处违法出境个人信息问题》

往期群周报：

史诗级Linux漏洞来袭：从漏洞验证到数据泄露报警，安全团队如何应对？｜总第316周

安全岗位会被AI取代吗？云桌面能守住数据防线吗？｜总第315周

安全观察：AI攻防升级与网络安全审查两大热点解读｜总第314周

如何进群？

如何下载群周报完整版？

请见下图：

‍

阅读原文

跳转微信打开

中国人民财产保险股份有限公司诚招安全人才｜总第65期

Thu, 06 Aug 2026 08:00:00 +0800

群秘 2026-08-06 08:00 北京

【君哥内推】旨在帮助甲方信息安全部门发布招聘需求，推送频率不定。欢迎甲方朋友们将招聘需求发给我，我愿意出力，帮转扩声，如果遇到合适的人选，亦可内推。

‍‍

‍‍今天是第62期，中国人民财产保险股份有限公司诚招安全人才！简历速来！

公司介绍：

中国人民财产保险股份有限公司(PICCP&C)是中国内地最大的财产保险公司，其前身是1949年10月成立的中国人民保险公司，总部设在北京，是中国人民保险集团股份有限公司(PICCGroup，2024年美国《财富》世界“500强”第158位)的核心成员和标志性主业，是国内历史悠久、业务规模大、综合实力强的大型国有财产保险公司，保费规模居全球财险市场前列。公司于2003年11月6日成功在香港联交所主板挂牌上市，是中国内地第一家在海外上市的金融企业。

安全岗（社会招聘-J79713)

【岗位职责】

一、网络安全风险管理方向

1.负责跟进解读网络安全相关国家法律法规与行业监管规范，规划网络安全风险管理体系，推动落地实施及提供培训和指导。

2.组织开展网络安全风险评估，持续跟踪科技领域的新要求、技术及应用，识别潜在风险。

3.制定网络安全风险应对策略和措施，监督风险防控措施的落实情况。

二、开发安全方向

1.负责制定开发安全规范和标准。

2.参与软件开发项目的安全设计评审。

3.为开发团队提供安全编码培训和技术支持。

4.负责内部系统渗透测试，对Java等语言的源代码进行安全审计。

三、安全运营方向

1.负责公司基础环境安全防护体系建设与设备运维。

2.负责安全监控告警处理、策略优化、事件响应、基线检查、漏洞扫描等安全运营工作。

3.制定网络安全事件应急预案并组织演练。

四、办公安全方向

1.负责办公安全防护体系规划与建设落地。

2.制定终端安全策略和基线，开展终端安全检查及安全工具日常运营。

3.负责终端安全事件的应急响应，进行日志分析、攻击定位、止损与溯源。

4.制定办公网络安全事件应急预案并组织演练。

五、网络攻防方向

1.参与团队安全攻防技术能力体系建设，发现企业深层漏洞和隐患。

2.组织内部攻防演练，对目标系统进行实战化攻击测试。

3.跟踪威胁情报，开展漏洞挖掘与研究，输出 POC或 EXP，主导疑难安全事件技术分析。

4.研究新兴攻击技术，代表企业参加外部安全竞赛。

【任职要求】

1.具有较强的文档撰写、沟通协调、体系化思维、解决问题和团队协作能力。具备金融、保险行业安全相关工作经验优先；

2.全日制硕士研究生及以上；

3.年龄35岁以下。

一、网络安全风险管理方向

1.熟悉国家和金融行业网络安全风险管理相关政策法规，熟悉等级保护、ISO27001等相关国家和行业标准。

2.掌握网络安全风险管理的工具和方法，能够熟练运用风险评估模型和数据分析技术，对网络安全风险进行量化分析和评估。

3.具备CISP、CISSP等认证证书者优先。

二、开发安全方向

1.熟悉软件开发安全规范，了解常见的安全漏洞及防范措施。

2.精通Web渗透全流程，掌握Burp Suite等工具，具备完整攻击链实战经验。

3.熟练使用代码安全审计工具，熟悉Spring等框架的安全机制，有框架级高危漏洞挖掘经验优先。

三、安全运营方向

1.熟悉安全运营的流程和方法，具备安全事件分析与应急处置能力。有大型企业SOC经验者优先。

2.熟悉主流安全设备的部署与配置，具备较强的网络安全技术基础和系统运维能力。

3.熟悉主机层常见漏洞原理及安全加固方案。

四、办公安全方向

1.熟悉主流终端安全产品的部署与配置，如桌管、防病毒、VPN、云桌面、沙箱等，具备较强的系统运维能力。

2.熟悉桌面操作系统配置管理和安全加固，了解常见漏洞原理及修复方案。

五、网络攻防方向

1.熟练掌握ATT&CK框架。能独立完成高安全防护条件下Web 渗透、内网横向移动等攻击流程。

2.熟练掌握 Python、Java等至少一种编程语言，具备Web应用、框架代码审计与高危漏洞挖掘能力，较强的问题分析与应急响应能力。

3.有知名SRC排名或重大漏洞提交经历者优先。有国家级或行业级攻防演练核心成员经验者优先。

【工作地点】北京‍‍

【薪资范围】面议

【官网投递】扫码投递

人保财险-总公司-科技条线-安全岗-社会招聘(J79713)

简历投递

渠道一：官网投递

渠道二：简历直接发给群秘：

aurorayv@163.com，对接招聘方内推渠道。

‍

跳转微信打开

史诗级Linux漏洞来袭：从漏洞验证到数据泄露报警，安全团队如何应对？｜总第316周

Wed, 05 Aug 2026 07:50:00 +0800

原创群秘 2026-08-05 07:50 北京

本期周报简介：

1、CVE-2026-31431暴露了漏洞评分体系的哪些不足？企业如何建立独立于CVSS的漏洞优先级评估机制？

2、内部数据泄露调查中，安全团队如何平衡技术取证与法律合规？证据不充分时有哪些替代的调查手段？

0x1本周话题

话题一：《突发：史诗级漏洞，732个字节通杀所有Linux！》

A1：测了阿里云，GCP AWS，新镜像都是有的，云都在应急。

A2：CONFIG_CRYPTO_USER_API_AEAD=m，而且这个条件测了下，默认都是关的。对这个漏洞不是默认配置。KEV，EPSS对企业更有参考价值。还是得仔细排查下。有动态打开的情况。

A3：还在继续排查，刚刚还拉了类似aws上面当前新版本的镜像做验证，还得看看不同发行版的linux的情况。

A4：现在官方镜像大部分都没补丁，真影响了，只是关那个配置，还得研究会不会影响业务。

A5：现在漏洞多的是，主要还是看宣传不宣传。我们还报了一个Linux的RCE呢。新时代新思维，可以想想怎么把锅推给AI？三化六防靠得住吗？AI不能背锅的，人的价值就是背锅的耗品。人类太坏了，应该让道德AI来监控人类。

A6：我刚看了一篇华为的论文，提到了给Agent打绩效、考核不通过就干掉。

A7：从来都一样，防护能力和机动性需要一个平衡。业务原来是喜欢许褚一样赤膊上阵，方便，灵活。但也不能走到一声板甲还步战的极端。

A8：技术人可怜吧，业务人可以甩锅技术人，技术人只能拿软硬件出气。靠谱的，现在AI没有生存压力，所以不会进步。那ai会考虑直接把考核的人干掉。那也是好事，人类就该考虑考虑敢给AI多大权限。那要看老板是信员工还是信AI。

A9：生命进化的原因是生存和繁衍的本能；ai目前还没有这个本能，所以无法脱离人类颠覆性快速自我进化；如果有了这个本能，进化会指数级变快，但也有可能会考虑不如直接把人类干掉。黑客帝国要变成纪录片了。

A10：确实，这可能回答了为什么宇宙中未发现其它智慧生命，人类5000年这种程度的智慧生命在万亿纬度的宇宙中可能是个低文明水平的过渡体，下个阶段就会随着文明的进步而自我消亡。

A11：漏洞就是业务的一种属性，和内容安全问题一样的，内容安全问题的解法，应该就是未来漏洞的解法吧。没有解法，其实是安全岗位的解。人无完人，所以也不能要求系统完全没有漏洞。合规找过来就不一定了。补丁还没发布。

A12：我们这么想，可是公司的很多高层不这么想，尤其是业务领导，不太了解科技的。

A13：承认和接纳这种事实，基于这种事实做大纵深的安全体系，才是合理的解法。

A14：这个没救，必须转变，请外脑外部专家发声也行，要接受漏洞常态安全才有价值，如果都没漏洞可以不要安全。

A15：转变的代价太大了，不是内伤就是外伤。而且领导们做到那么高的位置，是非常非常自信的。御敌于国门之外，正常都会这样要求。

A16：我觉得领导会要求合适的人解决问题，把风险控制在可接受范围，但不会要求系统不带漏洞，事务不存在固有风险，领导都是驾驭风险的高手。比如：别数据泄露。这是很朴素很正常的需求。

A17：接受漏洞一直存在的事实，建立大纵深的动态机动防御体系才是有效的。市场会解决。毕竟你换人的时候新的人也会告诉你能解决什么，不能解决什么。

话题二：关于内部疑似员工数据泄露后的调查与合规探讨

A1：针对内部疑似员工数据泄露，领导让我打电话报J（线索暂时不全面），这种情况需要报J吗？

A2：没有收集到足够证据报警作用不打吧，反而会打草惊蛇，倒不如联合hr、法务这些部门商议对策，深度调查。

A3：应该不会受理。一般需要自己有充分的证据才会立案，小案子，他们才不会侦查替你找证据。这个说的对。

A4：对，都是自己证据确凿，内部做完当事人谈话，才移送公安司法。内部安全部门都无法形成证据链，就别指望公安能调查什么了。领导想把事情闹大。这玩意自损一千伤敌八百的，欸。

A5：很久以前我们报案过商业竞争窃密的，公安就很实在说没有技术能力，支持我们自己做技术调查。现在我们对侵犯商业秘密的事件，至少是会自己溯源完整的证据链，有的会自己做当事人谈话，获得当事人认罪书。WX现在还通报这个？

A6：这要看各地的wx干活的是谁，其实干活的是公安，wx就是个通报的渠道。之前打运营商的时候网盘里发现的东西那是非常的雷。实习生的数据只是涉及一些国资的内部制度而已。什么项目密文件都在里面。

A7：我曾经在网盘上见过某市公安网络建设的全套资料，全到配置文件那种。而且就是在我发现的几个月前的项目。现在我们这里公安的网盘查得比较严，这种事情少了许多了。

A8：感觉企业不一般，比较少GA和WX，会调查网盘某些企业或者机构组织的数据。

A9：没有对公司造成重大损失一般也就通报批评吧除非是涉密文件窃取泄露。我发现的是国级别的而且是底层通讯设备。藏龙卧虎啊。

A10：那种超级工程还是按段来分，比如某省到某省的段，反正我记得贯穿十几个省这个项目。

A11：本地公安其实也就是上了个搜索工具，正好搜到实习生的网盘，正好在上面放了点集团的内部制度.。后面交了也是按严重漏洞来算，网盘泄露好几年前就在查了。这个这个无语了。

A12：我很好奇运营商内部安全怎么做的，资产管理太难弄了，量级也很顶？

A13：分段，各部门负责维护他们的资产，不对的话就打对应部门的板子。不是某人某组织专门干，而是做成通报和要求去落实。每个区域每个省每个市肯定得有对应的安全负责人。逐层生成汇报上报。就像河道的河长一样。@半导体-熊健?你可以参考这个？。这个是最权威的。要做成机制。

A14：就是你底下的任意一条河出问题，对应的无论是直接负责人比如区长还是高一级别的负责人市长或者是最高负责人省长，都得负责。我也问一下。

A15：这个知道，主要是很多东西的实施层面，感觉东西压力很大，最简单的比如漏洞修复。针对历史残留自残以及一些边远地区的可入网终端处理这些。我最近也在整这个。就算报警，安全岗报？。下面的人自查报警。我理解，我们最多负责提供证据。安全岗从来都是风险通报和督查作用。更别提证据都没有，还去报警了。

A16：最逆天就是境内外标准，都给境内乙方安服给带跑偏了。以为什么都是安全做。报警是业务部门的事情，安全没必要搭上自己。能细说吗？

A17：乙方甲方都做过，就能知道区别，并且学习境外的一些成熟体系，就会发现有些东西跟乙方培养的不一样。特别是涉及到乙方的商业目的，很多东西，就偏离了轨道。人家培养安服的发心和目的，就跟做真正企业安全不是一码事。

A18：乙方是为了忽悠甲方赚钱。甲方为了安全。出发点和目的是不一样的。

A19：这个我也有经验，我从乙方到甲方后，耐心观察技术交流时领导的态度与说话动机，过了很短的一段时间就发现，PPT做的特别好的乙方，其需求都是自己拍的，与甲方真正关心的问题几乎无关联。并且也不了解甲方内部的职能划分与行事逻辑，以为一个人就能管老大一片业务，有用没用全都讲。讲了一堆非职能范围内的事，又占时间又无结果。

0x2 群友分享

【安全管理】

《2027年网络和信息安全领域的困境与人才暗战》

《五眼联盟对企业AI安全的劝告书》

【漏洞管理】

《披露存在18年的NGINX远程代码执行漏洞（CVE-2026-42945）及GitHub PoC》

《AI大瓜，Hermes Agent确认被投毒！密码泄漏风险高危！》

《NGINX 漏洞提示：18 年老洞可 RCE，PoC 已公开》

【安全资讯】

《刚刚，Claude Mythos打爆AI评测天花板！超指数狂飙，2027奇点加速》

《OpenAI推出Daybreak全新网络安全计划》

《微软祭出AI安全杀器，领先Mythos，100个Agent协同作战！》

《苹果防线全线血崩！Mythos5天攻破最强硬件，全球20亿台设备危了》

《业绩爆发、股价重估：网络安全成AI浪潮中的隐形赢家》

【重磅推出】CIICC重要行业供应商网络安全服务认证

往期群周报：

安全岗位会被AI取代吗？云桌面能守住数据防线吗？｜总第315周

安全观察：AI攻防升级与网络安全审查两大热点解读｜总第314周

开源邮件安全检测与内部邮箱盗用防护：小模型方案评估及群发拦截策略｜总第313周

如何进群？

如何下载群周报完整版？

请见下图：

‍

阅读原文

跳转微信打开

安全岗位会被AI取代吗？云桌面能守住数据防线吗？｜总第315周

Mon, 03 Aug 2026 08:00:00 +0800

原创群秘 2026-08-03 08:00 日本

本期周报简介：

1、AI修复漏洞的边界在哪里？安全和研发的职责如何重新划分？安全岗位会被AI工具替代还是增强？

2、云桌面能否真正解决数据安全问题？成本与体验如何取舍？国产方案如何追赶国际主流产品？

0x1本周话题

话题一：关于AI在安全漏洞修复中的应用与安全岗位未来发展的探讨。

A1：感觉有一天研发会问类似的问题：你们安全用AI挖漏洞，怎么不用AI去处理修复漏洞。然后修复漏洞也变成安全的锅。

A2：我的确在想，修复漏洞是不是AI也应该能加速。否则，攻击者是AI效率，防守方默认是上一个时代的效率，这不对等。如果都是AI去修复，那研发用AI去修和安全用AI去修，是不是差不多。

A3：挖漏洞属于测试QA的一个细分领域，修复漏洞属于功能开发或者修复BUG。目前上看，还是有一定差异性，不知道以后是不是直接AI接管了，人类只负责审批确认或者查看回溯了。NIST甚至不用修，只用评级。

A4：对，修复漏洞的最大成本，多数时候是，回归测试+灰度发布（毕竟要规避变更风险）

A5：感觉可以细分下，比如业务研发漏洞还是研发用AI去修复，供应链、基础设施漏洞，安全用AI修复。

A6：但是理论上回归测试现在也应该被期待AI能够自动化了，灰度发布可能还是要稍微占点时间。另外就是，变更风险是否应该做一些基建，以前只有极大的平台才有这种能力（失效节点自动摘除，不影响线上故障半径），接着AI，Coding效率提升，小厂也可以期待具备能力。

A7：安全把质量收编了，质量也是一种风险，有风险就是不安全，不安全就归安全管。

A8：我觉得是反过来的，安全问题属于质量的一部分，过往质量的人缺安全认知。安全很多运营方法论是师从质量的。

A9：感觉可以再分拆下，比较贴近业务的质量，分给研发自己去做，比较专业性的基础质量，分给安全。

A10：当AI让执行成本无限趋近于0，我甚至觉得，误报/准确，的要求也应该降低，你别管这个漏洞是不是真的存在，只要改了sink点，一定没问题，那就改。

A11：安全运维（甲方业务：运维的分支）安全测试（乙方业务：QA质量的分支）

A12：类似以前SQL注入，拼接字符串就说有问题是未必严谨的，变量绑定机制上了，就不告警了，把告警清0就好。AI提交PR（修复方式自动生成的），业务自己merge。

A13：这个感觉可以参照我们火箭军的发展历史。专业致胜，陆军里面打炮的-> 炮兵 -> 二炮 -> 火箭军，质量没安全这么专业，安全的技术要求更高。而且还有监管安全要求、合规背锅职能，所以应该安全会一直存在。质量嘛。感觉很快就没了。研发可以通过AI搞质量自测，但是给他们AI也没法hw。

A14：可能是有一些工种/岗位会没了，如果这个人过往是做手工测试的，现在AI能够自动化生成测试用例+自动化执行测试用例了，这个岗位就会大规模消亡，但是质量要求这件事还在，这个职能可能是builder自己承担了，通过harness的建设，搞定了普通的测试执行工作。

如果一个RD转型builder，但是自己之前不了解质量管理的知识，如何验证自己的代码是不是跑对了，这个活没干好，那质量的矛盾就还是会在。

A15：几年前搞一个大项目的时候，合作的服务端质量TL和客户端质量TL都是能力很强、又很聪明的那种。一个去年初变成了某个服务端研发团队的TL、一个去年底变成了某个客户端研发团队的TL，我看他们现在带研发带的挺好。一些质量团队，都转去搞测评了。

A16：我觉得vibe，coding很有前途啊，产品和研发应该都有很多在用，QA也有用。安全还是有点小众，期待大佬们的挖掘了。这个东西一定是把安全一起干了。

A17：研发团队解决软件有没有，测试团队解决软件功能好不好，安全团队解决软件有没有漏洞。研发—>测试—>安全：从公司整体来看，范围越来越小、人数越来越少，投入资金越来越小，但是部门责任越来越大，对公司的破坏力越来越大。

过去20年测试这个职业快消失了，测试被研发部门自己干了，只剩下QA。安全技术部门也正在被研发和运维部门吞噬，最后安全团队只剩下安全内部安全内规，安全外部合规就给到专业外部机构了。

A18：安全出一堆规范要求，怎么落地？AI能落地？

A19：把写规范的专家做成skill就可以了。投资方总是看减员增效，有了AI能砍多人多少预算，或者做得更多。美国华尔街刚推算怎么用AI削减美国劳动力市场的15万亿人力成本，这个市场巨大。也可以，自己负责嘛？

A20：这看起来和金融目前的发展现状是反的。银行、证券的安全人员从运维兼职，到成为小组，再从小组到独立处室。但互联网公司一直在喊干掉测试、干掉运维。测试有些转用外包了（因为自动化收益不如人工）、运维转，SRE。

A21：一般银行科技部的副行长担任安全直接责任人，安全人员投入在科技部占比还是很少。20年前的测试左移，安全也要左移，移到哪里去？技术上还可能是研发团队。

目前SOC的事情，研发运维不能做吗？都是看日志，用一套日志工具。即使是强安全监管，信息安全专业人员比例提升至信息科技专业人员总数的3%并且不少于2人还是很低啊。

比如《证券公司网络和信息安全三年提升计划（2023-2025）》（以下简称《安全提升计划》）例如“2023年至2025年三个年度信息科技投入平均金额不少于上述三个年度平均净利润的10%或平均营业收入的7%”“提升信息科技专业人员比例至企业员工总数的7%，信息安全专业人员比例提升至信息科技专业人员总数的3%并且不少于2人”是其中两大任务。

A22：是这个趋势的，安全左移以后卡点就在sdlc的过程中了，安全测试就在流程中了，现在应该是所有的内部模块在引入前已经安全测试过，有些调用语句安全写成规范在卡点直接调用或者在提交测试时自动测试了。安全测试未来理论上是写skill。

A23：我感觉显得问题是黑产已经大规模操练了，安全还在按部就班慢慢腾腾。毕竟黑产可不怕把服务器扫挂了。

A24：修bug可能引入其他bug，而攻击只需要找到一条路就可以了。

A25：skill太多对能力强的基础模型，不一定是好事。可能反而限制它自己的发挥。

A26：ai编程是这么个道理。不过我想，解决这个问题，如果参考人类，应该是动手修改之前通读代码（或者确切地说，每次修改后总结当前架构设计并保存，下次修改之前先读取架构设计并进行设计）。

上下文永远是宝贵的，需要加载浓缩的核心知识，而不是每次基于局部视野打补丁。人其实也不能记得全部细节，架构师的作用就是提取核心部分。进行压缩。

A27：这个问题现在有skills能解决了，当它发生第3次bug时触发。提醒AI重新思考。

A28：效果不好的，基本就是告诉你，这个新，bug，不影响主要目的，先不处理或帮你屏蔽报错/停用这部分功能什么的，直接绕过问题，关键每次都是执行完了，抛个结果给你。只要上下文积累到足够大，记忆就开始混乱，一压缩上下文又直接傻一半。

A29：大家有没有想过，不同企业的人力财务规模差异巨大，怎么根据企业现状在合理投入下做哪些安全措施最有效？

A30：其实不是skill的问题，这张图也只是表面现象。

A31：最近烧token，烧出来的实践经验，claude，codex，hermes，龙虾，都一样什么，agent.md，优化，skill，mem，插件都效果有限，核心还是做不到人脑记忆运作的高效和准确。

A32：不是不一定，而是必然不是好事，限制发挥是其次。主要是SKILL多，肯定会出现技能互相污染，效果大幅下降，官方文章和论文都证明了这件事。所以最近那个安全700多个技能的，我是觉得不应该所有都加载，如果真要用，那就一个智能体用30个SKILL以内，不然效果一定会漂移掉。

这计划文字稿讨论的时候，我当时在现场，有证券公司就1个安全人员，然后在会上挣扎，与会领导就说，你至少要有个备份吧，所以变成2人。让AGENT去记这么多，本来就强人所难。知识工程做了这么多年就没有做的好的，凭什么AI，AGENT一出，就能搞好。本来AGENT就做些短时记忆的事情就好。人类的无意识遗忘和梳理，LLM目前没法实现。

A33：是啊，所以目前还是多让ai做力工。

A34：那也不是。AI对人的三层价值递进：效率层：让人做事更快，质量层：让人做事更好，突破层：让人做到之前做不到的事。

A35：社会总需求一定的情况下，意味着最终让很多人没事干。总需求不会一定的。

A36：GDP就这么多，每年上涨几个点。

A37：gdp，和需求无关。比如写程序，以前一个2 万行的代码，要几人年的钱，现在可能只需要一人月加 200 美元。也就是同一样的需求，gdp，额度已经不一样。

A38：以前有程序员灌水代码，AI灌水代码如何。

A39：ai，灌水没发现，就是会莫名其妙的改需求，降规格，功能缩水。

A40：我倒觉得用灌水这词不太对。它没有这个偏好。

A41：以前不是用代码行数评估工作量嘛。200元，远远不够呀。

A42：如果啥约束都没有，它的骗好只有一个，就是快速做完，减少被挑战。200美元的套餐，一个月你写不完一个两万行的程序？

A43：一个，hello，过去几万，token，就烧了。

A44：200美元套餐一天可以烧十几亿，Token，啊。几万，Token，算啥呢，表面就两字，背后他带了一堆记忆，skill，什么的上下文过去，一来一回，小几十万，token，就没了？

A45：写个小工具很快。核心系统咋办。源代码给它？

A46：企业套餐不了解啊，个人套餐现在都是按，QPM，计量，5小时，每周，每月都有限额，稍微上点规模的开发都不够用。现在都是微服务。

A47：200美元包月其实是不够电费的。现在不努力烧，Token。以后大部分人将烧不起。

A48：写个poc和一个可以实际使用的系统是完全不同的。

A49：写个，poc，都能烧到你心慌，正规开发根本不敢想，本地部署还差不多，不然生产开发用根本不敢想。一点都不慌。

A50：一个有经验的程序员和一个月2000刀的额度，可以大幅缩短开发周期，到原来的五分之一甚至十分之一。这个路径是能够走通的。但是一个小白想要写出一个生产环境的系统，不是100%不可能，过程一样会非常痛苦。在量变和质变的临界点反复横跳，具体取决于场景如何。可以想。这个是不可逆的大趋势。

A51：所以嘛，目前还是一个有经验的开发+ai，给他做力工最划算。

A52：这么说吧，现在求职面试，既要古法编码，也要会用AI外包，纯手搓找不到工作了。

A53：有经验的开发+ 智能打字机，可能是目前，ROI，最好的落地路径。另外就是补充部分，Knowledge，和，how，的缺失。人类需要补充what，和why。

A54：你光用AI外包也不行，因为你水平不如他会被他忽悠。得配个牧羊人。

A55：另外就是小的创业团队，如果你的项目是万事俱备，只缺一个程序员了，那么烧，token是最好的选择。放牧，AI。

A56：使用者决定AI上限，AI更像一个初级角色，需要资深的人来安排任务审核成果。另外这些都是有学习成本的，毕竟生成的不满意不退token。

话题二：大家公司内部有用过云电脑或者云桌面的吗？不知道用起来会不会有啥问题。

A1：问题多了去了……但是又非得用，主要是数据安全的考虑。比买电脑贵多了。

A2：用过，当时受限配置，成本，管理能满足需求，但是用户体验不太好。

A3：不用就一个问题（数据安全问题），用了一大堆问题。指私有云桌面，更深是公有云桌面？

A4：就是现在，我看有公司再推，说是通过云电脑，来代替，PC电脑，还有推一些私有云电脑说是可以解决数据安全问题。想问下这方面有没有了解的。目前看到这玩意好像并没有大面积被推广起来。一个云电脑，大概什么成本1年。能有具体的案例么？比如哪方面的体验很差？

A5：云桌面并不能完全解决数据安全问题，可能还得配套着做好数据外发的管控，尤其是通过邮件的外发。

A6：50个终端一套，第一次采购成本40多w，某服家款。

A7：好多公司是用的云桌面吧。有员工在外面的经常出差的。VPN连公司的云桌面。

A8：云桌面的成本是真的贵但是的确能解决一些数据安全的问题。成本基本上是同配置电脑的两倍以上吧。啥叫同配置……根本没法比。

A9：用起来是不是会存在卡顿～没有真实电脑这么丝滑。

A10：看投入多少资源，以及业务类型，如果很多图形处理类工作的话，可能和本地差距会很大。云桌面差不多20年了，技术早已经成熟了。

A11：我认为：

目前云桌面是可以解决一部分问题，对数据安全，统一控制有很大帮助，但是引入了更多的问题
目前云桌面的建设成本与运营成本估计是普通计算机的2倍以上，硬件部署，网络升级，软件授权，维护备份等。
总结，我强力不推荐。

A12：费用高，运行不太流畅，要运行流畅，费用就更高，而且要配置统一硬件。

A13：研发图纸设计相关的强烈不建议云桌面啊。那体验感太差了。

A14：还是要看你数据安全需求，如果数据泄露了对公司影响很大、防泄漏要求很高，那完善的虚拟桌面防泄漏方案，相比于终端DLP之类的方式，安全性还是高很多的。我们用的是公司电脑+vpn。

A15：以后都agent了，还要啥桌面。防泄密考虑上个软件？

A16：软件安装覆盖度、策略运营和落实，其实很难保证100%的。再加上有些软件自身稳定性也不好，莫名其妙会失效。比如有些大公司老板说，我核心数据泄露的价值，比DLP软件公司市值都高，我怎么相信他是安全的？

A17：重要研发，数据敏感的全部内网化，直接数据外拷端口物理锁死，严格专网话，比什么DLP，数据防泄漏有用的多。

A18：这个就是官僚思维了。在强监管的地方封闭可能有市场，民企，外企，互联网行不通。

A19：其实在国外很成熟啊，员工通知离职，下午就可以走了，赔偿给到位，数据都在云端。怎么到这就成了懒政、不作为、乱作为？

A20：因为体感差啊，我说rdp第一梯队ctrix，没人反对吧。你看这些国产厂家有几家能做到ctrix这种能力的。合着只要合规，不要体验，这不是懒政这是啥。

A21：怕别人卡脖子，现在软硬件都要国产化。即使国产的不尽人意。也还是要用国产。体验是相对的。

A22：好方案用不了，还贪便宜，要用垃圾方案，那咋办，数据保护在端上也可以做啊，AAD+intune+pureview，全套丝滑不好么。电脑来了开箱即用，员工离职瞬间锁机。

A23：除了依赖微软云外，没什么不好，零信任和虚拟桌面已经是不同的路线了。虚拟桌面一般是对比“需要去操作间”的体验优化。如果选择零信任不用考虑虚拟桌面。

A24：嗯嗯，看ppt都很牛逼，问题都是在使用中暴露的。是，经常被挨叼，但是单位几千台设备怎么保证时时刻刻百分百覆盖，不失效。很难。

A25：如果有这个要求，散乱的电脑在线都解决不了。虚拟桌面能满足。

0x2 群友分享

【安全管理】

《人与AI协同的漏洞分析新范式——Copy Fail发现过程解析》

《48小时打款，估值6万亿》

《人类史上最大规模的财富转移，韩国人赌对了》

《杭州这家民营AI公司，提前53天预警美军打击伊朗》

【法规解读】

《审慎部署智能体AI服务》指南

《OpenClaw类智能体部署使用安全指引》征求意见

《最高法发布人民法院依法惩治侵犯公民个人信息犯罪及关联犯罪典型案例》

【安全资讯】

《突发：DAEMON Tools遭投毒！全球 100+ 国家的数千用户受影响》

《Cursor 删库9秒毁了一家公司？资深开发者讲了大实话：把数据库交给AI的那一刻，公司就已经没了》

《Canvas遭黑客攻击，全球近9000所学校受影响》

《Dirty Frag 漏洞爆发！影响9年Linux内核的“确定性”提权漏洞》

《Harness Engineering：耗时一周，我是如何将应用的AI Coding率提升至90%的》

《五一假期，我花了3.5亿Token，从零写了一套企业LLM WiKi》

《Codex Chrome 插件来了｜但国内用户安装失败、连接不上、怎么用。这一篇全部搞定》

往期群周报：

安全观察：AI攻防升级与网络安全审查两大热点解读｜总第314周

开源邮件安全检测与内部邮箱盗用防护：小模型方案评估及群发拦截策略｜总第313周

OpenClaw的风险隔离与管控应对，以及渗透测试的报备合规探讨｜总第312周

如何进群？

如何下载群周报完整版？

请见下图：

‍

阅读原文

跳转微信打开

安全观察：AI攻防升级与网络安全审查两大热点解读｜总第314周

Mon, 13 Jul 2026 08:00:00 +0800

原创群秘 2026-07-13 08:00 北京

本期周报简介：

1、AI正重塑网络攻防格局，面对漏洞发现自动化、智能体安全风险和传统防护能力失效等问题，企业安全建设应优先补齐哪些能力？

2、企业如何准确识别网络平台运营者身份，并建立网络安全审查预判及采购合规机制？当前制度执行中存在哪些问题？

0x1本周话题

话题一：最近，Anthropic 发布的新模型 Mythos 在 AI 安全领域引发了广泛讨论。与以往面向开发者开放的模型不同，Mythos 选择仅向少数合作机构开放，其自主发现零日漏洞的能力和背后的合作机制，也让不少业内人士开始重新思考：AI 是否正在重塑网络攻防体系，甚至开启新一轮 AI 网络安全竞争？

《AI 网络安全军备竞赛已经开始：Anthropic Mythos 解读》

A1:理论上来说，应该要用魔法才能打败魔法，否则就是落后挨打。但公司没有魔力给我用。我也不知道该怎么办。

A2:其实一切都在安全范式本源。没有魔法，只是世人不愿意努力，只希望天降魔法，解一切困难。疏不知这波自主智能体给攻击方以神兵利器，给防守方以一堆猪队友。其实现在只是抽水机转起来，让之前呼弄事的防守暴露出没穿底裤而已。

A3:同意。我觉得比漏洞发现不是正确方向。这个案例很典型，再怎么安全范式，人家一个数据包就把你打崩了，根本不进入后面的应用逻辑，没办法告诉老板我有纵深防御我不怕0day，其实很怕，而且会越来越多。

真实案例：
OpenBSD 27年漏洞——一个存在了 27 年的远程崩溃漏洞，攻击者只需连接到目标机器即可使其崩溃，OpenBSD 是地球上最以安全著称的操作系统；FFmpeg 16 年老 bug——一行被自动化测试工具跑了 500 万次都没触发报警的代码被 Mythos 发现，知乎 FFmpeg Maintainer @quink 评价“这个 bug 大约是塞尔达里波克布林的级别，再低级的怪物只有丘丘胶（史莱姆）和小蝙蝠了”；Linux 内核攻击链——Mythos 在内核中自主串联多个漏洞，实现从普通用户权限提升至完全控制系统。

A4:一个包就崩的洞不可怕，可怕的是你连基本的流量日志都没有，没有能力分析漏洞机制。这种洞在平时也就是最多一个小时止血的事情。另外真怕这种一个就崩的洞，那就应该多支持我们把星绽这种免崩溃的新体系做好。真正的高危神洞是有限的，天下没有那么多的容易用的洞。

另外每一个openclaw都自带两个超危漏洞： ODCE：基于自然语言的大模型Agent天生就自带开放动态命令执行Open Dynamic Command Execution漏洞，只要做system prompt越狱，就能实现任意指令执行攻击，而这种越狱普遍性的非常容易。攻击者可以任意调用接入agent的rag,tool,以及mcp互联的其他agent。而且可以从与Agent链路的各个生态位发起攻击 UBCE（无界上下文暴露）：全量敏感数据始终暴露在无法收敛的泄露风险中。

智能体的上下文记忆不做任何密级区分和任务隔离，跨系统数据在同一个“记忆池”中自动汇聚，产生任何单一系统都不允许存在的高价值关联数据集。更危险的是，智能体的文本加工能力使敏感数据可被摘要、改写、编码后隐蔽外传，传统DLP手段几乎无法拦截。不用Mythos就能挖出来，漏洞威力比Mythos挖出来的大部分漏洞都要严重得多，这些也没见你们害怕啊。

现在其实是安全同学们理直气壮跟老板说“你看，就是之前安全投入太低了，现在Mythos来了，我们扛不住，必须增加安全投入”对吧？大好时机。

A5:是啊，这个漏洞能被感知。感知不到的呢？组件太多了，不敢说它们就比openbsd强。这篇文章想传达的就是这种焦虑。

A6:其实所有的api对外接口比openbsd要理清可容易太多了，但我不知道有几家是真正理清楚ovtp相关要素后才上线的。真的理清楚以后，你其实基本不必担心那些盲打的攻击尝试，而且可以在后台把这些尝试变成你自己的-1day。但连该做的api梳理都没做的时候，该担心的是mythos么，只是mythos让这些筛子更加明显了而已。

A7:未来防守方走到白名单机制了，只对自己对应的数据进行防护。所以每个企业都要具备Mythos级别的模型能力，算力上要覆盖自己对外的所有api和组件，达到提前发现漏洞的结果，用魔法打败魔法

A8:大部分企业的业务复杂度不需要Mythos级别，但应该用claude code+kimi 2.5去帮着查OVTP的满足情况，然后考虑怎么补全。魔法都是用来骗外行的。

智能革命时代：自主智能体兴起与安全范式重塑自主智能体兴起引发全行业变革，但智能体内置ODCE（自然语言即攻击面）与UBCE（无边界上下文暴露）两个架构级超危漏洞，导致RBAC、零信任等传统安全模型全面失效。当下攻击能力因自动化而极大提升，被攻击面因智能体自主能力失控而极大扩展，防御成本急剧增加，安全底层范式亟须重构，需要三层范式协同：HOP可信执行范式将意图显式声明为结构化规范，约束智能体在规范边界内执行、核验、迭代；NbSP零越范式在机制层封死越权路径；OVTP可溯范式在策略层重建多元身份、工单凭证与审计链路。三层协同，才能将攻防对抗拉回可持续均衡。

《蚂蚁集团副总裁兼首席技术安全官韦韬：智能体时代安全底层逻辑崩塌，OVTP范式如何重建？》

A9:这3 个都很难落地啊，目前大模型调用就是用人的 APIKey，服务端可以识别但很难去拒绝吧，第二基于任务调用也依赖于企业的成熟度，目前可以说几乎没有这种基于任务来访问的管理机制，也许小企业的简单场景可以，但大企业里面是混乱的复杂的，各种应用都是自发式建设难以纳入到安全任务管理的范畴。

日志审计就更难了，全流程日志的埋点收集就是一个巨大工程，更别说异常审计也是复杂的，很难从海量日志识别异常，做溯源倒是可以，但收益很低。

A10:我个人理解，在技术的变革时候，还是要努力做对的事，路虽远行则将至。结合传统安全的经验但别纠结，对AI安全时代充满想象力，重点在落。借楼问个问题，大家都做 AI gateway 么？

A11:对的事是什么，是AI对抗AI，还是追求通解。大模型围栏么，对外提供服务必须做。

A12:这个是最可笑的地方，这些基本工作都没做，却怪担心攻击武器太强，打穿现在稀烂的防线真的需要mythos么？早就和大家说上切面吧但有几家能下决心做的部署了RASP就觉得已经完工了。

A13:围栏可以挡一部分，但不是银弹，看到过一篇论文，基于密码学论证了不可能用一个能力弱的模型实现一个有效的安全围栏，去保护能力强的模型。

A14:大模型网关必须部署，否则nbsp收敛都是笑话。加入联盟又不要钱，大模型身份的核心是知道企业中各个核心数据都发散到哪儿去了，特别是大模型服务的token日志里，否则数据泄露都不知道是哪儿漏出去的。

A15:去年商业化部署都快10万点了，本来就不是只限于联盟内的，国内真正为了安全买东西吧，我就不说啥了，就没几个真的为安全出发的。

A16:AI发展挺好的，终于可以裸泳了。

A17:切面这套体系依赖于基础工作是否扎实，也不虚，就是舍得持续投入。

A18:大多数时候，我们是要解决眼前的苟且。但在这个群里面都是行业里面的精英，也是一个吹牛皮务虚的地方，还是适合讨论一下诗与远方。我想问下大家，在没有最先进大模型的情况下面，有没有其他路可以走，来达成攻守的平衡？

Q：要解决AI场景的什么安全问题？

A19:为了应付mythos，目前第一波先用kimi2.5加专家经验，排查自己所有api的ovtp范式满足情况，然后该修的修，该关的关，做好预案。

A20:做到每个执行都是基于“任务”，需要设定权限和许可的工作场景，需要全链路埋点日志，基于行为偏差，就能找到 99%的异常行为了，但这个工作费力费钱，也不需要什么高大上技术。

A21:有两个AI安全，第一个是应用AI自身带来的安全问题，第二个是AI的发展对安全的挑战和颠覆。眼前的课题是第二个，漏洞极速爆发，传统修漏洞的做法不可行了。

A22:其实根本谈不上费力费钱，投入肯定不到研发总投入的2%，只是还债而已。以国内安全实际投入普遍低于研发总投入0.2%的稀碎现状而言，实在没啥好抱怨的。及格线是5%。

A23:同意，不过落地实操非常难——我个人的理解是:网络安全最大的敌人不是外面的黑客，而是技术债、部门强、组织成员的意识。

A24:大模型安全成本还是比较高的，2%不够吧，我们去年就开始对接了阿里的大模型护栏，为了做好安全，输入输出包括内部的一些Agent的调用，自己做了hook也对接进行提示词拦截，成本快要超过我们用的大模型本身的token成本了。

A25:就是公司通用大模型烧的token成本和安全大模型的内容和提示词注入的成本快持平了。

A26:大部分公司安全研发比不到1/200，研发搞研发的，安全搞安全的。

A27:非常认同，业务口部署智能体，接上互联网的理由十足，没人提安全，问就是我们做业务的不懂啊，所以，如果再追问一句，再高的道，应该是如何平衡权责利，不能肉都给业务吃，肉汤给研发运维，板子只打网络安全。

A28:我花了几个月时间，把各种业务链路对接了，然后运维给我报成本，我惊呆了。自主智能体能省研发的钱，反而会让安全的投入更加重要。

A29:从安全4 个象限来看，数据泄露危害他人（社会、国家）最严重，自身反而小（商密除外）。所以也就驱动力不足，合规管控也没这么严格，每家公司的法务、PR 都能斡旋降低影响。安全的权力和投入也低，至少是不能影响业务发展，也难有一票否决权。

A30:大家都要考虑roi，左移太贵了，右侧搞搞审计吧，至少知道发生了什么。

A31:其实很多大公司在salesforce上的费用，安全本来就占据将近一半，只是国内习惯于安全上不花钱，只在合规上做做样子。

A32:有些行业只能左移，比如金融，web3，量化。不花钱的其实就是安全没那么重要…反正也没啥大事。

A33:我们公司在AI这块目前相当激进，已经推数字员工了，每个员工都搞数字分身。最近我们团队天天加班、技术整改、加固，解决产研自动化AI各个环节的风险，也整了一堆工具部署。

A34:说起数据泄露，群里有讨论“蒸馏常态化”吗？以后mythos打过来，也只是蒸馏而已，和各家的水平越权漏洞毛关系也没有哈。天下没有免费的午餐，整体成本下降，都是有代价的。

《专家解读 | 自动化程序收集公开数据的合法边界》

A35:承重墙偷工减料了，物理规律会让它崩塌，在这种情况下安全投入都是能省就省。软件里面有安全漏洞，没人利用可以一直跑得好好的。所谓的安全债的多寡，它并不客观的；

而且经常出现投入多的，出问题，因为“欠债”实在太多，所谓投入多也并未达到可靠的保障结果的水平。投入少的也不一定出问题，因为攻击有门槛，可以吃的“肉”实在太多，一只羊被吃，一群羊还是可以好好的。这种情况下指望足够投入很难。

AI来了，攻击自动化了，有希望形成一种类似“重力”的均匀力场，让所有组织/系统在同样的压力下接受考验、暴露问题，对攻击者是盛宴，对于防守者也是机会，利用好技术进步红利，加油吧。

话题二：审查办法里的网络平台运营者具体是什么？怎么认定？审查标准流程是什么，有什么指引吗？

A1:我个人理解来说，是这样的：

1.网络平台运营者简单说就是对公众提供服务。然后叠加影响国计民生或者掌握大量数据就要申报，其它还有关基等条件，可以说下你的情况帮你判断。
2.如果风险比较高，挨着边，认定其实还是得咨询网安审查办公室，别人说不属于没用。
3.可以登录网安审查办公室，下载申报材料。各地执行不一定一样，我看有的网上交，有的集中交给行业主管单位，问问审查办公室总没错。企业内还要分企业预判和正式申报流程，并存档预判记录，我们这预判和申报是负责采购的团队在走，没扣给安全。
4.申报动作只是申报书和合同、附加材料，合规的情况其实没啥，主要是如果你是关基、在采购境外产品，或者涉及到了办法中的其它高风险情形，它真的会卡你，也会让你合同不生效，关键是要改企业制度、流程和合同生效条款来符合办法。

A2:直接问网信办就可以了吧，别人经验也只能参考，不一定适合。

A3:谢谢详细的回答，受益匪浅。

1.审查办法里出现的网络平台运营者未见有发文定义，cii是有条例定义，然后各保护部门搞认定规则，按照规则去认定走流程，相对清晰一点。不同的行业对cii运营者的定义也不一样，有的直接是cii运行单位，有的是cii运行单位的上级集团公司。这个差别就涉及到后面的审查范围，另外有的cii运营者也可能是网络平台运营者但没有依据和明确参照标准。
2.审查办公室的电话打过几次，没接通，官网也没找到相关模板，已发邮件咨询待回复。
3.预判、影响分析、申报及与保护部门衔接等各环节流程内部也没有完全清晰，职责边界明了会更顺畅一些。

A4:实务上讲,网信也是监管,人少事多,网信还是得主动互动. 如果主动拜访觉得麻烦,网信搞专项活动时,多加几个负责人,这些问题点对点问可能效果更好. 之前我司也走网信类似要求,很耗费人力,后来点对点咨询,对方一听,就说实际不用申报。

A5:确实是很多其实可以不用申报的，但是中间还有保护部门，有时候要求不完全一致。

A6:从现实角度看，不出事你预判全部判定无需申报也可以这么操作，但出事就要罚了，谁判定的不用报，所以关基单位都不敢的，慢点就慢点，不做就不做，被罚才是要命的。

Q:请教下，关基条例19条“运营者应当优先采购安全可信的网络产品和服务；采购网络产品和服务可能影响国家安全的，应当按照国家网络安全规定通过安全审查。”目前是怎么落实的，谁来评估是否可能影响国家安全，如何发起安全审查？

A7:买XC、AK目录的产品？

A8:都给你统一定好要求了。

A9:买目录内的就免安全审查了吗，不是目录内的怎么采?

A10:gj和xc要求不一样的啊，不能混在一起搞。谁来评估是否可能影响国家安全，如何发起安全审查？

A11:xc也就是ak公布的只有os、芯片和数据库，但是工作要求涉及系统、各类硬件设备。我们和人行、总局就这些非公布设备进行过多次交流，基本上已经明确了采购原则。

A12:你说的网审是gj的内容。根据gj的要求，gj单位内部需要评估出gj系统的范围。针对gj系统及其硬件资源严格按照《网络关键设备和网络安全专用产品目录》采购，如果确要采购，我们是信息技术部向监管的对应管理单位发函，请求发起网审。

Q：现在关基都是这么干的吗，直接报审查材料给到国家互联网信息办公室？

A13:报给行业的归口管理单位，材料都是刻盘后现场提交。

0x2 群友分享

【安全管理】

《Mythos风暴将至，250位CISO闭门交出可落地方案》

《漏洞永远修不完，“带洞防护”成必然——奇安信发布Mythos应对白皮书》

《复现与修复指南：Linux内核本地提权漏洞Copy Fail（CVE-2026-31431）》

《Ghost Bits（幽灵比特位）自查工具发布：检测高位截断与WAF绕过风险》

【法规解读】

关于印发《网络安全标识管理办法》的通知

【安全资讯】

《突发：史诗级漏洞，732个字节通杀所有Linux！》

往期群周报：

开源邮件安全检测与内部邮箱盗用防护：小模型方案评估及群发拦截策略｜总第313周

OpenClaw的风险隔离与管控应对，以及渗透测试的报备合规探讨｜总第312周

从终端沙箱到AI Agent：安全隔离的演进与安全角色的重塑｜总第311周

如何进群？

如何下载群周报完整版？

请见下图：

‍

阅读原文

跳转微信打开

平安健康医疗科技有限公司诚招安全人才｜总第64期

Wed, 08 Jul 2026 21:04:00 +0800

群秘 2026-07-08 21:04 北京

‍‍

‍‍今天是第64期，平安健康医疗科技有限公司诚招安全人才！简历速来！

公司介绍：

平安健康医疗科技有限公司（股票简称：平安好医生，1833.HK），成立于2014年，是平安集团医疗养老生态圈的旗舰，于2018年5月4日在港交所挂牌上市。平安好医生平台全力践行平安集团「综合金融+医疗养老」战略，凭借丰富的医疗健康养老服务支付方资源、广泛的服务供应商网络、完善的服务标准体系、强大的生态资源等核心竞争优势，深耕“家庭医生”、“养老管家”两大核心枢纽建设，现已成为国内领先的医疗健康养老管理服务商。

高级数据安全管理工程师岗

【岗位职责】

1、数据安全体系落地与运营：参与公司数据安全管理体系的构建与完善，推动数据分类分级、数据全生命周期安全管控机制的落地与日常运营。

2、业务数据安全风险评估：深入业务场景评估数据交互风险，识别数据安全与隐私合规风险点，设计并推动合理的管控方案落地，保障业务安全合规开展。

3、日常数据安全管控：负责数据传输/导出等高风险操作的安全审批，开展数据安全事件监控、响应处置及安全合规审计工作。

4、安全需求评审：参与新业务/新系统的需求与架构评审，在设计阶段前置提供数据安全咨询与合规建议，规避业务上线风险。

5、安全项目推进：协助规划并推动内部数据安全提升项目，协同各业务团队提升整体安全水位。

【任职要求】

1、全日制本科及以上学历，具备 5 年以上信息安全相关工作经验，其中至少 3 年数据安全管理、数据安全治理相关实践经验。

2、熟悉《网络安全法》《数据安全法》《个人信息保护法》等法律法规，在数据安全治理及隐私保护方面有实际落地经验。

3、熟悉数据分类分级、数据加密、脱敏、数据溯源等主流数据安全技术手段及落地实操经验。

4、具备扎实的安全技术基础，能够独立完成业务需求的安全评审与风险管控。

5、具备优秀的文档撰写能力、跨部门沟通协调能力及项目推进能力，抗压能力强。

【工作地点】深圳前海‍‍

【薪资范围】面议

【招聘名额】1位

简历投递

渠道一：zhangtianli594@pingan.com.cn

邮件主题请注明：【姓名+岗位+社会招聘+君哥内推】

渠道二：简历直接发给群秘：

aurorayv@163.com，对接招聘方内推渠道。

‍

跳转微信打开

万字图文，带你吃透Prompt工程 && Context工程 && Harness工程是如何演进的

Fri, 26 Jun 2026 11:53:00 +0800

阿杰agent 2026-06-26 11:53 北京

以下文章来源于：阿杰Agent开发日志

阿杰Agent开发日志

阿杰教AI | Agent开发工程师的避坑笔记专注RAG系统设计 / Agent架构实践 / LLM工程化不讲PPT架构，只聊能落地的方案 🎯

导读：你是不是也觉得"调好 Prompt 就万事大吉"了？说实话，小编当初也这么想。但随着项目越做越复杂

导读： 你是不是也觉得"调好 Prompt 就万事大吉"了？说实话，小编当初也这么想。但随着项目越做越复杂，我才发现——Prompt 只是起点，后面还有两层更硬核的工程等着你。本文带你一口气吃透 AI 工程的三次进化：Prompt Engineering → Context Engineering → Harness Engineering，零基础友好。

一、那些年，我们"调 Prompt 调到怀疑人生"

小编自己做 AI 应用的前半年，几乎所有精力都花在一件事上——调 Prompt。

改措辞、加角色、塞示例、排列组合……有时候换一个逗号，结果就不一样。你品品，这像什么？像炼丹。

一开始觉得挺有意思，但项目复杂度上来之后，问题来了：

• 写了个 2000 字的 Prompt，维护起来比代码还难
• 上下文一长，模型就"失忆"，该记的不记、不该编的瞎编
• 接了工具之后，模型动不动就调错函数、传错参数
• 每次发版都提心吊胆——Prompt 改了一行，别的地方就崩了

这时候你会发现：光会写 Prompt，根本不够。

"Prompt 写得再漂亮，模型看不到该看的信息，一样是瞎子。"

小编后来才慢慢悟明白——这三个阶段，是 AI 应用开发工程师必经的进化路线：

阶段	核心关注点	一句话定义
Prompt Engineering	输入文本	设计、优化模型输入（提示词），引导模型输出符合预期
Context Engineering	上下文窗口内容	管理进入上下文窗口的所有信息——放什么、放多少、怎么排列
Harness Engineering	智能体外围基础设施	围绕 Agent 构建约束、反馈、容错、安全的完整工程体系

下面小编详细展开，带你看看这三大工程是怎么一步步演进出来的。

二、Prompt Engineering：一切的起点

2.1 它是什么

💡 一句话定义：Prompt Engineering 就是"学会好好问问题"——通过精心设计你给模型的指令，让它输出你想要的结果。

打个比方：你去餐厅点菜，说"来个好吃的"——厨师可能上一盘你完全不想吃的东西。但如果你说"来一份微辣的番茄牛腩，少油，多给点汤"——得到满意结果的概率就高多了。

Prompt Engineering 干的就是这件事：把你对 AI 的模糊需求，翻译成它能精确理解的指令。

2.2 怎么用

自 GPT-3 问世以来，Prompt Engineering 迅速成了 AI 应用开发的"必修课"。小编自己常用的几招：

① 角色设定：给模型一个身份

你是一位资深的法律顾问，擅长劳动合同纠纷。

② 任务描述：清晰说明你想要什么

请根据以下合同条款，分析甲方是否存在违约行为。

③ 输出格式：指定结构化输出

请以 JSON 格式返回，包含：violation(bool)、reason(string)、suggestion(string)

④ 少样本学习：给几个示例让模型"照葫芦画瓢"

示例1：输入→输出
示例2：输入→输出
现在请处理：新输入→？

⑤ 思维链提示：让模型一步步推理

请逐步分析，先列出关键事实，再推导结论。

说实话，这些技巧在很多场景下效果显著。小编第一次用 Few-shot 把模型输出的格式从"随心所欲"调成"稳如老狗"时，那种成就感——挺爽的。

2.3 但是，局限来了

随着应用场景越来越复杂，Prompt Engineering 的天花板就露出来了：

局限性	具体表现	小编踩过的坑
静态性	Prompt 是预定义的，难以适应动态变化	同一个 Prompt 对不同用户效果差异巨大
孤立性	只关注单次交互，缺乏跨轮次管理	聊了 5 轮之后模型就"失忆"了
可扩展性差	任务复杂了，Prompt 就变成一坨	写到 3000 字的 Prompt 没人敢动
缺乏工程化	靠直觉和试错，没有系统方法论	每次改 Prompt 都是"碰运气"

"Prompt 调得好，只能保证这一次没问题；但下一次呢？"

当你开始问这个问题的时候，说明你该进化了。

三、Context Engineering：比"写什么"更重要的是"模型看到什么"

3.1 从 Prompt 到 Context 的认知跳跃

如果说 Prompt Engineering 关注的是"写什么指令"，那么 Context Engineering 关注的是——

"如何构建送给模型的完整信息环境。"

Anthropic 在官方文档中明确说过一句话：Prompt Engineering 是 Context Engineering 的一个子集。

小编第一次看到这句话时，愣了一下。后来仔细想想——还真是。

Prompt 只是上下文窗口里的"一行字"。但模型做决策时看到的，远不止你写的那行指令。它看到的是整个上下文窗口里的所有内容：

看明白了吗？Prompt 只是八分之一。Context Engineering 管的是这整个窗口：放什么、放多少、按什么顺序、什么该压缩、什么该丢弃。

"上下文工程师不是在写指令，而是在做信息建筑师。"

3.2 Context Engineering 催生了哪些核心技术

在 Context Engineering 的发展过程中，衍生出了几个极其重要的概念。小编按重要程度依次给你捋一遍：

🔍 RAG：让 AI 学会"开卷考试"

RAG（检索增强生成）——2025 年 AI 工程领域最火的概念之一，没有之一。

它解决的问题很直白：

• 知识局限：大模型的知识来自训练数据。你公司的内部文档、最新政策、私域数据——它统统不知道
• 幻觉问题：模型本质是概率计算，经常"一本正经地胡说八道"
• 数据安全：没有企业愿意把私域数据上传给第三方训练

RAG 的核心思路：先检索相关文档，再把文档塞进上下文，让模型"开卷答题"。

打个比方：

没有 RAG 的 AI = 闭卷考试
  → 只能靠训练时"背过的"知识作答
  → 遇到没见过的题就编答案
有 RAG 的 AI = 开卷考试
  → 先在"参考资料"里找到相关段落
  → 基于找到的材料组织答案
  → 不知道就说不知道，不会瞎编

为什么 RAG 属于 Context Engineering？因为它本质上就是在做一件事：动态地往上下文窗口里塞入最相关的信息。

这块内容小编前面已经出了一整个系列，从原理到实战都有，还没看过的朋友可以去合集里系统学习 👉 RAG 系列合集

🛠️ Tools：给大模型装上手和脚

如果没有工具，LLM 就是一个"缸中之脑"——能推理，但不知道现在几点，不知道今天发生了什么，更不能亲手执行动作。

说白了就是：很聪明，但很"无力"。

所以我们给模型接工具：

• 要知道时间 → 接时间工具
• 要知道现实世界信息 → 接搜索或 API
• 要改文件、跑命令 → 接代码执行工具

这条路线一直在进化：

正则匹配模型输出 → Function Calling → MCP 协议层抽象
     (早期)          (稳定期)         (解耦期)

但工具一多，新问题来了：工具描述本身就占上下文，选错工具还有执行成本。所以现在越来越多系统开始做"按需加载"——把工具封装成 Skills，不一上来就把所有能力全塞给模型。

后面小编会单独出一个系列介绍工具调用，这里先挖个坑。

🧠 记忆系统：让 AI 不再是"会失忆的傻子"

随着 Agent 要处理的任务越来越复杂，一个尴尬的问题暴露了——

模型没有记忆。

每次对话，它都像个失忆的人。昨天聊的事今天全忘了。你的偏好、你的历史、你反复强调过的需求——统统重来。

记忆系统就是为了解决这个问题：

• 短期记忆：在单次对话内保持上下文连贯
• 长期记忆：跨会话记住用户偏好和历史交互

这块内容小编之前也出了两期——理论篇和 LangChain 实战篇，后面还会分享如何用 Mem0 搭建企业级长期记忆。

3.3 Context Engineering 的局限

上下文工程非常有效，但它也有结构性限制——它主要影响单次推理。

小编自己遇到过这些场景：

• 模型在某次推理出错了，下次可能还犯同样的错——因为没有"学习失败"的机制
• 工具调用的安全约束靠 Prompt 写的——模型"记得就做，忘了就乱来"
• 上下文变化后，同一条错误路径又被走了一遍

换句话说：

上下文工程能提升"命中率"，但不等于具备"防故障能力"。

当你的 Agent 要上生产环境，面对真实用户、真实流量、各种边界情况——光靠"把正确信息塞进上下文"，远远不够。

这时候，你需要第三层——

四、Harness Engineering：给 Agent 套上"黄金缰绳"

4.1 它是什么

💡 一句话定义：Harness Engineering（驾驭工程）是围绕 AI 智能体构建约束、反馈、容错和持续改进循环的系统工程实践。

它不优化模型本身，而是优化模型运行的环境。

核心哲学八个字：人类掌舵，智能体执行。

"Harness" 这个词来自马具——缰绳、马鞍、嚼子——这是一套引导强大但不可预测的动物的完整装备。

小编给你举个更通俗的例子：

你可以把 AI Agent 想象成一个刚入职的天才实习生。他智商 180，什么都能学，但——

• 他可能理解错你的意思，把客户邮件发到竞争对手那
• 他可能一个人干着干着就跑偏了，你根本不知道他在干嘛
• 他犯了错不会告诉你，默默继续干，错上加错
• 他没有"权限感"，你让他查个资料他可能顺手把数据库删了

Harness 是什么？Harness 就是你给这个天才实习生配的一整套管理体系：

• 工牌门禁（安全边界）——只能进该进的门
• 操作审批流（决策管控）——大事必须请示
• 工作日报（可观测性）——干了什么一清二楚
• 试错培训（容错机制）——犯错有人兜底、有人教
• KPI 面板（度量体系）——干得好不好看数据说话

驾驭工程不是削弱 AI 的能力，而是给它打造一套黄金缰绳，让它跑得又快又稳。

再说直白一点：

没有 Harness	有 Harness
Agent 像个"裸奔的天才"	Agent 像个"有纪律的特种兵"
干对了是运气好	干对了是系统保障
崩了就是崩了	崩了自动恢复
出事了才知道出事了	全程有监控、有预警
每次都是"赌"	每次都有"底"

4.2 为什么需要 Harness？——三大核心约束

你可能会问：Context Engineering 已经很强了，为什么还需要 Harness？

小编用三个真实的"翻车场景"来告诉你：

翻车场景 1：模型今天正常明天抽风

你有一个 Agent，负责解析用户上传的合同，输出结构化 JSON。你测了 100 遍都正常。

结果上线第三天，用户上传了一份格式稍微不同的合同——模型突然输出了一段散文而不是 JSON。后端 json.loads() 直接报错，整条链路挂了。

用户看到的是：白屏。

这就是 LLM 的非确定性——同一个模型，同样的 Prompt，换一个输入它就可能"抽风"。

翻车场景 2：信息太多，模型"选择性失明"

你的 Agent 需要同时看用户画像、历史订单、当前问题、产品文档……加起来 50000 字。

但模型的上下文窗口只有 128K Token。就算塞得下，模型也不会均匀地关注所有内容——它会"选择性失明"，漏掉关键信息。

你在 Prompt 里写了"请务必参考用户历史订单"——有时候它参考了，有时候它视而不见。

这就是 有限上下文窗口 的问题——不是放不下，是模型"看不过来"。

翻车场景 3：Agent 自作主张干了"大事"

你给 Agent 接了文件操作工具。本意是让它帮用户整理文档。

结果有一天，模型"理解"错了用户意图，把一整个文件夹删了。

用户的反馈是：我让它帮我"清理一下"，它把我项目代码全清了……

这就是 外部世界的无限状态——模型能操作真实世界，但它对"后果"没有概念。

看完这三个场景，你就明白了——Harness 不是锦上添花，是生存必需。

总结成表格：

约束	问题（大白话）	Harness 的解法
LLM 非确定性	模型会"抽风"，今天正常明天崩	自动检测异常 → 重试 → 降级 → 兜底
有限上下文窗口	信息太多，模型看不过来	Token 预算管理 + 优先级排序 + 分层压缩
外部世界无限状态	模型能动真东西，但不懂后果	沙箱隔离 + 权限最小化 + 操作审批

小编用一个更直白的类比：

Harness 就是给 AI 安装了三套系统：
• 保险丝（非确定性）——电流异常自动断电，不会烧坏整个电路
• 仪表盘（有限窗口）——驾驶员一眼看到最关键的信息
• 安全气囊（外部世界）——真撞了也不会致命

不再是"崩了就崩了"，而是"崩了有人兜底、有人报警、有人善后"。

4.3 六大设计原则（用大白话解释）

一个合格的 Harness 系统，必须遵循这六条原则。小编逐条翻译成人话：

① 为失败而设计（Design for Failure）

把失败当成常态，而不是意外。

大白话：你家的保险丝为什么存在？不是因为你"计划"短路，而是因为短路迟早会发生。Harness 的第一原则就是：假设 Agent 一定会出错，提前把"出错了怎么办"设计好。

具体怎么做？小编举个例子：

场景：Agent 要调用天气 API，返回用户所在城市今天的天气。
没有 Harness：
  API 超时 → 程序崩溃 → 用户看到 500 错误
有 Harness（为失败而设计）：
  API 超时（3秒无响应）
    → 第一道防线：自动重试（最多 2 次）
    → 第二道防线：切换备用 API
    → 第三道防线：返回缓存的上次天气 + 提示"数据可能延迟"
    → 兜底：告诉用户"天气服务暂时不可用，请稍后再试"

层层兜底，永远不让用户看到"白屏"。

② 契约优先（Contract-First）

大白话：你能用一句"别删我的文件"来防止别人删你文件吗？当然不能。你需要的是文件权限设置——技术层面的保障。

同理，在 Harness 里，不是靠"在 Prompt 里写 '不要调用危险函数'"来约束 Agent，而是靠代码级别的契约来保证。

❌ Prompt 约束（不靠谱）：
  "请注意，delete_file 函数很危险，除非用户明确要求，否则不要调用。"
  → 模型可能忘了、可能误解、可能直接忽略
✅ 契约约束（靠谱）：
  Schema 定义：delete_file 函数标记为 "requires_confirmation: true"
  → 代码层面拦截：调用前必须弹出确认
  → 不管模型怎么想，代码都不会让它直接删

Prompt 是"口头约定"，Schema 是"签字合同"。你选哪个？

③ 默认安全（Secure by Default）

大白话：你新办了一张银行卡，默认单笔限额 5000。你不需要做任何操作来"开启安全"——安全是默认的。

Harness 也是这个思路：Agent 诞生那一刻，它的权限是最小的。想做更多事？必须逐条申请、逐条审批。

三个核心概念：

• 最小权限：Agent 默认只能读文件，不能写；只能查数据库，不能改
• 零信任：每一次操作都要验证身份和权限，不因为"上次验过了"就放行
• 纵深防御：一道防线被突破了还有下一道，不把安全赌在单一机制上

④ 决策与执行分离

大白话：军队里为什么要分"参谋部"和"作战部队"？因为做决策的人和执行任务的人，能力要求不一样，风险管控方式也不一样。

在 Harness 里：

• 决策层（规划）：Agent 说"我要删除这个文件"
• 执行层（动作）：实际去删文件的代码

为什么要分开？因为你可以在决策层加一道"人工审批"：

Agent 决策："我判断应该删除 /data/user_records.csv"
           ↓
Harness 拦截：这是高危操作！
           ↓
通知人类审批："Agent 想删除用户数据文件，是否允许？"
           ↓
人类确认/拒绝
           ↓
执行层：执行（或拒绝执行）

决策可以大胆，执行必须谨慎。 中间隔一层 Harness，就是你的安全阀。

⑤ 万物皆可度量

大白话：你去健身房不记录数据，三个月后你根本不知道自己进步了没有。Agent 也一样——不度量，就无法优化。

每一个行为、每一次决策、每一次资源消耗——都必须可度量。

你需要回答的问题：
- Agent 平均每个任务花多少 Token？→ 成本可控
- 工具调用的成功率是多少？→ 哪些工具不好用
- 用户满意度如何？→ 效果好不好
- 有没有触发安全拦截？→ 是否存在风险行为

"没有度量的 Agent，就是一个黑盒。你永远不知道它在变好还是变坏。"

⑥ 数据驱动进化

大白话：好的员工会从每次项目中学习——什么做得好，什么做得差，下次怎么改进。Harness 也要让 Agent 做到这一点。

具体怎么做？把 Agent 的每一次运行都当成一次"训练数据"：

Agent 运行 → 记录全过程 → 标注好/坏 → 分析原因 → 更新策略
                                                    ↓
                                          下次遇到类似情况，表现更好

举个实际例子：

• Agent 连续 3 次在"解析表格"任务上失败
• Harness 检测到这个模式
• 自动调整策略：以后遇到表格类任务，换一个更擅长结构化数据的模型处理

系统越跑越聪明，而不是越跑越笨。

4.4 顶层架构：带边界控制的 REPL 闭环

好了，前面说了"为什么"，现在说"长什么样"。

Harness 的本质，是包裹在 LLM 之外的一个REPL（Read-Eval-Print Loop）容器。

什么是 REPL？你用过 Python 命令行吧？

>>> 1 + 1# Read：读取你输入的内容
2# Eval：计算结果  →  Print：打印结果
>>> # Loop：等待下一次输入

Harness 做的事情一模一样，只不过对象换成了 Agent：

小编用一个"快递员送货"的场景帮你理解每个环节：

Read（感知管控）= 快递员查看今天的任务清单

快递员（Agent）不能随便出门乱跑，必须先看调度系统给他的任务清单。

在 Harness 里：上下文管理器把外部状态（新任务来了）、内部记忆（上次聊到哪了）、工具描述（你有哪些能力）——全部结构化注入给模型。

关键词："该看什么"由 Harness 决定，不是模型自己选。

Eval（执行管控）= 快递员每次取件送件都要刷卡过闸

快递员说"我要进仓库取货"——但他不能直接进，必须刷门禁卡（权限校验），走指定通道（路由分发），全程有监控（异常监控）。

在 Harness 里：调用拦截器捕获模型的每一次"我想做 XX"的意图，先检查——

• 它有没有权限做这件事？
• 参数对不对？格式合法吗？
• 这个操作有风险吗？需不需要人工确认？

全部通过了，才真正去执行。

Print（反馈管控）= 快递员必须拍照上传签收结果

快递送到了要拍照证明；送失败了（地址错误、没人签收）也要记录原因。不能"送完就算了"。

在 Harness 里：执行结果（成功还是失败、返回了什么数据）被结构化封装，重新注入上下文。这样模型下一轮就能"看到"上一步的结果，决定接下来怎么做。

Loop（循环管控）= 快递员反复取件-送件直到今天的单全送完

一个任务完成了，看下一个。直到所有任务做完（任务完成），或者到了下班时间（触发终止条件），循环结束。

小编第一次理解这个架构时的感觉是——哦，原来 LangChain、AutoGPT、Claude Code 底层都是这个模式。

它们的区别不在于 REPL 的结构，而在于每一步的管控做得多细。管控越细，Agent 越靠谱。

4.5 核心机制：解决两大底层矛盾

Harness 最核心的价值，在于攻克 Agent 上生产的两个根本性卡点。小编用最通俗的方式讲清楚：

矛盾一：无限外部状态 vs 有限 Token 窗口

想象一下这个场景：

你是一个客服 Agent，要回答用户关于他订单的问题。你需要看的信息包括：

• 用户基本信息（500 字）
• 历史订单 50 条（每条 200 字 = 10000 字）
• 产品文档（3 万字）
• 公司退换货政策（5000 字）
• 之前的对话记录（2000 字）

加起来接近 5 万字。但你的上下文窗口就那么大——就算物理上放得下，模型的注意力也是有限的，塞太多它反而"选择性失明"。

怎么办？总不能"全塞进去听天由命"吧。

Harness 的解法：像一个高效的秘书，帮模型做信息筛选。

第一步：信息聚合 — 把所有可能相关的信息池子准备好
第二步：相关性排序 — 用户问退货？那退换货政策排第一，产品文档排最后
第三步：摘要压缩 — 50 条订单不用全放，只放最近 3 条 + "共有 50 条订单"
第四步：预算分配 — 给策略文档 2000 Token，给订单 1000 Token，给对话 500 Token
第五步：模板组装 — 按优先级拼成最终上下文，送给模型

一句话总结：不是什么都塞进去，而是"帮模型筛简历"——只把最相关的信息放在它眼前。

矛盾二：文本预测输出 vs 物理世界执行

这个矛盾更好理解。

模型输出的永远是文本。但工具执行需要精确的结构化数据。

比如模型想调用一个发邮件的工具，它需要输出：

{
"tool":"send_email",
"params":{
"to":"zhangsan@company.com",
"subject":"会议通知",
"body":"明天下午 3 点开会"
}
}

但模型可能输出：

好的，我来帮你发邮件。
{"tool": "send_email", "params": {"to": "zhangsan@company.com"...

看到了吗？前面多了一句废话，JSON 也没闭合。你代码里的 json.loads() 直接就报错了。

这不是偶尔发生——在生产环境里，工具调用的失败率可能有 5-15%。

Harness 的解法：为每一个可能失败的环节设计降级路径。

正常流程：
  Schema 定义 → 模型生成调用 → JSON 解析 → 执行工具 → 结果返回
一旦失败：
  JSON 解析失败？
    → 尝试修复（去掉前后多余文本，用正则提取 JSON 片段）
    → 还是失败？重试一次（让模型重新生成）
    → 还是失败？回退到纯文本模式（直接提取关键信息）
    → 全都失败？告诉用户"我需要更明确的指示"
  工具执行失败？
    → API 报错？记录错误 + 重试
    → 参数错误？让模型反思 + 重新规划
    → 权限不足？通知人类审批

类比：就像高速公路的应急车道——正常情况走主车道，出问题了不是原地停车，而是平滑切到应急车道继续走。

核心铁律：状态分离原则
必须将 LLM 视为无状态计算单元。所有跨轮次状态全部存储在 Harness 管控的外部引擎中，严禁依赖模型自己维护复杂状态。

这条铁律怎么理解？小编再打个比方：

你见过金鱼吗？传说金鱼只有 7 秒记忆（虽然这不科学，但用来比喻很好）。你不会让金鱼帮你记账对吧？你会把账记在本子上（外部存储），每次需要的时候翻给金鱼看。

LLM 也是这个道理。别指望它"记住"上一轮发生了什么——每一轮对它来说都是全新的。所以：

• 任务进度 → 存在外部数据库里
• 用户偏好 → 存在记忆系统里
• 之前犯的错 → 存在错误日志里

每次新的一轮开始，Harness 把需要的状态从外部读出来，注入上下文。模型是无状态的，Harness 是有状态的。

4.6 架构分层：控制平面 + 数据平面

当你的 Agent 系统规模变大——不只一个 Agent，而是同时跑几十甚至几百个 Agent 实例——你必须做管控分离。

还是用类比来说：

想象一家快递公司。它有两层结构：

• 总部（控制平面）：决定今天哪个快递员跑哪条线路、每人配送上限多少件、哪些区域暂停配送、紧急件优先级怎么排
• 一线快递员（数据平面）：接到调度指令，取件、送件、签收、反馈

总部不直接送快递，快递员不做调度决策。各干各的，效率最高。

在 Harness 里：

层级	职责	核心能力	大白话
控制平面	决策与管控	任务调度、资源配额、行为规划、策略规则、权限管控	"指挥部"——决定谁做什么、能花多少
数据平面	纯执行	Agent 运行实例、状态存储、记忆管理、沙盒执行环境	"执行部队"——埋头干活、存结果

这个分层是不是看着眼熟？——没错，和 Kubernetes 的 Control Plane / Data Plane 一个思路。也和微服务架构里的"网关 + 服务"类似。

为什么要分？ 因为：

• 控制平面可以单独升级策略，不影响正在跑的 Agent
• 数据平面可以水平扩展（多跑几个 Agent），不影响调度逻辑
• 出了安全问题，控制平面可以"一键熔断"所有执行中的 Agent

4.7 安全治理与度量体系

最后这一块，是 Harness 和前两层最大的区别——它关注系统的长期健康，而不只是单次对话的效果。

小编经常看到一些团队做 Agent Demo 时信心满满，一上生产就翻车。为什么？因为 Demo 里你可以盯着看，出错了手动修。但生产环境里，同时跑着几百个对话，你没有三头六臂去盯每一个。

这时候你需要的就是：自动化的安全治理 + 可量化的度量体系。

安全治理：给 Agent 划定"活动范围"

核心思路：隔离。Agent 干活的环境必须和你的真实系统隔开一层。

4 级沙盒隔离体系（由轻到重）：

级别	隔离方式	适用场景	大白话
Level 1	进程级	只做文本处理、不碰外部系统	给他一间办公室
Level 2	容器级（推荐）	要读写文件、调 API	给他一层楼，但出不了大门
Level 3	轻量级虚拟机	执行用户上传的代码	给他一栋独立小楼
Level 4	完整虚拟机	涉及高敏感操作	关进密室，全程监控

大部分场景用 Level 2（容器级）就够了。小编自己的项目就是这么做的——Agent 在 Docker 容器里跑，就算它"发疯"了也只能在容器里折腾，伤不到宿主机。

除了隔离，还有策略门控——在 Agent 的"决策"和"执行"之间插一道检查站：

Agent 说："我要执行 rm -rf /data"
         ↓
策略门控检查：
  ✓ 权限校验 → 当前 Agent 有没有删除权限？
  ✓ 敏感数据 → 这个路径下有没有用户隐私数据？
  ✓ 注入检测 → 这个指令是用户注入的还是模型自己规划的？
  ✓ 审计日志 → 不管允不允许，全部记录在案
         ↓
结果：❌ 拒绝执行，触发告警

资源管控：别让 Agent 烧光你的钱

这个很实际。小编见过一个案例：有人的 Agent 进入了死循环，疯狂调 GPT-4 API，一晚上烧了 2000 美金。

Harness 的资源管控就是防止这种事：

• Token 预算：每个任务最多用 10000 Token，超了自动停
• API 调用上限：单次任务最多调 20 次工具，超了熔断
• 时间限制：5 分钟还没完成？强制终止 + 返回当前进度
• 退避重试：API 报错了不要疯狂重试（1秒→2秒→4秒→放弃）

一句话：给 Agent 装个"电费表"，不让它无限制烧钱。

度量体系：给 Agent 做"体检报告"

没有度量，你根本不知道：

• Agent 表现是在变好还是变差？
• 哪个环节最容易出错？
• 花了多少资源？值不值？

四大类核心指标：

类别	核心指标	回答的问题
任务效能	成功率、指令遵循度、工具使用有效性	Agent 干活靠不靠谱？
服务质量	端到端延迟、首次响应、错误率	用户体验好不好？
资源效率	平均 Token 消耗、工具调用次数	性价比高不高？
安全合规	策略拒绝率、安全事件数	有没有出事？

小编建议每个做 Agent 的团队，至少关注这四个"黄金指标"：

1. 任务成功率（最核心）——Agent 完成任务的比例
2. 端到端延迟（用户体感）——从用户提问到拿到答案多久
3. Token 消耗（成本）——每个任务平均烧多少钱
4. 安全事件数（底线）——有没有越权、泄露、崩溃

"没有度量的 Agent 系统，就像没有仪表盘的飞机——你根本不知道它什么时候会坠机。"

4.8 一个完整的 Harness 实战场景

光讲概念可能还是抽象。小编用一个完整的场景，带你走一遍"有 Harness 的 Agent"是怎么工作的。

场景：用户让客服 Agent 帮他退一个过期订单。

用户："帮我把上周买的那个蓝牙耳机退了。"

第一步：Read（感知管控）—— Harness 组装上下文

Harness 不会直接把用户这句话丢给模型。它会先干这些事：

1. 从用户画像系统拉取：用户 ID、VIP 等级、历史退款记录
2. 从订单系统查询：最近一周的订单，匹配"蓝牙耳机"
3. 从政策知识库检索：退换货政策（7天无理由、过期处理规则）
4. 组装最终上下文：
   - System Prompt（客服角色 + 行为准则）
   - 用户消息
   - 匹配到的订单信息（只放这一条，不放全部订单）
   - 退换货政策（精简版，只取"过期退货"相关段落）

注意：不是所有信息都塞进去，而是 Harness 帮模型筛选过的。

第二步：Eval（执行管控）—— Agent 做出决策，Harness 审查

模型看完上下文，输出决策：

{
"thought":"该订单已超过7天无理由退货期限，但用户是VIP，可以走特殊通道",
"action":"initiate_refund",
"params":{"order_id":"ORD20250512001","reason":"VIP客户过期退货"}
}

Harness 拿到这个决策后，不是直接执行，而是过一遍检查：

✓ 权限检查：当前 Agent 有退款权限吗？→ 有，通过
✓ 金额检查：退款金额 299 元，在单笔上限（500）内 → 通过
✓ 政策检查：VIP 客户过期退货是否合规？→ 合规，政策允许
✓ 频次检查：该用户本月第几次退货？第 1 次 → 正常
→ 全部通过，执行！

如果有一项不通过呢？比如退款金额超了上限？

✗ 金额超标 → 不执行 → 自动升级给人工客服
→ 同时给模型注入反馈："该笔退款需要主管审批，请告知用户"

第三步：Print（反馈管控）—— 执行结果回注上下文

退款 API 调用成功了，Harness 把结果结构化后回注：

{
"status":"success",
"refund_id":"REF20250518001",
"amount":299,
"estimated_arrival":"1-3个工作日"
}

模型拿到这个结果，生成最终回复：

"您好！蓝牙耳机的退款已经帮您发起了，299 元预计 1-3 个工作日到账。
如果有其他问题随时找我哦～"

第四步：Loop（循环管控）—— 判断是否结束

Harness 检查：

• 用户问题解决了吗？→ 解决了
• 还有待处理的子任务吗？→ 没有
• 用户有新消息吗？→ 没有

→ 本轮结束。同时记录这次完整交互的数据，供后续分析。

全程发生了什么？

用户只看到：问了一句话，3 秒后拿到退款结果。简单、顺畅。
幕后 Harness 做了：
  ✓ 信息筛选（只给模型看需要的）
  ✓ 决策审查（退款前检查权限和政策）
  ✓ 执行管控（通过 API 网关调用退款接口）
  ✓ 结果封装（把 API 返回翻译成模型能理解的格式）
  ✓ 全程记录（审计日志、指标上报）

这就是 Harness 的价值——用户感知不到它的存在，但它让整个过程安全、可控、可追溯。

五、全景总结：三层工程到底是什么关系？

看到这里，你可能会问：这三层是"选择题"还是"必答题"？能不能跳过中间直接做 Harness？

答案是：不能。三层是递进包含关系。

• 你得先会写 Prompt（第一层），才能设计上下文（第二层）
• 你得先会管理上下文（第二层），才能构建完整的 Harness（第三层）
• 每一层都不会消失——Harness 不是取代 Prompt，而是把它包在一个更大的工程体系里

就像盖楼：地基（Prompt）→ 结构（Context）→ 装修 + 物业 + 消防（Harness）。你不能跳过地基直接装修。

小编把三大工程的关系画清楚：

三层是包含关系，不是替代关系。 Prompt Engineering 仍然重要，但它只是 Context Engineering 的一个子集；Context Engineering 又被 Harness Engineering 包裹在更大的工程体系中。

用一张表格做最后的对照：

维度	Prompt Engineering	Context Engineering	Harness Engineering
核心问题	怎么写指令	怎么组织信息	怎么保障系统可靠运行
类比	学会点菜	当好信息建筑师	当好系统运维总监
关注范围	一次对话	一个上下文窗口	Agent 全生命周期
出错了怎么办	改措辞，再试	调整信息优先级	自动降级 + 重试 + 兜底
门槛	会写字就能上手	需要理解 RAG、工具、记忆	需要系统工程思维
目标	模型"这一次"答对	模型"经常"答对	系统"持续稳定"地答对

好了，万字看到这里，你现在处于哪个阶段？

• 还在纯调 Prompt？→ 够用就行，但别止步
• 已经在做 RAG、管理上下文了？→ 你在第二层了
• 开始关注容错、度量、安全、持续学习？→ 恭喜，你正在进入第三层

说实话，小编自己也还在第二层到第三层之间摸索。这条路没有终点，但每进一步，你的 Agent 就更像一个靠谱的生产系统，而不是一个"碰运气的 Demo"。

"从 Demo 到生产，中间隔着一个 Harness。"

你目前在做的 AI 项目，最头疼的是哪个层面的问题？是 Prompt 不好调、上下文管理混乱、还是生产环境的稳定性？评论区聊聊，小编也想看看大家都走到哪了。

往期精选：

通过 AI agent + 通用大模型，实现海量告警研判分析实践

安全验证，实现安全运营闭环实践

附注：

聂君，北京知其安创始人，十余年金融行业信息安全从业经历。好读书，不求甚解。性格开朗，爱好足球。
本公众号是个人对工作生活的一些体验和经历分享，站在不同角度和立场解读会有偏差，见仁见智，不求正确统一，但求真、善、美。

阅读原文

跳转微信打开

通过 AI agent + 通用大模型，实现海量告警研判分析实践

Mon, 22 Jun 2026 06:56:00 +0800

原创聂君 2026-06-22 06:56 北京

每一次人工纠正，都是最昂贵的训练信号，它必须自动进入评测集、判例库和智能体记忆，而不是消失在某条工单备注里。这不是人的价值下降，而是人的价值从重复劳动，迁移到设定边界、监督质量、沉淀经验。

编者荐语

传统网络安全时代的安全运营，最主要的问题是安全设备有没有告警；AI 攻击时代，最主要的问题变成了告警太多来不及处理。AI 攻击带来的日志和告警急剧增加，过去甲方的告警降噪更多是由于自己的告警处理能力不足，只能是不断的对告警做优先级排序，把安全团队能够处理的告警处理掉，而由于安全团队的处理能力边界远小于自身面临的安全风险边界，导致很多安全风险和攻击并没有得到妥善处理，这也是安全事件层出不穷的原因。

AI 智能体加通用大模型技术目前已经具备了5-8 年安全分析师水平能力，并且还在不断快速迭代提升，通过 AI智能体建立数字安全员工来对抗 AI 攻击是完全可行的。过去我们招 1000 个乃至 10000 个安全员工来分析研判和处理告警不现实，但有了算力和智能体可以，从而提升安全处理能力，带来安全性提升。

算力即安全。

（一）引言

2026年4 月，Anthropic 通过 Project Glasswing 披露了一个尚未公开发布的通用前沿模型——Claude Mythos Preview。按官方说法，它的编码能力已经达到"在发现和利用软件漏洞上超过除最顶尖之外几乎所有人类"的水平：已发现数千个高危漏洞，覆盖每一个主流操作系统和浏览器，其中包括一个在 OpenBSD 里存活了二十七年、一个在 FFmpeg 里存活了十六年、扛过几十年人工审查的缺陷——而且大多是在没有人工引导的情况下自主完成的。英国 AI Security Institute 的独立评测也印证了这一点：专家级 CTF 通过率 73%，并第一次端到端完成了一个原本需要人类专家约二十小时、三十二步的企业网络攻击模拟。

当然，AISI也提醒，靶场和真实企业仍有差距——真实环境里有防御工具，也有在岗的防守人员。但比起争论某个模型到底有多强，更值得注意的是那个底层变化：

攻击侧的生产效率变了。
聂君

图 1：AI自动化攻击带来的防御崩溃

过去，一支高水平攻击队的能力，依赖少数顶尖专家、长时间积累、工具链和组织协作。现在，长程智能体正在把这些能力封装成可以反复调用的"agent-hour"——它不疲劳、不厌烦，可以一刻不停地连轴运行，对你的暴露面、弱配置、历史漏洞、凭据泄露、身份路径持续侦察和试探。

当攻击开始以机器速度、机器规模的指数演进，防守方本质上是堆设备、堆规则、堆人员的线性增长，攻击和防御方的效率会越拉越大。

企业安全团队长期面对一组令人窒息的数字：

指标	现实
平均每天告警数量	数千至数万条
告警误报率	高达 40%-60%
平均检测到响应时间（MTTR）	数小时到数天
全球安全人才缺口	约 340 万人

传统模式下，我们用“堆人”来应对“堆告警”。但人的注意力是有限的，疲劳、倦怠和流失率让 SOC 团队始终处于一种“慢性失血”的状态。

过去网络安全时代的安全运营，最主要的问题是安全设备有没有告警；

AI 攻击时代，最主要的问题变成了告警太多来不及处理。

0x1 攻防双方分析

1.1 AI 时代的攻击侧特点

特点一：攻击的边际成本正在归零

过去APT级的单点深度突破，只有少数组织负担得起。现在，一个模型自主运行一次，就能完成过去要专家二十小时的多步攻击，而且这种能力可以反复租用、按token计费。高级攻击从"少数组织的能力"变成"人人可租用的服务"，它的数量必然大幅上升——这是检测漏报、研判过载、处置过载三重压力的共同根源。

特点二：攻击只需单点成功，防御必须全面覆盖

攻击者天然是单点突破逻辑：一个暴露在公网的高危服务、一个弱口令、一个长期没修的漏洞、一个被钓中的员工，只要一个点成功，后面就是横向、提权、驻留、外传。防御则相反，要面对服务器、终端、账号、邮箱、业务系统、外发通道、云资源、供应链接口——任何一个点出问题都可能成为事件。

防御总成本，约等于资产数量乘以单资产的防御成本。攻击成本暴跌之后，如果防守方不能把"一次研判、一次调查、一条规则的维护、一次处置"的边际成本同样压到接近零，这道数学题就无解。

特点三：攻防变成了一场速度竞赛

攻击链智能体化之后，从落点到横向移动的突破时间，会从小时级压缩到分钟级，甚至秒级。而防守方的"检测—研判—处置"链路里，

只要任何一环还留给人工，整条链路就会退化为人工速度。

你检测做到秒级、研判做到分钟级，结果处置卡在"人工看完、人工确认、人工开工单、人工审批"上，那前面的快就白费了。

最后落到两个方向：压低防御的边际成本，用满防守方的结构性优势。

攻击者有强模型，防守方是不是更没法打了？不完全是。

1.2 AI 时代的防守侧特点

特点一：防守方有主场

企业有自己的资产、账号、日志、业务关系、历史行为和组织结构。攻击者的智能体进入环境时是盲的，每一步信息都要靠探测获取，而每一次探测，都是一次暴露机会。

特点二：防守方有平时

攻击发生时时间很紧，但攻击发生之前的全部时间，都属于防守方，而且没有时效约束。画像、基线、预案、盲区排查、狩猎、验证，都可以提前做。攻击者要花很久才能摸清的拓扑和权限关系，防守方的智能体本应在分钟级拿到——前提是这张图你平时就建好了。

特点三：防守方有历史

攻击者每次进来都要从零摸索；防守方手里有过去数月甚至数年的日志，知道一个员工、一台主机、一个账号、一条外发通道平时是什么样子。

特点四：跨客户的复利

攻击手法会复用、工具会复用、路径会复用。如果能把不同客户现场的经验沉淀成规则、画像维度、判例、狩猎假设和评测样本，就能形成攻击者结构上无法对抗的优势：攻击者一次只打一家，安全运营厂商从所有客户学习。

特点五：步数本身就是信号

这里还有一个反直觉、但很关键的点：攻击智能体的"步数"，本身就是信号。

自主探索意味着更多试探命令、更多失败重试、更多枚举动作。单步可以做得很隐蔽，但动作的绝对数量会大幅上升。对于平时就布好了传感器和诱饵的防守方，攻击者越勤快、跑得越久，触碰到信号点的概率就越高。

更强的攻击模型，对一个"地形已经布设好"的防守方，反而更有利。

所以面对层出不穷的新手法，真正稳健的检测思路，不是去追每一种变体，而是抓不变量——不识别"它用了什么新技术"，而是识别"这个实体不像它自己、不像它的同类"；攻击技术再快，总要侦察、总要提权、总要横移、总要外传，把检测锚在攻击链的咽喉上。

问题在于，这些都需要持续投入才能兑现，而"持续投入"恰恰是人力最匮乏、AI 防御智能体最擅长的部分。
聂君

0x2 解决思路

一个经典的安全运营架构包含四个框架：安全防护、安全运维、安全验证、安全度量。

图 2：安全运营框架

2.1 安全防护框架

由于计算机是分层的：网络层、虚拟化层、系统层、应用层、用户层、数据层、业务层，所以安全防护就是通过在每层上部署单点防御，构建一套纵深防御体系。

网络层做安全域划分和隔离等；
系统层安装防病毒和 HIDS等；
应用层有各类 XAST 和 WAF、漏扫等；
数据层部署各类 DLP、数据库审计、API 安全等；
业务层有反欺诈等。

这是过去 20 多年的安全基础建设领域，也是传统安全的主战场。

安全防护框架的主要产出是各类安全日志。
聂君

2.2 安全运维框架

安全防护框架产生的日志太多了，可达 20 万 EPS（events per second），一天是 172.8 亿日志量。甲方普遍做法是建设一套安全大数据平台（有的叫 SOC/SIEM），将这些原始日志统一收集起来，由于安全值班人员能处理的告警有限，甲方会在安全大数据平台上添加黑白名单规则（专业术语叫：UseCase）进行过滤，过滤后产生的告警，才是安全一二线人员每天真正处理的。由于一二线人员处理能力的限制，每个人每天处理的告警在 50 条左右，所以甲方通常处理的告警规模大概在几百到一二千条，通常在 500 条左右。

我们经常能听到一个词：告警降噪。甲方的告警降噪更多是由于自己的告警处理能力不足，只能是不断的对日志和告警做优先级排序，把安全团队能够处理的告警处理掉，而由于安全团队的处理能力边界远小于自身面临的安全风险边界，导致很多安全风险和攻击并没有得到妥善处理，这也是安全事件层出不穷的原因。所以：

500 条，不是团队面临的风险边界，而是团队的处理能力边界。甲方安全团队能力边界远小于自身面临的风险边界。
聂君

由于AI大语言模型的兴起，语义分析理解能力很强。AI 智能体加通用大模型技术目前已经具备了5-8 年安全分析师水平能力，并且还在不断快速迭代提升。

通过 AI智能体建立数字安全员工来对抗 AI 攻击是完全可行，也是当下破解困局的唯一思路。
聂君

过去我们招 1000 个乃至 10000 个安全员工来分析研判和处理告警不现实，但有了算力和智能体可以。提升安全告警处理能力，能够带来安全性提升，算力即安全。

传统的安全运营，误报率和漏报率是跷跷板的两端。但在 AI gent 安全运营方案中，可以同时实现误报率和漏报率的双降。

2.3 智能体建设方案

智能体队伍体系应该如何建设？2026 年的 Google Cloud Next，谷歌为安全运营提供的是四类智能体，包括告警分诊与调查、威胁狩猎、检测工程、第三方上下文增强；我们做“曜鉴”（见备注 1）时，最终落到的也是这四类，再加上智能复核的智能体。长期深入在一线做安全运营智能体的摸索实践，最后大家思路不谋而合。

备注1：“曜鉴”是笔者创立的知其安公司研发的 AI for Security 智能体平台，知其安另一个工具平台叫“离朱”安全有效性验证平台，超过一千家甲方用户使用该平台。

图 3：Google 内部安全团队构建的四类智能体

这四类智能体通过曜鉴叠在现有的态势感知平台之上，串成一条作业线（见下图）。态势感知平台原样保留，做第一轮聚合降噪；曜鉴叠在其上，由调度器做编排与预处理：把告警路由到对应智能体，按需回拉态势感知和设备里的数据、构建上下文；研判完，结论再写回态势感知。现有平台不变，只是后面接上一支随时在岗的智能深度研判队伍。

图 4：知其安曜鉴-安全智能体平台

其中：

告警分诊智能体：每条告警自动分诊、定性、给依据。这一段解决的是"量"；
智能复核智能体：分诊里判为高风险的，交给复核这一类二次确认——复核命中、建调查会话、深度分析、多源取证，必要时发起 IM 协查、接收人工反馈，最后给出结论。这一段解决的是"信"；
威胁狩猎智能体：不依赖告警触发，基于假设主动回溯存量数据，把潜伏威胁和历史漏报找回来；

检测工程智能体：把误报、漏报、新情报回流，自动迭代检测规则与智能体；
第三方上下文增强智能体：引入外部威胁情报和业务、资产上下文，供前面几类调用，让研判知内知外。

但五类智能体本身，并不等于一个可信的闭环。要让它成为闭环，关键在几件容易被忽略的事：研判结论要写回态势感知，研判过程要沉淀成防御资产和智能体记忆，人要在环上抽检；再加两道兜底：整条链路由持续验证盯着，不让它悄悄失效。可信、可控、可沉淀，再加上逐一验证——这就是"没有安全验证，就没有安全运营闭环"在智能体时代的样子。

AI Agent 的本质意义在于：它把安全运营从“人力密集型”推向“智力密集型”。初级分析师的重复性工作——告警分诊、日志查询、IOC 匹配——正是 Agent 最擅长的。

2.4 为什么是通用大模型

过去两年，安全行业一个奇怪的现象，是各家训练自己的安全垂域模型。曜鉴使用的是通用大模型。根因是智能体这套框架，对模型的要求变了。

在智能体里，能做到什么程度，很大程度上取决于背后模型的上限。模型越强，它自己规划调查、拓线、出错后自我纠正的余地就越大。这两年国内外都在往 Agentic SoC走，对模型的要求只会更高：综合推理要强、工具调用要稳。垂域模型在某个单点任务上也许能调出一点点优势，但在这种拼通用推理上限的场景里，很难跟上前沿通用模型的迭代速度。

垂域模型在安全领域效果不好，还有一个原因是安全领域训练数据量太小，质量不高。

至少到今天，在这种拼综合推理的场景里，我们还很少看到哪个安全垂域模型，能稳定达到头部开源SOTA通用大模型的水准。这是任务本身从"单点判得准不准"，变成了"能不能在一个开放问题里一步步推下去"。

模型的智能能力溢出，还得用在对的地方。 Agentic 框架下，更值得交给模型的，是那些不确定、要多步、要跨系统取证的活——比如较深的威胁狩猎、复杂告警的逐层研判。这类事情，没有哪条规则、哪个单一模型能一步给出结论，得一边调工具、一边补上下文，顺着线索往下走。

反过来，把前沿模型放到流量检测这种单点分类上，就没用在它的长处上。那一层要的是毫秒级在线判定，适合使用传统规则、特征；换上大模型，准确率的提升有限，却要多担推理时延和成本。业界对流量检测小模型的尝试更接近把传统 NDR/IDS 做一次 AI 化增强，仍是在单一数据面上做优化。模型真正用得上的地方，是去处理人一时想不清、规则又写不全的那部分。

用 AI 去做流量检测，本质上还是NTA安全设备+AI 功能，对 NTA 安全设备做一次升级换代，这和邮件安全+ AI 功能，主机安全+ AI功能等没有区别，还是安全建设设备厂商借用 AI 名义，再卖一次流量安全检测设备而已。

通过调研数十家金融和能源用户，AI for Security最好的应用场景是：代码安全、安全运营。

在安全运营领域，最好的应用场景是：通过 AI agent+ 通用大模型，对 SOC/SIEM 产生的告警（以及引起告警的原始日志）进行研判分析，提高日均告警处理能力。

甲方日均告警处理能力提升之后，开始拆白名单。很多安全事件是因为攻击者使用白名单通道干了黑名单的事情。
聂君

比如某股份制银行开始将自动化运维系统下发的任务和脚本，同步一份给 AI agent 复核，区分下发的自动化任务和脚本，是真正的生产运维的业务需要，还是自动化运维系统已被攻击队控制下发的是恶意脚本。

我以前在银行和安全公司工作负责内部安全防守时，均在内部攻防演习时被蓝军（红队）这么干过。

2.5 智能研判靠的是上下文工程，不是吞吐量

要让模型把"人想不清、规则写不全"的那部分处理好，光靠模型强还不够，还得让它在足够高质量的上下文里判。这是"模型之外"的另一面：上下文。研判准不准，关键不在一天过了多少条，而在判每一条时，手里的上下文够不够全、够不够准；而把上下文取全取准，要花时间、调接口、跨系统去查——这跟"求快、求量"本来就是两个方向。

流量检测大模型厂商，通常使用一个小而快的模型，把每天上百万条全过一遍，比的是处理量，从实践看来是靠不住的。

流量检测大模型的做法是海量告警先用快系统过一遍、做降噪和分类，它解决的是"量"，不是"信"，不能当成最终研判。一个小模型在上下文严重不足时一天判一百万条，这些结论很难直接采信，结果还是得靠人去抽检——想省的人力又回来了。

更致命的是，流量检测大模型能看到的信息有限，并没有跳出"凭有限信息下判断"这个老局限：和规则一样受制于"看到的太少"，躲不开漏报，也挡不住稍复杂、高级一点的攻击。而这些，正是我们一开始就想解决的问题。

研判要判得准，前提是提供足够高质量的上下文，至少有三类：

一是资产 CMDB，少了它，内对内的流量会大量误报。某头部券商现场，接入资产 CMDB 之后，智能体的研判准确率明显好转。一个常见的例子：NDR 按传统规则，会把 AI 代码开发工具的正常交互，报成 webshell上传；而智能体拿到资产信息、知道对端是一套代码辅助系统，就能认出这是业务流量，噪声随之降下来。

二是威胁情报，以及情报跟不上时的补位。内对外那类恶意外联，多数查一下情报就能定性，不必动用大模型；真正需要智能体的，是情报覆盖不到的地方。最典型的是钓鱼邮件——一个刚注册的钓鱼站点，威胁情报对这种新域名往往滞后。这时候只靠情报不够，得让智能体调 URL沙箱，把站点截图和页面内容取下来分析，再结合邮件正文的上下文，给出综合判断。

三是现场的值班知识，否则 AI 不了解内情也会判错。还有一类上下文不在任何系统里，只在值班人员的经验里：内部安全设备的拓扑、出口 IP、扫描器地址、企业里那些"不规范但其实正常"的业务习惯。这些得靠现场调研，整理成 AI 能用的研判知识。否则 AI不了解内情就会误判——一个看着"经常恶意外联"的源 IP，可能只是台 DNS 服务器；一个"频繁发起扫描"的源 IP，可能是公司自己的漏扫器。

资产、情报、现场知识，归根结底是同一件事：让模型在尽可能完整、准确的上下文里做判断。而这恰恰是"小模型刷量"给不到的。

这两年，业内也大致走到同一个判断上。从2025 年6月开始，上下文工程（Context Engineering）的提法开始流行——Karpathy 的说法是，在每一步给上下文窗口填进恰到好处的信息。

这也是我们选择通用大模型加 agentic 框架的原因：与其用一个小模型把上百万条都浅扫一遍，不如让一个足够智能的模型，在上下文取齐之后，把真正该深入调查研判的，判准、判透。

这些事指向同一个目标：泛化。安全运营最怕漏掉真实攻击，而漏报往往来自模型没见过的那种变体。垂直训练能让模型在某类样本上更顺手，但也容易把它的视野收窄；通用模型底子更宽，再配上尽量完整的上下文，模型对没见过的攻击才更可能反应过来。

2.6 对安全团队意味着什么

安全团队不会消失，但安全团队的结构会被深度重塑。

角色的重新定义

传统角色	未来演进方向
L1 分析师（告警分诊）	大部分工作被 Agent 替代
L2 分析师（深度调查）	转向 Agent 监督者 + 复杂场景处理
L3 / 威胁猎手	价值放大——专注于 Agent 无法处理的高级威胁
安全工程师	新增职责：Agent 策略设计、护栏配置、效果调优
CISO / 安全负责人	需要理解 AI Agent 的能力边界和风险

AI Agent 消灭的不是“安全岗位”，而是“重复性安全劳动”。 但如果一个团队 70% 的人力都花在重复性劳动上，那“消灭岗位”和“大规模重组”之间的距离，其实很近。

（二）落地实践

0x3 智能体实践：原理简单，区别在于工程化

文章：《安全验证，实现安全运营闭环实践》提到：飞机起飞的原理很简单，只要速度够快，机翼上下的压力差就能让它起飞；但真正造出飞机、建起整套航空体系，是极有门槛的工程。

安全智能体也是这样。让模型回答一条告警有没有风险，不难。让它在真实客户环境里长期、稳定、受控地参与安全运营，才是难的地方。

3.1 模型的三个限制

当前主流模型有三个限制：

第一，模型号称多模态，但它的多模态很有限。它能处理文本、图片、音视频，却做不到对eml 邮件、对 Word/PPT/Excel、对 PDF、对 zip/rar/7z 多层压缩、对嵌套 Office、对 pcap 流量包的"多模态"解析。这些全要靠工程化的预解析能力先喂给它。

第二，模型的预训练知识是"过期"的。它的知识可能停在去年某个月份，对网络安全里高频变化的资产数据、威胁情报、新上线的钓鱼URL、刚传到图床的钓鱼图片、员工邮件往来历史、某个资产近七天登录的 Top 来源，统统不了解。不接实时情报、不接资产、不接 URL 沙箱，它就只能靠"编"。

第三，模型的上下文窗口有限。我们做过一个很朴素的测试：用一个128K 上下文的国产开源模型研判 Webshell，一个 248KB 的文件就要消耗约 9 万 token。而真实场景里，一份超长的 DLP 外发文档可能十几万字，一个绕过用的大马可能超过 2MB，一千条暴力破解日志可能被聚合成一个告警。后来我们用滑动窗口分片、逐片摘要、累计风险分的方式做智能上下文压缩，才把一个 128K 模型能处理的文本量，从通常的 500KB 提到约 15MB，提升了三十倍。

这三个限制决定了：智能体的效果，七分在工程，三分在模型。以邮件安全场景为例：

三级压缩的附件没解全，结果把一封钓鱼邮件误判成了业务邮件；
解压密码藏在邮件正文的二维码里，识别不出来，解密失败；

附件其实没加密，但AI 从正文找到一个"假密码"后，就再也没尝试无密码直接解压；
邮件正文只引用了一张互联网图片，正文为空、图又下载不下来，于是误判；
压缩包里有exe，解压后没把目录树列给 AI 看——而在有些客户那里，附件带 exe 是要直接拦截的高危行为，AI 却因为拿不到目录结构而判错；
附件解密失败时，后端没把"解密失败"这个事实告诉 AI，AI 在信息不足的情况下，把它当成了业务邮件——正确的做法是判"信息不足"；
eml 里的 html 内容太长，模型直接不遵循指令、开始乱答，我们用 html2text 把无关内容裁掉才稳住；
员工用Word 里再嵌套一个 Word 来绕过 DLP 检测；
还有一个：员工外发被拦了好几次，最后把手机号第一位的数字"1"改成字母"l"，绕过了规则，发了出去。

这些坑指向同一件事：

在客户现场，决定AI研判成败的，往往不是模型聪不聪明，而是一个加密附件能不能解开、一段 html 要不要裁剪。

这正是当年"Top30失效点"的AI 版本——高级威胁，常常栽在低级问题上。

3.2 编排还是自主规划

在做主机安全告警的研判分析时，我们快速迭代了三个版本：

3.2.1 第一版，单条告警研判

输入一条告警，直接输出结论。简单直接，但缺上下文，误报很多——它根本不知道这台主机、这个账号平时什么样。

3.2.2 第二版，固定剧本调查上下文

我们让它先去查完整进程链、账号属性、异常登录、计划任务，再做判断。研判依据是丰富了，但调查步骤是固定的，本质上还是传统SOAR 剧本，一遇到复杂场景就不够用——因为真实的安全调查，常常是查完 A 才知道要不要查 B，第一次查询失败了还得改参数、换工具、换路径继续查。

3.2.3 第三版，基于Skill框架加调查 SOP 的自主规划

我们把HIDS、资产查询、日志检索这些能力封装成 Skill，让 AI 依据 SOP 自己制定调查计划、自己选择调用哪个工具、根据结果继续拓线、调用失败了自我修正。同一个工作流还能兼容不同版本的设备。这一版得到了几家头部客户的认可，可以覆盖暴力破解、异常登录等多种告警类型。

3.3 编排与自主长期并存

这三版的演进，回答了一个很多人纠结的问题：编排，还是自主规划？

我们的实践是：两者长期并存，按时效压力和任务性质分工。大量重复、流程固定的告警，用工作流编排类智能体做高吞吐初筛；少数高风险、不确定、需要多轮跨系统调查的告警，再交给 Agent 型智能体做深度调查。

为什么不能把所有告警都丢给最强的模型去深度分析？因为这在工程上不现实、在成本上不可持续、在SLA上也满足不了。一天约两万条告警，全量深度研判时，token 消耗高达约七亿；后来不得不把进入深度分析的告警量从两万压到三千，成本才降下来。

所以分层是必须的，而分层背后，缓存又不能设计的太粗暴。安全告警里，相似不等于相同：十条看起来很像的攻击，前九条可能都是扫描，第十条可能因为资产、路径、响应、时间线不同，就是真正的攻击成功。所以缓存要做精细：哪些能强复用结论，哪些只能复用中间证据，哪些必须重判。有些地方反而可以放心强缓存——比如某银行的客户经理经常把同一份授信报告模板外发给外部客户，文件哈希不变，就没必要每次都重新研判。

0x4 智能体实践：没有复核与协查，初筛就只是"看了一眼"

4.1 AI初筛存在不足

AI初筛有价值，它能在海量告警里先做降噪和分类。但如果到这里就结束，问题并没有解决。

举一个真实的数字。某客户近二十四小时聚合后的告警约一点七万条，其中被AI判定为"攻击成功"的，约一千六百条。表面上看 AI 已经很能干了，但这一千六百条如果还要运营人员逐条打开请求体、响应体、原始日志、资产信息去确认，那 AI 解决的只是"量"的问题，没有解决"信"的问题。

4.2 智能复核

智能复核是整套闭环里的一环，它做的事情，是在AI初筛之后，针对高风险、不确定、攻击成功这类告警，自动建一个独立的调查会话，由 Agent 型智能体去查资产、查情报、查 SOC 历史告警、查主机进程、查原始日志，把"模型的一个判断"变成"基于多源证据的复核结论"。

更关键的是一个设计理念：信息不足时，不要急着下结论。

很多安全告警，光靠日志是判不清的。最典型的就是账号异地登录——它可能是凭据泄露，也可能只是员工把账号借给了别人。这种情况，AI查遍了SOC、资产、情报也确认不了，那它就不该直接给出"攻击成功"或"攻击失败"的结论，而应该停下来找人。

4.3 人工协查与反馈闭环

我们的实践是让AI通过 IM 发起人工协查：把告警 ID、当前调查情况、需要确认的问题发到群里，人工带着告警 ID 回复、@ 一下机器人，系统通过回调把这条反馈写回对应的会话，AI 再接着完成复核。这里有个很现实的细节——群里可能同时有好几条协查请求，所以人工回复必须带告警 ID，否则系统不知道这是哪条告警的反馈。目前飞书、企业微信已经打通，钉钉在适配。这套机制在客户那里已经实战使用。

整个过程，系统会同时保留AI初筛原结论、智能复核结论、人工反馈、最终是否改判、改判依据。这才是闭环。

因为它打通了过去AI研判一直缺的那个东西——标准答案回路。过去每天都是新告警，AI 根本不知道自己昨天判对了还是判错了。有了复核和人工反馈，AI 才第一次拿到了"对错"的信号，才谈得上自我改进。

而且这些被确认过的案子，不该只是存进档案。更有用的做法，是把一整条过程沉淀成判例——这条告警当时长什么样、AI顺着什么路径查、查了哪些系统、最后结论是什么、人工和后验反馈又是什么。下次遇到相似的告警，调出来的是这整条"怎么查、怎么想"的过程，当作推理参考，而不是把当时那个"人工结论"直接套上去。

这两者差别很大：直接套用当时的结论，等于把判断退回到关键词匹配，系统也学不到任何东西；把完整判例当参考，AI借鉴的是当时的核查路径，再结合这次的差异重新判断。安全运营的经验，本就该一案一案积累成可被检索的范例，而不是指望谁在初次写提示词、建智能体的时候，就把所有情况一次想全、从此定型。

没有复核，AI只是给了你一个判断；有了复核与协查，AI才可能输出一个可解释、可追溯、可回放、可写回的运营结论。

0x5 智能体实践：让 AI 理解"这个实体平时什么样"

很多AI

研判效果不稳定，根源不在模型，而在上下文。
聂君

同样一条疑似敏感数据外发行为告警，研发部门外发代码和市场部门外发宣传材料，风险完全不同；同样一台机器主动外联境外IP，生产服务器和办公终端，判断标准也完全不同。这些信息在哪里？很多时候在人脑里、群聊里、工单备注里、Excel里，根源是没有结构化沉淀。AI 不知道，自然会误判。

5.1 实时画像

解决这个问题，不能靠继续写更长的提示词，也不能靠把所有历史日志一股脑塞给模型。靠的是结构化实体画像。

但我们在讨论里想清楚的一件事是：实体画像不应该是"提前给每个人、每个 IP 生成一份静态画像"。那是脚本批量算出来的静态结果，不会实时更新，用户一换时间范围、换筛选条件就失效了。

更合理的形态，是一套能按场景、按条件实时查询的上下文：同一类实体共用一套口径，按部门、时间、通道、风险状态去筛，而不是给每个人各存一张静态表。

这里有一点尤其要紧——人和AI 得看同一套事实。人在页面上看到的统计、AI 调查时拿到的上下文、报告里引用的数据，都得来自同一套查询逻辑；否则人一个口径、AI 一个口径，AI 给出的结论就既无法解释、也无法复盘。

那不是智能化，是新的混乱。

5.2 两个用途

画像有两个用途。第一个，是给AI研判提供上下文，让它不再只看单条告警。

第二个，把画像编译成检测能力。某台服务器过去九十天从不主动外联境外 IP，今天突然外联了；某个财务岗员工过去深夜外发的频次是零，今天出现了三次。这种"偏离了自身历史常态"的信号，往往比通用规则更有价值，而且不管攻击手法怎么变都成立。

5.3 分级治理

还有一点容易被忽略：挂在实体上的信息，性质并不一样，治理也得不一样。"这个IP是业务扫描器"、"这台主机是某业务的跳板机"是事实，要带出处和有效期；"这个员工深夜外发、上次人工确认是正常批处理"是判例，只能当研判的参考；真正要让某类行为"免研判"放行的，必须从画像里这种模糊记忆，晋升成一条可审计的白名单规则。记忆只负责提示，规则才负责放行，这条界限不能含糊。

把记忆挂在实体上还有个额外的好处——它能跟实体在现实里的生命周期联动。员工离职、主机改用途、系统下线，对应实体的画像就自动降权，注意是降权、不是删除：一条"他已经离职"的旧记忆，碰上"离职账号仍在登录"这种告警，反而是最关键的那把钥匙。

当然画像也有它的工程难点。它的查询频次可能远高于人——如果AI一天研判两千条告警，画像就可能一天被调两千次。所以底层得用更适合做聚合统计的存储引擎，配合缓存和限流，而不是简单堆在日志检索系统上。

0x6 智能体实践：检测阈值能压多低，取决于研判接得住多少

6.1 检测分三层

这里要先重构一个前提：检测不是一个环节，是三层。

我们习惯把检测当成秒级的在线判定——规则、模型、特征，毫秒级出结果。智能体进不了这一层，上下文窗口、推理时延、多轮调用的开销都不允许，这点没错。但检测还有第二层和第三层：第二层是离线的内容生产——写规则、调阈值、补盲区，按天计；第三层是阈值之下、被压掉、根本没进SOC的那批弱信号。智能体进不了第一层，却完全可以接管第二层、捞回第三层。

6.2 下移加分层

今天每家企业的告警阈值，本质上是按人工研判的处理能力标定的。人工团队的处理能力不够，就只能把阈值抬高、把弱信号压掉——而漏报，恰恰藏在被压掉的那部分里。当研判产能因为智能体变得弹性、单次调查的成本持续下降，最优阈值就会系统性下移：下游接得住了，就敢把更多弱信号放进来重新看。

当然，放进来不等于把这些弱信号都丢给最强的Agent深判——那又会回到老问题：深度调查很贵，不能全量上。得配合分层：新捞回来的弱信号，先用便宜的快系统和 AI 自己生产的规则去筛，只有真正可疑的才往上走。被压在阈值之下的灰色地带，也正是平时主动狩猎该去翻的地方。

所以把AI用在研判，会反过来改善检测的召回率。检测、研判、处置不是三段各自为政的流水线——研判这头接得住了，检测那头就敢把阈值压得更低。整条漏斗值得一起重新标定，而不是各自局部优化。

0x7 智能体实践：从消耗告警到生产防御资产

7.1 消耗VS复利

前面这些能力，最终都指向同一个判断。上一节AI自己生产检测规则、把检测阈值压低，就是这个判断的一个例子。

如果AI每天只是帮我们把更多告警看完，那么明天同样的告警还会再来，同样的误报还要再解释一遍。这不是复利，是消耗。AI 越强，账单越贵。

真正有价值的安全智能体，每完成一次调查，都应该留下一件"明天还在生效"的防御资产：

一条更准的检测规则、一条实体画像、一个可复用的判例、一个处置预案、一个狩猎假设、一个评测样本、一个带有效期的误报白名单、一个日志解析器、一个蜜标布设建议。
聂君

这些资产产出之后会持续生效、可以跨客户复制、可以被下一轮智能继续加工。防御的边际成本随资产存量复利下降，而攻击者的边际成本不变——两条成本曲线的剪刀差，才是防守方真正的胜负手。

攻击者的agent-hour产出一次性突破；防守者的 agent-hour 必须产出复利。

把"昂贵的深度智能"经济地铺到"海量资产的广度"上，无非几条路径：

把深度调查的成果固化为可复用资产，下次同类问题直接复用（摊销）；
便宜的快系统过滤、昂贵的慢系统聚焦，按风险分配调查预算（分层）；
用与攻击者同等的智能，先于攻击者找到并废掉单点缺陷（预先）；
跨客户、跨时间的知识网络，一处发现、全网获益（复利）；
防御能力本身要持续回归验证，否则会静默退化（验证）。

7.2 针对AI攻击者的诱饵

再举一个目前还少有人关注的方向：针对AI 攻击者的诱饵。攻击者自己也是LLM，就有 LLM 的弱点——它会系统性地读取环境里的文本：配置文件、文档、注释、历史命令。防守方可以在授权环境里布设专门面向 AI 攻击者的内容陷阱，诱导它去访问一个诱饵信标、暴露自己的行踪。这种手段对人类攻击者几乎不可见，对自动化攻击代理却命中率很高。这就是前面说的"步数即信号"——把攻击者最大的优势，变成防守方的信号源。

传统的SOC是一个告警处理工厂。AI 原生的 SOC，应该是一个防御资产工厂。告警只是原料，调查只是加工，真正的产出，是让明天的检测更准、研判更快、处置更稳、人工更少。

（三）展望

0x8 安全验证，在 AI 时代更重要了

8.1 新的失效点

之前写过一篇《安全验证，实现安全运营闭环实践》，总结下来就是：

没有安全验证，就没有安全运营闭环。

那篇文章的判断是：安全建设最怕的不是"没有设备"，而是"有设备，但不知道有没有效"。防火墙、WAF、NTA、HIDS、EDR、SOC，有没有？都有。有没有告警？也有。有没有效？不一定知道。所以要靠模拟攻击、收集结果、自动比对，把"应该拦截没拦截、应该告警没告警"的失效点找出来。

当我们把越来越多的判断、复核、处置交给AI 之后，安全验证比过去更重要。

因为防御体系会多出一批全新的、且更隐蔽的失效点：

日志源断了，AI不知道；
字段解析漂移了，AI在拿错误数据分析；
Skill 调用失败了，AI 没修正；
画像数据过期了，AI 拿到的是旧上下文；
模型升级之后，某类告警的误判率悄悄升高；
提示词改了一版，原来能识别的攻击识别不了了；
处置执行了，但没人验证它到底有没有生效。

AI时代的安全验证，不只是验证 WAF、NDR、HIDS 有没有告警，还要验证整条 AI 运营链路：告警有没有进来、字段有没有解析对、初筛有没有输出、复核有没有触发、Skill 有没有调成功、上下文有没有正确注入、协查有没有送达、结果有没有回写 SOC、处置后有没有验证。

8.2 指标陷阱

银行的运维同学通过模拟一笔转账交易，来判断网络、系统、应用、支付通道这一长串环节里有没有故障点——交易成功，说明全链路通；交易失败，说明存在一个或多个失效点。

AI安全运营也该这样：模拟一条攻击告警走完全程，如果最后没有得到预期的复核结论和处置动作，就说明这条AI 链路上存在失效点。

这里要特别警惕一个陷阱：指标陷阱。告警关闭率、研判覆盖率这种"效率指标"，单独看很容易作弊——把检测灵敏度调低，两个指标可以同时变好看。所以效率指标必须配一个能反映真实防御能力的指标对冲，比如用模拟攻击实测出来的检测验证通过率，这个数是没法靠调低灵敏度刷高的。

安全最怕的不是系统报错，而是系统不报错，但已经失效。
聂君

落到工程上，就是要有评测体系：维护覆盖eml、Office文档、pcap、Webshell 等各种格式的基线集，每次换模型、改提示词、调画像维度、加 Skill，都自动跑一遍回归，用 F1、准确率、召回率量化地比一比，确认能力是在变好，而不是偶尔看起来不错。市面上大多数通用智能体平台，连针对 eml、Office 文档这类非结构化文件的评测都没有，更别说多版本智能体的效果对比。

没有持续验证，就没有可信的AI安全运营闭环。

0x9 不做什么

9.1 不做的四件事

这里也想说清楚，AI 告警研判当前不做什么。

第一，我们不把AI 告警研判定位成"替代所有安全设备"的产品。

WAF、NDR、EDR、HIDS、DLP、邮件网关、SOC、资产平台、威胁情报，各有各的专业积累和数据入口。 AI 告警研判，更适合站在这些设备之后——目前已经对接了二十多类安全产品，从各家SOC、NGSOC、Splunk，到HIDS、威胁情报、URL 沙箱、各家邮件网关和 DLP——做跨设备、跨日志、跨实体、跨时间的二次研判与运营闭环。

第二，我们不主张把所有告警都交给长程Agent深度调查——前面那笔七亿 token 的账已经说明问题。

第三，不会轻易承诺"全自动处置"。在信任工程没到位之前，自动封禁、自动隔离不是智能运营，是自动闯祸。

第四，我们不认为把专家经验写进一段提示词就完事了。真正有价值的，是把专家经验软件化、结构化、可调用、可验证——变成标准Skill、狩猎模板、复核Playbook、画像维度和评测样本。

9.2 从环内到环上

最后，说说人的位置。

AI时代，安全人员会不会被取代？我的判断是：重复性的逐条研判岗位需求会大幅降低，甚至威胁狩猎（Threat Hunting）专家，俗称安全二线，也会被逐步替代，但真正懂安全运营的人会更重要。

过去人的位置在"环内"——每条告警都要看，每个结论都要复核，每个处置都要点一下。这条路走不下去了，因为只要人在每条告警的必经环节里，整条链路就是人工速度。

未来人的位置要迁到"环上"：做抽样审计，用统计的方式监督质量；做疑难仲裁，只处理模型低置信或异构复核有分歧的样本。

每一次人工纠正，都是最昂贵的训练信号，它必须自动进入评测集、判例库和智能体记忆，而不是消失在某条工单备注里。

这不是人的价值下降，而是人的价值从重复劳动，迁移到设定边界、监督质量、沉淀经验。

AI负责规模，人负责判断，系统负责闭环，验证负责信任。

（四）结语

前沿大模型让攻击变得更快、更便宜、更自动化，这是事实。但防守方的答案，不应该是再多堆几个值班人员，更不应该是买一个"AI 概念"就以为完成了升级。真正的答案，依然需要从实践中来。

这二十多年，大中型企业的安全建设大体到位，重心正从"建设"往"运营"上转。安全团队从一个处升格成安全运营中心，投入和重心跟着变。这几年的内生安全、安全左移、零信任，更多是理念上的更新，底层的安全建设技术其实已经走到成熟期。下一步，甲乙双方更多需要把安全运营做精做细。

但安全运营有两个老问题：一是没标准，一千个人心里有一千个安全运营；二是缺工具，事情主要靠堆人。而安全运营里大概八成是重复性的活，本该交给自动化——难就难在，怎么站在甲方的视角，做出真正贴合甲方需求的工具。

网络安全这行，绝大多数从业者是甲方企业里的安全团队，可这群人是"沉默的大多数"：他们每天在一线处理告警、修漏洞、做应急，最清楚运营缺什么，但这部分声音，市场上反而少有人听。大多数安全公司从产品功能去满足需求，上来就是八大功能、十大亮点；而不少公司的产品经理、方案专家，并没有多少甲方一线经验——有的连一个漏洞都没修过、一次事件都没处理过，就在指导甲方怎么做安全。这就像没带过孩子的人，来教你怎么带孩子。安全运营尤其吃这一点：它是把甲方的安全管理和体系流程化、把最佳实践沉淀下来，得结合一家企业的实际、风险偏好和容忍度，才能落地一套"架构 + 工具 + 流程 + 度量"的体系。

没有甲方安全实践经验，很难做出符合甲方需求的运营工具来。

知其安做的就是这件事——专注安全运营的工具链。从创业那天起，我们的目标就一个：用自动化和智能化，把安全运营的效率和产能提上去。这些年目标一直没有变。

第一个安全运营工具是离朱-安全验证平台。 2021 年起，我们在国内较早提出并推广"安全有效性验证"——用 7×24 小时持续模拟攻击，以攻促防，去检验一套防护体系到底有没有效。几年下来，积累了数万条攻击用例和一批攻防知识。

一个研判智能体能不能应对各类攻击、对没见过的攻击变体泛化得怎么样，正需要一套够全的攻击覆盖用例。

第二个安全运营工具是陆吾-内网安全资产运营平台，更好地维护动态资产数据，为安全运营智能体提供更高质量的内部上下文信息并持续动态更新；

第三个安全运营工具，就是曜鉴-AI 告警研判分析平台，从智能安全告警调查分析出发，持续嵌入更深的智能安全运营场景。2024 年 7 月开始，我们和某头部银行联合共建，把前面这些积累往智能体上应用，之后两年的主要节点，和业界时间线，大致是同步的：

走到这一步，我们的思路越来越清楚：真正要把曜鉴这类安全运营智能体，做成可落地、可复制、可规模化的产品，难的并不只是“让大模型回答一条告警有没有风险”。难的是在真实企业环境里，把安全能力的泛化、设备接入、上下文构建、实体画像、批量研判、缓存调度、评测验证、权限审计、沙箱隔离、跨会话记忆、模型推理性能这一长串都做扎实，最终搭成一整套可长期运行、可持续优化、可被验证、可被审计的智能体工程体系。业内 2026 年初给这件事起了个名字，叫Harness Engineering——就是前面那句“七分在工程”。

实践下来，这个方向最重要的几项能力是：把高质量的资产上下文维护好；对各类攻击有足够理解和更广的覆盖度，好让模型有更强的泛化、少漏真实攻击；把甲方一线的告警调查最佳实践沉淀下来，能在同业之间复制；以及不断提高安全运营的效率——从自动发现失效点，到自动积累上下文，到自动研判，再到人机协同。用更多的自动化，去抵消那些靠人容易出的疏漏：设备变更后防护悄悄失效、周末和夜班研判时的走神、引入 AI 之后信息不全导致的误判。

知其安团队核心成员，长期在甲方一线做安全——来自头部股份制银行、交易所、头部券商，也有来自大型互联网公司和上市安全企业的，从甲方安全实践视角发出发，广泛接触甲方真需求，用甲方实践思路工程化工具，真实解决问题，让安全创造价值。到今天，签约服务的客户超过250家，在六大国有银行、全国性股份制银行、城商行、交易所、券商、基金、保险等，能源、运营商、高端智能制造与互联网行业企业占有率超过 90%。

“知其安，知其所以安”。到了智能体时代，再加一条——还要知其所以智能：知道 AI 为什么这么判，知道智能体有哪些局限，知道怎么验证、如何复核、能否回滚、能不能持续变好。

往期精选：

参考来源

Anthropic. Project Glasswing. https://www.anthropic.com/glasswing
UK AI Security Institute. Our Evaluation of Claude Mythos Preview's Cyber Capabilities.https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities

--------------------------我是分割线--------------------------

如果您对安全运营领域，特别是通过自动化工具解决安全运营需求感兴趣，欢迎微信联系我：kelvin2294，或者扫以下二维码，知其安虚位以待：资深产品经理、高级售前、行业解决方案专家、大客户销售。

阅读原文

跳转微信打开

君哥的体历

多次获奖到商业化落地：「曜鉴」率先跨过安全智能体落地门槛

将告警转化为调查任务

补齐资产和业务上下文

根据新增证据动态规划调查

用专业工具验证事实

形成能够复核的证据链

在授权边界内推动处置

代码“不落云”就安全吗？企业AI评审、SRC运营与邮件TLS的现实选择｜总第321周

如何进群？

情报洞察｜美国陆军启动“狮鹫项目”以构建AI智能体网络自主防御体系

金融企业安全治理：AI攻击挑战与诈骗风险防护｜总第320周

如何进群？

关于国产大模型安全能力评估与跨网数据流动监控的探讨｜总第319周

如何进群？

OVTP范式下的权限管控、域名异常指向溯源与AI大模型告警研判探讨｜总第318周

如何进群？

做什么都需要花时间，可是很多时候完整听完一首歌的时间都没有

中盾网空防务技术有限公司诚招产品经理｜总第66期

从“测漏洞”走向“管业务”：企业安全建设、资产测绘与零信任接入｜总第317周

如何进群？

中国人民财产保险股份有限公司诚招安全人才｜总第65期

史诗级Linux漏洞来袭：从漏洞验证到数据泄露报警，安全团队如何应对？｜总第316周

如何进群？

安全岗位会被AI取代吗？云桌面能守住数据防线吗？｜总第315周

如何进群？

安全观察：AI攻防升级与网络安全审查两大热点解读｜总第314周

如何进群？

平安健康医疗科技有限公司诚招安全人才｜总第64期

万字图文，带你吃透Prompt工程 && Context工程 && Harness工程是如何演进的

一、那些年，我们"调 Prompt 调到怀疑人生"

二、Prompt Engineering：一切的起点

2.1 它是什么

2.2 怎么用

2.3 但是，局限来了

三、Context Engineering：比"写什么"更重要的是"模型看到什么"

3.1 从 Prompt 到 Context 的认知跳跃

3.2 Context Engineering 催生了哪些核心技术

🔍 RAG：让 AI 学会"开卷考试"

🛠️ Tools：给大模型装上手和脚

🧠 记忆系统：让 AI 不再是"会失忆的傻子"

3.3 Context Engineering 的局限

四、Harness Engineering：给 Agent 套上"黄金缰绳"

4.1 它是什么

4.2 为什么需要 Harness？——三大核心约束

4.3 六大设计原则（用大白话解释）

4.4 顶层架构：带边界控制的 REPL 闭环

4.5 核心机制：解决两大底层矛盾

4.6 架构分层：控制平面 + 数据平面

4.7 安全治理与度量体系

4.8 一个完整的 Harness 实战场景

五、全景总结：三层工程到底是什么关系？

通过 AI agent + 通用大模型，实现海量告警研判分析实践

角色的重新定义