# 记忆删除

选择可恢复的 forget 路径，或选择经过明确授权且带有可审计 tombstone 的破坏性模式。

- Canonical: https://docs.xmemo.dev/zh/docs/concepts/memory-deletion
- Locale: zh-CN
- Content-Locale: zh-CN
- Canonical-Content-Digest: 376e4e4ecb3e1fc0955b2cd5176a16a92431ecba87f15d1ded32d8ee3f15f1fd
- Edition-Digest: e244f6d8e0f404eb9df3286fc694ff902b959d7e338af895821880205f43e1ff
- Source-Revision: sha256:ae05ed5a78af519bbe1b86561e36ef07d4758d3bcae57a6df91b7e53e4f5cfff

## 软删除是公开默认值

DELETE /v1/memories/{memory_id} 默认使用 mode=soft_delete。POST /v1/memories/{memory_id}/forget 接受同一 MemoryForgetRequest 系列参数，包括 mode、reason、replacement_content 和 metadata。软删除会创建 tombstone 与 version snapshot，将 memory status 改为 deleted，并且之后可以 restore。

```http
DELETE /v1/memories/<memory-id>?mode=soft_delete&reason=user-requested
X-API-Key: <your-assigned-api-key>
```

## forget、redact 和 hard-delete 是不同模式

persistence engine 接受 soft_delete、redact 和 hard_delete。Redact 会将 content 替换为 [REDACTED]（或提供的 replacement content），清除 metadata 与 embeddings，并记录安全的 redaction provenance。Hard delete 不可逆，并由更强的 memory:hard_delete authorization 路径保护；不要把它作为日常修正手段。

- soft_delete — 带 tombstone 和 version snapshot 的可恢复删除。
- redact — 移除原始 content 与 embedding，同时保留非 content 的 tombstone/result。
- hard_delete — 需要更强 delete capability 的永久移除路径。

## 只恢复软删除的记忆

POST /v1/memories/{memory_id}/restore 接受带有可选 reason 和 metadata 的 MemoryRestoreRequest。持久化路径会将 status 恢复为 active 并递增 version；redacted memory 无法恢复，因为其原始 content 已不可用。

```http
POST /v1/memories/<memory-id>/restore
X-API-Key: <your-assigned-api-key>
Content-Type: application/json

{
  "reason": "owner-confirmed recovery"
}
```

## 删除经过授权并留下审计记录

REST mutation path 会在解析目标前检查特定模式的 memory scope 和 owner-scoped key。它会写入包含请求模式、reason 是否存在以及目标引用的 memory tombstone/audit evidence，但不会暴露已忘记的 content。

## ChatGPT 用户

让 ChatGPT 持久访问你的 XMemo 偏好、项目事实、决策和 TODO，同时不把 bearer token 粘贴到聊天里。

通过 ChatGPT/OpenAI app 的 OAuth 流程连接托管 XMemo MCP server，然后为你的 XMemo 账户批准 memory:read 与 memory:write 授权。

保存一条合成偏好或项目笔记，开启新聊天，再让 ChatGPT 在继续工作前通过 XMemo 召回它。

如果 OAuth 失败或工具未出现，先在宿主应用里退出该 MCP server，重新连接 XMemo server URL 并重试，再考虑创建 direct token。

## Copilot / Codex 开发者

在 IDE 与 CLI agent 之间携带仓库决策、编码规范、bug 修复说明和任务历史。

在可用时对 VS Code / GitHub Copilot 和 Gemini CLI 使用 OAuth。对于 Copilot CLI、Codex、Cursor 或其他直连 MCP 客户端，请在本地环境或密钥存储中保留 XMEMO_KEY，并设置稳定的 XMEMO_AGENT_INSTANCE_ID。

记录一条代码库决策或 bug 修复，然后让下一个 IDE 或 CLI agent 在编辑前召回相关 XMemo 上下文。

如果召回为空，检查所选 MCP 配置路径、direct client 的 XMEMO_KEY 环境变量，以及宿主应用中是否存在过期 OAuth 凭据。

## 团队 / 企业 pilot owner

用账户控制、来源归因、导出/删除流程和 reviewer-safe 设置证据来评估共享记忆。

创建或进入受保护的 XMemo workspace，邀请已批准用户，然后根据 readiness badges 通过 OAuth 或 scoped direct credential 连接各客户端。

让一名 pilot 成员保存一条合成团队记忆，在 XMemo 中确认来源归因，然后审阅删除/导出和支持路径。

如果成员无法连接，先检查角色权限、OAuth 批准、客户端 readiness 状态和支持指引，再签发新 token。

## 自主 agent operator

让 headless 或定时 agent 记录进度、取回历史决策，并保持稳定的非秘密实例身份。

获取 /api/v1/mcp/config/autonomous-agent。当 runner 支持 OAuth + 自定义 headers 时优先使用 auth_modes.oauth；只有完全 headless 的 runner 才使用 auth_modes.xmemo_key，并从密钥库读取 XMEMO_KEY。

运行一个会向 XMemo 写入进度的合成任务，重启 runner，并确认它使用同一个 XMEMO_AGENT_INSTANCE_ID 召回该进度。

如果归因变化或召回分散到多个实例，请把 XMEMO_AGENT_INSTANCE_ID 持久化到 git 之外，并确认 runner 不会每次启动都重新生成它。