[!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. 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，而不是“部署时随便改的参数”。

11. 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

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

12. 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。

13. Shadow 与 Canary 的职责不同

Shadow

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

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

Canary

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

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

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

14. Sticky / Stable Assignment

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

可以使用稳定 bucketing：

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

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

15. 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，而不是只“换回旧模型”。

16. 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。

17. 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

18. 两条最终主链

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。