[分享] Windows上DSH的使用方式 (解决PowerShell疯狂报错)

本贴主要分享我目前在 Windows 上使用 DeepSeek Harness（DSH）的一套配置方式。

核心思路很简单：

不再让 Agent 使用 DSH 自带的 Bash / PowerShell 工具，而是统一通过 FastCtx 本地MCP工具去调用 Git Bash。

这样可以避开 Windows 下非常烦人的 PowerShell 语法、转义、路径以及 Bash/PowerShell 混用问题，也可以避免模型浪费注意力在拼Bash命令上

我的DSH环境

目前使用版本：```
DSH: 0.1.2-rc.1
Windows 11
Shell: Git Bash
FastCtx: 0.2.5
```我同时使用：

- dsh web

- dsh-tui (解锁Herdr、Orca的Agent Team场景)

两套 Profile。

需要注意，DSH 的插件是按 Profile 管理的，所以 Web 和 TUI 使用的插件需要分别安装到对应 Profile。dsh plugin --profile <name> add <package> 本质上就是往指定 Profile 中安装依赖。

一、我目前安装的插件

1. dsh-tui

我的 TUI Profile：```
dsh-tui
│
│ dependencies:
├── @anysearch/[email protected]
├── @deepseek-ai/[email protected]
├── @deepseek-harness-tui/[email protected]
└── @nanmicoder/[email protected]
```对应推荐理由：

插件 |
推荐理由 |

@anysearch/[email protected] |
每天免费搜索 1000 次，日常联网搜索够用了 |

@deepseek-ai/[email protected] |
关键插件，用于接入 FastCtx 等 MCP 工具 |

@deepseek-harness-tui/[email protected] |
TUI 爱好者狂喜 |

@nanmicoder/[email protected] |
权限管理，减少频繁确认 |

安装方式：```
dsh plugin --profile dsh-tui add @anysearch/[email protected]
dsh plugin --profile dsh-tui add @deepseek-ai/[email protected]
dsh plugin --profile dsh-tui add @deepseek-harness-tui/[email protected]
dsh plugin --profile dsh-tui add @nanmicoder/[email protected]

2. dsh web

Web Profile：```
web
│
│   dependencies:
├── @anysearch/[email protected]
├── @deepseek-ai/[email protected]
├── @nanmicoder/[email protected]
├── [email protected]
└── [email protected]
```对应推荐理由：

插件 |
推荐理由 |

`@anysearch/[email protected]` |
每天免费搜索 1000 次 |

`@deepseek-ai/[email protected]` |
**关键插件**，负责连接 FastCtx MCP |

`@nanmicoder/[email protected]` |
权限管理 |

`[email protected]` |
改善侧边栏状态显示 |

`[email protected]` |
DSH 插件市场，安装、查看、管理插件方便很多 |

安装：```
dsh plugin --profile web add @anysearch/[email protected]
dsh plugin --profile web add @deepseek-ai/[email protected]
dsh plugin --profile web add @nanmicoder/[email protected]
dsh plugin --profile web add [email protected]
dsh plugin --profile web add [email protected]

二、为什么我要折腾 FastCtx？

这其实才是本文的重点。

在 Windows 上使用 DSH 时，一个比较让人头疼的问题就是 PowerShell

模型写代码的时候，大量命令天然更偏向 Bash 使用习惯。

但是 Windows 下 DSH 默认 Shell 体系更偏 PowerShell。

于是很容易出现这种情况：

模型拼Bash命令 → 实际运行的是PowerShell(报错) → 转义(修复) → 路径(报错) →
路径(修复) → …

这些东西混合在一起以后，非常容易浪费大量 Token 在修 Shell 命令 而不是解决真正的问题。

DSH 官方本身在 Windows 平台默认也是 PowerShell，但是模型真不会写好 PowerShell。

所以我的解决方法是：不用 PowerShell。

三、我的最终方案

我的方案是：```
DSH
│
├── 内置 bash ❌ 禁用
│
├── 内置 PowerShell ❌ 禁用
│
└── MCP
│
└── FastCtx
│
├── inspect_local_file
├── grep
├── glob
├── replace
│
└── run
│
└── Git Bash
```最终所有终端命令：

Agent → FastCtx MCP → FastCtx run → Git Bash → Windows

因此 Agent 只需要写：```
pwd
ls
grep
git status
pnpm install
npm test
```模型完全按照标准 Bash 去写即可。

FastCtx 在 Windows 下的 Bash 执行本身就是通过 Git Bash 完成的。

四、先创建一个自定义模式

我个人建议不要直接乱改 DSH 的默认模式。

创建一个专门用于 FastCtx 的自定义模式。

核心只有一个要求：

把 DSH 自带的 shell tool 全关掉。

也就是将：```
tool-bash
tool-pwsh
```设置为禁用。

配置中的核心效果相当于：```
tool-bash:
disabled: true

tool-pwsh:
disabled: true
``如果你当前使用的 UI 中显示的是 disable` 开关，那么直接把 Bash 和 PowerShell 两项都关闭即可。

这里之所以两个都禁用，是因为：

后面所有 Shell 命令全部交给 FastCtx 的 run。

这样可以避免模型同时看到：```
bash
pwsh
mcp__fastctx__run
```然后随机挑一个执行。

我的目标非常明确：```
Shell 只有一条路：

FastCtx → Git Bash

五、安装 FastCtx

FastCtx 本身安装非常简单。

需要 Node.js 18+。

执行：```
npm install --global fastctx
```如果 npm 镜像同步不及时导致 404，可以临时使用官方 npm registry：```
npm install --global fastctx --registry=https://registry.npmjs.org/
```安装完成后：```
fastctx
```即可进入 FastCtx 的配置界面。FastCtx 官方也提供这种全局 npm 安装方式。

---

六、开启 FastCtx 的 Bash 能力

FastCtx 默认主要提供文件相关能力，例如：```
inspect_local_file
grep
glob
replace
```而我们这套方案还有一个非常重要的需求：```
让 FastCtx 接管终端
```因此需要启用 Bash Terminal。

FastCtx MCP 启动方式使用：```
fastctx serve --enable-shell
```启用后除了文件工具以外，还会有：```
run
run_background
job_output
job_kill
job_list
```其中最重要的就是：```
run
```**因为以后普通终端命令基本全部通过它执行。**

---

七、把 FastCtx 注册到 dsh-mcp-client

这里需要：```
@deepseek-ai/dsh-mcp-client
```这也是为什么前面我把它标为**关键插件**

官方 `dsh-mcp-client` 的作用就是：

外部 MCP Server → dsh-mcp-client → 注册到 DSH ctx.tools → Agent调用

注册成功以后，FastCtx 最终会变成：```
mcp__fastctx__inspect_local_file
mcp__fastctx__grep
mcp__fastctx__glob
mcp__fastctx__replace
mcp__fastctx__run
mcp__fastctx__run_background
mcp__fastctx__job_output
mcp__fastctx__job_kill
mcp__fastctx__job_list
```这是 `dsh-mcp-client` 官方定义的 MCP 工具注册方式。

---

FastCtx MCP 配置

在对应 Profile 的：```
cordis.patch.yml
```中添加一个 MCP Client 实例。

例如：```
- insert:
    - id: mcp-fastctx
      name: '@deepseek-ai/dsh-mcp-client'
      config:
        serverName: fastctx
        transport: stdio
        command: 'C:/Users/asus/.fastctx/bin/fastctx.exe'(自己的fastctx路径)
        args:
          - serve
          - --enable-shell
        cwd: !!js process.cwd()
        env:
          FASTCTX_BASH: 'F:/Git/bin/bash.exe'(自己的GitBash路径)
        toolCallTimeoutMs: 300000
        failOnStartupError: false
```核心其实只有：```
serverName: fastctx
transport: stdio
command: fastctx
args:
  - serve
  - --enable-shell
```也就是让 DSH 启动：```
fastctx serve --enable-shell
```官方 `dsh-mcp-client` 的 stdio 配置也是通过 `serverName / transport / command / args / env / cwd` 这一套参数启动 MCP Server。

---

八、Web 和 TUI 都要配置

这里容易踩坑，如果你同时使用**dsh web、dsh-tui**

它们属于不同 Profile。

所以 ~/.dsh/profiles/web/ 和 ~/.dsh/profiles/dsh-tui/ 是两套配置

也就是都需要注册：```
Web
 └── @deepseek-ai/dsh-mcp-client
      └── FastCtx

TUI
 └── @deepseek-ai/dsh-mcp-client
      └── FastCtx
```否则很容易出现：```
Web 能用 FastCtx
TUI 看不到
```或者反过来。

---

九、配置 `.dsh/AGENTS.md`

光安装 FastCtx 还不够。

因为模型同时可能知道很多读取文件的方法，比如：```
cat
Get-Content
grep
Select-String
findstr
dir
ls
```所以我还会在 ~/.dsh/AGENTS.md 中明确告诉 Agent：

> 本地文件和 Shell 操作优先使用 FastCtx。

我现在使用的是下面这段：```
<!-- fastctx:begin -->
## Local file inspection

For reading, searching, and finding local files, prefer the FastCtx MCP
server's own tools — `inspect_local_file`, `grep`, and `glob` — over shell
equivalents such as `cat`/`Get-Content`, `rg`/`findstr`/`Select-String`,
and `dir`/`ls -R`.
Use FastCtx file tools directly for local-file operations, including when a
local reference is URI-shaped; pass the equivalent plain absolute filesystem path.
Read only what the task needs. When you need several files, pass them to
one `inspect_local_file` call as files=[{"path": ...}, ...] instead of one
call per file. The last line of every result says `Complete` or
`Partial` — continue only with the exact parameters a `Partial` note
provides.

### Batch replacement

Use FastCtx's `replace` for mechanical find-and-replace across files.
It preserves each file's encoding and line endings, supports dry-run previews,
and rejects concurrent changes before writing. Use apply_patch for generated
content, semantic rewrites, or small local edits.

### Shell commands

Prefer FastCtx's `run` over the built-in shell for terminal work: it
executes with bash (Git Bash on Windows), so always write POSIX bash —
never PowerShell syntax.

Never pass `apply_patch` to FastCtx's `run`: it is not a program and
no shell can run it. Reach it through Codex itself — as its own tool
call, or in Codex's built-in shell — never through the FastCtx tools.

Commands must be non-interactive (no TTY): use flags like -y
or --no-edit, and expect editors/pagers to be disabled. For anything
that may outlast run's four-minute maximum, use `run_background`, check
on it with `job_output`, and stop it with `job_kill`. Background jobs run
independently of this session and survive restarts; rediscover an earlier
job with `job_list` and read its output by job_id. A non-zero exit code is
a normal result. The last line of every result says `Complete` or
`Partial`.
<!-- fastctx:end -->
```这段提示词主要解决三件事情。

1. 文件读取不要再绕 Shell

优先：```
inspect_local_file
grep
glob
```而不是：```
cat
grep
find
```更不要在 Windows 上变成：```
Get-Content
Get-ChildItem
Select-String

2. 批量替换使用 FastCtx replace

比如全项目机械替换：AAA → BBB，其实可以交给 replace 这种结构化工具处理

而真正需要理解代码语义的修改，再让 Agent 使用专门的 Patch/Edit 工具。

3. Shell 永远按照 Bash 写

这是最关键的一句：```
always write POSIX bash — never PowerShell syntax
``从此这些命令都按照标准 Bash 来：``
&&
||
grep
find
rm
cp
mv
sed
awk
``不再考虑PowerShell的命令：``
Get-ChildItem
Get-Content
Select-String
Remove-Item
Copy-Item

十、怎么确认 真的跑的是 Git Bash？

配置完成以后，以下提示词发给 DSH：

调用 mcp__fastctx__run 工具并执行：```
echo "BASH=$BASH"
echo "BASH_VERSION=$BASH_VERSION"
echo "MSYSTEM=$MSYSTEM"
which bash
pwd
```正常情况下 Windows + Git Bash 应该能看到类似：```
BASH=/usr/bin/bash
BASH_VERSION=5.x.x
MSYSTEM=MINGW64
/usr/bin/bash
/c/Users/xxx
```看到 **MSYSTEM=MINGW64** 和 **/usr/bin/bash**

基本就能确认：

> **现在真的跑在 Git Bash，而不是 PowerShell。**

---

十一、最终效果

以前：```
Agent -> PowerShell -> 命令语法错误 -> 修转义 -> 路径错误 -> 再修 -> 继续报错
```现在：```
Agent -> FastCtx -> Git Bash ->正常执行
```同时文件操作也变成：```
读文件       → inspect_local_file
搜索内容     → grep
搜索文件     → glob
机械替换     → replace
运行命令     → run
长时间任务   → run_background
后台输出     → job_output
终止任务     → job_kill
找回后台任务 → job_list
```整个工具边界会清晰很多。

---

十二、总结

**DSH 负责 Agent，FastCtx 负责本地文件和 Shell，Windows 终端统一使用 Git Bash**

这样配置以后，Windows 上使用 DSH 的体验会干净很多，尤其是再也不用看 Agent 和 PowerShell 的转义规则互相折磨 ^-^