1. 把 Zero Data Retention 的承诺边界先钉死
去年底帮一个做企业内部助手的团队过合规评审，会议室里那位负责安全的同事只问了一句话："你说数据不落盘，那你告诉我，这条用户提问从发出到拿到答案，中间一共被存在了几个地方？"在场的三个工程师当场卡住——有人只知道调了接口，有人以为开了企业版就自动"零留存"，还有人压根没想过工具调用那一跳会把整段对话再复制一份出去。这次之后我养成了一个习惯：凡是聊Zero Data Retention（ZDR），先不急着讲怎么开，而是先把"它到底承诺了什么、又不承诺什么"画清楚。因为绝大多数所谓的"留存事故"，根本不是协议没生效，而是你脑内的数据流和真实的数据流对不上。
这篇东西面向的是正在把模型能力往生产系统里塞的人——不管是刚接手Responses API调用的后端同学，还是正在接MCP工具链的平台工程师，或者是在设计多轮AI Agent的架构负责人。我不会给你一份"开启 ZDR 三步走"的操作手册，那种东西看官方条款就行；我要拆的是三个具体层面的留存边界：API 请求层、工具调用层、Agent 编排层。这三层里，第一层是你能控制的开关，第二层有一半不在你手里，第三层最容易在你自己写的代码里破功。理解了这个分层，你才能回答"数据存在哪几个地方"这种问题，而不是背一句"我们用了零留存"就完事。
提醒：ZDR 属于需要单独申请与审批的企业级安排，具体覆盖范围、例外项、元数据保留口径以你签署的条款和官方最新文档为准。本文讨论的是工程视角下的数据流理解与配置思路，不构成任何合规承诺。
1.1 ZDR 与"默认留存"差的不是一点点
先把三档常见的账户形态摆在一起，这是我每次做内部培训都会画的一张表，因为它能一次性消掉大部分误解。默认情况下，标准 API 调用会产生滥用监控相关的日志，响应对象在服务端保留一段时间用于排查和政策审核；Responses API 更直接，它默认会把响应对象存下来，方便你后续用 ID 去取。中间还有一档通常称为"改进版滥用监控"的过渡形态，把保留窗口压缩到很短的周期。最右边才是 ZDR：请求与响应在推理完成后不做持久化保存用于训练或后续检索。
| 维度 | 默认标准形态 | 短周期监控形态 | ZDR 形态 |
|---|---|---|---|
| 响应对象可回查 | 是，保留数天到数十天 | 是，窗口明显缩短 | 否，需自行保存 |
| 是否用于模型改进 | 视账户设置而定 | 通常不用于训练 | 明确不用于训练 |
previous_response_id | 可用 | 可用 | 通常不可用 |
| 异步长任务模式 | 可用 | 可用 | 多数不可用 |
| 滥用监控日志 | 保留 | 短周期保留 | 不保留或仅极少量元数据 |
| 申请门槛 | 无 | 无 | 需企业级审批 |
看清这张表你会发现一个反直觉的点：ZDR 不是"更安全的默认值"，而是"用工程复杂度换留存收缩"的一笔交易。你换到的是"服务端不给你留东西"，付出的是"所有状态管理你自己扛"。很多人只看到前半句就冲了，上线两周才发现多轮对话、异步任务、上下文缓存全部要重写，这时候再回头已经很被动。
1.2 三个最常见的理解偏差
第一个偏差是把 ZDR 理解成"数据不传输"。这显然不成立——推理必须在服务端完成，输入必然要传出去。ZDR 管的是"传完之后留不留"，不是"传不传"。所以传输链路上的加密、网关审计、出口白名单这些工作，跟 ZDR 是两套独立的事情，不能因为开了 ZDR 就把传输侧的控制放松。
第二个偏差是把 ZDR 理解成"模型不会记住"。模型权重不会因为一次推理而改变，这是常识；但"不留存"和"不进入上下文"是两件事。你在一次会话里贴进去的客户名单，在那一轮推理中就是上下文的一部分，它不会因为 ZDR 就变成"模型看不见"。真正需要控制的是"哪些内容根本不该进上下文"，这属于数据最小化，跟留存策略是两个维度。
第三个偏差最隐蔽：以为 ZDR 覆盖了所有下游。它覆盖的是模型服务商那一侧，不覆盖你自己接的 MCP 服务端、你自己的向量库、你自己的可观测平台。我见过一个团队把模型侧配置得干干净净，结果工具服务端把完整请求体写进了访问日志，保留周期还是默认的 90 天。合规评审的时候，这一条比模型侧的问题严重得多。
2. Responses API 里的 store 开关，是你能握住的第一根杠杆
Responses API 的设计思路跟早期的对话接口不太一样：它把"一次响应"当成一个有身份的对象，你可以拿着 ID 回头查、可以串联成会话、可以让它在后台慢慢跑。这套设计在体验上很舒服，代价就是默认会存。所以在 ZDR 语境下，这个接口是你第一个要动手改的地方，也是最容易被忽略的地方——因为它的默认值对开发者太友好了，友好到你不会去翻那一页参数说明。
2.1store参数到底改变了什么
store这个布尔参数控制的不是"这次请求发不发出去"，而是"这次生成的响应对象要不要在服务端持久化"。设成false，响应照样返回给你，但你不能再拿它的 ID 回来查，也不能用它做后续轮次的锚点。很多人第一次看到这个参数会以为它只是省点存储费，实际上它是留存策略的总闸。
{ "model": "your-model", "store": false, "input": [ { "role": "user", "content": "帮我把这份合同里的付款条款摘出来" } ] }注意一个坑：这个参数不是全局配置，是逐请求的。你的代码库里可能有十几个地方在调接口，封装层如果没有统一注入，早晚会漏掉一处。我的做法是在 SDK 外面包一层薄封装，把store的默认值设成false，需要显式开启的地方必须传参覆盖，并且加上代码注释说明为什么这里要开。这比在每个调用点手写一遍可靠得多，也比事后 grep 检查靠谱——因为 grep 会漏掉动态拼装的请求体。
还有一个细节值得说：开启store: false之后，返回体里某些字段会缺失或者为空，比如一些引用类的元信息。如果你的前端代码里有对这些字段的非空判断，上线后大概率会崩。这不是 bug，是设计使然，提前在测试环境跑一遍空值路径能省掉一次线上事故。
2.2previous_response_id与状态外置的取舍
previous_response_id是 Responses API 多轮对话的核心机制，你把上一轮的 ID 传进去，服务端自动把历史拼上。体验极好，代码极短，但它天然依赖服务端有存储。在 ZDR 下这条路基本走不通，你必须自己维护历史。
具体怎么做？最直接的是本地维护一个消息数组，每轮把完整历史重新发过去。代价是 token 消耗随轮次线性增长，长会话成本会明显抬头。更聪明的做法是做窗口化加摘要：保留最近 N 轮原文，更早的轮次压缩成一段结构化摘要。摘要这步本身也有讲究——摘要里不要出现原始敏感字段，只保留业务语义，比如把"客户张三，身份证号 XXX，欠款 12 万"压成"某客户存在逾期账款，金额量级十万级"。
# 状态外置的极简示意：历史自己管，不依赖服务端 def build_payload(history, user_input, max_turns=6): recent = history[-max_turns:] messages = [] for turn in recent: messages.append({"role": "user", "content": turn["q"]}) messages.append({"role": "assistant", "content": turn["a"]}) messages.append({"role": "user", "content": user_input}) return {"model": "your-model", "store": False, "input": messages}这段代码没什么技术含量，但它揭示了一个转变：你要从"调用一个接口"变成"自己实现一个会话服务"。会话存哪里、存多久、怎么过期、怎么在多实例之间共享，全变成你的活。如果你们是多副本部署，还得考虑会话粘性问题，否则用户的第二轮请求打到另一台机器上就接不上了。这些都是原本由服务端替你兜的成本。
2.3 无状态改造的真实工作量
我给一个中型团队估过这块的改造量，结论是"接口改动一天，周边配套两周"。接口改动就是加个参数、拆个封装，很快；周边配套包括：会话存储选型与容量规划、过期清理策略、多实例一致性、摘要生成的成本与准确率、前端从"传 ID"改成"传会话 token"、埋点与回放能力的重建。
其中最容易被低估的是回放能力。有服务端存储的时候，出问题可以拿 ID 把当时的完整输入输出捞出来复盘；无状态之后，如果你自己没存，那就是真的没了。所以做无状态改造的同时，一定要在你自己可控的、符合留存策略的地方留一份最小必要的调试记录——注意这里的关键词是"你自己可控"和"最小必要"，不是让你把原始请求原样抄一份存起来，那等于把刚省掉的留存又加回去了。我的常规做法是只记录请求哈希、模型名、耗时、token 数、错误码，敏感内容一律不入库。
3. MCP 链路上的数据分岔，比你想象的复杂
MCP（Model Context Protocol）这套东西的价值在于把"模型能调什么"标准化了：工具、资源、提示模板都通过统一协议暴露，客户端不用为每个外部系统写一遍胶水代码。它带来的问题是数据流从"一条直线"变成了"一棵树"：模型服务商只看到工具调用的参数和返回值，但工具服务端、你自己的 MCP 客户端进程、中间的网络代理，全都会经手数据。ZDR 只管这棵树的一个枝干。
3.1 一次工具调用经过的每一跳
我习惯用"逐跳列清单"的方式做梳理。一次典型的远程 MCP 工具调用，大致经过这些节点：用户浏览器 → 你的后端 → 模型服务商 API → 模型决定调用某工具 → 模型服务商向你的 MCP 服务端发起请求（或者你的后端代为发起）→ MCP 服务端执行 → 结果回传 → 再送回模型。每一个箭头都是一个潜在的落点。
| 跳数 | 节点 | 典型留存风险 | 是否在 ZDR 覆盖内 |
|---|---|---|---|
| 1 | 前端应用 | 本地缓存、埋点上报 | 否 |
| 2 | 你的后端 | 访问日志、异常栈、请求体打印 | 否 |
| 3 | 模型服务商 | 响应对象、监控日志 | 是 |
| 4 | MCP 客户端 | 会话状态、调试日志 | 否 |
| 5 | MCP 服务端 | 业务日志、数据库写入 | 否 |
| 6 | 中间网络层 | 网关访问日志 | 否 |
| 7 | 可观测平台 | trace 里的完整 payload | 否 |
看这张表，你大概能理解为什么我说"ZDR 只覆盖一格"。第 3 行是协议覆盖的，其余六行全是你的责任田。我见过的真实情况是：第 2 行和第 7 行最容易出问题，因为访问日志和 trace 采集通常是全局中间件，默认就把请求体打进去了，谁都没想到要去关。
3.2 工具服务端的日志才是重灾区
为什么工具服务端特别危险？因为它拿到的往往不是"一句话"，而是经过模型加工后的结构化参数，信息密度极高。比如一个查订单的工具，模型传给它的参数可能是{"user_id": "...", "phone": "...", "order_no": "..."}——这些是模型从用户原话里抽出来的，比你直接从表单采集的字段更完整。
更麻烦的是异常路径。工具执行失败的时候，很多框架会把入参整个打进错误日志，方便排查。这条日志一旦落到集中式日志系统里，保留周期往往按默认的 30 天甚至更久来算，而且会同步到多个副本、备份、离线数仓。你去清理的时候，得把这些地方全扫一遍。
我通常会在 MCP 服务端做三件事：第一，日志分级，工具入参默认只打字段名和长度，不打值；第二，异常处理里做一次字段脱敏，把疑似身份类、联系方式类、金额类的值替换掉；第三，给 MCP 服务端单独配一个短保留周期的日志通道，业务日志和调试日志分开放。第三点特别重要——很多团队的日志系统是"一个桶装所有东西"，想给某一类日志设短周期基本做不到，只能提前分流。
3.3 工具返回值同样要裁剪
大家通常盯着入参，忘了出参。工具的返回结果会被塞回模型上下文，如果返回的是"整张表"，那你等于把整张表送进了推理链路。我见过一个内部知识库工具，默认返回 20 条命中结果，每条都带完整正文，一次调用就是几千 token，里面可能还混着不该给模型看的内容。
裁剪策略我一般按三层来：字段级——只返回业务需要的字段，不要SELECT *；条数级——给一个明确的 top-N，并且让模型能主动收窄范围；语义级——长文本做摘要而不是原样返回。第三层要小心，摘要本身也是模型生成的过程，如果你的摘要服务不在 ZDR 范围内，那这条数据又流出去一次。所以摘要要么在你自己的环境里做，要么走同样受约束的链路。
4. AI Agent 长循环里的留存放大效应
单个 API 调用跟 Agent 的差距，用一句话概括：前者是"传一次"，后者是"传 N 次，而且每次越传越多"。一个跑十轮的工具型 Agent，用户最初那句话会被复制进十次请求体里，中间还夹杂着十次工具调用的入参出参。这带来两个后果：留存面按倍数扩张，以及你很难说清"某条数据到底经过了几次外发"。
4.1 循环结构决定了复制次数
一个典型的 ReAct 风格循环长这样：把任务和历史发给模型 → 模型输出思考与工具调用 → 执行工具 → 把结果追加进历史 → 再发给模型。每转一圈，整个历史就外发一次。如果你做的是并行子任务，主 Agent 把上下文分发给三个子 Agent，那就是分叉之后的乘法效应。
假设用户输入 500 token，每轮工具返回 800 token，跑 8 轮，那么外发的总 token 量大致是 500×8 + 800×(1+2+…+8) ≈ 32800 token。也就是说，一条 500 token 的输入，在整条链路上产生了 60 多倍的传输量。传输量不等于留存，但只要链路上任何一跳有落盘，被落盘的内容就是这 60 多倍的量级。
这里有个我踩过的坑：早期做 Agent 的时候，为了"方便排查"，在每一轮循环里把完整状态 dump 成一个 JSON 文件写到临时目录。本地跑着很爽，问题是这个逻辑被原样带进了测试环境，而测试环境跑的是真实脱敏数据，结果那台机器的磁盘快满了才被发现。清理的时候翻了三天，因为文件名是时间戳，没有索引，只能一条条看。这个教训非常直白：调试便利性和留存合规是天然对立的两件事，一定要在环境层面做硬隔离，而不是靠人自觉。
4.2 记忆层是 ZDR 够不到的地方
Agent 一旦要做"记住用户偏好"，就会引入持久化。常见做法有三种：直接把历史写进业务库、用向量库做语义检索、用缓存做短期记忆。这三种全部在 ZDR 覆盖范围之外，而且三者的问题各不相同。
业务库的问题是没有过期机制。一张表建好了，字段加上了，数据就一直躺着。我建议所有跟会话相关的表在设计时就带上ttl或者expires_at字段，并且配一个定时清理任务，这个任务要能被监控到，失败要告警——因为清理任务静默失败导致数据堆积，是很难在业务指标上发现的。
向量库的问题是不可逆。你把一段话转成向量存进去，原始文本要不要留？如果留了，那等于存了一份原文；如果不留，那检索出来的结果就只是相似度分数和一个 ID，业务上没法用。多数实现是两者都存，那就要接受"这里有一份完整副本"这个事实，并且把它纳入留存清单。
缓存的问题最隐蔽——很多缓存是内存态，看起来"不算持久化"，但它会被 dump 快照，会出现在监控面板上，会随着故障转移复制到别的节点。我给一个团队排查过，他们在 Redis 里存了完整的会话历史，设了 2 小时过期，觉得风险可控；结果发现 Redis 开了持久化，并且每天做一次快照备份到对象存储，保留 30 天。这条链路一画出来，会议室里安静了好一会儿。
4.3 子 Agent 的上下文继承
多 Agent 架构里有个容易忽视的点：子 Agent 通常由主 Agent 派发，上下文靠"传"而不是"共享"。如果主 Agent 的上下文里有敏感内容，子 Agent 默认也会拿到。更麻烦的是，子 Agent 可能被配置成调用不同的模型或不同的工具集合，这些链路的数据流向跟你主线完全不一样。
我的处理方式是在派发点做一次裁剪：只把子任务必需的信息传给子 Agent，而不是整个上下文梭哈。这个裁剪逻辑要写在代码里，不能靠 prompt 里写一句"请不要泄露以下内容"——那只是建议，不是控制。同时给每个子 Agent 打一个任务标签，日志里带上这个标签，出了问题能快速定位是哪条支路扩散出去的。
5. 落地一份能过评审的边界清单
前面讲的全是"哪里有风险"，这一节讲"怎么把它管起来"。我在几个团队推过同一套方法，核心就三步：把数据流画出来、把配置写死、把验证自动化。听起来很工程化，做起来其实很朴素，关键是要有人真的动手去画那张图，而不是嘴上说"我们都清楚"。
5.1 数据流梳理：白板比文档有效
我建议的做法是拉上三个人——写调用的、运维的、做安全的——找一块白板，从一个真实用户操作开始，一个箭头一个箭头往外画。画的时候问三个问题：这一跳存不存？存多久？谁能读？凡是回答不上来的，就是待办。
这个练习通常会暴露两类问题。一类是"幽灵节点"：某个组件的日志被某个采集器抓走了，但团队里没人知道这个采集器存在，因为它是由另一个部门三年前配的。另一类是"策略孤岛"：安全团队以为应用层没存，应用团队以为日志层的保留周期是 7 天，实际配的是 90 天。这两类问题在白板上会立刻现形，在看文档的时候永远不会。
画完的图不要只放文档里，把它做成一个可以随代码一起更新的东西。我见过做得最好的一个团队，把数据流图放在仓库根目录，配了 CODEOWNERS，任何涉及新增日志、新增外部调用的 PR 都会触发评审。这比写十页规范有效。
5.2 配置层与契约层的双保险
配置层是你能直接改的部分：store: false、日志脱敏规则、日志保留周期、trace 采样与字段白名单、缓存 TTL、清理任务。这些要全部收敛到统一的配置中心，不要散落在各个服务的环境变量里——散着就一定会漂移。
契约层是对外部的约束：跟 MCP 服务提供方把"日志记录范围"写清楚，跟你采购的可观测平台确认"payload 是否入库、保留多久"，跟模型服务确认当前的留存安排和例外项。这些内容口头沟通没有意义，一定要落到纸面，因为对方的人员会流动，而你不想每次换对接人都重新解释一遍。
注意：配置和契约都要有版本概念。留存策略变更时，要有变更记录、影响范围评估和回滚方案。我见过一次把日志保留期从 7 天调到 30 天的变更，没人评估影响，三个月后合规检查才发现，追溯起来已经很难说清原因了。
5.3 怎么验证自己确实没落盘
这一条是我最看重的，也是最容易被跳过的。验证方法分三层。
第一层是代码层静态检查。在 CI 里加一条规则：禁止在请求构造路径上出现store: true，禁止把原始请求体传给日志函数的某些重载版本。这条规则会误报，需要维护，但它拦住的问题往往是最致命的。
第二层是运行时抽样检查。在测试环境灌一批带标记的假数据（比如特定前缀的字符串），跑完业务流程后，去所有可能的落点扫一遍，看能不能搜到这个标记。落点包括：应用日志、数据库、缓存、对象存储、日志平台、trace 平台。这个方法很土，但特别有效，因为它不依赖你对系统的理解，只依赖事实。
第三层是契约层的外部确认。定期跟服务商要一份当前的留存说明，跟自己的理解对一遍。这一层没法自动化，但每年至少做一次。
# 抽样验证思路示意：用带标记的假数据跑流程，再扫描可能的落点 MARKER="zdr-probe-$(date +%s)" echo "本次探针标记: $MARKER" # 跑完业务流程后，在各落点检索该标记 # grep -r "$MARKER" /var/log/your-app/ （示例，请按实际路径调整）6. 那些踩过才知道疼的地方
前面五节讲的是方法论，这一节讲具体的坑。这些坑有共同特征：文档里不会有，出问题时表现得很奇怪，排查完回头看又觉得"这么明显怎么没早想到"。
6.1 调试开关是最大的破功点
框架自带的调试模式、ORM 的 SQL 打印、HTTP 客户端的 verbose 日志、异常处理中间件的"完整请求快照"——这些都是为了让人舒服地调试，代价是把数据原样写进日志。问题在于，这些开关往往是全局的、默认关但随手就开、开了之后忘了关。
我现在的做法是给这些开关加一道锁：调试开关只允许在本地开发环境打开，通过环境变量校验，如果检测到非开发环境打开就直接启动失败。听起来有点粗暴，但这比事后追查好多了。还有一个小技巧：把 verbose 日志的输出目标改成 stdout 而不是文件，配合容器日志策略做短周期清理，能减少一部分残留。
另一个容易忽略的是错误上报平台。异常堆栈里经常夹着变量值，尤其是那种把请求对象整个序列化进异常信息的写法。SDK 层面通常会带一个"是否上报请求体"的开关，默认是开的，记得关。
6.2 功能与留存策略的兼容性冲突
不是所有功能都能和 ZDR 共存，这个要提前摸清楚，否则会在设计中期被迫返工。目前我了解到的冲突点主要有这几类：
| 功能 | 冲突原因 | 替代方案 |
|---|---|---|
| 异步长任务模式 | 依赖服务端保存中间状态 | 自建任务队列，自己存状态 |
| 服务端会话串联 | 依赖服务端存响应对象 | 状态外置，自己维护历史 |
| 服务端上下文缓存 | 依赖对历史前缀的存储 | 减少重复前缀，或接受成本 |
| 文件检索类工具 | 文件需上传并短期保留 | 自行解析后以文本形式入上下文 |
| 部分评估与微调流程 | 需要样本留存 | 明确排除在业务链路之外 |
表格里最后一行值得单独说。很多团队的评估集是从生产流量里抽的，这件事本身没问题，但如果你的评估流程挂在同一条链路上，那"零留存"就被自己破了。正确做法是在业务链路上不抽原始样本，或者抽完之后立刻做不可逆的脱敏，并且脱敏后的数据集要单独纳入管理。
6.3 二次转发与"帮忙看一下"的陷阱
最后一个坑，跟技术无关，跟流程有关：有人把日志截图发到沟通群里请人帮忙看。这一下，数据就进了聊天工具、进了别人的设备、进了群文件、进了备份。这条链路完全不在你的数据流图上，但它真实存在，而且发生频率极高。
我没法用技术手段解决这个，只能靠规范加工具：一是把错误信息里可能带敏感值的地方做替换，让人截出去的图本身就没内容；二是在团队里立一条规矩，排查问题优先用 ID 和哈希定位，实在需要看原文就在受控环境里看；三是提供一个"安全日志导出"的小工具，一键生成脱敏后的上下文，让人觉得用工具比截图方便。第三条最有效——你没法靠禁止改变习惯，只能靠提供更省事的替代路径。
我自己现在的习惯是，所有排查记录里只留三类信息：请求的唯一标识、时间戳、错误分类。需要复现的时候，用这三样去系统里查，查不到就接受"这次复现不了"，重新造数据。听起来很笨，但它让我在过去一年多里没有再因为排查动作本身制造过留存问题。
再补一个实际操作中的小技巧：给每个环境配一张"数据等级卡片"，贴在 wiki 首页，写清楚这个环境里跑的是什么数据、允许怎么操作、出问题找谁。新同学入职第一天就看这个，比读一堆规范有效得多。我们在一个项目里试过，前面三个月因为"不知道测试环境有真实数据"导致的误操作，从每月两三次降到零。
这套东西做到最后你会发现，ZDR 本身只是一个开关，真正难的是围绕它重建整套数据治理的习惯。技术选型可以抄，习惯抄不来，只能一轮一轮磨。
