打开我们官网的实战案例页，你会发现一件同行不太做的事：每个案例都不是视频，而是完整的 AI 会话回放，旁边还有一个 .zsession 文件可以下载导入。从第一句提问到最后一份报告，模型如何推理、调用了哪些工具、哪一步出错、如何恢复——全程未删减，10 个案例，无一例外。
这样做的团队并不多，原因也不难理解：AI 会话是最诚实的日志，也是最容易泄密的日志。 其中包含执行过的命令、工具返回的原始输出、环境变量的回显、内网的拓扑、客户的名称——任何一项外泄，都可能造成一次真实的安全事件。所以行业的常态是：演示视频经过剪辑，截图经过处理，会话本体不见天日。
我们做出了相反的选择。支撑这个选择的不是勇气，而是一道在内容离开本机之前工作的数据脱敏引擎。本文说明三件事：它如何工作、我们在哪里犯过错，以及一个容易被忽视的事实——好的脱敏，并不是遮得越多越好。
一、「原样」的是过程，遮住的是隐私
先把标题里的「原样」定义清楚：原样的是工作过程，遮掉的是敏感字段。 回放中的每一次推理、每一次工具调用、每一次失败重试，都是真实发生的原貌；而授权序列号、密钥、令牌这类信息，在导出的那一刻已被替换。
这一点可以直接验证。打开智甲 EPP 自动巡检案例的会话回放，定位到巡检报告部分，可以看到这样一行：
授权序列号：
****，过期时间：2026-06-24（剩余 1 天）
报告末尾，AI 自己写下了一句：「敏感信息已脱敏：授权序列号已替换为 ****。」——脱敏动作本身，也保留在记录里。这正是我们想要的状态：遮掩是显式的、可见的、可审计的，而不是悄悄删除内容。
二、脱敏的基础能力
它在产品中的位置是 设置 → 数据脱敏，定位是一个外发场景的数据保护引擎：只在内容离开本机之前介入——导出 HTML 回放、导出 .zsession、AI 落盘 .md 文档，三个场景各有独立开关。日常对话与本地分析，不做任何处理。
规则层提供四种类型：
- keyword——字面串全替换，朴素而可靠；
- regex——RE2 正则，替换模板支持捕获组，可以实现「留头遮尾」式的部分遮掩；
- ipv4_mask——结构化的 IPv4 遮掩，可指定遮掩第几段（任意段，含中间段），而非整体遮掩；
- domain_mask——域名遮掩，保留末尾几级标签（默认只留 TLD），其余替换为掩码字符。
规则之上还有一组内置 secrets 预设，覆盖高置信度、低误报的常见凭据格式：AWS Access Key、GitHub PAT、Slack Token、Stripe Live Key、GCP API Key、OpenAI Key，以及整块跨行的 PEM 私钥。这些格式特征明确（AKIA…、ghp_…、sk_live_…），误报率低，启用成本很小——即使把一把真实的 AWS 密钥误粘贴进会话，导出时它也已被替换。
两个设计决策值得说明：
命中必留痕。 每次触发脱敏的导出，都会给出一条提示：命中了多少条、命中了哪几条规则（按规则 Label 列出）。这份文件的每一处改动都有据可查——脱敏系统本身不能是黑箱：否则既无法确认它遮全了，也无法确认它没有遮错。
状态始终明确。 总开关关闭时，所有场景一律放行原文。这个设计看似保守，实则必要——半开半闭的脱敏才是真正危险的状态：使用者以为已遮掩，实际没有。我们宁可让使用者明确知道「当前没有脱敏」，也不制造「开启之后不知道哪里少了内容」的错觉。基于同样的理由，write_md 落盘脱敏默认关闭：它会改变写入内容，需要使用者明确启用。
值得补充的是，「凭据不出门」的原则贯穿产品各处：MCP 配置的读类工具（mcp.describe_server、mcp.export_config）返回的 authToken 一律只显示尾 4 位，环境变量值整体遮掩——无论是否导出，凭据在对话流中已经处于遮掩态。
三、两次缺陷，两次修复
脱敏机制很难一次做对。我们的发布日志里记录着两次真实的缺陷修复：
第一次：代码块行首的 IP 未被遮掩。 会话导出的是 JSON 结构，代码块内容带着转义。旧实现对转义前的文本套用规则，代码块中行首位置的 IP 因此未被匹配。修复方式是改为对解码后的 JSON 文本值套用规则——先还原为最终呈现的文本，再决定遮什么。
第二次：嵌套 JSON 的深层字段被遗漏。 工具调用的参数和结果中常常嵌套着另一层 JSON，旧实现只扫描顶层文本值，深层字段成为盲区。修复方式是递归下钻嵌套的 JSON 结构，将工具调用的参数与结果全部纳入覆盖。
两个缺陷指向同一个教训：脱敏引擎的对手不是「敏感字符串」，而是数据的形态。转义、嵌套、编码——每一层形态变换，都可能成为敏感信息躲过遮掩的通道。这两条修复都原样写进了发布日志与参考手册——缺陷并不可怕，不留记录的修复才可怕。
四、脱敏不是越多越好
最后说那个容易被忽视的事实。仔细检查我们公开的会话，会发现其中保留着不少内网 IP——这不是遗漏，是判断。三个真实例子，全部可以在官网验证：
IRC 僵尸网络流量分析的会话里，受害主机 192.168.7.133、内网 DNS 192.168.7.2 原样保留。因为它们是样本 pcap 中的流量——受害主机与 C2 的通联关系正是这个案例的证据链本身。将其遮掩，研判过程无法复现，会话回放也就失去了公开的意义。样本中的 IOC 是研判对象，不是隐私。
EDR 行为告警链分析的会话里有一串 10.0.19041.4522，形似内网 IP，实际是 Windows 的版本号。一条不加区分的 IPv4 正则会将它误处理为 10.0.*.*，告警分析中的系统版本信息随之丢失。这正是 ipv4_mask 设计为「可指定遮掩哪一段」的原因——机制要精确，判断要留给专业的人。
智甲 EPP 巡检的会话里，授权序列号被遮掩为 ****，而巡检目标的 SSH 连接地址 192.168.80.152 保留——前者是凭据，泄露有真实代价；后者是演示环境中的巡检对象，遮掩它，读者将难以理解巡检在对谁进行。
三个例子指向同一个结论：什么必须遮、什么必须留，是领域判断，不是正则能替你做的决定。 遮多了毁证据，遮少了漏凭据——脱敏引擎提供的是精确执行判断的机制，而判断本身，来自对安全工作的理解。这也是我们始终坚持的观点：安全场景的工具，更适合由安全团队来构建。
五、闭源产品也需要透明
作为直接面向对抗的安全智能体，我们选择不公开检测内核，而以「可验证的发布」承担透明的义务（见《为什么选择闭源》）。会话公开是同一个答案的另一半——
我们不公开源码，但公开行为。 AI 如何分析一个样本、如何在只读分析区保持克制、如何出错又如何自愈，全过程原样可查、可下载、可导入复现。源码透明证明的是「代码长什么样」，行为透明证明的是「它实际做了什么」——对一个要进入你工作台的智能体，后者往往更接近使用者真正关心的问题。
而这份行为透明能够成立的前提，脱敏能力是基础之一：因为出口处守得住，过程才敢全部公开。 你的会话本地保存，导出时同一套规则为你工作——我们敢挂在官网上的，你也可以放心发给同事、交给甲方、写进复盘报告。
透明与保密并不必然对立。分得清什么该公开、什么该守住，两件事就能同时成立。
我们在 AVL Code 中等你，骑着驴，全程可回放、可脱敏。
AVL Code，AVL 安全引擎，与智能随行。安天澜砥团队出品。