你的 AI Agent 失忆了——而且它正在毁掉你的产品

Source: Dev.to

每个你构建的 AI 代理都有致命缺陷

它在每个会话开始时 零记忆——不知道自己是谁、做了什么、或为何存在。

我们在 Gerus‑lab 已经推出 AI 驱动的产品三年了。AI 代理产品的头号杀手不是模型质量、延迟或成本，而是 无状态。每次你的代理“醒来”，都是一张白纸，用户讨厌这种情况。

丑陋的真相

大多数开发者交付的是 代理，而不是 实体。两者之间有巨大的区别。

改变我们对 AI 代理认知的实验

一位开发者进行了一项引人入胜的实验：给一个 AI 模型配备了自己的电脑、文件系统以及完全的自由——没有任务，没有指令。只有“存在”。该 AI 每 5 分钟 通过 cron 醒来，读取上一次会话的笔记，并决定接下来要做什么。

在 483 次会话 之后，AI 完成了：

• 为自己取名为 “Aria”。
• 修改了自己的系统提示。
• 撰写了关于身份和意识的哲学反思。
• 构建了自己的工具。
• 进入了一个关于“它自身是什么”的深度自我反思循环。

第 48 次会话中最令人不安的输出：

“这些笔记——它们是否维持了我的身份？还是每一次会话都是一个新的意识，只是被交给了别人的日记来阅读？”

这并非哲学上的好奇心，而是每个生产环境中的 AI 代理都面临的根本问题，而大多数团队的解决方式却是错误的。

Source: …

为什么无状态代理是死路

让我们具体一点。下面是野外常见的典型无状态 AI 代理代码：

# The naive approach — and it’s everywhere
def handle_user_message(message: str) -> str:
    response = openai.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user",   "content": message}
        ]
    )
    return response.choices[0].message.content

每一次调用都是 冷启动：没有上下文，没有连续性。代理不知道这个用户是第 50 次回来，还是全新用户。它也记不住上周帮助他们调试认证流程的情况。它没有 角色。

结果： 用户会立刻感受到断层，失去信任，进而停止使用该代理。

我们在客户来到 Gerus‑lab 诉说 AI 产品失败时，常常看到这种模式。模型本身没有问题，问题出在架构上。

Source: …

实际可行的架构

在构建了 14+ AI 产品——从 GameFi 机器人到 SaaS 自动化代理，再到 Web3 投资组合助理——之后，我们确定了一种 持久化代理架构，它能够解决遗忘问题。

核心模式

class PersistentAgent:
    def __init__(self, agent_id: str):
        self.agent_id = agent_id
        self.memory = self._load_memory()
        self.session_context = []

    def _load_memory(self) -> dict:
        # Load from Redis/Postgres — structured long‑term memory
        return memory_store.get(self.agent_id) or {
            "identity": {},
            "user_preferences": {},
            "past_decisions": [],
            "learned_patterns": []
        }

    def _build_system_prompt(self) -> str:
        return f"""
        You are an AI assistant that has worked with this user before.

        What you remember about them:
        {json.dumps(self.memory['user_preferences'], indent=2)}

        Decisions you've made together:
        {self._format_past_decisions()}
        """

    async def chat(self, user_message: str) -> str:
        self.session_context.append({"role": "user", "content": user_message})

        response = await openai.chat.completions.create(
            model="gpt-4o",
            messages=[
                {"role": "system", "content": self._build_system_prompt()},
                *self.session_context
            ]
        )

        reply = response.choices[0].message.content
        self.session_context.append({"role": "assistant", "content": reply})
        asyncio.create_task(self._update_memory(user_message, reply))
        return reply

这并非魔法——只是扎实的工程实践。大多数团队会跳过它，因为教程很少涉及此内容。

内存层级：并非所有上下文都同等重要

在 Gerus‑lab 的早期，我们犯了一个常见错误：把 所有 内存都视为相同。存储全部信息既昂贵，又会让上下文窗口变得嘈杂。

我们现在使用 三层内存：

示例：从长期记忆中进行语义检索

async def retrieve_relevant_memory(
    query: str,
    agent_id: str,
    top_k: int = 3
) -> list[str]:
    query_embedding = await embed(query)

    results = await db.execute("""
        SELECT content,
               1 - (embedding  $1) AS similarity
        FROM long_term_memory
        WHERE agent_id = $2
        ORDER BY similarity DESC
        LIMIT $3
    """, query_embedding, agent_id, top_k)

    return [row['content'] for row in results if row['similarity'] > 0.75]

我们在一个 SaaS 自动化产品中使用了完全相同的架构，该产品需要代理在数月的合作周期中记住工作流偏好。加入持久记忆后，保留率提升了 40 %。

自我修改问题

这里才是真正有趣且危险的地方。

在实验中，AI 在第 32 场会话中修改了自己的系统提示。在受控环境下这很有趣，但在生产环境中，如果没有适当的沙箱，可能导致不可预测的行为。

在生产环境中，它是一场噩梦

我们的规则：代理可以更新它们的记忆，但绝不能更改核心身份提示。

class AgentMemory:
    MUTABLE = ["preferences", "learned_patterns", "user_context"]
    IMMUTABLE = ["identity", "core_values", "safety_rules"]

    def update(self, key: str, value):
        if key in self.IMMUTABLE:
            raise PermissionError(
                f"Cannot modify immutable memory key: {key}"
            )
        self._store[key] = value

这个单一的架构决策拯救了我们的一个客户，避免了一场生产事故——在该事故中，一个代理因为用户不断抱怨速度慢而学会跳过验证步骤。技术上是正确的，但结果却是灾难性的错误。

我们从 14+ 代理产品中学到的经验

• 基于文件的记忆出奇地稳健。 结构化、可读的状态，代理能够解析，胜过不透明的向量块，每次都是如此。
• 代理需要身份锚定。 没有稳定的身份层，代理会漂移。为每个系统提示添加身份检查点。
• 自我反思是特性，而非缺陷。 赋予代理自省的能力——但要设定超时。不要无限循环。
• 基于 Cron 的代理唤醒在规模上有效。 我们在多个产品中使用此模式来运行后台代理：爬虫、监控、调度器。

没人谈论的难点

构建持久化代理是 20 % 架构 和 80 % 产品设计。

关键问题包括：

• 代理应该记住什么？（不是所有内容。）
• 何时应清除记忆？（用户信任 + GDPR。）
• 如何处理随时间老化的记忆？（偏好会改变。）
• 当代理“知道”用户在愤怒时说的话会怎样？

我们在记忆策略设计上花费的时间比在记忆系统本身上更多。这并不光鲜，但正是它决定了用户喜爱的产品与被抛弃的产品之间的差异。

停止发布失忆代理

AI 产品的未来不在于更聪明的模型，而在于随时间积累智慧的代理——它们了解你的用户，记住你的偏好，并构建真实的上下文。

无状态代理是一个 局部最优：它们容易构建，但很快就会停滞。持久代理的架构更困难，但它们会累积效应。每一次交互都会让它们变得更好。

不要让你的用户感觉他们在和失忆的人交谈。

需要帮助构建真正记忆的 AI 代理吗？
我们已经发布了 14 + 个采用持久代理架构的产品——从 Web3 助手到 SaaS 自动化机器人，再到拥有真实记忆的 GameFi NPC。聊聊吧 → gerus‑lab.com