9 月关于 AI agent 的讨论，重心悄悄挪了位置：大家不再只问「哪个模型更强」，而是开始认真问「怎么让 agent 记住东西，并且在对的时刻把该记的递送回来」。Codex 的 _context 是一种工业答案；学术界给了一个更锋利的说法——Cue-Anchored Working Memory：记忆是「递送」，不是「存储」。这条线，才是 agent 从聊天机器人走向受管业务系统的真正深水区。

一、Cue-Anchored：记忆是「递送」，不是「存储」

AgentPatterns 这篇把 agent 记忆拆成两层。第一层是大家熟悉的「文档层」：CLAUDE.md、AGENTS.md、plan 文件、auto-written memory 目录——写是主动的，读也是主动的。问题在这层存不住「情境绑定」的事实：比如「这个 config 是 load-bearing 的」「这行逻辑别动」，它们只在你正盯着那段代码时有用，写成脱离语境的文档反而没人看。

第二层是论文提出的新东西：cue-anchored working memory。它不靠 agent 主动想起，而是由 harness 在「情境触发」时自动注入——比如 agent 打开某个文件（path cue）、引用某个符号（symbol cue）、或临近 compaction（event cue），harness 端确定性地把对应事实塞进窗口。五种可组合的 cue：path / symbol / semantic / event / temporal，全部在 harness 侧判定，不经过模型的判断。

图 1 · Tier1 主动读写文档，Tier2 由 harness 在情境触发时确定性注入——后者才是「记忆」，前者只是「参考文档」。

**这篇最反直觉的一句：一个存储到底是「记忆」还是「参考文档」，由递送机制决定，不由存了什么决定。**lookup 的就是文档，injection 的才是记忆。这把「记忆」从「可插拔的模块」重新定义成「harness 的属性」——也就是说，你换再大的向量库，只要还是让 agent 自己去查，它就还是文档；真正让它变成记忆的，是 harness 在那一刻替它想起来。实证也支持：一个只靠主动存的 store，在 114 轮里零调用；而 harness 注入的事实，扛过了 138 次 compaction-resume 循环。

二、四层记忆架构：别再 brute-force 长上下文

Towards AI 这一周另一篇给了更工程化的框架：长上下文窗口的成本约为持久记忆检索的 15 倍，所以该用四层记忆替代暴力长窗口——working（工作记忆）、episodic（情景）、semantic（语义）、procedural（程序性）。它横向比了 Mem0、Letta、Zep/Graphiti、AWS AgentCore 在存储/检索/注入管线的差异，并用艾宾浩斯遗忘曲线做 decay 策略，同时点名了常被忽略的生产风险：记忆中毒、漂移、幻觉事实。

记忆层	存什么	典型载体
working	当前任务即时状态	上下文窗口 / scratch
episodic	发生过的事与轨迹	日志 / trajectory store
semantic	提炼过的事实与知识	向量库 / 知识图谱
procedural	怎么做某类事的流程	runbook / skill

**「15 倍」这个数字值得所有做 agent 的团队贴在显示器上。**它意味着，与其给模型塞更长的窗口，不如把上下文拆成「该忘的忘、该存的存、该在关键时刻递回来的递回来」。但别忽略那篇文提醒的暗面：记忆会中毒、会漂移、会自己编事实——记忆系统本身需要可观测、可回滚、可审计，否则它记住的谎言比忘掉的真相更危险。

三、StateM：解药在 harness 层，不在更大模型

StateM 这篇把「harness 决定上限」说得更绝：长程 agent 失败，往往不是模型不会做某一步，而是它弄丢了可变状态、跳过了已知步骤、或提前收工。StateM 是一个 agent-native runtime，把执行围绕 durable states、phase-local context、checked transitions、recoverable runbooks 组织起来——不改模型权重，就把 GPT-5.5 在 Terminal-Bench 2.1 从 83.1% 拉到 92.1%，换到 GPT-5.6 上达到 95.3% 原始准确率，整轮 benchmark 约 15 美元。

图 2 · 把执行环境交互循环交给 harness，模型只管请求-响应，准确率从 83% 跃到 95%。

**95.3% 的意义不在数字，在于「没换模型」。**它证明 agent 的瓶颈大量压在 harness：状态归谁管、阶段上下文怎么切、转换怎么校验、runbook 怎么恢复。对工程团队的直接启示是——当你想靠换更大模型救长任务时，先看看是不是 harness 在漏状态。Microsoft 的 Agent Lightning v1.0（约 3500 行）也在做同样的事：把 harness 变成可研究的测试床。

四、开源框架也在往「受管系统」收敛

落到能用的东西上，AgentScope 2.0 把这条线做成了开箱即用的工程：短期上下文由中间件接管自动压缩、工具结果卸载、系统提示注入；长期记忆给出可插拔后端（Agentic Memory、Mem0、进程内 ReMe，挂在中间件上对话结束自动回写）；还自带一个基于 FastAPI 的多租户、多会话 agent service 加 Web 前端，把「能跑的 agent」到「能上线的应用」之间缺的工程代码补齐。

**看 AgentScope 2.0 会明白：所谓「agent 框架」的胜负手，早不是谁的 prompt 模板更巧，而是谁把状态、记忆、可观测、治理这些脏活提前写好了。**它和微软 Agent Framework 1.16 把 state 升为「核心基础设施决策」、agent 与 channel 解耦、OpenTelemetry 成一等公民，是同一个方向的两种表达。

**一句话收束：**9 月 agent 领域的共识正在收敛——模型够不够强，已经不是第一性问题；状态、记忆、可观测、治理才是。Cue-Anchored 告诉我们记忆靠「递送」而非「存储」，四层架构告诉我们长窗口该被拆解，StateM 告诉我们 harness 层能白捡十几个点的准确率。对团队而言，这意味着：把 agent 当成一个受管业务系统来设计，而不是一个更聪明的聊天框——下次立项，先画状态机和记忆流向，再选模型。

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。