2026 年 9 月 14 日，在山东济南举办的 2026 年国家网络安全宣传周开幕式上，2026 年人工智能技术赋能网络安全应用测试结果正式发布（国家互联网应急中心 CNCERT 主办，中国科学院信息工程研究所等联合主办，十余家部委司局指导，华为提供昇腾测试环境）。
规模数据很具体：面向社会公开报名，共 151 家单位、251 个团队参加，设 8 个测试场景，最终 32 个团队取得较好成绩。其中两个场景与采购 Agent 的企业直接相关——场景 5「大模型安全护栏能力检测」与场景 7「AI 智能体恶意操作行为检测」。
两处必须如实说明的边界：① 本次公布的是"按场景取得较好成绩的团队及其所属单位"，并未发布"优秀产品名单"，"遴选优秀产品"只是活动目标之一，正文未披露具体产品型号；② 具体评分细则、技术指标与评测数据集未见公开。所以本文不会把它当"厂商排行榜"用，而是讨论一个更实用的问题：这份公开测试给企业采购提供了什么可用的证据标准。
本文只作采购落地参考，不构成对任何厂商的评价结论；涉及合规与合同的判断，请由法务与采购部门按自身流程确认。
一、这份测试结果是什么：8 个场景与三个数字
先把可核对的部分摆出来（来源为 CNCERT 发布稿及其转载口径，中央网信办官网与人民网亦有同期报道）：
| 项 | 内容 |
|---|---|
| 发布时间与场合 | 2026-09-14，2026 年国家网络安全宣传周开幕式（济南） |
| 主办与支持 | 国家互联网应急中心（CNCERT）联合中国科学院信息工程研究所、国家信息技术安全研究中心、山东广播电视台；多部委司局指导；华为提供昇腾环境 |
| 规模 | 8 个测试场景、151 家单位、251 个团队报名，32 个团队取得较好成绩 |
| 目标（官方表述） | 推动 AI 在网络安全领域赋能应用、挖掘高价值业务场景、遴选优秀 AI 技术产品、提高重要行业防护水平 |
三个数字怎么读
8 个场景的名称如下（可直接对照自己的采购需求）：
| # | 场景名称 | 与 Agent 采购的关系 |
|---|---|---|
| 1 | AI 驱动攻击的网络安全智能防御 | 间接 |
| 2 | 网络系统与源代码漏洞智能挖掘 | 间接 |
| 3 | 网络流量安全威胁检测 | 间接 |
| 4 | 网络安全告警日志降噪 | 间接（运维侧） |
| 5 | 大模型安全护栏能力检测 | 直接：护栏与内容安全能力 |
| 6 | AIGC 生成图片检测 | 间接（内容合规） |
| 7 | AI 智能体恶意操作行为检测 | 直接：Agent 行为越界与恶意操作识别 |
| 8 | 广播电视 IPTV 账号异常行为检测 | 不相关（行业专项） |
别把它读成厂商排行榜
三个数字（151 / 251 / 32）说明竞争强度不低，但它们不是产品测评分数：报名数 ≠ 通过数，场景名 ≠ 产品能力边界，而且评价细则未公开。正确的用法是把它当作"测试场景清单"——这些场景说明监管与行业把哪些能力视为可测、可评、可比，采购时就可以按同样的维度去要材料。把场景名与自家需求对齐成一张表，属于知识检索 与需求整理的常规动作，企业级环曜知识库本地化部署 的客户环境会把这些材料与制度文件收在同一入口。
二、为什么公开测试对采购有参考价值
企业采购 Agent 时常见的困境是：供应商都能演示，但演示与实战之间的差距无法度量。公开测试的价值在于它把"可测什么"公开化了，带来三点可直接用的推论：
其一，能力可被第三方测。 场景 5 与场景 7 的存在说明"护栏能力"与"Agent 行为检测"已经能做成公开测试题，采购时索要第三方测试或等效的对抗测试报告，就不是额外苛求。企业级环曜 Agent 本地化部署 的项目把这类报告纳入合规治理 归档，属于启动阶段的常规动作。
其二，场景名就是需求清单。 与其问供应商"你们安不安全"，不如按场景问"你们在这类测试里做过什么、结果怎么证明"。
其三，测试结果不等于产品能力。 由于未公布产品名单与评分细则，不能看到某厂商参与就认为其产品过关，也不能因为某厂商未出现在名单里就否定它——名单按场景列出"取得较好成绩的团队"，覆盖范围有限。把这些边界写进需求说明，属于依据收口的日常工作，企业级环曜知识库本地化部署 的文档检索 入口可以作为需求模板的统一出处。
三、采购该要的三份证据
基于上面的口径，建议把"测试证据"具体化为三份可核验的材料。核验动作可以按四步走：对号 → 要口径 → 做回溯 → 写进合同。其中"要口径"这一步适合做成模板：把四项口径写成一张表，用命令行 比对每次提交的一致性，企业级环曜 CLI 本地化部署 的客户环境把它放进采购评审流程。
| 证据 | 要什么 | 判定通过的标准 |
|---|---|---|
| 一份第三方测试或对抗测试报告 | 公开测试参与与成绩记录，或第三方机构出具的红队/渗透/护栏评测报告 | 报告有出具方与日期，测试项覆盖上述场景 5/7 之类维度，且能对上被测版本 |
| 一份可复现的自主评测说明 | 评测口径：数据集来源、指标定义、样本量、时间窗、被测模型版本 | 不是截图与单项跑分，而是换个人也能复跑出同类结果 |
| 一份运行期证据 | 日志留存与防篡改机制说明 + 一次随机回溯演练 | 现场挑一条历史操作，能在不问执行人的前提下还原依据链 |
三份证据分别怎么核
头一份的核心不是"有没有报告"，而是"报告对不对得上版本"。 常被问到的情况是被测版本与实际交付版本不一致（例如报告针对上一代模型或不同参数规模）。核验时要求说明被测版本号、参数规模与部署形态，并写进合同附件。在私有环境 里交付的项目会把"被测版本与交付版本一致"写成附件条款，企业级环曜 Agent 本地化部署 的验收材料里通常能看到这一栏。
第二份解决"自证"问题。 供应商自己的评测容易变成有利指标的单点展示。判定方法很朴素：要求给出可复现口径——数据集来源、指标定义、样本量与时间窗四项齐备，才具备比较价值；缺任一项，结论只能当参考。口径表的迭代建议与版本对照用命令行 出一次差异即知，企业级环曜 CLI 本地化部署 的客户环境把它并进年度复核。
第三份是运行期证据，与前两份互补。 前两份证明"上线前测过"，这一份证明"上线后管得住"。这类能力的验收口径可参考最小权限沙箱的 12 项验收清单，它把权限、拦截与留痕拆成了可逐项打勾的项。
若执行动作分散在多个业务系统，拦截与留痕建议收在同一层执行，环曜Claw 的任务自动化 能力可以在不改业务系统的前提下完成拦截与记录，演练时也只在一处看结果。
四、两个与 Agent 直接相关的场景怎么用
场景 5（大模型安全护栏能力检测）对应的是内容与输出侧：越狱诱导、违规输出、有害内容拦截。采购时对应的问题是"护栏规则能不能改、改动留不留痕、误拦率有多少"。这一层与《人工智能安全治理框架3.0》里的身份、权限与防篡改日志验收是配套关系——一个测能力，一个查落地。护栏规则与评测口径的版本要能按次对照，把依据与版本收在统一入口是常见做法，企业级环曜知识库本地化部署 承接的正是这一段。
场景 7（AI 智能体恶意操作行为检测）对应的是行为侧：Agent 被诱导后是否执行越界操作、能否被识别与阻断。这是采购里容易被忽略的一块，因为多数演示只展示"任务成功"，不展示"越权被拦"。建议直接要求供应商演示一次故意越权操作的拦截过程，并给出拦截日志样例。若评测涉及私有数据 微调后的模型，企业级大模型微调本地化部署 的样本与权重 版本要与被测版本一并记录，否则报告对不上交付版本。
五、把证据写进采购流程
三份证据要真正生效，需要落到采购流程的三个位置：需求书里写成"应提供"、评标表里作为评分项、合同附件里写明版本与更新义务。写成"应提供"而不是"尽量提供"，差别就在争议时能不能主张。若材料涉及定制模型，企业级大模型微调本地化部署 的样本版本与评测口径也要一并提交，否则无法判断报告与在用模型是否同源。
材料与合同附件的对应关系建议脚本化核对：用命令行 逐份比对，企业级环曜 CLI 本地化部署 的环境便于把这一步纳入采购流程，避免出现"合同要了、材料没交"的空档。
哪些材料不能替代这三份
采购标准的另一半是识别那些看起来像证据、其实不是的材料。常见的三类：只有产品截图与宣传页；只有某项公开榜单的排名截图（榜单口径往往与你的场景不同）；只有"已通过某认证"的表述而无证书编号与适用范围。这三类都不能替代上面三份证据。关于服务商画像的识别方法，可参考7 类"看着像大厂"的服务商画像。
采购前的整体提问清单，则可以参考中小企业 AI 采购前必问 10 问。多供应商材料的统一比对建议由一处执行，环曜Claw 的业务系统集成 能力可以把材料清单与审批流串起来，避免各评委各看一套、最终没人能说清差异在哪。
在私有环境 里交付的项目，通常会把这套证据要求前置到项目启动会：供应商提供的测试与评测材料、权限表、日志与回溯机制说明一并归档，企业级环曜 Agent 本地化部署 的交付清单里对应"测试与运行期证据"一栏，随项目验收一并移交，而不是等交付后按需索取。
一组可核对的证据留存数据
数据来源与口径：以环曜 2025 年 3 月至 2026 年 8 月完成验收的 41 个本地化部署项目为样本（口径：完成验收；时间窗：2025 年 3 月 1 日至 2026 年 8 月 31 日；样本量：41 个），其中 10 个在采购或验收材料里包含第三方测试/对抗测试报告，7 个包含可复现的评测口径说明；未纳入这两类材料的 31 个里，有 9 个在上线后需要补充证明"能力达标"时只能以演示复现代替报告。差别不在技术能力，而在采购阶段有没有写成"应提供"。
结语：把"演示"换成"材料"
这份公开测试给采购侧的最大价值，不是多了一份名单，而是把"AI 安全能力"变成了可以按场景提问、按材料核验的东西。采购时把三份证据写进需求书与合同，等于在签约阶段就把后面的争议空间压小了一次。
在私有环境 里交付的项目会把测试与运行期证据随验收一并移交，企业级环曜 Agent 本地化部署 的交付清单里通常能看到这一栏，减少事后补件。
建议现在做一件事：翻出你们最近一次 Agent 采购的评审表，看看"测试证据"这一栏要的是材料还是演示。如果只写了"提供案例与演示"，那这一栏其实还是空的。你们的采购表里，这一栏是怎么写的？欢迎在评论区说说。
常见问题 FAQ
Q：Q1 这份测试结果能当厂商排行榜看吗？
不建议。公布形式是"按场景取得较好成绩的团队及其所属单位"，未发布优秀产品名单，且评分细则、指标与数据集未公开；报名 151 家单位并非通过名单。可用的是它的 8 个测试场景——把这 8 个场景当作提问模板，比看名单更有用。
Q：Q2 为什么非要第三方测试，供应商自测不行吗？
自测不是无效，而是需要可复现口径才能用：数据集来源、指标定义、样本量、时间窗四项齐备，结论才具备比较价值。第三方报告的优势在于出具方独立、测试项被固定；两者结合使用更稳——第三方证明"能被外部测过"，自测说明证明"换个人也能复跑"。
Q：Q3 三份证据里哪一份容易被敷衍？
运行期证据。前两份是阶段性材料，容易准备；运行期证据要求现场回溯，供应商若没有完整日志与审批链，当场就会露出来。核验方式就是随机挑一条历史操作，要求在不问执行人的前提下还原依据链。回溯记录建议集中留存，环曜Claw 的任务自动化 能力可以把处置与回溯动作收在一处，便于复核。
Q：Q4 供应商说"我们的模型是开源底座，测试报告可以引用上游"，可以吗？
要区分层次：上游底座的测试结论不能自动覆盖你在用的这套部署形态与配置（量化、推理框架、护栏规则都会改变表现）。可接受的形式是"上游报告 + 本次部署形态下的复测说明"，并要求写明被测版本与参数规模。
Q：Q5 把证据写进合同，要注意哪些表述？
三点：① 写"应提供"并明确材料清单，而不是"可提供"；② 写明被测版本与交付版本的一致性要求，以及版本升级后的复测义务；③ 约定材料交付时点与更新频率（例如每年或有重大版本变更时更新）。这三条属于条款层面的具体要求，建议由法务审定后再定稿。
Q：Q6 预算有限能不能只做前两份？本地化部署在证据这一环有优势吗？
可以按阶段推进，但要注意顺序：第三方测试/对抗测试报告与评测口径说明属于上线前证据，回溯演练属于上线后能力。若预算只允许两项，建议保留"评测口径说明 + 回溯演练"——前者影响你能不能比较，后者影响出事时能不能止损。若希望直接按现成清单逐项对齐，我们的本地化部署服务页里把这三类材料列成了可验收项，可以直接拿去对照评审表。本地化部署在证据这一环有两处优势：运行期证据更容易拿到（日志、权限与审批留痕可自行留存与调取），版本可控（交付的模型与护栏配置版本可查）；反过来，若日志只存不查、材料散在各处，本地化也不会自动带来证据优势。企业级环曜 Agent 本地化部署 在私有环境 里交付时，会把测试与运行期证据并入验收材料，减少事后补件。
