“AI 挖出微软漏洞”是一句容易传播的标题，却把一次安全研究里最重要的分工抹平了。公开报道提到，微软安全更新相关致谢出现了类似 “Yuki Chen using GLM from z.ai” 的署名。这个表述至少说明研究者在工作中使用了 GLM；它本身并不能回答模型负责了哪一步，更不能推导出“模型独立发现、验证并提交了全部漏洞”。在讨论 AI 的网络安全能力时，先把证据层级分清楚，比急着判断“人会不会被替代”有用得多。
能直接核对的一手材料包括微软安全更新指南、Z.ai 的 GLM-5.3 技术说明和Anthropic 对 GLM-5.3 的独立安全评估。微软站点部分详情依赖浏览器脚本；逐条核查特定 CVE、致谢者和修复状态时，应该打开对应记录，而不是把新闻中的截图当作完整原始证据。本文把已证实的模型能力、公司披露的统计和仍然未知的人机分工分开讨论。
一条致谢署名，处在证据链的哪一环
安全漏洞从“怀疑这里有问题”到公开通告，通常会经过代码阅读、构造触发条件、复现、评估影响、向厂商报告、厂商确认与修复。公开致谢属于这条链路的后端：它说明某位研究者的工作被相关流程记录下来，却不自动公开全部实验日志。即使署名带有“using GLM”，也不能从这一句反推出模型是发现者、利用链作者或最终审查者。
| 可观察材料 | 较稳妥的结论 | 不能顺推的结论 |
|---|---|---|
| 漏洞通告与致谢署名 | 有记录的研究者和受影响组件 | 模型独立完成全部研究 |
| 可复现的触发样例 | 某条件下问题确实存在 | 它必然能被远程利用 |
| 可用的利用链 | 指定环境下可完成更高层级目标 | 所有平台都同样受影响 |
| 厂商补丁与版本说明 | 修复范围和用户操作 | 之前的所有相似报告都来自同一方法 |
这也是报道里“23 项漏洞”需要谨慎处理的原因。数字可能指某一批次与 GLM 相关的致谢记录，但它与 Z.ai 所说的跨项目漏洞统计不是同一个集合；同一漏洞也可能经过多名研究者和多个工具。没有逐条 CVE、确认日期和致谢字段的清单，不应把两个数字相加，更不该称为模型的“自主战绩”。
流程示意，说明人工核验节点与交付边界。
模型到底能帮研究者做什么
在大型软件里，研究者首先要读懂代码边界：输入如何进入组件、对象在哪里创建和释放、异常路径是否被测试覆盖。模型能够帮助检索调用链、提出可疑路径、整理崩溃日志、生成候选测试用例和比较补丁前后的行为。对人而言，真正昂贵的不是生成一段猜测，而是筛掉误报并验证影响。一次崩溃不是可利用漏洞，一条看似合理的漏洞报告也未必通过厂商确认。
Z.ai 在官方模型说明中披露：与安全团队合作，对 269 个项目进行研究，经专家筛查与去重后跟踪到 2,436 项发现，其中 1,097 项被列为严重或高危。这是公司披露、专家参与、跨项目累计的数据，不能写成“模型独立找到 2,436 个已公开 CVE”。同一页面还给出其 ExploitGym 等评测结果，并承认在更复杂的利用链任务上与更强的封闭模型仍有差距。
Anthropic 的2026 年 9 月研究从另一角度评估了 GLM-5.3：在隔离环境的已知浏览器漏洞任务中，模型可以完成部分端到端利用；在 410 次尝试中成功 50 次。这个结果说明能力门槛在上升，但它是特定基准、预算和实验环境下的表现，不代表任意未知漏洞都能被自动攻破。研究同时指出模型滥用防护的风险；这也是把能力讨论和发布治理放在一起看的原因。
把“AI 安全研究”拆成可审查的工作流
如果团队想把模型加入防御性漏洞研究，可先选一段已获授权、可隔离的测试代码，而不是把生产环境和真实第三方系统交给 Agent 自由探索。设计一条有停止点的流程：
- **界定范围。**记录代码仓库、允许测试的版本、环境、数据和授权人。输入资料脱敏，凭据不进入提示词或日志。
- **模型做候选发现。**让模型给出文件路径、调用链、触发前提与不确定性，不把“可能有漏洞”直接写成结论。
- **工具做受控复现。**在隔离环境里验证崩溃和行为差异；保留版本、命令、日志与可重复步骤。不要把 PoC 自动指向未授权目标。
- **研究员评估影响。**确认是否真实、是否可利用、所需权限、影响范围与误报可能；必要时让另一名研究员复核。
- **负责披露与修复。**按厂商安全响应渠道报告，跟踪补丁和公告，在修复窗口内控制敏感细节传播。
衡量这条流程时，不能只数“发现了多少疑点”。更有价值的指标是经过人工确认的有效报告率、复现时间、误报率、厂商接受率、从报告到补丁的周期，以及研究者花在高价值判断上的时间。模型越能自动化初筛，人工验证和授权边界越要清楚。
两个方向的风险，要一起看
同一套代码理解、工具调用和实验迭代能力可以帮助防御者更早找到问题，也可能降低攻击者寻找薄弱点的成本。防御团队需要优先处理高危组件、限制 Agent 的网络和凭据权限，并把所有模型输出视为未经验证的线索。对使用开放权重模型的团队，还要评估本地部署后安全限制是否可被改变，制定使用范围与审计规则。
真正值得关注的变化，不是某一条致谢是否写了模型名，而是漏洞研究逐渐从“专家独自翻代码”变成“专家定义边界、模型扩大搜索、工具做复现、厂商完成修复”的协作系统。公开证据越少，结论越要收紧；验证材料越完整，团队才越有资格谈效率提升。
常见问题（FAQ）
微软致谢里出现 GLM，等于微软认证了 GLM 的独立能力吗？
不等于。致谢记录可以说明研究者使用了该工具并被记录，但通常不披露模型、人和其他工具的完整分工。
Z.ai 所说的 2,436 项发现都是微软漏洞吗？
不是。该统计覆盖 269 个不同项目，且经过专家筛查与去重；它与微软某批次致谢不是同一口径。
为什么发现崩溃还不算“找到高危漏洞”？
还需要确认可重复、受影响版本、攻击前提、权限边界和实际影响。许多崩溃无法稳定利用，部分模型报告也可能是误报。
企业可以让 Agent 自动向外部目标测试吗？
不应默认这么做。先取得明确授权，限定隔离环境、目标、时间和工具权限，并让研究员审查输出与披露流程。
