煎饼果子不放葱

ReAct、CoT 与 Tool-Use：从想清楚到做清楚一句话：CoT 解决”想清楚”，Tool-Use 解决”查清楚/做清楚”，ReAct 把两者编成闭环——推理指导行动，行动反馈推理。这是现代 AI Agent 的核心范式。 三个概念，一张关系图在 AI 工程的语境里，有三个高频概念总是纠缠在一起： Chain-of-Thought (CoT)：让模型把推理过程一步步写出来 Tool-Use：让模型调用外部工具获取信息或执行操作 ReAct：把推理和行动交织成循环 它们不是三个并列的方案，而是递进的能力层次： 1纯 LLM（只靠记忆）→ 加 CoT（会想了）→ 加 Tool-Use（有手了）→ ReAct（脑手协调） 下面逐个讲透。 一、Chain-of-Thought：让模型把过程写出来核心思想让模型在给出最终答案前，把中间推理步骤显式地生成出来。就像老师要求学生”写解题过程，不能只写答案”。 直观对比不用 CoT： Q: 商店有 23 个苹果，卖了 15 个，又进货 8 个，现在有几个？A: 16 用 CoT： Q: 商店有 23 个苹果，卖了...

为什么”把聊天记录全塞进去”是 LLM 产品最常见的自杀行为 一句话结论：无限追加聊天历史不是”给模型的上下文越多越好”——它会在四个维度同时崩盘：硬天花板、成本爆炸、延迟倍增、信号被噪声淹没。成熟的 AI 产品用分层上下文架构替代全量追加。核心思路不是”给更多信息”，而是”给每个 token 更值钱的信息”。 四个同时发作的问题直觉很自然：用户聊了 30 轮，把每一轮都喂给模型，答案不就更有上下文了吗？ 前十轮没问题。二十轮依然连贯。到四十轮左右，事情开始崩了： 回复变慢 成本悄然攀升 模型开始跑偏——重提二十分钟前的话题，跟刚说的矛盾，或者执着于某个过时信息 这不是偶发 bug，是系统性必然。原因有四层，层层叠加。 第一层：context window 是硬天花板GPT-4o 上限 128K token，Claude 200K，Gemini 2.5 Pro 1M。 数字看着大，但一个健谈用户在单次长会话里就能烧掉 100K。撞到天花板时你只有两个选择：从头截断（丢掉关键早期上下文），或者拒绝继续。两个都是烂体验。 第二层：Token 成本随每轮累积——沉默的杀手就...

推理模型如何”思考”：一切都只是 Token一句话：推理模型没有做任何新事情。所谓的”先想再答”，就是把中间推理步骤写成 token 藏在后台不让用户看见。思考 token 和输出 token 由完全相同的前向传播产生——没有第二个模型，没有独立推理引擎，没有模式开关。一切都只是 token。 思考 Token 并不特殊首先要刻进脑子里的认知：思考 token 和输出 token 是完全相同的机制生成的。 都是同一个 autoregressive 过程——模型根据前面所有 token 预测下一个 token，把它塞回上下文，重复。前向传播是同一个，权重是同一套。不存在什么”推理副脑”、辅助模块、神经网络里的推理模式开关。 让思考 token 显得不同的唯一原因：谁看得见它们。标准聊天里，模型生成的每一个 token 都直接推给用户。推理模型里，模型先生成一段”思考”token——这些 token 在内部消费，用来影响后续 token 的预测——但不对最终输出暴露。只有思考块之后的 token 才送到用户眼前。 这意味着推理不是”在基座模型之上额外加的能力”。它是基座模型本来就有...

深入理解 LLM 函数调用：模型不会”决定”用工具一句话：函数调用不是模型内部”觉醒”的能力，而是推理层在 prompt 里塞了一套工具描述后，模型遵循协议输出的结构化 token。本质上是 prompt engineering 的延伸——只不过发生在 API 层而非用户输入层。 模型不会”觉得该用工具了”关于函数调用最大的误解，就是以为模型内部有个”我该调工具了”的判断机制。没有。模型就是一个 autoregressive token 生成器——给定前文，预测下一个 token。仅此而已。 函数调用是推理层启用的能力，需要两个显式条件同时满足： 请求里必须带 tools 参数——一个函数定义数组，每个函数包含名称、自然语言描述和 JSON Schema 参数规格。 tool_choice 参数必须允许调用。默认值是 "auto"——模型在它觉得合适时可能返回工具调用。你也可以设为 "none"（绝不下手）、"required"（必须下手），或锁定到某个具体函数。 当 tool_choice 为 "aut...

LLM 解码策略：temperature、采样与 beam search，到底在选什么一句话：所有解码策略本质上只做一件事——从模型输出的概率分布里挑一个 token。区别只在于你用什么规则去挑，以及你要确定性还是要多样性。 基础管道：Logits → Softmax → 概率分布模型最后一层输出的是 logits——词汇表里每个 token 对应一个实数，有正有负，范围不受约束。这还不是概率。 把它变成概率靠的是 softmax： 1P(i) = exp(logit_i) / Σ exp(logit_j) 做完这一步，你手里就有了一个合法概率分布：每个 token 一个概率，全加起来等于 1。后续的 temperature、top-K、top-P、greedy decoding、beam search——全是在这个分布上做文章。要么改分布的形状，要么换挑选的规则。 Temperature：一个旋钮控制”脑洞程度”Temperature 是调起来最简单的参数。它在 softmax 之前动刀，把每个 logit 除以 T： 1P(i) = exp(logit_i / T) /...

多模态 AI 聊天的图像上传：从字节流到用户体验一句话：给 AI 聊天加上图片上传，不是往聊天气泡里塞个 <img> 标签就完事了。它是一条从客户端预处理直通模型 API 的工程管线——上传架构、数据格式、预处理、UX 打磨，每层都有坑，踩过才知道。 上传架构：为什么图片不该经过你的服务器用户选了一张图，这个文件总得想办法到达模型 API。最天真的做法是把所有东西都过一遍你的后端：前端上传到你服务器，你服务器再转发给模型。五个用户的时候没问题，规模化之后直接崩——图片上传吃带宽、占请求线程，你的 API 服务器瞬间变成奢华版文件代理。 正确的姿势是直传 OSS。 后端只管签发临时凭证（STS token 或预签名 URL），前端拿着凭证直接上传到对象存储。流程是这样的： 用户选图 → 前端调后端拿上传 token 后端返回一个短期预签名 URL（有效期按分钟计，绝不按小时） 前端直传 OSS，拿到永久图片 URL 这个 URL 被塞进模型 API 请求——字节流从头到尾没经过你的服务器 后端保持轻量，客户端代码里也不暴露长期密钥。安全边界清晰：临时凭证、服务端签...

Transformer 到底怎么生成文本：逐层拆解一句话：Transformer 推理就四个阶段——Attention（信息路由）→ FFN（知识存储）→ 层层堆叠（抽象升级）→ 解码（从向量到词）。一旦你把这四个阶段吃透，KV Cache 为什么吃内存、长上下文为什么贵、temperature 到底在调什么、模型为什么会产生幻觉、speculative decoding 怎么加速——这些工程决策突然就变得自然而然了。 阶段一：Attention——让每个 token “看到”其他所有 token一个 token 刚进入 Transformer 层的时候，它对周围的 token 一无所知。Attention 就是来解决这个问题的。 每个 token 通过三个学出来的权重矩阵做投影，产出三个向量： Q（Query，查询）： “我现在需要什么信息？”——当前 token 对历史的检索请求 K（Key，键）： “我这里有什么信息可查。”——每个 token 的索引条目 V（Value，值）： “这就是具体内容。”——被”关注”时实际传递出去的信息 当前 token 的 Q 去跟每...

从 Token 到 RAG：理解 AI Native 数据管道一句话：RAG 不是什么魔法，它只是在”大模型读不懂你的私有数据”这个问题上，搭了一条最务实的桥。这条桥由三块砖铺成——Token、Embedding、Vector Database。搞懂它们怎么连起来的、哪里会断，是每个做 AI 产品的工程师逃不掉的功课。 第一块砖：Token——模型看到的”文字”LLM 不读单词，也不读句子。它只认 token 序列。 输入是 token 序列，输出也是 token 序列。模型一辈子只干一件事：给定一串 token，猜下一个最可能的 token，然后把这个 token 拼到序列末尾，再猜下一个，循环往复。 一个 token 可能是一个完整单词（”apple”），也可能是子词碎片（”un” + “believ” + “able”），甚至只是单个字符——全看分词器怎么切。这是整个管道里最底层的粒度，一切从这里开始。 第二块砖：Embedding——把含义变成数字机器不认文字，只认数字。这是根本矛盾。 Embedding 模型做的事：把一段文本映射成一个固定长度的浮点数向量。Open...

低端设备上让 AI 原生应用”感觉快”的实战指南 一句话结论：在 150 美元、3GB 内存、弱信号的手机上，让应用”感觉快”靠的不是某个单一优化——而是把首次绘制拆成流水线、让虚拟列表根据设备内存动态适配、以及把图片加载做成优先级调度系统。这三件事做到位，白屏、卡顿、图片乱跳全消失。 场景还原做一个新闻资讯应用。首页是卡片滚动列表——标题、摘要、缩略图、日期。纸面上看着简单。 扔到一台 150 美元的 Android 手机上试试：3GB 内存，不稳定的 3G。白屏数秒。图片延迟加载挤得文字到处乱跳。滚动卡成幻灯片。应用”坏了”。 这不是假设——这是每个面向真实用户的工程师最终都要面对的场景。 第一条：首次绘制是流水线，不是单步事件最大的思维误区：认为”首页加载=请求数据→渲染→完事”。 在低端设备上，这个模式必然导致痛苦的白屏。实际上，首次绘制应该是一串渐进的里程碑： 1骨架屏 → 缓存读取 → 缓存渲染 → 网络合并 → 缓存写入 阶段一：骨架屏，0ms 出现应用壳就绪的那一刻，网络字节还没到。骨架屏立刻上屏。 这不是装饰——这是心理锚点。用户看到骨架，认知...

流式输出：AI 原生应用的默认交互范式 一句话结论：流式输出不是 UX 上的锦上添花——它是 LLM 应用的身份基石。但真正的难点从来不是”把 chunk 拼起来显示”，而是分布式状态一致性。搞不定这件事，你的停止按钮、刷新恢复、聊天持久化全是 bug。 本质：LLM 天生就该流式LLM 不是一次性产出整段文字。它 autoregressive 地工作：给定一串 token，预测下一个最可能的 token，追加到序列尾部，循环往复。 换句话说，模型本身就在增量地”吐”内容。那你把内容增量地交给用户，就是最自然的选择。 反过来，让用户盯着白屏等 5 秒、10 秒甚至 30 秒，等完整答复再一口气显示——这等于把”慢”暴露给用户，没有任何缓冲。用户会觉得应用坏了。 流式输出把体验翻转了：文字立刻开始出现，感知延迟大幅降低。更关键的是，它把”黑盒查询”变成了”实时协作”——用户可以边看边判断方向对不对，发现模型跑偏就立刻打断，省下浪费的 token。 这种可中断、可纠偏的交互模式，正是 AI 原生应用和传统 Web 应用的分水岭。 核心难点：三层状态机聊天 UI 看起来简单——接...