一行命令拉起 Web 工作台的 Agent 框架，一个补丁能让它更顺手还是更卡顿？
DeepSeek Harness 在 2026 年 8 月 13 日开源首日，12 小时内 GitHub Star 突破 5 万。从 v0.1 开发者预览版到 0.1.3-alpha.1，只隔了不到一个月。这次更新带来了文件上传、代理配置、Intel Mac 支持等五个新能力，却同时承认了一个性能回退。一个刚刚从 Alpha 冲到 RC 的版本，为什么转头又开了一条 Alpha 线！
任意文件上传来了，但上传完怎么用才是关键
以前 DSH 只支持上传图片。上传后自动压缩、后台传输、read_image 读取、多模态模型处理，一套流程跑得挺顺。但你真正干活时给 AI 的东西远不止图片。PDF 合同、Word 文档、Excel 表格、CSV 数据、JSON 配置、代码文件、日志、压缩包——这些东西才是日常。
0.1.3-alpha.1 直接把这道墙拆了。文件和图片现在能混在同一个预览区里。你可以在一次任务中同时扔给 Agent 一张产品截图、一份需求文档、一个用户数据表和一个配置文件，让 Agent 围绕这组资料工作。上传过程也像样了：后台显示进度、可以随时取消、切换到别的会话再切回来，上传状态还在。
但真正让事情不一样的，是文件上传后的处理方式。DSH 把文件保存到工作环境，模型通过已有文件工具按保存路径按需读取。这意味着你不用再把一个几十页的 PDF 整个塞进 Prompt 里。文件上传、保存到工作区、告诉 Agent 文件在哪、Agent 自己判断读哪部分——这才是长期任务该有的样子。
对比一下竞品！Aider 是 Git 原生的轻量工具，主打小而确定；Claude Code 和 Codex 走的是 IDE 集成路线。DSH 的“一切皆插件”架构让文件处理这件事变成了可插拔的能力——文件上传插件只管传，文件读取插件只管读，两者通过保存路径解耦。这套设计比竞品更灵活，但也更复杂！
代理设置终于统一了，但为什么之前会这么乱
一个让人抓狂的场景：Chrome 能联网、curl 能联网、git 能联网，DSH 却连不上。问题出在 Node 网络栈和代理环境变量这一层。
0.1.3-alpha.1 把这事修了。HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY——启动环境里怎么配，DSH 的出站请求就怎么走。模型调用、网页搜索、网页抓取、HTTP MCP 这些能力，终于统一到一套网络策略下。
最常见的配置就是 export HTTPS_PROXY=http://127.0.0.1:7890。有地址要直连就继续配 NO_PROXY=localhost,127.0.0.1,.internal。对国内用户来说，这属于基础设施补丁。以后再碰到浏览器正常但 DSH 死活访问不了的情况，排查路径清楚多了。
但这事有意思的地方在于：为什么一个 Agent 框架的网络请求会这么乱？因为 DSH 的“一切皆插件”架构里，模型适配器、工具注册表、会话日志、Agent Loop 全都可以替换。每个插件可能用自己的网络请求方式。统一代理设置听起来简单，在插件化架构里等于要给所有出站请求加一道统一闸门。这套架构灵活，但统一基础设施的成本也高！
图片终于能直接看了，但 read_image 的渲染逻辑藏着一个判断
以前 read_image 调用返回的是原始附件对象——你在 Web 界面上看到的是一堆技术字段，不是图片本身。
0.1.3-alpha.1 改了。顶层和 PTC 嵌套的 read_image 工具调用，现在直接在 Web 工具卡里渲染图片。你不需要点开附件、不需要解析返回结构，图片就在对话流里直接出现。
这个改动看起来小，但暴露了 DSH 的一个设计判断：工具调用的结果应该以用户可读的形式呈现，而不是以机器可读的形式抛给用户。竞品里，Claude Code 在终端里根本没法渲染图片；Aider 压根不支持多模态。DSH 的 Web UI 在这块确实走得靠前。
但问题来了：read_image 的“顶层”和“PTC 嵌套”两种调用场景都支持了，那其他工具调用呢？文件读取、代码执行、网页抓取——这些工具的结果是不是也该有对应的可视化渲染？还是说只有图片特殊！
模型自动发现补全了，但第三方模型接入的门槛到底在哪
DSH 现在支持从自定义模型提供商的 models 对象和 Anthropic 原生模型列表里自动发现模型。发现之后自动回填模型名称、上下文窗口、最大输出 token。
这事的反常识点在于：一个 DeepSeek 自己做的 Agent 框架，居然在积极接入 Anthropic 的模型列表。你不是应该优先推自己的模型吗？
答案在“一切皆插件”里。模型适配器本身就是可替换的插件。DSH 的定位不是“DeepSeek 模型专用客户端”，而是“让任何模型都能接进来的 Agent 运行框架”。支持 Anthropic 模型列表不是让步，是架构的自然延伸。
但这也意味着：模型自动发现只覆盖了 Anthropic 和自定义 providers 的 models 对象。其他厂商呢？OpenAI 的模型列表、Google 的模型列表、国产厂商的模型列表——这些要不要支持？如果不支持，用户是不是还得手动填参数？自动发现这件事，做一半比不做更让人困惑！
Skill 选择器加了模糊搜索，但一个搜索框能解决 Skill 泛滥的问题吗
Skill 选择器现在支持模糊搜索了。聊天气泡里的 Skill 和命令引用也优化了展示。
Skill 是 DSH 里一个特殊的概念——它不是工具，是预设好的能力组合。标准模式自带全套 Skill：文件编辑、Shell、文件与网页检索、规划、目标管理、子 Agent、工作流。随着插件生态扩展，Skill 只会越来越多。模糊搜索解决的是“找到那个 Skill”，但解决不了“我到底该用哪个 Skill”。
竞品里，Aider 没有 Skill 这个概念，它就是 Git 加 AI；Claude Code 的 Skill 更像是内置命令。DSH 的 Skill 是插件组合的产物——你可以装一个插件就多一组 Skill。这种设计给了你无限扩展的可能，但也给了你无限选择的困境！
性能倒退了，但为什么一个补丁版本会越修越慢
Release Note 最后一行写得很直白：“本次发布存在已知的性能回退，可能影响部分历史 session 加载的响应速度，我们将在下一个版本中修复。”
一个版本加了五个新功能、修了一堆 Bug，然后告诉你性能变慢了。这正常吗？
不正常。但如果你看过 DSH 的版本节奏就明白了。0.1.2 从 Alpha 冲到 RC，刚有点要收口的意思。紧接着 0.1.3 重新回到 Alpha。中间只隔了 29 个半小时。而且这次还带了破坏性变更：Session persistence API 改成 SessionHandle 持有、agentLoop.create() 变成异步、新增 Session 锁确保同一 Session 至多被一个进程持有。Session 格式也升到了 v2。
这意味着什么？意味着 DSH 还在快速迭代期，架构层面的改动还在发生。性能回退不是 Bug，是重构的代价。官方说的是“下个版本解决”，没说“下个版本一定解决”。
对比一下：Aider 从个人项目起步，四年多慢慢磨到 48k Star。DSH 开源首日 5 万 Star。速度带来的不只是关注，还有架构还没稳定就得面对海量用户的压力。性能回退在这种节奏下几乎是必然。
但这事还没完。
一个还在 0.1.3-alpha.1 就敢做破坏性变更、改 Session 格式、把同步 API 改成异步的项目，摆明了在告诉所有用户：这东西还没定型。性能回退只是一张明牌，暗牌是下个版本还可能删接口、改格式、动存储。你要跟，就得接受随时重来的准备！