2026年6月18日，阅读时间17分钟。几周前，我们发布了关于Project Glasswing的初步发现，研究了当您将前沿安全模型应用于企业代码库时会发生什么。我们还探讨了我们的防御结构如何适应以保护我们的基础设施和客户免受前沿AI所带来的威胁。从那时起，AI生态系统持续快速变化——在单一模型上构建的开发人员已经体验到了当该模型不再可用或被更强大的模型取代时会发生什么。这些市场变化进一步证明了我们的核心论点：无论在任何特定日子哪个基础模型处于领先地位，未来的代理工作流都不会在独立模型、提示或单代理会话中找到。将安全“技能”从局部化转变为持续的、全舰范围的扫描管道需要一种架构，在这种架构中，模型被视为可互换的组件。依赖单一模型天生限制了防御覆盖，因为同一系统往往通过完全相同的视角查看代码路径。为了解决这个问题，模型应该经常更换和交叉测试。通过在管道中变换模型——例如使用一种模型进行初步发现，然后用完全不同的模型进行验证——我们可以确保漏洞通过不同逻辑集进行交叉检查。此外，真正企业级的框架必须超越孤立的代码库，以追踪跨越多个代码库的依赖漏洞，最终将数千个原始候选项筛选到可信赖的、经过分类的可操作修复队列。这篇文章实用地探讨了如何构建那个与模型无关的层，重点关注我们如何管理状态控制、消除假阳性以及在规模上协调端到端分流。两个反对意见， upfront 第一篇文章论证了为什么通用编码代理无法完成这项工作。主要问题是代理每次只能持有一个假设，在覆盖真实代码库的一小部分后填充其上下文窗口，然后在上下文压缩期间丢失信息。有关更多细节，请阅读那篇文章。在我们继续之前，我们想回答两个可能的问题。“为什么不使用子代理而不是框架？”子代理是有用的，它们是一个不错的起点。但是，安全分析需要数百个在运行中生存的独立调查，它们不共享上下文窗口，并且可以稍后重新规划和交叉参考。这需要持久性、去重、可恢复性，并最终达到全舰范围的依赖关系追踪。这是一个编排问题，而一个提示无法让您达到这个目标。“这篇博客文章只是前沿模型的广告吗？”不。我们的方法集中在框架上，而不是模型。在漏洞发现方面，我们使用当前在我们需要的内容上表现最好的前沿模型。当我们将不同的模型指向同一目标时，它们各自呈现不同比例的漏洞。框架是持久存在的部分。如果您构建自己的系统，从第一天起就设计成与模型无关。这将使您自由选择任何模型，而不受限制。一切都从一项技能开始 我们从大约450行的安全审核技能开始，在单个代码库上运行，并调整提示，直到发现真正的漏洞。随后，我们添加了构成整个系统管道的编排。真正的价值在于提示本身，我们的提示继续几乎不变地传递最初技能的攻击场景、漏洞类别和反模式检测。该技能被编写为在一个会话中运行7个阶段的审核：三个并行的研究代理进行侦察，写下architecture.md。一个Hunter代理每类攻击运行，试图破坏代码而不是审查它。对抗验证者试图反驳每个发现。存活下来的内容作为人类可读的漏洞报告写出。它们还作为findings.json在架构下发出，并由机械检查验证该文件。最后，一个新的代理独立重新验证每个发现。存活的、重新验证的发现将提交给ingest API。那个第一个技能几乎直接映射到后来的框架：技能阶段 - 框架阶段 侦察代理写architecture.md 侦察 猎人按攻击类别运行 猎杀 验证者反驳发现 验证 存活的发现成为一份报告 报告 findings.json被机械检查架构符合性，而非正确性 发现中行号和函数的机械验证 新代理重新验证发现 独立验证 该技能有效，但很快暴露了其局限性。查看覆盖度指标，单次运行仅发现您在多次运行中捕获的大约一半的漏洞。在我们的经验中，发现的漏洞往往偏向于较简单和不那么微妙的。一旦您的流程基本上是“运行十次并手动比较”，您可能需要开始考虑一个真正的框架。