Hi there 👋

It’s the first day of Thanksgiving break—thanks for reading. Last week’s vibe coding interview piece became my most-read article ever, thanks to Ruanyifeng for featuring it in his tech weekly. This week I want to talk about model selection for AI apps at the end of 2025. It’s critical: it drives both quality and cost. Don’t shrug off the difference between $0.20 and $0.25 per million tokens—that’s a 25% gap. If a candidate can rattle off capabilities, pricing, and quirks of today’s mainstream models, that’s a big plus in my book....

今天是感恩节假期的第一天，感谢各位读者的支持。上篇关于vibe coding面试的文章是我写作生涯阅读量最高的一篇，最应该感谢阮一峰老师把它收录到了科技爱好者周刊里，让它有机会出现在大家眼前。 这周想聊聊2025年末的AI应用模型选型。模型选型对AI应用来说真的非常重要，不仅决定效果，还影响成本。别看每百万token一个0.2美元一个0.25美元只差5分钱，这里面可是25%的成本差距。如果一个面试者能对现在主流的模型能力、价格、特点如数家珍，在我这里一定是个加分项。 Openrouter的参考价值 Openrouter是个不错的参考，可以看现在别人用什么模型比较多，但上面的分布和真实用量肯定有巨大差别。 Openrouter每周都有模型榜单 首先是上面很多免费token送，一免费用量就会上去，比如现在排第一的Grok 4.1 Fast (free)。第二是上面的用户很多是编程相关的，从top apps一看就比较清楚。第三是真正大量的应用不会在上面跑，Openrouter有5.5%的手续费，中间商赚差价一点不划算。 Openrouter的用量是被几个AI编程工具主导的 先上个表格 我今天特意花时间把我比较关注的几家模型都列了一下，公众号不好分享文件，我就贴个图。这里只关注语言能力，虽然有些模型是多模态的；而且都是标准模型，finetune的模型不在本文讨论之列。御三家里，总体Anthropic最贵，中杯都比其他两家的flagship贵，反过来说就意味着它家的包月是最值的（重度用户如果用API来驱动Claude Code，一天几十刀很轻松）。 当下主流模型信息 小中大杯的选择 正经闭源模型厂商为了满足不同的市场需求，一般分为小中大杯。不管是OpenAI的nano、mini、纯数字，还是Anthropic的haiku、sonnet、opus，亦或是Google的flash lite、flash、pro，甚至是阿里的flash、plus、max都符合这个规律。有一些起步晚、产品线不那么齐全的厂商，比如X.ai，只有俩模型，fast和非fast。 按照我的经验，大杯模型适合直面用户需求的场景，比如chatbot、AI Agent（如编程）；中小杯适合离线任务如数据处理、工作流。如果在规模任务上使用大杯模型，轻则荷包出血，重则倾家荡产，大家上线之前一定要慎重。 跟着厂商升级 在同一厂商的产品线内，一定要跟着厂商进行升级。以O家为例，2025年11月还在使用GPT-4o的员工，轻则应给与警告，重则可扫地出门。 随意对比一下就可以发现，GPT-4.1比GPT-4o便宜了不少，具体来说input和output是8折，cached是5折。而且随着模型的进步，往往可以实现4.1-mini实际效果追平4o的情况，那样的话基本是2折不到的价格。 Thinking vs Non-Thinking 在Thinking和Non-Thinking模型之间，也要做好权衡。 GPT-5是一代奇葩，全家爱思考，且不得不思考。轻则简单任务思考400个token，重则复杂任务思考几千个token，Thinking token一律按output计费。你掂量一下你的output有几个字，会不会把钱都砸在动脑筋上了。 好在5.1及时纠偏，可以不思考。如果你的prompt是CoT的，已经有思考路径，那就别让模型自己瞎想，果断选择Non-Thinking模型，随随便便能省出一大笔钱。 缓存命中率 Input/Output和缓存命中率也是需要考虑的一大因素。一定要构建好缓存命中率的内部监控，并且在系统实现时尽可能地提升命中率。目前行情价缓存命中后是1折的价钱，能命中的话能极大降低成本。 输入输出比大的话可以选择input价格有优势的模型，反之选output价格有优势的模型。因为output的价格一般是input的好几倍，但这个倍数不同模型差别较大。O家和G家是8倍，A家是5倍，Kimi是3倍，马老板家大奇葩，是2.5倍。 Throughput的两极分化 Throughput其实也很重要，现在两极分化很严重。一般O家和G家给API的速度都是几十token每秒，但一些ASIC推理厂商已经可以做到上千token每秒。但选ASIC厂商基本意味着只能用少数几个开源模型。 这个体验差别其实是巨大的，但是绝大多数用户还没有体验过。举个大家比较能理解的例子，现在所有的Chatbot产品模型的输出都是"流式"的，这样做是因为模型说完答案可能要好几十秒，先给用户看点东西，不那么枯燥，别等不及跑路了。所以模型推理有一个重要的指标是TTFT(time to first token)。 但是如果把速度提升两个数量级，基本上整个答案就是一起蹦出来的。虽然我们给产品加了流式输出，但用户丝毫感觉不到流式效果。如果Claude Code现在平均5分钟干完一个你的需求，用上ASIC之后可能就是5秒钟。你提需求没他做需求快 :P。 Rate Limit的甜蜜烦恼 还有一个甜蜜的烦恼是rate limit。你需要考虑rate limit说明你的业务还不错，已经有比较稳定的用量。以GPT-5.1为例，Tier1用户每分钟请求的TPM（token per minute）是500k，RPM是500。如果你一个prompt有10k个token（这点token对Agentic应用真的是洒洒水），那意味着你一分钟只能干50个请求。但如果你是尊贵的Tier5用户，这个数会涨80倍，基本就够用了。但一些neo cloud的rate limit一般比较低的，他们没有那么大的算力池来满足瞬时的需求，这是他们相比大厂的一大劣势。 如果你是一个Tier5用户，那你就得好好考虑成本了，几十万美元一个月的token钱其实就有很多省的空间和必要了。 实战分析：5 nano vs 4.1 nano 我们一直用的比较多的是O家模型，总体还是比较满意的。我觉得input 0.1美元以下他们还是做得挺好的，5分钱的5 nano并不算太差，开源界这个价的模型都得8b以下了，除非finetune，否则能力都不咋地。 这里可以实战分析一下：5 nano和4.1 nano，一个thinking一个non-thinking，input一个0.05美元一个0.1美元，output都是0.4美元。假设用medium的reasoning effort，thinking token数约500个，那么两个模型的成本关系就取决于输出token数和input/output ratio。 右上角区域5nano省钱，反之4.1nano省钱 上图横坐标是输入输出比，越大5越容易省钱，纵坐标是输出token数，越大5越容易省钱。简单来说，如果你的任务输出很短，5 nano的thinking开销会让它比4.1 nano更贵；但如果输出很长，thinking开销占比就小了，5 nano的input价格优势就体现出来了。不同的问题成本关系是不同的，需要根据实际场景来选择。...

Cover created with Nano Banana Our team’s interview format just changed. Leetcode puzzles are out; building a full feature is in. If you don’t code with AI—and your typing speed isn’t absurd—you won’t finish. It sounds like a tooling upgrade, but it’s actually reshaping what we mean by an “excellent engineer.” The Gap Gets Wider In classic algorithm interviews, the difference between failing and passing might come down to a single hint....

Cover created with Nano Banana 我们组的面试方式变了。 从写leetcode题变成让候选人实现一个完整功能。如果你不用AI编程，除非手速超快，否则根本完不成。这种改变看似只是工具的升级，但实际上正在重塑我们对"优秀工程师"的定义。 差距被放大了 原来的算法面试，写不出来和写得出来之间，可能只是一个提示的差别。但现在让你实现一个界面或一个功能，完成度可以是天差地别。 有人能在一小时内做出一个基本可用的页面，交互流畅，样式得体。有人却在和AI的来回修改中越陷越深，最后连基本功能都跑不通。同样是用AI工具，结果却大相径庭。 这种面试方式，把候选人之间的差异放大到了前所未有的程度。 沟通能力成了硬通货 在这种新面试下，沟通能力变得特别关键。不仅是和面试官的沟通，和AI沟通好同样重要。 我最近观察到一个有意思的现象:不善于沟通的人往往对vibe coding比较失望。这不仅体现在讲不清楚需求，更重要的是预期管理的问题。 你不能给沟通对象设定一个好的预期，就很难有好的沟通策略。拿vibe coding举例: 明确告诉AI要改哪些文件，可以大幅减少AI改错的情况 时不时把反馈提给AI让它重构，可以避免工程越写越歪 但如果把AI想得太差，事无巨细都说得一清二楚，效率又会很低 这种把握度，恰恰考验的是对工具能力边界的理解，以及与之协作的能力。 品味变得可以考察了 另一个变得重要的是品味。 这个东西在传统面试里真不太好考察，顶多看看代码风格。我想没有前端面试会去计较CSS里的配色吧。但现在因为面试做的东西展示性强了很多，品味这个以前很虚的东西，突然变得具体可见了。 界面布局是否合理?交互是否流畅?视觉是否舒适?这些过去被认为是"设计师的活"的东西，现在成了工程师面试的考察点。 所以现在应该多花点时间观察和揣摩各个出色的产品。品味不是天生的，是可以通过大量观察和实践培养的。 技术深度依然重要，但体现方式变了 那这种情况下是不是技术就不重要了?并不是。 今天我就遇到了一个特别值得学习的面试者。他在一家澳洲的大厂工作，公司提供了非常完备的AI编码工具给员工用，所以他很习惯这套面试方式。他很快就把我让他实现的功能写出来了，经过一两轮反馈，完成度又提高了不少。 但更厉害的是:他在AI开始工作前，会先给我讲一下他认为AI会在哪里做修改。等AI写完，他会打开对应的地方来验证一下。 这个策略让我对他的好感度一下子提升。一个能指挥AI、让AI放大自己生产力、当AI出错时能给与正确指示的工程师形象就这样树立起来了。 这才是技术深度的新体现方式:不是你能不能手写红黑树，而是你能不能预判AI会怎么实现，能不能快速验证AI的输出是否正确。 工具还没跟上 目前的面试工具好多都还没有适应这套范式。 比如今天用的Show Me Bug，原来他们一个网页端的IDE可以运行代码还挺好用的，但目前还没引入AI编程功能。所以现在最好用的还是视频电话然后共享桌面。 希望以后会有更好用的工具出来，专门为vibe coding面试设计。 AI作弊的悖论 想起来不久之前有个很火的用AI帮面试者作弊的公司。但现在当使用AI成为重要的考察项目，作弊是不是也就无从谈起了? 如果面试本身就是要考察你和AI协作的能力，那用AI还算作弊吗?这个问题挺有意思的。 不得不感叹这两年的变化真的太快了。 从10.11那期我提到Claude Code让我一晚上写了5700行代码，到10.19那期提到AI让我们一周完成三周的工作，再到今天我们已经开始用vibe coding来面试新同事。 AI不仅改变了我们的工作方式，也在改变我们对"优秀工程师"的定义。沟通能力、品味、对工具的掌控力，这些过去相对软性的能力，现在都成了核心竞争力。 而技术深度依然重要，只是它的体现方式变了。

On my commute I listened to a podcast episode featuring Songlin Yang—nicknamed the mother of linear attention—where she patiently explained the mechanics behind the architecture. The structure is red-hot right now, especially because several frontline Chinese model labs are doubling down on it. I figured it was worth retelling the story in my own words. How Is a Token Generated? To keep things simple, let’s focus on the inference stage of a large language model—the everyday scenario where a user asks a question....

上班路上听了号称线性注意力之母的Songlin Yang的一期播客，小姐姐在里面科普了线性注意力的原理。最近这个结构非常火，特别是国内几个一线大模型厂商都在押注这个赛道。我觉得有必要用自己的话把这件事再说一遍。 一个Token是怎么生成的? 为了简单起见，我们聚焦在大语言模型的推理阶段——通俗点讲就是普通用户向大模型提问这个场景。假设用户问了这么一个问题:“我想元旦去看雪，有什么地方推荐的吗?“用过大模型的人都知道，接下来大模型就会开始一个字一个字地回答你。 大模型回答的每一个字，都可以拆解成以下几个阶段: 1. Tokenization(分词) 简单讲就是把人类的语言变成一串数字，每个数字都是一个编号。比如上面那个问题在ChatGPT处理前会转变成这样一串编号:[37046， 33565， 111， 24186， 6079， 99…]。你会发现这个编号序列的长度和用户输入的问题长度不一样，这是因为这个过程可能会对一些字词进行合并或拆解，不过这个小细节跟我们今天的主线关系不大。 2. Embedding(嵌入) 这个过程很重要也很简单，可以理解成查字典。拿上面的编号去查一个大表，每个编号都会对应一个很长的向量，用来在所谓的"语义空间"表示这个编号代表的token。 理解清楚向量是什么需要一定数学背景，但它起到的作用其实很直观。比如"苹果"和"香蕉"两个词语的编号可能差得很远，一个是888，一个是6666，中间差了几千个别的词，这些词也不知道是些啥，可能是"硅谷”、“大模型"这些跟水果一点关系都没有的词。但变成语义空间的向量就不一样了，好的语义表示可以让近义词的向量之间距离近，无关的词之间距离远，甚至还可以做一些运算。 经典例子是在向量空间里"皇帝”-“男人”+“女人"约等于"皇后”。用这个例子应该能让embedding起到的作用更直观。这个很大的表在模型训练好后是固定的。 3. Transformer处理 Transformer这个词，以往的大众媒体宣传都在借用变形金刚的形象，可能是因为比较酷。其实人家的本意更接近变压器，是在把输入的信息转变成另一种形式来输出。现在的大模型会堆叠好多层的Transformer，也就是做好多次变换，但每一次其实原理都一样。 最开始Transformers结构 这个过程有两个重要的步骤: 第一步:Self Attention(自注意力机制) 大名鼎鼎的自注意力机制，也是本公众号名字的由来。名字很玄乎，做的事情说起来却很直观——把当前上下文中与生成下一个token最相关的信息聚合起来。 具体地说，我们在上一步已经把每个token都转化成了embedding向量。假设当前上下文的长度是L，embedding的维度是d，那就变成了一个$L×d$的矩阵。首先，会对这个矩阵做三种不同的变换，数学上就是乘以三个不同的矩阵，得到三个变换后的矩阵Q(query)、K(key)、V(value)。 现在我们取出第L个Q向量(也就是最后一个)去和1L-1个K里面的向量分别计算相似程度。算完之后我们可以取出最相似的那个K向量对应的V向量来作为预测下一个token最有用的信息。但这种取max相似的做法太生硬了，所以用了一种叫softmax的方法——按照和第L个K向量的相似程度把1L-1个V向量加权求和起来。 可想而知，为了做这个加权求和，我们要做L-1次向量点乘。每生成一个字就要做L-1次，如果生成总长度为n，那这个计算量的量级就是n的平方。现在的大模型已经会思考了，随便就能给你生成几千上万个token，这个计算量就非常巨大了。 Self Attention示意图，原图来自https://newsletter.theaiedge.io/p/understanding-the-self-attention 第二步:FFN(前馈网络) 这一步不是本文重点，是对上面算出来的聚合后的上下文向量做一些变换。用的网络结构叫前馈网络FFN。因为生成下一个token只要处理一个向量，所以计算耗时不大。 但这个网络也很重要，实际上是大模型的全局记忆或永久记忆之所在(自注意力主要是在操作上下文，是工作记忆)。其特点是参数量特别大，因为参数量越大，可以记忆的东西就越多。但参数大也会带来计算量大的问题，于是就有了MoE混合专家网络——把总参数量用很多个专家来撑大，但大家术业有专攻，每次只取几个专家来激活处理。在此先按下不表，有兴趣的朋友可以自行扩展阅读。 4. 输出Token 对变换后的向量，再通过一个分类器分到token集合上，取出概率最大(根据采样方式不同也可以不是最大的)的那个token作为这一步的输出。 如何串起来? 这个也比较容易理解。当用户输入问题之后，我们走完上面的流程就会得到一个新的token。然后我们又可以拿它的id去查embedding，对这个embedding做qkv变换，然后拿这个q去和1~L的k去做softmax拿到聚合后的上下文向量，再经过FFN和分类器就又得到了下一个token。如此循环，直到世界的尽头——啊不，直到输出停止token。 线性注意力解决了什么问题? 自注意力机制在这里最主要的问题是速度，因为O(n^2)的时间复杂度，随着模型输出变长，会越来越慢。 从上面的过程里聪明的你可能发现了一些讨巧的地方，那就是每个位置的token对应的QKV向量如果能保存起来的话，做一次embedding到向量的变换就可以一直用，一劳永逸，省下一些时间。 但这种方法是以空间换时间。GPU上的存储是很宝贵的，而且模型这么大，也需要占据很大的空间。所以现在大家就想办法把这个缓存搬到内存上，甚至是固态硬盘上。于是推波助澜了今年存储股的暴涨(参考镁光、SanDisk以及国内的兆易创新)。 线性注意力就是要解决这个问题。总体的框架并没有变，但是做了一些关键的修改。首先就是把softmax这个函数给干掉，于是这个上下文计算变成这样: $$ \begin{aligned} &&&&\mathbf{o_t} = \sum_{j=1}^t \mathbf{v}_j(\mathbf{k}_j^\top \mathbf{q}_t) &&&&& \mathbf{k}_j^\top \mathbf{q}_t = \mathbf{q}_t^\top \mathbf{k}j \in \mathbb{R}\\ &&&&= (\sum_{j=1}^t\mathbf{v}_j\mathbf{k}_j^\top)\mathbf{q}_t &&&&&\text{By associativity} \end{aligned} $$ 于是可以发现，整个过程可以逐步计算得到了，每一步的计算复杂度跟当前的长度无关，只跟V和K的大小有关。同时，因为括号里的东西是累加的，我们可以不用记录历史的kv了，KV cache完全不需要了。假设称括号里的东西为状态矩阵: $$ \mathbf{S} = \sum \mathbf{v}_i\mathbf{k}_i^\top $$...

This week didn’t revolve around a single theme. It wasn’t a neat follow-up to last week’s “product fundamentals,” nor a deep dive into “triple-speed coding” like 10.19. It felt more like a handful of scattered observations and experiments, each sparking new thoughts. If there’s a shared thread, it’s probably this: in an era where AI rewires productivity, what actually matters? Beautiful view outside the Google office When Productivity Explodes, Taste Becomes Scarce I spent a day at Google’s San Francisco office for an event....

这周没有单一的主题。没有像上周那样聚焦于"产品基本功"，也没有像10.19那样围绕"三倍速编程"展开。更像是几个零散的观察和实践，但每一个都让我有些新的思考。如果非要找个共同点，大概是：在AI改变生产力的时代，什么才是真正重要的? Google办公室窗外美景 当生产力爆炸，品味成为稀缺 这周去了Google三番办公室参加一个活动，虽然内容比较high level，但质量不错。他们总结了AI时代产品的几个变化，我记住了三个： 第一是意图做输入。用户很多时候不需要像以前一样亲自操作，只要把想干什么告诉产品就行。第二是多模态，模型的进步使得理解和操作非结构化数据变得前所未有的容易。第三是自动化，产品可以直接交付结果，而且能在你不使用它的时候继续为你工作，达到更好的效果。 这三点对照起来看，还有很多产品形态会发生变化。特别是第三点"自动化"，我觉得特别值得深挖。ChatGPT只在你问它时为你工作，但优秀的人类都有很强的主观能动性，能在背后下功夫。未来的产品如果能具备这种"主观能动性"，不再是被动响应，而是主动为用户创造价值，那会是质的飞跃。 会上有个观众问了一个很有意思的问题。她是孩子的母亲，自己学计算机出身，很热爱这一行也感受到了红利，但她担心孩子不能再学这个了。嘉宾David Benjamin(Google AI Future Fund的co-founder)说这个问题很难回答，但他的感觉是： 现在是人类历史上生产力最发达的时候，你可以靠说话实现一个app，创作一幅图画甚至视频，品味变得特别重要。而品味是靠很多人文学科比如历史、艺术来培养的。 这个观点我相当认同。当技术实现的门槛被AI大幅降低，差异化就不再来自"能不能做到"，而是"做出来的东西好不好"。什么是好?这就需要品味。而品味的培养，恰恰不是靠刷LeetCode和背设计模式，而是需要更广阔的人文积累。 小团队效率高是有理论基础的 这周听了一个很棒的播客《OpusClip 增长秘诀：如果每个阶段只让我选一件事做》，里面提到的一个观点和我最近的实践高度吻合：创业公司应该多用SaaS服务，不要老想着招人自己干。嘉宾君陶说他自己手上就有十几个SaaS产品在用。 构建用户反馈闭环他们就用了至少4种产品 美国这边真的有太多SaaS服务，而且定价都很便宜。比如我们最近打算给用户发newsletter来提高留存，以往都是找内部的newsletter团队帮忙，但他们事情也蛮多，一般需求得两三天才能消化。这次我直接买了个服务，一个月只要35美元。功能非常完善：所见即所得的模板编辑器、详尽的打开率报表，应有尽有。配置起来花了不到两小时，马上就把邮件发出去了。 还有一个需求是做小搜索模块。搁以前肯定是搞个embedding推理服务，建个ES索引，吭哧吭哧搞一会。这次直接丢Pinecone里，免费套餐就包圆了，只需要往里丢文档和搜索查询，其他全不用管。 这两个还算常规。但其实像用户调研这种看起来很复杂的事情，都有SaaS可以帮你完成从招募、访谈到分析的全流程。 对于创业公司人手不够，如果没有用这些服务，大部分是因为"不知道"。但对于中型公司，可能还有一大原因是思想上的惯性。毕竟有这么多工程师，得安排上活啊。结果可能是搭了一大堆完成度不高的模块，反而在项目过程中消耗了不少时间来修复各种并非主线上的问题——最近我就遇到了好多。最后没能在产品验证、商业验证这些核心问题上花足够的时间。 所以说，小团队做到比更大团队效率高，也许是有理论基础的。组织变大之后如何保持高效率，也是真的需要水平的。 从Build到Growth的转型 听了播客里嘉宾的话，这周花了不少时间试着去找产品的第一批核心用户。以前没怎么做过，发现这事确实很难。 我们试了几个渠道。第一个是从老产品导流，目前看转化率非常低。从逻辑上看这两个产品的人群确实差得比较远，但毕竟是free lunch，所以还是做了。 然后试了去Reddit发帖，带来了几个用户。但这个渠道有一些门槛，不少subreddit都有很严格的发帖审核。我的一个比较生硬的广告让我被管理员永久封号了。这个教训挺深刻：在社区里，你不能只是把产品扔进去就走，而是要先理解社区的文化和规则，建立信任，然后再自然地分享。 不过Reddit也让我发现了一些宝藏。有好多给做产品的人讨论的板块，比如r/alphaandbetausers、r/startup，大家贴自己的产品然后互相给反馈，氛围挺不错的。 目前正在观察Twitter。从帖子的阅读数来看，Twitter的传播速度应该更快。但如果根据播客里讲的，Reddit中某些板块里有核心用户的可能性比Twitter大，后面还是应当加大力气。 这种帖子能带来曝光，但难找到核心用户 AI让创建一个app变得容易，但找到第一批核心用户依然很难——对我来说是这样。OpusClip的君陶他们做得就很好，播客里也有很多可执行的干货。我们之前更擅长build，现在也要往找用户和增长上多花功夫。 这和上周的观察是一脉相承的。10.26那期我说"效率不等于方向"，Composio的CEO虽然英语不好，但在Twitter上孜孜不倦地发视频最终火了起来。现在轮到自己实践，才真正体会到：build只是第一步，让合适的人知道你的产品，可能更难也更重要。 把这周的几个观察串起来看，有个隐隐约约的线索： AI降低了技术实现的门槛。一晚上5700行代码，一周完成三周的工作量，这都是前几周我们亲身体验过的。SaaS服务进一步降低了基础设施的门槛，Mailgun两小时就能配好newsletter，Pinecone免费套餐就能搞定搜索。 但AI并没有降低"做对的事"的门槛。什么是好的产品?谁是你的用户?怎么找到他们?如何和他们沟通?这些问题依然需要品味、判断和大量的实践。 在AI时代，技术实现不再是瓶颈，真正稀缺的是对"什么值得做"的判断，以及把它做好、让合适的人知道的能力。 这可能也解释了为什么小团队效率可能更高：当实现的成本大幅降低，组织的核心价值就从"能调动多少资源"变成了"能多快做出正确的决策"。而决策速度，往往和团队规模成反比。 下周见。

This week I listened to LatePost Chat’s episode “Agents Are Opportunities—and So Are Agent-Building Tools | Starting From OpenAI DevDay.” Henry, the guest, mapped out six major inflection points in the evolution of agent tooling: from ChatGPT’s launch at the end of 2022 to the recent wave of “computer use.” Every leap in model capability exposes a new “body part” that needs strengthening, and each gap spawns a new tool....

这周听了晚点聊的一集播客【Agent是机会，造Agent的工具也是|从OpenAI开发者日聊起】，感觉很好。嘉宾Henry在里面梳理了Agent工具发展的六次主要升级，从2022年底ChatGPT发布，到最近的Computer use能力，每次模型能力的跃迁都会暴露"身体"的短板，催生一波新工具来补齐。 听完之后有种connected the dots的感觉。这两年确实就是这么过来的，每隔几个月就有新的能力出来，每次都会带起一批新公司。LangChain抓住了最早的编排需求，LiveKit赶上了语音交互的浪潮，E2B、Daytona切入了代码执行的沙盒，Browserbase又站在了Computer use的风口上。 这套梳理让我想起了这几周在旧金山Tech Week见到的那些创始人。当时还不知道背后的脉络，现在一对照，才发现他们确实都是在各自的节点上抓住了机会。 左起分别是E2B，Composio，Pokee AI，AGI Inc的Founder LangChain的启示 Henry提到LangChain从最早的编排框架一路演化，现在已经是独角兽，靠Observability & Evaluation实现了几千万美元的ARR。我以前对LangChain的态度比较不屑，觉得它引入了太多复杂的抽象，社区里批评的声音也不少。有技术能力的公司确实不需要那层抽象，反而会让Agent和已有系统的整合变得麻烦。 但现在想想，这其实说明市场需求和技术理想之间存在错位。我比较了解或者说我本身就属于"有技术能力"的群体，但这个群体并不是全部。有大量有实际需求但没有相应技术能力的人，对他们来说，用LangChain几行代码写一个Agent是很不错的选择。 更重要的是，LangChain没有止步于最初的框架，而是紧跟着行业发展推出新产品，相继推出了LangGraph、LangSmith两个新产品，最终找到了现在这个赛道。这种"抱紧赛道，敢于Pivot，横向发展"的路径，和上期Reynold Xin的观点是吻合的。 LangChain团队已经挺大了 Composio的震撼 播客里提到了Composio这家做工具调用的公司，7月份融到了2900万美金。我在Tech Week的panel上见过他们CEO。根据嘉宾介绍，这是一家纯印度班底的公司，人很少，在印度成立，为了离用户更近刚全体搬来旧金山不久。 当时听他和Panel的其他Founder聊，就觉得英语好差，我比较难听懂。那时还不知道他们融了这么多钱，更不知道他们刚从印度搬来。如果你没见过这个人，只是看到融资的消息，至少我个人是会产生慕强情绪的，肯定会仰视。但面对面见过，这种活人感会消灭掉很多神秘感，让人更客观一点。我觉得这种对外界和对自己的客观是很重要的，不卑不亢。 但震撼的不是这个。据说Composio的CEO就是在Twitter上孜孜不倦地发视频，最终火了起来。硅谷的工具型公司也会举办build day、hackathon来让潜在用户接触到自己的产品。 我身边也有团队尝试做过工具调用相关的产品，当时做了个类似mcp.so的MCP server索引，试图通过提供测试报告来做出差异化，并寄希望于通过SEO来获取流量。但事实证明这条路走不通。截止到目前，有用的MCP server（比如各大平台、工具第一方发布的）不需要测，其他MCP server根本不值得测；导致想象中的差异化并没有价值。而且SEO的策略也有非常大的问题。 Composio老哥确实是个搞流量的好手 用户在哪里？ 对比一下就能看出差异。身边的开发者（特别是AI的early adopter）已经比较少用Google了，但AI的社区（Reddit、Twitter、各种散落的Discord频道）却在变得越来越繁荣。与其被动地等搜索引擎的流量，更好的做法是到用户最密集的开发者社区去主动宣传。 搜索流量和社区流量更本质的差异是用户的intent纯度。搜索引擎搜MCP，即使真的点到了你的网页，也并不一定代表他是MCP的真正用户。但如果你办一个限定使用自己产品的build day，在场的开发者会真正地沉浸式用你的产品，可以带来非常多有价值的反馈。在产品的早期，找到真正的核心用户是非常关键的。 一个很有趣的细节是，虽然身边的团队在build MCP index，但日常工作生活中团队里没有一个人是MCP的重度用户。现在反思起来，这是一个巨大的问题，也从侧面反映出对真正用户的理解是很差的。自己必须是用户，或者至少离典型用户很近，不管是不是AI，这都应该是做产品的基本准则。 而Composio的CEO，英语不好，但在Twitter上"不完美但持续输出"。这种状态，其实就是上一波互联网产品的基本practice：尽早发布，尽快迭代。一个产品如果没法launch到真正的用户群体中，获得反馈，进入迭代，基本上就会进入做也不是、停也不是的尴尬状态。LangChain也一样，被人骂不可怕，说明有人用，最怕的其实是无人关心。 效率不等于方向 这让我想起前两周的观察。10.11那期我提到Claude Code让我一晚上写了5700行代码，10.19那期提到AI让我们一周完成三周的工作。效率的提升是实实在在的，三倍速的编程确实让人兴奋。 但从效率提升到产品成功里面还有非常长的路要走。方向错了，工具再强也没用。或者说，当你连用户在哪都不知道的时候，做得再快也只是在错误的路上狂奔。 从10.05那期我提到"东一榔头西一锤子，结果就是毛都没搞出来"。现在回头看，不是我们不够努力，也不是工具不够强大，而是在最根本的问题上——谁是用户、用户在哪、用户需要什么——没有想清楚。 总而言之一句话，做产品的基本功依然重要，甚至比过去更重要。