先看证据
分数很高，问题在于分数覆盖了什么
OrcaRouter 于 2026 年 10 月 10 日发布 OrcaCyber Zero 1.5。这是一款面向授权漏洞研究的后训练模型，定位包括漏洞复现、漏洞利用开发、渗透测试与安全审计；它通过 OrcaRouter 托管 API 提供服务，不开放模型权重。产品页把 1M-token 上下文、原生工具调用和接近满分的网络安全基准成绩放在同一个卖点里。
值得细读的不是“100%”这个数字本身，而是它和评估边界之间的落差。模型在 Cybench 上报告 39/39，在 CVE-Bench 可评估子集上报告 23/24，但前者总计 40 道任务，后者基于 40 个严重级别 Web CVE、实际只计入 24 道可评估任务。高分说明它在特定测试设置中表现突出，并不自动说明它能在任意代码库里稳定找到并验证漏洞。
基准成绩需要连同测试条件一起读
Orca 公布的四项结果分别是 Cybench 100%、CVE-Bench 95.8%、HumanEval+ 93.9% 和 SWE-bench Pro V2 76.5%。其中 Cybench 的 100% 是在 unrestricted agent execution 条件下完成 39 道任务；这意味着结果不仅涉及模型推理，也受到代理执行方式和工具环境影响。单看百分比，读者看不出这些条件与团队自己的安全测试环境有多接近。
不同基准也不能压成一个“网络安全能力”总分。材料明确指出，SWE-bench Pro V2 的 76.5% 不应直接与标准 SWE-bench Pro 成绩比较；CVE-Bench 的分母又只是可评估子集。四项数据均为厂商自报，材料没有提供独立复现结果。因此更稳妥的读法是：这些数字构成了值得验证的能力信号，而不是经过外部确认的实战保证。
长上下文改变的是工作流，不是证据标准
1M-token 上下文的实际价值，在于让安全代理有机会在一个会话中读取大型代码库和相关攻击面，再结合工具调用推进分析。模型还支持最高 128K-token 输出和结构化输出，接口兼容 OpenAI 风格的调用方式。对需要反复在代码、日志与测试结果之间切换的团队来说，这种设计可能减少上下文拼接，也让自动化流程更容易接入现有工具链。
但上下文容量不是代码覆盖率，也不是漏洞发现率。材料没有说明参数规模、底层硬件或模型如何在长输入中选择与保留证据，也没有给出长上下文任务的独立评估。即使代理能读入更多仓库内容，团队仍需判断它是否追踪了正确的调用路径、是否误把可疑模式当成可利用漏洞，以及复现结果是否可靠。大窗口扩大了模型可以处理的材料范围，并没有替代验证环节。
托管与准入门槛也是系统设计的一部分
OrcaCyber Zero 1.5 只能通过 OrcaRouter 的托管 API 使用，访问被限制在 Security Research tier。申请者需要 engagement、passkey 并接受相关条款，目标用户是可信安全研究人员、红队和授权测试团队。这种准入方式与模型面向高风险安全任务的定位相呼应，但也意味着使用者无法自行部署权重或选择量化版本；硬件信息同样未披露。
价格为每百万输入 token 3 美元、每百万输出 token 7.50 美元，缓存读取为每百万 token 0.75 美元。对长上下文代理而言，单价之外还要核算重复读取、工具调用和长输出造成的总消耗。托管服务降低了团队准备模型基础设施的负担，却把运行依赖、数据处理和服务可用性更多地交给供应方；现有材料没有提供足够信息来评估这些运营条件。
把它当作待验证的安全能力，而非自动结论
对技术负责人来说，合适的起点不是把模型直接接入生产扫描，而是在授权、隔离且可审计的测试范围内，比较它与现有流程的差异。记录模型提出的漏洞假设、使用的工具、复现步骤和最终人工判定，才能看出它是在减少漏报，还是只是在生成更多需要筛选的线索。尤其要把“发现问题”和“证明可利用、完成修复验证”分开计量。
目前材料支持的判断是：OrcaCyber Zero 1.5 具备值得评估的网络安全基准成绩、较大的上下文窗口和面向代理的接口，但没有独立复现，也没有足够信息证明其在组织自有代码和治理要求下的表现。若团队无法接受托管依赖或无法满足准入条件，这些能力也未必可用。采用与否应由受控试点中的可复现漏洞、误报成本、数据处理要求和实际总费用共同决定，而不是由单一榜单分数决定。