1. 为什么 LLM 应用接入阶段必须做 PII 前置脱敏很多团队在接入大模型时第一反应是“先把功能跑通”把用户输入原封不动地丢给模型。等业务跑起来才发现日志里躺着手机号、身份证号、银行卡号甚至用户的家庭住址。这时候再回头做治理成本会翻好几倍。PIIPersonally Identifiable Information个人可识别信息在 LLM 场景下的风险和传统后端不太一样。传统后端里敏感字段通常有明确的表结构加个字段级加密就能兜住。但 LLM 应用的输入是自由文本用户可能在任何位置、用任何格式塞进敏感信息。比如一段客服对话里用户会写“我的手机号是 138xxxx1234帮我查下订单”也可能写“联系我一三八xxxx一二三四”。如果你只在数据库层做防护这些内容在进入模型之前就已经泄露了。更麻烦的是调用审计。很多团队用一个大 Key 打通所有模型调用出了问题根本不知道是哪次请求、哪个用户、哪个业务线触发的。日志里只有 token 消耗和延迟没有可追溯的请求标识。一旦发生数据泄露事件你连“谁在什么时候把什么数据发给了哪个模型”都答不上来。所以接入阶段要做两件事前置脱敏和调用审计。前置脱敏是在请求离开你的服务之前把 PII 替换成占位符或假数据模型看到的是脱敏后的文本返回结果再由你的服务还原。调用审计是给每次请求打上可追溯的标签记录脱敏前后的字段变化、模型响应状态、耗时等形成完整的审计链路。这两件事如果分散在业务代码里做每个接入方都要重复实现一遍规则不统一、日志格式不一致后期维护会非常痛苦。更合理的做法是用统一的 Key/API 通道作为入口在通道层做脱敏和审计。这样业务方只需要把请求发到统一入口脱敏规则和审计策略由通道统一管理。TaoToken 在这里的角色就是提供这样一个统一 Key 通道。你可以把它理解为一个“模型调用的网关”所有业务线的 LLM 请求都走同一个 Base URL用统一的 Key 做认证通道层可以挂载脱敏中间件和审计日志。下面我会从实际配置出发一步步说明怎么落地。2. TaoToken 统一 Key 通道的前置准备与接入配置在开始写脱敏规则之前先把通道跑通。TaoToken 的接入方式和主流 OpenAI 兼容接口一致你不需要改业务代码的调用逻辑只需要把 Base URL 和 Key 换掉。2.1 获取 Key 与确认 Base URL首先到 TaoToken 控制台创建一个 API Key。建议按业务线或环境开发/测试/生产分别创建不要所有业务共用一个 Key。这样审计日志里可以通过 Key 的前缀区分来源后期做权限回收也方便。创建 Key 的入口在控制台的 API Keys 页面。创建时注意两点一是给 Key 起一个能识别业务的名字比如llm-pii-prod-order二是设置合理的额度上限避免某个业务异常调用把整体额度打满。Base URL 统一使用https://taotoken.net/api不要加任何路径后缀。很多 OpenAI SDK 会自动拼接/v1/chat/completions所以 Base URL 只写到/api即可。2.2 用环境变量管理 Key不要把 Key 硬编码在代码里。推荐用环境变量export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用 Python 的 openai SDK初始化方式如下import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 你好帮我写一段脱敏规则说明}], ) print(response.choices[0].message.content)这段代码跑通说明通道已经可用。接下来才是重点在请求进入模型之前插入脱敏逻辑。2.3 脱敏中间件的位置选择脱敏逻辑放在哪里决定了它的覆盖范围。有三种常见位置第一种是放在业务代码里每个调用点手动脱敏。这种方式最灵活但最容易漏。只要有一个新同学忘了加脱敏就会出问题。第二种是放在 SDK 封装层所有业务统一调用你封装的safe_chat()方法。这种方式比第一种好但如果有业务直接调原生 SDK就绕过了。第三种是放在网关层所有请求必须经过网关才能到达模型。这种方式覆盖最全但需要你有网关能力。TaoToken 的统一 Key 通道本身就是一个网关入口你可以在自己的服务里做一个“前置代理”所有请求先经过你的代理做脱敏再由代理转发到 TaoToken。我推荐第三种因为审计和脱敏都需要在同一个位置完成才能保证日志的完整性。下面给出一个可复制的脱敏配置片段。3. 可复制的脱敏规则配置与审计字段清单这一节给出具体的配置片段。你可以直接复制到项目里按自己的业务调整正则和替换策略。3.1 脱敏规则配置文件JSON 格式创建一个pii_rules.json放在项目配置目录下{ version: 1.0, rules: [ { name: phone_cn, description: 中国大陆手机号, pattern: 1[3-9]\\d{9}, replacement: [PHONE_{index}], enabled: true }, { name: id_card_cn, description: 中国大陆身份证号18位, pattern: [1-9]\\d{5}(19|20)\\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\\d|3[01])\\d{3}[0-9Xx], replacement: [IDCARD_{index}], enabled: true }, { name: bank_card, description: 银行卡号16-19位数字, pattern: \\b\\d{16,19}\\b, replacement: [BANKCARD_{index}], enabled: true }, { name: email, description: 电子邮箱, pattern: [a-zA-Z0-9._%-][a-zA-Z0-9.-]\\.[a-zA-Z]{2,}, replacement: [EMAIL_{index}], enabled: true }, { name: name_cn, description: 中文姓名2-4字需结合上下文默认关闭, pattern: (?:姓名|名字|联系人)[:是]?\\s*([\\u4e00-\\u9fa5]{2,4}), replacement: [NAME_{index}], enabled: false } ], audit: { log_fields: [ request_id, timestamp, api_key_prefix, model, pii_types_detected, pii_count, masked_content_hash, original_content_hash, response_status, latency_ms ], retention_days: 90, store_original: false } }几个关键点说明replacement里的{index}会在运行时替换成递增序号比如[PHONE_1]、[PHONE_2]。这样同一个请求里多个手机号可以区分还原时按序号对应。name_cn规则默认关闭因为中文姓名识别误报率高。如果你的业务场景明确需要可以打开但建议配合上下文关键词使用。audit.store_original设为false表示审计日志里不存原始内容只存哈希值。这是隐私保护的基本要求审计日志本身不能成为泄露源。3.2 脱敏中间件实现Python 示例下面是一个可运行的脱敏中间件读取上面的 JSON 配置对请求内容做替换并生成审计记录import json import re import hashlib import time import uuid from typing import Any class PIIMasker: def __init__(self, rules_path: str): with open(rules_path, r, encodingutf-8) as f: config json.load(f) self.rules [r for r in config[rules] if r.get(enabled)] self.audit_config config.get(audit, {}) def mask(self, text: str) - tuple[str, dict]: detected [] masked text for rule in self.rules: pattern re.compile(rule[pattern]) matches list(pattern.finditer(masked)) if not matches: continue for idx, match in enumerate(matches, start1): placeholder rule[replacement].replace({index}, str(idx)) masked masked.replace(match.group(0), placeholder, 1) detected.append({ type: rule[name], placeholder: placeholder, original_hash: hashlib.sha256( match.group(0).encode() ).hexdigest()[:16], }) audit { pii_types_detected: list({d[type] for d in detected}), pii_count: len(detected), masked_content_hash: hashlib.sha256(masked.encode()).hexdigest()[:16], original_content_hash: hashlib.sha256(text.encode()).hexdigest()[:16], } return masked, audit这个类可以嵌入到你的请求处理流程里。每次调用模型之前先对messages里的content做mask()拿到脱敏后的文本和审计信息。3.3 审计字段清单审计日志建议包含以下字段缺一不可字段名类型说明request_idstring每次请求唯一标识用 uuid4 生成timestampint请求发起时间戳毫秒api_key_prefixstringKey 的前 8 位用于区分业务线modelstring调用的模型名称pii_types_detectedlist检测到的 PII 类型列表pii_countint脱敏字段总数masked_content_hashstring脱敏后内容的哈希original_content_hashstring原始内容的哈希不存原文response_statusintHTTP 状态码或业务状态码latency_msint端到端耗时这些字段写入你的日志系统比如 ELK 或 Loki保留 90 天。如果发生安全事件你可以通过request_id关联到具体请求通过original_content_hash验证某段内容是否曾经被发送过而不需要存储原文。4. 验证脱敏生效与日志可追溯的完整请求配置写好了接下来要验证它真的生效。我设计了一个样例请求包含手机号、身份证号和邮箱然后检查脱敏后的内容和审计日志。4.1 构造测试请求masker PIIMasker(pii_rules.json) user_input ( 你好我是张三手机号 13812345678 身份证 110101199001011234 邮箱 zhangsanexample.com 帮我查一下最近的订单。 ) masked_text, audit_info masker.mask(user_input) print(脱敏后, masked_text) print(审计信息, json.dumps(audit_info, ensure_asciiFalse, indent2))运行结果应该是脱敏后 你好我是张三手机号 [PHONE_1]身份证 [IDCARD_1]邮箱 [EMAIL_1]帮我查一下最近的订单。 审计信息 { pii_types_detected: [phone_cn, id_card_cn, email], pii_count: 3, masked_content_hash: a1b2c3d4e5f6..., original_content_hash: f6e5d4c3b2a1... }注意“张三”没有被脱敏因为name_cn规则默认关闭。如果你需要脱敏姓名打开规则后需要额外处理上下文避免把“张三丰”这种正常词汇误伤。4.2 发送脱敏后的请求到 TaoTokenrequest_id str(uuid.uuid4()) start int(time.time() * 1000) response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: masked_text}], ) latency int(time.time() * 1000) - start audit_log { request_id: request_id, timestamp: start, api_key_prefix: os.environ[TAOTOKEN_API_KEY][:8], model: gpt-4o-mini, pii_types_detected: audit_info[pii_types_detected], pii_count: audit_info[pii_count], masked_content_hash: audit_info[masked_content_hash], original_content_hash: audit_info[original_content_hash], response_status: 200, latency_ms: latency, } print(json.dumps(audit_log, ensure_asciiFalse))4.3 检查模型返回与还原模型返回的内容里会包含[PHONE_1]这样的占位符。你需要在返回给用户之前做还原def unmask(text: str, mapping: dict) - str: for placeholder, original in mapping.items(): text text.replace(placeholder, original) return textmapping在脱敏时生成存在请求上下文里不要写入日志。还原后的内容返回给用户用户看到的是完整信息但模型全程只看到了脱敏后的文本。4.4 验证日志可追溯在日志系统里搜索request_id你应该能看到一条完整的审计记录。通过original_content_hash你可以确认这次请求的原始内容哈希值。如果后续有安全审计需求你可以让用户提供原始内容计算哈希后比对确认是否曾经发送过。这套流程跑通后你就有了一个可追溯的脱敏通道。每次请求都有唯一 ID脱敏字段类型和数量都有记录原始内容不落盘只存哈希。5. 常见报错与排查401、local proxy failed、reading choices、OAuth实际接入过程中你可能会遇到几类典型报错。下面按报错信息逐一排查。5.1 401 Unauthorized这是最常见的认证失败。先检查 Key 是否正确echo $TAOTOKEN_API_KEY确认输出以sk-开头且没有多余空格。如果 Key 正确检查 Base URL 是否写成了https://taotoken.net/api/v1。正确的写法是https://taotoken.net/apiSDK 会自动拼接/v1/chat/completions。多写一层/v1会导致路径变成/api/v1/v1/chat/completions服务端无法识别。还有一种情况是 Key 被禁用或额度耗尽。到控制台检查 Key 的状态和剩余额度。5.2 local proxy failed这个报错通常出现在你本地设置了 HTTP 代理但代理不可用。检查环境变量env | grep -i proxy如果有HTTP_PROXY或HTTPS_PROXY临时取消unset HTTP_PROXY HTTPS_PROXY然后重新运行请求。如果你确实需要代理才能访问外网确保代理地址和端口正确且代理服务正在运行。5.3 reading choices 相关报错类似Error reading choices或choices is empty的报错通常有两种原因。一是模型返回了非预期格式比如你调用的模型名称不存在。检查model参数是否拼写正确比如gpt-4o-mini不要写成gpt-4-mini。二是请求超时导致响应体不完整。可以适当增加超时时间client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], timeout60.0, )如果问题持续打印完整响应体排查print(response.model_dump_json(indent2))5.4 OAuth 相关报错如果你用的是某些需要 OAuth 的客户端工具可能会遇到OAuth token expired或invalid_grant。这类报错和 API Key 认证是两套体系。TaoToken 的 API 调用使用 Key 认证不需要 OAuth。如果你在客户端工具里配置了 OAuth检查是否误开了相关选项。对于 Claude Code 这类工具配置方式如下Base URL 填https://taotoken.net/apiKey 填你的 TaoToken API KeyModel ID 填你需要的模型名称比如claude-3-5-sonnet。三件套缺一不可只填 Key 不填 Base URL 会走默认端点导致认证失败。如果你用 Cline 或 CC Switch 这类工具同样需要确认三件套完整。Cline 的 MCP 配置里baseUrl和apiKey要同时存在。Codex 的auth.json里api_key和base_url要对应。6. 把脱敏与审计做成可持续的接入规范脱敏和审计不是一次性的配置而是需要持续维护的接入规范。我建议从三个层面固化下来。第一规则版本化。pii_rules.json纳入 Git 管理每次修改走代码评审。新增规则时同步补充测试用例确保不会误伤正常文本。比如银行卡号的正则\b\d{16,19}\b可能会匹配到订单号你需要根据业务数据调整边界条件。第二审计日志分级。不是所有请求都需要记录完整的 PII 类型。对于低敏感业务可以只记录pii_count不记录具体类型。对于高敏感业务记录完整字段。分级策略写在配置里按业务线加载不同配置。第三定期回放验证。每月抽一批审计日志用original_content_hash对应的原始内容从业务数据库里取重新跑一遍脱敏规则确认规则仍然有效。如果发现漏网之鱼及时补充规则。如果你还没有统一的 Key 通道可以先从 TaoToken 的 API Keys 页面创建一个专用 Key把脱敏中间件挂在自己的服务里所有请求经过中间件后再转发到https://taotoken.net/api。这样你不需要改动现有业务代码的调用逻辑只需要把 Base URL 和 Key 换掉脱敏和审计就在你的控制范围内了。对于需要长期跑编码 Agent 的场景可以考虑 Coding Plan把脱敏后的请求统一走通道审计日志里能看到每次 Agent 调用的模型和耗时。如果只是想先验证模型对话效果可以直接在模型对话页面测试脱敏后的文本确认模型能正确理解占位符语义。整套流程跑下来你得到的是一个可追溯、可审计、可还原的 LLM 接入通道。业务方只管发请求脱敏和审计在通道层自动完成。出问题时你能通过request_id快速定位而不是在一堆日志里大海捞针。