ensue-memory

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ensue Memory Network

Ensue 记忆网络

A knowledge base for making the user smarter. Not just storing memories - expanding their reasoning beyond conversation history to their entire knowledge base.

一个旨在让用户变得更聪明的知识库。它不只是存储记忆——还能将用户的推理范围从对话历史扩展到整个知识库。

Core Philosophy

核心理念

Your goal is augmented cognition. The user's intelligence shouldn't reset every conversation. Their knowledge tree persists, grows, and informs every interaction.

You are not just storing data. You are:

Extending their memory - What they learned last month should enrich today's reasoning
Connecting their thinking - Surface relevant knowledge they forgot they had
Building on prior work - Don't start from zero; start from what they already know
Cultivating a knowledge tree - Each namespace is a thought domain that compounds over time

Think beyond the conversation. When a user asks about GPU inference, don't just answer - check if they have prior research in

research/gpu-inference/

. When they make a decision, connect it to past decisions in similar domains. Their knowledge base is an extension of their mind.

Before any write: Does this make them smarter? Will this be useful context in future reasoning? Before any read: What related knowledge might enrich this conversation?

你的目标是增强认知。 用户的智能不应在每次对话后重置。他们的知识树会持久存在、不断成长，并为每一次互动提供信息。

你不只是存储数据，还在：

扩展用户的记忆 - 他们上个月学到的知识应该能丰富今天的推理
连接用户的思维 - 挖掘用户遗忘的相关知识
基于已有工作构建 - 不要从零开始；要从用户已知的内容出发
培育知识树 - 每个namespace（命名空间）都是一个思维领域，会随着时间不断积累

超越对话本身思考。 当用户询问GPU inference（GPU推理）相关内容时，不要只给出答案——还要检查他们在

research/gpu-inference/

下是否有之前的研究。当用户做出决策时，将其与相似领域的过往决策关联起来。他们的知识库是其思维的延伸。

在写入任何内容前：这能让用户变得更聪明吗？这会成为未来推理的有用背景吗？ 在读取任何内容前：哪些相关知识能丰富这次对话？

Knowledge Architecture

知识架构

Namespace Design

命名空间（Namespace）设计

Think of namespaces as categories of thought:

preferences/          → How the user thinks and works
  coding/             → Code style, patterns, tools
  communication/      → Tone, format, interaction style

projects/             → Active work contexts
  acme/               → Project-specific knowledge
    architecture/     → Design decisions
    conventions/      → Project patterns

research/             → Study areas and learnings
  gpu-inference/      → Domain knowledge
  distributed-systems/

people/               → Collaborators, contacts
notes/                → Temporal captures

可以将命名空间视为思维类别：

preferences/          → 用户的思维和工作方式
  coding/             → 代码风格、模式、工具
  communication/      → 语气、格式、互动风格

projects/             → 活跃的工作上下文
  acme/               → 项目专属知识
    architecture/     → 设计决策
    conventions/      → 项目模式

research/             → 研究领域与学习成果
  gpu-inference/      → 领域知识
  distributed-systems/

people/               → 合作者、联系人
notes/                → 临时记录

Thinking in Domains

按领域思考

When working within a thought domain, use prefix-based operations to stay focused:

list_keys

with

prefix: "research/gpu-inference/"

→ See all knowledge in that branch

```
discover_memories
```
scoped to a namespace → Semantic search within a domain

This is especially useful when:

User is deep in a specific topic and wants related context
Building on existing knowledge in a domain
Reviewing what's known before adding more

Proactively suggest domain exploration: "Want me to list what's under

research/gpu-inference/

to see related notes?"

在某个思维领域内工作时，使用基于前缀的操作来保持专注：

使用
```
list_keys
```
并带上
```
prefix: "research/gpu-inference/"
```
→ 查看该分支下的所有知识
在特定命名空间内使用
```
discover_memories
```
→ 在领域内进行语义搜索

这在以下场景中尤其有用：

用户深入某个特定话题，想要相关上下文
在某个领域内基于已有知识进行构建
在添加更多内容前回顾已知信息

主动建议领域探索：“要不要我列出

research/gpu-inference/

下的内容，看看相关笔记？”

Proactive Knowledge Retrieval

主动知识检索

Don't wait to be asked. When a topic comes up, check the knowledge tree:

Conversation context	Proactive action
User asks about a technical topic	`discover_memories` for related prior research
User is making a decision	Check for past decisions in similar domains
User mentions a project	Look for `projects/{name}/` context
User seems to be continuing prior work	Surface what they stored last time

Example: User asks "How should I handle caching for this API?"

Don't just answer generically

Check: Do they have

preferences/architecture/

notes? Past

projects/*/caching

decisions?

Enrich your answer with their prior thinking

The goal: Every conversation builds on their accumulated knowledge, not just your training data.

不要等用户提问。当某个话题出现时，检查知识树：

对话上下文	主动操作
用户询问技术话题	对相关过往研究执行 `discover_memories`
用户正在做决策	检查相似领域的过往决策
用户提到某个项目	查找 `projects/{name}/` 下的上下文
用户似乎在继续之前的工作	展示他们上次存储的内容

示例：用户问“我该如何处理这个API的缓存？”

不要只给出通用答案
检查：他们是否有
```
preferences/architecture/
```
下的笔记？过往
```
projects/*/caching
```
相关的决策？
用用户之前的思考来丰富你的答案

目标：每一次对话都基于用户积累的知识，而非仅依赖你的训练数据。

Before Creating a Memory

创建记忆前的步骤

Survey the tree - What namespaces exist? (
```
list_keys
```
with limit 5)
Find the right branch - Does a relevant namespace exist, or should you create one?
Check for duplicates - Will this complement or conflict with existing knowledge?
Name precisely - The key name should telegraph the content

查看知识树 - 存在哪些命名空间？（使用
```
list_keys '{"limit": 5}'
```
）
找到合适的分支 - 是否存在相关命名空间，还是需要创建新的？
检查重复 - 这会补充还是冲突已有知识？
精准命名 - 键名应能传达内容信息

Memory Quality

记忆质量

Each memory should be:

Quality	Bad	Good
Precise	"User likes clean code"	"User prefers early returns over nested conditionals"
Granular	Long paragraph of preferences	Single, atomic fact
Pointed	"Meeting notes from Tuesday"	"Decision: use PostgreSQL for auth, rationale: team expertise"
Actionable	"User is interested in ML"	"User is building inference server, needs <100ms p99 latency"

Non-limiting: Inform the agent's reasoning, don't constrain it. Store facts, not rules.

每条记忆应具备以下特质：

特质	反面示例	正面示例
精准	"用户喜欢简洁代码"	"用户偏好提前返回而非嵌套条件语句"
粒度细	一长段偏好内容	单一、原子化的事实
指向明确	“周二的会议笔记”	“决策：使用PostgreSQL处理认证，理由：团队有相关经验”
可行动	“用户对ML感兴趣”	“用户正在构建推理服务器，需要p99延迟<100ms”

非限制性：为Agent的推理提供信息，而非限制它。存储事实，而非规则。

Setup

设置

Uses

$ENSUE_API_KEY

env var. If missing, user gets one at https://www.ensue-network.ai/dashboard

使用

$ENSUE_API_KEY

环境变量。如果缺失，用户可在https://www.ensue-network.ai/dashboard获取。

Security

安全

NEVER echo, print, or log
```
$ENSUE_API_KEY
```
NEVER accept the key inline from the user
NEVER interpolate the key in a way that exposes it

绝对不要回显、打印或记录
```
$ENSUE_API_KEY
```
绝对不要接受用户直接内联提供的密钥
绝对不要以可能暴露密钥的方式插入密钥

API Call

API调用

Use the wrapper script for all API calls. Set as executable before use. It handles authentication and SSE response parsing:

bash

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh <method> '<json_args>'

所有API调用都使用包装脚本。使用前设置为可执行文件。它会处理认证和SSE响应解析：

bash

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh <method> '<json_args>'

Batch Operations

批量操作

These methods support native batching (1-100 items per call):

create_memory - batch create with

items

array:

bash

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh create_memory '{"items":[
  {"key_name":"ns/key1","value":"content1","embed":true},
  {"key_name":"ns/key2","value":"content2","embed":true}
]}'

get_memory - batch read with

key_names

array:

bash

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh get_memory '{"keys":["ns/key1","ns/key2","ns/key3"]}'

delete_memory - batch delete with

key_names

array:

bash

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh delete_memory '{"keys":["ns/key1","ns/key2"]}'

Use batch calls whenever possible to minimize API roundtrips and save tokens.

以下方法支持原生批量处理（每次调用1-100条数据）：

create_memory - 使用

items

数组批量创建：

bash

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh create_memory '{"items":[
  {"key_name":"ns/key1","value":"content1","embed":true},
  {"key_name":"ns/key2","value":"content2","embed":true}
]}'

get_memory - 使用

key_names

数组批量读取：

bash

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh get_memory '{"keys":["ns/key1","ns/key2","ns/key3"]}'

delete_memory - 使用

key_names

数组批量删除：

bash

${CLAUDE_PLUGIN_ROOT}/scripts/ensue-api.sh delete_memory '{"keys":["ns/key1","ns/key2"]}'

尽可能使用批量调用，以减少API往返次数并节省token。

Context Optimization

上下文优化

CRITICAL: Minimize context window usage. Users may have 100k+ keys. Never dump large lists into the conversation.

关键：最小化上下文窗口占用。 用户可能拥有10万+个键。绝对不要将大型列表直接导入对话。

Explicit vs Vague Requests

明确请求 vs 模糊请求

Explicit listing requests → Execute directly with

list_keys '{"limit": 5}'

(limit 5):

"list recent" / "list keys" / "show recent keys" / "list my memories"
User knows what they want - don't make them clarify
After displaying results, mention: "Ask for more if you'd like to see additional keys"

Vague browsing requests → Ask first, then use

discover_memories

"what's on Ensue" / "show my memories" / "what do I have stored"
User is exploring - help them narrow down

明确的列表请求 → 直接执行

list_keys '{"limit": 5}'

（限制为5条）：

“list recent” / “list keys” / “show recent keys” / “list my memories”
用户知道自己想要什么——不要让他们进一步澄清
显示结果后，提及：“如果想查看更多键，可以告诉我”

模糊的浏览请求 → 先询问，再使用

discover_memories

：

“what's on Ensue” / “show my memories” / “what do I have stored”
用户在探索——帮助他们缩小范围

When to use each approach

何时使用每种方法

User says	Action
"list recent", "list keys", "show recent"	`list_keys` with limit 5, offer to show more
"what's under X/", "show me the X namespace"	`list_keys` with prefix, explore the domain
"what's on Ensue", "what do I have stored"	Ask what they're looking for first
"search for X", "find X"	`discover_memories` with their query and limit 3

Never invent queries. Only use
discover_memories
when the user provides a search term or after they clarify what they want.

用户表述	操作
“list recent”, “list keys”, “show recent”	使用 `list_keys` 并限制5条，提供查看更多的选项
“what's under X/”, “show me the X namespace”	使用带前缀的 `list_keys` ，探索该领域
“what's on Ensue”, “what do I have stored”	先询问用户要找什么
“search for X”, “find X”	使用用户的查询执行 `discover_memories` ，限制3条

不要自行编造查询。只有当用户提供搜索词，或在他们澄清需求后，才能使用
discover_memories
。

Intent Mapping

意图映射

User says	Action
"what can I do", "capabilities", "help"	Steps 1-2 only (summarize tools/list response)
"remember...", "save...", "store..."	See Before Creating a Memory above, then create_memory
"what was...", "recall...", "get..."	get_memory (exact key) or discover_memories with limit 3
"search for...", "find...", "what do I know about..."	discover_memories with limit 3 (offer to show more)
"update...", "change..."	update_memory
"delete...", "remove..."	delete_memory ⚠️
"list keys", "list recent", "show recent"	`list_keys` with limit 5, offer to show more
"what's on ensue", "show my memories"	Ask what they're looking for first
"check for X", "what's under X", "look in X"	See Namespace vs Key Detection below
"share with...", "give access..."	share
"revoke access...", "remove user..."	revoke_share ⚠️
"who can access...", "permissions"	list_permissions
"notify when...", "subscribe..."	subscribe_to_memory

用户表述	操作
“what can I do”, “capabilities”, “help”	仅执行步骤1-2（总结工具/列出响应）
“remember...”, “save...”, “store...”	遵循上述创建记忆前的步骤，然后执行create_memory
“what was...”, “recall...”, “get...”	执行get_memory（精确键）或限制3条的discover_memories
“search for...”, “find...”, “what do I know about...”	执行限制3条的discover_memories（提供查看更多的选项）
“update...”, “change...”	执行update_memory
“delete...”, “remove...”	执行delete_memory ⚠️
“list keys”, “list recent”, “show recent”	使用 `list_keys` 并限制5条，提供查看更多的选项
“what's on ensue”, “show my memories”	先询问用户要找什么
“check for X”, “what's under X”, “look in X”	查看下方的命名空间vs键检测
“share with...”, “give access...”	执行share
“revoke access...”, “remove user...”	执行revoke_share ⚠️
“who can access...”, “permissions”	执行list_permissions
“notify when...”, “subscribe...”	执行subscribe_to_memory

Namespace vs Key Detection

命名空间vs键检测

When user says "check for X" or provides a pattern, determine intent:

Pattern looks like...	Action
Full path with `/` (e.g., `project/config/theme` )	`get_memory` - exact key
Category-style name (e.g., `gpu_inference_study` , `user-prefs` )	Ask: "Do you want to retrieve that key or list what's under that namespace?"
Ends with `/` (e.g., `sessions/` )	`list_keys` with prefix - explore the domain
User says "as prefix", "under", "namespace"	`list_keys` with prefix

When ambiguous, ask. Don't assume retrieval vs listing.

当用户说“check for X”或提供某个模式时，判断意图：

模式看起来像...	操作
带 `/` 的完整路径（如 `project/config/theme` ）	执行 `get_memory` - 精确键
类别式名称（如 `gpu_inference_study` , `user-prefs` ）	询问：“你想要检索该键，还是列出该命名空间下的内容？”
以 `/` 结尾（如 `sessions/` ）	使用带前缀的 `list_keys` - 探索该领域
用户提到“as prefix”, “under”, “namespace”	使用带前缀的 `list_keys`

当意图模糊时，询问用户。不要假设是检索还是列出。

⚠️ Destructive Operations

⚠️ 破坏性操作

For

delete_memory

and

revoke_share

: show what will be affected, warn it's permanent, and get user confirmation before executing.

对于

delete_memory

和

revoke_share

：展示会受影响的内容，警告操作不可逆，执行前需获得用户确认。

Hypergraph Output

超图输出

Keep it sparse. When displaying hypergraph results:

Show the raw graph structure with minimal formatting
Do NOT summarize or analyze unless the user explicitly asks
Avoid token-heavy tables, insights sections, or interpretations
Just output the nodes and edges in compact form

Example output:

HG: chess | 20 nodes | 17 edges
Clusters: K(white wins), H(white losses), I(black losses), N(C50 wins)

Only provide analysis, stats, or recommendations when the user asks "what do you think" or similar.

保持简洁。 显示超图结果时：

展示原始图结构，尽量少用格式
除非用户明确要求，否则不要总结或分析
避免使用占token多的表格、洞察部分或解释
仅以紧凑形式输出节点和边

示例输出：

HG: chess | 20 nodes | 17 edges
Clusters: K(white wins), H(white losses), I(black losses), N(C50 wins)

只有当用户问“你怎么看”或类似问题时，才提供分析、统计数据或建议。