跳转至

Yes, absolutely! Docker natively supports mounting multiple volumes to a single container. You can mount as many separate directories as you need.

In your case, splitting it into two volumes is actually a best practice. It keeps the agent's internal state (memory, configurations, API keys) completely separate from your external working files (codebases, shared documents).

Here is how you can implement it using either the command line or Docker Compose.

Using docker run

You just add multiple -v flags to your command.

docker run -d \ --name hermes-agent \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /path/to/host/hermes_memory:/root/.hermes \ -v /path/to/host/shared_files:/workspace \ nousresearch/hermes-agent

What this does:

  1. The Docker Socket: Allows Docker-out-of-Docker (DooD) so the agent can spin up test containers.
  2. Persistent Memory (/root/.hermes): This is where Hermes saves its internal SQLite databases, settings, learned skills, and OAuth tokens (like the Google workspace token).
  3. Shared Host Files (/workspace): This is the "port" to your host machine. Any files you drop into /path/to/host/shared_files on your host will instantly appear in /workspace inside the agent, and the agent can read/edit them.

Using docker-compose.yml

If you are using Docker Compose (which makes managing multiple volumes much easier), your configuration would look like this:

services: hermes-agent: image: nousresearch/hermes-agent container_name: hermes-agent volumes: # 1. Docker socket for spinning up sibling containers - /var/run/docker.sock:/var/run/docker.sock

  # 2. Persistent Agent Memory (config, DBs, learned skills)
  - ./hermes_persistent_memory:/root/.hermes

  # 3. Shared File Port (Code repos, documents, etc.)
  - /path/to/host/shared_files:/workspace

⚠️ Important Reminder for your Test-Drive setup:

Because you are using Docker-out-of-Docker, remember that if Hermes decides to test a git repo located in the shared folder (/workspace), and tries to spin up a new container to test it, the new container doesn't know what /workspace is.

If Hermes spins up a node/python testing container, you must prompt or configure the agent to mount the host path (/path/to/host/shared_files) to the test container, not the internal container path (/workspace).

To solve this Docker-out-of-Docker (DooD) path translation problem, there are three main ways to handle it.

Here are the exact implementations, ordered from easiest/most foolproof to the most "agentic":

Method 1: The "Identical Path" Trick (Highly Recommended)

The absolute easiest way to fix this is to bypass the need for translation entirely. You do this by making the path inside the Hermes container exactly match the path on your host machine.

Instead of mounting to a generic /workspace folder inside the container, map it to the exact same directory structure.

If your host path is /home/user/projects/shared_files:

docker run -d \ --name hermes-agent \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /home/user/hermes_memory:/root/.hermes \ -v /home/user/projects/shared_files:/home/user/projects/shared_files \ nousresearch/hermes-agent

Why this is foolproof: When the agent looks at its files, it sees them at /home/user/projects/shared_files. When it runs a docker run -v /home/user/projects/shared_files:/app command to spin up a test container, the host Docker daemon receives that exact path—which correctly maps to the real host folder. No LLM hallucination or prompt engineering is required!

Method 2: Use Environment Variables + A Custom Hermes Skill

If you must keep the internal path as /workspace (e.g., to keep things tidy inside the container), you should pass the host path to the agent as an environment variable, and teach it a "Skill" to use that variable.

Step 1: Pass the variable in your Docker run command

docker run -d \ --name hermes-agent \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /path/to/host/shared_files:/workspace \ -e HOST_WORKSPACE_PATH="/path/to/host/shared_files" \ nousresearch/hermes-agent

Step 2: Teach Hermes the translation rule Once the container is running, open the chat with Hermes and explicitly teach it this rule so it saves it to its procedural memory (.hermes). Send this exact prompt:

"Listen carefully: You are running inside a Docker container using Docker-out-of-Docker. The directory /workspace inside your environment actually maps to the host machine path stored in the environment variable $HOST_WORKSPACE_PATH. Whenever you use the terminal to run a docker run command that needs to mount the workspace, you MUST NOT use /workspace. You must use the $HOST_WORKSPACE_PATH variable instead. Please use your skill_manage tool to save this as a permanent rule called 'docker-path-translation'."

Hermes will write a markdown file into its memory ensuring that every time it prepares a docker run command, it substitutes /workspace with the host path.

Method 3: Provide a Pre-written Bash Script Wrap

If you don't want to rely on the LLM remembering the path rule, you can give it a dedicated script in the shared folder that handles the translation automatically.

Step 1: Create a file named run_test_container.sh in your shared files folder:

!/bin/bash

run_test_container.sh

Usage: ./run_test_container.sh

Hardcoded host path

HOST_PATH="/path/to/host/shared_files" IMAGE=\(1 shift CMD=\)@

echo "Spinning up $IMAGE and mounting \(HOST_PATH..." docker run --rm -v "\)HOST_PATH:/app" -w /app "$IMAGE" $CMD

Step 2: Make it executable on your host:

chmod +x /path/to/host/shared_files/run_test_container.sh

Step 3: Tell the Agent to use it. Now, whenever you ask Hermes to test a repo, just tell it:

"Test drive this git repo. Instead of writing raw docker commands, use the ./workspace/run_test_container.sh script. For example: ./workspace/run_test_container.sh node:18 npm test."

Summary: Method 1 is the best because it requires zero cognitive load from the LLM. Method 2 is the most "agentic" and utilizes Hermes's built-in skill system. Method 3 is the safest if you want strict control over exactly how test containers are spawned.