文章作者、来源：36Kr

AI热词串起从会回答到能办事的能力进阶链

AI圈子现在最不缺的，就是新名词。

LLM、Token、Context、Prompt、RAG、Tool、MCP、Agent、Skill……

AI 这些热词不是词汇表，而是一条从“会回答”到“能办事”的能力链。

很多人看到这些词，第一反应是：AI 还没完全用明白，概念先背不过来了。

但如果换个角度看，它们并不是一堆孤立的技术黑话。它们背后其实只有一条主线：

AI正在从一个“会聊天的窗口”，变成一个“能进入工作流的系统”。

过去我们用 AI，更多是问一句、答一句。让它写一段文案。让它总结一份资料。让它改一篇文章。让它解释一个概念。

这个阶段的 AI，更像一个语言助手。它的核心价值，是帮你把话说出来。但现在，AI 的边界已经开始往外走。

它不只是生成内容，还要理解上下文；不只是回答问题，还要检索资料；不只是给建议，还要调用工具；不只是完成一步动作，而是拆解任务、持续执行，最后交付一个相对完整的结果。

所以，理解 AI 名词最好的方式，不是把它们做成一张词汇表。更好的方式，是顺着一个真实使用过程去看：

AI为什么能回答你？

它为什么能接住前后文？

它为什么不能只靠自己瞎答？

它为什么有时候输出不能直接用？

它怎么从“给建议”变成“能操作”？

它又怎么真正进入工作流？

这条线看明白了，很多 AI 热词自然就有了位置。

AI为什么能回答你

今天几乎所有主流 AI 应用，底层都离不开一个东西：LLM。

LLM，全称是 Large Language Model，中文叫大语言模型，也就是我们常说的大模型。

你看到的是写作助手、AI 搜索、智能客服、代码工具、知识库问答、投研助手、办公自动化工具，但往下拆，大概率都是某个大模型在提供核心能力。

大模型最核心的工作方式，可以粗略理解为：

根据前面的输入，生成后面可能出现的内容。

你问它一个问题，它不是像人一样先在脑子里完整想好一篇答案，再一次性输出。它更像是在不断根据已有内容往后续写，一段一段生成结果。

这也是为什么 AI 看起来特别像在“接话”。

你给它一个标题，它能接着写正文。

你给它一段资料，它能接着做总结。

你给它一个需求，它能接着组织方案。

你给它一个问题，它能接着给出解释。

所以，早期很多人对大模型的第一印象是：它很会写，很会总结，很会把复杂内容讲得像人话。

但这里还有一个容易被忽略的概念：Token。

我们平时说一篇文章有多少字，但大模型不是按“字”来工作，而是按 Token 来处理信息。

Token 可以理解为模型眼里的“信息切片”。

一个汉字可能是一个 Token，也可能和其他字符组成一个 Token；一个英文单词可能是一个 Token，也可能被拆成多个 Token；代码、标点、特殊符号，也都会被切成不同的 Token。

中间负责切分和转换的角色，叫 Tokenizer。

它会把人类能看懂的文字，拆成模型能处理的 Token，再转成数字。模型真正处理的不是文字，而是一串数字。

这也是为什么很多 AI 产品会谈 Token 消耗。

你输入的内容越多，消耗的 Token 越多；你让模型输出越长，消耗的 Token 也越多；你把历史对话、系统规则、工具说明、文档资料全塞进去，也都要占 Token。

Token 不只是技术细节，它背后对应的是成本、速度和容量。

尤其到企业场景里，如果每次问答都把大量无关资料塞给模型，系统会变慢，调用成本也会升高。

所以，AI 能回答你，靠的是大模型；但 AI 怎么处理你的输入，靠的是 Token 这套底层单位。

这是理解后面所有概念的起点。

AI为什么能接住前后文？

我们和 AI 聊天时，经常会觉得它有记忆。

前面告诉它一个背景，后面继续问，它好像还能接得上。

比如你先说：我正在做一篇关于 AI 工具的公众号文章。过一会儿你再说：帮我把开头写得更有冲突感。

它通常能知道你说的“开头”，指的是前面那篇文章的开头。

这看起来像是 AI 记住了你说过的话。

但更准确地说，很多时候不是它真的“记住了”，而是这一次它又“看见了”。

这里就要讲到 Context，上下文。

Context 可以理解为：

模型这一次工作时，桌面上摊开的全部材料。

它里面可能有当前问题，也可能有前面的对话历史，还可能有你提供的资料、系统设定的规则、输出格式要求、工具列表，甚至还有模型刚刚生成过的中间内容。

所以，AI 输出质量不只取决于模型本身，还取决于这一次它到底看到了什么。

该给的背景没给，它就只能猜；无关信息塞太多，它就容易被干扰；规则写得不清楚，它就会自由发挥；历史上下文太乱，它就可能前后矛盾。

这就是为什么现在越来越多人开始讲 Context Engineering，上下文工程。

过去大家更熟悉 Prompt Engineering，好像只要把一句提示词写好，AI 就能稳定输出。

但现在大家慢慢发现，真正影响 AI 效果的，不只是那一句 Prompt，而是模型这一次看到的全部信息怎么组织。

换句话说：

prompt是一句指令，context是完整现场。

你只把指令写清楚，还不够。你还要知道哪些资料该放进来，哪些历史要保留，哪些规则要前置，哪些无关信息应该拿掉。

还有一个相关概念，叫 Context Window，上下文窗口。

它指的是模型一次最多能处理多少 Token。

上下文窗口越大，模型理论上一次能看到的信息越多。所以很多模型会强调长上下文能力，适合处理长文档、长对话、大型代码仓库、合同资料、会议记录。

但这里有一个误区：

能塞进去，不代表就该全部塞进去。

你把几百页资料一股脑丢给 AI，它确实可能能读，但不代表它一定能抓住重点。

信息太多，噪音也多；上下文太长，成本也高；材料不整理，模型可能平均用力；关键内容被埋住，结果反而变差。

这就像你让一个同事帮你做分析。你不能把一整个文件夹扔给他，然后说“你自己看吧，给我结论”。更好的方式，是把和问题相关的内容先筛出来，再让他分析。

除了 Context，还有一个更长期的概念：Memory，记忆。

Context 更像临时工作台。

Memory 更像长期档案。

Context 解决的是“这一次模型能看到什么”。

Memory 解决的是“长期协作中，模型能不能记住你的偏好和项目背景”。

比如你长期让 AI 帮你写公众号文章。

如果没有 Memory，你每次都要重新说：不要 AI 味，不要流水账，不要空泛观点，段落要短，标题要有抓力，逻辑要顺，不要写成百科词条。

但如果 AI 有了 Memory，它就应该逐渐知道你的写作偏好，知道你不喜欢什么，也知道你希望输出的是能直接进入发布流程的内容。

当然，Memory 不是所有 AI 产品都默认具备的能力。它通常取决于产品是否支持长期记忆、项目空间、用户画像或企业知识沉淀机制。

所以，这一层讲的不是“AI 为什么会说话”，而是：

AI为什么能理解当前任务。

先有大模型，AI 才能生成内容；有了上下文，AI 才能接住当前语境；有了记忆，AI 才能在长期协作里不总是从零开始。

AI为什么不能只靠自己瞎答？

很多人一开始用 AI，会有一个误解：

既然它这么聪明，是不是所有问题都能直接问它？

但真实情况是，大模型并不是一个永远准确的事实库。

它能生成看起来合理的内容，但如果没有可靠资料支撑，就可能出现一本正经地胡说。

尤其到了企业场景里，这个问题会被放大。

比如一家企业内部有很多资料：产品手册、销售话术、客户案例、合同模板、售后流程、运营 SOP、历史项目复盘。

如果员工问 AI：

这个客户适合推哪套方案？

AI 如果只靠模型自己回答，很容易给出一些看似正确、实则泛泛的建议。

更合理的方式是：先从企业资料库里找出和这个客户、这个产品、这个场景相关的内容，再把这些资料交给大模型，最后让模型基于资料组织答案。

这就是 RAG。

RAG，全称是 Retrieval-Augmented Generation，一般翻译为检索增强生成。

它解决的是一个很实际的问题：

资料很多时，不要让模型凭空回答，也不要让模型盲读全部资料，而是先检索，再生成。

你可以把 RAG 理解成给大模型配了一个资料检索系统。

用户提问之后，系统先去资料库里找相关内容，再把找到的内容放进上下文，最后让大模型基于这些内容回答。

这样做有几个好处：答案更有依据，不用每次把全部资料都塞给模型，企业资料更新后 AI 能基于新的资料回答，也能降低模型瞎编的概率。

但 RAG 不是万能药。它能降低模型瞎编的概率，但不能保证答案永远正确。检索结果是否准确、资料本身是否过期、模型是否正确理解资料，都会影响最终结果。

RAG 背后还会用到几个相关概念。

比如 Embedding，嵌入向量。

它的作用，是把文本、图片或其他内容转成数字向量，让系统可以计算语义相似度。

再比如 Vector Database，向量数据库。

Embedding 生成之后，需要有地方存储和检索，这个地方就是向量数据库。

很多知识库问答系统，表面上看是 AI 在回答，底层其实是：

文档切分 → 内容向量化 → 向量数据库检索 → 大模型生成答案。

更成熟一点的系统，还会用到 Hybrid Search，混合检索。

只靠语义检索，有时会漏掉精确关键词；只靠关键词检索，又不够理解语义。

比如产品型号、合同编号、客户名称、政策条款，这些内容必须精准命中。但用户提问的表达方式，又可能和原文不完全一致。

所以很多系统会把语义检索和关键词检索结合起来。

还有一个概念叫 Reranker，重排序。

检索系统先找出一批可能相关的内容，但第一批结果不一定排序最好。Reranker 的作用，就是再判断一遍：哪些内容和用户问题最匹配，哪些内容最值得交给大模型。

所以，RAG 真正成熟以后，不是简单“搜一下资料”。

它是一条链路：

切分资料 → 生成向量 → 检索召回 → 混合检索 → 重排序 → 放进上下文 → 大模型生成。

这也是为什么企业级 AI 应用不简单。

不是接一个大模型接口，就能做好知识库。真正难的是：怎么让 AI 找到正确资料，并基于正确资料回答。

这一段和前面的关系也很清楚：

Context 是模型当前的工作台。

RAG 是从资料库里挑出合适的内容，放到这个工作台上。

AI为什么有时候输出不能直接用？

解决了资料问题，下一步还要解决交付问题。

很多人用 AI 时，会遇到一种情况：

AI 回答得好像没错，但就是不能直接用。

它说了一堆话，但没有结构；观点看起来对，但没有字段；内容能看，但进不了表格；结论有了，但系统接不住。

这时候就要回到 Prompt，提示词。

Prompt 本质上不是玄学，而是任务说明。

你让它写文章，是 Prompt；你让它总结会议，是 Prompt；你让它分析数据，是 Prompt；你让它把一段话改得更像人话，也是 Prompt。

Prompt 的关键，不是写得花哨，而是把任务说清楚。

你只说：

帮我分析一下这些用户反馈。

AI 很可能给你一堆泛泛的总结。

但你说：

请基于这些用户反馈，提炼用户最集中的5类需求，并按照“需求描述—代表反馈—背后痛点—产品机会—运营动作”的结构输出。

结果就会稳定很多。

一个好的 Prompt，通常要讲清楚几件事：处理什么材料，站在什么视角，完成什么动作，按照什么结构输出，不要做什么。

但如果是一个 AI 产品，不能只靠用户每次输入 Prompt。

后台还需要有长期规则。

这就是 System Prompt，系统提示词。

User Prompt 是用户这一次提出的问题。

System Prompt 是系统长期设置的角色、规则和边界。

比如一个 AI 合同初筛助手，用户可能只说：

帮我看看这份合同有没有风险。

但系统后台要告诉模型：你不是律师；不要给最终法律意见；只做风险初筛；从付款、交付、违约、知识产权、争议解决几个维度提示；输出语言要克制，不要下绝对结论。

这就是 System Prompt 的价值。

它不是解决某一次任务，而是决定这个 AI 产品长期以什么方式工作。

再往前一步，如果 AI 要进入业务系统，只会输出自然语言还不够。

它最好能按照固定字段、枚举值、标签、分类、分数、状态和下一步动作输出。

这就需要 Structured Outputs，结构化输出。

比如一个销售线索判断工具，它不能只说：

这个客户看起来挺有价值，建议重点跟进。

它最好能输出：

客户阶段：初步意向

线索登记：A

关注点：价格、交付周期

下一步动作：安排顾问沟通

是否需要人工确认：是

这样结果才能进入 CRM、表格、工作流或自动化系统。

所以，Structured Outputs 的价值是：

让 AI 的输出不只是“看起来有道理”，而是能被系统接住。

这一步非常关键。

因为 AI 如果只会说自然语言，它更像一个会写报告的人。但如果它能稳定输出结构化结果，它就可以成为系统的一部分。

这一段解决的是：

AI 怎么从“会回答”，变成“能交付”。

RAG 解决资料从哪里来。

Prompt 解决任务怎么说清楚。

Structured Outputs 解决结果怎么被系统继续使用。

AI怎么从“给建议”变成“能操作”？

到这里，AI 已经能生成内容，能理解上下文，能基于资料回答，也能输出结构化结果。

但它还有一个天然限制：

它本身不能直接感知和操作外部世界。

它不知道你的数据库里有什么；不能自己登录后台；不能自己发送邮件；不能自己修改表格；不能自己查询订单；不能自己在网页上点击按钮。

如果 AI 要完成这些动作，就需要 Tool，工具。

Tool 可以理解成外部能力。

比如查数据库、读文件、生成表格、调用 CRM、查询库存、发送邮件、生成图片、运行代码。

模型负责判断现在需要用哪个工具，真正执行动作的是系统。

这里还有一个更工程化的说法，叫 Function Calling，函数调用。

Tool 是通俗说法。

Function Calling 是工程说法。

模型不是自己去查数据，而是判断：现在需要查数据，应该调用哪个函数，参数是什么，拿到返回结果后怎么解释。

比如你让 AI：

帮我看看这个客户上次沟通是什么时候。

如果没有工具，它只能说“请你查看 CRM”。

但如果它接入了 CRM 工具，它就可以调用对应函数，查询客户记录，再把结果整理成自然语言告诉你。

所以，Tool 的本质是：

让 AI 从“会说”，开始变成“能做”。

但工具多了，又会出现新的问题。

每个平台都有自己的接入方式；每个系统都有自己的接口；同一个工具接入不同 AI 产品，可能要重复适配。

这时候就轮到 MCP 出场。

MCP，全称 Model Context Protocol，模型上下文协议。

你可以把它理解为 AI 连接外部工具和数据源的一套标准化协议。

它不是让模型本身变聪明，而是让模型更容易连接外部数据和工具。

真实落地时，可以简单理解成：

MCP Server 负责把某个系统、数据源或工具能力暴露出来。

MCP Client 负责让 AI 应用以统一方式连接这些能力。

比如企业内部有 CRM、知识库、工单系统、合同系统、财务系统。

过去每个系统都要单独对接不同 AI 工具。有了 MCP 之后，理论上可以用更统一的方式把这些能力暴露给 AI。

所以，MCP 为什么热？

因为 AI 如果一直停留在聊天框里，MCP 没那么重要。但一旦 AI 要进入真实业务系统，连接工具、调用数据、处理任务，统一协议就会变得非常关键。

还有一个更进一步的方向，叫 Computer Use，计算机使用能力。

Tool 更多是调用接口。

但现实里，很多系统并没有开放接口。

很多操作仍然发生在网页、后台、表单、软件界面里。

Computer Use 要解决的，就是让 AI 能看屏幕、识别按钮、填写表单、点击网页，像人一样操作软件界面。

过去 AI 想完成任务，前提是系统开放接口。但如果 AI 能操作界面，它的执行边界就会扩大很多。

比如打开一个网站，查找某个页面，填写一张表单，下载一份文件，把内容复制到另一个系统，完成一个后台操作流程。

当然，这也意味着风险更高。

AI 一旦能操作界面，就不能只考虑“回答是否正确”，还要考虑“动作是否安全”。

所以，工具能力越强，越需要后面的工作流、护栏和人工确认。

这一段是全文最关键的能力跃迁：

AI 从“给建议”，开始变成“能操作”。

AI怎么真正进入工作流？

只会调用工具，还不等于真正进入工作流。

因为真实任务往往不是一步完成的。

你让 AI 做一份竞品分析，它不能只回答一句“建议关注产品、价格和渠道”。

一个真正能办事的 AI，应该会拆步骤：先确定竞品范围，再搜索公开资料，再提取产品功能，再分析定价策略，再对比用户反馈，再整理差异，最后形成报告。

中间可能还要调用搜索工具、网页阅读工具、表格工具、文档生成工具。

这就是 Agent，智能体，Agent 不是更会聊天的机器人，它更像一个围绕目标持续推进任务的执行系统。

普通聊天机器人偏回答，Agent 偏执行。

普通聊天机器人等你一步步说，Agent 会围绕目标拆步骤。

普通聊天机器人给你一个结果，gent 会推进一个流程。

但 Agent 也不是万能的。

它不天然懂你的工作习惯，不知道你的流程标准，也不知道你对输出的偏好。

比如你希望它写周报，它不知道你公司的周报结构；你希望它做用户分析，它不知道你关注哪些指标；你希望它审文章，它不知道你讨厌什么表达；你希望它做销售线索判断，它不知道你的客户分层标准。

如果每次都重新交代一遍，非常低效。

这就需要 Agent Skill。

Agent Skill 可以理解为写给 Agent 的标准作业说明书。

它把某类高频任务的目标、步骤、判断标准、输出格式、注意事项提前写好。之后只要用户触发相关任务，Agent 就按照这套规则执行。

不过，Agent Skill 不是所有 AI 产品都统一采用的标准叫法。你可以先把它理解为“给 Agent 使用的一套可复用任务说明和能力包”。

比如一个“文章审核 Skill”可以写清楚：先判断标题是否有吸引力；再检查开头是否进入主题；再判断段落是否啰嗦；再识别有没有 AI 味；再检查事实风险；最后输出修改建议和重写版本。

一个“运营复盘 Skill”可以写清楚：先看核心数据变化；再找异常点；再拆原因；再判断动作是否有效；最后输出下周建议。

Skill 的价值，不是让 AI 临时发挥，而是让 AI 稳定复用一套方法。

对个人来说，它能沉淀自己的工作习惯。

对企业来说，它能沉淀组织里的流程、经验和判断标准。

但还要再往前看一步。

真正可靠的Agent，不是让AI自由发挥，而是把它放进清晰的Agentic Workflow，智能体工作流里。

这个工作流要回答：任务怎么拆，每一步由谁完成，什么时候调用工具，什么时候需要人确认，失败后怎么回退，结果怎么评估，过程怎么追踪。

比如一套内容审核流程：

AI 可以先读文章，再检查标题、事实、结构、表达，再给出修改建议，再生成一版修改稿；但最终是否发布，必须由人确认。

这就涉及到另一个概念：Human-in-the-loop，人在回路。

AI 可以参与执行，但关键节点要有人确认。

尤其是涉及风险动作时：发邮件、发短信、提交订单、修改数据库、删除文件、发布内容、给客户报价、生成法律或财务判断。

这些动作不应该完全交给 AI 自动完成。

AI 可以分析，可以起草，可以推荐，可以预填，但最终动作要不要发生，应该有人确认。

这不是降低效率。

这是建立责任边界。

同时，AI 进入真实业务以后，还必须有 Guardrails，护栏。

护栏决定哪些输入不该接受，哪些输出不能放行，哪些工具不能调用，哪些动作必须二次确认，哪些结果需要人工审核。

AI 越能执行，越需要护栏。否则它就会从“智能助手”变成“不可控黑箱”。

最后，还需要 Evals 和 Tracing。

Evals 是评测。

它要回答：这个 AI 系统到底靠不靠谱？100 次里能成功多少次？RAG 检索准不准？工具调用稳不稳？结构化输出有没有漏字段？Agent 流程会不会卡住？

Tracing 是链路追踪。

如果一个 Agent 执行复杂任务，最后结果错了，你不能只看到最终答案。你要知道它读了什么资料，调用了什么工具，每一步返回了什么，哪个判断导致后面跑偏，有没有触发护栏，有没有人工确认。

没有 Tracing，Agent 就是黑箱。

有了 Tracing，Agent 才能被调试、被复盘、被优化。

所以，Agent 不是终点。

真正的终点是：

AI 能在明确边界内，进入一个可控、可追踪、可评估的工作流。

结尾：AI热词不是重点，能力递进才是重点

现在回头看这条线，其实很清楚。

LLM 解决的是：AI 为什么能生成内容。

Token 解释的是：AI 处理信息的基本单位。

Context 解决的是：AI 为什么能接住当前语境。

Memory 解决的是：在支持长期记忆或项目沉淀的产品里，AI 如何长期理解用户和项目。

RAG 解决的是：AI 如何基于资料回答，而不是凭空生成。

Prompt 解决的是：任务怎么说明白。

Structured Outputs 解决的是：结果怎么被系统接住。

Tool 解决的是：AI 怎么连接外部能力。

MCP 解决的是：工具和系统怎么统一接入。

Computer Use 解决的是：AI 怎么操作真实软件界面。

Agent 解决的是：AI 怎么围绕目标持续推进任务。

Agent Skill 这类能力包解决的是：经验和流程怎么被复用。

Guardrails、Human-in-the-loop、Evals、Tracing 解决的是：AI 怎么安全、可靠、可控地进入真实业务。

所以，AI 热词越来越多，不是因为行业喜欢造词。

而是因为 AI 的能力边界真的在变化。

它正在从一个聊天窗口，变成一个工作系统。

过去我们关注的是：这个模型会不会写？回答像不像人？生成速度快不快？

接下来更重要的问题会变成：

它能不能理解我的业务资料？

能不能调用我的工具？

能不能遵守我的流程？

能不能拆解复杂任务？

能不能在关键节点让我确认？

能不能被评测、被追踪、被持续优化？

这才是 AI 真正进入生产力阶段的标志。

不是会说得更漂亮。

而是能在正确的边界内，把事情往前推进。