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

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

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

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

5
00:00:27,240 --> 00:00:30,080
到现在在webcoding时代

6
00:00:30,080 --> 00:00:30,900
这些很多功能

7
00:00:30,900 --> 00:00:32,200
我们其实都可以让大模型

8
00:00:32,200 --> 00:00:32,820
帮我们完成

9
00:00:32,820 --> 00:00:34,520
所以像这部分内容

10
00:00:34,520 --> 00:00:35,560
仍然是很重要

11
00:00:35,560 --> 00:00:37,120
但是我们可能就不需要

12
00:00:37,120 --> 00:00:39,140
去特别深入的吸引到

13
00:00:39,140 --> 00:00:39,920
每一行代码

14
00:00:39,920 --> 00:00:40,700
每一个参数

15
00:00:40,700 --> 00:00:41,820
分别代表什么样的含义

16
00:00:41,820 --> 00:00:43,040
这个程度来进行理解

17
00:00:43,040 --> 00:00:43,900
你只需要知道是

18
00:00:43,900 --> 00:00:45,120
它是干什么的

19
00:00:45,120 --> 00:00:46,020
有什么用

20
00:00:46,020 --> 00:00:47,760
以及你能怎么用

21
00:00:47,760 --> 00:00:49,340
这个东西其实是最重要的

22
00:00:49,340 --> 00:00:50,760
那么我们接下来就来看看

23
00:00:50,760 --> 00:00:53,200
OpenAI的Responses API

24
00:00:53,200 --> 00:00:54,200
到底是什么

25
00:00:54,200 --> 00:00:56,480
当然这里大家如果不太了解

26
00:00:56,480 --> 00:00:58,220
这个Response API到底是什么的话

27
00:00:58,220 --> 00:01:00,940
你可以把它想象成就是OpenAI版的LongChain

28
00:01:00,940 --> 00:01:04,140
专门负责给我们开发者一个接口

29
00:01:04,140 --> 00:01:06,820
去更好的去调用这样的一些大模型

30
00:01:06,820 --> 00:01:10,100
然后把它们和一些工具给它绑在一块

31
00:01:10,100 --> 00:01:11,620
最后做成一个Agent

32
00:01:11,620 --> 00:01:12,840
就是这样的一个API

33
00:01:12,840 --> 00:01:14,140
可以这么来进行理解

34
00:01:14,140 --> 00:01:16,120
当然其实这个Response API

35
00:01:16,120 --> 00:01:17,580
是去年3月11号

36
00:01:17,580 --> 00:01:22,440
OpenAI正式开源的一个全新的一种大模型调度的一种方法

37
00:01:22,440 --> 00:01:25,240
然后官网在OpenAI官网上也有非常详细的

38
00:01:25,240 --> 00:01:28,500
关于使用这个Response API的一些好处啊

39
00:01:28,500 --> 00:01:32,300
和怎么去进行迁移呀的一些这个方法啊

40
00:01:32,300 --> 00:01:33,780
当然这里我们要说明的是

41
00:01:33,780 --> 00:01:36,980
其实每一家啊大保险厂商都有资格的啊

42
00:01:36,980 --> 00:01:38,700
这个API的调度的这个范式

43
00:01:38,700 --> 00:01:40,560
比如说对于这个

44
00:01:40,560 --> 00:01:42,880
Anthelope来说啊

45
00:01:42,880 --> 00:01:45,460
他们呢自己有一套Anthelope API啊

46
00:01:45,460 --> 00:01:47,680
还有一套Cloud Agents SDK啊

47
00:01:47,680 --> 00:01:49,360
那么对于OpenAI来说呢

48
00:01:49,360 --> 00:01:51,480
他们家啊有这个Response API啊

49
00:01:51,480 --> 00:01:53,880
和Agent SDK啊两套开发框架啊

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

51
00:02:00,700 --> 00:02:01,600
是这么一回事

52
00:02:01,600 --> 00:02:03,240
那么对于openAI来说

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

54
00:02:10,640 --> 00:02:13,280
然后对于这个deep seek来说

55
00:02:13,280 --> 00:02:17,000
他现在是接入到了responses API这功能体系里面来

56
00:02:17,000 --> 00:02:19,760
当然这里其实有一个很有意思的一个点

57
00:02:19,760 --> 00:02:22,380
就在于说其实之前有同学会问到说

58
00:02:22,380 --> 00:02:27,280
Deepseek他们是怎么去考虑去接入OpenAI的Response API的呢

59
00:02:27,280 --> 00:02:28,640
当然我们说对Deepseek来说

60
00:02:28,640 --> 00:02:30,840
他一旦接入OpenAI这个Response API之后

61
00:02:30,840 --> 00:02:33,780
他实际上就可以无缝的接入Codex的体系了

62
00:02:33,780 --> 00:02:35,060
那他是怎么接入的呢

63
00:02:35,060 --> 00:02:35,680
其实非常简单

64
00:02:35,680 --> 00:02:36,940
就是在后训练的过程当中

65
00:02:36,940 --> 00:02:40,960
给了他很多的一些指令方面的训练集

66
00:02:40,960 --> 00:02:45,860
让他的响应格式能够和Response API的响应格式来进行兼容

67
00:02:45,860 --> 00:02:48,720
这里其实就会说的会比较底层了

68
00:02:48,720 --> 00:02:49,760
因为其实大家知道

69
00:02:49,760 --> 00:02:51,580
对于任何大模型来说

70
00:02:51,580 --> 00:02:53,760
它原始的这个输出这个内容

71
00:02:53,760 --> 00:02:55,680
实际上就是一个又一个token

72
00:02:55,680 --> 00:02:57,440
或者一个又一个字符

73
00:02:57,440 --> 00:02:59,940
这个字符里面内容其实会非常非常多

74
00:02:59,940 --> 00:03:01,680
然后大模型输出的

75
00:03:01,680 --> 00:03:03,820
实际上是一段非常非常长的这个字符

76
00:03:03,820 --> 00:03:05,120
那么我们每次呢

77
00:03:05,120 --> 00:03:08,280
在去进行大模型的这个聊天的过程当中

78
00:03:08,280 --> 00:03:10,860
实际上后台是需要把很长的这段字符

79
00:03:10,860 --> 00:03:13,060
来进行各式各样的格式解析的

80
00:03:13,060 --> 00:03:14,200
这段是什么

81
00:03:14,200 --> 00:03:15,180
那段是什么

82
00:03:15,180 --> 00:03:16,300
那么有一些呢

83
00:03:16,300 --> 00:03:19,180
他输出这个结果是给用户去看的

84
00:03:19,180 --> 00:03:20,820
原来某一段话的回复

85
00:03:20,820 --> 00:03:22,360
那么也有一些输出这个结果

86
00:03:22,360 --> 00:03:24,740
可能是比如说工具调用信息

87
00:03:24,740 --> 00:03:27,780
他自己运行当中的一些状态信息等等等等

88
00:03:27,780 --> 00:03:29,680
总之是有很长很长这段信息

89
00:03:29,680 --> 00:03:32,700
那么这个信息是以什么样的格式来进行输出

90
00:03:32,700 --> 00:03:34,580
他就可以被什么样的格式来进行解析

91
00:03:34,580 --> 00:03:35,480
你可以这么来经理解

92
00:03:35,480 --> 00:03:37,820
那只不过现在对于DeepseekV4

93
00:03:37,820 --> 00:03:39,300
整个正式版的模型来说

94
00:03:39,300 --> 00:03:43,960
他们选择了是以Responsees API这样的一个形式来进行输出

95
00:03:43,960 --> 00:03:46,640
所以他们就可以被Response API来进行解析

96
00:03:46,640 --> 00:03:48,080
所以他就跟他兼容了

97
00:03:48,080 --> 00:03:49,980
这么来进行理解就可以了

98
00:03:49,980 --> 00:03:50,600
是这么一回事

99
00:03:50,600 --> 00:03:53,360
是他在训练过程当中进行的非常深度的设置

100
00:03:53,360 --> 00:03:54,440
OK好

101
00:03:54,440 --> 00:03:57,020
那么问题是Response API它是什么东西

102
00:03:57,020 --> 00:03:57,680
对不对

103
00:03:57,680 --> 00:04:01,440
它怎么样来进行的解析

104
00:04:01,440 --> 00:04:05,180
那么非常完整的一次Response API的调用

105
00:04:05,180 --> 00:04:07,420
大家可以看这段代码

106
00:04:07,420 --> 00:04:10,040
那么这个代码实际上就是一次非常完整的

107
00:04:10,040 --> 00:04:10,840
非常底层的

108
00:04:10,840 --> 00:04:11,760
我们使用Python

109
00:04:11,760 --> 00:04:12,700
当然你使用这个

110
00:04:12,700 --> 00:04:14,420
使用这个TS

111
00:04:14,420 --> 00:04:16,000
其实也是类似的

112
00:04:16,000 --> 00:04:17,100
这样的语法规则

113
00:04:17,100 --> 00:04:19,460
来去完成一次通过Response API

114
00:04:19,460 --> 00:04:20,660
调用底层模型的

115
00:04:20,660 --> 00:04:22,480
一整个完整的这样的一个流程

116
00:04:22,480 --> 00:04:23,460
那它是什么样的呢

117
00:04:23,460 --> 00:04:24,640
首先我们需要

118
00:04:24,640 --> 00:04:27,580
这个import OpenAI

119
00:04:27,580 --> 00:04:28,580
就导入这样的库

120
00:04:28,580 --> 00:04:30,340
然后导入这个库之后

121
00:04:30,340 --> 00:04:31,500
接下来我们需要实力化

122
00:04:31,500 --> 00:04:32,680
一个OpenAI的客户端

123
00:04:32,680 --> 00:04:34,680
然后在OpenAI客户端里面

124
00:04:34,680 --> 00:04:36,060
输入你的Deepseek API key

125
00:04:36,060 --> 00:04:37,880
和Deepseek的这个base URL

126
00:04:37,880 --> 00:04:39,380
这个base URL是定死的

127
00:04:39,380 --> 00:04:40,600
然后这个Deepseek API key

128
00:04:40,600 --> 00:04:41,800
你需要自己去注册一个

129
00:04:41,800 --> 00:04:45,160
那么这里就实力化了一个open AI的这样的客户端

130
00:04:45,160 --> 00:04:46,900
然后有了这个客户端

131
00:04:46,900 --> 00:04:49,300
或者你可以把它理解成是一个负了值的

132
00:04:49,300 --> 00:04:52,620
一个open AI对象的一个实力化的一个对象

133
00:04:52,620 --> 00:04:53,260
就这么一回事

134
00:04:53,260 --> 00:04:59,140
然后接下来就可以调用client.response.create这样的一个命令

135
00:04:59,140 --> 00:05:03,800
就可以去获得一次对应的模型回复的这样的响应结果

136
00:05:03,800 --> 00:05:06,440
这里我们输入modal等于deep seek v4 flash

137
00:05:06,440 --> 00:05:09,220
然后这个instructor代表的含义

138
00:05:09,220 --> 00:05:10,860
实际上就是system prompt

139
00:05:10,860 --> 00:05:11,880
你可以这么来自己理解

140
00:05:11,880 --> 00:05:15,100
就是我们整个的agent运行的方式当中

141
00:05:15,100 --> 00:05:15,960
system prompt

142
00:05:15,960 --> 00:05:17,500
然后有一个input

143
00:05:17,500 --> 00:05:18,500
input代表的含义就是

144
00:05:18,500 --> 00:05:20,380
我现在跟他来进行的对话

145
00:05:20,380 --> 00:05:20,740
对不对

146
00:05:20,740 --> 00:05:22,820
然后下面还有其他的参数

147
00:05:22,820 --> 00:05:24,220
这下我们可以都不管

148
00:05:24,220 --> 00:05:25,820
然后通过这样的方式

149
00:05:25,820 --> 00:05:27,860
就可以完成一次模型的调用

150
00:05:27,860 --> 00:05:29,240
当然我这里给大家举的例子

151
00:05:29,240 --> 00:05:31,340
都是生成的英文的提出词

152
00:05:31,340 --> 00:05:32,680
但用中文也是一样的

153
00:05:32,680 --> 00:05:33,380
没有任何影响

154
00:05:33,380 --> 00:05:36,100
总之就可以完成一次对应的响应

155
00:05:36,100 --> 00:05:38,340
比如说我们这就可以让他来进行运行

156
00:05:38,340 --> 00:05:40,440
我这个是在线的这个环境

157
00:05:40,440 --> 00:05:41,540
就可以直接来进行运行

158
00:05:41,540 --> 00:05:42,440
也是一样对不对

159
00:05:42,440 --> 00:05:44,400
这个Response API

160
00:05:44,400 --> 00:05:46,700
先做好一个Client

161
00:05:46,700 --> 00:05:48,120
然后这Client

162
00:05:48,120 --> 00:05:49,960
然后接下来就可以跟他来进对话了

163
00:05:49,960 --> 00:05:50,720
就这么一回事

164
00:05:50,720 --> 00:05:52,200
那么这个Client

165
00:05:52,200 --> 00:05:55,080
实际上我们现在所说的这个Response API

166
00:05:55,080 --> 00:05:57,300
实际上就是这Client里面的一个方法

167
00:05:57,300 --> 00:06:01,320
通过他能够去获取一次又一次模型的响应结果

168
00:06:01,320 --> 00:06:02,900
是什么样的一个情况

169
00:06:02,900 --> 00:06:04,420
好

170
00:06:04,420 --> 00:06:07,880
那么对于我们当前的这个Response API来说

171
00:06:07,880 --> 00:06:10,180
其实它返回的这个结果里面

172
00:06:10,180 --> 00:06:11,700
包含的消息会非常多

173
00:06:11,700 --> 00:06:12,720
它会包含你的

174
00:06:12,720 --> 00:06:13,900
比如说Reasoning Item

175
00:06:13,900 --> 00:06:15,680
推理的字段的内容

176
00:06:15,680 --> 00:06:17,280
会包含这个Message的内容

177
00:06:17,280 --> 00:06:18,620
会包含这个Function Call

178
00:06:18,620 --> 00:06:19,840
就是你工具调用这个内容

179
00:06:19,840 --> 00:06:20,360
等等等等

180
00:06:20,360 --> 00:06:21,460
价格式各样这个内容

181
00:06:21,460 --> 00:06:23,620
然后这个Message里面还会包含

182
00:06:23,620 --> 00:06:25,580
它模型本身的output

183
00:06:25,580 --> 00:06:28,060
或者其他的一些警告

184
00:06:28,060 --> 00:06:29,440
拒绝的一些信息

185
00:06:29,440 --> 00:06:31,240
还有包括文本图像的一个信息

186
00:06:31,240 --> 00:06:31,720
等等等等

187
00:06:31,720 --> 00:06:32,740
也就是它实际上

188
00:06:32,740 --> 00:06:33,460
你可以把理解成

189
00:06:33,460 --> 00:06:35,760
就是一个完整的一种响应格式

190
00:06:35,760 --> 00:06:37,960
是这么样的一个基本的定位

191
00:06:37,960 --> 00:06:39,720
所以也是基于这样的响应格式

192
00:06:39,720 --> 00:06:43,720
我们才能够去很好的去跟当前大模型来进行对话

193
00:06:43,720 --> 00:06:46,660
能够把它的对应结果来进行一个输出

194
00:06:46,660 --> 00:06:47,900
来进行一个响应

195
00:06:47,900 --> 00:06:48,820
那么上面也是一样的

196
00:06:48,820 --> 00:06:49,480
我们又来了一遍

197
00:06:49,480 --> 00:06:52,300
这个Response API完整的执行流程

198
00:06:52,300 --> 00:06:54,160
那么只不过在执行的过程当中

199
00:06:54,160 --> 00:06:57,600
我们这里是考虑把每一个Response里面的所有内容

200
00:06:57,600 --> 00:06:58,580
单独给你打印出来

201
00:06:58,580 --> 00:07:00,420
来看一看它到底回复哪些东西

202
00:07:00,420 --> 00:07:03,140
那么它回复内容包括什么Response ID

203
00:07:03,140 --> 00:07:04,540
Response的State

204
00:07:04,540 --> 00:07:05,540
Response Model

205
00:07:05,540 --> 00:07:06,220
等等等等

206
00:07:06,220 --> 00:07:07,100
总之就是

207
00:07:07,100 --> 00:07:08,800
它的每一条消息回复里面

208
00:07:08,800 --> 00:07:10,660
实际上会包含我们当前

209
00:07:10,660 --> 00:07:13,720
所有的回复的内容

210
00:07:13,720 --> 00:07:15,680
所有当前模型运行的

211
00:07:15,680 --> 00:07:17,060
全部的这样的信息

212
00:07:17,060 --> 00:07:17,940
换而言之就是

213
00:07:17,940 --> 00:07:19,760
我们当前这样的模型

214
00:07:19,760 --> 00:07:21,960
在执行当前任务的时候

215
00:07:21,960 --> 00:07:23,100
所有的状态信息

216
00:07:23,100 --> 00:07:24,340
你可以这么来进行理解

217
00:07:24,340 --> 00:07:24,820
好

218
00:07:24,820 --> 00:07:27,940
那么它和另外一个

219
00:07:27,940 --> 00:07:29,900
就是我们经常会讨论的

220
00:07:29,900 --> 00:07:31,560
叫Chat Compilation API

221
00:07:31,560 --> 00:07:33,040
它们两者之间

222
00:07:33,040 --> 00:07:34,780
到底是什么样的一个

223
00:07:34,780 --> 00:07:36,840
什么样的区别

224
00:07:36,840 --> 00:07:38,980
这里我们是首先需要放在这

225
00:07:38,980 --> 00:07:40,120
来给大家来进行个探讨

226
00:07:40,120 --> 00:07:41,600
因为其实很多同学之前

227
00:07:41,600 --> 00:07:42,940
其实是了解

228
00:07:42,940 --> 00:07:45,100
OpenAI的Chat Compilations API的

229
00:07:45,100 --> 00:07:46,400
那么这里面

230
00:07:46,400 --> 00:07:48,440
我们说OpenAI是原上一版本的

231
00:07:48,440 --> 00:07:49,680
Chat Compilations API

232
00:07:49,680 --> 00:07:51,340
它的核心的功能

233
00:07:51,340 --> 00:07:53,440
是去围绕Message消息列表

234
00:07:53,440 --> 00:07:54,560
来进行编辑

235
00:07:54,560 --> 00:07:55,620
也就是说它实际上

236
00:07:55,620 --> 00:07:57,480
是去维护一个又一个消息列表

237
00:07:57,480 --> 00:07:58,440
那一个消息列表里面

238
00:07:58,440 --> 00:07:59,940
我们需要由System

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

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

241
00:08:14,600 --> 00:08:16,000
来进行一个测试

242
00:08:16,000 --> 00:08:17,760
然后最后的模型也给你返回出一个消息

243
00:08:17,760 --> 00:08:21,200
它返回消息的本质的也是一条消息

244
00:08:21,200 --> 00:08:23,880
所以原来的openAI它上一代的

245
00:08:23,880 --> 00:08:24,900
或者deep seek也是一样

246
00:08:24,900 --> 00:08:27,680
它之前支持的主要是chatcompletions API

247
00:08:27,680 --> 00:08:30,640
那么它那些主要是去维护一个消息列表

248
00:08:30,640 --> 00:08:33,100
而现在升级到了response API

249
00:08:33,100 --> 00:08:37,100
你会发现它实际上是维护你当前运行的一个状态

250
00:08:37,100 --> 00:08:39,120
所谓当前运行的状态

251
00:08:39,120 --> 00:08:41,740
就指的是我们现在在运行的过程当中

252
00:08:41,740 --> 00:08:45,020
一个模型它其实每次在进行响应的过程当中

253
00:08:45,020 --> 00:08:47,860
它会有很多很多的一些状态方面这样的信息

254
00:08:47,860 --> 00:08:50,240
而原来我们重点维护的消息列表

255
00:08:50,240 --> 00:08:52,720
你可以把理解成只是状态当中的一个维度

256
00:08:52,720 --> 00:08:53,640
仅此而已

257
00:08:53,640 --> 00:08:55,800
那么现在我们说借助Response API

258
00:08:55,800 --> 00:08:57,080
实际上对于开发者来说

259
00:08:57,080 --> 00:08:59,480
其实就能够非常便捷的把一些工具

260
00:08:59,480 --> 00:09:02,040
把一些这个extract给它放到一块

261
00:09:02,040 --> 00:09:03,800
就可以迅速的构成一个agent

262
00:09:03,800 --> 00:09:05,420
然后你只需要输入一个input

263
00:09:05,420 --> 00:09:08,900
它背后就可以完整的去执行一整个agent loop

264
00:09:08,900 --> 00:09:10,620
那所谓agent loop

265
00:09:10,620 --> 00:09:12,900
这点大家也可以这么理解一下

266
00:09:12,900 --> 00:09:14,820
就是我现在agent要调用一些工具

267
00:09:14,820 --> 00:09:16,380
来完成一些事项

268
00:09:16,380 --> 00:09:16,720
对不对

269
00:09:16,720 --> 00:09:17,820
那这工具有的时候

270
00:09:17,820 --> 00:09:20,660
我们需要多部的进行调用

271
00:09:20,660 --> 00:09:23,260
有的时候也需要并发的来进行调用

272
00:09:23,260 --> 00:09:23,560
对不对

273
00:09:23,560 --> 00:09:25,420
那原来我们需要实现多部

274
00:09:25,420 --> 00:09:26,840
或者并发的这样的工具调用

275
00:09:26,840 --> 00:09:28,760
你可能得编写更加复杂的

276
00:09:28,760 --> 00:09:29,400
这样的一个程序

277
00:09:29,400 --> 00:09:31,460
或者是用比如说像long chain

278
00:09:31,460 --> 00:09:32,580
这样的agent开发框架

279
00:09:32,580 --> 00:09:33,000
对不对

280
00:09:33,000 --> 00:09:35,020
它其实是支持内部

281
00:09:35,020 --> 00:09:37,560
去完成agent loop这样的工作的

282
00:09:37,560 --> 00:09:39,480
agent loop就是它不断不断去调用工具

283
00:09:39,480 --> 00:09:42,020
直到它能够完成当前的请求为止

284
00:09:42,020 --> 00:09:42,480
好

285
00:09:42,480 --> 00:09:43,920
现在我们说这些功能

286
00:09:43,920 --> 00:09:47,960
其实也是可以被responses API来去完成的

287
00:09:47,960 --> 00:09:51,380
这个其实是它的一个功能上面这样的进阶

288
00:09:51,380 --> 00:09:53,900
如果原来你是使用chat completion API的话

289
00:09:53,900 --> 00:09:56,080
你可能就需要不断的去维护它的消息例表

290
00:09:56,080 --> 00:09:57,980
其实整个过程会非常的繁琐

291
00:09:57,980 --> 00:10:00,180
如果你需要去实现agent loop的话

292
00:10:00,180 --> 00:10:01,740
其实你需要手动来进行搭建

293
00:10:01,740 --> 00:10:03,300
而现在是用responses API

294
00:10:03,300 --> 00:10:04,060
其实不需要

295
00:10:04,060 --> 00:10:07,040
它内部是可以帮你去全自动的

296
00:10:07,040 --> 00:10:09,140
完成agent loop这样的工作的

297
00:10:09,140 --> 00:10:12,020
所以其实对于Responses API来说

298
00:10:12,020 --> 00:10:13,820
它其实也就是你可以把它理解成

299
00:10:13,820 --> 00:10:15,500
就是一个类似于LongChain这样的一个

300
00:10:15,500 --> 00:10:17,880
agent和工具把它绑定一块的一个脚手架

301
00:10:17,880 --> 00:10:20,660
这个是它的一个基础的认知

302
00:10:20,660 --> 00:10:26,380
当然在OpenAI官方的给出的Responses API的说明里面

303
00:10:26,380 --> 00:10:27,780
它其实也有谈到说

304
00:10:27,780 --> 00:10:29,400
我们现在使用Responses API

305
00:10:29,400 --> 00:10:32,920
相比于上一代的Chat Completions API来说

306
00:10:32,920 --> 00:10:34,760
其实它的性能是增长了3%

307
00:10:34,760 --> 00:10:38,480
它是在terminal的榜单上

308
00:10:38,480 --> 00:10:40,560
它性能是增上了3%

309
00:10:40,560 --> 00:10:42,240
也就是说明有了框架

310
00:10:42,240 --> 00:10:43,720
去搭建一些agent

311
00:10:43,720 --> 00:10:45,640
实际上是能够更好的

312
00:10:45,640 --> 00:10:48,660
更加稳定的去维护这些agent运行的

313
00:10:48,660 --> 00:10:50,820
它是有这样的一个功能在这

314
00:10:50,820 --> 00:10:51,200
OK

315
00:10:51,200 --> 00:10:53,960
这个是所谓的Responses API

316
00:10:53,960 --> 00:10:56,960
当然我们说对于Responses API来说

317
00:10:56,960 --> 00:10:58,420
我们下面还有很多的一些

318
00:10:58,420 --> 00:11:01,200
大家可以课后自己再去来进行

319
00:11:01,200 --> 00:11:03,580
深度学习的一些内容和素材

320
00:11:03,580 --> 00:11:06,820
比如说它也是支持一些参数这样的调整的

321
00:11:06,820 --> 00:11:07,160
对不对

322
00:11:07,160 --> 00:11:08,780
比如说什么temperature

323
00:11:08,780 --> 00:11:12,440
还有topia这样的一些底层的模型运行参数

324
00:11:12,440 --> 00:11:13,200
这样的调整

325
00:11:13,200 --> 00:11:18,180
比如说你这个temperature调整的范围是在0到2之间

326
00:11:18,180 --> 00:11:20,420
然后temperature越高

327
00:11:20,420 --> 00:11:21,860
那么它生成结果越就越不稳定

328
00:11:21,860 --> 00:11:22,700
然后temperature越低

329
00:11:22,700 --> 00:11:24,140
它生成结果越稳定等等等等

330
00:11:24,140 --> 00:11:28,480
同时它也是支持直接通过一些json schema

331
00:11:28,480 --> 00:11:30,940
这个是来进行structured output

332
00:11:30,940 --> 00:11:32,260
就是结构化的输出

333
00:11:32,260 --> 00:11:33,220
那么结构化输出呢

334
00:11:33,220 --> 00:11:35,500
实际上在现在很多的agent开发场景下

335
00:11:35,500 --> 00:11:37,100
都会非常非常的重要

336
00:11:37,100 --> 00:11:37,480
对不对

337
00:11:37,480 --> 00:11:39,000
你可以通过类似这样的方式

338
00:11:39,000 --> 00:11:42,840
去设置好对应的这个结构化输出的

339
00:11:42,840 --> 00:11:44,980
这个结构化这个文本的这个要求

340
00:11:44,980 --> 00:11:45,640
然后呢

341
00:11:45,640 --> 00:11:47,760
把它直接带入到我们的

342
00:11:47,760 --> 00:11:50,080
Responses API的这个text参数里面去

343
00:11:50,080 --> 00:11:52,100
就让它能够进行结构化的输出了

344
00:11:52,100 --> 00:11:52,840
是这么一回事

345
00:11:52,840 --> 00:11:54,140
当然我们现在公开课

346
00:11:54,140 --> 00:11:55,860
其实一般来说就不会围绕

347
00:11:55,860 --> 00:11:56,940
比如说结构化输出里面

348
00:11:56,940 --> 00:11:58,640
具体它是规定哪些结构

349
00:11:58,640 --> 00:12:00,140
这个Json schema的这个对象

350
00:12:00,140 --> 00:12:01,540
到底代表什么样的含义

351
00:12:01,540 --> 00:12:02,600
来展开来说

352
00:12:02,600 --> 00:12:03,860
实际上也是因为

353
00:12:03,860 --> 00:12:05,660
这东西都可以让大模型来完成

354
00:12:05,660 --> 00:12:07,060
重点是你需要知道的是

355
00:12:07,060 --> 00:12:08,500
有这个responsive API之后

356
00:12:08,500 --> 00:12:10,740
它的结果化输出会非常稳定

357
00:12:10,740 --> 00:12:13,400
是这么样的一个情况

358
00:12:13,400 --> 00:12:14,520
具体怎么稳定

359
00:12:14,520 --> 00:12:16,160
它其实有很多层的检验

360
00:12:16,160 --> 00:12:18,400
什么text format

361
00:12:18,400 --> 00:12:20,320
一层的检验

362
00:12:20,320 --> 00:12:22,260
返回结果的Json格式的

363
00:12:22,260 --> 00:12:23,760
一层本地的教验

364
00:12:23,760 --> 00:12:26,780
最后再给你返回一个结果化输出

365
00:12:26,780 --> 00:12:27,440
这样的文本

366
00:12:27,440 --> 00:12:30,640
它是可以经过多层的教验和反馈

367
00:12:30,640 --> 00:12:33,020
最后给你输出一个结构化的文本

368
00:12:33,020 --> 00:12:34,640
这个其实是没有什么问题的

369
00:12:34,640 --> 00:12:36,960
然后同时对于Response API来说

370
00:12:36,960 --> 00:12:39,680
它还有非常关键的Tours的参数

371
00:12:39,680 --> 00:12:40,060
对不对

372
00:12:40,060 --> 00:12:42,000
Tours的参数我们一会儿就看到

373
00:12:42,000 --> 00:12:44,100
它其实和Launcher里面的Tours的参数

374
00:12:44,100 --> 00:12:45,440
实际上就是一样的

375
00:12:45,440 --> 00:12:46,740
给它输入一个工具

376
00:12:46,740 --> 00:12:47,800
然后它就可以调用这工具

377
00:12:47,800 --> 00:12:49,440
来完成对应的工作

378
00:12:49,440 --> 00:12:50,580
是怎么样的情况

379
00:12:50,580 --> 00:12:53,180
所以对于整个的Response API来说

380
00:12:53,180 --> 00:12:55,040
核心样的参数就这么些

381
00:12:55,040 --> 00:12:57,600
模型instruction系统开发指令

382
00:12:57,600 --> 00:12:58,280
对不对input

383
00:12:58,280 --> 00:13:00,460
本次任务的基本请求

384
00:13:00,460 --> 00:13:03,480
然后还有这个什么maxoutputtoken

385
00:13:03,480 --> 00:13:05,700
这个最高的模型输出结果上线

386
00:13:05,700 --> 00:13:07,640
还有这个temperaturetoppr reasoning

387
00:13:07,640 --> 00:13:08,600
对它推理强度

388
00:13:08,600 --> 00:13:09,360
刚不说了吗

389
00:13:09,360 --> 00:13:10,460
这个V4这个模型

390
00:13:10,460 --> 00:13:11,800
有三档推理强度

391
00:13:11,800 --> 00:13:13,820
然后下面还有这个text

392
00:13:13,820 --> 00:13:16,680
主要是去进行结构化输出的一些参数

393
00:13:16,680 --> 00:13:17,500
然后还有这个tours

394
00:13:17,500 --> 00:13:19,740
是可以绑定一些外部的这样的工具

395
00:13:19,740 --> 00:13:21,140
然后它还有这个tourchoice

396
00:13:21,140 --> 00:13:22,060
代表的含义是

397
00:13:22,060 --> 00:13:23,220
我们每次运行的时候

398
00:13:23,220 --> 00:13:24,780
指定的工具来进行运行

399
00:13:24,780 --> 00:13:25,820
还有这个stream

400
00:13:25,820 --> 00:13:26,260
对不对

401
00:13:26,260 --> 00:13:27,820
流式打印等等等等

402
00:13:27,820 --> 00:13:28,900
有很多很多这些参数

403
00:13:28,900 --> 00:13:30,320
基本上如果你看这参数

404
00:13:30,320 --> 00:13:33,580
你会感觉他整个的运行的状态

405
00:13:33,580 --> 00:13:38,940
差不多就和LongChain的CreateAgent是非常类似的

406
00:13:38,940 --> 00:13:39,360
对不对

407
00:13:39,360 --> 00:13:44,160
那这个是现在对于DeepSeq V4正式版模型来说

408
00:13:44,160 --> 00:13:46,940
他所选择的一套基本的API

409
00:13:46,940 --> 00:13:49,640
当然下面还有关于什么流失打印

410
00:13:49,640 --> 00:13:51,080
是怎么样来进行操作的

411
00:13:51,080 --> 00:13:53,400
这一点大家也可以自己去看一下

412
00:13:53,400 --> 00:13:57,280
下面还有对应的可以来进行测试和运行的代码

413
00:13:57,280 --> 00:13:59,180
关于流失打印其实也是一样的

414
00:13:59,180 --> 00:14:00,500
就是人工讲应起来

415
00:14:00,500 --> 00:14:00,920
其实会非常

416
00:14:00,920 --> 00:14:02,900
其实人工编写其实非常麻烦

417
00:14:02,900 --> 00:14:04,480
但是对于现在的agent来说

418
00:14:04,480 --> 00:14:05,940
他们编写其实非常简单

419
00:14:05,940 --> 00:14:06,760
所以你只需要知道

420
00:14:06,760 --> 00:14:08,740
他其实这个是可以非常顺利的

421
00:14:08,740 --> 00:14:09,820
来进行实现的

422
00:14:09,820 --> 00:14:10,480
就没有什么问题

423
00:14:10,480 --> 00:14:11,460
然后同时

424
00:14:11,460 --> 00:14:13,760
他由于是维护每次运行的状态

425
00:14:13,760 --> 00:14:16,240
所以他也是可以把之前对话状态

426
00:14:16,240 --> 00:14:17,040
给他传入进去的

427
00:14:17,040 --> 00:14:19,760
把之前对话状态传入进去

428
00:14:19,760 --> 00:14:20,620
实际上相当于是

429
00:14:20,620 --> 00:14:22,800
把上一次任务执行记录的全部信息

430
00:14:22,800 --> 00:14:25,300
包括上一次咱们对话这个信息

431
00:14:25,300 --> 00:14:26,240
都给他输入进去

432
00:14:26,240 --> 00:14:28,500
然后他就可以来实现多种对话了

433
00:14:28,500 --> 00:14:29,100
就这么一回事

434
00:14:29,100 --> 00:14:34,700
这个其实是它的多轮对话的历史保存的一个基本的方法

435
00:14:34,700 --> 00:14:39,900
就是把它的之前上一轮的response id给它传入进去

436
00:14:39,900 --> 00:14:43,300
那么它接下来就可以顺利的来进行多轮对话了

437
00:14:43,300 --> 00:14:45,400
这个是它的一个基本设置

438
00:14:45,400 --> 00:14:49,700
然后同时下面还有关于function calling的完整的外部循环

439
00:14:49,700 --> 00:14:51,860
就是我们现在要去定一个外部工具

440
00:14:51,860 --> 00:14:52,300
对不对

441
00:14:52,300 --> 00:14:54,100
你这个什么查询天气的外部工具

442
00:14:54,100 --> 00:14:55,700
各式各样的外部工具

443
00:14:55,700 --> 00:14:59,000
包括这里面是个结构化信息的匹配的一个外部工具

444
00:14:59,000 --> 00:15:03,320
等等等等 都可以通类似使用类似这样的方式来进行一个定义

445
00:15:03,320 --> 00:15:07,720
定义好了外部工具之后 接下来在Responses API里面直接输入tools

446
00:15:07,720 --> 00:15:11,960
然后把你的工具给它放进去 然后它就可以顺带进行运行 就这么简单

447
00:15:11,960 --> 00:15:16,440
当然如果你去拆 如果你去看它底层的响应的过程的话

448
00:15:16,440 --> 00:15:20,920
这里其实就是一个我们去看它底层响应的过程完整的事例了

449
00:15:20,920 --> 00:15:24,760
那么你会发现 它其实底层仍然还是一个function calling的完整流程

450
00:15:24,760 --> 00:15:27,880
就是你给它关联工具之后 你先给工具发送个请求

451
00:15:27,880 --> 00:15:30,280
然后公共运行完了之后呢 给你一个function response message

452
00:15:30,280 --> 00:15:32,280
然后你接收到function response message之后呢

453
00:15:32,280 --> 00:15:34,080
再开启你的second response啊

454
00:15:34,080 --> 00:15:36,280
就是再去结合最开始用户的问题啊

455
00:15:36,280 --> 00:15:38,280
去给用户来进行回复啊 是这么一回事啊

456
00:15:38,280 --> 00:15:40,680
所以这个呢实际上是一个验证的过程啊

457
00:15:40,680 --> 00:15:42,880
你要说一下啊 对于response API来说呢

458
00:15:42,880 --> 00:15:44,680
他的这个也是一样的

459
00:15:44,680 --> 00:15:48,080
他的这个工具要用其本质上啊 也是这个function calling啊

460
00:15:48,080 --> 00:15:51,680
跟现在所有的其他的这个agent开发框架的这个function calling啊

461
00:15:51,680 --> 00:15:52,680
也全部都是一样的

462
00:15:52,680 --> 00:15:56,080
当然他其实非常完善好 整个response API里面

463
00:15:56,080 --> 00:15:57,680
他其实有非常完善的功能

464
00:15:57,680 --> 00:15:59,700
包括它工具室外的时候

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

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

467
00:16:20,960 --> 00:16:27,360
完整接入到Codex里面去 并且能完整的释放现在Codex的完整性能 这个其实做不到

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

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

470
00:16:40,560 --> 00:16:43,480
所以我们可能就不像之前的公块课一样

471
00:16:43,480 --> 00:16:45,940
围绕每一个API的每一行代码来进行讲解

472
00:16:45,940 --> 00:16:47,980
因为现在来看其实意义不是很大

473
00:16:47,980 --> 00:16:49,560
你总之你核心是要知道

474
00:16:49,560 --> 00:16:51,520
这个Response API到底是干什么的

475
00:16:51,520 --> 00:16:53,080
这点其实会非常重要

476
00:16:53,080 --> 00:16:55,800
当然下面我们其实是围绕Response API

477
00:16:55,800 --> 00:16:56,940
做了一个小小的实验

478
00:16:56,940 --> 00:16:59,820
我们来搭建了一个简单的一个agent

479
00:16:59,820 --> 00:17:02,560
然后这个agent基本上就是

480
00:17:02,560 --> 00:17:04,940
现在有很多很多张表

481
00:17:04,940 --> 00:17:07,320
然后我们来做一个简单的数据分析

482
00:17:07,320 --> 00:17:09,400
然后核心是从各个表当中

483
00:17:09,400 --> 00:17:11,680
来进行数据提取跟数据查询

484
00:17:11,680 --> 00:17:15,180
当然我们这里为什么跟大家去先使用这个Response API

485
00:17:15,180 --> 00:17:16,200
搭建一个简单的数据分析

486
00:17:16,200 --> 00:17:17,640
因为从下一个小节开始

487
00:17:17,640 --> 00:17:20,800
我们在使用Codex这样更加复杂的工具的时候

488
00:17:20,800 --> 00:17:23,300
实际上我们最后的目标这不就是搭建

489
00:17:23,300 --> 00:17:23,780
对不对

490
00:17:23,780 --> 00:17:25,880
长成这样的一个数据分析系统吗

491
00:17:25,880 --> 00:17:29,100
只不过我们现在从最底层的API出发

492
00:17:29,100 --> 00:17:30,240
一点点来进行学习

493
00:17:30,240 --> 00:17:33,980
到最后能搭建这么一个比较复杂的数据分析系统

494
00:17:33,980 --> 00:17:35,460
其实有很长的路要走

495
00:17:35,460 --> 00:17:38,000
所以我们在最一开始就给大家举一个小例子

496
00:17:38,000 --> 00:17:41,660
如果我们现在是使用Response API来搭建一个数据分析系统的话

497
00:17:41,660 --> 00:17:42,700
那么未来它是一个

498
00:17:42,700 --> 00:17:45,980
那么它首先这第一步应该怎么卖出去

499
00:17:45,980 --> 00:17:48,860
然后我们再来考虑使用这Codex之后

500
00:17:48,860 --> 00:17:53,240
你整个搭建数据分析系统的效率跟速度就可以起飞

501
00:17:53,240 --> 00:17:53,580
对不对

502
00:17:53,580 --> 00:17:56,480
我们来一步一步来看它是怎么样来进行运行的

503
00:17:56,480 --> 00:17:58,480
当然这里我们涉及到一个数据集

504
00:17:58,480 --> 00:17:59,640
叫Allist

505
00:17:59,640 --> 00:18:02,120
它是巴西电商公司的一个开源数据集

506
00:18:02,120 --> 00:18:04,380
这个数据集其实非常庞大

507
00:18:04,380 --> 00:18:08,040
里面总共有这么十几万行的这个数据

508
00:18:08,040 --> 00:18:09,580
那这个数据集也是我们之后

509
00:18:09,580 --> 00:18:13,380
在做我们当前整个数据分析系统的性能测试的时候

510
00:18:13,380 --> 00:18:14,560
最核心的这个数据集

511
00:18:14,560 --> 00:18:15,380
所以大家可以看一下

512
00:18:15,380 --> 00:18:18,360
当然其实对于所谓这个电商的这个数据

513
00:18:18,360 --> 00:18:20,460
其实主要是分成这么两大类

514
00:18:20,460 --> 00:18:21,820
一个是orders

515
00:18:21,820 --> 00:18:23,060
一个是customers

516
00:18:23,060 --> 00:18:25,720
这么两类的这个数据表格

517
00:18:25,720 --> 00:18:28,000
它这个数据集不是一个单独的数据集

518
00:18:28,000 --> 00:18:30,580
是分了好多好多好多个这个子数据的这个数据集

519
00:18:30,580 --> 00:18:32,580
然后这个orders就是你订单

520
00:18:32,580 --> 00:18:34,220
然后customer就是当前的客户

521
00:18:34,220 --> 00:18:35,420
等等非常非常多

522
00:18:35,420 --> 00:18:40,580
总之近期订单历史订单非常非常多

523
00:18:40,580 --> 00:18:42,760
总共是一个世界外行的数据表格

524
00:18:42,760 --> 00:18:45,620
那么这个数据表其实会有点复杂

525
00:18:45,620 --> 00:18:48,400
我们一会儿都会看到这个数据表里面完整的内容

526
00:18:48,400 --> 00:18:49,740
总之大家需要知道是

527
00:18:49,740 --> 00:18:50,920
哎呀 这里有个数据表格

528
00:18:50,920 --> 00:18:53,360
好 那么如果你现在想要使用

529
00:18:53,360 --> 00:18:55,360
比如说Deepseek v4这样的模型

530
00:18:55,360 --> 00:18:58,700
搭配着它现在已经兼容的Responsees API

531
00:18:58,700 --> 00:19:00,500
去搭建一个数据分析系统

532
00:19:00,500 --> 00:19:03,760
大家可以想想看有哪一些想法

533
00:19:03,760 --> 00:19:04,280
对不对

534
00:19:04,280 --> 00:19:06,000
其实我们对于现在的agent开发来说

535
00:19:06,000 --> 00:19:08,100
首先你得有一个基本的思路

536
00:19:08,100 --> 00:19:09,840
和一些基础的想法

537
00:19:09,840 --> 00:19:11,560
可能我们就会涉及到

538
00:19:11,560 --> 00:19:13,440
比如说我现在数据库

539
00:19:13,440 --> 00:19:14,780
数据存储的数据库里面

540
00:19:14,780 --> 00:19:16,520
所以我需要有一些

541
00:19:16,520 --> 00:19:19,120
从数据库里面取出数据的这样的工具

542
00:19:19,120 --> 00:19:19,720
对不对

543
00:19:19,720 --> 00:19:21,680
然后也需要有一些

544
00:19:21,680 --> 00:19:23,840
我们去查询数据这样的工具

545
00:19:23,840 --> 00:19:26,700
然后同时还需要有一些读取数据的工具

546
00:19:26,700 --> 00:19:28,320
然后同时还需要有一些

547
00:19:28,320 --> 00:19:31,100
查询具体的每一个数据里面的

548
00:19:31,100 --> 00:19:32,120
航和列之间的工具

549
00:19:32,120 --> 00:19:34,060
这里面其实我们是给出一系列工具

550
00:19:34,060 --> 00:19:35,040
列出数据表格

551
00:19:35,040 --> 00:19:37,240
然后查询每一个数据表

552
00:19:37,240 --> 00:19:38,500
什么来源表明

553
00:19:38,500 --> 00:19:39,800
然后什么查询

554
00:19:39,800 --> 00:19:41,220
什么每一个数据的

555
00:19:41,220 --> 00:19:42,560
这个原数据

556
00:19:42,560 --> 00:19:43,220
它的来源

557
00:19:43,220 --> 00:19:45,020
它的最大最大行数

558
00:19:45,020 --> 00:19:47,360
它的编写设计数代码来进行运行

559
00:19:47,360 --> 00:19:48,560
同时还需要

560
00:19:48,560 --> 00:19:51,140
去创建

561
00:19:51,140 --> 00:19:53,640
去实现一个能够单独去创建数据集的

562
00:19:53,640 --> 00:19:55,000
这样的一个外部工具等等

563
00:19:55,000 --> 00:19:58,160
这个其实是我们现在的建议数据分析的过程当中

564
00:19:58,160 --> 00:19:59,180
我们最核心

565
00:19:59,180 --> 00:20:00,060
最常用的

566
00:20:00,060 --> 00:20:01,560
无聊数据库来进行操作的啊

567
00:20:01,560 --> 00:20:02,860
是像四项工具啊

568
00:20:02,860 --> 00:20:03,540
列数表格

569
00:20:03,540 --> 00:20:04,020
对不对

570
00:20:04,020 --> 00:20:05,360
查他的这个原数据啊

571
00:20:05,360 --> 00:20:07,200
就是查这个数据表格的这个真实情况

572
00:20:07,200 --> 00:20:08,240
然后呢编写circle啊

573
00:20:08,240 --> 00:20:09,420
来进行这个读数啊

574
00:20:09,420 --> 00:20:10,620
然后呢去创建表格

575
00:20:10,620 --> 00:20:11,760
把这个数据给取出来啊

576
00:20:11,760 --> 00:20:13,240
基本上我们说这四个工具呢

577
00:20:13,240 --> 00:20:14,340
是非常核心的

578
00:20:14,340 --> 00:20:15,220
这么四个工具

579
00:20:15,220 --> 00:20:15,420
好

580
00:20:15,420 --> 00:20:15,980
那么下面啊

581
00:20:15,980 --> 00:20:17,420
其实就是关于这四工具的

582
00:20:17,420 --> 00:20:19,620
这样的一个定义的这个方法了啊

583
00:20:19,620 --> 00:20:20,380
那么这里面呢

584
00:20:20,380 --> 00:20:22,420
其实各个不同类型的这个工具啊

585
00:20:22,420 --> 00:20:22,740
他呢

586
00:20:22,740 --> 00:20:23,740
其实呃

587
00:20:23,740 --> 00:20:25,060
我们上面他的具体的功能

588
00:20:25,060 --> 00:20:26,240
其实定义还是非常清楚的啊

589
00:20:26,240 --> 00:20:27,660
这里我们都是使用的python

590
00:20:30,060 --> 00:20:32,060
Sirco查询的一些工具

591
00:20:32,060 --> 00:20:33,800
其实它背后的核心实现逻辑

592
00:20:33,800 --> 00:20:35,860
就是把用户的输入的语言

593
00:20:35,860 --> 00:20:37,080
把它转换成对应的Sirco代码

594
00:20:37,080 --> 00:20:39,260
然后把它再去检查一下

595
00:20:39,260 --> 00:20:40,740
Sirco代码本身这样的格式

596
00:20:40,740 --> 00:20:41,920
那么接下来就可以来进行运行

597
00:20:41,920 --> 00:20:45,540
就这么样的一个基本的使用方法

598
00:20:45,540 --> 00:20:49,040
下面就是这些工具的一些创建这样的方式

599
00:20:49,040 --> 00:20:51,360
然后紧接着我们就可以把这工具

600
00:20:51,360 --> 00:20:55,720
给它关联到我们当前的Responses API里边来

601
00:20:55,720 --> 00:20:57,940
那么接下来下面有一个Stream

602
00:20:57,940 --> 00:20:59,160
就打印的这样的方式

603
00:20:59,160 --> 00:20:59,800
那么接下来呢

604
00:20:59,800 --> 00:21:01,640
我们说你的一个极简的啊

605
00:21:01,640 --> 00:21:03,380
一个简易的这个agent啊

606
00:21:03,380 --> 00:21:04,940
实际上就相当于是完成了啊

607
00:21:04,940 --> 00:21:06,940
当然我们这里其实有个每一个

608
00:21:06,940 --> 00:21:09,100
有每一个的这个外部函数

609
00:21:09,100 --> 00:21:11,780
它具体完整的这样的这个定义方法啊

610
00:21:11,780 --> 00:21:12,300
这里面呢

611
00:21:12,300 --> 00:21:13,540
会有大家可以自己去看一下啊

612
00:21:13,540 --> 00:21:14,940
因为实际上我们说啊

613
00:21:14,940 --> 00:21:16,460
这个每个外部函数的这个定义呢

614
00:21:16,460 --> 00:21:17,720
都会比较复杂啊

615
00:21:17,720 --> 00:21:19,640
但是这里面先给大家简单的啊

616
00:21:19,640 --> 00:21:20,860
留下一个这个印象啊

617
00:21:20,860 --> 00:21:22,180
就是对于现在的

618
00:21:22,180 --> 00:21:23,340
我们在进行啊

619
00:21:23,340 --> 00:21:24,820
这个agent的开发过程当中啊

620
00:21:24,820 --> 00:21:26,620
那么如果你需要去搭建一个

621
00:21:26,620 --> 00:21:28,200
数据分析的这样的agent的话

622
00:21:28,200 --> 00:21:31,420
然后如果你现在去使用这个Responses API的话

623
00:21:31,420 --> 00:21:33,120
实际上实现起来会非常简单

624
00:21:33,120 --> 00:21:34,800
我们说你只需要定义好

625
00:21:34,800 --> 00:21:37,460
我们刚刚所说的拥有这些功能的外部函数

626
00:21:37,460 --> 00:21:41,820
然后把这函数和我们当前的model模型放在一块

627
00:21:41,820 --> 00:21:43,520
对不对来进行一个封装

628
00:21:43,520 --> 00:21:47,060
然后最后它就可以直接就是一个简单的agent

629
00:21:47,060 --> 00:21:48,720
就可以直接顺利来进行运行

630
00:21:48,720 --> 00:21:49,480
就这么回事

631
00:21:49,480 --> 00:21:52,360
但这里其实会具体涉及到很多的一些代码

632
00:21:52,360 --> 00:21:54,740
就比如说我们如何把自然预言转化成sicle

633
00:21:54,740 --> 00:21:55,300
对不对

634
00:21:55,300 --> 00:21:59,900
然后呢Sircle本身这样代码如何去提升它的这样的准确性等等等等

635
00:21:59,900 --> 00:22:03,360
那么这个可能就属于这个比较进阶的一些功能了

636
00:22:03,360 --> 00:22:06,140
这个我们公开课可能就没有时间展开来说了

637
00:22:06,140 --> 00:22:09,040
但是呢这里给大家提供的所有的这些代码呢

638
00:22:09,040 --> 00:22:12,380
实际上每个代码都是可以真实的来进行运行的

639
00:22:12,380 --> 00:22:14,200
然后呢大家如果感兴趣的话

640
00:22:14,200 --> 00:22:16,260
课后呢可以单独再去看一下这个代码

641
00:22:16,260 --> 00:22:19,800
或者你也可以直接能把它导到你本地的这个环境里边去

642
00:22:19,800 --> 00:22:23,560
让它呢反正我们说每一个这个核心的这个外部函数

643
00:22:23,560 --> 00:22:26,560
我们下面都有完整脚本和它的功能的这样的定义

644
00:22:26,560 --> 00:22:29,500
你可以直接用它来进行的使用也是ok的

645
00:22:29,500 --> 00:22:31,840
只不过这里我们就跟大家说的一点

646
00:22:31,840 --> 00:22:35,120
是其实对于当前的Response API来说

647
00:22:35,120 --> 00:22:37,280
如果你想创建一个数据分析agent

648
00:22:37,280 --> 00:22:38,940
我知不知道它也可以非常简单

649
00:22:38,940 --> 00:22:39,500
对不对

650
00:22:39,500 --> 00:22:42,740
我们无非就是我的工具给它封闹到一起去

651
00:22:42,740 --> 00:22:44,660
然后用户输入一个业务的问题

652
00:22:44,660 --> 00:22:46,640
我们就看需要使用哪些工具

653
00:22:46,640 --> 00:22:47,240
对不对

654
00:22:47,240 --> 00:22:49,180
然后通过Response API

655
00:22:49,180 --> 00:22:50,800
它本质上实际上是一个agent loop

656
00:22:50,800 --> 00:22:55,440
它是一个不断循环的这样的一个操作

657
00:22:55,440 --> 00:22:58,620
它就会不断的尝试去调用各式各样的工具

658
00:22:58,620 --> 00:23:00,240
来进行多部工具调用

659
00:23:00,240 --> 00:23:02,220
或者工具的这样的并发使用等等

660
00:23:02,220 --> 00:23:05,200
然后最后完成了

661
00:23:05,200 --> 00:23:07,600
最后就给输出一段最终这样的结果

662
00:23:07,600 --> 00:23:11,420
然后最后我们也可以让它去绘制一些表格等等

663
00:23:11,420 --> 00:23:13,760
它其实基本上就是这么样的一个过程

664
00:23:13,760 --> 00:23:14,720
但是它底层

665
00:23:14,720 --> 00:23:16,900
我们说上面其实大模型的运行的层

666
00:23:16,900 --> 00:23:20,560
底层实际上我们肯定是需要有维护的收据库

667
00:23:20,560 --> 00:23:25,660
这里其实我们默认的数据库是CircleLite和MyCircle这么两种数据库

668
00:23:25,660 --> 00:23:30,880
然后那么无非就是下来我们上面各式各样生产出来的消息

669
00:23:30,880 --> 00:23:34,920
或者你的Circle从你的数据库当中具体来进行运行等等

670
00:23:34,920 --> 00:23:36,300
然后运行完了之后

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

672
00:23:41,700 --> 00:23:44,020
然后共同回复用户当前这样的问题

673
00:23:44,020 --> 00:23:45,360
就是这样的一个过程

674
00:23:45,360 --> 00:23:48,460
所以其实现在我们在进行Agent的开发过程当中

675
00:23:48,460 --> 00:23:51,420
本质上其实如果说最底层的话

676
00:23:51,420 --> 00:23:52,860
无非就是创建好工具

677
00:23:52,860 --> 00:23:56,140
然后和你当前的agent给他放在一块

678
00:23:56,140 --> 00:23:58,020
然后最后来进行一些测试

679
00:23:58,020 --> 00:23:58,920
来进行运行

680
00:23:58,920 --> 00:24:00,880
看一下能不能够来进行顺利的运行

681
00:24:00,880 --> 00:24:02,080
上面我们最下面

682
00:24:02,080 --> 00:24:03,220
最上面这个脚本

683
00:24:03,220 --> 00:24:04,280
最后面这两个脚本

684
00:24:04,280 --> 00:24:07,960
实际上是去查询我们当前的数据

685
00:24:07,960 --> 00:24:10,660
它一段时间的销量的结果

686
00:24:10,660 --> 00:24:12,000
它的各式各样的

687
00:24:12,000 --> 00:24:15,280
巴西店商各式各样不同品类的这样的商品

688
00:24:15,280 --> 00:24:19,420
它实际上销量的一个分布情况

689
00:24:19,420 --> 00:24:23,220
这个是我们来进行的一个查询

690
00:24:23,220 --> 00:24:25,200
然后最后生成了一张图片

691
00:24:25,200 --> 00:24:26,240
是这么一回事

692
00:24:26,240 --> 00:24:29,200
那么实际上具体运行脚本和代码

693
00:24:29,200 --> 00:24:30,880
实际上就是上面这些脚本和代码

694
00:24:30,880 --> 00:24:34,080
这个是在数据库中查询数据的一个完整的脚本

695
00:24:34,080 --> 00:24:36,140
那下面是查询完数据之后

696
00:24:36,140 --> 00:24:38,520
生成最终运行结果的这样的脚本

697
00:24:38,520 --> 00:24:42,800
那么里面实际上本质上都是去关联到我们当前agent

698
00:24:42,800 --> 00:24:44,500
来进行一轮又轮的运行

699
00:24:44,500 --> 00:24:45,300
是怎么样一回事