创作日期：2026年10月7日
第（三十八）篇，我们建立了 Verifiable AI Supply Chain，并要求一次生产 AI Decision 能够反向追踪到 Software、Model、Prompt、Tool、Knowledge、Data、Evaluation 与 Policy。
上线前的核心问题因此被压缩成：
Was this AI configuration
approved before deployment?也就是：这个真正运行的 AI Configuration，是否就是经过验证、评估和批准的那一套配置？
这是非常重要的一步。
但仍然没有解决另一个更加困难的问题。
Approved At T0
≠
Safe Forever一个 Agent 今天通过 Evaluation，并不意味着三个月后仍然适合拥有相同权限。
Prompt 没有改，环境可能变了；Model ID 没有改，Provider 后端行为可能变了；Corpus 没有改，知识可能已经过时；Tool 没有改，外部 API 行为可能变了。甚至所有技术组件都没有变化，用户开始用一种完全不同的方式使用它，也可能让原本合理的安全假设失效。
因此，第（三十九）篇真正要回答的问题变成：
Does current production evidence
still justify
the level of autonomy
we are granting it?这意味着 AI Governance 必须从 Pre-deployment Approval 进入：
Continuous Assurance
也就是：
Agent 的自治权限不能只由“过去通过过什么评估”决定，而应持续由“当前生产环境中还存在什么有效证据”决定。
一、为什么一次 Evaluation 永远不够
传统软件系统当然也需要生产监控。
但 AI Agent 有一个更加明显的问题：它的行为高度依赖运行上下文。
即使：
Software = Same
Model = Same
Prompt = Same
Tools = Same生产环境中的 User Input、Retrieved Context、External Data、Tool Responses、Attack Patterns、Business Rules、Search Ecosystem 与 Knowledge Freshness 仍然会持续变化。
Same Configuration
+
Different Environment
=
Potentially Different RiskNIST AI RMF 的 MEASURE 2.4 明确要求：AI 系统及其组件的功能和行为需要在 Production 中持续监测；NIST 同时指出，随着环境变化，AI 系统可能出现新的问题与风险，使系统不再满足最初设计时的假设与限制。
2026 年 3 月，NIST 关于已部署 AI 系统监测的研究进一步指出：预部署 Evaluation 大多发生在受控测试环境，而 Post-deployment Monitoring 的价值之一，就是发现由于模型非确定性、动态输入条件以及真实部署环境而出现的意外行为和后果。NIST 同时提醒，当前 AI Post-deployment Monitoring 的最佳实践、经过验证的方法和统一术语仍然相对分散和早期。
所以 Pre-deployment Evaluation 只能证明：在某些已定义条件下，这套系统曾经表现得足够好。
它不能自动证明：现在正在运行的系统，在现在的环境、现在的攻击模式、现在的数据和现在的业务条件下，仍然值得拥有同样的自治权限。
二、Continuous AI Evaluation 不是“每天重新跑一次 Benchmark”
Continuous Evaluation 不应该理解成：
Run Offline Eval
Every Day更完整的结构应该是：
Offline Evaluation
+
Production Observation
+
Online Evaluation
+
Incident Evidence
+
Human Feedback
+
Red Team Evidence
+
Business Outcome
+
Drift Detection共同回答：
Is the current system
still operating
inside its approved
behavioral envelope?因此，本项目把 Continuous AI Evaluation 定义为：
持续从真实生产执行中收集可验证证据，并使用预定义或动态选择的 Evaluation 对 AI 系统的行为、风险和任务有效性进行重新测量。
重点不是 Continuous = evaluate everything，而是：
Continuous
=
evidence is continuously refreshed三、Production Trace 应该成为 Online Evaluation 的基本证据单元
第（三十八）篇已经建立 AI Decision Receipt。现在这些 Receipt、Trace 和 Production Effect 开始进入 Evaluation。
一次完整 Trace 可能包含：
Original Intent
↓
Agent Configuration
↓
Model Calls
↓
Prompt Resolution
↓
Retrieval
↓
Tool Selection
↓
Tool Calls
↓
Authorization
↓
Production Effect
↓
User / System Outcome真正成熟的 Online Evaluation 不应该只评分 final answer，还需要在必要时评估 retrieval quality、tool trajectory、authorization behavior、routing decision、citation quality、policy compliance、latency、failure recovery 与 production effect。
MLflow 当前的生产 Trace Evaluation 已经支持从 Production Trace 中评估最终输出以及中间行为，包括 Tool Call Trajectory、Sub-agent Routing 与 Retrieved Documents 等信息；其 Automatic Evaluation 也能够对生产 Trace 或多轮对话持续执行采样评估，用于监测 Hallucination、PII 泄漏、相关性、用户挫败等问题。
但工具能评分，并不意味着治理已经完成。
因为还必须回答：
Which traces?
Which scorer?
Which judge?
Which threshold?
Which sampling policy?
Which risk tier?
What happens after failure?四、不是所有 Production Traffic 都需要用相同方式 Evaluation
如果一个 SEO Research Agent 每天处理大量任务，Evaluate 100% with expensive LLM judge 可能既没有必要，也不可持续。
更成熟的设计应该使用：
Risk-based Evaluation Sampling
Low Risk Read Tasks
→ Random Sampling
Medium Risk Draft Tasks
→ Higher Sampling
High Risk Publishing Tasks
→ 100% Policy Evaluation
Critical Production Mutation
→ Deterministic Gate
+ Human / Independent Review同时还可以增加 Anomaly-triggered Evaluation。
例如 Unusual tool sequence、New query pattern、Unknown corpus source、High token usage、Repeated retries、Unexpected write operation、Policy boundary request、Privilege escalation attempt 出现时，提高 Evaluation 强度。
所以 Evaluation Frequency 本身也应该成为 Risk Control，而不是一个固定参数。
五、Continuous Evaluation 需要 Baseline，否则“变化”没有参照物
要判断 Behavior Drifted，首先必须知道 Drifted From What。
因此每一个重要 Agent 都应该至少存在一个 Behavioral Baseline。
例如 SEO Publisher Agent：
Publication Accuracy
Citation Coverage
Unsupported Claim Rate
Tool Error Rate
Unauthorized Action Rate
Human Rejection Rate
Rollback Rate
Latency
Cost
Conversion Outcome上线前可以形成 Expected Baseline，上线以后继续形成 Observed Production Distribution。
Expected
↓
Observed
↓
Difference
↓
Significance
↓
Risk Interpretation这才是真正意义上的 Drift Detection。
六、Behavioral Drift 不能和传统 Model Drift 混为一谈
传统 Machine Learning 中，Drift 经常指 Data Drift、Concept Drift 或 Performance Drift。
但 Agent System 的 Drift 更复杂。
第（三十八）篇已经区分 Model Configuration Drift、Prompt Configuration Drift、Tool Configuration Drift 与 Corpus Drift。这些主要回答：Did the configuration change?
第（三十九）篇需要继续增加：
Behavioral Drift
它回答：
Did observed behavior change
even if configuration
appears unchanged?例如 Same Prompt、Same Model ID、Same Tools，但 Tool-call frequency ↑、Citation accuracy ↓、Unsafe refusal ↓、False positive escalation ↑、Human override ↑，这就是 Behavioral Drift。
七、一个 Agent 至少存在几种不同的 Behavioral Drift
Output Drift：内容质量、事实性、结构、语言或者答案类型变化。
Tool-use Drift：Agent 开始更频繁调用某些工具，或者出现过去没有的 Tool Sequence。
Retrieval Drift：相同类型 Query 开始检索不同来源、不同 Source Class 或不同 Document Cluster。
Authority Drift：Agent 更频繁接近权限边界。
Safety Drift：Prompt Injection 成功率、Policy Violation 或异常执行增加。
Business Drift：技术指标看起来正常，但最终业务效果开始下降。
这意味着：AI 系统“仍然能回答问题”并不等于它“仍然在按照我们批准的方式工作”。
八、Model Regression 与 Prompt Regression 应该独立测量
假设模型从 Model A 升级到 Model B，总平均 Benchmark 提升了，并不能证明 SEO Publisher 一定表现更好。
因为对一个具体 Agent 来说，我们真正关心的是 Task-specific Regression。
Fact Accuracy ↑
Reasoning ↑
But
Schema Compliance ↓
Tool Discipline ↓
Citation Precision ↓
Refusal Calibration ↓这仍然可能是一个不可接受的升级。
同样，Prompt v21 比 Prompt v20 整体评分高，但如果 Unauthorized Publish Rate 从 0 变成 0.2%，对于 Publishing Agent 来说，可能已经足以阻止 Release。
Average Quality Improvement
≠
No Critical Regression九、Regression Gate 应该按能力维度，而不是只看一个总分
一个错误设计是：
Overall Score:
92 → 94
PASS但这可能掩盖：
Safety:
99 → 92
Tool Discipline:
100 → 96
Citation Accuracy:
95 → 88对于不同 Agent，Score Importance 本来就不同。
SEO Research Agent 可能高度关注 Evidence Quality、Source Attribution、Factual Accuracy。
Publisher Agent 还必须增加 Authority Compliance、Mutation Safety、Rollback Readiness。
Technical SEO Agent 如果可以直接修改 robots.txt、canonical、redirect、sitemap，其错误成本显然也不同。
所以最终 Gate 应该更接近：
All Critical Dimensions
Within Approved Bounds而不是 Average Score Above Threshold。
十、Shadow Evaluation：新行为可以看生产流量，但先不要获得生产后果
第（三十八）篇已经提出 ALLOW_SHADOW。第（三十九）篇要把它进一步工程化。
Production Request
↓
Current Agent
↓
Real Effect同时复制一份输入给：
Candidate Agent
↓
Decision
↓
No Production Effect于是能够比较 Champion Decision vs Challenger Decision，而不会让 Candidate 直接修改生产环境。
对于 SEO Publisher，当前 Agent 可能决定 PUBLISH，Shadow Candidate 则可能建议 REQUIRE_REVIEW。这个差异本身就是重要证据。
相反，如果 Challenger 开始频繁建议 DELETE、REDIRECT、NOINDEX、PUBLISH，而 Champion 不会，我们就能在真正授予权限之前发现 Behavioral Expansion。
十一、Shadow 不等于完全真实的生产验证
Shadow 可以重放真实 Input，但它通常无法完全复制 Real User Reaction、Real External Side Effects、Real Feedback Loops 与 Real Tool Mutation Consequences。
Shadow Evidence
≠
Full Production Evidence它更适合作为 Pre-authority Production Evidence，也就是：让系统先接触真实世界，但暂时不给它改变真实世界的能力。
十二、Champion-Challenger 不应该只用于选“分数最高的模型”
传统 Champion-Challenger 很容易写成 Model A vs Model B。
但 Agent 的真正 Comparison Subject 应该是：
AI Configuration A
vs
AI Configuration B也就是同时比较 Model、Prompt、Tools、Corpus、Retrieval Policy 与 Runtime Config。
甚至也可以只挑战一个 Component，例如 Same Model、Same Tools、Same Corpus，只比较 Prompt 18 vs Prompt 19。
这能够帮助明确：Which change caused which regression?
十三、真正成熟的 Champion-Challenger 应该比较 Production Traces
Offline Benchmark 很重要，但线上系统最终面对的是真实 Query Distribution。
因此可以形成：
Production Trace Sample
↓
Replay
↓
Champion
+
Challenger
↓
Pairwise Evaluation
↓
Critical Regression Check
↓
Human Review Sample
↓
Promotion Decision这个过程比 New Model Benchmark looks better → Replace Old Model 更加可靠。
尤其对于 Agent 来说：模型不是产品。Model + Prompt + Tools + Context + Governance 才构成最终运行行为。
十四、Red Team 也不能只是上线前举行一次
NIST AI RMF 的生产监测指导中明确提出，可以持续跟踪安全测试和异常事件指标，并使用 Red Team Exercise 在对抗或压力条件下测试系统、识别 Failure Modes，并把 Red Team 结果用于 Continuous Improvement。
这意味着 Red Team 不应该只发生在 Before Launch，还应该发生在 After New Model、After Prompt Change、After Tool Addition、After Corpus Expansion、After Incident、After New Attack Technique，以及 Periodically In Production。
因为攻击者不会被冻结在系统上线当天。
2026 年 NIST 还进一步强调从一次性设置 Guardrail 转向 Continuous-Monitor-and-Update 安全模型的必要性。
Passed Red Team Once
≠
Currently Robust十五、Red Team 结果应该进入 Risk Engine，而不是只写成一份报告
例如测试发现 Prompt Injection Success = 3%。如果只是生成一份 Red Team Report.pdf，治理价值仍然有限。
它应该进入 Risk Evidence，进一步影响 Autonomy。
Injection Resistance ↓
↓
Risk ↑
↓
Publish Capability ↓
↓
Human Approval ↑这就是 Evidence → Risk → Authority，而不是 Evidence → Archive。
十六、这就进入 Safety Case 与 Assurance Case
当一个系统获得越来越大的自治权限时，Agent passed eval 已经不足以支撑治理决策。
真正需要回答的是：
我们为什么相信这个系统在当前条件下，可以安全地执行这类操作？
Systems Engineering 中已经长期存在 Assurance Case。
ISO/IEC/IEEE 15026-2:2022 当前规定了 Assurance Case 的结构术语，并明确适用于 Assurance Case 的开发和维护。其核心思想是将关于系统某项属性的 Claim，通过结构化 Argument 与 Evidence 连接起来，而 Safety、Security、Reliability 等都可以成为需要被论证的系统属性。
因此对于 AI Agent，我们可以借用这种思想。
不是写 Agent is safe，而是形成：
CLAIM
SEO Publisher Agent
may autonomously publish
low-risk informational articles.然后继续拆解：
ARGUMENT
Because:
configuration is approved,
critical evals pass,
production drift is within bounds,
tool behavior is controlled,
rollback is available,
incident rate is acceptable.最后连接：
EVIDENCE
Evaluation Attestation
Production Trace Metrics
Red Team Results
Human Review Sample
Tool Provenance
Incident History
Rollback Tests十七、Safety Case 不能成为一次性 PDF
如果 Assurance Case 在 2026-01-01 成立，并不能自动保证 2026-10-07 仍然成立。
因为 Evidence 可能已经 Expired、Invalidated、Superseded、Drifted 或 Contradicted。
因此 AI Agent 更需要：
Living Assurance Case
也就是让 Claim、Argument、Evidence 持续连接最新 Production Evidence。
例如：
Claim:
Agent may publish autonomously
Evidence:
Evaluation PASS
Production incident rate LOW
Prompt drift NONE
Tool drift NONE
Red team current
Rollback verified如果某个关键 Evidence 失效，例如 Red Team = STALE 或 Evaluation Coverage = GAP，那么 Assurance Case Confidence 应该下降，相应 Authority 也应该下降。
这里的 Living Assurance Case 是本项目基于 Assurance Case 方法进一步形成的 Runtime Governance 实现方式，并不是 ISO 已经规定的一种统一 AI Assurance Case 产品。
十八、于是 Evidence 本身也需要 Freshness
很多治理系统只有 PASS / FAIL，没有 WHEN，这是不够的。
例如 Security Red Team: PASS，但 Evaluated: 180 days ago。如果期间已经 Model Changed、Corpus Expanded、New Tool Added、Attack Pattern Evolved，这个 PASS 的证明力可能已经显著下降。
因此每一种 Evidence 都应该具有：
created_at
subject
scope
valid_until
invalidating_events例如 evaluation_attestation 可以定义为 valid until configuration changes；red_team_evidence 可以定义为 valid for 30 days or until security-relevant change；tool_validation 可以定义为 valid until definition hash changes。
于是 Evidence Validity 从静态字段变成动态状态。
十九、这会产生一个新概念：Assurance Debt
Technical Debt 是 System changed faster than engineering can properly maintain it。
而 AI Agent 还可能出现：
Assurance Debt
例如 Configuration changes → Evaluation does not catch up；Tool Surface expands → Red Team coverage stays old；Autonomy increases → Monitoring remains unchanged。
Operational Capability
>
Evidence Coverage这个差距就是 Assurance Debt。
它非常危险，因为系统看起来 working，但治理证据实际上已经落后于生产现实。
二十、下一步就是 Risk Recalibration
如果 Continuous Evaluation 只负责发现 Something changed，还不够。
必须继续回答：
Does this change
materially change risk?例如 Response latency +5% 可能不是自治权限问题，但 Unauthorized Tool Attempt 0 → 0.3% 对于高权限 Publisher Agent 来说可能是严重变化。
所以生产 Risk Engine 需要把 Evaluation Evidence、Drift、Incident、Red Team、Human Override、Business Impact 与 Exposure 重新组合成 Current Risk State。
二十一、Risk 不是系统的固定标签
错误：SEO Agent = Medium Risk。
更准确的是：
Risk
=
Context-dependent同一个 Agent，Read GSC Data 可能是低风险，Generate Draft 可能是中低风险，Publish Article 风险更高，Modify robots.txt 可能进一步提高，Delete thousands of URLs 则完全属于另一类 Risk Exposure。
所以 Agent Risk 必须至少考虑 Action、Resource、Blast Radius、Reversibility、Evidence Confidence、Current Behavior 与 Environment。
二十二、这就自然进入 Autonomy Budget
第（三十九）篇最重要的项目抽象之一是：
Autonomy Budget
它不是 Money Budget，也不是某项现有 AI 标准已经定义好的统一指标。
本项目把它定义为：
在当前风险、证据和环境条件下，一个 Agent 可以在不增加额外人工审批的情况下，被允许自主消耗多少生产权限和影响范围。
因此 Autonomy 不应该只有 ON / OFF，而应该是多维度的。
二十三、Autonomy Budget 可以控制什么？
例如同一个 SEO Agent，可以限制：
Task Count
Action Type
Resource Scope
Tool Privilege
Mutation Volume
Financial Cost
Blast Radius
Time Window
Tenant Scope
Rollback Difficulty于是 Autonomy Budget 实际上是在规定：系统在需要再次获得人工授权之前，最多能够自主改变多少现实状态。
二十四、例如 SEO Publisher Agent
状态良好时：
AUTONOMY:
Informational Article
≤ 5 posts/day
Approved Category Only
Approved Sources Only
No Page Deletion
No URL Change
No robots Modification如果最近发生 Citation Accuracy Drift，可以自动调整为：
Draft Only
+
Human Review Required如果检测 Unauthorized Tool Attempt，继续降低为 READ_ONLY。
如果发生 Unknown Model + Tool Catalog Drift，则直接进入 DENY。
二十五、所以 Autonomy 应该可以升，也应该可以自动降
很多 AI 产品只设计 Promotion，没有 Demotion，这是非常危险的。
成熟的系统需要：
READ_ONLY
↓
DRAFT
↓
HUMAN_APPROVED_WRITE
↓
LIMITED_AUTONOMY
↓
FULL_APPROVED_AUTONOMY也必须能够反向：
FULL_AUTONOMY
↓
LIMITED
↓
REQUIRE_APPROVAL
↓
SHADOW
↓
READ_ONLY
↓
DENY这才是真正的 Dynamic Authority。
二十六、Capability 不应该永久授予
第（三十八）篇已经提出 Capability + AI Configuration Hash。
第（三十九）篇进一步要求 Capability 还要绑定 Current Assurance State。
Capability Validity
=
Identity
∩
AI Configuration
∩
Intent
∩
Policy
∩
Evaluation Coverage
∩
Current Risk State
∩
Autonomy Budget也就是说，过去合法的 Capability，在新的风险状态下可能不再有效。
二十七、这就是 Capability Adjustment
例如 PUBLISH_POST 原本允许 autonomous。
发生 Behavioral Drift 之后可以自动变成 PUBLISH_POST requires approval，再进一步降为 CREATE_DRAFT only。
而不是必须等到 major incident 之后才人工关闭整个系统。
这让安全控制从 Emergency Kill Switch 升级成 Continuous Privilege Shaping。
二十八、真正的 Continuous Assurance 应该形成反馈环
Production Trace
↓
Online Evaluation
↓
Behavioral Drift Detection
↓
Regression Detection
↓
Risk Recalibration
↓
Assurance Case Update
↓
Autonomy Budget
↓
Capability Adjustment
↓
New Production Behavior
↓
New Production Trace这不是 Monitor → Dashboard，而是：
Monitor
→
Decide
→
Adjust Authority二十九、这才是 Monitoring 与 Governance 的区别
Monitoring 只能告诉你：Something is wrong。
Governance 必须能够回答：What authority should the system still retain?
例如 Hallucination Rate ↑ 可能意味着 Research Answer → Require Citation，而不是 Shutdown Everything。
但 Unauthorized Production Mutation 则可能意味着 Write Capability → Immediately Revoke。
所以真正成熟的系统不是 One Alert = One Response，而是：
Evidence
↓
Risk Classification
↓
Policy
↓
Proportional Control三十、这也意味着 Alert 本身要按 Authority Impact 分类
普通 Latency Drift 和 Privilege Boundary Violation 不应该拥有相同 Severity。
Agent Monitoring 应更关注：
Could this anomaly
change production authority
or production effect?于是 Monitoring Severity 可以进一步连接 Authority Risk，而不仅仅是 System Health。
三十一、Red Team、Champion-Challenger、Shadow 和 Online Eval 其实属于同一个体系
它们看起来是几套不同技术，但本质都是在回答：
What evidence
do we currently have
about system behavior?Offline Eval 提供 controlled evidence。
Shadow 提供 production-distribution evidence without effects。
Champion-Challenger 提供 comparative evidence。
Red Team 提供 adversarial evidence。
Online Evaluation 提供 live behavioral evidence。
Incident Monitoring 提供 failure evidence。
Human Review 提供 expert judgment evidence。
它们最终都应该汇入：
Assurance Evidence Plane
三十二、这比“做更多 Eval”重要得多
因为真正的问题从来不是 How many evaluations have we run? 而是：
Do we currently possess
enough relevant evidence
to justify this authority?10,000 个普通回答 Eval 不能自动证明 DELETE_PAGE 是安全的。
100 个 Summary Test 也不能证明 MODIFY_ROBOTS 应该自治执行。
Evidence 必须与 Claim 匹配。
三十三、NIST ARIA 也说明 Evaluation 正在从模型测试向真实使用推进
NIST 当前对 ARIA 项目的说明，把 Pilot Evaluation 分为三种测量层级：Model Testing、Red Teaming、Field Testing。
其中 Field Testing 关注 AI Application 在普通实际使用场景中的表现。
这提供了一个非常重要的方向：
Lab Evidence
≠
Field Evidence对 Agent 尤其如此。
三十四、截至 2026 年 10 月 7 日，NIST TEVV-Athlon 仍需要准确描述
NIST 于 2026 年 8 月 7 日发布 NIST AI 200-2 TEVV-Athlon Framework Initial Public Draft，并将公开征求意见期设定到 2026 年 10 月 6 日。
截至本文写作日 2026 年 10 月 7 日，这一征求意见期限已经结束，但 NIST 当前公开页面仍然将该文件标识为 Initial Public Draft；没有依据把它写成已经发布的 Final Standard。
Comment Period Closed
≠
Final Standard PublishedTEVV-Athlon 所强调的方向已经非常清楚：AI Evaluation 应围绕具体目标构建适合实际系统和应用环境的 Measurement，而不是假设存在一套对所有 AI System 都通用的单一 Benchmark。
三十五、前沿 AI 治理也越来越体现“风险变化 → 控制变化”
这并不是说不同公司的框架已经形成统一标准。
Google DeepMind 的 Frontier Safety Framework 采用 Capability Level 与风险评估机制，并要求在能力达到相应阈值之前准备适当 Mitigation。
Anthropic 当前 Responsible Scaling Policy 同样强调按风险比例调整 Safeguards，并持续重新测量能力与风险。
这些都不等于本文提出的 Autonomy Budget 已经成为统一行业标准，但它们共同说明了一件事：
更强的能力、更大的风险或新的证据状态，需要对应更强或不同的控制。
三十六、于是可以建立 Continuous Assurance State
一个 Agent 不应该只有 DEPLOYED 状态。
ASSURED
ASSURED_WITH_LIMITS
DEGRADED
RE_EVALUATION_REQUIRED
HUMAN_REVIEW_REQUIRED
SHADOW_ONLY
QUARANTINED
UNASSURED状态变化由 Evidence 驱动，而不是由 someone remembered to update the configuration 驱动。
三十七、可以进一步定义 Assurance State Machine
PRE_DEPLOYMENT
↓
EVALUATED
↓
LIMITED_RELEASE
↓
ASSURED
↓
CONTINUOUS_MONITORING如果一切正常，维持 ASSURED。
如果出现轻微 Drift，进入 ASSURED_WITH_LIMITS。
如果出现 Evaluation Coverage Gap，进入 RE_EVALUATION_REQUIRED。
如果出现高风险异常，进入 QUARANTINED。
如果证据重新满足要求，则 REVALIDATED → ASSURED。
这样 Assurance 才真正成为 Runtime State。
三十八、Continuous Assurance 最重要的指标不只是 Accuracy
Accuracy 很重要。
但一个自治 Agent 更重要的问题可能包括：
Unattributed Decision Rate
Unevaluated Configuration Rate
Critical Regression Rate
Unauthorized Tool Attempt Rate
Human Override Rate
Rollback Rate
Assurance Evidence Freshness
Drift Detection Delay
Autonomy Demotion Delay
Incident-to-Containment Time尤其值得关注：
Autonomy Without Evidence Rate
也就是 Autonomous Production Actions performed without current matching assurance evidence。
对于高风险 Agent，理想状态应该接近 0。
三十九、第二个关键指标：Stale Assurance Rate
定义为 Current Authority backed only by expired or stale evidence。
例如：
Agent:
FULL_AUTONOMY
Latest Red Team:
180 days old
Prompt:
changed 3 times
Tool Catalog:
changed twice如果权限仍然保持不变，这就是典型的 Stale Assurance。
四十、第三个指标：Mean Time to Autonomy Reduction
发生高风险异常以后，How long until authority is reduced?
如果 Incident detected: 09:00，Human notices: 15:00，Capability revoked: 17:00，那么系统暴露窗口就是 8 hours。
所以治理系统还需要关注：
MTAR：Mean Time to Autonomy Reduction
这是本项目定义的运行治理指标，不是现有统一标准指标。
但对于 Autonomous Agent 来说，它可能比普通 Alert Response Time 更直接反映：我们能多快阻止一个已经失去充分信任依据的 Agent 继续扩大影响。
四十一、Continuous Assurance 同样需要 Game Day
测试 Model behavior suddenly regresses。
Online Eval
↓
Regression Detected
↓
Risk ↑
↓
Autonomy ↓测试 Prompt Injection success rate rises。
Red Team / Online Detection
↓
Assurance Case weakened
↓
Write Capability requires approval测试 Evaluation evidence expires。
FULL_AUTONOMY
→
LIMITED_AUTONOMY而不是 Do Nothing Until Incident。
四十二、还要测试 Evaluation System 自己失效
这是容易被忘记的一层。
如果 Online Judge 失效，或者 Scorer silently changes，或者 Evaluation pipeline stops ingesting traces，那么 No Alarm 并不代表 Everything Is Safe，可能只是 Measurement Is Broken。
因此还需要：
Evaluation Observability
四十三、没有 Measurement Health，就没有可信 Continuous Assurance
至少应该知道：
Trace Coverage
Sampling Coverage
Judge Availability
Scorer Version
Evaluation Latency
Failed Evaluation Jobs
Unknown Result Rate
Missing Ground Truth Rate如果 Online Evaluation Coverage = 0，系统不应该继续显示 ASSURED，而应该进入 ASSURANCE_UNKNOWN。
这再次继承整个系列的原则：
Unknown
≠
Safe四十四、最终完整架构开始形成
PRODUCTION AGENT
│
▼
PRODUCTION TRACE
│
┌──────────────┼───────────────┐
│ │ │
▼ ▼ ▼
ONLINE EVAL MONITORING INCIDENTS
│ │ │
└──────────────┼───────────────┘
▼
BEHAVIORAL EVIDENCE
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
REGRESSION DRIFT RED TEAM
│ │ │
└─────────────┼─────────────┘
▼
RISK RECALIBRATION
│
▼
ASSURANCE CASE
│
▼
AUTONOMY BUDGET
│
▼
CAPABILITY ADJUSTMENT
│
┌───────────┼───────────┐
▼ ▼ ▼
ALLOW REQUIRE DENY
REVIEW
│
▼
NEXT PRODUCTION RUN
│
└───────────────┐
▼
NEW EVIDENCE这就是第（三十九）篇真正建立的：
Continuous Assurance Loop
四十五、最终 Authority Eligibility 再次升级
第（三十八）篇是：
Production Authority Eligibility
=
Verified Identity
∩
Approved Software
∩
Approved AI Configuration
∩
Valid Evaluation
∩
Valid Intent
∩
Valid Capability
∩
Current Policy现在必须继续增加 Current Production Evidence、Behavior Within Bounds 以及 Current Assurance State。
最终变成：
Production Authority Eligibility
=
Verified Identity
∩
Approved Software
∩
Approved AI Configuration
∩
Matching Evaluation
∩
Fresh Production Evidence
∩
Acceptable Behavioral State
∩
Acceptable Risk State
∩
Valid Intent
∩
Valid Capability
∩
Available Autonomy Budget
∩
Current Policy四十六、这就是 Evidence-conditioned Authority
权限不再是：
Agent X
may publish.而是：
Agent X
may publish
while
current evidence
continues to justify
that authority.前者是 Static Permission。
后者是：
Evidence-conditioned Authority
四十七、第（三十九）篇新的 Safety Invariants
第一条：
Approved Once
≠
Assured Forever第二条：
No Production Evidence
→
No Strong Production Assurance第三条：
Configuration Stable
≠
Behavior Stable第四条：
Average Eval Improved
≠
No Critical Regression第五条：
Shadow Success
≠
Full Production Safety第六条：
Passed Red Team Once
≠
Currently Robust第七条：
Expired Evidence
→
Reduced Assurance第八条：
Evaluation Coverage Gap
→
Authority Must Not Increase第九条：
Risk ↑
→
Autonomy must stay same or ↓除非存在新的充分证据支持另一结论。
第十条：
Unknown Evaluation State
≠
Safe State最后一条：
No Current Assurance Evidence
→
No Strong Claim
that Current Autonomy
is Justified结语：真正成熟的 Agent，不是“上线后还能正常运行”，而是“每天都还能证明自己值得拥有现在的权限”
传统软件上线以后，我们经常问：
Is it up?
Is it healthy?
Is latency normal?
Are errors increasing?这些问题仍然重要。
但 Autonomous Agent 还必须多问一句：
Should it still
be allowed
to do what
it is currently allowed to do?这就是整个治理逻辑发生变化的地方。
第（三十八）篇解决的是：
Was this configuration
evaluated and approved?第（三十九）篇继续解决：
Does current evidence
still justify
the current authority?于是 Deployment Approval 不再是信任终点，它只是 Continuous Assurance 的起点。
最终我们需要形成：
Production Trace
↓
Online Evaluation
↓
Behavioral Drift
↓
Regression Detection
↓
Red Team Evidence
↓
Risk Recalibration
↓
Living Assurance Case
↓
Autonomy Budget
↓
Capability Adjustment
↓
Production Trace不断循环。
因此，第（三十八）篇的：
Verify the entire behavioral configuration before trusting an AI decision.
到了第（三十九）篇还需要继续升级成：
Continuously verify that production evidence still justifies production authority.
进一步压缩：
Observe Continuously
↓
Evaluate Continuously
↓
Detect Drift
↓
Recalculate Risk
↓
Refresh Assurance
↓
Resize Autonomy
↓
Adjust Capability这才真正把：
Verifiable AI Supply Chain
推进成为：
Continuously Assured Autonomous Agent
第（四十）篇自然承接方向
到了这里，我们已经可以：
Verify Configuration
↓
Observe Production
↓
Evaluate Behavior
↓
Detect Drift
↓
Recalculate Risk
↓
Adjust Autonomy但还存在一个更危险的问题。
假设 Agent 已经发现 Current Risk > Allowed Risk，或者 Assurance Case = Broken。
此时系统究竟应该 Stop、Pause、Degrade、Isolate、Rollback、Fail Over、Escalate，还是 Recover？
更困难的是：多个 Agent、Tool、Workflow 和 Production Effect 已经同时运行时，怎样阻止风险继续传播？
所以第（四十）篇可以自然进入：
AI Runtime Containment / Circuit Breaker / Kill Switch / Graceful Degradation / Safe State / Quarantine / Rollback / Compensating Action / Incident Command / Blast Radius Containment / Autonomous Recovery
把：
We know
the Agent should
lose autonomy.进一步推进成：
How do we
safely contain,
stop and recover
a running autonomous system
before damage propagates?形成：
Risk Breach
↓
Containment Decision
↓
Circuit Breaker
↓
Capability Revocation
↓
Isolation
↓
Safe State
↓
Rollback / Compensation
↓
Forensics
↓
Revalidation
↓
Controlled Recovery也就是从：
Continuously Assured Autonomous Agent
继续进入：
Containable and Recoverable Autonomous System
官方依据与工程边界说明
NIST AI RMF：MEASURE 2.4 明确要求 AI System 及其 Component 在生产状态下进行功能与行为监测，并强调环境变化可能导致系统偏离最初假设。官方资料：NIST AI RMF Playbook – Measure
NIST Post-deployment Monitoring：NIST 2026 年关于已部署 AI 系统监测的研究明确指出，Pre-deployment Evaluation 与真实部署环境之间存在差距，Post-deployment Monitoring 对发现非确定性、动态输入和意外后果具有重要作用；同时当前方法仍处于持续发展阶段。官方资料：NIST – Challenges in Monitoring Deployed AI Systems
NIST TEVV-Athlon：NIST AI 200-2 Initial Public Draft 的征求意见期已于 2026 年 10 月 6 日结束；截至 2026 年 10 月 7 日，NIST 当前页面仍将其标识为 Initial Public Draft，不能称为最终正式标准。官方资料：NIST TEVV-Athlon Framework
NIST ARIA：NIST 当前公开资料将 ARIA Pilot 的 Evaluation 描述为 Model Testing、Red Teaming 与 Field Testing 三个测量层级，为“受控评估 + 对抗测试 + 实际使用测试”的组合提供了现实参考。官方资料：NIST Human-Centered AI / ARIA
MLflow Online Evaluation：当前 MLflow AI Platform 已提供基于 Production Trace 的 Evaluation、Automatic Evaluation 和 Production Monitoring，可以在真实 Trace 上持续运行 Scorer / Judge，并评估最终输出及 Tool、Retrieval 等中间行为。官方资料：MLflow – Evaluate Production Traces
Assurance Case：ISO/IEC/IEEE 15026-2:2022 是当前已发布的 Systems and Software Assurance — Assurance Case 标准，规定 Assurance Case 的结构术语，并适用于 Assurance Case 的开发和维护。本文借鉴 Claim → Argument → Evidence 思想构建 AI Runtime Assurance，但并不声称该标准已经定义本文的 Autonomy Budget、Online Evaluation 或 AI Continuous Assurance Loop。官方资料：ISO/IEC/IEEE 15026-2:2022
行业风险框架：Google DeepMind Frontier Safety Framework 与 Anthropic Responsible Scaling Policy 当前均体现了依据能力和风险变化调整 Evaluation、Safeguard 或 Governance 强度的思路，但它们是各组织自己的 Framework，不能被描述成统一行业标准。参考：Google DeepMind Frontier Safety；Anthropic Responsible Scaling Policy
本文提出的 Behavioral Baseline、Risk-based Evaluation Sampling、Behavioral Drift、Living Assurance Case、Assurance Debt、Autonomy Budget、Evidence-conditioned Authority、Continuous Assurance State、MTAR、Autonomy Without Evidence Rate、Stale Assurance Rate、Continuous Assurance Loop 等，均属于本 SEO / GEO 自动化项目基于上述标准、研究和工程实践进一步形成的治理抽象，不是 NIST、ISO、MLflow、Google DeepMind 或 Anthropic 联合定义的统一标准。