usehook - 前端码易

如果对调度机制掌握还不够深入，可以跳转到 React 源码专栏中学习。

1. 无状态的挑战

NOTE

HTTP 协议是无状态的，但用户与 Agent 的交互是连续的。

在构建智能 Agent（特别是 AI 伴侣）时，我们需要处理跨越多次交互的上下文信息。由于底层 LLM（大语言模型）本身是无状态的，每一次请求对于模型来说都是全新的。

AI 电子女友本质是「长期存在的关系型 Agent」，而不是「单轮问答工具」。

关系意味着——记忆、阶段、情绪连续性、角色一致性、长期目标演化。而大模型本身只是一台「有限窗口的概率预测机器」。如果不做上下文调度，中长期关系一定崩。

1.1 会话延续性问题

当用户与 AI 伴侣聊天时，他们期望 AI 能够记住之前的对话内容：名字、喜好、刚刚讨论过的话题等。如果每次请求都只发送当前这句话，AI 将无法理解上下文，导致回复显得“智障”或不连贯。

例如：

用户："我喜欢吃苹果。"

(5分钟后) 用户："我想吃那个。"

如果没有上下文，AI 会问："你想吃哪个？"

如果有上下文，AI 会答："好的，这就为你准备苹果。"

这种延续性是建立情感连接的基础。

1.2 LLM 的局限性

既然需要上下文，为什么不把所有历史记录都发给 LLM 呢？主要有两个限制：

Token 有限：所有模型都有最大上下文长度限制（如 8k, 32k, 128k）。长期陪伴类产品，可能几个月、几年，聊天记录会迅速累积，远超任何模型的窗口限制。

成本与延迟：发送的 Token 越多，推理成本越高，响应速度越慢。对于实时互动的伴侣应用，高延迟是不可接受的。

不区分“重要”与“闲聊”：模型不知道“用户今天感冒”是短期信息，“用户讨厌被忽视”是长期人格信息。如果不加调度层，模型会随机记住或忘记，导致“今天还记得，明天全忘”。

因此，我们需要一个「调度层」来决定：什么要进 prompt、什么要压缩、什么要长期存储、什么要丢弃。