现在日常写代码、排查线上 Bug 越来越依赖 AI，但经常会遇到不得不把内网 IP、线上数据库连接串、业务手机号/身份证、AK/SK 等信息带入上下文的场景，合规和隐私风险很大。

核心设计与工作流程

它本质是一个运行在本地的代理网关，完全不需要改动下游代码：

  1. 零侵入接入：只需把客户端的 API Base URL 指向本地端口（如 http://127.0.0.1:18710），上游中转和协议完全透明。
  2. 上行自动脱敏：请求经过本地网关时，正则与词库匹配敏感信息，替换为带业务语义的轻量占位符（如 {{IPPRIVATE_xxxx}}、{{PHONE_xxxx}}、{{CONNSTR_xxxx}}），原文绝不出网。
  3. 下行无感还原：模型回复经过本地网关时，自动对照映射表还原为真实明文；支持 SSE 流式实时还原，打字机吐字体验完全不受影响。

捕获模式

Agent 目标地址仍然是原始大模型 API 地址（比如 https://api.openai.com/v1），没有改任何代码配置。 捕获工具（mitmproxy 这类中间人）在本机网络层截获这个出站 HTTPS 请求：

  1. Agent 发起请求 → 本机网络栈被劫持，流量拐到捕获程序
  2. 捕获程序拿到完整请求体 → 执行脱敏（敏感信息替换占位符）
  3. 脱敏后的新请求再发给上游大模型
  4. 大模型返回结果，同样被捕获程序拦截 → 还原占位符 → 返回 Agent

关键点：

  • 不是大模型收到请求之后再截取；是本机出站前劫持
  • 难点：HTTPS 加密，中间人劫持必须安装根证书，否则拿不到请求明文，无法脱敏；SSE/HTTP2/QUIC 很容易击穿劫持，这就是作者说坑多的根源。

本地网关模式

base_url 是 LLM 客户端 / Agent 里配置的API 基础地址，OpenAI 风格 SDK 都会读取这个参数，用来拼接 /chat/completions 这类接口路径。 例如原生：https://api.openai.com/v1 改成网关后：http://127.0.0.1:18710/v1

完整数据流

  1. 修改 Agent 的 base_url，指向本机运行的代理网关（http://127.0.0.1:18710）
  2. Agent 发起 API 请求，直接发给本地网关进程（不再直接访问大模型官网）
  3. 网关收到请求 → 上行过滤、脱敏（敏感文字替换占位符）
  4. 网关自己作为客户端，把处理后的请求转发给上游真实大模型服务
  5. 上游返回响应 → 网关下行还原占位符，SSE 流式场景逐块还原
  6. 网关把还原后的内容返回给 Agent

一句话区分：

  • 捕获模式：Agent 目标不变，网络半路截胡流量
  • 代理网关模式：主动让 Agent 直接把请求发给网关程序（改 base_url），网关做转发，属于应用层正向代理，不是网络抓包劫持。

本地脱敏网关数据流

极简对比一句话

  1. 捕获模式：Agent 目标不变，网络中间偷偷抓包，在请求出去前改内容脱敏，不用改 Agent 配置；HTTPS 证书坑多不稳定。
  2. 代理网关：改 Agent 配置，让 Agent 直接找网关，网关接收请求，过滤脱敏后再代它去请求大模型，应用层转发，稳定，支持 SSE 流式。

本地网关的技术难度

主要难点集中在 5 个层面：

1. 流式还原（SSE）是最大难点

SSE 以数据块（chunk）形式持续推送，{{PHONE_xxxx}} 这类占位符可能被拆分到前后两个数据块中。直接逐块替换必然出现还原失败，必须做边界缓存、智能拼接判断，处理各种异常分片场景。

2. 脱敏准确率难以兼顾

  • 纯正则容易误判：把普通数字串识别为手机号、把代码标识符识别为敏感信息；
  • 也容易漏判：JSON 嵌套字段、函数调用参数、代码片段中的敏感数据，很难用通用规则全覆盖；
  • 平衡召回率和准确率是长期调优的点。

3. 多协议兼容成本高

需要兼容不同厂商的 LLM API 格式（OpenAI 风格、Anthropic 等），支持非流式、流式、函数调用等多种模式，还要适配各种语言的 SDK，做到 “改个 base_url 就能用”，不能要求下游改代码。

4. 并发与性能压力

  • 正则匹配和字符串替换有 CPU 开销，高并发下网关不能成为链路瓶颈；
  • 每个请求对应独立的「敏感信息 - 占位符映射表」，并发场景下要保证数据隔离，不能串请求。

5. 异常与状态管理

上游超时、连接中断、客户端重试时，映射表要正确清理或复用；还要处理请求取消、错误响应等边界场景，避免状态泄漏和逻辑混乱。

为什么要做数据脱敏

核心目的是在使用大模型能力的同时，保证敏感数据不出本地、不泄露，具体驱动因素：

  1. 合规要求：手机号、IP、身份证、数据库连接串等属于个人信息 / 企业敏感数据，受《个人信息保护法》等法规约束，违规向第三方传输会面临合规风险。
  2. 防止数据外泄：大模型服务商通常会留存请求日志，部分场景下还会用于模型训练；脱敏后原文绝不出网，即使上游发生数据泄露，泄露的也只是无意义的占位符。
  3. 保护业务机密：Agent 场景中请求常会携带内部系统地址、业务数据、代码片段、配置信息；脱敏后上游大模型只做语义推理，接触不到真实的内部敏感信息。
  4. 降低信任依赖：不需要信任大模型厂商的数据安全承诺，在本地网络出口就把风险拦截掉，属于典型的 “数据可用不可见” 落地方案。