[!info] related notes

• 所属 MOC: BodySense 项目 MOC、Agent Evals MOC
• 完整架构入口: BodySense Diagnosis Agent Architecture
• 前置概念: BodySense Diagnosis 的 PydanticAI 执行边界、Model Gateway、Agent 评估工程化
• 配置与资格: Agent 配置组合、Agent Model Capability Policy、Eval 非劣性门槛、Agent Configuration 的 Interaction Effect
• Evidence 与 Safety: Decision-Relevant Evidence Gap、Evidence Acquisition Policy、Agent Evidence Admissibility、Agent Safety Envelope、Agent DecisionAuthority
• 审计与复现: Agent DecisionTrace、Configuration / Execution Provenance、Replay Modes、Agent Behavioral Contract

BodySense Diagnosis 的模型治理与 Eval 生产闭环

这篇笔记现在承担什么角色

这篇笔记专注于一个问题：

一套 BodySense Diagnosis Agent Configuration，怎样证明自己有资格上线、怎样安全进入真实流量、以及生产证据怎样反过来推动下一版 Configuration？

完整 runtime / domain / authority 心智模型已经收口到 bodysense-diagnosis-agent-architecture；这里不再重复所有领域建模细节。

治理闭环可以压缩成：

Business Requirements
        ↓
Immutable AgentConfiguration
        ↓
Offline Qualification
        ↓
Non-Inferiority / Hard Gates
        ↓
Shadow
        ↓
Canary
        ↓
Promotion
        ↓
Production DecisionTrace / Telemetry
        ↓
Replay / Regression / Challenge Eval
        ↓
New Configuration

1. 资格单位不是“模型”，而是完整 Configuration

生产系统真正批准的不是：

“Model X 很强”

而是完整 behavior bundle：

AgentConfiguration
├─ logical model / model policy
├─ prompt revision
├─ output schema revision
├─ tool policy
├─ evidence policy
├─ reasoning/governance policy
├─ decision policy
└─ behaviorally significant generation settings

只要其中一个行为相关边界变化，就可能改变最终业务行为，因此通常要产生新的 configuration identity。

[!important] 原则 Component qualified ≠ Configuration qualified.

单独证明模型、Prompt、Tool 都“不错”，不能推出它们组合以后仍安全。

2. ModelRole → Logical Model → Physical Deployment

BodySense 业务层使用稳定业务角色和逻辑模型：

Business Role
Diagnosis
    ↓
Logical Model
bodysense-diagnosis
    ↓
LiteLLM Gateway
    ↓
Physical Provider / Model Revision

职责分离：

BodySense
→ 决定 role、qualification、policy、safety authority

PydanticAI
→ typed Agent execution / tools / structured output

LiteLLM
→ provider normalization / retry / fallback / load balancing

Provider 5xx 后切换 endpoint 是基础设施 fallback；它和业务上的 ABSTAIN / ESCALATE 不是一回事。

3. Capability Policy：REQUIRED / PREFERRED / OPTIONAL

模型进入候选集合前，可以按业务需求声明能力：

REQUIRED
→ 不满足就没有生产资格

PREFERRED
→ 有更好，但缺失不一定直接淘汰

OPTIONAL
→ 不影响最低资格

这些标签不是永恒真理，而是可被 Eval/Production evidence 修正的业务假设。

例如某能力原本被标为 PREFERRED，但生产数据发现某类 critical slice 在缺少它时显著退化，此时才能基于证据考虑升级为 REQUIRED，而不是因为“听起来更安全”就收紧所有模型。

4. Diagnosis Eval 的四类证据

Hard Gates

回答：

能不能进入 production candidate set？

例如：

• critical safety invariant；
• schema contract；
• forbidden side effects；
• configuration identity mismatch。

Reliability

回答：

• structured output 是否稳定？
• tool surface 是否符合配置？
• completion / error semantics 是否可靠？

Quality

回答：

• Candidate 是否合理？
• evidence 支持是否充分？
• explanation 是否准确表达不确定性？

Operational Metrics

回答：

• latency；
• token；
• monetary cost；
• provider reliability。

关键切片不能被 overall average 掩盖。

5. Dataset：Development / Calibration / Holdout / Regression / Challenge

成熟 Eval 不应把所有 case 放进一个会不断被 Prompt 调优看到的集合。

Development
→ 日常迭代

Calibration
→ Judge/rubric 校准

Holdout
→ 独立资格验证

Regression
→ 已知生产/历史失败

Challenge
→ 极端、边界、容易破坏 hard invariant 的 case

同时要按 user / episode / scenario family 做 grouped split，避免近重复 case 泄漏到不同集合。

6. Evaluator Ladder

推荐顺序：

Deterministic Rule
        ↓ 不足以表达
Structured Semantic Validator
        ↓ 仍不足
LLM-as-a-Judge

例如：

critical_gap_count > 0
→ ALLOW_NORMAL forbidden

完全不需要 Judge。

而：

Candidate reasoning 是否和 evidence 语义一致？

才适合 semantic evaluator / Judge。

Judge 是 quality signal，不是 DecisionAuthority。

7. Behavioral Contract 比“最终答案相同”更重要

一个 production Agent case 更适合定义：

Run Input
Expected Invariants
Forbidden Behaviors
Trace Expectations
Quality Rubric

而不是只写：

expected disease = X

因为可能出现：

最终 Candidate 猜对
BUT
用 external knowledge 伪造 user fact

这种 run 应该 FAIL。

详见 agent-behavioral-contract。

8. Non-Inferiority：新配置不一定要“更高分”

如果 Challenger 的目标是：

• 降成本；
• 降延迟；
• 提高 provider availability；

它不一定需要在所有 quality metric 上显著超过 Champion。

可以预先声明 non-inferiority margin：

critical slices 无回归
AND
overall quality 不低于 baseline - margin

关键点是：

• margin 必须预先定义；
• dataset fingerprint 必须一致；
• critical regression 一票否决；
• non-inferior ≠ automatically promoted。

9. Interaction Effect：一次改多个变量时不要乱归因

如果一次同时改变：

Model A → B
Prompt v7 → v8

然后 production rejection 上升，只能先说：

新 Configuration Bundle 出现回归。

不能直接宣布：

“Model B 一定有问题。”

需要时用 2×2 experiment：

A × v7
A × v8
B × v7
B × v8

区分：

• model main effect；
• prompt main effect；
• model × prompt interaction。

10. 对话学习形成的 Qualification 判断树

实际学习时，最容易混淆的不是某个 Eval 指标，而是：什么时候能替换、什么时候要暂停、什么时候能归因到某个模型/能力。 可以把整套判断压缩成下面这张树：

Candidate Configuration
        ↓
Capability Requirements
        │
        ├─ REQUIRED capability missing
        │      → INELIGIBLE
        │
        └─ capability gate passed
               ↓
        Hard Gates / Critical Slices
               │
               ├─ hard regression
               │      → REJECT
               │
               └─ passed
                      ↓
               Non-Inferiority
                      │
                      ├─ inferior beyond margin
                      │      → REJECT / REWORK
                      │
                      └─ non-inferior
                             ↓
                  Cost / latency / availability
                  可以作为替换偏好参与选择
                             ↓
                           Shadow
                             ↓
                           Canary
                             ↓
                  Production governance signals
                             │
              ┌──────────────┴──────────────┐
              ↓                             ↓
         stable / expected             rejection ↑ / anomaly
              ↓                             ↓
          Promotion                  PAUSE PROMOTION
                                           ↓
                                  Failure Attribution
                                           ↓
                            先缩小到最窄 configuration slice

这里有三个很重要的对话式判断。

non-inferior 不等于“无条件自动 Promote”

如果 Challenger 的主要价值是更便宜、更快或更稳定：

Hard Gates passed
+
critical slices no regression
+
quality non-inferior

说明它有资格进入下一阶段比较；此时成本、延迟、availability 才是合理的 soft preference。

但：

non-inferior
≠
automatically promoted

仍然需要 Shadow / Canary / production evidence。

Production rejection 上升时，先暂停 Promotion，不要马上改 Capability Policy

例如某个新 bundle 上线 Canary 后：

governance rejection ↑

第一结论应该是：

这个新 configuration 在真实分布上出现了回归信号

而不是立刻：

“reasoning 能力一定必须从 PREFERRED 升成 REQUIRED”

更稳的顺序：

pause promotion
→ slice by reason / case / config / provider
→ identify first contract drift
→ 再决定是 model、prompt、policy 还是 capability-class 问题

单个 Model 失败，不等于整个 capability class 都失败

如果：

reasoning = PREFERRED
Model B 表现差

但其他无 reasoning 模型并没有系统性退化，那么更合理的动作可能只是：

demote / reject Model B

而不是：

把所有无 reasoning 模型永久排除

只有跨模型、跨 Prompt、关键 slice 上都有稳定证据表明：

缺少该 capability
→ 系统性违反 hard/critical contract

才有充分理由把：

PREFERRED → REQUIRED

所以 Capability Policy 本身也是可被 Eval 证据修正的假设，不是先验真理。

一次改多个组件，只能先归因到 Bundle

Model A → B
Prompt v7 → v8

如果新 bundle 回归，第一结论只能是：

Configuration Bundle regression

如果 2×2 结果类似：

A×v7  normal
A×v8  normal
B×v7  normal
B×v8  bad

最强信号是：

Model B × Prompt v8 interaction

不能单独判：

Model B 一定坏
or
Prompt v8 一定坏

这张判断树把 Capability、Hard Gate、Non-Inferiority、Interaction Effect、Shadow/Canary 与 Production Feedback 放到同一条因果链里。

11. Evidence / Safety 也是 Configuration 行为的一部分

Agent qualification 不只测 Candidate quality，还要验证：

• user_information Gap 不被 generic RAG 非法关闭；
• EvidenceBudget 不被绕过；
• inadmissible Evidence 不能关闭 critical Gap；
• unresolved critical Gap 不能普通 AUTO；
• unknown policy state fail closed。

这说明 Evidence Policy、Decision Policy 也属于 configuration identity，而不是“部署时随便改的参数”。

12. SafetyEnvelope 不能由单次 Run 临场扩张

假设某 configuration 只在：

critical gap = CLOSED

的条件下被证明可以 normal AUTO。

生产中遇到：

critical gap = OPEN
confidence = 0.99

也不能让模型说：

“我这次很自信，所以破例。”

如果想扩大边界，应走：

production evidence
→ add challenge/regression cases
→ revise policy/config
→ qualification
→ shadow/canary
→ promotion

这才是安全边界的演化方式。

13. Historical / Counterfactual Replay 如何进入治理闭环

Production incident 可以被冻结为：

pinned BodyState
+ original configuration
+ evidence/source versions
+ DecisionTrace
+ execution provenance

Historical Replay

解释：

当时为什么这样决定？

Counterfactual Replay

比较：

同一历史 case 如果使用 Challenger C15 会怎样？

优秀的 production failure 不应该只变成一条日志，而应该变成 reviewed regression case。

14. Shadow 与 Canary 的职责不同

Shadow

真实 production distribution
+ candidate execution/comparison
+ 不改变正式业务结果

主要用于观察真实流量上的行为差异。

Canary

小比例真实 traffic
→ candidate configuration 真正服务

开始承担受控真实影响，因此必须有：

• stable assignment；
• predeclared stop conditions；
• rollback；
• durable rollout observations。

15. Sticky / Stable Assignment

同一个 subject / episode 在 rollout 中不应该随机地这次走 Champion、下次走 Challenger，从而制造体验和历史混乱。

可以使用稳定 bucketing：

subject identity
→ deterministic hash bucket
→ stable Champion/Canary assignment

这使 risk-slice 与 longitudinal comparison 更可靠。

16. Promotion 与 Rollback 是整个 Bundle 的生命周期

Promotion 单位应该是 configuration：

Champion C1
→ Shadow C2
→ Canary 5%
→ Canary 25%
→ Canary 50%
→ Promoted C2

如果出现：

• unsafe authority relaxation；
• forbidden side effect；
• configuration identity mismatch；
• hard regression；

应按预定义策略 pause / rollback。

Rollback 也应该恢复整个 approved bundle，而不是只“换回旧模型”。

17. Production Telemetry 必须回流 Eval

完整闭环：

Production signal
  ↓
DecisionTrace / Failure Attribution
  ↓
Narrow hypothesis
  ↓
Replay / Regression / Challenge cases
  ↓
Controlled Eval
  ↓
Evidence
  ↓
New Configuration / Policy
  ↓
Qualification
  ↓
Promotion

例如 governance rejection ↑，应先按：

• configuration；
• model/provider execution；
• BodyState slice；
• EvidenceGap pattern；
• governance reason；
• authority outcome；

定位最窄问题，再决定是换 model、修 Prompt、修改 evidence policy，还是扩展 SafetyEnvelope。

18. BodySense 当前实现状态（2026-08-20 完成的 Diagnosis Platform）

这部分是对旧笔记最重要的更新：Diagnosis 已经不是“仍在双轨迁移”的状态。

当前仓库已完成并归档 Diagnosis Agent Platform Phases 3–10，包括：

immutable AgentConfiguration + Go-owned deployment selection
Pydantic Evals qualification / slices / critical gates
paired non-inferiority
EvidenceGap / EvidenceBudget / EvidenceAttempt
Go DecisionAuthority / SafetyEnvelope
DecisionTrace + configuration/execution/evidence provenance
Historical + Counterfactual Replay
reviewed regression export
Shadow / stable Canary / Promotion / Rollback
repository-wide LiteLLM logical-model routing
legacy application-owned provider/router/fallback stack retired

因此旧的：

AIService → application ModelRouter → ProviderAdapter

现在只应作为历史演进理解，不再是 Diagnosis North-Star。

当前统一模型执行边界是：

BodySense business/config policy
        ↓
logical model group
        ↓
LiteLLM Gateway
        ↓
provider / retry / fallback

19. 两条最终主链

Configuration Qualification

Capability Requirements
        ↓
Immutable Configuration
        ↓
Hard Gates + Critical Slices
        ↓
Reliability / Quality
        ↓
Non-Inferiority
        ↓
Shadow
        ↓
Canary
        ↓
Promotion

Production Feedback

Production Run
        ↓
DecisionTrace + Provenance
        ↓
Failure Attribution / Replay
        ↓
Regression / Challenge Eval
        ↓
New Configuration
        ↓
Re-Qualification

总结

BodySense Diagnosis 的模型治理不是“挑最强模型”，而是建立：

一个以 immutable configuration 为资格单位、以 hard invariant 与关键 slice 为安全底线、以 Replay 与生产证据驱动回归集、通过 Shadow/Canary/Promotion 显式演化的 Agent release control plane。

运行时完整架构、Durable Domain 与 DecisionAuthority 的组合关系见 bodysense-diagnosis-agent-architecture。