全自动信任梯子上线之后——我干了一件我一直该干但一直没干的事：算钱。

不算不知道。一次全自动任务从用户点击「开始」到任务结束——全流程是这样的：搜索关键词调一次模型判断、筛选岗位调一次、深度匹配调一次、生成开场白调一次、发送前安全检查调一次。也就是说——一次完整任务最少调五次模型。如果中间某个环节出错了需要重试——那就更多。峰值的时候我见过一次任务跑了十一次调用的记录——不是因为流程复杂——是因为Agent在一个步骤上反复失败反复重试——每次重试都在烧钱。

我用的模型按token收费。一次任务平均消耗大概六千到八千个token——折算下来单次任务的模型成本在四毛二分钱上下浮動。一天如果跑几百次任务——一个月下来就是两三千块。

四毛二一次——听着不多。但一个用户如果每天跑两次全自动——一个月就是二十五块二的模型成本——而他的月费只有九块九。也就是说——每来一个用户——我都在亏钱。用的越多——亏的越多。这个运营模型从一开始就是倒挂的。

一、我到底在为哪些事情付钱

我把一次全自动任务的详细日志翻出来——逐段逐段看每一轮模型调用到底在干什么。

第一轮调模型——搜索关键词。输入是「帮我搜一下杭州的AI产品经理岗位」——输出是一串搜索参数。坦白说——这个判断连模型都不需要——URL拼接就能解决——但我的Agent直接调了模型。第二轮调模型——筛选岗位。「从刚才搜到的五十个结果里选出五个最值得点进去看的」——这个需要一点理解——但中等模型完全够用——我却一直在调最强的那档。第三轮调模型——深度匹配。把岗位JD和候选人简历逐条比对——算出匹配度——这个确实需要比较强的理解能力——用贵模型是合理的。第四轮调模型——生成开场白。「根据JD和简历写一段自然得体的开场白」——需要创造力和语气把控——用贵模型也合理。第五轮调模型——发送前检查。「检查一下这条消息有没有违规词、语气对不对」——这个我一个正则表达式就能解决的问题——也在调大模型做。

五轮调用里——真正需要用到最强模型能力的——只有两到三轮。剩下的一半——用规则或者便宜的多的模型就能干——甚至干得更好。

但这还不是最让我崩溃的发现。日志里还藏着一个更隐蔽的问题——每次模型调用之前——Agent都会先问一次模型「我刚才调用到哪一步了」和「下一步应该做什么」。也就是说——它在每一步正式开始之前——先花一次调用的钱问路——然后再花一次调用的钱干活。问路那一次的钱——是完全浪费的。

搜索框在哪儿、登录按钮在哪儿、城市选择器在哪儿、搜索按钮在哪儿——这些问题的答案每次调用都一样——但Agent每次都在重复问。它就像一个没有地图的外卖骑手——每天跑同一个小区——每次到门口都要停下来问一遍物业「XX栋怎么走」。

我拉平了所有日志数据——发现一次全自动任务里大约有百分之六十的模型调用是在问「不需要智能的问题」。搜索框位置、按钮坐标、页面结构——这些信息一次拿到之后存下来就可以直接用了——根本不需要每次都问。相当于每次点外卖都要付一份外卖员的问路费——而且那个外卖员已经跑过一百次同一个地址了。

二、小周说「你的Agent正在用杀鸡的刀宰牛」

我把这个问题跟小周说了。「我的Agent每次跑完一次完整任务要调五六次模型——感觉自己像个烧钱机器。四毛二一次——我算了算——用户越多我亏得越多。」

「你用的哪个模型？」小周问。

我报了一个名字。是能力比较强的那档——处理复杂任务很稳。

「你拿着它去干什么？」

「判断搜索框在哪儿——还有——」

小周在电话那头笑出了声。那种笑不是嘲笑——是一个工程师看到你拿着火箭筒打蚊子时的本能反应。就像你花了三个月攒了一台顶配电脑——然后用它只开了一个计算器。

「我换个说法你就懂了。你现在手上有一把菜刀和一把手术刀。你切菜用菜刀——剖鱼用手术刀。但你现在是用手术刀在切菜——能切——但刀钝得快还贵。你那把菜刀在哪儿呢？你没买。」

「那该怎么办？」

「把问题分分类。」小周说。「一类是规则能解决的——坐标固定、逻辑确定——用代码写死就行——不花钱。二类是简单判断——按钮位置变了、页面加载超时——需要一点点推理——用便宜的模型就能判断。三类是复杂理解——匹配度计算、开场白生成——这些才值得用贵模型。你现在是把第三类的工具拿来做第一类的事。能不做吗？能。贵不贵？贵。而且是完全没有必要的贵。」

小周的话点醒了我一件事——不是模型太贵——是我用错了地方。

三、拆成两个Agent——「手」和「嘴」

我花了一周把全自动的架构整个重写了。

原来的架构是一个Agent从头跑到尾——遇到任何事情都调大模型——没有任何分级、没有缓存、没有分工。就像一个什么都干的装修工——水电工是他、泥工是他、木工也是他——一个人干所有工种——每个工种都按最高级别的工钱算。

新的架构拆成两个独立的Agent——我管它们叫「手」和「嘴」。

「手」的任务是操作。搜索框在哪儿——它先查坐标规则表——表里存着上一次成功点下去的屏幕坐标。如果坐标点下去之后结果不对——它截一张图——把截图和「我要找搜索框」这个目标一起丢给便宜模型做兜底判断。模型判断出新坐标——存回规则表——下次直接用。日积月累——规则表越用越准——需要兜底的情况越来越少。

「嘴」的任务是判断和生成。这个岗位跟候选人匹配吗——调贵模型。开场白怎么写——调贵模型。HR问了问题怎么回——调贵模型。「嘴」只碰那些真正需要上下文理解和语言生成的任务——不碰任何「现在该点哪儿」「按钮变没变」的问题。

两个Agent之间通过一个非常轻量的状态对象通信。「手」做完一步——把结果写进状态对象——然后告诉「嘴」可以开始。「嘴」读到状态——接着往下做。每一步不需要问「我现在到哪一步了」——状态对象精确记录了执行进度。这个状态对象的引入——直接把模型调用次数降了一半。

重构之后的数据对比非常直观。重构之前——一次全自动任务平均调五次模型——全部用贵模型——单次成本四毛二。重构之后——「手」的部分百分之九十的情况走规则不花钱——百分之十的情况才调模型兜底——而且兜底用的是便宜模型。「嘴」的部分调用次数从五次降到了两到三次——因为不再需要在每一步之前问路了。重构后的单次任务成本——四分六厘。从四毛二降到四分六厘——一分钱不到。节省了百分之八十九。

这个数字让我特别清楚地意识到了一件事：不是模型太贵——是我用错了地方。百分之六十的调用都在问不需要智能的问题——这个比例才是真正的成本黑洞。

四、阿 May 说「你终于学会给人派活了」

「你以前就是一个人干所有的活。」阿 May 听了我的双Agent拆分之后说。「你现在终于知道给不同的人派不同的活了。」

「什么意思？」

「工地上分工是这样的——泥工只负责砌墙——木工只负责支模——钢筋工只负责绑钢筋。每个人只干自己最擅长的那件事。砌墙的不会去绑钢筋——不是因为绑钢筋更难——是让泥工去绑钢筋效率低、出错率高、还浪费他的工钱。你原来那个Agent就是——你让一个绑钢筋的去砌墙——他也能砌——但砌出来是歪的——还花着绑钢筋的工钱。」

「但现在多了一个问题——两个Agent之间怎么配合？」

「工地也有这个问题。」阿 May 说。「泥工砌完一段墙——木工才能来支模。谁通知木工？以前是工长拿着流程单喊——现在是墙上贴一个二维码——扫一下就知道下一步该谁了。你们那个叫什么——握手协议？」

「接口。」我笑了。

「对——接口。你两个Agent之间得有一个『干完了、下一步你上』的信号。泥工撤了木工才上——不能两个人在同一个位置同时干活——会撞。而且工人交接的时候有一个规矩——交枪不交活——你手里的工具可以交给下一个人——但你干的活的质量你自己负责——出了问题找你——不找接手的人。你们那个也得这样——责任边界得清楚——谁出的错找谁。」

阿 May 说的「交枪不交活」后来成了我设计Agent接口时的一个原则。两个Agent之间传递的不只是数据——还有责任。「手」做了错误操作——不能怪「嘴」没判断出来——因为「嘴」不该对「手」的操作负责。反之——「嘴」写了糟糕的开场白——「手」只管发出去——责任在「嘴」。这个责任分割让调试变得非常简单——出错了直接定位到对应的Agent——不需要在两个Agent之间来回猜。

五、坑在哪

坑一：把所有问题都交给同一个模型去判断。这是最贵也最懒的做法。不是所有问题都需要大模型。搜索框在哪儿这种问题——规则解决百分之九十——剩下百分之十才需要模型兜底。做Agent之前先分清楚：规则能干的走规则——便宜模型能干的走便宜模型——真正需要理解的才用贵模型。分得越清楚——成本越可控。

坑二：Agent没有记忆——每次都重新问同样的问题。搜索框坐标问一次就够了——存下来下次直接用。但我的初始设计里Agent每一步都像失忆了一样——不知道自己刚才做了什么——也不知道自己已经知道了什么。加一个简单的状态对象在Agent之间传递——就能省掉百分之六十的调用量。

坑三：模型不分级——贵的便宜的混着用。坐标定位用便宜模型、开场白用贵模型——这才是对的。但我之前是全用一种。用对模型比用强模型重要得多。一个便宜模型在简单任务上可能做到九十五分——贵模型也不过九十八分——便宜模型已经够了。

坑四：只盯着单次调用成本——不看一次完整任务的总成本。四毛二一次看起来不多——但里面百分之六十的钱花在不必要的地方。做AI产品不能只看「调一次模型多少钱」——要看「完成一次用户任务多少钱」——还要看「这个用户任务里有多少钱是可以省掉的」。

坑五：Agent之间没有清晰的责任边界。两个Agent拆开之后——如果没有明确谁对什么负责——出了错就要在两个Agent之间来回排查。谁做的坐标判断——手。谁写的开场白——嘴。这个责任分割必须在架构设计的时候定好——出了事才知道找谁。

坑六：没有考虑规模增长后的成本曲线。四毛二一次在只有几十个用户的时候还能接受——但成本增长是指数级的。做成本优化的时候不能只看当前的用户量——要预判三个月后的用户量。我应该在设计架构的第一天就想清楚——每个用户每次任务花多少钱——用户涨到一千、一万的时候——这个成本结构还能不能撑住。我当时没想——后来账单逼着我想了。

六、速查卡

七、这一章我真正学会的那一招

四毛二降到四分六厘——省了百分之九十。但我觉得最大的收获不是省钱本身——是意识到一个更本质的问题：很多问题不需要聪明答案——只需要对的答案。搜索框在哪儿——这个问题不需要一个有创造力的模型来回答——它只需要一个坐标。我之前犯的错误是——凡是遇到问题——第一反应就是「调模型」。我默认了模型是唯一的解题工具——却忘了还有规则、有缓存、有便宜模型——这些工具大多数时候比贵模型更有效。

便利贴又更新了。在「信任梯子」下面我加了一行：「双Agent——手走规则、嘴走模型。不是所有问题都值得用最聪明的模型去回答——有些问题只需要一个坐标。规则能干的走规则——便宜模型能干的走便宜模型——只有真正需要理解的任务才用贵模型。」

「不是模型太贵——是我用错了地方。百分之六十的模型调用都在问不需要智能的问题。Agent拆分的本质不是分工——是让模型只做模型该做的事。」

【掉落】双Agent分工：手走规则——嘴走模型。不是所有问题都值得用最强的模型去回答。规则能干的走规则——便宜模型能干的走便宜模型——只有真正需要理解的任务才用贵模型。成本从四毛二降到四分六厘——省了百分之九十。不是模型太贵——是用错了地方。