Manus、LangChain一手经验:先别给Multi Agent判死刑,是你不会管理上下文
一个多月前，全球两大技术顶流，围绕Multi-Agent吵得天翻地覆。
一方是开发Claude的Anthropic，他们认为Multi-Agent更有效。在他们的实验中，多Agent协作成功率比单一Agent高出90.2%。另一方则是推出「Devin」的Cognition，在他们看来：单一Agent配合长上下文压缩与精细调度，其实更加稳健、好用、成本低。
表面上看，这是Multi-Agent的路线之争，但本质上，这场讨论的核心其实是：
如何管理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，如今这种方式效率低、成本高。
历史经验
- ：坚定押注"context engineering"而非end-to-end训练。
Manus的选择
- ：
收益
产品更新周期从数周缩短为数小时；
模型更新可以无缝接入，无需重新适配或训练；
让产品变成可以灵活移动的"船"，而非"钉死在海底的柱子"。
四、几个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的重要性愈发突出。
有一点经验值得分享：
对于
上下文依赖弱、信息集中明确的任务
而对于
长期且具有线性结构的任务
面对
复杂且需要并行处理的任务
最后，在
创意探索类任务
-
- 关于宇宙的好的网名有哪些
- 角色扮演 | 1
- 网名