把 Manus Cascade 的「按需加载」搬进自己的 Agent:三步省出两成 Token
Manus 2.0 换上自研底座 Cascade 后,公布一组测试数据:相较上一代,Token 消耗降 23.2%、任务完成时间缩 28.2%、运行成本降 32%。官方特别注明这是单项测试配置的结果,不是全任务平均。但它点破了一个普遍浪费:大多数 Agent 一上来就把全部工具描述、全部历史、全部专业能力塞进上下文,哪怕任务根本用不到。Cascade 的做法是「起步保持轻量,按需才加载」。 第一步:工具描述怎么做分层加载? 别在系统提示里一次挂二十个工具。把工具分成「核心动作」和「专业能力」两层:核心动作,例如读文件、跑命令、发请求,始终在线;专业能力,例如画图、视频、检索某库,做成可被检索的清单。当任务命中某类专业需求,再让模型按需把对应工具描述拉进上下文。这一步通常能砍掉系统提示的一半长度。 第二步:上下文怎么做到起步最小? Cascade 的另一个要点是项目初始状态轻量。对应到工程上:新会话不要默认灌入全部历史与知识库,而是先让模型基于一句任务描述规划,再由规划结果决定加载哪些文档。这与「全量塞进上下文再让模型挑」是两种范式——前者是按需取,后者是倒进来再筛。 第三步:怎么给能力加载记一笔成本? 每多加载一个工具或文档,都意味着后续每一轮都要为它付 Token。给每次加载记一笔账,让模型在规划时就感知到成本:能用现有工具一步完成的,绝不新加工具。配合一个简单规则——连续两轮没用到的工具,下一轮从上下文摘除——可以把长尾浪费压掉。 按需加载会带来什么副作用? 按需加载省 Token 的代价是「多一次决策」:模型要先判断需不需要某个能力,这一跳本身可能出错,导致该加载时没加载。解决办法是保留一个回退:任务失败时自动把被裁剪的工具加回来重试一次。Manus 那 23.2% 背后,大概率就有这套回退机制在兜底。 这套省 Token 思路今晚就能改吗? Cascade 证明了一件事:Agent 的省 Token 空间不在模型单价,而在「上下文是不是给多了」。把工具分层、上下文按需、加载记账这三步做到位,任何自研 Agent 都能复刻出自己版本的两成降幅——而且今晚就能改。 去论坛讨论 这篇文章里的观点,欢迎到硅基AGI论坛讨论。按标题搜索:Cascade按需加载

