数据控制与参数过滤 - API Docs

默认字段处理

以下是 relay/common/relay_info.go 的 RemoveDisabledFields 在被调用且未启用全局/渠道请求直通时的行为；不是所有上游、插件和配置的统一保留承诺。

字段	默认处理	配置边界
`service_tier`	移除	渠道允许后才能转发；上游还需支持对应服务等级
`inference_geo`	移除	Claude 区域扩展；允许转发不证明数据驻留
`speed`	移除	Claude 速度扩展；需渠道允许及上游支持
`safety_identifier`	移除	需渠道允许；不要用原始个人信息作为标识
`store`	默认允许转发	`DisableStore` 会移除该字段，不会强制改成 false
`stream_options.include_obfuscation`	移除	需渠道允许；不要与是否流式输出混淆

全局或渠道直通会跳过这个过滤函数。其他转换、参数覆盖和上游默认行为仍可影响有效请求。调用方不能仅靠发送字段证明它已生效，应由部署方核实实际路径和配置。

`store: false` 能说明什么

它请求支持该字段的上游不保存相应响应资源，不等于网关不记录日志、缓存关闭、禁止训练或全链路零数据保留。特别是 DisableStore 删除 false 后会恢复上游默认行为，不能把这个配置当成“强制不保存”。日志、代理、渠道供应商、缓存及任务产物的生命周期需要分别核实。使用无状态对话历史可以减少对响应 ID 保存的依赖，但发送的历史仍会交给上游。搜索关键词、PDF 内容和工具输入同样会离开应用进入实际执行方。不要将 OpenRouter 的 ZDR 筛选、BYOK、服务等级或训练政策参数直接当成本项目端到端保证。

接入时核对

确定原生还是转换路径，以及渠道是否覆盖或过滤请求字段。
按部署政策选择允许发送的内容；应用日志只保留必要诊断字段，参见请求观测。
将保留时间、删除行为和第三方服务范围交由部署方明确；不要用本地 fixture 或一次成功请求替代验证。

本文不更改渠道配置。示例中的 store: false 可在 PDF 输入和联网搜索查看；本地只验证发送意图，不能验证上游保留策略。实现依据：relay/common/relay_info.go、relaykit/dto/channel_settings.go 与各渠道适配器。 Read in English