架构 on 小盒子的技术分享

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

Sun, 12 Apr 2026 08:38:12 +0000

前两天在写一篇技术文章，写到一半需要配一张微服务架构图。我打开了某在线画图工具，对着空白画布发了十分钟的呆，拖了两个方块，连了一条线，觉得丑，删掉，再拖两个方块。

半小时过去了，图还没画完，文章的灵感已经凉透了。

我相信很多搞技术内容的朋友都有过这种体验。你脑子里其实很清楚这张图应该长什么样，但你就是得花一两个小时在画图工具里对齐、配色、调字号。明明内容才是核心，结果时间全花在了排版上。

然后我发现了一个东西，彻底解决了这个问题。

它叫 fireworks-tech-graph，是一个 Claude Code 的 skill。装上之后，你跟 Claude Code 说一句中文，它就能给你吐出一张出版级别的技术图。SVG 矢量源文件加 1920px 高清 PNG，直接能往文章里塞。

我用它画了10张不同类型的图，从架构图到 ER 图到状态机，从白底极简到暗色霓虹到工程蓝图。每张图从下指令到拿到成品 PNG，平均不超过30秒。

30秒。

我之前在画图工具里对齐一个箭头的时间都不止30秒。

怎么装呢，你甚至不需要记任何命令。

打开 Claude Code，直接跟它说「帮我安装 fireworks-tech-graph 这个 skill」，它自己就把活干了。装完之后你说「画一个 xxx 图」，它就自动触发。

如果你喜欢手动装也行，就一句 claude skills install fireworks-tech-graph，完事。

触发词非常宽泛，「画图」「帮我画」「做个架构图」「生成一个流程图」「可视化一下」，随便怎么说都行，它都能识别。

它能画什么？

这个 skill 支持10种有模板的图表类型，外加4种无模板但有规则定义的类型。我挑几个最实用的说一下。

1，架构图。这是用得最多的，画微服务分层、系统组件关系。你告诉它有哪些服务、怎么分层、哪些组件之间有调用关系，它自动帮你排好。我画的那张微服务架构图有5层，右侧还挂了一个观测性旁路，出来的效果跟正经架构文档里的图一模一样。

2，流程图。CI/CD 流水线、审批流、业务决策流。菱形判断节点、圆角矩形处理步骤、失败回环，全都有。你只需要描述「从提交代码到部署生产」中间经过哪些步骤和判断就行。

3，时序图。微服务之间谁先调谁，消息怎么传递。标准的 UML 时序图，有生命线、激活框、alt 分组框。你列出参与者和消息序列，它帮你排好。

4，ER 图。数据库表之间的关系。支持鸦脚记法，PK 自动下划线，FK 标注。你把实体和属性列出来，告诉它哪些是一对多、哪些是多对多，它画出来的东西可以直接放进数据库设计文档。

5，状态机。订单生命周期、工单状态流转这种。每个状态是一个圆角矩形，转换线上标事件名，有初始态的实心圆和终态的同心圆。

6，对比矩阵。横评几个模型、几个方案的时候特别好使。我画了一张 LLM 模型对比表，5个模型7个维度，绿色打勾红色打叉，交替行填充，出来就是一张可以直接发朋友圈的表。

7，时间线。项目路线图、版本规划。甘特图样式，彩色横条加菱形里程碑。

除了这些，还有 Agent 架构图、用例图、数据流图。反正你在技术写作里能用到的图，它基本都覆盖了。

比较骚的是它有7种视觉风格，每种味道完全不一样。

默认的 Flat Icon 是白底彩色，适合博客和文档。Dark Terminal 是暗色霓虹风，发 GitHub 和技术社区特别帅。Blueprint 是工程蓝图风，深蓝色背景加网格线加角标，那种 CAD 图纸的感觉。Notion Clean 是极简白，一根线一个色。Glassmorphism 是毛玻璃卡片，适合产品官网和 Keynote。最近还加了 Claude Official 和 OpenAI Official 两种风格，分别是 Anthropic 和 OpenAI 的品牌调性。

你指定风格的方式就是在 prompt 里加一句「用蓝图风」或者「Style 3」，就这么简单。

我觉得这个 skill 最打动我的点，不是它画得多漂亮，而是它把「画图」这件事的心理门槛降到了零。以前我写文章需要配图的时候，经常会想「算了这里用文字描述一下也行吧」，因为打开画图工具、画完、导出、插入这一套流程太重了。现在不一样了，我在 Claude Code 里写着文章，写到需要配图的地方，直接说一句「帮我画一个 xxx」，30秒后图就在本地了。

这种体验就像是，你本来在用文本编辑器写代码，突然有人给你装了一个实时预览插件。功能上没变，但那个「随时能看到效果」的即时反馈感，会让你更愿意去做这件事。

画图也是一样。当成本足够低的时候，你会发现你开始「想画就画」了。

想试的朋友，打开 Claude Code，说一句「帮我安装 fireworks-tech-graph」，等它装完，再说一句「画一个 xxx 图」。

就这么简单。两句话的事。

下面附一些 demo 图：

让Agent快上100倍的秘密，其实藏在一本大一计算机教科书里

Sat, 11 Apr 2026 10:50:21 +0000

事情是这样的。

最近我几乎每天都在用Claude Code写东西。用得越多，我越产生一种奇怪的感觉。

就是你给它下完一个任务之后，它开始一步一步地干活。先是啪，读了一个文件。然后哒，想了几秒。然后啪，又打开一个文件。再想几秒。再打开一个文件。就这么一直持续下去。

你坐在椅子上看着进度条一格一格地亮起来，心里清楚得不能再清楚，这十个文件它明明可以一起读的，它们之间根本没有任何依赖关系。

但它就是不。它就是要一个接一个地来。

一时间无语凝噎。

后来我跟几个同样重度用Agent的朋友聊了一下，他们也都有这个感受。说真的我始终觉得这是现在所有Agent产品共同的一个病，不管是 Claude Code、Cursor、Manus还是那些MCP插件，只要你让它干稍微复杂一点的活，你就会看到它在那里慢悠悠地一步一步走，像一个做事非常有耐心但完全不会一心二用的老实人。

前两天跟朋友吐槽这事的时候，我又想起了两年前Berkeley那帮人写的一篇论文。论文叫LLMCompiler，2024年就发在ICML上了，现在回头看它也不算新东西。但每次我被Agent气到的时候都会想起它，觉得它的思路到今天都没过时，甚至越品越有味道。

它当时就已经把这个病的根源讲得很清楚了，这个慢不是LLM的错，也不是任务复杂度的错，是我们给它用的那套调度系统，还停留在1960年代的水平。

这篇论文的名字挺干的，叫**《An LLM Compiler for Parallel Function Calling》**，ICML 2024。作者是Sehoon Kim、Amir Gholami那帮人，都在Berkeley和LBNL。它不是今年的新论文，但在我心里一直是Agent方向上最被低估的几篇之一。

它在做的事其实非常cool。

它在把大学一年级《计算机组成原理》那本书里的东西，原样搬到LLM的世界里。

坦率的讲，你想想看过去60年整个计算机体系结构的历史，其实就是一部「怎么让本来是串行的指令跑得更并行」的历史。指令流水线、乱序执行、超标量、分支预测，这些听着就头大的名词，说到底都是在干一件事，就是让CPU不要一条指令一条指令傻乎乎地等，能同时干的活就一起干。

这套东西人类已经研究得非常透了。透到什么程度呢？透到你今天买一颗普通的i5芯片，它每个时钟周期能同时发射的指令数，大概是80年代那种整栋楼的超级计算机的水平。

但是。

当我们把LLM当成一种新型处理器去用的时候，这套智慧全忘了。

现在几乎所有的Agent框架，底层都是一个叫ReAct的东西。它是Yao等人2022年提的，全称是Reason + Act。工作方式非常朴素，想一步，做一步，看结果，再想一步，再做一步，再看结果。它是一个循环。

听着很自然对吧？它确实自然。但你仔细看就会发现，这玩意从执行效率上来说，跟那种每次只能执行一条指令、做完一条才开始下一条的远古处理器，是一样的。

一次一条。干等。

而且这个问题在越来越多的Agent场景里暴露得越来越厉害，因为我们现在给Agent的活越来越复杂，一次要调用的工具越来越多。ReAct的串行执行就成了一个越来越重的镣铐。

回到LLMCompiler这块。

作者的思路简单粗暴，既然Agent执行工具调用的过程跟CPU执行指令长得一样，那就直接套编译器的架构好了。他们搞了三个组件。

第一个叫 Function Calling Planner，函数调用规划器。你可以把它想象成编译器里那个分析语义、构建依赖图的部分。用户给了一个问题，比如论文里举的那个例子，「微软的市值需要涨多少才能超过苹果？」，Planner要做的事情是先把这个问题拆成几个独立的任务，再搞清楚这些任务之间谁依赖谁。

它会拆成三步。

一，去查微软的市值。二，去查苹果的市值。三，用一个数学工具做减法，把差值算出来。

然后它会发现一件事，任务1和任务2，彼此没有任何关系。它们完全可以同时去查。只有任务3需要等前两个都拿到结果。

这就是一张 DAG，有向无环图，编译器里最核心的数据结构之一。

第二个组件叫 Task Fetching Unit，任务获取单元。这个名字直接就是从CPU里偷来的。

在现代CPU里有一个东西叫指令获取单元，它的任务是一旦前一条指令把某个寄存器的值算出来了，立刻把依赖这个寄存器的下一条指令发射出去，别等一整串指令都准备好再开搞，那样太慢。

LLMCompiler的Task Fetching Unit做的事完全一样。Planner一吐出DAG，它就开始扫描，发现哪些任务的依赖已经解决了，立刻往下扔。任务1和任务2没有依赖？好，同时发射，两个搜索并行执行。任务3等着1和2的结果？好，等它们回来我再把结果塞进任务3里，然后发射。

整个过程是流式的。Planner一边在吐计划，执行器一边在干活，中间没有「等Planner把所有计划全想完再开始」这种停顿。论文里专门做了个消融实验，流式处理本身就贡献了一个量级的加速。

第三个组件叫 Executor，执行器。这个没啥好说的，它就是真正去调工具的那个家伙。Task Fetching Unit告诉它哪个工具可以调了，它就调。

三个东西加起来，整个架构就跟一台小号的CPU一模一样。有人分析程序，有人调度，有人执行。

说到这我真的有点被打动。你知道我为啥被打动吗？因为这个思路其实任何一个学过编译原理的本科生都能想到。它没有任何复杂的数学，没有什么神秘的训练技巧，就是把一个用了60年的老配方，拿来炒一道新菜。

但它偏偏有效。而且效果好到离谱。

顺着上面的再聊聊，这篇论文最让我兴奋的其实是实验结果部分。

作者用了四个benchmark来测试LLMCompiler。这四个测试排起来有一个隐藏的升番结构，从最简单的场景到最复杂的场景，效果一个比一个炸。我逐个说一下。

第一个叫HotpotQA。这是个很经典的多跳问答数据集，论文的Figure 1就举了一个例子，「斯科特·德瑞克森和埃德·伍德是不是同一个国籍？」这种问题。用ReAct的话就是一步一步来，先搜A，拿到结果，再搜B，拿到结果，再对比。用LLMCompiler的话，A和B可以同时搜。

速度快了1.8倍。成本降了3.37倍。准确率基本一样。

就这个结果拎出来看已经很能打了，但它只是开胃菜。

第二个叫Movie Recommendation。这个更有意思，它每次要你从8部电影里找出跟某部电影最像的那部。也就是要对8部电影分别做独立的搜索和分析。

ReAct在这里干了一件特别傻的事。论文附录里有一张图我看完直接笑出声，它显示有大约85%的样本，ReAct根本没搜完8部就结束了。它搜到第五部就停下来，觉得「我好像够了」，然后给一个答案。

你敢信？？？

一个号称能干活的Agent，居然连把活干完都做不到。它会提前认输。

LLMCompiler在这里就完全没这个问题，因为Planner一开始就把8个任务全部规划好了，Executor必须全部执行完才能汇总。结果是速度快了3.74倍，成本降了6.73倍，准确率还反超ReAct 7个多点。

第三个叫Game of 24。这游戏你们可能玩过，给你4个数字让你用加减乘除搞出24。之前最强的解法叫Tree-of-Thoughts，让LLM自己去搜索各种可能的组合。LLMCompiler在这里做了一个很骚的事，它把「Tree-of-Thoughts的一次尝试」当成一个工具，然后让Planner去并行调度这些尝试。

速度快了2倍。

到这里我已经觉得够牛了。

但是真正让我给整不会的是第四个benchmark，WebShop。这是一个模拟网上购物的环境，你要在一堆商品里找到符合某些需求的那一个。典型的操作是搜索→看结果→再搜索→再看结果。

LLMCompiler在这里直接跑出了101.7倍的加速。

不是10倍，不是50倍，是一百零一点七倍。

而且成功率还比ReAct高了25.7个百分点。

我第一次看到这个数字的时候真的愣住了。我来回看了好几遍论文的表格，生怕自己看错了小数点。101.7x。

它的原因其实非常直观。WebShop里有大量「先广撒网再选最优」的搜索动作。LLMCompiler可以一口气把所有候选搜索并行发射出去，而ReAct得一个一个搜。你想想，如果你在淘宝上找一个东西，你是一次打开十几个标签页横向对比，还是一个一个点开再返回再点开？

答案很明显。

但前者需要你有一个「规划」的能力，得先知道哪十几个是值得看的。这恰好就是LLMCompiler在做的事。

这块需要注意一下。LLMCompiler的意义不只是快，还有一个更深的点，它顺手救了准确率。

这个我刚才提到了一嘴，但值得展开说说。作者分析了ReAct失败的案例之后发现，这些失败的绝大多数其实跟智力无关，跟纪律有关。

两种典型的失败场景。一种是提前收工，它只搜了部分信息就觉得够了，开始瞎答。另一种更惨，是它会在同一个查询上无限循环，因为Wikipedia返回的信息不够精确，它就一直搜一直搜一直搜，直到context window爆掉。

这两种失败加起来，贡献了ReAct绝大部分的失败样本。

为啥会这样？我自己的理解是，ReAct是一种即兴架构。它没有全局视野，每一步都是基于上一步的观察临时决策的。这种即兴决策模式很像我们人脑，但它也天然带着人脑即兴决策的毛病，容易累、容易放弃、容易走进死胡同。

LLMCompiler强迫模型在一开始就把所有要做的事列出来，这等于逼着它做一次系统性的规划。规划好了之后，执行阶段就只负责执行，不再思考。

我觉得这里有一个非常深的启发。我们过去几年一直在迷信让LLM多想一步，搞出了Chain-of-Thought、Tree-of-Thoughts、Self-Reflection各种花活，都是在鼓励模型「思考得更细、更久、更多」。但其实有时候反过来，让它先想一次然后别再想了，反而更管用。

CPU的设计哲学其实也是这样。现代CPU里最快的指令是那些不需要跳转、不需要预测、不需要动态决策的指令。凡是涉及到走一步看一步的指令，都会拖慢整条流水线。

计算机硬件的人早就发现了，即兴决策是昂贵的。

而这个老道理，现在又回到了AI Agent这边。

坦率的讲，我觉得LLMCompiler这篇论文本身可能不是最大的新闻。真正的新闻是它揭示的那个更大的趋势。

我们正在把整个计算机体系结构，重新发明一遍。

你仔细想想这几年LLM推理和Agent方向上那些最亮眼的突破，几乎每一个都能在老教科书里找到原型。

Speculative decoding，是把CPU的分支预测搬到了LLM推理。 KV cache，是把CPU的cache机制搬到了LLM推理。 Continuous batching，是把操作系统的进程调度搬到了LLM推理。现在LLMCompiler，是把编译器的指令调度搬到了LLM Agent。

每一个都在发生。每一个都带来10倍甚至100倍的加速。每一个的核心创意都不是横空出世的神来之笔，而是一句「等等，这个问题我们在硬件/OS层面已经解决过了，直接拿来用就好」。

卡帕西前阵子说过一句我记了很久的话，他说LLM是一种新的计算机，一种以自然语言为指令集的计算机。这句话如果你真的认真对待，那它的所有推论都是自洽的。既然它是一种新的计算机，那我们给旧计算机发明的所有优化技巧，理论上都应该能再用一次。

我有时候会觉得，我们这一代做AI的人特别幸运。我们在亲眼看一部已经拍过一遍的电影，被用新的道具重新拍摄。剧本是一样的，角色是一样的，剧情走向都是一样的。但因为道具全换了，看起来就像一部全新的片子。而且你手里只要有一本原版的剧本，你就能提前知道下一幕会发生什么。

回到这篇论文本身。

我觉得它最重要的贡献其实不是那些benchmark数字，而是它开了一个非常清晰的方向。那就是Agent的慢不是不可解决的。

你今天用Claude Code等十分钟，不是因为LLM笨，也不是因为你的任务太复杂。是因为底下那套调度系统还在用ReAct这种20世纪60年代级别的执行模式。只要换上哪怕一个粗糙的编译器思路，立刻就能快10倍、快100倍。

其实这两年已经有不少框架在往这个方向走了，LangGraph、LlamaIndex都陆陆续续搞过类似的planner组件，多Agent框架里的并发调度也都能看到这套思路的影子。但奇怪的是，我们日常在用的那些最主流的Agent产品，Claude Code、Cursor这些，还是没有把这套东西吃得特别透。你还是经常能看到它们在那里一步一步串行地跑，跑得你抓狂。

我始终觉得这是一件很可惜的事。一个两年前就该被充分吸收的好思路，到今天还只在部分框架里存在，绝大多数用户还是在吃ReAct的苦。

其实之前OpenAI做过一个简化版，它叫Parallel Function Calling。但这篇论文里也明确对比了，OpenAI那个只能处理最简单的、完全独立的并行任务，一碰到有依赖关系的就歇菜了。LLMCompiler能处理有依赖的完整DAG，这是质变。而且论文在ParallelQA这个他们自己造的benchmark上，直接把OpenAI的并行函数调用给干穿了。

还有一个让我很开心的点，LLMCompiler不依赖特定模型。它能跑在闭源的GPT系列上，也能跑在开源的LLaMA-2 70B上，效果都很好。这意味着你要用它，不需要求爷爷告奶奶去办一个特殊API，自己拿个开源模型搭一套就能跑。对整个开源生态是实实在在的利好。

论文的代码早就开源在 https://github.com/SqueezeAILab/LLMCompiler ，这两年我零零散散跑过一些例子，整体感觉是它确实好使，但对Planner的prompt质量非常敏感，稍微写粗糙一点就容易崩。这大概也是为啥它没在主流产品里全面铺开的原因之一，论文里优雅的架构，落到工程上总会多出一堆脏活。

最后说点题外话。

我一直觉得AI这个行业最迷人的地方，就在于它需要你是一个杂食动物。你得懂一点机器学习，懂一点系统，懂一点产品，懂一点用户。因为AI正在跟所有领域发生化学反应，任何一个你以为已经过时的角落，都可能突然长出一个全新的方向。

LLMCompiler这篇论文就是一个典型的例子。它既不需要你是最顶尖的ML研究员，也不需要你是最强的系统工程师。它需要你有一个能从「我的LLM Agent跑得好慢啊」跳到「诶等等，CPU当年也有这个问题，是怎么解决的来着？」的跨界联想能力。

我始终觉得这种联想能力，比任何单一领域的深度都重要。

很多朋友问我怎么跟上AI的发展。我有时候觉得，与其拼命去看最新的模型发布，不如回头去翻翻那些老的、经典的、看起来跟AI毫无关系的书。编译原理、操作系统、计算机网络、数据库系统、图形学。这些书里有太多你以为已经过时的东西，在LLM时代突然又活了过来。

你读过的每一本旧书，都可能在未来某天变成一枚重新上膛的子弹。

前提是你得先把枪挂在墙上。

以上。

干货 | 轻量级驾驭工程：AI Coding Workflow 最佳落地实践

Mon, 30 Mar 2026 11:58:33 +0000

导读：在 AI 辅助编程普及的今天，你的团队是怎么写代码的？是靠开发者随心所欲的“自然对话”，还是有严谨的工作流约束？本文将为你详细拆解“轻量 Harness 化 AI 研发工作流”的设计思路、工具选型与落地路径。无论你是独立开发者还是研发团队负责人，这套直接可抄作业的 Workflow 都不容错过。

一、 AI 编程的“向左走向右走”

当前 AI 编程的实践，大致演化出了两条截然不同的路径：Vibe Coding 与 规范驱动开发 (SDD)。

维度	🎨 Vibe Coding (直觉编程)	📐 规范驱动开发 (SDD)
核心理念	自由交互，强调开发者与 AI 的自然对话	规范先行，以 Spec 为唯一事实来源
适用场景	快速原型、概念验证、探索性开发	生产环境、复杂系统、高质量要求
侧重点	提示词 (Prompt) 工程的灵活性	规范的严谨性与完整性

⚠️ Vibe Coding 的隐患：

随着大模型能力的增强，Vibe Coding 搭配插件确实能快速出活。但在团队级实践中，它暴露出 4 个致命问题：

1.效果不可控：不同模型、不同 Prompt 风格的产出质量参差不齐。

2.幻觉难约束：缺乏结构化约束，强如顶尖模型也会“胡编乱造”。

3.技术债隐蔽：表面跑通了，底层可能埋下了架构和质量的“雷”。

4.协作难统一：个人习惯各异，大规模协作时极易失控。

正是为了系统性解决这些痛点，SDD (Spec-Driven Development) 应运而生。

二、什么是 SDD？它为什么重要？

💡 核心理念： 在 SDD 中，规范（而非代码）才是唯一的事实来源。开发者编写严谨的自然语言规范，由 AI 自动生成、测试并维护代码。参考阅读：GitHub Spec-Driven Development

采用 SDD，意味着研发范式的三大转变：

○🔄 权力反转：过去是“需求文档服务于代码”（代码写完文档就废了）；现在是“代码服务于规范”（代码只是规范的衍生品）。

○🛤️ 工作流重塑：修 Bug 或加功能，不再直接改代码，而是先更新规范，再让 AI 重新生成代码。

○🛡️ 两道防线约束质量：

▫模板约束：强制 AI 聚焦业务逻辑。遇到模糊需求必须提问（[需要澄清]），杜绝瞎猜。

▫架构宪法：设定硬规则（如：必须先写测试并确认失败，才能写业务代码；强制模块化等）。

🎯 终极价值：消除需求与实现之间的鸿沟，让程序员从“敲代码的打工人”进化为“定义系统意图的架构师”。

三、击中痛点：告别“实现漂移”

主流 AI 工作流为何纷纷拥抱 SDD？因为它解决了一个核心顽疾——实现漂移 (Implementation Drift)。

在随意的 Vibe Coding 中，代码层的知识无法被提取和固化。AI Agent 就像一个失忆的工人，缺乏上层显性知识和关键上下文，导致：

○效率低下：每次开发都要让 AI 重新从底层啃代码，无法高层建瓴。

○知识断层：编程规范、技术约束无法沉淀。

○协作困难 & 质量崩塌：Bug 和技术债越滚越大。

四、主流 SDD 工作流大比拼

社区中已涌现出众多优秀的 SDD 实践方案，我们进行了深度体验对比：

工作流	定位与特色	GitHub 仓库	实践痛点
Spec-Kit	官方工具链，全链路 (constitution/spec/plan/tasks/implement) 完整	github/spec-kit	流程重、Token 消耗大、耗时长、维护成本高
OpenSpec	轻量级 SDD 实现，更灵活	Fission-AI/OpenSpec	需人为设计流程，上手门槛较高
GSD	强调 fresh context 和 map-codebase 的分阶段框架	gsd-build/get-shit-done	棕地项目知识总结极佳，但完整流程耗时长
superpowers	Skills 驱动，强调 brainstorming, TDD 和 review	obra/superpowers	亮点突出，但整体流程中部分步骤相对薄弱
compound engineering	闭环流程 (Brainstorm→Plan→Work→Review→Compound)	EveryInc/compound-engineering-plugin	流程合理，但对棕地项目的存量知识沉淀不足

结论： 在生产环境中，我们需要平衡开发效率、代码质量和 Token 成本。目前没有任何单一工作流能完美兼顾，强行绑定只会让开发体验打折。

五、破局策略：组合最优解（缝合怪战术）

基于上述痛点，我们的落地策略是：取各家之长，组合使用。

○阶段一（当下）：做“缝合怪”。串联 GSD + compound engineering + superpowers 的最佳环节，先跑通验证。

○阶段二（未来）：逐步过渡到自研工作流，形成完全契合团队基因的 AI 编程链路。

🛠️ 工具选用原则与雷达图：

流程环节	选用工具	选用理由（最佳平衡点）
🔍 Codebase 分析	GSD `/gsd:map-codebase`	对棕地项目（遗留系统）分析最全面完整
🧠 Brainstorm	CE `/ce:brainstorm`	探索速度与效果的最优平衡
📝 Plan	CE `/ce:plan`	兼具效率和生成质量，Token 消耗合理
💻 Work	Claude Code / Codex	无需特殊指令，明确方案下 AI Agent 自主能力已足够
👀 Review	superpowers (自然语言)	综合表现最佳：不慢、不冗长、反馈极具价值
📈 Compound	GSD `/gsd:map-codebase`	支持增量更新，自动识别并沉淀项目变化

(注：CE 为 compound engineering 的简称)

六、终极实战：六步法完整工作流

综合打磨后，我们得出了这套黄金六步法。它与 Compound Engineering 的流程高度重合（因其设计合理），但我们补齐了 Codebase 环节，并替换了部分步骤的具体实现。

👣 Step 1: Codebase (建立项目认知)

○执行方式：运行 GSD 的 /gsd:map-codebase。

○作用：并行拉起多个代理，全面提取架构文档、规范、外部集成、技术栈、风险点。为后续开发提供关键上下文。

👣 Step 2: Brainstorm / Research (技术方案探索)

○执行方式：运行 /ce:brainstorm。

○作用：结合项目现状探索可行性方案，效率与效果极佳。

👣 Step 3: Plan (制定开发计划)

○执行方式：运行 /ce:plan。

○作用：总结探索成果，输出高质低耗的开发计划。

👣 Step 4: Work (执行开发)

○执行方式：直接对话使用 Claude Code 或 Codex。

○作用：为什么不加约束？因为前置方案已明确，放开手脚让 AI 自主调用工具和子代理，反而能最大化效率。

👣 Step 5: Review (代码审查)

○执行方式：通过自然语言触发 superpowers，例如：

“用 superpowers 对最新的一次 commit 进行 code review”

○作用：提供速度适中、精炼且极具价值的代码质量反馈。

👣 Step 6: Compound (知识复利)

○执行方式：再次运行 /gsd:map-codebase。

○作用：沉淀显性知识（业务逻辑、技术决策等）。支持增量识别，无需每次代码变更都执行。建议执行时机：Feature 完成时、做出重要技术决策时、架构显著变化时。

七、灵活适配：按场景“裁剪”流程

全套流程虽好，但没必要杀鸡用牛刀。团队可根据任务粒度自由裁剪：

○🚀 完整 Feature 开发 (工作量大)：Codebase → Brainstorm → Plan → Work → Review → Compound

○🏃 中等粒度任务 (方案清晰)：Codebase → Work → Review → Compound

○🔧 小型修复/调整 (日常 Bug)：Codebase → Work → Review

○🩹 快速修补 (十万火急)：Codebase → Work

⚠️ 避坑指南： 即使使用短流程，也要记得定期执行 Compound (/gsd:map-codebase) 沉淀知识，防止“实现漂移”死灰复燃！

八、建立知识沉淀体系（动静分离策略）

通过上述 Workflow，项目会自然沉淀出两类核心资产，我们称之为动静分离：

1.🔄 Codebase 文档 (动态，全队共享)

由 /gsd:map-codebase 自动刷新，包含项目结构、模块关系、依赖分析。它是 AI Agent 的“实时地图”。

2.📌 CLAUDE.md / AGENTS.md (静态，手动维护)

用于兼容不同 AI 工具的内容一致性文件。主要记录开发规范、技术约束、业务规则和“绝对禁区”。不频繁变更。

(除这两者外，其他过程文档在开发结束后可直接删除或归档。)

九、驾驭工程的核心：上下文工程

有工具还不够，AI 编程的终极壁垒是：将隐性知识转化为显性知识。

不要指望 AI 自己去翻代码找表结构，这不仅慢而且容易错。我们需要主动投喂“AI 友好的知识形态”（Context Engineering）。

✅ AI 喜欢的格式：

○.md Markdown 文件 (如 PRD 文档)

○.sql 数据库脚本 / 表结构导出

○结构化的 Schema / JSON / YAML (如 UI 交互描述)

○CLI 命令行工具 / Bash 脚本

❌ AI 讨厌的格式：

○Word、Excel、PPT 等非结构化办公文档。

落地建议： 团队需建立规范，确保业务规则、设计图和数据结构在进入工作流前，已被转化为上述机读友好的格式。这是划定 AI 操作边界、消除幻觉的关键。

🛠️ 附录：工具链安装避坑指南

为了方便大家上手，我们整理了三大工具的安装差异。整体结论：建议统一使用 Claude Code 执行工作流，支持度最好。

工具	Claude Code 安装姿势	Codex 安装姿势	差异与踩坑点
GSD	`npx get-shit-done-cc --claude --global` (或 `--local`)	`npx get-shit-done-cc --codex --global` (或 `--local`)	同一个 installer，Codex 侧是 skills-first，最省事。
superpowers	`/plugin install superpowers@claude-plugins-official`	需 clone 仓库 + 建立 symlink 到 Codex skills 目录。详见 Codex 官方文档	明显 Claude-first，Codex 需要繁琐的手工安装。
compound-engineering	先 `/plugin marketplace add EveryInc/compound-engineering-plugin`
再 `/plugin install compound-engineering`	`bunx @every-env/compound-plugin install compound-engineering --to codex`	Claude 是原生插件；Codex 是转换安装（且官方标明为 experimental）。

🔗 传送门：

○GSD: https://github.com/gsd-build/get-shit-done

○superpowers: https://github.com/obra/superpowers

○compound-engineering: https://github.com/EveryInc/compound-engineering-plugin

Google 刚刚把多模态检索，从“拼装工程”变成了“基础能力”

Thu, 12 Mar 2026 02:51:44 +0000

过去几年，多模态检索一直有一种很别扭的感觉：大家都知道它重要，也都知道它有价值，但真要落地，往往就会迅速滑向一场“拼装工程”。文本一套模型，图片一套模型，音频最好先转写，视频最好先抽帧，PDF 还要单独解析。最后系统看起来像是“能搜”，可背后其实是五六条处理链硬拼在一起，复杂、昂贵，而且很难优雅。

Google 新发布的 Gemini Embedding 2，真正让人眼前一亮的，不是它又把 embedding 做强了一点，而是它第一次把文本、图片、音频、视频、PDF拉进了同一个统一向量空间里。官方把它定义为 Google 首个原生多模态 embedding 模型，目前已经通过 Gemini API 和 Vertex AI 进入 Public Preview。

这件事听上去像模型更新，实际上更像一次架构层的洗牌。因为从这一刻起，多模态检索终于不再只是“大厂能做、小团队很难做优雅”的高级能力，而开始像一项真正的基础设施：可以被调用，可以被组合，也可以被更低成本地接进你的搜索、RAG、知识库和内容系统里。

它到底强在哪，不只是“支持多模态”

很多人看到这里，第一反应可能是：

“支持文本、图片、音频、视频、PDF，这不就是多模态吗？”

还真不止。

Gemini Embedding 2 的关键不只是“什么都能输进去”，而是所有模态出来以后能落在同一个 embedding space 里。这意味着什么？意味着你不再一定要为每种媒介维护完全独立的语义体系。文本可以搜图片，图片可以召回 PDF，音频可以关联视频片段，跨模态检索终于不是一层额外的“补丁能力”，而成了模型本身的默认能力。

这会直接改变系统设计思路。

以前你更像是在设计“五条平行管线”。

现在你更像是在设计“一个统一召回底座”。

注意，我这里说的是“更像”，不是说所有复杂度从此消失。长视频仍然要切片，复杂知识库仍然要做 metadata 设计，高要求场景依然常常需要 rerank。

最值钱的地方，是它终于不再要求你先做“翻译官”

过去处理非文本内容时，行业里一个非常常见的默认动作是“先降级成文本”。

●音频？先 Whisper。

●视频？先抽帧，最好再加字幕。

●PDF？先 OCR，再抽正文。

这类方案当然能工作，但本质上是在让系统把所有模态都挤进“文本入口”里。Gemini Embedding 2 做的，是把入口重新打开。它可以原生摄取音频，不需要中间文本转写；视频支持约 2 分钟级别的原生输入；PDF 也可以直接嵌入。

这意味着搜索开始更接近人真正理解世界的方式。

●你问“哪节课讲过这个图”，系统不一定非要先把整门课转成文本再去关键词匹配；

●你上传一段声音，也不一定非得先变成文字才能参与检索；

●你搜一个商品，也不一定要把图和文分开索引，最后再人工拼装成“结果页”。

一个特别容易被低估的能力：它可以表示“实体”，不只是“素材”

Gemini Embedding 2 还有一个很值得说的亮点：它支持混合输入。

如果你在一个 content entry 里传入多个 parts，比如“文字 + 图片”，模型会为这组内容生成一个聚合后的 embedding；如果你在 contents 数组里放多个独立条目，它则会返回多个独立向量。官方文档甚至直接建议：对于像社交媒体帖子这种包含多种媒体内容的复杂对象，可以把多个 embedding 聚合，形成一个 post-level representation

这件事非常关键。

因为它把 embedding 的对象，从“原子素材”升级成了“业务实体”。

一块手表，不只是商品图，也不只是商品描述；

一条社交帖子，不只是文字，也不只是配图；

一堂课程，不只是讲义 PDF，也不只是视频和录音。

过去这些东西往往是拆开建索引、拆开召回、最后在上层硬拼。

现在你可以在索引层就把它们当成一个“对象”来表示。

这对于做内容平台、商品搜索、企业知识库、课程检索，影响都非常大。因为从这里开始，RAG 的检索单元不再只能是 text chunk，它可以是一个帖子、一个商品、一段课堂内容，甚至一个带图文说明的复杂知识实体。

3072 维不是重点，重点是你终于可以按成本来调“语义密度”

做系统的人都知道，维度本身并不是越大越好。更大的维度意味着更高的存储成本、更高的计算开销、更长的检索延迟。Gemini Embedding 2 默认输出 3072 维，但支持用 output_dimensionality 调整维度，官方推荐的常见选择是 768、1536、3072，并说明它支持从 128 到 3072 的灵活输出。这个能力背后用的是 MRL（Matryoshka Representation Learning）

简单说就是：你可以根据场景，在“效果”和“成本”之间做更细粒度的平衡。

●如果你是大规模通用检索，1536 维可能就已经很香；

●如果你追求极致成本和吞吐，768 维会很有吸引力；

●如果你做的是高价值高精度场景，3072 维会更稳。

免费吗？多少钱？

Gemini Embedding 2 现在有两条主路径，想快速试、想低门槛上手，用 Gemini Developer API；想走企业治理、云权限、生产环境，走 Vertex AI。

第一条是 Gemini Developer API。

这一条更轻，适合开发者快速试。官方价格页明确写了：gemini-embedding-2-preview 当前有 Free Tier，文本、图片、音频、视频输入在免费层里都是 Free of charge。免费层数据 Used to improve our products: Yes；如果切到付费层，这一项会变成 No。付费价格方面：

●标准模式下文本是 $0.20 / 1M tokens

●图片约 $0.00012 / 张

●音频约 $0.00016 / 秒

●视频约 $0.00079 / 帧；

如果用 Batch API，价格大约是标准价的 50%。

第二条是 Vertex AI。

这一条更偏企业与云上生产环境。你需要 Google Cloud 项目、启用 billing、开启 Vertex AI API，并配置认证；而且 AI Studio 的 API key 不能直接用于 Vertex AI。模型页还写明：Gemini Embedding 2 当前支持的是 Standard PayGo，不支持 Provisioned Throughput、Flex PayGo、Priority PayGo 和 Batch Prediction，当前页面列出的区域是 us-central1。Vertex AI 价格页对它的专属条目写的是：

●文本 $0.2 / 1M tokens

●图片 $0.00012 / image

●视频 $0.00079 / frame

●音频 $0.00016 / sec

●输出不收费。

两个很容易踩的坑

第一个坑，是不要把旧向量直接拿来和新模型混用。

gemini-embedding-001 和 gemini-embedding-2-preview 的 embedding spaces 不兼容。也就是说，如果你准备升级到 Gemini Embedding 2，旧数据不能直接拿来比较，你需要重新做一遍 re-embedding。这对已经有存量索引库的团队来说，是非常现实的迁移成本。

第二个坑，是不要把“视频支持时长”写得过于绝对。

目前官方资料里有三种写法：

●Google 博客写的是支持最多 120 秒视频；

●Gemini API 文档写的是视频上限 128 秒；

●Vertex AI 模型页则更细，写成带音频视频上限 80 秒，不带音频视频上限 120 秒。

所以总结来说它当前具备 2 分钟级别的视频原生 embedding 能力，更长的视频仍建议切片后索引。

它不会消灭所有复杂度，但它确实改写了“默认架构”

Gemini Embedding 2没有神奇到让多模态检索从此没有工程问题。

它不会自动帮你解决 metadata、chunking、权限隔离、召回融合、在线延迟、索引更新这些老问题。

但它确实把过去那种“多模态一定要多套模型、多套索引、多阶段拼装”的默认范式，往前推了一大步。

更重要的是，这一步不是停留在“论文层面”的。Google 已经给出了官方接入路径，也已经列出 LangChain、LlamaIndex、Haystack、Weaviate、Qdrant、ChromaDB 和 Vertex AI Vector Search 等生态集成方式。也就是说，这不是一个“看上去很厉害但暂时用不起来”的能力，它已经开始变成开发者今天就能碰、今天就能试、今天就能接进系统里的东西。

所以，Gemini Embedding 2 真正改变的，可能不是“embedding 这个模型又进步了多少”，而是：

Google 终于把多模态检索，从一项需要大量拼装和妥协的工程活，推进成了一种更统一、更自然、更接近基础设施的能力。

最后

如果文本、图片、音频、视频、PDF 真的开始共享一个语义空间，接下来最值得重新思考的问题，也许就不再是：

“我还能接多少模型？”

而是：

在我的系统里，什么才算一个真正值得被检索的对象？

是一段文字，

是一页 PDF，

是一张图，

是一条帖子，

还是一个由图文、声音、视频共同组成的“实体”？

Gemini Embedding 2 给出的，不只是一个新模型。

它更像是在提醒所有做 AI 应用的人：

下一代检索系统要统一的，从来不只是接口，而是我们理解世界的入口。

OpenClaw 爆火背后：它不是聊天机器人，而是一套真正会做事的 AI 系统

Wed, 11 Mar 2026 10:14:30 +0000

如果你最近在 GitHub 上关注过 AI Agent 领域，大概率已经看到过 OpenClaw。到 2026 年 3 月 10 日，它的 GitHub 仓库已经来到约 297k stars，超过了 React 的约 244k 和 Linux 的约 222k。更重要的不是数字本身，而是它火起来的方式：它不是靠一个漂亮网页，也不是靠一个“会聊天的套壳”，而是靠一整套把大模型接入真实消息渠道、真实设备、真实浏览器、真实文件系统的系统架构，硬生生把“AI 助手”做成了一个长期在线的工程系统。

但如果你只把 OpenClaw 理解成“接了很多 IM 的机器人”，你会完全错过它最有价值的部分。OpenClaw 官方 README 写得很直白：“The Gateway is just the control plane — the product is the assistant.” 这句话几乎就是读懂整个项目的钥匙。它的重点从来不是“有多少入口”，而是：有没有一个统一控制面，把消息、状态、路由、模型、工具、节点、权限和安全边界收在一起。 README、架构文档和 Vision 文档都在强调同一件事：OpenClaw 想做的是“真正会做事的 AI”，运行在你的设备、你的渠道、你的规则之内。

这篇文章，我想尽量回答七个问题：

1.它到底是什么？

2.它为什么会采用现在这套架构？

3.Gateway 到底在系统里扮演什么角色？

4.Agent 是怎么运行起来的？

5.Memory、Workspace、Session 为什么是它的关键设计？

6.多 Agent、节点、工具体系是怎么拼到一起的？

7.以及最后，为什么它值得被看作下一代 AI 助手的典型系统样本。

在回答这些问题之前，我不得不说，现在龙虾有些过热了，对于想 “卖铲子” 的公司当然觉得这是好事，于是他们推波助澜，但对于专业人士不能人云亦云。openClaw 有它优秀的一面，也有被炒作夸大的一面，应该客观地看。

一、OpenClaw 的本质，不是聊天机器人，而是“个人 AI 助手控制面”

一句话定义 OpenClaw，我会这样说：

OpenClaw = 一个以 Gateway 为中心的个人 AI 助手控制平面，下面挂着嵌入式 agent runtime、会话系统、工具系统、消息渠道、节点设备和安全边界。

这个定义不是我自己拔高出来的，而是官方文档本身就在往这个方向写。

●README 说它是“你运行在自己设备上的 personal AI assistant”；

●架构文档说它是一个 single long-lived Gateway，拥有所有 messaging surfaces；

●Vision 文档则把它描述为“the AI that actually does things”，运行在你的设备、你的渠道、你的规则里。

把这些信息放在一起看，你会发现 OpenClaw 的设计起点根本不是一个“聊天 UI”，而是一个长期在线、可被多入口触发、可调用工具、可连接设备、可持续维护状态的 AI 系统。

这也是为什么我认为 OpenClaw 更接近“控制面”而不是“应用层”。在很多 AI 产品里，用户打开网页，输入问题，后端调一下模型，返回一段文本，交互就结束了。OpenClaw 则完全不是这种形态。它默认有一个长期运行的 Gateway 进程，消息渠道接到这个 Gateway，上层的 CLI、Control UI、WebChat 接这个 Gateway，macOS/iOS/Android/headless 节点也接这个 Gateway，甚至定时任务、exec approvals、pairing 和 health 事件都围绕 Gateway 展开。也就是说，Gateway 不是一个消息转发器，而是系统中枢。

二、Gateway 为什么是 OpenClaw 最关键的设计

OpenClaw 官方架构文档里最重要的一句话，是它把 Gateway 明确成 single control plane。一个长期运行的 Gateway 拥有所有 messaging surfaces；control-plane clients 通过 WebSocket 连进来；nodes 也通过 WebSocket 连进来，但会声明自己是 role: node；Canvas host 也由 Gateway 的 HTTP server 提供，而且默认和 Gateway 共用 127.0.0.1:18789 这个端口。

这意味着什么？意味着 OpenClaw 的系统设计不是“每个端各做一套逻辑”，而是“先做一个统一控制面，再让所有端接入它”。这在工程上有三个非常大的好处。

第一，状态是统一的。

会话在哪里维护？在 Gateway。

路由在哪里决策？在 Gateway。

设备配对、认证 token、事件广播、健康状态、cron、工具审批在哪里收敛？还是在 Gateway。

这让系统不会因为前端入口变多而出现多套状态、多个事实来源。

第二，协议是统一的。

Gateway protocol 文档明确写了：OpenClaw 不是“随便传一段 JSON”，而是有明确握手流程和版本约束的 WebSocket 协议。服务端先发 connect.challenge，客户端再带着 device identity、role、scopes、caps、auth、签名等参数发起 connect，通过后才返回 hello-ok。协议版本有 minProtocol/maxProtocol 协商，协议 schema 由 TypeBox 定义，再生成 JSON Schema 以及 Swift model。对一个跨 CLI、网页、桌面、移动端、节点设备的系统来说，这种 typed protocol 的价值非常高。

第三，能力是统一暴露的。

比如 Control UI 不是一个独立后端，而是 Gateway 在同一端口上提供的浏览器管理界面；WebChat 直接连 Gateway WebSocket；nodes 也不是第二套服务，而是带 role:node 的外围设备。也就是说，OpenClaw 并不是“一个 App + 一堆外挂”，而是“一个控制面 + 多个表面”。

很多人第一次看 OpenClaw，会把注意力放在“它居然支持这么多渠道”。但真正懂架构的人，会先看 Gateway。因为能不能把多个入口、多种设备、多条事件流、多种工具执行方式，全都压到一个长期运行的控制面里，决定了它到底是“一个功能”还是“一个系统”。OpenClaw 的做法很明确：先有控制面，再有助手。

三、它最强的抽象，不是对话框，而是 Agent、Session 和 Route

很多 AI 产品最基础的抽象单位是“聊天窗口”。OpenClaw 不是。

OpenClaw 的真正基础模型，是：

●谁来回复（Agent）

●回复落在哪段连续上下文里（Session）

●一条消息应该被路由到哪个 agent 和哪个 session（Route）

Agent：一颗完整隔离的大脑

Multi-Agent 文档里写得很清楚：一个 agent 是一个 fully scoped brain，拥有

●自己的 workspace

●自己的 agentDir

●自己的 auth profiles

●自己的 session store

它的文件、人格、配置、认证信息和会话历史都是围绕这个 agent 单独组织的。默认路径也很清晰：

●workspace 在 ~/.openclaw/workspace 或 workspace-<agentId>

●session 存在 ~/.openclaw/agents/<agentId>/sessions

●auth profile 在 ~/.openclaw/agents/<agentId>/agent/auth-profiles.json

这件事非常重要。因为这说明 OpenClaw 的多 Agent，不是“在一个上下文里换不同 system prompt 假装多人格”，而是真的把状态、身份、凭证和工作目录做成了隔离单元。但要注意，这种独立是为了让系统跑得更有条理，属于“防君子不防小人”的内部隔离。官方的意思很明确：同一个网关（Gateway）里的 Agent 默认都是“自己人”，不能把互不信任、甚至带有敌意的任务强行塞进同一个网关里，它并没有提供那种级别的安全防御。

Session：上下文连续性的主键

Session 文档里有一句特别关键的话：

OpenClaw treats one direct-chat session per agent as primary.

这句话可以理解成：对每一个 agent，OpenClaw 都认为它有一个“主私聊会话”

OpenClaw 默认会将一个 Agent 接收到的所有私聊（Direct Message, DM）都汇聚到一个主会话里（即 agent:<agentId>:<mainKey>）。对于群聊、频道或特定的话题（Thread），则会自动拆分独立处理。

对于 direct chat， agent 有一个规范意义上的主会话；默认所有 DM 都往这里归并，以保证连续性。

假设你有一个 agent 叫 main。默认情况下：

●你在 Web UI 私聊它一次

●之后又在 CLI 私聊它

●再后来在手机端私聊它

如果这些都被识别为 direct chat，而且你没有改 session.dmScope，那么这些私聊会折叠进同一个主 session,这样做的好处是：agent 会把这些私聊视为同一条连续对话，而不是三个彼此割裂的会话。

默认的主会话机制在单用户场景下很完美，但在多用户场景下就是一个巨大的安全漏洞。

如果 Alice 和 Bob 都去私聊同一个 Agent，在默认配置下，他们实际上是在向同一个“上下文沙箱”里写入数据。这就好比两个人共用一个日记本：

●Alice 刚和 Agent 聊完财务密码。

●Bob 接着去问 Agent“我们刚才聊了什么？”

●Agent 就会直接把 Alice 的密码复述给 Bob，造成严重的信息泄露。

为了应对多用户场景，OpenClaw 提供了 session.dmScope 配置，允许你在架构层面把私聊的上下文切分成更安全的细粒度：

●按发信人隔离（per-peer）。

●按频道+发信人隔离。(per-channel-peer)

●按账号+频道+发信人隔离(per-account-channel-peer)。

⚠️ 如果你在开发面向多用户的 AI Agent，绝对不能盲目使用默认的私聊配置。必须根据业务需求，通过调整 dmScope 将用户的对话状态彻底隔离开，防止你的 Agent 变成一个没有隐私边界的“大喇叭”。

Route：决定消息进入哪颗大脑

Channel Routing 文档把消息路由规则写得非常明确，一条消息发过来，绝对不是“哪个 Agent 闲着就扔给谁”，而是像网关（Gateway）匹配规则一样，必须严格按照优先级一层层往下筛，直到找到唯一确定的接收者。

我们可以用**“公司收发室分拣快递”**来打个比方，看一下这 5 层降级（Fallback）匹配规则：

1.精准单聊 (Exact peer match)：快递单上写着“直接交到张三本人手里”。

○明确的点对点直接交互，优先级最高。

2.跟帖/线程继承 (Parent peer match)：快递单没写名字，但备注了“这是昨天那个加急件的补充材料”。收发室一查昨天是李四负责的，直接给李四。

○识别 Thread 或上下文，让同一个 Agent 连贯处理同一个话题。

3.平台级群组与角色 (Discord guild+roles / Slack team)：快递写着“给财务部经理”或“给核心开发组”。

○根据外部平台（如 Discord/Slack）的特定权限组或大团队来分配对应的 Agent。

4.账号与频道 (Account / Channel)：快递写着“送到 3 楼会议室”或“交给官方客服号”。

○匹配特定的聊天频道或绑定的公共账号。

5.默认兜底 (Default agent)：啥也没写清楚的无主件，统统扔给“前台总机”处理。

○如果上面所有条件都未命中，最后由默认的 Agent 统一接管。

这意味着 OpenClaw 的“消息归属”不是模糊的。一条消息不是“谁在线谁回”，而是经过一套确定性规则，先判定该由哪个 agent 接管，再决定落到哪个 session 里。

所以 OpenClaw 能天然处理这些现实世界场景：

●同一个 Gateway 托管多个 agent；

●一个 Telegram 群给 work agent；

●一个 WhatsApp 家庭群给 family agent；

●一个 Slack team 给 support agent；

四、Agent 不是外挂调用，而是嵌入式运行时

很多人对 OpenClaw 最大的误解，是把它当成了一个简单的“任务调度员”——以为它只是在收到消息时，拉起一个外部的子进程（Subprocess）去跑一下，或者通过接口（RPC）远程调一下就完事了。

但架构文档明确指出：OpenClaw 是将 Agent 运行时“原生内嵌”到自己的网关里的。它不是把 Agent 当作一个不可控的外部黑盒，而是直接在内部实例化 Agent 的核心会话（AgentSession）。

Pi Integration Architecture 文档写得非常明确：OpenClaw 不是把 pi 作为 subprocess 或 RPC mode 的外部黑盒去调用，而是直接导入并实例化 pi 的 AgentSession，通过 createAgentSession() 把 agent runtime 嵌入到自己的消息网关架构里。

这种“深度内嵌”的架构设计，直接赋予了系统 6 大核心优势：

1.全局生命周期掌控：从对话的创建、挂起、恢复到销毁，网关层拥有绝对的控制权。

2.动态能力扩展：可以在运行时，随时把自定义的外部工具“塞”给 Agent 使用。

3.“看人下菜碟”的人设：能够根据消息来源（不同的平台渠道或上下文），动态切换 Agent 的系统提示词。

4.强悍的记忆管理：不仅能持久化保存对话，还支持高级的“记忆压缩（Compaction）”防止上下文爆满，甚至支持像 Git 一样对对话“开分支（Branching）”。

5.智能凭证轮询：在多个账号或 API Key 之间自动无缝切换，轻松应对并发和限流问题。

6.模型厂商解绑：底层的大模型想换就换，完全不受单一服务商（如 OpenAI、Anthropic）的绑架。

简单来说，OpenClaw 走的是“直接收编”的路线，它把 Agent 的核心大脑直接“拔”过来，原生种植在了自己的神经中枢里。这就好比你不再是打电话咨询外部专家，而是直接把这位专家招进了自家的核心指挥部。正因为“人”彻底成了内部员工，你才能拥有上帝视角般的掌控力：你可以全面接管他的作息安排（会话生命周期），随时往他手里塞各种定制兵器（动态注入工具），根据不同场合要求他扮演不同的角色（按渠道切换提示词），像操作代码仓库一样去整理甚至分叉他的记忆（支持压缩与分支的持久化），甚至连他背后的“脑力供应商”（随时无缝切换各家大模型）和权限账号，都能在底层悄无声息地替他自动轮换。说白了，OpenClaw 不是在和 Agent “跨部门合作”，而是直接把 Agent 融为了自己身体的一部分。换句话说，OpenClaw 不是“在用一个 agent”，而是“在拥有一个 agent runtime，并把它纳入自己的控制面”。这也是它跟很多“外接 Agent SDK 的应用层产品”最大的差别之一。别人只是调用，OpenClaw 是接管。

五、Agent Loop：一条消息的"真实旅程"

前面我们讲了 Gateway 如何把消息路由到正确的 Agent。现在让我们跟随一条消息，看看它进入 OpenClaw 后，到底经历了什么。

不是"一次请求"，而是一个完整生命周期

如果你习惯了网页聊天框的"发消息→等回复"模式，OpenClaw 的处理方式会让你有点意外。

传统模式：

⚡ 代码片段用户发消息 → 后端调用模型 → 返回文本 → 结束

OpenClaw 模式：

⚡ 代码片段用户发消息 → 分配 runId → 解析 session → 装配上下文 → 运行 agent → 流式返回事件 → 持久化 session → 结束

这一条链路，实际上就是你给 OpenClaw 发一句话之后，系统内部真实发生的事情。它不是“一次 HTTP 请求”，而是一个完整的运行生命周期。

OpenClaw 把你的消息视为一个进程而非请求。它会给这个进程分配ID、监控生命周期、管理并发、持久化状态。

并发控制：为什么同一聊天窗口的消息要"排队"？

想象一下这个场景：你在 Telegram 连续发了三条消息：

●“帮我查一下明天天气”

●“顺便看看日程”

●“把第一封邮件标为已读”

如果这三条消息并发执行，会发生什么？

●Agent 可能先处理了邮件，再处理天气

●Session 历史会乱序写入

●工具调用可能互相冲突

OpenClaw 的解决方案很简单：每个 session 串行化执行。这不是性能问题，而是状态一致性问题。长期在线的助手，必须保证"记忆"不会被乱序操作搞乱。是防止工具竞争和状态污染的工程必要选择。

流式事件：你看到的不是"打字动画"，而是真实的工作过程

OpenClaw 的流式输出，不是简单的"逐字显示"，而是三种事件流：

为什么要这样设计？因为这让用户能真正"看到 AI 在工作"。不是动画，不是假进度条，而是系统内部真实发生的事件被推送到前端。它的体验更像一个"正在办公的助手"而非"死寂的输入框"

六、真正让它“像一个人”的，不是模型，而是 Workspace、System Prompt 和 Memory

很多人体验 OpenClaw 后会有一种明显感觉：它比普通网页聊天更像一个“持续存在的助手”。这种感觉，核心不是来自模型，而是来自它对工作区、提示词和记忆的系统化设计

Workspace：AI 的家，而不是一个临时目录

简单说，Workspace 就是 AI 的"家"：

●它有固定的位置（~/.openclaw/workspace/）

●它有固定的文件结构

●它是 AI 长期工作的地方，不是临时落脚点

OpenClaw 在 Workspace 里约定了一整套"说明书文件"：

这个设计特别妙。因为它把很多系统会偷偷塞进 prompt 模板或数据库里的东西，变成了用户可见、可读、可改、可备份的文件系统资产。你不是在“配一个人设”，而是在维护一个 AI 的长期工作环境。

这里有一个非常重要的提醒：workspace 是默认工作目录，但不是硬沙箱（hard sandbox）；相对路径默认在 workspace 内解析，但绝对路径仍可能访问宿主机其它位置，除非你开启 sandbox。

System Prompt：每次运行都在"编译上下文"

OpenClaw 不是把用户的问题直接扔给模型，而是每次都重新构建一份完整的上下文：

1⚡ 代码片段System Prompt 结构：
2├── Tooling（可用工具列表）
3├── Safety（安全规则）
4├── Skills（技能列表）
5├── Workspace Context（工作区文件）
6├── Documentation（相关文档）
7├── Current Date & Time（当前时间）
8└── Runtime（运行环境信息）

Context 文档还补充了细节：默认会把 AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、BOOTSTRAP.md 等文件作为 Project Context 注入系统提示；技能本身只会注入“技能列表和描述”，真正的 SKILL.md 需要模型按需读取。

类比：

●传统聊天：像"临时起意打电话"

●OpenClaw：像"开会前先发会议议程和背景资料"

Memory：真正写到磁盘，才算记住

Memory 文档里我最喜欢的一句话是：

The files are the source of truth; the model only “remembers” what gets written to disk.

OpenClaw 默认的记忆结构非常简单，但非常工程化:

1⚡ 代码片段workspace/
2 ├── memory/
3 │ ├── 2026-03-10.md ← 今天的日志
4 │ ├── 2026-03-09.md ← 昨天的日志
5 │ └── ...
6 └── MEMORY.md ← 长期、精炼的永久记忆

两种记忆的区别：

检索机制：不是"只有文件"，也不是"只有向量"

OpenClaw 使用混合检索,它明确暴露了两个 agent-facing tools：

●memory_search 负责检索

●memory_get 负责精确读取某个 Markdown 文件或行段

1⚡ 代码片段用户问"我上次出差去哪了？"
2 ↓
3 BM25 关键词检索 ← 精确匹配"出差"
4 +
5 向量语义检索 ← 理解"去哪了"是问目的地
6 ↓
7 MMR 重排序 ← 去重、多样化
8 ↓
9 返回最相关的几条记忆片段

记忆刷新：在"遗忘"前先"存档"

OpenClaw 有一个很巧妙的设计：pre-compaction memory flush

当 session 接近上下文上限（比如对话太长，快塞不进模型窗口了），OpenClaw 会：

●触发一次"静默回合"（用户看不到）

●提醒模型：“把值得记住的信息写入记忆文件”

●然后再压缩上下文

七、工具体系：分层设计，不是堆砌功能

如果说 Gateway 是控制面，Session 是状态骨架，那么 Tools / Plugins / Skills 就是 OpenClaw 的执行肌肉。

OpenClaw 的工具体系有三个层次，很多人会混淆。让我们分清楚：

Tools：第一等公民

OpenClaw 暴露的是 first-class agent tools，不是外挂脚本。包括 browser、canvas、nodes、cron、gateway、session 相关工具、agents_list、image、pdf、message、exec 等。

OpenClaw 没有把“能力调用”做成 prompt 技巧，而是做成了运行时契约。Tool list 和 tool schema 会进入模型上下文；tool allow/deny、tool profiles、per-agent 工具策略、provider-specific 工具策略和 sandbox 工具策略共同决定模型实际能拿到哪些工具

Plugins：扩展系统本身

插件是运行在 Gateway 内部的代码模块，可以：

●注册新的 RPC 方法

●添加新的 HTTP 路由

●注册新的工具

●启动后台服务

类比：

●Skills：像"使用说明书"

●Tools：像"内置功能"

●Plugins：像"给系统装新器官"

Skills：教 AI 如何做事

每个 Skill 就是一个目录，核心是 SKILL.md——一份详细的操作指南。Skill 的三个来源（优先级从高到低）：

●<workspace>/skills/：当前工作区专属

●~/.openclaw/skills/：用户私有技能

●Bundled skills：系统内置技能

与Plugins的本质区别:Plugins是给手机增加新硬件（如外接摄像头）；Skills是相机APP里的"夜景模式"说明书。

八、Node：让 AI “有手有眼”

OpenClaw 严格区分了两个概念：

为什么这样设计？

如果把它们混在一起：

●Telegram Bot 只能干 Telegram 允许的事

●WhatsApp Bot 只能干 WhatsApp 允许的事

每个渠道都要重新实现一遍"控制电脑"的能力

OpenClaw 的设计：

●所有消息渠道都汇聚到 Gateway

●所有设备能力也汇聚到 Gateway

Gateway 负责调度：“这个 Telegram 消息需要控制 iPhone，我来协调”

Node 是什么？

node 是 companion device，可以是 macOS、iOS、Android 或 headless 设备；它通过和 operator 一样的 Gateway WebSocket 接入，但使用 role: “node”，向 Gateway 暴露一组命令面，比如 canvas.、camera.、device.、notifications.、system.*，再由 node.invoke 触发。官方还特别强调：nodes are peripherals, not gateways。消息还是落在 Gateway，不是落在 node

Node 是一台"伴侣设备"，它：

●通过 WebSocket 连接到 Gateway

●向 Gateway 暴露一组能力（camera、notifications、system…）

●等待 Gateway 的指令

类比：

●Gateway：大脑

●消息渠道：耳朵和嘴

●Node：手和脚

没有 Node 的话：

●Telegram Bot 无法直接控制你的 iPhone

●需要你自己手动截图,再发给 Bot

●AI 无法真正"替你做事"

有了 Node：

●AI 可以跨设备协同工作

●你在 Telegram 发指令,它在你的 Mac 上执行

●真正的"个人助手"体验

九、安全边界：诚实比承诺更重要

OpenClaw 的安全模型假设的是 one trusted operator boundary per gateway

OpenClaw 的安全文档非常诚实，这句话翻译成人话是：

这意味着：如果你把Gateway密码给朋友，让他也连进来，你们的对话历史、文件访问、记忆内容默认不隔离。这不是漏洞，是设计选择——为了简化架构，OpenClaw牺牲了多租户隔离，换取单用户场景下的极致能力。

安全层次

 1⚡ 代码片段外层：公网/外部消息源
 2 ↓
 3第一道门：Gateway 入口保护
 4 - token/password 认证
 5 - challenge 签名验证
 6 - device identity 校验
 7 - pairing 审批
 8 ↓
 9第二道门：权限控制
10 - operator / node 角色
11 - scopes 权限范围
12 ↓
13第三道门：执行保护
14 - tool policy（工具策略）
15 - exec approvals（执行审批）
16 - sandbox（沙箱隔离）
17 - allowlist（白名单）
18 ↓
19内层：高风险边界
20 - plugins = trusted code
21 - 插件和 Gateway 同等权限

Sandbox：可以隔离，也可以放行

OpenClaw 的沙箱设计非常灵活：

配置维度：

●mode：off / non-main / all（是否启用沙箱）

●scope：session / agent / shared（沙箱范围）

●workspaceAccess：none / ro / rw（工作区访问权限）

实际用法举例：

浏览器隔离：不是接管你的 Chrome

OpenClaw不会接管你的日常Chrome（那里面可能有银行登录态），而是拉起独立的Chrome Profile：

●独立的Cookie、缓存、扩展

●Agent专用，与你的个人浏览数据隔离

●支持截图、点击、PDF生成，但无法访问你个人的浏览器历史

这是"能力"与"安全"的折中：AI需要浏览器自动化，但不能拥有你的全部数字生活。

十、为什么这是"个人AI操作系统"的雏形？

OpenClaw 之所以值得研究，不是因为它 GitHub stars 多，而是因为它回答了一个未来会越来越重要的问题：

如果 AI 不再是网页对话框，而是一个长期在线、能操作设备、能记住一切的助手，它的系统架构应该长什么样？

OpenClaw 的答案是：

这套答案不一定是终局，也还远没到“完美”。Vision 文档自己都说，项目还很早，当前重点依然是 security、safe defaults、bug fixes、stability 和 setup reliability。也就是说，它依然在快速迭代，仍然带着实验性。

但它已经足够有代表性。因为它第一次比较完整地把“个人 AI 助手”这件事，从概念拉成了系统工程：

●消息不再只是消息，而是事件入口；

●模型不再只是回答器，而是运行时里的推理核心；

●工具不再只是 function calling 演示，而是被策略、审批和沙箱约束的系统调用；

●记忆不再只是“模型好像记得”，而是落到磁盘、可检索、可审计、可 Git 备份的工作区资产

它具备了"操作系统"的味道

不是说它替代 Windows 或 macOS，而是说它有那种系统级的感觉：

1⚡ 代码片段传统应用：打开 → 用 → 关闭
2操作系统：开机 → 长期运行 → 管理所有应用 → 关机
3
4传统 AI：聊天 → 结束
5OpenClaw：启动 Gateway → 长期在线 → 管理所有 Agent → 关闭

最后，再强调一次：OpenClaw 的本质，不是一个接了很多渠道的聊天 Bot，而是一套以 Gateway 为控制面、以 Agent/Session/Memory 为状态骨架、以工具与节点为执行面，把大模型真正接入现实世界的个人 AI 助手系统。

昨天面试官问我：一个 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 的预测分数。

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

嘿，朋友，做了个 AI 模型比价工具，想请你来试试

Thu, 22 Jan 2026 07:51:40 +0000

大家好，我是小盒子。

这两年 AI 大模型卷得厉害，GPT-4、Claude、Gemini、Llama……模型眼花缭乱，价格也是五花八门。作为一个经常要调用 API 的开发者，我经常想搞清楚一个问题：到底谁家的模型便宜？性价比高的是哪个？

说实话，每次想比较价格，我都得打开一堆浏览器标签页：AWS Bedrock 的定价页、Azure OpenAI 的价格表、OpenAI 官网、还有 OpenRouter……然后手动对比，算汇率，头都大了。更要命的是，这些价格还时不时更新，上周看的数据，这周可能就变了。

不知道你有没有同感：

●想用 Claude 3.5 Sonnet，但不确定是直接调 Anthropic 便宜，还是走 AWS Bedrock 便宜？

●项目预算有限，想找个便宜点的模型先跑通，但不知道该选谁？

●跟老板汇报要说清楚模型成本，却发现各家的计价单位都不一样，有的按 1K tokens，有的按 1M tokens，换算起来很麻烦？

就因为这些"痛点"，前段时间，我干脆撸起袖子，做了一个工具来解决这个问题。

于是，Model Price 就这么诞生了。

它的目标很简单：把各大 AI 服务商的模型价格聚合到一起，让你一眼就能看清谁便宜、谁贵、性价比如何。

代码都在这儿了，开诚布公，欢迎随时来坐坐：

●GitHub: https://github.com/xiaobox/model-price

●在线演示: https://modelprice.boxtech.icu

（要是觉得还行，顺手点个 Star，就是对我最大的肯定。）

这把"锤子"，我花了些心思去打磨

我不想只做个"能看"的工具，我希望它能"好用"，甚至让你"爱用"。所以，在几个关键的地方下了功夫。

首先，数据要全

目前 Model Price 覆盖了 6 家主流 AI 服务商，580+ 个模型：

服务商	模型数量	数据来源
AWS Bedrock	96+	公开 API
Azure OpenAI	50+	零售价格 API
OpenAI	53+	官网爬虫
Google Gemini	31+	官网爬虫
OpenRouter	339+	公开 API
xAI (Grok)	12+	官方文档

无论你用的是 GPT-4、Claude 3.5、Gemini Pro 还是 Llama，都能在这里找到对应的价格。

其次，数据要准

最让我头疼的就是价格变动。所以我给 Model Price 做了自动数据获取机制：

●对于有公开 API 的服务商（如 AWS、Azure、OpenRouter），直接调接口拿最新数据

●对于没有 API 的服务商（如 OpenAI、Google），用 Playwright 爬虫自动抓取官网定价

这样一来，数据基本能保持实时更新，你不用再担心看到的是过时信息。

查找要快

580+ 个模型，如果只能翻页查看，那体验也太差了。所以我加了多维度筛选：

●按提供商筛选：只看 OpenAI 的？只看 AWS 的？一键切换

●按模型系列筛选：只看 GPT-4 系列？只看 Claude 系列？

●按能力标签筛选：支持视觉的？支持音频的？支持 Function Call 的？

●按价格排序：从低到高、从高到低

基本上，三秒内就能找到你想要的模型。

最后，看着要舒服

我做了两种视图模式：

●卡片视图：信息展示更直观，适合浏览

●表格视图：数据更紧凑，适合对比

每个模型的价格还有一个小的柱状图，让你一眼就能看出谁贵谁便宜。输入输出价格分开展示，Batch API 价格也有，该有的都有。

技术栈，给爱折腾的朋友参考

Model Price 的技术选型很主流，方便大家二次开发：

后端：

●Python 3.11+

●FastAPI（高性能异步框架）

●Playwright（网页爬虫，用于抓取 OpenAI、Google 官网）

●httpx（异步 HTTP 客户端）

●uv（超快的 Python 包管理器）

前端：

●React 18

●TypeScript 5

●Vite（构建工具）

●CSS Variables（主题系统）

代码结构清晰，Provider 采用插件架构，想要接入新的服务商，只需要实现一个 BaseProvider.fetch() 方法就行。

这只是个开始

想邀请你一起来添砖加瓦

现在 Model Price 已经能用了，但它离"完美"还差得很远。一个人的力量终究有限，一个好的开源项目，生命力在于社区。

所以，我诚心地邀请你，无论你是谁，都可以来参与这件事：

●如果你只是想找个工具查价格：欢迎直接访问 https://modelprice.boxtech.icu 使用。如果能顺手在 GitHub 上点个 Star，我会非常开心。

●如果你经常用某个服务商，发现数据有误：欢迎提 Issue 告诉我，我会尽快修复。

●如果你和我一样，是个爱折腾的开发者：欢迎来读源码，提 PR。比如接入新的服务商、优化爬虫逻辑、改进 UI 交互……都非常欢迎。

●如果你有其他想法：比如想要对比历史价格、想要价格变动提醒、想要导出 Excel……都可以提 Issue，我们一起讨论。

一个优秀的开源项目，就像一场漫长的篝火晚会，需要不断有人添柴，才能一直燃烧下去。

Model Price 就是我点起的第一根火柴。

好了，就说这么多。感谢你耐心听我这个老家伙唠叨。

如果你对 Model Price 有一点点兴趣，就去看看吧。期待在 GitHub 上，看到你的身影。

GitHub 传送门： https://github.com/xiaobox/model-price

硅谷还在堆卡，DeepSeek 却在做题：2025 最后一天，他们用一道数学公式重写了底层

Sat, 03 Jan 2026 03:17:15 +0000

2025 年终于翻篇了。

回看过去这一年，全球 AI 行业简直是在 “神仙打架”。从美国的 OpenAI 到中国的各大厂，大家都在疯狂迭代，没有谁敢在舒适圈里躺平。但在如此窒息的竞争节奏下，DeepSeek 依然是个异类。无论是综合能力极强的 V3，还是推理模型 R1，亦或 Coder 系列，DeepSeek 总能以一种 “不仅强，而且便宜得不可思议” 的姿态出现。

大家都在研究他们的显卡利用率，研究他们的 MoE 路由。然后 2025 年的最后一天，DeepSeek 又默默丢出了一篇名为 mHC 的论文。

看完这篇论文，我才真正理解了 DeepSeek 这个生态为何能爆发得如此之快。这不仅仅是一项技术优化，更是一种敢于挑战权威和规则的勇气。

当大多数团队还在常规的架构上修修补补时，DeepSeek 的研究员们已经把手术刀伸向了模型最基础、也最敏感的 “血管”—— 残差连接。这是一次极高风险的赌博：他们为了追求极致的模型容量，选了一条理论上极不稳定的路，用一道优雅的数学公式，硬生生把这条路给铺平了。

DeepSeek 最可怕的不是某一个具体的模型，而是他们对底层数学原理的掌控力。正是这种能力，支撑起了从 R1 到 V3 这一条条产品线的快速突破。DeepSeek 的护城河，比我们想象的还要深。

即使是 GPT-5，也逃不掉的 “老祖宗之法”

在深度学习领域，网络越深，越需要一条 “直通车”。残差（ResNet）就是那条车道：不一定唯一，但几乎是默认选项。

不管是 GPT-5 还是 Gemini 3，扒开代码，核心逻辑都长这样：

⚡ 代码片段下一层的输入 = 上一层的输出 + 这一层的变化

这叫恒等映射。它像一条笔直的管道，保证信号能安全地流到第 100 层。从何凯明的《Deep Residual Learning for Image Recognition》开始，十年了，哪怕是最激进的架构师，也不敢轻易动这个地方。

但创新的接力赛其实已经开始了。 2024 年 9 月，字节跳动（ByteDance） 的 Seed 团队率先搞出了一个叫 Hyper-Connections (HC) 的理论（https://arxiv.org/abs/2409.19606）。这帮人的脑洞很大：为什么要死守着原封不动？把信号打散、揉碎，多搞几条路混合在一起，模型的脑容量不是更大吗？

不得不说，字节跳动这个想法很有前瞻性，但在当时来看，它更像是个 “半成品”。因为它有个致命缺陷：极其不稳定。对于追求稳妥的大模型团队来说，这种 “理论收益高、实际风险大” 的方案，通常看完论文就扔进收藏夹吃灰了 —— 毕竟谁也不想拿几千万的显卡去赌一个可能会炸的模型。

但 DeepSeek 的工程师思路不太一样。他们看完论文，没盯着风险看，而是死死盯着那个 “收益”。他们觉得，这玩意儿虽然现在会炸，但原理没毛病。只要能想办法给它装个 “刹车”，它就是跑得最快的。于是，他们做了一个非常务实的决定：把这个友商没跑通的架构捡起来，自己动手修好，然后真的用到了自家的大模型上。

但这毕竟是给高速行驶的赛车换引擎，稍微手抖一下就是车毁人亡。DeepSeek 真的稳住了吗？

压力测试

DeepSeek 为了证明自己的方案（mHC）到底稳不稳，他们在 27B 的模型上，用 mHC（灰线）和 HC（蓝线）做了个对比测试：

大家注意看这两条线的走向。

●左图 (a) ：蓝线（HC）的 Loss Gap 在 12000 步之前，它还在 0 附近徘徊；但过了 12000 步，蓝线突然旱地拔葱，直线飙升。

●右图 (b) ：蓝线（HC）的梯度在 12000 步左右突然开始疯狂抖动，全是毛刺。

HC 在训练进行到 12000 步时，梯度范数（Grad Norm）突然开始剧烈震荡。这意味着什么？意味着模型内部的信号传导出问题了，每一次参数更新都在 “乱指路”。这就好比赛车开到 200 码时，方向盘突然开始疯狂抖动，车身剧烈摇摆。结果就是车彻底撞毁了，因为右边的梯度乱了，左边的 Loss 自然就崩了。蓝线（Loss Gap）的瞬间飙升，就是梯度失控的直接后果。模型不仅学不到新东西，反而把之前学到的也吐出来了。这就是典型的 “训练崩溃”。

再看那条灰线，对比简直不要太强烈。无论右边的梯度怎么波动，加了数学约束的 mHC（灰线）始终把梯度按得死死的，平滑得像条直线。因为内部稳住了，外部的表现自然就稳了 —— 所以在左图中，它的 Loss 始终贴着基准线走，完全没有出现暴涨。

DeepSeek 用这组图证明了： HC 的崩溃不是偶然，而是必然（右图的梯度震荡）。而 mHC 成功的原因是数学约束带来的平稳。

3000 倍的隐形 “通胀”

既然灰线（mHC）在结果上已经赢了，那我们必须得搞清楚：蓝线（HC）到底是怎么输的？

DeepSeek 的工程师对模型内部的信号做了一次深度 CT 扫描。他们想看看，信号在网络里传导时，到底是被放大了还是缩小了。

这是一组极具欺骗性的对比。

●左图 (a) 看单层：看起来很正常。每一个单独的层（Single Layer），信号增益都在 1 附近波动，稍微大一点点而已。

●右图 (b) 看叠加：灾难发生了。当几十层叠加在一起（Composite Mapping），那个微小的 “一点点” 被指数级放大，蓝线直接飙到了天际。

这两张图揭示了 HC 架构最隐蔽的致命伤。如果你只看单层（左图），你会觉得 HC 没啥大毛病。它的信号放大倍数也就 1.1、1.2 的样子。很多工程师看到这就放心了：“这不挺稳的嘛？” 但别忘了，大模型动不动就是 60 层起步。真正的恐怖在右图。当信号穿过 60 层网络时，那些看似无害的 1.1 倍被连续相乘。 1.1 的 60 次方=304。如果是 1.2 呢？结果是 56000。

图中蓝线（HC）清晰地记录了这个失控的过程：在深层网络，反向传播的梯度增益（Backward Gradient Gain）最高飙到了 3000 。这是什么概念？ 正常模型的信号增益应该是 1（能量守恒）。但蓝线飙到了 3000。这就好比你在第一层对模型耳语了一句 “你好”，传到第 60 层时，变成了 3000 个广场舞大喇叭同时贴着你耳朵尖叫。

在这种噪音下，梯度瞬间爆炸，前面提到的梯度震荡就是这么来的。这简直是个死局： 想聪明（用宽连接），就会爆炸；想稳定（用老架构），就得忍受平庸。

一道 “小学数学题” 救场

面对这个死局，DeepSeek 的解法简单得很。既然信号会因为连乘而无限放大，那就给它加个 “会计”，强制它遵守能量守恒。

他们引入了一个概念：双随机矩阵（Doubly Stochastic Matrices）。名字很唬人，但本质极简。它其实就是强制模型做 “加权平均” 。

DeepSeek 给那个狂暴的混合矩阵定了一条死规矩： “不管你怎么折腾，你每一行的权重加起来必须等于 1，每一列加起来也必须等于 1。”

这就是数学的魔力：你想想，如果你计算一组数的 “平均值”，结果有可能超过最大值吗？绝对不可能。DeepSeek 证明了：这种矩阵就算乘上一万次，它依然守规矩，永远不会让能量溢出（信号范数 ≤ 1）。

效果立竿见影。看看这组热力图对比，这就是 “无序” 和 “有序” 的区别：

●第一排是失控的 HC 方案，那些深蓝色的色块代表数值极大的异常点（有的飙到了 268.9，有的跌到 -255.2），整个矩阵一片混乱

●第二排是加了 “紧箍咒” 的 mHC 方案，颜色立刻变浅且均匀，所有数值被死死锁在 0 到 1 之间，井井有条。

那个飙到 3000 倍的信号核爆，被瞬间按回了 1.6 倍 。面对 3000 倍的信号核爆，DeepSeek 没有用工程上的 “补丁”（比如强行截断数值），而是从数学底层定义了一个新的流形（Manifold）。这道 “数学题” 的真面目，其实就是著名的 Birkhoff 多面体投影。

生态爆发的秘密

如果你觉得这只是个学术实验，那就太天真了。注意看原文中这句容易被忽略的话：

This conclusion is further corroborated by our in-house large-scale training experiments

“这一结论得到了我们内部大规模训练实验的进一步证实。”

这句话翻译过来就是：虽然这篇论文展示的是 27B 小模型的实验数据，但我们在内部那个庞大的模型矩阵（包括大家熟知的 V3 等）身上，早就验证过这一套了。

这就解释了为什么 DeepSeek 总能比别人 “多算一步”：当行业还在卷应用层时，他们已经在底层的连接方式上，用 6.7% 的额外计算时间，换来了一个容量更大、表达更强、且绝不炸膛的通用架构。正是这种底层技术的溢出，才支撑起了 DeepSeek 从 V3 到 R1 再到 Coder 的全线开花。

另外，离春节不远了，你应该知道我要说什么。哈哈

总结

读完这篇论文，我最大的感受是：DeepSeek 赢的不是显卡数量，而是对数学的直觉。

如果非要用一句话总结这篇论文，我想引用一位网友的神评论：

以前的模型像个被牵着手的乖孩子（ResNet），安全但学不会跑。后来大家撒手让它跑，结果它是撒手没，跑两步就疯了（HC）。

DeepSeek 做的事，就是给孩子画了个圈（双随机矩阵）。不管你在圈里怎么跑、怎么翻跟头都行，但绝对不许出圈。

于是，孩子既学会了跑，又没跑丢。

当硅谷还在比拼谁的 H100 更多时，DeepSeek 用一道数学题证明了： 有时候，约束才是最大的自由。

附录

●DeepSeek 的跨年 “交卷” 之作：https://arxiv.org/pdf/2512.24880

●字节跳动的大胆尝试：https://arxiv.org/abs/2409.19606

●不可动摇的 “老祖宗”：https://arxiv.org/abs/1512.03385

●那道神奇的 “数学题”：Sinkhorn, R. (1964). A Relationship Between Arbitrary Positive Matrices and Doubly Stochastic Matrices.

提示词缓存:让 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 的性格、规则、工具定义）通常很长且固定，缓存后每次调用都极快

逃离旧世界的引力：AI 进化的三个阶梯

Wed, 17 Dec 2025 03:29:11 +0000

有关 “AI Native” 的话题很热，最近看到一个视频，个人感觉很值得一看，我总结了一下内容，建议大家可以先看一下原视频

马车夫的诅咒

如果穿越回 19 世纪末，去问一位马车夫当务之急是什么，他绝不会幻想一台 “内燃机”，他只会祈祷上帝赐予他一匹更快的马。

福特这句被引用烂了的名言，之所以历久弥新，是因为它精准地揭示了一个横亘在所有技术革命面前的诅咒：**“拟物化”**的思维惯性。

人类总是试图用旧世界的容器，去盛装新世界的技术

今天的 AI 浪潮，正深陷在这个陷阱里。残酷的现实是：AI 赋能（AI Enabled）并不是通往未来的必经之路，而是一条铺满鲜花、看似舒适，实则通往平庸的死胡同。真正的变革，绝不是在旧躯壳上修修补补，而是从基因层面进行的暴力重组。

AI Enabled：给马车装上法拉利引擎

目前绝大多数企业，都停留在第一阶段。

这一阶段的底层公式是：旧流程 + AI 插件 = 数字化转型？

这是一种极其危险的错觉。在这种模式下，权力的拓扑结构纹丝不动。人类依然是系统的 CPU（中央处理器），负责所有的逻辑判断、流程串联；而 AI 仅仅是一个外接的 GPU，被要求在某个局部环节加速。这就像给一辆老式木制马车硬塞进了一台 V12 引擎。速度或许能短暂提升，但那副为了马匹设计的脆弱车架，根本无法承受剧烈的推力。在一个 “人是 CPU” 的系统里，强行插入一个超强的 AI，只会让协作变得拥堵。协调成本的激增，将彻底抵消技术带来的红利。这是做加法，不是做乘法。

跨越门槛的三重奏

要从 “赋能” 跃迁到 “原生”，我们需要跨越技术与认知的双重鸿沟。幸运的是，技术界正在发生三场静悄悄的突变：

从 “鹦鹉学舌” 到 “深度思考” (System 2)： AI 正在戒掉单纯的概率拟合，生长出 “思考链”（Chain of Thought）。人不再是流程中必须存在的 “盖章员”，我们只需在关键的例外时刻登场。
从 “坐而论道” 到 “起而行之” (Agent)： AI 终于拿到了键盘和鼠标的控制权。它不再是顾问，而是执行者。人类被迫向两端迁移：在上游制定策略，在下游处理烂摊子。
从 “无状态” 到 “长时记忆” (Memory)：这是资产的根本转移。未来的经验将固化在系统的向量数据库里。人类不再是经验的肉身载体，而是记忆结构的设计师。

AI Native：流程即代码，数据如流水

当上述三次突变完成，商业世界将迎来 “奇点”：AI Native（AI 原生）。

这是一个 “AI 是 CPU，人是协处理器” 的新世界。我们不再是给旧马车加速，而是基于 “第一性原理”，从零开始设计一辆智能汽车。

在这个阶段，组织架构将发生剧烈的 “去骨架化”。数据流和 Agent 像水银泻地般自动流转。检验一家企业是否进入 “原生” 阶段，只需三个灵魂拷问：

生死之问：拔掉 AI，你的业务是 “变慢了”，还是 “不存在了”？（前者是赋能，后者才是原生）。
传球之问：在业务链条里，谁在传球？真正的原生组织不仅让人机协作，更让 AI 与 AI 之间直接 “握手”。
护城河之问：你的系统是在单纯消耗数据，还是在吞噬经验？如果机器不能把人类的痛苦转化为直觉，那它只是在搬砖，没有建立壁垒。

AI Awaken：这里的黎明静悄悄

在 Native 阶段，我们穷尽了效率。但紧接着，我们将被迫直面一个令人战栗的终极问题：如果机器做完了所有的 “How”（怎么做），谁来定义 “What”（做什么）和 “Why”（为什么）？

当 AI 不再满足于在已知的地图里导航，而是闯入 “无人区” 发现新规律；
当 AI 不再满足于回答问题，而是开始质疑问题本身；
当 AI 不再盲目逼近目标函数，而是开始修改那个关乎生死的奖励函数时……

它就不再是一个工具，而是一个拥有意志的新物种。这便是 AI Awaken（AI 觉醒）。

你可能会问：人类为什么会允许事态发展到这一步？答案既简单又冷酷：为了赢。

AI Native 的天花板，依然是人类认知的边界。当所有人都把效率卷到极致时，胜负手就取决于谁能投出那一招突破人类盲区的 “神之一手”。那一刻，并不是 AI 想造反，而是商业竞争的 “囚徒困境” 逼迫我们不得不这样做。

Native 阶段，我们交出了执行权。 Awaken 阶段，我们将交出定义权。

最后的领地

面对这个不可逆的未来，请不要再问 “AI 还能帮我做什么”。你应该问的是：当这个硅基物种比我更勤奋、更聪明、甚至比我更懂 “什么是正确” 时，我存在的必要性到底是什么？或者说，当所有的理性决策都可以被外包，这个世界上究竟还剩下什么东西，是必须由一个会犯错、会衰老、会痛苦、会叹息的碳基生命，亲自来完成的？

这或许，才是人类最后的护城河。