WEBVTT

00:00:00.000 --> 00:00:04.720
那么紧接着我们就来看看,Response API到底应该如何上手来进行使用。

00:00:04.720 --> 00:00:14.000
这个其实是我们现在在去做开发的过程当中,可能都需要会涉及到一些底层的通信格式的讲解。

00:00:14.000 --> 00:00:18.560
当然如果是去年的话,这部分内容应该是非常核心,非常重要的一部分的内容。

00:00:18.720 --> 00:00:27.240
还有底层的开发范式,对不对?OpenAI的Response API,还有之前的ChatComplations API,这都是我们将用大模型的基础。

00:00:27.240 --> 00:00:30.080
到现在在webcoding时代

00:00:30.080 --> 00:00:30.900
这些很多功能

00:00:30.900 --> 00:00:32.200
我们其实都可以让大模型

00:00:32.200 --> 00:00:32.820
帮我们完成

00:00:32.820 --> 00:00:34.520
所以像这部分内容

00:00:34.520 --> 00:00:35.560
仍然是很重要

00:00:35.560 --> 00:00:37.120
但是我们可能就不需要

00:00:37.120 --> 00:00:39.140
去特别深入的吸引到

00:00:39.140 --> 00:00:39.920
每一行代码

00:00:39.920 --> 00:00:40.700
每一个参数

00:00:40.700 --> 00:00:41.820
分别代表什么样的含义

00:00:41.820 --> 00:00:43.040
这个程度来进行理解

00:00:43.040 --> 00:00:43.900
你只需要知道是

00:00:43.900 --> 00:00:45.120
它是干什么的

00:00:45.120 --> 00:00:46.020
有什么用

00:00:46.020 --> 00:00:47.760
以及你能怎么用

00:00:47.760 --> 00:00:49.340
这个东西其实是最重要的

00:00:49.340 --> 00:00:50.760
那么我们接下来就来看看

00:00:50.760 --> 00:00:53.200
OpenAI的Responses API

00:00:53.200 --> 00:00:54.200
到底是什么

00:00:54.200 --> 00:00:56.480
当然这里大家如果不太了解

00:00:56.480 --> 00:00:58.220
这个Response API到底是什么的话

00:00:58.220 --> 00:01:00.940
你可以把它想象成就是OpenAI版的LongChain

00:01:00.940 --> 00:01:04.140
专门负责给我们开发者一个接口

00:01:04.140 --> 00:01:06.820
去更好的去调用这样的一些大模型

00:01:06.820 --> 00:01:10.100
然后把它们和一些工具给它绑在一块

00:01:10.100 --> 00:01:11.620
最后做成一个Agent

00:01:11.620 --> 00:01:12.840
就是这样的一个API

00:01:12.840 --> 00:01:14.140
可以这么来进行理解

00:01:14.140 --> 00:01:16.120
当然其实这个Response API

00:01:16.120 --> 00:01:17.580
是去年3月11号

00:01:17.580 --> 00:01:22.440
OpenAI正式开源的一个全新的一种大模型调度的一种方法

00:01:22.440 --> 00:01:25.240
然后官网在OpenAI官网上也有非常详细的

00:01:25.240 --> 00:01:28.500
关于使用这个Response API的一些好处啊

00:01:28.500 --> 00:01:32.300
和怎么去进行迁移呀的一些这个方法啊

00:01:32.300 --> 00:01:33.780
当然这里我们要说明的是

00:01:33.780 --> 00:01:36.980
其实每一家啊大保险厂商都有资格的啊

00:01:36.980 --> 00:01:38.700
这个API的调度的这个范式

00:01:38.700 --> 00:01:40.560
比如说对于这个

00:01:40.560 --> 00:01:42.880
Anthelope来说啊

00:01:42.880 --> 00:01:45.460
他们呢自己有一套Anthelope API啊

00:01:45.460 --> 00:01:47.680
还有一套Cloud Agents SDK啊

00:01:47.680 --> 00:01:49.360
那么对于OpenAI来说呢

00:01:49.360 --> 00:01:51.480
他们家啊有这个Response API啊

00:01:51.480 --> 00:01:53.880
和Agent SDK啊两套开发框架啊

00:01:53.880 --> 00:02:00.700
这个其实每一家他们都会有推出一些适配自己家模型的一些agent通信和开发范式

00:02:00.700 --> 00:02:01.600
是这么一回事

00:02:01.600 --> 00:02:03.240
那么对于openAI来说

00:02:03.240 --> 00:02:10.640
他们其实当然这个responses API就是现在他们来进行模型调度的过程当中最核心的响应的这样的方法

00:02:10.640 --> 00:02:13.280
然后对于这个deep seek来说

00:02:13.280 --> 00:02:17.000
他现在是接入到了responses API这功能体系里面来

00:02:17.000 --> 00:02:19.760
当然这里其实有一个很有意思的一个点

00:02:19.760 --> 00:02:22.380
就在于说其实之前有同学会问到说

00:02:22.380 --> 00:02:27.280
Deepseek他们是怎么去考虑去接入OpenAI的Response API的呢

00:02:27.280 --> 00:02:28.640
当然我们说对Deepseek来说

00:02:28.640 --> 00:02:30.840
他一旦接入OpenAI这个Response API之后

00:02:30.840 --> 00:02:33.780
他实际上就可以无缝的接入Codex的体系了

00:02:33.780 --> 00:02:35.060
那他是怎么接入的呢

00:02:35.060 --> 00:02:35.680
其实非常简单

00:02:35.680 --> 00:02:36.940
就是在后训练的过程当中

00:02:36.940 --> 00:02:40.960
给了他很多的一些指令方面的训练集

00:02:40.960 --> 00:02:45.860
让他的响应格式能够和Response API的响应格式来进行兼容

00:02:45.860 --> 00:02:48.720
这里其实就会说的会比较底层了

00:02:48.720 --> 00:02:49.760
因为其实大家知道

00:02:49.760 --> 00:02:51.580
对于任何大模型来说

00:02:51.580 --> 00:02:53.760
它原始的这个输出这个内容

00:02:53.760 --> 00:02:55.680
实际上就是一个又一个token

00:02:55.680 --> 00:02:57.440
或者一个又一个字符

00:02:57.440 --> 00:02:59.940
这个字符里面内容其实会非常非常多

00:02:59.940 --> 00:03:01.680
然后大模型输出的

00:03:01.680 --> 00:03:03.820
实际上是一段非常非常长的这个字符

00:03:03.820 --> 00:03:05.120
那么我们每次呢

00:03:05.120 --> 00:03:08.280
在去进行大模型的这个聊天的过程当中

00:03:08.280 --> 00:03:10.860
实际上后台是需要把很长的这段字符

00:03:10.860 --> 00:03:13.060
来进行各式各样的格式解析的

00:03:13.060 --> 00:03:14.200
这段是什么

00:03:14.200 --> 00:03:15.180
那段是什么

00:03:15.180 --> 00:03:16.300
那么有一些呢

00:03:16.300 --> 00:03:19.180
他输出这个结果是给用户去看的

00:03:19.180 --> 00:03:20.820
原来某一段话的回复

00:03:20.820 --> 00:03:22.360
那么也有一些输出这个结果

00:03:22.360 --> 00:03:24.740
可能是比如说工具调用信息

00:03:24.740 --> 00:03:27.780
他自己运行当中的一些状态信息等等等等

00:03:27.780 --> 00:03:29.680
总之是有很长很长这段信息

00:03:29.680 --> 00:03:32.700
那么这个信息是以什么样的格式来进行输出

00:03:32.700 --> 00:03:34.580
他就可以被什么样的格式来进行解析

00:03:34.580 --> 00:03:35.480
你可以这么来经理解

00:03:35.480 --> 00:03:37.820
那只不过现在对于DeepseekV4

00:03:37.820 --> 00:03:39.300
整个正式版的模型来说

00:03:39.300 --> 00:03:43.960
他们选择了是以Responsees API这样的一个形式来进行输出

00:03:43.960 --> 00:03:46.640
所以他们就可以被Response API来进行解析

00:03:46.640 --> 00:03:48.080
所以他就跟他兼容了

00:03:48.080 --> 00:03:49.980
这么来进行理解就可以了

00:03:49.980 --> 00:03:50.600
是这么一回事

00:03:50.600 --> 00:03:53.360
是他在训练过程当中进行的非常深度的设置

00:03:53.360 --> 00:03:54.440
OK好

00:03:54.440 --> 00:03:57.020
那么问题是Response API它是什么东西

00:03:57.020 --> 00:03:57.680
对不对

00:03:57.680 --> 00:04:01.440
它怎么样来进行的解析

00:04:01.440 --> 00:04:05.180
那么非常完整的一次Response API的调用

00:04:05.180 --> 00:04:07.420
大家可以看这段代码

00:04:07.420 --> 00:04:10.040
那么这个代码实际上就是一次非常完整的

00:04:10.040 --> 00:04:10.840
非常底层的

00:04:10.840 --> 00:04:11.760
我们使用Python

00:04:11.760 --> 00:04:12.700
当然你使用这个

00:04:12.700 --> 00:04:14.420
使用这个TS

00:04:14.420 --> 00:04:16.000
其实也是类似的

00:04:16.000 --> 00:04:17.100
这样的语法规则

00:04:17.100 --> 00:04:19.460
来去完成一次通过Response API

00:04:19.460 --> 00:04:20.660
调用底层模型的

00:04:20.660 --> 00:04:22.480
一整个完整的这样的一个流程

00:04:22.480 --> 00:04:23.460
那它是什么样的呢

00:04:23.460 --> 00:04:24.640
首先我们需要

00:04:24.640 --> 00:04:27.580
这个import OpenAI

00:04:27.580 --> 00:04:28.580
就导入这样的库

00:04:28.580 --> 00:04:30.340
然后导入这个库之后

00:04:30.340 --> 00:04:31.500
接下来我们需要实力化

00:04:31.500 --> 00:04:32.680
一个OpenAI的客户端

00:04:32.680 --> 00:04:34.680
然后在OpenAI客户端里面

00:04:34.680 --> 00:04:36.060
输入你的Deepseek API key

00:04:36.060 --> 00:04:37.880
和Deepseek的这个base URL

00:04:37.880 --> 00:04:39.380
这个base URL是定死的

00:04:39.380 --> 00:04:40.600
然后这个Deepseek API key

00:04:40.600 --> 00:04:41.800
你需要自己去注册一个

00:04:41.800 --> 00:04:45.160
那么这里就实力化了一个open AI的这样的客户端

00:04:45.160 --> 00:04:46.900
然后有了这个客户端

00:04:46.900 --> 00:04:49.300
或者你可以把它理解成是一个负了值的

00:04:49.300 --> 00:04:52.620
一个open AI对象的一个实力化的一个对象

00:04:52.620 --> 00:04:53.260
就这么一回事

00:04:53.260 --> 00:04:59.140
然后接下来就可以调用client.response.create这样的一个命令

00:04:59.140 --> 00:05:03.800
就可以去获得一次对应的模型回复的这样的响应结果

00:05:03.800 --> 00:05:06.440
这里我们输入modal等于deep seek v4 flash

00:05:06.440 --> 00:05:09.220
然后这个instructor代表的含义

00:05:09.220 --> 00:05:10.860
实际上就是system prompt

00:05:10.860 --> 00:05:11.880
你可以这么来自己理解

00:05:11.880 --> 00:05:15.100
就是我们整个的agent运行的方式当中

00:05:15.100 --> 00:05:15.960
system prompt

00:05:15.960 --> 00:05:17.500
然后有一个input

00:05:17.500 --> 00:05:18.500
input代表的含义就是

00:05:18.500 --> 00:05:20.380
我现在跟他来进行的对话

00:05:20.380 --> 00:05:20.740
对不对

00:05:20.740 --> 00:05:22.820
然后下面还有其他的参数

00:05:22.820 --> 00:05:24.220
这下我们可以都不管

00:05:24.220 --> 00:05:25.820
然后通过这样的方式

00:05:25.820 --> 00:05:27.860
就可以完成一次模型的调用

00:05:27.860 --> 00:05:29.240
当然我这里给大家举的例子

00:05:29.240 --> 00:05:31.340
都是生成的英文的提出词

00:05:31.340 --> 00:05:32.680
但用中文也是一样的

00:05:32.680 --> 00:05:33.380
没有任何影响

00:05:33.380 --> 00:05:36.100
总之就可以完成一次对应的响应

00:05:36.100 --> 00:05:38.340
比如说我们这就可以让他来进行运行

00:05:38.340 --> 00:05:40.440
我这个是在线的这个环境

00:05:40.440 --> 00:05:41.540
就可以直接来进行运行

00:05:41.540 --> 00:05:42.440
也是一样对不对

00:05:42.440 --> 00:05:44.400
这个Response API

00:05:44.400 --> 00:05:46.700
先做好一个Client

00:05:46.700 --> 00:05:48.120
然后这Client

00:05:48.120 --> 00:05:49.960
然后接下来就可以跟他来进对话了

00:05:49.960 --> 00:05:50.720
就这么一回事

00:05:50.720 --> 00:05:52.200
那么这个Client

00:05:52.200 --> 00:05:55.080
实际上我们现在所说的这个Response API

00:05:55.080 --> 00:05:57.300
实际上就是这Client里面的一个方法

00:05:57.300 --> 00:06:01.320
通过他能够去获取一次又一次模型的响应结果

00:06:01.320 --> 00:06:02.900
是什么样的一个情况

00:06:02.900 --> 00:06:04.420
好

00:06:04.420 --> 00:06:07.880
那么对于我们当前的这个Response API来说

00:06:07.880 --> 00:06:10.180
其实它返回的这个结果里面

00:06:10.180 --> 00:06:11.700
包含的消息会非常多

00:06:11.700 --> 00:06:12.720
它会包含你的

00:06:12.720 --> 00:06:13.900
比如说Reasoning Item

00:06:13.900 --> 00:06:15.680
推理的字段的内容

00:06:15.680 --> 00:06:17.280
会包含这个Message的内容

00:06:17.280 --> 00:06:18.620
会包含这个Function Call

00:06:18.620 --> 00:06:19.840
就是你工具调用这个内容

00:06:19.840 --> 00:06:20.360
等等等等

00:06:20.360 --> 00:06:21.460
价格式各样这个内容

00:06:21.460 --> 00:06:23.620
然后这个Message里面还会包含

00:06:23.620 --> 00:06:25.580
它模型本身的output

00:06:25.580 --> 00:06:28.060
或者其他的一些警告

00:06:28.060 --> 00:06:29.440
拒绝的一些信息

00:06:29.440 --> 00:06:31.240
还有包括文本图像的一个信息

00:06:31.240 --> 00:06:31.720
等等等等

00:06:31.720 --> 00:06:32.740
也就是它实际上

00:06:32.740 --> 00:06:33.460
你可以把理解成

00:06:33.460 --> 00:06:35.760
就是一个完整的一种响应格式

00:06:35.760 --> 00:06:37.960
是这么样的一个基本的定位

00:06:37.960 --> 00:06:39.720
所以也是基于这样的响应格式

00:06:39.720 --> 00:06:43.720
我们才能够去很好的去跟当前大模型来进行对话

00:06:43.720 --> 00:06:46.660
能够把它的对应结果来进行一个输出

00:06:46.660 --> 00:06:47.900
来进行一个响应

00:06:47.900 --> 00:06:48.820
那么上面也是一样的

00:06:48.820 --> 00:06:49.480
我们又来了一遍

00:06:49.480 --> 00:06:52.300
这个Response API完整的执行流程

00:06:52.300 --> 00:06:54.160
那么只不过在执行的过程当中

00:06:54.160 --> 00:06:57.600
我们这里是考虑把每一个Response里面的所有内容

00:06:57.600 --> 00:06:58.580
单独给你打印出来

00:06:58.580 --> 00:07:00.420
来看一看它到底回复哪些东西

00:07:00.420 --> 00:07:03.140
那么它回复内容包括什么Response ID

00:07:03.140 --> 00:07:04.540
Response的State

00:07:04.540 --> 00:07:05.540
Response Model

00:07:05.540 --> 00:07:06.220
等等等等

00:07:06.220 --> 00:07:07.100
总之就是

00:07:07.100 --> 00:07:08.800
它的每一条消息回复里面

00:07:08.800 --> 00:07:10.660
实际上会包含我们当前

00:07:10.660 --> 00:07:13.720
所有的回复的内容

00:07:13.720 --> 00:07:15.680
所有当前模型运行的

00:07:15.680 --> 00:07:17.060
全部的这样的信息

00:07:17.060 --> 00:07:17.940
换而言之就是

00:07:17.940 --> 00:07:19.760
我们当前这样的模型

00:07:19.760 --> 00:07:21.960
在执行当前任务的时候

00:07:21.960 --> 00:07:23.100
所有的状态信息

00:07:23.100 --> 00:07:24.340
你可以这么来进行理解

00:07:24.340 --> 00:07:24.820
好

00:07:24.820 --> 00:07:27.940
那么它和另外一个

00:07:27.940 --> 00:07:29.900
就是我们经常会讨论的

00:07:29.900 --> 00:07:31.560
叫Chat Compilation API

00:07:31.560 --> 00:07:33.040
它们两者之间

00:07:33.040 --> 00:07:34.780
到底是什么样的一个

00:07:34.780 --> 00:07:36.840
什么样的区别

00:07:36.840 --> 00:07:38.980
这里我们是首先需要放在这

00:07:38.980 --> 00:07:40.120
来给大家来进行个探讨

00:07:40.120 --> 00:07:41.600
因为其实很多同学之前

00:07:41.600 --> 00:07:42.940
其实是了解

00:07:42.940 --> 00:07:45.100
OpenAI的Chat Compilations API的

00:07:45.100 --> 00:07:46.400
那么这里面

00:07:46.400 --> 00:07:48.440
我们说OpenAI是原上一版本的

00:07:48.440 --> 00:07:49.680
Chat Compilations API

00:07:49.680 --> 00:07:51.340
它的核心的功能

00:07:51.340 --> 00:07:53.440
是去围绕Message消息列表

00:07:53.440 --> 00:07:54.560
来进行编辑

00:07:54.560 --> 00:07:55.620
也就是说它实际上

00:07:55.620 --> 00:07:57.480
是去维护一个又一个消息列表

00:07:57.480 --> 00:07:58.440
那一个消息列表里面

00:07:58.440 --> 00:07:59.940
我们需要由System

00:08:00.000 --> 00:08:05.400
也就是说它实际上是去维护一个又一个消息列表,那一个消息列表里面我们需要有systemmessage,需要有usermessage,有的时候还会有大模型回复回来message,

00:08:05.400 --> 00:08:14.600
但总之我们实际上重点是去维护它的模型每次运行过程当中消息列表,然后给它导入到当前模型里面去来进行一个运行,

00:08:14.600 --> 00:08:16.000
来进行一个测试

00:08:16.000 --> 00:08:17.760
然后最后的模型也给你返回出一个消息

00:08:17.760 --> 00:08:21.200
它返回消息的本质的也是一条消息

00:08:21.200 --> 00:08:23.880
所以原来的openAI它上一代的

00:08:23.880 --> 00:08:24.900
或者deep seek也是一样

00:08:24.900 --> 00:08:27.680
它之前支持的主要是chatcompletions API

00:08:27.680 --> 00:08:30.640
那么它那些主要是去维护一个消息列表

00:08:30.640 --> 00:08:33.100
而现在升级到了response API

00:08:33.100 --> 00:08:37.100
你会发现它实际上是维护你当前运行的一个状态

00:08:37.100 --> 00:08:39.120
所谓当前运行的状态

00:08:39.120 --> 00:08:41.740
就指的是我们现在在运行的过程当中

00:08:41.740 --> 00:08:45.020
一个模型它其实每次在进行响应的过程当中

00:08:45.020 --> 00:08:47.860
它会有很多很多的一些状态方面这样的信息

00:08:47.860 --> 00:08:50.240
而原来我们重点维护的消息列表

00:08:50.240 --> 00:08:52.720
你可以把理解成只是状态当中的一个维度

00:08:52.720 --> 00:08:53.640
仅此而已

00:08:53.640 --> 00:08:55.800
那么现在我们说借助Response API

00:08:55.800 --> 00:08:57.080
实际上对于开发者来说

00:08:57.080 --> 00:08:59.480
其实就能够非常便捷的把一些工具

00:08:59.480 --> 00:09:02.040
把一些这个extract给它放到一块

00:09:02.040 --> 00:09:03.800
就可以迅速的构成一个agent

00:09:03.800 --> 00:09:05.420
然后你只需要输入一个input

00:09:05.420 --> 00:09:08.900
它背后就可以完整的去执行一整个agent loop

00:09:08.900 --> 00:09:10.620
那所谓agent loop

00:09:10.620 --> 00:09:12.900
这点大家也可以这么理解一下

00:09:12.900 --> 00:09:14.820
就是我现在agent要调用一些工具

00:09:14.820 --> 00:09:16.380
来完成一些事项

00:09:16.380 --> 00:09:16.720
对不对

00:09:16.720 --> 00:09:17.820
那这工具有的时候

00:09:17.820 --> 00:09:20.660
我们需要多部的进行调用

00:09:20.660 --> 00:09:23.260
有的时候也需要并发的来进行调用

00:09:23.260 --> 00:09:23.560
对不对

00:09:23.560 --> 00:09:25.420
那原来我们需要实现多部

00:09:25.420 --> 00:09:26.840
或者并发的这样的工具调用

00:09:26.840 --> 00:09:28.760
你可能得编写更加复杂的

00:09:28.760 --> 00:09:29.400
这样的一个程序

00:09:29.400 --> 00:09:31.460
或者是用比如说像long chain

00:09:31.460 --> 00:09:32.580
这样的agent开发框架

00:09:32.580 --> 00:09:33.000
对不对

00:09:33.000 --> 00:09:35.020
它其实是支持内部

00:09:35.020 --> 00:09:37.560
去完成agent loop这样的工作的

00:09:37.560 --> 00:09:39.480
agent loop就是它不断不断去调用工具

00:09:39.480 --> 00:09:42.020
直到它能够完成当前的请求为止

00:09:42.020 --> 00:09:42.480
好

00:09:42.480 --> 00:09:43.920
现在我们说这些功能

00:09:43.920 --> 00:09:47.960
其实也是可以被responses API来去完成的

00:09:47.960 --> 00:09:51.380
这个其实是它的一个功能上面这样的进阶

00:09:51.380 --> 00:09:53.900
如果原来你是使用chat completion API的话

00:09:53.900 --> 00:09:56.080
你可能就需要不断的去维护它的消息例表

00:09:56.080 --> 00:09:57.980
其实整个过程会非常的繁琐

00:09:57.980 --> 00:10:00.180
如果你需要去实现agent loop的话

00:10:00.180 --> 00:10:01.740
其实你需要手动来进行搭建

00:10:01.740 --> 00:10:03.300
而现在是用responses API

00:10:03.300 --> 00:10:04.060
其实不需要

00:10:04.060 --> 00:10:07.040
它内部是可以帮你去全自动的

00:10:07.040 --> 00:10:09.140
完成agent loop这样的工作的

00:10:09.140 --> 00:10:12.020
所以其实对于Responses API来说

00:10:12.020 --> 00:10:13.820
它其实也就是你可以把它理解成

00:10:13.820 --> 00:10:15.500
就是一个类似于LongChain这样的一个

00:10:15.500 --> 00:10:17.880
agent和工具把它绑定一块的一个脚手架

00:10:17.880 --> 00:10:20.660
这个是它的一个基础的认知

00:10:20.660 --> 00:10:26.380
当然在OpenAI官方的给出的Responses API的说明里面

00:10:26.380 --> 00:10:27.780
它其实也有谈到说

00:10:27.780 --> 00:10:29.400
我们现在使用Responses API

00:10:29.400 --> 00:10:32.920
相比于上一代的Chat Completions API来说

00:10:32.920 --> 00:10:34.760
其实它的性能是增长了3%

00:10:34.760 --> 00:10:38.480
它是在terminal的榜单上

00:10:38.480 --> 00:10:40.560
它性能是增上了3%

00:10:40.560 --> 00:10:42.240
也就是说明有了框架

00:10:42.240 --> 00:10:43.720
去搭建一些agent

00:10:43.720 --> 00:10:45.640
实际上是能够更好的

00:10:45.640 --> 00:10:48.660
更加稳定的去维护这些agent运行的

00:10:48.660 --> 00:10:50.820
它是有这样的一个功能在这

00:10:50.820 --> 00:10:51.200
OK

00:10:51.200 --> 00:10:53.960
这个是所谓的Responses API

00:10:53.960 --> 00:10:56.960
当然我们说对于Responses API来说

00:10:56.960 --> 00:10:58.420
我们下面还有很多的一些

00:10:58.420 --> 00:11:01.200
大家可以课后自己再去来进行

00:11:01.200 --> 00:11:03.580
深度学习的一些内容和素材

00:11:03.580 --> 00:11:06.820
比如说它也是支持一些参数这样的调整的

00:11:06.820 --> 00:11:07.160
对不对

00:11:07.160 --> 00:11:08.780
比如说什么temperature

00:11:08.780 --> 00:11:12.440
还有topia这样的一些底层的模型运行参数

00:11:12.440 --> 00:11:13.200
这样的调整

00:11:13.200 --> 00:11:18.180
比如说你这个temperature调整的范围是在0到2之间

00:11:18.180 --> 00:11:20.420
然后temperature越高

00:11:20.420 --> 00:11:21.860
那么它生成结果越就越不稳定

00:11:21.860 --> 00:11:22.700
然后temperature越低

00:11:22.700 --> 00:11:24.140
它生成结果越稳定等等等等

00:11:24.140 --> 00:11:28.480
同时它也是支持直接通过一些json schema

00:11:28.480 --> 00:11:30.940
这个是来进行structured output

00:11:30.940 --> 00:11:32.260
就是结构化的输出

00:11:32.260 --> 00:11:33.220
那么结构化输出呢

00:11:33.220 --> 00:11:35.500
实际上在现在很多的agent开发场景下

00:11:35.500 --> 00:11:37.100
都会非常非常的重要

00:11:37.100 --> 00:11:37.480
对不对

00:11:37.480 --> 00:11:39.000
你可以通过类似这样的方式

00:11:39.000 --> 00:11:42.840
去设置好对应的这个结构化输出的

00:11:42.840 --> 00:11:44.980
这个结构化这个文本的这个要求

00:11:44.980 --> 00:11:45.640
然后呢

00:11:45.640 --> 00:11:47.760
把它直接带入到我们的

00:11:47.760 --> 00:11:50.080
Responses API的这个text参数里面去

00:11:50.080 --> 00:11:52.100
就让它能够进行结构化的输出了

00:11:52.100 --> 00:11:52.840
是这么一回事

00:11:52.840 --> 00:11:54.140
当然我们现在公开课

00:11:54.140 --> 00:11:55.860
其实一般来说就不会围绕

00:11:55.860 --> 00:11:56.940
比如说结构化输出里面

00:11:56.940 --> 00:11:58.640
具体它是规定哪些结构

00:11:58.640 --> 00:12:00.140
这个Json schema的这个对象

00:12:00.140 --> 00:12:01.540
到底代表什么样的含义

00:12:01.540 --> 00:12:02.600
来展开来说

00:12:02.600 --> 00:12:03.860
实际上也是因为

00:12:03.860 --> 00:12:05.660
这东西都可以让大模型来完成

00:12:05.660 --> 00:12:07.060
重点是你需要知道的是

00:12:07.060 --> 00:12:08.500
有这个responsive API之后

00:12:08.500 --> 00:12:10.740
它的结果化输出会非常稳定

00:12:10.740 --> 00:12:13.400
是这么样的一个情况

00:12:13.400 --> 00:12:14.520
具体怎么稳定

00:12:14.520 --> 00:12:16.160
它其实有很多层的检验

00:12:16.160 --> 00:12:18.400
什么text format

00:12:18.400 --> 00:12:20.320
一层的检验

00:12:20.320 --> 00:12:22.260
返回结果的Json格式的

00:12:22.260 --> 00:12:23.760
一层本地的教验

00:12:23.760 --> 00:12:26.780
最后再给你返回一个结果化输出

00:12:26.780 --> 00:12:27.440
这样的文本

00:12:27.440 --> 00:12:30.640
它是可以经过多层的教验和反馈

00:12:30.640 --> 00:12:33.020
最后给你输出一个结构化的文本

00:12:33.020 --> 00:12:34.640
这个其实是没有什么问题的

00:12:34.640 --> 00:12:36.960
然后同时对于Response API来说

00:12:36.960 --> 00:12:39.680
它还有非常关键的Tours的参数

00:12:39.680 --> 00:12:40.060
对不对

00:12:40.060 --> 00:12:42.000
Tours的参数我们一会儿就看到

00:12:42.000 --> 00:12:44.100
它其实和Launcher里面的Tours的参数

00:12:44.100 --> 00:12:45.440
实际上就是一样的

00:12:45.440 --> 00:12:46.740
给它输入一个工具

00:12:46.740 --> 00:12:47.800
然后它就可以调用这工具

00:12:47.800 --> 00:12:49.440
来完成对应的工作

00:12:49.440 --> 00:12:50.580
是怎么样的情况

00:12:50.580 --> 00:12:53.180
所以对于整个的Response API来说

00:12:53.180 --> 00:12:55.040
核心样的参数就这么些

00:12:55.040 --> 00:12:57.600
模型instruction系统开发指令

00:12:57.600 --> 00:12:58.280
对不对input

00:12:58.280 --> 00:13:00.460
本次任务的基本请求

00:13:00.460 --> 00:13:03.480
然后还有这个什么maxoutputtoken

00:13:03.480 --> 00:13:05.700
这个最高的模型输出结果上线

00:13:05.700 --> 00:13:07.640
还有这个temperaturetoppr reasoning

00:13:07.640 --> 00:13:08.600
对它推理强度

00:13:08.600 --> 00:13:09.360
刚不说了吗

00:13:09.360 --> 00:13:10.460
这个V4这个模型

00:13:10.460 --> 00:13:11.800
有三档推理强度

00:13:11.800 --> 00:13:13.820
然后下面还有这个text

00:13:13.820 --> 00:13:16.680
主要是去进行结构化输出的一些参数

00:13:16.680 --> 00:13:17.500
然后还有这个tours

00:13:17.500 --> 00:13:19.740
是可以绑定一些外部的这样的工具

00:13:19.740 --> 00:13:21.140
然后它还有这个tourchoice

00:13:21.140 --> 00:13:22.060
代表的含义是

00:13:22.060 --> 00:13:23.220
我们每次运行的时候

00:13:23.220 --> 00:13:24.780
指定的工具来进行运行

00:13:24.780 --> 00:13:25.820
还有这个stream

00:13:25.820 --> 00:13:26.260
对不对

00:13:26.260 --> 00:13:27.820
流式打印等等等等

00:13:27.820 --> 00:13:28.900
有很多很多这些参数

00:13:28.900 --> 00:13:30.320
基本上如果你看这参数

00:13:30.320 --> 00:13:33.580
你会感觉他整个的运行的状态

00:13:33.580 --> 00:13:38.940
差不多就和LongChain的CreateAgent是非常类似的

00:13:38.940 --> 00:13:39.360
对不对

00:13:39.360 --> 00:13:44.160
那这个是现在对于DeepSeq V4正式版模型来说

00:13:44.160 --> 00:13:46.940
他所选择的一套基本的API

00:13:46.940 --> 00:13:49.640
当然下面还有关于什么流失打印

00:13:49.640 --> 00:13:51.080
是怎么样来进行操作的

00:13:51.080 --> 00:13:53.400
这一点大家也可以自己去看一下

00:13:53.400 --> 00:13:57.280
下面还有对应的可以来进行测试和运行的代码

00:13:57.280 --> 00:13:59.180
关于流失打印其实也是一样的

00:13:59.180 --> 00:14:00.500
就是人工讲应起来

00:14:00.500 --> 00:14:00.920
其实会非常

00:14:00.920 --> 00:14:02.900
其实人工编写其实非常麻烦

00:14:02.900 --> 00:14:04.480
但是对于现在的agent来说

00:14:04.480 --> 00:14:05.940
他们编写其实非常简单

00:14:05.940 --> 00:14:06.760
所以你只需要知道

00:14:06.760 --> 00:14:08.740
他其实这个是可以非常顺利的

00:14:08.740 --> 00:14:09.820
来进行实现的

00:14:09.820 --> 00:14:10.480
就没有什么问题

00:14:10.480 --> 00:14:11.460
然后同时

00:14:11.460 --> 00:14:13.760
他由于是维护每次运行的状态

00:14:13.760 --> 00:14:16.240
所以他也是可以把之前对话状态

00:14:16.240 --> 00:14:17.040
给他传入进去的

00:14:17.040 --> 00:14:19.760
把之前对话状态传入进去

00:14:19.760 --> 00:14:20.620
实际上相当于是

00:14:20.620 --> 00:14:22.800
把上一次任务执行记录的全部信息

00:14:22.800 --> 00:14:25.300
包括上一次咱们对话这个信息

00:14:25.300 --> 00:14:26.240
都给他输入进去

00:14:26.240 --> 00:14:28.500
然后他就可以来实现多种对话了

00:14:28.500 --> 00:14:29.100
就这么一回事

00:14:29.100 --> 00:14:34.700
这个其实是它的多轮对话的历史保存的一个基本的方法

00:14:34.700 --> 00:14:39.900
就是把它的之前上一轮的response id给它传入进去

00:14:39.900 --> 00:14:43.300
那么它接下来就可以顺利的来进行多轮对话了

00:14:43.300 --> 00:14:45.400
这个是它的一个基本设置

00:14:45.400 --> 00:14:49.700
然后同时下面还有关于function calling的完整的外部循环

00:14:49.700 --> 00:14:51.860
就是我们现在要去定一个外部工具

00:14:51.860 --> 00:14:52.300
对不对

00:14:52.300 --> 00:14:54.100
你这个什么查询天气的外部工具

00:14:54.100 --> 00:14:55.700
各式各样的外部工具

00:14:55.700 --> 00:14:59.000
包括这里面是个结构化信息的匹配的一个外部工具

00:14:59.000 --> 00:15:03.320
等等等等 都可以通类似使用类似这样的方式来进行一个定义

00:15:03.320 --> 00:15:07.720
定义好了外部工具之后 接下来在Responses API里面直接输入tools

00:15:07.720 --> 00:15:11.960
然后把你的工具给它放进去 然后它就可以顺带进行运行 就这么简单

00:15:11.960 --> 00:15:16.440
当然如果你去拆 如果你去看它底层的响应的过程的话

00:15:16.440 --> 00:15:20.920
这里其实就是一个我们去看它底层响应的过程完整的事例了

00:15:20.920 --> 00:15:24.760
那么你会发现 它其实底层仍然还是一个function calling的完整流程

00:15:24.760 --> 00:15:27.880
就是你给它关联工具之后 你先给工具发送个请求

00:15:27.880 --> 00:15:30.280
然后公共运行完了之后呢 给你一个function response message

00:15:30.280 --> 00:15:32.280
然后你接收到function response message之后呢

00:15:32.280 --> 00:15:34.080
再开启你的second response啊

00:15:34.080 --> 00:15:36.280
就是再去结合最开始用户的问题啊

00:15:36.280 --> 00:15:38.280
去给用户来进行回复啊 是这么一回事啊

00:15:38.280 --> 00:15:40.680
所以这个呢实际上是一个验证的过程啊

00:15:40.680 --> 00:15:42.880
你要说一下啊 对于response API来说呢

00:15:42.880 --> 00:15:44.680
他的这个也是一样的

00:15:44.680 --> 00:15:48.080
他的这个工具要用其本质上啊 也是这个function calling啊

00:15:48.080 --> 00:15:51.680
跟现在所有的其他的这个agent开发框架的这个function calling啊

00:15:51.680 --> 00:15:52.680
也全部都是一样的

00:15:52.680 --> 00:15:56.080
当然他其实非常完善好 整个response API里面

00:15:56.080 --> 00:15:57.680
他其实有非常完善的功能

00:15:57.680 --> 00:15:59.700
包括它工具室外的时候

00:16:04.040 --> 00:16:14.960
所以也是基於response API,我們說deepseek它現在是擁抱了response API,才能夠更好的去接入到我們現在的codex裡面來進行運行。

00:16:14.960 --> 00:16:20.960
否则的话 如果Deepseekv4本身这个模型 它并不兼容Responsees API的话 那么它其实是没有办法

00:16:20.960 --> 00:16:27.360
完整接入到Codex里面去 并且能完整的释放现在Codex的完整性能 这个其实做不到

00:16:27.360 --> 00:16:34.960
当然其实我们上面关于底层的API这个讲解 一个其实比较快 第二个其实我们也是希望主要是给大家留下一些印象

00:16:34.960 --> 00:16:40.560
知道是怎么一回事就可以了 因为之后的编写主要是让我们AI来进行编写

00:16:40.560 --> 00:16:43.480
所以我们可能就不像之前的公块课一样

00:16:43.480 --> 00:16:45.940
围绕每一个API的每一行代码来进行讲解

00:16:45.940 --> 00:16:47.980
因为现在来看其实意义不是很大

00:16:47.980 --> 00:16:49.560
你总之你核心是要知道

00:16:49.560 --> 00:16:51.520
这个Response API到底是干什么的

00:16:51.520 --> 00:16:53.080
这点其实会非常重要

00:16:53.080 --> 00:16:55.800
当然下面我们其实是围绕Response API

00:16:55.800 --> 00:16:56.940
做了一个小小的实验

00:16:56.940 --> 00:16:59.820
我们来搭建了一个简单的一个agent

00:16:59.820 --> 00:17:02.560
然后这个agent基本上就是

00:17:02.560 --> 00:17:04.940
现在有很多很多张表

00:17:04.940 --> 00:17:07.320
然后我们来做一个简单的数据分析

00:17:07.320 --> 00:17:09.400
然后核心是从各个表当中

00:17:09.400 --> 00:17:11.680
来进行数据提取跟数据查询

00:17:11.680 --> 00:17:15.180
当然我们这里为什么跟大家去先使用这个Response API

00:17:15.180 --> 00:17:16.200
搭建一个简单的数据分析

00:17:16.200 --> 00:17:17.640
因为从下一个小节开始

00:17:17.640 --> 00:17:20.800
我们在使用Codex这样更加复杂的工具的时候

00:17:20.800 --> 00:17:23.300
实际上我们最后的目标这不就是搭建

00:17:23.300 --> 00:17:23.780
对不对

00:17:23.780 --> 00:17:25.880
长成这样的一个数据分析系统吗

00:17:25.880 --> 00:17:29.100
只不过我们现在从最底层的API出发

00:17:29.100 --> 00:17:30.240
一点点来进行学习

00:17:30.240 --> 00:17:33.980
到最后能搭建这么一个比较复杂的数据分析系统

00:17:33.980 --> 00:17:35.460
其实有很长的路要走

00:17:35.460 --> 00:17:38.000
所以我们在最一开始就给大家举一个小例子

00:17:38.000 --> 00:17:41.660
如果我们现在是使用Response API来搭建一个数据分析系统的话

00:17:41.660 --> 00:17:42.700
那么未来它是一个

00:17:42.700 --> 00:17:45.980
那么它首先这第一步应该怎么卖出去

00:17:45.980 --> 00:17:48.860
然后我们再来考虑使用这Codex之后

00:17:48.860 --> 00:17:53.240
你整个搭建数据分析系统的效率跟速度就可以起飞

00:17:53.240 --> 00:17:53.580
对不对

00:17:53.580 --> 00:17:56.480
我们来一步一步来看它是怎么样来进行运行的

00:17:56.480 --> 00:17:58.480
当然这里我们涉及到一个数据集

00:17:58.480 --> 00:17:59.640
叫Allist

00:17:59.640 --> 00:18:02.120
它是巴西电商公司的一个开源数据集

00:18:02.120 --> 00:18:04.380
这个数据集其实非常庞大

00:18:04.380 --> 00:18:08.040
里面总共有这么十几万行的这个数据

00:18:08.040 --> 00:18:09.580
那这个数据集也是我们之后

00:18:09.580 --> 00:18:13.380
在做我们当前整个数据分析系统的性能测试的时候

00:18:13.380 --> 00:18:14.560
最核心的这个数据集

00:18:14.560 --> 00:18:15.380
所以大家可以看一下

00:18:15.380 --> 00:18:18.360
当然其实对于所谓这个电商的这个数据

00:18:18.360 --> 00:18:20.460
其实主要是分成这么两大类

00:18:20.460 --> 00:18:21.820
一个是orders

00:18:21.820 --> 00:18:23.060
一个是customers

00:18:23.060 --> 00:18:25.720
这么两类的这个数据表格

00:18:25.720 --> 00:18:28.000
它这个数据集不是一个单独的数据集

00:18:28.000 --> 00:18:30.580
是分了好多好多好多个这个子数据的这个数据集

00:18:30.580 --> 00:18:32.580
然后这个orders就是你订单

00:18:32.580 --> 00:18:34.220
然后customer就是当前的客户

00:18:34.220 --> 00:18:35.420
等等非常非常多

00:18:35.420 --> 00:18:40.580
总之近期订单历史订单非常非常多

00:18:40.580 --> 00:18:42.760
总共是一个世界外行的数据表格

00:18:42.760 --> 00:18:45.620
那么这个数据表其实会有点复杂

00:18:45.620 --> 00:18:48.400
我们一会儿都会看到这个数据表里面完整的内容

00:18:48.400 --> 00:18:49.740
总之大家需要知道是

00:18:49.740 --> 00:18:50.920
哎呀 这里有个数据表格

00:18:50.920 --> 00:18:53.360
好 那么如果你现在想要使用

00:18:53.360 --> 00:18:55.360
比如说Deepseek v4这样的模型

00:18:55.360 --> 00:18:58.700
搭配着它现在已经兼容的Responsees API

00:18:58.700 --> 00:19:00.500
去搭建一个数据分析系统

00:19:00.500 --> 00:19:03.760
大家可以想想看有哪一些想法

00:19:03.760 --> 00:19:04.280
对不对

00:19:04.280 --> 00:19:06.000
其实我们对于现在的agent开发来说

00:19:06.000 --> 00:19:08.100
首先你得有一个基本的思路

00:19:08.100 --> 00:19:09.840
和一些基础的想法

00:19:09.840 --> 00:19:11.560
可能我们就会涉及到

00:19:11.560 --> 00:19:13.440
比如说我现在数据库

00:19:13.440 --> 00:19:14.780
数据存储的数据库里面

00:19:14.780 --> 00:19:16.520
所以我需要有一些

00:19:16.520 --> 00:19:19.120
从数据库里面取出数据的这样的工具

00:19:19.120 --> 00:19:19.720
对不对

00:19:19.720 --> 00:19:21.680
然后也需要有一些

00:19:21.680 --> 00:19:23.840
我们去查询数据这样的工具

00:19:23.840 --> 00:19:26.700
然后同时还需要有一些读取数据的工具

00:19:26.700 --> 00:19:28.320
然后同时还需要有一些

00:19:28.320 --> 00:19:31.100
查询具体的每一个数据里面的

00:19:31.100 --> 00:19:32.120
航和列之间的工具

00:19:32.120 --> 00:19:34.060
这里面其实我们是给出一系列工具

00:19:34.060 --> 00:19:35.040
列出数据表格

00:19:35.040 --> 00:19:37.240
然后查询每一个数据表

00:19:37.240 --> 00:19:38.500
什么来源表明

00:19:38.500 --> 00:19:39.800
然后什么查询

00:19:39.800 --> 00:19:41.220
什么每一个数据的

00:19:41.220 --> 00:19:42.560
这个原数据

00:19:42.560 --> 00:19:43.220
它的来源

00:19:43.220 --> 00:19:45.020
它的最大最大行数

00:19:45.020 --> 00:19:47.360
它的编写设计数代码来进行运行

00:19:47.360 --> 00:19:48.560
同时还需要

00:19:48.560 --> 00:19:51.140
去创建

00:19:51.140 --> 00:19:53.640
去实现一个能够单独去创建数据集的

00:19:53.640 --> 00:19:55.000
这样的一个外部工具等等

00:19:55.000 --> 00:19:58.160
这个其实是我们现在的建议数据分析的过程当中

00:19:58.160 --> 00:19:59.180
我们最核心

00:19:59.180 --> 00:20:00.060
最常用的

00:20:00.060 --> 00:20:01.560
无聊数据库来进行操作的啊

00:20:01.560 --> 00:20:02.860
是像四项工具啊

00:20:02.860 --> 00:20:03.540
列数表格

00:20:03.540 --> 00:20:04.020
对不对

00:20:04.020 --> 00:20:05.360
查他的这个原数据啊

00:20:05.360 --> 00:20:07.200
就是查这个数据表格的这个真实情况

00:20:07.200 --> 00:20:08.240
然后呢编写circle啊

00:20:08.240 --> 00:20:09.420
来进行这个读数啊

00:20:09.420 --> 00:20:10.620
然后呢去创建表格

00:20:10.620 --> 00:20:11.760
把这个数据给取出来啊

00:20:11.760 --> 00:20:13.240
基本上我们说这四个工具呢

00:20:13.240 --> 00:20:14.340
是非常核心的

00:20:14.340 --> 00:20:15.220
这么四个工具

00:20:15.220 --> 00:20:15.420
好

00:20:15.420 --> 00:20:15.980
那么下面啊

00:20:15.980 --> 00:20:17.420
其实就是关于这四工具的

00:20:17.420 --> 00:20:19.620
这样的一个定义的这个方法了啊

00:20:19.620 --> 00:20:20.380
那么这里面呢

00:20:20.380 --> 00:20:22.420
其实各个不同类型的这个工具啊

00:20:22.420 --> 00:20:22.740
他呢

00:20:22.740 --> 00:20:23.740
其实呃

00:20:23.740 --> 00:20:25.060
我们上面他的具体的功能

00:20:25.060 --> 00:20:26.240
其实定义还是非常清楚的啊

00:20:26.240 --> 00:20:27.660
这里我们都是使用的python

00:20:30.060 --> 00:20:32.060
Sirco查询的一些工具

00:20:32.060 --> 00:20:33.800
其实它背后的核心实现逻辑

00:20:33.800 --> 00:20:35.860
就是把用户的输入的语言

00:20:35.860 --> 00:20:37.080
把它转换成对应的Sirco代码

00:20:37.080 --> 00:20:39.260
然后把它再去检查一下

00:20:39.260 --> 00:20:40.740
Sirco代码本身这样的格式

00:20:40.740 --> 00:20:41.920
那么接下来就可以来进行运行

00:20:41.920 --> 00:20:45.540
就这么样的一个基本的使用方法

00:20:45.540 --> 00:20:49.040
下面就是这些工具的一些创建这样的方式

00:20:49.040 --> 00:20:51.360
然后紧接着我们就可以把这工具

00:20:51.360 --> 00:20:55.720
给它关联到我们当前的Responses API里边来

00:20:55.720 --> 00:20:57.940
那么接下来下面有一个Stream

00:20:57.940 --> 00:20:59.160
就打印的这样的方式

00:20:59.160 --> 00:20:59.800
那么接下来呢

00:20:59.800 --> 00:21:01.640
我们说你的一个极简的啊

00:21:01.640 --> 00:21:03.380
一个简易的这个agent啊

00:21:03.380 --> 00:21:04.940
实际上就相当于是完成了啊

00:21:04.940 --> 00:21:06.940
当然我们这里其实有个每一个

00:21:06.940 --> 00:21:09.100
有每一个的这个外部函数

00:21:09.100 --> 00:21:11.780
它具体完整的这样的这个定义方法啊

00:21:11.780 --> 00:21:12.300
这里面呢

00:21:12.300 --> 00:21:13.540
会有大家可以自己去看一下啊

00:21:13.540 --> 00:21:14.940
因为实际上我们说啊

00:21:14.940 --> 00:21:16.460
这个每个外部函数的这个定义呢

00:21:16.460 --> 00:21:17.720
都会比较复杂啊

00:21:17.720 --> 00:21:19.640
但是这里面先给大家简单的啊

00:21:19.640 --> 00:21:20.860
留下一个这个印象啊

00:21:20.860 --> 00:21:22.180
就是对于现在的

00:21:22.180 --> 00:21:23.340
我们在进行啊

00:21:23.340 --> 00:21:24.820
这个agent的开发过程当中啊

00:21:24.820 --> 00:21:26.620
那么如果你需要去搭建一个

00:21:26.620 --> 00:21:28.200
数据分析的这样的agent的话

00:21:28.200 --> 00:21:31.420
然后如果你现在去使用这个Responses API的话

00:21:31.420 --> 00:21:33.120
实际上实现起来会非常简单

00:21:33.120 --> 00:21:34.800
我们说你只需要定义好

00:21:34.800 --> 00:21:37.460
我们刚刚所说的拥有这些功能的外部函数

00:21:37.460 --> 00:21:41.820
然后把这函数和我们当前的model模型放在一块

00:21:41.820 --> 00:21:43.520
对不对来进行一个封装

00:21:43.520 --> 00:21:47.060
然后最后它就可以直接就是一个简单的agent

00:21:47.060 --> 00:21:48.720
就可以直接顺利来进行运行

00:21:48.720 --> 00:21:49.480
就这么回事

00:21:49.480 --> 00:21:52.360
但这里其实会具体涉及到很多的一些代码

00:21:52.360 --> 00:21:54.740
就比如说我们如何把自然预言转化成sicle

00:21:54.740 --> 00:21:55.300
对不对

00:21:55.300 --> 00:21:59.900
然后呢Sircle本身这样代码如何去提升它的这样的准确性等等等等

00:21:59.900 --> 00:22:03.360
那么这个可能就属于这个比较进阶的一些功能了

00:22:03.360 --> 00:22:06.140
这个我们公开课可能就没有时间展开来说了

00:22:06.140 --> 00:22:09.040
但是呢这里给大家提供的所有的这些代码呢

00:22:09.040 --> 00:22:12.380
实际上每个代码都是可以真实的来进行运行的

00:22:12.380 --> 00:22:14.200
然后呢大家如果感兴趣的话

00:22:14.200 --> 00:22:16.260
课后呢可以单独再去看一下这个代码

00:22:16.260 --> 00:22:19.800
或者你也可以直接能把它导到你本地的这个环境里边去

00:22:19.800 --> 00:22:23.560
让它呢反正我们说每一个这个核心的这个外部函数

00:22:23.560 --> 00:22:26.560
我们下面都有完整脚本和它的功能的这样的定义

00:22:26.560 --> 00:22:29.500
你可以直接用它来进行的使用也是ok的

00:22:29.500 --> 00:22:31.840
只不过这里我们就跟大家说的一点

00:22:31.840 --> 00:22:35.120
是其实对于当前的Response API来说

00:22:35.120 --> 00:22:37.280
如果你想创建一个数据分析agent

00:22:37.280 --> 00:22:38.940
我知不知道它也可以非常简单

00:22:38.940 --> 00:22:39.500
对不对

00:22:39.500 --> 00:22:42.740
我们无非就是我的工具给它封闹到一起去

00:22:42.740 --> 00:22:44.660
然后用户输入一个业务的问题

00:22:44.660 --> 00:22:46.640
我们就看需要使用哪些工具

00:22:46.640 --> 00:22:47.240
对不对

00:22:47.240 --> 00:22:49.180
然后通过Response API

00:22:49.180 --> 00:22:50.800
它本质上实际上是一个agent loop

00:22:50.800 --> 00:22:55.440
它是一个不断循环的这样的一个操作

00:22:55.440 --> 00:22:58.620
它就会不断的尝试去调用各式各样的工具

00:22:58.620 --> 00:23:00.240
来进行多部工具调用

00:23:00.240 --> 00:23:02.220
或者工具的这样的并发使用等等

00:23:02.220 --> 00:23:05.200
然后最后完成了

00:23:05.200 --> 00:23:07.600
最后就给输出一段最终这样的结果

00:23:07.600 --> 00:23:11.420
然后最后我们也可以让它去绘制一些表格等等

00:23:11.420 --> 00:23:13.760
它其实基本上就是这么样的一个过程

00:23:13.760 --> 00:23:14.720
但是它底层

00:23:14.720 --> 00:23:16.900
我们说上面其实大模型的运行的层

00:23:16.900 --> 00:23:20.560
底层实际上我们肯定是需要有维护的收据库

00:23:20.560 --> 00:23:25.660
这里其实我们默认的数据库是CircleLite和MyCircle这么两种数据库

00:23:25.660 --> 00:23:30.880
然后那么无非就是下来我们上面各式各样生产出来的消息

00:23:30.880 --> 00:23:34.920
或者你的Circle从你的数据库当中具体来进行运行等等

00:23:34.920 --> 00:23:36.300
然后运行完了之后

00:23:36.300 --> 00:23:41.700
你最后返回的Circle数据库这样的内容也会拼接到我们原始的消息列表里面去

00:23:41.700 --> 00:23:44.020
然后共同回复用户当前这样的问题

00:23:44.020 --> 00:23:45.360
就是这样的一个过程

00:23:45.360 --> 00:23:48.460
所以其实现在我们在进行Agent的开发过程当中

00:23:48.460 --> 00:23:51.420
本质上其实如果说最底层的话

00:23:51.420 --> 00:23:52.860
无非就是创建好工具

00:23:52.860 --> 00:23:56.140
然后和你当前的agent给他放在一块

00:23:56.140 --> 00:23:58.020
然后最后来进行一些测试

00:23:58.020 --> 00:23:58.920
来进行运行

00:23:58.920 --> 00:24:00.880
看一下能不能够来进行顺利的运行

00:24:00.880 --> 00:24:02.080
上面我们最下面

00:24:02.080 --> 00:24:03.220
最上面这个脚本

00:24:03.220 --> 00:24:04.280
最后面这两个脚本

00:24:04.280 --> 00:24:07.960
实际上是去查询我们当前的数据

00:24:07.960 --> 00:24:10.660
它一段时间的销量的结果

00:24:10.660 --> 00:24:12.000
它的各式各样的

00:24:12.000 --> 00:24:15.280
巴西店商各式各样不同品类的这样的商品

00:24:15.280 --> 00:24:19.420
它实际上销量的一个分布情况

00:24:19.420 --> 00:24:23.220
这个是我们来进行的一个查询

00:24:23.220 --> 00:24:25.200
然后最后生成了一张图片

00:24:25.200 --> 00:24:26.240
是这么一回事

00:24:26.240 --> 00:24:29.200
那么实际上具体运行脚本和代码

00:24:29.200 --> 00:24:30.880
实际上就是上面这些脚本和代码

00:24:30.880 --> 00:24:34.080
这个是在数据库中查询数据的一个完整的脚本

00:24:34.080 --> 00:24:36.140
那下面是查询完数据之后

00:24:36.140 --> 00:24:38.520
生成最终运行结果的这样的脚本

00:24:38.520 --> 00:24:42.800
那么里面实际上本质上都是去关联到我们当前agent

00:24:42.800 --> 00:24:44.500
来进行一轮又轮的运行

00:24:44.500 --> 00:24:45.300
是怎么样一回事