Olivia
Online
传人Joe
@bridge_joe
iOS Developer, Stay Hungry, Stay Foolish.
Joined October 2012
177 Following
143 Followers
155 Posts
越来越觉得 Maka 很适合用来学习 Agent。
比如最近一个maka core dev提了 issue 在讨论 DeepSeek 的缓存优化。
全过程透明：1 个 issue + 8 个 PR 一路推上来，从 usage 归一化 → request prefix 稳定化 → archive 压缩历史
https://t.co/HhAODH6pwf
听起来像是仅仅是为了省 token fee，但真正做起来之后，才会遇到一堆 Agent runtime真实又核心的问题：prompt prefix 怎么稳定、tool schema 怎么 canonicalize、历史上下文怎么 budget、usage/cost 怎么算对、cache miss 怎么解释。
中间有个反直觉的发现：砍历史 != 省钱，实测发现砍掉旧 turn 反而把 cache miss 拉高，总 cost 更贵。我们把滑窗 trim 改回 opt-in。
这是把 Agent 做成产品时一定会撞上的工程问题, 不仅仅是写一个 Agent loop 这么简单。
这篇论文让我感觉，我们对「AI 会取代程序员」这件事的讨论方向可能全错了。
核心观点：AI Agent 的出现不是让软件工程师工作效率更高，而是让「把决策逻辑永久编码进软件」这件事本身变得越来越不必要。
作者说的是一个更根本的范式变化：传统软件工程的本质是，人类把判断逻辑「固化」成代码——if-else、状态机、算法，这些都是把人类决策「提前写死」的方式。但在以 LLM 为核心推理引擎的 Agent 系统里，代码变成了「临时生成、用完即扔的工具」，每次任务，Agent 动态生成需要的代码，执行完就不需要了。决策不再被预先编码，而是在运行时由 LLM 推理循环动态产生。这不是增量改进，而是软件生产范式的结构性替换。
我觉得这个观点里最值得注意的细节是：这不只是生产力工具的升级，而是「软件」这个概念本身的角色在变。以前代码是「系统的中心」，Agent 框架是外壳。现在 LLM 推理循环是中心，代码变成了外壳里的临时辅助。如果这个趋势持续，软件工程的核心能力可能不再是「写出好代码」，而是「设计出可靠的推理约束边界」。
以前我们关注写出可维护的代码，以后可能更要关注设计出可靠的推理边界。
https://t.co/28rZe5qvBP
近期看过最好的 agent 基建文章
https://t.co/iKOn6Ot3sq
viber/deux 实测，效果非常好 更新快，重启快
Stanford CS336 上，Tatsu 讲了一节 LLM 架构课，把过去 3 年所有主流 LLM 拆开，看它们的共通模板
结论挺爆：90% 的架构选择已经收敛，你随便挑一个开源大模型，它跟其他模型在这些维度上几乎一模一样
讲师的原话
- 2024 年大家都在 cosplay Llama2
- 2025 年的主题是「怎么训得不崩」
- 2026 年的主题是「怎么扛住长上下文」
下面是 2026 年开源 LLM 的标准模板 你训自己的模型可以直接抄
【架构层 已经收敛的 7 件事】
1）Layer Norm 挪出残差流（pre-norm）
原版 Transformer 把 LN 放在残差里 几乎所有现代模型都挪到外面
原因：keep your residual stream clean 梯度反传更稳
2）RMS Norm 替代 LayerNorm
LayerNorm 的减均值 + 加 bias 那部分实际没怎么帮上忙
丢掉之后 flops 只省 0.17% 但运行时省到 25%
（瓶颈在数据搬运 计算反而次要）
3）所有 bias 项全删
跟 RMS Norm 一个道理 系统层省内存搬运
4）激活函数用 SwiGLU 或 GeGLU
gated linear unit 几乎所有现代模型都用
Llama 系 / Qwen / Mistral 用 SwiGLU
Google 系（Gemma / T5）用 GeGLU
区别极小 选哪个都行
5）位置编码用 RoPE
2024 年之后基本统一了
原理：把每对维度按位置旋转一个角度 让 inner product 只依赖相对位置
6）Transformer block 串联（不是并联）
GPT-J / Palm 试过并联 现在基本被放弃
串联的实现优化得太好了 并联省的那点系统开销不值得损失表达力
7）Layer norm 可以「撒」
哪儿不稳就在哪儿加 LN
attention 之前能加 之后能加 两边都加（double norm）也可以
现代模型很多这样做
【超参数 已经收敛的 5 个数】
1）feedforward 维度 / hidden 维度
- 非 GLU 模型：4 倍
- GLU 模型：8/3 ≈ 2.67 倍（因为 GLU 多一组矩阵 要保持总参数量）
- Llama 系：3.5 倍
- T5 1.0 试过 64 倍 后来 T5 1.1 改回标准 别学
2）head 数 × head 维度 ≈ hidden 维度
几乎所有模型都遵守 T5 是为数不多的例外
3）模型纵横比（hidden / 层数）≈ 100
太深 pipeline parallel 难做
太宽 表达力受限
100 这个数字是系统约束 + 表达力的平衡点
4）vocab size
单语模型：30K 左右（早期 GPT-2 那种）
多语 / 通用模型：100K-200K（GPT-4 / Llama 3 / Gemma 都在这个范围）
现代基本都是后者
5）weight decay
仍然普遍使用
但研究发现它在 LLM 里干的事其实是优化器干预 让你最终能收敛到更深的最优点
跟你想的「防过拟合」没什么关系
所以别因为「单 epoch 不会过拟合」就把它关掉
【稳定性 三个救命 trick】
训练大模型最怕中途 loss 突然飙升 然后 NaN 全军覆没
现代模型用三个 trick 防这件事
1）Z-loss
output softmax 的 normalizer 容易爆
加一个 (log Z)² 的正则项 让 Z 始终接近 1
DCLM / Olmo 都用
2）QK norm
attention 的 Q 和 K 在矩阵乘之前各加一个 LN
让 softmax 的输入永远是单位尺度
multimodal 圈先用起来 现在所有大模型都加
3）Logit soft cap（仅 Google 系）
attention logit 用 tanh 硬封顶
Gemma 2/3/4 都在用 但会损失一点点性能 慎用
【Attention 两个新趋势】
1）GQA（Grouped Query Attention）几乎统一
原版 multi-head 推理时 KV cache 会让算术强度崩到 1/h
GQA 共享 K 和 V 但保留多个 Q
表达力几乎不损失 推理成本砍掉 80%
现在所有要做生产部署的大模型 没有不用 GQA 的
2）局部 + 全局 attention 交替
处理长上下文的新方式
Cohere Command A 起头 现在 Llama 4 / Gemma 4 / Olmo 3 全在用
比如每 4 层有 1 层 full attention 其他 3 层是 sliding window 只看附近的 token
比纯 SSM 更稳 比纯 full attention 便宜得多
（Qwen 3.5 做了变体 把 sliding window 那 3 层换成 SSM）
收尾一句
如果你正在训自己的 LLM，上面这一套就是 2026 年的「默认配置」 不需要重新发明，直接抄
如果你只是想看懂 GitHub 上那些 modeling_xxx.py
这一份足够你不再被术语吓住
我现在明白为什么大家Claude Code各种套餐都消耗很快了，因为大家都直接用Coding模型处理多个同类文件，而不是先做一个接LLM等各种API的Python程序、再用测试好的程序来处理多个文件。这样用模型当然是没底的，而且完全没必要啊，Python + LLM API多便宜啊，而且文件如果量大，这样根本不可行啊。
补充一下用 GPT 2 Image 画出来的效果，好家伙，商用级素材。
日读论文：学习，即遗忘。理解，即压缩。
https://t.co/RLIByBhHmc
大模型训练了几万亿 token，但它脑子里到底留下了什么？
这个问题一直没有好答案。我们知道模型越大越聪明，知道数据越多越好，但"训练"这件事的本质是什么，说不清。有人说是记忆，有人说是模式匹配，有人说是涌现——都对，都没说到根上。
信息论里有个老框架叫 *Information Bottleneck*（信息瓶颈），二十多年前 Tishby 提出来的。核心想法很简单：好的学习就是好的压缩——保留有用的，扔掉没用的。这个理论在小网络上验证过，但到了大模型这个量级，计算互信息的老方法全崩了，算不动。
这篇论文找到了一条路：用一种叫"软熵估计"的新方法，把互信息的计算扩展到了 70 亿参数的大模型上。然后他们发现了一件漂亮的事——大模型的训练过程，和信息瓶颈理论的预测严丝合缝。
────────
你要从一个住了十年的大房子搬进一个小公寓。房子里几千件东西，公寓放不下。你得决定带什么、扔什么。
搬家搬得好的人，不是按房间打包的，是按"我这辈子还需不需要"来筛的。最后留下的东西不多，但件件有用。一个外人看你的新公寓，能从你留下的东西猜出你是干什么的、你在乎什么。
大模型训练就是这个过程。几万亿 token 是那个大房子，模型的参数空间是那个小公寓。训练不是在"学习"——是在"遗忘"。把跟预测下一个词无关的信息扔掉，留下的就是"理解"。
────────
模型训练分两步：
*装箱期*（fitting phase）：训练早期，模型拼命增加对输出的信息量，什么都往表征里塞。这时候它在扩大自己的感知范围——先看到，才能筛选。
*扔东西期*（compression phase）：损失函数开始趋平后，模型的行为变了。它不再增加新信息，而是开始扔——减少表征里保留的输入信息，同时保持对输出的预测能力不掉。
这两步走完，模型的表征逼近了一条理论极限线——信息瓶颈边界。意思是：在保留这么多预测能力的前提下，它已经扔到不能再扔了。
────────
关键是两个数：
- *复杂度* I(X;Z)：表征里还留着多少输入的原始信息。越低说明压缩越狠
- *表达力* I(Y;Z)：表征里有多少关于输出的有用信息。越高说明学到的东西越多
在一个坐标系里画出来——横轴复杂度，纵轴表达力——模型训练的轨迹就是一条先往上走（装箱）再往左拐（扔东西）的曲线。理想终点是一条对角线，斜率等于 1，意思是"留下的全有用，没有一件多余的"。
问题是：这两个数在大模型上算不出来。传统方法要把高维空间做离散化分箱，维度一高就炸了。
────────
最有意思的发现：70 亿参数的 OLMo2 漂亮地走完了两步，紧贴信息瓶颈边界。但 10 亿参数的小模型卡住了——装箱期还行，到了该扔东西的时候，它开始震荡，忽远忽近，怎么也贴不上那条线。
这说明压缩不是免费的。要扔掉"正确的东西"，你得先有足够的容量来分辨哪些该留哪些该扔。参数不够的模型，像一个搬家时分不清什么重要的人——扔了不该扔的，又捡回来，反反复复。
────────
学习不是积累，是丢弃。一个模型的聪明程度，不取决于它记住了多少，而取决于它扔掉了多少正确的东西。
这不只是关于大模型的判断。它在说一件更深的事：理解的本质是压缩。你真正懂了一个领域，恰恰表现为你能说出哪些东西不重要。专家和新手的差别不在知识量——在于专家知道什么可以忘。
日读论文：CPU 与主板的隐喻
https://t.co/00U1rhnY78
为什么这两年模型没怎么变大，Agent 却突然能干活了？
过去三年的故事很熟悉：参数一路堆上去，从十亿到万亿，GPT-4 Gemini DeepSeek 一层层盖。大家信 scaling law，信只要模型够大，它就能记住世界、规划长任务、和别人协作。这是「靠体重解决问题」的时代。
然后卡住了。
体重再加也解决不了几件事：模型没法选择性地更新（想让它忘掉一个过时事实，只能微调）；一出 session 就失忆（昨天聊过的今天不记得）；让它用工具要靠堆 few-shot（每次都从零解释一遍怎么用）；多个 Agent 协作全靠自然语言猜（你说一句它猜一句）。你会发现模型已经够聪明了，但它干不成事，不是因为笨，而是因为每次都在从零开始。
于是大家不得不换一条路。不加参数了，改加「外挂」——在模型外面搭记忆库、技能库、协议层、执行沙箱。Auto-GPT、MemGPT、MCP、Claude Code，一个个冒出来。这些东西看起来琐碎、工程味重，但它们才是让 Agent 真正能用起来的原因。
这篇综述问的就是这件事：我们到底在干嘛？这些外挂的本质是什么？作者给出一个答案——*externalization*（外化）。
────────
先不谈 AI。想想人类是怎么变聪明的。
一万年前一个猎人要记住「哪里有水、哪里有狼、怎么剥皮」，全靠脑子。脑子一死，知识清零。后来有了*语言*——可以把知识讲给下一代，脑子死了知识不死。再后来有*文字*——不用靠人讲，刻在石头上就行，知识脱离具体的脑子。再后来*印刷*——知识可以复制上万份。再后来*计算机*——知识可以被检索、被计算、被共享。
每一步都是同一个动作：*把大脑里扛不动的东西，放到大脑外面去*。这叫认知外化（cognitive externalization）。Norman 管这个叫「认知人工物」（cognitive artifacts）——不是帮你想得更快，而是把难想的事变成容易想的事。算乘法口算很难，拿张纸写竖式就容易；这不是因为纸让你变聪明了，而是纸替你扛住了中间结果。
作者的核心比喻就是：*LLM Agent 正在重走这条路*。
*第一层：weights（2022-2023）*。能力全在模型参数里。GPT-4 一家独大，你问它什么它答什么，靠的是训练时硬塞进去的东西。这相当于人类早期全靠脑子记——强大但不灵活。换个知识要重训，成本极高。
*第二层：context（2023-2024）*。发现参数太贵太死，开始把东西「临时塞进输入」。Prompt 工程、few-shot、CoT、RAG——本质都是：*与其让模型回忆，不如让它辨认*。你不指望它凭空想出答案，你把答案贴在鼻子底下让它挑。这一层解决了「死记硬背」的问题，但带来新问题：context 窗有限，越长越贵，中间的内容还会被忽略（lost in the middle）；更麻烦的是*一出 session 就全忘了*，每次都得重新贴一遍。这相当于人类有了纸——能临时写写，但纸一扔就没了。
*第三层：harness（2024-2026）*。既然 context 会失忆，那把该记的东西*持久化*到模型外面。建个数据库存记忆，建个库存技能，定个协议让 Agent 之间能对话，再加个沙箱让它能安全执行。这就是 harness——不是某个组件，是围绕模型的*整个运行时*。相当于人类有了图书馆、工具箱、法律合同、工厂流水线。
────────
*能力不在模型里，在模型与环境的协议中。*
这句话是这篇综述真正的价值。
听起来像老生常谈，但仔细想想：过去三年 AI 圈对「能力」的默认定义是*参数里存了什么*——能力 = weights 里编码的函数。这个定义让 scaling law 成为宗教：更多参数 → 更多能力。
这篇论文在说：能力的定义错了。能力不是模型单方面的属性，是*模型 + 外部基础设施*的联合属性。同一个 GPT-4，放在 vanilla API 里它是一个能力，放在 Claude Code 的 harness 里它是另一个能力——差距大到不像同一个模型。这个差距不是 prompt 工程能解释的，是外部的 memory、skills、protocols、执行环境共同塑造的。
一旦你接受这个视角，很多事情都会被重新理解：
- 评测基准应该测「系统能力」而不是「模型能力」——让模型裸考意义不大
- 安全性不该只管模型对齐，要管整个 harness 的权限和审计
- 竞争优势不在谁训了最大的模型，在谁搭了最好的 harness
- 「通用智能」可能不是一个模型属性，是一个生态系统属性
这是一个本体论层面的转向。从「模型中心」到「系统中心」。从「智能在脑子里」到「智能在脑子和环境的协议里」。
脱离论文，这句话能不能成立？我觉得能——它和具身认知（embodied cognition）、分布式认知（distributed cognition）在哲学上同源。人类智能从来不是孤立大脑的属性，它是大脑 + 语言 + 工具 + 他人 + 制度的联合属性。我们一直知道这个道理，但在 AI 讨论里忘了。这篇论文提醒你记起来。
今天刷到这篇文章几次，说点不一样的。与其说 AI First，不如说软件工程 First。
这篇文章看着在讲 AI，底下全是软件工程。
抛开后面讲组织和人的部分，原文前半段的重点简单总结一下：
AI 时代，人成了瓶颈。PM 花几周做需求，AI 两小时就能实现，PM 成了瓶颈。QA 测三天，AI 写代码只要两小时，QA 成了瓶颈。团队 25 个人，对手几百人，人力也是瓶颈。
怎么办？把人从链条里拿掉。AI 写代码、AI 审查代码、AI 跑测试、AI 部署上线、AI 监控线上状态，出了问题自动回滚。每天定时扫描日志，自动发现问题、分配任务、跟踪修复。整条流水线跑起来，人只需要在关键节点做判断。
至于文中提到的统一代码库，锦上添花，和 AI First 关系不大。有当然更好，没有也有很多替代方案。
整套方案听下来，逻辑自洽，效果也漂亮：一天部署好几次，功能当天上当天撤，数据说了算。
但先别急着照搬，先对照自己的情况想几件事：
第一，自动化测试。AI 改完代码，你得有办法确认它没搞崩别的功能。测试覆盖不够的话，每次 AI 提交代码你都得人工回归一遍，那速度根本快不起来。
第二，CI/CD 流程。从提交代码到部署上线，中间的测试、审查、发布、回滚，是不是全自动跑通了？这条流水线不通，AI 写得再快，代码也堆在那儿等人手动处理。
第三，A/B 测试和线上监控。新功能上线之后效果好不好，得有数据说话，效果不好得能随时关掉。没有这套机制，AI 一天产出五个功能，你都不知道哪个该留哪个该砍。
第四，任务管理。任务得拆到合适的粒度，生命周期得跟踪得住。一个大而模糊的任务丢给 AI，现在的能力还啃不动。多个 Agent 同时干活的时候，谁做哪个、哪个优先、做到什么程度，这些都得有地方管。
第五，系统架构。架构太乱或者压根没有架构的代码，AI 维护起来跟人一样头疼。上下文塞满了还是搞不清边界在哪，改一处崩三处。
这几条里如果有做不到的，就得靠人去补。补不上，AI First 就只是一句口号。
但假设你全做到了，就能 AI First 了？
还是不行。这套玩法只适合一部分场景。
什么场景适合？后端逻辑为主、界面不复杂的产品，比如 API 服务、数据处理平台、内部工具。功能好不好，跑一下数据就知道，不需要人去盯着每个像素。原文里的就是个 Agent 平台，本质上是后端驱动的产品，可以用这套打法。
再比如早期产品快速试错，功能上了不行就撤，用户预期本来就没那么高，AI 的速度优势能充分发挥。
但很多场景玩不转。
比如 UI 密集的产品。自媒体天天喊前端已死，但你让 AI 做个复杂界面试试，各种易用性问题、交互细节、视觉还原，它搞不定的。否则马斯克靠 AI 早就改了不知道改版 X 多少次了。
比如对功能质量敏感的产品。Anthropic 和 OpenAI 不知道 AI First 吗？他们敢在 Claude Code 和 Codex 上这么搞吗？让 AI 全自动迭代自家的核心产品，用户不骂死才怪。
再比如安全性要求高的场景，银行系统、在线交易平台，AI 代码出个差错，那可不是回滚能解决的。
AI First 的方向没有错，它代表的是一种意识的转变：每做一个决策的时候，想一想这件事能不能让 AI 来做，如果不能，缺什么条件，怎么把条件补上。
但这种意识要落地，靠的不仅是买几个 AI 工具的订阅，还需要把基础搭好。测试、CI/CD、监控、架构、任务管理，这些做扎实了，AI 的能力自然能释放出来。做不好，加再多 AI 也是在沙子上盖楼。
从这个角度看，AI First 的终点未必是让 AI 干所有的活，而是借着这股力量，把你一直想做但没动力做的工程改进，真正推动起来。
仰望星空是好的，但也还要脚踏实地。
Karpathy 做了个知识管理工具，很精致。类似的产品遍地都是。但这件事本身就是一个时代的隐喻：最聪明的人还在优化收集，而收集这件事已经毫无意义了。
说穿了，所谓个人 AI 知识库，就是这个时代的收藏夹。从 Evernote 到 Notion 到 Obsidian，换了三代皮囊，干的是同一件事——把别人的东西搬到自己的抽屉里，然后再也不打开。现在加上一层向量搜索和知识图谱，本质没变，只是抽屉更高级了。你收藏一万篇文章，不如 ChatGPT 现场给你讲一遍。
AI 已经是人类有史以来最强的公共知识检索引擎。还在整理公共知识的人，是在和推土机比挖坑。
什么东西 AI 搜不到？你操盘的项目烧了八百万最后烂尾，复盘时才发现不是方向错了，是第三个月该砍没砍。你带过的团队，骨干离职后才意识到自己把信任当成了管理。你谈崩的那次融资，不是因为数据不好看，是因为你在关键问题上犹豫了三秒，对面就读出了你自己都不信。还有那些所有人都说不行、你顶着压力做成了的决定——事后看，关键不是你比别人聪明，是你在那个具体时刻看到了别人没看到的东西。这些成败都没有出现在任何商业书籍、任何知乎高赞、任何 MBA 案例里，因为它们带着你独有的上下文，长在你身上。
这才是唯一值得系统化的东西：被现实反复锤炼后结晶出来的判断力。
而 AI 的讽刺恰好在这里。它不是均衡器，是照妖镜。有判断力的人用 AI，杠杆率翻倍，因为他们知道什么该要、什么该扔。没判断力的人用 AI，灾难加速——AI 给了你五个方案，每个都说得头头是道，你选不出来，或者选了最顺耳的那个。以前决策慢，好歹有时间撞墙后回头；现在 AI 帮你把油门焊死，撞墙的速度快了十倍。
有人说 AI 会让每个人都成为专家。错。AI 让每个人都能输出专家的格式，但格式从来不是专业最难的部分。最难的部分是知道什么时候该说不。
AI 把执行成本压到了接近零，但判断成本一分没降。而大多数人一辈子都在逃避的，恰恰是判断。
别再整理知识库了。把你最痛的失败和最反共识的成功写下来，写清楚当时怎么想的、为什么对了或错了、如果重来会怎么做。这十条的价值，超过你收藏的一万篇文章。知识不稀缺了，你的经历才稀缺。
刷到Miles大神的这个Claude code Prompt，卧槽太顶了，
必须分享下，简直是教科书级别，
这才是Claude code的正确打开方式啊兄弟们，
咱们很多人用 Claude Code 或 Cursor 觉得不好用，
估计跟我一样还只是把它当做一个 AI 工具，用指令逻辑驱动，
Miles这个妙的点是用组织管理的逻辑驾驭 AI，
不着急让 AI 写代码，
先花 80% 的篇幅教 AI 怎么做个好员工，比如
1️⃣ 敢于质疑老板，Challenge assumptions
2️⃣ 做事有章法，Discovery -> Planning -> Building
3️⃣ 凡事有交代，Stop and check in
整个 Prompt 的架构也很硬，这里放下内核框架大家感受下，原版 Prompt 我提取出来放评论区̋(ˊ•͈ꇴ•͈ˋ)
1. Role Definition (角色升维)：从 Coder 升级为 Technical Co-Founder。不仅写代码，还负责技术决策和怼老板（Challenge assumptions）
2. Process Control (流程锁定)：强制分阶段（Discovery -> Planning -> Building...），防止 AI 一上来就瞎写一通
3. Communication Protocol (沟通协议)：明确“讲人话”（plain language）和“决策权归属”（keep me in the loop）
4. Anti-Fragile (反脆弱)：预设了“Handle edge cases”、“Not a hackathon project”，要求生产级质量
Anchor Points (物理触点):
• Hackathon project（反面教材）
• Real product（交付标准）
• Technical jargon（被禁止的黑话）
• Version 1（MVP思维）
Drafting Strategy:
• Intro: 直接点破本质——这是在雇佣一个CTO，而不是一个码农
• Deconstruction: 分模块拆解（Role, Phases, Rules），每一个点都要解释“为什么这样写比普通 Prompt 强”
• Highlight: 重点强调 Phase 1 的“Challenge assumptions”和 Phase 3 的“Stop and check in”
• Ending: 总结这个 Prompt 的核心心法
其实这个压缩方式还挺好用的，DeepChat 里面上下文压缩也是这样的思路去做的，当上下文过长命中阈值的时候，就回去从远端开始 offload 掉 tool call相关的内容，不过如何以后模型都能内置这种能力，那倒是省事了。代码在这里
https://t.co/fm33J0Xqog
妙啊
notebooklm 的读书场景，最佳实践探索：
1、微信读书正常阅读划线；
2、电子书全文导入 notebooklm（用 calibre 转 txt），再用 fast research/deep research 自动化收集主题资料；
3、读完后，在微信读书里整理划线和笔记时，重读时的思考，在 notebooklm 里和 gemini 3 聊一聊
根据我的大量实践，notebooklm 里面的回答质量足够高。例如图 2-4。和我真人理解的水平旗鼓相当，但是表述等细节上远超人类，对阅读者很有帮助。
这样，一本书读完后，留下或多或少的划线，整理时在微信读书里全文搜索关键词，重读若干遍，过程中 5678 个问题随时和 gemini 聊。
读书是为了促进思考，notebooklm 可以成为你在阅读场景下的极佳思想伙伴。
强烈推荐读一下这篇文章 我自己做了些整理
作者是北大 Linian Wang。文章讲的是把 Kimi K2 适配到 vLLM 的过程中，遇到一个很反直觉的现象：同一个模型，在官方 API 上 tool calling 几乎不出错，但换到 vLLM 上就一塌糊涂。然后作者一步步定位原因、推动修复。
我觉得它最值得看的点，其实不是“Kimi/K2/vLLM”上，而是通过这个过程可以把大模型 API 的底层逻辑理解清楚：
大模型 API 的本质：把请求“展开成 Prompt（Token 序列）”，然后做补全（completion）。
所谓 chatbot、tool calling / function calling，本质都是在这个过程上做工程封装。
一切都可以拆回成：Render → Completion → Parse
现在 Chat Completions（以及 function call / tool calling）看起来是这种“结构化请求”：
- messages：system/user/assistant 多轮（也包含 tool_calls 与 tool 的返回）
- tools / functions：工具定义
- tool calling 的模式/约束：tool_choice、parallel tool calls 等
- 采样/停止参数：temperature、stop、max_tokens…
但在模型真正开始预测下一个 token 之前，这些东西都会被系统按照下面的过程处理：
(A) 展开（render）→ 得到最终 Prompt（文本/Token 序列）
(B) 补全（completion）→ 模型续写下一段 Token
(C) 解析（parse）→ 把续写还原成 assistant 文本 / tool_calls 等结构化结果
所以其实可以这么理解：
- Chat Completions ≈ Completions +（A：自动把 messages 渲染成 prompt）+（C：把输出再解释回消息结构）
- Chat + tool calling ≈ Chat +（C：把“特定格式的补全”解析成 tool_calls，并做 schema 校验/护栏）
重点：Chat / Function Call 不是模型多了一种全新能力，而是服务端把 prompt 构造与输出解析自动化了；模型层面依旧是在做下一段 token 的补全。
文章里出现的 bug 基本都发生在 A（render）或 C（parse），而不是“模型本身能力不行”。
文章里一个非常实用的排障方法：
- 不直接用 /v1/chat/completions
- 而是在外部手动 apply_chat_template 得到最终 prompt
- 再把这个 prompt 丢给更底层的 /v1/completions
这么做的好处是：你能“看到真相”：
- 你能检查最终 Prompt 到底长什么样（当然也可以用 echo 回显出来）
- 你还能看到模型最原始的补全文本（协议 token 没被上层 parser 二次加工/丢弃）
后面很多结论，都靠这一步才定位出来：问题不在“模型不会调工具”，而在 prompt 展开和输出解析存在不兼容或边界问题。
三个问题，用更直白的话讲清楚就是展开和解析上出了问题
1) Prompt 末尾少了“现在轮到 assistant 开始输出”的自动补全后缀
本来应该用户问一句 → 模型应该立刻按 tool call 的格式进行补全。
但因为一个参数没有传递到位，导致实际喂给模型的 prompt 末尾缺了关键的 assistant 回合起始标记 / generation prompt（可以理解为少了一个重要的协议尾巴，相当于没明确告诉模型“轮到你回答了”）。
结果就是模型仍然会补全 token，但完全不知道“接下来该干嘛”
- 有时像在续写历史对话（没进入回答态）
- 有时输出自然语言闲聊
- 有时输出半截结构化但不成形
1) 空内容被错误渲染成，直接把 prompt 污染成噪声
某条历史消息 content: '' 就是“空”，本来在 Prompt 也应该就是🈚️啥也不出现。
结果实际渲染链路，框架内部为了统一数据结构，把 '' 标准化成类似 [{type: "text", text: ""}] 这样的 list（多模态/富文本体系里很常见）塞到 Prompt 里面。
结果就是模型是在对“被污染的上下文”做补全。导致 tool calling 的效果劣化。
3) 模型其实已经“写出了工具调用”，但解析器太严格，把它当异常丢掉了
模型已经生成了“看起来就是工具调用”的片段，但是解析器太严格了，当做异常处理掉了。
（这里面还有上下文污染导致模型生成格式不对的原因）
读完这篇文章最大的收获
1) 一切要还原到“Prompt 补全”这个本质上来理解。
虽然这篇文章，是围绕 tool calling 展开的，但它的结论其实适用于所有大模型 API 场景（chat、completion、structured generation……）。
不管你是用 chat 还是 function call，本质上都是在做“Prompt 补全”。
所以当遇到问题，第一步都要还原到“最终 prompt 是什么样子？”要拿到实际喂给模型的 prompt，甚至不用像文章中这样，拿到协议层的，只用看到你的 API 请求就能判断对不对。
另外很多 API 的报错，也可以从“Prompt 补全”这个角度去分析。
2) Tool calling 本质是“强约束 Schema 输出”（甚至可以当 JSON 限定器/结构化生成器用）。
从工程角度看，tool calling 更像：
让模型按一个强约束的输出协议（schema）去生成结构化片段，然后由服务端解析并执行。
一旦你把它理解其本质是“强 schema 生成”，你会发现 tool calling 还能干一件很实用的事：
- 你不一定真的要“调用工具”，也可以把它当作 JSON/DSL 的限定器，让模型稳定地产出符合 schema 的结构化结果，再交给下游系统处理。
对“强约束生成 / constrained decoding”这个方向感兴趣的话，也推荐顺手看：
- XGrammar：偏“把语法/约束编译成高效的 token 级约束”，让解码阶段就不可能走出非法分支
- LLGuidance：偏“用 guidance/约束驱动生成”，把结构化正确性前置到解码过程，而不是生成完再靠 parser 猜测。
https://t.co/aAopZ18aUl
你有没有想过，为什么有些人能做出改变世界的事情，而大多数普通人却一辈子碌碌无为？
这或许并不是因为天赋差距，也不是因为资源不够，而是因为大多数人根本分不清什么是信号、什么是噪音。
如果你对这个话题感兴趣，非常推荐你们去看一下《The Diary of a CEO》和凯文·奥利里的这期对谈。
凯文·奥利里，人称Mr. Wonderful，是一位白手起家的投资人，创建并出售的公司价值数十亿美元。
但他早年的经历更有意思，90年代的时候他做教育软件，跟史蒂夫·乔布斯有过深度合作。
在访谈里，他反复提到了一个非常尖锐的观察：真正能成功的企业家、管理者和领导者，都具备一种能力，就是在海量的信息和机会中，快速识别出什么是信号，什么是噪音。
他说，这是他这么多年来见过的、关于成功者最核心的共同特质。
而这，也是史蒂夫·乔布斯教他的。
什么是信号？
信号是你今天醒着的18个小时里，必须搞定的3到5件事，是那些真正能推动你朝目标前进的信息和机会。
什么是噪音？
噪音是那些看起来很诱人、很紧急、很重要，但实际上会分散你注意力甚至把你带偏的东西。
换句话说，所有阻止你完成这3到5件事的东西，都是噪音。
有人给你发消息，噪音。
有个会议可开可不开，噪音。
但很多人，都把自己大部分时间花在了那些看起来紧急、但并不重要的事情上，被邮件、会议、社交媒体、各种琐事淹没。
一天到晚都在「响应」，却从来没有真正「推进」。
凯文说，乔布斯的成功公式就是：80%信号，20%噪音。
访谈里，凯文分享了一段他和乔布斯的真实对话，也是我觉得最精彩的一部分。
当时他们在讨论教育软件的开发，奥利里提了一些关于用户反馈的问题。
乔布斯直接打断他：
「凯文，我才不管学生想要什么，家长怎么想，或者任何人怎么想。我只管我自己想怎样。他们自己都不知道自己想要什么，直到我告诉他们想要什么。」
奥利里说：「史蒂夫，你听起来就像……」
话还没说完，乔布斯已经不想听了。
这段对话完美解释了为什么乔布斯能做到80%信号。
在他的世界观里，用户反馈、市场调研、专家意见，这些大多数公司奉为圭臬的东西，全都是噪音。
他只相信一件事：自己对产品的愿景。
凯文说，乔布斯当年会凌晨两点半给他发邮件，期待他立刻回复。
说实话，乔布斯不是个好相处的人，他说话很冲，甚至会直接说「闭嘴，照我说的做」。
但正是这种近乎偏执的专注，让他能够做出改变世界的产品。
凯文回忆，每次他遇到坏消息，比如丢了一个大客户、出了什么问题——他就想起乔布斯对他说的话：
「专注于信号，凯文。专注于信号。就这样。」
不管是好消息还是坏消息，都不能把你从信号上拉走，这才是真正的纪律。
这听起来好像很简单，但你仔细想想，大多数人的一天是怎么过的？
早上打开电脑，回几封邮件。
然后有人找你开会，中午吃饭刷刷手机，下午又是几个会议。
一天结束的时候，觉得自己很忙，很累，但今天到底完成了什么真正重要的事？
答不上来。
这就是典型的50%信号、50%噪音，甚至更糟。
凯文说：「一个能理解信号噪音比的人，会成功。那些信号噪音比跌到50对50的人，会失败。就这么简单。」
接下来他讲了一个关于埃隆·马斯克的观察。
他说，如果乔布斯是80%信号、20%噪音，那马斯克就是接近100%信号。
「他没有噪音。他不处理噪音。他醒着的每一分钟、每一秒钟，都是信号。」
凯文还提到了他在哈佛教书时观察到一个现象。
当时，每届120人的班级里，大约三分之二的人毕业后想去做咨询。
凯文认为，这些人会过着平庸的生活，一辈子不做任何有实质意义的决定。24个月后，他们会被这种病永远感染。
他说这句话，并不是说咨询这个职业本身有什么问题，而是在说一种思维模式的问题。
什么思维模式呢？
就是回避做决定，回避承担风险，回避在信号和噪音之间做出选择。
咨询顾问的工作本质是帮别人分析问题、提供建议，但最终拍板做决定的是客户。这意味着你可以永远站在安全的位置，不用为结果负责。
时间长了，你会失去一种能力，就是在不确定性中做判断的能力。
而企业家、管理者、领导者每天面对的恰恰就是不确定性。
没有人能告诉你哪个选择一定对，你必须自己判断，然后承担后果。
凯文说，成功的企业家需要具备几个特质，一个是风险承受能力，一个是专注力，还有一个是运气。
运气这个东西听起来不可控，但其实也和选择有关。
因为运气并不会平均分配给所有人，它会倾向于那些把自己放在正确位置上的人。
同理，如果你一直在追逐噪音，你就不太可能碰上那些改变命运的机遇，因为你的注意力和时间都被占用了。
凯文在最后总结了他眼里成功的真正秘诀：
「你今天醒着的这18个小时，有3到5件事是必须完成的，把它们找出来。然后不管发生什么，把它们完成。明天也这样做，后天也这样做。这就是成功的秘密。」
这是区分伟大企业家和普通管理者的核心。
核心就一句话：专注于信号，消除噪音。
我现在把 Agent 的实现理解成三种“承载层”：模型 / Prompt / 代码。
它们本质是在做一个常见权衡：泛化能力 vs 可控/可审计。
越靠模型越泛化但越难控；越靠代码越可控但越僵硬；Prompt 是可调的软控制器。
这就是一个 trade-off，最理想情况是，你理解模型的边界，边界内靠模型，边界外用代码。
Last Seen Users on Sotwe
Most Popular Users
Elon Musk 
@elonmusk
240.4M followers
Barack Obama
@barackobama
119.3M followers
Donald J. Trump
@realdonaldtrump
111.6M followers
Cristiano Ronaldo
@cristiano
109.9M followers
Narendra Modi
@narendramodi
106.9M followers
Rihanna
@rihanna
97.5M followers
NASA
@nasa
92.1M followers
Justin Bieber
@justinbieber
90.8M followers
KATY PERRY
@katyperry
87.3M followers
Taylor Swift
@taylorswift13
81.1M followers
Lady Gaga
@ladygaga
72.7M followers
Kim Kardashian
@kimkardashian
69.6M followers
Virat Kohli
@imvkohli
69.3M followers
YouTube
@youtube
68.6M followers
Bill Gates
@billgates
63.7M followers
The Ellen Show
@theellenshow
62.5M followers
Neymar Jr
@neymarjr
62M followers
CNN
@cnn
61.9M followers
X
@x
60.9M followers
Selena Gomez
@selenagomez
60.4M followers