tomtan/memory-gateway
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

添加内存管理工具和用户密钥支持，更新文档和测试用例

Browse Source
This commit is contained in:
tomtan
2026-06-02 10:09:21 +08:00
parent 68b2513043
commit 1b5fee9866
9 changed files with 653 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
skills/memory-system-api/SKILL.md
View File

@ -1,6 +1,6 @@
---
name: memory-system-api
description: "Use when an AI agent needs to operate this repository's Memory System API, including creating users, writing session messages, committing or extracting memory, searching memories, reading profiles, or debugging OpenViking/EverOS backend results."
description: "Use when an AI agent needs to operate this repository's Memory System API, including creating users, writing session messages, committing or extracting memory, managing memory URIs, searching memories, reading profiles, or debugging OpenViking/EverOS backend results."
---
# Memory System API
@ -26,13 +26,13 @@ Do not assume business APIs will auto-create users. Non-user-creation endpoints
- `user_key`: OpenViking key returned when the user is created.
- `session_id`: conversation ID and OpenViking session ID.
Internally the gateway always uses the fixed OpenViking admin workspace:
Internally the gateway creates one isolated OpenViking account per business user:
```json
{"account_id": "admin", "admin_user_id": "admin"}
{"account_id": "<user_id>_account", "admin_user_id": "<user_id>"}
```
On the first user creation, if the admin workspace is not stored in SQLite yet, the gateway creates it first and then creates the requested user. After that, later users go straight to `/api/v1/admin/accounts/admin/users`.
The gateway does not call `/api/v1/admin/accounts/admin/users`. User creation goes through `/api/v1/admin/accounts`, stores the returned `user_key`, and later business calls use that user key directly.
The SQLite store is the source of truth for:
@ -44,8 +44,9 @@ The SQLite store is the source of truth for:
Session memory is retrieved under OpenViking using the explicit user/session URI paths:
```text
viking://user/<user_id>/memories/
viking://user/<user_id>/<session_id>
viking://user/memories
viking://user/memories/...
viking://user/<session_id>
```
## Endpoints
@ -65,6 +66,8 @@ Base path: `/memory-system`
| `GET` | `/memories/content` | Read one OpenViking memory URI | Yes |
| `POST` | `/memories` | Create, replace, or append an OpenViking memory via `content/write` | Yes |
| `DELETE` | `/memories` | Delete an OpenViking memory URI via `fs` | Yes |
| `POST` | `/resources` | Upload local file or remote URL to OpenViking resources | Yes |
| `DELETE` | `/resources` | Delete OpenViking resource URI via `fs` | Yes |
| `POST` | `/search` | Search OpenViking and EverOS | Yes |
| `GET` | `/users/{user_id}/profile` | Read EverOS profile | Yes |
@ -195,6 +198,8 @@ curl -sS -X DELETE -G "$BASE/memory-system/memories" \
--data-urlencode "recursive=false"
```
For directory-like or composite memories, retry deletion with `recursive=true` only after OpenViking reports that recursive deletion is required.
## Response Handling
Top-level `status` is one of:
@ -213,6 +218,8 @@ Session context responses include OpenViking context under `context`, EverOS rec
- Omitting `user_key` on business calls.
- Sending `account_id` to business APIs.
- Confusing `X-API-Key` with `user_key`.
- Assuming memory updates use a PATCH endpoint; use `POST /memory-system/memories` with `mode=replace` or `mode=append`.
- Deleting memories recursively by default; use `recursive=false` unless the target is a directory or composite resource.
- Expecting `backends.everos.result` to still contain full `episodes` or `original_data`.
- Assuming the gateway stores these values only in memory; it persists them in SQLite.