snapshot: preserve central wiki state 2026-08-15 (7 modified + 1 new file)
This commit is contained in:
Tony0410
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: Agent Memory
|
||||
type: concept
|
||||
status: active
|
||||
created: 2026-07-22
|
||||
updated: 2026-07-22
|
||||
verified_on: 2026-07-22
|
||||
confidence: high
|
||||
tags: [concept, memory]
|
||||
sources: [raw/configs/hermes-config-sanitized.txt]
|
||||
---
|
||||
|
||||
# Agent Memory
|
||||
|
||||
## Idea
|
||||
How an agent retains facts/context beyond a single conversation turn or session — what gets stored, when it's flushed, and how it's retrieved later.
|
||||
|
||||
## How this install implements it
|
||||
- **Backend:** Mnemosyne, local native (not a separate docker service) — see [[systems/mnemosyne]], [[comparisons/memory-backends]].
|
||||
- **Verified settings:** memory enabled `true`; message char limit `5000`; user-profile char limit `3000`; flush every `6` turns; `auto_sleep: true`; default scope `session`; vector type `int8`; shared surface `data/shared/mnemosyne.db`.
|
||||
- **Correction (2026-07-22, per Anthony):** this page previously named Hindsight as a predecessor backend on this box. That was a mix-up with a different Hermes instance — Hindsight has nothing to do with this box. See [[comparisons/memory-backends]] for the full correction.
|
||||
|
||||
## Model
|
||||
- Per-turn conversation content accumulates up to the char limit, then flushes to the Mnemosyne store every 6 turns (rather than every turn) — a batching tradeoff between write frequency and losing very recent context if the process dies mid-batch.
|
||||
- `scope: session` means recall defaults to the current session rather than a global cross-session pool, unless explicitly widened.
|
||||
|
||||
## Related
|
||||
- [[systems/memory-backend]]
|
||||
- [[comparisons/memory-backends]]
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Browser Automation
|
||||
type: concept
|
||||
status: active
|
||||
created: 2026-07-22
|
||||
updated: 2026-08-02
|
||||
verified_on: 2026-08-02
|
||||
confidence: high
|
||||
tags: [concept, browser, camofox, steel]
|
||||
sources: [live-probe, session-history]
|
||||
---
|
||||
|
||||
# Browser Automation
|
||||
|
||||
## Idea
|
||||
Giving an agent a real, controllable web browser — as opposed to just an HTTP-fetch tool — so it can handle JS-heavy pages, logins, and visual verification.
|
||||
|
||||
## How this install implements it
|
||||
- **Engine:** Camoufox (Firefox-based, fingerprint-resistant) — see [[comparisons/camoufox-vs-chrome]] for why this over stock Chrome.
|
||||
- **Connection:** REST API at `localhost:9093` (profile `anthony`) + CDP WebSocket at `localhost:9377`
|
||||
- **Display:** headed, not truly headless — runs under `Xvfb :99` (1600×1200×24) with `fluxbox` as window manager, viewable live over VNC (see [[systems/headless-server]]).
|
||||
- **Config:** `cloud_provider: camofox`, `camera_provider: camofox` in `~/.hermes/config.yaml`
|
||||
- **Auth:** Persistent profile `anthony` — authenticated into Uber Eats, LinkedIn, etc. No cookie files needed.
|
||||
|
||||
## Why headed-under-Xvfb instead of headless
|
||||
Running a real X display (rather than a headless browser flag) lets a human watch/intervene via VNC and tends to reduce automation-detection fingerprints compared to headless-mode flags — consistent with using Camoufox in the first place. The tradeoff, flagged in [[systems/headless-server]], is that the VNC exposing this display currently has no password.
|
||||
|
||||
## The Steel Experiment (Jul 29–30)
|
||||
Steel Browser (Chromium 140 on CT201) was briefly the primary backend. It offered full CDP access and a built-in session viewer, but was reverted after:
|
||||
- CDP URL normalization issues (Docker internal networking required a plugin patch)
|
||||
- Empty-stream errors from the `opencode-go/deepseek-v4-flash` provider path
|
||||
- DeepSeek 0731's stricter tool name validation affected all providers
|
||||
|
||||
**Lesson:** A local browser backend (same host, no network hop) has fewer failure modes than a remote Docker container. The `browser-steel` plugin is still present but disabled. See [[comparisons/steel-vs-camoufox]] and [[decisions/rollback-steel-to-camofox]].
|
||||
|
||||
## Related
|
||||
- [[systems/browser-backend]]
|
||||
- [[comparisons/steel-vs-camoufox]]
|
||||
- [[comparisons/camoufox-vs-chrome]]
|
||||
- [[systems/headless-server]]
|
||||
- [[concepts/tool-calling]]
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: Model Routing
|
||||
type: concept
|
||||
status: active
|
||||
created: 2026-07-22
|
||||
updated: 2026-07-22
|
||||
verified_on: 2026-07-22
|
||||
confidence: high
|
||||
tags: [routing, model, inference]
|
||||
sources: [raw/configs/hermes-config-sanitized.txt, current-profile.md]
|
||||
---
|
||||
|
||||
# Model Routing
|
||||
|
||||
## Purpose
|
||||
How Hermes selects providers, applies combos, and enforces context limits.
|
||||
|
||||
## Current Flow
|
||||
- Main path: `custom:litellm` → `http://litellm:4000/v1`
|
||||
- Default model: `freellmapi-auto`
|
||||
- OmniRoute used for auxiliary roles: vision, skills_hub, approval, mcp, title_generation, web_extract, compression
|
||||
|
||||
## Context Enforcement
|
||||
- Three layers: model native → combo `data.config.context_length` → Hermes client cap
|
||||
- Effective context is the minimum of the three
|
||||
|
||||
## Combo Behavior
|
||||
- `priority` retries same provider up to `maxRetries`, then errors; it does NOT fall through
|
||||
- `fill-first` walks the list on failure
|
||||
- `auto`/`lkgp` recalculates per request using health scoring
|
||||
- Same-provider entries in a combo share rate-limit buckets
|
||||
- Session affinity caches provider in `session_model_history`
|
||||
|
||||
## Aliases and Mappings
|
||||
- Model aliases resolved via `key_value` table (`modelAliases` namespace)
|
||||
- Wildcard mappings via `model_combo_mappings`
|
||||
- OpenCode/Zen entries may resolve back to `opencode-zen` provider internally
|
||||
|
||||
## History
|
||||
- User-provided: OpenRouter was used previously; provider lists now centered on LiteLLM + OmniRoute
|
||||
- User-provided: `persist_switch_by_default=false`; `/model` is per-session unless `--global` used
|
||||
- Inferred: Configuration undergoes periodic corrections related to vision, model fallback, and browser backend tuning
|
||||
|
||||
## Related
|
||||
- [[model-providers]]
|
||||
- [[systems/omniroute]]
|
||||
- [[openrouter]]
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: Persistent Shells
|
||||
type: concept
|
||||
status: active
|
||||
created: 2026-07-22
|
||||
updated: 2026-07-22
|
||||
verified_on: 2026-07-22
|
||||
confidence: high
|
||||
tags: [concept, terminal]
|
||||
sources: [raw/configs/hermes-config-sanitized.txt]
|
||||
---
|
||||
|
||||
# Persistent Shells
|
||||
|
||||
## Idea
|
||||
A background shell session that survives across separate Hermes turns/requests, instead of spawning and tearing down a fresh shell each time — so state (working directory, exported variables, long-running processes) carries over.
|
||||
|
||||
## How this install implements it
|
||||
- **Verified (`~/.hermes/config.yaml`):** `terminal.persistent_shell: true`
|
||||
- **Backend:** local (not containerized separately from the agent process)
|
||||
- **Working directory:** `/home/hermes/workspace`
|
||||
- **Timeout:** 180s
|
||||
- **Home mode:** auto
|
||||
- **Container CPU:** 1
|
||||
|
||||
## Why it matters here
|
||||
Enables multi-step CLI workflows (e.g. a long `git` operation, a build, a watch process) to be resumed across turns without Hermes re-establishing context each time. The tradeoff is a shell can be left in a bad state (stuck process, wrong directory) that silently affects the *next* turn — see [[runbooks/troubleshoot-tool-loop]] for the related tool-loop guardrails that catch some of this.
|
||||
|
||||
## Related
|
||||
- [[systems/terminal-backend]]
|
||||
- [[systems/hermes-agent]]
|
||||
- [[concepts/tool-calling]]
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Tool Calling
|
||||
type: concept
|
||||
status: active
|
||||
created: 2026-07-22
|
||||
updated: 2026-07-22
|
||||
verified_on: 2026-07-22
|
||||
confidence: high
|
||||
tags: [concept, tool-calling]
|
||||
sources: [raw/configs/hermes-config-sanitized.txt]
|
||||
---
|
||||
|
||||
# Tool Calling
|
||||
|
||||
## Idea
|
||||
How Hermes decides to invoke a tool, and — more specifically for this page — how it detects and stops itself when tool use goes wrong (loops, repeated failures).
|
||||
|
||||
## How this install implements guardrails
|
||||
**Verified (`~/.hermes/config.yaml`, `tool_loop_guardrails:`):**
|
||||
```
|
||||
warnings_enabled: true
|
||||
hard_stop_enabled: false
|
||||
warn_after:
|
||||
exact_failure: 2
|
||||
same_tool_failure: 3
|
||||
idempotent_no_progress: 2
|
||||
hard_stop_after:
|
||||
exact_failure: 5
|
||||
same_tool_failure: 8
|
||||
idempotent_no_progress: 5
|
||||
```
|
||||
- Warnings trigger well before any hard stop (2–3 repeats vs 5–8).
|
||||
- **`hard_stop_enabled: false`** — Hermes will *warn* about a stuck tool loop but will not currently force-stop itself. That's a deliberate-looking but consequential setting: a genuinely stuck loop only gets a warning, not an automatic halt.
|
||||
|
||||
## Why it matters here
|
||||
This is the mechanism behind [[runbooks/troubleshoot-tool-loop]] — that runbook's "agent loops on one tool" symptom is exactly what `warn_after`/`hard_stop_after` are meant to catch. With hard-stop disabled, a human (or the messaging integrations) is the actual backstop today.
|
||||
|
||||
## Related
|
||||
- [[concepts/persistent-shells]]
|
||||
- [[runbooks/troubleshoot-tool-loop]]
|
||||
- [[systems/hermes-agent]]
|
||||
Reference in New Issue
Block a user