原文把 agent 可见性拆成四个维度。这四个 pillar 覆盖了安全、运维、产品三个角色的需求，不需要在每个事件里塞原始内容。

**1. 工具交互（Tool Interactions）

记录 agent 调了哪个工具、为什么调、结果如何。关键字段包括工具名称、参数类型、调用延迟、重试次数、响应状态、错误分类。

长期看，这些数据能揭示工具选择模式的漂移。如果一个 agent 突然开始频繁调用高风险连接器、或者反复调用导出接口，那往往是 prompt 滥用或策略漏洞的最早信号。这比等出了事再查更有价值。

**2. 推理过程（Reasoning Processes）

推理过程日志记录的是决策上下文，不是原始思维链。原文的观点很明确：你知道哪个策略门被评估了、哪些约束激活了、哪个分支被选中就够了，不需要记录推理过程中产生的每一个 token。目的是可解释性，不是全量采集。

**3. 质量指标（Quality Indicators）

质量指标衡量系统是否在安全地做有用的事。典型指标包括任务完成率、回退频率、幻觉代理指标（hallucination proxy metrics，用模型自我矛盾频率等间接信号推测是否产生了幻觉）、人工修正率、评估流水线的响应相关性分数（用自动化评测系统判断输出是否准确回答了问题）。

安全和质量在这里是关联的。质量信号下降往往先于不安全行为，因为困惑的 agent 更容易过度调用工具、误处理指令、或在响应中暴露无关上下文。

**4. 用户交互（User Interactions）

用户交互日志记录请求和响应的元数据，但内容本身要严格控制。有用的字段：用户角色、会话标识、意图标签、响应类别、策略执行结果。原始提示和响应应该抽样采集，采集到的必须做脱敏处理，保留期要短。

大多数场景下，元数据已经足够回答运维问题，同时大幅降低隐私泄露风险。

原文还给出了一个 OTel trace 事件示例，展示了实践中的样子：

{
  "trace_id": "4bf92f3577b34da6",
  "service.name": "support-agent",
  "gen_ai.tool.name": "document_retriever",
  "gen_ai.tool.call.status": "success",
  "gen_ai.policy.decision": "allowed",
  "gen_ai.safety.filter": "pii_detected",
  "gen_ai.safety.action": "masked",
  "document.classification": "internal",
  "latency_ms": 340,
  "user.role": "support_tier_1"
}

注意文档内容、用户提示、检索文本都没有出现在事件中。 gen_ai.safety.filter: pii_detected 记录发现了什么， gen_ai.safety.action: masked 记录做了什么处理。这些信息已经足够重建事件经过和证明合规。