Appearance
观测数据该留什么、删什么：Retention、Redaction 与 Audit
前置：多租户环境怎样保护 Secret 和 Workspace Trust
核心问题：Trace/Log 既要能审计故障又可能包含敏感信息，哪些字段应保留、脱敏或按时间删除？
Agent Trace 天然比普通服务日志更敏感
它可能同时包含：
text
用户原始问题
检索出的内部文档
Tool 参数与结果
Workspace 文件片段
模型输出
审批意见
错误栈如果默认“为了调试全部保存”，Observability 系统反而会变成最大的敏感数据副本。
先做 Data Classification，再谈 Retention
可以按数据类型分别定义：
| 类型 | 典型策略 |
|---|---|
| 运行指标、token、latency | 长期聚合，少含正文 |
| Trace metadata | 较长时间，字段化保存 |
| Prompt/Tool payload | 短期或按需采样/脱敏 |
| Credential/secret | 不应持久化到 Trace |
| Artifact | 按 workspace/project 生命周期 |
| Audit event | 更长保留，内容最小但完整性更强 |
关键是：Retention 不是整张表统一 N 天，而是按数据类别、tenant 和用途定义。
Redaction 最好发生在写入前
如果先把完整 secret 写到 tracing backend，再在 UI 隐藏，数据已经泄漏到存储、备份和导出链路。
优先：
text
raw execution data
→ structured allowlist / redaction
→ persistence/export而不是：
text
store everything
→ hope viewer hides it对于 Tool 参数，可以保存 field name、类型、hash、长度或 stable reference，而不是原文。
Trace 与 Audit Log 的目标不同
Trace：解释系统为什么慢、为什么走这条 trajectory、哪次 Model/Tool 调用失败。
Audit：回答谁以什么身份和授权，对哪个资源执行/批准/拒绝了什么高风险动作。
Audit event 至少需要：
text
actor / delegated identity
run_id / operation_id
resource / action
policy + approval version
timestamp
result / external reference
integrity metadataAudit 通常比 debug log 更严格地控制写入、修改、读取和保留期，但也不意味着要保存整个 Prompt 正文。
删除与可追责并不冲突
用户内容删除后，可以保留不包含敏感正文的最小安全证据，例如：某 operation 在某时间被某 principal 批准并成功，payload 只保留 hash/reference。这样仍能审计系统行为，而不是永久保存所有业务数据。
Failure Modes
Secret 先写 Trace 再做 UI Mask
处理： exporter 前 redaction/allowlist；secret 默认 deny。
Audit 与 Debug Log 共用同一可随意删除的管道
处理： 审计事件独立 schema、访问控制和完整性策略，并与 Trace 通过 operation/trace identity 关联。
如何验证
使用 canary secret 执行完整 Run，然后搜索 Trace、log、metric label、artifact metadata、exception、audit；除专门 secret store 外不得出现原值。再执行 retention/deletion 测试，确认 payload 被删除而最小 audit evidence 仍符合 policy。
自测
- Trace 对调试很有价值，但包含用户 secret。Retention 与 Redaction 应怎样同时满足可审计和最小数据暴露？
- 如果在采集后很久才做 redaction，原始敏感数据已经进入哪些系统？为什么应尽可能靠近采集边界处理？