Redacted介绍（脱敏 / 涂黑 / 删改后公开，指对外展示或记录信息时，把敏感内容隐藏或替换，只保留必要信息用于排查问题、审计或协作沟通）敏感信息、马赛克
文章目录
- 什么是 Redacted（脱敏/涂黑）
- 为什么要 Redacted
- Redacted 适用于哪些场景
- 典型需要脱敏的字段
- 常见的 Redacted 方式（从强到弱）
- Redacted 的关键原则（最佳实践）
- 一个直观例子
- 项目里的意义
什么是 Redacted（脱敏/涂黑）
Redacted通常译作“脱敏 / 涂黑 / 删改后公开”。它指的是：在对外展示或记录信息（日志、报表、截图、文档、对话记录、API 返回等）时，把敏感内容隐藏或替换，只保留必要信息用于排查问题、审计或协作沟通。
你最常见的体验是：合同/判决书里某些段落被黑条遮住；系统日志里 token 被打印成***REDACTED***。
为什么要 Redacted
- 合规与隐私：个人信息（手机号、邮箱、身份证）、账号凭据（密码、token、cookie）泄露会触发合规风险。
- 安全防护：凭据一旦进入日志/监控平台，很容易被“二次扩散”——更多人、更多系统都会看到。
- 降低事故半径：即使日志平台被误共享或被入侵，脱敏能显著减少可利用信息。
- 仍然可观测：脱敏不是“什么都不记录”，而是在安全范围内保留定位问题的线索。
Redacted 适用于哪些场景
- 应用日志：工具调用参数、HTTP headers、用户输入、模型 prompt、模型输出等。
- 监控与追踪：APM/Trace 的 tags、attributes、事件 payload。
- 错误上报：异常上下文、请求体、数据库查询参数。
- 对外材料：工单截图、共享给第三方的排障资料、公开报告。
典型需要脱敏的字段
- 认证信息：
password/secret/token/api_key/authorization/cookie - 会话标识：
session/session_id - 个人信息：手机号、邮箱、身份证号、地址、姓名（视业务而定）
- 业务敏感：订单号、设备序列号、内部链接、知识库原文、模型系统提示词（很多公司也当敏感）
常见的 Redacted 方式（从强到弱）
- 完全替换：
***REDACTED***（最安全，信息最少） - 部分保留：只保留前后几位，如
sk-...9f3a、138****1234 - 哈希化：保存
sha256(value)用于关联同一值，但不可逆（注意加盐） - 结构保留：保留类型/长度/是否为空等元信息，如
<str len=128> - 字段级策略：对不同字段用不同规则（token 全替换，手机号部分保留）
Redacted 的关键原则（最佳实践）
- 默认脱敏（default deny）：先假设所有输入都可能含敏感信息。
- 最小必要：日志只保留定位问题所需的最少信息。
- 一致性：统一规则，避免某个模块“漏网”。
- 防止日志爆炸：对长文本/大对象要截断；必要时只记录摘要（长度、hash）。
- 不要影响业务语义：脱敏应发生在“展示/记录层”，不要改变真正的业务入参和处理结果。
一个直观例子
未脱敏日志（风险很高）：
传入参数：{"user_id":"1001","token":"eyJhbGciOi...","phone":"13812341234"}脱敏后日志（仍可排障）：
传入参数：{"user_id":"1001","token":"***REDACTED***","phone":"***REDACTED***"}项目里的意义
对于智能体 + 工具调用链路，日志里经常会出现：
- 用户自然语言输入（可能含隐私）
- 工具参数（可能含设备信息、账号信息）
- prompt / retrieved context（可能是内部知识库内容）
- 模型输出（可能回显敏感字段）
所以在middleware里做 redacted 非常合适：它位于统一入口，最容易做到全局一致。