人工智能（AI）知识串讲

约 7365 字大约 25 分钟

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 架构，有几个特点：

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

大模型时代

大语言模型（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 ，都属于闭源模型，我们只能在官方应用中使用或者调用官方提供的 API 。而有一些公司为了抢占市场或提高知名度，选择把大模型开源，例如：

2023 年 Meta 开源了 LLaMA 模型；
2024 年深度求索开源了 DeepSeek-V3 和 DeepSeek-R1 模型，并在2025年初火爆出圈，推动了国内 AI 的浪潮；
2025 年阿里开源了 Qwen 3.5 模型；
2026 年 Google 开源了 Gemma 4 模型。

MoE & Dense

以 DeepSeek 为例，DeepSeek-V3 是通用模型，这类模型常采用 稠密模型架构（Dense），相对更“全能”一些。

而 DeepSeek-R1 采用 混合专家模型架构（Mixture-of-Experts, MoE），属于思考模型，擅长推理和逻辑。当我们向它提问，它首先会使用 思维链（chain-of-thought，CoT） 来思考问题，完成思考后才开始输出答案，逻辑性和准确率较高。

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

下载开源模型

开源模型的好处是我们可以把大模型下载到本地部署，企业可以在内网部署大模型，进行 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 位的、中等量化强度的模型。

运行本地大模型

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

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

选择第三方服务商

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

多模态

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

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

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

Token

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

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

蒸馏

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

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

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

提示词工程 (Prompt Engineering)

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

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

上下文工程（Context Engineering）

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

问题一：上下文窗口有限

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

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

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

2024年发布的 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 技术。

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

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

Skills

大模型本身不能直接上网、查天气或定闹钟。它唯一能做的事情，就是接收一段文本，然后预测并输出下一段文本。如果我们要让 AI 帮我们做具体的事情，就必须让大模型搭配工具。

Skills 就是这样一份技能清单，它本质就是一个个现成的、可被 AI 读取的工具，刚刚提到， AI 大模型只能接收文本，所以这个“工具”必然也是以文本的形式存在。通常，Skill 会被标准化为一个 SKILL.md 文件，里面说明了这项技能的详细信息，包括这项技能涉及到的外部接口（如有）。

当我们想让 AI 帮我们查天气，AI 首先会查找 Skills 技能清单，如果清单里面恰好有一项“天气服务”，它就能根据“天气服务”的说明，构造相应的入参，让后台应用帮忙调用，得到结果后，再组织成通顺的语言来回答。

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

# 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. **贴心建议（可选）**：根据天气情况提供一句话的穿衣或出行建议（如：“紫外线较强，建议做好防晒。”）

AI Agent（智能体）

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

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

事实上，我们面对的各种 AI 助手，输入框背后不单纯只有大模型，而是一个 AI Agent（智能体）。Agent 本质上就是一个程序，一边对接了大模型，另一边对接了各种各样的外部资源（Skills、RAG、MCP Server、第三方接口等等）。

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

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

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

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

如果一次调用的结果不能达成目标，Agent 可以循环多次调用大模型和外部工具。

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

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

Function Calling

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

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

构建智能体的三种范式

1. ReAct

ReAct（Reason + Act）是构建智能体的一种范式，它通过一种特殊的提示工程来引导模型，使其每一步的输出都遵循一个固定的轨迹：

Thought（思考）：分析当前情况、分解任务、制定下一步计划，或者反思上一步的结果。
Action（行动）：决定采取的具体动作，通常是调用一个外部工具。
Observation（观察）：观察从外部工具返回的结果。

智能体将不断重复这个 Thought -> Action -> Observation 的循环，将新的观察结果追加到历史记录中，形成一个不断增长的上下文，直到它在Thought中认为已经找到了最终答案，然后输出结果。

2. Plan-and-Solve

Plan-and-Solve 是构建智能体的另一种范式，解决思维链在处理复杂问题时容易“偏离轨道”的问题，整个流程分两个核心阶段：

规划 (Planning)：将问题分解，并制定一个清晰、分步骤的行动计划。规划本身是一次 LLM 调用。
执行 (Solving)：严格按照计划中的步骤，逐一执行。每一步的执行都可能是一次独立的 LLM 调用，或者是对上一步结果的加工处理，直到计划中的所有步骤都完成。

3. Reflection

在前两种的基础上，加入反思和优化。核心流程：

执行（Execution）：用 ReAct 或 Plan-and-Solve 尝试执行一个任务。
反思（Reflection） 调用一个独立的LLM实例，扮演“评审员”，从多个维度进行评估完成情况，包括事实性错误、逻辑漏洞、效率问题、遗漏等。
优化 (Refinement)：对反思阶段发现的问题，进行优化

MCP 和 MCP Server

MCP

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

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

MCP Server

如果我们把 AI Agent 比作客户端，那么 MCP Server 就是专门给 Agent 调用的服务器。

MCP Server 本质上也是一个后台程序，用来把私有数据或工具按照 MCP 的标准格式暴露给 AI 客户端。由于开源社区和官方已经有大量极度完善、经过无数测试的专用 MCP Server，因此我们需要什么服务就启动什么 MCP 服务，例如需要连接 PostgreSQL 数据库，直接拉取官方的 postgres-mcp-server 镜像跑起来就行，而不建议自己去写一套连接 PostgreSQL 的代码。

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

Vibe Coding

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

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

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

OpenClaw

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

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

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