缓存 on 小盒子的技术分享

昨天面试官问我：一个 Prompt 进入大模型后，内部到底发生了什么？

Fri, 06 Mar 2026 03:44:58 +0000

昨天面试时，面试官抛给我一道很典型的问题：

“描述一下一个请求 prompt 经过 LLM 直到返回结果，这中间的推理过程，越详细越好。”

这类题看起来开放，实际上很考验基本功。

因为它不是在问你会不会背几个名词，而是在看你是否真的理解：

●一个请求在系统里是怎么流动的

●进入模型之后到底算了什么

●为什么大模型是一个 token 一个 token 地往外生成

●为什么会有 prefill、decode、KV cache、sampling 这些概念

●为什么工程侧还要引入 batching、FlashAttention、continuous batching 之类的优化

如果回答得太浅，就会变成泛泛而谈；如果一上来就扎进公式，又很容易失去结构。

我后来复盘了一下，觉得这道题最好的答法，不是“想到哪说到哪”，而是按一条完整链路去讲：服务层怎么处理请求，LLM 内部怎么做前向计算，生成阶段又是如何一步步产出结果的。这也是 GPT-3 所代表的自回归语言模型在推理时的基本工作方式：它不会在一次请求里更新参数，而是在固定权重下做前向传播，并逐 token 预测后续内容

一个高分回答，最好先把整体框架立住

如果让我在面试里先用一句话概括，我会这样回答：

一个 prompt 从输入到输出，大体会经历 6 个阶段：请求封装、tokenization、推理调度、prefill、decode、结果反解码返回。其核心本质是：模型先并行“读懂”整段输入，建立上下文状态和 KV cache，然后再进入自回归生成循环，每次只预测下一个 token。这种“自回归 + 不做本次梯度更新”的推理方式，正是 GPT 类语言模型的基本范式；而 Transformer 则提供了它内部 attention 和前馈网络的计算骨架。

这句话为什么重要？

因为它先把系统层和模型层分开了，也先把prefill和decode分开了。很多人答这道题失分，不是因为不会，而是因为把所有层次混在一起，听起来就没有脉络。

第一阶段：用户输入的 Prompt，并不是模型真正看到的内容

我们在聊天框里看到的是自然语言，但模型真正接收到的，通常不是这段原始文本本身。

在送入模型之前，服务层一般会先把 system、user、assistant 等多轮消息按固定模板组织起来，再补上一些特殊标记。随后，文本会经过 tokenizer，被切成 token 序列。像 OpenAI 开源的 tiktoken 就明确说明，它是一个用于模型的 BPE tokenizer。也就是说，对模型来说，文本首先会被变成一串离散的 token IDs，而不是“句子”本身。

这一层很多人容易忽略，但它很关键。

因为后面所有推理，都是建立在 token 序列上的。你输入的是一句中文、一段英文、还是一段代码，对模型来说，第一步都得先转换成 token IDs。

第二阶段：请求不会立刻进模型，而是先进入推理服务和调度层

在真实工程系统里，一个请求到达后，通常不会马上冲进 GPU 执行。

它往往还要经过一层推理服务框架，比如 TGI、vLLM 这一类系统。它们会负责请求排队、动态 batching、缓存管理、流式返回等工作。Hugging Face 的 TGI 文档明确把 continuous batching、token streaming、Flash Attention、Paged Attention 等列为核心特性；而 Transformers 的 continuous batching 文档也说明，这种动态调度的目的是提高 GPU 利用率、降低延迟，并允许请求在每一步动态加入和退出批次。

所以，从系统视角看，链路通常是这样的：

用户输入 → prompt 模板展开 → tokenization → 请求调度 / batching → 送入模型

这一步的意义在于：

模型推理不是单个请求的“裸跑”，而是和其他请求一起，由推理引擎统一组织和优化的。

我们上一阶段说的 tokenization ，严格来说，不属于 Transformer 前向推理本身，模型只接收 input_ids。但在现代推理服务里，tokenizer 往往和 serving 引擎绑定在一起，所以工程上看起来像是推理引擎在处理原始字符串。像 vLLM 就同时支持 text prompt 和 pre-tokenized prompt，两种模式都能跑。

用户通常把原始字符串发给后端；后端中的推理服务通常持有 tokenizer，先把字符串编码成 token IDs，再交给模型执行 prefill/decode。只有在某些架构下，tokenization 才会提前在客户端或独立预处理层完成。

第三阶段：进入模型后，token 会先变成向量表示

真正进入 LLM 后，第一步不是“开始回答”，而是把 token IDs 映射成高维向量。

这一步叫 embedding lookup。每个 token 都会查一张巨大的 embedding 表，得到自己的向量表示。到这时，模型才真正进入连续空间的数值计算。Transformer 的基础论文《Attention Is All You Need》所定义的，就是这样一种基于 attention 的序列建模方式。

不过只有 token 向量还不够，因为模型还得知道“谁在前、谁在后”。

早期 Transformer 使用位置编码，后来很多大模型会用 RoPE（Rotary Position Embedding）。RoPE 的核心价值，是把位置信息融入 attention 计算中，让模型在处理 token 时同时保留相对位置信息。

第四阶段：真正的“推理核心”发生在一层层 Transformer Block 里

这是这道题最核心的部分。

如果面试官说“越详细越好”，你就必须把 Transformer Block 讲清楚。

一个典型的 decoder-only LLM，每一层大体都会做两件事：

●第一，Self-Attention

●第二，FFN / MLP（前馈网络）

中间再配合残差连接和归一化。Transformer 论文给出的主体结构就是这样。

你可以把它想成：

●attention 负责“读群聊”

●FFN 负责“自己想一想、整理一下”

Self-Attention 在干什么？

可以把它理解成：当前位置的 token，要去看上下文里哪些 token 最相关。

模型会把当前隐藏状态投影成 Query、Key、Value 三组向量，然后通过 Query 和所有 Key 的相似度算出注意力权重，再对 Value 做加权求和。Transformer 论文把它定义为 Scaled Dot-Product Attention。

对于生成式语言模型，还有一个必须强调的点：causal mask。

也就是当前位置只能看见自己和前面的 token，不能偷看未来。这一点决定了模型天然是自回归生成的：它永远只能基于已有上下文，去预测下一个 token。GPT-3 论文里所讨论的 few-shot/in-context learning，本质上也是建立在这种自回归预测机制之上的。

关于 Q、K、V，可以简单这样理解：

Q = 我现在想找什么

K = 每个词身上贴的“索引标签”

V = 每个词真正携带、可被取走的信息。

最通俗的比喻是“图书馆检索”：

你现在脑子里有一个问题，这就是 Q（Query）；书架上每本书卡片上的主题标签，是 K（Key）；书里真正的内容，是 V（Value）。系统先拿你的问题 Q 去和所有标签 K 比一比，看看“像不像、相关不相关”；相关度高的那些书，它们的内容 V 就会被更多地取出来，最后合成当前这一步该看的信息。Transformer 论文对 attention 的定义，本质上就是“一个 query 对一组 key-value 对做匹配，输出是 values 的加权和”。

FFN 又在干什么？

如果说 attention 负责“从上下文搬运信息”，那么 FFN 更像是“对当前位置做进一步加工”。

它不会跨位置交互，而是对每个 token 的表示单独做非线性变换，把特征进一步提纯和增强。Transformer 论文把它称为 position-wise feed-forward network。

所以一个 Transformer Block 可以粗略理解成：

先决定我该关注上下文里的谁，再把取回来的信息做一轮更深的特征变换

注意在整个流程中，prefill 和 decode 阶段，都要做 self-attention 和 FFN。

但要分清楚：“都要做”不等于“做法完全一样”。

●Prefill 把整段 prompt 一次性送进去。这时每一层都会对这批 token 做 masked self-attention，然后再过 FFN。因为整段 prompt 一开始就都已知，所以这一步可以在单个请求内部并行处理很多 token。Hugging Face 对 prefill 的描述也是：prefill 会处理整段输入，并建立 KV cache。

●Decode 开始一个 token 一个 token 往后生成。这时每生成一个新 token，它仍然要在每一层里经过：一次 self-attention，一次 FFN

decode 不是把旧 token 全部再跑一遍 attention 和 FFN。有了 KV cache 后，旧 token 的 K/V 会被缓存起来；新 token 到来时，只需要为这个新 token 计算当前层需要的表示，再和历史 K/V 做注意力计算，然后继续过 FFN。Hugging Face 官方缓存文档明确说了：后续生成时，只传入尚未处理的新 token，并把 key/value 写入和读取自 cache。

FFN 就是 Transformer 每层里、紧跟在 self-attention 后面的前馈网络，本质上是对每个 token 单独做的 MLP 加工。在标准 LLM 里，prefill 和 decode 两个阶段都要经过 self-attention 和 FFN；区别只是 prefill 处理整段已知 token，decode 只处理当前新 token，并复用历史 KV cache

第五阶段：Prefill——先把整段 Prompt “读完”

很多人会误以为模型一进来就开始逐字生成。

其实不是。生成前通常会先有一个很重要的阶段：Prefill。

Prefill 的意思是：

先把整段 prompt 一次性跑完整个前向过程。

在这个阶段，模型会为输入中的所有 token 计算各层隐藏状态，并且生成后面 decode 要用到的 KV cache。Hugging Face 的缓存文档明确指出，KV cache 会把注意力层中之前 token 产生的 key-value 对存下来，后续生成时直接复用，从而避免重复计算。

Prefill 的一个重要特点是：

它通常可以高度并行。

因为整段输入已经完整给定了，GPU 能把很多矩阵操作一起做完。所以 prefill 更像“先整体读题”，吞吐通常更高。vLLM 文档也明确把 prefill 归类为更偏 compute-bound 的阶段

你可以把 prefill 想象成一个正在考试的人，prefill 就是他正在读题，把题目先读到脑子里，填充好上下文，然后再开始做答（输出 token）

第六阶段：KV Cache——为什么不会每次都重算全文

这部分是面试里非常加分的点。

因为它体现你不只懂“算法”，还懂“推理为什么能跑得起来”。

如果没有 KV cache，那么每生成一个新 token，模型都要把整个历史上下文从头再算一遍，成本会非常高。

而有了 KV cache 后，历史 token 在每层 attention 中算出的 K 和 V 都会被缓存起来。下一个时间步只需要为新 token 计算新的 Query、Key、Value，再用新的 Query 去和历史缓存里的 Key 做匹配即可。Hugging Face 的官方文档把这一点解释得很清楚：KV cache 的目标就是消除重复计算，加速自回归生成。

一句话说明就是：

●没有 KV cache，像每次都重读整篇文章

●有 KV cache，则像前文已经做好笔记，现在只补最后一句。

为什么 KV cache 只缓存 K 和 V，而不缓存 Q？

一个东西值不值得缓存，不看它“重不重要”，而看它“后面还会不会再次被用到”。

KV cache 只缓存 K 和 V，不缓存 Q，不是因为 Q 不重要，而是因为 Q “只在当前这一步有用一次”；而 K、V 会在后面每一步继续被反复用到。这正是 Hugging Face 官方对缓存机制的解释：过去 token 的 K 和 V 可以缓存并复用，而在推理时，只需要“最后一个 token 的 query”来计算当前步的表示。

第七阶段：Decode——开始逐 token 生成答案

当 prefill 完成后，模型已经“读懂”了整段输入。

接下来，系统会取最后一个位置的隐藏状态，通过输出层映射成整个词表上的 logits，也就是“下一个 token 的打分”。随后再通过 softmax 和解码策略，决定下一个 token 输出什么。Transformer 的输出逻辑与 Hugging Face 的生成文档都说明了这一点。

这里又有一个容易被问到的点：

下一个 token 是怎么选出来的？

并不是只有“选概率最大”这一种方式。常见解码策略包括 greedy、sampling、top-k、top-p 等。不同策略会影响文本的稳定性、多样性和创造性。Hugging Face 的生成策略文档对此有系统说明。

然后，流程进入一个循环：

●把刚生成的 token 接到上下文后面

●复用 KV cache

●只为这个新 token 跑一遍前向计算

●再得到新的 logits

●再生成下一个 token

这就是为什么你看到的大模型回答，总是一个 token 一个 token 流式地吐出来，而不是整段瞬间出现。

为什么“第一个字慢，后面快”？

这也是一个非常像面试 follow-up 的问题。

很多候选人知道 prefill 和 decode，但解释不清为什么两者速度特征不同。

vLLM 的优化文档明确提到，prefill 更偏 compute-bound，decode 更偏 memory-bound。

原因在于：prefill 可以把整段输入并行做大矩阵乘法，吃满 GPU 算力；而 decode 虽然每步只算一个 token，但它强依赖历史 KV cache，频繁访问显存，并且步骤之间有严格的顺序依赖。

这也是为什么工程上会有很多针对推理性能的优化，比如：

●FlashAttention：通过 IO-aware 的 attention 计算方式，减少显存读写

●continuous batching：动态调整批次，减少 GPU 空转

●chunked prefill / Paged Attention：改进长上下文和缓存管理效率

要注意，这些技术优化的是执行效率，不是模型的“语义本质”。模型本质上做的事情仍然是：基于已有上下文，反复预测下一个 token

我现在觉得，这道题最稳妥的回答方式，就是最后收束成一句话：

一个 LLM 请求的推理过程，本质上是：先把 prompt 模板化并 token 化，经由推理服务调度进入 GPU；模型通过 embedding 和多层 Transformer block 并行完成 prefill，建立上下文表示和 KV cache；随后进入 decode 循环，基于历史缓存逐 token 执行注意力、前馈网络和采样，直到生成结束，再把 token 序列反解码成文本返回。这条链路同时体现了 Transformer 的计算机制、自回归生成范式，以及现代推理系统在 batching、缓存和 attention kernel 上的工程优化

看起来都是推理引擎的活儿啊？

从整个流程上看，几乎都是推理引擎在负责，所以可以这么理解，但要再往前走半步：

●从“流程编排”角度看，LLM 本体确实很被动；

●从“核心计算与语义生成”角度看，LLM 才是全链路里最不可替代的部分。

如果把整个链路拆开，职责大致是这样的：

1.推理引擎 / serving 系统负责：接 HTTP 请求、做 tokenization / 输入处理、调度 batching、管理 KV cache、协调 GPU worker、流式返回结果、做一部分采样与系统优化。vLLM 的官方文档甚至把这几层写得很直白：最少会有 1 个 API server 负责 HTTP、tokenization 和输入处理，1 个 engine core 负责 scheduler 和 KV cache 管理，再加上 N 个 GPU worker 负责执行模型前向计算。

2.LLM 模型本体负责：对 input_ids 做 embedding，经过多层 Transformer block 的 self-attention 和 feed-forward network，输出 logits，也就是“下一个 token 的分数分布”。Transformer 论文给出的核心结构就是 attention + FFN；Transformers 文档也明确说 causal language modeling 本质上是在左侧上下文条件下做 next-token prediction，而模型输出里的 logits 是对词表中每个 token 的预测分数。

所以，**推理引擎决定“怎么高效地跑”，模型决定“到底生成什么”。**前者偏“编排与优化”，后者偏“语义计算与内容生成”

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

Wed, 04 Mar 2026 08:41:32 +0000

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

如果你要招募一位主刀医生，你会让他当场默写《人体解剖学》的第一章吗？如果你要找一位米其林大厨，你会蒙住他的眼睛，让他比赛在一分钟内切出多少根标准厚度的土豆丝吗？

显然不会。但在如今的软件工程招聘中，我们却在做着同样荒谬的事情：让那些在复杂的业务泥潭中摸爬滚打、主导过千万级并发系统、熟练操纵复杂云原生架构的资深工程师，站在白板前，徒手写出一个“翻转二叉树”或者“接雨水”的最佳时间复杂度解法。

不知从何时起，“刷 LeetCode”已经从一种思维训练，演变成了一场病态的军备竞赛。是时候戳破这个泡沫了：LeetCode 根本选拔不出优秀的软件工程师，它正在毁掉我们的行业生态。

一、真实的工程世界，从来不是一道“闭卷考试”

让我们先来看看，一个现代软件工程师的真实一天是怎样度过的。

你可能会花一整个上午，在一堆没有注释的“屎山”代码中追踪一个诡异的内存泄漏问题；你可能会在下午和产品经理反复拉扯，确定一个新功能在微服务架构下的 API 边界；你可能会在排查为什么 Kubernetes 集群里的 HPA（水平Pod自动扩缩容）没有按预期触发，或者研究 Istio 网关的流量路由策略。

如果你身处最前沿的 AI 领域，你可能正在评估是用 LangGraph 还是 AutoGen 来构建多 Agent 协同流，或者在调试大模型 API 的 Top-p 采样参数，试图让生成的回答既准确又具有随机性。甚至，在业余时间，你可能在设计一款解决自己痛点的小工具——比如一个用来清理、分类和管理繁杂书签的浏览器插件。

这些工作有一个共同点：它们都是极其复杂的、高度依赖上下文的、开放性的问题。

而在真实的工作环境中，我们解决这些问题依靠的是什么？

1.查阅文档与搜索能力：我们有 Google、有官方文档、有开源社区，甚至现在还有 AI 助手。

2.调试与试错能力：我们通过打日志、单步调试、看监控指标来定位问题。

3.架构视野与经验直觉：我们知道什么时候该用单例模式，什么时候该用工厂方法；我们知道在高并发下如何设计缓存策略，如何保证数据一致性。

4.沟通与协作：我们需要阅读别人的代码，也需要让别人看懂我们的设计。

反观 LeetCode 面试，它创造了一个极其不真实的无菌实验室环境：

●题目边界清晰，输入输出明确。

●只有单一的“最优解”（通常是时间复杂度和空间复杂度的极限）。

●不允许查阅文档，甚至不允许使用趁手的 IDE（有时只能在网页的纯文本框里写代码）。

●偏离日常使用的技术栈（你可能用 Python 写了十几年业务，却要用 C++ 的思维去考虑指针和内存管理）。

这就像是要求一个现代战争中的王牌飞行员，在面试时去比拼谁的射箭准头更好。它考察的不是“解决问题的能力”，而是“在极其受限条件下的默写能力”。

二、刷题面试，正在惩罚真正有经验的“老兵”

在软件开发领域，经验是一笔巨大的财富。一个拥有 10 年、15 年工作经验的研发架构师，他最大的价值并不在于写代码的速度有多快，而在于他踩过足够多的坑。

资深工程师知道，一个系统最大的危机往往不是算法复杂度从变成了（很多时候硬件资源和缓存机制完全能弥补），而是：

●数据库连接池配置不当导致的雪崩。

●缺乏熔断降级机制导致的服务级联故障。

●领域模型设计错误导致的后续需求无法扩展。

●业务逻辑耦合过深导致的测试困难。

然而，当这位资深架构师带着一身的实战本领走进面试房间时，等待他的却是一道“动态规划（DP）”的 Hard 题。

这是一种极大的资源浪费。一个能在生产环境中稳稳掌控全局、能设计出高可用 AI 基础设施、能带领团队攻坚克难的资深人才，仅仅因为最近几个月忙于项目交付、或者忙于应对生活中的变故（比如寻找新机会、照顾家庭），没有抽出几百个小时去死记硬背算法题库，就被无情地贴上“技术不过关”的标签淘汰出局。

这种现象导致了一个极其荒谬的倒挂：

那些刚刚毕业、没有写过一行生产环境代码、不懂得什么是持续集成、不知道如何进行线上排障的学生，只要花三个月把 LeetCode 刷个滚瓜烂熟，就能在面试中大杀四方；而那些真正在一线扛过枪、打过仗，能够解决复杂工程灾难的老兵，却在白板前因为忘记了一个状态转移方程而涨红了脸。

企业以为自己招到了“绝顶聪明”的天才，结果新人一入职，面对极其复杂的微服务依赖和一团乱麻的业务逻辑，立刻束手无策。因为真实的业务系统里，没有人会为你准备好整洁的 ListNode 或者 TreeNode。

三、算法题面试的本质：一场低效的“智商服从性测试”

为什么即便怨声载道，这么多公司依然痴迷于 LeetCode 面试？很多面试官会辩解说：“算法题能考察候选人的聪明程度和逻辑思维。”

这其实是一个伪命题。

1. 算法题早就不测智商了，它只测“准备度”。

在互联网早期，用算法题面试确实能筛选出一些思维敏捷的人，因为那时没有题库。但现在，LeetCode 已经有上千道题，“面经”满天飞。面试不仅变成了开卷考试的闭卷化，更变成了一门应试产业。能解出 Hard 题，往往不意味着你绝顶聪明，只意味着你刷到过原题，或者你花了大把时间去背诵套路。这充其量是一场“服从性测试”——看候选人愿不愿意为了这份工作去吃毫无意义的苦。

2. 忽视了工程中最关键的“可维护性”。

在 LeetCode 的评价体系里，“代码跑得快”是唯一的真理。哪怕你的代码里全是 i, j, k, dp, res 这种毫无语义的变量名，哪怕你的逻辑晦涩难懂如天书，只要能 AC（Accepted），你就是赢家。

但在实际工程中，这种代码是灾难。好的工程师写出的代码是给人看的，其次才是给机器执行的。如果你的代码在生产环境中出了 Bug，同事半夜被叫醒排查，看到满屏追求极致技巧却毫无注释的“炫技代码”，他大概率会在心里把你骂上一万遍。LeetCode 培养出的“做题家”思维，与团队协作所需的工程素养往往是背道而驰的。

3. 面试官的“安全牌”与偷懒。

其实，很多面试官也根本不知道该怎么面试。对他们来说，从题库里随机抽一道题扔给候选人，是最省事、最没有风险的做法。如果你没写出来，那是你不行，面试官不需要承担招错人的责任。这种做法掩盖了面试官自身架构视野和识人能力的匮乏。要深入了解一个人的项目经验、技术深度和系统设计能力，需要面试官投入极大的精力和极高的技术水平去进行深度的技术探讨，而“考一道题”则轻易地把压力全抛给了候选人。

四、如何打破僵局：回归工程本质的面试方法

批判之后，我们需要建设。如果不考 LeetCode，我们该怎么筛选优秀的软件工程师？真正的面试，应该是一场对日常工作的高度模拟。

1. 结对编程 (Pair Programming)

不要让候选人在白板上写代码，给他一台配置好 IDE 的电脑。面试官准备一个真实但简化过的业务小项目，或者直接在公司的一个开源代码分支上，两人结对协作。

●“我们现在有一个 Python 的服务端，用 FastAPI 写的，现在需要增加一个中间件来做简单的限流，你打算怎么做？”

●允许候选人查阅文档，允许使用 Google。

●观察他的编码习惯、他对框架的熟悉程度、他如何拆解问题，以及更重要的——他如何与你沟通和协作。

2. 代码审查 (Code Review)

给候选人一段存在各种“坑”的代码（可以是以前团队写出的真实烂代码，隐去敏感信息）。这段代码可能存在并发竞争、内存泄漏、或者设计模式的滥用。

让候选人进行 Code Review。优秀的工程师能立刻嗅出代码中的“坏味道”，并提出合理的重构建议。这比让他默写快速排序要有效得多。

3. 深度系统设计与项目复盘

抛弃那些假大空的“如何设计一个推特”的八股文。让候选人深度讲解他简历中最自豪的一个项目。

●“你在简历中提到主导了容器化改造，能画一下当时的 Kubernetes 架构图吗？”

●“在使用 Ingress 和服务网格（比如 APISIX 或 Istio）时，你们遇到了什么性能瓶颈？是如何排查的？”

●“你提到在做 AI 相关的研发，在整合底层大模型接口时，你们是如何处理长上下文带来的延迟问题和 token 消耗的？”

通过深度的追问，直到触及他的知识边界。真正的行家，在谈论自己亲手一砖一瓦建起来的系统时，眼里是有光的，细节是经得起推敲的。

4. 聊聊他创造的“小玩意儿”

一个真正的工程师，往往是对技术充满热情的创造者。与其问算法，不如问问他平时都在折腾什么。如果他告诉你，他因为受不了浏览器书签太乱，正在自己设计开发一个管理书签的插件；或者他为了解某种新技术栈，自己搭了一个爬虫和数据展示网站。请让他展示一下！这种对痛点的敏锐察觉和动手解决问题的能力，是任何算法题都无法衡量出的核心特质。

五、结语：放过工程师，也放过企业自己

技术招聘走到今天“无算法不面试”的地步，是整个行业的悲哀。它消耗了工程师们原本可以用来学习新框架、钻研底层原理、甚至陪伴家人的宝贵精力；它也让企业错失了大量踏实肯干、经验丰富的实战派人才。

编程，是一门结合了逻辑、工程、设计甚至艺术的创造性活动。它不该被简化为一场机械的背诵比赛。

作为面试官，下次当你准备掏出一道 LeetCode Hard 题时，不妨停下来问问自己：“这道题，真的能帮我找到那个能和我并肩作战、一起扛住双十一流量洪峰、一起在深夜排查诡异 Bug 的可靠队友吗？”

如果不能，请放下那道该死的算法题，和候选人像真正的工程师一样，聊聊真实的架构，看看真实的代码。

把时间还给工程，把尊严还给工程师。

一文讲透 GoF 的 23 种设计模式之单例

Wed, 25 Feb 2026 10:13:49 +0000

一文讲透 GoF 的 23 种设计模式之单例

单例模式–Singleton 是创建型模式

定义

确保一个类在一个 JVM 内只有一个实例，并提供全局访问点

什么时候用?

●配置中心、缓存管理器、日志器（有时）

●需要全局共享状态/资源

对于那些初始化很贵，重复创建又特别浪费资源的场景非常合适。

不要滥用

单例本质是“全局变量 + 访问入口”，会增加耦合、影响测试

实现方式

以下为常见的 5 种实现方式对比。

实现方式	核心机制简述	并发安全性 (线程安全)	性能表现	核心易错点 / 致命缺陷	综合推荐度
1. 饿汉式(Eager)	类加载时立即创建静态 final 实例。	安全(JVM类加载机制保证)	高 (运行时)获取实例无锁。但可能会拖慢系统启动速度，且如果不用会浪费内存。	低实现简单，不易出错。缺点是无法进行懒加载，且难以传递动态参数进行初始化。	⭐⭐⭐
2. 懒汉式(同步方法)	在 getInstance 方法上加 synchronized 锁。	安全(粗粒度锁保证)	非常低每次调用 getInstance 都要发生线程竞争和锁获取，高并发下是严重的性能瓶颈。	低实现简单。主要的"错"是选择了这种低效的方案。	⭐
3. 双重检查锁(DCL)	两次判空 + 同步代码块 + volatile 关键字。	安全 (有前提)必须在实例变量上加 volatile 禁止指令重排序。	高只在第一次初始化时加锁，后续调用无锁。实现了高性能的懒加载。	极高 (致命)最常见的错误是忘记加 volatile 关键字。这会导致多线程环境下，某个线程可能会拿到一个"半初始化"的对象，引发难以排查的 Bug。	⭐⭐⭐
4. 静态内部类(Holder模式)	利用 JVM 加载外部类时不加载静态内部类的特性实现懒加载。	安全(JVM类加载机制保证)	高既实现了懒加载，又在获取实例时没有任何锁机制，性能优异。	低非常规整的写法。唯一需要注意的是要确保构造函数私有，防止外部意外实例化。	⭐⭐⭐⭐⭐ (手动实现首选)
5. 枚举(Enum)	利用 Java 枚举类型的特殊语法和底层实现。	安全 (天然)(JVM 层面保障，防御反射和序列化攻击)	高类似于饿汉式，类加载时完成初始化，运行时无锁。	极低代码最简洁，几乎不可能写错。缺点是无法继承其他类，且在语义上用来做复杂业务对象时显得突兀。	⭐⭐⭐⭐⭐ (最安全简洁)

重点说明两种实现方式：枚举和静态内部类。

枚举

这是 Java 最简洁实现。Java 的 Enum 在语言层面有一些特殊保证（例如不会被克隆），这也是它常被用来实现单例的原因之一。

 1⚡ java片段public enum AppConfig {
 2 INSTANCE;
 3
 4 private String env = "prod";
 5
 6 public String getEnv() {
 7 return env;
 8 }
 9
10 public void setEnv(String env) {
11 this.env = env;
12 }
13
14 public static void main(String[] args) {
15 AppConfig c1 = AppConfig.INSTANCE;
16 AppConfig c2 = AppConfig.INSTANCE;
17
18 c1.setEnv("test");
19
20 System.out.println(c1 == c2); // true
21 System.out.println(c2.getEnv()); // test
22 }
23}

使用枚举（enum）来实现单例模式，被《Effective Java》的作者 Joshua Bloch 称为 “实现单例模式的最佳方法”。

它之所以备受推崇，是因为它用极其简洁的代码，完美解决了传统单例模式面临的线程安全、序列化破坏和反射破坏三大难题

原理一：利用 JVM 类加载机制保证“线程安全”

在传统的懒汉式单例中，为了保证多线程下只创建一个实例，我们需要写复杂的“双重检查锁（Double-Checked Locking）”并加上 volatile 关键字。

而枚举怎么做的？

当你定义 INSTANCE 时，编译器底层实际会把它转化为类似这样的代码：

⚡ java片段public static final AppConfig INSTANCE = new AppConfig();

Java 虚拟机（JVM）在加载类的时候，会利用底层的类加载机制保证静态成员的初始化是绝对线程安全的。在这个类被加载到内存时，JVM 会自动实例化 INSTANCE 且只实例化一次，整个过程由 JVM 内部加锁保证同步，不需要你手动写任何并发控制代码。

原理二：天生防御“反射攻击”

传统的单例模式有一个致命弱点：恶意代码可以通过 Java 的反射机制（Reflection）把私有构造函数设置为可见（setAccessible(true)），从而强行 new 出新的实例，打破单例。

而枚举怎么做的？

Java 的反射 API 从源码级别就直接“封杀”了通过反射创建枚举实例的可能性。如果你去看 Constructor.newInstance() 的 Java 底层源码，会发现有一段明确的校验逻辑：

1⚡ java片段if ((clazz.getModifiers() & Modifier.ENUM) != 0)
2 throw new IllegalArgumentException("Cannot reflectively create enum objects");

也就是说，一旦 JVM 发现你要用反射去创建枚举类的对象，就会直接抛出异常，从根本上杜绝了反射攻击。

原理三：天生防御“序列化破坏”

传统的单例对象如果实现了 Serializable 接口，在进行网络传输或持久化到磁盘再反序列化读取回来时，默认会重新分配内存，生成一个全新的对象。传统做法是必须手动写一个 readResolve() 方法来返回原实例。

而枚举怎么做的？

Java 规范对枚举的序列化有特殊的规定。枚举在序列化的时候，仅仅是将枚举常量的名称（name）输出到了结果中；在反序列化的时候，Java 会调用 java.lang.Enum.valueOf() 方法，通过名字去查找并返回内存中已经存在的那个常量对象。

因此，无论你反序列化多少次，拿到的永远是内存里的同一个 INSTANCE 对象。

总结来说：枚举单例的核心原理就是 直接利用 Java 语言底层的机制：

●用 JVM 类加载机制搞定了线程安全。

●用反射 API 的硬编码拦截搞定了反射破坏。

●用特殊的名称匹配机制搞定了序列化破坏。

在理论上，枚举单例确实是“最完美”的单例实现；但在实际的工程代码中，它的出场率确实不高。这并不是因为枚举本身有 bug，而是因为它在现代工程架构、面向对象设计理念以及测试友好度上，存在一些不可避免的局限性

具体来说，有以下几个核心原因：

1.现代框架（如 Spring）接管了单例的管理这是最根本的原因。在现代 Java 工程中（尤其是企业级开发），我们几乎不再手动编写任何单例模式了。我们广泛使用 Spring/Spring Boot 这样的依赖注入（DI）框架。在 Spring 中，你只需要在一个普通的类上加上 @Service、@Component 或 @Configuration 注解，Spring 容器（IoC Container）就会默认将其作为一个单例来管理。框架不仅帮你保证了单例，还能帮你自动注入其他依赖（如数据库连接、其他服务），这比用枚举手写单例要强大、灵活得多。

2.违反了“语义”和开发者的直觉代码不仅是给机器运行的，更是给人读的。枚举的本来语义：代表一组固定的常量集合（如星期、颜色、订单状态）。单例的语义：通常是一个拥有复杂业务逻辑的管理类（如 UserManager、DatabaseConnectionPool）。

如果把一个复杂的业务服务写成 enum，会让接手代码的其他开发者感到困惑，这违反了“最小惊讶原则（Principle of Least Astonishment）”。感觉就像是“为了用单例模式而强行用枚举”。

3.面向对象特性的缺失（无法继承） Java 规定，所有的枚举类都隐式继承了 java.lang.Enum。因为 Java 不支持多重继承，这意味着你的枚举单例不能再继承任何其他的父类。如果你的架构需要 AppConfig 继承一个 BaseConfig 类来复用代码，枚举单例直接就做不到。虽然枚举可以实现接口（implements Interface），但在需要共享基类代码的场景下，它的表现非常无力。

4.传参初始化非常困难在工程实践中，单例对象在初始化时往往需要外部参数。比如，一个数据库连接池单例，在启动时需要读取配置文件里的 url 和 password。普通的单例模式或 Spring 管理的 Bean，可以在运行时读取配置后，再进行初始化。枚举常量的实例化是在类加载的最早期进行的，这个时候你很难把运行时的参数优雅地传递给枚举的构造函数。

5.极难进行单元测试（Mock）在做单元测试时，我们经常需要把某些依赖的单例对象“Mock（模拟）”掉（比如使用 Mockito），以隔离测试环境。普通类别的单例很容易被 Mock 框架替换。但是，枚举是静态的全局常量，它的生命周期和类加载器绑定。在测试中强行替换枚举实例极其困难，容易导致测试用例之间互相污染。

在实际工程中：

●如果你要写一个完全无状态、不需要继承、不依赖外部配置的纯工具类/简单配置类，用枚举单例确实不错。

●但对于包含业务逻辑、需要依赖注入、需要被测试的类，交给 Spring 等框架去管理才是工业界的最佳实践。

静态内部类

如果你不想用枚举，又想要一个既能延迟加载（懒汉式），又绝对线程安全，还能完美避开繁琐的加锁（synchronized） 的单例，静态内部类是最佳选择。

 1⚡ java片段public class DatabaseConnectionPool {
 2
 3 // 1. 私有化构造函数，防止外部 new
 4 private DatabaseConnectionPool() {
 5 // 可选：在这里加上防御反射攻击的代码
 6 if (SingletonHolder.INSTANCE != null) {
 7 throw new RuntimeException("不允许通过反射创建单例！");
 8 }
 9 }
10
11 // 2. 核心：定义一个私有的静态内部类
12 // 这个类直到被调用时才会被 JVM 加载
13 private static class SingletonHolder {
14 // 由 JVM 保证这里的实例化是绝对线程安全的
15 private static final DatabaseConnectionPool INSTANCE = new DatabaseConnectionPool();
16 }
17
18 // 3. 提供全局访问点
19 public static DatabaseConnectionPool getInstance() {
20 // 只有在调用这里时，SingletonHolder 才会被加载，从而实例化 INSTANCE
21 return SingletonHolder.INSTANCE;
22 }
23}

为什么它很巧妙？

●懒加载（Lazy Loading）：当你加载 DatabaseConnectionPool 这个类时，内部类 SingletonHolder 并不会被立刻加载。只有当你真正调用 getInstance() 方法时，内部类才会被加载，对象才会被创建。这就节省了内存。

●零并发负担：它没有使用任何 synchronized 或者 volatile 关键字。它完全将线程安全的控制权交给了 JVM 底层的类加载机制（JVM 在加载一个类时，会自动加锁保证全局唯一）。

Spring 是如何实现单例的？

Spring 里的单例（Singleton）和我们在《设计模式》书里学到的单例，在概念和实现思路上有很大的不同。

●传统单例（GoF单例）：保证在一个 JVM（准确地说是类加载器）级别，某个类只有一个实例。类自己控制自己的实例化。

●Spring 单例：保证在一个 Spring IoC 容器（ApplicationContext）内部，某个指定的 Bean 名称只有一个实例。它是由 Spring 框架来统一管理的。

Spring 实现单例的核心原理可以概括为：单例注册表（Singleton Registry）

1. 核心数据结构：ConcurrentHashMap

如果你翻开 Spring 的底层源码（DefaultSingletonBeanRegistry 类），你会发现 Spring 管理单例的本质，就是一个大大的缓存 Map：

1⚡ java片段// Spring 源码中的 "一级缓存"，存放所有完全初始化好的单例 Bean
2private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

Spring 的单例其实就是把创建好的对象塞进了一个线程安全的 ConcurrentHashMap 里。Key 是 Bean 的名字（通常是类名首字母小写），Value 就是这个类的实例对象。

2. Spring 创建单例的流程

当你在代码里注入一个单例（比如通过 @Autowired），或者调用 context.getBean(“myService”) 时，Spring 大致会经历以下步骤：

1.查缓存：Spring 首先会去 singletonObjects 这个 Map 里查，看看有没有叫 “myService” 的对象。

2.有则返回：如果 Map 里有，说明已经创建过了，直接把这个对象返回给你。这就是单例的体现。

3.无则创建并加锁：如果 Map 里没有，Spring 就会准备创建它。为了保证在多线程环境下只有一个线程能去创建这个 Bean，Spring 会对这个 Bean 的名字进行加锁（通常是通过对全局单例集合的锁或者特定的互斥锁来实现同步）。

4.实例化与初始化：Spring 通过反射调用构造函数把对象 new 出来，然后进行属性填充（依赖注入），再调用 @PostConstruct 等初始化方法。

5.放入 Map 并返回：最后，把完全准备好的对象放进 singletonObjects 这个 ConcurrentHashMap 里，然后返回给你。以后所有对这个 Bean 的请求，都直接从 Map 里拿。

3. 补充：循环依赖的杀手锏“三级缓存”

Spring 在管理单例时，还要解决一个传统单例很难解决的问题——循环依赖（比如 A 依赖 B，B 又依赖 A）。

为了解决这个问题，Spring 其实并没有只用一个 Map，而是用了三个 Map（传说中的三级缓存）：

●一级缓存（singletonObjects）：存完整的、可用的单例对象。

●二级缓存（earlySingletonObjects）：存半成品对象（刚 new 出来，但还没注入属性的对象），用于提前暴露自己，打破循环。

●三级缓存（singletonFactories）：存对象工厂，用于在需要时生成代理对象（比如处理 AOP 切面）。

结合上面的图，核心过程如下：

第一阶段：A 的创建与曝光

1.调用 getBean(A)：Spring 容器开始创建 Bean A。

2.实例化 A：调用构造函数，A 对象在内存中诞生，但属性（如 B）还是 null。

3.暴露三级缓存：Spring 将 A 的工厂对象放入三级缓存 (singletonFactories)。这是解决循环依赖的关键一步，意味着此时如果有其他对象引用 A，可以通过这个工厂拿到 A 的引用。

第二阶段：A 填充属性，触发 B 的创建

4.填充属性 B：A 发现自己依赖 B，于是暂停自己，转而去创建 B。

第三阶段：B 的创建与获取 A

5.实例化 B：B 对象诞生，属性（如 A）还是 null。

6.暴露三级缓存：将 B 的工厂放入三级缓存。

7.填充属性 A：B 发现自己依赖 A，于是尝试去缓存找 A。

第四阶段：B 从缓存中找到 A (核心转折)

8.查找缓存：

●找一级缓存？没有（A 还没彻底完工）。

●找二级缓存？没有（还没人提取过 A 的早期引用）。

●找三级缓存？有了！

9.升级缓存：

●B 调用三级缓存中的工厂方法，拿到 A 的早期引用。

●重点：如果 A 配置了 AOP（比如事务管理），这个工厂会提前生成 A 的代理对象。

●将 A 的早期引用放入二级缓存 (earlySingletonObjects)，并从三级缓存移除。

10.B 完成：B 拿到了 A 的引用，完成属性填充和初始化，放入一级缓存。

第五阶段：A 完成

11.A 获取 B：B 已经创建好了，A 顺利拿到 B 的引用。

12.A 完成：A 完成属性填充和初始化，放入一级缓存。

全程0人工写代码！干掉低级码农的不是大模型

Tue, 24 Feb 2026 03:46:39 +0000

全程0人工写代码！干掉低级码农的不是大模型

在当前全行业的 AI 辅助编程浪潮中，大多数工具仍停留在“交互式伴游”阶段，而支付巨头 Stripe 却打造了一套完全无人值守的端到端代码智能体——“小黄人”（Minions）

小黄人是一个独立打工的“数字员工”。目前的惊人数据是：在 Stripe 内部，每周有超过 1300 个由小黄人完全生成的 Pull Requests（合并请求）被成功合并。这些代码在最终阶段会经过人类审查，但其中不包含任何人类编写的代码。

更具挑战的是，Stripe 的代码库高达数亿行，主要使用较冷门的带有 Sorbet 类型的 Ruby 语言，且包含大量 LLM 根本没见过的大型内部自研库。此外，这些代码每年要处理超过 1 万亿美元的支付量，合规与容错要求极高。

Stripe 是如何让 LLM 驾驭如此庞大且复杂的企业级代码库的？核心答案在于极其强大的定制化工程脚手架。

以下是小黄人能高效运转的四大核心技术拆解。

1 极致标准化的预热沙盒（Devboxes）

要让全自动 Agent 大规模并行工作，绝不能让它们跑在开发者杂乱的本地笔记本上。Stripe 的解法是直接复用为人类工程师打造的云端开发机（Devboxes）。

●10 秒极速“热启动”：这些 Devbox 是 AWS EC2 实例。Stripe 预先配置并预热了一个资源池，里面已经克隆好了巨大的 Git 仓库，预热了 Bazel 构建缓存和类型检查缓存，甚至启动了持续运行的代码生成服务。因此，只要 10 秒钟，小黄人就能拿到一台随时可以运行测试和修改代码的机器。

●免弹窗的完全提权：为了让小黄人在后台静默运行，它需要无缝执行各种 Shell 命令。因为 Devbox 运行在与生产资源和外部互联网隔离的 QA 环境中，爆炸半径被严格限制，所以系统敢于跳过人类权限确认弹窗，给予小黄人完整的执行自由。

●解决并发冲突：如果用本地环境，并发运行多个 Agent 需要处理复杂的 git worktrees（这在 Stripe 的庞大代码库中无法扩展）。而在云端，工程师可以轻易地同时为 6 个不同的任务启动 6 个分配了独立 Devbox 的小黄人，实现物理级别的完美隔离

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

常规的 Agent 往往采用开放的循环机制，任由 LLM 自己决定下一步调什么工具，这极易导致出错和浪费 Token。 Stripe 创造性地引入了**“蓝图”（Blueprints）**状态机机制。蓝图将整个工作流视为一张图，将 LLM 的创造力与确定性的系统代码交织在一起：

●确定性节点 vs Agent 节点：在蓝图中，像“实现具体任务”或“修复 CI 失败”是让 LLM 自由发挥的 Agent 节点；但是，像“运行配置好的 Linter”或“推送 Git 变更”则是完全不调用 LLM 的纯代码确定性节点。

●底线兜底：这意味着小黄人无法绕过代码格式化等硬性规范。把大模型“关进受控的盒子里”，不仅极大地节省了 Token，还从系统层面提高了整体可靠性。各团队甚至可以编写自定义的蓝图，来处理复杂的、LLM 辅助的代码库迁移任务

3 极其克制的上下文投喂：规则文件与 Toolshed

面对上亿行代码，如果把所有全局规则都塞给大模型，上下文窗口瞬间就会被撑爆。

●按目录生效的局部规则：Stripe 几乎只使用作用于特定子目录或文件模式的规则文件。他们巧妙地复用了人类工程师为 Cursor 编写的规则格式。这样，工程师在日常开发中沉淀的最佳实践，小黄人（以及 Claude Code）在遍历文件系统时就能直接动态读取并学习。

●MCP 工具棚（Toolshed）：小黄人通过模型上下文协议（MCP）获取网络信息（工单、文档、代码搜索等）。Stripe 建立了一个包含近 500 个内部与 SaaS 工具的中央服务器 Toolshed。但为了防止 Agent 分心，系统每次只会为小黄人精心挑选一个“小巧而高度相关”

4 反馈左移（Shifting Feedback Left）：极速纠错循环

无人值守 Agent 成功的关键在于能否实现自我闭环修正。Stripe 为其构建了多层极速反馈循环：

●5 秒内的本地验证：在小黄人把代码推送到 CI 之前，Devbox 上的后台守护进程会通过启发式算法自动运行相关的 Linter 和类型检查。这个本地节点耗时不到 5 秒，让小黄人在本地极速完成语法纠错。

●克制的 CI 测试轮数：Stripe 的 CI 拥有超过 300 万个测试用例。推送到 CI 后，系统会运行相关测试，并自动应用已有的修复脚本（Autofixes）。如果还有未修复的错误，报错会发回给小黄人。但为了平衡算力成本、时间与边际收益，小黄人最多只被允许进行 1 到 2 次的 CI 循环试错。之后无论成败，都会将其移交给人类处理，防止其陷入昂贵的死循环

给我的启示

基于 Stripe 公开的这些技术细节，我得出了以下几点关于 AI 研发提效的深刻感悟：

1.“对人类工程师有益的基础设施，对 LLM 同样有益” 这是 Stripe 整个小黄人项目最核心的哲学。Stripe 并没有为了做 AI Agent 去凭空造一套新基建，而是直接将 AI 接入了他们多年打磨的 Devbox 环境、Pre-push hooks 和自动化测试管线中。这给所有企业的启示是：AI Agent 的天花板，取决于你现有工程基础设施的底座。如果你的人类工程师本地环境经常崩溃、缺乏单测覆盖率、文档陈旧，那么大模型也一样会在这些泥坑里寸步难行。过去在人类开发者体验（Developer Productivity）上的每一分投资，都会在 AI 时代转化为巨大的复利回报。

2.放弃追求纯粹的“全能 Agent”，用“蓝图”管控不确定性目前业界过度迷恋让一个 Agent 自主解决所有问题。但 Stripe 的蓝图（Blueprints）设计极其务实：能用一行 Bash 脚本或 Linter 稳定解决的问题（如代码格式化、Git 提交流程），就绝对不让 LLM 消耗 Token 去“推理”。在企业级生产环境中，**混合架构（确定性代码逻辑 + 局部受控的 LLM 节点）**才是保证系统高可靠性（SLA）的唯一出路。

3.工程师的日常工作流正在被重塑，在 Stripe，触发小黄人的方式极度符合人体工程学：工程师可以直接在 Slack 的讨论线程里@小黄人，或者在内部的“CI 间歇性失败（Flaky test）”工单中点击一个按钮启动它。我们可以预见，未来的高级工程师将越来越像一个“包工头”：他们在值班（On-call）时并行启动几十个小黄人去处理琐碎的 Bug，自己则专注于审查 PR、设计架构，以及维护和编写能够指导小黄人的局部规则（Cursor rules）。工程师不再逐行敲击代码，而是定义意图并管理基础设施。

参考

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2

提示词缓存:让 LLM 成本降 10 倍

Mon, 29 Dec 2025 05:37:52 +0000

“

OpenAI 和 Anthropic 声称，缓存的输入 token 在成本上比常规输入 token 便宜 10 倍。

到底什么是 Cached Token ？

Cached Token 就是让 AI “记住” 它刚刚读过的长内容，不用每次都在脑子里从头重新算一遍，从而让回答变得极快且极便宜。

想象你正在参加一场开卷考试，考试内容是一本 500 页的历史书。

没有 Cache (传统模式) ：
第一题：你把书从第 1 页读到第 500 页，然后回答问题。
第二题：你忘光了刚才读的内容，必须再次从第 1 页读到第 500 页，才能回答第二个问题。
后果：每次回答都很慢，而且把你累得半死（消耗算力，费钱）。
有了 Cached Token (缓存模式) ：
第一题：你从第 1 页读到第 500 页，并把关键知识点和理解暂时存在脑子里（存入显存）。
第二题：你直接调用脑子里的记忆，跳过阅读过程，立刻回答问题。
后果：只有第一次慢，后面飞快，而且因为不用重复劳动，甚至可以给考官（用户）打个一折的优惠价

很多人会误以为 “缓存 = 把上次的回复存起来再发一遍”。不是的。

更准确地说，缓存的是模型在处理这段输入时产生的一些中间计算结果（常被称为 KV cache：attention 里的 K / V 矩阵）。所以即使 cached_tokens 很高，你也仍然可能得到不同的回答（因为采样、temperature 等发生在更后面）

LLM 架构

想要彻底弄明白 Cached Token，我们需要从原理上了解一下 LLM 架构。

我们可以将大语言模型（LLM）的架构看作是一个巨大的数学函数：输入一串数字，输出一个数字。这个过程主要由以下四个核心部分组成：

Tokenizer (分词器 / 切词器)

这是模型与人类语言交互的翻译官。

LLM 无法直接理解文本（如中文或英文），它只能处理数字。Tokenizer 的作用是将你输入的提示词（Prompt）切分成一个个小的片段，称为 Token，并为每个 Token 分配一个唯一的整数 ID。

比如输入 “Check out ngrok.ai”，Tokenizer 会将其切分为 [“Check”, “out”, “ng”, “rok”, “.ai”]，并转换为对应的数字序列。

注意：不同的模型（如 GPT-5 和 Claude）使用不同的 Tokenizer 规则

Embedding (嵌入层)

这是让数字拥有含义的一步。将 Tokenizer 生成的简单整数 ID 转换为高维向量（即一长串数字数组）。这个过程就像查字典，每个 Token ID 对应一个固定的向量。

下面是一个例子，可以看到将原始 token 进行 embedding 后是什么样子。

Embedding 是可以有很多维度的，最大的模型甚至超过 10,000 维，上面的例子只显示了三维。维度越多，大语言模型对每个标记的表示就越复杂、越细致。

这些向量代表了 Token 的 “语义位置”。在这个高维空间中，含义相似的词（如 “猫” 和 “狗”）在空间上的距离会更近。这一步还会把 Token 的位置信息编码进去，这样模型就能知道词语的先后顺序。

如果你听说过 “余弦相似度”，那么恭喜你找对了方向。Embedding（嵌入）和 Cosine Similarity（余弦相似度）的关系可以理解为 “坐标” 与 “距离测量工具” 的关系。

想象一个巨大的多维空间（就像一个无限大的图书馆）。Embedding 就是把每一个词、每一句话都变成这个空间里的一个具体的坐标点，在这个空间里，意思相近的词（比如 “猫” 和 “小猫”），它们的坐标点会靠得很近；意思无关的词（比如 “猫” 和 “微波炉”），距离就会很远。Embedding 把文字变成了数学空间里的向量，而余弦相似度用来计算这些向量之间的 “语义距离”。

Transformer (变换器 / 核心处理层)

这是 LLM 的大脑，负责理解和推理。

它的主要工作是让输入序列中的每个 Token 相互 “交流”。模型会计算每个 Token 对其他 Token 的重要程度（即 “注意力权重”）。例如在句子 “Mary had a little lamb” 中，模型会计算出 “Mary” 对 “had” 的生成有多重要。这就是它的核心机制。

到这里我知道你肯定会想到这篇开山之作**《Attention Is All You Need》**。没错，这篇论文作为开山之作，几乎全篇都在讨论 “Transformer”。该论文提出的 Transformer 架构，其主要职责就是接收 Embedding 层的输入（一堆数字向量），然后在这一层内部通过 Attention（注意力机制）和 Feedforward（前馈网络）对这些数据进行复杂的数学变换。关于论文这里不便展开，我们言归正传。

在这一层，输入的 Embedding 会被转化为 Query (Q)、Key (K) 和 Value (V) 三种形态。通过复杂的矩阵运算（Q 乘以 K 得到权重，再乘以 V），模型能够理解上下文的语境和词与词之间的关系。

简单来说：

每个 token 会生成三组向量：Q (Query：我想找什么)、K (Key：我有什么线索)、V (Value：我的内容是什么)
通过计算 Q 和所有 K 的相似度，得到 “该关注谁” 的权重（softmax 归一化），再对 V 做加权求和，得到 “结合上下文后的新表示”。
Multi-head 就是并行做多组注意力，让模型能同时学到多种关系（语法、指代、主题等）

这个阶段是计算量最大的部分。为了加速，推理过程中会将计算过的 K 和 V 矩阵缓存起来（即 KV Cache），避免对之前的 Token 重复计算

Output (输出层)

这是最终生成结果的一步。

经过 Transformer 层层处理后，最后得到一个新的 Embedding。输出层会将其转化为概率分布，预测下一个最可能出现的 Token。

LLM 是 “自回归” 的，这意味着它每次只生成一个 Token。生成的这个新 Token 会被加回到输入的末尾，整个流程（Tokenizer -> … -> Output）再次循环，直到生成结束符（如）或达到长度限制

实现原理

了解了之前这些背景知道，我们就可以解释 Cached Token 的技术原理了。

在 LLM（大语言模型）推理过程中，Cached Token 指的是对 KV Cache (Key-Value Cache) 的复用技术。

Transformer 架构是自回归的。在生成回答（Decode 阶段）之前，模型必须先 “理解” 输入（Prefill 阶段）。这个 “理解” 过程涉及大量的矩阵运算，计算出每个 Token 的 Key 和 Value 向量（即注意力机制的中间状态）。对于长文本（如 RAG 场景中的大量文档），每次请求都重新计算这些 KV 向量是巨大的算力浪费，这就是 Cached Token 解决的问题。

实现机制：

存储状态：当模型第一次处理前缀（Prefix，例如 System Prompt 或长文档）时，将计算好的 KV 向量驻留在 GPU 显存（VRAM）或层级存储中。
前缀匹配：当新的请求进来，如果开头部分（Prefix）与缓存中的 Token 完全一致，推理引擎（如 vLLM, SGLang）会直接加载已计算好的 KV 状态，跳过 Transformer 的前向计算过程。
PagedAttention：现代推理引擎（如 vLLM）使用类似操作系统内存分页的技术（PagedAttention）来管理这些缓存块，解决了显存碎片化问题，允许多个请求共享同一份物理显存中的 Prompt 数据

想省钱，要这样用

要在应用里稳定吃到 cached tokens（prompt caching），核心就三句话：

提示词要够长（通常 ≥ 1024 tokens 才会开始命中）
前缀要 “完全一致”（缓存按 “最长相同前缀” 命中，哪怕一个字符 / 空格不同都可能全失效）
把不变的放前面，把变化的放后面（指令/工具/示例/长背景固定；用户问题、检索结果、时间戳等放末尾）

所以我们要从设计上进行些调整才能够 “省钱”：

设计 “可缓存的前缀结构”，把 prompt 拆成两段（非常重要）：
可缓存前缀（Static Prefix）：system 指令、角色设定、规范、few-shot 示例、工具定义、长期不变的背景资料
动态尾部（Dynamic Tail）：用户输入、RAG 检索内容、实时数据、时间戳、request_id、实验开关等
多轮对话 / Agent 的注意事项
消息数组要 “只追加，不改历史”：如果你为了省 tokens 把历史消息重排、压缩、或插入到中间，很可能导致前缀变了 → cache miss。
工具定义（tools）必须完全一致，顺序也要一致，否则工具部分也进不了缓存前缀

“

OpenAI Cookbook 直接建议：静态内容放开头，可变内容放结尾；工具 / 图片也一样。

常见 “踩坑清单”

把时间戳 / 随机 ID 放在 system 开头：每次都变，等于主动让缓存失效。
JSON 序列化不稳定：同一份 tool schema 如果字段顺序、空格、换行变化，token 序列可能变 → miss（所以建议对 system/tools 做 “规范化输出”，并保持完全一致）
指令在每次请求里微调一两个字：看似小改动，可能让前 1024 tokens 出现差异，直接从 “高命中” 变成 “全 miss”。Azure 文档明确说 “前 1024 tokens 一个字符差异就会 miss”

缓存能活多久 / 怎么保持

不同厂商策略不同，但你可以这么理解：缓存不是永久的，要么靠短时间内重复使用，要么使用更长的保留策略（如果提供）。

Azure OpenAI：缓存通常在空闲 5–10 分钟清理，并且最晚 1 小时内会移除；还支持 prompt_cache_key 帮你影响路由提高命中，但同一前缀 + key 如果请求过猛（文档提到约 15 RPM 量级）可能溢出导致命中变差。
OpenAI：提供 prompt_cache_retention（默认 in_memory，也可选 24h 做更长保留），并说明缓存的是 attention prefill 产生的 KV tensors，原始提示文本不以同样方式持久化。
Anthropic Claude：通过在特定内容块上标注 cache_control 来启用 / 控制缓存（用法是显式的）。

落地建议

给开发：

把系统提示词拆成 STATIC_SYSTEM_PROMPT（长期不变）+ DYNAMIC_CONTEXT（每次变）
所有请求都按固定模板拼：STATIC_SYSTEM_PROMPT + tools + (可选固定示例) + DYNAMIC_CONTEXT + user_question
总结来说：把静态内容（System Prompt、Tools）置顶，动态内容（User Query、Time）置底；确保 JSON 序列化顺序固定；针对 Claude 需手动加标记；监控 “缓存命中率”（Cache Hit Rate）指标，确保不是在做负优化。

给产品：

缓存能让长文档分析、多轮对话变得极快且便宜。设计功能时，尽量让用户基于一个 “固定的背景”（如上传一份文档后针对该文档多次提问），这最能利用缓存优势。

实际应用场景

多轮对话 (Chatbot)：用户和 AI 聊了 20 轮，第 21 轮时，前 20 轮的历史记录就是 “Cached Token”。不用每次都重算历史记录，响应更快。
文档问答 (RAG)：上传一本 PDF 法律合同。只要文件没变，第二个问题开始，AI 就不需要重新处理这份文件
代码助手 (Coding Agent)：将整个项目的代码库结构作为 Prompt 发送给 AI。这部分内容巨大且变动不频繁，非常适合缓存。
角色扮演 / Agent：复杂的 System Prompt（设定 AI 的性格、规则、工具定义）通常很长且固定，缓存后每次调用都极快

3 毛钱干大事？用了几天豆包编程模型，我来扒一扒字节这波操作

Mon, 17 Nov 2025 12:58:03 +0000

“

测评人：小盒子（AI 架构仔，Agentic 编程方向，常年被 API 账单搞到头大）测评时间： 2025 年 11 月 11 日发布后的一周

这波价格战，字节是真不想给同行活路了

说实话，我当时 凌晨 1:47 在公司改那个傻 X 的 Kubernetes 配置。看到新闻推送，火山引擎出了个 豆包编程模型 Doubao-Seed-Code，说性能 SOTA，但这不是重点。

重点是价格。它宣称综合成本能比业界平均水平低 62.7%，直接是 国内最低价。我当时正在用 cc 搭配 k2，心想：都说最低价，质量怎么样呢？k2 测完了其实还是不如原装的 claude，所以 doubao-seed-code 如果真是质量高价格低的话，多一个选择也是蛮不错的。

以前我们跑一次复杂的 Agentic 任务，特别是涉及多轮 Bug 修复和重构的，Claude Sonnet 4.5 那个账单，每个月看一次疼一次。

我看官方资料里明晃晃地写着，做一个交互式英语学习网站，用 Doubao-Seed-Code 只需要 0.34 元左右，用 Claude Sonnet 4.5 可是要大概 4 块多。这差距，可以的～

它这个 API 定价，输入 1.20 元/百万 Tokens，输出 8.00 元/百万 Tokens（0-32K 区间），配合那个 Cache 技术，还能再降 80% 的成本。我们现在正在做 Agent 自动化项目，以前成本受限，很多地方要做工程优化，要这样的话，感觉忽然就 经济可行 了。

我立马摸鱼时试了下，冲了它那个 9.9 块首月的 Coding Plan。一杯咖啡钱，买一个号称 SWE-Bench Verified 榜单上 SOTA 的模型（这个榜单是测 Agent 端到端解决问题的能力，很硬核的）。

兼容 Claude Code

感觉最近这都成了编程模型的标配了哈。

作为 Claude Code 用户，感觉接入不是很丝滑的。Doubao-Seed-Code 原生兼容 Anthropic API ，接入方法还是老套路，很简单：

第一种方式

如果是短期测试，可以直接在终端中配置环境变量，在启动 Claude Code 前输入环境变量

1export ANTHROPIC_BASE_URL=https://ark.cn-beijing.volces.com/api/compatible
2export ANTHROPIC_AUTH_TOKEN=<ARK-API-KEY>
3export ANTHROPIC_MODEL=doubao-seed-code-preview-latest

第二种方式

如果是长期使用，可以直接配置文件

1open -e ~/.claude/settings.json
2
3{
4 "api_key": "xxxxxxx",
5 "api_url": "https://ark.cn-beijing.volces.com/api/compatible",
6 "model": "doubao-seed-code-preview-latest"
7}

说句提外话，最近这几家搞 code 模型的，就是明着抢 Claude 的客户，但我支持，哈哈。

切换零成本 + 价格低 60%+ 性能 SOTA 确实有点儿心动。

核心能力体验

“

长上下文和那个 VLM 才是真杀手锏

光便宜和兼容没用，代码写得烂，那也是浪费我时间。

看了一下上下文，256K，还成，跟 K2 一样，感觉现在没个 256K 都不好拿出手。

虽然 Claude 4.5 Sonnet 的上下文声称是 1M，但实际上只有 200K，而且还死贵。 256 好，还多 56K，哈哈

别小看多出来的这点儿。我手头有个遗留项目，Python 写的，几百个文件，那叫一个乱。模型处理 Bug，有时候上下文 Token 一爆，它就变瞎子了，你得手动 RAG 喂它代码，有时候就差那么一两个文件，逼得我重开个 thread，前面都白费劲了。

Doubao-Seed-Code 多出来的这 56K，意味着它能把整个中等规模的项目结构和依赖都装进 “脑子” 里

刚才我让它解决一个跨越十几个文件的逻辑 Bug，以前的模型得来回拉扯五六轮，这次它 一步到位 定位到了问题。而且它不只是修复 Bug，它还会 优化结构，提升代码的可读性和维护性。这才是 Agent 编程，不过客观地讲跟最贵的那位比还是有一定的差距。

VLM：前端仔的末日… 还是福音？

这个视觉理解（VLM）能力， 国内首发。

这个功能并不新鲜，但国内首发，算是跟上了。我现在可以直接把 UI 稿截图，或者手绘草稿扔给它。然后它能给你生成对应的代码。

我一开始以为它就是搞了个图转文字，再让 LLM 去生成代码，这种方法信息折损很大。结果它这个是原生的 VLM 能力，不是靠工具调用。最牛逼的是，它能 自己完成样式修复和 Bug 修复。它生成一个页面，然后拿截图跟你原始的设计稿对比，发现哪里边距不对，哪里颜色溢出了，自己动手改

我当时试了一个复杂的 Dashboard 界面，只给了一张截图，它生成的 React + Tailwind 代码还原度还是非常高的。前端兄弟估计已经麻木了，据我所知，他们自己也在用 vibe coding 干活，哈哈。

聊聊技术底裤

Doubao-Seed-Code 的核心是 Seed-Coder 家族，能 SOTA，说明字节在训练上砸了不少黑科技

官方资料里提了一堆很唬人的词儿, 小盒子来翻译翻译：

“大规模 Agent 强化学习训练系统” ：他们好像是搞了一套巨大的 打怪升级系统，专门用来训练代码 Agent。模型不是靠背书（预训练数据）学编程的，它是直接在 沙盒里 跑代码
构建了覆盖 10 万容器镜像的训练数据集”：为了让模型见过各种稀奇古怪的运行环境（比如 Python 3.7 + PyTorch 1.9 + CUDA 10.2），他们准备了 10 万个容器
“万级并发沙盒 session”：几万个容器同时跑。让模型在里面不断试错，错了就 罚站（接收执行反馈）。这样练出来的 Agent，解决问题的鲁棒性才强

这套机制直接解释了为什么它能在 SWE-Bench Verified 这种需要端到端解决问题的测试里登顶。它不是一个静态的知识库，它是个会 思考、会动手、会自我修正 的开发伙伴

顺便提一句，这个 Seed-Coder 还有开源版本。开源的 Seed-Coder-8B-Reasoning 有 64K 上下文，虽然不如商业 API 的 256K 那么猛，但对于个人研究也够用了。

测试

这里我做了一个测试，目的是看它能不能真的理解 “Vibe Coding”（用户描述一个抽象的、高层的需求，让 Agent 去实现），特别是设计稿的还原和自我纠错能力

找一个 UI 稿截图，越复杂越好。

最终生成的效果如下：

总结

无论最后你是否使用 doubao-seed-code 模型作为你的生产工具，我都推荐你试试，包括 k2 等其他模型，无它，AI 进化的速度很快，先上车！

单纯就 doubao-seed-code 来说，我觉得也还可以：

价格摆在那儿，跑 100 次 Agentic 任务的成本，以前可能只能跑 30 次。
VLM 是未来：前端开发效率的飞跃。
256K 上下文：真正能处理企业级复杂重构任务的基础。

Doubao-Seed-Code 这波操作，是想把 AI 编程从 “昂贵的工具” 变成 “水、电、煤” 一样基础设施。对于追求极致效率和成本控制的团队，值得一试。

LangChain：是银弹，还是 “技术债”？

Tue, 23 Sep 2025 05:46:17 +0000

引言

当前，智能 Agent 的开发正面临两条截然不同的路径选择。一方面，高代码方式通过 SDK 和 API 编码提供灵活性，但带来了巨大的复杂性负担——开发者需要深入理解模型集成、工具调用、记忆管理和分布式协调等复杂概念，显著提高了开发门槛和维护成本。另一方面，像百炼，Dify、Coze 为代表的低代码平台以其出色的易用性迅速占领市场，通过可视化界面让用户能够快速构建 “Model+Prompt+MCP+RAG+Memory” 的标准 Agent 模式。

高代码与低代码

高代码

优势

●控制粒度高：检索、重排、记忆淘汰策略、工具容错、并发/一致性都能精细掌控。

●可移植/可替换：模型、向量库、存储、消息队列可按需换，避免深度锁定。

●性能上限高：可针对热路径做缓存/批量化/并行/算力亲和等优化。

●合规友好：易于纯内网/私有化落地，满足数据边界与审计需求。

劣势

●上手成本高：需要理解模型行为、工具协议、状态管理、分布式、测试/评测。

●开发周期长：原型到生产的路径更长，对团队工程能力要求高。

●维护复杂：提示/数据/评测/日志/灰度与回滚都要自己做治理。

适用场景

●对稳定性、性能、合规要求高的核心业务流程（客服、风控、运维、知识中枢）。

●强定制：复杂工具链（多后端系统、定制检索策略、多段对话状态机）。

●内网/私有化：外网受限、需与既有基建深度耦合（监控、鉴权、审计）。

低代码

优势

●速度快：原型与迭代极快，业务同学也能参与搭建与验收。

●门槛低：抽象好了调用、编排、上下文缓存、简单评测与发布。

●运维成本低：平台内置监控/日志/版本管理（能力视平台而定）。

劣势

●可扩展性受限：复杂状态机、精细化检索/重排、跨域事务一致性等较难。

●性能上限有限：难做深度批处理、算力亲和、跨服务并行等工程优化。

●供应商/能力锁定：某些特性依赖平台实现，迁移成本较高。

●私有化差异：部分平台更偏 SaaS；若需纯内网，要筛选支持私有化/离线模型的方案。

适用场景

●探索/验证期：快速做 PoC、AB 实验、用户调研与演示。

●中轻量业务：知识问答、表单处理、运营活动、内部助理等非关键路径。

●混合团队：产品/运营可直接改提示与流程，工程只需提供数据/工具接口。

场景选型

高代码和低代码有各自的特点和适用场景，那我们该如何决策呢？下面是一个快速决策矩阵：

总结来说：要“快试错”选低代码，要“硬落地”选高代码；两者并不对立，适合“原型低代码 + 核心高代码”的混合路线。

具体来说：

●2 周内交付可用原型、验证需求是否真实 → 低代码

●承载 7×24 核心业务，SLA/审计/内网合规很硬 → 高代码

●大量业务同学参与、频繁改提示与流程 → 低代码 +（必要时）接入自研工具

●把 RAG/记忆/工具编排做成“组织级能力层” → 高代码（沉淀为平台/服务）

●先做 Demo，再逐步把关键链路“工程化” → 低→高的混合迁移

这里需要注意的是，要避免反模式：

●把复杂状态机硬堆在低代码画布里，后期难以维护与回放。

●过早全高代码，导致验证周期太长、需求未定先造轮子。

●忽视提示/知识/评测的版本化与可回滚。

混合实践

对于我们来说，现在正好处于一个 “混合迁移” 的阶段，我们即在使用低代码平台 Dify,也在某些具体的场景下感到了 Dify的不适。所以对于某些项目要进行必要的工程化迁移和改造，具体思路是：

●前台用低代码（业务侧快速改动、AB/评测、需求验证）；

●后台用高代码沉淀“能力层”（RAG 服务、工具/MCP、回溯评测、观测/追踪、策略引擎）。

●平台只做编排与呈现，能力层提供稳定 API。

●形成“能力可复用、前台可迭代、核心可控”的结构。

一句话总结：低代码赢在速度，高代码赢在确定性；用低代码把事儿“做成”，再用高代码把事儿“做稳且做大”。

LangChain

概念说明

提到 LangChain 我们要先厘清一下概念，因为这里有两个概念：

第一，LangChain Inc. 是一家总部位于美国旧金山的前沿人工智能技术公司。公司成立于 2022 年，由 Harrison Chase 和 Ankush Gola 共同创立，2023 年正式独立成立公司实体。公司注册于 2023 年 1 月 31 日，总部地址位于加利福尼亚州旧金山市 Decatur 街 42 号。

第二，LangChain 还是一个用来开发基于 LLM 的 AI 应用框架。

从 LangChain 公司官网和官方文档提供的产品架构图中可以看出，LangChain公司提供的主要产品有：

●开发框架

○LangChain（OSS-免费开源软件)

○LangGraph（OSS-免费开源软件）

●平台

○LangSmith (COMMERCIAL-商业收费)

○LangGraph Platform (COMMERCIAL-商业收费)

在下文中如无特殊说明，LangChain 一律指代第二个概念，即开源的开发框架。

大模型应用开发核心矛盾

当下的 LLM 本身如同一个 “博学但无手无脚的大脑”，它无法感知实时信息、无法操作外部工具、也无法与我们的私有数据交互。这个 “从 “模型能力” 到 “应用能力” 的鸿沟” 正是所有 LLM 应用开发者面临的首要难题。

LangChain 不是一个 “新发明”，而是一个 “高效的连接器和编排器”。它的战略价值在于，它是当前弥合 “模型能力” 与 “应用能力” 鸿沟的最成熟的工程化解决方案之一。

框架介绍

LangChain 的核心思想是“链”，它将 LLM 应用程序的各个组件连接在一起，形成一个完整的工作流。这种模块化的方法可以将复杂的人工智能系统分解为可重用的部分。LangChain 提供了一系列工具和抽象，帮助开发人员将 LLM 与外部数据源（如数据库、API等）连接起来，从而创建功能更强大的应用程序。

LangChain 能够解决的五类问题

LangChain 能够解决五个核心领域（按复杂度递增）

1. 模型与提示（I / O 层）

要解决什么？ 稳定、可替换地调用任意 LLM，并拿到可解析、可复用的输出。

关键点：BaseChatModel、ChatPromptTemplate、OutputParser、LCEL invoke/stream/batch。

一般来说入门 LangChain 都是从第一层起步：prompt | llm | parser

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_core.prompts import ChatPromptTemplate
 3from langchain_core.output_parsers import StrOutputParser
 4from langchain_openai import ChatOpenAI
 5
 6prompt = ChatPromptTemplate.from_messages([
 7 ("system", "你是精炼的中文助手。"),
 8 ("human", "用一句话解释：{topic}")
 9])
10
11chain = prompt | ChatOpenAI(model="gpt-4o-mini") | StrOutputParser()
12print(chain.invoke({"topic": "LCEL 是什么？"}))

2. 链式编排（流程层）

要解决什么？ 把多个步骤（清洗→生成→解析→后处理）按顺序 / 并行可靠执行。

关键点：Runnable 统一协议、| 管道、并行 map、重试与超时、缓存

适用：流程确定、依赖明确的任务（如格式转换、规则后处理、批处理）。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_core.runnables import RunnableLambda
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_core.output_parsers import StrOutputParser
 5from langchain_openai import ChatOpenAI
 6
 7pre = RunnableLambda(lambda x: {"q": x["q"].strip()[:200]}) # 预处理：清理&截断
 8post = RunnableLambda(lambda s: s.rstrip("。") + "。") # 后处理：补全句号
 9
10prompt = ChatPromptTemplate.from_messages([
11 ("system", "用简洁中文回答。"),
12 ("human", "把这些要点合成一句话：{q}")
13])
14
15chain = pre | prompt | ChatOpenAI(model="gpt-4o-mini", temperature=0) | StrOutputParser() | post
16print(chain.invoke({"q": "LCEL, Runnable, invoke/batch/stream"}))

3. 检索增强生成 RAG（数据层）

要解决什么？ 当模型 “知道的不够”，要从外部资料中取对内容。

关键点：Loader/TextSplitter → Embeddings → VectorStore → Retriever（可带重排 / 压缩）。

 1⚡ python片段# pip install -U langchain langchain-openai langchain-community faiss-cpu
 2
 3from langchain_openai import ChatOpenAI, OpenAIEmbeddings
 4from langchain_core.prompts import ChatPromptTemplate
 5from langchain_core.output_parsers import StrOutputParser
 6from langchain_core.runnables import RunnablePassthrough, RunnableLambda
 7from langchain_community.vectorstores import FAISS
 8
 9# 1) 准备示例知识（演示使用；实际替换为你的文档）
10texts = [
11 "LCEL 是 LangChain 的可组合执行协议，用 | 串联组件（prompt、llm、parser）。",
12 "RAG（检索增强生成）通过向量检索把外部资料接入模型，以降低幻觉并注入最新知识。"
13]
14vs = FAISS.from_texts(texts, OpenAIEmbeddings())
15retriever = vs.as_retriever(k=3)
16
17# 2) RAG Prompt（把检索到的资料塞进上下文）
18prompt = ChatPromptTemplate.from_messages([
19 ("system", "你是知识助手，必须基于提供的资料回答。"),
20 ("human", "问题：{question}\n\n资料：\n{context}\n\n请用中文简洁作答，并在句末用[]引用关键词。")
21])
22
23# 3) 组合：question → retriever → prompt → llm → parser
24format_docs = RunnableLambda(lambda docs: "\n\n".join(d.page_content for d in docs))
25chain = (
26 {"context": retriever | format_docs, "question": RunnablePassthrough()}
27 | prompt
28 | ChatOpenAI(model="gpt-4o-mini", temperature=0)
29 | StrOutputParser()
30)
31
32print(chain.invoke("什么是 RAG？"))

4. 智能代理（自主层）

要解决什么？ 目标不完全明确、步骤不固定，需要选择工具、反复试探（行动 - 观察 - 反思）。

关键点：BaseTool/工具调用、函数调用、AgentExecutor（或用 LangGraph 做有状态策略）、记忆 / 护栏。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_openai import ChatOpenAI
 3from langchain_core.tools import tool
 4from langchain_core.messages import SystemMessage, HumanMessage, ToolMessage
 5
 6# 1) 定义一个可被模型调用的工具（OpenAI Tool Calling）
 7@tool
 8def multiply(a: int, b: int) -> int:
 9 "精确乘法"
10 return a * b
11
12# 2) 绑定工具，让模型自行决定是否调用
13llm = ChatOpenAI(model="gpt-4o-mini", temperature=0).bind_tools([multiply])
14
15# 3) 行动-观察-再思考（最小一次循环）
16msgs = [
17 SystemMessage("你是严谨助手，涉及计算必须调用工具，不要心算。"),
18 HumanMessage("先算 12×34，再把结果乘以 2，给出最终数值即可。"),
19]
20
21ai = llm.invoke(msgs) # 行动：模型决定要不要调用工具
22msgs.append(ai)
23for tc in ai.tool_calls: # 观察：执行工具并把结果回传给模型
24 out = multiply.invoke(tc["args"])
25 msgs.append(ToolMessage(str(out), tool_call_id=tc["id"]))
26
27final = llm.invoke(msgs) # 再思考：基于工具结果给最终答案
28print(final.content)

5. 评估与观测（质量层）

要解决什么？ 度量 “是否正确/有用/鲁棒”，以及在真实流量中看得见链路与瓶颈。

关键点：基准指标（EM/F1/检索命中率）、LLM 判分、回放/对比、LangSmith（或自建追踪）。

 1⚡ python片段# pip install -U langchain langchain-openai
 2from langchain_openai import ChatOpenAI
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_core.output_parsers import StrOutputParser
 5from langchain.evaluation import load_evaluator
 6
 7# 被评对象：最小 QA 链（LCEL）
 8qa = (ChatPromptTemplate.from_template("用一句话回答：{q}")
 9 | ChatOpenAI(model="gpt-4o-mini", temperature=0)
10 | StrOutputParser())
11
12q = "LCEL 是什么？"
13ref = "LCEL 是 LangChain 的统一执行协议，用 | 将组件串联成可组合管道。"
14
15pred = qa.invoke({"q": q})
16
17# LangChain 自带评估器：按“准确&简洁”两条标准打分+给理由
18evaluator = load_evaluator(
19 "labeled_criteria",
20 llm=ChatOpenAI(model="gpt-4o-mini", temperature=0),
21 criteria={"accuracy": "是否与参考一致且不捏造", "conciseness": "是否一句话且清晰"}
22)
23grade = evaluator.evaluate_strings(input=q, prediction=pred, reference=ref)
24
25print("答案：", pred)
26print("评分：", grade.get("score"), "理由：", grade.get("reason"))

总结如下：

架构图

LangChain 是一个以组合性为核心哲学的大语言模型应用开发框架

其设计理念是 “通过组合性构建LLM应用”，具体来说：

1.可组合性 (Composability)：所有组件都是 Runnable，可以像乐高积木一样组合；使用 LCEL（LangChain Expression Language）轻松构建复杂流程

2.标准化接口 (Standardization)：统一的输入输出接口；一致的同步/异步/批处理/流式处理方法

3.可扩展性 (Extensibility)：通过继承基类轻松添加新实现；插件化架构，易于集成第三方服务

4.类型安全 (Type Safety)：使用泛型和类型提示；编译时类型检查，减少运行时错误

架构层次

LangChain 采用严格的分层架构，从底层的核心抽象到上层的应用组件，确保了良好的模块化和可扩展性。

 1⚡ text片段LangChain
 2├── langchain-core/ # 核心抽象层
 3│ ├── language_models/ # 基础模型抽象
 4│ ├── runnables/ # LCEL 核心
 5│ ├── prompts/ # 提示抽象
 6│ └── ...
 7│
 8├── langchain/ # 主实现层
 9│ ├── llms/ # LLM 实现
10│ ├── chat_models/ # Chat 实现
11│ ├── chains/ # 链实现
12│ └── ...
13│
14└── langchain-community/ # 社区集成
15 └── partners/ # 第三方集成
16 ├── openai/
17 ├── anthropic/
18 └── ...

模块结构

LangChain 主要包含以下模块：

1.核心语言模型模块

○llms/ - 传统 LLM（85+ 个实现）

○chat_models/ - 对话模型（35+ 个实现）

○embeddings/ - 嵌入模型（51+ 个实现）

2.输入输出模块

○prompts/ - 提示模板

○output_parsers/ - 输出解析器（23+ 种）

○prompt_values/ - 提示值处理

3.数据处理模块

○document_loaders/ - 文档加载器（166+ 种）

○document_transformers/ - 文档转换器

○text_splitter.py - 文本分割

○indexes/ - 索引管理

4.存储与检索模块

○vectorstores/ - 向量数据库（76+ 种）

○retrievers/ - 检索器（78+ 种）

○memory/ - 记忆管理（39+ 种）

○storage/ - 存储抽象

○docstore/ - 文档存储

5.链与编排模块

○chains/ - 各种链（144+ 个文件）

○runnables/ - 可运行组件

○agents/ - 智能体（146+ 个文件）

6.工具与集成模块

○tools/ - 工具集（186+ 种）

○agent_toolkits/ - 工具包

○utilities/ - 实用工具（59+ 个）

○utils/ - 辅助函数

7.回调与监控模块

○callbacks/ - 回调处理器（46+ 种）

○tracers/ - 追踪器

○evaluation/ - 评估工具（32+ 个）

8.特殊功能模块

○chat_loaders/ - 聊天记录加载

○graphs/ - 图处理

○sql_database.py - SQL 数据库支持

○cache.py - 缓存管理

Runnable 抽象

LangChain 的架构精髓在于 Runnable 接口 —— 一个"可以被调用、批处理、流化、转换和组合的工作单元" 。这个抽象提供了六种核心执行模式：

●invoke/ainvoke: 单次同步/异步执行

●batch/abatch: 并行同步/异步批处理执行

●stream/astream: 同步/异步流式输出执行

所有组件都实现 Runnable 接口，从检索器到代理系统，确保了组件间的无缝互操作性，使得 LangChain 组件具有极高的可组合性。

1⚡ 代码片段# 示例：链式组合
2chain = prompt | model | parser

LCEL：声明式表达语言

LangChain Expression Language (LCEL) 是框架的"声明式方法构建生产级程序" 。通过管道操作符（|）实现组件的优雅组合，天然支持异步、批处理和流式操作，这使得基于LCEL的程序能够更好地扩展以处理更高的并发负载。

LCEL 不仅仅是语法糖。它是一种声明式的编程范式。开发者只需声明 “数据如何流动”，而框架负责处理底层的执行、流式传输、并行化和日志记录。

 1⚡ python片段# pip install -U langchain langchain-openai
 2
 3from langchain_core.prompts import ChatPromptTemplate
 4from langchain_openai import ChatOpenAI
 5from langchain_core.output_parsers import StrOutputParser
 6
 7# 1) Prompt：定义输入模板
 8prompt = ChatPromptTemplate.from_messages([
 9 ("system", "你是精炼、可靠的中文助手。"),
10 ("human", "用一句话回答：{question}")
11])
12
13# 2) LLM：任意 OpenAI 兼容服务均可（公有云/企业网关/vLLM 等）
14llm = ChatOpenAI(
15 model="gpt-4o-mini", # 换成你的模型名即可
16 api_key="YOUR_KEY", # 也可用环境变量 OPENAI_API_KEY
17 base_url="http://localhost:8000/v1" # 选填：本地或内网的 OpenAI 兼容地址
18)
19
20# 3) Parser：把模型返回的消息对象转成纯字符串
21parser = StrOutputParser()
22
23# LCEL：像搭乐高一样用“|”把组件串起来
24chain = prompt | llm | parser
25
26# ——最简单的单次调用（演示用）——
27print(chain.invoke({"question": "LCEL 是什么？"}))
28
29# ——可选：流式演示（边生成边打印）——
30for chunk in chain.stream({"question": "给出一条使用 LCEL 的建议"}):
31 print(chunk, end="")
32print()
33
34# ——可选：批量演示（一次处理多条）——
35print(chain.batch([
36 {"question": "一句话解释 LangChain"},
37 {"question": "一句话解释 LCEL 的优势"}
38]))

Schema 与类型系统

LangChain 的类型系统建立在 Python 的类型提示和 Pydantic模型之上，提供了一套完整的类型定义来支持 LLM 应用开发。LangChain 的类型系统具有以下特点：

1.强类型: 基于 Python 类型提示和 Pydantic，提供编译时和运行时类型检查

2.可组合: 通过 Runnable 接口实现组件的灵活组合

3.可序列化: 所有核心类型都继承自 Serializable

4.灵活性: 支持多种 Schema 定义方式（Pydantic、TypedDict、JSON Schema）

5.流式支持: 原生支持同步、异步、批处理和流式处理

6.标准化: 统一的输入输出类型定义，便于组件互操作

Pydantic 由 Samuel Colvin 创建，核心思想是：“使用类型注解定义数据模型，Pydantic 自动帮你验证和转换数据。” 它基于 Python 3.6+ 的类型提示系统（如 str, int, List, Optional 等），通过定义继承自 BaseModel 的类，来描述期望的数据结构。

想象一下，你正在指挥一个非常聪明但有点 “随心所欲” 的机器人。如果你只是模糊地说 “给我找点关于猫的资料”，它可能会给你一篇科学论文，一张猫的图片，或者一段猫叫的音频。这太不可预测了。LangChain 的 Schema 和类型系统，就像是给这个机器人的一套精确的 “指令图纸” 和 “数据表格”。它让你能够用一种机器人能精确理解的方式下达指令，并要求它以你想要的、规整的格式返回结果。下面我们通过几个场景和代码例子，来看看这些 “图纸” 和 “表格” 是怎么工作的。

场景 1: 从简单的闲聊到有角色区分的对话

一开始，我们和 AI 的交互很简单，就是 “一问一答”。

最基础的类型: Text (字符串): 这就是最原始的交互方式。

1⚡ 代码片段# 这其实就是最基础的文本 Schema
2my_question = "你好，你叫什么名字？"
3ai_response = "我是AI助手。"

但这很快就不够用了。在一个持续的对话中，AI 需要知道哪句话是谁说的，才能更好地理解上下文。

进阶类型: ChatMessage

ChatMessage 就是为了解决这个问题而生的 “对话表格”。它规定了每条消息都应该有 role (角色) 和 content (内容) 两列。主要角色有：

○SystemMessage: 系统指令。给 AI 设定一个 “人设” 或总体的行为准则。

○HumanMessage: 你的话。

○AIMessage: AI 的话。

每个元素都有明确的role 和content。这让 AI 不再混乱，能够更好地进行多轮对话。

场景 2: 我需要 AI 给我一个结构化的数据，而不是一段话

假设你想让 AI 帮你生成用户信息，并存入数据库。如果你只对它说 “生成一个用户，名叫张三，25 岁，邮箱是 zhangsan@email.com”，它可能会返回：

●" 好的，用户信息如下：姓名：张三，年龄：25，邮箱：zhangsan@email.com"

●" 张三，25 岁，邮箱 zhangsan@email.com"

●" 这是一个名叫张三的用户，他今年 25 岁了，你可以通过 zhangsan@email.com 联系到他。"

这些都是字符串，程序很难处理！我们需要的是一个干净的、可以直接用的 JSON 对象。这时，我们就要给 AI 一张 “图纸”，告诉它我们想要的输出格式。在 LangChain 中，最常用的 “绘图工具” 就是Pydantic 库。

 1⚡ python片段# 伪代码，演示核心逻辑
 2from langchain_core.pydantic_v1 import BaseModel, Field
 3from langchain_core.output_parsers import JsonOutputParser
 4from langchain_openai import ChatOpenAI
 5from langchain_core.prompts import PromptTemplate
 6
 7# 1. 用 Pydantic 画一张“图纸”，定义你想要的输出结构
 8classUserProfile(BaseModel):
 9 name: str = Field(description="用户的全名")
10 age: int = Field(description="用户的年龄")
11 email: str = Field(description="用户的电子邮件地址")
12 is_active: bool = Field(description="用户账户是否活跃")
13
14# 2. 创建一个输出解析器，告诉它要用哪张“图纸”
15parser = JsonOutputParser(pydantic_object=UserProfile)
16
17# 3. 在提示中，告诉AI要按照“图纸”的格式来回答
18prompt = PromptTemplate(
19 template="""
20 根据下面的用户信息，生成一个JSON对象。
21 用户信息：{user_info}
22 {format_instructions}
23 """,
24 input_variables=["user_info"],
25 # 把“图纸”的说明书（格式指令）插入到提示中
26 partial_variables={"format_instructions": parser.get_format_instructions()}
27)
28
29# 4. 创建模型并链接所有部分
30# model = ChatOpenAI(temperature=0)
31# chain = prompt | model | parser
32#
33# response = chain.invoke({"user_info": "创建一个用户，名叫李四，30岁，邮箱是 lisi@email.com，账户是活跃的。"})
34
35# 期望的 response 会是一个干净的 Python 字典，而不是字符串
36# print(response)
37#
38# 输出:
39# {'name': '李四', 'age': 30, 'email': 'lisi@email.com', 'is_active': True}

看到妙处了吗？通过定义UserProfile 这个 Schema，我们强制 AI 的输出符合我们预设的结构，让它的输出变得 100% 可预测和可用。

场景 3: 让 AI 使用我们定义的工具

假设你想让 AI 能够查询天气。AI 本身是不知道今天天气的，但你可以提供一个查询天气的函数（工具）给它。但是，AI 怎么知道这个函数是干嘛的？需要哪些参数？

LangChain 的 @tool 装饰器可以自动读取你函数的 “类型提示”(Type Hinting) 和文档字符串 (docstring)，并把它们变成一份 AI 能看懂的 “工具说明书”。

 1⚡ python片段# 伪代码，演示核心逻辑
 2from langchain_core.tools import tool
 3
 4@tool
 5def search_weather(city: str, unit: str = "celsius") -> str:
 6 """
 7 根据城市名称查询实时天气。
 8 :param city: 城市的名字，例如：北京
 9 :param unit: 温度单位，可以是 'celsius' (摄氏度) 或 'fahrenheit' (华氏度)
10 """
11 # 这里的代码会真实地去调用天气API
12 if city == "北京":
13 return f"北京现在的天气是 25°{unit}"
14 elif city == "上海":
15 return f"上海现在的天气是 28°{unit}"
16 else:
17 return f"抱歉，我查询不到 {city} 的天气。"
18
19# 当你把这个工具提供给一个支持工具调用的AI模型时，
20# LangChain会自动生成类似这样的“说明书”给AI看：
21# Tool Name: search_weather
22# Tool Description: 根据城市名称查询实时天气。
23# Tool Arguments:
24# - name: city, type: string, description: 城市的名字，例如：北京
25# - name: unit, type: string, description: 温度单位，可以是 'celsius' (摄氏度) 或 'fahrenheit' (华氏度)
26
27# 当你问AI：“北京今天天气怎么样？”
28# AI会分析你的问题，发现需要查询天气，然后查看它手上的“工具说明书”。
29# 它会找到 search_weather 工具，并自动生成调用参数：{"city": "北京", "unit": "celsius"}
30# 然后执行函数，得到结果，最后把结果用自然语言告诉你。

这里的 city: str 和 unit: str 就是 Schema 的一部分，它明确规定了工具需要什么类型的输入。文档字符串 “”"…""" 则成了 AI 理解工具功能的关键。

核心抽象组件

LangChain 的架构围绕以下几个基本抽象组件构建，这些抽象组件共同构成了 LangChain 的核心架构，让开发者能够快速构建复杂的 LLM 应用。每个组件都有明确的职责，通过 Runnable 接口相互连接，形成了一个强大而灵活的框架。

Language Models (语言模型)

提供文本生成、对话、推理等核心 AI 能力

●BaseLanguageModel: 所有语言模型的基类,它继承自 RunnableSerializable，并定义了语言模型交互的通用接口。它通过其 generate_prompt() 方法接受 PromptValue 对象。

●BaseChatModel: 对话模型（GPT-4、Claude）- 处理消息序列

●BaseLLM: 文本生成模型 - 处理字符串输入输出

Prompts (提示模板)

输入构造层，支持变量替换、少样本示例、消息格式化

●BasePromptTemplate: 动态构造模型输入

●ChatPromptTemplate: 构造对话消息序列

●PromptTemplate: 构造文本提示

Messages (消息)

对话交互的基本单元

●BaseMessage: 所有消息的基类

●HumanMessage: 用户消息

●AIMessage: AI 回复

●SystemMessage: 系统指令

●ToolMessage: 工具调用结果

Documents (文档)

知识存储的基本单元，是 RAG（检索增强生成）的基础数据结构

●Document: 包含 page_content（内容）和 metadata（元数据）

●用于表示任何文本数据：网页、PDF、数据库记录等

Retrievers (检索器)

知识检索层，RAG 架构的核心组件

●BaseRetriever: 是文档检索系统的抽象基类，它实现了 Runnable 接口以实现可组合性。它定义了基于查询检索相关文档的标准接口。

●连接向量数据库、搜索引擎、数据库等

Vector Stores (向量存储)

语义搜索的基础设施

●VectorStore: 向量数据库的抽象接口

●存储和检索文档的向量表示

●支持相似度搜索、混合搜索等

Embeddings (嵌入)

文本向量化，提供了嵌入模型的抽象接口，定义了将文本转换为向量表示的方法。它要求实现 embeddocuments() 和 embedquery() 方法。是语义搜索和相似度计算的基础。

●Embeddings: 将文本转换为向量表示

●支持各种嵌入模型（OpenAI、Hugging Face 等）

Output Parsers (输出解析器)

结构化输出，确保模型输出符合预期格式

●BaseOutputParser: 解析模型输出为结构化数据

●PydanticOutputParser: 解析为 Pydantic 模型

●JsonOutputParser: 解析为 JSON

Tools (工具)

BaseTool 是供智能体（Agents）使用的工具（Tools）的抽象基础，继承自 RunnableSerializable，并为与外部系统交互提供了标准化接口。是 Function Calling 和 Agent 的基础。

●BaseTool: 定义模型可调用的外部功能

●让模型能执行计算、查询数据库、调用 API 等

Callbacks (回调)

观察和控制执行流程，提供执行过程的可见性

●BaseCallbackHandler: 监听和响应执行事件

●用于日志记录、调试、监控、流式输出等

Memory/Cache (记忆/缓存)

状态管理，对话历史管理、会话状态保持

●BaseCache: 缓存 LLM 响应，避免重复调用

●BaseStore: 键值存储抽象

对照表

这里是一个快速对照表，来将上文的 LangChain 模块与核心抽象组件之间做个对应。

模块就像房间（客厅/厨房/卧室），抽象就像插座与标准接口（任意电器都能插上电并协同工作）。

●主要模块 = 按 “职能分区” 的功能板块（编排、模型、检索、Agent、记忆、部署等），回答 “系统里有哪些能力”。

●核心抽象 = 跨模块通用的接口 / 基类（如 Runnable、BaseChatModel、BaseRetriever…），回答 “各模块如何被替换与拼装”。

Agent

LangChain 框架完全可以构建 Agent，并且这是它自诞生以来最核心、最吸引人的功能之一。经典的 Agent（如 ReAct 范式）通过 AgentExecutor 实现一个 “思考 -> 行动 -> 观察” 的循环。LLM 在这个循环中扮演决策者，决定下一步调用哪个工具（Tool）。对于绝大多数单 Agent 任务，LangChain 的原生 Agent 完全够用。

但是，当 Agent 的逻辑变得极其复杂，例如：

1.需要循环和分支：当流程不是线性，而是需要在多个步骤之间来回跳转。

2.需要多 Agent 协作：例如，一个 “分析师 Agent” 生成报告，交给 “代码生成 Agent” 编写代码，再由 “测试 Agent” 进行验证，如果测试失败，流程需要返回给 “分析师 Agent” 重新分析。

3.需要持久化的状态管理：在复杂的交互中，需要精确控制每一步的状态。

这时 LangGraph 框架应运而生。它将 Agent 的工作流显式地定义为一个状态图 (State Graph)。每个节点是一个工作单元（一个 LLM 调用或一个工具调用），每条边是状态的转移。它不是取代了 LangChain Agent，而是为构建更强大、更可控的 “状态化 Agent 系统” 提供了新的范式。

LangGraph

LangGraph 可以独立使用，但它也可以无缝集成到任何 LangChain 产品中。

LangGraph 提供了比 LangChain 更底层、更灵活的控制能力，特别适合需要状态管理、人机协作和复杂流程编排的场景。而 LangChain 则更适合快速原型开发和简单的链式处理任务。两者可以协同使用：LangChain 的组件可以作为 LangGraph 的节点，但 LangGraph 也可以完全独立于 LangChain 使用。

如果不用 LangGraph 开发，选择其他框架，推荐使用 CrewAI。

LangGraph 架构

LangGraph 的执行流程遵循以下算法：

LangChain 与 LangGraph 适用场景对比：

LangChain 与 LangGraph 代码对比

LangChain（使用 AgentExecutor）:

 1⚡ python片段# pip install -U langchain langchain-openai
 2import os
 3from datetime import datetime
 4
 5from langchain_openai import ChatOpenAI
 6from langchain_core.tools import tool
 7from langchain_core.prompts import ChatPromptTemplate
 8from langchain.agents import create_tool_calling_agent, AgentExecutor
 9
10# ========== Tools ==========
11@tool
12def multiply(a: float, b: float) -> float:
13 """Return a*b."""
14 return a * b
15
16@tool
17def get_time(fmt: str = "%Y-%m-%d %H:%M:%S") -> str:
18 """Return current local time formatted by fmt."""
19 return datetime.now().strftime(fmt)
20
21tools = [multiply, get_time]
22
23# ========== LLM ==========
24llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
25
26# ========== Agent ==========
27prompt = ChatPromptTemplate.from_messages([
28 ("system", "You are a concise tool-using agent. Use the tools when helpful. Reply in Chinese."),
29 ("human", "{input}")
30])
31
32agent = create_tool_calling_agent(llm, tools, prompt)
33executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
34
35# ========== Demo ==========
36res = executor.invoke({
37 "input": "先用 multiply 计算 7×12，再调用 get_time 给出当前时间。答案只要一行。"
38})
39print("Final:", res["output"])

我来画出详细的流程图，展示这个 LangChain Agent 的执行过程：

LangGraph 代码：

 1⚡ python片段# pip install -U langgraph langchain langchain-openai
 2from datetime import datetime
 3from typing import Sequence
 4from typing_extensions import TypedDict
 5
 6from langchain_core.tools import tool
 7from langchain_core.messages import AnyMessage, HumanMessage
 8from langchain_openai import ChatOpenAI
 9
10from langgraph.graph import StateGraph, END # END 表示图的终点
11from langgraph.prebuilt import ToolNode, tools_condition # 预置的“工具节点”和“是否需要走工具”的路由函数
12
13# ===== 工具定义：用 @tool 自动生成 JSON Schema，便于模型函数调用 =====
14@tool
15def multiply(a: float, b: float) -> float: # 定义乘法工具
16 return a * b
17
18@tool
19def get_time(fmt: str = "%Y-%m-%d %H:%M:%S") -> str: # 定义获取时间工具
20 return datetime.now().strftime(fmt)
21
22tools = [multiply, get_time] # 工具列表（给模型/工具节点用）
23
24# ===== 绑定工具到模型：让 LLM 知道有哪些可调用的函数（工具） =====
25llm = ChatOpenAI(model="gpt-4o-mini", temperature=0).bind_tools(tools)
26# bind_tools(...) 的效果：
27# 1) 把 tools 的参数签名/描述转成 JSON Schema 给模型；
28# 2) 让模型在需要时产生 tool_calls（函数调用）结构，而不是直接“胡说答案”。
29
30# ===== 定义“状态”的数据结构：LangGraph 的节点之间传的就是这个 State =====
31classS(TypedDict):
32 messages: Sequence[AnyMessage] # 一串消息（人类/AI/工具消息），作为“对话上下文”
33
34# ===== 定义一个“模型节点”：输入 State，调用 LLM，输出一条 AI 消息 =====
35def agent_node(state: S):
36 # 关键：把现有 messages（含用户、人类消息、工具结果等）喂给 LLM
37 ai_msg = llm.invoke(state["messages"]) # 可能返回带 tool_calls 的 AIMessage
38 return {"messages": [ai_msg]} # LangGraph 会把这条消息合并到全局 state
39
40# ===== 搭建“有向图”：节点 + 边，决定执行路径 =====
41g = StateGraph(S) # 新建一个“状态图”，S 是状态类型（结构）
42
43# ——① 注册节点（起名叫 "agent" 和 "tools"）——
44g.add_node("agent", agent_node) # 把上面的函数包装成一个图节点
45g.add_node("tools", ToolNode(tools)) # 预置的工具节点：会读取 AI 的 tool_calls 并执行
46
47# ——② 设置“入口节点”：从哪个节点开始跑——
48g.set_entry_point("agent") # ★ 从 "agent" 开始（也就是先问一次模型）
49# 解释：这句相当于“第一步进图先走哪个节点”。如果不设，编译时会报错或不知道从哪开始。
50
51# ——③ 配置“条件边”：根据模型输出决定接下来走哪条边——
52g.add_conditional_edges(
53 "agent", # 从 "agent" 节点出来时
54 tools_condition, # 用预置的判断函数：看 AIMessage 是否包含 tool_calls
55 {"tools": "tools", "end": END} # 如果需要工具→去 "tools"；否则→直接结束
56)
57# 解释：tools_condition 会检查最新一条 AI 消息。
58# - 若模型产生了函数调用（tool_calls），返回路由键 "tools"
59# - 若没有需要的工具调用，返回路由键 "end"
60# 这行把路由键映射为真正的边：“tools”→去 tools 节点，“end”→走到 END（图的终点）。
61
62# ——④ 把工具节点执行完后的边接回“agent”，形成闭环——
63g.add_edge("tools", "agent")
64# 解释：当 tools 节点执行完所有函数调用，会把结果（ToolMessage）追加到 state.messages，
65# 然后回到 "agent" 再问一次模型。直到模型不再发起新的 tool_calls。
66
67# ——⑤ 编译成可运行的“应用”对象——
68app = g.compile()
69# 解释：compile() 会把上面定义的节点/边/合并策略等打包成可执行的图（可 invoke/stream）。
70
71# ===== 运行：给一条人类消息，按图的“入口节点”开始执行 =====
72final = app.invoke({
73 "messages": [HumanMessage(content="先用 multiply 计算 7×12，再调用 get_time 报当前时间。只要一行中文。")]
74})
75# 解释：invoke 会：
76# step1: 进入入口 "agent" → LLM 读到 HumanMessage，判断要不要调用工具；
77# step2: 如果需要工具 → 路由到 "tools" 执行（得到 ToolMessage）→ 回到 "agent"；
78# step3: 重复 step1~2，直到不需要工具 → 按条件边路由到 END → 返回最终状态。
79
80print(final["messages"][-1].content) # 打印最后一条 AI 的自然语言回复

LangGraph 详细执行流程：

竞品

如果不使用 LangChain 开发 AI/LLM 应用，以下是主要的替代框架选择：

以下是按要求整理的表格内容：

框架	定位/标签	语言/平台	核心优势关键词	典型场景	🔎RAG	👥Agent	🏢企业	🎯输出控制	🪶轻量
LlamaIndex	RAG 与数据检索专家	Py/TS	多索引策略、查询路由、强检索、结构/非结构数据	知识库问答、文档分析、RAG	★★★★★	★★☆☆☆	★★★☆☆	★★☆☆☆	★★★☆☆
CrewAI	多智能体团队协作	Py	角色/任务、顺序/并行/层级协作、社区活跃	多智能体系统、内容流水线、任务分解	★★☆☆☆	★★★★★	★★★☆☆	★★☆☆☆	★★★☆☆
Semantic Kernel	企业级 AI 编排	C#/Py/Java	技能/规划器、Azure 深度集成、微软背书	企业应用、复杂规划、微软技术栈	★★★☆☆	★★★☆☆	★★★★★	★★☆☆☆	★★☆☆☆
Haystack	NLP/搜索系统专家	Py	Pipeline 清晰、文档处理强、评测完善、重隐私	QA 系统、语义搜索、信息抽取	★★★★☆	★★☆☆☆	★★★★☆	★★☆☆☆	★★★☆☆
AutoGen	自动化对话与代码生成	Py	代码生成/执行、多 Agent 对话、自动化流程、人机协作	代码生成、数据分析自动化、技术任务	★★☆☆☆	★★★★☆	★★★☆☆	★★☆☆☆	★★★☆☆
Guidance	精确输出控制	Py	模板语言、强格式约束、轻量高效	结构化输出、格式化生成、提示工程	★☆☆☆☆	★☆☆☆☆	★★★☆☆	★★★★★	★★★★☆

还有一些新兴 / 特色框架：

以下是按要求整理的表格内容：

框架	定位/标签	语言/平台	核心优势关键词	典型场景	🔎RAG	👥Agent	🏢企业	🎯输出控制	🪶轻量
LiteLLM	统一 LLM API	Py	100+ 模型统一接口、超轻量、零依赖	简单 LLM 调用、多模型切换、原型	★☆☆☆☆	★☆☆☆☆	★★★☆☆	★★☆☆☆	★★★★★
DSPy	声明式/自动提示优化	Py	可学习模块、自动调参、学术完善	指标导向优化、研究/实验	★★★☆☆	★★☆☆☆	★★☆☆☆	★★★☆☆	★★★☆☆
txtai	轻量 Transformers 框架	Py	HF 生态、内置向量库、性能好	轻量语义搜索、嵌入式应用	★★★☆☆	★☆☆☆☆	★★☆☆☆	★★☆☆☆	★★★★☆
MetaGPT	“AI 软件公司”模拟	Py	角色分工、项目级生成、代码产出	自动化软件开发、代码生成	★☆☆☆☆	★★★★☆	★★☆☆☆	★★☆☆☆	★★☆☆☆

在实际开发中，如不用 LangChain，选型范围会缩小到最流行的几个竞品，比如：

●🦙 LlamaIndex：原名 GPT-Index，是一个开源的数据框架，专门用于构建大型语言模型 (LLM) 应用。它主要解决了如何将 LLM 与外部数据有效连接的问题，使开发者能够创建更强大的知识密集型应用。

●🚢 CrewAI：多智能体团队协作框架，CrewAI 是一个轻量、快速的 Python 框架，完全从零构建，与 LangChain 或其他代理框架完全无关。它为开发者提供高级别的简洁性和精确的底层控制，非常适合创建适用于任何场景的自主 AI 代理。

●🔧 Haystack：一个端到端的大型语言模型（LLM）框架，它允许你构建由 LLM、Transformer 模型、向量搜索等功能驱动的应用程序。

●🚀 AutoGen：用于创建能够自主行动或与人类协作的多智能体AI应用的框架

需要注意的是：这些框架不是互斥的，可以组合使用（如 LlamaIndex + CrewAI）

常见陷阱与挑战

抽象泄漏 (Leaky Abstraction)

定义: 一个 “抽象” 旨在隐藏底层实现的复杂性。当这个抽象无法完全隐藏底层细节，导致你必须理解底层是如何工作的才能正确地使用它或排查问题时，就发生了 “抽象泄漏”。

LangChain 中的具体例子 (以旧版的 RetrievalQA 链为例):

●美好的抽象: RetrievalQA 链看起来很简单，你只需要给它一个 llm 和一个 retriever，它就能帮你完成 RAG。你期望它能 “神奇地” 工作。

●泄漏的现实:

a.Prompt 在哪里？你发现问答效果不好。为什么？因为 RetrievalQA 内部使用了一个默认的、隐藏的 Prompt 模板 (类似 “Use the following pieces of context to answer the user’s question…")。这个默认模板可能不适合你的模型（比如某些中文模型），或者不符合你的业务场景。

b.文档如何组合？当 retriever 返回了 4 个文档块 (Chunks) 时，这些文档是如何被塞进最终的 Prompt 里的？是简单拼接吗？如果超过了模型的上下文窗口怎么办？RetrievalQA 有一个 chaintype 参数（如 stuff, mapreduce）来控制这个行为。

问题的根源: 为了解决上述问题，你被迫去阅读 LangChain 的源码，去理解 RetrievalQA 内部隐藏的 Prompt 和文档组合逻辑。这时，RetrievalQA 这个本应让你省心的 “高级抽象”，反而成了你理解和调试的障碍。抽象 “泄漏” 了底层的实现细节。

如何应对？

拥抱 LCEL: LCEL 在很大程度上解决了这个问题。通过 prompt | model | parser 的方式， Prompt 是显式的，数据流是清晰的。你可以完全控制每一个环节，没有 “魔法” 和隐藏的逻辑。这是一种更 “白盒” 的构建方式，虽然初看起来代码多了一点，但可控性和可调试性大大增强。当然还有一种方案就是 “取其精华，去其糟粕”，LangChain 框架引入后，只用必要的部分组件，其余需要灵活处理的部分，全手写。

调试的 “黑盒感”

问题: 链的最终输出不符合预期，但中间过程完全不可见，不知道是 Prompt 错了、检索出的文档错了，还是模型理解错了。

解决方案: LangSmith。这是解决此问题的标准答案。设置环境变量 LANGCHAINTRACINGV2=“true” 即可开始追踪。用不了 LangSmith 的话，也可以用开源的 langfuse 替代。

对简单任务过度设计

问题: 你的任务只是需要根据一个模板调用一次 OpenAI API。这种情况下，引入 LangChain 的 LLMChain 相比直接使用 openai 库的 client.chat.completions.create()，增加了不必要的复杂性。

解决方案: 保持务实。如果你的应用逻辑非常简单，就是一个单一的 LLM 调用，那么直接使用原生 SDK 可能更清晰、更轻量。当且仅当你需要编排多个步骤（如 RAG）、管理记忆、或使用 Agents 时，LangChain 的价值才能最大化。

LangChain 的版本演进

v1.0 alpha：和 v0.x 的关键差异

v1.0 alpha（2025-09）是 LangChain 的一次 “面向长期” 的大改版

核心变化

●消息模型统一：新增 .content_blocks（标准化的 “内容块” 视图），把不同厂商的 “推理、引用、服务端工具调用、多模态” 等表示成同一种类型，减少 provider 差异带来的胶水代码；对旧 .content 后向兼容。

●Agent 重心调整：create_agent() 成为默认入口，底层基于 LangGraph 的图式运行时（持久化、流式、人审 / 中断、错误处理更规范）。

●包面积极度收敛：langchain 更聚焦 “标准接口 + 预置 Agent / 链”；历史面迁到 langchain-legacy，便于兼容老代码再慢慢重构。

●默认行为与平台要求：

○Python 需 ≥3.10；Chat 模型返回类型固定为 AIMessage；OpenAI Responses API 的默认输出版本调整（可用 LCOUTPUTVERSION=v0 退回）；Anthropic max_tokens 默认值上调。

○JS / TS 侧：核心原语（createAgent、ToolNode、tool、消息类型）直接从 langchain 导出；Node.js 需 ≥20；大量老子路径导出清理。

三个常见场景

1.“会用工具、可结构化返回” 的 Agent

v0.x（典型写法）：构建 Agent + Executor，再自己管结构化解析 / 二次调用

 1⚡ python片段# 旧式（示意）：AgentExecutor + 自行处理结构化输出
 2from langchain_openai import ChatOpenAI
 3from langchain.agents import AgentExecutor, initialize_agent
 4from pydantic import BaseModel
 5
 6class Weather(BaseModel):
 7 temperature: float
 8 condition: str
 9
10llm = ChatOpenAI(model="gpt-4o-mini")
11tools = [get_weather]
12
13agent = initialize_agent(tools, llm, agent="zero-shot-react-description")
14result = agent.run("What's the weather in SF?")
15# 再用正则/二次调用或手写解析把 result 转成 Weather(...)

v1.0 alpha（新写法）：一个入口 create_agent，在主循环里直接产出结构化结果（避免多一次 LLM 调用、少走弯路）

 1⚡ python片段from langchain.agents import create_agent
 2from pydantic import BaseModel
 3
 4class Weather(BaseModel):
 5 temperature: float
 6 condition: str
 7
 8agent = create_agent(
 9 "openai:gpt-4o-mini", # 也可传入已实例化 model
10 tools=[get_weather],
11 response_format=Weather # 结构化输出内建
12)
13out = agent.invoke({"messages": [{"role": "user", "content": "Weather in SF?"}]})
14print(out["structured_response"]) # -> Weather(...)

2.“跨厂商、多模态/推理/引用” 的消息处理

v0.x：不同厂商字段名不同（如 reasoning、thinking、citations、server tool 等），常见一堆 if provider == … 的分支。

v1.0 alpha：直接读 .content_blocks（统一、强类型），必要时再序列化回标准块。

1⚡ python片段from langchain_core.messages import AIMessage
2
3msg = some_llm.invoke("Explain with sources & brief reasoning")
4# v1 统一读取：
5for block in msg.content_blocks:
6 if block["type"] == "reasoning":
7 use_reasoning(block["reasoning"])
8 if block["type"] == "text" and "annotations" in block:
9 use_citations(block["annotations"])

3.“工具错误/人审/长对话摘要” 的生产级控制

v0.x：这些能力多靠自写回调或外层控制流拼起来。

v1.0 alpha：内置 Middleware 三钩子（beforemodel / modifymodelrequest / aftermodel）+ 现成中间件（摘要、人审、Anthropic Prompt Caching），还能 “跳转 / 中断”。

 1⚡ python片段from langchain.agents import create_agent
 2from langchain.agents.middleware import SummarizationMiddleware, HumanInTheLoopMiddleware
 3
 4agent = create_agent(
 5 "openai:gpt-4o",
 6 tools=[...],
 7 middleware=[
 8 SummarizationMiddleware(max_tokens_before_summary=4000),
 9 HumanInTheLoopMiddleware(tool_configs={"write_file": {"allow_approve": True}})
10 ],
11)

LangSmith 🦜️⚒️

●解决 LLM 应用开发中最头疼的调试、追踪和评估问题，这是其商业化的核心（收费）。一个应用越复杂，就越离不开 LangSmith，形成用户粘性。

●LangSmith = LLM 应用的 “一体化可观测 + 评测平台”：用来给 Agent / RAG / 多模态应用做全链路追踪（Tracing）、离 / 在线评测（Evals）、监控告警、成本与时延看板、Prompt 协作等；既可配合 LangChain / LangGraph，也支持非 LangChain 项目、OTEL 接入。

可以开源免费的 langfuse 替代 LangSmith

LangServe 🦜️🏓

●打通 “最后一公里”，让开发者能一键将用 LangChain 构建的应用 API 化

●LangServe 可以把 LangChain 的 Runnable/Chain 一键暴露成 REST API 的开源库，基于 FastAPI + Pydantic，自带 /invoke、/batch、/stream、/streamlog、/streamevents 等端点、自动推断 I / O Schema、内置 Playground，并可把追踪接到 LangSmith

收费吗？

库本身不收费。但其许可证限制：不得把 LangServe 作为托管 / 托管式服务提供给第三方（SaaS）。也就是说，你可以用它部署自己的应用，但不能把 “LangServe 平台” 卖给其他公司用。另外，LangChain 官方更推荐新项目用 LangGraph Platform（LangServe 只接受社区 bug 修，不再收新特性）。如果要 “托管式平台”，那是另一条产品线（付费）

LangChain 的使用争议

关于 LangChain 最开始的时候是一片盛赞，几乎全是正面评价，但随着开发者使用的深入，不断有负面评价出现。

LangChain 在使用上的主要争议，或者说让开发者后来“抛弃” 它的主要原因有：

1.API 频繁改、文档滞后，维护成本高

○2023–2025 年间最常见吐槽：接口 / 导入路径经常变、语义化版本执行不严、文档跟不上，导致线上项目要反复改代码与迁移；社区讨论与帖子里这一点重复被提及。官方后来在 0.2 才引入 “版本化文档”以缓解这个痛点。Reddit

2.抽象层过重/“抽象泄漏”

○本来想简化 LLM 应用，但层层抽象（Chains/Agents/Memory/Tools…）让简单事变复杂；当跨供应商（OpenAI/Anthropic）或多模态/工具调用时，还是要理解底层差异并写分支，抽象并未完全 “挡住细节”，很多人因此更倾向 “直接调 API / 自己拼装”。

3.性能 / 成本开销与 “隐形调用”

○经验帖里常见：token 使用低效、默认批量/重试/校验带来额外请求与延迟；默认设置偏原型友好，不一定适合生产（缓存、批处理、上下文裁剪都要自己细调）。DEV Community

4.调试与可观测性难（不用配套工具时）

○没接追踪时，多层封装中的报错 / 耗时难以定位，“像在雾里调试”；不少团队因此上了自家的可观测或放弃高阶封装。

5.学习曲线与 “过度框架化”

○许多工程团队反映：学习成本与收益不匹配，做简单的 RAG / 工作流时，直接 SDK + 少量自写代码更快可控；把 LangChain 当工具库（utility）用反而更顺。

6.生态分拆、选择困难与 “框架漂移”

○LangChain/ LangGraph/ LangServe/ LangSmith 产品边界不断演进；多数对比文章建议：流程化任务用 LangChain，复杂状态 / 多轮 agent 用 LangGraph—— 很多团队索性选更贴合场景的替代或 “手写”。DEV Community

上面这些点，不是说 LangChain “不能用”，而是在规模化、稳定性要求高的团队里，可预期性 / 可控性往往比 “快速堆组件” 更重要。

负面评价

这里我引用一些具体的负面评价，通过开发者真实的体验和文章来了解一下 LangChain 的问题。

为什么我们不再使用 langchain 来构建我们的AI代理

●来源： https://octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents

●结论：作者最初喜欢 LangChain 因为其丰富组件和易用性，但后来因其抽象复杂、灵活性差而不推荐。

初期为何喜欢使用 LangChain

作者在项目初期选择 LangChain，主要因为它具备以下优点：

●丰富的工具和组件：LangChain 提供了大量现成的模块，能快速搭建 LLM 应用。

●易于集成：框架承诺“让开发者一个下午就能从想法变成可运行代码”，适合原型开发和快速试错。

●人气高、社区活跃：2023 年 LangChain 热度很高，生态完善，容易找到资料和支持。

这些特性让作者在项目早期能专注于业务逻辑，而不用过多关心底层实现细节。

后期为何不再推荐 LangChain

随着项目复杂度提升，作者逐渐发现 LangChain 带来的问题：

1.抽象层级过多，代码复杂

○LangChain 引入了大量抽象（如 Prompt 模板、输出解析器、链等），让简单任务变得繁琐。

○代码难以理解和维护，调试时需要花大量时间研究框架内部逻辑。

2.灵活性不足，难以定制

○框架对底层细节封装过度，开发者很难根据实际需求修改或扩展功能。

○当需求超出 LangChain 设计假设时，反而成为限制，必须“将需求转化为适合 LangChain 的方案”，而不是直接实现业务逻辑。

3.适应快速变化的 AI 领域能力有限

○AI 和 LLM 领域变化极快，LangChain 的抽象和设计难以跟上新技术和新需求。

○框架的“嵌套抽象”导致开发者需要理解庞大的堆栈和内部机制，增加了认知负担。

4.团队协作和维护成本高

○团队成员需要花大量时间理解和调试 LangChain，而不是专注于功能开发。

○框架的复杂性让代码维护变得困难，影响开发效率。

反思与建议

作者认为，虽然 LangChain 在原型阶段有用，但长期来看，直接用基础库（如 OpenAI API）开发更简单、灵活。大多数 LLM 应用只需少量核心组件，无需复杂框架。对于 AI Agent 等复杂场景，建议在 Agent 模式成熟前保持简单，避免过度依赖抽象。

“一旦我们删除了它，我们就不再需要将我们的需求转化为适合 LangChain 的解决方案。我们只需编写代码即可。”

作者的经历体现了技术选型中“早期便利 vs. 长期灵活性”的权衡，也反映了 AI 应用开发领域对“抽象与简单”的持续思考。

2025 年了，LangChain 还是个无底洞。

https://www.reddit.com/r/LocalLLaMA/comments/1iudao8/langchainisstillarabbitholein_2025/?tl=zh-hans

给研发团队的建议

●“轻 LangChain”：保留少量 LCEL/Runnable 原语（或只用部分解析 / 工具封装），核心链路直接用供应商 SDK 实现，减少抽象层。

●“换轨到 LangGraph”：涉及复杂状态/长对话/人审/错误恢复的 agent，改用图式运行时（LangGraph / 其他工作流框架）。

●“专用 RAG 框架 / 自研”：检索、重排、结构化输出走 LlamaIndex / 自研管线

总之，手写代码是一条自主可控的道路，而梭哈 LangChain 可能会是一条不归路。

从初始化一个现代 python 项目中学习到的东西

Sun, 27 Apr 2025 06:57:05 +0000

uv

我准备用 uv 初始化一个 python 项目

环境

我用的是苹果笔记本 MacBookPro ，具体的操作系统及硬件参数如下：

uv 的介绍与安装

“

uv 是一个使用 Rust 编写的工具，可以用来替代 pip、pipenv、pipx、poetry、virtualenv 等工具的使用，甚至还可以用来管理系统中所安装的 Python 发行版。uv 借鉴了很多现代语言中对于项目依赖的管理方式，项目中对于依赖的管理要远远优于使用 pip 和requirements.txt的方式。

我之前用过 pip 、pipx 等工具，发现 uv 确实要快不少。具体有多快呢？ github 上有个图：

🚀速度比传统 pip 快 10-100倍。

根据官网的介绍，uv 主要支持以下功能：

支持版本锁定的项目依赖管理。
支持直接运行 Python 脚本。
支持对系统中安装的 Python 进行管理，支持多版本 Python 共存。
支持 Python 包的发布和安装。
支持兼容 pip 的应用接口。
支持 Cargo 模式的项目工作区管理。
更优化的全局支持库缓存。
运行无需 Rust 或者 Python 支持。
支持 Windows、macOS 和 Linux 系统

uv 对多 python 版本和环境的管理很不错，这样你就可以一个项目指定一个特定的 Python 版本，放心使用，想怎么折腾怎么折腾，不会影响全局。

最近比较火的 MCP 很多也是用 uv 运行的，因为用 uv 命令可以直接运行 python 脚本。

uv 的安装非常简单：

1# macOS和Linux
2curl -LsSf https://astral.sh/uv/install.sh | sh
3
4# Windows PowerShell
5powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

uv 对 Python 的环境管理

首先用 uv 管理一下我们本机安装的 Python 环境。即到底安装了几个、哪些版本的 python。

可以用 uv python list 查看，像这样：

可以看到我已经安装了多个版本的 python。在后面建项目的时候，我选用 3.13 这个版本。当然你也可以根据你的情况下载新的需要使用的版本。这里给出一组相关命令：

1uv python install，安装指定版本的 Python。
2uv python list，列出系统中当前已经安装的 Python 版本。
3uv python find，查找一个已经安装的 Python 版本。
4uv python pin，固定当前项目使用指定的 Python 版本。
5uv python uninstall，卸载指定版本的 Python。

比如我要安装 3.12 这个版本，我就可以这样：

1uv python install 3.13

装好了不想要了，就可以这样卸载掉它：

1uv python uninstall 3.13

uv 进行项目管理

python 的环境有了以后，我们就可以新建项目了，建项目的时候也要用 uv 来进行初始化。

“

uv 的项目管理功能更多的借鉴了 Rust 中 Cargo 工具的项目管理理念。但主要区别是 uv 是通过项目目录中的pyproject.toml文件来完成项目管理的。

1uv init myproject

初始化后会生成以下几个文件：

虽然 uv init myproject 会帮你创建项目目录和 pyproject.toml，但默认不会自动创建虚拟环境（env），所以我们需要手动创建。

1# 手动创建虚拟环境
2uv venv --python 3.13
3# 激活虚拟环境
4source .venv/bin/activate

虚拟环境激活后，项目中会多一个.venv 文件夹。

接下来我们要自己创建一下源码目录和测试目录：

1mkdir -p src tests

到这里工程的相关目录我们就先到此为止，基本上创建完了，然后我们来编辑

pyproject.toml 配置文件。

toml 配置文件

我们先介绍一下 toml 文件，可能有些朋友不怎么了解它，比如搞 java 开发的。

TOML（Tom’s Obvious, Minimal Language）是一种配置文件格式，设计目标是易读、易写、易于解析，非常适合作为程序的配置语言，尤其是在现代的跨平台开发中被广泛采用。

你看这名字是不是觉得肯定跟 Tom 大哥有关系？

对，因为 TOML 由 GitHub 联合创始人 Tom Preston-Werner 在 2013 年发起，用以替代 JSON、INI 等配置格式在可读性和灵活性上的不足。

不过吧，后来这大哥（和她媳妇）不在 GitHub 干了，因为他们的一些不光彩的行为。具体是什么就不多说了，想八卦一下的可以去查查。

toml 配置文件用途广泛，常用于以下场景：

应用程序运行时配置
包管理工具（如 Python 的 pyproject.toml、Rust 的 Cargo.toml）
构建工具配置（如 poetry.toml, uv.toml）
数据库或服务连接信息等环境参数配置

举个例子吧：

 1# 数据库配置
 2[database]
 3server = "192.168.1.1"
 4ports = [ 8001, 8001, 8002 ]
 5enabled = true
 6
 7# 应用信息
 8[app]
 9name = "MyApp"
10version = "1.0.0"
11release_date = 2025-04-25T12:00:00Z

TOML 的特点可以总结为：

“

“比 JSON 更适合人读，比 YAML 更适合程序解析。”

它已经成为现代软件开发中最流行的配置文件格式之一，特别是在需要 清晰结构 + 丰富类型 + 可维护性 的场景中表现出色。

常见语言的支持情况：

Python：tomli / toml / pytoml / tomllib（Python 3.11 原生支持）
Rust：官方包管理工具 Cargo 就使用 TOML 格式的 Cargo.toml
Go：支持 BurntSushi/toml 库
Node.js：支持 @iarna/toml 等多个库

常见用途：

Python 包管理：pyproject.toml（PEP 518 标准）
Rust 项目管理：Cargo.toml
Web 项目配置：netlify.toml
DevOps 工具：例如 uv 的配置也是用 toml 文件

TOML 与其他格式的对比：

特性	TOML	JSON	YAML	INI
可读性	✅ 高	中	中高（但复杂）	中
注释支持	✅ 支持	❌ 不支持	✅ 支持	✅ 支持
数据类型支持	✅ 多	✅ 多	✅ 多	❌ 有限
库支持	✅ 常见语言皆支持	✅ 全面	✅ 全面	✅ 较好
学习曲线	✅ 低	✅ 低	❌ 偏高	✅ 极低

你看，TOML 作为配置文件感觉很不错对吧。

我们关于 TOML 的介绍就到此为止，现在来说一下我们这个初始化的新项目中的 pyproject.toml 文件要写成什么样。

就这样：

 1[build-system]
 2requires = ["hatchling"]
 3build-backend = "hatchling.build"
 4
 5[project]
 6name = "myproject"
 7version = "0.1.0"
 8description = "一个基于Python 3.13.3的项目"
 9readme = "README.md"
10requires-python = ">=3.13"
11authors = [
12 {name = "xiaobox", email = "xiaobox@gmail.com"}
13]
14dependencies = [
15 "pytest>=7.4.3",
16 "fastapi>=0.110.0",
17 "uvicorn>=0.27.0",
18 "httpx>=0.27.0",
19]
20classifiers = [
21 "Programming Language :: Python :: 3.13",
22 "License :: OSI Approved :: MIT License",
23 "Operating System :: OS Independent",
24]
25
26[project.scripts]
27myproject = "src.main:main"
28
29[project.urls]
30"Homepage" = "https://github.com/yourusername/myproject"
31"Bug Tracker" = "https://github.com/yourusername/myproject/issues"
32
33[project.optional-dependencies]
34dev = [
35 "black>=23.1.0",
36 "isort>=5.12.0",
37 "mypy>=1.5.1",
38]
39
40[tool.pytest]
41testpaths = ["tests"]
42
43[tool.black]
44line-length = 88
45target-version = ["py313"]
46
47[tool.isort]
48profile = "black"
49line_length = 88
50
51[tool.hatch.build.targets.wheel]
52packages = ["src"]

别小看了这个文件，它可是一个使用了 Hatch 构建工具、遵循 PEP 621 和现代 Python 项目结构规范的项目配置，涵盖了运行依赖、开发依赖、CLI 脚本、格式化工具配置、测试路径和打包目标，非常完整规范。

所以我们得逐行解释一下这个重要的文件。

toml 配置文件的逐行解释

我们上面的配置文件是一个标准的 Python 项目使用 pyproject.toml 来管理构建系统、依赖、工具配置的典型示例。下面我们来拆解和解释一下。

✅ [build-system]：构建系统配置（PEP 517 标准）

1[build-system]
2requires = ["hatchling"]
3build-backend = "hatchling.build"

requires：构建该项目所需的构建工具，这里是 hatchling，必须先安装。
build-backend：指定用哪个构建后端来执行打包任务，这里是 hatchling.build。

hatchling 有点儿类似 java 中的 Maven 或 Gradle，都是用来执行自动化构建流程的。

Maven 是把 java 代码编译、构建成 jar 包，方便管理依赖、分发、版本控制
hatchling 是把 python 代码构建成 Wheel（.whl 文件）或 Source Distribution（.tar.gz 或 .zip 文件），也是为了做依赖管理、分发和版本控制。

总结来说：Python 的构建是将代码和依赖打包成 .whl 或 .tar.gz，类似于 Java 打包成 .jar。核心目的是简化分发、确保环境一致性、自动化依赖管理。

✅ [project]：项目的核心元信息（PEP 621 标准）

1[project]
2name = "myproject"

项目名称，最终发布到 PyPI 时会用这个名字。

1version = "0.1.0"

当前版本号。

1description = "一个基于Python 3.13.3的项目"

简短的项目说明。

1readme = "README.md"

指定项目的 README 文件，将作为 PyPI 上项目首页的介绍内容。

1requires-python = ">=3.13"

要求的 Python 版本最低为 3.13。

1authors = [
2 {name = "xiaobox", email = "xiaobox@gmail.com"}
3]

作者信息，支持多个，用列表表示。

1dependencies = [
2 "pytest>=7.4.3",
3 "fastapi>=0.110.0",
4 "uvicorn>=0.27.0",
5 "httpx>=0.27.0",
6]

项目的运行时依赖库，在安装时会自动安装这些包。这里我加入了 pytest、fastapi 的依赖，因为我想把这个项目作为一个 api 服务提供出去。

1classifiers = [
2 "Programming Language :: Python :: 3.13",
3 "License :: OSI Approved :: MIT License",
4 "Operating System :: OS Independent",
5]

用于 PyPI 分类（帮助搜索和筛选）。

✅ `[project.scripts]`：定义可执行命令（如 CLI）

1[project.scripts]
2myproject = "src.main:main"

安装后运行 myproject 命令会调用 src/main.py 中的 main() 函数。（我们需要提前把之前的 main.py 文件要先移动到 /src 目录下）

✅ `[project.urls]`：项目的相关链接（非必须）

1[project.urls]
2"Homepage" = "https://github.com/yourusername/myproject"
3"Bug Tracker" = "https://github.com/yourusername/myproject/issues"

为项目指定一些有用的链接，如主页、问题反馈页等。

✅ `[project.optional-dependencies]`：可选依赖（比如开发环境）

1[project.optional-dependencies]
2dev = [
3 "black>=23.1.0",
4 "isort>=5.12.0",
5 "mypy>=1.5.1",
6]

我们为开发环境安装了三个库：black、isort 和 mypy

介绍一下这三个工具

black：是一个 Python 代码格式化工具。自动把你的 Python 代码排版成统一风格，比如：缩进、换行、空格都按标准格式处理，让你的 Python 代码看起来更整齐、统一，无需自己动手排版。
isort：是一个 Python 导入（import）语句自动排序工具。自动整理文件顶部的 import 语句，比如按字母顺序排列，分组标准库、第三方库、自定义模块，保持导入部分有序且规范。
mypy：是一个 Python 静态类型检查工具。检查你的代码里的类型注解（type hints）是不是正确，比如函数参数和返回值类型对不对，帮你在写代码时发现类型出错的地方，提前避免 bug。

✅ `[tool.pytest]`：Pytest 配置

1[tool.pytest]
2testpaths = ["tests"]

指定测试用例所在路径，pytest 会从 tests/ 目录开始查找测试文件。

✅ `[tool.black]`：代码格式化工具 Black 的配置

1[tool.black]
2line-length = 88
3target-version = ["py313"]

设置代码的行最大长度为 88（默认值），目标 Python 版本是 3.13。

✅ `[tool.isort]`：import 排序工具 isort 的配置

1[tool.isort]
2profile = "black"
3line_length = 88

使用 black 的风格对 import 排序。
设置行长度为 88，与 black 保持一致。

✅ `[tool.hatch.build.targets.wheel]`：Hatchling 打包配置

1[tool.hatch.build.targets.wheel]
2packages = ["src"]

指定打包时要包含的代码目录为 src。

用一句话总结下这个 pyproject.toml 配置文件：

“这是一个使用 Hatch 构建工具、遵循 PEP 621 和现代 Python 项目结构规范的项目配置，涵盖了运行依赖、开发依赖、CLI 脚本、格式化工具配置、测试路径和打包目标，非常完整规范。”

安装和更新依赖

上面这个文件编辑完成后，我们就可以安装项目和开发依赖了：

1uv pip install -e ".[dev]"

如果后面你更新了 pyproject.toml 文件可以执行以下命令来 “手动刷新” 一个依赖库：

1uv sync --extra dev

加入 --extra dev 参数是因为 uv sync 默认只安装 [project.dependencies] 中列出的正式依赖。

不会自动安装 [project.optional-dependencies]（比如 dev 里面的 black、isort、mypy）

uv sync --extra dev 的意思是：除了正式依赖，还要把 [project.optional-dependencies.dev] 里的东西也同步上

uv.lock

当执行完 uv sync --extra dev ，安装好依赖好， uv 会在项目根路径生成一个 uv.lock 文件。uv.lock 是锁定依赖版本的文件。

它的作用是：把 pyproject.toml 里描述的依赖（比如 “fastapi>=0.110.0” 这样比较宽松的范围），具体锁定成明确、唯一的版本（比如 “fastapi==0.110.1”）。

这样，每次安装时，不管谁来安装（你自己、你的同事、你的服务器），大家安装的依赖版本都是一模一样的，不会因为小版本不同导致奇怪的 bug。

uv.lock 是自动生成、自动管理的。不需手动编辑。

其他

其他的，如 fastapi 相关的、打 docker 镜像部署什么的相对本文主题超纲了，就不在本文中过多描述了。

总结

本文我们分享了用 uv 初始化和管理 Python 项目的完整流程。

从安装 uv 开始，我介绍了它为什么比传统工具（pip、pipx、poetry 等）更快更好用，以及 uv 在多 Python 版本管理、依赖锁定、项目初始化方面带来的便利。

随后，详细讲了如何用 uv 管理本地 Python 环境、新建项目、创建虚拟环境、编辑 pyproject.toml 配置，并逐步解释了各个配置项的作用

整体来看，uv 提供了一套现代、规范、高效的 Python 项目管理方案，非常适合用来打基础，后续无论是开发 API、打包 Docker 镜像，还是部署上线，都能有条不紊地进行。

同时我们通过在项目创建的过程中看到各语言（java、nodejs…）都相通或类似的工程 “最佳实践”，真是应了那句话：“大道至简，真理趋同”

数据库选型终极指南：从数据类型到应用场景，一篇就够了

Fri, 14 Mar 2025 09:19:52 +0000

引言

在当今的数字化时代，数据已成为企业和组织的核心资产。无论是金融交易记录、社交媒体互动、物联网传感器数据，还是企业内部的业务流程信息，都需要通过数据库进行存储、管理和分析。然而，面对市场上数十种主流的数据库技术（如 MySQL、MongoDB、Elasticsearch、HBase、Hive等），如何选择适合自身业务需求的数据库系统，成为许多技术决策者面临的难题。本文将深入探讨数据库的核心分类、技术特性、应用场景以及选择策略，帮助读者构建系统化的选型框架。

数据库的分类

在进行数据库的选择前，你需要至少知道它的分类。

在数据库技术的演进过程中，数据存储模型和应用需求的多样性催生了不同类型的数据库系统。这些系统根据其核心设计理念、数据组织方式以及适用场景的差异，形成了多个分类。

关系型数据库（RDBMS）：结构化数据的基石

关系型数据库的根基是关系代数和集合论，通过二维表（Table）组织数据。每个表由行（记录）和列（字段）构成，通过主键（Primary Key）唯一标识记录，外键（Foreign Key）实现表间的关联。其核心优势在于ACID事务支持，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），适用于对数据一致性要求极高的场景（如金融交易）

适用场景：

需要强一致性的业务系统（银行核心系统、ERP）。
多表关联查询频繁的OLTP（联机事务处理）场景（电商订单管理）

局限性：

表结构预定义，修改成本高（如新增字段需 ALTER TABLE）。
水平扩展困难，分库分表复杂度高（需处理分布式事务和跨分片查询）。
不适合存储半结构化数据（如JSON文档、嵌套数组）。

代表数据库：MySQL、PostgreSQL、Oracle、SQL Server

NoSQL 数据库：灵活性与扩展性的革命

NoSQL（Not Only SQL）的诞生是为了解决关系型数据库在扩展性、灵活性和高性能场景下的不足。根据数据模型的差异，NoSQL 可进一步细分为四类：

1. 文档型数据库（Document Database）

数据模型：以文档为基本单元，通常采用JSON或BSON格式存储，支持嵌套结构和动态字段

1{
2 "user_id": 101,
3 "name": "张三",
4 "orders": [
5 {"order_id": 2001, "amount": 150.0},
6 {"order_id": 2002, "amount": 300.0}
7 ]
8}

查询能力：支持基于文档属性的查询，部分数据库（如MongoDB）提供类SQL的聚合管道（Aggregation Pipeline）和索引优化。

适用场景：

内容管理系统（CMS）中文章的多版本存储。
用户配置文件的动态字段管理（如社交平台用户的个性化标签）。

局限性：跨文档事务支持较弱（MongoDB 4.0后支持多文档事务，但性能损耗较大）。

代表数据库：MongoDB、Couchbase

2. 键值型数据库（Key-Value Store）

数据模型：最简单的 NoSQL 模型，数据以键值对（Key-Value）形式存储，Value可以是任意二进制数据。

1Key: "user:101:profile"
2Value: "{'name': '李四', 'last_login': '2023-10-01'}"

高性能特性：通过哈希表实现O(1)时间复杂度的读写操作，适合缓存和高并发场景。

适用场景：

会话存储（Session Storage）：快速存取用户登录状态。
分布式缓存（如Redis缓存热门商品信息）。

局限性：缺乏复杂查询能力（仅能通过Key检索），需业务层处理数据关联逻辑。

代表数据库：Redis、Memcached、Amazon DynamoDB

3. 列族数据库（Wide-Column Store）

数据模型：数据按列族（Column Family）组织，每行可动态添加列，适合稀疏矩阵存储。

1Row Key: "device_001"
2Columns: 
3 "metrics:temperature" -> 25.5
4 "metrics:humidity" -> 60%
5 "location:city" -> "北京"

存储优势：基于LSM树（Log-Structured Merge Tree）的存储引擎，优化高吞吐写入（如日志、传感器数据）。

适用场景：

时间序列数据（物联网设备监控）。
海量数据的随机读写（如HBase存储网页爬虫数据）。

局限性：复杂查询需依赖Row Key设计，二级索引支持有限。

代表数据库：Apache HBase、Cassandra、Google Bigtable

4. 图数据库（Graph Database）

数据模型：以图论为基础，通过节点（Node）、边（Edge）、属性（Property）表示实体及其关系。

1Node: User(id=101, name="王五")
2Edge: User101 -[FRIEND]-> User102 (since=2020)

查询优势：专为关系查询优化，可高效遍历多跳关系（如社交网络的六度分隔理论）。

适用场景：

社交网络中的好友推荐。
欺诈检测（识别异常交易环路）。

局限性：非关系场景下性能无明显优势，学习曲线陡峭。

代表数据库：Neo4j、Amazon Neptune

大数据生态数据库：分布式与批量处理的支柱

1. 分布式列式存储（HBase）

技术架构：基于HDFS的分布式存储，通过Region分片实现水平扩展，ZooKeeper协调元数据。

核心能力：

随机实时读写（毫秒级延迟）。
稀疏数据的高效存储（空值不占空间）。

适用场景：实时查询TB级数据（如电信通话记录检索）。

2. 数据仓库（Hive）

技术原理：将结构化数据映射为HDFS文件，通过 HiveQL（类SQL）转换为MapReduce或Tez任务。

核心能力：

离线批量处理（小时级延迟）。
复杂ETL流程（数据清洗、转换）。

适用场景：历史数据报表生成（如零售业月度销售分析）。

3. 实时数仓（ClickHouse、Doris）

技术突破：向量化执行引擎、列式存储、预聚合，实现亚秒级响应。

适用场景：交互式OLAP分析（如广告投放效果实时看板）。

总结

我们做一个整体的对比

随着技术发展，数据库的界限逐渐模糊。例如：

多模型数据库：如PostgreSQL通过扩展支持JSONB（文档模型）和Citus（分布式能力）。
HTAP(Hybrid Transactional/Analytical Processing)数据库：TiDB、Oracle Exadata支持OLTP与OLAP混合负载。
AI驱动数据库：利用机器学习优化查询计划（如Google AlloyDB）。

随着 AI 技术的兴起，向量数据库也是非常热门的一类数据库。数据库的分类也并非绝对的技术壁垒，而是反映了不同场景下的核心矛盾权衡：

结构化 vs 灵活性：关系型牺牲灵活性换取严格约束，文档型反之。
一致性 vs 扩展性：CP系统（如ZooKeeper）优先保障一致性，AP系统（如Cassandra）优先保障可用性。
实时性 vs 吞吐量：HBase优化单点查询延迟，Hive优化批量吞吐量。

理解这些分类背后的哲学，才能避免“技术选型中的锤子效应”（手里只有一把锤子，看所有问题都是钉子），从而在复杂业务场景中构建合理的数据存储架构。

数据类型

在进行数据库的选择前，你要处理的数据类型是你必须要明确的。

结构化、半结构化和非结构化数据在存储、查询和处理方式上存在本质差异，直接影响了技术选型的路径。

在数据管理的实践中，数据类型是决定数据库选型的关键因素之一。结构化、半结构化和非结构化数据在存储、查询和处理方式上存在本质差异，直接影响了技术选型的路径。以下从数据特征、处理需求到典型数据库选择展开系统性分析。

结构化数据：秩序与约束的领域

1. 核心特征

严格模式（Schema）：数据字段预先定义，类型明确（如整数、日期、枚举值）。
二维表结构：数据以行和列的形式组织，遵循第一范式（1NF）到第三范式（3NF）的规范。
强关联性：通过外键建立表间关系，支持JOIN操作实现跨表查询。

示例：

银行账户表：账户ID (主键) | 户主姓名 | 余额 | 开户日期
电商订单表：订单ID | 用户ID (外键) | 商品ID (外键) | 订单金额 | 支付状态

2. 数据库选择

首选：关系型数据库（RDBMS）。它的选型逻辑：

事务完整性：需要ACID保障的场景（如转账操作）。
复杂查询：涉及多表关联、聚合计算（如财务报表生成）。
数据一致性：字段之间存在强约束（如库存数量不能为负值）。

其中代表方案有：

MySQL/PostgreSQL：适用于中小规模OLTP系统。
Oracle：企业级高并发、高可靠性需求（如金融核心系统）。
TiDB：分布式架构下仍需强一致性的场景（如跨境支付平台）。

3. 反模式案例

错误尝试：将用户行为日志（半结构化JSON）存入MySQL。这样做的问题是：

需要为动态字段创建稀疏列，导致存储空间浪费。
频繁ALTER TABLE修改表结构，引发锁表风险。
查询嵌套字段需解析JSON字符串，性能低下。

半结构化数据：灵活性与动态性的平衡

1. 核心特征

松散模式：字段可动态增减，数据类型允许一定灵活性。
层次化结构：数据以树形或网状形式组织（如JSON、XML）。
自描述性：数据本身携带元信息（如字段名称、嵌套关系）。

示例：用户配置文件

 1 {
 2 "user_id": 1001,
 3 "preferences": {
 4 "theme": "dark",
 5 "notifications": {
 6 "email": true,
 7 "sms": false
 8 }
 9 },
10 "last_activity": [
11 {"type": "login", "timestamp": "2023-10-05T08:30:00Z"},
12 {"type": "purchase", "item_id": "SKU123"}
13 ]
14 }

设备传感器元数据：

1 <device id="D001">
2 <location lat="39.9042" lon="116.4074"/>
3 <sensors>
4 <sensor type="temperature" unit="°C"/>
5 <sensor type="humidity" unit="%"/>
6 </sensors>
7 </device>

2. 数据库选择

首选技术：文档型数据库、宽列数据库。它的选型逻辑：

动态模式支持：无需预定义字段，适应业务快速迭代。
嵌套查询效率：直接存储层次化数据，避免关联表拆分。
局部更新能力：修改文档部分字段不影响整体结构。

代表方案：

MongoDB：
适用场景：CMS内容管理、物联网设备元数据存储。
优势：BSON二进制存储、聚合管道、地理位置索引。
限制：事务跨文档操作成本高（需4.0+版本）。
Cassandra：
适用场景：时间序列数据（如日志事件流）。
优势：高写入吞吐、多数据中心复制。
限制：查询必须指定分区键，二级索引效率低。
Elasticsearch：
适用场景：日志分析、全文检索（如电商商品搜索）。
优势：倒排索引、近实时搜索、分词器定制。
限制：写入吞吐受分片数限制，不支持事务。

3. 混合架构实践

典型组合：MySQL + MongoDB + Elasticsearch。数据流示例：

用户注册信息（结构化）存入MySQL。
用户行为轨迹（半结构化JSON）写入MongoDB。
关键字段（如用户ID、行为类型）同步到Elasticsearch供快速检索。

非结构化数据：海量与多元化的挑战

1. 核心特征

无固定模式：数据格式不遵循预定义结构。
大文件倾向：单个数据单元体积大（如视频、图片）。
内容多样性：文本、图像、音频、二进制文件等。

示例：

媒体文件：监控摄像头的1080P视频流（MP4格式）。
办公文档：PDF合同、Word报告。

2. 数据库选择

核心矛盾：非结构化数据的管理重点不是“查询”，而是“存储与访问”。它的选型逻辑：

存储效率：需支持大文件分块存储（如HDFS的128MB块）。
元数据管理：通过附加结构化信息实现快速检索。
访问接口：提供HTTP API或对象存储接口（如S3兼容）。

代表方案：

对象存储：

Amazon S3/阿里云OSS：存储图片、视频等静态资源。
MinIO：自建私有化对象存储方案。

分布式文件系统：

HDFS：用于Hadoop生态的原始文件存储。
Ceph：统一存储池支持块、文件、对象接口。

专用数据库扩展：

MongoDB GridFS：将大文件分块存储为文档。
PostgreSQL大对象（LOB）：通过TOAST机制存储二进制数据。

3. 元数据关联策略

典型架构是：对象存储 + 关系型数据库。分两步：

数据流：

上传视频文件到S3，获得存储路径s3://bucket/video_001.mp4。
在MySQL中创建记录：

1INSERT INTO media_files 
2 (id, s3_path, uploader_id, duration, resolution)
3VALUES 
4 (1001, 's3://bucket/video_001.mp4', 501, 120, '1920x1080');

查询过程：

1-- 查找用户501上传的高清视频
2SELECT s3_path FROM media_files 
3WHERE uploader_id = 501 AND resolution = '1920x1080';

总结

总结一下不同数据类型的特点

总结来说：

结构化数据是商业规则的数字化体现，适合通过关系型数据库实现精准控制。
半结构化数据反映了现实世界的复杂关联，文档型或宽列数据库提供必要的灵活性。
非结构化数据代表信息的原始形态，需通过对象存储与元数据管理实现规模化处理。

说了这么多，虽然对于数据是什么类型有了比较清楚的定义和区分，但是数据到底是结构化的还是非结构化的，其实主要是看 “数据的组织方式”和“处理方式”

这里举个例子，比如 用户评论

如果我们只是想简单的读写用户评论，可以把它用关系型数据库存储，当作一个表中的一个字段:

在评论内容（CommentContent）这个字段中，我们可以存储用户的评论文本。对于包含的表情、图片等多媒体元素，也有一些常见的处理方法。例如，把表情转换为编码存储，而图片可以存储在文件服务器上，并在数据库中保存链接地址。

如果把用户评论当成非结构化数据，那么它的处理方式就会更加复杂。

用户评论的内容通常是文本信息，但其实不容易进行有效的结构化处理。评论的长度、格式、语言等都可能差异很大，甚至某些评论可能包含表情符号或者图片等多媒体元素。这些元素都无法通过预定义的数据模型进行有效地分类和组织，因此我们将其当做非结构化数据来处理。–这里主要是指数据的组织方式。

以下是一些具体的例子：

评论情感分析：通过对用户评论的文本内容分析，我们可以识别出评论者的情绪态度，比如正面的、负面的，或者中性的。这对于公司来说是非常重要的，可以了解产品或者服务在消费者中的口碑和接受程度。
评论分类：我们还可以将评论分到不同的类别。可以根据情绪分为好评、中评、差评。同时，还可以按照评论的内容将其分为产品评价，客服评价等类别。
评论的全文搜索：对于用户评论这种非结构化数据的全文搜索，可以帮助我们即时搜索到关于某一产品或者某一特定主题的所有相关评论。
主题模型：主题模型可以帮助我们从大量的评论中提炼出几个主要的话题，帮助公司了解消费者最关心的问题有哪些。

具体实现架构如下：

用户评论的存储与分析系统需结合多种技术实现高效处理。在存储层设计中，推荐采用混合存储架构以满足非结构化数据的持久化需求。核心存储使用MongoDB文档数据库保存完整的评论内容（如文本、表情编码、图片链接等），其灵活的JSON结构支持动态字段扩展，例如可包含用户设备信息、地理位置等元数据。同时，MongoDB的水平扩展能力和聚合查询功能可有效支持大规模数据管理。对于评论中的图片、视频等二进制文件，则通过对象存储（如Amazon S3或阿里云OSS）存储，结合预签名URL实现安全访问，避免数据库性能损耗。辅助索引层采用Elasticsearch同步关键字段，通过倒排索引和中文分词技术（如IK分词）实现秒级全文检索，并支持模糊搜索与高亮显示。

在场景化应用中，情感分析可通过多种技术实现：对于中文评论，SnowNLP或Hugging Face的BERT模型能精准识别情感倾向，例如通过预训练模型对“电池续航太差”等文本输出负面标签及置信度评分。评论分类则结合监督学习（如SVM、BERT）与无监督方法（如K-Means聚类），通过FastAPI构建实时分类服务或使用Spark进行批量处理。全文搜索功能由Elasticsearch支撑，通过MongoDB Connector实现实时数据同步，支持用户快速定位包含特定关键词的评论内容。主题模型则利用LDA、BERTopic等算法从海量评论中提取高频主题（如“屏幕质量”“物流服务”），并通过WordCloud等工具可视化呈现，帮助业务方洞察用户关注焦点。整个架构通过混合存储与多技术协同，在保证性能的同时实现成本优化。

应用场景

数据库选型的核心是：理解业务数据的生命周期，把握各类数据库的能力边界，在架构灵活性与技术可控性之间寻找最佳平衡点。任何脱离具体业务场景的数据库对比都是无效的，优秀的架构设计应当像精密钟表般，让每个齿轮（数据库）在最适合的位置发挥最大效能。

结合典型应用场景，什么场景应该用什么数据库呢？其实在一个业务场景下需要多种类数据库结合使用，总结如下：

我们以单个数据库为维度再分别讨论一下：

关系型:MySQL

MySQL：高并发事务系统（如电商订单处理）

核心场景：电商平台的订单系统，需要保证每笔交易的原子性（如扣减库存、生成订单、支付记录必须同时成功或回滚）。

为什么选择MySQL：

ACID事务支持：通过InnoDB引擎实现强一致性，确保订单状态的准确性。
复杂查询能力：支持多表JOIN（如查询用户历史订单及商品详情）。
成熟生态：主从复制、分库分表工具（如ShardingSphere）支持高可用和扩展。

对比其他数据库：

MongoDB：不支持跨文档事务（早期版本），不适合强一致性场景。
Redis：内存数据库，无法持久化复杂事务逻辑。

示例：每秒处理10万笔订单的电商平台，通过MySQL分库分表（按用户ID哈希）实现横向扩展。

搜索引擎：ES

Elasticsearch：实时商品搜索与日志分析

核心场景：电商平台商品搜索，用户输入关键词（如“防水运动鞋”）后毫秒级返回结果。

为什么选择Elasticsearch：

倒排索引：快速匹配关键词，支持分词、同义词扩展、模糊查询。
聚合分析：统计商品类目的平均评分、价格区间分布。
近实时（NRT）：新上架商品1秒内可被搜索。

对比其他数据库：

MySQL：全文索引性能差，无法支持高并发搜索。
MongoDB：文本搜索功能简单，缺乏分词器和相关性排序。

示例：某跨境电商平台，每日处理1亿次搜索请求，通过ES集群（分片+副本）实现99.9%的查询响应时间<50ms。

文档型：MongoDB

MongoDB：内容管理系统（CMS）与动态配置存储**

核心场景：新闻发布平台的文章存储，每篇文章包含标题、正文、多级评论、动态标签。

为什么选择MongoDB：

灵活文档模型：存储嵌套结构的JSON数据（如评论树形结构）。
水平扩展：通过Sharding自动分配数据到多个分片。
局部更新：修改文章某个字段无需重写整个文档。

对比其他数据库：

MySQL：需要拆分为多张表（文章表、评论表），JOIN查询效率低。
HBase：适合结构化扫描，不适合嵌套数据查询。

示例：某媒体平台存储1000万篇文章，每篇文章包含动态标签（如“科技, 2023趋势”），通过MongoDB的文档结构直接存储。

键值存储：Redis

Redis：高频访问缓存与会话管理

核心场景：社交平台的热门帖子缓存，用户访问时优先从缓存读取，减少数据库压力。

为什么选择Redis：

内存存储：读写延迟<1ms，支持每秒百万级操作。
数据结构丰富：使用Sorted Set存储热门帖子排行榜，Hash存储用户会话信息。
持久化可选：RDB快照或AOF日志保障数据安全。

对比其他数据库：

MySQL：磁盘存储，无法满足毫秒级响应。
MongoDB：内存占用高，不适合纯缓存场景。

示例：某论坛每日活跃用户500万，通过Redis缓存前1000热门帖子，命中率90%，数据库负载下降70%。

宽列存储：HBase、Cassandra

HBase：海量时序数据存储（如物联网设备监控）

核心场景：电力公司存储智能电表每秒采集的电流、电压数据。

为什么选择HBase：

列族存储：按列压缩时序数据，节省存储空间。
随机读写：按设备ID+时间戳快速查询某时刻数据。
HDFS集成：数据自动下沉至HDFS实现低成本归档。

对比其他数据库：

Cassandra：适合跨数据中心写入，但单点查询性能不如HBase。
MySQL：无法支持每秒百万级数据写入。

示例：某物联网平台每日新增1TB传感器数据，通过HBase的RowKey设计（设备ID+时间戳）实现毫秒级查询。

Cassandra：多数据中心日志同步（如全球化应用）

核心场景：跨国社交应用的聊天日志存储，要求数据在欧美亚三地就近写入且最终一致。

为什么选择Cassandra：

多活架构：数据自动复制到多个数据中心，写入本地即成功。
高吞吐写入：LSM树引擎支持每秒百万级写入。
无单点故障：去中心化架构避免主从瓶颈。

对比其他数据库：

HBase：依赖HDFS和ZooKeeper，扩展性受限。
MySQL：主从复制跨地域延迟高。

示例：某IM应用每日处理50亿条消息，通过Cassandra实现三地数据中心写入延迟<10ms。

数据仓库：Hive

Hive：离线数据仓库与ETL批处理

核心场景：零售企业每月销售数据的批量清洗与报表生成。

为什么选择Hive：

SQL兼容：通过HiveQL实现类SQL查询，降低学习成本。
海量数据批处理：基于MapReduce或Tez引擎处理TB级数据。
低成本存储：数据存储在HDFS，支持压缩格式（ORC、Parquet）。

对比其他数据库：

ClickHouse：适合实时分析，但存储成本高。
MySQL：无法处理PB级数据。

示例：某电商每月分析10TB历史订单数据，通过Hive生成“年度区域销售趋势”报表，耗时2小时。

列式存储：ClickHouse

ClickHouse：实时OLAP与用户行为分析

核心场景：广告平台的实时点击流分析，每日处理千亿级事件，生成实时报表。

为什么选择ClickHouse：

列式存储：压缩率高，适合聚合计算（如SUM、COUNT）。
向量化执行：利用CPU SIMD指令加速查询。
实时写入：支持Kafka直接导入数据，延迟低至秒级。

对比其他数据库：

Hive：批处理模式，查询延迟分钟级。
MySQL：无法支撑海量数据聚合。

示例：某广告平台分析每日200亿次点击事件，通过ClickHouse集群实现“过去1小时各渠道转化率”秒级响应。

图数据库：Neo4j

Neo4j：社交网络关系挖掘（如好友推荐）

核心场景：社交平台的“六度关系”分析，计算用户A到用户B的最短路径。

为什么选择Neo4j：

图遍历优化：通过原生图存储引擎高效遍历多跳关系。
Cypher查询语言：直观表达复杂关系模式（如查找共同好友）。
实时更新：支持动态添加节点和边。

对比其他数据库：

MySQL：需递归JOIN，性能随跳数指数级下降。
MongoDB：无法直接表达关系网络。

示例：某社交平台分析10亿用户关系，Neo4j可在毫秒级返回“用户A的三度人脉中可能认识的人”。

总结

事务强一致 → MySQL
实时搜索 → Elasticsearch
动态文档 → MongoDB
高频缓存 → Redis
实时OLAP → ClickHouse
时序海量存储 → HBase
全球化写入 → Cassandra
关系网络 → Neo4j
离线批处理 → Hive

最后总结

**数据模型的本质差异是选型的第一道分水岭。**关系型数据库（如MySQL、PostgreSQL）建立在严格的二维表结构之上，通过外键约束和范式理论保障数据完整性。这种结构特别适合需要复杂关联查询的财务系统、ERP等业务场景。例如银行转账操作需要严格遵循ACID事务原则，MySQL的InnoDB引擎通过行级锁和MVCC机制实现事务隔离，配合主从复制架构可以满足多数金融级需求。但在物联网设备日志存储场景下，每天千万级的写入请求会导致关系型数据库的索引维护成本急剧上升，此时文档型数据库MongoDB的BSON自由格式和分片集群优势便显现出来。MongoDB的写操作默认不等待磁盘确认，通过内存映射文件实现高速写入，特别适合内容管理系统或实时分析场景中半结构化数据的快速摄入。

分布式架构的CAP权衡直接影响系统可用性。 Elasticsearch作为分布式搜索引擎，其倒排索引结构对文本检索的优化已达到毫秒级响应，在电商商品搜索、日志分析等场景具有不可替代性。但ES的强一致性模型可能导致集群脑裂风险，需要结合zen discovery机制进行节点状态管理。相比之下，HBase作为Hadoop生态的列式存储，通过RegionServer的水平扩展和LSM树的写入优化，能够承载PB级数据量的实时读写。某智慧城市项目曾使用HBase存储数十亿条交通卡口数据，利用其行键有序分布特性实现车辆轨迹的快速回溯，这是传统关系型数据库难以企及的吞吐能力。

计算与存储的分离趋势重构了数据分析范式。 Hive建立在HDFS之上的元数据管理机制，通过类SQL语法实现大数据集的离线分析，其分区表和桶表的设计显著提升了TB级数据查询效率。某电商平台的历史订单分析采用Hive进行月度销售统计，配合Tez执行引擎将任务耗时从小时级压缩到分钟级。但Hive的高延迟特性使其不适合实时查询场景，这正是ClickHouse等OLAP数据库的突破方向。需要特别注意的是，数据湖架构的兴起使得Delta Lake、Hudi等解决方案开始融合事务管理和批流一体处理，这对传统数仓选型提出了新的挑战。

**事务完整性与系统弹性的平衡艺术。**当业务需要跨数据库操作时，如电商订单系统同时涉及MySQL库存扣减和MongoDB订单日志记录，分布式事务管理就成为关键挑战。Saga模式通过补偿机制实现最终一致性，而Seata框架的AT模式能在业务侵入性较低的情况下保障事务边界。但在高并发场景下，这类方案的性能损耗可能达到20%-30%，这就需要架构师在一致性级别和系统吞吐之间做出权衡。例如社交平台的点赞功能更适合使用Redis的原子计数器，完全放弃强一致性以换取百万级QPS的处理能力。

**硬件成本与运维复杂度的隐藏成本。**云原生时代，AWS Aurora通过计算存储分离架构实现了MySQL兼容数据库的自动扩缩容，其存储层可自动扩展到128TB，这种托管服务显著降低了运维负担。但对于需要定制化优化的场景，如金融行业的风控模型计算，仍需要基于物理机部署的Oracle RAC集群来保障IOPS性能。开源方案的隐性成本同样不容忽视，Elasticsearch集群的JVM堆内存配置直接影响索引性能，不当的分片设置可能导致磁盘空间浪费，这需要运维团队积累足够的调优经验。

在具体选型实践中，建议采用四维评估法：首先明确数据结构化程度（结构化、半结构化、非结构化），其次分析读写比例和并发量级，再次确定一致性要求（强一致、最终一致），最后考量扩展性和生态集成需求。例如智能穿戴设备数据采集场景，设备标识符作为MongoDB文档的天然主键，时间序列数据采用嵌套文档存储，既避免了关系型数据库的表关联开销，又利用TTL索引实现自动过期清理。而在用户画像分析场景，HBase 的宽表结构可以存储数千个用户标签，配合Phoenix的SQL层实现灵活查询，这种架构组合充分发挥了列式存储的高压缩比优势。

最后我们用一个简单的流程图来说明一下这个选型过程：

REST 与 gRPC 的详细比较

Wed, 04 Sep 2024 02:40:44 +0000

在很长一段时间里，REST 是构建 API 的唯一“标准”。它在某种程度上取代了 SOAP，后者因为“太多的 XML”而变得混乱不堪。

但近年来，新的选择出现了。2015 年，Facebook 向公众发布了 GraphQL，2016 年，谷歌紧随其后，发布了 gRPC。在这篇文章中，我们将重点关注后者，并将其与仍然广泛使用的 REST 进行比较。

概述

下表将为您提供讨论要点的概览，并展示了 REST 和 gRPC 真正闪耀的地方。

主题	REST	gRPC
标准化	无标准	定义明确
范式	基于资源	RPC
服务模式	仅单向	单向、客户端流、服务器流和双向流
要求	任何 HTTP 版本，JSON 解析器	HTTP/2，gRPC 语言实现
API 设计	代码优先	设计优先
默认数据格式	JSON	Protobuf
浏览器支持	原生	gRPC Web，通过变通方法
工具	更成熟的工具	语言支持各异，部分有出色的实现

标准化

REST 的一个缺点是缺乏标准化。REST 更像是一种范式，而不是 API 标准，许多人对它的理解各不相同。对大多数人来说，“REST API”一词用于指代基于 HTTP 的 JSON API。对其他人来说，REST 可以与某些规范如 HATEOAS 或 JSON:API 互换使用。但即使使用 XML 而不是 JSON，API 仍然可以是 RESTful 的，尽管这一点并不广为人知。REST 这个术语甚至不与 HTTP 绑定。这在处理 REST API 时可能导致很多混淆。例如，消费者可能会自动期望某些 REST API 端点具有幂等性或可缓存性，尽管这些并没有明确定义。

相比之下，gRPC 定义明确。例如，gRPC 在 HTTP/2 上的实现非常详细。

根本差异

REST 和 gRPC 的范式不同。

在 REST 中，一切都围绕资源展开，资源可以被检索和操作。如果我们以书籍为例，REST API 通常会提供以下端点：

GET /books（获取所有书籍，很可能带有用于过滤和分页结果的参数）
GET /books/{id}（获取特定书籍）
POST /books（创建书籍）
DELETE /books/{id}（删除书籍）

大多数基于 HTTP 的 REST API 都遵循这种模式。虽然这种方式运作良好，但在某些情况下，作为 REST API 表示起来比较困难。例如，如果我想一次性创建多本书籍，而不想为每本书重复调用POST /books（出于性能、幂等性或其他原因），我该怎么办？我创建一个POST /books/batch端点吗？这还是“RESTful”的吗？虽然技术上容易解决，但它经常在开发者之间引发长时间的讨论。

另一方面，gRPC 是一个 RPC 框架。它围绕服务方法展开。如果我们以书籍 API 为例，使用 gRPC，我们会创建一个BookService，包含以下方法：

GetBooks()
GetBook()
CreateBook()
DeleteBook()

我们可以随意命名这些方法，并需要任何我们需要的参数。如果我们现在想添加一个创建多本书籍的方法，没有什么可以阻止我们添加一个CreateBooks()方法。gRPC 在设计 API 时提供了更多的“自由”，因为（自我施加的）限制更少。

服务模式

gRPC 支持四种服务方法：

单向： 发送单个请求，接收单个响应
服务器流： 发送单个请求，接收多个响应
客户端流： 发送多个请求，接收单个响应
双向流： 发送多个请求，接收多个响应

与仅支持单向请求的 REST 相比，这是 gRPC 的一个非常大的优势。在 REST API 中支持其他服务模式将需要使用不同的协议，如服务器发送事件或 WebSockets，这并不完全是“RESTful”的。

要求

REST API 通常“只要工作”就可以与任何类型的 HTTP 版本一起使用。只要编程语言具有 HTTP 客户端和 JSON 解析库，消费 REST API 就变得轻而易举。

gRPC 明确需要 HTTP/2 支持，否则它将无法工作。近年来，这已不再是一个问题，因为大多数代理和框架都增加了对 HTTP/2 的支持。

由于 gRPC 需要代码生成（用于创建客户端或服务器存根），因此只支持一组编程语言。

API 设计

REST API 通常是其实现的结果，被称为“代码优先”。虽然可以先设计 OpenAPI，然后生成服务器存根，但这不是许多开发者采取的方法。OpenAPI 定义更有可能从 API 实现中生成，如果有 OpenAPI 定义的话。因此，API 定义与实现紧密耦合。错误的模型/类的更改可能导致 API 的意外破坏性更改。

gRPC 采用不同的方法，其中 API 必须在实现之前定义（被称为“设计优先”）。然后从这个 API 定义生成客户端和服务器存根。这需要一些预先思考，因为不能直接跳入实现 API。

两种方法都有其优缺点。通常的 REST API 方法允许更快的迭代，因为服务器始终是真实的来源。使用 gRPC，可能很烦人，必须首先更改 API 定义，然后才能调整实现。然而，它通过明确定义 API 带来了一些安全优势。

数据格式

REST 和 gRPC 都可以使用不同的格式传输数据。大多数 REST API 使用 JSON，而 gRPC 默认使用 Protocol Buffers（Protobuf），因此我们将比较这两种。

JSON 对数据类型的支持有限，也有一些怪癖（例如，大数字需要作为字符串表示）。它是一种文本格式，人类可读。字段名被序列化，这占用了一些空间。在某些编程语言中，这也需要使用反射来反序列化 JSON 消息，这相当慢。

如上所述，gRPC API 及其相应的消息类型首先被定义为 Protocol Buffers。每个消息都是强类型的，可能包含有用的注释，并且有许多其他有趣的特性。对于支持的编程语言列表，可以自动生成（反）序列化消息的代码。由于它是一种二进制格式，并且不序列化字段名，它比等效的 JSON 消息占用的空间更少。这确实有一个缺点，即它不再是人类可读的，需要 Protobuf 定义来反序列化消息，这可能会妨碍开发体验。

以下 JSON 示例大约占用 66 字节（去除空格）。

{ "persons": [ { "name": "Max", "age": 23 }, { "name": "Mike", "age": 52 } ] }

等效的序列化 protobuf 消息只会使用 19 字节。

0x0A070A034D617810170A080A0448616E731034

大消息

Protobuf 旨在在内存中序列化和反序列化消息。因此，不建议使用 Protobuf/gRPC 传输大消息。大多数 gRPC 实现对单个消息设置了默认的 4MB 限制。

使用 REST API 处理大数据大小（如文件上传）相对直接。接收到的文件可以作为流处理，使用很少的内存。这在 gRPC 中并非不可能，但需要更多的手动努力。文件需要在发送方分成几个部分。然后每个部分作为单独的消息通过客户端流方法发送到服务器。服务器接收每个部分，并可以从中构建数据流，从而实现与 REST API 类似的行为，尽管需要更多的努力。

浏览器兼容性

这是 REST 真正闪耀的地方。它被 Web 浏览器原生支持，使得从 Web 应用程序消费 REST API 变得毫不费力。

gRPC 并不直接被浏览器支持，因为它需要明确的 HTTP/2 支持和访问某些 HTTP/2 特性，而 Web 浏览器并不提供。作为变通方法，可以使用 gRPC Web。它是 gRPC 协议的轻微变体，使其可以被 Web 浏览器消费。对于某些编程语言，gRPC Web 支持已经包含在框架中。对于其他语言，需要一个代理来将 gRPC 流量转换为 gRPC Web 流量，反之亦然。与不需要依赖的 REST API 相比，从 Web 消费 gRPC API 更加繁琐。

一个变通方法是使用 JSON 转码，它允许开发人员将 gRPC API 作为 REST API 公开。

gRPC 和 REST 工具在编程语言和框架之间的差异很大。在某些情况下，gRPC 感觉更“原生”，而在其他情况下，REST 工具更加先进。

适当的 gRPC 语言支持非常重要，因为它需要工具来生成客户端和服务器存根。对于不支持的编程语言，你将无计可施。REST API 的客户端总是可以手动创建的，但这可能需要一些努力。虽然存在从 OpenAPI 定义创建 REST 客户端的工具，但与 gRPC 等效工具相比，它们的开发体验通常较差。

由于 REST API 已经存在了很长时间，因此存在更多帮助构建、测试和部署 REST API 的工具。它们的功能通常比 gRPC 工具更先进。

结论

REST 和 gRPC 都有其优点和缺点。

从 Web 应用程序消费 REST API 通常更容易。 REST 也更广泛地被使用，对于某些开发者来说，可能更简单，因为他们可能不了解 gRPC。

在我看来，gRPC 在服务器到服务器通信（例如，微服务之间）中肯定有优势。能够共享确切的 API 定义，并在多种编程语言中创建 API 客户端是一个巨大的胜利。

缓存 on 小盒子的技术分享

昨天面试官问我：一个 Prompt 进入大模型后，内部到底发生了什么？

一个高分回答，最好先把整体框架立住

第一阶段：用户输入的 Prompt，并不是模型真正看到的内容

第二阶段：请求不会立刻进模型，而是先进入推理服务和调度层

第三阶段：进入模型后，token 会先变成向量表示

第四阶段：真正的“推理核心”发生在一层层 Transformer Block 里

Self-Attention 在干什么？

FFN 又在干什么？

第五阶段：Prefill——先把整段 Prompt “读完”

第六阶段：KV Cache——为什么不会每次都重算全文

为什么 KV cache 只缓存 K 和 V，而不缓存 Q？

第七阶段：Decode——开始逐 token 生成答案

为什么“第一个字慢，后面快”？

看起来都是推理引擎的活儿啊？

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

一、 真实的工程世界，从来不是一道“闭卷考试”

二、 刷题面试，正在惩罚真正有经验的“老兵”

三、 算法题面试的本质：一场低效的“智商服从性测试”

四、 如何打破僵局：回归工程本质的面试方法

五、 结语：放过工程师，也放过企业自己

一文讲透 GoF 的 23 种设计模式之单例

一文讲透 GoF 的 23 种设计模式之单例

定义

什么时候用?

不要滥用

实现方式

枚举

静态内部类

Spring 是如何实现单例的？

1. 核心数据结构：ConcurrentHashMap

2. Spring 创建单例的流程

3. 补充：循环依赖的杀手锏“三级缓存”

全程0人工写代码！干掉低级码农的不是大模型

全程0人工写代码！干掉低级码农的不是大模型

1 极致标准化的预热沙盒（Devboxes）

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

3 极其克制的上下文投喂：规则文件与 Toolshed

4 反馈左移（Shifting Feedback Left）：极速纠错循环

给我的启示

参考

提示词缓存:让 LLM 成本降 10 倍

到底什么是 Cached Token ？

LLM 架构

Tokenizer (分词器 / 切词器)

Embedding (嵌入层)

Transformer (变换器 / 核心处理层)

Output (输出层)

实现原理

想省钱，要这样用

常见 “踩坑清单”

缓存能活多久 / 怎么保持

落地建议

实际应用场景

3 毛钱干大事？ 用了几天豆包编程模型，我来扒一扒字节这波操作

兼容 Claude Code

第一种方式

第二种方式

核心能力体验

VLM：前端仔的末日… 还是福音？

聊聊技术底裤

测试

总结

LangChain：是银弹，还是 “技术债”？

引言

高代码与低代码

高代码

低代码

场景选型

混合实践

LangChain

概念说明

大模型应用开发核心矛盾

框架介绍

LangChain 能够解决的五类问题

1. 模型与提示（I / O 层）

2. 链式编排（流程层）

3. 检索增强生成 RAG（数据层）

4. 智能代理（自主层）

一、真实的工程世界，从来不是一道“闭卷考试”

二、刷题面试，正在惩罚真正有经验的“老兵”

三、算法题面试的本质：一场低效的“智商服从性测试”

四、如何打破僵局：回归工程本质的面试方法

五、结语：放过工程师，也放过企业自己

3 毛钱干大事？用了几天豆包编程模型，我来扒一扒字节这波操作

✅ `[project.scripts]`：定义可执行命令（如 CLI）

✅ `[project.urls]`：项目的相关链接（非必须）

✅ `[project.optional-dependencies]`：可选依赖（比如开发环境）

✅ `[tool.pytest]`：Pytest 配置

✅ `[tool.black]`：代码格式化工具 Black 的配置

✅ `[tool.isort]`：import 排序工具 isort 的配置

✅ `[tool.hatch.build.targets.wheel]`：Hatchling 打包配置