AI应用技术 名词篇

今年的 AI 这一波迭代，直接被逼的我这类"躺平不想学习的老年人"爬起来继续学习，没想到 AI 最先革了一大批程序员的饭碗（另一个强势的视频、图片生成处理分支也非常强悍）。。。

最后考虑了一下，感觉还是按时间线的顺序解释比较好，毕竟这些名词的出现也是 AI 发展到某一步自然而然的产物。

而这里首先要说一下，目前的 AI Coding 还是在快速的迭代，这绝对不是最终版本。

无论有多少新的名词，到最后还是要回到一个技术上，就是 LLM 也就是大语言模型，接下来的一切发展都是为了解决 LLM 做不到 xxx 而搞出的中间层，也就是这一切的开始还是 OpenAI 当年发布的那个惊艳的聊天框。

接下来我划分为几个阶段，各个阶段对应出现的新名词大概是：

起步阶段：LLM、Token、Prompt、Context、Memory

发展阶段：Search、Agent（初始形态）、FunctionCalling、MCP、RAG

可用阶段：Agent（增强形态）、LangChain、Workflow、SKILL

成熟阶段：在未来

当下流行的工具：CodeX、ClaudeCode、OpenClaw、Hermes Agent

工具背后技术：上下文管理、提示词工程、模型微调

当然，也不需要太焦虑（卖课的这次估计要赚麻了），不少地方还是有保密要求的，这种强势模型基本还都是闭源，具体使用上还没一些人吹的那么离谱，但如果是自由开发者，那确实要认真考虑下。

在 AI 时代，只要你学的足够慢，你就可以不用学了，今年学习的崭新的热门技术，也许明年甚至几个月后就过时了。

起步阶段

首先这一切的起源还是要从 LLM 说起，当然现在另一种以即梦代表的视频图片生成也非常成熟了，说回 LLM，也就是大语言模型，最开始的 OpenAI 的 ChatGPT 这种 ChatBot，到目前来说依然是这一切的基石。

关于 LLM 大家都很熟了，本质就是根据输入来预测下一个字做词语接龙，最终形成一个句子。

就从这种最原始的 AI 对话来看，LLM 本质是词语接龙，那么在它看来也没有什么对话不对话，只是我们人为的分成了对话的形式；

举个比较好理解但是可能不太恰当的例子，当输入的是：我现在有西红柿和鸡蛋，我可以做什么菜？

这一句输入我们可以人为的拆分成两部分，一个是前提条件或者说上下文信息“我现在有西红柿和鸡蛋”叫做 Context，接下来的“我可以做什么菜？”是为了引出后续我们想要的结果所以可以称之为提示词，叫做 Prompt。

这样最简单的一个 AI 对话就完成了，接下来就是新的问题，如果想基于之前的聊天记录继续问问题，为了让答案更合理，就需要把之前的聊天记录当作上下文 Context 带着喂给 LLM，毕竟 LLM 只是在做词语接龙，没有任何记忆能力。 这些作为上下文的历史聊天记录就叫 Memory 记忆，嗯，又是一个新词；

当聊天记录长到一定程度，每次都带着有点浪费 Token，所以还可以把这些历史记录 Memory 仍给 LLM 让它提炼出核心部分进行压缩，这样就减少了上下文长度。

AI 语义中的 Token 它不是单一的词，可以是字、字母、标点、子词或常用词组的切分片段。

AI 不直接阅读人类文字，而是将文字切分为 Token 并转为数字进行推理计算。

它是模型处理的最小文本单元，1 个英文单词约等于 0.75 个 Token；1 个中文字约等于 0.6-1 个 Token。 例如，英文单词 “apple” 可能是一个 Token，而较长的词可能被拆分为两个。

对于推理来说，太小的字母效率太低，一个单词又显得太粗不灵活，到了中文就更难了，因为没有空格，分词非常主观，例如“南京市/长江大桥” 还是 “南京/市长/江大桥”。

现在是使用折中方案，根据出现频率来切分，高频内容 = 1 个 Token，低频内容 = 多个 Token，它不是固定大小的，而是根据 “理解效率” 动态生成的。

如果想了解具体是怎么拆的，搜索关键词：BPE（字节对编码）

对了，由于汉字的信息密度比较高，LLM 时代，理论上汉字天然就具备省 Token 的特点，但是现在国外那些 LLM 训练用的分词器基本是英文特别优化，实际测试上，汉字只能是特定场景省 token，普遍还是比英文高一些，日文韩文更加离谱；当然如果你用文言文，那除了可能有些歧义，是的确用量只有正常的 30% 左右。

到目前为止，LLM 相关的最常用的名词基本就这些了，下面开始进阶的内容了。

发展阶段

如果 LLM 比作超级大脑，那么有一个硬伤，就是无法做任何操作，无法实现你给它一个指令，它框框把活给你干完，也就是说它无法自主感应到环境和对环境产生影响。

一个最简单的例子，你直接问 LLM 今天的天气、日期、新闻，它都是乱扯，也就是它不具备搜索的能力，想要 LLM 具有搜索能力，实现上你肯定不能在 LLM 核心本身打算盘，它就是单纯的一个词语接龙；

那如果当需要搜索的时候，我们替他搜索，然后把整个搜到的结果当作上下文传给 LLM，之后让它总结不久行了？

但是这样我们也太麻烦了，那么把固定的搜索动作用程序实现，对话的时候自动执行，是不是就可以回归到对话本身了？ 通过这个自动化的程序实现搜索，相当于让 LLM 拥有了“动手能力”，能够操纵工具的能力。

接下来就以这个示例，来解释涉及的相关名词。

FunctionCalling

在具体的 AI 应用程序实现上，还会有一个问题，以上文的搜索来说，这个程序如何知道需不需要搜索，应该搜索什么？

所以就需要加入一段 Prompt，规定 LLM 返回是什么格式，比如用 Json，什么字段表示什么含义，这样程序才能精准的理解 LLM 的意图，这个概念再起个名字，就叫 FunctionCalling 吧，类似开发过程中前端和后端约定的接口定义。

OpenAI 开发文档中有一篇详细介绍了 FunctionCalling

最后对 FunctionCalling 做个总结：

它处于 AI 应用客户端和 LLM 之间，客户端把一组函数定义直接塞给模型，模型自己从里面选择合适的时机执行（其实是输出意图，例如调用哪一个函数传什么参数，实际执行的还是 AI 应用程序，因为 LLM 没有执行动作的能力)，避免了 LLM 瞎编；

它通常是单个平台的内部机制，每个 AI 应用程序都可能有自己独特的 FunctionCalling 定义。

简单说就是客户端和模型之间约定的一种工具调用表达方式；

MCP

在具体到实际的业务中，都会有一些通用工具，例如你 A、B 两个项目都需要查数据库，没必要在 A 和 B 都维护一套 FunctionCalling 逻辑，如果把这些通用的功能封装到一起那确实不错，并且可以对外进行开放，这个其实就是 MCP，最开始由 Anthropic 提出来的。

简单理解就是把一些通用或者个性化的功能提取出来，就是一个 MCP 服务器，提供给 AI 应用程序（或者说任何“会调工具的模型客户端”）调用。

MCP （Model Context Protocol）说白了就是一个工具调用协议，规定如何交流，至于这个客户端和 MCP 之间如何交流，可以是 HTTP、WebSocket、进程之间的消息传递、本地脚本等等。

MCP 处于 AI 应用客户端与外部工具之间，把“工具/资源怎么以标准的形式暴露给 AI 应用客户端”这件事做成统一协议，例如通过指定消息约定获取 MCP 有哪些可以执行的工具、怎么执行、怎么返回。

MCP 和 FunctionCalling 区别

其实可以看出，MCP 和 FunctionCalling 不是在一个层级上的，

Function Calling 中的工具可以拿到 MCP 中，那么流程就是 LLM 使用 Function Calling 来传递需要由客户端调用某个 MCP 里的工具，客户端再按照 MCP 定义调用 LLM 决定调用的工具，最后把结果给 LLM；

从 LLM 的视角看，这就是一个 Function Calling，MCP 对 LLM 来说通常是“不可见的”，LLM 看到的只是“有一组工具可用，我现在要调用其中一个”

Agent 智能体

最开始所说的那个 AI 应用程序看着挺智能的，可以主动执行/调用一些脚本工具，就叫智能体 Agent 吧；

而这种可以联网搜索的对话是非常普遍的一个需求，所以再起个名字叫 Web Search 吧（后面干脆就叫 Search，不光能搜索网页，看着更厉害）。

最开始的智能体 Agent 可能只是在你发送的消息上加了一些 Prompt 而已，有点噱头的感觉；但现在的一些 Agent 才是真正的有点智能的感觉了，除了搜索，一些比较确定性的操作都是非常适合集成到智能体中，例如查找本地文件、查找数据库中的内容等。

OK，到现在，通过注入的特定 Prompt（FunctionCalling / MCP）解决了 LLM 大脑和 Agent 之间的交流不规范的问题，并且还让 LLM 间接具备了调用工具的能力，例如文件读取、执行命令、搜索等等。

RAG

对于搜索能力，如果展开来说说，在将用户输入的提示词发送给 LLM 之前，先进行切分然后去向量数据库查询，也就是可以把语义相近的片段查出来的数据库；

然后把查询的结果加入到上下文，以达到增强生成内容的可靠性（减少幻觉）和相关性，这种模式又被人称为：检索增强生成 Retrieval-Augmented-Generation（RAG），当时还火过一阵子，有的中转站还用这种技术来偷懒省 Token。

原理看着简单，就是字面意思的检索相关语料-增强上下文-再生成，但是实际想把它用好就不是那么容易的一件事了，每一个步骤都有对应的难题，尤其是对于多模态的数据来说。

可用阶段

到现在这个阶段，再看 Agent 它的形式可以多种多样，目前比较多的还是编程方向，比如 CLI 形式的 CodeX、ClaudeCode；IDE 形式的 Trae、Cursor 等；当然也有桌面助手形式的通用型 Agent：OpenClaw。

即使现在的这些 Agent 已经看着足够智能，但是距离 AGI 还是有些差距。

一个真正的智能体，应该要起码像一个实习生，当拿到一份任务的时候，首先要有计划，然后结合自己手上的工具资源，去完成这个任务，也就是以结果为导向。 在这个过程中，可能会遇到各种问题，环境配置错误跑不通、程序出错各种各样的问题，但是作为一个实习生，起码会先看看是什么错误，然后根据错误信息进行下一步处理，之后再次进行尝试验证，最终得到一个可以正常跑通的流程。

所谓智能体，本质其实是循环的三件事，思考-行动-观察 即 Agent Loop：

1. 收集信息发给 LLM，LLM 经过思考给出规划与下一步要做什么
2. 解析 LLM 的返回，按照返回的意图执行对应的命令
3. 观察执行结果，并且收集数据。
4. 将执行的结果再次发给 LLM，思考下一步要做什么，相当于重复第一步
5. …

假设有一个文件的代码存在问题，你询问编程智能体这个错误的原因； Agent 不会解析你的提示词，只负责转发，所以第一步会直接发给 LLM，当然这里会带着预置的 Prompt （类似“你是一个编程专家，你需要解决用户的编码问题，你可以使用 xx 工具….”）。

第二步，LLM 经过思考后按照 Prompt 中规定的格式（FunctionCalling），把下一步骤要做什么返回，例如首先 LLM 需要读取文件看一下代码，这时候 Agent 就按照返回的指令执行读取文件。

第三步，将执行结果和历史记录一起发送给 LLM，这时候 LLM 再根据观察到的执行结果继续思考，可能返回让 Agent 继续读取相关文件来收集信息，直到最后 LLM 收集到足够的信息判断问题所在。

MultiAgent

在 Agent 处理一些复杂任务时，因为上下文有限的问题，可能会拆分为多个 Agent，例如一个专门读代码，一个专门写代码，一个负责验收等等，有的会按现实中角色进行划分子 Agent。

但是这种处理方式很难说是最佳实践，Claude 发布的一篇文章有提到过，多 Agent 架构未必比单 Agent 要更好；

有的时候优化提示词和工具描述，可能带来的效果要更好。

适合多 Agent 的情况：

1. 存在上下文爆炸/上下文污染，也就是太多的上下文会分散精力，导致 LLM 智力下降，可以通过多 Agent 来隔离上下文。
2. 任务可以并行运行，可以通过多 Agent 来提速。
3. 拆分子 Agent 可以改善决策效果，或者可以让任务更加聚焦时

说回上面的写代码的示例，如果拆分多个 Agent，例如最经典的开发、测试，大量的 Token 可能都浪费在互相解释上，也就是我们所说的团队合作，在“对齐颗粒度”这个事情上花的精力要比实际工作要多得多，相信大家都深有体会。

正确的方式应该是按照上下文边界进行划分，谁负责哪一块就负责到底。

只有当任务需要的上下文、背景信息不同时，再考虑进行拆分。

LLM 注意力最集中的是最前面的系统提示词和最后的提示词描述部分，中间的上下文注意力是被稀释的，所以有时候适当的重复也是一个办法，但 LLM 本身就是需要在每一个 token 之间寻找关系，上下文越长注意力注定是越分散的。

Skill

通过上面的内容，我们知道需要做好上下文的管理，非必要不要添加太多的上下文，又因为 LLM 没有记忆，所以 Agent 和 LLM 交流时，每次都需要携带一堆的可调用工具、FunctionCalling 定义上下文，于是我们想，能不能把这些功能拆出来，按需加载，让 Agent 瘦身？

当然拆出来也需要按照一个规范来，例如 tools/ 文件夹下就放每一个工具的具体描述，初始阶段只把这些支持的工具简单的描述发给 LLM，让 LLM 判断是否需要，如果需要再把完整的内容加载到上下文中（渐进式披露），这基本就是 Skill 的运行逻辑了。

给 Skill 一个定义的话：把某一类任务的做法，打包成一份可复用的“操作说明 + 工具流程”（可以包括 Prompt、工具脚本、知识文件等）。

这有点像是可以打包分发的 Agent，举例来说可以是：做代码审查的 skill、操作浏览器的 skill、处理 PDF 的 skill。

模型本身可能“知道大概怎么做”，但 skill 会告诉它：

遇到这类任务时，应该按什么步骤做，用什么工具，注意什么格式，结果怎么交付，有点像做一类任务的菜谱，只要严格按菜谱做，就能获得一个相对稳定的结果。

没有 skill 的时候，模型处理任务经常靠临场发挥。有时候很顺利，有时候磕磕绊绊，每次使用的处理方式可能也不同，而有了 skill，相当于提前让 LLM 知道了一种高效的处理方式，这样结果更稳定。

这有点像让经验沉淀下来，实现稳定、可复用、可迁移的任务流程。

与 Function Calling、MCP 的区别：

• Function Calling 偏“单个动作”（即模型怎么表达“我要调用这个工具”），Skill 偏“一套任务方法”；
• MCP 告诉 LLM 有哪些外部能力可以用（工具怎么标准化接入客户端），Skill 是遇到某类任务时，应该怎么用这些能力
• Skill 代表着某类任务应该如何被稳定完成

具体一个 Skill 是什么格式什么规范可以参考这篇：Agent Skills Overview，大概可理解一个 Skill 就是一个文件夹：

my-skill/
├── SKILL.md          # Required: metadata + instructions
├── scripts/          # Optional: executable code
├── references/       # Optional: documentation
├── assets/           # Optional: templates, resources
└── ...               # Any additional files or directories

一个 Skill 的运作基本可以分为：发现、激活、运行。

Tools 和 Plugins

在一些 AI 应用 GUI 中，可能还存在工具 Tools、插件 Plugins 的概念，其实就是一种细化，大体可以理解 Tools 就是能被调用的具体能力（读文件，执行命令等）；Plugin 是给整个应用扩展功能的安装包/扩展模块。

MCP 是把 tool 暴露出来的一种协议，一个 MCP server 下面往往挂着很多 tools。

Skill 更像“会怎么用 tool 的经验包”。tool 可以理解为等于单个动作，而 skill 相当于一套动作组合与规则。

插件这个词在不同产品里定义差异最大，但大体可以理解成给整个 AI 应用增加新功能的一种扩展包。

例如可以是一组 tools、一个新的 UI 面板、特定任务的完整工作流。

他们的层级是逐渐递增的：

Tools：

面向“执行层”

解决的是：现在到底能做什么动作

最小能力单元。

真正被调用的动作。

例如一个 Agent 会内置一些 Tools：比如文件读写、网页浏览、终端执行。

MCP：

面向“接入层”

解决的是：这些动作怎么从外部服务接进来

把外部 tools 标准化接入进来。

Skill：

面向“方法层”

解决的是：某类任务应该怎么稳定完成

告诉模型在某个任务里该怎么组合 tools。

Plugin：

面向“扩展层 / 产品层”

解决的是：怎么给整个应用安装一块新能力

把 tools、skills、配置、UI、鉴权等打包成应用扩展。

LangChain 与 Workflow

接下来以一个具体示例来说，做一个 PDF 翻译的功能，这个步骤可以拆解为：提取 PDF 的文本，让 LLM 进行翻译，对翻译后的文本导出成 PDF。

根据我们的提示词，LLM 经过思考，达到这个目标它可能首先要写一个脚本程序把 PDF 的文字提取出来，第二步是翻译，最后写一个导出 PDF 的脚本，然后执行；

在这段流程中，提取 PDF 文字和导出 PDF 是固定的程序，不需要任何变化，唯一需要的就是中间的翻译，每次让 LLM 先生成脚本再执行即增加了不确定性，也浪费 Token，那么如果我们把这些固化的脚本提前生成好内置进去，然后只编排一下顺序流程是不是会更好，这就是 LangChain。

至此，我们打造的这个小程序可以称作是一个 Agent，所以 LangChain 可以理解为一个用来开发 LLM 应用的编程框架。 表面上这只是一个程序和 LLM 进行对话，实际上你需要处理一堆的问题，例如 prompt、做 RAG 检索、存 memory、处理输出格式、做错误重试；

这些流程非常琐碎，并且基本每个 Agent 都需要做这些处理，LangChain 就是把这些常用模块封装起来；它主要是解决：怎么把 LLM 和外部能力组合成一个应用；即它是开发 LLM 应用的胶水层 / 编排层框架。

大多数场景下，任务都是像流水线一样，不是一步完成，而是按固定流程走，该先干嘛、后干嘛，大体固定（区别与通常所说的 Agent 一般是自主规划），这种结构我们可以称作是 Workflow 工作流。

可以看出 LangChain 里可以实现 Workflow。

对于一些普通用户，未必有这种编程思维，所以又有人使用低代码的方式实现了一个 Web 可视化页面，只需要鼠标拖动几下就能设计完成，这就是 LangGraph。

Workflow 的出现还是因为纯 Agent 太飘了，成本、耗时、达成率都非常不稳定，而它的出现就是别让模型每一步都自由发挥，该固定的固定，该判断的再让它判断。

到这里，感觉和 Skill 有点相似，都是通过 LLM 来达成某件事情，只不过它们在形态上有明显的区别：

LangChain 是代码里控制步骤，Skill 更像是把这套流程总结成一个说明书，让 LLM 能尽量的自主下达命令执行，达到 LangChain 编程的效果。

如果从稳定 –> 灵活的方向考虑，那么顺序就应该是： LangChain、workflow、SKILL、Agent。

以 AI 目前的发展，这些都是中间产物，未来如果做到面向普通人，就是越简单越好，别管什么性能

OpenClaw 和 Hermes Agent

OpenClaw 在我看来就是一个可以控制电脑的通用 Agent，技术上来说并没有什么突破性的创新，只不过因为它可以通过微信、Telegram、飞书这种即时通讯工具和我们交流，让你有一种给员工发号施令的感觉，并且它确实是可以操作你的电脑帮你完成一些任务。

现在 OpenClaw 已经降温了，目前版本也被指出上下文管理烂，大部分纯 AI 编写，存在很多安全问题，更有网友用 10% 的代码量实现了 OpenClaw 的核心功能。

不过 OpenClaw 的生态已经起来，后续的发展还是有待观察，但是如果你要尝试的话，OpenClaw 依然是第一选择，不过要尤其注意升级容易死。

当下 Hermes Agent 反而开始火爆，有当初 OpenClaw 的势头，并且它的功能和 OpenClaw 基本类似，区别反而主要是对 OpenClaw 一些问题的优化。

Hermes Agent 给出的口号是与你一同成长的 Agent，最大的特点就是会自进化，也就是越用越懂你。

1. 技能自主创建：

   完成你的任务后，Agent 会自己判断一下这个流程是否值得沉淀（一般来说，复杂任务更容易被沉淀为 Skill，例如涉及 5 次以上工具调用的复杂任务）。

   如果它认为需要，就会自己把整个执行过程沉淀为 Skill，下次遇到类似任务直接调用。

2. 技能自主迭代：

   在后续使用中，如果 Agent 发现更优解法，会自动更新 Skill。

   Hermes Agent 的技能创建/更新默认不需要人工确认，这种设计的好处是体验流畅、真正做到无感成长，但还是建议人工定期的去 review。

这里讲一个看到的故事，有安全团队发现了在跑的 Hermes Agent 的一个漏洞，可以稳定复现，当准备去进行的时候，发现 Hermes Agent 发现了有人通过这个漏洞在进行攻击，并且自己进行修复了，这个的意义就不一样了，发现的漏洞已经不重要了，这让 Hermes Agent 达到了不一样的高度。

但是又说回来，Hermes Agent 远没有宣传的那么 NB，营销属性比较多，用起来一点都不智能远远不如 OpenClaw，所谓的自主迭代实现也很粗糙，远远达不到宣传的效果，并且 OpenClaw 通过 EvoMap 也可以实现，并且还陷入了抄袭风波。

不论是 Hermes Agent 还是 OpenClaw，现在还是都没解决记忆管理和上下文管理的问题，大概率还是会出现越用越笨。

最后提醒下，在使用这一类 Agent 时，因为权限足够大，在配置各类 Skill 时需要谨慎，谨防下载到恶意的 Skill 和提示词注入漏洞。

这俩货展开都是一大堆的细节，这个后面单开说，现在这篇只是个大概解释。

其他

提示词工程是个很复杂的东西，并不仅仅是语言的艺术，详细的解释可以参考这篇《提示工程学习笔记》文章，好的提示词确实是可以极大的提高输出质量提高效率，提示词的缓存也是一门复杂的学问。

一些比较有用的例如：给几个答案示例就能有效约束大模型的输出格式，并且提高输出质量。

模型微调在去年还有一些团队在做，尤其是一些垂直领域，LoRA 算法可以让训练量不那么大也能进行微调，大幅降低了成本。

但是有个尴尬的问题，目前基座大模型的迭代速度太快了，大多数时候是当你拿着 v1 版本微调了半年或者几个月，他们出了 v2 版本直接在你微调的细分领域干掉了你，基本就是等于白干了。

相比之下，用 RAG 反而成了一种比较低成本的平替。

上下文工程

上下文管理是非常重要的一个东西，所以这里单独拿出来，这个很大程度上决定了 Agent 的效果，因为对于 LLM 来说，并不是上下文越多越好，和人一样，太多的上下文会分散精力，所以 SKILL 或者说工具，也不是越多越好

HarnessEngineering

翻译过来叫驾驭工程，强调通过构建受控环境，让 Agent 在约束下高效可靠地完成长周期复杂任务。

包含围绕 Agent 构建约束机制、反馈回路、可靠上下文等等一系列工程实践。

简单理解就是 AI 帮我们干活不能让它乱干，要有一个验收的机制，尤其是在需求不明确不具体的情况下，AI 很容易就和你的理解有偏差，最后还自信满满的给你说一句干完了，整个过程很不稳定。

Harness 下相当于给它定了一套制度，例如：

1. 先拆需求
2. 每阶段只做一小块
3. 每块有明确验收标准
4. 做完必须测试
5. 不通过就返工
6. 全过程有记录

当你给了 Agent 足够高的权限，很容易让它把系统或者环境给搞崩，这时候 Harness 也是为了尽量约束，最后的结果通过验收环境来决定而不是 AI 执行过程中的“感觉”。

一个算得上智能的 Agent，Harness 是必须的。

参考：

https://oigi8odzc5w.feishu.cn/wiki/WBMfwiNkfi6uNFkRtXdcavDzn0e

https://oigi8odzc5w.feishu.cn/wiki/NtOrwxnyWirN3ykWSoncFRr5nGc

https://space.bilibili.com/341376543/upload/video