我刷到一张对比图，标题叫「AI 这十年」。画面是三个逐渐长高的人形剪影：2016 是个婴儿，身上写着 AlphaGo、ImageNet、CNN、RNN、Yolo、GAN、ResNet、Transformer、Bert；2022 是个背书包的小学生，身上写着 ChatGPT、Claude、Prompts；2026 是个高出一头的成年人，身上密密麻麻列了 22 个词，从 Orchestration 一路排到 Cost Optimization，最后跟一行 And More。
图想说的是「AI 长大了」。但我数完那 22 个词之后的感觉正相反：长高的不是那个人，是他身上挂的装备。
名词速查
图上那 22 个词跨了好几个子领域，先把本文会用到的摊平。这一节的作用是让你不用中途去搜。
| 术语 | 一句话解释 |
|---|---|
| 上下文窗口（context window） | 一次调用最多能塞进去多少 token，超了就报错或被截断 |
| token | 模型的计费和计算单位，一段文字被切成的碎片数；不是一个汉字一个 token（见BPE 那篇） |
| 无状态（stateless） | 一次推理结束后，模型权重不保留这次对话的任何痕迹，下次从零开始 |
| RAG / 检索 | 提问前先从外部库里捞几段相关内容拼进 prompt，而不是把整个库都塞进去 |
| MCP | 一套让模型调用外部工具/数据源的协议约定（史上最大改版那篇） |
| Fine-tuning / 蒸馏 / 合成数据 | 三种真的会改动模型权重的做法：继续训练、用大模型教小模型、造训练数据 |
| Guardrails | 在模型外面加的输入输出检查，拦掉不该过的内容 |
| AI Gateway | 挡在应用和模型之间的代理层，管路由、限流、密钥、计费 |
我数了一遍：22 个词，19 个在模型外面
分类判据只有一条，好让你能自己复核：要落地这一项，主要工作是不是改动模型权重？ 是，算「模型里」；不是，算「模型外」。
| 那一栏的词 | 在模型里？ | 主要由哪个约束生出 |
|---|---|---|
| Fine-tuning | ✅ 是 | — |
| Distillation | ✅ 是 | — |
| Synthetic Data | ✅ 是 | — |
| Stateless Systems | ❌ 外 | 约束本身 |
| Memory Architecture | ❌ 外 | 无状态 |
| MCP & Protocols | ❌ 外 | 无状态 |
| Loop Automation | ❌ 外 | 无状态 |
| Agentic AI | ❌ 外 | 无状态 |
| Function Calling | ❌ 外 | 无状态 |
| Advanced Tooling | ❌ 外 | 无状态 |
| Orchestration | ❌ 外 | 无状态 + 窗口有限 |
| RAG 2.0 | ❌ 外 | 窗口有限 |
| Vector Databases | ❌ 外 | 窗口有限 |
| Knowledge Graphs | ❌ 外 | 窗口有限 |
| Context Understanding | ❌ 外 | 窗口有限 |
| Multi-Agent Collaboration | ❌ 外 | 窗口有限 |
| Prompt Optimization | ❌ 外 | 窗口有限 + 按量计费 |
| Cost Optimization | ❌ 外 | 按量计费 |
| AI Gateways | ❌ 外 | 按量计费 |
| Evaluation Frameworks | ❌ 外 | 输出不确定 |
| Guardrails | ❌ 外 | 输出不确定 |
| Observability | ❌ 外 | 输出不确定 |
3 项在模型里，19 项在模型外。
这个分类里最该被质疑的是 Function Calling——「会发出结构化工具调用」这个能力确实训在权重里。我把它归到模型外，判据是图上这一项在工程上要你做的事：定义 schema、执行、把结果回填进下一轮。那部分一行权重都不碰。这是我的判断，不是客观事实，你完全可以把它挪到左边，结论变成 18 比 4，不影响量级。
一句话根本约束
那 19 个词之所以长成这样，是因为四个约束同时成立：
- 无状态：一次推理结束，权重不带走任何东西。
- 窗口有限：一次调用能塞进去的 token 有硬上限。
- 按量计费：每个 token 都要付钱、付延迟。
- 输出不确定：同样的输入不保证同样的输出，因为它是采样出来的。
这句话是可反驳的——反驳方式就是取消其中一条，看设计会不会塌：
- 取消「无状态」（模型自己记得上次聊了什么）→ Memory Architecture、MCP、Loop Automation、Stateless Systems 这一串失去存在理由。
- 取消「窗口有限」（无限上下文，且注意力不衰减）→ RAG 2.0、Vector Databases、Knowledge Graphs、Multi-Agent 的主要动机消失。注意得同时取消衰减，否则位置带来的干预力差异还在。
- 取消「按量计费」→ AI Gateways、Cost Optimization、半个 Prompt Optimization 直接归零。
- 取消「输出不确定」→ Evaluation Frameworks、Guardrails、Observability 缩水成普通单元测试。
四条全取消，2026 那一栏剩下 3 个词：Fine-tuning、Distillation、Synthetic Data。这一栏不是能力清单，是约束清单的镜像。
崩点：用我自己的博客仓库算一笔账
「窗口有限」听起来像个远方的技术参数。我拿手边最小的一个语料实测了一下，它崩得比我预期早得多。
最朴素的做法是这样的：不要检索、不要向量库、不要记忆架构，每次提问就把全部资料塞进 prompt——模型足够聪明，让它自己找。这个仓库存着我写的全部博客，就试它。
# 在仓库根目录
cat src/content/blog/*.md | wc -c # 6286900
ls src/content/blog/*.md | wc -l # 337337 篇、6,286,900 字节，6.29 MB。一个 U 盘塞得下几百份。再按字符类型拆一下：
python3 -c "
import glob, re
t = ''.join(open(f, encoding='utf-8').read() for f in glob.glob('src/content/blog/*.md'))
cjk = len(re.findall(r'[\u4e00-\u9fff]', t))
print('total chars', len(t)); print('cjk', cjk); print('non-cjk', len(t) - cjk)"
# total chars 3425442
# cjk 1261786
# non-cjk 2163656上面三个数是我在写这篇时跑出来的真实输出。下面的 token 数是估算，不是实测——这台机器上没有 tokenizer 库，也没有可用的 API 凭证，跑不了 count_tokens。所以我给三档，让你看到区间而不是一个假装精确的数字：
| 估法 | 中文 | 非中文 | 得到 token |
|---|---|---|---|
| 最宽松（下界） | 2 字 / token | 4 字符 / token | 1.17M |
| 常见经验值 | 1 字 / token | 4 字符 / token | 1.80M |
| 偏保守 | 1 字 / 1.5 token | 3.5 字符 / token | 2.51M |
关键在下界那一行。2 个汉字挤成 1 个 token 是没有哪个主流 tokenizer 真能做到的乐观值，可它算出来仍是 1.17M——已经装不进 1M 的上下文窗口。 也就是说，无论我怎么调估算系数，结论都不变：一个个人博客的全部存量，塞不进当前最大的窗口。崩点就在第一个数量级上，不需要等到公司知识库那种规模。
再算钱。按 Claude Opus 5 的输入价 $5.00 / MTok（模型价目见文末来源）：
| 做法 | 每次输入 token | 每次成本 | 100 次 / 天 |
|---|---|---|---|
| 全塞（常见估法 1.80M） | 1.80M | $9.01 | $901 |
| 全塞（下界 1.17M） | 1.17M | $5.86 | $586 |
| 先检索 5 篇 | ~26.7K | $0.13 | $13 |
单篇平均 10,165 字符，约 5.3K token；捞 5 篇约 26.7K token。同一个问题，全塞比检索贵 67 倍，而且前者根本跑不起来。
于是「RAG 2.0」「Vector Databases」这两个词的性质就变了：它们不是 2026 年流行的技术选型，是这道除法算出来的结果。你可以不喜欢向量库，可以换成 grep（Claude Code 和 Codex 就是这么干的），但你不能不做检索——除数摆在那里。
想自己复核这笔账
三条命令，五分钟，换成你自己的仓库：上面两条 wc 拿到字节和文件数，第三条 Python 拿到中文/非中文字符数，然后套表里的系数乘一遍。要记录的数字就一个：下界估法算出来的 token 数，是不是已经超过你在用的那个窗口。 我这里是 1.17 倍。如果你手上是一个中型代码库，大概率是几十倍。
一个诚实的补台：上面的中文正则 [\u4e00-\u9fff] 只覆盖基本汉字区，标点、假名、扩展区都被算进了「非中文」那一栏。这会让中文占比略微低估，因此三档估算整体偏低——不改变「超窗口」的结论，但你复核时会发现自己的数比我这个算法给的更大一点。真要精确，走 tokenizer；BPE 那篇里我用 Qwen 的分词器实测过，一个汉字往往不止一个 token。
图上最矛盾的一对词，其实是一件事
2026 那栏里 Stateless Systems 和 Memory Architecture 并排列着。当成两项能力读，这是自相矛盾的：一个说系统不存状态，一个说要设计记忆。
它们不是并列的两项，是同一个约束的因和果。因为一次推理结束状态就消失，所以记忆必须搬到模型外面，变成文件、数据库、索引。图把因和果都画进了「能力清单」，于是读起来像是这个人同时长出了两种本领——实际上他是长出了一条假腿，和一根拐杖。
这条线不是 2026 年才有的。MCP 那次最大改版做的就是这件事：状态不会消失，只会搬家。往前追，它是 REST、是 fate-sharing、是「功能应该放在两端而不是通信系统里」。
我在这条约束上翻的车：记忆架构的真实失败模式
写这篇之前，我先跑了一条检查：
# 比对仓库内的规范目录与用户配置目录下的同名副本
diff -r <repo-skill-dir> <user-config-skill-dir> && echo "in sync"输出 in sync。这条检查存在的唯一原因，是这两个目录曾经静默分叉过——同一份写作规范在这个仓库里存了一份（有 git 历史，是真相源），在用户配置目录下存了一份（是真正被加载执行的那份）。它们不是符号链接，是磁盘上两个独立文件。
后果很具体：被加载的那份落后了 130 行，缺了两条新增的反模式规则。于是照着它写出来的稿子，原样复现了新规则专门要防的那个毛病。这条教训后来被写进规范并入库：
5811e11 skills: add three publish gates and merge the forked writing guidecommit 标题里那个 merge the forked writing guide，就是账。
我从这件事上学到的，和图上「Memory Architecture」给人的印象完全不同。记忆架构的难点从来不是「存哪里」，是「谁是单一真相源」。 加一个向量库很容易，加第二份副本更容易；难的是保证读的那一份就是新的那一份。分布式系统里这叫一致性，多 Agent 的内存问题其实就是这个老问题换了张脸。
图上那个词只有两个单词的宽度，装不下这件事。
「Guardrails」落地长什么样：一条只拦两个前缀的正则
顺着这条线看另一个词。Guardrails 在图上是一个盾牌图标，听着像一套体系。在这个仓库里，它的实现是 scripts/validate-blog-content.mjs:22 的一条正则：
{
kind: 'unix-home-path',
pattern: /(?<![\w:/.-])\/(?:Users|home)\/[A-Za-z0-9._-]+(?:\/[^\s'"<>)]+)*/g,
}作用是拦住文章里泄漏的本地机器路径。我读完这行的第一反应是：它只认 /Users 和 /home 两个前缀。/tmp/xxx.py、/var/log/...、/private/... 一律放行——而临时实验脚本恰好最常落在 /tmp。
这不是这条正则写得差，是护栏的普遍形态：护栏是有名字的规则的集合，它只挡住你已经想到的那些形状。 所以规范里现在多了一条人工自查（「正文里所有绝对路径都问一次：这个路径在别人机器上存在吗」）——护栏漏掉的部分，成本转移到了流程上。
图上那 22 个词，每一个展开都是这个质感：一个漂亮的名词，底下是一条不完整的正则、一个凑合的索引、一张手动维护的表。
这张图哪里是对的
到这里该接住一个反问：你是不是在挑一张科普图的刺？
它的时间点和分层都对。2016 那一栏确实全是模型和架构的名字——CNN、ResNet、Transformer，那是模型自己在长。2022 那一栏是两个产品加一种交互方式，也准确：那一年的变化是能力被包装成了产品。图真正准确的地方是它无意间画出了重心迁移：从架构，到产品，到脚手架。
我不同意的只有一件事：把第三栏那 22 个词读成「他长高了」。那 19 个挂件不是身高，是负重。它们全都在补同一件事——模型本身一次推理就失忆，连自己刚才叫什么都记不住。
顺着这个角度重看，那张图甚至更值得看：2026 那个人形之所以画得比前两个高出一头，不是因为脑子大了，是因为身上挂满了东西，轮廓被撑开了。
常见误读 → 实际情况
这篇要修的就是看图之后最容易带走的那几个印象：
| 看图容易读成 | 实际情况 |
|---|---|
| 2026 栏那么多词 = 模型能力大爆发 | 22 个里 19 个不改模型权重，是模型外的脚手架 |
| 这些是「新技术趋势」，会被下一波趋势替换 | 它们是四个约束的产物；约束不变，换掉一个只会长出功能等价的另一个 |
| Stateless Systems 和 Memory Architecture 是两种能力 | 是一个约束的因和果：状态一定消失，所以记忆必须外挂 |
| RAG / 向量库是一种技术选型偏好 | 是一道除法的结果。我这个 337 篇的博客最宽松也要 1.17M token，装不进 1M 窗口 |
| Guardrails / Evaluation 是成熟度标志 | 是「输出不确定」逼出来的补丁，落地常常就是一条只认两个前缀的正则 |
| 越往右越先进，2016 那些过时了 | 2016 栏是模型本体，2026 栏是外挂；后者依赖前者，不是取代前者 |
通俗总结
把它想成给一个每天早上醒来就忘光一切、但脑子极好、按分钟收费、而且一次只看得进一页纸的天才助手打配套设施。
他忘光了，你就给他建档案柜（记忆架构、知识图谱）；他一次只看得进一页，你就得先替他挑出该看的那几页（检索、向量库）；他按分钟收费，你就得算账、限流、走代理（成本优化、网关）；他偶尔胡说，你就得抽检、加复核、装监控（评测、护栏、可观测）。
那张图上 2026 那个人身上密密麻麻的 22 个词，19 个就是这些配套设施。能一句话讲给同事的版本是：那不是他长高了，是你给他背上了包。 而这也解释了图上唯一真正的成长方向——如果哪一天他睡醒还记得昨天的事、一次能读完整本书，你搭的那 19 样东西里大部分会当场失业。
所以下次刷到这类「AI 进化史」的对比图，那种一边点赞一边觉得哪里不对的感觉是有来由的：图在讲模型的成长，而你每天在做的，是给一个记不住昨天的东西补记忆、补检索、补账本。
参考来源
工程实践
- 本站相关：MCP 史上最大改版的本质：状态不会消失，只会搬家
- 本站相关：Claude Code 和 Codex 还在用 RAG 吗？——代码检索为什么回到了 grep
- 本站相关：别把向量数据库当知识库：RAG、Agent 记忆和知识库的一条主线
- 本站相关：BPE 不是一个汉字一个 Token：从 Qwen tokenizer 实验看懂 token 计费
- 本站相关：KV cache 是内存管理，上下文管理是 GC 吗？——把 LLM 推理栈当操作系统读一遍
- 本站相关：遗忘是一种能力：五篇论文看懂长程 Agent 的记忆管理，正在重演操作系统内存史
- 本站相关：多 Agent 的内存问题，其实是分布式系统的老问题换了张脸
- 本站相关：上下文不是平的：位置与结构如何决定一条信息对输出的干预力
- 本站相关：Agent 的内存管理：Claude Code 与 Codex 如何决定「忘掉什么」
- 本站相关：Agent 记忆的前沿玩法：从存聊天记录，到主动寻找可用证据
- 模型价目与上下文窗口：Anthropic 定价页（本文用的 Opus 5 输入价 $5.00 / MTok、1M 窗口来自我手边一份 2026-06-24 缓存的价目表，写作时未逐项回查官网，价格可能已变动）
- 字节数、字符数、
diff -r结果、commit5811e11、scripts/validate-blog-content.mjs:22的正则：均为我在本仓库实测/查证
图片来源
- 一张标题为「AI 这十年」的对比图文，我在短视频平台刷到，原作者与原始链接未记录。图上文字内容以本文导语所述为准（我按截图逐字抄录），三栏词条即分类表的输入。