Philipp Schmid是Hugging Face的机器学习工程师。前几周，他参加了Manus AI和LangChain两家公司的技术分享，听到一个挺有意思的故事：Manus团队重写了五次代理系统，最后发现删代码比加功能效果更好。
这听起来很反直觉。大部分人觉得AI系统越复杂越好，喂给模型的信息越多越聪明。但Manus的经验说，事情正好相反。
Schmid把这次分享整理成博文，核心观点就一句话：给AI找到刚好够用的信息，别塞一堆垃圾进去。
上下文会腐败，就像食物会变质
先说个基本事实：AI模型的上下文窗口会"腐败"。
什么意思？就算你的模型号称能处理100万个token，实际上塞到25万个左右，性能就开始下滑了。就像内存不够用，电脑开始卡顿一样。
这个现象有个专门的名字叫"上下文腐败"（Context Rot）。Schmid说，大部分开发者都忽略了这个问题，一味往里塞信息，结果适得其反。
Manus的三个解决办法
1. 能压缩就压缩，能删就删
Manus发现了两种清理上下文的方法：
可逆压缩 ：把已经存在别处的信息删掉。比如AI写了500行代码存到文件里，聊天记录就别再保存这500行了，只留个文件路径就行。需要的时候再读取。
有损摘要 ：上下文超过12.8万token时，让AI总结早期对话。但有个小技巧：保留最近3轮的完整对话，让模型保持"手感"。
2. 别让所有AI共享同一个大脑
多个AI代理最容易犯的错误：大家共用一套上下文。结果就是信息混乱，每个代理都被无关信息干扰。
Manus借鉴了Go语言的设计思路："通过交流共享信息，别通过共享内存交流。"
具体做法：
- 简单任务（比如"搜索文档中的某个词"）：给代理单独的上下文，只告诉它要干什么
- 复杂任务（比如调试，需要看历史错误）：才共享完整上下文
3. 工具越少越好
给AI提供100个工具，它就会用错。Manus的解决方案是分三层：
底层 ：20个基础工具（写文件、运行命令、搜索等）
中层 ：不单独定义工具，直接用命令行调用
顶层 ：复杂操作打包成代码库，一次性解决
把AI当工具，别当人
很多人喜欢给AI代理起名字，搞什么"经理AI"、"设计师AI"，让它们互相聊天。Schmid说这是过度拟人化。
更好的做法：把子代理当函数用。主AI调用 call_planner(goal="...")，子系统跑完返回结构化结果，就像调用API一样简单。
实际效果怎么样？
有开发者试了这套方法，重构了三次才稳定，但最终token成本降了40%。这个数字挺有说服力的。
几个实用建议
别用检索管理工具 ：根据语义相似性动态加载工具定义听起来很酷，实际上会把模型搞糊涂。
暂时别训练自己的模型 ：模型更新太快，今天训练的明天就过时了。先把工程做好。
设置预警线 ：别等到真正卡死才优化，提前监控token使用量。
用简单指标验证效果 ：代码能跑吗？文件创建成功了吗？别搞复杂的评分系统。
删除的艺术
Manus团队最大的收获是学会了删除。他们删掉了复杂的工具定义，删掉了多余的管理层，删掉了花哨的路由逻辑。结果系统变得更稳定，成本更低。
LangChain的Lance Martin说得好："2025年最好的AI系统，不是能处理百万token的，而是用5万token就能解决问题的。"
“做减法，与大模型现状能力和未来方向相向而行”是对的也符合common sense，但减什么，怎么减，这就不容易了，而这也恰恰是壁垒的一部分。
博文：https://www.philschmid.de/context-engineering-part-2
关注公众号回复“进群”入群讨论。