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

文章来自：51CTO