路由和上下文经济学：这一周工具在改写成本结构

结论先行：这一周工具圈最值得记的不是谁又变强了，而是成本结构被重写了一遍——同一个模型可以按任务自动路由到不同档位，长会话不必每轮重发全部历史，一个人的固定成本因此第一次跟任务量脱钩。

过去两年，所有人算成本的方式都是一样的：调用一次多少钱，乘以大概多少次，得到一个月花多少。这个算法有一个致命前提——每次调用都按同一个价、每次都带同样多的上下文。

这一周公开发布的东西，几乎同时拆掉了这两个前提。

一、三条消息，指向同一个方向

• 路由：不再手工挑模型。某代码托管平台的多模型自动路由功能正式可用，按推理、代码生成、调试、工具调用等不同需求评估任务，再决定用一个还是多个模型执行，并提供三档强度。官方给出的数字是：最高档与性能最强档的表现相差不到 2 分，但单任务成本约为其一半，耗时少约四成。
• 上下文：不必每轮重发全部历史。某大模型平台上线了消息线程的公开测试，智能体每轮只发送新增消息，不用再把完整对话历史重复传一遍。官方给出的数字是：在五十万到一百万 token 规模的请求下，首字响应时间中位数下降约 35%。
• 分工：一个智能体当主管，指挥一群智能体干活。某国产团队开源了一套架构原型，采用「路由 + 执行」双层设计，主管智能体负责接收消息、判断是否接单、分派任务和统一回复，多个执行智能体各有独立的会话和工作目录，可以从代码托管平台的评论或即时通讯工具接活。

二、为什么这对一个人特别重要

先看原来的算法。一个人的成本大概是三块：工具订阅费、模型调用费、自己的时间。前两块是固定支出，第三块是变动支出。

问题是，一个人做服务型生意，收入几乎完全跟第三块挂钩。干得多赚得多，一停下来收入就断。这不是勤奋能解决的问题，是结构问题。

路由和上下文这两件事，动的正是第一块和第二块之间的关系，而且动的方向很特别——它们让「一个人的时间」能同时承载更多任务，而固定成本不变。

• 路由的作用：把简单活交给便宜档，把难活交给贵档，中间那道「我该选哪个」的判断力，工具替你做了。对一个人来说这道判断力很贵——你得知道每个任务实际需要什么水平，一次判断错了就是白付好几倍的钱。
• 上下文的作用：长任务里每轮重发全部历史，是很多「AI 越用越贵」体感的技术来源。改成只发增量之后，同样的任务长度，账单不再随轮数线性往上走。

两者叠加的效果是：一个固定成本不变的小团队，能处理的并发任务量上去了。这不是「效率提升」这种模糊说法，而是成本表上某一栏从固定变成了可变弹性。

三、三个能收钱的位置

1. 路由策略的代配置与代运维。工具自动路由解决了「选哪个」，但没解决「按什么标准分档」——哪类任务算简单、哪类必须用强的、哪些可以降级处理、失败怎么兜。这是需要人来定的部分，也是可以按次或按月卖的服务。客户付的不是工具订阅费，是「你别给我配错」这句承诺。
2. 上下文瘦身改造。很多团队的账单高得莫名其妙，原因是每个任务都带着一大段永远用不到的历史。做一次清理——哪些该进上下文、哪些该进外部文件、哪些直接删——往往能砍掉可观的一块。这是一次性的改造服务，交付物清晰，最好卖。
3. 把「主管 + 执行」这套结构卖成产品。主管智能体派工、执行智能体各干各的，这个结构对交付形态的影响是：你能同时盯着的活变多了。对应的服务是给客户的重复流程做一套「派工 + 执行 + 汇总」的编排，做完按月维护。这一档是三种里唯一能绕开「收入等于工时」的。

三档的共同点是：客户买的都是「成本变得可预测」，不是「AI 变聪明了」。前者能算账、能写进合同，后者只能写进宣传语。

四、三个坑

• 坑一：以为路由能替你做业务判断。工具按「任务类型」分档，按的是任务表面特征。但你的业务里最难的任务，往往长得最简单——一次「帮我看看这个方案」，背后可能是要拍板几十万的事。分档规则里必须留一个人工提权的口子，否则最关键的活会被自动降级处理，而且降得悄无声息。
• 坑二：把上下文压缩当成省钱手段。省下来的钱是真的，但砍掉的信息也是真的。一段被砍掉的历史，可能正是模型判断的依据，砍掉之后它会「自信地编一个」。该留什么，不该留什么，是需要按业务定的规则，不是按 token 预算定的。
• 坑三：主管架构一上来就铺开。多智能体并行听起来很强，但每个执行单元都是一条独立的出错路径，出了错你要能看出是哪一环出的。做这类编排的正确顺序是：先让一个执行单元稳定跑通，再加第二个，最后才加主管。顺序反了，就是同时制造三处不确定性。

五、三个今天就能做的动作

• 把上个月的调用账单拆开看一眼。按任务类型分开记，看看哪一类活占了最多的钱却最不值钱。这张表是你谈任何 AI 相关服务时最有力的东西，也是你自己最该先优化的。
• 给你最长的一条工作流算一笔账：它现在每轮带多少历史、走几次调用、一次多少钱。三个数一乘，你大概会想动手改点什么——哪怕只是把每轮都带的某段文档换成按需读取。
• 写下你业务里「不能被自动降级」的那一类活。列出来，标注清楚它长什么样。这是将来配路由规则时最重要的一条，也是你现在就能拿来和别人谈的差异化。

最后回到这一周本身。三条消息看起来分散——一家代码托管平台、一家大模型平台、一家国产团队，做的也不是同一件事。但它们改的是同一个东西：调用成本和任务量之间的关系。

过去这段时间，一人公司的处境是「一个人干四五个人的活，但只能赚四个人的钱」。现在这个换算比例开始松动——不是因为你变强了，而是因为工具开始替你做那些「判断该用多大火力」的决策。这层判断力一旦被工具接走，你一个人的产能上限就跟着往上抬，而固定成本还留在原地。

这个窗口不会永远开着。路由、上下文、编排这三件事一旦变成基础设施的默认配置，它们就不再是差异，而是基线——而基线是不值钱的。所以现在值得做的，是在这三件事上把「客户该分档怎么分、上下文该留什么、哪些活不能让机器碰」这三个判断先攒下来。工具会替你算成本，但替你做判断的，永远得是你自己。

至于那些每天都要跑一遍的重复产出，本质上是同一道题：执行层交给流水线。比如本站公众号图文工具这样一次跑完选题到成稿的通道，意义不在于「省了几毛钱」，在于它把你从「天天必须做」这件事里摘出来——摘出来的时间，正好够你把上面那三个判断攒明白。