DeepSeek Harness Python SDK 会上传会话日志吗？关闭方法与数据边界

DeepSeek Harness 的 Python SDK 默认带一个会话日志贡献器 session-log-deepseek：它会随 DeepSeek 请求上传未被接受的日志事件，每次请求最多 8 MiB。 这不是 OTel 遥测，而是会话日志链路；sdk-minimal 默认不含 OTel，但包含这个贡献器。对敏感仓库或合规环境，应该先明确它是否开启，再决定要不要关。

DeepSeek Harness：默认上传什么、上限多少

上传对象是“会话日志事件”，不是“最终回答”或“统计指标”。 三个要点：（来源）

1. 随 DeepSeek 请求上传 — 不是独立的后台任务，而是搭在模型请求链路上。预期：请求发出时可能同时携带日志事件。
2. 只带未被接受的事件 — 官方描述为“未接受的日志事件”，不是整份会话。预期：不会每次都把全部历史重传。
3. 每次请求最多 8 MiB — 由 maxBytes 控制。预期：单次请求不会无限量携带日志。

“日志事件”包含什么，取决于会话日志本身。对话消息、工具调用、工具结果只要进入日志，就可能在可上传范围内。不要把它理解成“只传错误统计”。

DeepSeek Harness：关闭方法

关闭只需要一条 profile patch：session-log-deepseek.enabled: false。 两种写法：（来源）

# $DSH_HOME/profiles/sdk-minimal/cordis.patch.yml
- id: session-log-deepseek
  config:
    enabled: false

1. 持久关闭 — 写进 profiles/sdk-minimal/cordis.patch.yml。预期：之后每次启动 SDK 都不上传。
2. 按次关闭 — 单独写一个 patch 文件，构造 DeepSeekHarness 时通过 patches=(...) 传入。预期：只影响本次进程。
3. 重启验证 — 关闭后重启宿主程序。预期：新进程按新配置启动，旧进程仍按旧配置运行。

如果写的是 enabled: false 但没生效，先确认改的是不是当前 dsh_home 下的 profile；SDK 只读显式传入的 home。

DeepSeek Harness：两条日志链路不要混

session-log-deepseek 与会话日志是两件事，和 OTel 遥测也不是同一条链路。 对照：（来源）

关闭第二条不会删除第一条；关闭 OTel 也不会停止第二条。排查“数据有没有出去”时，要分别确认这三条链路，而不是只看一个开关。

DeepSeek Harness：三种控制层级

只靠一个开关不够时，可以按“应用配置 → 单次运行 → 网络层”三层控制。 对比如下：（来源）

1. 应用配置 — 在 profile patch 里关闭，适合长期使用。代价：换 home 或换 profile 后要重新配。
2. 单次运行 — 用 patches 临时关闭，适合敏感任务。代价：每次都要记得传，漏传就回到默认。
3. 网络层 — 在容器或出口网关限制可访问域名。代价：可能影响模型请求本身，需要精细规则。

三层可以叠加。最稳的做法是“默认关闭 + 敏感任务再用网络层兜底”，而不是只依赖一个 YAML 开关。

DeepSeek Harness：关闭后本地还留什么

关闭上传不等于关闭日志。SDK 仍会把会话写到本地 JSONL。 本地留存包括：（来源）

• sessions — dsh_home/sessions 下的未压缩 JSONL，含完整对话与工具结果。
• profile — sdk-minimal 的配置与已安装插件。
• 凭据与设置 — 如果该 home 使用过 provider，相关凭据可能在其中。

如果目标是“本地也不留”，需要额外处理 sessions/，并在任务结束后清理 home。不要以为关了上传就自动变成无痕。

DeepSeek Harness：合规判断怎么做

先回答三个问题，再决定是否关闭：数据是否敏感、请求是否出公司网络、日志是否含第三方内容。 判断口径：（来源）

1. 数据敏感度 — 仓库里有密钥、客户数据或未公开代码时，默认关闭。预期：避免日志事件随请求离开。
2. 网络边界 — 请求本来就要发到模型服务，日志只是附带；如果模型请求本身不允许出网，应先解决网络，而不是只关日志。
3. 第三方内容 — 工具结果可能包含用户数据或网页内容。预期：这类内容进入日志后同样可能被上传，需按数据分级处理。

对大多数本地开发，默认开启不是灾难；对受监管环境，默认关闭更稳。关键是明确选择，而不是“不知道它开着”。

怎么确认上传是否开启

不要靠猜，按配置、启动日志与网络三层确认。 步骤：

1. 查 profile patch — 看 session-log-deepseek.enabled 是 false 还是未设置。预期：明确当前配置意图。
2. 看启动后的配置树 — 用 dsh --profile sdk-minimal --dump-config 核对该项。预期：确认 patch 真的被叠加。
3. 观察请求体或出口流量 — 在受控环境里抓一次模型请求，确认是否附带日志载荷。预期：用证据而不是记忆判断。

如果三层里有任何一层对不上，以实际请求为准；配置写了 false 但流量仍带日志，说明改错了 home 或 profile。

确认时不要只看 dsh --profile sdk-minimal --dump-config 的输出，还要确认 SDK 构造时传入的 dsh_home 就是那个 profile 所在的 home。两者不一致时，你查的配置根本不是运行时用的配置。

另外，SDK 的配置在进程启动时读取；改完 patch 后必须重启宿主程序。只在磁盘上改文件、进程不重启，抓到的流量仍会按旧配置走。

DeepSeek Harness 常见问题

Q：关闭后模型还能正常用吗？ 能。关闭的只是日志贡献器，不影响模型请求、工具调用或会话持久化。

Q：8 MiB 是每次会话还是每次请求？ 官方写的是每次请求最多 maxBytes（8 MiB）。不是整份会话的总上限。

Q：这个上传和 /feedback 是一回事吗？ 不是。/feedback 是用户主动反馈；session-log-deepseek 是默认的会话日志贡献器。两者不要混为一谈。

一句话收束： SDK 的日志上传是默认行为，不是遥测统计；要控就控在 profile patch 里，同时别忘了本地 sessions 仍在。