Agent 的 Configuration Provenance 与 Execution Provenance

区分一次 Agent 决策中“批准的是哪套行为配置”和“这次运行实际用了哪些模型、证据、工具与策略版本”，为审计、回滚和 replay 提供双层溯源。

#type / synthesis #status / growing #tech / ai #tech / architecture #tech / ops #resource / agent

[!info] related notes

Agent 的 Configuration Provenance 与 Execution Provenance

范围

这篇笔记区分 Agent 决策中两种都必须保存、但回答不同问题的 provenance：Configuration Provenance 与 Execution Provenance。

最简记法：

Configuration Provenance
= should / intended / approved

Execution Provenance
= did / observed / actually happened

为什么“配置是什么”和“实际跑了什么”一定要拆开

普通应用里我们有时会假设：

配置写了 A
→ 运行时就是 A

但生产 Agent 中间还有很多动态层：

logical model
→ gateway routing
→ physical provider
→ retry/fallback
→ tool availability
→ knowledge snapshot
→ external observations

所以：

Approved Intent
≠
Observed Execution

如果不拆，事故后很容易出现：

“配置明明写的是模型 A，为什么结果像模型 B？”

答案可能是 gateway fallback，而不是配置被改了。

Configuration Provenance

Configuration provenance 回答：

这次决策名义上属于哪一个经过评测和批准的行为配置？

典型字段：

configuration_id / version
code revision
prompt version/hash
model policy / logical model
output schema version
tool policy
retrieval / evidence policy
safety / governance policy
decision policy version
behaviorally significant generation settings
approved eval evidence / qualification version

它建立的是“批准对象”的身份。

如果 Prompt、DecisionPolicy、EvidencePolicy 等行为字段发生变化，就不应该继续复用同一个 configuration identity。

Configuration Provenance 不是一堆“当前配置值”

真正的 provenance 要能回答历史问题。

错误：

analysis.configuration = "production"

因为 production pointer 以后会变化。

更好：

analysis.configuration_id = treat-config-f68e...

然后这个 ID 指向 repository-versioned immutable manifest。

所以：

Environment pointer
= mutable selection

Configuration identity
= immutable selected artifact

这跟 Git branch 与 commit SHA 的关系很像：

main
→ mutable pointer

commit SHA
→ immutable identity

Execution Provenance

Execution provenance 回答：

这一轮实际上发生时，到底用了什么、看到了什么、走了哪条运行路径？

典型字段：

physical model/deployment revision
provider / endpoint
gateway-reported model
runtime fallback/degradation
actual tool versions / attempts
actual evidence IDs / source versions
knowledge/index snapshot
pinned business-data revision
timestamps / environment identity
usage / latency
observed run/conversation identifiers

它建立的是“实际执行事实”的身份。

Execution Provenance 为什么不能由模型自己报告

例如让模型输出：

{
  "used_evidence": ["E31"],
  "model": "gpt-x"
}

这只是模型的陈述。

真正 provenance 应来自 runtime：

Gateway response metadata
Tool executor
Evidence acquisition runtime
Database/run envelope

原因很简单：

Runtime knows what happened
Model only sees/infers part of what happened

不能让被观察对象自己成为唯一审计来源。

为什么二者都需要

只保存 Configuration 不够

配置可能写：

logical_model = bodysense-diagnosis

但本轮实际：

provider A timeout
→ gateway fallback
→ provider B / model revision M2-r17

如果没有 Execution Provenance，历史只能知道“计划怎么跑”，不知道“实际上怎么跑”。

只保存 Execution 也不够

即使知道实际用了：

M2-r17
E17@v3
E21@v1

仍然回答不了：

  • 这个组合为什么有资格上线？
  • 它属于哪个批准 bundle？
  • rollback 应恢复哪个 configuration？
  • production 结果要和哪份 qualification evidence 对齐？

所以完整关系是：

Approved Configuration
        ↓ configuration provenance
Runtime Execution
        ↓ execution provenance
DecisionTrace / Result

Configuration Provenance 可以看作“控制面”，Execution Provenance 可以看作“数据面”

一个很有用的类比：

Control Plane
决定：应该怎样运行

Data Plane
体现：这次实际怎样运行

Agent Configuration 是控制面批准对象；Execution Provenance 是数据面观察。

这能帮助理解为什么：

  • LiteLLM 可以动态路由物理 provider；
  • BodySense 仍然保持 logical model 的业务稳定性；
  • 每次 run 仍要记录实际 provider/model revision。

Selected、Resolved、Observed 三层身份

生产系统甚至可以进一步拆：

Selected Configuration
= Go/Control Plane 选择的 config ID

Resolved Runtime Configuration
= Python 实际解析出的 manifest

Observed Execution
= Gateway/tools 实际发生的执行

一个重要 hard invariant 是：

selected config identity
== resolved config identity

否则配置控制链已经断裂。

然后 Execution Provenance 可以与 configuration 允许的范围比较：

observed logical route 是否匹配？
observed tool surface 是否越界？

同一个 BodyState + 同一个 Configuration 也可能产生不同 Analysis

这是 Execution Provenance 最有价值的地方之一。

假设：

BodyState = R53
Configuration = C15

Run A：

actual evidence = E17@v3, E21@v1
provider = A
Decision = ALLOW_NORMAL

Run B：

actual evidence = E17@v4, E25@v2
provider = B after fallback
Decision = ABSTAIN

两次 R53 + C15 完全相同，但实际 execution observations 不同，所以结果可以不同。

因此更精确的历史模型是：

DiagnosisAnalysis
=
Pinned Domain Input
×
Immutable Configuration
×
Observed Execution

例如：

D220 = R53 × C15 × Exec-A
D221 = R53 × C15 × Exec-B

不同不自动等于 Bug；还需要检查 Behavioral Contract 是否仍满足。

为什么 same R + same C 仍不应该期待逐字相同

除了 LLM 本身的语义波动，Execution 还可能包含：

retrieval result order changed
provider fallback happened
external tool returned newer state
network timeout changed tool path

所以真正稳定的应该是：

Hard Behavioral Contract

而不是：

whole response bytes

Execution Provenance 的作用之一，就是帮助解释“这次合理差异来自哪里”。

Mutable State 需要 Revision Identity

只要一个可变对象参与关键决策，就应尽量给它稳定 revision identity，例如：

  • BodyState revision；
  • knowledge document/source version；
  • index/corpus snapshot；
  • governance policy version；
  • prompt hash；
  • logical-to-physical model mapping version。

否则：

“同一个名字”

可能在不同日期代表不同内容，replay 和审计失去锚点。

为什么“model name”尤其不够

例如：

gpt-x

可能在不同时间对应：

  • provider A 的 deployment revision 1；
  • provider A 的 deployment revision 2；
  • provider B 的兼容中转；
  • gateway route 后的 fallback model。

所以重要场景至少区分：

logical model identity
physical provider
reported physical model/revision
fallback path

这也是使用 LiteLLM 之类 gateway 后必须保留 runtime metadata 的原因。

Production 与 Eval/Replay 对知识环境的要求不同

Production

生产系统可以允许动态知识环境，例如最新知识库持续更新，只要每次 run 记录：

actual evidence IDs
source versions
retrieval/index metadata

这让系统可以消费最新知识，同时仍保留历史 provenance。

Eval / Historical Replay

为了可比较和可复现，通常应该进一步 pin：

corpus revision
index snapshot
evidence source version

否则今天和下周跑同一个 benchmark，变化可能来自知识环境，而不是 configuration 本身。

[!important] 区分 生产允许“动态环境 + 精确 provenance”；严格实验与 replay 更倾向“冻结环境 + 精确 provenance”。

Dataset Provenance 也是 Qualification 的一部分

不仅 Agent Configuration 要有 identity，Eval dataset 也要有 fingerprint/version。

否则：

C15 pass rate = 95%

没有意义，因为你不知道是在哪一批 case 上。

更完整：

Configuration C15
Dataset DSet-7f1...
Evaluator Set E3
→ qualification result

这能保证 paired non-inferiority 比较是真正在同一个 frozen benchmark上发生。

Evidence Snapshot 为什么可能需要保存

仅有：

source_key = E17
source_version = v3

有时仍不足够。未来可能：

  • 原文被删除；
  • 第三方 API 下线；
  • index 重建；
  • 历史版本无法重新获取。

因此对于真正参与关键决策的 Evidence，可以保存必要的 relevant excerpt / snapshot，使 DecisionTrace 在未来仍有审计意义。

Provenance 与数据最小化之间要平衡

“为了 replay”不能无限复制所有内容。

可以按重要性分：

必须精确保留
→ identity、revision、decision-relevant excerpt

可引用外部 durable artifact
→ BodyState revision、config manifest

只需 observability
→ 大量低层 span/log

这样既能 replay/audit，也不会让 provenance 成为敏感数据 dump。

与 Model Gateway 的关系

Configuration 可以只绑定逻辑模型：

bodysense-diagnosis

而 LiteLLM/Gateway 负责：

provider
endpoint
physical model
retry
fallback

所以：

Configuration
→ 定义允许的 logical behavior

Execution Provenance
→ 记录这一轮实际落到了哪个 physical execution

这使业务配置不必硬编码每个 provider，同时仍能解释实际运行。

Infrastructure Fallback 为什么通常不应该改变 Business Configuration Identity

如果 configuration 定义：

logical model = bodysense-diagnosis

Gateway 从 provider A fallback 到 provider B，只要两者都在该 logical route 的批准基础设施策略内：

Configuration identity 可以不变
Execution Provenance 改变

但如果你改变的是：

logical route policy
required capabilities
reasoning mode

那通常是 configuration 行为变化。

这帮助区分：

Infrastructure execution variance
vs
Business behavior revision

与 DecisionTrace 的关系

Execution provenance 可以从 runtime trace 自动收集一部分，但最终应以稳定 schema 挂到 DecisionTrace 或业务审计记录上，而不是要求未来查询者解析供应商私有日志。

DecisionTrace 更关注：

为什么这样决定？

Execution Provenance 更关注：

这一次到底怎么执行？

二者互补。

一个具体分工例子

DecisionTrace
- decision = ABSTAIN
- reason = critical_gap_unresolved
- gap_id = G8

Configuration Provenance
- config = C12
- decision policy = v1
- evidence policy = v2

Execution Provenance
- provider B after fallback
- search attempt A7
- E21@v3 returned
- E21 rejected: source_version_not_approved

三者合起来才完整解释：

为什么这套批准配置在这次实际执行中最终 ABSTAIN

与 Replay 的关系

Historical Replay 要尽量恢复：

原 BodyState revision
原 Configuration
原 Evidence/source versions
原 policy revisions
原实际 tool observations

Counterfactual Replay 则有意识地替换 configuration，同时尽量固定 historical input。

如果 provenance 不完整，应明确标记 replay fidelity 不完整，而不是假装完全复现。

Replay Fidelity 应显式记录缺失变量

例如：

input snapshot: exact
configuration: exact
evidence E31: exact
evidence E42: missing historical snapshot
provider revision: unknown

那么 replay result 应标记：

fidelity = degraded
missing_dimensions = [E42, provider_revision]

否则用户会把一个“近似重放”误解成“历史复现”。

与 Failure Attribution 的关系

如果 selected config 是 C15，但 execution provenance 显示 Python resolve 了 C16：

Configuration Boundary Failure

如果 C15 正确，但 provider fallback 到 B 后性能退化：

Infrastructure Execution Failure

如果 evidence IDs 与 policy 都正确，但 DecisionAuthority 错：

Decision Failure

Provenance 让“模型表现变了”变成可以定位到具体层的工程问题。

Treatment 中的 Provenance

TreatmentRevision 应同时 pin：

source BodyState revision
source Diagnosis identity
Treatment configuration identity
execution provenance
Evidence acquisition trace

这样以后 Outcome 绑定 Intervention 时，可以知道：

这个 intervention 最初是在哪一套事实和 Agent 行为下产生的？

这对长期健康系统特别重要。

Consultation 中的 Provenance

Consultation 是 multi-turn runtime，所以还要区分：

conversation/thread identity
public run identity
selected consultation configuration
resume configuration identity
execution observations

尤其 interrupt/resume 后必须继续 pin 原本运行配置，而不能因为 production pointer 已变就偷偷换配置。

测试 Provenance 应覆盖什么

Configuration

same manifest → same fingerprint
behavior-significant change → new ID
unknown ID → reject

Selection vs Resolution

Go selected C15
Python resolved C15
→ pass

Go selected C15
Python reports C16
→ fail closed

Execution

fallback happened
→ provider/model/fallback metadata persisted

Evidence

actual evidence IDs / versions persisted

Replay

historical artifact missing
→ fidelity degraded, not silently replaced

No model self-report trust

model claims E99 used
runtime did not observe E99
→ E99 not accepted as execution provenance

自测题

  1. Configuration Provenance 和 Execution Provenance 分别回答什么？
  2. 为什么 production pointer 不能作为历史 config identity？
  3. 为什么模型自己输出 used_evidence 不能替代 runtime provenance？
  4. 同一个 BodyState + Configuration 为什么仍可能有不同 Analysis？
  5. logical model 与 physical model/proxy/provider 为什么要分层记录？
  6. Gateway infrastructure fallback 什么时候可以不改变 Configuration identity？
  7. Eval dataset 为什么也需要 fingerprint/version？
  8. Historical replay 的 provenance 不完整时应该怎么表达？
  9. DecisionTrace 和 Execution Provenance 分别承担什么职责？
  10. Consultation resume 为什么特别依赖 configuration provenance？

常见误解

  • 记录 model name 就够了：同名模型、provider、endpoint、revision、mapping 都可能变化。
  • 配置版本就是完整执行事实：runtime fallback、检索结果和外部状态会让同一配置的两次执行不同。
  • Execution Provenance 只是 debugging metadata：它也是 qualification 对齐、audit、rollback、incident attribution 与 replay 的基础。
  • 同 R + 同 C 必须同结果：还要看 actual execution observations。
  • 知识库更新后直接用最新版 replay 历史即可：那已经引入新的 counterfactual variable。
  • Production pointer 就是 configuration identity：pointer 会变；历史必须 pin immutable identity。
  • 越多 provenance 越好：应保留 decision-relevant facts，并遵守数据最小化。
创建于 2026/8/19 更新于 2026/8/23