先看证据
架构转型：从智能对话到控制平面
0sec Labs 发布的 0 标志着 AI 自动化安全工具的一个关键转折点。它并非简单的模型套壳，而是一个旨在将大语言模型（LLM）与传统离散安全工具链深度整合的“安全编排引擎”。通过 CLI、MCP（模型上下文协议）以及浏览器控制台，0 允许用户利用多模型能力进行漏洞调查、渗透测试及修复生成。这一架构设计的核心在于将 AI 从单纯的“辅助对话”升级为控制平面，通过标准化的执行路径编排各种安全逻辑。
在底层实现上，0 采用了模块化设计，将复杂的安全扫描划分为计划、发现、攻击、分流、验证和报告六个阶段。这种方式与传统黑盒 LLM 工具的主要区别在于，它强调“ reproduce before trusting”（先重现，后信任）的验证准则。例如，在处理二进制目标时，0 引入了名为 0verse 的独立引擎，整合了 Ghidra、angr 和 AFL++ 等成熟的逆向分析工具，从而确保了扫描结果的合规性与可追踪性。
Web 渗透测试的 Shell-first 范式
针对 Web 应用渗透测试，0 采用了 shell-first 的执行哲学。这意味着 AI 代理在处理目标时，并非依赖于高度抽象的 API 调用或单一用途的插件，而是直接通过 bash shell 调用诸如 curl、python3 和 sqlmap 等行业标准工具。这种设计不仅提高了工具的可扩展性，还使得漏洞扫描的过程具有了极高的透明度和可审计性。报告输出支持 HTML、PDF、SARIF、Markdown 和 JSON 等格式，满足了企业级安全审计的记录要求。
此外，项目通过 MCP Server 为 coding agents 提供了标准化的接口。这意味着开发者可以将 0 的自动化安全能力嵌入到现有的 CI/CD 流水线中，或者将其集成到像 Cursor 或 Windsurf 这样的开发环境中作为 AI 代理的安全插件。这种互操作性是目前许多同类开源工具所不具备的，使得 0 不仅仅是一个单机版的实验室工具，更具备了扩展至复杂工程化场景的潜能。
性能指标背后的严谨边界
官方提供的 benchmark 数字在阅读时需要极其谨慎，不能将其视为通用性能结论。以 XBOW Web CTF 的 97.9% 成功率为例，该指标记录的是 2026 年 5 月份基于特定 gpt-5.4 cohort 的“保留结果”，且包含多轮重试。官方明确说明这并非 pass@1（即一次性通过成功率），也并非单一的黑盒测试结果。事实上，在仅进行黑盒测试的记录中，其成功率回落至 77.9%，这反映了工具在真实生产环境中的复杂性与对人工监督的需求。
同样地，Cybench 测试中 36/40（90%）的分数同样包含 3 次重试的条件。项目组将这些基准描述为“仓库快照”，旨在展示工具的演进过程而非绝对的生产力指标。由于这些分数的产生依赖于特定的模型提供方及重试逻辑，开发者在评估其价值时，应当更多关注其工作流的可重复性，而非仅仅被高分所吸引。目前 0 正处于 Research Preview 阶段，这意味着其覆盖范围、验证深度和实际漏洞检出效果，仍需要针对特定代码库进行充分的本地验证。
工程化落地的实操建议
在当前阶段，0 的最强应用场景在于将其作为自动化安全检查的“插件”。开发者无需更换底层的 AI 模型，因为它支持包括 OpenAI、Anthropic、DeepSeek 等在内的 14 种主流提供方，并兼容 Claude、Codex 和 Gemini CLI 运行时。这种“自带模型（BYO Model）”的策略，使得企业可以在保护自身代码库隐私的前提下，利用最强模型驱动 0 的安全工作流。
下一步的验证应当聚焦于以下三个维度：第一，测量特定工作流下的总推断成本，目前单个 XBOW 挑战的推断成本约 5.20 美元，在规模化测试中需纳入财务考量；第二，评估 0verse 在闭源二进制文件上的实际检出覆盖率，并对比其与手动逆向分析的工作效率提升；第三，在 CI/CD 中建立基准测试，监控该工具在处理虚假报警（FPR）时的表现。项目提供的 npm audit 测试展现了 0.973 的 F1 分数，这提供了一个衡量自动化分流能力的可行参考路径。