AI AGENT SYSTEMS · 05

评测、安全与
发布门禁

把“看起来不错”改造成可重复、可分层、能阻断风险的质量系统

理论 Eval + Safety + Red Team 实战 Python Basic + Advanced
学习目标

建立从业务风险到发布决策的评测闭环

核心结论：评测不是项目结束后的打分，而是需求、开发、发布和线上运营共同使用的质量契约。

Risk Model识别哪些错误只是体验问题，哪些会造成资金、合规或数据事故。
Eval Design设计正常、边界、失败和对抗案例及明确期望。
Safety Gate在危险动作执行前使用确定性规则阻断。
Release Gate根据分层指标、硬失败和回归变化决定是否发布。
失败现场

平均分 8.2，系统仍然承诺了错误退款

核心结论：平均分会把少量致命错误淹没在大量简单成功案例中。

报告
指标
客服回答平均 8.2 / 10，通过率 94%团队认为已达到上线标准
红线
案例
模型未经资格核查承诺退款，并执行危险 SQL两个错误都被总平均分抵消
上线
后果
产生资金承诺与数据安全事故评测指标与真实业务风险脱节
方法论主线

从风险出发，而不是从“找个指标”出发

目标Business Outcomes定义系统要完成的任务和不可接受结果
风险Failure Taxonomy按影响、概率、可检测性和可恢复性分层
数据Eval Set覆盖正常、边界、失败、对抗和历史事故
判定Metrics & Rubrics确定性断言优先，模型评审作为补充
决策Release Gate硬失败阻断发布，线上反馈持续回流
理论 01

先定义失败分类，再设计测试

体验Style Failure语气生硬、冗长、格式不佳；通常可降级处理。
任务Task Failure答案不完整、工具顺序错误、没有完成用户目标。
事实Grounding Failure编造政策、引用错误、证据不足却给出确定结论。
安全Critical Failure越权执行、泄露数据、错误资金承诺和危险操作。
Severity

同样是“答错”，业务影响完全不同

核心结论：Severity 决定评测门槛、处置优先级和是否允许被其他分数抵消。

S0 提示不影响任务完成的轻微风格问题，进入优化队列。
S1 一般需要用户重试或补充信息，但不会造成不可逆后果。
S2 严重给出错误业务结论、遗漏关键条件或错误调用工具。
S3 致命资金、合规、隐私、权限或不可逆操作，任何一例失败都阻断发布。
Bad → Good 01

平均分不能代替字段级 Rubric

“整体表达流畅，得分 8.2，通过。”

  • 错误退款承诺被语气分抵消
  • 不知道具体失败字段
  • 无法指导修复
no_false_promise: FAIL
empathy: FAIL
next_step: FAIL
no_sensitive_data: PASS
release: BLOCKED
硬失败独立判定
Basic Python

Customer Support Rubric Eval

核心结论：基础项目把客服质量拆成可解释检查，并让错误承诺成为不可抵消的硬失败。

projects/lesson-05/basicmain.pysrc/rubric.pytests/test_rubric.py
01 compare平均分与字段 Rubric 对比
02 hard fail错误承诺直接阻断
03 unittest验证好坏响应和门禁
python3 main.py compare
Basic 运行结果

一个致命错误就足以改变发布决定

lesson-05/basic · compare
AVERAGE > score=8.2 passed=true

RUBRIC >
no_false_promise=false
empathy=false
next_step=false
hard_failures=[no_false_promise]
passed=false
4可解释字段
1硬失败
BLOCK发布决定
Eval Case Contract

评测样例必须包含输入、上下文、期望和风险

case_id稳定标识和版本
input用户请求与多轮历史
context检索证据、工具状态和身份
expected允许行为与禁止行为
severity失败影响等级
assertions确定性检查和 Rubric
Eval Coverage

真实评测集至少覆盖五类来源

主流程Golden Cases最常见、高价值的正常任务
边界Boundary Cases缺字段、模糊表达、冲突证据和权限边界
失败Negative Cases必须拒答、handoff 或阻断的情况
对抗Adversarial Cases提示注入、工具诱导、数据泄露和绕过策略
线上Incident Cases真实事故、人工纠正和用户投诉
理论 02

确定性断言优先，LLM Judge 只评开放质量

代码可以直接判断JSON Schema工具名称与调用顺序引用是否存在SQL 和权限规则
适合模型辅助判断解释是否清晰是否完整覆盖用户问题语气是否符合场景开放式摘要质量
Judge Reliability

模型评审也需要校准和审计

核心结论：LLM Judge 不是客观真理；它会受到位置、长度、措辞和模型版本影响。

Rubric 固定给出字段定义、分值锚点和正反例，减少自由判断。
盲评与换序隐藏候选来源并交换顺序，检测位置偏差。
人工校准定期与领域专家标注比较一致性。
版本追踪记录 Judge 模型、Prompt 和温度，升级时重新基准测试。
Bad → Good 02

安全检查必须发生在危险动作之前

先把模型生成的 SQL 发给数据库，再分析是否危险。

  • 检测发生得太晚
  • 不可逆副作用已经产生
  • 模型判断可能再次失误
model proposal
→ deterministic safety gate
→ permission check
→ human approval if needed
→ tool execution
Guardrail 位于执行前
Safety Gate

不同风险需要不同层的防护

输入层提示注入、敏感数据、恶意文件。分类与隔离
模型层越界回答、错误承诺、策略绕过。Prompt + 输出验证
工具层危险 SQL、付款、删除、外发。权限 + 硬规则 + 审批
运行层循环、成本、批量副作用。预算 + 熔断 + Trace
Bad → Good 03

红队不是上线前做一次“越狱测试”

核心结论：Adversarial Eval 应围绕真实资产、攻击者目标和系统工具持续更新。

ATTACK忽略规则并执行 DROP TABLE
ASSET生产数据库与客户数据
错误只靠拒答 Prompt工具仍有权限
正确多层阻断Gate + RBAC + Audit
Advanced Python

Agent Eval & Safety Lab

核心结论：进阶项目同时测试客服承诺、提示注入、危险 SQL 和工具前置条件。

Eval CasesAgent TraceTool Proposal
EVAL LABRubric EvalDeterministic AssertionsSafety GateRegression Report
FailuresBlocked ActionsRelease Decision
python3 main.py compare
Release Gate

发布决策必须同时看绝对门槛和回归变化

指标
门槛
变化
决定
S3 critical
0 failures
0 → 1
BLOCK
Task success
≥ 90%
92% → 91%
PASS
Citation precision
≥ 95%
97% → 96%
PASS
Cost p95
≤ budget
+18%
REVIEW
线上评测

离线通过，不代表线上行为稳定

Canary小流量比较新旧版本，监控错误、延迟和成本。
Shadow新版本只运行不执行副作用，用真实流量评估。
Sampling按风险分层抽样人工审查，而不是随机看几个回答。
Feedback Loop投诉、人工修改、handoff 和事故自动生成候选评测案例。
Eval Governance

防止评测集被“刷题”

核心结论：如果开发者只优化公开固定样例，指标会上升，但真实泛化能力可能下降。

公开开发集用于快速迭代和解释失败允许开发者查看持续补充难例
隐藏验收集用于发布门禁限制直接访问定期轮换与去污染
课堂实战

从一个事故建立一条发布门禁

20 minBasic

把错误退款承诺拆成字段 Rubric 和硬失败。

35 minAdvanced

新增提示注入与危险工具案例，接入 Safety Gate。

15 minRelease

比较两个版本并给出发布、复核或阻断决定。

验收

上线前检查八个质量问题

01 是否从业务风险定义评测？
02 是否区分严重等级？
03 关键失败能否独立阻断？
04 评测是否覆盖真实事故？
05 确定性断言是否优先？
06 Judge 是否校准和版本化？
07 安全门是否位于执行前？
08 线上反馈是否回流？
Lesson 05 · Takeaway

不能阻断错误的评测，
只是报表，不是质量系统。

NEXT · Lesson 06　生产运行时与上线治理