在云计算的时候就在做的一个新的方向，memory service 对其中一些行业场景做了解析和增强方案，对agent的效果提升非常明显
最近用 Claude Code 重构blog的过程和研究openclaw的过程我发现他们也有自己的memory体系，但是更简单，跟倾向于通过执行任务的llm直接进行memory的提取和压缩，并且这并不是一个非常重要的任务，通常只发生在上下文长度即将越过模型上下文边界时，由于这种配置肯定不是面向成本的，是面向效果的，有点像“性能优先” 所以一定是一个过渡版本。这个粗暴的压缩会导致一些问题
- 有工程师使用openclaw整理邮件，明确要求了先分拣，不要进行删除。但是由于文件数量过大，直接触发了上下文压缩，而关键的任务要求“不要删除”又被丢弃了，导致删除无预期的直接开始，工程师直接崩溃了都
- 当我指导agent完成任务时，我会在审美，代码架构设计，成本和性能平衡上反复增加相同的对话内容。agent并没有意识到“我是一个成本敏感的技术宅” 导致了很多额外的交互成本
发生这些不是模型的原因，因为当你调整了上下文，他的表现非常好，但是上下文的管理在agent应用中通常是不透明的，通用的自动化意味着对特殊场景适配性不足
这件事让我开始认真想一个问题：Agent 的智能增强，真正的战场不在模型本身，在于系统能不能在每一步给模型喂到"对的信息"。更直白说，就是上下文管理能力。
过去一年行业讨论 LLM 时，聚焦的常常是两件事：更聪明的模型、更长的上下文。但在我自己使用 Agent 的经历中，我感受到的体验提升的往往不是你如何使用它，而是：这一轮对话里，系统放了什么进来。
"记忆"是个好的切入点，但不是终点
很多团队做 Agent 遇到的第一个痛点，都是"记忆"——用户说过的话模型忘了，每次都像第一次，对话越长越跑偏。
"记忆"这个词容易被理解，也容易快速带来体验提升，所以很多产品从这里切入。我也是。
但做着做着会意识到：只存信息是不够的。信息越来越多，反而不知道哪些该给模型看——给多了是噪音，给少了是遗漏，给错了是干扰。
所以从"记忆"走向"上下文管理"，是自然的演进，也是不得不走的一步。
"上下文管理"这个词没"记忆"性感，但更准确：在任务不同阶段，动态选择、组织、压缩、注入信息，让模型输出更符合目标、约束、偏好与当前情境。
它覆盖的范围，比大多数人想象的要大
如果真的把"上下文管理"展开，会发现几乎所有常见的 Agent 增强方向都能归进来。
提示词工程，本质是指令与约束的上下文注入——你是谁，你要怎么做事，什么能做什么不能做。很多人以为 prompt 工程是 trick，其实是在做系统级的上下文定义。常见失败是 prompt 越写越长，反而稀释重点，和用户目标冲突，听起来对、做不动。
偏好与习惯总结，本质是用户长期记忆的上下文注入。喜欢简洁还是详细、习惯先问还是先给结论、常用哪些术语——这些不用每次重新沟通。这是"认识你"的体验基础，也是让用户有粘性的地方。关键是偏好要可触发、可更正，不是越多越好，用不上的偏好是噪音。
自我进化，本质是系统经验记忆的上下文注入。失败案例沉淀、用户改动过的地方是偏好信号、哪种提问策略更少返工——这些积累下来，是让 Agent 越用越稳的关键。经验要"可执行"，不要写成泛泛的道理，更像"下次遇到 X，先做 Y"。
长程任务总结，本质是把过程状态变成可持续上下文。长任务难的不是信息量大，是状态复杂——决策、依赖、待办、阻塞、变更。好的压缩不是对话摘要，而是状态化：已确认事实/未确认假设、已做步骤/待做步骤、当前阻塞、关键决策原因。只做摘要不做状态，执行到一半就会断档，这是我犯过的错。
Skill（方法论 + 工具经验），本质是可复用的上下文构造模板加执行策略。触发条件、最少需要哪些信息、步骤顺序、常见坑、工具失败兜底——把这些固化成 Skill，是把"会做一次"变成"每次都能做"。从产品角度看，Skill 是把隐性经验显性化，把不可控的 prompt 变成可运营资产。
最后一个有点意外：情绪。很多人把情绪当成"模型天生会不会共情"，但在一个了解你的Agent面前，他是可以表现出情绪的。只是没有记忆的感情是“会消失的爱”目前还不能提供。
六类：指令、偏好、经验、状态、技能、情绪。
上下文做成资产，比堆模型更可持续
聊到这里，我觉得比较有价值的一个判断是：
模型能力的提升是供应侧的事，产品做不了太多，现在的迭代速度和成本来看，自己去续训练模型，除非你有非常多垂直领域的数据，不然很难收回成本。但上下文管理系统是产品自己能建的护城河——你如何在你提供的平台上，组织更好的上下文，帮助客户完成任务。同时具备任务+错误=更好的完成任务的模式，具有自我迭代的空间，这个是比训练模型成本更低，适应更广泛的。同时用户的习惯偏好会增强用户在平台的粘性，数据搬迁又增加了用户被挖掘的成本。短期来看上下文管理会降低paas平台售卖的token数量，～但是从一个任务流程会变的更长，体验更好的角度，上下文管理的能力反而会让token持续消耗，增加token流水。甚至有些厂商在尝试记忆不付费，通过token的增长补贴这部分成本。可能也是成功的商业设计
从记忆 MVP（偏好 + 摘要）开始，推进到状态化长程任务，再到 Skill 资产化，最后到经验进化闭环——这是一条可以实操的路径，每一步都有产品价值，不需要等到"模型再强一点"，没有一个起步陷阱。
我在做博客 Agent 的时候，第一步做的就是上下文压缩规则——哪些东西必须保留、哪些可以压缩、哪些到了一定量就该存到外部文件。后来又做了 Skill——把处理文章这件事的步骤和坑固化下来，给到下一次用。
每一步都没有多聪明，但确实每次都会有更多的节约，甚至不需要引入很复杂的记忆数据库。
Agent 的护城河，不在模型能不能一次答对，而在系统能不能持续构造正确上下文，让它每次都更接近答对。
与其花精力关注哪个新模型更强，不如先把系统里的上下文管理做扎实。希望这个方向马上有非常成熟的思路和产品出现。