curl 示例前，先选择 Cloud 区域。需要认证的调用必须使用与密钥同一区域的地址。下方示例都使用 MIROBODY_API_BASE：
store 与 retention 正交，一个管对话，一个管数据面：
retention 管理显式的数据面写入，不管理存储对话。store=true 的对话还可能从内容中抽取出健康记录与持久记忆，这些记录用 DELETE /v1/data 删除，或直接删除该 Subject。store=false 的对话则不会产生任何此类数据。
对话状态（store）
store 默认 true（对齐 OpenAI）。一个被存储的响应持久化三项内容：响应对象（供 GET /v1/responses/{id}）、对话线程（供 previous_response_id 续接），以及该轮次给平台对话记忆贡献的内容。
对未知、已过期或已删除的响应使用
previous_response_id 会返回 404：超过 30 天的链式对话除非绑定了 session_id，否则视为已消失。以客户端工具交接收尾的响应必须先用 function_call_output item 续运行，见 Function calling。清理
DELETE /v1/responses/{id} 总会移除指定的存储响应。只有当它是所在对话的最后一个存活响应时，平台才会拆除对话历史并回撤对话衍生的记忆。见 Agent API → 删除。
跨会话记忆
存储的对话让 agent 记住关于某个 Subject 的持久事实，并在此后的对话中沿用。store: false 的轮次完全置身事外。删除一段对话的最后一个存活响应，才会回撤该对话衍生的记忆；线程中仍有其他响应时，删除较早响应不会回撤共享记忆。
写日记（Journaling）
一条主观日记（比如*「头疼一下午，喝了两杯咖啡后缓解」*）就是一次单轮POST /v1/responses，带 store: true。不需要专用端点：本页讲的这些开关组合起来就是配方。为每条记录分配独立的 session_id（如 journal-{entry_id}），使其不受 30 天 TTL 约束，并可独立删除。builtin_tools: "none" 加上要求单句确认的 instructions，把你并不消费的回复成本压到最低：
- 指标与记忆会自动为你抽出。 Mirobody 会在写入后不久从这条存储条目中抽出可量化指标与持久记忆，与回复本身无关。
- 单条回看用
GET /v1/responses/{id}。不提供列表端点（对齐 OpenAI），请在你自己一侧维护(记录 → response_id)索引。平台是数据/智能层，不是笔记应用。 - 删除单条记录：调用
DELETE /v1/responses/{id}。采用推荐的「每个session_id仅一个响应」设计时，该响应就是对话的最后一个存活响应，其对话衍生记忆也会被回撤。若多个响应共用同一session_id，需将其全部删除后，共享记忆才会被回撤。 - 删除会话范围的工作数据：调用
DELETE /v1/sessions/{id}。此调用不会删除存储响应对象。 - 擦除 Subject：调用
DELETE /v1/subjects/{user}。 - 一个细节：已经抽取进数据面的读数是普通记录，删除日记条目只会回撤记忆，这些读数仍会保留；用
DELETE /v1/data（按id或indicator）或 Subject 级擦除来移除。
数据面留存（retention）
健康记录与文件带有自己的生命周期，设置位置就在数据写入处：POST /v1/data（必填）、POST /v1/files（可选）、POST /v1/standardize（store=true 时必填）。
没有
retention: "none"：写入存储却要求不存储是自相矛盾的。用完即弃的分析请用 POST /v1/standardize 的 store=false（dry-run，零副作用），以 retention: "1h" 写入（自动过期），或使用 retention: "session" 并在用完后删除该会话。
常见用法
另见
- Agent API（Responses）：
store所属的端点。 - 数据生命周期：删除已存响应与 Subject。
- 结构化记录：数据写入处设置的
retention。