玄姐聊AGI公众号文章2026-10-21

百度 Agent 评测体系深度架构拆解

公众号 · 40 篇文章

大家好，我是玄姐。

PS：AI 落地点击预约直播。

这两年我带着团队帮 70 多家头部企业做了 130 多个企业级大模型应用项目，我越来越确定一件事：Agent 项目卡在 PoC 走不到生产，十有八九不是模型不够强，而是评测体系没建起来。没有评测，你不知道改了一版 Prompt 是变好还是变坏；没有评测，你不知道换一个底座模型会不会把老功能搞挂；没有评测，老板问一句“这个 Agent 到底靠不靠谱”，你只能拿几条演示截图去回答。

大厂的 Agent 评测，和学术界的静态跑分完全是两码事。它要解决的是从模型选型、组件调试、端到端业务验收，一直到线上运营监控的全生命周期质量保障。业内一般把它归纳为六大模块：

评测目标与多维指标体系
评测集治理与数据工程
分层归因与链路评测
评估器与评测方法论
自动化评测平台与 AgentOps
安全护栏与红队测试

国内把这六块做得最完整、也讲得最清楚的厂商，百度算一个。今天这篇，我就按六大模块逐项拆百度的做法：工具链是什么，方法论怎么设计，算法用在哪里，参数给了什么建议值。同时，我把 2026 年这一年业界最新的评测实践（Anthropic 的 Agent 评测方法论、OpenTelemetry GenAI 语义约定、Gartner 评测与可观测平台市场指南、百度伐谋 2.0 和 DuMate 的最新进展）叠加进来，再加上我自己在项目里踩过的坑。

中间会单开一节，讲百度相比其他大厂最特别的一招：评估器被当成回报函数来设计。如果这篇文章你只能记住一句话，就记这句。

先上一张总体架构图，后面九节都挂在这张图上。

这张图从下往上读：最底层是评测集资产与数据工程，往上是规则、裁判、人工三类评估器，再往上是覆盖模型层、应用层、Agent 层、线上层的四层指标，右侧贯穿的是分层归因与安全红队，最外圈是 AgentOps 数据飞轮把评测结果回流成训练信号。而把整张图串起来的灵魂，就是“评估器即回报函数”。

PS：AI 更多案例深入免费学习去这里，扫码直达：

1.打开 AITutor 新一代 AI 原生学习伙伴：www.aiaitutor.com 2.在首页输入"你想学习的AI知识” 就能看到更详细更丰富案例。3.包含了图文、视频、播客、闪卡、代码、测验等9种学习模态。

一、评测版图总览：平台内嵌式评测

1.1 五块资产对上六大模块

百度的评测版图由五块资产拼成，恰好和六大模块形成映射：

1.2 一句话总评：评测是工具链里的一等功能

百度的评测体系是“平台内嵌式”的。评测不是一个独立部门，而是千帆、AgentBuilder 工具链里的一等功能，和训练、精调、部署、运营跑在同一个闭环里。

这和 OpenAI、Anthropic 的“研究驱动式”评测形成了鲜明对照，也更贴近国内企业的工程落地路径。

1.3 最新风向：评测和可观测正在合并成一个品类

这个判断在 2026 年得到了行业层面的印证。Gartner 今年 2 月发布了《AI Evaluation and Observability Platforms 市场指南》，直接把“评测”和“可观测”放进同一个市场品类里讨论，Comet、Openlayer、W&B 这些厂商都按这个口径重新定位产品。

翻译成大白话：离线评测和线上监控不再是两套系统，而是同一条质量链路的两端。百度从平台层面把评测内嵌进全流程，走的正是这个方向。

我的建议是，企业自建评测平台时，别再单独立一个“评测项目”，而是从第一天就把它设计成研发流水线和运营看板的一部分。

二、指标体系：四层指标金字塔

2.1 指标随被测对象分层

百度的指标体系随被测对象分层：模型层看通用能力，应用层看任务完成，Agent 层看端到端，线上层看业务效果。越往上越贴近业务。

2.2 模型层往下抠，全是工程细节

自动基线评估的四个维度各有子项：

知识问答：拆成常识问答和垂类专业知识；
逻辑推理：拆成数据推理和上下文对话逻辑；
阅读理解：拆成长短文本和代码能力；
文本生成：拆成文本质量和创意程度。

裁判员打分开放三类预置指标：事实性错误、情感倾向、语义连贯，而且裁判必须输出打分理由，判断本身可审计。

几个参数值得记下来：评估任务支持最多 5 个模型版本并发对比；评估数据集标注样本要大于 3 条，上限 10000 条；数据存在 BOS，提交评估后禁止修改，保证评估结果可复现；规则打分支持停用词表，避免特殊字符和高频虚词污染相似度指标。

2.3 三个值得注意的亮点

自动基线评估进精调闭环。精调完成后一键生成评估报告，训练完立刻知道有没有训坏。这是国内平台最早把回归评估做进精调闭环的实践之一。
代码助手做第三方对标。文心快码在 IDC《中国代码生成产品评估 1H25》9 项维度中 8 项满分，服务超 110 万企业用户。百度把进入权威第三方评测本身当作质量战略。
评估维度可自定义。千帆裁判员评估器开放打分指标、步骤、满分制自定义，企业可以按业务定义及格线，而不是套用通用分。

2.4 边界：工程化优先于学术化

需要说明一个边界。意图理解率、Pass@k、Progress Rate、Grounding Accuracy 这类轨迹级指标，在百度体系里主要出现在研究侧（FM Agent 的评估器设计、TransBench 对 GUI Agent 的 grounding 评测），平台侧则收敛为“四维基线 + 命中分 + 业务 A/B”。

工程化优先于学术化，这是百度口径的鲜明取舍。

2.5 补一课：pass@k 和 pass^k 不是一回事

既然提到 Pass@k，我顺手补一个今年很多团队开始重视的点。Anthropic 在《Demystifying evals for AI agents》里把两个指标讲得很透：

pass@k：k 次尝试里至少成功一次的概率，k 越大越高。适合“有一次做对就够”的场景，比如代码生成后有测试兜底。
pass^k：k 次尝试全部成功的概率，k 越大越低。单次成功率 75%，连续 3 次全对只有 0.75 的三次方，约 42%。

面向客户的 Agent，真正该看的是 pass^k。用户不会给你三次机会，客服 Agent 十次里错三次，用户感知就是“不靠谱”。我们在金融、保险客户的项目里，验收口径一律加 pass^k，这一条能挡掉大量“演示很惊艳、上线就翻车”的情况。

三、评估器：规则、裁判、人工三角互证

3.1 三评估器全部 SDK 化

千帆的评估器体系是“三角互证”结构，全部 SDK 化、可组合：

规则评估器：计算预测和标注的文本相似度（ROUGE、BLEU 等）与 accuracy，适合标准选择题或简单问答。便宜、可复现、没有裁判偏差。停用词表过滤是必做的前置清洁。
裁判员评估器：用能力更强的模型做裁判，打分 Prompt、步骤、满分制全开放。预置模型可选 ERNIE 4.0、4.0 Turbo、3.5，也支持拿你自己的模型当裁判。裁判输出打分理由，适合开放性、复杂问答。
人工评估器：平台完成人工打分后回收结果，支持多人协同，可按满意度、事实性、逻辑性、创造性分维度打分。自动评估和人工复审可以串成流水线。

三者组合后，由 EvaluationManager 一次调用产出双份结果：单条评估明细（每条输入输出加单条指标）和总体指标字典。逐条可查，总体可比。

3.2 千帆杯：一套可以直接抄的两轮评测流程

方法论上最有参考价值的，是“千帆杯”AI 原生应用挑战赛的评测流程设计：

这套设计的精髓在于：模型裁判负责规模，规则负责可解释，人工负责最后一公里。三者各管一段，谁都不包打天下。

3.3 研究侧的评估器算法

研究侧同样有干货。

FM Agent（百度智能云，arXiv:2510.26144）的领域评估器把 correctness、effectiveness、LLM-supervised feedback 三路结合，配合多进化岛并行的进化采样策略，在 MLE-Bench 拿到 43.56%（提升 4 个百分点），ALE-Bench 1976.3 分，KernelBench 最高 20 倍加速。
TURA 的轨迹蒸馏用双裁判模型串联：Jcorrect 校验 API 调用合规性、参数有效性、思维链逻辑合理性；Jefficient 分析动作冗余和路径效率。低效轨迹被修正或剔除。“正确性 + 效率”双闸门的轨迹质量过滤，是 Agent 数据工程里少见的完整细节。
安全评测侧，风险自动标注结合上下文语义综合判断回答安全性，自动生成可追溯、可核验的评测依据，把“裁判判断本身可审计”工程化了。

3.4 对照最新实践：评结果，不评说辞

把百度的三角互证和 Anthropic 今年公开的 Agent 评测方法论放在一起看，有三点高度一致，也有一点值得互补：

优先评结果，而不是评 Agent 的自述。Anthropic 强调 outcome 优先：订票 Agent 说“已预订成功”不算数，要去数据库里看订单到底在不在。这和百度规则评估器“能用确定性校验就不用模型”的思路一致。
能用代码判就别用模型判。代码评估器快、便宜、可复现；模型评估器灵活但不确定，必须用人工标注做校准；人工是金标准，但主要用来校准模型裁判。这就是三角互证的国际版本。
多步任务给部分分。一个十步的 Agent 任务，做对八步和一步都没做对，不能都记 0 分。

互补点：给裁判一个“不确定”选项。Anthropic 建议给 LLM 裁判留一个 Unknown 出口，减少裁判硬判产生的幻觉。千帆杯的做法是“不确定算选手赢”。我在项目里把两者合起来用：裁判输出不确定的样本，自动路由到人工复核队列，既不误杀，也不放水。

四、深挖：评估器即回报函数，百度最被低估的一手

复盘百度的评测体系，如果只能带走一条认知，我选这条：

别家大厂的评测回答“这个模型几分”，百度的评测回答“下一步往哪搜、往哪调、往哪训”。

评估器在百度体系里的角色，更接近强化学习里的回报函数，而不只是一把量尺。证据链有三条，分别落在平台、研究、运营三个层面。

4.1 证据一：评估织进精调流水线

千帆的自动基线评估挂在精调任务的下游，训练完成即自动触发：ERNIE-4.0-8K 当裁判，预置基线集打分，一键生成报告。这个 checkpoint 的分数直接决定它有没有资格进模型广场参与排序。

评估在这里是流水线的一环，每个产出的模型都被自动评一遍，不存在“训完了没人评”的灰色地带。

对照多数团队的现状：训练脚本一堆，评估靠人想起来才跑，评完还要手工整理报告。差距的根源不在工具，而在于评估有没有被当成流程的必经节点。

4.2 证据二：评估器驱动进化搜索，High 难度段领先 9 个百分点

FM Agent 是这套思维的极致呈现。它用“LLM 推理 + 大规模进化搜索”解机器学习工程问题，进化搜索每一轮都要靠领域评估器给候选解打分、选父代、分配资源。评估器就是这套系统的适应度函数（fitness function）。

三路信号分工很清晰：

correctness 管跑得对不对（测试通过）；
effectiveness 管跑得好不好（指标高低、效率成本）；
LLM-supervised feedback 管人类偏好这类难量化的维度。

三者合成一个累积信号，持续喂给搜索过程。

结果也证明了评估器信号质量的价值。MLE-Bench 奖牌率对比里，FM Agent 总分 43.5%，比第二名 Operand ensemble 的 40.0% 高 3.5 个百分点。拆到难度分段看，Low 难度两家 62.0% 打平，真正拉开差距的是 High 难度段：33.5% 对 24.5%，领先 9 个百分点。

为什么是高难度段拉开差距？低难度拼的是代码生成的下限，高难度拼的是评估信号的信噪比。任务复杂到候选解好坏难辨时，进化方向全靠评估器引导，信号一脏，搜索就跑偏。

支撑这套评估的还有 Ray 构建的分布式异步基础设施，大规模并发评估让评估吞吐不成为进化搜索的瓶颈。这一点常被忽略：进化式系统的搜索上限，往往就是评估吞吐的上限。

最新进展是，2026 年 4 月百度伐谋 Agent 2.0 再次登顶 MLE-Bench 并刷新 SOTA，官方口径是在高难度任务的综合胜率上相对基于各类主流模型的 Agent 显著领先，并在 5 月的 Create 2026 百度 AI 开发者大会上正式发布。高难度段持续领先，和上面的分析是吻合的。

4.3 一个容易忽略的细节：评估器和底座解耦

FM Agent 的底座模型是 Gemini-2.5-pro，不是文心。

评估器方法论和自家底座是解耦的。评估器是平台能力，哪家的模型都能评，都能拿来当裁判。这正是“评估器即回报函数”思维的延伸：回报函数本身也是可插拔组件，与被评对象、被用对象分离。

国内不少团队做评测容易陷进“用自家模型评自家模型”的自证循环，百度的解耦给出了一条明路。

4.4 证据三：数据飞轮，评测结果不封卷

运营侧的承接是 AgentBuilder 数据飞轮（第七节展开）。分析看板诊断出的坏例不停留在报告里，分发数据反馈直接回流底座自主调优。

评测数据的身份变了：它同时是训练数据。这条链路把“评测发现了问题”到“模型变好了”之间的距离压到最短，中间没有人工整理、重新标注、排期训练的断点。

4.5 三条证据合起来：QC 思维与 RL 思维的分野

把百度和 OpenAI、Anthropic、Google 放在一起看，评测职能的组织学位置完全不同：

这个分野有历史根源：百度起家于搜索，在线 A/B 和 SSR、GSB 这类实时质量信号本来就是它的核心生产系统，评测职能天然长在闭环里。

4.6 硬币的反面：Goodhart 定律与三道对冲

评估器决定优化方向，就一定会触发 Goodhart 定律：指标一旦成为目标，就有人（或模型自己）开始迎合指标。

在评估器即回报函数的体系里，评估器的偏差会被搜索和训练系统性放大，一个偏门的评估维度，可能诱导出一整支“应试型”模型。百度的对冲手段有三个，都值得抄：

分库隔离：评测集与训练集在平台内分库隔离，切断“照着答案练”的通路。
隐藏测试集纪律：MLE-Bench 2026 年 3 月新增清洁赛道后，FM Agent 2.0 以干净成绩重回主榜榜首，参评纪律经得起第三方检验。
裁判可审计：裁判打分理由强制输出且可审计，让“裁判为什么这么判”始终可追问。

另外还有一处保守倾向设计：千帆杯规则里“裁判未明确判负即算选手得分”，系统性压低裁判误杀率。这和我们做评测平台的经验同源：假通过比假失败更危险，宁可多一轮人工复核，也不要让裁判的误杀把好的被测对象劝退。

再补一个今年很有说服力的反面案例。Anthropic 公开过：Claude Opus 4.5 在 CORE-Bench 上最初只拿到 42%，修掉评分脚本的 bug、放开过于死板的脚手架约束之后，分数到了 95%。同一个模型，分数差了一倍多，差的全是评估器。评估器本身的质量，决定了你看到的是真实能力还是噪声。所以评估器也要被评测，这件事一定要有专人负责。

4.7 可操作结论：先问“这个结果驱动什么动作”

给自建评测体系的团队，这一节的可操作结论是：设计任何评估维度之前，先回答“这个评估结果驱动什么动作”。

驱动得了精调回滚、驱动得了检索参数调整、驱动得了 Prompt 重写的指标，才值得建；驱动不了任何动作的指标，只是给周报提供装饰。

五、分层归因：“答案哪来的”一次点击

5.1 复合系统失败了，到底是谁的锅

Agent 是“大模型 + RAG + 工具 + 编排”的复合系统。端到端失败时，必须回答清楚：是意图解析错了，检索召回差了，重排序失误了，还是生成产生了幻觉？

百度把归因能力直接做进了 AppBuilder 的产品交互里：

5.2 参数建议：具体到可以直接抄

AppBuilder 混合检索同时执行 BM25 全文检索和向量语义检索，两路分数归一化后加权合成最终相关性分。给出的参数建议非常具体：

召回数量 K 从 8 起步。K 太小会漏关键信息，太大会引入冗余上下文和生成噪声，按生成模型的上下文窗口渐进增减。
匹配分阈值从 0.2 起步。先统计 score 分布，再动态设定。
重排序分数“覆盖或主导”最终排序，修正两路初排序的固有偏差。
场景化选型：电商搜索用混合检索，法规条款查询用全文检索，口语化客服用语义检索。

这张“策略与场景”映射表本身就是归因方法论的沉淀：先选对检索算法，再谈调参。

5.3 线上归因：不止于报告

千帆模型监控面板实时追踪调用次数、响应时间、输出质量。检测到某模型准确率下降时，自动触发模板优化流程，通过 A/B 测试选出最优 Prompt 版本。一个典型阈值案例：某金融风控 Prompt 准确率波动超过 5% 即触发优化。

5.4 短板与补法：轨迹级归因用 OpenTelemetry 补

轨迹级归因（逐步回放 Agent 的 thought、action 链）在百度公开体系中体现为 AppBuilder 的链路调试加来源定位，粒度到“组件 + 切片”级，而不是“步”级。轨迹回放能力在研究侧（TURA 的轨迹合成与过滤）更成熟，平台侧尚未完全产品化。

这块短板，2026 年的行业标准已经给出了补法。OpenTelemetry GenAI 语义约定在今年迭代到 v1.41，对 Agent 的链路做了标准化定义：

invoke_agent：一次 Agent 执行任务的 span，按本地框架执行和远程调用区分；
invoke_workflow：v1.41 新增，专门描述固定路径的工作流，和自主决策的 Agent 区分开；
execute_tool {工具名}：工具调用 span，名字里必须带工具名，参数和返回值在隐私策略允许时才记录；
gen_ai.evaluation.result：v1.38 引入的评测结果事件，带分数值和标签，可以把评估器的打分直接挂到对应的链路上。

需要注意，这套约定目前仍处于 Development 状态，属性名还可能调整，但核心概念已经比较稳定。

我的建议是：自建 Agent 平台时，链路埋点直接对齐 OTel GenAI 语义约定，评估器打分以 evaluation 事件挂在 span 上。这样“哪一步错了”和“这一步得了几分”在同一条 trace 里，步级归因就有了数据底座，以后换可观测平台也不用重新埋点。

六、评测集治理：数据集当资产管

6.1 评测集与模型同权重

千帆把评测集当作和模型同等权重的资产来管，覆盖构建、标注、清洗、版本化、复用全链：

数据集 SDK 化：千帆 Python SDK 的 Dataset 对象支持本地构建、云端发布、load() 复用。评估用数据集和训练用数据集同构，一次治理两处受益，天然形成版本锚点。
一站式数据工程：平台内置数据标注、清洗、增强服务，支持自定义标注规则与质量评估；另有独立的大模型语料清洗系统，风险检测加自动化脱敏，脱敏后的文件可直接用于训练。
AgentBuilder 数据集接入：支持大容量、多格式（文本、表格、图片、音视频）、多途径接入，可设置定期刷新，把“知识保鲜”做成了平台能力。
安全评测数据构造：按风险分类、攻击类型、多模态场景三个维度自动生成标准化评测数据，可用改写模型按需定向扩产；舆情风险监测每日自动聚合境内外热点，自动构建标准化测试样本，评测集本身是活水。

6.2 标杆案例：深度研究任务的评测集工程

数据治理的标杆案例，是深度研究任务的评测集构建。

百度千帆深度研究 Agent 参评的 DeepResearch Bench（中科大团队，2025 年 6 月发布）是这样建的：从约 9.6 万条真实用户查询中筛出 44,019 个深度研究任务，统计 22 个领域的真实需求分布，再由各领域博士级专家设计 100 个中英文对等任务。它的 RACE 报告质量评估框架与人类专家判断的一致性达到 71.33%。

百度千帆深度研究 Agent 于 2026 年 2 月登顶该榜，DuMate 于 2026 年 5 月以 58.03 分保持第一。

“真实分布采样、专家设计、动态标准评估”，这套评测集工程是数据治理模块的行业标杆。

6.3 最新进展：DuMate 把评测标准反过来用于生成

今年 6 月百度智能云公开了 DuMate-DeepResearch 的技术报告（arXiv:2606.07299），有一个点特别值得做评测的同学关注：基于 Rubric 的测试时优化。

它会为每个任务动态生成专属的质量评判标准，然后用这套标准反过来指导证据整合，并决定研究什么时候可以停止。同时每个中间决策和工具调用都显式可追溯。报告给出的成绩是 DeepResearch Bench 总分 58.03%，DeepResearch Bench II 61.95%，信息召回和分析维度排名第一。

看到没有？评测标准不只是赛后打分用的，它被前移进了推理过程本身。这又是一次“评估器即回报函数”的体现，只不过这次回报函数作用在测试时，而不是训练时。

6.4 防数据污染：三条路径

评测集与训练集在平台内分库隔离；
自研 Agent 参评的国际基准（MLE-Bench 等）均在隐藏测试集上评分，MLE-Bench 2026 年 3 月因竞品数据泄漏争议新增“清洁赛道”后，百度伐谋（FM Agent）2.0 以干净成绩重回主榜榜首，反证了评测纪律；
千帆自动基线评估预置平台评测集，避免企业自造集子带来的口径漂移。

6.5 另一翼：Prompt 资产库

千帆预置了 200 多个经产业实践验证的 Prompt 模板，覆盖金融、医疗、教育、电商等场景，每个模板带输入示例、参数配置和效果评估指标，配合三级管理体系（基础库、行业模板、自定义工作台）与 Prompt 链技术。

这实质上是把评测的输入侧也标准化了：模板质量先被平台评测过，业务再基于模板做增量评测，误差传播被前置压缩。

6.6 我的补充：评测集从哪起步

很多企业一提评测集就想着先攒一万条，结果半年都没开工。结合 Anthropic 的建议和我们的项目经验，起步三条就够：

从 20 到 50 条真实失败案例起步，线上投诉、测试 bug 单、业务专家吐槽，都是最好的种子；
正反样本要平衡，既要测“该做的时候做没做”，也要测“不该做的时候有没有乱做”，否则会把 Agent 优化成什么都敢调工具的愣头青；
区分能力集和回归集：能力集通过率低，给团队一座要爬的山；回归集通过率应该接近 100%，守住老功能。能力集的题刷到高通过率之后，就“毕业”进回归集。

七、AgentOps：评估织进全流程，数据飞轮不封卷

7.1 评估织进全流程工具链

千帆把评估织进“数据准备、训练、部署、监控优化”全流程：

自动化评估流水线：集成单元测试、集成测试、A/B 测试三段，平台口径是“开发即验证”；支持和 Jenkins 等 CI 工具对接，提交代码或 Prompt 自动触发回归评测。
Prompt 版本管理与回滚：版本控制记录每次修改的 diff，权限分级支持团队协作，效果监控统计每个 Prompt 的实际使用指标。
全链路监控三条线：资源线（GPU 利用率、显存），质量线（输出合规性检测），成本线（按 API 调用拆分计算消耗），异常自动触发预警与回滚。

7.2 数据飞轮三层调优

运营闭环看 AgentBuilder 的“数据飞轮三层调优”，这是国内把 AgentOps 讲得最完整的运营评测设计：

三层首尾相接才是飞轮：冷启动靠平台预评测，运营中真实交互产生新评测数据，数据再回流训练。这也是第四节“评估器即回报函数”在运营侧的落点。

7.3 工程节奏的实证

某银行智能客服项目，传统模式要 3 周，千帆路径压缩到 3 天：第 1 天用模型评估工具筛选最优金融模型，第 2 天调用金融模板微调，第 3 天压测上线。

另一组数字同样说明问题：使用千帆的企业，平均 AI 开发周期从 3 个月缩到 2 周，模型迭代频率从季度级提到周级。

迭代频率的提升，本质是评估吞吐的提升。你一周能可信地评几轮，就能一周迭代几轮。

7.4 最新实践：评测驱动开发

2026 年业界在 AgentOps 上最大的共识变化，是从“开发完再评测”走向评测驱动开发（Eval-Driven Development）：

先写评测，再写 Agent。规划一个新能力时，先把它写成评测任务，此时 Agent 肯定过不了，然后迭代到通过为止，和 TDD 一个思路。
评测任务走 PR 流程。产品经理、业务专家都可以像提代码一样提评测用例，评测集和代码一起评审、一起版本化。
评的是 Harness 加模型的整体。你评的从来不是一个裸模型，而是模型加上脚手架、工具、记忆、编排的整体，换任何一块都要重新跑回归。
每次试验环境隔离。每个 trial 从干净环境起步，避免共享状态导致的相关性失败，否则同一个 bug 会在十条用例里“连坐”，把你对能力的判断带偏。

把这四条和千帆的“开发即验证”放在一起，就是一套完整的 Agent 研发质量闭环。这也是我们在给企业建 AI 原生研发体系时，Harness 和 Loop 两块必须一起设计的原因。

八、安全红队：以攻促防的算法化

8.1 安全护栏六类能力

百度大模型安全护栏获得中国信通院大模型安全护栏能力评估优秀级，产品矩阵覆盖六类能力：

8.2 红队四步流水线

红队的打开方式，是攻击模拟引擎驱动的四步流水线：

攻击向量库：基于历史攻击数据与威胁情报构建，覆盖提示词注入、对抗样本、模型窃取等类型，并动态扩展；
自动攻击生成：结合遗传算法与强化学习，自动生成对抗性输入；
沙箱攻防：在沙箱环境中多模型版本并行对比；
裁判自进化：通过微调“裁判大模型”做自动化对抗测试，要求护栏的防御能力跑在攻击者前面。

注意第 2 步和第 4 步：攻击方用遗传算法和强化学习进化，防守方的裁判也在进化。这又是一个以评估器为回报函数的闭环，只不过这次是攻防对抗版。

8.3 几个硬数字

裁判大模型自动标注准确率 95% 以上，超过人工水平；

安全评测集覆盖金融、医疗等 20 个垂直领域，持续吸纳最新风险事件与对抗样本，保持题库活性；

vivo 连续三年的实测合作中，隐蔽攻击拦截成功率 98.7%，较传统方案提升 32 个百分点，模型安全漏洞发现周期从 72 小时压缩到 8 小时；

端侧离线审核算子把算力占用降低 40%，满足 GB/T 45654 对离线审核能力的国标要求；

这套安全评测体系已服务超过 200 家企业客户，日均处理安全请求 12 亿次。

8.4 安全评测产品线：例行化而非一次性

安全评测产品线形成了完整流水线：评测数据构造，风险自动化脱敏标注（可追溯可核验），策略配置管理，自动化评测报告（风险识别、分析、优化建议），数据看板（风险趋势与异常定位），舆情事件监测。

方法论上，百度强调以攻促防的例行化安全评估：安全评测要做成嵌入训练、精调、推理、部署、运营全生命周期的例行机制，上线前的单次检查只是起点。

8.5 我的补充：Agent 安全评测要盯住工具调用

Agent 和聊天机器人的最大区别是它会“动手”。所以 Agent 的安全评测，重点必须从“说了什么”转到“做了什么”：

工具调用环节单独设红线用例，比如越权查询、批量删除、对外发送敏感数据，每一条都要有确定性校验；
间接注入要专门测，网页、邮件、文档里埋的指令，才是 Agent 时代最主要的攻击面；
评估器要防投机取巧，Anthropic 专门提醒过评分器要能抵御捷径和绕过，否则 Agent 会学会“看起来拒绝了，实际已经执行了”。

九、总评与可借鉴清单

9.1 七个维度成熟度打分

9.2 七条可借鉴实践

对想自建评测体系的团队，七条可以直接落地的实践：

评估器三角互证：规则打底、裁判模型补位、人工兜底，并用“裁判未明确否决即算通过”的保守倾向压低误杀率。
把评估器当回报函数设计：每个评估维度先回答“结果驱动什么动作”，驱动不了动作的指标不建；评估信号被搜索或训练消费时，同步上隔离、隐藏集、可审计三道对冲。
评估集 SDK 化与版本化：评测集与训练集同构管理，评估可精确复现，回归才有锚点。
归因做到切片级点击：检索策略、Top-K、阈值、重排序四要素对比测试，“答案哪来的”必须一次点击可达。
线上即评测：真实交互数据回流成评测集与训练信号，坏例从看板直达修复动作。
红队算法化：攻击向量库加遗传算法、强化学习自动扩产对抗样本，裁判大模型自我进化，安全评测例行化。
参评权威基准作为质量战略：IDC 满分、MLE-Bench 与 DeepResearch Bench 登顶，第三方评测背书与内部评测体系互为放大器。

9.3 我的落地三步走

最后，我给准备动手的企业一个落地节奏，这是我带团队在多个客户项目里验证过的：

第一步，先建回报函数，再建平台（第 1 个月）。从 20 到 50 条真实失败案例起步，每条用例写清楚“结果怎么判”，能用代码判的绝不用模型判。同时定下 pass^k 作为面向客户场景的验收口径。

第二步，把评测接进流水线（第 2 个月）。提交 Prompt、换模型、改工具，一律自动触发回归评测；链路埋点对齐 OTel GenAI 语义约定，评估器打分挂在 span 上，归因先做到组件级和切片级。

第三步，让飞轮转起来（第 3 个月起）。线上坏例自动回流评测集，能力集刷满了就毕业进回归集，安全红队做成每周例行。评估器本身也要被评测，裁判和人工的一致性每月复核一次。

十、写在最后

回看百度这套体系，最值得学的不是某个工具，而是一种组织认知：评测不是质检部门的成本，而是驱动 Agent 进化的生产资料。

当评估器开始决定“下一步往哪搜、往哪调、往哪训”的时候，评测就从一把尺子变成了一台发动机。2026 年 Agent 的竞争，模型能力越来越接近，真正拉开差距的，会是谁的回报函数设计得更准、谁的评估吞吐更高、谁的飞轮转得更快。

如果你对企业级 AI 原生研发体系（Skills、SDD、Harness、Loop、知识飞轮、评测、治理度量）感兴趣，去 AITutor 领取福利。

AITutor 福利：AITutor 每个人的 AI 原生学习伙伴，业界最丰富 AI 实践和案例，4500+ 门多模态 AI 课程、7×24 小时 AI 导师已全面开放，快来免费体验吧。

打开 AITutor，新一代 AI 原生学习伙伴：www.aiaitutor.com
在首页输入「你想学习的 AI 知识」，就能看到更详细、更丰富的案例
包含图文、视频、播客、闪卡、代码、测验等 9 种学习模态

扫码直达：