背景

先说结论：目前为止我的感觉是惊艳。

起因很简单：我想验证 DSH 到底能不能干"真活"——不是聊天问答那种，而是完整接手一个真实任务。正好手头有个年头长的老项目（一个基于 IIS 的自动部署工具），就拿它当了被测对象。我试探性地问了一句：

当前项目有个 AutoDeploy 的项目，是基于 IIS 做自动部署的，年头长了，你看看能把具体功能识别出来，并做一些文档说明，然后给出改进优化意见吗

这句话扔给了 DeepSeek Harness（后面简称 DSH）。接下来的一段时间，我基本是在旁边看着它干活。

认识与安装：DeepSeek Harness 是什么

它自称"一切皆插件"

打开官网首页，最醒目的就是这句定位（图 1）：

模型、工具、技能、会话、沙箱、存储、循环、调度、UI 等所有 Agent 能力均由插件组合而成，可以自由替换和灵活重组。面向全球 Harness 开发者开放测试，并同步开放源代码。

这个理念我后来实际用下来是认同的：你看到的所有能力——终端、文件检索、代码搜索、技能、子代理、长期目标——确实都挂在统一的插件机制上，页面上也提供了"社区插件"入口，意味着这套东西可以按需拆装。当前是 1.x 开发者预览版，官方也明说了（图 3）：核心组件和基础 API 都会在接下来一段时间内快速迭代。

安装：一条命令的事

安装环节出奇地简单（图 2），全局装一个 npm 包即可：

npm install -g @deepseek-ai/dsh

装完直接启动：

dsh web
# dsh web: http://127.0.0.1:3080

浏览器打开 http://127.0.0.1:3080 就是工作界面了。如果不想全局安装，官网首页也提供了 npx 免安装的启动方式。

配置：模型、插件、权限

界面里需要配置的东西不多，三处：

1. 模型（图 5）：填入模型提供方的 API 密钥即可使用对应模型，除了内置的 DeepSeek，还支持添加自定义模型提供方——也就是说你可以把它接到任意兼容的模型服务上。
2. 插件（图 6）：本地已安装的插件可以逐个启用/停用，比如 tool-fs-search（文件搜索）这类，一目了然。
3. 会话参数（图 4、图 7）：新建会话时选模型（我用的是 DeepSeek-V4-Flash）、选文件权限模式（比如 Workspace Write，限定 Agent 只能在工作区内写文件），然后直接描述目标即可。

整个界面比较克制：左边是会话/工作区，中间是对话流，右边是实时统计面板（图 8）——每轮对话的步数、LLM 时长、工具调用次数和 token 消耗都看得见。第一次看到"对话轨迹"展开视图（图 9）的时候还挺震撼的：Agent 每一步的思考、每一个工具调用（读文件、跑命令、搜代码）全部留痕，像一份完整的审计日志。

第一阶段：读代码、写文档

DSH 没有上来就"编"，而是老老实实把项目里所有源文件读了一遍，包括运行期生成的 DownloadList.json、currVersion.txt、step.txt 这类数据文件——这些文件恰好暴露了真实的数据格式，比看代码还直观。

看完之后它产出了三样东西：

1. 功能说明：识别出这是一个 7 步状态机——轮询版本索引 → 下载更新包 → 停 IIS 站点 → 备份 → 解压覆盖 → 启动站点 → 邮件通知，状态落盘到 step.txt 支持断点续跑；
2. 命令行参数表：-appSite、-output、-subpath、-noticeTo 等一二十个参数的语义和示例；
3. 改进优化建议：21 条，按 P0（安全）→ P3（增强）分级。

这里有个细节我印象很深：它从 StepNotice.cs 里翻出了一个明文写死的邮箱授权码，原样贴进了风险报告里。顺带还指出代码里残留的测试 Cookie、演示内网 IP、Debugger.Break() 这种"生产环境一执行就挂起"的雷。

之后我提了个要求：文档统一收到项目 docs/ 目录，后续按 Obsidian 风格管理。它就把文档全部改造成了带 YAML frontmatter、[[wikilink]] 互链、#标签、MOC 主页的结构，docs/ 目录直接就能当 Obsidian vault 打开。

第二阶段：目标驱动的重构

文档阶段只是热身。真正让我觉得"惊艳"的，是下一步。

我把 AutoDeploy-改进优化建议.md 里的 21 条改进定成了一个长期目标交给它（图 10——对话里直接 /goal 完成 AutoDeploy-改进优化建议.md 里列出的内容，它会创建一个带回合计数（Rounds）的持久目标，然后进入多轮自主执行）：

完成 AutoDeploy-改进优化建议.md 里列出的内容

然后它开启了一个最多 256 轮的多轮自主执行模式。我大致在旁边记录了一下它的动作序列：

它做了什么

类别	具体动作
框架升级	net6.0 → net8.0（LTS），Coravel 4.2→5，Hosting 7→8
安全	硬编码 SMTP 密码/邮箱/内网地址全部外置到 appsettings.json + 环境变量；下载包新增 SHA256 强制校验
安全	构建时发现 SharpCompress 0.32.2 有已知漏洞告警（GHSA-6c8g-7p36-r338），主动升级到 0.48.0
可靠性	新增失败自动回滚（解压/启动失败时从最近备份恢复站点并邮件告警）
可靠性	修复 -subpath 仅传文件时 _temp 漏备份的静默 bug
可靠性	Serilog 日志、邮件失败重试、IIS 启停等待目标状态、磁盘空间预检
可维护性	状态机枚举化、参数解析重写（带 --help）、配置三来源合并、死代码清理
功能增强	发布后健康检查、备份保留策略、deploy-status.json + HTTP API、多目标选择、-headless/-service/-monitor-only
测试	新增 xunit 测试项目，42 个用例

几个亮点展开说：

1. 它自己写的 bug，被它自己的测试抓出来。 重构时它把 -file 参数映射到了一个没被读取的属性上（VersionIndexUrl vs Monitor.IndexUrl），导致"配了参数却不生效"。启动校验直接拦下报错，它定位后修复，还专门补了一条回归测试用例。这个过程和我们平时开发没什么两样：写代码 → 冒烟测试 → 发现问题 → 修 → 补测试。

2. 它自己搭环境做端到端验证。 为了验证整条流水线，它在本地起了一个 mock HTTP 服务器（模拟版本索引 + 更新包），搭了一个假发布目录，然后看着日志：下载（SHA256 通过）→ 停站（跳过）→ 备份 → 解压覆盖 → 通知，6 秒跑完全流程。接着又故意放一个损坏的压缩包验证回滚：日志里清清楚楚地出现

[ERR] 步骤 decompress 执行失败
[WRN] 开始执行回滚...
[INF] 回滚：解压备份 v.rollback.2026_1010155582.zip → ...\site
[WRN] 回滚完成（已恢复 1 个备份包）

最后 deploy-status.json 里 "LastResult": "rollback"，站点文件被恢复成旧版本。这种"自己给自己验收"的能力，比单纯生成代码有用得多。

3. 它知道什么时候该查资料。 升级 SharpCompress 后 API 大改（Open 变 OpenArchive、Create 变 CreateArchive），编译报错。它没有瞎猜，而是去 NuGet 缓存里用反射把新 DLL 的公开方法列出来，确认新签名后改代码，一次通过。遇到 NuGet 版本冲突（NU1605）、漏洞告警（NU1902）这类问题也都是自己处理。

小坑集锦

1. Agent 的测试脚本也会挂起。 它用 PowerShell 的 Start-Job 跑 mock 服务器，结果整个脚本超时卡死，连输出都截断了。它很快换成工具自带的后台任务方式绕过去。期间我还问了一句"卡住了？“——其实它没卡，是在等我下一步指令。跟 Agent 协作，要理解它的节奏：它干完一个阶段会停下来等你说"继续”。
2. 控制台输出中文乱码。 第一次冒烟测试时它打印的错误信息全是 GBK 乱码，差点误判。后来发现真相在 Serilog 日志文件里，而不是 stdout。排查 Agent 的问题，和排查人的问题一样：先看日志。
3. 配置"三层来源"合并的坑。 命令行 > 环境变量 > appsettings.json，优先级本身不难，但"字段映射错位"这种低级错误，没有启动校验和单元测试兜底的话，上线才会炸。

一些体会

惊艳在哪？ 不是它回答了一个很难的问题，而是它完成了一个完整的闭环：读代码 → 写文档 → 立目标 → 多轮自主重构 → 自测 → 修复自己引入的 bug → 端到端验收 → 更新文档。整个过程我只需要做三件事：下目标、看结果、做安全决策（比如"更换邮箱授权码"这种必须人工执行的动作，它不会替你去做，只会明确标出"运维必做"）。

DSH 和聊天式 AI 的区别，用我自己的话说：聊天式 AI 是"顾问"，问一句答一句；DSH 更像"远程实习生"——给它一个明确的目标（还能挂后台、最多 256 轮自主推进、必要时派子代理并行干活），它会持续工作并汇报。工具链里除了终端和文件读写，还有代码搜索、网页搜索、后台任务、技能库（git 工作流、变更记录、阿里云百炼系列等），基本覆盖了一个开发者日常要用的东西。

当然也有边界。 目标要定义清楚：“完成改进建议里列的内容"这种目标它执行得很好；但如果你自己都不知道想要什么，指望它替你拍板，那体验会打折扣。另外 P3 里有一条"多服务器编排"它评估后明确标注为"部分实施”——它知道自己能力的边界，这个诚实度我很喜欢。

成本：这单"大活"只花了 7 毛钱

最后聊聊大家最关心的成本。上面这一整套流程——读代码、写文档、21 项改进的 net8 重构、42 个单元测试、端到端验证——任务量说实话不算轻松，换成人来做，怎么也是 1~2 个开发日的活。那 DSH 花了多少钱？

答案是：7 毛多（图 11，DeepSeek 官方用量账单）：

从账单看，本次会话总共消耗了约 2700 万 token、300 余次 API 请求（deepseek-v4-flash），而实际计费只有 ¥0.77。能便宜到这个程度，关键在两点：

1. 上下文缓存：从结果看，本次大部分输入基本都命中了 DeepSeek 的上下文缓存——代码、文档、历史对话在多次工具调用间被反复读取，命中缓存的部分几乎按成本价计费。这是"重活不重费"的核心原因；
2. 模型单价低：deepseek-v4-flash 这类模型本身定价就低，任务量再大，单价摆在那里，总额也上不去。

所以即便后续 DeepSeek 调整售价，按这个"高缓存命中"的用量结构，费用也不会过于离谱，成本优势依然遥遥领先。7 毛钱换来的是一份完整的功能文档 + 21 项风险清单 + 一套可运行的 net8 重构代码 + 42 个测试——这笔账怎么算都划算。

总结

如果你手头也有这种"年头长、没人敢动、文档缺失"的老项目，我强烈建议用 DSH 先做一次"体检+手术"：让它先读代码、写文档、列改进清单，再挑一个明确目标让它落地。整个过程最有价值的产出，可能不是那些代码改动，而是那份文档和风险清单——它把"这个项目到底怎么工作的、哪里埋着雷"这件事，从某个离职同事的脑子里，搬到了你们团队的仓库里。

好了，基本就是这些，回到文章开头，我对 DSH 的第一印象就是惊艳，期待后续的 CLI 版本。

注意，本篇 90% 的内容是在 DSH 工具中输出，笔者只是将利用 DSH 完成上述 auto deploy 项目的优化，并在当前上下文提供了一些截图素材，然后就是做了一些校验和细节调整，最后得到了本篇的全部内容。