提示文中涉及的接口字段、开关名称与保留窗口均以当前官方文档和实际合同条款为准版本迭代较快落地前务必做一次核对。1. 先厘清一个常见误解ZDR 提供的究竟是什么保障前阵子帮一个做智能客服的团队做架构评审会上有位同学拍了胸脯说“我们走的是 ZDR数据不留放心”。结果我把他们的链路图往白板上一画——模型调用、Responses API、两个 MCP 工具、一个自建向量库、一套可观测性平台——他自己也沉默了。因为 ZDR 覆盖的只是其中一小段剩下的每一段都可能悄悄留下副本。这类误解非常普遍所以这篇就把OpenAI Zero Data Retention零数据留存下文简称 ZDR和Responses API、MCP、AI Agent这几个概念放在同一条链路上拆开讲说清楚边界到底画在哪里、哪些地方必须自己补位。这篇适合三类人看正在给企业客户做 AI 应用交付、被数据治理条款卡过的工程师正在设计 Agent 架构、需要提前把留存面规划进去的架构师以及负责安全合规、需要一份可执行核对清单的同学。全文不讲空话尽量给到可以直接照着改的配置、验证方法和踩坑记录。1.1 ZDR 的适用对象与开通前提ZDR 不是你在代码里加个参数就能生效的能力它本质上是账号层面的一项数据治理安排。通常需要企业级账号、经过商务与安全评估、在合同或数据处理附录里明确写入然后在组织级别打开。也就是说它是组织属性不是单次请求属性。这一点很关键很多团队以为调用时传一个开关就等于零留存实际上组织没开通那个开关能起的作用有限。从工程视角看ZDR 承诺的核心是请求内容和模型输出不会被持久化保存用于后续用途也不会被拿去做模型训练。但要注意“不用于训练”和“不留存”是两件独立的事。前者是数据用途开关后者是数据生命周期策略。你可能同时需要两者但它们是两个不同的配置项别混为一谈。另外一个行业通行做法是即便在零留存安排下出于安全与滥用监控目的仍可能保留一个短周期的审查窗口窗口内的记录通常不对外提供、只用于安全审查到期自动清理。具体天数各家条款不同落地时以合同为准。所以内部沟通时建议把话说成“业务数据不进长期存储”而不是“一个字节都不落盘”后者容易给自己挖坑。1.2 四个高频混淆概念的对照做方案评审时我发现大家经常把下面四件事说成一件事。用一张表拉开差距后面讨论会顺畅很多。概念解决的问题典型落地位置常见误解不用于训练数据用途边界组织级策略 合同以为等于不存储零数据留存 ZDR数据生命周期组织级开通 请求参数配合以为开了就全链路干净数据驻留数据物理位置区域化部署选项以为驻留等于不留存审计日志可追溯性应用侧日志系统以为日志不算“留存”最后一行是最容易翻车的。很多团队把 ZDR 做完了转头在应用侧把完整请求体打进日志平台保留 180 天还做了全文检索。从数据治理的视角看这跟没做 ZDR 差别不大——敏感内容只是换了个地方躺着。2. Responses API 的有状态设计为什么让留存问题变复杂Responses API 相比早期的纯无状态接口最大的变化是引入了服务端会话对象。你可以只回传一个previous_response_id让服务端自己把上下文接上省掉客户端拼接历史消息的麻烦。这个设计对多轮 Agent 非常友好但它天然意味着服务端要存东西。这跟 ZDR 就是一对需要显式调和的矛盾。2.1 store 参数的真实语义在 Responses 请求里store决定这次响应对象是否在服务端保留。默认值在不同版本和不同账号类型下可能不同所以不要靠记忆直接在请求里显式写死。我的习惯是所有请求一律显式声明store绝不依赖默认值。理由很简单默认值会随版本演进而显式的字段是代码评审时能被看见的。在已开通 ZDR 的组织下通常会出现两种表现一种是请求被强制按不存储处理你传store: true也不生效另一种是直接返回参数错误提示该组织不支持存储。两种都算正常但排查思路完全不同。所以第一件事是拿一个最小请求做探针确认你的组织落在哪种行为上再决定代码怎么写。2.2 两种调用姿势的取舍关闭服务端存储之后多轮上下文得自己管。这里给两段对比代码注意看差异点。# 姿势 A依赖服务端会话非 ZDR 场景常见写法 from openai import OpenAI client OpenAI() first client.responses.create( modelmodel-name, input帮我总结这段工单内容……, storeTrue, ) second client.responses.create( modelmodel-name, input把上面的结论压缩成三条, previous_response_idfirst.id, storeTrue, )# 姿势 BZDR 下的自管理上下文 from openai import OpenAI client OpenAI() history [] def ask(user_text: str) - str: history.append({role: user, content: user_text}) resp client.responses.create( modelmodel-name, inputhistory, storeFalse, ) history.append({role: assistant, content: resp.output_text}) # 关键客户端侧也要有截断策略否则上下文无限膨胀 if len(history) 20: del history[:2] return resp.output_text姿势 B 换来的是留存面收敛代价有三个token 成本上升每轮都要重传历史、首字延迟略增、上下文裁剪逻辑得自己写而且容易写出 bug。我在一个项目里就因为裁剪逻辑把 system 提示词一起删了导致模型行为漂移了两天才被发现。对比维度服务端会话自管理上下文服务端留存面有响应对象无仅请求期每轮 token 成本低高随轮次线性增长上下文可控性弱强可精确裁剪客户端实现复杂度低中高适合场景低敏感、追求体验高敏感、需审计2.3 后台任务与异步模式要单独评估Responses 支持把长任务放到后台跑任务状态需要在服务端维护一段时间客户端再回来取结果。这个能力在 ZDR 场景下要格外小心任务状态的持久化本身就是一种留存。我的建议是凡是涉及后台模式的链路单独拉一个清单出来逐条确认任务对象里存了什么、存多久、能否在完成后立即删除。如果业务上只是偶尔需要跑长任务宁可走同步流式 客户端重试也不要为了省事把整条链路切到后台模式。3. MCP 是数据出站的第一道缺口MCP 这套开放协议解决的是“模型怎么标准化地调用外部工具和数据源”的问题。它的价值很明确工具描述、参数结构、调用结果都有了统一约定Agent 的编排层不用为每个工具写一套适配。但它同时把一条数据出站通道摆在了你面前而这条通道不在 ZDR 的覆盖范围内。3.1 一条完整的调用链路长什么样一次 MCP 工具调用大致经过这些环节模型生成工具调用意图编排层解析成结构化请求MCP 客户端通过 stdio 或 HTTP 把请求发给 MCP 服务端服务端再去访问真实的外部系统数据库、工单系统、搜索服务返回结果沿原路回传进入模型上下文。整条链路上ZDR 只能约束“模型服务侧不长期保存”而 MCP 服务端那一跳是你自己或者第三方在收数据。我见过最典型的场景是客服 Agent 调用一个自建的订单查询工具用户随口说了句“我的手机号是……”这个号码作为工具参数被发到 MCP 服务端而那个服务端的访问日志默认开着、保留 90 天、还带请求体。模型侧干干净净业务侧一地鸡毛。3.2 三类 MCP 服务端的风险分级类型部署位置主要风险建议本地 stdio 工具与应用同机本地日志文件、临时文件残留关闭 debug 日志临时文件用后即删自建 HTTP 工具自有内网访问日志、链路追踪、参数落库日志脱敏 短保留 字段白名单第三方托管工具外部服务数据出境、条款不透明、二次利用逐家做安全评估能不传就不传第三类最需要警惕。因为它的数据处理条款你控制不了而 ZDR 也管不到它。评审时我会直接问一句这个工具的服务方能不能书面说明参数不做持久化答不上来的一律按“会留存”处理然后看业务能不能接受。3.3 在 MCP 前面加一层数据最小化代理实操上最有效的做法不是禁用工具而是在编排层和 MCP 客户端之间插一层很薄的代理做三件事字段白名单、值脱敏、调用审计。伪代码如下。ALLOWED_FIELDS { query_order: {order_id, date_range}, search_kb: {keyword, top_k}, } def sanitize(tool_name: str, args: dict) - dict: allowed ALLOWED_FIELDS.get(tool_name, set()) cleaned {k: v for k, v in args.items() if k in allowed} # 对自由文本做长度截断与敏感模式替换 for k, v in cleaned.items(): if isinstance(v, str) and len(v) 200: cleaned[k] v[:200] return cleaned def call_tool(tool_name: str, raw_args: dict): safe_args sanitize(tool_name, raw_args) audit_log(tooltool_name, keyslist(safe_args.keys())) # 只记键名不记值 return mcp_client.invoke(tool_name, safe_args)这段代码的价值不在于多精巧而在于它把“什么能出站”变成了一份显式清单。清单进代码库、进评审流程比写在文档里靠谱得多。3.4 别忽略工具返回值的反向污染大家盯着出站参数往往忘了入站结果。工具返回的内容会进入模型上下文如果这次请求恰好开了存储那工具查出来的订单详情、客户备注就一起被存进去了。更麻烦的是这些内容还会被后续轮次反复带上。所以工具返回值也要做裁剪只回传模型决策必需的最小字段别把整行数据库记录直接丢进上下文。4. AI Agent 的留存面全景盘点单个接口的留存好控制一旦变成多轮、多工具、带记忆的 Agent留存点会散落在五六个地方。我一般用一张表把全部落点列出来逐个标“已处理 / 待处理 / 不适用”评审时对着过。4.1 六个必须逐个确认的落点序号落点存了什么归谁管常见疏漏1模型请求与响应完整上下文服务方 合同以为 ZDR 全包2响应对象会话历史服务方忘了 store 参数3Agent 记忆 / 向量库用户偏好、历史摘要自己无 TTL、无分区分权4工具调用日志参数与返回值自己或第三方默认全量记录5可观测性与追踪完整 prompt 与 tool 事件自己调试期开启后忘了关6前端会话缓存对话内容自己存 localStorage 且不清理第 5 项是我见过翻车最多的。为了排查一个线上问题临时把追踪级别调到最细问题解决了没人改回来结果一周内所有用户的完整对话都进了追踪平台。这跟 ZDR 毫无关系纯粹是工程纪律问题。4.2 记忆与向量库最容易被忽视的第二数据库Agent 一旦带了长期记忆向量库就成了第二个用户数据库。Embedding 本身也是数据而且是更难删除的数据——你很难从一堆稠密向量里精确定位“这个用户的那句话”。实操建议有三条按租户或用户做物理分区便于整分区删除给每条记忆打时间戳并设置 TTL到期自动清理写入前做一次敏感信息过滤别把手机号、证件号这类字段编进向量。4.3 编排框架的默认日志级别主流编排框架在不配置的情况下往往会输出相当详细的运行日志包括完整提示词和工具入参出参。这些日志默认打到标准输出容器平台一采集就进了日志中心。我的做法是在启动脚本里显式关掉追踪开关并把日志级别固定为信息级同时在代码仓库里加一条检查规则防止有人为了调试把开关又打开提交上去。5. 落地一套可审计的链路从画边界开始讲了这么多风险落到工程上其实就三件事把信任边界画清楚、把配置写死、把验证做成例行检查。5.1 信任边界的画法我习惯在架构图上用一条线把系统切成两半线的一侧是“我完全控制”的组件另一侧是“我部分控制或完全不控制”的组件。对 AI 应用来说这条线通常画在编排层和外部服务之间。线右侧包括模型服务、第三方 MCP 工具、第三方追踪平台线左侧包括自己的业务后端、自建工具、自建存储。ZDR 只管右侧第一格其余每一格都要单独给出控制手段。这个动作看起来简单但它能一次性把“我们以为安全”和“实际安全”之间的差距暴露出来。5.2 一份可以直接抄的配置清单组件配置项建议值验证方式模型请求store显式 false抓包看请求体模型请求会话续接禁用 previous_response_id试探应报错长任务后台模式默认关闭代码检索关键字MCP 客户端参数白名单按工具配置单测覆盖MCP 服务端访问日志仅记元数据抽查日志样本编排框架追踪开关生产关闭启动脚本检查应用日志请求体记录禁止日志采样审计向量库TTL按业务设 7 至 30 天定时任务监控5.3 怎么证明“确实没留”这一步最容易被跳过也最值得做。我一般用四个动作交叉验证。第一抓一次真实请求的报文确认请求体里store字段的值符合预期。第二用上一次响应的标识去做续接试探如果组织处于零留存模式这个调用应该失败或者被降级失败本身就是证据。第三从日志平台随机抽十条记录看有没有完整请求体这一条最能暴露工程纪律问题。第四每季度做一次“红队式”抽查让一位不熟悉链路的同学只看代码和配置试着找出三个可能留存用户原文的地方。找得到就修找不到说明设计确实收敛了。# 最小探针确认组织行为注意替换占位符 curl -s https://api.openai.com/v1/responses \ -H Authorization: Bearer $API_KEY \ -H Content-Type: application/json \ -d { model: model-name, input: ping, store: false } | head -c 500跑完这个探针重点看返回体里跟存储状态相关的字段以及有没有告警提示。不同版本字段命名会有差异别硬记字段名看返回结构里的语义即可。6. 排查实录那些让人抓头的报错与异常下面这些是我和同事在真实项目里遇到过的现象按“现象—原因—处理”整理遇到类似情况可以先对照一遍。现象可能原因处理方式传 store 为真但行为像关闭组织已启用零留存参数被覆盖改为显式 false避免误导后来者续接调用返回参数错误该组织不允许服务端会话切换到自管理上下文工具调用偶发超时后重复执行客户端重试策略与工具幂等性冲突加幂等键重试只做查询类流式响应中断产生半截内容网络抖动客户端未做完整性校验加结束标记校验失败重放日志平台出现完整对话调试开关未复位纳入上线检查清单向量库体积异常增长缺少 TTL 与去重定时清理 写入前去重有几条经验值得单独说。重试与幂等这一条很多团队在查询类工具上不设幂等键超时重试就把同一条记录查了三次日志里也写了三遍。虽然数据没被模型侧留存但工具侧留了三份。流式中断这一条更隐蔽客户端拿到半截 JSON 就直接解析解析失败的异常里往往带着原始响应片段一旦被打进错误日志又是一次留存。还有一个高频问题多环境配置漂移。测试环境为了调试把追踪开满生产环境用的是同一份配置文件模板部署时忘了覆盖。我的做法是把“是否允许记录完整请求体”做成一个显式的环境变量默认值为禁止只有在本地开发环境才手动改成允许并且这个变量名里带上dev_only字样让它在代码评审时足够扎眼。7. 成本、体验与安全的三角平衡把留存面收紧之后最直接的两个代价是 token 成本和交互体验。这一节聊怎么把代价控制在可接受范围。7.1 自管理上下文的账单怎么算举个具体例子。假设一轮对话历史平均 800 token用户会聊 10 轮输出平均 300 token。走服务端会话时每轮只需传新增内容10 轮累计输入大约 8000 token 量级走自管理上下文时第 N 轮要重传前 N-1 轮累计输入接近 44000 token 量级差了五倍多。这个差距在低单价模型上还能忍在高单价模型上就是实打实的预算问题。优化手段有三个把历史做摘要压缩只保留关键事实而不是原话对早期轮次做滑动窗口超过窗口的直接丢弃把不敏感的短会话路由到服务端会话模式敏感会话走自管理。第三条需要一套路由判断逻辑通常按会话来源或用户等级来分实现成本不高但收益明显。7.2 分级策略比一刀切更现实我越来越倾向于按数据敏感度做分级而不是全链路一刀切。第一级是公开信息类场景比如产品文档问答这类完全可以走服务端会话体验优先第二级是内部业务数据走自管理上下文加日志脱敏第三级是涉及个人身份信息的场景除了上述措施还要加上工具参数白名单、向量库分区、以及更短的日志保留窗口。分级的好处是资源花在刀刃上坏处是需要一套判定规则并且要防止误判。我的做法是默认落到最高级别只有明确的场景白名单才允许降级这样出错时是“过度保守”而不是“意外泄露”。7.3 一个容易被忽略的成本项验证本身的开销做验证要发探针请求、要跑抽检脚本、要做日志采样这些都会产生费用和人力。我一般把验证频率定成探针请求每次发布跑一次日志抽检每周一次红队式抽查每季度一次。频率再高收益递减频率再低容易积压问题。这套节奏跑下来一个中等规模的团队每周投入不到两小时但能挡住绝大部分配置漂移。最后分享一个我自己踩过的坑。早期做零留存改造时我把注意力全放在请求参数上觉得store写死就万事大吉。直到有一次线上排查需要还原一个用户的完整对话我在日志平台里搜关键词三秒钟就搜出了原文——那一刻才意识到真正的留存风险从来不在模型服务那一侧而在我们自己为了方便而随手打开的每一个开关里。后来我们定了一条内部规矩任何会记录完整请求体的改动必须走一次额外的评审评审只问一句话——这个日志三个月后还敢不敢给客户看。答不上来就别记。