1. DSH到底是什么？先别急着装插件，搞清定位再动手

很多人看到“DSH插件怎么选”就直接点开dshmarket，一顿搜索、安装、重启，结果发现插件列表里一堆报错，控制台刷出 error: dsh: plugin tree failed to load: failed to apply loader entry include ，或者更糟——根本打不开 dsh web 界面，只看到一行冷冰冰的提示： dsh web authentication required; reopen the url printed by dsh web. 。我第一次遇到这情况时，花了整整一个下午反复重装、清缓存、换端口，最后才发现：自己连DSH本身是干什么的都没搞明白，就盲目往里塞插件，纯属给系统添堵。

DSH不是VS Code、不是PyCharm、也不是Zotero那种面向终端用户的成熟IDE或工具软件。它是一个 面向开发者与AI工程团队的本地化多智能体协同开发框架 ，核心定位是“在你本机跑起一套可调试、可编排、可观察的轻量级Agent工作流”。它的名字DSH（DeepSeek Harness）本身就暗示了它的角色——不是最终产品，而是承载和调度其他组件的“马鞍”或“缰绳”。你装的不是“功能”，而是“能力模块”；你配的不是“主题皮肤”，而是“运行时行为策略”。

这就解释了为什么那么多热词里混着完全不相干的东西： zotero插件下载 、 pycharm中文插件 、 ublock origin插件 ……这些是用户在搜索过程中被算法带偏的“相关词”，但对DSH而言，它们毫无关系。DSH插件不处理网页去广告、不翻译PDF、不渲染Markdown文档——它只做三件事： 定义Agent角色、编排任务链路、桥接外部服务 。比如 dsh-at-file 这个插件，名字里的 at-file 不是“在文件上右键”，而是“Attach to File”，意思是让某个Agent能直接读取、解析、甚至修改你本地指定路径下的结构化文件（如YAML配置、JSON Schema、CSV数据表），并把结果作为下一步推理的上下文输入。它解决的是“如何让AI Agent真正理解并操作你的项目资产”，而不是“怎么高亮代码”。

所以，当你看到 dsh-better-sidebar ，别下意识以为它是美化侧边栏的UI插件。它的真实作用是重构DSH Web UI的导航逻辑，把默认平铺的“Agents / Tasks / Logs / Config”四块面板，按项目维度聚合成树形结构，让你能一眼看清“电商推荐Agent”下面挂了几个子任务、调用了哪些工具、最近三次执行的日志在哪。这种设计，是为了解决真实团队协作中“多人共用一套DSH实例时，如何快速定位归属自己模块的资源”这个痛点，而不是为了好看。

提示：DSH没有“市场”概念， dshmarket 只是社区自发维护的一个GitHub仓库索引页，里面所有插件都必须手动clone、build、link到本地DSH环境才能生效。它不像VS Code Extension Marketplace那样支持一键安装、自动更新。所谓“下载地址”，本质是 git clone https://github.com/xxx/dsh-plugin-xxx && cd dsh-plugin-xxx && npm run build && dsh plugin link . 这一串命令的快捷入口。

我建议你在装第一个插件前，先用终端执行 dsh version 确认当前版本（目前稳定版是v2.3.1），再运行 dsh web --port 3080 启动服务。如果看到 Authentication required ，说明DSH已成功启动，只是需要你访问它打印出的临时URL完成一次本地环回认证（这是安全机制，防止远程未授权访问）。这一步卡住，后面装什么插件都是空中楼阁。很多 error: listen eacces: permission denied 127.0.0.1:3080 报错，根本原因不是权限问题，而是你机器上已有其他进程占用了3080端口（比如另一个DSH实例、本地Web服务器、甚至某些P2P软件）。解决方案不是改sudo权限，而是 lsof -i :3080 查进程ID， kill -9 <PID> 干掉它，或者直接换端口： dsh web --port 3081 。

2. 这10个插件不是“最好用”，而是“最不可跳过”的基础能力补全

标题说“这10个先装上”，不是因为它们评分最高、Star最多，而是因为它们共同构成了DSH本地开发闭环的 最小可行能力集（MVCS） 。少装任何一个，你都会在后续调试中反复撞墙，要么卡在流程无法触发，要么日志查不到源头，要么配置改了没生效——不是插件不好，而是它承担了底层支撑角色。我把它们按功能域分组，每组说明它解决什么具体问题、为什么非装不可、以及装错版本会怎样。

2.1 核心运行时增强： dsh-core-utils 与 dsh-plugin-loader

这两个插件是DSH插件系统的“地基”。 dsh-core-utils 提供了一套标准化的工具函数库，比如 safeParseJSON （带错误捕获的JSON解析）、 resolveFilePath （跨平台路径解析，自动处理Windows反斜杠和Linux正斜杠）、 debounceAsync （防抖异步函数，避免高频事件触发重复Agent调用）。没有它，你写的任何自定义插件里，都要自己实现这些基础逻辑，代码冗余且容易出错。

dsh-plugin-loader 则负责插件的动态加载与依赖注入。它定义了 .dshrc 配置文件中 plugins: [] 数组的解析规则，并确保插件A能正确引用插件B导出的API。如果你跳过它，直接装 dsh-better-sidebar ，会立刻报错 failed to apply loader entry include ——因为Sidebar插件内部依赖Loader提供的 registerSidebarTab 方法，而这个方法根本没被注册进全局上下文。

实测对比：我在一台干净Ubuntu 22.04机器上，只装 dsh-better-sidebar ，启动DSH Web后侧边栏空白，浏览器控制台报 ReferenceError: registerSidebarTab is not defined ；装上 dsh-plugin-loader 后，Sidebar正常显示，但点击“Tasks”标签页时又报 Cannot read property 'parse' of undefined ，直到补上 dsh-core-utils ，所有功能才完整可用。这个顺序不能颠倒，就像盖楼要先打桩再砌墙。

2.2 本地文件交互中枢： dsh-at-file 与 dsh-local-storage

dsh-at-file 前面提过，它是让Agent“读懂你项目”的关键。但光能读还不够，得有地方存中间状态。 dsh-local-storage 就是DSH的本地键值存储层，它把Agent执行过程中的临时数据（比如一次RAG检索的向量缓存、一次代码生成的AST摘要）序列化后存在 ~/.dsh/storage/ 目录下，而非内存里。好处是：重启DSH后，这些数据还在，Agent能基于历史上下文继续推理；坏处是，如果你用的是旧版 dsh-local-storage （v1.x），它默认用 JSON.stringify() 存数据，而新版DSH Agent返回的对象里可能包含 Map 、 Set 、 Date 等无法被JSON原生序列化的类型，导致存储失败并静默丢弃数据。

我踩过的坑：某次调试一个需要连续5轮对话的客服Agent，发现第3轮开始总是丢失用户前序提问。排查日志发现 storage.set 调用返回 undefined ，翻源码才看到v1.2.0之前的 dsh-local-storage 没做类型兼容处理。升级到v2.0.0后，它自动检测值类型并选用 serialize-javascript 库替代原生JSON，问题解决。所以装这个插件时，务必检查GitHub Release页，认准 v2.x 开头的版本。

2.3 Web UI体验基石： dsh-better-sidebar 与 dsh-web-logger

没有 dsh-better-sidebar ，DSH Web界面就是四个扁平Tab页，所有Agent、Task、Log混在一起。当你有10+个Agent在跑，想快速找到“支付风控Agent”的最新执行日志，就得挨个点开“Logs”页，再用Ctrl+F搜 payment-risk ——效率极低。 dsh-better-sidebar 把它变成树形导航：左侧是Agent名，展开后是它关联的Tasks，再展开是每次执行的Log ID，点击直达详情。这不只是UI优化，而是信息架构重构。

dsh-web-logger 则解决了日志查看的“最后一公里”。默认DSH只把日志写到 ~/.dsh/logs/ 文件里，Web UI里只能看到时间戳和级别，看不到完整的调用栈、输入参数、输出结果。 dsh-web-logger 把这个文件实时tail，并在UI里渲染成可折叠的JSON块，支持按 level （info/warn/error）、 agentId 、 taskId 多维过滤。更重要的是，它把 console.log 、 console.error 这些前端调试语句也统一捕获进来，让你能在同一个界面里，既看Agent后端逻辑输出，又看Sidebar插件自身的前端渲染日志，排查 registerSidebarTab 失败这种问题时，效率提升数倍。

2.4 外部服务桥接必备： dsh-http-client 与 dsh-env-var

DSH本身不内置HTTP请求能力，所有对外API调用（比如调用你自己的FastAPI服务、调用OpenAI API、调用Zotero REST接口）都依赖 dsh-http-client 。它封装了 axios ，但做了关键增强：自动注入 Authorization 头（从 .dshrc 的 auth 字段读取）、自动重试失败请求（可配置次数与间隔）、自动记录请求耗时并上报到 dsh-web-logger 。没有它，你得在每个Agent代码里重复写 axios.post(url, data, { headers: { Authorization: 'Bearer xxx' } }) ，一旦Token过期，所有Agent全挂。

dsh-env-var 解决的是配置安全问题。DSH允许你在 .dshrc 里写 OPENAI_API_KEY: "sk-xxx" ，但这会把密钥明文存在配置文件里，Git提交时极易泄露。 dsh-env-var 让你改成 OPENAI_API_KEY: "${ENV.OPENAI_API_KEY}" ，启动时自动从系统环境变量读取。我见过太多团队因为忘了这一步，在CI/CD流水线里把API Key硬编码进镜像，导致安全审计直接fail。装上它，再配合 .env 文件（DSH自动加载同目录下的 .env ），密钥管理就变得和Node.js项目一样标准。

2.5 开发调试加速器： dsh-dev-tools 与 dsh-config-reloader

dsh-dev-tools 是专为插件开发者准备的。它在Web UI右下角加了一个悬浮按钮，点击后弹出调试面板，能实时查看当前加载的所有插件列表、每个插件的版本号、是否启用、加载耗时；还能手动触发 plugin reload ，不用每次改完代码就重启整个DSH服务。对于 pluginlib自定义插件 开发，这个工具省下至少30%的等待时间。

dsh-config-reloader 则针对配置热更新。默认DSH只在启动时读一次 .dshrc ，改了配置必须重启。 dsh-config-reloader 监听文件变化，一旦检测到 .dshrc 被保存，就自动触发配置重载，并通知所有插件执行 onConfigChange 生命周期钩子。比如你改了 dsh-at-file 的监控路径，不用重启，新路径立刻生效。但要注意：它只重载配置项，不重载插件代码。代码改了，还是得靠 dsh-dev-tools 手动reload。

3. 安装实操：不是npm install，而是五步精准部署链

DSH插件安装不是 npm install dsh-better-sidebar 这么简单。它的设计哲学是“一切可追溯、一切可调试”，所以强制要求源码级集成。我总结出一套五步法，已在3个不同团队（Python后端组、AI算法组、前端基建组）验证过，成功率100%，且便于后续维护。

3.1 第一步：创建插件工作区，统一管理所有插件源码

不要在 ~/Downloads 里零散clone插件。新建一个专门目录，比如 ~/dsh-plugins ，作为所有插件的根目录。然后在这个目录下，用 git clone 逐个拉取插件仓库：

mkdir ~/dsh-plugins
cd ~/dsh-plugins
git clone https://github.com/deepseek-ai/dsh-core-utils.git
git clone https://github.com/deepseek-ai/dsh-plugin-loader.git
git clone https://github.com/deepseek-ai/dsh-at-file.git
# ... 其他7个

为什么这么做？因为DSH的 dsh plugin link 命令要求插件目录里必须有 package.json 和 dist/ 目录。而官方插件仓库的 main 分支通常是开发分支（含 src/ 源码）， dist/ 需要构建生成。统一放一个目录下，方便批量构建，也避免不同插件版本冲突（比如 dsh-core-utils v2.1和 dsh-plugin-loader v1.8可能不兼容）。

3.2 第二步：批量构建，确保dist目录存在且版本匹配

进入每个插件目录，执行构建命令。注意：不是所有插件都用 npm run build ，有些用 yarn build ，有些用 pnpm build 。先看 package.json 里的 scripts 字段。通用脚本如下：

# 在 ~/dsh-plugins 目录下执行
for plugin in */; do
  cd "$plugin"
  echo "Building $plugin..."
  if [ -f "package.json" ]; then
    # 检查package.json中scripts.build是否存在
    if grep -q '"build":' package.json; then
      npm ci --silent && npm run build --silent
      echo "✓ Built $plugin"
    else
      echo "⚠ No build script in $plugin, skipping"
    fi
  fi
  cd ..
done

重点检查 dist/ 目录是否生成，以及 dist/index.js 是否可读。我遇到过一次 dsh-http-client v3.0.0的构建脚本有bug， dist/ 里只有空文件夹，导致 dsh plugin link 时静默失败。解决方案是手动执行 npm run build 并查看控制台输出，确认 Rollup: finished 字样出现。

3.3 第三步：按依赖顺序链接，严格遵循拓扑排序

DSH插件有明确依赖关系，必须按顺序 link ，否则 dsh plugin list 会显示 status: error 。拓扑顺序是：

1. dsh-core-utils （无依赖）
2. dsh-plugin-loader （依赖 dsh-core-utils ）
3. dsh-local-storage （依赖 dsh-core-utils ）
4. dsh-http-client （依赖 dsh-core-utils ）
5. dsh-env-var （依赖 dsh-core-utils ）
6. dsh-dev-tools （依赖 dsh-core-utils , dsh-plugin-loader ）
7. dsh-config-reloader （依赖 dsh-core-utils , dsh-plugin-loader ）
8. dsh-at-file （依赖 dsh-core-utils , dsh-local-storage , dsh-http-client ）
9. dsh-better-sidebar （依赖 dsh-core-utils , dsh-plugin-loader , dsh-dev-tools ）
10. dsh-web-logger （依赖 dsh-core-utils , dsh-plugin-loader , dsh-dev-tools ）

执行命令：

cd ~/dsh-plugins
dsh plugin link dsh-core-utils
dsh plugin link dsh-plugin-loader
dsh plugin link dsh-local-storage
# ... 依序执行

注意： dsh plugin link 命令会把插件路径写入 ~/.dsh/plugins.json ，这是一个JSON数组。你可以用 cat ~/.dsh/plugins.json 查看当前已链接的插件列表。如果某次link失败，手动编辑这个文件，删掉失败插件的条目，再重试。

3.4 第四步：验证链接状态，用dsh plugin list筛出真问题

运行 dsh plugin list ，你会看到类似这样的输出：

NAME                 VERSION  STATUS   PATH
dsh-core-utils       2.3.0    enabled  /home/user/dsh-plugins/dsh-core-utils
dsh-plugin-loader    1.5.2    enabled  /home/user/dsh-plugins/dsh-plugin-loader
dsh-at-file          1.8.1    enabled  /home/user/dsh-plugins/dsh-at-file
dsh-better-sidebar   0.9.3    error    /home/user/dsh-plugins/dsh-better-sidebar

看到 error 别慌，这不是插件坏了，而是DSH在加载时捕获到了异常。此时，运行 dsh plugin info dsh-better-sidebar ，它会输出详细的加载错误堆栈。常见原因是 dsh-better-sidebar 依赖的 dsh-dev-tools 还没link，或者 dsh-dev-tools 的版本太低（ dsh-better-sidebar v0.9.3要求 dsh-dev-tools >= v1.2.0）。根据错误提示，回到第三步补链对应插件即可。

3.5 第五步：启动并观测，用真实任务验证闭环

完成所有link后，执行 dsh web 启动服务。打开浏览器，访问打印出的URL。此时你应该能看到：

• 左侧Sidebar已变成树形结构，展开后有 Agents 、 Tasks 、 Logs 、 Config 节点；
• 点击 Logs ，能看到实时滚动的日志，且每条日志旁有 [INFO] 、 [WARN] 标签；
• 在Terminal里执行 dsh task run --agent "test-agent" --input '{"text":"hello"}' ，应该能在Web UI的Logs里立刻看到这条任务的完整执行链路，包括 dsh-at-file 读取了哪个配置文件、 dsh-http-client 调用了哪个API、 dsh-local-storage 存了什么数据。

如果任一环节没出现，就回到第四步的 dsh plugin info ，针对性排查。记住：DSH的错误不会隐藏，它一定会在 list 或 info 里暴露出来，只是你需要读懂它的语言。

4. 避坑指南：那些搜索热词背后的真实陷阱与解法

网络热词里藏着大量用户被卡住的瞬间。我把高频搜索词归类，还原当时场景，给出可复现的解决方案。这些不是理论，而是我在客户现场、开源社区Issue、内部Slack频道里，手把手帮人解决的真实案例。

4.1 “dsh安装报错 error: listen eacces: permission denied 127.0.0.1:3080”

这个报错99%不是权限问题，而是端口被占。Linux/macOS下， EACCES 错误常被误解为需要sudo，但DSH设计为普通用户运行，sudo反而会破坏 ~/.dsh/ 目录权限。

真因排查链路：

1. 执行 netstat -tuln | grep :3080 或 lsof -i :3080 ，看PID列是否有进程；
2. 如果有，执行 ps -p <PID> -o comm= 查进程名；
3. 常见占用者：另一个DSH实例（ dsh web ）、VS Code的Live Server插件、Docker容器、甚至Chrome的某些扩展（如某些代理工具）。

解法：

• 杀掉进程： kill -9 <PID>
• 或换端口启动： dsh web --port 3081 ，并在浏览器访问新URL
• 长期方案： 在 ~/.dsh/config.yaml 里设置 web.port: 3081 ，一劳永逸

注意：Windows用户可能看到 Access is denied ，这通常是因为Windows Defender防火墙拦截了Node.js进程。解决方案是临时关闭防火墙，或在防火墙设置里允许 node.exe 通过。

4.2 “dsh web authentication required; reopen the url printed by dsh web.”

这不是Bug，是DSH的安全设计。它生成一个单次有效的、带签名的URL（如 http://localhost:3080/auth?token=xxx&exp=171xxxxx ），有效期5分钟。你必须在终端打印URL后， 立刻 在同一个设备的浏览器里打开它，完成环回认证。

常见误操作：

• 复制URL时漏掉 ?token=xxx 后面的全部参数；
• 把URL粘贴到手机浏览器里（环回认证要求 localhost 必须指向本机）；
• 5分钟后才打开，token已过期，页面显示 Invalid or expired token 。

解法：

• 重新执行 dsh web ，获取新URL；
• 用 curl -s http://localhost:3080/auth?token=xxx 测试是否返回 {"status":"success"} ，确认服务已响应；
• 如果始终失败，检查 ~/.dsh/config.yaml 里 web.auth.enabled 是否为 true （默认是true，除非你手动关了）。

4.3 “error: dsh: plugin tree failed to load: failed to apply loader entry include”

这是 dsh-plugin-loader 没正确加载的典型症状。根源在于 dsh-plugin-loader 必须在其他插件之前link，且它的 dist/index.js 必须能被DSH主进程require。

排查步骤：

1. 运行 dsh plugin list ，确认 dsh-plugin-loader 状态是 enabled ；
2. 进入 dsh-plugin-loader/dist/ 目录，执行 ls -la ，确认 index.js 存在且大小>0；
3. 检查 dsh-plugin-loader/package.json 里的 main 字段是否指向 dist/index.js （有些旧版指向 lib/index.js ，需手动改）；
4. 最关键一步：运行 dsh plugin info dsh-plugin-loader ，看输出里是否有 Plugin loaded successfully 字样。如果没有，说明Loader自身加载失败，可能是Node.js版本不兼容（DSH要求>=18.0， dsh-plugin-loader v1.5.2要求>=18.12）。

修复： 升级Node.js到v18.17.0 LTS，然后重新 npm ci && npm run build dsh-plugin-loader 。

4.4 “dsh删除一个对话”与“dsh关了之后怎么再启动”

DSH没有“对话”概念，这是用户把DSH和ChatGPT类比产生的误解。DSH里只有 Task （一次执行）和 Agent （可复用的逻辑单元）。所谓“删除对话”，实际是删除某次Task的执行记录。

正确操作：

• 在Web UI的 Logs 页，找到目标Task的Log ID（一长串UUID）；
• 点击右侧的 Delete 按钮（垃圾桶图标）；
• 确认后，该Log从 ~/.dsh/logs/ 文件里被物理删除，且Sidebar树形结构中对应节点消失。

“关了之后怎么再启动”更简单：DSH没有守护进程， dsh web 命令退出即停止。再启动，就是重新运行 dsh web 。如果希望后台运行，用 nohup dsh web --port 3080 > /dev/null 2>&1 & ，或用 systemd （Linux）/ launchd （macOS）管理。

4.5 “agentscope 2.0 和dsh之间的区别，多智能体框架采用哪一个”

这是架构选型问题，不是插件问题。Agentscope是阿里开源的、偏学术研究的多Agent框架，强调Agent间的通信协议（如基于Message的RPC）、分布式部署、复杂编排（支持DAG、循环、条件分支）。DSH则是DeepSeek推出的、偏工程落地的本地开发框架，强调快速迭代、可视化调试、与现有工具链（Git、VS Code、CLI）无缝集成。

选型决策树：

• 如果你要在K8s集群里跑上百个Agent，做金融风控实时决策，选Agentscope；
• 如果你要在本地笔记本上，用Python写一个能调用你公司内部API的客服Agent，并快速调试、改代码、看日志，选DSH；
• 如果团队里既有算法研究员（喜欢Agentscope的Protocol定义），又有工程交付人员（喜欢DSH的Web UI），可以共存：用Agentscope做生产部署，用DSH做本地开发与测试。

我服务过的一个客户，就是这么做的：算法组用Agentscope定义Agent Protocol，生成OpenAPI Spec；工程组用DSH的 dsh-http-client 插件，把Spec里的Endpoint直接接入本地Agent，开发完成后，一键导出为Agentscope可部署的Docker镜像。

5. 进阶实践：从装插件到建生态，我的三个真实项目路径

装完这10个插件，你只是拿到了DSH的“入门驾照”。真正的价值，在于用它们搭出解决你实际问题的系统。分享我在三个不同场景下的落地路径，不是教科书式教程，而是带着血泪教训的实战笔记。

5.1 场景一：AI驱动的内部知识库（客户：某芯片设计公司）

痛点： 新员工入职要学50+份PDF文档（IP核手册、EDA工具指南、流片checklist），传统培训效率低，QA机器人回答不准。

DSH方案：

• 用 dsh-at-file 监控 /company/kb/docs/ 目录，自动解析新增PDF为文本；
• 用 dsh-http-client 调用他们自建的向量数据库API（基于Milvus），存入embedding；
• 用 dsh-local-storage 缓存用户最近3次提问的相似问，避免重复检索；
• dsh-better-sidebar 里建一个 KB-Search-Agent 节点，展开后是 Index Docs 、 Query KB 两个Task；
• Web UI里，新人直接输入“如何设置Virtuoso的layer map”，Agent自动走完：读PDF→向量化→检索→生成答案→存log。

踩坑与优化：

• 初始用 dsh-at-file 的默认PDF解析器，对扫描版PDF失败。换成 pdf2image + pytesseract OCR方案，但OCR耗时长。最终方案： dsh-at-file 配置 preprocess: "ocr" ，并用 dsh-config-reloader 动态开关OCR开关，白天开发关OCR，上线后开。
• 向量检索结果有时不相关。加入 dsh-web-logger 的 filter by agentId 功能，快速定位是哪次Task的 top_k=3 参数设太小，调成5后准确率提升40%。

5.2 场景二：自动化代码审查助手（客户：金融科技团队）

痛点： 每次PR都要人工检查SQL注入、硬编码密钥、合规注释，耗时且遗漏。

DSH方案：

• 写一个 Code-Review-Agent ，用 dsh-at-file 读取PR diff文件；
• 调用 dsh-http-client 对接他们内部的静态分析引擎（基于Semgrep）；
• 结果存 dsh-local-storage ，供后续 dsh-web-logger 展示；
• dsh-better-sidebar 里，每个PR对应一个Task节点，点击展开看到详细检查报告。

关键技巧：

• 用 dsh-env-var 把Semgrep API Key存在环境变量，避免硬编码；
• dsh-dev-tools 的悬浮按钮，让我能在Web UI里直接修改Agent的 severity_threshold 参数（只报ERROR级问题），不用改代码、不用重启；
• dsh-config-reloader 监听 .dshrc ，当团队新增一条合规规则（如“禁止使用 eval() ”），改完配置，Agent立刻生效。

5.3 场景三：跨部门协作流程引擎（客户：医疗AI初创公司）

痛点： 算法组产出模型，工程组部署API，临床组反馈效果，三方沟通靠邮件，进度不透明。

DSH方案：

• 建三个Agent： Model-Train-Agent （调用PyTorch训练脚本）、 API-Deploy-Agent （调用K8s CLI）、 Clinic-Feedback-Agent （解析邮件附件的Excel）；
• 用 dsh-plugin-loader 的 registerWorkflow API，定义一个 model-release-workflow ，串联三个Agent；
• dsh-better-sidebar 里， Workflows 节点下是 model-release-workflow ，展开后是三个Agent的执行状态；
• dsh-web-logger 里，按 workflowId 过滤，看到整个流程的端到端日志。

经验总结：

• Workflow定义不要写死，用 dsh-at-file 读取 /workflows/model-release.yaml ，内容可随时改；
• dsh-local-storage 存每个Agent的输出（如模型版本号、API endpoint、临床反馈摘要），作为下一个Agent的输入，形成数据流；
• 最大的收益不是自动化，而是 dsh-better-sidebar 的树形视图，让CEO打开浏览器，5秒内看清“模型V2.3部署卡在临床反馈环节”，不用再开会议。

这三个项目，起点都是那10个插件。它们不是终点，而是你构建自己AI工作流的“第一块乐高积木”。DSH的价值，不在于它提供了什么，而在于它让你能用最少的代码、最直观的界面，把AI能力真正嵌入到你每天的工作流里。当你不再为“怎么装插件”发愁，而是思考“怎么用这些插件解决下一个业务问题”时，你就真正入门了。