待翻译：When AI Memory Becomes Production State

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

Disclosure: These views are my own and do not represent my current or any former employers. Executive summary An agent that forgets can inconvenience a user. An agent that remembers the wrong thing can keep making the same mistake. Persistent memory changes the failure model of an AI system. A generated answer normally affects one interaction. A stored preference, business fact, summary, or procedure can influence many later interactions without the original source being visible. The effect can cross sessions, devices, users, agents, and software versions. Once persisted memory can influence later reasoning or actions, it becomes production state. It needs an owner, provenance, access boundaries, freshness rules, conflict handling, retention, deletion, observability, and recovery. Current agent platforms already expose many of these controls. Microsoft Foundry supports scoped memory stores, item-level create, read, update, and delete operations, default time to live, and separate user-profile, chat-summary, and procedural memory types.[1][2] Google Memory Bank provides identity scoping, consolidation, automatic expiry, revision history, and restrictive IAM conditions.[4] LangGraph separates thread checkpoints from cross-thread stores and documents retention requirements for growing checkpoint histories.[7] Letta allows memory blocks to be shared across agents or made read-only.[8] These features show that memory is already being implemented as a data system, even when product language presents it as personalisation or continuity. The reliability risks are also visible. A Mem0 issue reports that partial embedding failures can silently drop extracted memories while returning a normal result to the caller.[13] Another describes old and new employment facts coexisting because an additive extraction path does not automatically supersede the earlier fact.[12] A Claude Code issue describes concurrent sessions racing on a shared memory file and losing an update.[15] Cisco research demonstrated persistent memory poisoning that influenced Claude Code across projects, sessions, and reboots before Anthropic changed the affected trust path.[16] Research benchmarks show a more general quality problem. LoCoMo found that long-context and retrieval-based approaches still lagged human performance on long-range conversational memory, while LongMemEval reported a substantial accuracy drop during sustained interactions and separated memory performance into indexing, retrieval, and reading stages.[18][19] Security research adds a different concern: AgentPoison demonstrated in a controlled setting that a very small proportion of poisoned memory entries could influence later agent behaviour while leaving benign performance largely unchanged.[20] Controls should vary with consequence because universal retention and universal deletion are both poor defaults. Different memory classes create different obligations: Temporary working context should be bounded to a task or session. User preferences should be visible, correctable, and scoped to the right identity. Business facts should carry provenance, observation time, and a freshness policy. Procedural memory should be versioned, tested, approved, and reversible. Memory used for consequential actions should never replace an authoritative system of record or deterministic policy check. This paper proposes a memory reliability lifecycle: capture, validate, classify, persist, consolidate, retrieve, apply, correct, expire, delete, and audit. Each stage has a different proof obligation. Write success confirms persistence, not the quality of the stored fact; retrieval relevance says nothing about freshness; and a deletion response may cover one copy while leaving summaries, logs, or downstream artifacts intact. Model-generated consolidation can remove duplication while also erasing a material distinction. Useful measures therefore focus on observable properties rather than claiming to measure truth directly. Examples include confirmed write durability, provenance coverage, cross-scope isolation tests, contradiction density, correction propagation time, expiry latency, deletion completeness within a declared scope, and the percentage of consequential actions with an inspectable record of which memories influenced them. Reliable memory remembers selectively through bounded, inspectable, and correctable state. The system should know where each memory came from, who it belongs to, when it should stop being trusted, and what must happen before it can influence a consequential action. 1. Memory changes the failure model Stateless systems have familiar limitations. They lose continuity, repeat questions, and force users to restore context. Memory improves that experience by carrying useful information forward. Persistence also carries mistakes forward. Suppose a user tells a travel agent that they prefer a window seat. Remembering that preference is convenient and low risk. If the user later needs an aisle seat for accessibility reasons, the original preference must stop controlling the result. The same pattern becomes more serious in business workflows: a support agent remembers an entitlement that has expired; a coding agent preserves an obsolete security exception; an operations agent recalls a mitigation that is unsafe after an architecture change; a procurement agent retains an old approval limit; a multi-agent workflow shares a corrupted procedure; an assistant associates one user's information with another user's scope. The immediate model output may be fluent and internally consistent. The failure began earlier, when the system wrote, retained, merged, retrieved, or trusted the wrong memory. This creates a delayed failure path: an interaction produces a candidate memory; the memory is persisted outside the active conversation; later retrieval presents it as useful context; the model treats it as evidence or instruction; an output or action reflects the stored error. The original source may no longer be available to the user, reviewer, or operator. Without provenance and revision history, the system can explain what it remembered but not why it believed the memory deserved trust. Memory therefore changes more than personalisation. It changes where defects can live, how long they can persist, and how widely they can propagate. 2. Memory classes create different obligations Product documentation uses different names for memory, and the boundaries are not standardised. A practical reliability model still needs categories because the same controls do not fit every form of retained state. Memory class Typical content Useful lifetime Main reliability concern Working context Current messages, tool results, active plan One task or session Unbounded growth, compaction loss, stale intermediate state User preference Language, format, accessibility need, product default Until corrected or expired Wrong identity, outdated preference, opaque correction Episodic memory Prior interactions, events, summaries, outcomes Task-dependent Missing context, distorted summary, temporal confusion Semantic or business fact Account status, project decision, ownership, environment detail Until source changes Staleness, contradiction, weak provenance Procedural memory Steps, checks, tool sequence, learned operating pattern Until process or system changes Repeated unsafe behaviour, unreviewed drift Shared memory State used by several agents, users, or services Task- or system-dependent Large blast radius, concurrent writes, scope leakage Working context Working context supports the task in progress. LangGraph models this through thread-scoped checkpoints, while AWS describes short-term memory as turn-by-turn state within a session.[5][7] It may be temporary, but it still needs lifecycle controls. Long sessions can grow without bound. Compaction can remove material details. A crash can leave the system uncertain about which step completed. Working context becomes durable state when it is checkpointed for recovery or resumption. At that point, retention and replay semantics matter. User preferences Preference memory creates continuity without asking the same questions again. Microsoft, AWS, OpenAI, Google, and other platforms all describe this as a central use case.[1][5][10][11] Preferences are assertions with a source and a date, not timeless facts. "Prefers email" may be valid for one account, one workflow, or one period. Systems should preserve that context rather than reducing every statement to a permanent global attribute. Episodic memory Episodic memory records what happened. It may contain a conversation summary, incident outcome, prior task result, or model reflection. Summaries reduce context size, but they also compress evidence. A summary can omit an exception, turn uncertainty into certainty, or combine events that should remain separate. Keeping the source link and generation version allows later review. Semantic and business facts These memories represent durable knowledge such as a project decision, user role, service owner, or current account state. Dynamic business facts should usually remain in their authoritative systems. Memory can help locate or interpret them, but a consequential action should revalidate the current value at the source. Mem0's documentation illustrates the update problem. Its automatic extraction path is additive: a move from one city to another can create a new memory without rewriting the old one. Applications must use explicit update or delete operations when they need correction.[9] Procedural memory Procedural memory stores how work should be performed. Microsoft describes it as reusable routines inferred from earlier interactions, including when to use a procedure and which ordered actions and checks it contains.[1][3] This memory has greater consequence than a preference. A wrong preference may produce an inconvenient answer. A wrong procedure can repeat an unsafe action across many tasks. Procedural memory should therefore resemble versioned operational policy. It needs an owner, tests, approval, rollout boundaries, and rollback. Shared memory AWS documents multi-agent memory as a way for agents to coordinate a shared workflow. Letta allows several agents to attach to the same persistent memory block, where one update becomes visible to all of them.[5][8] Sharing can reduce duplicated state. It also expands the blast radius of a bad write and introduces concurrency questions that do not appear in private memory. 3. How memory becomes trusted Most long-term memory systems perform several operations between a conversation and a later action. Anthropic's memory tool makes one part of the responsibility explicit. Claude requests file operations, while the application owns storage, persistence, and the controls that keep access inside the intended memory path.[6] Extraction The system decides which parts of an interaction are worth retaining. This is often an LLM task. Microsoft describes extracting preferences, facts, and context from conversations. Mem0 extracts durable facts before embedding and storing them.[1][9] Extraction is a policy decision. A system can store too little, too much, or the wrong abstraction. It may preserve an inference as though the user stated it directly. A memory record should distinguish: direct user statement; observation from an authoritative system; tool result; model inference; summary or consolidation; procedure learned from prior execution. These sources deserve different levels of trust. Consolidation New information may duplicate, refine, contradict, or supersede existing memory. Google and Microsoft document consolidation features intended to merge related information and evolve memories over time.[1][4] Consolidation saves space and reduces retrieval noise. It can also destroy history. A [truncated for AI cost control]