文章通过中间人攻击分析了GitHub Copilot的工作原理，探讨了其上下文处理、内存使用和网络流量机制，揭示了AI编程助手在代码补全时的数据传输与隐私影响。

好的，作为一名专业的中文编辑，我已将您提供的英文文章内容进行重新陈述，保留了核心细节，并删减了与主题无关的冗余内容。以下是改写后的中文版本：

标题：GitHub Copilot 的工作原理：上下文、记忆与网络流量

本文作者通过将 VS Code 和 GitHub Copilot 置于中间人代理（MITM）之后，深入探究了其内部工作机制。作者发现，这些基于 Electron 框架构建的 AI 应用，其网络流量可以被有效拦截和分析。

核心发现：

1. 启动阶段的网络请求：在用户进行任何操作前，Copilot 已发起多类网络请求，包括：

   • 认证与会话：通过标准的 OAuth 流程获取并验证令牌。
   • 模型发现：向 /models 和 /agents/swe/models 端点发送请求，以获取当前账户可用的通用模型和专用于软件工程（SWE）的智能体模型列表。

2. 运行时行为：

   • 意图识别：用户发送提示后，Copilot 会先向 /models/session/intent 端点发送请求，对提示进行意图分类（如代码生成、调试、推理等），再据此选择合适的模型来执行任务。
   • 上下文注入：内联补全功能会将当前编辑的文件内容作为上下文发送。作者通过测试发现，即使 .env 文件本身被禁用补全，在编辑其他文件（如 pyproject.toml）时，.env 文件中的内容（包括假秘密）也可能因“最近编辑文件”功能而被包含在发送给 Copilot API 的 HTTP 请求中。该功能默认会包含最多20个文件、8个编辑摘要和每处更改周围的3行上下文。

3. 本地会话存储与记忆：

   • Copilot 使用一个名为 session-store.db 的本地 SQLite 数据库来存储会话摘要、工作过的仓库和分支，以及所有用户的提示和对应的 LLM 响应。
   • 通过一个名为 session_store_sql 的工具，模型可以查询这个本地数据库。作者发现，模型在首次查询时并不知道数据库结构，会先尝试失败，然后通过内省元数据来获取表定义，最终成功检索信息。
   • 数据库中的 user_message 和 assistant_response 字段以明文形式存储，且代码中没有任何清洗、脱敏或过滤步骤。这意味着用户发送给 Copilot 的任何敏感信息（如 API 密钥、密码）都会以明文形式持久化在本地。

结论与思考：

• AI 编码工具正演变为有状态系统：它们越来越多地整合用户工作区、近期编辑、对话、工具、历史记录和模型路由。每个新的上下文来源都提升了工具的实用性，但也带来了上下文膨胀、数据机密性和隐私方面的挑战。
• 上下文正成为产品核心：模型和基准测试结果固然重要，但 AI 编码工具的真正差异化优势，正转向如何有效地组装正确的上下文。这带来了两个挑战：一是工程问题，即如何保持上下文的精炼和相关性；二是隐私与保密性问题，即需要谨慎定义哪些数据可以跨越文件、会话、机器乃至模型 API 的边界。
• 逆向工程的价值：对于构建 AI 应用的开发者而言，逆向工程并研究模型周围的“脚手架”（harness），可能比单纯研究模型本身能学到更多。

根据评论内容，总结如下：

主要观点与论据：

1. 技术实现与安全风险（高认可度）：作者通过mitmproxy拦截Copilot网络流量，发现其会从非当前编辑文件（包括.env）拉取上下文，且缺乏对敏感文件的保护规则。评论2（bartek_gdn）强调"应在沙箱中运行，避免环境变量泄露"；评论3（tolugenius）表示"震惊于缺乏.env文件规则"。

2. 开源与闭源争议（中等认可度）：评论4（ameliaquining）指出Codex客户端是开源的（提供GitHub链接），但未获其他用户直接回应。

3. 安全与创新的平衡（中等认可度）：评论5（mathieu_aithos）认为"大公司在安全与创新间妥协可以理解"，但暗示存在治理漏洞。

4. 替代技术方案（低认可度）：评论6（p1llus）推荐使用eBPF绕过证书固定和mTLS直接获取明文数据，但未获广泛讨论。

5. 功能缺陷（低认可度）：评论7（Supermancho）批评Copilot在Java编程中的表现，并指出其"任务完成后才写入记忆"导致中间探索过程丢失。

平衡性说明： 多数评论聚焦技术实现细节与安全风险，对Copilot的批评集中在安全漏洞和功能缺陷，但缺乏正面评价。评论8（nottorp）对"用户喜爱的Electron应用"提出质疑，但未获直接回应。