亚马逊Bedrock藏了3个评分维度，AI终于学会"长记性"

你的Agent能调取过去6个月的全部会议记录，却在回答项目 deadline 时，把昨天刚敲定的关键节点埋在3月的几十条无关状态更新下面。

技术上全对，体验上全废。这是大多数Agent的通病——除非你有意识地设计检索逻辑。

斯坦福的25个虚拟人，把记忆问题演成了行为艺术

斯坦福研究团队构建"生成式智能体（Generative Agents）"时，给虚拟小镇塞了25个模拟角色。每个Agent能存储数千条观察记录，但问到"接下来该做什么"时，系统只靠关键词随机检索。

结果出现荒诞循环：同一个Agent连续五次走进咖啡馆，因为记忆系统分不清"我五分钟前刚喝过"和"我一般午饭时间来"。

研究团队用三个评分维度破解了这个困局：时效性（recency）——这件事何时发生；重要性（importance）——这件事有多关键；相关性（relevance）——与当前处境的关联程度。

Amazon Bedrock AgentCore 现在把这套机制封装成企业级基础设施。但为什么这些维度有效、如何配置，得回到那项研究的具体设计里找答案。

上下文窗口越大，幻觉越隐蔽

大语言模型能处理极长的上下文，但这能力本身是个陷阱。企业常误以为：给Agent完整的对话历史和知识库，就能产出智能行为。实际运行中，这套逻辑频频翻车。

想象一个客服场景：用户提到三个月前的账单问题、询问当前的功能需求、还想约个电话。Agent的记忆库里躺着数千条交互记录，涵盖账单纠纷、功能反馈、日程冲突、甚至上周闲聊时提的咖啡偏好。

没有评分机制的Agent，把所有记忆视为同等重要。上下文窗口被最近存储的内容或基础关键词匹配填满——它可能调取用户上周随口说的拿铁口味，却漏掉需要立即处理的账单升级模式。

斯坦福的研究把这种失效模式量化呈现了。模拟角色Klaus Mueller被问到"推荐谁一起度过时间"时，无评分版本的系统选了Wolfgang，仅仅因为这个名字在近期观察中出现频率高。实际上，两人从未有过实质性交流。

他们只是住在同一街区。

三个维度如何改写检索逻辑

引入三维评分后，同一问题的输出完全不同。时效性压低三个月前的旧记录权重，重要性把账单纠纷标记为高优先级，相关性确保功能需求和日程安排进入候选集。

Bedrock AgentCore 的实现允许开发者自定义各维度权重。客服场景可能调高时效性和重要性，法律文档分析可能侧重相关性和重要性，创意写作助手或许给时效性更低权重以保留长期灵感。

这种灵活性对应着斯坦福研究的核心发现：记忆的价值不是存储本身，而是检索时的决策质量。

研究团队记录了一个典型对比。无评分系统中，Agent Maria在虚拟小镇连续三天去同一家餐厅，因为"餐厅"关键词高频出现且近期有记录。引入三维评分后，Maria开始根据当天心情、社交关系变化、甚至天气选择不同场所——行为模式从机械重复转向情境适应。

企业部署时的真实权衡

Bedrock AgentCore 把这套机制打包成可配置模块，但企业落地时面临具体选择。时效性权重过高，Agent变成"金鱼记忆"，反复询问刚确认过的信息；重要性权重过高，可能固化早期形成的偏见判断；相关性算法设计不当，会制造"信息茧房"，只检索与当前查询字面匹配的内容。

AWS 官方文档建议从均等权重起步，根据实际对话日志迭代调整。一个被验证的模式是：客服场景时效性40%、重要性35%、相关性25%；知识库问答场景调整为时效性20%、重要性30%、相关性50%。

这些数字不是最佳实践，而是调试起点。每个业务场景的"重要"定义不同——账单纠纷在SaaS公司是P0，在内容平台可能是P2。

斯坦福研究的25个虚拟人跑了两天模拟，产生数万条交互记录。Bedrock AgentCore 面对的是真实企业的百万级会话。规模差异意味着评分算法需要更精细的工程优化，但底层逻辑没变：让Agent"记得"不如让它"记得该记的"。

当Klaus Mueller最终推荐了一位真正有过深度交流的角色时，研究团队记录了他的检索日志：时效性过滤掉两周前的表面寒暄，重要性保留了那次关于职业焦虑的长谈，相关性确认了对方当前的时间可用性。

三个维度的乘积，决定了一条记忆是否值得被想起。你的Agent现在拥有同样的计算框架——问题是，你准备让它记住什么、又忘记什么？