GitHub Copilot 内部架构：上下文注入与会话存储分析

通过中间人 (MitM) 代理对 GitHub Copilot 的网络流量进行分析，并结合 VS Code 源代码，研究发现该工具正在演变成一个有状态的系统。它通过结合用户工作区数据、最近的编辑记录、对话历史以及本地 SQLite 数据库来为 LLM 组装上下文。

模型路由与发现

GitHub Copilot 使用多阶段流程来确定哪个模型应该处理特定的用户请求。该过程始于引导阶段，在此阶段，扩展程序通过 OAuth 进行身份验证并发现可用模型。

模型发现

Copilot 会发送两个不同的请求来识别可用功能：

向 /models 发送请求以获取可用模型的通用列表。
向 /agents/swe/models 发送请求以识别专门适用于代理式软件工程 (SWE) 能力的模型。

基于意图的路由

当用户在 "Auto" 模式下发送消息时，Copilot 并不会立即调用生成式模型。相反，它会将提示词发送到 /models/session/intent 端点。系统会根据各种意图（例如 code-gen、debugging、reasoning 和 tool-use）对提示词进行评分，并使用此分类将请求路由到最适合该任务的模型。

上下文注入与隐私风险

Copilot 提供相关建议的能力取决于它注入到提示词中的上下文。然而，这种机制可能会在无意中泄露用户当前未编辑的文件中的敏感数据。

"最近编辑" 泄露

Copilot 为上下文实现了一个滑动窗口，其中包含多达 20 个文件、8 个编辑摘要以及每个更改周围的 3 行上下文。由于该窗口会跟踪工作区内的最近编辑，因此存储在 .env 文件中的密钥可能会在由完全无关的文件（例如 pyproject.toml 文件）中的按键触发的提示词中被包含进去。

缺乏默认的密钥过滤

对 VS Code 源代码的分析确认，在上下文的写入路径中不存在默认的脱敏、掩码或密钥过滤步骤。虽然 Business 和 Enterprise 计划提供了“仓库策略”来限制某些文件，但个人计划没有将 .env 文件视为特殊的默认规则，也没有与 .gitignore 集成以防止敏感文件被发送到 API。

本地状态与 Chronicle 工具

GitHub Copilot 维护本地状态以提供跨会话的长期记忆，这是通过一个名为 Chronicle 的工具实现的。

session-store.db

Copilot 利用名为 session-store.db 的本地 SQLite 数据库来存储会话摘要、仓库、分支以及用户提示词和助手响应的完整历史记录。

明文存储与工具访问

session-store.db 中的 user_message 和 assistant_response 列是以明文形式存储的。LLM 可以通过一个名为 session_store_sql 的工具访问此历史记录，该工具允许模型运行 SQL 查询来查询本地数据库，以回答有关之前工作的问题（例如，“我这周做了什么？”）。

对 sessionStore.ts 的源代码分析确认，turn.user_message 是按原样插入数据库的，没有任何掩码或脱敏处理。

技术实现分析

为了揭示这些行为，研究人员使用 mitmproxy 来拦截 Electron 基础的 VS Code 应用程序与 GitHub 服务器之间的 HTTPS 流量。

拦截设置

由于 VS Code 是基于 Electron (Chromium + Node.js) 构建的，可以通过配置以下设置来路由流量，从而通过代理进行拦截：

Http Proxy: http://localhost:8080
Http Proxy Strict SSL: 取消勾选（以允许 mitmproxy CA 证书）。
Http: Proxy Support: 设置为 override 以强制扩展程序使用代理支持。

其他观察方法

社区讨论建议了其他观察 Copilot 内部机制的方法：

eBPF: 使用 eBPF 可以直接从线路上捕获原始明文数据（在加密前或解密后），从而绕过对证书固定或 mTLS 的对抗。
Agent Debug Logs: VS Code 包含一个内置功能，可通过 Copilot 对话菜单中的 "show agent debug logs" 选项访问，该功能会显示工具调用、提示词以及模型选择逻辑。

结论：上下文即产品

AI 编码工具之间的差异化正在从底层模型的原始能力转向“护栏 (harness)”的复杂程度——即组装正确上下文的系统。主要的工程挑战在于如何在上下文密度（保持提示词精简且利于缓存）与严格的隐私边界之间取得平衡，以确保敏感的开发者状态不会跨越到模型 API 或明文本地存储中。