那么，这个听起来高深的“上下文工程”到底是什么？
3. “上下文悖论”：Agent的阿喀琉斯之踵
2022年，我们谈论的是“提示词工程”（Prompt Engineering），它解决的是单次交互。
而2024年，我们面临的是“上下文工程”（Context Engineering），它要解决的是Agent（智能体）的长序列、多轮工具调用。
LangChain的创始人Lance指出了一个“上下文悖论”：
Agent要完成复杂任务，必须大量调用工具（典型任务约50次）来获取上下文。
但上下文越长，Agent的性能就越差，成本也呈指数级上升。
更糟糕的是，Peak发现，即使是100万Token的上下文窗口，模型在处理到200K（约20万）时，性能就开始“腐烂”（Context Rot），出现重复、缓慢和质量下降。
“上下文腐烂”的阈值，大约就在128K到200K之间。
你的Agent又慢又笨，不是模型不行，是你的“上下文工程”没做好。
4. 破局：上下文工程的4大支柱
如何解决这个悖论？LangChain的Lance总结了业内顶尖团队（包括Manus）都在使用的4大工程支柱：
上下文卸载 (Offloading)
做法：不把所有信息都塞进上下文。比如，一个万字的网络搜索结果，只在上下文中返回一个文件路径（file.txt），Agent需要时自己去读。
场景：处理大文件、大输出。
上下文检索 (Retrieving)
做法：把信息（如记忆）存储在外部（如向量数据库），在需要时通过RAG或简单的grep命令检索回来。
场景：长时记忆、知识库。
上下文隔离 (Isolation)
做法：使用多智能体（Multi-Agent）架构，每个子Agent只处理自己的小上下文窗口，互不干扰。
场景：复杂任务拆解。
上下文缩减 (Reducing)
做法：这是最核心也最精妙的一步，即在上下文“腐烂”之前，主动对其进行“瘦身”。
而Manus团队，正是在“上下文缩减”上，做到了极致。
5. Manus实战：“压缩”与“摘要”的精妙艺术
Peak的团队将“缩减”分为了两种截然不同的操作：
1. 压缩 (Compaction)：可逆的“瘦身”
定义：删除那些可以从外部（如文件系统）重建的信息。
3. “上下文悖论”：Agent的阿喀琉斯之踵
2022年，我们谈论的是“提示词工程”（Prompt Engineering），它解决的是单次交互。
而2024年，我们面临的是“上下文工程”（Context Engineering），它要解决的是Agent（智能体）的长序列、多轮工具调用。
LangChain的创始人Lance指出了一个“上下文悖论”：
Agent要完成复杂任务，必须大量调用工具（典型任务约50次）来获取上下文。
但上下文越长，Agent的性能就越差，成本也呈指数级上升。
更糟糕的是，Peak发现，即使是100万Token的上下文窗口，模型在处理到200K（约20万）时，性能就开始“腐烂”（Context Rot），出现重复、缓慢和质量下降。
“上下文腐烂”的阈值，大约就在128K到200K之间。
你的Agent又慢又笨，不是模型不行，是你的“上下文工程”没做好。
4. 破局：上下文工程的4大支柱
如何解决这个悖论？LangChain的Lance总结了业内顶尖团队（包括Manus）都在使用的4大工程支柱：
上下文卸载 (Offloading)
做法：不把所有信息都塞进上下文。比如，一个万字的网络搜索结果，只在上下文中返回一个文件路径（file.txt），Agent需要时自己去读。
场景：处理大文件、大输出。
上下文检索 (Retrieving)
做法：把信息（如记忆）存储在外部（如向量数据库），在需要时通过RAG或简单的grep命令检索回来。
场景：长时记忆、知识库。
上下文隔离 (Isolation)
做法：使用多智能体（Multi-Agent）架构，每个子Agent只处理自己的小上下文窗口，互不干扰。
场景：复杂任务拆解。
上下文缩减 (Reducing)
做法：这是最核心也最精妙的一步，即在上下文“腐烂”之前，主动对其进行“瘦身”。
而Manus团队，正是在“上下文缩减”上，做到了极致。
5. Manus实战：“压缩”与“摘要”的精妙艺术
Peak的团队将“缩减”分为了两种截然不同的操作：
1. 压缩 (Compaction)：可逆的“瘦身”
定义：删除那些可以从外部（如文件系统）重建的信息。
