我第一次真正接触「人工智能」这个概念，是在 2016 年左右，在吴军博士的《智能时代》中，我得以窥见那些影响人类的前沿技术，都是如何在远在硅谷的实验室中被创造出来的。

那时候，我在 Coursera 学习吴恩达（Andrew Ng）的机器学习课程，古法手写了勉强能用的 NaiveBayes 分类器，甚至还让它 在浏览器跑了起来 。那时的技术核心大多围绕着传统统计学习。比如：

• 朴素贝叶斯：通过统计过往邮件的用词规律，来「计算」一封新邮件更像是垃圾邮件，还是正常邮件。
• SVM（支持向量机）：在数据中寻找一条最优的「分界线」，试图以最大的间隙把不同类型的内容分隔开。

转眼多年过去，当下的数据规模、计算能力和模型参数量，都已经跨过了某个关键的「临界点」。这种巨大的量变最终引发了质变，一种近乎于 意识涌现 的智能现象开始频繁出现，工程师们的话题也不断从技术到哲学，甚至引发各种对「生命本质」的思考。

不过说回来，这种技术大跃迁背后的核心动力是：深度学习（Deep Learning）。深度学习的核心思想，是让机器通过海量数据自己「摸索」出规律，而不是由人类手工设计规则。类似于：一个孩子不是靠背字典学会说话的，而是在无数次听与说中，自然而然地理解了语言。

如果把深度学习看作一个坚实的地基，那么当下席卷全球的大模型（LLM），就是在这个地基之上盖起的、直插云霄的摩天大楼。

大语言模型（LLM）

大模型的全名是 Large Language Model ，相比于规模跃迁之前的模型，突出的就是一个「大」字：它既大在万亿级别的参数量，也大在动辄数百 GB 甚至 TB 级别的模型规模。

通俗地说：大语言模型 = 深度学习技术 + 海量参数 + 惊人算力 + 近乎全人类文明的文本数据 × 训练之后的产物（推理能力）。

在真正理解大模型「更聪明」在哪之前，我们需要先搞明白一个更基础的问题：大模型是怎么「看见」文字的？

就如同，计算机的底层永远都是映射高低电平的 0 和 1 一样，其实大模型压根不认识人类写的文字。模型的内部全是矩阵运算，接收和输出的都是数字。因此，我们和 AI 对话时所打出的文字抵达模型之前，必须经过一个叫做 Tokenizer 的翻译层：它会先把输入的文本切分成若干最小片段，再把每个片段映射成一个对应的数字编号，也就是 Token ID，然后把这串数字列表送进模型。输出时再反向翻译回来，把数字还原成人类可读的文字。

Token ，就是这套切分规则产出的最小单元，也是大模型处理文本时真正意义上的「一个单位」—— 它既不是字，也不完全等同于词，而是模型在训练过程中自己学出来的一套切分规则。比如「程序员」这个词，在某些模型里会被切成「程序」和「员」两个 Token，英文单词 unhappy 则可能被拆成 un 和 happy。

一般来说，一个 Token 约等于 0.75 个英文单词，或 1.5 到 2 个汉字。这个数字在实际使用中很有参考价值：当你看到某个模型支持「100 万 Token 的上下文窗口」，换算一下大概是 150 万汉字 —— 够塞得下一整本《红楼梦》和《三国演义》了。而「上下文窗口」（Context Window），正是衡量一个模型单次能处理多少信息的核心指标，也是后面 RAG 要解决的核心约束之一。

大模型生成文字的方式，本质上是一场不断向前滚动的概率计算。它每次只预测「下一个最可能出现的 Token 是什么」，吐出这个 Token 之后，再把它追加到已有的序列末尾，基于这个更长的序列重新计算下一个……如此循环，直到输出结束符为止。

这意味着：模型并不是「想好了整句话再说出来」，而是每一步都在用截至当前的全部内容做依据，滚动地预测下一个词。 这也是为什么你会在屏幕上看到模型一个词一个词地「流」出来，因为它确实就是这么一步步算出来的，而不是一次性生成后再逐字显示的前端体验优化。

相比早期只能做标签化预测的分类器，大语言模型之所以显得「更聪明」，关键在于它学会了两件以前模型不擅长的事：

一、理解一句话里的「顺序和关系」

现在的大模型不再只是把词当成零散的符号，而是知道哪些词在前、哪些在后，它们之间是因果、指代，还是转折关系。

二、知道怎么在一句话里「抓重点」

当一句话中出现「它」、「这件事」、「那个东西」之类的模糊指代时，模型会自动判断这些词更可能指向谁（权重），而不是平均对待每一个词。这让它在理解长句、复杂语义时，看起来更像人在思考。

在这些核心能力的加持下，大模型开始向不同感官演化：

• 大语言模型 ：现在最成熟的分支，擅长文字创作、逻辑推理和对话。
• 视觉大模型 ：不仅能「看」到像素，更能识别出图像中的物体关系、场景氛围甚至复杂的动态行为。
• 多模态大模型 ：这是目前的「终极形态」，它能同时处理文字、图像和声音，像人类一样通过多种感官综合理解世界。

总之，大模型不再像以前那样只是「判断对错」的工具，而更像是：一个能理解上下文、组合信息、并给出连贯回应的智能系统。 这种体验，就如同我们在和 ChatGPT、Gemini 对话时那般自然。

向量嵌入（Embedding）

在传统数据库里，存储的都是明确、量化、结构化的信息。比如这样的：

当我们需要检索数据时，只能通过明确的字段、参数来过滤数据输出。比如：用 /query?gender=male&height_min=175&bmi_max=23 来筛选出「身高高于 175 且 BMI 低于 23 的男性」。

但如果你的需求是：筛选出几个身材精壮的年轻小伙。 传统数据库就懵了：

• 「年轻」是多少岁？
• 「精壮」是看身高、体重、BMI，还是整体感觉？

这种模糊、主观、难以量化的语义，几乎无法用传统数据库来处理。因此， 向量数据库 （Vector Database）应运而生。它存储的核心不再是孤立的字符，而是将数据转化为具有特定含义的「特征向量」。

通俗一点说：向量数据库存储的不再是原始数据本身，而是数据的「含义」。

而「把数据转换成含义」的过程，就是 向量嵌入 （Embedding）。

Embedding 模型会把一段文字、一句话，甚至一张图片，转换成一串数字坐标，投射到一个高维的「语义空间」中。 在这个空间里：

• 含义相近的内容，位置会靠得更近（如「首相」与「总统」）。
• 含义无关的内容，距离自然会很远（如「汽车」与「寺庙」）。

当我们向 AI 提问时，它并不是在像传统检索那样「逐字匹配关键词」，而是在做一件更像人类的事情：找含义最接近的内容。

技术上，每一个被存入向量数据库的文本片段，都已经在索引阶段经由 Embedding 转换成了一串数字坐标。当用户发来一个问题，系统会把这个问题同样转成向量，然后逐一计算它与数据库中每个片段向量之间的距离或夹角，得出一个相似度分值，最后按分值排序，取最靠前的几条返回。

也就是说，所谓「语义检索」，本质上是一次全库打分与排序 —— 不是在找「字面上相同的词」，而是在找「数字坐标最接近的那些片段」。这种查找方式，被称为 相似性搜索 （Similarity Search）。常见的衡量标准包括：

• 欧几里得距离 ：测算两点间的「直线距离」，距离越短，相似度越高。
• 余弦相似度 ：关注向量之间的「夹角」，夹角越小，意味着它们的逻辑方向越一致。这在处理长短不一的文本语义时表现特别好。

简单来说：AI 并不是在找「完全一样的字符」，而是在找「内涵最接近的灵魂」。 也正因为有了这种机制，AI 才具备了理解人类语言中微妙差异的能力。

当我们开始用「含义」而非「关键词」来检索信息时，一个新的问题就出现了：如果这些「含义」来自我自己的数据，而不是模型的训练记忆呢？模型会给我怎样的答案？

比如，当我问直接去问 GPT：「我还是对前天发生的那件事耿耿于怀，你怎么看？」GPT 不知道前天发生了什么事，不知道训练记忆之外的信息，就只能胡编乱答或者无法回答。

于是，就有了 RAG 这种应用形态。

检索增强生成（RAG）

前文提到，大语言模型（LLM）是通过海量数据训练得到的。它是一个拿海量数据训练出的结果（概率权重机制），而不是数据本身。 这就意味着它有两个明确的设计边界：

• 时效性：训练数据有截止日期，它不会知道今天刚发生的新闻。
• 覆盖面：基于公共数据训练，它不会知道专业领域知识、私有业务知识。

如果不考虑这些限制，大模型往往只能被当作一个通用的推理与生成工具来使用。那，要如何让模型知道并理解我的私有知识呢？

先看一个我经常会用到的实际场景：我每次完成一篇文章，都会把这篇文章的内容全文粘贴到 ChatGPT 的对话窗口，并请它给出纠错和点评。 这个流程的实质就是：我把一段大模型原本并不了解的私有内容作为「上下文」交给它，再让它基于这些信息给出理解、分析和反馈。

但如果我给出的不再是一篇文章，而是合并全站的几百篇文章在一起的一个长达数十万字的集合，让大模型来给出一个整体评价呢？

单从技术上说，这是可以做到的。比如 Gemini 1.x 的模型就已经支持百万级 Tokens 的上下文窗口了。但是，这样做的效率会很低，在长上下文的频繁请求下，会产生大量的算力消耗，成本极高。

在现实的场景中，更多的需求是：一个企业希望把自己的产品手册、FAQ、技术文档等私有资料交给大模型，让它能够回答终端用户提出的各种问题。

在这种场景下，效率、成本、准确性 就成了必须认真考虑的问题。

这正是 检索增强生成 （Retrieval-Augmented Generation）出现的原因。

简单去理解的话，RAG 就像是给大模型进行一次「开卷考试」：先从海量资料中检索出相关的考点，再让大模型基于这些知识片段组装答案。

常见的 RAG 流程，大概可以分为两部分：

一、存知识：构建外部知识库。

• 分块（Chunking）：将长文档切分为语义相对完整的小片段。
• 向量化（Embedding）：利用 Embedding 模型将片段转为向量，存入向量数据库。

二、取与答：按需调取知识。

• 检索（Retrieve）：将用户问题转成向量，在数据库中查找语义最接近的内容片段。
• 生成（Generate）：将「问题 + 检索到的片段」一起打包发给大模型。一般来说，都是类似这样的指令：「请根据以下参考资料回答，如果资料未提及，请回答不知道。」

简单来说：RAG = LLM（聪明的大脑）+ 向量数据库（外部知识）。

如果没有外部知识库的支持，大模型只是一个空有逻辑、但在专业盲区会「一本正经地胡说八道」的机器人。而 RAG 的引入，让大模型从「凭记忆作答」转变为「基于证据说话」，在极大程度上抑制了 AI 的 幻觉现象 。

智能体（AI Agents）

当我们向 ChatGPT 问出：今天清迈的天气怎么样？ ChatGPT 想要回答这个问题，就必须先「理解」我是在询问关于某时某地的某个数据，然后「动手」去调用一些 API 来获取对应的数据，再返回来组装后输出。

大模型 LLM 本身只是「大脑」，是强有力的思考工具。可以理解输入的意图，但无法产生副作用（即无法直接改变系统状态或操作现实世界）。也就是说：它知道我是在问天气，但它没办法去查询天气，除非我「明确教了它」查询天气的 API 以及调用方法。 或者是 Siri 知道我想让扫地机器人停下来，但我没告诉它扫地机器人应该如何停，它就没有任何办法。

就像这样，当我们不断地为大模型装备上各种可用的工具和能力：查天气的 API、搜索引擎、文件处理、代码执行... 并允许它在思考过程中自主选择和调用这些工具时，一个近乎万能的 智能体 （AI Agents）就诞生了。

通俗地说：AI Agents = 拥有手脚和工具（Tools）的大脑（LLM）。

它与普通 LLM 的最大区别在于：不只是回答问题，而是能够完成实际任务。 比如：

• Gemini 集成了 Google 搜索能力，可以分析实时天气、股价和新闻。
• ChatGPT 集成了文件与代码工具，可以直接翻译文档、转格式、写代码。

这些能力的背后，就是不同形式的 Agent 的集成。比如，下面就是一段运行在 Cloudflare Workers AI 中的关于工具集成的伪代码：

        
        

          
1234567891011121314151617181920212223242526272829303132333435363738
          
const { message } = await request.json();

// 定义 LLM 有哪些具体的工具可以使用
const tools = [
  {
    name: "word_to_pdf",
    description: "当用户提出要转换文档、Word 转 PDF 或处理 .docx 文件时调用。",
    parameters: {
      type: "object",
      properties: { filename: { type: "string" } },
    },
  },
];

const aiResponse = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
  // 将工具列表告知 LLM 大模型
  tools: tools,
  messages: [
    {
      role: "system",
      content:
        "你是一个工具网站的 AI 助手。如果用户想转 PDF，请直接调用 word_to_pdf 工具。否则请优雅地回答能力不足。",
    },
    { role: "user", content: message },
  ],
});

if (aiResponse.tool_calls?.some((tool) => tool.name === "word_to_pdf")) {
  // 如果 AI 理解用户语义后，下达了「转换」指令，则执行相关业务操作
  service.wordToPdf().then((result) => {
    return new Response({
      response: "文件已转换完成",
      pdf: result,
    });
  });
} else {
  return new Response(JSON.stringify({ response: aiResponse.response }));
}
        
      

看起来已经相当优雅可用了，但在复杂任务中，挑战又出现了。

假设我们给 Agent 这样一个任务：我想去东南亚旅行，在东盟 10 个国家中选择目的地；我要天气晴朗、机票便宜、最好有廉价航空；如果这段时间没有廉航，就直接排除这个地方。

这个任务并不是一次查询就能完成的，而是涉及多个条件、多个步骤、前后强相关的判断。要想顺利完成，Agent 就必须具备像人类一样做事的能力。

那人是怎样做事的？人类在处理复杂任务时，通常会遵循一种朴素但有效的方法：先计划 → 再执行 → 看结果 → 再调整。

这就是著名的 PDCA 循环 。

PDCA 是美国统计学家 Shewhart 博士提出的，由另一个统计学家 Deming 采纳、宣传，获得普及，所以又称戴明环。

PDCA 就是把事务的流程分为四个阶段，以确保每次的目标都能达成。

1. 计划（Plan）：拆解任务，制定步骤。
2. 执行（Do）：按计划逐步行动。
3. 检查（Check）：判断结果是否符合预期。
4. 调整（Act）：总结经验或重新规划，进入下一轮。

这种方法在人类社会中被反复验证，甚至在日本工业界广受推崇，是高效完成复杂任务的经验总结。

在 AI 领域，这种思路被转化为 ReAct （Reason + Act）框架。它的核心是：让模型在每一步行动前进行思考（Thought），在行动后进行观察（Observation），并把结果反馈给下一步思考。

也就是说，Agent 会在执行过程中不断记录：我在想什么（Thought）、我调用了什么工具（Action）、得到了什么结果（Observation），再基于这些信息继续判断和执行后续任务。

ReAct 对应 PDCA，可抽象为：

• 规划（Plan/Thought）：将复杂的大任务拆解为小的、可操作的子任务（ToDo List）。
• 执行（Do/Action）：当内部知识不足时，主动调用外部 API（搜索、运行代码、访问数据库）。
• 评估（Check/Observation）：检查执行结果是否符合预期。如果 API 报错或数据异常，需要能自我定位原因。目前，顶级模型已具备一定的自我反思能力，但在严苛场景下还是需要结合特定逻辑进行校验。
• 反思（Act/Next Thought）：基于评估结果，决定是结束任务，还是调整策略进入下一个循环。

这种方式显著提升了 Agent 在复杂任务中的反思能力和问题解决能力，许多知名项目（如 AutoGPT 、 LangChain 中的 Agent 体系）都直接或间接采用了类似思路。

不过，当任务变得足够复杂时，问题也会随之出现：

• 如果任务拆解得不够细，步骤就无法穷尽。
• 如果缺乏评估与反馈，循环就可能永远停不下来。

因此，规划能力直接决定着 Agent 的鲁棒性，它是界定一个 Agent 是否真正可用的关键分水岭，也是现在 Agent 研究的核心方向之一。

ReAct 这种设计思想也可以用于 Prompt 的设计中，只需要遵循：

1. 明确引导模型进行链式推理。
2. 定义可执行的行为（工具或 API）。
3. 要求模型在每次行动后进行观察与再评估。
4. 允许循环执行，并设置终止条件（如最大步数或完成判定）。
5. 在满足条件后输出最终答案。

一个典型 ReAct 范式的 Prompt 结构大概像这样：

        
        

          
1234567
          
Question: 用户的初始问题
Thought: 模型对问题的初步分析，决定下一步该做什么
Action: 模型选择要调用的具体工具
Action Input: 传递给工具的参数
Observation: 工具返回的结果（反馈给模型）
... (重复上述过程，直到找到答案)
Final Answer: 最终输出
        
      

这套结构，决定了 AI「像人一样做事」的实力。

模型上下文协议（MCP）

Agent 的手脚和工具有很多，但 每只手、每只脚的「接口」都不一样，怎么办？

以前，如果想让 Agent 连接自己的 GitHub、Notion 或者本地数据库，开发者需要为每一个工具编写专属的集成代码。这就像是在 USB 出现之前，用鼠标要专门插一个接口，用键盘又是另一个接口，打印机、光驱... 每多一个不同能力的硬件，就要多适配一个硬件特定的接口。

为了终结这种「接口碎片化」的低效、混乱、强耦合， 模型上下文协议 （Model Context Protocol）应运而生。

可以把 MCP 想象成 AI 时代的 USB 标准。它是由 Anthropic（Claude 的母公司）提出的一项开放协议，旨在为大模型和外部数据、工具之间建立一套通用的「对话语言」。

• 以前的集成模式：模型 ↔ 专门的适配代码 ↔ 不同的工具/数据。
• MCP 集成模式：模型 ↔ MCP 协议 ↔ 任何支持 MCP 的工具。

在当下这个 Agent 蓬勃的时代，MCP 非常重要，它极大地降低了开发成本，推进了 AI 生态的完善。

一、从「写集成代码」到「写工具协议」。

以前每接入一个新工具，都要：写一套专属的 Prompt 说明、写一层适配代码、处理模型返回结果，再喂回模型。现在工具只需要实现一次 MCP Server，模型只要支持 MCP Client，双方就能通过统一协议通信。就像是 USB 的公口插到母口那样简单。

开发者从「给模型写适配代码」，变成了「给工具声明能力边界」。

二、模型与工具解耦，避免「绑定厂商」。

传统集成，工具是绑定模型平台的，代码都是专门适配的。MCP 协议下，变成了：任何模型 ↔ MCP ↔ 工具。 哪怕今天用 GPT，明天换 Claude，也不用重写工具的集成了，只要模型支持 MCP Client 就可以无痛迁移。

三、上下文不再靠「猜」，而是结构化地理解。

在没有 MCP 时，模型理解外部环境通常靠：手动粘贴、模型猜测、Prompt 描述。 MCP 协议下：以结构化上下文的方式暴露能力、明确信息的访问的边界和权限。 这让模型在「动手」之前拥有了更清晰的全局观，而不是瞎猜。

简单来说： 如果说 Agent 是让大脑长出了手脚，那么 MCP 就是统一了手脚的神经反射接口。

截止目前，像 Cursor、Claude Desktop 等工具已经深度支持了 MCP。这意味着啥呢？意味着任何人都可以在本地跑一个简单的 MCP Server，让云端的顶尖大模型直接读写你的本地数据库或执行本地脚本。甚至在授权下读取本地的相册、日记、待办，让 AI 真正成为接管数字世界的「超级中枢」。

模块化技能包（Skills）

如果说 MCP 能给大模型接上一堆不同能力的手脚，那 Skills 解决的就是另一件事：怎么指挥手脚把一件事真正做好。

MCP 关心「能不能做，能做哪些」，而 Skills 关心的是「该怎么做，怎么做最优」。 MCP 强调的是工具能力，Skills 强调的是使用工具的方法论。

就像是：当我们需要做一顿饭，MCP 会先帮我们确保有刀能切、有锅能炒、有灶台能生火，先把工具能力准备齐全；但一顿饭做出来好不好吃，取决于厨师的经验（像是顺序、火候、调剂佐料的时机...）而这些东西，不是工具能实现的，它们是方法，是经验。

Skills 本质上就是把这些「方法」结构化、显式化，变成 AI 可以反复遵循的一套标准流水线 SOP 。

在技术实现上，Skills 解决了一个关键痛点：上下文空间浪费。

比如，我们现在设计了一个机器人，为了力求它全知全能，我们基于一个顶级的大模型，并为它配备了 500 个工具，于是我们就需要把这 500 个工具各自的说明书打包，在 AI 启动时（运行前）全部一股脑丢给它。而这种操作，会瞬间占满 AI 的注意力，导致 AI 在处理核心任务时能力下降，这就是 上下文膨胀 （Prompt Bloat）。

而 Skills 采用的是 「渐进式披露」 策略。也就是：AI 在启动时只会看到所有 Skill 的名字和简短描述，只有当 AI 判断当前任务确实需要某个特定 Skill 时，才会按需加载它的详细内容。 这就像是，以前是给 AI 读整本工具书的全文，AI 记不住，而且还会因为信息太多而把我的问题本身给降权，导致回答不准确； 而现在不再给 AI 直接读一本书，而是给它读一个带简单摘要和名字的目录，当要用到某个工具的时候，再进去翻到工具所在的内容页。

一个 Skill 在工程上的表现很简单，其实就是一个文件夹，里面有一个主要的 skill.md 描述文件，和一些可选的资料文件。结构虽然朴素，但在理念上它承载的是一套工作方法论：

• skill.md：核心文件，包含元数据（名称/描述）和正文（详细的执行步骤与 SOP）。
• References（参考资料）：存放目标范例，让 AI 知道「好结果」长啥样。
• Assets（素材模板）：提供规范的输出格式，比如一个 Notion 页面模板。
• Scripts（自动化脚本）：对于既定的操作步骤，直接提供代码让 AI 调用。

AI 启动时，并不会把所有 Skill 的正文一股脑塞进上下文，它只去理解每个 Skill 的名字和一句话简介，只有当它判断「这个 Skill 和当前任务高度相关」时，才会把这个 Skill 的正文加载进来。这就是一种按需展开、渐进披露的设计。

也许在未来 AI 会聪明到不再需要人类主动告知它 SOP。但当下的现实是：越是复杂、越是结果导向的事情，越依赖流程。除非我们对结果本身没有确定性要求。

顺序不一样，结果就不一样。 做饭是这样，写作是这样，做项目、做规划、做决策，也都是这样。Skills 做的事情，就是把那些「经验里才有的流程」提前写清楚：什么时候该问问题，什么时候该产出草稿，什么时候该检查、对齐、收敛，做到什么程度才算「合格」。

这些判断，工具不知道，模型也不会凭空知道，它们只能来自人类智慧的沉淀。

提示词（Prompt）

传统编程，是以人的意图设计为蓝本（产品），用代码去实现具体业务（开发）。

AI 驱动的编程，同样是实现人的意图（产品），但不再有程序实现这一步，而是通过自然语言编织逻辑（Prompt）来传递意图。 大模型理解这些提示词后，会根据指令去调用对应的工具或生成内容，从而完成任务。

所以，提示词工程不仅仅是简单的提问，而是一门能让 AI 更好地理解和执行需求的技术。 于是就衍生出了这门叫 提示词工程 （Prompt Engineering）的学问。

简而言之：提示词（Prompt）就是你提交给大模型的「需求说明书」。 你怎么问，它就怎么答。问得好，答案就靠谱；问得差，答案就离谱。

目前市面上大部分的 AI 功能的本质都是一样的：构造一个 Prompt，然后调用大模型 API。

比如：

• AI 摘要/点评？→ Prompt + LLM
• AI 翻译/改版？→ Prompt + LLM
• AI 生成 PPT？→ Prompt + LLM

所以想实践好大模型应用，Prompt 的编写是非常重要的。而一个良好的 Prompt 结构，就是能够向大模型阐述清楚需求逻辑的结构。

• 角色（Role）：定义大模型现在的身份（如：你是一位资深的架构师）。
• 规则（Constraints）：明确必须遵守的底线（如：严禁泄露用户信息，回答必须简洁）。
• 流程（Workflow）：分步说明做事的方法（如：第一步提取关键词，第二步分析情感）。
• 输出（Output）：规定结果的格式（如：以特定结构的 JSON 输出，或使用 Markdown 表格）。

当逻辑组织得足够清晰严密时，大模型输出的稳定性和质量都会有很好的提升。

商业版图

简单总结一下这些 AI 相关的概念与技术：

而围绕这些技术，当下的 AI 行业也已经形成了相对清晰的分工：

• 超级智能体（Agent）：以 ChatGPT、Claude、Gemini 为代表，它们集成强大的插件生态（可能间接推动像 MCP 这种接口标准），以全能助手的定位直接服务用户。
• 开源底座：像是 DeepSeek、阿里的通义千问（Qwen）、Meta Llama 等强力开源模型。这些都是构建 Agent 的核心底座。
• 知识库存储：诸如 SupaBase 、 Pinecone 或 Cloudflare Vectorize 之类的云商业数据库，为 AI 提供持久化记忆。
• 开发编排平台：诸如 Dify 之类的平台，允许开发者通过可视化流，将模型、向量库与工具集成，快速搭建 Agent 应用。
• 垂直方案封装：像 FastGPT 之类的平台，更侧重于业务层的深度封装。使用成本略高，但效率很高，对完全 0 技术人群来说相当友好。
• 基础算力设施：以 Cloudflare Workers AI 为代表，只部署开源模型，完全按照算力消耗付费，而且免费额度完全管饱，个人开发者门槛很低。

技术与人

我从来不是一个缺乏想象力的人，但回望 10 年前，当我还在浏览器里折腾那个简陋的贝叶斯分类器时，我确实不会想到 AI 是以如此具体、如此渐进又飞跃的形式呈现的。

从理解词汇的 Embedding，到学会查资料的 RAG，再到现在有手有脚能思考的 Agent；技术名词层出不穷，效率也确实有了指数级提高，纳斯达克的走势也翻倍再翻倍。但我还是能隐约感觉到：似乎更重要的，不再是对工具的掌握，而是 「自己为什么需要这个工具」。

人的工具属性被大大弱化，甚至归零，那人存在的意义又从哪重新建立？ 还是说，大多数人，本来就应该直观地面对「无意义」这个事实。

引用「 槽边往事 」的一段话：

相比于最强的推理模型，更重要的是那个 值得放进去跑一遍的问题。 相比于最强的编程模型，更重要的是一个 解决了真实需求痛点的好点子。 相比于最强的视频生成模型，更重要的是一个 能打动人心、让人产生共鸣的好故事。

这里，这些模型、工具无法解决的东西，都需要时间，都需要思考，需要人类本身的智慧和温度；这在过去、现在乃至未来，都不是 AI 所能解决的问题。

工具可以被替代，但 「值得被解决的问题」只能由人来发现。多年前折腾分类器的那个下午，我并不知道自己在做什么，只是觉得有意思。现在回头看，那份「有意思」本身，才是没有被任何工具取代过的东西。

保持好奇、认真打磨、用心生活，永远不会被淘汰。

（完）