读完一早上的访谈.
主题综述

上下文工程与 Agent 记忆

主题综述

主题页（活文档）· 最近更新 2026-06-12 · 取材 7 篇访谈

更新日志

主流共识

第一点：把 agent 搭起来很简单，让它"好用"全卡在上下文上。 这是七篇的共同起点。Lance Martin 把这句说得最直白：

"It's relatively simple to lay out an agent, but it's actually quite tricky to get it to work well. In a particular managing context with agents is a hard problem."
「部署一个 agent 相对简单，但要让它良好运行非常棘手。特别是在 agent 中管理上下文是一个难题。」
Lance Martin · Context Engineering for Agents

而 context engineering 这个词之所以一夜成名，按 Lance 转引 Karpathy 的定义，是因为它精确命中了所有人都在经历的痛——"为 LM 提供下一步所需的恰好那点上下文"。他还点破了为什么 agent 比聊天模型难得多：上下文不再只来自人，而是从几十到几百次工具调用里源源不断地灌进来，naive 地全塞回去，要么撞上下文窗口，要么撞上 Jeff（Chroma）说的 "context rot"（长上下文性能衰减）。

第二点：上下文不是聊天的延伸，它就是 agent 的"应用逻辑"本身。 Harrison Chase 把这点推到了最锋利的位置——agent 的"真相之源"已经从代码迁移到了"代码 + trace"：

"That means that the source of truth for software is in code, And for agents, it's a combination now of code and traces are where you can see the source of truth. It's technically in all those millions, billions of parameters, but you can't really do anything with that."
「这意味着软件的真理来源在代码里；而对 agent 来说，现在是代码和 trace 的组合——你能在 trace 里看到真相之源。从技术上讲它存在于数百万、数十亿个参数里，但你拿那个没法做任何事。」
Harrison Chase · Context Engineering Our Way to Long-Horizon Agents

因为第 14 步的上下文取决于前 13 步往里拉了什么，所以"给我看代码"在 agent 时代变成了"给我看 trace"。

第三点：解决了"理解/记忆"，可靠性才跟着来。 这是把这个主题和"可靠性"绑死的一句。Misha Laskin（Reflection AI）从企业落地角度给出：

"And of course, once you have that solved, it begets much more reliable agents that act for you as well."
「当然，一旦你把这个（理解/上下文）解决了，它就会催生出为你行动的、可靠得多的 agent。」
Misha Laskin · Asimov: Building An Omniscient RL Oracle

第四点：把记忆和上下文工程当成一件事的两个时间尺度。 这是 Harrison 和 Shunyu Yao 共享的概念框架——记忆不是另一个模块，是"更长时间跨度上的上下文工程"：

"If you think about memory in the context of this, that's also context engineering, right? It's context engineering over longer time horizons, and it's a slightly different set of context, but it's still giving that to the LLM."
「如果你在这个框架下想记忆，那它也是上下文工程，对吧？它是更长时间跨度上的上下文工程，是一组略微不同的上下文，但本质仍是把它喂给 LLM。」
Harrison Chase · Context Engineering Our Way to Long-Horizon Agents

分歧在哪

张力一 · 长期记忆放哪：模型权重 vs 非参数存储（文件系统）

这是本主题最值得记的一条——因为它几乎不是分歧，而是一边倒：从应用层（Cognition、Notion）到框架层（LangChain）到前沿实验室（DeepMind），都把长期记忆投给了"文件系统/外部存储，而非权重"。真正的张力，反而藏在"该不该、能不能放回权重"这条本应有人捍卫、却几乎没人捍卫的另一侧。

Oriol Vinyals（Gemini/DeepMind） 把这条说得最完整——而且他是前沿实验室的人，本来最有资格主张"塞进权重"，却恰恰相反：

"I don't think the weights of the model have caught up to this. Is this adding this kind of knowledge base into a file system or, you know, any format that is storage that you can modify and read from with some basic retrieval mechanism. So that's very powerful already. ... the mechanism I want it to work ... is this kind of File system style like nonparametric."
「我不认为模型的权重已经追上这一点了。这指的是把这种知识库加进文件系统——或任何你能修改、能读取、带基本检索机制的存储格式。这已经非常强大了。……我想要它运作的机制……就是这种文件系统式的、非参数的方式。」
Oriol Vinyals · Gemini Co-Lead on World Models, RL's Next Domains & Co

他给"为什么不放权重"的理由，是只有前沿实验室才说得出口的那种——服务成本：

"It's a bit more convenient than integrating those back into the weights because even from a practical point of view, we try to serve one model at scale. So what it would be really like painful to have to serve one model with different memories to users."
「这比把那些重新整合进权重更方便，因为哪怕只从实务角度看，我们要做的是规模化地服务同一个模型。要给不同用户服务一个带不同记忆的模型，会非常痛苦。」
Oriol Vinyals · Gemini Co-Lead

Walden Yan（Cognition/Devin） 从应用层给出同一结论，但理由不同——是模型自己变得"会用文件系统"了：

"But I think one big difference between two years ago and today is these agents are really good at using anything that resembles a file system natively. And so part of us is thinking, oh, should we rebuild memories to feel more like a file system that we let the agent navigate on its own?"
「但我觉得两年前和今天的一个重大区别是，这些 agent 原生地非常擅长使用任何长得像文件系统的东西。所以我们有一部分在想：是不是该把记忆重建成更像一个文件系统、让 agent 自己导航的样子？」
Walden Yan · The Age of Async Agents

Harrison Chase 是"file-system-pilled"喊得最响的——而且他给记忆的实现，就是让 agent 编辑自己的指令文件、每晚回看 trace 自我更新，完全绕过重训：

"File systems, I'm completely file system-pilled. I think in some form, agents should have access to some file system. ... file systems are still useful because that repeated thing could be generating a lot of context and you need to do context engineering."
「文件系统，我完全是 file-system-pilled。我认为 agent 在某种形式上都该能访问某个文件系统。……文件系统仍然有用，因为那个重复的事情可能产生大量上下文，你就需要做上下文工程。」
Harrison Chase · Context Engineering Our Way to Long-Horizon Agents

Notion（Simon Last） 把这条推到了极端——干脆没有"记忆"这个概念，记忆就是 Notion 页面：

"Another example of this is we have no built-in memory concept. Memory is just pages and databases. And so if you want to get a memory, just give it a page and give it access to that page."
「再举个例子：我们根本没有内置的'记忆'概念。记忆就是页面和数据库。所以如果你想要一段记忆，给它一个页面、给它访问那个页面的权限就行了。」
Simon Last · Notion's Token Town

唯一在概念层面为权重保留位置的，是 Shunyu Yao——他从第一性原理出发，坚持"权重本身就是一种记忆/信息存储"，不该被排除在外：

"And you can even think of the ways of neural network as some kind of non-memory because that's also part of the information is stored. ... the non-term memory or the persistent information is first, the neural network, and second, the code associated with the agent ... and maybe also some other vector stores."
「你甚至可以把神经网络的权重看成某种'非记忆'，因为那也是信息被存储的一部分。……长期记忆/持久信息首先是神经网络，其次是与 agent 关联的、调用神经网络的代码……也许再加上一些向量存储。」
Shunyu Yao · Language Agents: From Reasoning to Acting

注意：Shunyu 不是在主张"把个性化记忆塞进权重"，而是在框架层面拒绝把"权重"和"记忆"对立起来——他认为"知识"和"智能"压根分不开（详见下文张力四的延伸）。这和 Oriol 的实务结论并不直接冲突，但底层世界观相反：Oriol 想把记忆搬出权重，Shunyu 认为记忆从来就在权重里。

张力二 · 上下文怎么管：压缩(compaction) vs 检索(retrieval) vs 卸载(offload) vs 隔离(isolation)

这四种打法在 Lance Martin 那篇里被并成一张表（offload / retrieve / reduce / isolate），但七位发言人各自押注不同、且互有保留。

卸载 + 检索派（Lance / Manus 路线）：先把原始观察写到磁盘，再压缩——关键是压缩要可逆：

"Manus ... make the point and the warning that pruning comes with risk, particularly if it's irreversible. ... That's actually why Manus kind of has the perspective that you should definitely use context offloading. ... You don't have kind of lossy compression or lossy summarization."
「Manus……提出了警告：修剪是有风险的，尤其当它不可逆时。……这正是 Manus 主张你一定要用上下文卸载的原因。……（先卸载到磁盘，）你就不会有有损压缩或有损总结。」
Lance Martin · Context Engineering for Agents

Lance 在检索这一格里还有个反直觉的押注——别建索引，agentic grep 就够：

"Cloud Code doesn't do any indexing. It's just doing, quote unquote, agentic retrieval, just using simple tool calls. For example, using grep to kind of poke around your files, no indexing whatsoever, and obviously works extremely well."
「Claude Code 不做任何索引。它只是在做所谓的'agentic 检索'，就用简单的工具调用。比如用 grep 在你的文件里翻一翻，完全不建索引，而且显然效果极好。」
Lance Martin · Context Engineering for Agents

压缩派（Harrison/LangChain 路线）：把 compaction 当作 harness 的默认动作，但他坦承这件事还很手工、远未settled——而且他对"让模型自己决定何时压缩"持观望态度：

"Compaction is still very manual. The harness author decides what to do with it. Anthropic has some interesting things where they let the model decide when to compact things. We don't really see a ton of people using that. Maybe that'll be a part that's next."
「压缩仍然非常手工。是 harness 的作者决定怎么压。Anthropic 有些有意思的做法，让模型自己决定何时压缩。我们没怎么看到很多人用那个。也许那会是下一步。」
Harrison Chase · Context Engineering Our Way to Long-Horizon Agents

值得记的是 Alessio（主持人）补的一刀——自动压缩 ≈ 不压缩：他引昨天 meetup 的图说，OpenCode 这类工具的自动 compaction 效果"基本等于没压"，而人工精修的 compaction 好 2 倍，"但怎么做人工精修，没人知道"。压缩派自己也承认这格是开放问题。

隔离派的内部裂缝（多 agent 该不该用）见张力三。 这里只标一点：Notion 走的是第五种、上面四格都没有的打法——渐进式披露（progressive disclosure），即不卸载也不压缩，而是从源头就不让多余的工具进上下文：

"It was so many tokens, but also it's a quality issue because it meant that any engineer could introduce this new tool ... and it would nerf the overall model by causing it to call the tool too much."
「（一次性塞所有工具）token 太多了，而且这也是质量问题——因为这意味着任何工程师都能为某个小众功能引入一个新工具，它会因为让模型过度调用而把整个模型给削弱了。」
Simon Last · Notion's Token Town

注意这条隐含的反驳：卸载/压缩派治的是"上下文太长"，Notion 指出的是"上下文太长之前，光是工具定义本身就已经在毒化模型"——多一个工具不只是多花 token，是让模型变笨。

张力三 · 单一长上下文 vs sub-agent 隔离

这是七篇里对峙最清楚的一格，而且有人当面承认自己在改主意。

Cognition（Walden Yan） 是公开的"别造多 agent"那一派。他的论据是协作会制造冲突、而单 agent 自己管上下文反而稳：

"We've actually given Devin an MCP so they can just go arbitrarily message other Devins ... But I guess it somehow creates a really chaotic world in that sense. And so we've still found that most practical use on a day-to-day basis has been one single agent."
「我们其实给了 Devin 一个 MCP，让它们能随意给别的 Devin 发消息、创建新的 Devin……但这某种程度上造出了一个非常混乱的世界。所以我们发现，日常最实用的用法仍然是单个 agent。」
Walden Yan · The Age of Async Agents

但 Walden 给"多 agent"留了一个后门，恰恰也是上下文管理的角度——子 agent 不是协作者，是会折叠上下文的工具调用：

"are they really multi-agents or are they just kind of like tool calls? ... It has really nice context management benefits because all of the tool calls and tokens that it spends then get collapsed back to just the answer for the main agent."
「它们到底算不算多 agent，还是只是某种工具调用？……它有非常好的上下文管理收益，因为它花掉的所有工具调用和 token，最后都被折叠回成给主 agent 的那一个答案。」
Walden Yan · The Age of Async Agents

Lance Martin 给了这场争论最公允的拆解——分歧不在"多 agent 好不好"，而在"用在什么任务上"：读取型、易并行的任务（深度研究的上下文收集）适合多 agent，写入型、需协调的任务（编码）不适合：

"Cognition argues ... don't do sub-agents because each sub-agent implicitly makes decisions and those decisions can conflict. ... I like the take that apply multi-agents to problems that are easily parallelizable, that are read-only, for example, context gathering for deep research."
「Cognition 主张……别用子 agent，因为每个子 agent 都在隐式地做决策，而这些决策会冲突。……我喜欢的观点是：把多 agent 用在容易并行、且只读的问题上，比如深度研究的上下文收集。」
Lance Martin · Context Engineering for Agents

Harrison Chase 不站队、但给了多 agent 一个具体的失败模式——主-子之间的上下文交接是有损的：

"we'd see some failure modes where the sub-agent would do a bunch of work and then it would be basically like, look at my work above, and then pass that back to the main agent and it can't see it. And it's like, what are you talking about?"
「我们会看到一些失败模式：子 agent 干了一大堆活，然后它基本上会说'看我上面的工作'，把这句传回主 agent——可主 agent 根本看不见。于是主 agent 一脸懵：你在说什么？」
Harrison Chase · Context Engineering Our Way to Long-Horizon Agents

张力四 · 手工 scaffolding vs 模型自己动态生成结构（bitter lesson）

所有人都信 bitter lesson（手工结构终将被更通用的模型冲掉），但对"现在该删到什么程度"押注不同。

Oriol Vinyals 把这条推到了最远——连多 agent、子 agent、委派这些脚手架本身，将来都该由模型即时写出来：

"the system that we build now, sort of by coding, sometimes a complex sort of scaffold around the model, you know, multi-agents, sub-agents, delegation, very long running. That system itself is a piece of code that eventually the model itself could write on the fly ... actually maybe no system and just the model being able to write those depending on what it's being asked to do."
「我们现在通过写代码搭出来的系统——围绕模型的那套复杂脚手架，多 agent、子 agent、委派、超长运行——那个系统本身就是一段代码，最终模型自己就能即时写出来……甚至可能没有系统，只是模型按照被要求做的事自己去写。」
Oriol Vinyals · Gemini Co-Lead

Walden Yan 提供了这条定律正在发生的现场证据——Claude 3.7 一升级，他们做的大量工作是把 Devin 里不再需要的结构删掉：

"it's almost funny to be talking about how like big of a leaps on it 3.7 was and we honestly a lot of it was stripping out parts of Devin that were no longer needed with that jumping of intelligence."
「现在回头说 3.7 那一跃有多大几乎有点好笑——老实说，我们做的很多事，就是随着智能的跃升、把 Devin 里那些不再需要的部分删掉。」
Walden Yan · The Age of Async Agents

Harrison Chase 同意核心循环（让 LLM 在 loop 里自己选拉什么进上下文）已经"简单且通用到位"，手工脚手架会消失一部分——但他下一句立刻把 compaction 留在了"还很手工"那侧（见张力二）。这是这一派内部的微妙差异：信 bitter lesson，但承认眼下大部分上下文工程还得人来做。

反向的拉力也存在——Walden 同时指出，没有任何单一前沿模型能独自做完整端到端任务，所以现在还离不开手工编排多个模型。bitter lesson 是方向，不是当下的操作手册。

张力五 · "理解/上下文"是不是比"生成"更是真问题

这是 Misha Laskin 一个人撑起来、但足以重设整个主题坐标的一条。主流叙事把 agent 当"代码生成器"，他直接把比例倒过来：

"the world today is focused on I would say 80% kind of action, 20% understanding. So 80% code generation, 20% comprehension. The actual problem is exactly the opposite ... 80% of the time they're spending trying to comprehend complex systems and collaborating with teammates."
「今天整个世界关注的大概是 80% 行动、20% 理解，也就是 80% 代码生成、20% 理解。而真正的问题恰好相反……工程师 80% 的时间花在理解复杂系统、和队友协作上。」
Misha Laskin · Asimov

而他指出"理解"所需的上下文，根本不在代码库里——在人脑里、在聊天和项目管理工具里，是组织的"部落知识"：

"being able to learn from the engineering team to offload their tribal knowledge. So an engineer can go in and teach Asimov ... A lot of knowledge is stored in engineers' heads."
「能够向工程团队学习、把他们的'部落知识'卸载出来。一个工程师可以进去教 Asimov……大量知识是存在工程师脑子里的。」
Misha Laskin · Asimov

他给这套团队级记忆起的名字，把"记忆"和"版本控制"接到了一起——GitHub++（不是给代码做版本，是给"围绕代码的元知识"做版本）。这条把整个主题从"单 agent 的上下文窗口怎么省 token"拉高到了"一个组织的知识怎么被结构化、权限化地存住"——是七篇里唯一把记忆当作组织资产而非会话技巧来谈的。

都没说透的

1. 跨会话、跨用户的个性化记忆，几乎被绕开。 七篇里只有 Harrison 直接碰了一下，而且是泼冷水——他说自己几乎不用 ChatGPT 的记忆功能、也没觉得它带来黏性；他认为记忆要成为护城河，得是在"重复的、具体的工作流"里，而不是泛泛的聊天。其余六篇谈的都是任务内或团队内的上下文，没人讲清楚"模型怎么长期、安全地记住一个具体的人"。

2. 记忆的隐私与安全，只有 Misha 擦了一下边。 Misha 提到团队记忆要分权限（哪段代码该让哪个工程师编辑记忆），但这是协作权限，不是数据安全。一旦记忆是 agent 自动生成、自己写进文件系统（Walden 说 95% 的 Devin 记忆是自动生成的），"记错了怎么纠、记了不该记的怎么删、文件系统记忆被污染/越权读取怎么办"——七篇全程没人正面回答。Lance 倒是提了一个相关失败模式（ChatGPT 把用户位置错误地塞进生成图片），但当趣闻带过。

3. 记忆的评估，被反复点名是难题、却没有方法。 Walden 说记忆的"生成和检索都极难做对"，Harrison 说"记忆到底是什么都还没定义"，Shunyu 说"没有单一最优解"。三个人都把记忆评估认成开放问题，但没有一个人给出"怎么判断一段记忆该不该写、检索得准不准"的可操作标准。Shunyu 的态度甚至是放弃统一答案——多造工具，把选择权交给 agent。

4. 自动压缩的质量，是公认的黑洞。 张力二里 Alessio 那句"自动压缩约等于不压缩、人工精修好 2 倍、但怎么精修没人知道"——没有任何一篇接住了。这是把"长程 agent 能不能持续跑"卡住的具体技术缺口。

我的看法

判断一（把握较高）："长期记忆放文件系统、不放权重"在这批人里已经是默认共识，不再是争论。 从 Oriol（前沿实验室、最有动机塞权重）到 Notion（干脆取消"记忆"概念）的一边倒说明，至少在 2026 年中、在工程可行性这个层面，文件系统赢了——真正的开放问题不是"放哪"，而是"放进文件系统之后怎么检索、怎么评估、怎么不被污染"。

判断二（中等把握）：Misha 那条"理解 > 生成"很可能被低估了。 其余六篇都在"单 agent 怎么省上下文"这一层精耕，只有他把镜头拉到"一个组织的知识怎么被存住"。如果他对——80% 的价值在理解、且理解所需的上下文根本不在代码库——那么大半个 context engineering 工具栈都在优化错的那 20%。我倾向认为他对，但这是判断，不是结论。

判断三（把握中等偏低）：bitter lesson 在这个主题上会比在别处来得慢。 记忆涉及隐私、权限、跨会话状态这些"非纯智能"约束，Oriol"模型自己写脚手架"的图景在记忆这一块，会被这些约束拖住——这也是为什么连他自己都用"服务成本"而非"能力"来论证不放权重。

还想知道什么

1. 记忆该不该写、检索得准不准——有没有可操作的评估？ 三位发言人都认它是开放问题；想看任何一家把"记忆 eval"做成像代码 eval 那样的具体流程。 2. 文件系统记忆的安全边界。 agent 自动生成、自己读写记忆文件，当记忆被污染、或子 agent 越权读到不该读的记忆时，现有 harness 怎么兜底？Walden 的 brain/hands 隔离是为了密钥安全，但没覆盖记忆本身。 3. "人工精修压缩好 2 倍"——那 2 倍到底来自哪？ 想看一次把"好的 compaction"拆开的对照实验，而不是停在"它很重要、很难"。 4. Misha 的"部落知识"能不能脱离编码场景。 把组织隐性知识结构化成团队记忆，在非工程团队（销售、法务、运营）里成不成立？这决定了它是 Asimov 的产品特性，还是一个通用的记忆范式。

取材

继续读
线索
阅读线索：agent 不到 9 nines 可靠，那应该卖给企业还是消费者
线索
阅读线索：如果 coding 是 commodity，AI startup 的护城河长在哪儿
线索
阅读线索：推理成本一年跌 10×，AI app 该按什么定价
线索
摘报
综述
AI Agent 安全与治理
综述
Agent 代购时代：广告与商业的重写