Skip to content

45-telemetry-and-reporting-rules-audit.md

Latest commit

 

History

History
180 lines (122 loc) · 7.44 KB

45-telemetry-and-reporting-rules-audit.md

File metadata and controls

180 lines (122 loc) · 7.44 KB

45. Telemetry、Analytics 与上报规则审计

所属专题簇：控制、扩展与灰度治理

建议前读：24. GrowthBook、Analytics 与 Feature Control

建议后读：32. Harness 与 Eval Runtime

研究问题

Claude Code 具体会上报什么、发给谁、按什么规则裁剪，哪些属于自动 telemetry，哪些又只是用户显式提交的反馈？

一句话结论

当前源码里的上报体系主要分成三类：自动 telemetry、实验/灰度属性上报、用户显式反馈。自动 telemetry 有明显的字段裁剪、事件白名单、provider 分流和 PII 隔离设计；我没有看到直接面向“封号处罚”的本地上报接口。

这篇讲什么

这一章不讨论“上不上报”这种抽象问题，而是具体列出源码里的 reporting rules：

  • 哪些事件会进 telemetry sink
  • 哪些字段会被保留、裁剪或重命名
  • 哪些事件只发给 first-party
  • GrowthBook 会带哪些用户属性
  • 哪些属于用户主动提交，而不是静默上报

如果你不看源码，只看这一章，应该记住什么

  • Claude Code 确实有完整的 telemetry 体系，但默认就在尽量避免把原始代码和路径直接送进通用 analytics。
  • 上报是分流的：Datadog、1P event logging、GrowthBook 的规则并不一样。
  • 3P provider 在上报层反而经常被少记，而不是多记。

源码依据

Mermaid 图：上报分流规则图

flowchart TD
    A["运行时事件"] --> B["analytics/index.ts"]
    B --> C["sink.ts"]
    C --> D["Datadog\n白名单事件 + firstParty only"]
    C --> E["1P event logging\n更完整元数据"]
    A --> F["GrowthBook\n实验与 targeting 属性"]
    G["用户主动反馈"] --> H["Feedback.tsx\n显式提交 bug report"]
Loading

第一层规则：analytics 入口默认不鼓励发送任意字符串

src/services/analytics/index.ts 有一条非常明确的设计约束：

  • logEvent() 的 metadata 默认只接受 boolean | number | undefined
  • 如果要传字符串，必须显式标注“已验证不是代码或文件路径”

这说明系统的默认倾向不是“原样把用户内容塞进埋点”，而是先做类型级约束。

第二层规则：Datadog 不是全量事件池

src/services/analytics/datadog.ts 里有两条硬规则：

  • 只记录 DATADOG_ALLOWED_EVENTS 白名单中的事件
  • 如果当前 provider 不是 firstParty，直接不发 Datadog

所以 Datadog 不是“什么都发”的总线，而是一个 first-party 场景下的有限事件后端。

第三层规则：1P event logging 比 Datadog 更完整

src/services/analytics/firstPartyEventLogger.ts 会为事件补充：

  • core_metadata
  • user_metadata
  • event_metadata
  • user_id

并把事件发到 1P event logging batch endpoint。

这意味着 Anthropic 自家后端看到的 telemetry 会比 Datadog 更丰富，但源码里仍然没有出现“命中某条件就处罚账号”的本地逻辑。

第四层规则：PII 用 _PROTO_* 和 strip 机制隔离

src/services/analytics/index.ts 与 src/services/analytics/sink.ts 有一套清晰规则：

  • _PROTO_* 字段允许进入 1P privileged 通道
  • 发往 Datadog 之前统一 stripProtoFields()

这说明系统刻意把“通用可见 telemetry”和“受限访问字段”分开，而不是无差别扔给所有上报后端。

第五层规则：工具名和工具输入会被裁剪

src/services/analytics/metadata.ts 里有几条非常具体的上报规则：

  • MCP 工具名默认被归一成 mcp_tool
  • 只有官方 registry、built-in MCP 或某些受控场景才会记录更细 server/tool 名
  • tool input 会被截断、限制深度、限制集合大小

这说明 telemetry 不只是“记没记”，还在做结构化降敏。

第六层规则：GrowthBook 会拿到 targeting 属性

src/services/analytics/growthbook.ts 里的 GrowthBookUserAttributes 明确包括：

  • id
  • sessionId
  • deviceID
  • platform
  • apiBaseUrlHost
  • organizationUUID
  • accountUUID
  • userType
  • subscriptionType
  • rateLimitTier
  • email
  • appVersion

这说明 GrowthBook 不只是 feature 开关读取器，它还是按用户与组织属性做 targeting 的实验控制面。

第七层规则：API telemetry 主要记录元数据，不是原始 prompt

src/services/api/logging.ts 里的 logAPIQuery() 和 logAPIError() 关注的是：

  • model
  • provider
  • messagesLength
  • betas
  • permissionMode
  • querySource
  • requestId / previousRequestId
  • base URL / env model 等环境元数据

我没有在这层看到“默认原样上报完整 prompt 文本”的直接实现。

第八层规则：用户主动 bug report 和自动 telemetry 是两回事

src/components/Feedback.tsx 说明：

  • 用户可以显式提交 feedback / bug report
  • 这是交互式、可见的提交行为
  • 不能把它和静默 telemetry 混为一谈

这一点很重要，因为“存在 bug report 功能”不等于“系统自动举报用户”。

哪些上报规则最容易被误读

  • GrowthBook 带组织和账户属性
    这说明它能做定向实验，不直接说明它在做处罚。

  • 1P event logging 元数据更丰富
    这说明 Anthropic 自家可观测性更强，不直接说明有封号接口。

  • Datadog 不记录 3P provider
    这恰恰更像“3P 少上报”，而不是“3P 被重点执法”。

文档判断

如果把源码里的 reporting rules 做审计式归类，可以归成这样：

  • 已证实：存在完整 telemetry 与 experiment 系统
  • 已证实：默认做类型限制、字段白名单、PII 分流和工具输入裁剪
  • 已证实：Datadog 对 3P provider 有少记策略
  • 未证实：存在直接把 telemetry 用作本地封号处罚的代码路径

你真正应该记住的点

  • Claude Code 会上报，但上报并不是“什么都裸传”。
  • 它的 telemetry 规则是分层的：Datadog、1P、GrowthBook 各有不同边界。
  • 目前能从源码确认的是“观测、实验、产品治理”，不能直接推出“客户端有封号上报接口”。

延伸阅读