一、AI 概念眼花缭乱的真相
Token、Transformer、注意力、MoE、量化、剪枝、蒸馏、SFT、RLHF、CPT、Embedding、RAG、Function Call、MCP、Prompt、CoT、ReAct、ToT、Plan & Execute & Reflect、工作流、单 Agent、Multi-Agent、长期记忆、短期记忆、数据飞轮……
这是我最近两年看各种 AI 分享 PPT 时，按顺序抄下来的专有名词。随便数一下，就超过二十个。每一个背后都有论文、博客、厂商在吹。
刚接触的人大概率有同一个反应：**”这东西是不是在故意弄一堆新词出来唬人？”**
其实不是。这些名词不是凭空冒出来的，每一个都在解一道具体的工程题。问题是，市面上 90% 的文章只告诉你”这是什么”，不告诉你”它为什么必须存在”。于是你记下了一堆术语，但整张地图始终拼不起来。
这篇文章想给你一套坐标系。把所有 AI 应用开发里的复杂性，压到 5 道工程约束上。你以后再看到任何新概念，都可以先问一句：”它到底在解哪一道？代价是什么？”
二、一张表看穿所有复杂性
先把结论亮出来。Agent 开发里所有让你眼花的设计，本质都在对抗下面这 5 道约束：
理想世界里，你希望大模型是个全能超人——给它无限的 token 窗口，塞全量业务知识进去；它推理快如毫秒；它便宜到随便调；它啥都记得住；它想干啥干得成。
现实世界里，这五个维度每一个都卡你脖子。上下文窗口顶破天十几万 token，业务知识几百万字塞不下；复杂任务一步推不到位，它就开始胡说八道；一次调用等 3 秒、花几分钱，规模化后立刻变吞金兽；多轮会话一结束，它立刻失忆。
所有你头疼过的新概念，本质都是在绕过其中一道或几道枷锁。
讲到这里有个更底层的判断我想先说清楚：Agent 开发的本质，是在”把大模型当超人”和”完全不当超人”之间找平衡。
纯把它当超人，现实的约束立刻打脸。完全不当超人，退回到纯工程，很多复杂、无法穷举的场景你做不出来，也白白浪费了它的通用能力。后面讲的每一个方案，本质都是在这两极之间来回挪。
三、第一道枷锁：Token 窗口装不下世界
这道约束最直接。大模型能”看进眼里”的上下文，总共就十几万 token。一个中等业务的 FAQ 库，随便就上百万字。
于是有了第一组解法：不要一次塞，用到再取。
RAG：用多少取多少
RAG（Retrieval-Augmented Generation，检索增强生成）干的就是这件事。用户问题来了，先到知识库里把相关的那几条捞出来，跟问题一起喂给模型。大模型只处理”今天需要”的那部分，不处理”所有可能有用的”。
这听起来像个简单的搜索拼接，但我得提前打个预防针：RAG 之所以常常被骂”玩具”，不是技术不够，是知识库本身没整理好。这个坑后面专门讲。
Function Call 与 MCP：把”动手能力”外包
光有知识不够，Agent 还得能查实时数据、能下单。这就是 Function Call 做的事——调用大模型时把工具列表一起告诉它，它不会自己去执行，而是返回一个”我想调 X 工具，参数是 Y”的信号，由你的代码去调，调完把结果再塞回去给它继续想。
MCP（Model Context Protocol）是 Anthropic 把 Function Call 协议标准化后的产物。早期每个厂商工具定义格式都不一样，工具名、参数、返回字段改一次，全链路代码就要动一次。第三方工具接入更是每家都得适配一遍，极为麻烦。
MCP 的本质是行业规范层——对大模型而言，MCP 的底层仍然是 Function Call，并不是替代关系，只是帮你把接口长相统一了。这条我要强调一下，因为现在 MCP 被捧得太高，很多人以为它是什么新物种。它不是，它是一个协议壳子。
四、第二道枷锁：能力还不够强
假设你真塞进去了足够的上下文，模型能直接吐出正确答案吗？
复杂任务不行。它会跳步、会把中间推理省略、会因为”一步到位”的直觉反应得出错的结论。
这时你得做一件看起来有点反直觉的事：不让它一次性回答，而是逼它一步步想、边想边查、甚至多条路并行再对比。
这就是 CoT、ReAct、ToT、Plan & Execute & Reflect 这些”思考决策范式”的由来。它们不是模型自带的能力，而是用 Prompt 或流程编排”外挂”出来的。
我用一个具体例子贯穿讲清这四者的区别——假设你要做一个”徒步计划助手”。
直觉反应 vs 四种”慢思考”
BaseLine 就是一句话丢过去：”你是徒步助手，帮我规划。”速度最快，但模型很容易拍脑门。
CoT（Chain of Thought，思维链）是把推理步骤写进 Prompt：”第一步确认日期城市人群，第二步查天气，第三步按人群天气查路线，第四步输出详情。”推理链路被钉死了，效果稳定但不灵活。
ReAct（Reasoning + Acting）把工具调用也拉进循环——Thought（我现在需要什么信息）、Action（调工具）、Observation（看返回），反复三次。它比 CoT 更动态，因为中间每一步可以根据查到的信息调整下一步。
ToT（Tree of Thoughts，思维树）走得更远，一次性先提出几个候选方案（挑战型/中等型/休闲型），分别查资料、对比优缺点、淘汰掉不合适的，最后输出最优解。
Plan & Execute & Reflect 则多了最后一步反思——计划跑完不直接交差，先回头问自己一句”这个方案合理吗？不合理就重做”。
这些范式到底”住”在哪里
这是我个人觉得最容易被误解的点。这些方法不是模型预训练阶段”原生”刻意训练出来的能力。它们诞生于应用侧——工程师们发现单次推理效果不好，就用 Prompt 或流程编排把单次推理拆成多次。
后来模型厂商发现这些方法效果好，反过来在后训练阶段用包含 CoT/ReAct 轨迹的数据微调模型，让它执行这类任务更丝滑。但归根到底，这些方法属于 Prompt 工程或 Agent 流程编排的范畴，不是模型自身的魔法。
理解这一点的好处是：你能分清什么是模型的底子，什么是你能调的开关。
五、第三道枷锁：速度还不够快
解决了”够不够塞”和”想不想清楚”之后，下一个问题是”快不快”。
用户端一次对话等 3 秒就开始焦躁。如果你的 Agent 要 ReAct 循环三次、Multi-Agent 串行调四个模型，延迟会叠到让人想卸载应用。
对抗速度约束的手段分两层——模型侧和应用侧。
模型侧：让大象跑得像猎豹
MoE（Mixture of Experts，混合专家架构）现在火，逻辑很朴素：”分而治之，各展所长”。一个几千亿参数的模型里藏着几十个”子专家”，每次处理输入只激活其中一小撮。你看 DeepSeek V3 动不动参数量上千亿，推理成本却能控制住，就是这个套路。
稀疏注意力机制也是这条路。DeepSeek V3.2 用的就是 Sparse Attention——注意力机制本来是要对所有 token 两两算相关性的，开销是平方级。稀疏化之后，只算相关的、忽略明显无关的，推理又快又省资源。
这一层你管不着，是模型厂商的工作。但它解释了一个现象：为什么同样”参数量大”的两个模型，价格可以差十倍——结构决定账单。
应用侧：推理参数这把”手动挡”
这里有一个被严重低估的调节旋钮：温度 + 采样策略。
用同一个候选集举例：下一个 token 有五个候选——房子(0.5)、建筑(0.3)、屋顶(0.1)、苹果(0.05)、跑(0.02)。
贪婪采样永远选概率最高的，永远吐”房子”。稳定但死板，客服场景适用。
Top-k 取概率前 k 个随机挑。k=3 时你可能抽到”屋顶”。有多样性但也可能抽到烂词——如果前 k 里藏着低概率尾巴词，就会冒出奇怪输出。
Top-p（核采样）按概率从大到小累加到 p 为止再随机。p=0.8 就只剩”房子”和”建筑”可选，自动裁掉了尾巴。这是目前主流做法，既有多样性又控质量。
温度参数控制的不是选谁，而是概率分布本身的陡峭程度。低温把分布压得陡峭，高概率的更高，输出保守；高温把分布抹平，小概率词也有机会被选中，输出发散。
这四个参数看起来不起眼，但在客服类应用（要稳）和内容创作类应用（要有想象力）之间，它们就是开关。我见过很多团队直接用默认值，然后抱怨”大模型总是翻车”或者”大模型总是干巴巴”。先把温度调一调，很多问题当场消失。
六、第四道枷锁：成本不够低
速度和成本基本是连体婴。一次调用 GPU 占用越久、token 吞吐越大，账单就越厚。
减成本有两条完全不同的路。一条是让模型变小，一条是用业务知识”改装”模型。
模型变小：量化、剪枝、蒸馏三件套
量化是最常见的——把参数从 FP32/FP16 的高精度表示，压成 INT8/INT4 的低精度表示。核心技术活是找一个合适的缩放因子，让量化后的数值分布尽可能接近原始分布，不至于精度损失太严重。成本最低，副作用是模型能力会略微下降。
剪枝是把模型里那些”对输出贡献不大”的参数、神经元、注意力头直接剪掉。按权重大小、梯度信息、重要性评分判断”谁不重要”。可以是结构化剪枝（砍整个通道/整层），也可以是非结构化剪枝（砍单个权重）。成本中等，效果比量化猛一些。
蒸馏是最贵也最优雅的一条——用大模型当老师，训小模型当学生。学生不只学老师的”硬标签”（最终答案），还学老师的”软标签”（概率分布）。这种训练方式吸收的知识更丰富，小模型能做出接近大模型的效果。成本最高，因为你要先有一个大模型，还要完整训一遍小模型。
这三件套背后的逻辑都是用一点点质量损失换大幅资源节省。面向 C 端的产品基本都在用，只是用得深浅不同。
“让模型更懂你的业务”：三种玩法账单
另一条路不是让模型变小，是让模型变懂你的业务。有三种玩法，代价差异巨大：
这里我要引用原始分享里最有杀伤力的一句总结：
SFT 拼人力（苦力玩法），对齐拼人力 + 技术（苦力 + 技术玩法），CPT 拼人力 + 算力（苦力 + 土豪玩法）。
一句话把三种技术的实质讲明白了。
SFT（有监督微调）需要几千到几万条高质量问答对，单机多卡一两天就能跑。听起来不贵，难的是数据从哪来。一条标注质量达标的问答对，业务专家花几分钟是常态。几万条就是几个月的人月。这就是”苦力玩法”——技术门槛不高，但体力活逃不掉。
对齐（RLHF 等）要人标偏好排序对（”A 回答比 B 好”），数据量和 SFT 相当，但训练阶段同时涉及演员、参考、评论家、奖励四个模型互相喂数据。吃显存、吃调参经验，没有 RL 功底的团队根本跑不稳。苦力 + 技术的组合拳。
CPT（持续预训练）是真金白银——清洗去重后的海量无标注语料喂进去，多机多卡跑几天到几周。小团队连硬件都配不齐，”土豪玩法”名副其实。
选哪条路，本质上取决于你有什么：有人没钱选 SFT，有人有技术选对齐，有卡有钱不差人选 CPT。大多数业务场景其实都不需要走到这步——先把 RAG 做好，就能省下 80% 的微调开销。
七、第五道枷锁：没有持久记忆
这道约束最短。大模型本身不带跨会话记忆——一次对话结束，它完全不认识你。
解决方案拆成短期和长期。短期记忆就是当前会话的上下文拼接；长期记忆是把关键事实抽取出来、存进外部存储，下次对话再按需加载回来。
你会发现，长期记忆归根结底还是在解第一道枷锁——token 窗口装不下无限历史。所以所有长期记忆方案的核心动作就两个：抽取什么该记、什么时候召回回来用。
这是一个正在快速演化的领域，方案还没定型。但你可以用前面学到的坐标系判断任何新方案：它是为了省 token？还是为了提升个性化？还是为了节约调用成本？看清楚它在解哪道约束，就看清楚它值不值得用。
八、为什么 RAG 是最大的坑：一个项目的血泪账
前面讲了所有约束的解法。但我必须单独讲一下 RAG，因为它是**最容易做、最容易做砸、也最容易被错误归因为”大模型不行”**的那个环节。
“人看不懂的知识，模型也看不懂”
这是我听过最反直觉也最准确的一句话。
很多团队上线 RAG 应用，效果差得一塌糊涂，归因是”模型能力不够”或”向量检索不准”，于是花大价钱换更强的模型、换更贵的 Embedding。结果一点用没有。
真正的问题，往往出在知识库本身就是一坨乱麻。
一条业务规则藏在几份文档里，每份写得都不完整；两个概念边界互相打架；答案只给结论不给推理依据；用词混乱，同一个东西三个叫法。这种知识，让一个刚入职的新人看都看不懂，你凭什么指望大模型看懂？
知识库维护的三条硬规矩
我总结了一下这类项目踩过的坑，浓缩成三条规矩。
第一，知识之间体系要清晰，相关的放一起，不要重复不要交叉。不是为了”看起来整齐”，是因为大模型也会做相似内容匹配——同一个问题的答案散落在五个地方，检索召回时多半取不全，或者把矛盾的几条都拉回来把模型搞晕。
第二，用语要清晰、无歧义、有结构。标点、编号、先说什么后说什么，都影响模型理解。一句话反复用代词指代前面的东西，人看着要回头想两遍，模型也会错。
第三，把原始知识告诉模型，不只告诉最终结果。这是很多知识运营最难接受的一条。他们习惯了写 FAQ——问题 A 答案是 X。但大模型会推理，你给它原始规则，它能推出 A、B、C、D 很多个问题的答案；你只给它 A 的结果，用户一旦问到 A’，它就歇菜。用户的问法是无穷无尽的，FAQ 式知识永远穷举不完。
一个客服项目的 5 人 1 月 12 万字
我参与过的一个跨境 AI 客服项目，把这些教训刻得非常深。
第一版上线测评：效果差到完全不具备上线条件。团队第一反应是调 Prompt、换检索策略，忙了小半个月，收效甚微。
一个月后第二版：经过几轮知识优化和测评，指标略有好转，但离上线标准还差一大截。大家开始怀疑是不是模型选错了。
真正的转折点：团队停下来，组了 5 个人，花 1 个多月，按知识维护规范逐字重构了整整 12 万字的知识库。重构后第一次测评——直接达到上线条件。对外公开指标的风险率 3.69%，内部实测收敛到 1% 以内。剩下那 2% 多的”风险”里，很大一部分其实是模型在答案里吐露了中文思考过程，属于格式问题不是内容问题，处理一下就消失了。
这个项目顺利上线后，后续其他地区市场的上线也少走了很多弯路。
这个案例让我重新理解”AI 应用”
讲这个案例不是为了吹这个团队多厉害。是想说一件更朴素的事：真正让 AI 应用能用的，不是更炫的模型、更复杂的 Agent 编排、更新的 MCP 协议，而是 5 个人死磕一个月的知识整理。
硬核的 AI 工作，表面上看是调 Prompt、接 MCP、编排 Multi-Agent，底下其实是极其传统的两件事——把业务知识梳理清楚，把系统的每个环节数据打穿。前者是 RAG 的上限，后者是数据飞轮的起点。
背景知识 = 上下文工程的另一个名字
还有一条经验顺便说一下：引入”背景知识”概念，跟具体知识点关联在一起。同一份背景知识可以关联多条具体知识。当某条具体知识被召回时，把它挂的背景也一起送给模型。
这件事做了很久之后才发现——“原来这个叫做上下文工程（Context Engineering）”。
名字后来才有，但做法早就在一线团队里跑了。这也印证我前面的判断：你看到的每个新名词，背后基本都是一个早就被踩过的坑。
九、后记：把这套坐标系焊进脑子里
文章写到这，Token、Transformer、注意力、MoE、量化、剪枝、蒸馏、SFT、RLHF、CPT、Embedding、RAG、Function Call、MCP、Prompt、CoT、ReAct、ToT、Plan & Execute & Reflect、工作流、单 Agent、Multi-Agent、长期记忆、短期记忆——开头那份让你头大的名单，现在应该不那么晕了。
它们全部挂在 5 根钉子上：装不下（token）、想不清（能力）、跑不快（速度）、花得贵（成本）、记不住（记忆）。
以后你再看到一个新概念——不管它是 LongRAG 还是 GraphRAG、Agentic RAG，不管它是某某 Agent 框架还是某某多模态方案——先问自己三个问题：
第一，它在解 5 道约束里的哪一道？ 定位清楚了再看细节。
第二，代价是什么？ 没有免费的饭，加了一个方案就是在另一个维度付费。RAG 省了 token 但加了检索延迟；MoE 省了算力但加了训练复杂度；量化省了显存但牺牲了精度。
第三，我真的需要它吗？ 这个问题最残忍。很多团队不是死在技术不够上，是死在每个新概念都想试一遍。把最朴素的那道约束解掉（通常是知识库没整好），80% 的问题会自己消失。
最后借用一位同行在内部分享里的话，改了几个字：
Agent 开发是系统性工程（框架设计要平衡、流程编排要合理），也是细活儿（逐字优化 Prompt、逐环节优化效果）。
其实所有工作都这样。
AI 没有什么魔法。魔法都在那 5 道枷锁底下、每一次挣扎着突破一点点的工程细活儿里。
延伸阅读：
- Anthropic MCP 协议文档 —— 理解 Function Call 标准化的来龙去脉
- DeepSeek V3 技术报告 —— 看看 MoE 和稀疏注意力在工业界的最佳实践
- 任何一本讲 RLHF 的书 —— 看完你会明白对齐为什么是”苦力 + 技术”的组合拳