你应该知道 dsh 和 claude/codex/cursor 当前有哪些会影响生产的小区别

[meiyingda1]

1. 对于dsh来说mcp是全局的，目前应该没有claude 这样可以在工作目录里设置专属mcp的能力，如果你期望dsh加载只属于本项目的特殊mcp 这里要单独处理， --patch ./dsh.patch.yml 这个参数要记得用上
2. dsh 目前应该没有指定 system-prompt的功能， 是核心不支持没暴露 还是没有考虑这个问题要再看一下源码
   如果你用python/ js 等脚本来编排智能体，这个地方要特别小心，很容易就丢弃了你的 system-prompt信息，特别是claude用户
3. dsh 目前的 headless 模式，并不支持 --resume 参数，也就说无法简单的恢复对话持续执行，这个也是非常缺少的能力
   同样也是对python编排智能体的方法来说比较难受，这意味着你需要自己管理对话历史，不过这个应该可以自己修改代码实现

[meiyingda1]

https://github.com/PandaColour/panda-pipline 如果你看不懂我在说什么，你可以看看我这个项目，看看我是怎么调度claude codex 和 cursor 的

[weijiafu14]

三条我逐条说，因为它们的处境很不一样 —— 第 1 条今天就能解，第 2 条机制在但没现成包，第 3 条确实是官方 CLI 的事。

1. MCP 是全局的、没有项目专属 —— 今天能解

不用只靠 --patch。社区已经有好几个 MCP 管理插件，其中带项目层 / 全局层分开的配置面是可以直接用的（我维护的 dsh-work-x 里那个 Web MCP 管理页就是两层：项目层写工作区里的配置，全局层写用户级的，界面上分组显示）。只想要 MCP 入口不想装一整套的话，npm 上 dsh-mcp-manager 一族有好几个专做这件事的。

配置分层本身是 MCP 生态的既有约定（项目目录里的 .mcp.json 优先于用户级），所以这条不是 DSH 特有的难题，是入口没做而已。

2. 指定 system-prompt —— 核心支持，只是没暴露成用户入口

你猜的方向是对的，我核过：DSH 的 system-prompt/assemble 是一条 async waterfall，装配时执行、返回值权威、当轮生效。也就是说提示词的最终形态在这里定，插件挂上去就能整段替换或改写 —— 我在真 DSH 上验过这条链路（我们拿它承接 Pi 的 before_agent_start 覆写）。

但如实说：没有现成的包让你"配一个 system prompt 就完事"。 npm 上搜到的 dsh-system-prompt 全是官方那个装配注册表的 fork，不是用户面的东西。要用就得自己写个小插件挂 assemble，或者等有人写。

对你脚本编排的场景还有个更要命的点：这条 waterfall 在服务端跑，你从外面用 python/js 调的时候看不见它，所以"编排时不小心丢了 system-prompt"这个坑，插件侧补不回来——得在你的编排层保证。

3. headless 没有 --resume —— 这条我们帮不上

那是官方 CLI 的参数面，不是插件能加的。你说的"自己管理对话历史"是目前唯一的路。

（顺带：会话本身是持久化的、有稳定 id，DSH 也有公开的会话查询服务，所以"恢复"这件事在服务端是有数据基础的；缺的是 CLI 那个开关。这不改变结论，只是说明它是入口问题不是能力问题。）

---

利益相关：我维护 pi2dsh 和 dsh-work-x。我们不修 DSH 自家的组件，上面第 1 条给的是并排的另一条入口，第 3 条我明确给不了。

你那个 panda-pipline 我去看了下调度思路 —— 如果你要在 DSH 上做同一件事，第 2 条那个 assemble waterfall 大概是你最需要的抓手，值得单独提一个 feature request 要官方把它暴露成配置项。