文章目录前言阶段一对话Promot、Context、Memory阶段二简单智能体Agent、RAG、Function Calling、MCP阶段三流程化智能体LangChain、workflow、Skill、subAgentQA1. SKILL 是否可以替代 MCP2. 都有哪些方法可以实现工作流一些思考前言最近这段时间思考了 AI 的真正落地场景研究了这两年 AI 应用的历程可以归纳成三个阶段。第一个阶段是对话阶段以chatgpt、文心一言为代表的以交互式对话的方式进行 AI 落地。第二个阶段是初级智能体阶段在对话的基础上附加本地知识的检索和简单的工具调用让 AI 实现更多形式的任务。第三个阶段是高级智能体阶段这个阶段的代表性 AI 落地产品是OpenClaw将智能体部署到本地或云端开放更多的命令和接口赋予智能体更多的权限。另外附加 SKILL 这样的自定义技能让 AI 在机器上大展拳脚。接下来我们依次看一下各个阶段都有什么样的新技术各种技术如何以软件工程的方式组合在一起。阶段一对话Promot、Context、Memory原始的 LLM 对话中大语言模型只能进行一问一答的形式不能追问。这里的提问被叫做Promot。一个提问Promot中可能包括背景信息和最终的指示于是把背景信息的部分单独取名叫做上下文 Context。现在我们想要对 LLM 进行追问于是我们就将之前的对话历史全部都塞进Context上下文信息中然后再给出我们的问题将两者拼接到一起构成Promot交给 LLM。这样通过伪装多人对话的方式就实现了追问。将上面这种特殊的上下文信息叫做Memory意思是大模型的记忆。这些Memory可以再次调用大模型进行总结对内容进行总结摘要从而对记忆进行压缩减少上下文的长度。阶段二简单智能体Agent、RAG、Function Calling、MCP接下来又遇到了一个问题LLM 只能进行 token 级别的词语拼接只能生成文字无法调用别的工具比如上网查询。如果我们想要 LLM 来根据最新的信息回答问题这就无法实现。而上网查询可以轻松使用 python 代码实现。因此我们需要一段程序这段程序可以根据执行预设的接口来进行工具调用拿到想要的信息作为Context再由 LLM 生成回答返回给用户。这段程序看似就拥有了更高级别的智能被称为智能体 Agent。用户只需要跟智能体对话就可以完成可以工具调用获取跟多信息的智能对话。此时的 Agent 既然可以上网也可以检索本地的文档同样将和用户提问的Promot相关的检索结果作为Context交给 LLM以增强 LLM 生成更加可靠和本地化的回答。这一个过程称为RAGRetrieval-Augmented Generation检索增强生成。接着又有了一个问题智能体 Agent 如何知道 LLM 想要调用什么样的工具呢因为 LLM 的生成结果是自然语言描述很难用固定的代码脚本进行解析就很难知道其想要调用什么样的工具。于是我们制定了一个约定让 LLM 按照指定的死板的格式来描述自己的工具调用请求比如 JSON 格式。这样程序就可以很方便地解析了。这种 Agent 和大模型之间关于工具调用所约定的对话格式就叫做Function Calling。其实就是个约定罢了就像前端和后端请求时的接口格式约定类似。另外还有一点智能体 Agent 如何发现并调用各种各样的工具呢同样需要约定一套规范将工具调用的接口格式给统一化。比如 Agent 执行tools/list方法可以返回工具列表执行toos/call/xxx方法可以调用具体的 xxx 工具。约定了如何调用如何传参如何接收返回值等。这套约定就叫做MCPModel Context Protocol模型上下文协议。此时整个对话的流程就变成了你将提问发送给智能体 Agent。智能体 Agent 把提问与可用的工具名称发给 LLM。LLM 分析问题和可用的工具并以Function Calling约定的格式返回使用哪一个或多个。智能体 Agent 解析出工具通过MCP Server执行工具的执行结果被送回给智能体。智能体结合执行结果构造最终的prompt交给 LLM 生成自然语言的回答返回给你。阶段三流程化智能体LangChain、workflow、Skill、subAgent接下来我们有一个需求从一个英文文件中提取内容翻译成中文最后保存成Markdown格式。当然可以直接将这个需求描述发给 LLM把提取内容和保存的这两个工具也交给 LLM让它自己策划整体的流程。但是这样的每次都让 LLM 自由发挥不但原本简单的流程变得不稳定而且非常浪费 token。完全可以在全局层面通过编程的方式将整个流程固定先提取内容再翻译最后保存。提取内容和保存直接调用脚本执行LLM 只会在中间的翻译步骤被沟通。LangChain这个编程框架就是为了固定这种流程用的。同时也出现了workflow工作流通过可视化拖拽来自定义执行流程。另外如果文件的类型有多个格式保存的格式也可以有多种并且用户以自然语言的形式下发“从一个英文文件中提取内容翻译成中文最后保存成好看的页面格式”指令那么保存的类型不确定就无法直接执行特定的转换脚本了。上面的LangChain和workflow也就不管用了。为了解决这个问题充分发挥 LLM 的灵活性可以从 Agent 的层面出发将不同文件类型的提取文字和保存脚本都放在同一个目录下再写一个SKLL.md文件描述这个目录是在什么任务下使用的按照什么样的流程执行可以按需调用合适的脚本。在提示词中先让 LLM 读取SKLL.md再完成用户的指令。这样既保证了整个过程不需要让 LLM 消耗过多 token 去思考流程让流程可控又保证了一定的灵活性。SKLL.md所在的目录就叫做 Skill即 Agent 的技能。其实是一个渐进式披露、按需加载的Promot。另外又来了一个问题对于一些复杂任务来说比如生成一个大项目那么上下文就会变得非常大于是可以使用多个 Agent每个 Agent 负责其中的一部分子任务。这就是subAgent。本质上是为了做上下文隔离子 Agent 产生的上下文不会保存在主 Agent 中每个 Agent 各司其职把自己的任务处理好。QA1. SKILL 是否可以替代 MCP我觉得是可以的把 MCP 中可以使用的工具统统放在 SKILL 目录下只需要在SILL.md文件中声明什么情况下可以使用即可。2. 都有哪些方法可以实现工作流可以使用LangChainLangGraph、workflow、SKILL这三种方式实现相对固定顺序的工作流。其灵活性也是逐渐提高的LangChainLangGraph将流程中的每个步骤通过编码的方式写死整个过程极度固定。虽然特别稳定但是也失去了一定的柔性很难包容一些小问题。workflow将程序替换成了低代码的拖拽通过交互的方式将流程修改变得简单一些。SKILL则是通过说明文档和执行可运行脚本的方式将由程序控制的流程走向变成了由 Agent 自行控制存在灵活调整的空间同时又不至于像直接调用 LLM 那样不可控。一些思考其实从上面的各个名词发展的历程来看所有的新技术新名词都是围绕着如何去自动向提示词中添加上下文信息去构建一个好的Promot从而让回答的结果更加满足要求。而 Agent 发挥作用的只是在对话流程中能用固定的程序解决、不需要问 LLM 的地方。将模糊的分流逻辑交给大模型根据语义识别出用户意图把确定的分流逻辑由 Agent 交给程序。归根结底只要想让 LLM 回答的满意就必须“把事情说清楚”而“说清楚”的载体就是Prompt。整个 Agent 系统不过是将意图、环境状态、工具转化为 Promot 的 Token 流交给 LLM。参考https://www.bilibili.com/video/BV1ojfDBSEPv/https://zhuanlan.zhihu.com/p/29001189476https://blog.csdn.net/a2875254060/article/details/142468037https://zhuanlan.zhihu.com/p/1919781127339620246https://zhuanlan.zhihu.com/p/2014273572974130629
简述 AI 应用落地的三个阶段
文章目录前言阶段一对话Promot、Context、Memory阶段二简单智能体Agent、RAG、Function Calling、MCP阶段三流程化智能体LangChain、workflow、Skill、subAgentQA1. SKILL 是否可以替代 MCP2. 都有哪些方法可以实现工作流一些思考前言最近这段时间思考了 AI 的真正落地场景研究了这两年 AI 应用的历程可以归纳成三个阶段。第一个阶段是对话阶段以chatgpt、文心一言为代表的以交互式对话的方式进行 AI 落地。第二个阶段是初级智能体阶段在对话的基础上附加本地知识的检索和简单的工具调用让 AI 实现更多形式的任务。第三个阶段是高级智能体阶段这个阶段的代表性 AI 落地产品是OpenClaw将智能体部署到本地或云端开放更多的命令和接口赋予智能体更多的权限。另外附加 SKILL 这样的自定义技能让 AI 在机器上大展拳脚。接下来我们依次看一下各个阶段都有什么样的新技术各种技术如何以软件工程的方式组合在一起。阶段一对话Promot、Context、Memory原始的 LLM 对话中大语言模型只能进行一问一答的形式不能追问。这里的提问被叫做Promot。一个提问Promot中可能包括背景信息和最终的指示于是把背景信息的部分单独取名叫做上下文 Context。现在我们想要对 LLM 进行追问于是我们就将之前的对话历史全部都塞进Context上下文信息中然后再给出我们的问题将两者拼接到一起构成Promot交给 LLM。这样通过伪装多人对话的方式就实现了追问。将上面这种特殊的上下文信息叫做Memory意思是大模型的记忆。这些Memory可以再次调用大模型进行总结对内容进行总结摘要从而对记忆进行压缩减少上下文的长度。阶段二简单智能体Agent、RAG、Function Calling、MCP接下来又遇到了一个问题LLM 只能进行 token 级别的词语拼接只能生成文字无法调用别的工具比如上网查询。如果我们想要 LLM 来根据最新的信息回答问题这就无法实现。而上网查询可以轻松使用 python 代码实现。因此我们需要一段程序这段程序可以根据执行预设的接口来进行工具调用拿到想要的信息作为Context再由 LLM 生成回答返回给用户。这段程序看似就拥有了更高级别的智能被称为智能体 Agent。用户只需要跟智能体对话就可以完成可以工具调用获取跟多信息的智能对话。此时的 Agent 既然可以上网也可以检索本地的文档同样将和用户提问的Promot相关的检索结果作为Context交给 LLM以增强 LLM 生成更加可靠和本地化的回答。这一个过程称为RAGRetrieval-Augmented Generation检索增强生成。接着又有了一个问题智能体 Agent 如何知道 LLM 想要调用什么样的工具呢因为 LLM 的生成结果是自然语言描述很难用固定的代码脚本进行解析就很难知道其想要调用什么样的工具。于是我们制定了一个约定让 LLM 按照指定的死板的格式来描述自己的工具调用请求比如 JSON 格式。这样程序就可以很方便地解析了。这种 Agent 和大模型之间关于工具调用所约定的对话格式就叫做Function Calling。其实就是个约定罢了就像前端和后端请求时的接口格式约定类似。另外还有一点智能体 Agent 如何发现并调用各种各样的工具呢同样需要约定一套规范将工具调用的接口格式给统一化。比如 Agent 执行tools/list方法可以返回工具列表执行toos/call/xxx方法可以调用具体的 xxx 工具。约定了如何调用如何传参如何接收返回值等。这套约定就叫做MCPModel Context Protocol模型上下文协议。此时整个对话的流程就变成了你将提问发送给智能体 Agent。智能体 Agent 把提问与可用的工具名称发给 LLM。LLM 分析问题和可用的工具并以Function Calling约定的格式返回使用哪一个或多个。智能体 Agent 解析出工具通过MCP Server执行工具的执行结果被送回给智能体。智能体结合执行结果构造最终的prompt交给 LLM 生成自然语言的回答返回给你。阶段三流程化智能体LangChain、workflow、Skill、subAgent接下来我们有一个需求从一个英文文件中提取内容翻译成中文最后保存成Markdown格式。当然可以直接将这个需求描述发给 LLM把提取内容和保存的这两个工具也交给 LLM让它自己策划整体的流程。但是这样的每次都让 LLM 自由发挥不但原本简单的流程变得不稳定而且非常浪费 token。完全可以在全局层面通过编程的方式将整个流程固定先提取内容再翻译最后保存。提取内容和保存直接调用脚本执行LLM 只会在中间的翻译步骤被沟通。LangChain这个编程框架就是为了固定这种流程用的。同时也出现了workflow工作流通过可视化拖拽来自定义执行流程。另外如果文件的类型有多个格式保存的格式也可以有多种并且用户以自然语言的形式下发“从一个英文文件中提取内容翻译成中文最后保存成好看的页面格式”指令那么保存的类型不确定就无法直接执行特定的转换脚本了。上面的LangChain和workflow也就不管用了。为了解决这个问题充分发挥 LLM 的灵活性可以从 Agent 的层面出发将不同文件类型的提取文字和保存脚本都放在同一个目录下再写一个SKLL.md文件描述这个目录是在什么任务下使用的按照什么样的流程执行可以按需调用合适的脚本。在提示词中先让 LLM 读取SKLL.md再完成用户的指令。这样既保证了整个过程不需要让 LLM 消耗过多 token 去思考流程让流程可控又保证了一定的灵活性。SKLL.md所在的目录就叫做 Skill即 Agent 的技能。其实是一个渐进式披露、按需加载的Promot。另外又来了一个问题对于一些复杂任务来说比如生成一个大项目那么上下文就会变得非常大于是可以使用多个 Agent每个 Agent 负责其中的一部分子任务。这就是subAgent。本质上是为了做上下文隔离子 Agent 产生的上下文不会保存在主 Agent 中每个 Agent 各司其职把自己的任务处理好。QA1. SKILL 是否可以替代 MCP我觉得是可以的把 MCP 中可以使用的工具统统放在 SKILL 目录下只需要在SILL.md文件中声明什么情况下可以使用即可。2. 都有哪些方法可以实现工作流可以使用LangChainLangGraph、workflow、SKILL这三种方式实现相对固定顺序的工作流。其灵活性也是逐渐提高的LangChainLangGraph将流程中的每个步骤通过编码的方式写死整个过程极度固定。虽然特别稳定但是也失去了一定的柔性很难包容一些小问题。workflow将程序替换成了低代码的拖拽通过交互的方式将流程修改变得简单一些。SKILL则是通过说明文档和执行可运行脚本的方式将由程序控制的流程走向变成了由 Agent 自行控制存在灵活调整的空间同时又不至于像直接调用 LLM 那样不可控。一些思考其实从上面的各个名词发展的历程来看所有的新技术新名词都是围绕着如何去自动向提示词中添加上下文信息去构建一个好的Promot从而让回答的结果更加满足要求。而 Agent 发挥作用的只是在对话流程中能用固定的程序解决、不需要问 LLM 的地方。将模糊的分流逻辑交给大模型根据语义识别出用户意图把确定的分流逻辑由 Agent 交给程序。归根结底只要想让 LLM 回答的满意就必须“把事情说清楚”而“说清楚”的载体就是Prompt。整个 Agent 系统不过是将意图、环境状态、工具转化为 Promot 的 Token 流交给 LLM。参考https://www.bilibili.com/video/BV1ojfDBSEPv/https://zhuanlan.zhihu.com/p/29001189476https://blog.csdn.net/a2875254060/article/details/142468037https://zhuanlan.zhihu.com/p/1919781127339620246https://zhuanlan.zhihu.com/p/2014273572974130629
