基础概念

1. 模型的参数

参数是什么？

大模型就像一个超级复杂的“公式 + 神经网络大脑”。
里面有无数个可以调整的“小旋钮”，每个旋钮的数值就是一个“参数”。
每个参数都是一个数字（通常是 16 或 32 位浮点数），它们本身是没有任何含义的。
“70B 参数模型” = 有 700 亿个这样的数字参与计算。

这些参数本质上就是“模型记住的东西”和“模型如何变换信息的方式”。

参数是怎么来的？

参数是训练出来的，不是人为写的，训练的时候只知道输入和输出，通过训练后得到参数。

一开始参数是随机的 → 模型啥都不会。
通过“预测下一个词/下一个 token”这个任务，不断修正参数。
训练规模越大、数据越丰富，模型越“聪明”。
我们常说模型开源，开源的就是训练后的参数，训练过程一般是不开源的。

2. Token

Token 也叫词元，是模型眼中“最小的语义单位”，是模型处理文本的基本粒度。不是严格意义的“字”或“词”，而是由 tokenizer 定义的一种切分方式。
- “Hello” → 可能是一个 token；“incredible” → 可能被拆成 "in", "cred", "ible" 三个 token；
- 有的模型：一字一 token：“你”“好”“吗”；有的模型会把常用词合并，例如“人工智能”可能是 1~2 个 token。
Tokenizer：把文本切分成 token，再将 token 映射成 id，方便在后续的处理时，把 id 再映射成向量。因为模型只能处理数字，所以需要先将文本转换成数字。
Token 的类型：
- prompt_tokens：输入的 token
- completion_tokens：输出的 token
- total_tokens：总 token
- context：上下文，包含了输入和输出和历史对话
- KV 缓存：是模型内部的机制（自回归生成时的优化技术），作用于单次对话的生成阶段。
  - 比如：在对话里输入 1000 个 token，LLM 需要对这 1000 个 token 一次性建模，计算注意力，产生很多 KV，这些 KV 会被缓存，生成第一个 token 时，LLM 只需要对新生成的 token 做计算，再利用上一轮缓存的结果进行重新的计算即可，无需重新重头计算对话里的 1001 个 token。
- 提示词缓存：是推理服务层面的优化，不属于 LLM 的内部机制，缓存的是输入 prompt 的处理结果，作用于跨请求的优化，取决于 API 提供方的实现。
  - 比如：第一次对话输入 800(system_prompt) + 200(user_prompt) token，LLM 回答 100 (assistant_prompt) token，第二次对话输入 800(system_prompt) + 200(user_prompt) + 100 (assistant_prompt) token + 50 (user_prompt) token ，此时会缓存 800 + 200 个 token
Prompt 的类型：
- system_prompt：系统提示词，通常只会有一个，不是必需的，但有助于设定 assistant 的整体行为，帮助模型了解用户的需求，并根据这些需求提供相应的响应
- user_prompt：用户提示词，用户输入的内容
- assistant_prompt：LLM 回答的提示词，可以携带工具的调用信息

3. 词嵌入 Embedding

Embedding 是什么

将文本转换为一组坐标，也称向量，本质上是一个一维数组，维度表示数组的长度，维度越大，对事物的描述越具体，计算也会越耗时。

为什么需要 Embedding

因为计算机擅长做“向量间距离/相似度”的运算，但不擅长直接理解“自然语言”的语义。通过将两个事物（如文本）转换成向量，计算他们的距离，从而判断他们是否语义相似

区分 LLM 里的 Embedding 和 RAG 里的 Embedding

大模型对话的场景里，用户输入的文字，经过 token 拆分，再将 token 映射成 id，因为 id 本身没有含义，无法进行计算，需要再将 id 映射成向量（这一步也是 Embedding），从而理解用户输入，作为后续模型的推理使用。
- 这一步跟用户无关，是 LLM 的行为，属于模型内部的机制。
RAG 场景里，RAG 本身是一套机制，作为 LLM 外挂的知识库进行补充，本身跟 LLM 没有任何关系，是一种独立的方案，只是 RAG 会使用 Embedding 这种能力，将用户的输入转换为向量，在向量数据库里进行语义搜索，搜索出相关的资料贴到上下文里，帮助 LLM 进行更好的回答。
- RAG 本质上只是一种搜索的能力，跟使用关键字搜索是等价的，都是搜索不同的实现方式，主要是解决关键字搜索没有语义相关性的问题。
- RAG 是可以使用跟对话模型不同的模型进行 Embedding，处理外挂的知识库的。

4. 处理流程

对话时，大模型是逐个 token 地生成答案的：

用户输入先被 tokenizer 切成 token，并根据词表映射为 token id 序列。
这些 id 通过模型内部的 embedding矩阵 层变成向量序列，输入到 Transformer 神经网络里计算。
模型根据当前所有上下文，在词表的所有 token 上算出一个概率分布，然后挑出一个作为“下一个 token id”。
把这个新 id 加到上下文里，再重新喂给模型，继续算下一个 token。
如此循环，直到生成结束。
最后把所有生成的 token id 再映射回具体的 token，并拼成自然语言文本，就是我们看到的最终答案。

5. MoE 机制（Mixture of Experts，混合专家）

传统大模型里，每次生成答案都是所有参数一起参运算，参数越大，算力和成本也会跟着变高，甚至无法承受
有了 MoE 机制后，模型内部会分为多个“专家子网络” + 一个“调度员”，调度员会先根据用户的问题进行分类判断，然后把这个问题分配给少数几个最擅长的专家，每次只激活其中的一部分参数，使得计算成本变低
因为每次只用少数专家，你可以放心地堆更多专家（也就是总参数更多），这样模型的“总体知识容量”更大，能覆盖更多领域，但单次推理算力依然可控。
不同专家可以在训练中，慢慢学会擅长不同类型的数据/任务，比如有的更擅长数学推理、有的更擅长代码、有的更擅长日常对话或文学写作
MoE 解决的是“如何把模型做得更大、更强但算力还扛得住”的问题

6. 蒸馏

可以简单分为数据蒸馏和模型蒸馏
数据蒸馏：因为原始数据可能又多又杂，因此可以先用模型或人对原始数据进行筛选、改写、打更细致的标，浓缩成更精炼、更有效的训练集，或者是通过模型生成大量“带解释、带推理过程”的样本，生成更多小而精的数据集
模型蒸馏：如果只用大模型，效果虽然很好，但是部署成本高、推理慢、很难在手机、iot 设备上普及，如果直接训练一个小模型，虽然训练简单、部署便宜，但性能通常明显不如大模型，也很难达到大模型的水平，而模型蒸馏，就是用大模型对数据进行蒸馏，生成更多带有 CoT 题解的数据集用于小模型的训练，从而得到一个更小、更快、计算和部署成本低，但性能尽量接近大模型的小模型
模型蒸馏解决的是“如何把这种强能力复制到更小、更便宜的模型里”

7. 模型耗时

参数大小对质量和速度的影响

质量方面：
- 大参数模型：
  - 语言表达更自然，风格更多样；
  - 更善于理解复杂指令、隐含意图；
  - 推理能力更好（数学、逻辑、代码、规划等）。
- 小参数模型：
  - 能力更有限；
  - 适合做简单任务（分类、打标签、简单聊天、补全）。
速度 & 成本方面：
- 参数多 → 每次计算要遍历更多数字 → 每个 token 生成更慢 → 一次调用更贵。
- 参数少 → 计算轻 → 更快更便宜 → 更适合部署在本地或高并发业务。

同样输入 1k token，输出 200 token：

7B 模型：0.2s 出 first token，2s 输出完毕
70B 模型：0.8s 出 first token，6s 输出完毕（但答案明显更聪明）

**输入上下文的长度（输入 token 数）：**越长，内部计算越多 → 首 token 时间变长。

输出长度（需要生成多少 token）：每生成 1 个 token 都要跑一遍模型 → 输出越多，总时间越长。提示词的复杂程度不会影响LLM 的输出耗时，但是复杂的提示词可能会导致输出长度变长，从而影响耗时。

硬件配置：如 GPU 性能、并行度、云厂商还是私有化、网络延时等。

First Token Latency：从请求发出，到 LLM 开始返回第一个 token 的时间，包含请求到达服务器、排队、LLM输出；影响 first token 的因素：输入的长度（上下文 + 当前问题）、模型大小、服务器负载和网络延时

Total Latency：从请求发出，到最后一个 token 输出完的总时间。包含 first token 时间 + 后续每个 token 的平均生成时间 x 输出的 token 数

应用层概念

目前 AI 应用都是基于 LLM chat API + 提示词工程 + 上下文工程 + 各种策略来实现，下面会介绍在 AI 应用里涉及到的相关技术。

1. CoT

Chain-of-Thought 思维链：让 LLM 把它中间思考的步骤展示出来的方式。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


  问题：
  一个班有 30 个学生，其中 18 个是女生，男生有多少个？
  不用 CoT（直接给答案）：
  答案：12 人
  ---
  用 CoT：
  班级总人数是 30 人。
  女生有 18 人。
  男生人数 = 总人数 - 女生人数 = 30 - 18 = 12。
  所以男生有 12 人。
  ---
  这中间的“先算什么、再算什么”的步骤就是 Chain of Thought。

只要模型在回答过程中显式写出了中间推理过程（哪怕是你在 prompt 里说“请分步骤说明推理过程”），就可以说是在做 CoT，方式：

Reasoning API，侧重推理，如 deepseek r1 在回答的时候，会先展示一段引用，引用里是思考过程，展示完思考过程后，才会输出答案，这种方式会让 LLM 内部生成更长更细致的思考，再基于这些内部思考，生成答案对用户展示，比较强制，思考和推理的能力更强，但同时也更慢。

Reasoning API 只是帮你更稳定、高效地利用这种“思考过程”的一个产品形态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


  {
    "id": "resp_0217****",
    "created_at": 1756280722.0,
    "error": null,
    "incomplete_details": null,
    "instructions": null,
    "model": "doubao-seed-1-6-250615",
    "object": "response",
    "output": [
      {
        "id": "rs_0217****404a",
        "summary": [
          {
            "text": "\n用户说“你好呀。”，这是一个很友好的问候，我需要用同样友好的方式回应。首先，应该回应用户的问候，然后可以表达一下愿意帮助的态度，让对话能够继续下去。用户可能接下来会有其他问题或者想聊聊天，所以回应要自然、亲切。\n\n首先，直接回“你好呀！”来呼应对方的问候，保持一致的语气。然后加上一句“很高兴见到你～ 有什么我可以帮你的吗？”这样既表达了友好，又主动提供帮助，让用户知道我在这里可以协助他们。这样的回应比较温暖，也符合日常交流的习惯，不会显得太生硬。\n\n需要注意的是，用户可能只是想打个招呼，所以回应不要太复杂，保持简洁和亲切就好。避免使用太正式的语言，保持口语化，让用户感觉舒适。总结一下，回应应该包含问候、表达高兴见到对方，以及提供帮助的意愿。",
            "type": "summary_text"
          }
        ],
        "type": "reasoning",
        "status": "completed"
      },
      {
        "id": "msg_0217****a93c",
        "content": [
          {
            "text": "你好呀！很高兴见到你～ 有什么我可以帮你的吗？ 😊",
            "type": "output_text",
            "annotations": null
          }
        ],
        "role": "assistant",
        "status": "completed",
        "type": "message"
      }
    ],
    "max_output_tokens": 32768,
    "service_tier": "default",
    "status": "completed",
    "usage": {
      "input_tokens": 88,
      "input_tokens_details": {
        "cached_tokens": 0
      },
      "output_tokens": 230,
      "output_tokens_details": {
        "reasoning_tokens": 211
      },
      "total_tokens": 318
    },
    "caching": {
      "type": "disabled"
    },
    "store": true,
    "expire_at": 1756539922
  }

Chat API，侧重思考，普通的对话 API 也支持开启深度思考能力，部分模型支持，在输出答案的同时也会输出思考的内容，分开两个字段承载，与 Reasoning API 相比，速度会更快，但质量一般比不上

应用层在展示时，把 reasoning 的内容展示出来，也是一种 CoT

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


{
   "choices": [
     {
       "finish_reason": "stop",
       "index": 0,
       "logprobs": null,
       "message": {
         "reasoning": "思考的内容",
         "content": "最终的答案",
         "role": "assistant"
       }
     }
   ],
   "created": 1742631811,
   "id": "0217426318107460cfa43dc3f3683b1de1c09624ff49085a456ac",
   "model": "doubao-1-5-pro-32k-250115",
   "object": "chat.completion",
   "usage": {
     ...
   }
 }

通过提示词 + Chat API，比如 Agent 常用的 ReAct 策略，强制要求 LLM 以 Thought、Action、Observation 等结构进行输出，Thought 本质上就是思考的过程，输出时，内容都是耦合在 LLM 的回答里的，通过一个字段承载。
应用层在展示时，解析出 Thought 的内容，并把它展示出来，也是一种 CoT，但输出结果不一定稳定，比如直接输出内容，没有以 Thought 开头。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


   {
     "choices": [
       {
         "finish_reason": "stop",
         "index": 0,
         "logprobs": null,
         "message": {
           "content": "Thought: 思考的内容。Action: 调用什么工具",
           "role": "assistant"
         }
       }
     ],
     "created": 1742631811,
     "id": "0217426318107460cfa43dc3f3683b1de1c09624ff49085a456ac",
     "model": "doubao-1-5-pro-32k-250115",
     "object": "chat.completion",
     "usage": {
       ...
     }
   }

2. Function calling

因为 LLM 只能输出一大段文字，输出并不稳定，但是调用工具时需要结构化的输入，为了让 LLM 能更好的格式化生成输入参数，由此诞生了 Function calling 功能。
Function calling 是一种机制，本质是让 LLM “按规范输出一段结构化信息”，这样外部程序就能据此去调用函数/接口，再把结果喂回模型。
现在的 LLM Chat API 都支持 Function calling 功能，可以将工具方法以 Json-Schema 格式描述，作为接口参数进行传递，以这种方式调用 LLM chat api，方法描述通常不会完整计入“上下文 token”中，但仍然会有一定的计算开销，只是计费/长度处理上和普通上下文不同。

3. RAG

向量数据库与RAG初识

RAG（Retrieval-Augmented Generation）（检索增强生成）：可以理解为一种工具或方式，给大模型外挂一个搜索/知识库，再让模型根据搜到的内容来回答问题，让模型接入最新、特定领域、甚至私有的知识库，限制模型尽量“根据检索结果说话”，减少胡编。
RAG 流程主要分为两部分：
- 检索（Retrieval）：到外部知识库里“查资料”，比如文档、网页、公司内部文档。
- 生成（Generation）：把“查到的资料 + 用户的问题”一起喂给大模型，让模型基于这些资料组织答案。
解决的问题：
- 知识过期：模型训练数据有时间截止，最新政策、产品更新都不知道。
- 不了解私有数据：公司内部文档、个人笔记不在训练集里，模型天然不知道。
- 容易胡编（幻觉）：不知道的东西也照样一本正经编出来。
- 专业度不够：在法律、医疗、金融等垂直领域知识不全或不准确。
与其他概念的关系：
- 当调用 LLM chat api 时，想让 LLM 参考更加精准的资料，就可以使用 RAG 工具；
- 当 Agent 完成某些工作时，需要外部知识库的内容，就可以使用 RAG 工具；
- 在 MCP 框架里，可以把 RAG 工具封装成 MCP 方法，供 LLM 自行调用

4. MCP

Architecture overview - Model Context Protocol

**MCP （Model Context Protocol）模型上下文协议）**是一个标准化协议，规定模型如何安全、通用地访问外部的资源和工具，可以理解为面向对象里的接口和实现，大家在提供各种不同工具时都遵循这套接口，就可以有百花齐放的工具市场，丰富 LLM 的能力；
在没有 MCP 之前，想要使用 LLM chat api 并调用工具，虽然可以直接用 api 里支持的 tool 参数实现，但是这样有个问题，需要在调用 api 的逻辑里耦合工具调用的处理逻辑，比如解析 chat api 返回的内容，进行工具调用，这样在不同的应用里都需要重新接入；
有了 MCP 之后，MCP 规定了 client（工具调用方，通常与 LLM chat api 集成）和 server 的规范（工具提供方，执行工具返回结果），任何应用只要遵循了这套规范，都可以接入调用。
- 比如现在有指标数据查询的 API，将其用 MCP 包一层后，不过是 A 组的聊天机器人，还是 B 组的 Agent 应用，只要支持 MCP 协议，都可以在配置后调用这些工具，无需重复造轮子。

与其他概念的关系：

与 function call （tool call）的区别，function call 本身是 LLM Chat Api 提供的一种能力，通过对工具方法按 Json-Schema 转换成 json 后，作为参数传递，当 LLM 判断出需要调用工具时，会在响应体里一个特定的字段返回：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


请求体：
{
    "model": "DeepSeek-V3.1",
    "stream": false,
    "messages": [
        {
            "role": "user",
            "content": "今天的天气怎么样"
        }
    ],
    "tools": [
        {
            "type": "function",
            "function": {
                "name": "query_date",
                "description": "查询今天的日期",
                "parameters": {
                    "additionalProperties": false,
                    "type": "object",
                    "description": "查询今天的日期"
                }
            }
        }
    ]
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


响应体：
{
    "id": "22b4db60f0d34e08a55f2e3d229aa879",
    "created": 1768908785,
    "model": "ms-dwnrrcdx",
    "object": "chat.completion",
    "choices": [
        {
            "finish_reason": "tool_calls",
            "index": 0,
            "message": {
                "content": "我需要先查询今天的日期",
                "role": "assistant",
                "tool_calls": [
                    {
                        "index": -1,
                        "function": {
                            "arguments": "",
                            "name": "query_date"
                        },
                        "id": "call_0a313188b3374df585f51e34",
                        "type": "function"
                    }
                ]
            },
            "provider_specific_fields": {
                "matched_stop": null
            }
        }
    ],
    "usage": {
        "completion_tokens": 336,
        "prompt_tokens": 3976,
        "total_tokens": 4312,
        "prompt_tokens_details": {
            "cached_tokens": 2
        }
    },
    "metadata": {
        "weight_version": "default"
    }
}

MCP Client 也可以将 MCP Server 提供的工具 schema 转换成 function call 的形式调用 LLM，这取决于 MCP client 的实现方式
RAG 是怎么用知识库增强模型回答的能力
MCP 是一种 AI 应用使用工具的规范，RAG 可以是其中之一
Agent 是决策大脑，是一种执行流程，Agent 通过决策后调用满足 MCP 规范的工具

5. Workflow

Workflow（工作流）：一个复杂任务拆成一系列有顺序、有条件的步骤，然后自动执行的那条“流程链条”。常见于各种工作流引擎，在 AI 应用里诸如 coze、dify、n8n 等平台，支持用户拖拉拽组件来实现一整套自动化流程。
在 AI 应用里，可以通过这类平台，或者以自己手搓代码的形式，将一个次次都要重复的人类流程进行统一编排（哪一步该用哪个模型，哪个工具）让业务流程可视化、可配置化、可维护，按照特定的输入执行流程完成输出。
比如现在有一个“智能客服工单处理”的 workflow，它的流程是：
- 收到用户问题（输入）；
- 分类：是投诉、咨询还是报修（调用分类模型）；
- 如果是问业务规则 → 走 RAG 去知识库查；
- 如果是需要改订单 → 走“调用订单系统 API”的分支；
- 生成答复草稿 → 人工审核或自动发送；
- 写入日志和工单系统。
- 这整条就是一个 Workflow，里面可以嵌 RAG、普通 LLM 调用、外部 API 调用等等
与其他概念的关系：
- Workflow 像“流程图 + 状态机”，步骤比较固定
- Agent 则是有决策能力，能自己决定下一步怎么干的智能体
- RAG、MCP、Function calling 是 workflow 流程中的一个步骤

6. Agent

Agent（智能体）：一个“围绕某个目标，能自主规划步骤、调用工具、记忆上下文、与环境交互”的智能实体，它不是一个固定的流程，而是具备一定的决策能力。
Agent 让 LLM 具备完成某项任务的能力，而不是只能进行对话，当然，它本身也是调用 LLM chat api，只是引入了更加复杂的流程和提示词，从而驱动 LLM 自主实现任务目标。它通常具备几种关键能力：
- 理解任务：从指令中抽象出目标；
- 规划步骤：决定先做什么，再做什么；
- 调用工具：包括 RAG、API、数据库、脚本等；
- 与环境交互：读写文件、发请求等；
- 记忆和反思：根据历史结果调整策略。
实现 Agent 常见的策略：

策略	核心思想	流程	优点	缺点/风险	典型场景
纯 function call 追加 prompt 列表	直接让模型在对话中选工具并调用，基本不显式“想步骤”	给模型一串工具定义，放在系统 prompt 或 api tools 字段里没有显式的“计划”步骤，也没有显式的“思考段落”，就是用户说话 → 模型要么直接回答，要么返回一个 tool_call → 工具执行 → 再继续聊 → 直到没有工具执行，返回结果	实现简单、成本低、延迟短	容易瞎调用、缺乏长期规划、多步任务易乱。很难知道它“为什么这么调工具”，排查问题比较痛苦	简单助手、单步调用、工具数量少、调用模式很线性的场景
ReAct	“先想想，再行动”：交替 Reasoning + Acting	ReAct 的基本范式：Thought: 先在自然语言里写出“思考”（我现在应该干嘛、要查什么）Action: 再显式写出要调用哪个工具、用什么参数Observation: 记录工具返回结果然后循环：Thought → Action → Observation → Thought …	每一步都有“先想再做”，能维持一个清晰的推理链。Thought 可以直接展示给开发者或审计系统，看得出它的决策路径出错时可以分析是“想错了”还是“调工具错了”。	Token 消耗多、成本高；输出容易啰嗦，导致输出耗时长；需要精心提示词需要解析/约定 Thought / Action / Observation 的格式，做一个 loop 控制	多工具、多步推理、作为“多工具 Agent”的基础策略，适合中高复杂度任务
Plan-and-Execute	先整体规划步骤（Plan），再逐步执行（Execute）	把任务拆成两大阶段：Plan（规划）阶段：模型根据用户目标，生成一个结构化的“任务计划”，比如：步骤 1：调用工具 A 拉数据；步骤 2：调用工具 B 清洗数据；步骤 3：调用工具 C 画图；步骤 4：调用 LLM 写报告。Execute（执行）阶段：“执行器”按照这个计划一步步调用工具、处理结果；必要时再回头让模型调整计划。	结构化强，流程清晰，适合长流程，可以可视化、审核、拆解给子 Agent 或 Workflow计划可以先让人看一眼：OK 再执行，或者部分步骤需要人工确认。Plan 可以直接转换为一个 Workflow 或 DAG（有向无环图）去跑	实现复杂，需要设计“计划的结构化格式”，有一个执行器来解释计划。Plan 容易过时/不够细，先规划再执行，过程中环境变了、某个工具失败了，需要调整，缺少反思机制容易僵化多轮协调成本高	长流程任务、工作流型、有审计需求，需要“计划记录”和“执行轨迹”的企业场景、需要把 Agent 决策输出给其他系统/工作流引擎复用的场景，一般的 AI Coding 就是使用这种策略。
Self-Reflect	多轮尝试、反思、搜索更优方案	通过多个不同的上下文 + 不同模型（或同一模型）来实现对自己的结果进行“复盘和改进”：上下文 1 + 模型 1 生成初稿上下文 2 + 模型 2 对步骤 1 产生的初稿进行反思，并按照一定的格式输出上下文 1 + 模型 1 根据步骤 2 产生的反思进行修改重复以上步骤直至得出结论	质量明显好于“一次性输出”，通过第二遍自查 + 修正，效果通常有肉眼可见提升。能弥补推理 /规划策略的一些遗漏可以通过“反思提示词”让模型重点关注	成本很高、实现复杂、多一轮审稿调用、多一轮改稿调用，多轮迭代后，成本是线性甚至接近倍数增长；“反思”质量也受模型能力限制可能引入“过度修改”或风格漂移	复杂决策、代码修复、规划、文案/报告/文档类任务、需要高可靠性的 reasoning 输出

与其他概念的关系：
- Agent 为完成任务，会在某个步骤调用 RAG 来查知识
- MCP 给 Agent 提供统一的“工具接口”，Agent 决策“以什么顺序用哪些工具”
- Workflow 更像固定流程，Agent 是根据情况动态规划流程（当然，也可以在 Agent 内部使用固定 workflow 作为子流程）。
- Agent Skills 可以理解为是 Agent 身上的“技能插件包”。

7. Skills

Skills 本质上也是一种规范，一种模块化的能力，教 Agent 如何完整处理特定工作，它将执行方法、工具调用方式以及相关知识材料，按照 SOP 流程，封装为一个完整的「能力扩展包」，本身需要 Agent 进行驱动。
Agent Skills 通常包含下面四个东西，Agent 使用该 skill 时，无需提前将这坨东西加载到上下文里，通过动态加载（渐进式披露）不同的 Skill 包（通常仅需名字和描述），来具备不同的专业知识、工具使用能力，稳定完成特定任务。因此 skill 非常适合将某一项任务执行流程 sop 进行成 skill，从而实现复用。

主要实现复用和模块化，一个 skill 多个 Agent 都能用，skill 可独立升级，降低复杂度，更便于编排和优化。**但目前只有少数 AI 应用支持，比如 Claude Code、Coze 等，**当然，我们也可以自己手搓
- 比如现在有一种数据分析的 Skill，它能查询数据，并转换成图片，主 Agent 不需要知道查询数据、转换图片是怎么实现的，只需要知道它能进行数据分析，当它需要进行数据分析时，只需要加载对应的 skill，按照指引，就能进行数据分析。
与其他概念的关系：
- MCP 和工具调用(function calling)，更偏向于“底层能力”（比如 HTTP 请求），而 Skill 更像“面向业务的封装好的能力模块”（例如“生成周报”）。
  - MCP 是一种开放标准的协议，关注的是 AI 如何以统一方式调用外部的工具、数据和服务，本身不定义任务逻辑或执行流程，工具调用 function calling 同理。
- Agent 是“会思考会规划的主体”；Skills 是“它可调用的能力库”。
- 一个 Skill 内部可能：走一个 Workflow（多个步骤）、通过 MCP 调用后台系统、在其中一步使用 RAG 去查知识库；
- 关于Agent / Sub-Agent / Skill 的区别，可以用“公司组织架构”来比喻：
  - - Agent（主 Agent）：
      - 像一个“项目经理/主负责人”。
      - 负责：
        
        理解用户目标、
        
        拆解任务、
        
        协调资源（工具、技能、子 Agent）。
      - 安排哪个 Sub-Agent 上；
      - 在什么时机用哪个 Skill；
      - 统一管理“用户视角下的这场对话”。
  - - Sub-Agent（子 Agent）：
      - 像不同部门的“小负责人”，各自专长不同：
        
        法务 Agent、数据分析 Agent、运营 Agent 等。
      - 他们通常是：
        
        有自己的系统 prompt（角色/目标）；
        
        有自己的工具和技能配置；
        
        由主 Agent 调用/协同。
      - 是“能自己跑一段流程”的小 Agent，有自己的目标和工具；
      - 一般有自己的对话记忆，和主 Agent 只共享必要的信息；
      - 是否让它看到全局上下文，是一个设计选择，而不是能力限制：
  - - Skill（技能）：
      - 像“某部门的具体能力模块/职能”：
        
        “翻译文档”“写 SQL 报表”“总结长文”“生成周报”等。
      - 更偏“函数/模块”的概念：
        
        相对无状态；
        
        输入→输出明确；
        
        不自己负责高层决策，而是被 Agent 调用。
      - 本身不主动“跑起来”，需要主 Agent 决定什么时候调用；
      - Skill 不直接“拥有”完整上下文，是主 Agent 把当前需要的信息打包给它；
      - 调用结束后，主 Agent 决定要不要把结果写进全局记忆。
关于 Agent / Sub-Agent / Skill 在应用层面：
- Agent（主 Agent）：
  - 主 Agent = 全局导演 + 记忆管理员
  - 维护“全局会话记忆”（用户目标、主要事件、阶段结果）是“唯一看见所有东西”的角色。；
  - 安排哪个 Sub-Agent 上；
  - 在什么时机用哪个 Skill；
  - 统一管理“用户视角下的这场对话”。
- Sub-Agent（子 Agent）：
  - 是“能自己跑一段流程”的小 Agent，有自己的目标和工具（有自己的 system prompt / role / tools / skills）；
  - 一般有自己的对话记忆，和主 Agent 只共享必要的信息；
  - 是否让它看到全局上下文，是一个设计选择，而不是能力限制：
  - 由主 Agent 决定：
    - 初始给它什么信息；
    - 从它的输出中保存哪些要写入全局记忆。
- Skill（技能）：
  - 无状态函数 / 小工具
  - 不维护长期上下文；
  - 每次调用只依赖，参数 + 显式传入的必要背景；
  - 本身不主动“跑起来”，需要主 Agent 决定什么时候调用；
  - Skill 不直接“拥有”完整上下文，是主 Agent 把当前需要的信息打包给它；
  - 调用结束后，主 Agent 决定要不要把结果写进全局记忆。

全景图

技术调研

读 kimi 的 cli 源码，看到里面有两个机制，也分享一下

上下文压缩 - 被动上下文管理

核心目的

上下文压缩是自动优化机制，当上下文接近模型上限时，使用 LLM 将历史消息压缩为精简摘要，保留最近的关键消息，释放上下文窗口空间

触发流程

上下文长度检查

当前 token 数 + 保留空间 >= 模型最大上下文
默认保留空间：50,000 tokens（默认保留最近 2 条消息，确保当前对话连续性）

在 Agent 循环的每步开始前检查

在创建 checkpoint 之前
在执行下一步之前

需要有效的 LLM 实例

LLM 必须已初始化
用于执行压缩任务（使用 LLM 理解上下文并生成结构化摘要，压缩结果按优先级组织）

典型使用场景

场景 1: 长时间对话导致上下文接近上限

1
2
3


情况：Agent 与用户进行了多轮对话，上下文 token 数接近模型上限
操作：系统自动触发压缩，保留最近 2 条消息，压缩更早的历史
效果：将历史对话压缩为结构化摘要，释放大量上下文空间

示例流程：

用户与 Agent 进行了 50 轮对话
上下文 token 数达到 180,000（上限 200,000，保留 50,000）
系统检测到：token_count + reserved >= max_context_size
自动触发压缩流程
保留最近 2 条消息（用户问题和 Agent 回答）
将前 48 轮对话压缩为结构化摘要
压缩后的上下文：2 条完整消息 + 1 条压缩摘要（约 10,000 tokens）

场景 2: 大量代码和文件操作后需要继续对话

1
2
3


情况：Agent 读取了多个大文件、进行了大量代码修改，上下文已满
操作：自动压缩，保留当前任务状态，压缩历史操作细节
效果：保留关键信息（错误、解决方案、最终代码），删除中间过程

示例流程：

Agent 读取了 10 个文件（每个 1000 行）
进行了 20 次代码修改和调试
上下文接近上限
系统触发压缩
压缩提示词指导 LLM：

保留：当前任务状态、错误和解决方案、最终代码版本
删除：中间调试过程、冗余解释

压缩结果：结构化摘要（当前焦点、环境、已完成任务、代码状态等）

场景 3: 多步骤任务执行过程中上下文溢出

1
2
3


情况：复杂任务需要多步骤执行，每步都产生大量上下文
操作：在关键步骤前自动压缩，确保有足够空间继续执行
效果：保留任务进度和关键决策，压缩执行细节

示例流程：

任务：重构大型项目（需要 100+ 步骤）
执行到第 30 步时，上下文接近上限
系统在 Step 31 开始前自动压缩
保留：最近 2 条消息（当前步骤）
压缩：前 28 步的执行历史
压缩摘要包含：已完成的重构任务、遇到的错误、设计决策、当前代码状态
Agent 继续执行，有足够上下文空间

D-Mail（消息回溯）- 主动上下文管理

核心目的

D-Mail 用于主动管理上下文窗口，当 Agent 发现上下文中有大量不相关信息时，可以回滚到之前的 checkpoint，并用一条精简消息替换中间的多条消息。

触发流程

Agent 主动调用 SendDMail 工具

需要 Agent 判断上下文中有冗余信息
需要 Agent 识别到合适的 checkpoint

工具执行成功

工具未被用户拒绝
Checkpoint ID 有效

当前 Step 完成

所有工具调用完成
上下文已更新

典型使用场景

场景 1: 读取大文件后发现内容不相关

1
2
3
4


情况：Agent 读取了一个很大的文件，但发现大部分内容与当前任务无关
操作：发送 D-Mail 到读取文件之前的 checkpoint
内容：只告诉"过去的自己"文件中与任务相关的关键信息
效果：删除文件读取的完整内容，只保留有用信息

示例流程：

Checkpoint 0: 用户要求"分析项目结构"
Agent 读取 large_file.py（5000行代码）
Agent 发现只有 50 行相关
Agent 调用 SendDMail，回滚到 Checkpoint 0
D-Mail 消息：“我读取了 large_file.py，只有第 100-150 行与任务相关：…”

场景 2: 网络搜索结果过大

1
2
3
4
5
6


情况 A：搜索到了需要的信息，但结果很长
操作：发送 D-Mail 到搜索之前的 checkpoint
内容：只保留搜索结果中的关键信息
情况 B：搜索没有找到需要的信息
操作：发送 D-Mail 到搜索之前的 checkpoint
内容：告诉"过去的自己"尝试不同的搜索查询

示例流程（情况 A）：

Checkpoint 1: 用户要求"查找 Python 异步编程最佳实践"
Agent 调用 SearchWeb，返回 20 条结果
Agent 分析后找到 3 条相关
Agent 发送 D-Mail 回滚到 Checkpoint 1
D-Mail 消息：“我搜索了网络，以下是 3 条相关的最佳实践：…”

场景 3: 代码调试过程冗长且不相关

1
2
3
4
5


情况：写了一段代码，但有问题，经过很多步骤才修复
      这些调试过程对最终目标不重要
操作：发送 D-Mail 到写代码之前的 checkpoint
内容：告诉"过去的自己"最终的正确代码版本，并说明已经写入文件系统
效果：删除所有调试步骤，只保留最终结果

示例流程：

Checkpoint 2: 用户要求"实现一个排序函数"
Agent 编写代码（Step 1-5）
代码有 bug，Agent 调试（Step 6-20）
最终修复成功（Step 21）
Agent 发送 D-Mail 回滚到 Checkpoint 2
D-Mail 消息：“我已经实现了排序函数并写入文件，最终版本如下：…（代码）。不需要再写一遍了。”

AI基础概念整理

记录常见的AI基础概念以及一些工程方案

基础概念

1. 模型的参数

2. Token

3. 词嵌入 Embedding

4. 处理流程

5. MoE 机制（Mixture of Experts，混合专家）

6. 蒸馏

7. 模型耗时

应用层概念

1. CoT

2. Function calling

3. RAG

4. MCP

5. Workflow

6. Agent

7. Skills

全景图

技术调研

上下文压缩 - 被动上下文管理

核心目的

触发流程

典型使用场景

场景 1: 长时间对话导致上下文接近上限

场景 2: 大量代码和文件操作后需要继续对话

场景 3: 多步骤任务执行过程中上下文溢出

D-Mail（消息回溯）- 主动上下文管理

核心目的

触发流程

典型使用场景

场景 1: 读取大文件后发现内容不相关

场景 2: 网络搜索结果过大

场景 3: 代码调试过程冗长且不相关