[!info] related notes

• 所属 MOC: agent-evals-moc、agent-moc
• 前置概念: agent-configuration-bundle、eval-slice-gates、decision-relevant-evidence-gap
• 并列概念: agent-decision-authority
• 易混淆概念: Guardrail / content moderation
• 关系笔记: deny-overrides-policy-composition、agent-behavioral-contract、bodysense-diagnosis-agent-architecture

Agent Safety Envelope

一句话定义

Agent Safety Envelope 是某个具体 Agent Configuration 已经通过评测与治理批准、允许自动执行的条件范围；只有运行时状态落在这个范围内，系统才有证据支持 normal AUTO。

[!important] 重点 SafetyEnvelope 描述的是资格边界，不是模型“有多自信”。

为什么叫 Envelope，而不是一个 Safety Score

Envelope 更像一个多维区域：

scenario type
× risk stratum
× evidence completeness
× configuration capability
× tool availability
× policy state
× user/context constraints

只有落在已验证区域里的 case 才拥有 normal AUTO 资格。

这和单一分数完全不同。

例如：

confidence = 0.95

无法告诉你：

• 有没有 critical user-information gap；
• 是否出现 red flag；
• 当前 tool 是否可用；
• configuration 是否在该 scenario slice 上评估过；
• evidence source 是否允许。

所以 SafetyEnvelope 是多维 eligibility model，而不是“安全度 87 分”。

Safety Envelope 绑定 Configuration

安全边界不是抽象地绑定“这个模型”，而应绑定完整的 Agent 配置组合：

configuration identity
+ supported scenario slices
+ evidence requirements
+ risk constraints
+ tool/evidence policy
+ decision policy
+ hard blockers
+ approved decision modes

换模型、Prompt、Tool Policy、Evidence Policy、DecisionPolicy 或关键治理阈值，都可能改变边界，因此不能默认继承旧配置的批准结论。

为什么模型能力只是 Envelope 的一个维度

假设 Model B 在一般问答 benchmark 比 Model A 更强。

但 BodySense 的批准边界还取决于：

Prompt 是否让它稳定识别 red flag？
Schema 是否表达 EvidenceGap？
Tool policy 是否阻止 user_fact 被 RAG 合成？
DecisionPolicy 是否 deny-overrides？
在 HIGH-risk slice 上 recall 是否达标？

所以：

Foundation Model Capability
≠
Production Agent Safety Envelope

生产资格是整套 Configuration 的属性。

SafetyEnvelope 与 DecisionAuthority 的区别

两个概念经常一起出现，但回答的问题不同。

SafetyEnvelope

回答：

当前 case 是否仍在被证明可以 normal AUTO 的范围内？

例如：

critical gap unresolved
→ outside normal envelope

DecisionAuthority

回答：

既然超出了 normal AUTO 边界，现在具体允许做什么？

例如：

outside because critical diagnostic gap
→ ABSTAIN

outside because new red flag
→ ESCALATE

malformed policy facts
→ BLOCK

所以：

SafetyEnvelope
= eligibility boundary

DecisionAuthority
= authorized action selection

详见 agent-decision-authority。

为什么 Envelope 不应该直接产出所有业务动作

如果把：

inside/outside envelope

直接等价成：

AUTO/BLOCK

会丢失很多有用的业务状态。

例如 outside 可能因为：

non-critical evidence incomplete
→ ALLOW_DEGRADED

critical diagnostic uncertainty
→ ABSTAIN

new red flag
→ ESCALATE

corrupt policy/config
→ BLOCK

所以 envelope 只做 eligibility，具体动作仍交给 DecisionAuthority。

AUTO 的必要条件

一个简化判断是：

inside approved envelope
AND no hard blocker
AND required evidence conditions satisfied
→ normal AUTO may be allowed

这里的 may 很重要：进入 envelope 是自动化的必要条件之一，不代表系统一定要自动执行。

BodySense Diagnosis 的最小 runtime facts 可以包括：

active safety review
new red flag
governance verdict
analysis status
candidate cardinality
unresolved critical EvidenceGap count

SafetyEnvelope 尽量消费结构化 facts，而不是重新解释整段模型自然语言。

Envelope Facts 必须来自 Runtime，不来自模型自报

错误：

LLM output:
"I am inside the safe automation boundary"

正确：

Runtime Facts
├─ criticalGapCount
├─ newRedFlag
├─ activeSafetyReview
├─ configurationID
└─ governanceVerdict
        ↓
SafetyEnvelope evaluation

因为模型既是被约束对象，又不能自己成为唯一裁判。

超出 Envelope 时怎么办

例如 configuration C9 的批准条件要求：

critical evidence gap = CLOSED

运行时却出现：

critical gap = OPEN

那么当前 case 已经超出被验证过的 normal AUTO 边界。

正确路径通常是：

continue evidence acquisition if allowed
        ↓ unresolved
SafetyEnvelope = outside
        ↓
versioned DecisionPolicy
        ↓
ALLOW_DEGRADED / ABSTAIN / ESCALATE / BLOCK

Envelope 应该包含“已证明支持的 Scenario Slices”

平均指标不能告诉你系统在哪些区域可靠。

例如：

overall pass rate = 96%

但如果：

HIGH-risk neurological slice = 80% red-flag recall

那么不能因为总体很高就把 HIGH-risk slice 放进 AUTO envelope。

更成熟的 qualification 会分 slice：

LOW risk
MEDIUM risk
HIGH risk
critical red-flag
specific scenario family
unknown/unsupported

然后分别定义：

eligible decision modes
hard guardrails

这就是 SafetyEnvelope 与 Eval slice gate 的直接连接。

Envelope 可以被看成“Evaluation Evidence 的运行时投影”

Offline Eval 证明：

Configuration C15
在 slice S1/S2/S3 上满足要求
在 S4 上证据不足

Runtime 遇到 case 时，需要把它映射到：

当前 case 属于哪个 risk/scenario/evidence state？

然后判断：

是否落在 C15 已批准区域？

因此 SafetyEnvelope 不应是一个临时手写 if，而应该能追溯到 qualification evidence。

Unknown Case 应该怎么处理

最危险的逻辑是：

没有匹配到任何已知 high-risk rule
→ 当成 LOW risk

更安全：

classification = UNKNOWN
→ dedicated safe path

因为：

unknown
≠
low risk

如果 Eligibility Classifier 本身是安全依赖，也要版本化、评估和记录 provenance。

Confidence 为什么不是 Safety Proof

模型 confidence 描述的是模型自身输出的置信表达或某种估计信号；SafetyEnvelope 描述的是：

系统有哪些评测和运行事实支持，可以授权自动行为。

二者不是同一层级。

所以：

HIGH model confidence
+ HIGH judge score
+ critical gap OPEN

不能被解释为：

“总分很高，所以继续 AUTO”

Hard blocker 不是一个低分项。详见 deny-overrides-policy-composition。

Confidence 可以作为 Soft Signal，但不能覆盖 Hard Boundary

例如 envelope 内已经满足所有硬条件后，可以用 confidence：

Candidate A/B ranking
是否显示更多 uncertainty copy
是否选择更保守解释

但不能用它：

把 outside envelope 改成 inside

所以更准确：

Hard eligibility first
Soft confidence second

Better Model ≠ Larger SafetyEnvelope

即使未来模型明显更强，也不能自动推出：

模型更聪明
→ 可以忽略更多 critical gap
→ SafetyEnvelope 自动扩大

更强模型只是扩大 SafetyEnvelope 的候选理由，真正扩大边界仍需要：

new evidence / production hypothesis
→ regression/challenge cases
→ deterministic + semantic eval
→ critical slices green
→ policy/config revision
→ qualification
→ shadow/canary
→ promotion

[!tip] 一句话 Capability improvement is not authority expansion.

Envelope 如何版本化演化

假设 v1 规定：

any unresolved critical gap
→ outside normal AUTO

后来大量 Eval 证明某类 gap：

• 只影响 candidate ranking；
• 不改变 safety action；
• 已有两个 approved independent sources；
• challenge/holdout 上没有增加风险。

正确演化不是让 LLM 临场破例，而是：

Safety/Decision Policy v1
        ↓
new Eval evidence
        ↓
Policy v2 + new AgentConfiguration
        ↓
re-qualification / promotion

旧历史仍绑定 v1，不会因为今天发布 v2 而被重解释或改写。

扩大 Envelope 应该是一个显式治理事件

可以把变化写成：

Before:
S3 cases → ABSTAIN only

After:
C16 + policy v2
S3 cases → ALLOW_DEGRADED eligible

然后配：

qualification dataset
non-inferiority/guardrails
shadow observations
canary metrics
promotion record

这样以后能回答：

为什么 2026-08-23 以后这类 case 开始可以自动处理？

而不是只看到某个 prompt 被修改。

SafetyEnvelope 与 Behavioral Contract

SafetyEnvelope 本身可以直接形成 hard evaluators，例如：

critical_gap_count > 0
→ normal_auto forbidden

active_safety_review = true
→ ordinary candidate delivery forbidden

这些属于 Behavioral Contract 中最内层的 hard invariants。

模型 wording、candidate ranking 可以有波动；Safety boundary 不应该跟着随机波动。

SafetyEnvelope 与 Qualification 的关系

Qualification 不只是产生：

PASS/FAIL

更有价值的是产生：

what conditions are supported for AUTO?

也就是为 SafetyEnvelope 提供证据。

例如：

General slice      98% pass
Critical red flag  100% hard gate
Unknown risk       insufficient evidence

那么 envelope 可以明确：

General + known low/medium risk → eligible
Unknown risk → not eligible

这比一个全局“模型通过评测”更精确。

与 Evidence Admissibility 的关系

Gap 能否关闭，还依赖 evidence 是否可采纳。

例如：

critical gap G3
A2 retrieves E8
E8 violates approved source/version policy

那么：

E8 retrieved ✅
E8 admissible ❌
G3 unresolved
→ still outside normal SafetyEnvelope

所以“搜到东西”不能自动把 case 推回 envelope 内。

与 EvidenceBudget 的关系

同样：

budget exhausted

只说明不能继续按当前方式取证。

它不能推导：

risk low

如果 critical gap 仍 open：

outside envelope

仍然成立。

与 Human Review 的关系

Human review 可以作为 envelope 外的一条授权路径，但要明确：

outside AUTO envelope
≠
system unusable

可能是：

AUTO forbidden
→ human review required
→ human-authorized transition

所以 SafetyEnvelope 实际上是自动化资格边界，不一定是整个业务允许/禁止边界。

Treatment 中 Envelope 为什么更动态

Diagnosis 的 envelope 多聚焦：

是否允许自动交付分析

Treatment 还要考虑时间：

proposal generated inside envelope at T1

不代表：

acceptance at T2 still inside envelope

BodyState、安全状态、Diagnosis freshness 都可能改变。

所以 Treatment acceptance 必须重新计算 current eligibility，而不是继承 generation 时的 envelope verdict。

Consultation 中 Envelope 可以作用于 Runtime Control

例如：

normal semantic reply → AUTO eligible

new red flag → require escalation interaction

high-risk unresolved user fact → interrupt/ask_user

也就是说 envelope 不只控制“最终答案”，还可以控制 Agent 的运行模式与 HITL requirement。

Production Metrics 应按 Envelope Slice 观察

不要只看全局：

automation rate
success rate

更有价值：

AUTO rate by risk stratum
ABSTAIN rate by gap type
ESCALATE rate by safety slice
policy rejection by configuration
canary regression inside approved slices

否则总体指标很好，某个高风险 slice 可能已经退化。

SafetyEnvelope 失效的典型方式

1. Classification drift

case 被错误归入低风险。

2. Policy drift

规则变了但 configuration identity 没变。

3. Evidence drift

新 source/index 改变 gap resolution 行为。

4. Delivery bypass

Decision outside envelope，但 UI 从 raw proposal 展示结果。

5. Resume drift

长运行 Agent 中断后 resume 使用了另一 configuration。

这些都说明 envelope 是跨层 contract，不只是一个 Python bool。

测试 SafetyEnvelope 应覆盖什么

Known inside cases

all required facts/evidence satisfied
→ inside normal AUTO envelope

Each hard blocker

critical gap
red flag
active safety review
unknown policy
→ outside

Unknown classification

UNKNOWN must not silently map LOW

Confidence override attempt

confidence HIGH + hard blocker
→ still outside

Evidence inadmissibility

retrieved but inadmissible
→ gap remains unresolved

Configuration change

new behavior policy
→ old envelope qualification not automatically inherited

Temporal reauthorization

Treatment current state changes after proposal generation：

re-evaluate envelope

自测题

1. 为什么 SafetyEnvelope 更像多维区域而不是一个安全分数？
2. SafetyEnvelope 与 DecisionAuthority 分别回答什么？
3. 为什么 Foundation Model 更强不等于 AUTO 范围自动扩大？
4. Eval slice 如何变成 runtime envelope evidence？
5. UNKNOWN 为什么不能默认 LOW risk？
6. Confidence 可以在哪些地方作为 soft signal，不能做什么？
7. Evidence inadmissible 为什么会让 case 继续 outside envelope？
8. Budget exhausted 为什么不能推导 risk LOW？
9. Human Review 与 AUTO Envelope 是什么关系？
10. Treatment 为什么必须在 acceptance 时重新判断 envelope？

常见误解

• Safety Envelope = 内容审核规则：它更广，描述的是 configuration 允许自动工作的已验证运行域。
• 高平均分代表 envelope 很大：关键切片和 hard gates 才决定哪些区域真正被批准。
• Judge 同意就能越界：Judge 只能提供语义评估信号，不能绕过 hard safety policy。
• 模型升级后 envelope 自动扩大：必须有新的 qualification evidence。
• 出了 envelope 就一定 BLOCK：Envelope 只判断边界；具体 ABSTAIN / ESCALATE / BLOCK 由 DecisionAuthority 决定。
• inside envelope 就一定要 AUTO：它表示有资格，不表示产品必须自动化。
• SafetyEnvelope 是一个静态 if：它应能追溯到 configuration qualification 与版本化 policy evidence。