标签归档:AIAgent架构

聊下 AI Agent 的上下文记忆和遗忘

最近 DeepSeek 的 OCR 论文里有个有趣的想法:用光学压缩来模拟人类的记忆遗忘机制。

这个思路很巧妙。他们注意到人类记忆和视觉感知都有个共同特点:距离越远,信息越模糊。一小时前的事记得清楚,一年前的事几乎忘光;10 厘米的东西看得清楚,20 米外的东西就模糊了。

DeepSeek 把这个生物学现象转化成了工程实现:近期对话用高分辨率保存,一周前的对话降到中等分辨率,久远的记忆压缩到最小。信息随时间自然衰减,就像人类遗忘一样。

这让我想到 Agent 记忆系统设计的本质问题。

1. 为什么 Agent 需要记忆

上下文窗口和记忆是两码事。

上下文窗口只是让模型一次看到更多对话,像是扩大了工作台。但记忆不同,它让 Agent 能保存、更新和选择性回忆信息。没有记忆,Agent 就像得了失忆症,每次对话都从零开始。

现在大家都在追求更大的上下文窗口,从 8K 到 32K,再到 128K、1M。但这种暴力扩张有个问题:计算成本呈二次方增长。处理 100K tokens 的成本是 10K tokens 的百倍。而且,把所有信息一股脑塞给模型,反而可能让它迷失在细节中。

记忆系统的价值在于选择性保留。

不是所有信息都值得记住,也不是所有信息都需要同样的精度。

2. Agent 记忆的层次结构

AI Agent 的记忆系统可以分成几个层次:

短期记忆(工作记忆)
这是 Agent 的记事本,保存当前对话和正在处理的任务。典型容量在几千到几万 tokens。没有它,Agent 会在对话中途失去思路,问你刚才说了什么。

长期记忆
这是跨会话的持久化存储。用户下次回来,Agent 还记得之前的交互。长期记忆又可以细分:

  • 事实记忆:保存确定的信息,比如用户姓名、偏好、角色定义。这些信息需要随情况更新,保持”当前真实状况”。
  • 情景记忆:记录具体经历,什么时候发生了什么,结果如何。这给 Agent 一种时间连续感,能回顾过去的决策。
  • 语义记忆:组织概念和关系的知识网络。让 Agent 理解”数据库慢”和”查询延迟高”是相关问题。

3. 遗忘机制是有用的

人类会遗忘,不是大脑容量不够,而是遗忘让我们更高效。

想象一下,如果你记得生活中的每个细节:每顿饭的味道、每次呼吸的感觉、路过的每个行人的脸。这些信息会淹没真正重要的记忆。遗忘是一种过滤机制,帮我们保留有价值的信息。

Agent 也需要这种机制。随着交互增加,历史数据会无限增长。如果不加选择地保存所有内容,会面临几个问题:

  1. 存储成本:每个用户的历史数据都完整保存,存储需求会爆炸式增长。
  2. 检索效率:在海量历史中找到相关信息越来越慢。
  3. 注意力分散:太多无关信息会干扰 Agent 的决策。
  4. 隐私风险:永久保存所有对话增加了数据泄露的风险。

4. 用分辨率模拟时间衰减

DeepSeek 的做法是:把历史对话渲染成图像,然后用不同的分辨率来编码。

近期对话用高分辨率(Gundam 模式,800+ tokens),保留完整细节。

一周前的对话用中等分辨率(Base 模式,256 tokens),保留主要内容。

久远的历史用低分辨率(Tiny 模式,64 tokens),只留个大概印象。

这样做的好处是:

  1. 不需要丢弃历史信息,所有对话都保留着
  2. 但远期信息自然”淡化”,占用的 token 越来越少
  3. 模拟了人类记忆的衰减曲线

具体实现上,他们会:

  1. 把超过一定长度的历史对话渲染成图像
  2. 第一次压缩,让 token 减少 10 倍
  3. 上下文再次超长时,进一步降低分辨率,再压缩 10 倍
  4. 随着时间推移,图像越来越小,内容越来越模糊,模型也就逐渐”读不清”了

这种方式不是简单的截断或删除,而是让信息随时间衰减——就像人类记忆一样。

5. 理论上无限的上下文

如果这个思路走通了,就能实现”理论上无限的 context window”。

这里的无限不是真的无限,而是通过分层压缩,让历史信息的存储成本趋近于常数。

我们不需要保持所有信息的高保真度,只需要让信息按重要性和时效性衰减。

最近的对话,全保留。
一周前的,压缩一次。
一个月前的,再压缩一次。
半年前的,只留个印象。

这样,计算资源始终聚焦在最重要的”近期”信息上,而久远的历史虽然还在,但只占用很少的 token。

从成本角度看,这比无脑扩大上下文窗口要合理得多。

6. 记忆管理的工程实践

在实际的 Agent 系统里,记忆管理通常分几个层次:

会话级记忆——当前对话的上下文,存在内存里,对话结束就清空。这部分可以直接用模型的上下文窗口。

用户级记忆——持久化存储,用向量数据库或 KV 存储。每次对话时,根据当前问题检索相关的历史记忆,注入到 prompt 里。

全局知识库——所有用户共享的知识,比如产品文档、技术规范、FAQ。这部分通常用 RAG(检索增强生成)来处理。

关键是如何在这些层次之间做好信息流转和优先级管理。

比如,用户刚说过的话,优先级最高,直接放在 prompt 前面。一周前的对话,需要检索后才注入。一个月前的,可能只保留摘要。

这种分层策略,和 DeepSeek 的分辨率衰减思路是一致的——让资源消耗和信息重要性成正比。

7. 遗忘不是丢失

这里需要明确的是,遗忘不等于删除。

人类的遗忘,是提取变难了,不是信息消失了。在特定的提示下,很多”遗忘”的记忆还能被唤起。

Agent 的记忆也应该这样设计。

低分辨率的历史对话,在大部分场景下不会被激活,但如果用户明确提到某个时间点的事情,系统可以重新加载那段历史的高分辨率版本。

这需要一个索引机制,能根据时间、主题、关键词快速定位到历史片段。

像 Manus 所使用的文件系统就是这样一种索引机制。

遗忘是常态,召回是特例。这样才能在效率和完整性之间找到平衡。

8. 什么值得记住

并不是所有对话都需要长期保存。

大量的对话是重复的、临时的、没有上下文依赖的。比如简单的问候、重复的确认、无关紧要的闲聊。

这些内容可以在会话结束后直接丢弃,不需要进入长期记忆。

真正值得记住的,是那些包含决策、偏好、关键信息的交互。

比如:

  • 用户明确表达的需求和偏好
  • 重要的决策节点和原因
  • 反复出现的问题和解决方案
  • 用户的角色、职责、技术栈等基础信息

这需要在记忆写入时做判断和过滤。可以用一个小模型或规则引擎,评估每轮对话的重要性,决定是否持久化。 Gemini Code 就是这么干的。

不是所有东西都值得记住,筛选本身就是一种优化。

9. 记忆的更新和冲突

长期记忆不是只写不改的日志,它需要能更新。

用户的偏好会变,角色会变,之前的信息可能过时或错误。

比如用户之前说喜欢中古风的家具,后来又说喜欢北欧风,这个信息需要更新,而不是简单地追加一条新记录。

如果只追加不更新,记忆会越来越冗余,甚至出现矛盾。

一个好的记忆系统,需要能识别冲突,做合并和覆盖。

这可以通过实体识别和关系抽取来实现。把对话内容结构化成三元组(主体-关系-客体),然后在写入时检查是否和已有记忆冲突。

如果冲突,可以根据时间戳、置信度等因素决定是更新还是保留多个版本。

记忆管理的复杂度,不亚于写一个小型数据库。

10. 压缩不只是技术问题

回到 DeepSeek 的光学压缩思路,它的价值不只是技术实现,更重要的是提供了一个思维框架。

我们习惯于把上下文长度当作硬指标——越长越好。但这个论文提醒我们,长度和质量不是一回事。

有时候,适度的遗忘反而能提升系统的整体表现。

有如下的好处:

  1. 减少了无关信息的干扰
  2. 降低了计算成本
  3. 让模型专注于最相关的内容

这和人类的认知机制是一致的。我们不会带着所有历史记忆去做每一个决策,而是根据当前情境激活最相关的那部分。

Agent 应该学会做同样的事。

11. 成本和效果的平衡

从成本角度看,无限扩展上下文是不可持续的。

假设一个 Agent 系统,每天处理 1000 次对话,每次对话平均 10 轮,每轮 500 tokens。

如果所有历史对话都全量保留,一个月下来,单个用户的上下文就会达到 1500k tokens。

如果有 1000 个活跃用户,每次推理都带上完整上下文,token 消耗会是天文数字。

但如果用分层记忆 + 遗忘机制:

  • 最近 3 天的对话,全保留
  • 一周到一个月的,压缩 50%
  • 一个月以上的,压缩 90%

token 消耗可能降低到原来的 10%-20%,而对实际效果的影响很小。

因为大部分场景下,用户关心的就是最近的对话。

12. 记忆应该是系统能力

很多团队把记忆功能当作一个独立的我来开发——加个数据库,存一下历史,检索一下注入。

但这样做的效果往往不好。

因为记忆不是一个功能模块,而是整个 Agent 系统的底层能力。

它需要和 prompt 设计、工具调用、推理链路、错误处理深度集成。

比如:

  • Prompt 需要为记忆预留位置和格式
  • 工具调用的结果需要写回记忆
  • 推理过程中需要动态检索记忆
  • 错误发生时需要回溯历史上下文

记忆管理做得好,Agent 的整体表现会有质的提升。做得不好,就只是一个会话机器人。

13. 一些建议

以下是一些可以尝试落地的建议:

1. 不要把所有历史都塞进 prompt

很多团队的做法是,每次调用都把所有历史对话拼接到 prompt 里。这在对话轮数少的时候没问题,但规模上去后会成为瓶颈。

改成检索式注入——根据当前问题,从历史记忆里检索最相关的几条,而不是全量加载。(这里就会考量检索的能力了)

2. 区分会话记忆和持久记忆

当前对话的上下文,存在内存里就行,不需要持久化。

只有那些需要跨会话保留的信息,才写入数据库。

这样可以大幅减少存储和检索的开销。

3. 给记忆加上过期时间

就像缓存一样,记忆也可以有 TTL(Time To Live)。

一般性的对话,可以设置 7 天或 30 天过期。重要的信息,可以标记为永久保留。

定期清理过期记忆,防止数据无限膨胀。

4. 用好向量数据库

向量检索是目前最适合做语义记忆的技术。

把历史对话做 embedding,存到向量数据库里,每次根据当前问题做相似度检索。

但要注意,向量检索的召回率不是 100%,需要结合关键词索引和时间过滤。

5. 记忆要能解释

用户问”你为什么这么回答”,Agent 应该能说清楚是基于哪段历史记忆做的判断。

这需要在记忆检索时保留溯源信息——这条记忆来自什么时间、什么对话、可信度如何。

可解释性不仅是用户体验问题,也是调试和优化的基础。

14. 最后

上下文记忆和遗忘,本质上是资源分配问题。

我们只有有限的 token 预算,有限的计算资源,有限的响应时间,需要在这些约束下做出最优决策。

无限扩展上下文听起来很美好,但实际上不可行。

真正的解决方案,是学习人类的记忆机制——让重要的信息留下来,让次要的信息自然衰减。

DeepSeek 的光学压缩思路提供了一个很好的启发:遗忘不是缺陷,而是一种优化策略。

如果能把这个思路落地到 Agent 系统里,不仅能降低成本,还能提升整体的智能水平。

因为真正的智能,不是记住所有东西,而是知道什么值得记住,什么可以忘记。

关于 AI Agent 的思考:大模型边界和工作流

最近在体验一些 AI Agent 的产品,有一个比较感受:大多数的 AI Agent 最终都是一个或多个工作流,原本我们想象的那种完全自主、能够独立思考和决策的 AI Agent 很少。

从而也就无法看到一句话就完成所有的事情,需要有专业的人在旁边盯着。

甚至出现了一个新的名词:大模型善后工程师

并且那种自动多的 AI Agent ,面对的大多数是对于幻觉,有一定容错的场景,如自动化报告生成,陪伴语聊。

那些无法容错的场景, AI Agent 就必须要人工审核或者带审计的工作流来完成。

为什么在准确性要求比较高的 AI Agent 都变成了工作流?

看一下我们常见的 AI Agent 逻辑:

收到用户输入 → 判断意图 → 调用对应的模块 → 整理输出 → 返回结果

这跟我们想象中的 Agent 差距很大。理想中的 Agent 应该像一个真正的助手,能理解复杂的需求,自主规划执行路径,遇到问题能灵活调整策略。但现实是,大部分产品都在用固定的流程来约束 AI 的行为。

为什么会这样?核心原因是大模型本身的特性决定的。

大模型的能力边界在哪里

大模型确实很强大,但它有明确的能力边界。

第一个边界是可靠性。大模型的输出本质上是概率分布,每次生成都有不确定性。同样的输入,可能得到不同的输出。这种不确定性在聊天场景下可以接受,但在准确率要求比较高的生产环境中就是个大问题。比如一个财务报表分析的 Agent,我们是无法接受它今天说利润率是 15%,明天又说是 18%。

第二个边界是准确性。大模型的训练数据是有截止时间的,而且它没有实时获取信息的能力。更重要的是,它会产生幻觉——看起来很有道理,但实际上是错的。一个合同审核的 AI Agent,引用了一条根本不存在的法律条款,差点出事。

第三个边界是执行能力。大模型本质上是一个文本生成器,它不能直接操作系统、调用 API、访问数据库。所有这些能力都需要额外的工程实现。而一旦涉及到外部系统的调用,就必须有明确的权限控制和错误处理,这又把我们拉回到工作流的思路上。

第四个边界是成本。完全放开让大模型自主决策,意味着大量的 token 消耗。一个复杂任务可能需要多次推理、多次调用,成本会急剧上升。在我们做 AI Agent 之初,成本问题就是一个要着重考虑的问题。我最近用得比较多的编程 Agent,就因为成本问题,把之前的收费逻辑做了颠覆式的变化,作为一个用户,最直观的感受就是费用暴增。

使用工作流是一种现实

面对这些边界,工作流成了一个自然的选择。

工作流解决了可控性问题。通过预设的流程,我们能确保 AI 的行为在可控范围内。每一步该做什么、不该做什么,都有明确的定义。这对企业应用来说至关重要。没有哪个企业敢把关键业务交给一个完全不可控的系统。

工作流解决了准确性问题。在工作流的每个节点,我们可以加入验证和校准机制。比如在数据查询环节,直接调用数据库而不是让大模型猜测;在关键决策点,加入人工审核环节。这样既利用了大模型的能力,又避免了它的短板。

工作流还解决了成本问题。通过流程优化,我们可以精确控制大模型的调用次数和方式。简单的任务用小模型或规则引擎处理,复杂的任务才调用大模型。这种分层处理大大降低了运营成本。

更重要的是,工作流让产品可以迭代优化。每个环节的表现都可以监控和改进,哪里出问题就改哪里,而不是面对一个黑盒束手无策。

如何设计一个好的工作流 Agent

既然工作流是当前的现实,那怎么设计一个好的工作流 Agent?

  1. 任务拆解。把复杂的任务拆解成多个简单、明确的子任务。每个子任务都有清晰的输入输出定义。比如一个智能客服 Agent,可以拆解为:意图识别、信息提取、知识检索、答案生成、对话管理等模块。
  2. 模块化设计。每个模块独立开发和优化,通过标准接口连接。这样的好处是可以灵活替换和升级。今天用规则引擎的地方,明天可以换成机器学习模型;现在用 GPT-4 的地方,以后可以换成更合适的专用模型。
  3. 状态管理。工作流需要维护整个对话或任务的上下文状态。这不仅包括用户的历史输入,还包括中间结果、系统状态等。良好的状态管理是实现复杂交互的基础。
  4. 异常处理。每个环节都可能出错,需要有完善的异常处理机制。比如大模型返回了不合预期的结果怎么办?外部 API 调用失败怎么办?这些都需要提前考虑。
  5. 人机协同。在关键环节保留人工介入的接口。这不是技术不行,而是业务需要。很多场景下,人工审核是合规要求,也是质量保证。总得有人背锅不是,毕竟 AI 背不了锅。

工作流的局限性

工作流虽然解决了很多问题,但也有明显的局限性。

第一是灵活性不足。预设的流程很难应对所有情况,遇到流程外的需求就无能为力。这也是为什么很多 Agent 给人感觉很”笨”的原因——它只会按照固定的套路来。

第二是开发成本高。设计一个完善的工作流需要深入理解业务逻辑,每个流程都需要大量的开发和测试。而且业务变化时,工作流也需要相应调整,维护成本不低。

第三是用户体验的割裂感。用户能明显感觉到自己在跟一个程序打交道,而不是一个智能助手。特别是当工作流设计不够自然时,这种割裂感会更强。

预想可能的发展

尽管当前工作流是主流,但技术还在快速发展。

模型能力在提升。新一代的大模型在准确性、稳定性上都有改进。特别是针对特定领域的专用模型,表现越来越好。比最新上的 Qwen3-Max 就针对工作流,工具调用有了特别的优化。这为减少工作流的约束提供了可能。

工具调用能力在增强。Function Calling、Tool Use、MCP,以及最新的 SKILLS 等技术让大模型能更好地与外部系统交互。虽然本质上还是工作流,但流程可以更动态、更智能。

多模态融合带来新可能。不只是文本,图像、语音、视频等多模态信息的处理能力都在提升。这让 Agent 能处理更复杂的任务,提供更自然的交互。

强化学习和自主学习是长期方向。让 Agent 从交互中学习,不断改进自己的策略。虽然现在还不成熟,但这是实现真正自主 Agent 的关键。

产品化的思考

做 AI Agent 产品,技术只是一部分,更重要的是产品思维。

首先要明确定位。你的 Agent 是要解决什么问题?为谁解决?解决到什么程度?不要试图做一个万能的 Agent,那样最后什么都做不好。现在很火的小鹏的机器人,其有 80 个控制点,相对于宇树的 20 个控制点,其灵活性肯定要高一些,但是其场景和定位是完全不一样的,成本也不一样。

其次是场景选择。选择那些容错率相对高、价值明确的场景。比如内容创作辅助就比财务决策更适合当前的技术水平。在合适的场景下,即使是工作流 Agent 也能创造很大价值。

然后是预期管理。不要过度承诺,要让用户清楚产品的能力边界。与其说这是一个智能助手,不如说这是一个智能工具。合理的预期能减少用户的失望,提高满意度。

还要重视数据积累。每一次用户交互都是宝贵的数据。通过分析这些数据,我们能发现工作流的不足,找到优化的方向。数据驱动的迭代是产品成功的关键。

最后是成本控制。AI Agent 的运营成本不低,必须找到合理的商业模式。是订阅制还是按量付费?是 To B 还是 To C?这些都需要根据产品特性和市场情况来决定。

实践中的几个关键点

基于这段时间的观察和实践,有几个点特别重要。

第一,不要迷信技术。大模型很强大,但它不是银弹。很多问题用传统方法解决更高效、更可靠。关键是找到合适的技术组合。

第二,重视工程实现。一个好的想法到一个可用的产品,中间有大量的工程工作。提示词优化、结果解析、错误重试、性能优化,这些看似琐碎的工作往往决定产品的成败。

第三,持续迭代。AI Agent 产品很难一步到位,需要不断根据用户反馈来改进。建立快速迭代的机制,小步快跑,逐步逼近理想状态。

第四,关注安全和合规。AI 的不可控性带来了新的安全风险。数据隐私、内容安全、决策可解释性,这些都需要提前考虑。特别是在企业级应用中,合规往往是第一要求。

第五,建立评估体系。怎么衡量一个 Agent 的好坏?准确率、响应时间、用户满意度、成本效率,需要建立全面的评估指标。只有能量化,才能持续优化。

写在最后

做 AI Agent 产品这段时间,最大的感受是理想与现实的差距。我们都希望做出科幻电影里那样的 AI,但现实的技术约束让我们不得不妥协。

但这未必是坏事。工作流让 AI 变得可控、可靠、可用。在当前的技术条件下,一个设计良好的工作流 Agent,往往比一个不受约束的”智能” Agent 更有价值。

关键是要认清现实,在约束中寻找创新的空间。大模型的边界是客观存在的,但边界之内仍然有广阔的天地。工作流不是终点,而是通向更智能的 Agent 的必经之路。

技术在进步,产品在迭代,市场在成熟。今天的工作流 Agent,可能就是明天自主 Agent 的雏形。重要的不是等待完美的技术,而是用现有的技术创造价值,在实践中推动进步。

这个领域还很年轻,充满了可能性。无论是技术突破还是产品创新,都有大量的机会。保持理性的乐观,脚踏实地地推进,相信我们能做出真正有用的 AI Agent 产品。

毕竟,每一个伟大的产品,都是从不完美开始的。

以上。

从 LangChain 和 Manus 两巨头上下文工程实战中学到的 5 点经验

最近仔细看了 LangChain 的 Lance 和 Manus 的 Pete 的视频,主题是构建 AI 智能体中的上下文工程。这次分享没有那些空泛的理论,全是在生产环境中验证过的实战经验。

我结合自己的思考,整理了我认为 5 个最有价值的技术要点,每一个都直接影响着智能体的性能和可用性。

1. 上下文爆炸是智能体最大的瓶颈

Manus 统计显示,一个典型的智能体任务需要约 50 次工具调用。Anthropic 也提到,生产环境中的智能体对话可能持续数百轮。每次工具调用都会返回结果,这些结果会不断累积在消息历史中。

问题在于,随着上下文长度增加,模型性能会明显下降。Anthropic 把这个现象称为”上下文腐烂”(context rot)。具体表现是模型开始重复输出、推理速度变慢、回答质量下降。大部分模型在 200k Token 左右就开始出现这些问题,远低于它们宣称的上限。

这就形成了一个矛盾:智能体需要大量上下文来保持工作状态的连续性,但上下文太长又会导致性能下降。这是所有开发智能体的团队都会遇到的核心挑战。

Lance 在分享中展示了他们 Open Deep Research 项目的数据。这个开源项目在 Deep Research Bench 测试中排名前十,但即使是这样优秀的实现,也需要在三个阶段中不断地卸载和压缩上下文才能保持高效运行。

Pete 则分享了 Manus 的经验。他们发现,如果不做任何优化,上下文会在几十轮对话后就达到模型的处理极限。更糟糕的是,用户往往在这时才开始进入任务的核心部分。

解决这个问题没有捷径,必须从架构设计开始就考虑上下文管理。这也是为什么”上下文工程”这个概念在今年 5 月开始迅速流行的原因。它不是可选的优化项,而是构建生产级智能体的必要条件。

2. 上下文工程的五大组成部分

Lance 和 Pete 在分享中系统地总结了上下文工程的五个核心组成部分,这些部分相互关联,形成了一个完整的技术体系。

上下文卸载 是把部分信息移出主消息历史,存储到外部系统中。最常见的是使用文件系统。当搜索工具返回大量结果时,不是把完整内容放在消息队列里,而是写入文件,只在上下文中保留文件路径。Claude Code、Manus、Open Deep Research 项目都大量使用这种方法。

上下文缩减 包括压缩和摘要两种策略。压缩是去掉可以从外部重建的信息,摘要是对信息进行不可逆的精简。Claude 3.5 Sonnet 已经内置了修剪旧工具调用的功能。Cognition 在智能体交接时也会触发摘要。

上下文检索 解决如何按需获取被卸载的信息。有两派做法:Cursor 使用索引加语义搜索,Claude Code 和 Manus 只用文件系统加 grep、glob 这样的简单工具。两种方法各有优劣,选择哪种取决于具体场景。

上下文隔离 通过多智能体架构实现关注点分离。每个子智能体有自己的上下文窗口,避免信息混杂。Manus 的 Wide Agents、LangChain 的 Deep Agents、Claude 的多智能体研究员都采用了这种设计。

上下文缓存 利用 KV 缓存等机制减少重复计算。Anthropic 等服务商提供的缓存功能对长上下文智能体至关重要,特别是在输入远长于输出的场景下。

这五个部分不是独立的,而是相互影响的系统。卸载和检索让缩减更高效,稳定的检索让隔离变得安全。但隔离会减慢上下文传递,降低缩减频率。更多的隔离和缩减又会影响缓存效率。

Pete 特别强调,这种相互依赖意味着你不能只优化某一个方面,必须从整体考虑。比如,如果你的检索机制不够稳定,就不能激进地进行上下文隔离,否则子智能体可能无法获取必要的信息。

3. 上下文管理和数据库系统的对比

在分享中我个人的感觉是上下文工程的设计和数据库系统设计有比较多的相似性。

上下文卸载和数据库索引有很多相似之处,但它们的设计目标和实现机制存在本质差异。

展开来讲:相似性是都是为了解决容量与性能的矛盾

数据库索引解决的是「如何在海量数据中快速定位」的问题,而上下文卸载解决的是「如何在有限窗口中访问无限信息」的问题。两者都是通过建立某种间接引用机制,让系统能够处理超出直接处理能力的数据量。

数据库有内存中的索引页、磁盘上的索引文件、以及实际的数据页。上下文工程也有类似的层次:活跃上下文(相当于内存中的热数据)、文件路径引用(相当于索引)、文件系统中的完整内容(相当于磁盘数据)。

数据库索引针对不同的查询模式有不同类型:B 树索引适合范围查询,哈希索引适合等值查询,全文索引适合文本搜索。上下文卸载也有类似的分类:代码文件用路径索引,搜索结果用语义向量索引,对话历史用时间戳索引。

数据库的 buffer pool 会缓存频繁访问的索引页和数据页。上下文工程中的 KV 缓存也会保留频繁引用的上下文片段。两者都使用 LRU 或类似算法决定淘汰策略。

关键差异:索引是查询优化,卸载是容量管理

数据库索引的主要目标是加速查询,即使没有索引,全表扫描也能得到结果,只是慢一些。而上下文卸载是为了突破硬性限制,没有卸载机制,超出窗口的信息就完全无法访问。这是「优化」与「必需」的区别。

数据库索引是冗余信息,删除索引不会丢失数据,只会影响查询性能。但上下文卸载中,如果文件系统中的内容丢失,而上下文中只有路径引用,信息就永久丢失了。这就是为什么 Pete 强调卸载必须配合可靠的检索机制。

数据库索引需要随数据更新而维护,这是 ACID 事务的一部分。而上下文卸载通常是单向的:信息从上下文移到外部存储,很少需要反向更新。即使文件内容被修改,上下文中的引用通常保持不变。

数据库可以选择性地为某些列建立索引,基于查询模式和数据分布做决策。而上下文卸载往往是强制的:当接近 Token 限制时,必须卸载某些内容,没有”不建索引”的选项。

就像数据库有内存、磁盘、缓存的层次结构,上下文工程也有类似的分层:活跃上下文(内存)、文件系统(磁盘)、KV 缓存(缓存层)。数据库的查询优化对应着上下文检索,事务隔离对应着智能体隔离,数据压缩对应着上下文压缩。

Pete 提到的”通过通信”和”通过共享内存”两种模式,实际上对应着数据库中的消息传递和共享存储两种架构。当子智能体需要完整历史记录时,使用共享上下文模式,这就像数据库中的共享存储架构。当任务相对独立时,使用通信模式,类似于分布式数据库的消息传递。

智能体间的状态同步问题,本质上就是分布式系统的一致性问题。

Manus 的解决方案也借鉴了数据库的设计思想。他们使用结构化的模式(schema)来定义智能体间的通信接口,确保数据的一致性。他们的分层行为空间设计(函数调用、沙盒工具、软件包与API)类似于数据库的存储引擎分层。

这种类比不仅仅是理论上的相似。在实践中,你可以直接应用数据库系统的很多优化技术。比如,使用 LRU 策略决定哪些上下文应该被压缩或摘要;使用预写日志(WAL)的思想,在摘要前先把完整上下文写入日志文件;使用索引来加速文件系统中的信息检索。

我们可以借鉴数据库领域几十年的研究成果和工程实践,而不是从零开始摸索。

3. 上下文工程的核心是做减法,而不是加法

Pete 在分享最后强调的这一点可能是最重要的:避免上下文过度工程(context over-engineering)。

他提到,Manus 上线六七个月以来,最大的性能提升不是来自增加更复杂的上下文管理机制,而是来自简化架构、移除不必要的功能、对模型给予更多信任。他们已经重构了 Manus 五次,每次都是在做减法。

比如,早期的 Manus 使用 todo.md 文件来管理任务列表,结果发现约三分之一的操作都在更新这个列表,浪费了大量 Token。后来他们改用更简单的结构化规划器,效果反而更好。

另一个例子是工具选择。他们没有使用复杂的语义搜索来动态加载工具,而是固定使用 10-20 个原子功能,其他所有功能都通过沙盒中的命令行工具或 Python 脚本来实现。这种分层的行为空间设计,让系统既灵活又简单。

Pete 还提到了一个评估架构的方法:在强弱模型之间切换测试。如果你的架构从弱模型切换到强模型后能获得明显提升,说明架构有较好的未来适应性。因为明年的弱模型可能就和今天的强模型一样好。

关于是否要训练专门的模型,Pete 的观点也很明确:初创公司应该尽可能长时间地依赖通用模型和上下文工程。训练专门模型不仅成本高,而且在产品快速迭代的阶段,很可能在优化错误的指标。MCP(Model Context Protocol)的推出就是个例子,它彻底改变了 Manus 的设计,如果之前投入大量资源训练专门模型,这些投入就浪费了。

他们现在也不使用开源模型,不是因为质量问题,而是成本问题。对于输入远长于输出的智能体应用,KV 缓存至关重要。大型云服务商有更好的分布式缓存基础设施,算下来使用他们的 API 反而更便宜。

这些经验告诉我们:上下文工程的目标是让模型的工作变得更简单,而不是更复杂。不要为了优化而优化,每个设计决策都要基于实际的性能数据和用户反馈。

4. 压缩与摘要的本质区别决定了使用策略

Pete 详细解释了压缩和摘要这两种看似相似实则截然不同的策略,这个区分对实际应用至关重要。

压缩是可逆的。在 Manus 中,每个工具调用都有完整格式和紧凑格式。比如写文件操作,完整格式包含路径和内容,紧凑格式只保留路径。因为文件已经存在于文件系统中,通过路径可以随时恢复完整信息。这种可逆性至关重要,因为你永远不知道哪个历史操作会在后续变得重要。

摘要是不可逆的。一旦执行摘要,原始信息就永久丢失了。因此必须非常谨慎。Manus 的做法是在摘要前将完整上下文转储为日志文件,作为最后的保险。而且摘要时要保留最新几次工具调用的完整信息,让模型知道当前的工作状态。

关于阈值的确定,Pete 分享了具体数据:大多数模型在 200k Token 左右开始出现性能下降,他们将 128k-200k 设定为”腐烂前”阈值。这不是随意设定的,而是通过大量评估得出的。他们测试了不同长度下模型的重复率、推理速度、输出质量等指标。

触发策略是渐进式的:

  • 接近 128k 时,开始压缩最旧的 50% 工具调用
  • 压缩后检查实际释放的空间
  • 如果压缩效果不明显(因为即使紧凑格式也占用空间),才考虑摘要
  • 摘要时使用完整版本而非压缩版本的数据
  • 始终保留最新的几次完整工具调用

尽可能保留信息的完整性,只在必要时才接受信息损失。这就像数据压缩算法中的无损压缩和有损压缩,你总是先尝试无损方案。

不同类型的内容有不同的压缩潜力。搜索结果、API 响应这类内容压缩效果好,因为大部分信息可以通过查询重新获取。而用户的指令、模型的推理过程压缩空间有限,因为这些信息往往都是必要的。

5. 隔离策略的选择取决于任务特性而非直觉

多智能体隔离是个老话题,但 Pete 分享的经验推翻了很多常见做法。

首先是反模式的识别。很多团队喜欢按人类角色划分智能体:设计师智能体、程序员智能体、经理智能体等。Pete 明确指出这是个陷阱。这种划分源于人类组织的局限性(个人能力和注意力有限),而不是 AI 系统的最优设计。Manus 只有极少的几个功能性智能体:通用执行器、规划器、知识管理器。

关于隔离模式的选择,Pete 区分了两种场景:

通信模式适合结果导向的独立任务。主智能体发送明确指令,子智能体独立完成,返回结果。整个过程主智能体不关心细节,只要最终输出。比如”在代码库中搜索特定函数”、”将这段文本翻译成中文”。这种模式的优势是上下文干净、成本低、易于调试。

共享上下文模式适合需要完整历史信息的复杂任务。子智能体能看到所有历史对话和工具调用,但有自己的系统提示和工具集。比如深度研究任务,最终报告需要参考大量中间搜索和笔记。这种模式成本高(需要预填充大量上下文,无法复用 KV 缓存),但对某些任务是必要的。

判断使用哪种模式的关键是从结果推理过程的依赖性。如果最终输出强依赖于中间步骤的细节,就需要共享上下文。如果只需要最终结果,通信模式就足够了。

Pete 还提到了一个实用技巧:”智能体即工具”(agent as tool)。从主智能体视角,调用子智能体就像调用普通工具,有明确的输入输出接口。这简化了系统设计,也让调试更容易。Manus 的”高级搜索”功能就是这样实现的,表面上是个工具,实际是个完整的子智能体工作流。

他们解决通信问题的方法是强制使用结构化输出。主智能体调用子智能体前必须定义输出模式,子智能体通过专门的”提交结果”工具返回数据,系统用约束解码确保格式正确。这避免了自由格式通信带来的解析问题和信息丢失。

6. 一些额外的技术洞察

除了这五个核心经验,还有一些值得记录的技术细节。

信息的局部性。使用基于行的格式意味着每行都是独立的信息单元,读取第 100 行不需要解析前 99 行。这对于大文件的随机访问至关重要。

结构化不等于复杂格式。Pete 强调,他们优先使用基于行(line-based)的纯文本格式,而不是 JSON 或 XML。原因很简单:模型可以用 grep 搜索特定行,用 sed 修改特定内容,用 head/tail 读取部分数据。这些都是模型已经掌握的基础工具。

关于 Markdown 的使用要特别谨慎。虽然模型都接受过 Markdown 训练,但过度使用会带来副作用。某些模型会因此输出过多的项目符号和格式化标记,浪费 Token 还影响可读性。Manus 的经验是:在需要结构时用 Markdown,在存储数据时用纯文本。

关于模型切换的评估方法。Pete 提到,他们会在强弱模型间切换来评估架构的未来适应性。如果一个架构在弱模型上也能工作(虽然效果差一些),说明它不是过度依赖特定模型能力的脆弱设计。

关于工具数量的上限,他们的经验是不超过 30 个。这不是任意数字,而是基于大量测试。超过这个数量,模型开始频繁调用错误的工具,甚至调用不存在的工具。解决方案不是动态加载工具,而是设计分层的行为空间:少量原子工具 + 沙盒命令 + 代码执行。

关于评估体系,Manus 的三层评估值得借鉴:用户评分是北极星指标,自动化测试覆盖可验证的任务,真人评估处理主观性强的输出。学术基准测试只是参考,不能作为主要依据。

上下文工程不是一些零散的技巧,而是一个需要系统思考的工程领域。每个设计决策都会影响到其他部分,没有放之四海而皆准的最佳实践,只有基于具体场景的权衡取舍。

以上。