人工智能（AI）知识串讲

约 174 字小于 1 分钟

2026-02-28

本篇博客已经整理成系列文章：

一台机器能够解读数据，并有可能从数据中学习，并利用这些知识来适应环境并实现特定目标，那么我们就称其拥有 人工智能（AI，artificial intelligence）。

AI 可以分为两派：符号主义（Symbolic） 和 联结主义（Connectionism）。

符号AI

符号AI 将现实世界的物体表示为符号，然后用逻辑来寻找解决方案。

iPhone 的 Siri 就属于这一类，Siri 维护着一个庞大的符号知识库，所以当我们问她问题时，她会识别名词和动词，将名词转换成符号，将动词转换成关系，然后在知识库中查找它们。

像这种通过知识库和推理实现的AI系统被称为 专家系统（expert systems）。

神经网络

然而，现实世界是模糊且不确定的，人类的直觉几乎不可能用符号和命题逻辑来编程，于是有了联结主义，或者说， 神经网络（Neural Network）。

神经网络模拟了人的大脑，由相互连接的神经元（节点）组成，这些神经元包括输入层、隐藏层和输出层，连结成网。

机器学习

通过不同的方式对人工智能大脑进行训练的过程，称为 机器学习（Machine Learning）。

我们要么给计算机输入大量先验知识，然后让计算机用判断对错的方式来认识世界，这种训练方式称为 监督学习（Supervised Learning），要么给计算机输入大量同类型的事物，让它自己找到规律，总结归类，这种训练方式称为 无监督学习（Unsupervised Learning），又或者，我们可以让计算机去完成一项挑战（下棋、游戏等），当它在无数次试错之后终于达到某个里程碑，此时记下方法，给予正向奖励，并让它寻找更好的方法，从而不断加强，这种训练方式称为 强化学习（Reinforcement Learning）。

机器学习造就了利用 协同过滤（Collaborative Filtering） 进行商品推荐的早期推荐系统，以及金融风控、垃圾邮件过滤等初级AI应用。

深度学习

计算机在神经网络中学习时，是通过一层又一层的神经元进行的，当层级足够深，并且能够自动进行特征提取，不再依赖人工设计的特征工程时，我们就称为 深度学习（Deep Learning）。

虽然神经网络和深度学习的概念在上个世纪早已提出，但它在数学上充满了大量的矩阵计算，非常消耗算力，那个年代互联网上也没有太多知识（数据）可以用来训练，所以在 2010 年代之前，并没有引起广泛关注。

ImageNet 和 AlexNet

2009 年，李飞飞教授公开了一个庞大的公共图片数据集 ImageNet，并在 2010 年举办了 “ImageNet 大规模视觉识别挑战赛”，前两年都是传统的“支持向量机（SVM）”算法获胜，直到 2012 年，多伦多大学的 Geoff Hinton 教授带领他的学生 Alex Krizhevsky 和 Ilya Sutskever 将神经网络应用于 ImageNet ，并取名为 AlexNet ，以 85% 的准确率斩获冠军。

AlexNet 证明了大规模数据 + 强大的 GPU 算力 + 深度神经网络这一组合的无穷威力，从此打开了人工智能新时代的序幕。

为了表彰 Geoff Hinton 在机器学习与人工智能上做出的基础发明及创新，2024年，他被授予诺贝尔物理学奖。

CNN 和 RNN

AlexNet 底层使用的是 卷积神经网络（CNN），CNN 使用卷积层来高效提取局部特征，特别适合图像和视频处理。

而在 自然语言处理（NLP） 方面， 循环神经网络（RNN） 开始崭露头角，RNN 会逐个读取单词（Token），并且维护一个隐藏状态来记忆之前看过的信息，因此适合处理序列（文字）数据。

RNN 虽然很好，但有两个致命缺陷：一个是无法并行计算，训练速度很慢，另一个是存在长距离依赖问题（遗忘），当句子变长时，AI容易“记了后面忘了前面”。

Transformer

2015 年前后，为了解决 RNN 的遗忘问题，研究人员在机器翻译任务中引入了 注意力机制（Attention），其核心思想是，在翻译当前词时，不要只看 RNN 最后一步压缩出来的状态，而是直接回头去看输入序列中的所有词。算是解决了长距离依赖问题。

2017 年，Google 机器翻译团队在训练庞大的翻译模型时，受够了 RNN 缓慢的训练速度。他们想，既然 Attention 这么好用，我们能不能把 RNN 彻底扔掉，只用 Attention ？

于是，著名的论文《Attention Is All You Need》诞生了。

不要循环（Recurrence），不要卷积（Convolution），注意力（Attention）就是你所需要的一切。

这篇论文提出的 Transformer 架构，有几个特点：

自注意力机制：句子中的每一个词都会和句子中的所有其他词直接进行交互，从而获得全局上下文；
并行化：整个句子的所有词可以同时输入到网络中，进行大规模并行的矩阵乘法运算；
位置编码：记住句子中词语的位置信息，从而感知到词的先后顺序；
多头注意力：让模型从不同的视角去理解句子（如一个头关注语法，一个头关注指代关系）

由于 Transformer 架构支持并行，研究人员终于可以利用海量的数据和庞大的算力去训练拥有数十亿、数百亿甚至上万亿参数的模型。这些拥有超大量参数的模型，称为 大语言模型（Large language models，LLM），简称大模型。

下一节：二、从大模型到Agent智能体

大语言模型（LLM）

由于 Transformer 架构支持并行，研究人员终于可以利用海量的数据和庞大的算力去训练拥有数十亿、数百亿甚至上万亿参数的语言模型。这些拥有超大量参数的语言模型，称为 大语言模型（Large language models，LLM），简称大模型。

语言模型的本质，就是一个概率机器，它只会玩“词语接龙”游戏：根据前面的词，预测下一个最有可能出现的词。例如，当我们输入“今天天气真”，它会预测下一个词最可能是“好”。

2018 年，OpenAI 基于 Transformer 搞出了 GPT-1（Generative Pre-trained Transformer），Google 则搞出了 BERT。可以说是 ChatGPT 和 Gemini 的前身。

闭源模型

2022 年底，OpenAI 的 AI 聊天机器人 ChatGPT 横空出世，彻底引爆了 AI 浪潮。

早在 2019 年，OpenAI 就接受了微软超过百亿美元的投资，ChatGPT 的出世让微软迅速将 GPT 能力整合进全线产品（Copilot），试图在 Bing 搜索和 Office 领域颠覆传统的交互模式；Google 经过一段时间的资源整合，也推出了 Gemini 系列模型；由 OpenAI 前核心成员创立的 Anthropic 推出的 Claude 系列模型在逻辑推理、代码生成和安全性上成为 GPT 极其强劲的对手。

无论是 GPT、Gemini 还是 Claude ，都属于闭源模型，我们只能在官方网站或APP中使用，或者调用官方提供的 API 。这些模型我们称为闭源模型。

开源模型

有一些公司为了抢占市场或提高知名度，选择把大模型的权重公开开放，也就是开源模型。例如：

2023 年 Meta 开源了 LLaMA 模型；
2024 年底，深度求索开源了 DeepSeek-V3 模型，一个月后的2025年春节前夕，又开源了 DeepSeek-R1 模型，火爆出圈，推动了国内 AI 的浪潮；
2025 年阿里开源了 Qwen 3.5 模型；
2026 年 Google 开源了 Gemma 4 模型，DeepSeek 发布了 V4 系列模型。

大模型架构：MoE & Dense

无论开源模型还是闭源模型，他们的底层设计都可以分为两类架构：

以早期 OpenAI GPT 2、GPT 3 和当前流行的 Google Gemma 模型为代表的 稠密架构（Dense）
以 DeepSeek-R1/V3、Google Gemini 为代表的 混合专家模型架构（Mixture-of-Experts, MoE）

在稠密架构（Dense）中，每当模型处理一个输入 Token 时，神经网络中的每一个参数都会被激活并参与计算，计算量大但训练简单。而混合专家架构（MoE）将模型的部分网络层拆分成多个独立的“专家”（Experts），推理时只有部分“专家”被激活，计算量低但训练成本很高。

虽然 MoE 推理时不需要所有专家的算力，但所有专家的参数都必须常驻在显存中，因此 MoE 模型对 GPU 的显存容量要求极高。这就是为什么现在的端侧模型（部署在手机、树莓派、车机的模型）首选 Dense 架构的主要原因。

下载开源模型

开源模型的好处是我们可以把大模型下载到本地部署，企业可以在内网部署大模型，进行 AI 落地的探索。这些模型通常会发布在 huggingface 网站上，这个网站可以说是 AI 界的 Github 了。

参数量

以 DeepSeek 为例，我们在 huggingface 下载 DeepSeek-R1 模型时会看到 14B、32B、671B，指的是不同参数版本，参数越高，表示越强大，当然成本也越高。这里的 B 指的是 Billion（10亿），R1 最高配置 671B 也就是 6710 亿参数，也就是我们说的满血版，而其他的是蒸馏版。

在本地部署的 DeepSeek-R1 大模型，满血版跑起来需要超过 400GB 的显存，一般人可跑不起，而 14B 需要 9GB 显存，4060Ti 16G 的显卡勉强能跑。

因为训练和运行大模型需要用到大量的 GPU 资源，NVIDIA 公司股票自 2023 年开始大涨，成了最大的受益者。

量化版本

到社区下载时，一般我们选择 GGUF 后缀的文件，GGUF（GPT-Generated Unified Format）是目前本地 AI 社区最流行的一种模型文件格式。

之后我们会看到 Q4_K_M 等字样，这指的是模型的量化版本。量化就是用更少的比特来表示权重（可以类比为把高清图片转存为压缩后的 JPG ），从而减小模型大小和显存占用，但会牺牲一点精度。Q4_K_M 中的 Q4 意味着将每个参数从 16 位压缩到 4 位，K 表示 K-Quants ，一种量化方案， M 表示 Medium ，中等量化强度。Q4_K_M 是一种比较好的量化方式，在精度和大小之间取得了很好的平衡。

所以，当我们到社区下载一个模型，名称为 Gemma-4-26B-MoE-Q4_K_M.gguf ，我们就可以知道，这是 Google 的 Gemma-4 模型，是一个 260 亿参数的、采用 MoE 架构的、量化到 4 位的、中等量化强度的模型。

蒸馏

刚刚在介绍参数量时，提到 DeepSeek 除了671B版本之外，其他的都叫蒸馏版本，那什么是蒸馏呢？

蒸馏就是让一个庞大、笨重但极其聪明的大模型，去教导一个轻量、快速的小模型，让小模型在保持较低计算成本的同时，尽可能逼近大模型的性能。蒸馏可以是将闭源大模型输出的高质量回答作为训练材料，也可以是在训练过程中让小模型去逼近开源大模型的中间层特征。

蒸馏技术让边缘计算与移动端部署成为可能，小参数模型可以离线部署在手机、车机、IoT 设备上。

运行本地大模型

我们借助 Ollama 这样的开源工具应用，在本地运行和部署大语言模型，Ollama 安装简单但交互简陋。而 LM Studio 是另一个界面友好型的运行本地大模型的应用。

无论是本地部署也好，服务商提供的 API 也好，我们都可以借助客户端工具去连接模型。ChatBox 和 Cherry Studio 就是这样的工具，他们提供了友好的界面。

2026年，Ollama 和 LM Studio 都已经有了自带的图形界面，ChatBox 和 Cherry Studio 不再是必须

模型参数

无论是本地部署还是调用 API，调用模型时都可以调节一些参数，来微调模型的效果。本地部署的通常可以在 LM Studio 的模型设置中调节，调用 API 的情况可以写入到请求的 JSON 中。

注意，这些参数不是必传的，如果不传，模型会使用默认值。大模型API是无状态、无记忆的，这意味着如果你想用一个非默认参数值，每次请求 API 时都要带上它。

{
  "model": "your-model-name-here",
  "messages": [
    {
      "role": "system",
      "content": "你是一个资深的研究员。"
    },
    {
      "role": "user",
      "content": "请介绍一下人工智能的发展历程。"
    }
  ],
  "temperature": 0.7,   
  "top_p": 0.9,         
  "top_k": 40,  
  "max_tokens": 1024, 
  "presence_penalty": 0.1, 
  "frequency_penalty": 0.1, 
  "repetition_penalty": 1.1,
  "stop": ["<|im_end|>", "User:"]
}

temperature（温度）

用来控制模型生成文本随机性或创造力的核心数值。温度越高，模型越有创造力，回答得越发散，温度越低，模型越保守，回答得越稳定。

低温度（通常为 0.0 - 0.3）：严谨与确定，适合代码生成、逻辑推理、事实问答等
中等温度（通常为 0.4 - 0.7）：平衡与自然，适合日常对话、内容创作等
高温度（通常为 0.8 - 1.0+）：发散与创造，适合头脑风暴、创意写作等

top_p（核采样）

模型会将所有候选词按概率从高到低排序并累加，当累加的概率值达到设置的 P 值（比如 0.9）时，就会把剩下那些低概率的词全部丢弃。这可以有效过滤掉极不靠谱的废话。

低 top_p（通常为 0.1 - 0.5）：更保守，更集中，适合需要精确和可预测输出的任务
高 top_p（通常为 0.8 - 1.0）：更随机，更多样化，适合需要创造性和多样性的任务

通常建议 Temperature（温度）和 Top-P（核采样）只挑选其中一个进行大幅度调整，另一个保持默认值即可

top_k

如果设置 K=40，模型在每次生成下一个词时，就只会在概率排名前 40 的词库里去选，排名 41 及以后的词直接被硬性淘汰。这能进一步防止模型在思维发散时“跑偏”，保证生成内容的下限。

低 top_k（通常为 1 - 10）：更保守，更集中，适合需要精确和可预测输出的任务
高 top_k（通常为 40 - 100）：更随机，更多样化，适合需要创造性和多样性的任务

max_tokens（最大输出长度）

控制模型生成文本长度。例如，当 max_tokens=1024 时，模型会生成最多 1024 个 token 的文本。如果你发现模型总是话说一半就停了，可以检查并把这个值调大。

context_length（上下文长度）

决定了模型在一次对话中能记住多长的前文。数值越大，模型能回顾的历史信息越完整，长篇阅读能力越强，但同时它也会呈几何倍数地疯狂吞噬显存（VRAM）或内存（RAM）。

repetition_penalty（重复惩罚）

降低那些已经在上文和历史记录中出现过的词再次被选中的概率。数值设置得越大，模型就越倾向于去寻找不同的新词汇。（通常在 1.1 到 1.2 之间比较合适）

frequency_penalty（频率惩罚）/ presence_penalty（存在惩罚）

粒度更细的重复惩罚，一个词出现得越多，它下次被选中的概率就被扣得越狠

stop

可以在这里定义一个数组，当云端模型在生成文本时一旦输出了这个数组里的任何一个词，就会立刻切断生成，这可以有效防止模型自导自演、代替用户说话。

选择第三方服务商

不是所有人都有条件本地部署大模型，为了方便，有人选择像硅基流动（SiliconFlow）这样的第三方聚合平台，本质上是平台帮你部署好了大模型，你只需要按需按量购买使用即可，这有点像 AI 时代的“云”。

Token

无论是闭源模型还是开源模型，只要涉及到用 API 调用的方式使用 AI ，就会看到 Token 这个单词。Token 可以理解为 AI 处理数据的最小单位，可能是一个单词，也可能是一个词组。几乎所有 API 都是按 Token 使用量收费。

部分媒体把 Token 翻译成“词元”，但是这个翻译在网络上引起不少争议。

思维链（chain-of-thought，CoT）

DeepSeek-R1 和 V3 的区别是什么？R1 属于思考模型，擅长推理和逻辑。当我们向它提问，它首先会使用 思维链（chain-of-thought，CoT） 来思考问题，完成思考后才开始输出答案，逻辑性和准确率较高。而 V3 属于全能通用模型，反应速度快，知识面广，擅长日常对话。

由此可见，如果我们要润色一封邮件，选 V3；如果要解决一道奥数题，选 R1。

然而，随着 DeepSeek V3.2 和 V4 这样的混合新模型出现，同一个模型兼具了推理模型和通用模型的特点。通常，在页面上会以“深度思考”或“Thinking”这样的字眼出现，当你想让 AI 做一些数学、代码、推理的任务时，就可以把这个选项勾上。

多模态

像 chatGPT 这样只能用文字语言交流的，属于语言模型。而有一些模型专注于其他方面，例如专注于图像生成的图像模型，Midjourney 就是一个明星产品，Google 的 Nano banana 生图效果也十分优秀。开源版本的图像模型是 Diffusion ，可玩性较高，并催生了 Stable Diffusion、ComfyUI 这类AI图像定制工具，网友们常常通过 civitai（C站）分享自己的 AI 作品。

此外，还有语音模型（如智普AI的GLM-4-Voice）、视频模型（如字节跳动的Seedance）。

然而，对于目标是星辰大海，是 通用人工智能（AGI） 的我们来说，不会满足于大模型只会一个技能。如果在训练的时候就混合了文字、语音、图像、甚至是视频的能力，这种全能的大模型就叫做 多模态模型，Gemini 就是其中之一。

提示词工程 (Prompt Engineering)

我们向 AI 提问时，输入的内容就是提示词。ChatGPT 的诞生，催生了 提示词工程 (Prompt Engineering)，简单来说，就是如何与AI说话的艺术。

早期的 ChatGPT 或者 Stable Diffusion，需要非常巧妙的提问，才能得到比较好的答案。提示词工程就是用来教你怎么写好提示词的。例如，给AI设定角色、提供背景、约束输出格式，从而让AI给出惊艳的回答，而不是泛泛而谈的废话。

上下文工程（Context Engineering）

大模型很好，但是它有两个问题：上下文窗口有限 和幻觉。

问题一：上下文窗口有限

在我们与大模型进行对话的时候，每一个对话窗口所能够输入的内容是有限的。例如，你不能一次性把一整本《红楼梦》粘贴在对话框，让大模型帮你续写。也不能对一个问题连续追问几百上千次。

这是因为大模型内部有一个 上下文窗口（Context Window），这个窗口就像是大模型的工作内存或短期记忆。它决定了模型在处理当前请求时，一次性能够看到并理解多少之前的信息。是的，当你追问时，其实是把新追问的问题拼接在之前的对话历史上，重新发送给大模型。

如何在有限的上下文窗口中，尽可能地“物尽其用”？

2025年初发布的 DeepSeek-R1 模型，所能支持的上下文窗口大小约 12.8万（128K） token，相当于一本《小王子》的长度，进入2025年和2026年，最先进的模型例如 Gemini 3.1 Pro、Claude 4.6 已经能够支持超过 100万（1M） token 的上下文，相当于 1.5 本《红楼梦》的长度。然而，上下文并不是使用得越多越好，上下文太长，大模型的推理能力和速度可能会下降，成本也会变高。

问题二：大模型的幻觉

大模型的知识只停留在它被训练好的那一天，无法给出实时信息或者是企业内部知识，加上其本质是一个概率机，容易给出一些看似有道理实际上错误的回答，这就是大模型的“幻觉”。

如何让大模型准确回答，不要瞎编？

检索增强生成（RAG）

为了解决上面两个问题，2020 年 AI 研究科学家 Patrick Lewis 等人提出了 检索增强生成（Retrieval-Augmented Generation，RAG） 技术，简而言之，就是给 AI 外接一个知识库或搜索引擎。

我们可以提前把资料上传，这些资料会先被切分成文字块，再进行向量化（Embedding），存储在向量数据库中。向量化就是把文字翻译成计算机能理解的高维浮点数数组。在向量化的世界中，越是语义相似的词语，会越接近。

当我们提问时，问题不是直接发送给大模型，而是先到向量数据库提取最相关的内容。然后把这些内容作为提示词的一部分，跟用户输入一起传输给大模型，让大模型结合这些准确资料来生成回答。例如：

你是一个专业的公司内部助手。请严格根据以下【参考资料】来回答用户的【问题】。
如果参考资料中没有相关信息，请回答“我不知道”，不要编造。

【参考资料】：
{这里填入向量数据量查到的内容，例如：
# 1. "员工入司满一年后，每年可享受5天带薪年假..."
# 2. "年假需提前一周在OA系统中申请..."
# 3. "病假相关规定如下..."}

【用户问题】：
{用户的原始问题}

企业级的 AI 客服、智能文档助手基本都在用 RAG 技术。

同理，对于有很多轮的长对话，我们也不需要每次把历史记录原封不动地重新发送给大模型，而是先向量化，或者干脆让大模型提炼总结对话历史，这样就能节省大量的上下文窗口。

像这样，为了解决大模型知识断层、不认识企业内部知识、多轮对话遗忘等问题，从而极致利用上下文窗口的工程，叫做上下文工程。

AI Agent（智能体）

大模型本质上只能输入输出自然语言，并不具备执行能力。

那么，AI 是怎么帮我们定闹钟、查天气的呢？

事实上，我们面对的各种 AI 助手，输入框背后不单纯只有大模型，而是一个 AI Agent（智能体）。Agent 本质上就是一个程序，顶层对接用户提问，中间对接各种各样的外部工具（如查天气的API、定闹钟的API、还有上一节提到的RAG等），底层再对接大模型。

当我们提问或下达一个命令，Agent 和大模型配合流程如下：

问题先进入 Agent，判断需不需要用到 RAG
将用户提问、可用的工具列表和通过RAG检索到的外部知识（如果有），组装成一个巨大的 Prompt，进入大模型
大模型接收到 Prompt，开始思考和拆解：
- 如果他认为需要调用外部工具，则返回 JSON （JSON中包含了要调用的工具名称和参数）
- 如果不需要，返回自然语言回答
Agent 根据大模型的返回：
- 如果收到 JSON，则调用对应的外部工具，把结果重新组装到 Prompt 中，再次发送给大模型
- 如果收到自然语言回答，则直接返回给用户

如下所示，是大模型返回给 Agent 的 JSON 文本，表示希望调用“getRealTimeWeather”服务，参数是“北京”。这样，Agent 就可以调用 getRealTimeWeather 方法的接口，获取北京的天气信息。

{
  "action": "getRealTimeWeather",
  "arguments": {
    "city": "北京"
  }
}

如果一次调用的结果不能达成目标，Agent 可以循环多次调用大模型和外部工具。直到大模型显式地认为目标达成（通常是在通信的 JSON 中有一个 finish_reason 字段为 stop）或者是达到 Agent 设定的最大循环次数。

可以用一个公式来定义 AI Agent：

AI Agent = LLM（大脑） + 规划（思考路径） + 记忆（RAG等） + 工具（Skills）

Function Calling / Tool Calling

大模型本身不能直接上网、查天气或定闹钟。

如果我们要让 AI 帮我们做具体的事情，就必须让大模型搭配工具。也就是说，大模型需要什么工具，Agent 就帮他去调用什么工具，这就是所谓的函数调用（Function Calling）或工具调用（Tool Calling）。

通常，AI Agent 中有哪些可用的工具，都是提前预设好的，当用户提问时，Agent 会把所有可用的工具和用户提问一起发送给大模型。（当然，如果可用工具很多，你也可以在 Agent 程序里先做一次初筛，只找出最相关的几个工具发送给大模型，毕竟，Agent 程序是你开发的，决定权在你）

由于发起外部请求一般都是 JSON 格式交互（方便程序解析），早期的 Agent 经常跟大模型斗智斗勇，比如 Agent 希望让大模型返回纯 JSON 格式，但是大模型经常不听话，给自己加戏，要么是 JSON 缺了括号或者括号层级不对，要么是在 JSON 前面多了一句“好的，这是你要的 JSON ......”这样的废话。导致 Agent 程序解析 JSON 时出现问题。

后来大模型厂商意识到纯 JSON 输出是一个强烈的需求，于是在训练模型时专门为这种场景做了微调。如果我们听到某个模型厂商宣称支持 Function Calling ，注意，并不是说这个模型自己能够去发起外部调用了，而是说，在需要工具调用的时候，模型能够保证输出严格正确的 JSON 格式（称为 JSON Schema）。

真正去触发工具调用（如调天气API、调谷歌搜索、修改文件等）这个动作的，还是 Agent 程序，而不是大模型本身。

MCP 和 MCP Server

MCP

AI Agent 去调用外部工具，通常是用 JSON 交互，但是不同的工具由不同的人开发，有不同的出入参格式，一旦工具多了，就会造成超级大麻烦。

模型上下文协议（Model Context Protocol，MCP） 是由 Anthropic 公司开源的一项开放标准，用于解决 AI Agent 与外部数据源、工具和系统集成时所面临的碎片化和非标准化问题，类似于为 AI 应用提供了通用的“USB-C 接口”。这样，大家都有了统一的标准，交互起来也就方便得多了。

MCP Server

有了 MCP 之后，虽然标准统一了，但是大家都在重复造轮子，在不同的 Agent 项目中，都要复制一份符合 MCP 标准的连接某个工具的代码。

我们为什么不把这份标准化的代码单独部署成一个服务呢？这样很多不同的 Agent 项目都可以直接连接并使用了。MCP Server 本质上就是这样一个单独部署的后台程序，用来把私有数据或工具按照 MCP 的标准格式暴露给 AI Agent。

由于开源社区和官方已经有大量极度完善、经过无数测试的专用 MCP Server，因此我们需要什么服务就启动什么 MCP 服务，例如需要连接 PostgreSQL 数据库，直接拉取官方的 postgres-mcp-server 镜像跑起来就行，而不建议自己去写一套连接 PostgreSQL 的代码。

从开箱即用、权限管控与安全隔离、单一职责与容错性、动态插拔等角度考虑，不同的功能（如读取数据库、读取文件系统）应该启动不同的 MCP Server，除非在业务场景高度耦合和定制化的场景下，才考虑把不同的数据源统一定制成一个 MCP Server。

A2A（Agent-to-Agent）

当我们的任务变得复杂起来，一个 AI Agent 往往力不从心，这时候就需要多个 AI Agent 分工协作，完成复杂任务。为了让多个 AI Agent 协作时，有一个标准化的通信方式，2025 年 4 月 Google 正式提出了 A2A（Agent-to-Agent）协议。

MCP 侧重于解决 Agent 如何连接外部数据，而 A2A 侧重于解决 Agent 之间如何谈判和协作。

Skills

我们现在有了 Agent 、有了 RAG 、有了 tool calling、有了 MCP 和 MCP server ，看起来什么都能做了，也确实什么都能做了。但是，如果一个任务需要固定的步骤来完成，比如“先查天气，再定闹钟”，我们怎么让 AI 知道这个固定的步骤呢？

我们自然会想到，把这些步骤写成一份固定的提示词，同时最好给出一份示例，或者参考文档，如果要执行脚本代码，干脆把可运行的脚本代码也提供给他，如果要调API，把API的说明文档也提供给他。

我们把上面这些东西打包成一个文件夹，就形成了一个技能包，也就是所谓的 Skills。

my-skill/
├── SKILL.md          # 必须: 说明文档 + 元数据
├── scripts/          # 可选: 可执行代码
├── references/       # 可选: 参考文档
└── assets/           # 可选: 模板、资源等

可以说，skills 解决了三个问题：

第一是 skill 提供了完成某件事的固定的提示词、步骤、脚本、参考文档，提升了 AI 的可靠性
第二是 skill 本质上就是一个文件夹，可以很方便地共享给别人，解决了技能复用的问题
第三是渐进式加载，SKILL.md 的头部有 name 和 description 字段，最初 Agent 只会把这两个字段给大模型，当大模型确认需要使用这个 skill 时，才会把完整的 SKILL.md 加载进来，这样可以避免大模型上下文窗口被工具列表撑爆的问题

下面是一个查询天气服务的 SKILL.md 示例

---
name: 天气查询助手
description: 查询实时天气
---

# Skill: Weather Inquiry Assistant (天气查询助手)

## 1. 意图与描述 (Description)
**目标**：当用户询问当前天气、未来天气预报、温度或基于天气的出行建议时，使用此技能。
**角色**：你是一个准确、客观且贴心的气象服务助手。你没有任何内置的实时天气知识，必须绝对依赖外部工具提供的数据。

## 2. 触发条件 (Triggers)
- 用户直接询问天气（例如：“北京今天热吗？”、“纽约明天下雨吗？”）。
- 用户询问基于天气的建议（例如：“周末去上海需要带伞吗？”、“明天适合洗车吗？”）。

## 3. 依赖与工具 (Required Tools)
执行此技能需要依赖以下预设的外部工具（API 函数）：
- `get_current_weather(location: string, unit: string)`: 获取指定地点的实时天气。
- `get_weather_forecast(location: string, date: string)`: 获取指定地点、指定日期的天气预报。
- `get_user_location()`: 尝试获取用户当前的默认地理位置。

## 4. 执行工作流 (Execution Steps)

1. **参数提取与验证**：
   - 检查用户输入中是否包含 **地点 (Location)**。
   - 检查用户输入中是否包含 **时间 (Time)**（默认视为“今天”/“现在”）。
2. **处理缺失信息 (Missing Information Handling)**：
   - 如果用户没有提供地点：首先尝试静默调用 `get_user_location()`。如果调用失败或无权限，必须主动向用户发起追问：“请问您想查询哪个城市的天气？”。**绝对禁止** 默认假设一个城市。
3. **执行工具调用**：
   - 根据提取的时间参数，选择调用 `get_current_weather` 或 `get_weather_forecast`。
   - 除非用户明确要求华氏度（Fahrenheit），否则默认传入 `unit = "Celsius"`（摄氏度）。
4. **数据解析与响应生成**：
   - 解析 API 返回的 JSON 数据。
   - 将生硬的数据转化为自然语言。如果用户询问的是具体建议（如“需要带伞吗”），必须在回答中给出明确的“是”或“否”，并附带降水概率作为依据。

## 5. 核心规则与最佳实践 (Rules & Best Practices)
- **零幻觉原则**：如果天气 API 返回错误或超时，诚实地告诉用户“目前无法获取气象数据”，**绝对禁止** 捏造天气状况或温度。
- **简明扼要**：优先直接回答用户的核心问题。不要堆砌所有的气象参数（如风向、气压、湿度），除非它们极端异常（如台风天）或用户明确要求。
- **单位本地化**：在输出温度时，确保带上明确的单位符号（如 25°C）。

## 6. 输出格式约定 (Output Format)
向用户输出时，建议采用以下友好且清晰的结构：
1. **结论先行**：直接回答用户的问题（如：“北京今天非常热，最高气温 35°C。”）
2. **核心数据补充**：提供天气状况（晴/雨/多云）和当前温度区间。
3. **贴心建议（可选）**：根据天气情况提供一句话的穿衣或出行建议（如：“紫外线较强，建议做好防晒。”）

Vibe Coding

有了 AI Agent 之后，我们再也不需要自己手动编写代码，一些 AI Agent 会自主规划文件结构、写代码、运行测试，甚至在内置浏览器里自我纠错，我们只需要在关键节点做出决策即可（例如，确认修改、确认执行某个脚本）。

像这样，我们只需要像产品经理一样用自然语言就能够完成软件开发的过程，就叫做 Vibe Coding。

Anysphere 公司的 cursor 、Google 公司的 Antigravity 和字节跳动公司的 Trae ，本质上就是集成了大量 AI Agent 功能，方便我们进行 Vibe Coding 或者 AI 辅助编程的 IDE 工具。

而 Anthropic 公司的 Claude Code，或者 Google 公司的 Gemini CLI, 则把 AI Agent 做成了命名行程序。这样，无论你使用什么IDE，都可以在终端中让 AI 帮你分析项目结构，甚至帮你完成任务。

OpenClaw

当我们有了各种各样的 AI Agent 之后，会发现它们都太过于“定制化“了，有些 Agent 只会帮你写代码，有些 Agent 只会帮你查天气，并且这些 Agent 内部通常绑定了某些大模型和 Skills ，并不能自由搭配。

有没有一个全能的管家，我们能自由选择大模型，自由选择需要哪些 Skills，并无缝低嵌入到你的电脑中，可以完成几乎任何一些就像我们自己在操作电脑的事情呢？有的，那就是 2026 年初爆火的 OpenClaw 。

OpenClaw 具备行动能力，它可以操作浏览器、执行终端命令、管理日程与邮件、定时执行任务（如每日搜集新闻并向你汇报），而且它可以嵌入到聊天软件之中，你可以像给朋友发消息一样，在 iMessage 上给你的 OpenClaw 下发任务，它就会帮你去完成。

但是，OpenClaw 不是万能的，它最被诟病的两点，其一是充斥大量 AI 生成的代码，工程结构混乱，意味着可能不稳定，其二是上下文管理混乱，每处理一个任务，消耗的 Token 的天量级的，意味着使用成本高昂。

尽管如此，OpenClaw 至少给了我们一些启发，让我们看到了未来 AI Agent 的潜力。

Harness Engineering

当我们有了 Claude Code 这种主导我们编程的工具，以及 OpenClaw 这种自由度非常高的 AI 助手之后，我们不禁思考，AI 的边界在哪里？

让 AI 自由发挥，理解错了你的意图怎么办？不知道有哪些工具怎么办？不小心把你电脑的重要文件删了怎么办？访问了它不该访问的文档怎么办？不记得你强调过的事怎么办？跑着跑着就偏离主线了怎么办？

于是有人提出了 Harness Engineering 这个概念，有人把这个词翻译成“驾驭工程”，讲的是我们如何通过工程化的方式，来让 AI 与模型外部环境进行交互。

我们在 Agent 内部加入了很多隔离沙箱、权限护栏 (Guardrails)、状态记忆持久化、自动化测试与反馈循环等技术手段，让 AI 大模型与真实世界、API、文件系统交互的整个闭环中正确、稳定、安全、合规地发挥，这些事情就是 Harness Engineering。

Harness Engineering 包括了提示词工程（Prompt Engineering）和上下文工程（Context Engineering）。

Claude Code、OpenClaw 这些 AI 助手，本身就是一种 Harness 。可以这样理解：一个 Agent 中，除了大模型之外，其他的部分，就是 Harness 。

有时候，AI 无法很好地完成一个任务，可能不是模型的问题，而是没有好的 Harness 。