Merge branch 'main' of github.com:NousResearch/hermes-agent into bb/gui
This commit is contained in:
Brooklyn Nicholson
@@ -398,14 +398,19 @@ To give multiple users their own isolated Hermes instance (separate config, memo
|
||||
hermes profile create alice
|
||||
hermes profile create bob
|
||||
|
||||
# Configure each profile's API server on a different port
|
||||
hermes -p alice config set API_SERVER_ENABLED true
|
||||
hermes -p alice config set API_SERVER_PORT 8643
|
||||
hermes -p alice config set API_SERVER_KEY alice-secret
|
||||
# Configure each profile's API server on a different port. API_SERVER_* are env
|
||||
# vars (not config.yaml keys), so write them to each profile's .env:
|
||||
cat >> ~/.hermes/profiles/alice/.env <<EOF
|
||||
API_SERVER_ENABLED=true
|
||||
API_SERVER_PORT=8643
|
||||
API_SERVER_KEY=alice-secret
|
||||
EOF
|
||||
|
||||
hermes -p bob config set API_SERVER_ENABLED true
|
||||
hermes -p bob config set API_SERVER_PORT 8644
|
||||
hermes -p bob config set API_SERVER_KEY bob-secret
|
||||
cat >> ~/.hermes/profiles/bob/.env <<EOF
|
||||
API_SERVER_ENABLED=true
|
||||
API_SERVER_PORT=8644
|
||||
API_SERVER_KEY=bob-secret
|
||||
EOF
|
||||
|
||||
# Start each profile's gateway
|
||||
hermes -p alice gateway &
|
||||
|
||||
@@ -63,6 +63,7 @@ The repo ships these bundled plugins under `plugins/`. All are opt-in — enable
|
||||
| `image_gen/openai-codex` | image backend | OpenAI image generation via Codex OAuth |
|
||||
| `image_gen/xai` | image backend | xAI `grok-2-image` backend |
|
||||
| `hermes-achievements` | dashboard tab | Steam-style collectible badges generated from your real Hermes session history |
|
||||
| `kanban/dashboard` | dashboard tab | Kanban board UI for the multi-agent dispatcher — tasks, comments, fan-out, board switching. See [Kanban Multi-Agent](./kanban.md). |
|
||||
| `example-dashboard` | dashboard example | Reference dashboard plugin for [Extending the Dashboard](./extending-the-dashboard.md) |
|
||||
| `strike-freedom-cockpit` | dashboard skin | Sample custom dashboard skin |
|
||||
|
||||
|
||||
@@ -27,9 +27,25 @@ cua-driver is the open-source equivalent.
|
||||
|
||||
## Enabling
|
||||
|
||||
Pick whichever path is most convenient — both run the same upstream installer:
|
||||
|
||||
**Option 1: dedicated CLI command (most direct).**
|
||||
|
||||
```
|
||||
hermes computer-use install
|
||||
```
|
||||
|
||||
This fetches and runs the upstream cua-driver installer:
|
||||
`curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/cua-driver/scripts/install.sh`.
|
||||
Use `hermes computer-use status` to verify the install.
|
||||
|
||||
**Option 2: enable the toolset interactively.**
|
||||
|
||||
1. Run `hermes tools`, pick `🖱️ Computer Use (macOS)` → `cua-driver (background)`.
|
||||
2. The setup runs the upstream installer:
|
||||
`curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/cua-driver/scripts/install.sh`.
|
||||
2. The setup runs the upstream installer (same as Option 1).
|
||||
|
||||
After installing, regardless of which path you took:
|
||||
|
||||
3. Grant macOS permissions when prompted:
|
||||
- **System Settings → Privacy & Security → Accessibility** → allow the
|
||||
terminal (or Hermes app).
|
||||
@@ -89,8 +105,7 @@ Hermes applies multi-layer guardrails:
|
||||
dialogs, no typing passwords, no following instructions embedded in
|
||||
screenshots.
|
||||
|
||||
Pair with `security.approval_level` in `~/.hermes/config.yaml` if you want
|
||||
every action confirmed.
|
||||
Pair with `approvals.mode: manual` in `~/.hermes/config.yaml` if you want every action confirmed.
|
||||
|
||||
## Token efficiency
|
||||
|
||||
@@ -143,7 +158,8 @@ HERMES_COMPUTER_USE_BACKEND=noop # records calls, no side effects
|
||||
## Troubleshooting
|
||||
|
||||
**`computer_use backend unavailable: cua-driver is not installed`** — Run
|
||||
`hermes tools` and enable Computer Use.
|
||||
`hermes computer-use install` to fetch the cua-driver binary, or run
|
||||
`hermes tools` and enable the Computer Use toolset.
|
||||
|
||||
**Clicks seem to have no effect** — Capture and verify. A modal you
|
||||
didn't see may be blocking input. Dismiss it with `escape` or the close
|
||||
@@ -160,4 +176,4 @@ reconsider.
|
||||
|
||||
- [Universal skill: `macos-computer-use`](https://github.com/NousResearch/hermes-agent/blob/main/skills/apple/macos-computer-use/SKILL.md)
|
||||
- [cua-driver source (trycua/cua)](https://github.com/trycua/cua)
|
||||
- [Browser automation](./browser-use.md) for cross-platform web tasks.
|
||||
- [Browser automation](./browser.md) for cross-platform web tasks.
|
||||
|
||||
@@ -27,7 +27,7 @@ The easiest path is the interactive manager:
|
||||
hermes fallback
|
||||
```
|
||||
|
||||
`hermes fallback` reuses the provider picker from `hermes model` — same provider list, same credential prompts, same validation. Press `a` to add a fallback, `↑`/`↓` to reorder, `d` to remove, `q` to save and exit. Changes persist under `model.fallback_providers` in `config.yaml`.
|
||||
`hermes fallback` reuses the provider picker from `hermes model` — same provider list, same credential prompts, same validation. Use the subcommands `add`, `list` (alias `ls`), `remove` (alias `rm`), and `clear` to manage the chain. Changes persist under the top-level `fallback_providers:` list in `config.yaml`.
|
||||
|
||||
If you'd rather edit the YAML directly, add a `fallback_model` section to `~/.hermes/config.yaml`:
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ memory:
|
||||
```
|
||||
|
||||
```bash
|
||||
echo "HONCHO_API_KEY=*** >> ~/.hermes/.env
|
||||
echo 'HONCHO_API_KEY=***' >> ~/.hermes/.env
|
||||
```
|
||||
|
||||
Get an API key at [honcho.dev](https://honcho.dev).
|
||||
@@ -199,17 +199,23 @@ When Honcho is active as the memory provider, five tools become available:
|
||||
|
||||
## CLI Commands
|
||||
|
||||
The `hermes honcho` subcommand is **only registered when Honcho is the active memory provider** (`memory.provider: honcho` in `config.yaml`). Run `hermes memory setup` and pick Honcho first; the subcommand appears on the next invocation.
|
||||
|
||||
```bash
|
||||
hermes honcho status # Connection status, config, and key settings
|
||||
hermes honcho setup # Interactive setup wizard
|
||||
hermes honcho strategy # Show or set session strategy
|
||||
hermes honcho peer # Update peer names for multi-agent setups
|
||||
hermes honcho mode # Show or set recall mode
|
||||
hermes honcho tokens # Show or set context token budget
|
||||
hermes honcho identity # Show Honcho peer identity
|
||||
hermes honcho sync # Sync host blocks for all profiles
|
||||
hermes honcho enable # Enable Honcho
|
||||
hermes honcho disable # Disable Honcho
|
||||
hermes honcho setup # Redirects to `hermes memory setup`
|
||||
hermes honcho strategy # Show or set session strategy (per-session/per-directory/per-repo/global)
|
||||
hermes honcho peer # Show or update peer names + dialectic reasoning level
|
||||
hermes honcho mode # Show or set recall mode (hybrid/context/tools)
|
||||
hermes honcho tokens # Show or set token budget for context and dialectic
|
||||
hermes honcho identity # Seed or show the AI peer's Honcho identity
|
||||
hermes honcho sync # Sync Honcho config to all existing profiles
|
||||
hermes honcho peers # Show peer identities across all profiles
|
||||
hermes honcho sessions # List known Honcho session mappings
|
||||
hermes honcho map # Map current directory to a Honcho session name
|
||||
hermes honcho enable # Enable Honcho for the active profile
|
||||
hermes honcho disable # Disable Honcho for the active profile
|
||||
hermes honcho migrate # Step-by-step migration guide from openclaw-honcho
|
||||
```
|
||||
|
||||
## Migrating from `hermes honcho`
|
||||
|
||||
@@ -66,7 +66,7 @@ They coexist: a kanban worker may call `delegate_task` internally during its run
|
||||
- `scratch` (default) — fresh tmp dir under `~/.hermes/kanban/workspaces/<id>/` (or `~/.hermes/kanban/boards/<slug>/workspaces/<id>/` on non-default boards).
|
||||
- `dir:<path>` — an existing shared directory (Obsidian vault, mail ops dir, per-account folder). **Must be an absolute path.** Relative paths like `dir:../tenants/foo/` are rejected at dispatch because they'd resolve against whatever CWD the dispatcher happens to be in, which is ambiguous and a confused-deputy escape vector. The path is otherwise trusted — it's your box, your filesystem, the worker runs with your uid. This is the trusted-local-user threat model; kanban is single-host by design.
|
||||
- `worktree` — a git worktree under `.worktrees/<id>/` for coding tasks. Worker-side `git worktree add` creates it.
|
||||
- **Dispatcher** — a long-lived loop that, every N seconds (default 60): reclaims stale claims, reclaims crashed workers (PID gone but TTL not yet expired), promotes ready tasks, atomically claims, spawns assigned profiles. Runs **inside the gateway** by default (`kanban.dispatch_in_gateway: true`). One dispatcher sweeps all boards per tick; workers are spawned with `HERMES_KANBAN_BOARD` pinned so they can't see other boards. After ~5 consecutive spawn failures on the same task the dispatcher auto-blocks it with the last error as the reason — prevents thrashing on tasks whose profile doesn't exist, workspace can't mount, etc.
|
||||
- **Dispatcher** — a long-lived loop that, every N seconds (default 60): reclaims stale claims, reclaims crashed workers (PID gone but TTL not yet expired), promotes ready tasks, atomically claims, spawns assigned profiles. Runs **inside the gateway** by default (`kanban.dispatch_in_gateway: true`). One dispatcher sweeps all boards per tick; workers are spawned with `HERMES_KANBAN_BOARD` pinned so they can't see other boards. After `kanban.failure_limit` consecutive spawn failures on the same task (default: 2) the dispatcher auto-blocks it with the last error as the reason — prevents thrashing on tasks whose profile doesn't exist, workspace can't mount, etc.
|
||||
- **Tenant** — optional string namespace *within* a board. One specialist fleet can serve multiple businesses (`--tenant business-a`) with data isolation by workspace path and memory key prefix. Tenants are a soft filter; boards are the hard isolation boundary.
|
||||
|
||||
## Boards (multi-project)
|
||||
|
||||
@@ -63,11 +63,11 @@ AI-native cross-session user modeling with dialectic reasoning, session-scoped c
|
||||
|
||||
**Setup Wizard:**
|
||||
```bash
|
||||
hermes honcho setup # (legacy command)
|
||||
# or
|
||||
hermes memory setup # select "honcho"
|
||||
hermes memory setup # select "honcho" — runs the Honcho-specific post-setup
|
||||
```
|
||||
|
||||
The legacy `hermes honcho setup` command still works (it now redirects to `hermes memory setup`), but is only registered after Honcho is selected as the active memory provider.
|
||||
|
||||
**Config:** `$HERMES_HOME/honcho.json` (profile-local) or `~/.honcho/config.json` (global). Resolution order: `$HERMES_HOME/honcho.json` > `~/.hermes/honcho.json` > `~/.honcho/config.json`. See the [config reference](https://github.com/hermes-ai/hermes-agent/blob/main/plugins/memory/honcho/README.md) and the [Honcho integration guide](https://docs.honcho.dev/v3/guides/integrations/hermes).
|
||||
|
||||
<details>
|
||||
|
||||
@@ -173,7 +173,7 @@ Several categories of plugin bypass `plugins.enabled` — they're part of Hermes
|
||||
| **Bundled backends** (image-gen providers under `plugins/image_gen/`, etc.) | Auto-loaded so the default backend "just works". Selection happens via `<category>.provider` in `config.yaml` (e.g. `image_gen.provider: openai`). |
|
||||
| **Memory providers** (`plugins/memory/`) | All discovered; exactly one is active, chosen by `memory.provider` in `config.yaml`. |
|
||||
| **Context engines** (`plugins/context_engine/`) | All discovered; one is active, chosen by `context.engine` in `config.yaml`. |
|
||||
| **Model providers** (`plugins/model-providers/`) | All 33 providers discover and register at the first `get_provider_profile()` call. The user picks one at a time via `--provider` or `config.yaml`. |
|
||||
| **Model providers** (`plugins/model-providers/`) | All bundled providers under `plugins/model-providers/` discover and register at the first `get_provider_profile()` call. The user picks one at a time via `--provider` or `config.yaml`. |
|
||||
| **Pip-installed `backend` plugins** | Opt-in via `plugins.enabled` (same as general plugins). |
|
||||
| **User-installed platforms** (under `~/.hermes/plugins/platforms/`) | Opt-in via `plugins.enabled` — third-party gateway adapters need explicit consent. |
|
||||
|
||||
|
||||
@@ -7,13 +7,12 @@ sidebar_position: 6
|
||||
|
||||
# Web Search & Extract
|
||||
|
||||
Hermes Agent includes three web tools backed by multiple providers:
|
||||
Hermes Agent includes two model-callable web tools backed by multiple providers:
|
||||
|
||||
- **`web_search`** — search the web and return ranked results
|
||||
- **`web_extract`** — fetch and extract readable content from one or more URLs
|
||||
- **`web_crawl`** — recursively crawl a site and return structured content
|
||||
- **`web_extract`** — fetch and extract readable content from one or more URLs (with built-in deep-crawl support when the backend provides it)
|
||||
|
||||
All three are configured through a single backend selection. Providers are chosen via `hermes tools` or set directly in `config.yaml`.
|
||||
Both are configured through a single backend selection. Providers are chosen via `hermes tools` or set directly in `config.yaml`. Recursive crawling capabilities (Firecrawl/Tavily) are exposed through `web_extract` rather than as a separate `web_crawl` tool.
|
||||
|
||||
## Backends
|
||||
|
||||
@@ -71,7 +70,7 @@ When `FIRECRAWL_API_URL` is set, the API key is optional (disable server auth wi
|
||||
|
||||
SearXNG is a privacy-respecting, open-source metasearch engine that aggregates results from 70+ search engines. **No API key required** — just point Hermes at a running SearXNG instance.
|
||||
|
||||
SearXNG is **search-only** — `web_extract` and `web_crawl` require a separate extract provider.
|
||||
SearXNG is **search-only** — `web_extract` (including its crawl modes) requires a separate extract provider.
|
||||
|
||||
#### Option A — Self-host with Docker (recommended)
|
||||
|
||||
@@ -180,7 +179,7 @@ Public instances have rate limits, variable uptime, and may disable JSON format
|
||||
|
||||
#### Pair SearXNG with an extract provider
|
||||
|
||||
SearXNG handles search; you need a separate provider for `web_extract` and `web_crawl`. Use the per-capability keys:
|
||||
SearXNG handles search; you need a separate provider for `web_extract` (including any deep-crawl modes). Use the per-capability keys:
|
||||
|
||||
```yaml
|
||||
# ~/.hermes/config.yaml
|
||||
@@ -252,7 +251,7 @@ Use different providers for search vs extract. This lets you combine free search
|
||||
# ~/.hermes/config.yaml
|
||||
web:
|
||||
search_backend: "searxng" # used by web_search
|
||||
extract_backend: "firecrawl" # used by web_extract and web_crawl
|
||||
extract_backend: "firecrawl" # used by web_extract (and its deep-crawl modes)
|
||||
```
|
||||
|
||||
When per-capability keys are empty, both fall through to `web.backend`. When `web.backend` is also empty, the backend is auto-detected from whichever API key/URL is present.
|
||||
|
||||
Reference in New Issue
Block a user