DeepSeek Harness v0.1.2-alpha.1 更新内容与升级判断

先看结论

DeepSeek Harness v0.1.2-alpha.1 是 2026-08-27 发布的 GitHub 预发布版。截至 52DSH 于 2026-08-28 复核时，npm latest 和 next 仍为 0.1.1-rc.2，所以普通用户执行现有默认 npx 命令不会自动得到这个 alpha 版本。

这次更新涉及会话界面、子 Agent 模型选择、插件登录控件、ACP、Headless 输出、安全说明和多个跨平台修复，值得开发者提前评估；但依赖生产 Profile、第三方插件或稳定脚本输出的用户，不应只看到 GitHub 出现新 Release 就直接替换当前环境。本文依据官方 Release、固定 commit 和版本比较进行源码级资料复核，没有安装或运行该预发布版。

三个渠道现在分别是什么版本

“GitHub 已发布”和“npm 默认可安装”是两件事。52DSH 把 0.1.2-alpha.1 记录为已确认的上游预发布版，同时保留 0.1.1-rc.2 作为默认安装基线。后续 npm 状态改变时还需要重新复核，不能用本文状态永久推断。

这次更新对普通用户最明显的变化

官方 Release 把会话阅读和输入体验作为一组重点：已完成回答前的过程内容和 System prompt 默认折叠；正文宽度可自适应或拖动；每个完成回答可以查看精确 token 用量；会话视图增加紧凑回合导航，字号与 Markdown 表格也能一起调整。

运行中的会话如果已经有草稿，主按钮会切换为“发送”并把消息排队；切换会话后未提交的提问卡片会保留。图片会先显示，再在后台完成压缩与上传；轨迹视图也能展示用户、助手和工具结果中的图片。这些变化主要减少长会话的视觉负担，不代表模型能力或权限边界自动变化。

官方还声明优化了页面启动、会话初始化和记录磁盘占用。由于本文没有在同一硬件和同一 Session 上做前后对比，不给出“快了多少”或“节省多少空间”的数字。

子 Agent 可以更明确地选择模型

0.1.2-alpha.1 新增或补齐了三层控制：

1. 开启子 Agent 模型选择后，Agent 可以在配置授权范围内选择 Provider、模型和 reasoning effort；
2. 调用方启动子 Agent 时可以指定 Provider、模型、reasoning effort 和最大输出长度；
3. Claude Code、Codex 子 Agent 支持配置模型。

这里的关键词是“在授权范围内”。它不等于任意 Agent 都能绕过 Provider、凭据或团队权限，也不代表旧版页面一定出现相同控件。现有 0.1.1-rc.2 用户应继续按模型、API Key 与 Provider 教程配置；准备验证 alpha 的开发者，应分别记录主 Agent 和子 Agent 实际使用的 Provider、模型、权限与输出限制。

插件可以扩展 Provider 登录，但也多了信息披露点

新版允许插件在模型设置中加入 Provider 登录控件。这为 OAuth 或特定服务认证提供了更自然的入口，但也意味着用户需要同时审查插件代码、登录流程、回调地址、凭据存储和撤销方式，不能因为控件出现在设置页就默认它属于官方认证。

另一个需要注意的变化是：官方 DeepSeek 适配器默认会随请求提供已启用插件的包名和版本，部署方可以通过配置关闭。官方还增加了可选的 Session 日志增量上传，该功能默认关闭。

这两项行为不同：插件包信息默认提供但可关闭，Session 日志上传是主动开启。企业或包含敏感项目名称的环境，应在测试前明确数据流、日志策略和配置责任。插件安装、Profile 和 Bundle 的关系见DSH 插件安装与管理指南；这次 Release 不能证明现有社区插件已全部兼容 alpha。

Headless、ACP 和应用启动有什么变化

Headless 运行现在会把进度流式写入 stderr，并把 stdout 限制为最终结果。对于只在终端阅读结果的人，这一区别可能不明显；对于把 stdout 直接送入 JSON、管道或 CI 后续步骤的脚本，它属于需要重新验证的接口行为。现有脚本应分别捕获 stdout、stderr 和退出码，不能把两条流重新混在一起。具体工作方式见DSH Headless 教程。

ACP 在这一版补齐标准 Session 控制、模型设置、MCP、权限和取消能力；Python SDK runtime 新增 Windows x64 发行包。应用也统一通过 dsh Profile 启动，包括 Python SDK 和 ACP 模式。准备接入这些能力的开发者适合在隔离环境评估，但不能把“官方提供发行包”直接写成自己的业务流程已兼容。

兼容性变化不能只看界面

升级判断至少要覆盖以下变化：

官方说明旧 Session 中的 Code Mode 记录仍可读取，但没有承诺所有外部脚本、插件和 CSS 选择器都不受名称与模块变化影响。依赖旧接口的开发者应先阅读完整 compare，再在可回退环境测试。

安全说明比功能更新更重要

官方在本版更新 Safety Notice：DeepSeek Harness 尚未接受安全审计，沙箱、审批与权限控制不能保证隔离。这不是“新版本突然不安全”，而是更明确地界定现有保护机制不能替代系统级隔离、最小权限和人工判断。

同时，公网 WebFetch 默认启用并内置 SSRF 防护，访问公网不再逐次审批。SSRF 防护主要处理网络目标边界，不会判断网页内容是否可信，也不会替代数据外发、许可证或提示注入风险控制。涉及私有仓库、企业网络或真实凭据时，应先阅读DSH 权限与沙箱边界，使用隔离测试目录和可撤销凭据。

哪些修复值得现有用户关注

官方 Release 还列出一组跨平台问题修复：

• macOS 与 Linux 的持久 PowerShell 启动过早、输出不完整；
• Linux 持久 Bash 在管道内部读取时提前返回空输出；
• macOS 上 Bash 派生大量子进程时宿主卡顿；
• Windows 目录选择器截断包含特定编码字符的路径；
• 会话界面无法展开持久 Bash 和 PowerShell 结果；
• Profile 配置的 Agent Preset 目录在启动时丢失；
• 无法加载的 Agent Preset 缺少提前标记和失败原因；
• 空闲 WebSocket 连接缺少心跳。

如果你正在稳定复现其中一个问题，alpha 可能值得在副本环境验证；如果当前工作流没有这些问题，则没有必要只为了版本号变化承担预发布兼容风险。

谁适合现在测试

适合测试的情况：

• 正在开发 Provider 登录插件，需要验证模型设置扩展点；
• 需要测试主 Agent 与子 Agent 的不同模型或 reasoning effort；
• 正在接入 ACP、Python SDK Windows x64 或新版 Profile 启动方式；
• Headless 脚本明确区分 stdout 和 stderr，并且已有回归用例；
• 正在复现 Release 列出的跨平台 Shell、Preset 或 WebSocket 问题；
• 有独立工作区、测试凭据、配置备份和快速回退路径。

建议继续等待的情况：

• 只使用 npm 默认安装，不需要 alpha 新能力；
• 生产 Profile 依赖多个社区插件，但没有逐个兼容性记录；
• 自动化脚本依赖旧 APIProxy、旧启动入口或混合 stdout/stderr；
• 环境包含真实凭据、客户数据或不可恢复的 Session；
• 团队尚未明确 WebFetch、插件信息披露和 Session 日志策略。

升级前按这五步检查

1. 记录当前 DSH 版本、启动方式、Profile、插件包版本和操作系统。
2. 备份 Profile 配置、必要的 Session 和工作区变更，不把明文凭据复制进普通归档。
3. 对照完整 Release 与 compare，只选择需要验证的功能，不把整个生产环境一次性迁移。
4. 在独立测试目录使用最小权限、可撤销凭据和低风险任务验证。
5. 分别记录预期结果、实际结果、stdout、stderr、退出码和回退路径。

具体的版本记录、更新、回退与清理步骤见DeepSeek Harness 更新与卸载指南。第一次接触 DSH 的用户应先使用稳定安装基线启动 Web UI，不要从 alpha 版本开始排查基础环境问题。

常见问题

v0.1.2-alpha.1 是正式版吗？

不是。官方 GitHub Release 明确标记为 Pre-release。版本号中的 alpha.1 也表示它处于早期预发布阶段。

为什么 npm 默认命令装不到这个版本？

因为截至本文复核时，npm latest 和 next 都还是 0.1.1-rc.2。GitHub Release 出现新 tag 不等于 npm dist-tag 已同步。

52DSH 为什么不把所有教程一起改成 0.1.2-alpha.1？

每篇教程对应不同功能和证据范围。预发布版尚未成为默认安装版本，批量改版本会把“已审阅该功能”和“仅看到新 Release”混为一谈，因此只更新真正受影响且完成来源复核的页面。

现有插件是否兼容 alpha？

本次 Release 没有证明所有社区插件已经兼容。需要逐个检查 manifest、固定版本源码、依赖、权限和实际运行结果；源码审阅不能替代运行验证。

什么时候应该重新评估？

当 npm dist-tags 改变、官方发布新的 alpha/rc 或正式版、你依赖的插件声明兼容版本，或者现有问题正好被本版修复时，都应重新进行版本复核。

官方固定来源

• v0.1.2-alpha.1 官方 Release ↗（外部链接，在新标签页打开）
• 发布合并提交 cd5ef814 ↗（外部链接，在新标签页打开）
• v0.1.1-rc.2 到 v0.1.2-alpha.1 完整变更 ↗（外部链接，在新标签页打开）
• npm 当前 latest 元数据 ↗（外部链接，在新标签页打开）

以上外部页面用于事实核对；52DSH 的测试建议和优先级判断属于编辑部基于这些来源作出的风险控制建议。