前沿重器
栏目主要给大家分享各种大厂、顶会的论文和分享，从中抽取关键精华的部分和大家分享，和大家一起把握前沿技术。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。（算起来，专项启动已经是20年的事了！）
2024年文章合集最新发布！在这里：再添近20万字-CS的陋室2024年文章合集更新
往期回顾
在小半年前吧，我尝试理性地去聊了聊上下文工程（前沿重器[72] 大模型"外脑"揭秘：Context Engineering综述、前沿重器[71] Context Engineering深度解读：范式跃迁，还是概念包装、）。时至今日，在自己的实践和持续学习下，感觉以前的经验的确有些浅薄了，这次，我带着Manus的一篇技术披露，深入分享一些上下文工程的技术细节。
这是一篇季逸超和Lance Martin的网络分享会记录，来自Lance Martin的记录分享。
-
Lance Martin的PPT：https://drive.google.com/file/d/1QGJ-BrdiTGslS71sYH4OJoidsry3Ps9g/view
-
季逸超的PPT：https://docs.google.com/presentation/d/1Z-TFQpSpqtRqWcY-rBpf7D3vmI0rnMhbhbfv01duUrk/edit?usp=sharing
话不多说，开始吧。
当然，这里我讲的不会局限在Manus以及博客原文本身，可能会从中拓展开，讲一些思路和相关的做法。
Agent中的上下文困境
在以大模型为基础的Agent系统内，我们通常需要不断地分析问题、调用各种工具、总结工具结果，随着这些步骤的增加，我们要往大模型塞的东西会不断增加，这问题，都别说突破大模型最大token数的这个瓶颈，哪怕没突破，大模型的处理质量也会随着输入长度的增加而逐步下降。以简单的RAG为例，查询的文档片段数量并不低，如果多次查询，多链路查询，这个文档数量是极多的，于是会有如下问题。
-
token数量消耗极大，成本提升。
-
导致关键 token 的 attention 权重被稀释，影响最终的回复质量。
-
当超过窗口限制，早期关键信息可能被丢弃，破坏任务连贯性。
因此，我们非常有必要在Agent处理过程，我们需要对这个上下文信息进行精筛和控制，降低成本，提升最终回复质量。
上下文工程方法
为了应对这个长上下文问题，Manus提供了3个关键方法，减少上下文、卸载上下文和隔离上下文。
减少上下文
此处，Manus会把工具调用分成full和compact模式。full模式内存储了工具调用的原始结果，存储在沙箱/或者说临时的文件系统里，而紧凑版本则是对完整结果的调用，full版本存储对完整结果的引用，例如文件路径。
-
对老的工具结果，用compact模式工具结果替代完整版本的结果，此时在调用大模型时就能实现token的节省。
-
对新的工具结果，用full模式，得到更精准的效果。
文中提到，这个类似的模式也在Anthropic中提到，这里我和文章一样引用原文。
Context editing automatically clears stale tool calls and results from within the context window when approaching token limits. As your agent executes tasks and accumulates tool results, context editing removes stale content while preserving the conversation flow, effectively extending how long agents can run without manual intervention.
我的理解，这个compact模式的压缩，很可能是下面这种模式的，某些不那么重要的细节，可能会通过转存的模式得以保留和链接。
go
[已保存至 /workspace/outputs/data_analysis.csv]如果只是需要一个简单的结果，那读到compact即可，如果是信息不足，则可以直接去这个data_analysis.csv读取更详细的信息。
更进一步，当这个链接足够多，仍然有可能会有token爆炸的情况，此时可以更进一步，对整个调用链路进行压缩，有个说法叫做结构化轨迹摘要，类似的工作在strategy/procedural/working memory都有提及，当然在self-evolution中也有，说白了不仅记录知识点，还能记录流程，就都串起来了，这些流程记忆不仅对单个任务有好处，对整个Agent系统的自优化都是有好处的。
补充一点，这里背后有个假设------LLM 上下文中的观测数据存在明显的时效衰减特性，即在多步工具调用过程中，刚返回的工具结果对下一步决策至关重要，而早期已被消费或聚合的结果则逐渐失去直接推理价值。若将所有历史观测无差别保留在上下文中，不仅浪费宝贵的 token 预算，还会因无关信息干扰注意力分布，导致关键信号被稀释。
隔离上下文
与当前主流 Agent 框架中流行的"多角色协作"范式不同，Manus并不将角色的分工拟人化成类似设计师、工程师这种模式，人类的分工更多是因为专业、认知的差异，然而Agent并不需要这种限制，Manus指出角色划分本身并非目的，上下文隔离才是关键。通过创建独立的上下文作用域，防止不同子任务之间的信息相互污染。
此处，Manus区分了3个角色。
-
规划器（planner）：分配任务
-
知识管理器（knowledge manager）：审查对话并确定应保存在文件系统中的内容
-
执行子智能体（executor sub-agent）：执行规划器分配的任务
Planner上，早期的Manus使用的是todo list的模式，结果发现有三分之一的token会花费在更新这个列表上，他们转而使用专用的规划器智能体，调用执行子智能体来执行任务。
-
对简单的任务（如查天气），Executor 的上下文仅包含 Planner 下发的精简指令，不携带任何历史对话或无关观测；
-
对复杂复合任务（如"分析用户行为日志并生成可视化报告"），Executor 则被授予访问完整 Planner 上下文快照以及共享文件系统的权限，以支持多步推理与中间状态复用。
这种模式有两个特点，是我们在系统内使用多步LLM作为内部核心流程算法时所需要关注的。
-
每个子任务仅获得完成其职责所必需的信息，既避免了无关历史对注意力的干扰，也降低了因上下文过载导致的幻觉风险。
-
所有 Executor 的输出均通过Schema约束与受限解码技术强制规范化，确保最终结果可被程序可靠解析，而非依赖脆弱的后处理正则匹配。
这一设计使得 Manus 能在保持 LLM 表达灵活性的同时，获得接近传统软件系统的接口契约可靠性。
卸载上下文
这一块讲的是工具的使用。工具是Agent系统内能力的体现，工具多强，理论上这个系统的能力就越强，因此我们是希望这个系统内能承载的工具更多更强的。
工具定义
这里有一个困境，这么多的工具，都有各自的工具说明，能力描述，首先肯定不能全都扔进大模型里让大模型选，这样会浪费宝贵的token，效果还不一定好。
Manus给出的方案是，把工具简化成通用的模式，例如，Bash工具和几个访问文件系统的工具，然后弄个沙箱，让大模型可以自由调度函数，然后在沙箱里自己进行计算分析，这种方式把工具给卸载到了沙箱。
注意，这里和Claude的skills可谓是异曲同工了。技能存储在文件系统中，而不是作为绑定工具，Claude 只需要几个简单的函数调用（Bash、文件系统）就能逐步发现和使用它们，现在github上其实已经有不少的skills开源库供大家使用了。这里出了一个比较火的说法------渐进式披露（Progressive disclosure），让系统只有在需要他的时候才会被加载。
另外，由于这个问题非常普遍，所以也有不同的解决方案，之前讲过的元宝（前沿重器[75] | 腾讯元宝重磅出击：Agentic RAG如何让搜索"重生"）介绍过，他是通过构建搜索模块来实现的这个方案。各有优劣吧，Manus这种自由度较高的场景，这么弄还是可以的，但是因为是自上而下的优化，所以定制化低、维护成本高的确是问题，元宝的方案则灵活度会高点，维护起来会更容易，但是这需要的专业性会高不少。
工具结果
工具的结果并不会直接扔给大模型，而是会做一个compact版本放到文件系统里，Manus是通过glob或者grep来找到这个文件进行处理。
模型选择
Manus 在模型使用策略上，他并没有使用单一模型，而是根据实际任务与根据子任务的语义特性，动态调度最适配的 LLM，Claude 进行编码，Gemini 进行多模态任务，或 OpenAI 进行数学和推理。
Bitter Lesson
Rich Sutton 在《The Bitter Lesson》中提出的核心洞见：在人工智能领域，长期来看，最大的进步几乎总是来自通用计算方法（如搜索、学习、规模扩展），而非人类精心设计的领域知识或手工规则。Manus一直铭记这一点。为此，他们是做了很多思考和优化。
-
自 2025 年 3 月上线以来，系统已彻底重构 5 次（文章时间是25年10月）；
-
每次重构的触发条件并非功能缺失，而是当新发布的更强 LLM（如 GPT-5、Claude 4）在现有框架下无法带来预期性能提升时；
-
此时团队会反向推断：瓶颈不在模型，而在框架本身------即当前的上下文管理策略、工具抽象方式或状态传递机制已成为"枷锁"。
举个例子，早期版本曾尝试在 Planner 中硬编码任务分解规则，或在 Executor 中注入领域特定的 prompt 模板。但当 Claude 3.5 发布后，这些人工规则反而限制了模型自主规划的能力，导致整体任务成功率停滞。于是团队果断移除这些"聪明设计"，回归到更通用的 Schema 约束 + 文件系统交互范式。
这里有一句有意思的结论。
If performance doesn't improve with stronger models, your harness may be hobbling the agent.
在这个假设下，他们的设计师尽可能让框架适配模型，尽可能地适配模型的能力，不让框架限制模型的发挥，而是助力模型的发挥。
这个思路无疑是新颖的，对于通用的Agent系统应该一定程度是适用的，然而在垂类或者是更细小的领域下，很多时候限制模型发挥的并非是框架，而是大模型自身和实际业务的信息差，此时我们需要一些机制告诉系统，什么事不合规，什么事不能做，或者是什么事应该怎么做，这是框架需要约束大模型的部分，也是我们要和大模型磨合的部分，就像面对一名能力不差甚至是挺强的新员工一样。
小结
Agent方面，Manus真的有东西吧，上面这些技术建议能看出，他们真的有比较丰富的实践经验。我简单总结一下。
-
上下文工程上，通过减少、隔离、卸载的模式很大限度的优化，确保进入大模型的内容足够精炼，以达到降低成本、保证回复质量的效果。
-
简化架构，很多事情下放到沙箱，构造一个沙箱来自动调用工具，如代码，自动完成任务。
-
Bitter Lesson的理解颇为透彻，不是"教会模型做事"，而是"不挡模型的路"。这确实是一种做前沿探索的思路，拥有比较高的视角，Manus也确实在践行。
