北京
一个中等复杂度的智能体请求，在推理链上就会消耗2万到6万个词元（token）；当碰到非平凡的工程任务时，每个问题甚至能烧掉15万到20万个词元。而实际情况是，这类消耗正在以工程团队无法忽视的速度膨胀。发现最具性价比的模型一直是所有人的目标，但随着智能体（Agent）应用走向多步推理、多组件协同，选择最便宜的模型已经不再是预算的最终答案——真正要命的，是系统里无休无止的词元流动。
开发者们逐渐看清一个事实：选对模型当然重要，但比这更紧迫的问题在于，如何在整个智能体工作流中限制不必要的词元搬移。一个请求从输入到输出，中间经过的每一次思考、每一次交接，都在默默吃掉大量上下文窗口，最后看到的账单往往远超出模型单价能解释的范围。
同样的任务，如果只交给单个智能体完成，大概会消耗5万个词元；而当任务被拆给多个专业化的智能体协同处理时，动辄就要吃掉几十万个词元。原因很简单：每个智能体都需要足够的上下文才能干活。以典型的智能体交互为例，为了输出区区500个词元的回复，它可能要吞下3万个词元的上下文——输入和输出之间已经拉出了60倍的差距。而且，这种交换在整个工作流里会反复叠加，每一次交接相当于都在缴一笔“输入税”，这笔税会随着循环迭代持续滚雪球。
多智能体架构下，这个问题尤其扎眼。当一个智能体把任务委派给下游智能体时，它必须把自己的当前状态、任务指令等统统编码进接收方的上下文窗口；接收方处理完所有信息后，把结果返回来；然后编排智能体再把这份结果连同自己正在追踪的其他信息一起吞回去。一遍遍的交换、回传、再消化，每一轮都在叠加额外开销，词元预算就这样被一层层抬上去。
一些团队已经开始想办法用更少的词元完成同样的任务。目前比较突出的实践方向有两个：一是压缩上下文但保留推理链路，二是用分层路由把低难度任务分流到更便宜的模型。
压缩上下文的最直接思路，就是不让智能体带着越滚越长的交互历史四处跑，更不用在每个任务执行前都把全部历史重播一遍。系统可以在传递之前，先把前期的对话或者工作记忆做摘要，只保留最关键的片段。另一种做法是主动缩小智能体的视野：与其把整个代码库或全部文档集合都塞给它，不如只暴露和当前任务直接相关的那一小部分。不过这中间有个度，视野切得太窄，智能体就可能丢掉后续需要的重要背景。为了补上这个缺口，系统需要搭配一个紧凑的记忆层，用来锁定关键事实和决策节点。最终要达到的状态是：智能体不用每次都重读整条推理链，但依然能随时回忆起链条上的关键环节。
分层路由的策略则更偏向“经济模型分工”。工程师们可以利用分层路由，把解析一个JSON响应、格式化一条日志条目、检查某个文件是否存在这类轻量操作，交给更便宜的小模型来处理，而不是统统搬出那个用来做系统架构规划的主力模型。通过把高频低难度的任务剥离出去，大模型的调用次数和每次携带的上下文量都会明显下降，整个工作流的词元消耗随之大幅收窄。这背后反映的思路其实很朴素：不是所有思考都需要同一种“脑力”，把消耗降下来，有时比把一个模型的能力拉到顶更重要。
说到底，选择越来越便宜的模型，
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
