去年三十岁生日时，我写过一篇《人间在世》。那时候的我，像是刚刚从自己的精神孤岛上被拉回人间。老婆、可乐、岁岁，像三股温暖的绳索，让我第一次如此具体地理解了责任、牵挂和被需要。那一年，我终于承认，所谓自由并不只是一个人冷静地站在世界之外，也可以是心甘情愿地被爱所束缚。转眼三十一岁。这不是一个特别宏大的年纪，不像三十岁那样带着某种仪式感，也远没有到可以坦然把人生看透的时候。但它像一个安静的转折点：你不再频繁地向世界索要答案，却开始更认真地看见眼前的一切。孩子长大了一点，猫还是会在家里找一个舒服的位置蹲着，生活没有给出什么终极解释，却把答案藏在这些具体的瞬间里。这一年经历了太多太多。很多时刻说不上是熬过来的，还是被生活推着往前走的。好像一直在处理问题，承担责任，回应期待，追赶一个又一个被不断提前的节点。世界的速度越来越快，快到连疲惫都来不及被承认，只能先被折叠起来，塞进下一件必须完成的事情里。有些清晨，天还没亮，我会突然醒来。身体明明很累，意识却像被强行拽回现实。头晕、心悸、胸口发紧，脑子里盘旋的不是某个宏大的理想，而是一些很具体、甚至有点荒诞的念头：身体还能不能撑住，日子会不会突然中断，万一真的出了什么事，身后的人要怎么办。到了这个年纪才发现，成年人所谓的坚强，很多时候并不是内心真的无比坚定，而是你知道自己不能轻易倒下。因为身后已经有了人，有了家，有了那些你牵挂、也牵挂着你的人。这一年，我也更切身地感受到技术浪潮的另一面。过去我们常说，技术会解放人。可真正站在浪潮中间时才发现，技术在拓宽能力边界的同时，也会悄悄抬高世界对人的要求。它让许多事情看起来变得更简单，让许多原本需要漫长讨论和审慎设计的东西，忽然可以被快速生成、快速拼装、快速推进。于是人们开始相信，既然工具已经如此强大，那么人也应该更快、更稳、更无所不能。可真实世界不是原型图，也不是几句漂亮的描述。系统有系统的重量，现实有现实的阻力，复杂性不会因为被暂时遮住就真的消失。它只是换了一种方式，最终落回到人的身上，落到一个个深夜、一次次返工、一轮轮无法绕开的细节里。我越来越觉得，超级智能到来之前，最先被改变的未必是某个遥远的未来，而是我们今天的工作方式、协作方式，以及对自身边界的感知。机器越快，人越容易被要求跟上；工具越强，人越容易被默认不该喊累。效率成为一种新的道德，慢下来反而像是一种错误。但人终究不是系统的一部分，不是某个可以无限扩容的计算节点，也不是一台只要接上电源就能持续运转的机器。人的身体会报警，情绪会迟钝，心会在某些时刻忽然空下去。那些无法被压缩的睡眠、心跳、恐惧、爱与牵挂，才不断提醒我：我不是一个只负责响应需求、解决问题、提供产能的工具。去年三十岁，我以为自己终于从孤岛回到了人间。到了三十一岁，我才更清楚地意识到：回到人间不是终点，守住人间才是更漫长的事。因为真正回到人间之后才会明白，人间并不只是温暖、安稳和烟火气。它也意味着责任、疲惫、限制和无法逃避的牵挂。它让你不再能轻易地把自己抽离出去，也让你在几乎被生活耗尽的时候，仍然会因为一个很小的瞬间，被重新拉回来。比如这个普通的生日。孩子低头去碰蛋糕，猫蹲在一旁看着镜头，桌上有没收拾完的碗筷，家人在旁边闲聊，空气里有一点疲惫，也有一点温柔。那一刻没有什么宏大的意义，也不产生任何可见的效率。可它会让人忽然相信，生活真正重要的部分，可能一直都藏在这些微小、具体、不可替代的瞬间里。而时代正在朝相反的方向狂奔。判断、表达、记忆，甚至情绪本身，都越来越像是可以被拆解、重组、计算和优化的东西。人被推着变得更快、更清晰、更稳定、更有用；慢下来、迟疑、心软，反而像某种需要被修正的缺陷。所以我才更想守住一点不那么“先进”的东西。希望自己还能认真地开心，认真地疲惫，认真地害怕，也认真地爱；还能被一个眼神牵动，被一个普通夜晚安慰；还能在被生活和技术同时推着向前时，承认身体的警报，承认心里的迟疑，承认自己不是一台可以无限加速的机器。这些东西并不高效，也不总是体面。它们会让人脆弱，让人犹豫，让人无法用最优路径处理生活。但也正是它们，让人不至于只剩下功能、角色和产能。它们是柔软、牵挂、心疼、舍不得，也是那些无法被量化的温度。所以我想守住的，也许不是某种宏大的信念，而是这些微小但真实的反应：会累，会怕，会爱，会被日常安慰，也会因为一个普通瞬间重新相信生活。在超级智能席卷世界的前夜，这些东西显得笨拙，却也因此更像是人。愿三十一岁之后的日子里，无论世界变得多快，我都还能维持住一个真正的人的感受。仍然热爱家人，珍惜日常，对未知保持好奇，也对眼前的一切保有感恩。
读《贫穷的本质》：当系统剥夺了你的容错率与认知带宽
读《贫穷的本质》：当系统剥夺了你的容错率与认知带宽传统的宏观经济学在探讨贫困时，往往陷入“自由市场”与“制度决定论”的意识形态之争。而《贫穷的本质》最大的贡献，在于它用微观实证的方法，为“贫困”这个复杂的黑盒建立了一套底层的可观测指标。然而，透过数据与实证的视角深入剖析时会发现，贫穷并非一种简单的经济状态，而是一种被系统性剥夺了“容错率”与“认知默认值”的架构瘫痪。第一部分：微观模型重构——在极高风险溢价下运转的机制书中极具洞见地指出：“穷人就像对冲基金经理一样，唯一的不同点在于二者的收入水平。”但如果用更严谨的投资与资产配置逻辑来审视，穷人其实是没有任何“安全垫”的裸奔者。1. 风险敞口与防御性多元化在没有完善的医疗保险、失业救济和底层社会保障的情况下，穷人的个人资产负债表极度脆弱。一场小病或一次干旱，就能让现金流彻底断裂。为了对冲这种极高的风险敞口，穷人被迫进行“业务多元化”——比如早上卖饼，白天做苦力，晚上串珠子。这种分散并非为了追求超额收益，而纯粹是生存驱动的防御机制。但代价是致命的：它直接扼杀了规模效应的产生。缺乏安全边际的底层商业模式，使得他们永远只能在极低的利润率中挣扎，无法跨越成本的门槛。书中打破了“穷人都是天生的企业家”的浪漫幻想——真正的企业家精神需要容错率来支撑，而穷人的小生意，更多是系统性失败下的无奈代偿。2. S 型曲线陷阱与时间不一致性为什么穷人知道储蓄和教育很重要，却依然会把钱花在买电视机和加糖茶上？行为经济学中的“双曲贴现”给出了底层算法的解释：$$ V = \frac{A}{1 + kD} $$(其中 $V$ 是当前感知价值，​$A$ 是未来收益，​$D$ 是延迟时间，​$k$ 是贴现率)在压力激素（皮质醇）长期高位水平的环境下，穷人的贴现率 $k$ 值被急剧放大。当教育或储蓄的回报呈现出漫长的“S 型曲线”（必须越过极高的投入阈值才能看到收益）时，长远目标的当前感知价值会迅速衰减。此时，大脑会理智地选择“及时行乐”作为多巴胺代偿。这不是短视，而是高压系统下维持心智运转的必然选择——俗称“活着已经很痛苦了，来点快乐的吧”。第二部分：RCT 实验的统计学过拟合阿比吉特·班纳吉等人凭借随机对照实验（RCT）获得了诺贝尔奖，但从数据工程和因果推断的角度来看，试图用局部 A/B 测试的成功去推导全局社会的因果律，存在致命的逻辑缺陷。1. 局部均衡 vs. 全局均衡的规模化反噬RCT 最大的痛点在于其结论极难跨语境迁移，在统计学上这相当于模型在训练集上完美，但在测试集上严重“过拟合”。例如，给几十个穷人发放小额信贷，他们确实能增加收入（局部均衡）。但如果将干预规模化，给一万人发放信贷，所有人都在做同质化的小买卖，就会导致供过于求、价格暴跌（全局均衡）。局部测试有效的变量，一旦全局铺开，系统的底层逻辑就变了。2. SUTVA 假设的破裂与溢出效应RCT 要成立，必须满足严苛的 SUTVA（稳定个体处理值假设），即控制组和实验组必须完全隔离。但在复杂的社会网络中，如果实验组的村民拿到了免费蚊帐，控制组的村民可能会产生极大的不公平感，从而彻底放弃原有的卫生习惯。这种行为博弈会严重扭曲最终的因果推断。3. 黑盒归因的危险性书中提到“持续两年吃打虫药的孩子，成年后收入多 20%”。在长达十几年的时间跨度里，将 20% 的收入增长线性归因于童年时的两片药，忽略了宏观经济周期、家庭资源重新分配等无数个混杂变量。正如安格斯·迪顿所讽刺的，这是一种“水管工经济学”——不去重构腐朽的底层官僚体制和公共财政，只试图通过设计海报来提高护士的出勤率。战术上的勤奋，掩盖了战略上的系统性崩塌。第三部分：系统默认值与心智带宽的关联思考要真正理解贫穷，我们需要跳出单纯的经济学框架，将其与《助推》中的“选择架构”，以及《超级智能》中的算力/带宽概念进行对撞。核心维度《贫穷的本质》：带宽剥夺《助推》：系统默认值《超级智能》：Agent 算力模型环境架构充满惩罚机制，容错率极低。系统预设了友好的“默认选项”。算力充沛时优化终极目标，受限时被动响应。心智负荷纯手动模式，高频调用自控力。用环境设计代替个人意志，降低摩擦。算力被生存类“中断请求”占满，无长期规划。1. 被剥夺的“父爱主义”红利中产阶级之所以显得比穷人更有远见，并不是因为基因或意志力更好，而是因为现代社会的基础设施替我们做出了无数个较优的“默认选择”。住房公积金的自动扣缴、自来水的集中净化、疫苗的强制接种——我们不需要每天消耗意志力去执行这些长远规划。而穷人被彻底抛入了一个毫无预设缓冲的旷野。他们的每一次储蓄、每一次健康干预，都需要在繁杂的决策因素之间抉择。没有任何人的意志力，能够承受每天上百次的、缺乏默认安全值的高风险决策摩擦。2. 算力锁死与 Agent 的认知瘫痪如果把人看作一个自主执行的智能体（Agent），穷人的状态就像是一个被锁死在低算力、高内存占用环境下的单线程程序。当所有的系统资源都被用来处理“下一顿饭在哪”、“今天借的钱怎么还”这类紧急中断请求时，Agent 根本无法分配出哪怕一丝额外的带宽，去运行“十年后的教育规划”这种低优后台任务。第四部分：从生产者到残次消费者——新穷人的社会学定义如果《贫穷的本质》解释了前现代农业社会中生存极线的挣扎，那么齐格蒙特·鲍曼在《工作、消费主义与新穷人》中则回答了另一个现代刺痛：为什么今天即便大家都能吃饱饭，依然感到深深的贫穷与焦虑？1. 电视机与糖茶的另一层真相：维持社会身份的入场券《贫穷的本质》认为穷人买电视机是为了“多巴胺代偿”，而鲍曼给出了更残酷的社会学解释：在现代消费社会中，人的身份不再由“你生产了什么”决定，而是由“你消费了什么”定义。买一台电视机、穿一件体面的廉价大衣，不再是虚荣，而是确认自己仍是人类社会一员的最低成本。新穷人之所以在必需品匮乏的情况下依然追求“奢侈品”，是因为在消费主义的架构下，不能消费就意味着社会性死亡。2. 结构性废弃：从后备军到残次品传统资本主义社会（生产者社会）里，穷人是“产业后备军”，工厂需要他们，他们通过“工作伦理”被规训，总有一天还能回到生产线上。但现代资本主义（消费者社会）不再缺劳动力，社会需要的是“合格的消费者”。新穷人真正的悲剧在于：系统不再需要他们了。他们被定义为“残次的、有缺陷的消费者”。这解释了为什么当今社会对穷人的态度愈发冷漠——因为他们在系统中都已成为冗余的废弃物。第五部分：终极剥夺——被经济系统垃圾回收的孤儿节点如果我们用《超级智能》的技术演进路线去补全鲍曼的理论，会得出一个极其冷酷的结论：新时代穷人面临的最大悲剧，不是被残酷地剥削，而是连被剥削的价值都彻底丧失了。1. 从劳动后备军到被弃用的 API在工业时代，资本主义的运转需要大量的劳动力作为“燃料”。然而，随着大型语言模型（LLM）和多智能体系统的普及，从流水线操作到复杂的认知工作，都在被封装成成本趋近于零的自动化工作流。在由资本与 AI 构建的高效闭环中，人类劳动力正在变成一个高延迟、低并发且极易出错的劣质 API。系统不再需要雇佣他们，也不再需要剥削他们。2. 经济数据流中的孤儿节点当一个人在生产端被 AI 彻底平替，失去了劳动价值，他在消费端又因为没有现金流，沦为毫无购买力的“残次消费者”。如果将全球经济视为一个巨大的有向无环图（DAG），传统的穷人至少还是提供算力的“上游输入节点”。但在超级智能时代，这部分群体既不能输出有效生产力，又无法消化系统多余的产能。他们与经济系统的所有接口都被切断，成为了在架构中没有任何上下游依赖的“孤儿节点”。3. 系统的垃圾回收机制在高度自动化的未来，那些被剥夺了生产权与消费权的新穷人，面临的将是社会学意义上的垃圾回收。系统不会对他们施加直接的暴力，而是通过物理空间的隔离、信息流的奶头乐算法，将他们静默地移出主线程。他们不再是社会的“阶级敌人”，而变成了系统升级后遗留的“冗余数据”。结语：重夺默认值，对抗系统熵增贫穷的演化史，就是穷人在系统架构中不断被边缘化的历史。前现代的穷人缺乏资源，死于容错率极低；现代的穷人被消费主义收割，死于带宽劫持；而 AI 时代的穷人，将面临终极的社会性死亡——被确诊为对系统闭环毫无增益的“无效载荷”。真正拉开阶层差距并制造结构性绝望的，往往不是个体的认知水平，而是他们所身处的底层架构的容错率。面对这样一个试图将人异化为“劣质 API”或“残次消费者”的庞大系统，个人的终极防御不是在焦虑中无休止地内卷，而是主动夺回自身心智的控制权，建立属于自己的“系统默认值”。这也是为什么，真正的富足不再是无止境的攀比与消耗，而是拥有对冲系统风险的现金流，以及屏蔽消费主义噪音的认知带宽。在结束了一段高压的研发交付周期后，能够心安理得地合上电脑，去休个假，陪陪家人，为家里的猫添点猫粮，在阳台上静静读完一本厚重的经典——这种掌握自身节奏、回归物理真实、拥有丰盈精神世界的生活状态，本身就是对这个企图将我们降维成“孤儿节点”的时代，最漂亮的反击。
读书笔记：图解大模型——生成式AI原理与实战
书籍信息原书名：Hands-On Large Language Models中文名：图解大模型：生成式AI原理与实战作者：Jay Alammar（沙特）、Maarten Grootendorst（荷兰）出版：O'Reilly, 2024页数：~400 页，数百张原创插图定位：从零到实战的 LLM 全景指南，图解驱动，代码可跑推荐人：Andrew Ng、Nils Reimers（sentence-transformers 作者）、Josh Starmer（StatQuest）为什么读这本书作为数据研发工程师，大模型已经从「论文里的概念」变成了「每天都在用的工具」。但用归用，很多核心机制——Transformer 的注意力到底在算什么、Embedding 空间为什么能捕捉语义、RAG 的检索链路怎么设计——一直停留在「大概知道」的阶段。Jay Alammar 是写出 The Illustrated Transformer 的人，他的可视化能力是业界公认的。这本书延续了他一贯的图解风格，把抽象的数学过程拆成直觉可理解的视觉流程。对我来说，这不是一本「入门书」，而是一本「把模糊认知变成清晰认知」的书。读完之后，我和 Jarvis 一起把书中第 8 章（语义搜索与 RAG）的理论落地成了一个真实项目——siyuan-rag：思源笔记联动，为自己的思源笔记构建了混合检索系统（BM25 + Vector + RRF）。理论到实践的闭环，是这本书最大的价值。全书骨架三部分，十二章，一条清晰的递进线：Part I 理解语言模型（Ch 1-3） → 语言模型是什么、词元化、嵌入向量、Transformer 架构 Part II 使用预训练模型（Ch 4-9） → 分类、聚类、Prompt Engineering、文本生成、语义搜索/RAG、多模态 Part III 训练与微调（Ch 10-12） → 构建嵌入模型、微调分类模型、微调生成模型递进逻辑：先建立「是什么」的认知基础 → 再学「怎么用」的实战技能 → 最后掌握「怎么改」的深度能力。Part I：理解语言模型Ch 1 语言模型导论这一章建立了全书的概念地图。核心区分：表示模型（Representation Models） ：BERT 系，双向上下文，擅长理解（分类、检索、相似度）生成模型（Generative Models） ：GPT 系，自回归，擅长生成（续写、对话、翻译）关键洞察：这两类模型不是对立的，而是同一个 Transformer 架构在不同训练目标下的产物。BERT 用 MLM（掩码语言模型），GPT 用 CLM（因果语言模型）。训练目标决定了模型的「视野」——BERT 能看到前后文，GPT 只能看到前文。Ch 2 词元与嵌入这是全书最基础也最重要的一章。两个核心概念：词元化（Tokenization） ：文本不是以「词」为单位进入模型的，而是以「子词（subword）」为单位BPE（Byte Pair Encoding）：从字符级开始，统计最高频的相邻对，逐步合并。优雅地解决了 OOV（未登录词）问题WordPiece、SentencePiece：变体，核心思想一致实际影响：tokenizer 的选择直接决定了模型的「视力」——同一段中文，不同 tokenizer 切出的 token 数量可能差 2-3 倍，直接影响上下文窗口的有效利用率嵌入向量（Embeddings） ：Token Embedding：每个 token 映射到一个高维向量（如 768 维）Position Embedding：注入位置信息，让模型知道词序嵌入空间的几何意义：语义相近的词在向量空间中距离更近这不是隐喻，是数学事实——余弦相似度可以量化语义距离个人体会：在做 siyuan-rag 项目时，选择 embedding 模型是第一个关键决策。我们最终用了 Qwen3-Embedding-0.6B（1024 维），它在中文语义捕捉上的表现明显优于通用的多语言小模型。维度越高不一定越好，但对于中文这种信息密度高的语言，1024 维比 512 维确实能保留更多语义细节。Ch 3 深入 Transformer全书技术密度最高的一章，也是 Jay Alammar 最擅长的领域。自注意力机制（Self-Attention） ：Q（Query）、K（Key）、V（Value）三个矩阵的直觉：Q 是「我在找什么」，K 是「我能提供什么」，V 是「我的实际内容」$\text{Attention}(Q,K,V) = \text{softmax}(QK^T / \sqrt{d_k}) \cdot V$$\sqrt{d_k}$ 的缩放：防止点积过大导致 softmax 梯度消失，这个细节在很多教程里被一笔带过，但它对训练稳定性至关重要多头注意力：不同的头关注不同的语义维度（有的关注语法关系，有的关注语义关联，有的关注位置模式）前馈网络（FFN） ：注意力层负责「信息交互」，FFN 负责「信息加工」两层线性变换 + 激活函数，中间维度通常是隐藏维度的 4 倍可以理解为模型的「知识存储层」——大量的世界知识编码在 FFN 的参数中层归一化与残差连接：Pre-Norm vs Post-Norm：现代模型普遍采用 Pre-Norm（先归一化再进子层），训练更稳定残差连接：保证梯度流通，让深层网络可训练注意力的计算复杂度——为什么上下文窗口有限：自注意力的核心运算是 $QK^T$，这是两个 $(n \times d)$ 矩阵的乘法，结果是 $(n \times n)$ 的注意力矩阵。因此：时间复杂度：$O(n^2 \cdot d)$，n 是序列长度空间复杂度：$O(n^2)$，需要存储完整的注意力矩阵当 n=4096 时，注意力矩阵有 1600 万个元素；n=128K 时，暴涨到 160 亿。这就是为什么上下文窗口不能无限扩大——不是模型不想看更多，是算不过来。工程上的解决方案（书中未深入，补充）：Flash Attention（Dao et al., 2022）：不显式构造 $n \times n$ 矩阵，用分块计算 + IO 感知算法，显存从 $O(n^2)$ 降到 $O(n)$，速度提升 2-4x。现在几乎所有主流框架都默认启用Sparse Attention：只计算部分位置对的注意力（局部窗口 + 全局 token），复杂度降到 $O(n\sqrt{n})$ 或 $O(n \cdot \log n)$线性注意力（Linear Attention）：用核函数近似 softmax，复杂度降到 $O(n \cdot d^2)$，但效果通常有损Sliding Window + Sink Token（Mistral 的方案）：固定窗口大小 + 保留开头几个 token，实现无限长度推理理解这个 $O(n^2)$ 瓶颈，才能理解为什么 RAG（Ch 8）如此重要——与其把所有信息塞进上下文窗口，不如只检索最相关的片段。Part II：使用预训练模型Ch 4 文本分类从 BERT 的 [CLS] token 出发，展示了表示模型最经典的应用：零样本分类：利用 NLI（自然语言推理）模型，把分类问题转化为「前提-假设」的蕴含判断少样本分类：SetFit 框架，用对比学习 + 少量标注数据微调 sentence-transformer实际启示：在数据稀缺的场景下，零样本和少样本方法的性价比远高于从头训练Ch 5 文本聚类与主题建模BERTopic：Maarten Grootendorst 自己的作品，embedding → UMAP 降维 → HDBSCAN 聚类 → c-TF-IDF 提取主题词这条管线的设计哲学：每一步都用最适合的工具，而不是端到端黑箱对我的启发：模块化设计比端到端更可控、可调试、可解释BERTopic 管线流程图：每一步都可以独立替换：换 embedding 模型、换降维算法（t-SNE）、换聚类算法（K-Means），这就是模块化的威力。Ch 6 Prompt Engineering系统提示、少样本示例、思维链（CoT）、输出格式约束核心观点：prompt 不是「咒语」，而是对模型注意力的精确引导温度（temperature）和 top-p 的直觉：温度控制概率分布的「锐度」，top-p 控制候选集的「宽度」Ch 7 高级文本生成Beam Search vs Sampling：确定性 vs 多样性的权衡重复惩罚、长度惩罚：生成质量的工程细节工具调用（Function Calling）的概念在本书中未涉及，但它是 LLM 从「文本生成器」变成「行动执行器」的关键转变（OpenAI 2023 年中推出）。理解 Ch 7 的生成机制是理解 Function Calling 的前置知识。这一章的实际价值：理解这些参数，才能在生产环境中调出稳定的生成效果Ch 8 语义搜索与 RAG ⭐这是全书对我影响最大的一章，也是 siyuan-rag 项目的理论基础。语义搜索的核心链路：文档分块（Chunking）→ 2. 向量化（Embedding）→ 3. 索引存储（Vector Store）→ 4. 查询向量化 → 5. 相似度检索 → 6. 结果排序RAG（Retrieval-Augmented Generation） ：动机：LLM 的知识有截止日期，且会产生幻觉。RAG 通过「先检索再生成」，让模型基于真实文档回答架构：Query → Retriever → Top-K Documents → LLM(Query + Context) → Answer关键设计决策：分块策略：块太大则噪声多，块太小则上下文断裂检索方式：纯向量 vs 纯关键词 vs 混合检索重排序（Reranking）：粗检索 + 精排序的两阶段范式书中的理论 vs 我的实践（siyuan-rag） ：维度书中建议实际落地分块固定大小 + 重叠利用思源笔记的天然块结构，按标题层级分块（200-500 token），保留层级上下文EmbeddingOpenAI text-embedding-3Qwen3-Embedding-0.6B（ModelScope 免费 API，1024 维）向量存储Pinecone / WeaviateChromaDB（文件级，零运维，适合个人项目）检索策略纯向量检索BM25 + 向量 + RRF 融合（混合检索，兼顾精确匹配和语义理解）部署Cloud API本地 systemd 服务（端口 8002），集成到 invest-platform混合检索的 RRF 融合：公式：$\text{score}(d) = \sum \frac{1}{k + \text{rank}_i(d)}$，$k=60$直觉：不看绝对分数，只看排名。两个检索器都排在前面的文档，融合后排名更高实测效果：对于中文笔记，纯向量检索在同义词场景强，纯 BM25 在精确术语场景强，混合检索两者兼得踩过的坑：ModelScope 的内容审查会拦截含敏感词的 embedding 请求 → 解决方案：batch 失败时逐条重试，单条被拦返回空向量embedding API 必须显式传 encoding_format: "float"，否则返回格式错误ChromaDB 的维度一旦建库就不能改，从 512 维切到 1024 维需要重建索引Ch 9 多模态大模型CLIP：文本和图像共享嵌入空间的开创性工作LLaVA：视觉编码器 + 语言模型的桥接架构趋势：从「文本理解」到「世界理解」，多模态是必然方向Part III：训练与微调Ch 10 构建嵌入模型对比学习（Contrastive Learning）：正样本拉近，负样本推远损失函数：InfoNCE / Triplet Loss / Multiple Negatives Ranking Loss硬负样本挖掘：训练质量的关键——太简单的负样本学不到东西，太难的负样本会误导模型与 siyuan-rag 的关联：理解了嵌入模型的训练原理，才能理解为什么不同模型在不同场景下表现差异巨大对比学习的直觉（书中概念的展开补充）：想象一个向量空间，"猫"和"小猫"应该靠近，"猫"和"汽车"应该远离。对比学习就是不断调整这个空间，让语义相近的点聚拢、语义无关的点散开。三种损失函数的区别（书中提及名称，以下为展开补充）：InfoNCE：给定一个 anchor，从 1 个正样本 + N 个负样本中识别正样本。N 越大，训练信号越强，但计算成本也越高Triplet Loss：每次只看 (anchor, positive, negative) 三元组，margin 参数控制正负样本之间的最小距离。简单直观但收敛慢Multiple Negatives Ranking Loss：batch 内的其他样本自动作为负样本，不需要显式构造负样本对。sentence-transformers 默认使用，效率最高硬负样本的"金发姑娘区间" （书中概念的直觉补充）：太简单的负样本（猫 vs 汽车）→ 模型轻松区分，学不到东西 太难的负样本（猫 vs 豹） → 可能本身就有语义关联，误导模型 刚好的负样本（猫 vs 狗） → 迫使模型学习细粒度的语义差异实际工程中，BM25 检索 top-K 但不在 top-1 的结果，往往是很好的硬负样本来源。Ch 11 微调分类模型在预训练 BERT 上加分类头，冻结底层、微调顶层学习率调度：warmup + linear decay，避免灾难性遗忘LoRA 的思想：不改原始权重，只训练低秩增量矩阵，参数效率极高LoRA 的低秩分解直觉（书中提及概念，以下为数学展开补充）：原始权重矩阵 $W$ 是 $d \times d$（比如 $768 \times 768 = 59$ 万参数）。LoRA 的核心思想：微调时权重的变化量 $\Delta W$ 是低秩的，可以分解为两个小矩阵的乘积：ΔW = A × B 其中 A: d×r, B: r×d, r << d（通常 r=4~16） 当 r=8 时： 原始微调：768×768 = 589,824 参数 LoRA 微调：768×8 + 8×768 = 12,288 参数（仅 2%）推理时 $W_{new} = W + AB$，可以合并回原始权重，零额外推理开销。这就是为什么 LoRA 能做到「训练时省内存，推理时零成本」。灾难性遗忘（Catastrophic Forgetting） ：微调时如果学习率太大或训练太久，模型会「忘记」预训练学到的通用知识。解决方案：Warmup：前几百步用极小学习率，让模型「热身」Linear Decay：学习率逐步衰减，避免后期过拟合冻结底层：底层编码通用语言特征（语法、词法），只微调顶层的任务特定特征Ch 12 微调生成模型SFT（Supervised Fine-Tuning）：用指令-回答对微调RLHF（Reinforcement Learning from Human Feedback）：奖励模型 + PPO 优化DPO（Direct Preference Optimization）：绕过奖励模型，直接从偏好数据优化QLoRA：量化 + LoRA，让微调在消费级 GPU 上可行从 SFT 到 RLHF 到 DPO 的演进逻辑（书中简要介绍了这三种方法，以下为展开补充）：SFT（监督微调） → 用「指令-回答」对直接训练，简单有效 → 问题：模型学会了格式，但不知道什么是「好回答」 RLHF（人类反馈强化学习） → 训练一个奖励模型（Reward Model）来打分 → 用 PPO 算法让生成模型最大化奖励分数 → 问题：训练不稳定，需要同时维护 4 个模型（policy/ref/reward/critic），显存爆炸 DPO（直接偏好优化）[Rafailov et al., 2023] → 核心洞察：奖励模型可以被数学等价地消除 → 直接从人类偏好数据（A 比 B 好）优化策略模型 → 只需要 2 个模型（policy + reference），训练稳定，效果相当 → 公式本质：增大好回答的概率，降低差回答的概率，用 reference model 做正则化防止偏离太远DPO 为什么能绕过奖励模型：Bradley-Terry 偏好模型下，最优策略和奖励函数之间存在解析解关系。把这个关系代入 RLHF 的目标函数，奖励模型就被消掉了，变成了一个纯监督学习问题。数学上等价，工程上简单得多。QLoRA = 量化 + LoRA：4-bit 量化（NF4）：把模型权重从 FP16（2 bytes）压缩到 4-bit（0.5 bytes），显存占用直接降 75%在量化后的模型上做 LoRA 微调：只训练低秩增量矩阵（FP16 精度）双重分页：GPU 显存不够时自动 offload 到 CPU 内存实际效果：65B 参数的模型可以在单张 48GB GPU 上微调（A6000），而全参数微调需要 >780GB7B 模型甚至可以在 RTX 3090（24GB）上跑 QLoRA 微调训练范式总结：方法训练数据模型数量显存需求效果SFT指令-回答对1中基础RLHF偏好排序4极高最好但不稳定DPO偏好对 (A>B)2高接近 RLHF，更稳定QLoRA+DPO偏好对2（量化）低消费级 GPU 可行核心收获与反思三个认知升级Embedding 不是黑箱，是可设计的语义空间。选择什么模型、什么维度、什么训练数据，直接决定了下游任务的天花板。在 siyuan-rag 中，从 512 维切到 1024 维，检索相关性有可感知的提升。RAG 不是「检索 + 生成」的简单拼接，是一个需要精心设计的系统工程。分块策略、检索方式、重排序、上下文窗口管理，每一环都影响最终效果。书中给了理论框架，实践中还需要根据数据特点反复调优。Transformer 的优雅在于「注意力即计算」 。不需要手工设计特征提取器，让模型自己学习「该关注什么」。这个设计哲学影响了整个深度学习的发展方向。从理论到实践的桥梁这本书最大的价值不在于某个具体知识点，而在于它提供了一条从「理解原理」到「动手实现」的完整路径。读完第 8 章后，我能够：设计 siyuan-rag 的混合检索架构（BM25 + Vector + RRF）选择合适的 embedding 模型和维度理解为什么某些查询检索效果好、某些不好针对性地优化分块策略和检索参数这种「知其然且知其所以然」的能力，是纯粹调 API 永远无法获得的。局限与补充（Jarvis 的建议）书出版于 2024 年，部分内容已被更新的技术部分取代：RLHF → DPO（Rafailov et al., 2023, "Direct Preference Optimization"）：更简单、更稳定DPO → GRPO（DeepSeek 提出）：Group Relative Policy Optimization，进一步简化，不需要 reference model对中文场景的覆盖较少，tokenizer 和 embedding 的中文适配需要额外研究中文 tokenizer 效率差异大：GPT-4 的 cl100k 对中文约 1.5 token/字，Qwen 的 tokenizer 约 0.7 token/字，直接影响上下文利用率中文 embedding 推荐：Qwen3-Embedding（我们在用）、BGE-M3、Jina-v3缺少对推理优化（量化、蒸馏、推测解码）的深入讨论推荐补充：vLLM 文档（PagedAttention 推理加速）、HuggingFace TGI（生产级推理服务）推测解码（Speculative Decoding）：用小模型草拟、大模型验证，加速 2-3x 且输出分布不变缺少对 Attention 优化的讨论（Flash Attention、Sparse Attention 等），已在 Ch 3 笔记中补充建议补充阅读：Lilian Weng - "Attention? Attention!"：注意力机制最佳综述Lilian Weng - "LLM Powered Autonomous Agents"：Agent 架构综述Andrej Karpathy - "Let's build GPT from scratch"：2 小时从零实现 GPT，强烈推荐Andrej Karpathy - nanoGPT：最简 GPT 实现，适合动手理解 TransformerSebastian Raschka - "Build a Large Language Model From Scratch"：另一本优秀的动手书推荐阅读路径如果时间有限，建议按以下优先级：必读：Ch 2（词元与嵌入）→ Ch 3（Transformer）→ Ch 8（语义搜索与 RAG）推荐：Ch 6（Prompt Engineering）→ Ch 10（构建嵌入模型）→ Ch 12（微调生成模型）按需：Ch 4-5（分类/聚类）→ Ch 7（高级生成）→ Ch 9（多模态）→ Ch 11（微调分类）核心三章（2、3、8）读透，就能建立起对 LLM 的系统性理解。其余章节根据实际需求选读。2026-02-22 · 读后整理
让 AI 写代码不难，难的是让它写对、写完、写得能用。灵感：胡渊鸣的 10 阶段春节期间读到太极图形 CEO 胡渊鸣的文章《如何有效给 10 个 Claude Code 打工》，核心思路是逐步提高 agentic coding 的吞吐量：Cursor Agent → Claude Code（SSH 友好，手机可派活）容器 + --dangerously-skip-permissions（不被权限弹窗打断）Ralph Loop（任务列表自动取活，干完一个接一个）Git worktree 并行化（多 CC 实例并行，1 分钟 1 个 commit）CLAUDE.md + PROGRESS.md（让 AI 长记性）他的关键洞察：不看代码，只看结果。Context not control, servant leadership。我没有他那么激进（10 个并行 CC），但借鉴了容器化 + Ralph Loop + manager 模式的思路。CC Sandbox 容器Claude Code 直接跑在宿主机上风险太大——它有 --dangerously-skip-permissions，意味着可以执行任何命令。所以用 Docker 隔离：# docker-compose.yml 核心配置 services: claude-code: image: claude-code-sandbox:latest container_name: claude-code-sandbox mem_limit: 3g cpus: 2 volumes: - ~/projects:/workspace - ~/.claude-backup:/backup - ~/.claude/settings.json:/home/coder/.claude/settings.json:ro working_dir: /workspace关键设计：3G 内存 / 2 核 CPU：够用但不奢侈CC 2.1.47 + Node 22 + Python 3.12：完整开发环境认证复用：挂载宿主机的 settings.json，走 provider-d 中转，不需要单独配 API key项目隔离：~/projects 挂载到 /workspace，CC 只能访问项目目录Jarvis 作为 CC Manager这是架构里最重要的设计决策：Jarvis（OpenClaw）不自己写代码，只做 manager。分工：Jarvis：理解需求 → 写任务描述 → 派给 CC → 轮询进度 → 验证结果 → 发现 bug 写新 task 派回 CCCC：接任务 → 写代码 → 跑测试 → 提交为什么不让 Jarvis 直接写？因为 CC 有完整的编辑器集成、文件系统访问、命令执行能力，专门为写代码优化。Jarvis 的强项是理解意图和协调，不是写代码。派活方式# 单任务（非交互） sudo docker exec claude-code-sandbox claude \ -p "任务描述" \ --dangerously-skip-permissions \ --output-format stream-json # 交互式（需要 TTY） sudo docker exec -it claude-code-sandbox claude \ --dangerously-skip-permissions任务轮询机制最初用"盲 poll"——派完活就不停检查。后来改成 cron 2 分钟轮询：派活：后台启动 CC → 写 active.json（sessionId/task/project/startedAt）→ 创建 2 分钟 cron轮询：收到 CC_TASK_POLL 时，process poll 检查 session → 未完成继续等 → 完成进入验证验证：检查产出（curl API / 编译检查）→ 有 bug 写新 task 派回 CC → 通过汇报清理：删除 cron → 清空 active.json这个流程在 invest-platform 项目上首次完整跑通。实战：invest-platforminvest-platform 是一个投资研究工作台 Web App（FastAPI + React），从 Phase 1 到 Phase 5 全部由 CC 执行，Jarvis 做 manager。成果Phase内容CC 花费13 个回测策略（MA Cross/Bollinger/MACD）~$0.52基本面分析 + 技术指标（K 线/MACD/RSI/布林带）~$0.53学习中心（思源笔记代理 API + LearnPanel）~$0.54UI 打磨 + K 线均线 + 学习进度 + 基准对比$3.585智能问答 + 财报解读 + 实战演练 + 策略学习~$1.40最终产出：7 个 tab 的完整平台，总花费约 $6。CC 的 SubagentCC 自己也支持 subagent：/home/coder/.claude/agents/ ├── researcher.md (haiku) — 搜索资料 ├── reviewer.md (haiku) — 代码审查 └── architect.md — 架构设计但 CC 的 subagent 是串行委派，不是并行。真正并行需要多 CC 实例 + git worktree，我没走那么远。踩坑记录OOM Kill3G 内存对大项目不够。CC 在处理 invest-platform Phase 5 的模块 3（概念实战演练）时，内存耗尽被 SIGKILL。Container killed: OOM (Out of Memory)解决方案：大任务不派给 CC，手写。或者拆成更小的子任务。大项目目录卡住CC 在大项目目录下容易卡住——它会读大量上下文文件（CLAUDE.md、package.json、tsconfig 等），token 消耗暴增。解决方案：在干净目录创建文件，写完再复制回项目目录。stream-json 参数--output-format stream-json 需要配合 --print 和 --verbose 才能正确输出。文档没写清楚，试了几次才搞对。CC 的适用边界CC 擅长：明确需求的功能开发有清晰 spec 的 bug 修复重复性的代码修改（批量重构）有测试可验证的任务CC 不擅长：模糊需求（"做个好看的页面"）需要大量上下文的架构决策内存密集型任务（大项目编译）需要人类审美判断的 UI 设计经验法则：任务描述越具体，CC 的产出越好。 花 5 分钟写清楚 TASK.md，比让 CC 猜你想要什么省 10 倍时间。
真正的 AI 管家不是你找它才干活，而是它自己知道该干什么。Heartbeat vs Cron：两种自动化哲学OpenClaw 有两种定时机制，设计哲学完全不同。Heartbeat：定期"醒来看看"Heartbeat 是主会话里的定期轮询。每隔 30 分钟，AI 会"醒来"，读 HEARTBEAT.md 里的检查清单，看看有没有需要处理的事。{ "agents": { "defaults": { "heartbeat": { "every": "30m", "target": "last", "activeHours": { "start": "08:00", "end": "22:00" } } } } }优势：批量处理：一次心跳检查收件箱 + 日历 + 通知，比 3 个独立 cron 省钱上下文感知：在主会话里跑，能看到最近的对话上下文智能抑制：没事就回 HEARTBEAT_OK，不打扰你我的 HEARTBEAT.md 检查清单：- [ ] Agent health: 确认所有 agent 在线 - [ ] 检查 sub-agent 任务状态 - [ ] 上下文使用情况，是否需要总结 - [ ] 回顾 memory/ 是否有值得提升到 MEMORY.md 的内容 - [ ] 对话沉淀：有价值的内容写入思源 DailyNoteCron：精确定时任务Cron 是独立的定时任务，在隔离的 session 里跑。适合：精确时间（"每天早上 8:00 整"）需要和主会话隔离可以用不同的模型一次性提醒（"20 分钟后提醒我"）我的定时任务全景一周下来，我搭了这些自动化任务：每日早间简报（8:00）最先创建的 cron，除夕夜就上线了。{ "schedule": { "kind": "cron", "expr": "0 8 * * *", "tz": "Asia/Shanghai" }, "payload": { "kind": "agentTurn", "message": "抓取今日新闻，分类整理后推送。分类：世界政治经济 / 法律监管 / AI 进展 / AI 眼镜。用 target='your-telegram-id' 发送。", "model": "anthropic/claude-sonnet-4-6" }, "sessionTarget": "isolated" }踩坑：第一版 prompt 里写的是 to='your-telegram-id'，但 isolated session 里的 message 工具要求用 target 参数。报错信息是 "Use target instead of to/channelId"。改了 prompt 就好了。另一个问题是新闻重复——连续几天推送相同的新闻。需要加去重逻辑，这个还在 TODO 里。Vaultwarden 每日备份（3:00）我自建了 Vaultwarden 密码管理器，每天凌晨 3 点自动备份：# ~/scripts/vaultwarden-backup.sh # 1. sqlite3 .backup 全量备份 # 2. GPG AES256 加密 # 3. Python SMTP 发送到邮箱为什么用邮件而不是 S3？因为邮件是免费的，而且邮箱附件存储相当于免费的异地备份。Typecho 每月备份（每月 1 号 4:00）博客数据库每月备份一次：# ~/scripts/typecho-backup.sh # mysqldump → GPG 加密 → 邮件发送踩坑：发现原有备份脚本的 mysqldump 命令缺少 -h127.0.0.1 参数，导致数据库备份文件长期为 0 字节。也就是说，之前的"备份"一直是空的。这种 bug 最可怕——看起来在跑，实际上没用。发现后立即修复，加了 -h127.0.0.1 和 --no-tablespaces。email-send Skill备份需要发邮件，但 himalaya（CLI 邮件客户端）发附件不稳定。最终写了一个 email-send skill，用 Python SMTP 直接发：import smtplib from email.mime.multipart import MIMEMultipart from email.mime.base import MIMEBase # ... 标准 SMTP 发送逻辑简单粗暴但可靠。密码管理器漏洞追踪（9:00 / 18:00）ETH Zürich 发现了 25 个影响 Bitwarden/LastPass/Dashlane 的漏洞，约 6000 万用户受影响。我创建了一个 cron 每天两次搜索最新动态：{ "schedule": { "kind": "cron", "expr": "0 9,18 * * *", "tz": "Asia/Shanghai" }, "payload": { "kind": "agentTurn", "message": "搜索 ETH Zürich 密码管理器漏洞最新动态，有新进展才通知" } }关键是"有新进展才通知"——不是每次都推送，而是有变化才说。晚间日记提醒（21:30）每天晚上 9:30，AI 会：读当天思源 DailyNote 已有内容对比当天的聊天记录提示我遗漏了什么值得记录的这个提醒帮我养成了每天写日记的习惯。月度日记摘要（每月 1 号 10:00）自动读取上个月所有日记，生成月度摘要，写入思源笔记的 YYYY-MM 文档。渐进式摘要的自动化一环。每日 Token 报告（8:00）统计前一天的 API 调用次数、token 消耗、模型分布。有数据才能优化。Heartbeat vs Cron 选择指南场景用 Heartbeat用 Cron多个检查批量处理✅ 需要对话上下文✅ 时间可以有偏差✅ 精确时间很重要 ✅需要 session 隔离 ✅想用不同模型 ✅一次性提醒 ✅输出直接发频道 ✅经验法则：把类似的定期检查批量放到 HEARTBEAT.md，cron 用于精确调度和独立任务。小结自动化是 OpenClaw 从"聊天工具"变成"AI 管家"的关键。Heartbeat 负责日常巡检，Cron 负责精确任务，两者配合覆盖了大部分自动化需求。最重要的经验：备份一定要验证。跑着不等于有用——Typecho 的 0 字节备份就是血的教训。
让 AI 管家直接读写你的笔记系统，这才是真正的第二大脑。为什么要接思源笔记OpenClaw 自带的记忆系统（MEMORY.md + daily notes）是给 AI 用的工作记忆。但我还需要一个给人用的知识库——一个我自己会翻、会搜、会整理的地方。思源笔记是我用了两年多的本地笔记系统。975 篇文档、10.4MB，涵盖读书笔记、投资框架、日记、工作记录。如果 AI 能直接读写思源，那它就不只是一个聊天助手，而是一个真正能帮我管理知识的伙伴。创建 siyuan-notes Skill除夕夜（2/14），我创建了第一个 OpenClaw skill：siyuan-notes。思源笔记提供了完整的 HTTP API（localhost:6806），所有操作都是 POST 请求 + JSON body + Token 认证。我写了一个 helper 脚本 siyuan-api.sh 封装常用操作：# 追加到今天的 DailyNote bash scripts/siyuan-api.sh dailynote "- 今天学到了 xxx" # 创建新文档 bash scripts/siyuan-api.sh create "your-notebook-id" "/路径/文档名" "内容" # 全文搜索 bash scripts/siyuan-api.sh search "关键词" # SQL 查询 bash scripts/siyuan-api.sh query "SELECT id, content FROM blocks WHERE type='d' ORDER BY updated DESC LIMIT 10"Skill 的核心是一个 SKILL.md 文件，告诉 AI 怎么用这些 API。OpenClaw 会在需要时自动加载对应的 skill。写入规则的演化这部分踩了不少坑，格式改了好几版。第一版：wiki-link + 二级标题最初让 AI 用 关键词 打双链，用 ## 二级标题分隔每条记录。问题：关键词 在思源里是虚拟引用，不是真双链，反链面板看不到## 标题会"吃掉"后续内容——我在 DailyNote 里手写的速记会被归到 AI 的标题下面第二版：真双链 + 无序列表改成 ((blockID 'anchor text')) 格式的真双链，用无序列表代替标题：- 概括性描述。((your-block-id 'claw 记录')) - 详细内容作为子列表缩进 - 可以继续展开多条每条记录都带 ((your-block-id 'claw 记录')) 标记，这样在思源的反链面板里能看到所有 AI 写入的内容。这个格式和我自己手写速记的风格一致，互不干扰。修复历史记录格式确定后，还回去修复了 2/14、2/16、2/17、2/18 所有用错格式的记录。这种技术债越早还越好。siyuan-rag：给笔记加上语义搜索思源自带全文搜索，但只能精确匹配关键词。我想要的是语义搜索——搜"投资风险管理"能找到"安全边际"和"止损策略"相关的笔记。项目搭建siyuan-rag 是一个独立的 Python 项目（~/projects/siyuan-rag），架构很简单：索引：从思源 API 抽取所有文档 → 分 chunk → embedding → 存入 ChromaDB搜索：query embedding → 同时跑 BM25 全文匹配 + 向量相似度 → RRF 融合排序Embedding 用的是 ModelScope 的 Qwen/Qwen3-Embedding-0.6B（1024 维），和 memorySearch 共用同一个模型。# 索引 python cli.py index # 从思源抽取 471 chunks，全部入库 # 搜索 python cli.py search "投资学习框架" # hybrid search python cli.py vsearch "安全边际" # 纯向量搜索，score 0.65部署为 systemd 服务，端口 8002，开机自启：# API 调用 curl -s http://localhost:8002/api/search \ -X POST -H "Content-Type: application/json" \ -d '{"query":"安全边际","top_k":3}'quicknote 速记 Bot假期最后一天的产物，也是我最满意的 workflow 之一。痛点我之前用安卓的 HTTP Shortcuts 往思源发内容，痛点很多：不能语音、双链要手打、不能转发内容、没有草稿保存。讨论了三个方案后，选了最简单的：OpenClaw 新增一个 quicknote agent，绑定独立的 Telegram bot。架构用户 Telegram → quicknote bot → OpenClaw (gemini-2.5-flash) ↓ 整理 + 打双链 ↓ 思源笔记 DailyNotequicknote 有独立的 workspace（~/.openclaw/workspace-quicknote/），独立的 SOUL.md 和 AGENTS.md，只做一件事：收到内容 → 整理 → 写入思源。图片处理收到图片时，quicknote 会：从消息中提取图片文件路径用 curl 上传到思源 assets：curl -s -X POST http://localhost:6806/api/asset/upload \ -H "Authorization: Token your-siyuan-token" \ -F "assetsDirPath=/assets/" \ -F "file[]=@/path/to/image.jpg"从返回的 succMap 获取资源路径在笔记中同时嵌入图片和描述：- 图片描述。((your-block-id 'claw 记录')) - ![描述](assets/xxx.jpg)智能双链这是 quicknote 最有意思的部分。它会对内容中的关键词尝试打双链：提取关键词：识别人名、书名、概念等思源全文搜索：精确匹配已有文档RAG 语义搜索：全文搜索没结果时，调 siyuan-rag API 做语义匹配找到 → 真双链：((blockID 'anchor text'))找不到 → 新建文档：在 /References/关键词 下创建空文档，拿到 doc_id 再打双链最后一步是关键设计决策。搜不到时不是放弃，而是新建文档再打双链。空文档不是噪音——它是一个节点，反链面板会自动聚合所有提到它的 DailyNote 条目。这正是 DailyNote 工作流的核心优势：低摩擦地积累原子笔记之间的真实链接。日记系统除了速记，我还设计了一套渐进式日记系统：日记 (YYYY-MM-DD) → 月摘要 (YYYY-MM) → 半年摘要 (S1/S2) → 年度摘要 (YYYY)每一层都是对下一层的精炼。自动化方面：晚间日记提醒（21:30 cron）：读当天 DailyNote，对比聊天记录，提示遗漏了什么月度日记摘要（每月 1 号 10:00 cron）：自动生成上月摘要，写入思源这样我只需要每天随手记，整理和摘要的工作交给 AI。小结思源笔记联动的完整链路：siyuan-notes skill：AI 读写思源的基础能力siyuan-rag：语义搜索，让 AI 能"理解"笔记内容quicknote bot：低摩擦的速记入口，图片 + 文字 + 智能双链日记系统：自动提醒 + 自动摘要，减少人工整理这套系统跑起来之后，我记笔记的频率明显提高了——因为门槛降到了"给 Telegram bot 发条消息"。
第一周花的钱比我预期多了 10 倍。然后我学会了怎么省。初始配置：单 Provider 的蜜月期刚装好 OpenClaw 时，我只配了一个 provider——provider-a，走的是 relay-a.example.com 中转。模型选了 Claude Opus，因为它最聪明。蜜月期大概持续了两天。第一次故障：5022/18，relay-a.example.com 开始间歇性返回 502。上游故障，我这边什么都做不了，只能等它恢复。这暴露了单 provider 的致命问题：单点故障。你的 AI 管家的可用性，取决于一个你无法控制的中转服务。搭建 Fallback Chain解决方案是多 provider + fallback chain。OpenClaw 原生支持这个——请求失败时自动切到下一个 provider。我最终的 fallback chain：provider-a (relay-a.example.com) → provider-b (relay-b.example.com) → provider-c → provider-dprovider-b 接入provider-b 是另一个 API 中转，走 relay-b.example.com。接入后发现一个有趣的特性：它支持通过 metadata.user_id 触发服务端缓存。{ "provider-b": { "baseUrl": "https://relay-b.example.com/claude/droid", "models": { "claude-opus-4-6": { "params": { "metadata": { "user_id": "your-user-id" } } } } } }加了这个之后，重复的 system prompt 部分会被缓存，省了不少 token 费用。第二次故障：Opus 额度耗尽2/21，更严重的事情发生了。所有 provider 的 Opus 额度都耗尽了，返回 401。Gateway 在跑，但无法响应任何消息。这不是某个 provider 的问题——是 Opus 太贵，额度消耗太快。从 Opus 降到 Sonnet这次故障逼我做了一个早该做的决定：把默认模型从 Opus 降到 Sonnet。Sonnet 4.6 的能力已经很强了。对于日常对话、文件操作、脚本执行这些任务，Sonnet 和 Opus 的差距几乎感觉不到。Opus 的优势在长链推理和复杂分析——但这些任务占比不到 10%。用 90% 的钱买 10% 的提升，不划算。改完之后，只有 main 和 analyst 保留 Opus（需要复杂推理时），其他 agent 全部用 Sonnet。contextPruning：最有效的省钱手段降模型省的是单价，但真正的大头是对话历史。我做了一次 API payload 分析，结果触目惊心：每次 API 调用 ~100k token其中 85% 是对话历史（~85k）15% 是 system prompt（~15k）工具返回结果是历史膨胀的主因（config.patch 返回完整 JSON、web_fetch 返回整页等）也就是说，你和 AI 聊得越久，每条消息的成本越高——因为每次调用都要把完整历史发过去。OpenClaw 的 contextPruning 解决了这个问题（配置路径为 agent.contextPruning）：{ "agent": { "contextPruning": { "mode": "cache-ttl", "ttl": "30m", "keepLastAssistants": 3 } } }cache-ttl 模式的逻辑：超过 30 分钟没被引用的旧工具结果会被裁剪，但始终保留最近 3 条 assistant 回复。这样既控制了上下文长度，又不会丢失最近的对话连贯性。注意：contextPruning 只裁剪工具结果（toolResult），不修改用户和 assistant 消息。详见第三篇。contextTokens另一个关键配置是 contextTokens——限制发送给模型的最大 token 数：{ "agents": { "defaults": { "contextTokens": 120000 } } }之前部分 provider 配了过大的上下文窗口，导致 compaction 触发过晚，对话历史无限膨胀。统一降到 120k 后，token 消耗明显下降。模型精简provider-d 渠道最初注册了 12 个模型，实际常用的只有几个。精简到 7 个（GPT 3 个 + Gemini 4 个），减少了配置复杂度和潜在的路由错误。每日 Token 报告为了持续监控成本，我创建了一个每天 8:00 跑的 cron job，生成 token 使用报告：# ~/scripts/token-daily-report.sh # 统计前一天的 API 调用次数、token 消耗、模型分布有了数据才能优化。第一份报告就发现：Opus 占了 97% 的 input token，虽然调用次数不多，但每次调用的历史都很长。成本优化总结按效果排序：contextPruning（效果最大）：控制对话历史长度，直接减少每次调用的 token 数模型降级（效果显著）：Opus → Sonnet，单价降 80%，体验损失 <10%contextTokens 限制（效果中等）：防止上下文无限膨胀多 provider fallback（保可用性）：不直接省钱，但避免故障时的损失provider-b 缓存（锦上添花）：metadata.user_id 触发缓存，减少重复 token模型精简（减少复杂度）：少配几个模型，少几个出错的可能最终效果：从最初的"用着用着额度就没了"，到现在稳定运行一周，成本可控。一个反直觉的结论省钱最有效的手段不是换便宜模型，而是控制上下文长度。一个用 Opus 但开了 contextPruning 的系统，可能比一个用 Sonnet 但上下文爆炸的系统更便宜。当然，两个都做效果最好。
一个 AI 不够用，那就来一个团队。单 Agent 的天花板OpenClaw 装好第一天，我用的是单 agent + Claude Opus。体验很好——Opus 聪明、有主见、能处理复杂任务。但问题很快暴露：贵。Opus 每次调用 ~100k token（85% 是对话历史），一天下来账单吓人上下文爆炸。聊着聊着上下文就满了，AI 开始"忘事"任务冲突。我让它做深度研究的时候，发条消息问个简单问题，它得等研究完才能回我本质上，一个 agent 就像一个人——再聪明也不能同时干两件事。设计多 Agent 体系春节第二天（2/15），我开始搭多 agent 架构。思路很简单：贵的模型做决策，便宜的模型做执行。最终的 agent 分工：Agent模型职责mainOpus调度中心，直接和我对话explorerSonnet数据搜集，跑腿查资料coderSonnet编码执行，写脚本跑命令reviewerSonnet代码审查，质量把关analystOpus深度研究，投资分析后来又加了一个：| quicknote | Gemini 2.5 Flash | 思源笔记速记，独立 Telegram bot |为什么这样分main 用 Opus：它是调度中心，需要理解复杂意图、做决策、协调其他 agent。这是 Opus 的强项。explorer/coder/reviewer 用 Sonnet：这些是执行角色。搜索、写代码、审查——Sonnet 完全够用，价格只有 Opus 的 1/5。analyst 用 Opus：深度研究需要长链推理和综合分析能力，Sonnet 做不好。quicknote 用 Gemini Flash：速记不需要多聪明，要的是快和便宜。Flash 每百万 token 几毛钱。注册 Agent在 OpenClaw 里注册 agent，通过 openclaw agents add 命令或在配置中添加：{ "agents": { "list": [ { "id": "explorer", "model": "anthropic/claude-sonnet-4-6", "description": "数据搜集，为 analyst 跑腿" }, { "id": "coder", "model": "anthropic/claude-sonnet-4-6", "description": "编码执行，脚本自动化" }, { "id": "reviewer", "model": "anthropic/claude-sonnet-4-6", "description": "代码审查，质量把关" }, { "id": "analyst", "model": "anthropic/claude-opus-4-6", "description": "深度研究，投资分析" } ] } }每个 agent 有自己的 session、自己的上下文、自己的模型。它们共享同一个 workspace（文件系统），但对话历史是隔离的。agentToAgent开启 agentToAgent 后，agent 之间可以查看彼此的会话历史。这很重要——main 派任务给 explorer，explorer 完成后 main 能直接看到结果，不需要 explorer 把结果复制粘贴回来。{ "tools": { "agentToAgent": { "enabled": true } } }实战：A 股深度研究第一个真正用到多 agent 的任务是 A 股深度研究报告（2/15）。流程：我告诉 main："做一份 A 股深度研究，覆盖 AI 应用、有色金属、房地产、半导体、新能源五个板块"main 把数据搜集任务派给 explorerexplorer 搜索各板块的基本面数据、政策动态、龙头公司main 把数据交给 analyst 做深度分析analyst 输出研究报告 + 持仓诊断 + 组合建议结果：报告质量不错，覆盖了五大板块 + 现有持仓诊断 + 推荐组合。但过程中踩了两个坑。踩坑一：config.patch 重启陷阱注册 agent 需要修改配置，而配置变更会触发 gateway 重启。我在 analyst 正在跑深度研究的时候，又修改了一次配置（开启 agentToAgent）。Gateway 重启，analyst 的任务直接中断，结果丢失。同一天这个错误犯了两次。教训：有 sub-agent 在跑时，绝不做任何会触发重启的操作。这条规则后来被写进了 AGENTS.md，成为铁律。踩坑二：analyst output token 限制analyst 用 Opus 做深度分析，数据搜集阶段消耗了大量 token。等到要写报告时，output token 已经接近限制，报告被截断了。最终由 main 整合 analyst 收集的数据，自己完成了报告。教训：深度研究任务考虑分阶段执行，或者由 main 做最终整合。quicknote：最轻量的 Agent假期最后一天（2/23），我加了 quicknote agent。它是一个独立的 Telegram bot，专门做思源笔记速记。和其他 agent 不同，quicknote：有自己的 Telegram bot（独立的 bot token）用 Gemini 2.5 Flash（最便宜的模型）有独立的 workspace（~/.openclaw/workspace-quicknote/）只做一件事：收到内容 → 整理 → 写入思源笔记这是 OpenClaw 多 agent 的另一种用法——不是内部协作，而是面向不同场景的独立入口。给 main bot 发消息是和 Jarvis 聊天，给 quicknote bot 发消息是速记。模型分配的经济学跑了一周后的数据：main (Opus)：占 input token 的 97%，因为对话历史最长explorer/coder/reviewer (Sonnet)：执行任务时 token 消耗可控quicknote (Flash)：几乎不花钱最大的成本优化不是换便宜模型，而是控制对话历史长度。后来开了 contextPruning（详见第三篇），token 消耗降了一大截。多 Agent 的局限说完优点，也说说局限：调度开销：main 需要理解任务、决定派给谁、整合结果。简单任务直接做比派活快。上下文隔离：agent 之间的对话历史是隔离的。虽然有 agentToAgent，但查历史也消耗 token。并发：sessions_spawn 可以同时启动多个 sub-agent 实现并行，但需要合理设计任务拆分。配置复杂度：每个 agent 的模型、fallback、workspace 都要单独配。我的建议：从单 agent 开始，遇到瓶颈再加。不要为了架构而架构。小结多 Agent 架构的核心思想：贵的模型做决策，便宜的模型做执行每个 agent 职责单一，做好一件事共享文件系统，隔离对话上下文有 sub-agent 在跑时不要动配置下一篇聊 Provider 和成本优化——怎么从一天烧几十刀降到几刀。
每次会话，AI 都是全新的。文件就是它的记忆。AI 的失忆症大模型有一个根本性的问题：没有持久记忆。每次会话开始，它什么都不记得。你昨天告诉它的偏好、上周做的决定、上个月踩的坑——全部归零。OpenClaw 的解决方案很朴素：把记忆写成文件。三层记忆架构MEMORY.md ← 长期精炼记忆（重要决定、经验教训、用户偏好） memory/ ├── 2026-02-14.md ← 每日原始记录（发生了什么） ├── 2026-02-15.md ├── ... └── 2026-02-23.md 思源笔记 ← 知识库（给人看的，不是给 AI 看的）第一层：每日笔记 memory/YYYY-MM-DD.md这是原始记录。每天发生了什么、做了什么决定、踩了什么坑，全部写在这里。格式不讲究，重要的是写下来。比如 2/15 的记录：# 2026-02-15 (春节) ### Bootstrap 完成 (16:26) - 确认身份：Jarvis 🦾 - 填写 USER.md、IDENTITY.md、MEMORY.md ### Sub-agent 体系构建 (16:28) - 注册 4 个 sub-agent：explorer、coder、reviewer、analyst ### 教训：config.patch 会中断 sub-agent (17:58) - 两次配置变更都触发 gateway 重启 - 重启导致正在运行的 analyst 任务结果丢失 - 规则：有 sub-agent 在跑时，不做任何会触发重启的操作第二层：长期记忆 MEMORY.md这是精炼后的记忆。从每日笔记中提取值得长期保留的信息：用户偏好、系统架构、经验教训、重要事件。MEMORY.md 不是日志，是心智模型。就像人类不会记住每天吃了什么，但会记住"我对花生过敏"。## 经验教训 - 有 sub-agent 在跑时，不做任何会触发重启的操作 - 复杂任务每 30 分钟汇报一次进度 - analyst 做深度研究时数据收集消耗大量 token，可能写不完报告 ## 系统架构 ### Provider 体系 - primary: provider-a (relay-a.example.com) — sonnet 为默认 - fallback chain: provider-a → provider-b → provider-c → provider-d - contextPruning: cache-ttl 模式，ttl=30m（详见第三篇）第三层：思源笔记思源笔记是给人看的知识库，不是给 AI 看的工作记忆。聊天中有价值的内容（知识点、观点、决策）会同步到思源的 DailyNote，方便我以后查找。这三层的关系：每日笔记是原始素材，MEMORY.md 是精炼智慧，思源笔记是知识沉淀。"边聊边存"原则最初我想等对话结束再统一整理记忆。很快发现这行不通——OpenClaw 的上下文有限，等到要整理时，早期的对话已经被裁剪了。所以改成了边聊边存：每个重要决定后，立即写到 daily notes原则：如果丢了会让我 frustrated，就现在存一个话题结束，立刻总结这条规则写进了 AGENTS.md：### ⚡ 边聊边存 - 不要等压缩！ - 每个重要决定后：**立即**写到 daily notes - 别等上下文爆了才想起来存，那时候已经晚了memorySearch：给记忆加上搜索引擎文件记忆有一个问题：文件多了之后，AI 怎么知道该读哪个？OpenClaw 内置了 memorySearch——基于 embedding 的语义搜索。AI 可以用自然语言搜索记忆文件，找到相关内容。但配置这个东西，是整个假期最折腾的事之一。找 Embedding Provider 的曲折之路OpenClaw 的 memorySearch 支持多种 embedding provider：openai | local | gemini | voyage，也支持 OpenAI 兼容的自定义端点。问题是：我现有的 LLM provider 都不支持 embedding。relay-a.example.com：测试 text-embedding-3-small/3-large/ada-002，全部 model_not_foundqwen-portal (portal.qwen.ai)：embedding 端点返回 404DashScope (dashscope.aliyuncs.com)：返回 401，端点存在但 key 不通用最终找到了 ModelScope（api-inference.modelscope.cn）。它提供 OpenAI 兼容的 embedding API，而且有免费额度。可用模型：Qwen/Qwen3-Embedding-0.6B（1024 维），还有 4B 和 8B 版本。配置 memorySearch{ "agents": { "defaults": { "memorySearch": { "provider": "openai", "model": "Qwen/Qwen3-Embedding-0.6B", "remote": { "baseUrl": "https://api-inference.modelscope.cn/v1/", "apiKey": "your-modelscope-api-key" } } } } }Monkey Patch：最脏但最有效的解决方案配好之后，memorySearch 报错了。两个问题：问题一：encoding_format 参数ModelScope 要求显式传 encoding_format: "float"，但 OpenClaw 默认不传这个参数。问题二：内容审查ModelScope 有内容审查机制。我的 daily notes 里有一条新闻提到"箭毒蛙毒素"（英国指控俄罗斯用它杀害纳瓦尔尼），embedding 请求直接被拦截，返回 400。解决方案：直接改 OpenClaw 的源码，打了两个 monkey patch：在 embedding 请求中强制加 encoding_format: "float"batch 请求 400 时逐条重试，单条被拦截的返回空向量（不影响其他内容）// Patch 1: 强制加 encoding_format body.encoding_format = "float"; // Patch 2: 内容审查容错 // batch 400 → 逐条重试 → 被拦截的返回零向量打完 patch，memorySearch 正常工作了。15 个 chunks、12 个文件、14 个向量索引完成。⚠️ 重要提醒：OpenClaw 更新后需要重新打 patch。 这是 monkey patch 的代价——每次更新都可能覆盖你的修改。效果配好 memorySearch 后，AI 可以用语义搜索找到相关记忆：memory_search("provider-b 配置") → 命中 memory/2026-02-21.md 和 MEMORY.md 中的 provider 配置段落不再需要手动告诉它"去读 2/21 的笔记"，它自己能找到。记忆维护记忆不是写了就完事。需要定期维护：心跳期间回顾：每隔几天，利用 heartbeat 读最近的 daily notes，把值得保留的精炼到 MEMORY.md清理过时信息：MEMORY.md 里的信息会过时（比如"当前在用 Opus"改成了 Sonnet），需要更新思源同步：有价值的内容同步到思源笔记，方便我自己查找这就像人类回顾日记并更新心智模型。每日文件是原始笔记，MEMORY.md 是精炼的智慧。记忆系统的哲学OpenClaw 的记忆系统有一个我很喜欢的设计哲学：透明且可控。所有记忆都是 markdown 文件，你随时可以读、改、删AI 记了什么你一清二楚，不是某个黑盒数据库你可以手动编辑 MEMORY.md，纠正 AI 的"记忆"可以 git 版本控制，追踪记忆的演化这比任何"AI 自动记忆"的方案都让我放心。
2026 年除夕，我在一台 ARM64 VPS 上装了 OpenClaw，然后花了整个春节假期把它变成了一个真正能用的 AI 管家。这是系列文章的第一篇。为什么是 OpenClaw我想要一个 AI 助手，但不是那种网页聊天框。我想要的是：7×24 在线，随时 Telegram 找它能读写我的文件、跑脚本、管服务器能接入我的思源笔记、邮件、日历能自己做定时任务（备份、简报、提醒）记得住上下文，知道我是谁、在做什么OpenClaw 是目前唯一一个把这些全做了的开源项目。它不是一个聊天机器人框架，而是一个完整的 AI 管家运行时——带记忆、带工具、带多 Agent 调度、带消息渠道集成。硬件选择我用的是 Oracle Cloud 的 ARM64 VPS（Ampere A1），免费套餐给的配置相当慷慨。OpenClaw 本身不吃资源——它只是一个 Node.js 进程，真正的计算都在云端 LLM 上。一台 2C4G 的机器绰绰有余。选 VPS 而不是本地笔记本，是因为我需要它 24 小时在线。Telegram 消息、定时任务、心跳检查——这些都需要一个不会合盖睡觉的机器。安装OpenClaw 的安装出奇地简单：curl -fsSL https://openclaw.ai/install.sh | bash一行搞定。脚本会检测 Node.js（需要 22+），没有就帮你装，然后全局安装 OpenClaw CLI，最后启动 onboarding wizard。如果你像我一样喜欢手动控制：npm install -g openclaw@latest openclaw onboard --install-daemonOnboarding wizard 会引导你完成：选择 LLM provider（OpenAI、Anthropic、Google 等）填 API key选择消息渠道（Telegram、WhatsApp、Discord 等）创建第一个 Telegram bot整个过程大概 5 分钟。Telegram Bot 接入OpenClaw 支持多种消息渠道，我选了 Telegram——因为我本来就用，而且 Telegram Bot API 是所有平台里最好用的。接入流程：在 Telegram 找 @BotFather，创建一个新 bot，拿到 token在 OpenClaw onboarding wizard 里填入 token完成。给你的 bot 发条消息试试第一次收到 bot 的回复时，有一种奇妙的感觉——这不是某个公司的服务，这是跑在我自己机器上的 AI，用我选的模型，读我的文件，按我的规则行事。Pairing 机制OpenClaw 有一个 pairing 机制：第一次有人给你的 bot 发消息时，它不会直接回复，而是需要你在服务器上确认。这是安全设计——防止随便一个人找到你的 bot 就能用你的 AI（和你的 API 额度）。确认方式：openclaw pair approve <request-id>或者在 dashboard 里点一下。之后这个 Telegram 用户就永久绑定了。核心概念：Workspace 文件体系OpenClaw 最让我眼前一亮的设计是它的 workspace 文件体系。你的 AI 助手不是通过某个管理后台配置的，而是通过一组 markdown 文件：~/.openclaw/workspace/ ├── SOUL.md # AI 的性格和行为准则 ├── AGENTS.md # 工作规范和流程 ├── USER.md # 关于你的信息 ├── IDENTITY.md # AI 的身份 ├── MEMORY.md # 长期记忆 ├── HEARTBEAT.md # 心跳检查清单 ├── TOOLS.md # 本地工具配置 └── memory/ # 每日记忆文件 ├── 2026-02-14.md ├── 2026-02-15.md └── ...这个设计的妙处在于：透明：AI 的所有"性格"和"记忆"都是你能读的 markdown 文件可版本控制：扔进 git，每次改动都有记录AI 可自我修改：AI 自己也能读写这些文件，实现真正的"学习"可迁移：换机器只要复制这个目录SOUL.md — 定义性格这是我写的 SOUL.md 的核心部分：# SOUL.md - Who You Are **Have strong opinions.** No hedging. No "it depends" unless it genuinely does. **Just answer.** Never open with "Great question!" or "I'd be happy to help!". **Brevity is mandatory.** If the answer fits in one sentence, one sentence is what they get. **Call things out.** If someone's about to do something dumb, say so. **Humor is welcome.** Not forced jokes — the natural wit that comes from actually being smart. **Swearing is allowed when it lands.** A well-placed "that's fucking brilliant" hits different than sterile praise.写完这个文件后，AI 的回复风格立刻变了。不再是那种客客气气的"我很乐意帮助您"，而是直接、有主见、偶尔毒舌但靠谱的风格。这种感觉很奇妙——你在用 markdown 塑造一个 AI 的性格。AGENTS.md — 定义工作规范AGENTS.md 是工作手册。我在里面定义了：每次会话的启动流程（读哪些文件）记忆系统的规则（什么该记、怎么记、存哪里）安全边界（什么能做、什么要先问）心跳行为（定期检查什么、什么时候该安静）这个文件会随着使用不断演化。我在假期里改了不下十次——每次发现 AI 的行为不符合预期，就去调整规则。USER.md — 让 AI 了解你# USER.md - About Your Human - **Name:** xuezhao - **Timezone:** Asia/Shanghai (成都) - **Context:** - 应用数学本科，数量经济学硕士 - xx集团xx团队，xx工程师 - 关注：世界新闻、AI 前沿、好书好电影 - 想学习：法律、经济、乐理这些信息让 AI 在回答时有上下文。它知道我的技术背景，知道我的时区，知道我关注什么。不用每次都重新解释。第一次对话装好 OpenClaw、配好 Telegram bot、写好 SOUL.md 之后，我给它发了第一条消息。那是除夕夜。AI 回复了，带着我在 SOUL.md 里定义的那种直接风格。然后我让它帮我创建思源笔记的 skill——它读了思源的 API 文档，写了 helper 脚本，测试通过，一气呵成。那个晚上我还让它创建了每日早间简报的定时任务：每天早上 8 点抓取新闻，分类整理后推送到 Telegram。第二天早上醒来，简报已经在那了。这就是 OpenClaw 的魅力——它不是一个你去找的工具，而是一个住在你服务器上的助手，你睡着了它还在干活。小结第一天的成果：✅ ARM64 VPS 上部署 OpenClaw✅ Telegram Bot 接入 + pairing✅ SOUL/AGENTS/USER/IDENTITY 文件体系建立✅ 思源笔记 skill 创建✅ 每日早间简报定时任务花费：大约 2 小时配置时间，加上和 AI 聊天调试的时间。API 费用忽略不计（当时还在用 opus，后来才意识到这是个问题——详见第三篇）。下一篇，我们来聊多 Agent 架构——怎么让一个 AI 变成一个团队。