Manus、LangChain一手经验:先别给Multi Agent判死刑,是你不会管理上下文

一个多月前，全球两大技术顶流，围绕Multi-Agent吵得天翻地覆。

一方是开发Claude的Anthropic，他们认为Multi-Agent更有效。在他们的实验中，多Agent协作成功率比单一Agent高出90.2%。另一方则是推出「Devin」的Cognition，在他们看来：单一Agent配合长上下文压缩与精细调度，其实更加稳健、好用、成本低。

表面上看，这是Multi-Agent的路线之争，但本质上，这场讨论的核心其实是：

打个比方，如果说大语言模型是CPU，那么上下文窗口就是RAM——它是模型的工作内存。

但问题是，硬件的RAM是有限的，模型的上下文长度也是有限的。对于AI智能体，尤其是多智能体这种需要多步骤、长时间处理的复杂任务，会产生海量信息，导致AI"消化不良"。这会引发几个致命的问题：

• 信息超载
  ：超出AI的"记忆容量"，直接卡死

• 成本飙升
  ：处理信息越多，花钱越多，延迟越高

• 性能下降
  ：信息太杂乱，AI反而变笨了

那么如何解决这个问题？Langchain、Lossfunk、Manus在内，业内有几个不同的思路，下面一一解读。

一、LangChain的Context Engineering四大策略

LangChain看来，Agent的上下文管理问题，可以归纳为四种：

• 上下文污染
  ：错误信息混进来，AI开始胡说八道

• 上下文分散
  ：有用信息被垃圾信息淹没

• 上下文混淆
  ：无关信息太多，AI搞不清重点

• 上下文冲突
  ：前后矛盾的信息让AI精神分裂

面对这些挑战，LangChain团队深入研究后，提出了Context Engineering的四大核心策略：写入、选择、压缩、隔离。

1. 写入上下文：给AI装上"便签纸"

就像做复杂工作时会记笔记一样，AI处理复杂任务时也需要把关键信息写下来，避免重复分析。比如在代码审查中，AI会把每个文件的问题清单和修改建议记录下来，而不是每次都重新扫描整个代码库。这样既省时间又避免遗漏。

2. 选择上下文：只看重要的信息

不是所有信息都值得进入AI的视野。Windsurf团队在处理大型代码库时发现，必须结合语法分析、知识图谱检索等技术，才能从成千上万行代码中找出真正相关的片段。这就像在图书馆里精准找到需要的那几本书。

3. 压缩上下文：把长故事变成要点

Claude Code的"auto-compact"功能展示了最佳实践：当对话记录快撑爆"内存"时（使用率超过95%），自动把几百轮对话压缩成核心要点。

4. 隔离上下文：分工合作，各司其职

LangGraph的多智能体架构把复杂任务拆解成独立模块，每个子任务在专门的"房间"里处理，避免相互干扰。Anthropic也指出，经过隔离上下文的multi-agent表现会优于单一智能体，因为每个子智能体都会拥有独立的上下文，探索一个问题的不同角度。

就像项目团队中每个成员专注自己的模块，最后整合成完整方案。这样既提高效率，又避免了"一锅粥"的混乱。这四种策略相互配合，形成了完整的上下文管理体系。

二、Lossfunk的6个上下文管理技巧

[Insight #1] 将任务拆分为人类可在10–15分钟内完成的小块

• 核心观点
  ：LLM成功执行任务的概率与人类完成该任务所需时间强相关。根据METR研究，任务耗时越短，LLM成功率越高（10分钟任务约等于90%成功率）。

• 工程建议
  ：不要期望LLM能在一个长session内完成复杂任务。应该将其拆分为原子化任务，每个子任务能在模型当前上下文内自洽完成。

[Insight #2] 一体化Agent + 长上下文胜于多Agent + RAG

• 观点
  ：如果模型的上下文窗口够大，应尽量将完整文件或数据一次性塞进context，而不是碎片化检索（RAG），后者的知识是碎片化的。

• 经验引用
  ：Cline项目和SWE-bench-Verified benchmark都证明完整上下文效果更佳。以前使用diff模型组合处理更新，误差高达20%；改用LLM生成REPLACE block，误差降到5%。

• 隐含逻辑
  ：绕过成本的工程取巧（如快照diff模型）往往带来质量牺牲。随着基础模型变强，应少用workaround，多信任模型原生能力。

[Insight #3] 长流程易失败，务必构建逐步验证机制

• 挑战
  ：任务流程越长，出错概率越大，且错误会层层积累。

• 应对策略
  ：
  将每一步设计为尽可能无状态的函数调用，减少上下文依赖；
  每一步任务完成后进行显式验证，模型必须能区分成功与失败，否则会带着错误一路狂奔。

• 目标
  ：降低耦合度、增强可测试性，使每步可观察、可诊断、可回滚。

[Insight #4] 把LLM当失忆天才，持续喂任务和上下文

• 原理
  ：模型容易遗忘早期输入。尤其在长对话中，前面的任务指令可能会被挤出上下文窗口。

• 实践建议
  ：
  不断重复todo list或关键任务信息；
  在prompt中显式列出当前步骤、目标和注意事项；
  引导模型先读文件再执行，有助于自建思路。

• 提示
  ：不需要一次性把所有上下文硬塞进prompt，而是让模型通过指令主动拉取信息。

[Insight #5] 给模型工具权限，让它主动构建自己的上下文

• 新范式
  ：别只往context塞内容，而是让模型自己去读写——就像人一样，动手比死记更强。

• 设计重点
  ：
  工具（如读文件、查数据库）需精心构建，避免信息过载或不足；
  工具调用的返回内容应简洁明确（如："查询成功，有10k条，这里展示前5条"）；
  出错时，提供恰当量级的信息以便恢复，而非一味输出全量堆栈。

• 总结
  ：工具接口设计是门信息设计的艺术。

[Insight #6] 多轮对话成本呈二次增长，务必保持上下文不可变

• 事实
  ：每增加一次对话轮次，如果上下文每次都变，LLM无法命中KV cache，成本激增。
  50轮时 ≈ $2.5/response，100轮时可飙升至 $100/response；
  如果上下文不变，命中KV cache成本可下降到1/10。

• 工程对策
  ：
  只追加上下文，不要替换；
  设计结构化memory和状态保存策略，以节省token；
  明确你的agent是否值得花这么多钱运行（用户真的愿意为它花钱吗？）。

三、Manus的七个Agent小技巧

Manus不久前正式公开了其产品逻辑，以及踩坑经验，并给出了七大context工程设计原则：

1️⃣ 设计围绕KV-Cache展开：缓存命中率是王道

• 核心观点
  ：生产级agent的最关键指标就是KV-cache命中率，直接影响成本与响应时间（TTFT）。

• 原因
  ：Agent的输入越来越长（大量上下文与工具调用记录），但输出短（如函数调用），prefill成本极高。

• 优化策略
  ：
  保持prompt prefix稳定，避免加入每秒变动的时间戳等干扰缓存；
  上下文追加而非修改，JSON序列化时使用确定性顺序；
  明确打上缓存断点标记，在某些模型框架中需手动设置。

2️⃣ 工具动态加载容易毁掉Agent，应该使用"屏蔽"而非"删除"

• 问题
  ：随着工具越来越多（甚至用户自定义数百个），模型选择工具时更容易出错或卡住。

• 教训
  ：动态插入/移除工具会使KV-cache失效，并引发引用未定义工具的问题。

• 解决方案
  ：
  不删除，只屏蔽：使用token masking技术动态调整可调用工具集；
  工具命名应有统一前缀（如browser_），便于分组与限制；
  使用Hermes格式或API支持的function-calling prefill来控制选择空间。

3️⃣ 文件系统是无损上下文的最佳外部内存

• 挑战
  ：128K上下文看似足够，但遇到大网页、PDF等非结构数据时依然吃紧。

• 常规压缩问题
  ：过早丢弃信息容易导致未来步骤丧失上下文。

• Manus的方法
  ：
  让agent使用文件系统读写，把数据外部化；
  删除网页内容但保留URL，清除文档但保留路径，确保信息可恢复；
  实现类似"长期记忆"系统，也为未来用更轻量架构（如SSM）打下基础。

4️⃣ 利用Recitation操控注意力，保持任务对齐

• 机制
  ：Manus会不断更新todo.md，将未完成目标"复述"到上下文尾部。

• 好处
  ：
  避免"lost-in-the-middle"问题；
  提升模型在长流程中保持目标一致性的能力。

• 总结
  ：通过自然语言"自我提醒"是目前最有效的attention操控方式之一。

5️⃣ 不要隐藏错误，保留失败痕迹让模型自我修正

• 错误是常态
  ：语言模型总会有hallucination、环境崩溃、调用失败等问题。

• 通病
  ：很多系统习惯清除失败痕迹、重试或reset。

• 正确做法
  ：保留失败记录，包括栈追踪或观察结果。这有助于模型调整belief，避免重复同样错误。

• 结论
  ：错误恢复能力是agent智能的真正表现。

6️⃣ 别被few-shot绑架，打破模式有助提升表现

• 问题
  ：模型会"模仿"上下文模式；如果放了太多重复的few-shot示例，它就会陷入固定思路。

• 案例
  ：当Manus批量评审简历时，模型会机械重复行为。

• 解决策略
  ：
  在action-observation模板中加入轻微变化（格式、顺序、措辞）；
  引入结构化噪声，打破固定模式。

• 总结
  ：保持上下文多样性，避免agent变得脆弱僵化。

7️⃣ Context Engineering胜于Fine-Tuning，灵活快、省钱多

• 历史经验
  ：Manus早年使用BERT等模型需数周迭代fine-tune，如今这种方式效率低、成本高。

• Manus的选择
  ：坚定押注"context engineering"而非end-to-end训练。

• 收益
  ：
  产品更新周期从数周缩短为数小时；
  模型更新可以无缝接入，无需重新适配或训练；
  让产品变成可以灵活移动的"船"，而非"钉死在海底的柱子"。

四、几个Context Engineering神器推荐

1. 上下文不够怎么办？用Milvus向量数据库

在实际应用中，面对海量外部知识、历史对话和多模态数据，如何高效存储、检索和动态调用上下文，是AI-Agent的核心挑战之一。

以向量数据库为例，像Milvus这类高性能数据库能够支持文本、图片等多模态数据的向量化存储和高效检索，帮助AI-Agent实时获取最相关的知识片段和历史信息。通过与LangChain、LlamaIndex等主流AI-Agent框架集成，可以实现RAG（检索增强生成）系统，提升智能体的知识获取和推理能力。

简单SDK调用流程：开发者可通过Milvus的Python SDK快速实现上下文的存储与检索闭环，降低技术门槛。

from pymilvus import MilvusClient
# 创建本地Milvus实例
client = MilvusClient("demo.db")
# 创建向量集合
client.create_collection(collection_name="knowledge_base", dimension=768)
# 向知识库批量插入向量化数据
client.insert(collection_name="knowledge_base", data=embedding_vectors)
# 检索最相关的上下文信息
query_vector = embedding_fn.encode_queries(["什么是Context Engineering？"])
results = client.search(
    collection_name="knowledge_base",
    data=query_vector,
    limit=3,
    output_fields=["text", "source"]
)

2. Context Engineering的工具选型推荐

TRAE SOLO模式

就在前几天TRAE推出了2.0版本新增了SOLO模式，该模式本质是一个高度自动化的AI开发agent，它会根据用户输入（自然语言、语音、文件等）自动拆解需求、生成代码、测试、预览和部署。其context engineering体现在：

Kiro的spec专家模式

最近AWS推出的IDE工具Kiro中有一个spec专家模式，强调用结构化规范（spec）来规划和驱动开发流程，其context engineering体现在：

无论是TRAE的SOLO还是Kiro的spec专家模式，本质上都在通过工程化手段管理AI/Agent的上下文，以提升智能体的任务完成能力和效率。这正是context engineering的核心思想。

结语

随着AI模型能力提升，Context Engineering的重要性愈发突出。

有一点经验值得分享：

对于

，例如事实查询或简单问答，最有效的策略是"选择 + 压缩"。无需大量写入和记录历史内容，系统就可以迅速从现有数据中筛选相关内容并进行压缩提炼，以实现快速响应和低成本运行。这种策略广泛应用于智能客服、搜索问答等场景中，强调速度优先和资源节省。

而对于

，如代码开发或文档撰写，则需要采用"写入 + 选择 + 压缩"的组合策略。这类任务要求系统能够逐步积累内容，保持上下文的连贯性，同时不断对内容进行选择性提取和压缩，以避免信息冗余并确保文档质量。此策略特别适合多轮编辑、协同创作等场景，强调信息积累与组织能力的协同优化。

面对

，例如研究分析或数据处理，最佳实践是引入"隔离 + 写入 + 选择"的策略组合。这类任务通常包含多个并行子任务或分析维度，若直接写入可能导致上下文混乱，因此需通过"隔离"机制将不同任务空间划分清晰，再辅以写入和选择策略对结果进行整合。此组合能显著提升处理量和效率，同时避免信息污染。

最后，在

中，如创意设计或头脑风暴，推荐使用"写入 + 选择"的策略。这类任务强调自由生成、思维发散和灵活性，因此不宜在初期过度压缩内容。系统应尽可能保留多样化的想法，并在后续阶段通过选择机制筛选出有价值的思路。这一策略鼓励创新，适用于设计工作坊、品牌构思等需要灵感迸发的环境。