研究了一下梁圣的大肥鲸DSH

1. 快速体验

1. 安装 Node.js（建议安装 LTS 版本）。
2. 一行命令启动 DSH：npx @deepseek-ai/dsh web，然后进入 http://127.0.0.1:3080。
3. 第一次使用时，会提示填入 DeepSeek API key（在 DeepSeek 开放平台创建）。但设置里其实可以选择各种提供官方云服务的 provider（a/、oai 等），也可以自定义 provider（beats）。

2. 主要特性

2.1. 核心思想：万物即插件

DSH 在基础能力（例如：怎么管理 memory、怎么管理 skills、怎么压缩/组装 context 等）上没有本质创新，但系统架构和经典 harness 架构（loop + hook）有本质区别，对比如下：

• 经典架构：以 Agent Loop 为中心，Hook 是 Loop 预留的扩展点。
• DSH：以能力依赖图为中心，Loop 也只是可替换节点，框架统一处理插件的依赖、启停、清理和隔离。

举个例子：

• 经典架构：一个厨房流水线

Loop: 接单 → 备菜 → 炒菜 → 装盘 → 上菜
hook:
炒菜前：检查食材、切菜
炒菜后：拍照、记录成本

• DSH：先有插件，再组装厨房

仓库插件：提供食材
炒菜插件：需要备菜，提供炒菜
厨师插件：执行备菜 -> 炒菜 -> 装盘流程
上菜员插件：需要先完成装盘，提供上菜服务

每个插件声明：
- 我需要什么
- 我提供什么
- 我启动和卸载时如何处理资源

框架根据依赖关系把它们连接起来。ReAct Loop 也只是其中一个“厨师插件”，可以整体换掉。

DSH 插件到底能改什么？

系统提示词、工具、Loop、context manager 等一切 harness 组件（除 AGENTS.md、skills 包等知识型文档）。并且，一个插件可以涉及多个 harness 组件，例如实现一个 Goal 组件，赋予 agent 持续工作、完成具体目标的功能，涉及 tool、sandbox、prompt 等多个配套组件。

结论：DSH 的创新偏向系统工程，而非 Agent 能力创新。它不会让工具调用更聪明、记忆更准确、上下文更合理，而是提供将各种插件组装在一起的编排能力，把过去散落在代码里的 Hook、规则和约定，变成明确的能力协议、依赖关系和生命周期。对于单一 Loop、少量 Hook 的项目可能过度设计，但当系统要支持多种 Loop、模型、存储、沙箱、UI 和运行形态时，它的统一插件模型才更有价值。

2.2. 个性化工作模式

2.3. 轨迹回放

可以清楚地看用户和 agent 的完整交互历史：系统提示词的内容、Session 包含了几个 Turn、每个 Turn 中用户说了什么、agent 调用了哪些工具，等等。

3. 一些关于 harness 基础能力的补充

3.1. 工具并发

一次 LLM 回复可以产生多个 tool calls。给每个工具一个是否支持并发的标识：is_support_parallel。如果为 True，说明该工具支持并发，否则只能串行执行。

工具的调用顺序依赖基模能力，例如：

read1 → read2 → read3 → write1 → read4 → read5 → write2 → write3

并发的执行过程依赖 harness：找到第一个不支持并发的工具 write1，则前面的可并发工具（read1、read2、read3）进入滚动并发池，例如容量为 10。然后执行 write1，之后继续按这个逻辑，并发 read4、read5，再执行 write2……

处理好的工具结果，也应该按照调用顺序排列好返回给 agent。

3.2. 通过 subagent 驱动子任务

子 agent 一般由主 agent 调用某个工具创建，用于完成具体的子任务。DeepAgents 的 task 工具的逻辑就是这样。

task 工具是支持并发的。假如 agent 一次性产生了 3 个 task tool calls，就可以并发出 3 个子 agent 完成具体的任务。

主 agent 需要总结、委派任务，生成 prompt 给子 agent。子 agent 首先要返回一个 task id，主 agent 根据 task id 追踪子 agent 运行状态、拿到结果，也可以自主取消任务。

程序上没问题，但是执行语义方面，主要还是依赖基础模型的能力（harness 也有一定作用，例如写好 prompt）。

举个例子，就像团队协作开发代码库一样，为了避免冲突，大家都是在自己的分支进行开发，最后 merge。子 agent 也应该遵循类似的逻辑来避免冲突性操作。理想状态下，各 agent 需要合理分工：subagent1 负责读和分析，subagent2 负责写前端，subagent3 负责写后端。或者，每个 subagent 先在各自独立的分支下开发，最后由主 agent merge。