主讲开场就说这期有点水，时间赶。但里面有几段挺值得留下来：Transformer 那篇论文八位作者后来各自去了哪，模型合并这条降低训练门槛的实验性路径，以及当时多 agent 圈子刚开始讲的一个词——production ready。
上周那场技术分享里有一份挺实用的东西：训练一个模型需要多大 GPU 的标准算法——总参数怎么折算成显存占用，各项参数分别是什么意思。
这是个标准答案，不一定完全适用于具体某个模型，但作为估算框架够用了。值得花时间把那几个参数的含义真正搞清楚，之后估算资源会快很多。
这期最有意思的是一篇按论文署名顺序讲八位作者的文章，从老一排到老八。
提出自注意力机制的是老四——把词和对话中所有元素的关联度算出来。文章里写了个细节：连他父亲都反对这个方向，而他父亲是德国著名的计算机语言学家。老四还是说服了几个同事一起搞。
至于为什么叫 Transformer，说法很多。一种是受动画片影响——当时 Google 最火的模型叫 Bert，那是芝麻街里的角色，那个年代的模型命名都挺中二的，起个变形金刚的名字也不奇怪；当然 Transformer 本身也有「把信息做变换」的意思。
去向上最有意思的两个：老八做了 NEAR——Web3 里技术含量相当高的一家区块链公司，商业化走得最远；八个人里只有老七去了 OpenAI，他在采访里还一度聊到过 Q*。
HuggingFace 上已经堆了海量模型。有人在做的事情是：假设有 A、B、C 三个模型，能不能 merge 成一个 D，让它保留三者的优势、减少各自的劣势。
已经有实验结果表明这条路有戏——合并后的模型在评测上确实能站住。当时的判断是：这是个很实验性质的方向，但可能是降低大模型训练门槛的一条潜在途径。
红杉那场 agent 会议上提到一个当时很有冲击力的说法：通过多 agent 的编排，基本能让 GPT-3.5 的能力达到 GPT-4 的水平。照这个推，用 GPT-4 做 agent 就能逼近下一代模型的水平。
框架这边冒出来的很多，小众一点的比如 swarms。有意思的是当时多 agent 圈子开始集体讲一个词——production grade / production ready：别只搞研究了，能在真实生产环境里跑起来才算好 agent。
不过看下来，这些框架的代码使用方式几乎一模一样，差异并不在 API 层面。
微软的 TaskWeaver 是这期唯一被单独拎出来讲的框架，原因不在功能——它默认就把智谱的 API 集成进去了，开箱支持。
这在当时相当少见：几乎没见过哪个多 agent 框架会把国内开放平台的 API 做成默认选项。它的 paper 作者名单里也是一大堆华人。
这期结尾提到一个后面打算重点试的方向——拿多 agent 来做 RAG。当时已经有 blog 在写这条路，思路是把检索、筛选、综合拆给不同角色去做，而不是塞进一条链里。
聊到 MetaGPT 那个 repo 时顺带提了另一个项目——一个程序员把「怎么活得更久」的各类证据认真整理成了一个 GitHub 仓库，从戒酒开始往下列，每条都附证据。
评价是：可见一个程序员认真起来是多么没事干。
后半场变成了内部讨论。当时的现状是：竞品和友商方案的信息基本靠零碎收集——从别人的公众号上看到、从客户那边听到，没有人在系统地做对比。
在客户现场能收集到其他厂商的落地案例，客户自研的 agent 方向也能听到一些，但这些散点没有汇总。讨论的结论倾向是：先确认有没有人已经在做，避免重复造轮子；如果都没空做，那这件事的缺口是真实存在的。