Copilot客户端遥测新增用户归属与可配置采集

GitHub 在 2026 年 10 月 12 日的 Changelog 公告中，为 GitHub Copilot 客户端遥测加入了“用户归属”和更细的采集控制。最值得注意的不是“遥测可以记录更多内容”，而是身份与内容终于被明确拆成两条配置线：企业管理员可以只关联活动来自哪个用户和主机，而不自动收集提示词、回答或工具内容。

官方公告：https://github.blog/changelog/2026-10-12-client-telemetry-user-attribution-and-configurable-capture/

这项更新的安全边界很清楚：telemetry.capture.identity 默认关闭，只负责身份归属；五类内容采集也全部默认关闭，是否开启应由具体审计目的决定。

先把“谁在使用”与“使用了什么”分开

企业做 Copilot 使用分析时，常见需求是把一次 Agent 活动归属到开发者和机器；这并不等于需要保存提示词、回答或命令。公告把这两类数据拆开，身份归属由 telemetry.capture.identity 控制，内容采集则由五类独立的 capture class 控制。

这意味着只打开身份捕获时，审计系统可以知道活动来自哪个账号、哪台本机账户和哪台主机，但不能据此推断已经收集了对话内容。相反，打开内容类配置也不应被理解为自动拥有身份归属能力。

身份遥测具体记录哪三个属性

telemetry.capture.identity 打开后，公告列出了三个新增的 OpenTelemetry 属性：

其中，身份捕获与既有的匿名化用户标识仍然是两套机制。公告还说明，细粒度控制已经覆盖 Copilot CLI、GitHub Copilot 应用，以及使用 Agent Host 的 VS Code 会话。不要把这三个字段理解成“完整用户画像”，它们只是把遥测活动关联到账号、系统账户和主机。

五类内容采集要按审计目标逐项判断

管理员还可以分别控制五类内容：prompts 包括用户、系统和开发者提示及支持的输入上下文；responses 包括助手回答和支持的推理内容；toolArguments 涉及原始工具参数、命令、工具模式及 MCP 服务、插件和 hooks 的标识；toolOutput 包括工具结果和执行错误详情；policyDetail 则可能包含沙箱文件系统路径等原始策略信息。

公告强调五类采集默认全部关闭。提示、工具和策略数据可能带出源代码、文件内容、命令、工具结果，以及工作区或用户配置文件路径。因此，生产环境更适合先写清“为了什么审计”，再只开需要的类别，并把数据发送到已批准的收集端点。

托管设置优先级决定最终行为

在配置落地时，最容易忽略的是优先级。公告指出，显式的托管值优先于本地设置、SDK 配置和环境变量。旧的 captureContent 仍可作为五类内容的遗留简写，但它永远不会启用身份捕获。

因此可以按下面的清单做上线前检查：第一，确认是否真的需要身份归属；第二，把五类内容逐项映射到审计目的；第三，检查是否可能出现代码、路径或命令；第四，确认收集端点已获批准；第五，核对托管设置是否覆盖了开发机上的本地偏好。这样既能利用遥测做运营分析，也不把“可观测”误当成“应当全部采集”。

常见问题

打开 telemetry.capture.identity 会收集提示词吗？

不会。它只负责身份归属；提示词属于独立的 prompts 内容采集类别，而且默认关闭。

captureContent 能替代身份捕获吗？

不能。它是五类内容采集的遗留简写，公告明确说明不会启用 identity。

三种身份字段是不是同一个用户名？

不是。user.name 是 GitHub 登录名，process.user.name 是本机操作系统账户，host.name 是本地主机名。

企业应该一次打开全部采集类别吗？

不建议按“全部打开”作为默认方案。应按审计目标最小化选择，并先确认代码、文件、命令和路径等数据是否允许发送。