基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/NousResearch/hermes-agent --skill honcho命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | honcho |
| description | Configure and troubleshoot Honcho memory for Hermes. |
| version | 2.0.0 |
| author | Hermes Agent |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["Honcho","Memory","Profiles","Observation","Dialectic","User-Modeling","Session-Summary"],"homepage":"https://docs.honcho.dev","related_skills":["hermes-agent"]}} |
| prerequisites | {"pip":["honcho-ai"]} |
Honcho provides AI-native cross-session user modeling. It learns who the user is across conversations and gives every Hermes profile its own peer identity while sharing a unified view of the user.
hermes memory setup honcho
# select "cloud", paste API key from https://app.honcho.dev
hermes memory setup honcho
# select "local", enter base URL (e.g. http://localhost:8000)
See: https://docs.honcho.dev/v3/guides/integrations/hermes#running-honcho-locally-with-hermes
hermes honcho status # shows resolved config, connection test, peer info
When Honcho injects context into the system prompt (in hybrid or context recall modes), it assembles the base context block in this order:
The session summary is generated automatically by Honcho at the start of each turn (when a prior session exists). It gives the model a warm start without replaying full history.
Honcho automatically selects between two prompt strategies:
| Condition | Strategy | What happens |
|---|---|---|
| No prior session or empty representation | Cold start | Lightweight intro prompt; skips summary injection; encourages the model to learn about the user |
| Existing representation and/or session history | Warm start | Full base context injection (summary → representation → card); richer system prompt |
You do not need to configure this -- it is automatic based on session state.
Honcho models conversations as interactions between peers. Hermes creates two peers per session:
peerName): represents the human. Honcho builds a user representation from observed messages.aiPeer): represents this Hermes instance. Each profile gets its own AI peer so agents develop independent views.Each peer has two observation toggles that control what Honcho learns from:
| Toggle | What it does |
|---|---|
observeMe | Peer's own messages are observed (builds self-representation) |
observeOthers | Other peers' messages are observed (builds cross-peer understanding) |
Default: all four toggles on (full bidirectional observation).
Configure per-peer in honcho.json:
{
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": true, "observeOthers": true }
}
}
Or use the shorthand presets:
| Preset | User | AI | Use case |
|---|---|---|---|
"directional" (default) | me:on, others:on | me:on, others:on | Multi-agent, full memory |
"unified" | me:on, others:off | me:off, others:on | Single agent, user-only modeling |
Settings changed in the Honcho dashboard are synced back on session init -- server-side config wins over local defaults.
Honcho sessions scope where messages and observations land. Strategy options:
| Strategy | Behavior |
|---|---|
per-directory (default) | One session per working directory |
per-repo | One session per git repository root |
per-session | New Honcho session each Hermes run |
global | Single session across all directories |
Manual override: hermes honcho map my-project-name
How the agent accesses Honcho memory:
| Mode | Auto-inject context? | Tools available? | Use case |
|---|---|---|---|
hybrid (default) | Yes | Yes | Agent decides when to use tools vs auto context |
context | Yes | No (hidden) | Minimal token cost, no tool calls |
tools | No | Yes | Agent controls all memory access explicitly |
Honcho's dialectic behavior is controlled by three independent dimensions. Each can be tuned without affecting the others:
Controls how often dialectic and context calls happen.
| Key | Default | Description |
|---|---|---|
contextCadence | 1 | Min turns between context API calls |
dialecticCadence | 2 | Min turns between dialectic API calls. Recommended 1–5 |
injectionFrequency | every-turn | every-turn or first-turn for base context injection |
Higher cadence values fire the dialectic LLM less often. dialecticCadence: 2 means the engine fires every other turn. Setting it to 1 fires every turn.
Controls how many rounds of dialectic reasoning Honcho performs per query.
| Key | Default | Range | Description |
|---|---|---|---|
dialecticDepth | 1 | 1-3 | Number of dialectic reasoning rounds per query |
dialecticDepthLevels | -- | array | Optional per-depth-round level overrides (see below) |
dialecticDepth: 2 means Honcho runs two rounds of dialectic synthesis. The first round produces an initial answer; the second refines it.
dialecticDepthLevels lets you set the reasoning level for each round independently:
{
"dialecticDepth": 3,
"dialecticDepthLevels": ["low", "medium", "high"]
}
If dialecticDepthLevels is omitted, rounds use proportional levels derived from dialecticReasoningLevel (the base):
| Depth | Pass levels |
|---|---|
| 1 | [base] |
| 2 | [minimal, base] |
| 3 | [minimal, base, low] |
This keeps earlier passes cheap while using full depth on the final synthesis.
Depth at session start. The session-start prewarm runs the full configured dialecticDepth in the background before turn 1. A single-pass prewarm on a cold peer often returns thin output — multi-pass depth runs the audit/reconcile cycle before the user ever speaks. Turn 1 consumes the prewarm result directly; if prewarm hasn't landed in time, turn 1 falls back to a synchronous call with a bounded timeout.
Controls the intensity of each dialectic reasoning round.
| Key | Default | Description |
|---|---|---|
dialecticReasoningLevel | low | minimal, low, medium, high, max |
dialecticDynamic | true | When true, the model can pass reasoning_level to honcho_reasoning to override the default per-call. false = always use dialecticReasoningLevel, model overrides ignored |
Higher levels produce richer synthesis but cost more tokens on Honcho's backend.
Each Hermes profile gets its own Honcho AI peer while sharing the same workspace (user context). This means:
hermes profile create coder --clone
# creates host block hermes.coder, AI peer "coder", inherits config from default
What --clone does for Honcho:
hermes.coder host block in honcho.jsonaiPeer: "coder" (the profile name)workspace, peerName, writeFrequency, recallMode, etc. from defaulthermes honcho sync # creates host blocks for all profiles that don't have one yet
Override any setting in the host block:
{
"hosts": {
"hermes.coder": {
"aiPeer": "coder",
"recallMode": "tools",
"dialecticDepth": 2,
"observation": {
"user": { "observeMe": true, "observeOthers": false },
"ai": { "observeMe": true, "observeOthers": true }
}
}
}
}
The agent has 5 bidirectional Honcho tools (hidden in context recall mode):
| Tool | LLM call? | Cost | Use when |
|---|---|---|---|
honcho_profile | No | minimal | Quick factual snapshot at conversation start or for fast name/role/pref lookups |
honcho_search | No | low | Fetch specific past facts to reason over yourself — raw excerpts, no synthesis |
honcho_context | No | low | Full session context snapshot: summary, representation, card, recent messages |
honcho_reasoning | Yes | medium–high | Natural language question synthesized by Honcho's dialectic engine |
honcho_conclude | No | minimal | Write or delete a persistent fact; pass peer: "ai" for AI self-knowledge |
honcho_profileRead or update a peer card — curated key facts (name, role, preferences, communication style). Pass card: [...] to update; omit to read. No LLM call.
honcho_searchSemantic search over stored context for a specific peer. Returns raw excerpts ranked by relevance, no synthesis. Default 800 tokens, max 2000. Good when you need specific past facts to reason over yourself rather than a synthesized answer.
honcho_contextFull session context snapshot from Honcho — session summary, peer representation, peer card, and recent messages. No LLM call. Use when you want to see everything Honcho knows about the current session and peer in one shot.
honcho_reasoningNatural language question answered by Honcho's dialectic reasoning engine (LLM call on Honcho's backend). Higher cost, higher quality. Pass reasoning_level to control depth: minimal (fast/cheap) → low → medium → high → max (thorough). Omit to use the configured default (low). Use for synthesized understanding of the user's patterns, goals, or current state.
honcho_concludeWrite or delete a persistent conclusion about a peer. Pass conclusion: "..." to create. Pass delete_id: "..." to remove a conclusion (for PII removal — Honcho self-heals incorrect conclusions over time, so deletion is only needed for PII). You MUST pass exactly one of the two.
All 5 tools accept an optional peer parameter:
peer: "user" (default) — operates on the user peerpeer: "ai" — operates on this profile's AI peerpeer: "<explicit-id>" — any peer ID in the workspaceExamples:
honcho_profile # read user's card
honcho_profile peer="ai" # read AI peer's card
honcho_reasoning query="What does this user care about most?"
honcho_reasoning query="What are my interaction patterns?" peer="ai" reasoning_level="medium"
honcho_conclude conclusion="Prefers terse answers"
honcho_conclude conclusion="I tend to over-explain code" peer="ai"
honcho_conclude delete_id="abc123" # PII removal
Guidelines for Hermes when Honcho memory is active.
1. honcho_profile → fast warmup, no LLM cost
2. If context looks thin → honcho_context (full snapshot, still no LLM)
3. If deep synthesis needed → honcho_reasoning (LLM call, use sparingly)
Do NOT call honcho_reasoning on every turn. Auto-injection already handles ongoing context refresh. Use the reasoning tool only when you genuinely need synthesized insight the base context doesn't provide.
honcho_conclude conclusion="<specific, actionable fact>"
Good conclusions: "Prefers code examples over prose explanations", "Working on a Rust async project through April 2026" Bad conclusions: "User said something about Rust" (too vague), "User seems technical" (already in representation)
honcho_search query="<topic>" → fast, no LLM, good for specific facts
honcho_context → full snapshot with summary + messages
honcho_reasoning query="<question>" → synthesized answer, use when search isn't enough
peer: "ai"Use AI peer targeting to build and query the agent's own self-knowledge:
honcho_conclude conclusion="I tend to be verbose when explaining architecture" peer="ai" — self-correctionhoncho_reasoning query="How do I typically handle ambiguous requests?" peer="ai" — self-audithoncho_profile peer="ai" — review own identity cardIn hybrid and context modes, base context (user representation + card + session summary) is auto-injected before every turn. Do not re-fetch what was already injected. Call tools only when:
honcho_reasoning on the tool side shares the same cost as auto-injection dialectic. After an explicit tool call, the auto-injection cadence resets — avoiding double-charging the same turn.
Config file: $HERMES_HOME/honcho.json (profile-local) or ~/.honcho/config.json (global).
| Key | Default | Description |
|---|---|---|
apiKey | -- | API key (get one) |
baseUrl | -- | Base URL for self-hosted Honcho |