0:00.000–0:01.531
zh那么紧接着我们就来看看,
0:01.531–0:04.720
zhResponse API到底应该如何上手来进行使用。
0:04.720–0:09.139
zh这个其实是我们现在在去做开发的过程当中,
0:09.139–0:14.000
zh可能都需要会涉及到一些底层的通信格式的讲解。
0:14.000–0:15.303
zh当然如果是去年的话,
0:15.303–0:16.997
zh这部分内容应该是非常核心,
0:16.997–0:18.720
zh非常重要的一部分的内容。
0:18.720–0:20.400
zh还有底层的开发范式,对不对?
0:20.400–0:22.680
zhOpenAI的Response API,
0:22.680–0:25.560
zh还有之前的ChatComplations API,
0:25.560–0:27.240
zh这都是我们将用大模型的基础。
0:27.240–0:30.080
zh到现在在webcoding时代
0:30.080–0:30.900
zh这些很多功能
0:30.900–0:32.200
zh我们其实都可以让大模型
0:32.200–0:32.820
zh帮我们完成
0:32.820–0:34.520
zh所以像这部分内容
0:34.520–0:35.560
zh仍然是很重要
0:35.560–0:37.120
zh但是我们可能就不需要
0:37.120–0:39.140
zh去特别深入的吸引到
0:39.140–0:39.920
zh每一行代码
0:39.920–0:40.700
zh每一个参数
0:40.700–0:41.820
zh分别代表什么样的含义
0:41.820–0:43.040
zh这个程度来进行理解
0:43.040–0:43.900
zh你只需要知道是
0:43.900–0:45.120
zh它是干什么的
0:45.120–0:46.020
zh有什么用
0:46.020–0:47.760
zh以及你能怎么用
0:47.760–0:49.340
zh这个东西其实是最重要的
0:49.340–0:50.760
zh那么我们接下来就来看看
0:50.760–0:53.200
zhOpenAI的Responses API
0:53.200–0:54.200
zh到底是什么
0:54.200–0:56.480
zh当然这里大家如果不太了解
0:56.480–0:58.220
zh这个Response API到底是什么的话
0:58.220–1:00.940
zh你可以把它想象成就是OpenAI版的LongChain
1:00.940–1:04.140
zh专门负责给我们开发者一个接口
1:04.140–1:06.820
zh去更好的去调用这样的一些大模型
1:06.820–1:10.100
zh然后把它们和一些工具给它绑在一块
1:10.100–1:11.620
zh最后做成一个Agent
1:11.620–1:12.840
zh就是这样的一个API
1:12.840–1:14.140
zh可以这么来进行理解
1:14.140–1:16.120
zh当然其实这个Response API
1:16.120–1:17.580
zh是去年3月11号
1:17.580–1:22.440
zhOpenAI正式开源的一个全新的一种大模型调度的一种方法
1:22.440–1:25.240
zh然后官网在OpenAI官网上也有非常详细的
1:25.240–1:28.500
zh关于使用这个Response API的一些好处啊
1:28.500–1:32.300
zh和怎么去进行迁移呀的一些这个方法啊
1:32.300–1:33.780
zh当然这里我们要说明的是
1:33.780–1:36.980
zh其实每一家啊大保险厂商都有资格的啊
1:36.980–1:38.700
zh这个API的调度的这个范式
1:38.700–1:40.560
zh比如说对于这个
1:40.560–1:42.880
zhAnthelope来说啊
1:42.880–1:45.460
zh他们呢自己有一套Anthelope API啊
1:45.460–1:47.680
zh还有一套Cloud Agents SDK啊
1:47.680–1:49.360
zh那么对于OpenAI来说呢
1:49.360–1:51.480
zh他们家啊有这个Response API啊
1:51.480–1:53.880
zh和Agent SDK啊两套开发框架啊
1:53.880–2:00.700
zh这个其实每一家他们都会有推出一些适配自己家模型的一些agent通信和开发范式
2:00.700–2:01.600
zh是这么一回事
2:01.600–2:03.240
zh那么对于openAI来说
2:03.240–2:10.640
zh他们其实当然这个responses API就是现在他们来进行模型调度的过程当中最核心的响应的这样的方法
2:10.640–2:13.280
zh然后对于这个deep seek来说
2:13.280–2:17.000
zh他现在是接入到了responses API这功能体系里面来
2:17.000–2:19.760
zh当然这里其实有一个很有意思的一个点
2:19.760–2:22.380
zh就在于说其实之前有同学会问到说
2:22.380–2:27.280
zhDeepseek他们是怎么去考虑去接入OpenAI的Response API的呢
2:27.280–2:28.640
zh当然我们说对Deepseek来说
2:28.640–2:30.840
zh他一旦接入OpenAI这个Response API之后
2:30.840–2:33.780
zh他实际上就可以无缝的接入Codex的体系了
2:33.780–2:35.060
zh那他是怎么接入的呢
2:35.060–2:35.680
zh其实非常简单
2:35.680–2:36.940
zh就是在后训练的过程当中
2:36.940–2:40.960
zh给了他很多的一些指令方面的训练集
2:40.960–2:45.860
zh让他的响应格式能够和Response API的响应格式来进行兼容
2:45.860–2:48.720
zh这里其实就会说的会比较底层了
2:48.720–2:49.760
zh因为其实大家知道
2:49.760–2:51.580
zh对于任何大模型来说
2:51.580–2:53.760
zh它原始的这个输出这个内容
2:53.760–2:55.680
zh实际上就是一个又一个token
2:55.680–2:57.440
zh或者一个又一个字符
2:57.440–2:59.940
zh这个字符里面内容其实会非常非常多
2:59.940–3:01.680
zh然后大模型输出的
3:01.680–3:03.820
zh实际上是一段非常非常长的这个字符
3:03.820–3:05.120
zh那么我们每次呢
3:05.120–3:08.280
zh在去进行大模型的这个聊天的过程当中
3:08.280–3:10.860
zh实际上后台是需要把很长的这段字符
3:10.860–3:13.060
zh来进行各式各样的格式解析的
3:13.060–3:14.200
zh这段是什么
3:14.200–3:15.180
zh那段是什么
3:15.180–3:16.300
zh那么有一些呢
3:16.300–3:19.180
zh他输出这个结果是给用户去看的
3:19.180–3:20.820
zh原来某一段话的回复
3:20.820–3:22.360
zh那么也有一些输出这个结果
3:22.360–3:24.740
zh可能是比如说工具调用信息
3:24.740–3:27.780
zh他自己运行当中的一些状态信息等等等等
3:27.780–3:29.680
zh总之是有很长很长这段信息
3:29.680–3:32.700
zh那么这个信息是以什么样的格式来进行输出
3:32.700–3:34.580
zh他就可以被什么样的格式来进行解析
3:34.580–3:35.480
zh你可以这么来经理解
3:35.480–3:37.820
zh那只不过现在对于DeepseekV4
3:37.820–3:39.300
zh整个正式版的模型来说
3:39.300–3:43.960
zh他们选择了是以Responsees API这样的一个形式来进行输出
3:43.960–3:46.640
zh所以他们就可以被Response API来进行解析
3:46.640–3:48.080
zh所以他就跟他兼容了
3:48.080–3:49.980
zh这么来进行理解就可以了
3:49.980–3:50.600
zh是这么一回事
3:50.600–3:53.360
zh是他在训练过程当中进行的非常深度的设置
3:53.360–3:54.440
zhOK好
3:54.440–3:57.020
zh那么问题是Response API它是什么东西
3:57.020–3:57.680
zh对不对
3:57.680–4:01.440
zh它怎么样来进行的解析
4:01.440–4:05.180
zh那么非常完整的一次Response API的调用
4:05.180–4:07.420
zh大家可以看这段代码
4:07.420–4:10.040
zh那么这个代码实际上就是一次非常完整的
4:10.040–4:10.840
zh非常底层的
4:10.840–4:11.760
zh我们使用Python
4:11.760–4:12.700
zh当然你使用这个
4:12.700–4:14.420
zh使用这个TS
4:14.420–4:16.000
zh其实也是类似的
4:16.000–4:17.100
zh这样的语法规则
4:17.100–4:19.460
zh来去完成一次通过Response API
4:19.460–4:20.660
zh调用底层模型的
4:20.660–4:22.480
zh一整个完整的这样的一个流程
4:22.480–4:23.460
zh那它是什么样的呢
4:23.460–4:24.640
zh首先我们需要
4:24.640–4:27.580
zh这个import OpenAI
4:27.580–4:28.580
zh就导入这样的库
4:28.580–4:30.340
zh然后导入这个库之后
4:30.340–4:31.500
zh接下来我们需要实力化
4:31.500–4:32.680
zh一个OpenAI的客户端
4:32.680–4:34.680
zh然后在OpenAI客户端里面
4:34.680–4:36.060
zh输入你的Deepseek API key
4:36.060–4:37.880
zh和Deepseek的这个base URL
4:37.880–4:39.380
zh这个base URL是定死的
4:39.380–4:40.600
zh然后这个Deepseek API key
4:40.600–4:41.800
zh你需要自己去注册一个
4:41.800–4:45.160
zh那么这里就实力化了一个open AI的这样的客户端
4:45.160–4:46.900
zh然后有了这个客户端
4:46.900–4:49.300
zh或者你可以把它理解成是一个负了值的
4:49.300–4:52.620
zh一个open AI对象的一个实力化的一个对象
4:52.620–4:53.260
zh就这么一回事
4:53.260–4:59.140
zh然后接下来就可以调用client.response.create这样的一个命令
4:59.140–5:03.800
zh就可以去获得一次对应的模型回复的这样的响应结果
5:03.800–5:06.440
zh这里我们输入modal等于deep seek v4 flash
5:06.440–5:09.220
zh然后这个instructor代表的含义
5:09.220–5:10.860
zh实际上就是system prompt
5:10.860–5:11.880
zh你可以这么来自己理解
5:11.880–5:15.100
zh就是我们整个的agent运行的方式当中
5:15.100–5:15.960
ensystem prompt
5:15.960–5:17.500
zh然后有一个input
5:17.500–5:18.500
zhinput代表的含义就是
5:18.500–5:20.380
zh我现在跟他来进行的对话
5:20.380–5:20.740
zh对不对
5:20.740–5:22.820
zh然后下面还有其他的参数
5:22.820–5:24.220
zh这下我们可以都不管
5:24.220–5:25.820
zh然后通过这样的方式
5:25.820–5:27.860
zh就可以完成一次模型的调用
5:27.860–5:29.240
zh当然我这里给大家举的例子
5:29.240–5:31.340
zh都是生成的英文的提出词
5:31.340–5:32.680
zh但用中文也是一样的
5:32.680–5:33.380
zh没有任何影响
5:33.380–5:36.100
zh总之就可以完成一次对应的响应
5:36.100–5:38.340
zh比如说我们这就可以让他来进行运行
5:38.340–5:40.440
zh我这个是在线的这个环境
5:40.440–5:41.540
zh就可以直接来进行运行
5:41.540–5:42.440
zh也是一样对不对
5:42.440–5:44.400
zh这个Response API
5:44.400–5:46.700
zh先做好一个Client
5:46.700–5:48.120
zh然后这Client
5:48.120–5:49.960
zh然后接下来就可以跟他来进对话了
5:49.960–5:50.720
zh就这么一回事
5:50.720–5:52.200
zh那么这个Client
5:52.200–5:55.080
zh实际上我们现在所说的这个Response API
5:55.080–5:57.300
zh实际上就是这Client里面的一个方法
5:57.300–6:01.320
zh通过他能够去获取一次又一次模型的响应结果
6:01.320–6:02.900
zh是什么样的一个情况
6:02.900–6:04.420
zh好
6:04.420–6:07.880
zh那么对于我们当前的这个Response API来说
6:07.880–6:10.180
zh其实它返回的这个结果里面
6:10.180–6:11.700
zh包含的消息会非常多
6:11.700–6:12.720
zh它会包含你的
6:12.720–6:13.900
zh比如说Reasoning Item
6:13.900–6:15.680
zh推理的字段的内容
6:15.680–6:17.280
zh会包含这个Message的内容
6:17.280–6:18.620
zh会包含这个Function Call
6:18.620–6:19.840
zh就是你工具调用这个内容
6:19.840–6:20.360
zh等等等等
6:20.360–6:21.460
zh价格式各样这个内容
6:21.460–6:23.620
zh然后这个Message里面还会包含
6:23.620–6:25.580
zh它模型本身的output
6:25.580–6:28.060
zh或者其他的一些警告
6:28.060–6:29.440
zh拒绝的一些信息
6:29.440–6:31.240
zh还有包括文本图像的一个信息
6:31.240–6:31.720
zh等等等等
6:31.720–6:32.740
zh也就是它实际上
6:32.740–6:33.460
zh你可以把理解成
6:33.460–6:35.760
zh就是一个完整的一种响应格式
6:35.760–6:37.960
zh是这么样的一个基本的定位
6:37.960–6:39.720
zh所以也是基于这样的响应格式
6:39.720–6:43.720
zh我们才能够去很好的去跟当前大模型来进行对话
6:43.720–6:46.660
zh能够把它的对应结果来进行一个输出
6:46.660–6:47.900
zh来进行一个响应
6:47.900–6:48.820
zh那么上面也是一样的
6:48.820–6:49.480
zh我们又来了一遍
6:49.480–6:52.300
zh这个Response API完整的执行流程
6:52.300–6:54.160
zh那么只不过在执行的过程当中
6:54.160–6:57.600
zh我们这里是考虑把每一个Response里面的所有内容
6:57.600–6:58.580
zh单独给你打印出来
6:58.580–7:00.420
zh来看一看它到底回复哪些东西
7:00.420–7:03.140
zh那么它回复内容包括什么Response ID
7:03.140–7:04.540
zhResponse的State
7:04.540–7:05.540
enResponse Model
7:05.540–7:06.220
zh等等等等
7:06.220–7:07.100
zh总之就是
7:07.100–7:08.800
zh它的每一条消息回复里面
7:08.800–7:10.660
zh实际上会包含我们当前
7:10.660–7:13.720
zh所有的回复的内容
7:13.720–7:15.680
zh所有当前模型运行的
7:15.680–7:17.060
zh全部的这样的信息
7:17.060–7:17.940
zh换而言之就是
7:17.940–7:19.760
zh我们当前这样的模型
7:19.760–7:21.960
zh在执行当前任务的时候
7:21.960–7:23.100
zh所有的状态信息
7:23.100–7:24.340
zh你可以这么来进行理解
7:24.340–7:24.820
zh好
7:24.820–7:27.940
zh那么它和另外一个
7:27.940–7:29.900
zh就是我们经常会讨论的
7:29.900–7:31.560
zh叫Chat Compilation API
7:31.560–7:33.040
zh它们两者之间
7:33.040–7:34.780
zh到底是什么样的一个
7:34.780–7:36.840
zh什么样的区别
7:36.840–7:38.980
zh这里我们是首先需要放在这
7:38.980–7:40.120
zh来给大家来进行个探讨
7:40.120–7:41.600
zh因为其实很多同学之前
7:41.600–7:42.940
zh其实是了解
7:42.940–7:45.100
zhOpenAI的Chat Compilations API的
7:45.100–7:46.400
zh那么这里面
7:46.400–7:48.440
zh我们说OpenAI是原上一版本的
7:48.440–7:49.680
enChat Compilations API
7:49.680–7:51.340
zh它的核心的功能
7:51.340–7:53.440
zh是去围绕Message消息列表
7:53.440–7:54.560
zh来进行编辑
7:54.560–7:55.620
zh也就是说它实际上
7:55.620–7:57.480
zh是去维护一个又一个消息列表
7:57.480–7:58.440
zh那一个消息列表里面
7:58.440–8:00.000
zh我们需要由System
8:00.000–8:05.400
zh也就是说它实际上是去维护一个又一个消息列表,那一个消息列表里面我们需要有systemmessage,需要有usermessage,有的时候还会有大模型回复回来message,
8:05.400–8:14.600
zh但总之我们实际上重点是去维护它的模型每次运行过程当中消息列表,然后给它导入到当前模型里面去来进行一个运行,
8:14.600–8:16.000
zh来进行一个测试
8:16.000–8:17.760
zh然后最后的模型也给你返回出一个消息
8:17.760–8:21.200
zh它返回消息的本质的也是一条消息
8:21.200–8:23.880
zh所以原来的openAI它上一代的
8:23.880–8:24.900
zh或者deep seek也是一样
8:24.900–8:27.680
zh它之前支持的主要是chatcompletions API
8:27.680–8:30.640
zh那么它那些主要是去维护一个消息列表
8:30.640–8:33.100
zh而现在升级到了response API
8:33.100–8:37.100
zh你会发现它实际上是维护你当前运行的一个状态
8:37.100–8:39.120
zh所谓当前运行的状态
8:39.120–8:41.740
zh就指的是我们现在在运行的过程当中
8:41.740–8:45.020
zh一个模型它其实每次在进行响应的过程当中
8:45.020–8:47.860
zh它会有很多很多的一些状态方面这样的信息
8:47.860–8:50.240
zh而原来我们重点维护的消息列表
8:50.240–8:52.720
zh你可以把理解成只是状态当中的一个维度
8:52.720–8:53.640
zh仅此而已
8:53.640–8:55.800
zh那么现在我们说借助Response API
8:55.800–8:57.080
zh实际上对于开发者来说
8:57.080–8:59.480
zh其实就能够非常便捷的把一些工具
8:59.480–9:02.040
zh把一些这个extract给它放到一块
9:02.040–9:03.800
zh就可以迅速的构成一个agent
9:03.800–9:05.420
zh然后你只需要输入一个input
9:05.420–9:08.900
zh它背后就可以完整的去执行一整个agent loop
9:08.900–9:10.620
zh那所谓agent loop
9:10.620–9:12.900
zh这点大家也可以这么理解一下
9:12.900–9:14.820
zh就是我现在agent要调用一些工具
9:14.820–9:16.380
zh来完成一些事项
9:16.380–9:16.720
zh对不对
9:16.720–9:17.820
zh那这工具有的时候
9:17.820–9:20.660
zh我们需要多部的进行调用
9:20.660–9:23.260
zh有的时候也需要并发的来进行调用
9:23.260–9:23.560
zh对不对
9:23.560–9:25.420
zh那原来我们需要实现多部
9:25.420–9:26.840
zh或者并发的这样的工具调用
9:26.840–9:28.760
zh你可能得编写更加复杂的
9:28.760–9:29.400
zh这样的一个程序
9:29.400–9:31.460
zh或者是用比如说像long chain
9:31.460–9:32.580
zh这样的agent开发框架
9:32.580–9:33.000
zh对不对
9:33.000–9:35.020
zh它其实是支持内部
9:35.020–9:37.560
zh去完成agent loop这样的工作的
9:37.560–9:39.480
zhagent loop就是它不断不断去调用工具
9:39.480–9:42.020
zh直到它能够完成当前的请求为止
9:42.020–9:42.480
zh好
9:42.480–9:43.920
zh现在我们说这些功能
9:43.920–9:47.960
zh其实也是可以被responses API来去完成的
9:47.960–9:51.380
zh这个其实是它的一个功能上面这样的进阶
9:51.380–9:53.900
zh如果原来你是使用chat completion API的话
9:53.900–9:56.080
zh你可能就需要不断的去维护它的消息例表
9:56.080–9:57.980
zh其实整个过程会非常的繁琐
9:57.980–10:00.180
zh如果你需要去实现agent loop的话
10:00.180–10:01.740
zh其实你需要手动来进行搭建
10:01.740–10:03.300
zh而现在是用responses API
10:03.300–10:04.060
zh其实不需要
10:04.060–10:07.040
zh它内部是可以帮你去全自动的
10:07.040–10:09.140
zh完成agent loop这样的工作的
10:09.140–10:12.020
zh所以其实对于Responses API来说
10:12.020–10:13.820
zh它其实也就是你可以把它理解成
10:13.820–10:15.500
zh就是一个类似于LongChain这样的一个
10:15.500–10:17.880
zhagent和工具把它绑定一块的一个脚手架
10:17.880–10:20.660
zh这个是它的一个基础的认知
10:20.660–10:26.380
zh当然在OpenAI官方的给出的Responses API的说明里面
10:26.380–10:27.780
zh它其实也有谈到说
10:27.780–10:29.400
zh我们现在使用Responses API
10:29.400–10:32.920
zh相比于上一代的Chat Completions API来说
10:32.920–10:34.760
zh其实它的性能是增长了3%
10:34.760–10:38.480
zh它是在terminal的榜单上
10:38.480–10:40.560
zh它性能是增上了3%
10:40.560–10:42.240
zh也就是说明有了框架
10:42.240–10:43.720
zh去搭建一些agent
10:43.720–10:45.640
zh实际上是能够更好的
10:45.640–10:48.660
zh更加稳定的去维护这些agent运行的
10:48.660–10:50.820
zh它是有这样的一个功能在这
10:50.820–10:51.200
enOK
10:51.200–10:53.960
zh这个是所谓的Responses API
10:53.960–10:56.960
zh当然我们说对于Responses API来说
10:56.960–10:58.420
zh我们下面还有很多的一些
10:58.420–11:01.200
zh大家可以课后自己再去来进行
11:01.200–11:03.580
zh深度学习的一些内容和素材
11:03.580–11:06.820
zh比如说它也是支持一些参数这样的调整的
11:06.820–11:07.160
zh对不对
11:07.160–11:08.780
zh比如说什么temperature
11:08.780–11:12.440
zh还有topia这样的一些底层的模型运行参数
11:12.440–11:13.200
zh这样的调整
11:13.200–11:18.180
zh比如说你这个temperature调整的范围是在0到2之间
11:18.180–11:20.420
zh然后temperature越高
11:20.420–11:21.860
zh那么它生成结果越就越不稳定
11:21.860–11:22.700
zh然后temperature越低
11:22.700–11:24.140
zh它生成结果越稳定等等等等
11:24.140–11:28.480
zh同时它也是支持直接通过一些json schema
11:28.480–11:30.940
zh这个是来进行structured output
11:30.940–11:32.260
zh就是结构化的输出
11:32.260–11:33.220
zh那么结构化输出呢
11:33.220–11:35.500
zh实际上在现在很多的agent开发场景下
11:35.500–11:37.100
zh都会非常非常的重要
11:37.100–11:37.480
zh对不对
11:37.480–11:39.000
zh你可以通过类似这样的方式
11:39.000–11:42.840
zh去设置好对应的这个结构化输出的
11:42.840–11:44.980
zh这个结构化这个文本的这个要求
11:44.980–11:45.640
zh然后呢
11:45.640–11:47.760
zh把它直接带入到我们的
11:47.760–11:50.080
zhResponses API的这个text参数里面去
11:50.080–11:52.100
zh就让它能够进行结构化的输出了
11:52.100–11:52.840
zh是这么一回事
11:52.840–11:54.140
zh当然我们现在公开课
11:54.140–11:55.860
zh其实一般来说就不会围绕
11:55.860–11:56.940
zh比如说结构化输出里面
11:56.940–11:58.640
zh具体它是规定哪些结构
11:58.640–12:00.140
zh这个Json schema的这个对象
12:00.140–12:01.540
zh到底代表什么样的含义
12:01.540–12:02.600
zh来展开来说
12:02.600–12:03.860
zh实际上也是因为
12:03.860–12:05.660
zh这东西都可以让大模型来完成
12:05.660–12:07.060
zh重点是你需要知道的是
12:07.060–12:08.500
zh有这个responsive API之后
12:08.500–12:10.740
zh它的结果化输出会非常稳定
12:10.740–12:13.400
zh是这么样的一个情况
12:13.400–12:14.520
zh具体怎么稳定
12:14.520–12:16.160
zh它其实有很多层的检验
12:16.160–12:18.400
zh什么text format
12:18.400–12:20.320
zh一层的检验
12:20.320–12:22.260
zh返回结果的Json格式的
12:22.260–12:23.760
zh一层本地的教验
12:23.760–12:26.780
zh最后再给你返回一个结果化输出
12:26.780–12:27.440
zh这样的文本
12:27.440–12:30.640
zh它是可以经过多层的教验和反馈
12:30.640–12:33.020
zh最后给你输出一个结构化的文本
12:33.020–12:34.640
zh这个其实是没有什么问题的
12:34.640–12:36.960
zh然后同时对于Response API来说
12:36.960–12:39.680
zh它还有非常关键的Tours的参数
12:39.680–12:40.060
zh对不对
12:40.060–12:42.000
zhTours的参数我们一会儿就看到
12:42.000–12:44.100
zh它其实和Launcher里面的Tours的参数
12:44.100–12:45.440
zh实际上就是一样的
12:45.440–12:46.740
zh给它输入一个工具
12:46.740–12:47.800
zh然后它就可以调用这工具
12:47.800–12:49.440
zh来完成对应的工作
12:49.440–12:50.580
zh是怎么样的情况
12:50.580–12:53.180
zh所以对于整个的Response API来说
12:53.180–12:55.040
zh核心样的参数就这么些
12:55.040–12:57.600
zh模型instruction系统开发指令
12:57.600–12:58.280
zh对不对input
12:58.280–13:00.460
zh本次任务的基本请求
13:00.460–13:03.480
zh然后还有这个什么maxoutputtoken
13:03.480–13:05.700
zh这个最高的模型输出结果上线
13:05.700–13:07.640
zh还有这个temperaturetoppr reasoning
13:07.640–13:08.600
zh对它推理强度
13:08.600–13:09.360
zh刚不说了吗
13:09.360–13:10.460
zh这个V4这个模型
13:10.460–13:11.800
zh有三档推理强度
13:11.800–13:13.820
zh然后下面还有这个text
13:13.820–13:16.680
zh主要是去进行结构化输出的一些参数
13:16.680–13:17.500
zh然后还有这个tours
13:17.500–13:19.740
zh是可以绑定一些外部的这样的工具
13:19.740–13:21.140
zh然后它还有这个tourchoice
13:21.140–13:22.060
zh代表的含义是
13:22.060–13:23.220
zh我们每次运行的时候
13:23.220–13:24.780
zh指定的工具来进行运行
13:24.780–13:25.820
zh还有这个stream
13:25.820–13:26.260
zh对不对
13:26.260–13:27.820
zh流式打印等等等等
13:27.820–13:28.900
zh有很多很多这些参数
13:28.900–13:30.320
zh基本上如果你看这参数
13:30.320–13:33.580
zh你会感觉他整个的运行的状态
13:33.580–13:38.940
zh差不多就和LongChain的CreateAgent是非常类似的
13:38.940–13:39.360
zh对不对
13:39.360–13:44.160
zh那这个是现在对于DeepSeq V4正式版模型来说
13:44.160–13:46.940
zh他所选择的一套基本的API
13:46.940–13:49.640
zh当然下面还有关于什么流失打印
13:49.640–13:51.080
zh是怎么样来进行操作的
13:51.080–13:53.400
zh这一点大家也可以自己去看一下
13:53.400–13:57.280
zh下面还有对应的可以来进行测试和运行的代码
13:57.280–13:59.180
zh关于流失打印其实也是一样的
13:59.180–14:00.500
zh就是人工讲应起来
14:00.500–14:00.920
zh其实会非常
14:00.920–14:02.900
zh其实人工编写其实非常麻烦
14:02.900–14:04.480
zh但是对于现在的agent来说
14:04.480–14:05.940
zh他们编写其实非常简单
14:05.940–14:06.760
zh所以你只需要知道
14:06.760–14:08.740
zh他其实这个是可以非常顺利的
14:08.740–14:09.820
zh来进行实现的
14:09.820–14:10.480
zh就没有什么问题
14:10.480–14:11.460
zh然后同时
14:11.460–14:13.760
zh他由于是维护每次运行的状态
14:13.760–14:16.240
zh所以他也是可以把之前对话状态
14:16.240–14:17.040
zh给他传入进去的
14:17.040–14:19.760
zh把之前对话状态传入进去
14:19.760–14:20.620
zh实际上相当于是
14:20.620–14:22.800
zh把上一次任务执行记录的全部信息
14:22.800–14:25.300
zh包括上一次咱们对话这个信息
14:25.300–14:26.240
zh都给他输入进去
14:26.240–14:28.500
zh然后他就可以来实现多种对话了
14:28.500–14:29.100
zh就这么一回事
14:29.100–14:34.700
zh这个其实是它的多轮对话的历史保存的一个基本的方法
14:34.700–14:39.900
zh就是把它的之前上一轮的response id给它传入进去
14:39.900–14:43.300
zh那么它接下来就可以顺利的来进行多轮对话了
14:43.300–14:45.400
zh这个是它的一个基本设置
14:45.400–14:49.700
zh然后同时下面还有关于function calling的完整的外部循环
14:49.700–14:51.860
zh就是我们现在要去定一个外部工具
14:51.860–14:52.300
zh对不对
14:52.300–14:54.100
zh你这个什么查询天气的外部工具
14:54.100–14:55.700
zh各式各样的外部工具
14:55.700–14:59.000
zh包括这里面是个结构化信息的匹配的一个外部工具
14:59.000–15:03.320
zh等等等等 都可以通类似使用类似这样的方式来进行一个定义
15:03.320–15:07.720
zh定义好了外部工具之后 接下来在Responses API里面直接输入tools
15:07.720–15:11.960
zh然后把你的工具给它放进去 然后它就可以顺带进行运行 就这么简单
15:11.960–15:16.440
zh当然如果你去拆 如果你去看它底层的响应的过程的话
15:16.440–15:20.920
zh这里其实就是一个我们去看它底层响应的过程完整的事例了
15:20.920–15:24.760
zh那么你会发现 它其实底层仍然还是一个function calling的完整流程
15:24.760–15:27.880
zh就是你给它关联工具之后 你先给工具发送个请求
15:27.880–15:30.280
zh然后公共运行完了之后呢 给你一个function response message
15:30.280–15:32.280
zh然后你接收到function response message之后呢
15:32.280–15:34.080
zh再开启你的second response啊
15:34.080–15:36.280
zh就是再去结合最开始用户的问题啊
15:36.280–15:38.280
zh去给用户来进行回复啊 是这么一回事啊
15:38.280–15:40.680
zh所以这个呢实际上是一个验证的过程啊
15:40.680–15:42.880
zh你要说一下啊 对于response API来说呢
15:42.880–15:44.680
zh他的这个也是一样的
15:44.680–15:48.080
zh他的这个工具要用其本质上啊 也是这个function calling啊
15:48.080–15:51.680
zh跟现在所有的其他的这个agent开发框架的这个function calling啊
15:51.680–15:52.680
zh也全部都是一样的
15:52.680–15:56.080
zh当然他其实非常完善好 整个response API里面
15:56.080–15:57.680
zh他其实有非常完善的功能
15:57.680–16:04.040
zh包括它工具室外的时候
16:04.040–16:14.960
zh所以也是基於response API,我們說deepseek它現在是擁抱了response API,才能夠更好的去接入到我們現在的codex裡面來進行運行。
16:14.960–16:20.960
zh否则的话 如果Deepseekv4本身这个模型 它并不兼容Responsees API的话 那么它其实是没有办法
16:20.960–16:27.360
zh完整接入到Codex里面去 并且能完整的释放现在Codex的完整性能 这个其实做不到
16:27.360–16:34.960
zh当然其实我们上面关于底层的API这个讲解 一个其实比较快 第二个其实我们也是希望主要是给大家留下一些印象
16:34.960–16:40.560
zh知道是怎么一回事就可以了 因为之后的编写主要是让我们AI来进行编写
16:40.560–16:43.480
zh所以我们可能就不像之前的公块课一样
16:43.480–16:45.940
zh围绕每一个API的每一行代码来进行讲解
16:45.940–16:47.980
zh因为现在来看其实意义不是很大
16:47.980–16:49.560
zh你总之你核心是要知道
16:49.560–16:51.520
zh这个Response API到底是干什么的
16:51.520–16:53.080
zh这点其实会非常重要
16:53.080–16:55.800
zh当然下面我们其实是围绕Response API
16:55.800–16:56.940
zh做了一个小小的实验
16:56.940–16:59.820
zh我们来搭建了一个简单的一个agent
16:59.820–17:02.560
zh然后这个agent基本上就是
17:02.560–17:04.940
zh现在有很多很多张表
17:04.940–17:07.320
zh然后我们来做一个简单的数据分析
17:07.320–17:09.400
zh然后核心是从各个表当中
17:09.400–17:11.680
zh来进行数据提取跟数据查询
17:11.680–17:15.180
zh当然我们这里为什么跟大家去先使用这个Response API
17:15.180–17:16.200
zh搭建一个简单的数据分析
17:16.200–17:17.640
zh因为从下一个小节开始
17:17.640–17:20.800
zh我们在使用Codex这样更加复杂的工具的时候
17:20.800–17:23.300
zh实际上我们最后的目标这不就是搭建
17:23.300–17:23.780
zh对不对
17:23.780–17:25.880
zh长成这样的一个数据分析系统吗
17:25.880–17:29.100
zh只不过我们现在从最底层的API出发
17:29.100–17:30.240
zh一点点来进行学习
17:30.240–17:33.980
zh到最后能搭建这么一个比较复杂的数据分析系统
17:33.980–17:35.460
zh其实有很长的路要走
17:35.460–17:38.000
zh所以我们在最一开始就给大家举一个小例子
17:38.000–17:41.660
zh如果我们现在是使用Response API来搭建一个数据分析系统的话
17:41.660–17:42.700
zh那么未来它是一个
17:42.700–17:45.980
zh那么它首先这第一步应该怎么卖出去
17:45.980–17:48.860
zh然后我们再来考虑使用这Codex之后
17:48.860–17:53.240
zh你整个搭建数据分析系统的效率跟速度就可以起飞
17:53.240–17:53.580
zh对不对
17:53.580–17:56.480
zh我们来一步一步来看它是怎么样来进行运行的
17:56.480–17:58.480
zh当然这里我们涉及到一个数据集
17:58.480–17:59.640
zh叫Allist
17:59.640–18:02.120
zh它是巴西电商公司的一个开源数据集
18:02.120–18:04.380
zh这个数据集其实非常庞大
18:04.380–18:08.040
zh里面总共有这么十几万行的这个数据
18:08.040–18:09.580
zh那这个数据集也是我们之后
18:09.580–18:13.380
zh在做我们当前整个数据分析系统的性能测试的时候
18:13.380–18:14.560
zh最核心的这个数据集
18:14.560–18:15.380
zh所以大家可以看一下
18:15.380–18:18.360
zh当然其实对于所谓这个电商的这个数据
18:18.360–18:20.460
zh其实主要是分成这么两大类
18:20.460–18:21.820
zh一个是orders
18:21.820–18:23.060
zh一个是customers
18:23.060–18:25.720
zh这么两类的这个数据表格
18:25.720–18:28.000
zh它这个数据集不是一个单独的数据集
18:28.000–18:30.580
zh是分了好多好多好多个这个子数据的这个数据集
18:30.580–18:32.580
zh然后这个orders就是你订单
18:32.580–18:34.220
zh然后customer就是当前的客户
18:34.220–18:35.420
zh等等非常非常多
18:35.420–18:40.580
zh总之近期订单历史订单非常非常多
18:40.580–18:42.760
zh总共是一个世界外行的数据表格
18:42.760–18:45.620
zh那么这个数据表其实会有点复杂
18:45.620–18:48.400
zh我们一会儿都会看到这个数据表里面完整的内容
18:48.400–18:49.740
zh总之大家需要知道是
18:49.740–18:50.920
zh哎呀 这里有个数据表格
18:50.920–18:53.360
zh好 那么如果你现在想要使用
18:53.360–18:55.360
zh比如说Deepseek v4这样的模型
18:55.360–18:58.700
zh搭配着它现在已经兼容的Responsees API
18:58.700–19:00.500
zh去搭建一个数据分析系统
19:00.500–19:03.760
zh大家可以想想看有哪一些想法
19:03.760–19:04.280
zh对不对
19:04.280–19:06.000
zh其实我们对于现在的agent开发来说
19:06.000–19:08.100
zh首先你得有一个基本的思路
19:08.100–19:09.840
zh和一些基础的想法
19:09.840–19:11.560
zh可能我们就会涉及到
19:11.560–19:13.440
zh比如说我现在数据库
19:13.440–19:14.780
zh数据存储的数据库里面
19:14.780–19:16.520
zh所以我需要有一些
19:16.520–19:19.120
zh从数据库里面取出数据的这样的工具
19:19.120–19:19.720
zh对不对
19:19.720–19:21.680
zh然后也需要有一些
19:21.680–19:23.840
zh我们去查询数据这样的工具
19:23.840–19:26.700
zh然后同时还需要有一些读取数据的工具
19:26.700–19:28.320
zh然后同时还需要有一些
19:28.320–19:31.100
zh查询具体的每一个数据里面的
19:31.100–19:32.120
zh航和列之间的工具
19:32.120–19:34.060
zh这里面其实我们是给出一系列工具
19:34.060–19:35.040
zh列出数据表格
19:35.040–19:37.240
zh然后查询每一个数据表
19:37.240–19:38.500
zh什么来源表明
19:38.500–19:39.800
zh然后什么查询
19:39.800–19:41.220
zh什么每一个数据的
19:41.220–19:42.560
zh这个原数据
19:42.560–19:43.220
zh它的来源
19:43.220–19:45.020
zh它的最大最大行数
19:45.020–19:47.360
zh它的编写设计数代码来进行运行
19:47.360–19:48.560
zh同时还需要
19:48.560–19:51.140
zh去创建
19:51.140–19:53.640
zh去实现一个能够单独去创建数据集的
19:53.640–19:55.000
zh这样的一个外部工具等等
19:55.000–19:58.160
zh这个其实是我们现在的建议数据分析的过程当中
19:58.160–19:59.180
zh我们最核心
19:59.180–20:00.060
zh最常用的
20:00.060–20:01.560
zh无聊数据库来进行操作的啊
20:01.560–20:02.860
zh是像四项工具啊
20:02.860–20:03.540
zh列数表格
20:03.540–20:04.020
zh对不对
20:04.020–20:05.360
zh查他的这个原数据啊
20:05.360–20:07.200
zh就是查这个数据表格的这个真实情况
20:07.200–20:08.240
zh然后呢编写circle啊
20:08.240–20:09.420
zh来进行这个读数啊
20:09.420–20:10.620
zh然后呢去创建表格
20:10.620–20:11.760
zh把这个数据给取出来啊
20:11.760–20:13.240
zh基本上我们说这四个工具呢
20:13.240–20:14.340
zh是非常核心的
20:14.340–20:15.220
zh这么四个工具
20:15.220–20:15.420
zh好
20:15.420–20:15.980
zh那么下面啊
20:15.980–20:17.420
zh其实就是关于这四工具的
20:17.420–20:19.620
zh这样的一个定义的这个方法了啊
20:19.620–20:20.380
zh那么这里面呢
20:20.380–20:22.420
zh其实各个不同类型的这个工具啊
20:22.420–20:22.740
zh他呢
20:22.740–20:23.740
zh其实呃
20:23.740–20:25.060
zh我们上面他的具体的功能
20:25.060–20:26.240
zh其实定义还是非常清楚的啊
20:26.240–20:30.060
zh这里我们都是使用的python
20:30.060–20:32.060
zhSirco查询的一些工具
20:32.060–20:33.800
zh其实它背后的核心实现逻辑
20:33.800–20:35.860
zh就是把用户的输入的语言
20:35.860–20:37.080
zh把它转换成对应的Sirco代码
20:37.080–20:39.260
zh然后把它再去检查一下
20:39.260–20:40.740
zhSirco代码本身这样的格式
20:40.740–20:41.920
zh那么接下来就可以来进行运行
20:41.920–20:45.540
zh就这么样的一个基本的使用方法
20:45.540–20:49.040
zh下面就是这些工具的一些创建这样的方式
20:49.040–20:51.360
zh然后紧接着我们就可以把这工具
20:51.360–20:55.720
zh给它关联到我们当前的Responses API里边来
20:55.720–20:57.940
zh那么接下来下面有一个Stream
20:57.940–20:59.160
zh就打印的这样的方式
20:59.160–20:59.800
zh那么接下来呢
20:59.800–21:01.640
zh我们说你的一个极简的啊
21:01.640–21:03.380
zh一个简易的这个agent啊
21:03.380–21:04.940
zh实际上就相当于是完成了啊
21:04.940–21:06.940
zh当然我们这里其实有个每一个
21:06.940–21:09.100
zh有每一个的这个外部函数
21:09.100–21:11.780
zh它具体完整的这样的这个定义方法啊
21:11.780–21:12.300
zh这里面呢
21:12.300–21:13.540
zh会有大家可以自己去看一下啊
21:13.540–21:14.940
zh因为实际上我们说啊
21:14.940–21:16.460
zh这个每个外部函数的这个定义呢
21:16.460–21:17.720
zh都会比较复杂啊
21:17.720–21:19.640
zh但是这里面先给大家简单的啊
21:19.640–21:20.860
zh留下一个这个印象啊
21:20.860–21:22.180
zh就是对于现在的
21:22.180–21:23.340
zh我们在进行啊
21:23.340–21:24.820
zh这个agent的开发过程当中啊
21:24.820–21:26.620
zh那么如果你需要去搭建一个
21:26.620–21:28.200
zh数据分析的这样的agent的话
21:28.200–21:31.420
zh然后如果你现在去使用这个Responses API的话
21:31.420–21:33.120
zh实际上实现起来会非常简单
21:33.120–21:34.800
zh我们说你只需要定义好
21:34.800–21:37.460
zh我们刚刚所说的拥有这些功能的外部函数
21:37.460–21:41.820
zh然后把这函数和我们当前的model模型放在一块
21:41.820–21:43.520
zh对不对来进行一个封装
21:43.520–21:47.060
zh然后最后它就可以直接就是一个简单的agent
21:47.060–21:48.720
zh就可以直接顺利来进行运行
21:48.720–21:49.480
zh就这么回事
21:49.480–21:52.360
zh但这里其实会具体涉及到很多的一些代码
21:52.360–21:54.740
zh就比如说我们如何把自然预言转化成sicle
21:54.740–21:55.300
zh对不对
21:55.300–21:59.900
zh然后呢Sircle本身这样代码如何去提升它的这样的准确性等等等等
21:59.900–22:03.360
zh那么这个可能就属于这个比较进阶的一些功能了
22:03.360–22:06.140
zh这个我们公开课可能就没有时间展开来说了
22:06.140–22:09.040
zh但是呢这里给大家提供的所有的这些代码呢
22:09.040–22:12.380
zh实际上每个代码都是可以真实的来进行运行的
22:12.380–22:14.200
zh然后呢大家如果感兴趣的话
22:14.200–22:16.260
zh课后呢可以单独再去看一下这个代码
22:16.260–22:19.800
zh或者你也可以直接能把它导到你本地的这个环境里边去
22:19.800–22:23.560
zh让它呢反正我们说每一个这个核心的这个外部函数
22:23.560–22:26.560
zh我们下面都有完整脚本和它的功能的这样的定义
22:26.560–22:29.500
zh你可以直接用它来进行的使用也是ok的
22:29.500–22:31.840
zh只不过这里我们就跟大家说的一点
22:31.840–22:35.120
zh是其实对于当前的Response API来说
22:35.120–22:37.280
zh如果你想创建一个数据分析agent
22:37.280–22:38.940
zh我知不知道它也可以非常简单
22:38.940–22:39.500
zh对不对
22:39.500–22:42.740
zh我们无非就是我的工具给它封闹到一起去
22:42.740–22:44.660
zh然后用户输入一个业务的问题
22:44.660–22:46.640
zh我们就看需要使用哪些工具
22:46.640–22:47.240
zh对不对
22:47.240–22:49.180
zh然后通过Response API
22:49.180–22:50.800
zh它本质上实际上是一个agent loop
22:50.800–22:55.440
zh它是一个不断循环的这样的一个操作
22:55.440–22:58.620
zh它就会不断的尝试去调用各式各样的工具
22:58.620–23:00.240
zh来进行多部工具调用
23:00.240–23:02.220
zh或者工具的这样的并发使用等等
23:02.220–23:05.200
zh然后最后完成了
23:05.200–23:07.600
zh最后就给输出一段最终这样的结果
23:07.600–23:11.420
zh然后最后我们也可以让它去绘制一些表格等等
23:11.420–23:13.760
zh它其实基本上就是这么样的一个过程
23:13.760–23:14.720
zh但是它底层
23:14.720–23:16.900
zh我们说上面其实大模型的运行的层
23:16.900–23:20.560
zh底层实际上我们肯定是需要有维护的收据库
23:20.560–23:25.660
zh这里其实我们默认的数据库是CircleLite和MyCircle这么两种数据库
23:25.660–23:30.880
zh然后那么无非就是下来我们上面各式各样生产出来的消息
23:30.880–23:34.920
zh或者你的Circle从你的数据库当中具体来进行运行等等
23:34.920–23:36.300
zh然后运行完了之后
23:36.300–23:41.700
zh你最后返回的Circle数据库这样的内容也会拼接到我们原始的消息列表里面去
23:41.700–23:44.020
zh然后共同回复用户当前这样的问题
23:44.020–23:45.360
zh就是这样的一个过程
23:45.360–23:48.460
zh所以其实现在我们在进行Agent的开发过程当中
23:48.460–23:51.420
zh本质上其实如果说最底层的话
23:51.420–23:52.860
zh无非就是创建好工具
23:52.860–23:56.140
zh然后和你当前的agent给他放在一块
23:56.140–23:58.020
zh然后最后来进行一些测试
23:58.020–23:58.920
zh来进行运行
23:58.920–24:00.880
zh看一下能不能够来进行顺利的运行
24:00.880–24:02.080
zh上面我们最下面
24:02.080–24:03.220
zh最上面这个脚本
24:03.220–24:04.280
zh最后面这两个脚本
24:04.280–24:07.960
zh实际上是去查询我们当前的数据
24:07.960–24:10.660
zh它一段时间的销量的结果
24:10.660–24:12.000
zh它的各式各样的
24:12.000–24:15.280
zh巴西店商各式各样不同品类的这样的商品
24:15.280–24:19.420
zh它实际上销量的一个分布情况
24:19.420–24:23.220
zh这个是我们来进行的一个查询
24:23.220–24:25.200
zh然后最后生成了一张图片
24:25.200–24:26.240
zh是这么一回事
24:26.240–24:29.200
zh那么实际上具体运行脚本和代码
24:29.200–24:30.880
zh实际上就是上面这些脚本和代码
24:30.880–24:34.080
zh这个是在数据库中查询数据的一个完整的脚本
24:34.080–24:36.140
zh那下面是查询完数据之后
24:36.140–24:38.520
zh生成最终运行结果的这样的脚本
24:38.520–24:42.800
zh那么里面实际上本质上都是去关联到我们当前agent
24:42.800–24:44.500
zh来进行一轮又轮的运行
24:44.500–24:45.300
zh是怎么样一回事
0:00.000–0:01.531
那麼接下來我們就來看看
0:01.531–0:04.720
到底該如何上手使用 Response API。
0:04.720–0:09.139
這其實是在我們現在進行開發的過程中
0:09.139–0:14.000
可能都會涉及到一些底層通訊格式的講解。
0:14.000–0:15.303
當然如果是去年的話
0:15.303–0:16.997
這部分內容應該是非常核心
0:16.997–0:18.720
非常重要的一部分內容。
0:18.720–0:20.400
還有底層的開發範式，對吧？
0:20.400–0:22.680
OpenAI 的 Response API
0:22.680–0:25.560
還有之前的 ChatCompletions API
0:25.560–0:27.240
這都是我們將使用大模型的基礎。
0:27.240–0:30.080
到現在在 webcoding 時代
0:30.080–0:30.900
這些很多功能
0:30.900–0:32.200
我們其實都可以讓大模型
0:32.200–0:32.820
幫我們完成
0:32.820–0:34.520
所以像這部分內容
0:34.520–0:35.560
仍然很重要
0:35.560–0:37.120
但是我們可能就不需要
0:37.120–0:39.140
去特別深入地鑽研到
0:39.140–0:39.920
每一行程式碼
0:39.920–0:40.700
每一個參數
0:40.700–0:41.820
分別代表什麼樣的含義
0:41.820–0:43.040
這個程度來進行理解
0:43.040–0:43.900
你只需要知道是
0:43.900–0:45.120
它是做什麼的
0:45.120–0:46.020
有什麼用
0:46.020–0:47.760
以及你能怎麼用
0:47.760–0:49.340
這個東西其實是最重要的
0:49.340–0:50.760
那麼我們接下來就來看看
0:50.760–0:53.200
OpenAI 的 Responses API
0:53.200–0:54.200
到底是什麼
0:54.200–0:56.480
當然這裡大家如果不太了解
0:56.480–0:58.220
這個 Response API 到底是什麼的話
0:58.220–1:00.940
你可以把它想像成就是 OpenAI 版的 LangChain
1:00.940–1:04.140
專門負責給我們開發者一個介面
1:04.140–1:06.820
去更好地呼叫這樣的一些大模型
1:06.820–1:10.100
然後把它們和一些工具綁在一起
1:10.100–1:11.620
最後做成一個 Agent
1:11.620–1:12.840
就是這樣的一個 API
1:12.840–1:14.140
可以這麼來進行理解
1:14.140–1:16.120
當然其實這個 Response API
1:16.120–1:17.580
是去年 3 月 11 號
1:17.580–1:22.440
OpenAI 正式開源的一種全新的大模型調度方法
1:22.440–1:25.240
然後官網在 OpenAI 官網上也有非常詳細的
1:25.240–1:28.500
關於使用這個 Response API 的一些好處啊
1:28.500–1:32.300
和怎麼去進行遷移呀的一些方法啊
1:32.300–1:33.780
當然這裡我們要說明的是
1:33.780–1:36.980
其實每一家大廠都有資格啊
1:36.980–1:38.700
這個 API 調度的這個範式
1:38.700–1:40.560
比如說對於這個
1:40.560–1:42.880
Anthropic 來說啊
1:42.880–1:45.460
他們自己有一套 Anthropic API 啊
1:45.460–1:47.680
還有一套 Cloud Agents SDK 啊
1:47.680–1:49.360
那麼對於 OpenAI 來說呢
1:49.360–1:51.480
他們家有這個 Response API 啊
1:51.480–1:53.880
和 Agent SDK 啊兩套開發框架啊
1:53.880–2:00.700
這個其實每一家他們都會推出一些適配自家模型的 agent 通信和開發範式
2:00.700–2:01.600
是這麼一回事
2:01.600–2:03.240
那麼對於 OpenAI 來說
2:03.240–2:10.640
他們當然這個 responses API 就是現在他們進行模型調度過程中最核心的響應方法
2:10.640–2:13.280
然後對於這個 DeepSeek 來說
2:13.280–2:17.000
他現在是接入了 responses API 這個功能體系裡面來
2:17.000–2:19.760
當然這裡其實有一個很有意思的一個點
2:19.760–2:22.380
就在於說其實之前有同學會問到說
2:22.380–2:27.280
DeepSeek 他們是怎麼考慮去接入 OpenAI 的 Response API 的呢
2:27.280–2:28.640
當然我們說對 DeepSeek 來說
2:28.640–2:30.840
他一旦接入 OpenAI 這個 Response API 之後
2:30.840–2:33.780
他實際上就可以無縫接入 Codex 的體系了
2:33.780–2:35.060
那他是怎么接入的呢
2:35.060–2:35.680
其實非常簡單
2:35.680–2:36.940
就是在後訓練的過程當中
2:36.940–2:40.960
給了他很多的一些指令方面的訓練集
2:40.960–2:45.860
讓他的響應格式能夠和 Response API 的響應格式來進行兼容
2:45.860–2:48.720
這裡其實就會說得比較底層了
2:48.720–2:49.760
因為其實大家知道
2:49.760–2:51.580
對於任何大模型來說
2:51.580–2:53.760
它原始的這個輸出這個內容
2:53.760–2:55.680
實際上就是一個又一個 token
2:55.680–2:57.440
或者一個又一個字符
2:57.440–2:59.940
這個字符裡面內容其實會非常非常多
2:59.940–3:01.680
接著是大模型輸出的
3:01.680–3:03.820
實際上是一段非常非常長的這個字串
3:03.820–3:05.120
那麼我們每次呢
3:05.120–3:08.280
在進行大模型聊天的過程中
3:08.280–3:10.860
實際上後台需要將很長的這段字串
3:10.860–3:13.060
來進行各種格式的解析
3:13.060–3:14.200
這段是什麼
3:14.200–3:15.180
那段是什麼
3:15.180–3:16.300
那麼有一些呢
3:16.300–3:19.180
它輸出這個結果是給用戶看的
3:19.180–3:20.820
原來某一段話的回覆
3:20.820–3:22.360
那麼也有一些輸出這個結果
3:22.360–3:24.740
可能是例如工具調用資訊
3:24.740–3:27.780
它自己運行過程中的一些狀態資訊等等
3:27.780–3:29.680
總之有很長很長的這段資訊
3:29.680–3:32.700
那麼這個資訊是以什麼樣的格式來進行輸出
3:32.700–3:34.580
它就可以被什麼樣的格式來進行解析
3:34.580–3:35.480
你可以這麼來理解
3:35.480–3:37.820
那只不過現在對於 Deepseek V4
3:37.820–3:39.300
整個正式版的模型來說
3:39.300–3:43.960
他們選擇是以 Responses API 這樣的形式來進行輸出
3:43.960–3:46.640
所以他們就可以被 Response API 來進行解析
3:46.640–3:48.080
所以它就與它相容了
3:48.080–3:49.980
這麼來進行理解就可以了
3:49.980–3:50.600
是這麼一回事
3:50.600–3:53.360
是它在訓練過程中進行的非常深度的設定
3:53.360–3:54.440
好的
3:54.440–3:57.020
那麼問題是 Response API 它是什麼東西
3:57.020–3:57.680
對吧
3:57.680–4:01.440
它怎麼樣來進行解析
4:01.440–4:05.180
那麼非常完整的一次 Response API 的呼叫
4:05.180–4:07.420
大家可以看這段程式碼
4:07.420–4:10.040
那麼這個程式碼實際上就是一次非常完整的
4:10.040–4:10.840
非常底層的
4:10.840–4:11.760
我們使用 Python
4:11.760–4:12.700
當然你使用這個
4:12.700–4:14.420
使用這個 TS
4:14.420–4:16.000
其實也是類似的
4:16.000–4:17.100
這樣的語法規則
4:17.100–4:19.460
來去完成一次透過 Response API
4:19.460–4:20.660
呼叫底層模型的
4:20.660–4:22.480
一整個完整的這樣一個流程
4:22.480–4:23.460
那它到底是什麼樣子呢
4:23.460–4:24.640
首先我們需要
4:24.640–4:27.580
這個 import OpenAI
4:27.580–4:28.580
就是匯入這樣的函式庫
4:28.580–4:30.340
然後匯入這個函式庫之後
4:30.340–4:31.500
接下來我們需要實例化
4:31.500–4:32.680
一個 OpenAI 的客戶端
4:32.680–4:34.680
然後在 OpenAI 客戶端裡面
4:34.680–4:36.060
輸入你的 Deepseek API key
4:36.060–4:37.880
和 Deepseek 的這個 base URL
4:37.880–4:39.380
這個 base URL 是固定不變的
4:39.380–4:40.600
然後這個 Deepseek API key
4:40.600–4:41.800
你需要自己去註冊一個
4:41.800–4:45.160
那麼這裡就實例化了一個 OpenAI 這樣的客戶端
4:45.160–4:46.900
然後有了這個客戶端
4:46.900–4:49.300
或者你可以把它理解成是一個賦予了值的
4:49.300–4:52.620
一個 OpenAI 物件的實例化物件
4:52.620–4:53.260
就是這麼一回事
4:53.260–4:59.140
然後接下來就可以呼叫 client.response.create 這樣的指令
4:59.140–5:03.800
就可以去獲得一次對應的模型回覆這樣的響應結果
5:03.800–5:06.440
這裡我們輸入 model 等於 deep seek v4 flash
5:06.440–5:09.220
然後這個 instructor 代表的意義
5:09.220–5:10.860
實際上就是 system prompt
5:10.860–5:11.880
你可以這麼來自己理解
5:11.880–5:15.100
就是說我們整個 agent 運行的方式當中
5:15.100–5:15.960
系統提示詞
5:15.960–5:17.500
然後有一個 input
5:17.500–5:18.500
input 代表的意義就是
5:18.500–5:20.380
我現在跟他來進行對話
5:20.380–5:20.740
對不對
5:20.740–5:22.820
然後下面還有其他的參數
5:22.820–5:24.220
這下我們可以都不管
5:24.220–5:25.820
然後通過這樣的方式
5:25.820–5:27.860
就可以完成一次模型的呼叫
5:27.860–5:29.240
當然我這裡給大家舉的例子
5:29.240–5:31.340
都是生成的英文的提示詞
5:31.340–5:32.680
但用中文也是一樣的
5:32.680–5:33.380
沒有任何影響
5:33.380–5:36.100
總之就可以完成一次對應的回應
5:36.100–5:38.340
舉例來說，我們就可以讓它來進行運行
5:38.340–5:40.440
我這個是在線的這個環境
5:40.440–5:41.540
就可以直接來進行運行
5:41.540–5:42.440
也是一樣對不對
5:42.440–5:44.400
這個 Response API
5:44.400–5:46.700
先做好一個 Client
5:46.700–5:48.120
然後這個 Client
5:48.120–5:49.960
然後接下來就可以跟它來進行對話了
5:49.960–5:50.720
就這麼一回事
5:50.720–5:52.200
那麼這個 Client
5:52.200–5:55.080
實際上我們現在所說的這個 Response API
5:55.080–5:57.300
實際上就是這個 Client 裡面的一個方法
5:57.300–6:01.320
透過它能夠去獲取一次又一次模型的回應結果
6:01.320–6:02.900
是怎麼樣的狀況
6:02.900–6:04.420
好
6:04.420–6:07.880
那麼對於我們當前的這個 Response API 來說
6:07.880–6:10.180
其實它返回的這個結果裡面
6:10.180–6:11.700
包含的訊息會非常多
6:11.700–6:12.720
它會包含你的
6:12.720–6:13.900
舉例來說 Reasoning Item
6:13.900–6:15.680
推理欄位的內容
6:15.680–6:17.280
會包含這個 Message 的內容
6:17.280–6:18.620
會包含這個 Function Call
6:18.620–6:19.840
就是你工具調用這個內容
6:19.840–6:20.360
等等等等
6:20.360–6:21.460
各式各樣這個內容
6:21.460–6:23.620
然後這個 Message 裡面還會包含
6:23.620–6:25.580
它模型本身的輸出
6:25.580–6:28.060
或者其他的一些警告
6:28.060–6:29.440
拒絕的一些資訊
6:29.440–6:31.240
還有包括文本圖像的資訊
6:31.240–6:31.720
等等等等
6:31.720–6:32.740
也就是說它實際上
6:32.740–6:33.460
你可以把它理解成
6:33.460–6:35.760
就是一種完整的回應格式
6:35.760–6:37.960
是這麼樣的基礎定位
6:37.960–6:39.720
所以也是基於這樣的回應格式
6:39.720–6:43.720
我們才能够去很好地跟當前大模型來進行對話
6:43.720–6:46.660
能夠把它的對應結果來進行一個輸出
6:46.660–6:47.900
進行回應
6:47.900–6:48.820
那麼上面也是一樣的
6:48.820–6:49.480
我們又執行了一遍
6:49.480–6:52.300
這個 Response API 完整的執行流程
6:52.300–6:54.160
只不過在執行的過程中
6:54.160–6:57.600
我們這裡是考慮把每個 Response 裡面的所有內容
6:57.600–6:58.580
單獨列印出來
6:58.580–7:00.420
來看看它到底回覆了哪些東西
7:00.420–7:03.140
那麼它回覆的內容包括 Response ID
7:03.140–7:04.540
Response 的狀態
7:04.540–7:05.540
Response 的模型
7:05.540–7:06.220
等等等等
7:06.220–7:07.100
總之就是
7:07.100–7:08.800
它的每一則訊息回覆裡面
7:08.800–7:10.660
實際上會包含我們目前
7:10.660–7:13.720
所有的回覆內容
7:13.720–7:15.680
所有目前模型運行的
7:15.680–7:17.060
全部的這類資訊
7:17.060–7:17.940
換言之就是
7:17.940–7:19.760
我們目前這樣的模型
7:19.760–7:21.960
在執行當前任務時
7:21.960–7:23.100
所有的狀態資訊
7:23.100–7:24.340
你可以這麼來理解
7:24.340–7:24.820
好
7:24.820–7:27.940
那麼它和另一個
7:27.940–7:29.900
就是我們經常討論的
7:29.900–7:31.560
稱為 Chat Completion API
7:31.560–7:33.040
它們兩者之間
7:33.040–7:34.780
到底是什麼樣的
7:34.780–7:36.840
什麼樣的區別
7:36.840–7:38.980
這裡我們首先需要把它放在這裡
7:38.980–7:40.120
來給大家進行探討
7:40.120–7:41.600
因為其實很多同學之前
7:41.600–7:42.940
其實是了解
7:42.940–7:45.100
OpenAI 的 Chat Completion API 的
7:45.100–7:46.400
那麼在裡面
7:46.400–7:48.440
我們說 OpenAI 是上一版本的
7:48.440–7:49.680
Chat 彙編 API
7:49.680–7:51.340
它的核心功能
7:51.340–7:53.440
是去圍繞訊息列表
7:53.440–7:54.560
進行編輯
7:54.560–7:55.620
也就是說它實際上
7:55.620–7:57.480
是去維護一個又一個的消息列表
7:57.480–7:58.440
那一個消息列表裡面
7:58.440–8:00.000
我們需要由System
8:00.000–8:05.400
也就是說它實際上是在維護一個又一個的消息列表，而在那個消息列表裡面，我們需要有system message、user message，有時還會有大模型回覆回來的message。
8:05.400–8:14.600
但總之，我們實際上的重點是去維護它的模型在每次運行過程中的消息列表，然後將其導入到當前模型中進行運行。
8:14.600–8:16.000
進行測試
8:16.000–8:17.760
然後最後的模型也會給你返回一條消息
8:17.760–8:21.200
它返回消息的本質也是一條消息
8:21.200–8:23.880
所以原來OpenAI上一代的
8:23.880–8:24.900
或者DeepSeek也是一樣
8:24.900–8:27.680
它之前支持的主要是chatcompletions API
8:27.680–8:30.640
那麼它那些主要是去維護一個消息列表
8:30.640–8:33.100
而現在升級到了response API
8:33.100–8:37.100
你會發現它實際上是在維護你當前運行的狀態
8:37.100–8:39.120
所謂當前運行的狀態
8:39.120–8:41.740
指的就是我們現在在運行的過程中
8:41.740–8:45.020
一個模型其實每次在進行響應的過程中
8:45.020–8:47.860
它會有很多很多關於狀態方面的信息
8:47.860–8:50.240
而原來我們重點維護的消息列表
8:50.240–8:52.720
你可以把它理解為只是狀態當中的一個維度
8:52.720–8:53.640
僅此而已
8:53.640–8:55.800
那麼現在我們說借助Response API
8:55.800–8:57.080
實際上對於開發者來說
8:57.080–8:59.480
其實就能夠非常便捷地把一些工具
8:59.480–9:02.040
把一些這個extract放到一塊
9:02.040–9:03.800
就可以迅速地構成一個agent
9:03.800–9:05.420
然後你只需要輸入一個input
9:05.420–9:08.900
它背後就可以完整地執行一整個agent loop
9:08.900–9:10.620
那所謂agent loop
9:10.620–9:12.900
這點大家也可以這麼理解一下
9:12.900–9:14.820
就是現在我的agent要調用一些工具
9:14.820–9:16.380
來完成一些事項
9:16.380–9:16.720
對不對
9:16.720–9:17.820
那這些工具有時候
9:17.820–9:20.660
我們需要多部進行調用
9:20.660–9:23.260
有時也需要並發地進行調用
9:23.260–9:23.560
對不對
9:23.560–9:25.420
那原來我們需要實現多部
9:25.420–9:26.840
或是並發地進行工具呼叫
9:26.840–9:28.760
你可能需要編寫更複雜的
9:28.760–9:29.400
這樣的程式
9:29.400–9:31.460
或是使用例如像 LangChain
9:31.460–9:32.580
這樣的 Agent 開發框架
9:32.580–9:33.000
對吧
9:33.000–9:35.020
它其實支援內部
9:35.020–9:37.560
去完成 Agent Loop 這樣的工作
9:37.560–9:39.480
Agent Loop 就是它不斷地呼叫工具
9:39.480–9:42.020
直到它能完成目前的請求為止
9:42.020–9:42.480
好
9:42.480–9:43.920
現在我們說這些功能
9:43.920–9:47.960
其實也可以由 Responses API 來完成
9:47.960–9:51.380
這其實是它在功能上的進階
9:51.380–9:53.900
如果你原本是使用 Chat Completion API
9:53.900–9:56.080
你可能就需要不斷地去維護它的訊息列表
9:56.080–9:57.980
其實整個過程會非常繁瑣
9:57.980–10:00.180
如果你需要去實現 Agent Loop
10:00.180–10:01.740
其實你需要手動來搭建
10:01.740–10:03.300
而現在是使用 Responses API
10:03.300–10:04.060
其實不需要
10:04.060–10:07.040
它內部可以幫你自動地
10:07.040–10:09.140
完成 Agent Loop 這樣的工作
10:09.140–10:12.020
所以其實對於 Responses API 來說
10:12.020–10:13.820
它其實也就是你可以把它理解成
10:13.820–10:15.500
就是一個類似於 LangChain 這樣的
10:15.500–10:17.880
將 Agent 和工具綁定在一起的脚手架
10:17.880–10:20.660
這是它的一個基礎認知
10:20.660–10:26.380
當然在 OpenAI 官方給出的 Responses API 說明裡面
10:26.380–10:27.780
它其實也有談到說
10:27.780–10:29.400
我們現在使用 Responses API
10:29.400–10:32.920
與上一代的 Chat Completions API 相比
10:32.920–10:34.760
其實它的效能提升了 3%
10:34.760–10:38.480
它是在 Terminal 的排行榜上
10:38.480–10:40.560
它的效能提升了 3%
10:40.560–10:42.240
也就是說有了框架
10:42.240–10:43.720
去搭建一些 Agent
10:43.720–10:45.640
實際上能夠更好地
10:45.640–10:48.660
更穩定地去維護這些 Agent 的運作
10:48.660–10:50.820
它是有這樣的功能在裡面
10:50.820–10:51.200
好的
10:51.200–10:53.960
這就是所謂的 Responses API
10:53.960–10:56.960
當然我們說對於 Responses API 來說
10:56.960–10:58.420
我們下面還有很多的一些
10:58.420–11:01.200
大家可以課後自己再去來進行
11:01.200–11:03.580
深度學習的一些內容和素材
11:03.580–11:06.820
比如說它也是支援一些參數這樣的調整
11:06.820–11:07.160
對不對
11:07.160–11:08.780
比如說什麼 temperature
11:08.780–11:12.440
還有 top_p 這樣的一些底層模型運行參數
11:12.440–11:13.200
這樣的調整
11:13.200–11:18.180
比如說你這個 temperature 調整的範圍是在 0 到 2 之間
11:18.180–11:20.420
然後 temperature 越高
11:20.420–11:21.860
那麼它生成結果就越不穩定
11:21.860–11:22.700
然後 temperature 越低
11:22.700–11:24.140
它生成結果越穩定等等等等
11:24.140–11:28.480
同時它也是支援直接透過一些 json schema
11:28.480–11:30.940
這個是用來進行結構化輸出
11:30.940–11:32.260
就是結構化的輸出
11:32.260–11:33.220
那麼結構化輸出呢
11:33.220–11:35.500
實際上在現在很多的 agent 開發場景下
11:35.500–11:37.100
都會非常非常的重要
11:37.100–11:37.480
對不對
11:37.480–11:39.000
你可以透過類似這樣的方式
11:39.000–11:42.840
去設定好對應的這個結構化輸出的
11:42.840–11:44.980
這個結構化這個文本的這個要求
11:44.980–11:45.640
然後呢
11:45.640–11:47.760
把它直接帶入到我們的
11:47.760–11:50.080
Responses API 的這個 text 參數裡面去
11:50.080–11:52.100
就讓它能夠進行結構化的輸出了
11:52.100–11:52.840
是這麼一回事
11:52.840–11:54.140
當然我們現在公開課
11:54.140–11:55.860
其實一般來說就不會圍繞
11:55.860–11:56.940
比如說結構化輸出裡面
11:56.940–11:58.640
具體它是規定哪些結構
11:58.640–12:00.140
這個 Json schema 的這個物件
12:00.140–12:01.540
到底代表什麼樣的含義
12:01.540–12:02.600
來展開來說
12:02.600–12:03.860
實際上也是因為
12:03.860–12:05.660
這東西都可以讓大模型來完成
12:05.660–12:07.060
重點是你需要知道的是
12:07.060–12:08.500
有了這個 Response API 之後
12:08.500–12:10.740
它的結果化輸出會非常穩定
12:10.740–12:13.400
就是這麼一個情況
12:13.400–12:14.520
具體怎麼穩定
12:14.520–12:16.160
它其實有很多層的檢驗
12:16.160–12:18.400
像是 text format
12:18.400–12:20.320
一層的檢驗
12:20.320–12:22.260
返回結果的 JSON 格式
12:22.260–12:23.760
一層本地的檢驗
12:23.760–12:26.780
最後再給你返回一個結果化輸出
12:26.780–12:27.440
這樣的文本
12:27.440–12:30.640
它是可以經過多層的檢驗和反饋
12:30.640–12:33.020
最後給你輸出一個結構化的文本
12:33.020–12:34.640
這個其實是沒有什麼問題的
12:34.640–12:36.960
然後同時對於 Response API 來說
12:36.960–12:39.680
它還有非常關鍵的 tools 參數
12:39.680–12:40.060
對不對
12:40.060–12:42.000
tools 參數我們一會兒就看到
12:42.000–12:44.100
它其實和 Launcher 裡面的 tools 參數
12:44.100–12:45.440
實際上就是一样的
12:45.440–12:46.740
給它輸入一個工具
12:46.740–12:47.800
然後它就可以調用這個工具
12:47.800–12:49.440
來完成對應的工作
12:49.440–12:50.580
是怎麼樣的狀況
12:50.580–12:53.180
所以對於整個 Response API 來說
12:53.180–12:55.040
核心的參數就這麼些
12:55.040–12:57.600
模型 instruction 系統開發指令
12:57.600–12:58.280
對不對 input
12:58.280–13:00.460
本次任務的基本請求
13:00.460–13:03.480
然後還有這個什麼 max_output_tokens
13:03.480–13:05.700
這個最高的模型輸出結果上限
13:05.700–13:07.640
還有這個 temperature、top_p、reasoning
13:07.640–13:08.600
對它推理強度
13:08.600–13:09.360
剛才不是說了嗎
13:09.360–13:10.460
這個 V4 這個模型
13:10.460–13:11.800
有三檔推理強度
13:11.800–13:13.820
然後下面還有這個 text
13:13.820–13:16.680
主要是去進行結構化輸出的一些參數
13:16.680–13:17.500
然後還有這個 tools
13:17.500–13:19.740
可以綁定一些外部工具
13:19.740–13:21.140
此外還有這個 tourchoice
13:21.140–13:22.060
代表的意義是
13:22.060–13:23.220
我們每次執行時
13:23.220–13:24.780
指定要使用的工具來進行運行
13:24.780–13:25.820
還有這個 stream
13:25.820–13:26.260
對吧
13:26.260–13:27.820
串流列印等等
13:27.820–13:28.900
有很多這樣的參數
13:28.900–13:30.320
基本上如果你看這些參數
13:30.320–13:33.580
你會感覺它整個的運行狀態
13:33.580–13:38.940
跟 LongChain 的 CreateAgent 非常類似
13:38.940–13:39.360
對吧
13:39.360–13:44.160
這是目前針對 DeepSeq V4 正式版模型
13:44.160–13:46.940
所選擇的一套基本 API
13:46.940–13:49.640
當然下面還有關於串流列印
13:49.640–13:51.080
是如何操作的
13:51.080–13:53.400
這一點大家也可以自己去看一下
13:53.400–13:57.280
下面還有對應的測試和運行代碼
13:57.280–13:59.180
關於串流列印其實也是一樣的
13:59.180–14:00.500
就是人工講起來
14:00.500–14:00.920
其實會非常
14:00.920–14:02.900
其實人工編寫其實非常麻煩
14:02.900–14:04.480
但對於現在的 Agent 來說
14:04.480–14:05.940
他們編寫其實非常簡單
14:05.940–14:06.760
所以你只需要知道
14:06.760–14:08.740
它其實可以非常順利地
14:08.740–14:09.820
來進行實現
14:09.820–14:10.480
就沒有問題
14:10.480–14:11.460
同時
14:11.460–14:13.760
由於它會維護每次執行的狀態
14:13.760–14:16.240
所以它也可以將之前的對話狀態
14:16.240–14:17.040
傳入進去
14:17.040–14:19.760
將之前的對話狀態傳入
14:19.760–14:20.620
實際上相當於
14:20.620–14:22.800
把上一次任務執行的全部資訊
14:22.800–14:25.300
包括上一次我們的對話資訊
14:25.300–14:26.240
都輸入進去
14:26.240–14:28.500
然後它就可以實現多種對話了
14:28.500–14:29.100
就是這麼一回事
14:29.100–14:34.700
這其實是多輪對話歷史保存的一個基本方法
14:34.700–14:39.900
就是將上一輪的回應 ID 傳入進去
14:39.900–14:43.300
這樣接下來就能順利進行多輪對話
14:43.300–14:45.400
這是它的一個基本設定
14:45.400–14:49.700
同時下方還有關於 Function Calling 的完整外部循環
14:49.700–14:51.860
就是我們現在要去定義一個外部工具
14:51.860–14:52.300
對吧
14:52.300–14:54.100
像是查詢天氣的外部工具
14:54.100–14:55.700
各種各樣的外部工具
14:55.700–14:59.000
包括這裡面是結構化資訊匹配的外部工具
14:59.000–15:03.320
諸如此類，都可以透過類似這樣的方式來進行定義
15:03.320–15:07.720
定義好外部工具之後，接下來直接在 Responses API 中輸入 tools
15:07.720–15:11.960
然後把你的工具放進去，它就能順帶執行，這麼簡單
15:11.960–15:16.440
當然如果你去拆解，如果你去看它底層的回應過程的話
15:16.440–15:20.920
這裡其實就是我們去看它底層回應過程的完整範例
15:20.920–15:24.760
那麼你會發現，它底層其實仍然是一個 Function Calling 的完整流程
15:24.760–15:27.880
就是你給它關聯工具之後，你先給工具發送請求
15:27.880–15:30.280
然後公共運行完畢後，給你一個 Function Response Message
15:30.280–15:32.280
然後你接收到 Function Response Message 之後呢
15:32.280–15:34.080
再開啟你的第二次回應啊
15:34.080–15:36.280
就是再去結合最初用戶的問題啊
15:36.280–15:38.280
去給用戶進行回覆啊，是這麼一回事啊
15:38.280–15:40.680
所以這個呢實際上是一個驗證的過程啊
15:40.680–15:42.880
你要說一下啊，對於 Response API 來說呢
15:42.880–15:44.680
他的這個也是一樣的
15:44.680–15:48.080
他的這個工具要用其本质上啊，也是這個 Function Calling 啊
15:48.080–15:51.680
跟現在所有的其他的這個 Agent 開發框架的 Function Calling 啊
15:51.680–15:52.680
也全部都是一樣的
15:52.680–15:56.080
當然他其實非常完善好，整個 Response API 裡面
15:56.080–15:57.680
他其實有非常完善的功
15:57.680–16:04.040
包括它工具室外的时候
16:04.040–16:14.960
所以也是基於 Response API，我們說 DeepSeek 它現在是擁抱了 Response API，才能夠更好的去接入到我們現在的 Codex 裡面來進行運行。
16:14.960–16:20.960
否則的話，如果 DeepSeek v4 本身這個模型，它並不相容 Responses API 的話，那麼它其實是沒有辦法
16:20.960–16:27.360
完整接入到 Codex 裡面去，並且能完整的釋放現在 Codex 的完整性能，這個其實做不到
16:27.360–16:34.960
當然其實我們上面關於底層 API 這個講解，一個其實比較快，第二個其實我們也是希望主要是給大家留下一些印象
16:34.960–16:40.560
知道是怎麼一回事就可以了，因為之後的編寫主要是讓我們 AI 來進行編寫
16:40.560–16:43.480
所以我們可能就不像之前的公塊課一樣
16:43.480–16:45.940
圍繞每一個 API 的每一行代碼來進行講解
16:45.940–16:47.980
因為現在來看其實意義不是很大
16:47.980–16:49.560
你總之你核心是要知道
16:49.560–16:51.520
這個 Response API 到底是做什麼的
16:51.520–16:53.080
這點其實會非常重要
16:53.080–16:55.800
當然我們下面其實是圍繞 Response API
16:55.800–16:56.940
做了一個小小的實驗
16:56.940–16:59.820
我們來搭建了一個簡單的 agent
16:59.820–17:02.560
然後這個 agent 基本上就是
17:02.560–17:04.940
現在有很多很多張表
17:04.940–17:07.320
然後我們來做一個簡單的數據分析
17:07.320–17:09.400
然後核心是從各個表當中
17:09.400–17:11.680
來進行數據提取跟數據查詢
17:11.680–17:15.180
當然我們這裡為什麼跟大家去先使用這個 Response API
17:15.180–17:16.200
搭建一個簡單的數據分析
17:16.200–17:17.640
因為從下一個小節開始
17:17.640–17:20.800
我們在使用 Codex 這樣更加複雜的工具的時候
17:20.800–17:23.300
實際上我們最後的目標不就是搭建
17:23.300–17:23.780
對吧
17:23.780–17:25.880
長成這樣的一個數據分析系統嗎
17:25.880–17:29.100
只不過我們現在從最底層的 API 出發
17:29.100–17:30.240
一點點來進行學習
17:30.240–17:33.980
到最後能搭建這麼一個比較複雜的數據分析系統
17:33.980–17:35.460
其實有很長的路要走
17:35.460–17:38.000
所以我們在最初就給大家舉一個小例子
17:38.000–17:41.660
如果我們現在是使用 Response API 來搭建一個數據分析系統的話
17:41.660–17:42.700
那麼未來它是一個
17:42.700–17:45.980
那麼它首先這第一步應該怎麼賣出去
17:45.980–17:48.860
然後我們再來考慮使用這 Codex 之後
17:48.860–17:53.240
你整個搭建數據分析系統的效率跟速度就可以起飛
17:53.240–17:53.580
對吧
17:53.580–17:56.480
我們來一步一步來看它是怎麼樣來進行運行的
17:56.480–17:58.480
當然這裡我們涉及到一個數據集
17:58.480–17:59.640
叫 Allist
17:59.640–18:02.120
它是巴西電商公司的開源數據集
18:02.120–18:04.380
這個數據集其實非常龐大
18:04.380–18:08.040
裡面總共有這麼十幾萬行的這個數據
18:08.040–18:09.580
那這個數據集也是我們之後
18:09.580–18:13.380
在做我們當前整個數據分析系統的性能測試的時候
18:13.380–18:14.560
最核心的這個數據集
18:14.560–18:15.380
所以大家可以看一下
18:15.380–18:18.360
當然其實對於所謂這個電商的這個數據
18:18.360–18:20.460
其實主要是分成這麼兩大類
18:20.460–18:21.820
其中一類是訂單
18:21.820–18:23.060
另一類是客戶
18:23.060–18:25.720
這兩類數據表格
18:25.720–18:28.000
這個數據集並非單獨的數據集
18:28.000–18:30.580
而是分為許多許多許多子數據集
18:30.580–18:32.580
然後這個orders就是你訂單
18:32.580–18:34.220
然後customer就是當前客戶
18:34.220–18:35.420
等等非常多非常多
18:35.420–18:40.580
總之近期訂單歷史訂單非常多非常多
18:40.580–18:42.760
總共是一個世界外行的數據表格
18:42.760–18:45.620
那麼這個數據表其實會有點複雜
18:45.620–18:48.400
我們等一下都會看到這個數據表裡面完整的內容
18:48.400–18:49.740
總之大家需要知道是
18:49.740–18:50.920
哎呀 這裡有個數據表格
18:50.920–18:53.360
好 那麼如果你現在想要使用
18:53.360–18:55.360
比如說Deepseek v4這樣的模型
18:55.360–18:58.700
搭配著它現在已經兼容的Responses API
18:58.700–19:00.500
去搭建一個數據分析系統
19:00.500–19:03.760
大家可以想想看有哪一些想法
19:03.760–19:04.280
對不對
19:04.280–19:06.000
其實我們對於現在的agent開發來說
19:06.000–19:08.100
首先你得有一個基本的思路
19:08.100–19:09.840
和一些基礎的想法
19:09.840–19:11.560
可能我們就會涉及到
19:11.560–19:13.440
比如說我現在資料庫
19:13.440–19:14.780
數據存儲的資料庫裡面
19:14.780–19:16.520
所以我需要有一些
19:16.520–19:19.120
從資料庫裡面取出數據的這樣的工具
19:19.120–19:19.720
對不對
19:19.720–19:21.680
然後也需要有一些
19:21.680–19:23.840
我們去查詢數據這樣的工具
19:23.840–19:26.700
然後同時還需要有一些讀取數據的工具
19:26.700–19:28.320
然後同時還需要有一些
19:28.320–19:31.100
查詢具體的每一個數據裡面的
19:31.100–19:32.120
行和列之間的工具
19:32.120–19:34.060
這裡面其實我們是給出一系列工具
19:34.060–19:35.040
列出數據表格
19:35.040–19:37.240
然後查詢每一個數據表
19:37.240–19:38.500
什麼來源表明
19:38.500–19:39.800
然後什麼查詢
19:39.800–19:41.220
每個數據項目的
19:41.220–19:42.560
原始數據
19:42.560–19:43.220
其來源
19:43.220–19:45.020
其最大行數
19:45.020–19:47.360
透過編寫設計代碼來執行
19:47.360–19:48.560
同時還需要
19:48.560–19:51.140
去建立
19:51.140–19:53.640
去實現一個能夠單獨建立資料集的
19:53.640–19:55.000
這樣的外部工具等等
19:55.000–19:58.160
這其實是我們目前建議的數據分析過程中
19:58.160–19:59.180
我們最核心
19:59.180–20:00.060
最常用的
20:00.060–20:01.560
使用資料庫來進行操作的啊
20:01.560–20:02.860
像是四項工具啊
20:02.860–20:03.540
列數表格
20:03.540–20:04.020
對不對
20:04.020–20:05.360
查詢它的原始數據啊
20:05.360–20:07.200
就是查詢這個資料表格的真實情況
20:07.200–20:08.240
然後呢編寫 SQL 啊
20:08.240–20:09.420
來進行這個讀取啊
20:09.420–20:10.620
然後呢去建立表格
20:10.620–20:11.760
把這個數據給取出來啊
20:11.760–20:13.240
基本上我們說這四個工具呢
20:13.240–20:14.340
是非常核心的
20:14.340–20:15.220
這四個工具
20:15.220–20:15.420
好
20:15.420–20:15.980
那麼下面啊
20:15.980–20:17.420
其實就是關於這四項工具的
20:17.420–20:19.620
這樣的定義方法了啊
20:19.620–20:20.380
那麼這裡面呢
20:20.380–20:22.420
其實各種不同類型的這個工具啊
20:22.420–20:22.740
它呢
20:22.740–20:23.740
其實呃
20:23.740–20:25.060
我們上面提到的具體功能
20:25.060–20:26.240
其實定義還是非常清楚的啊
20:26.240–20:30.060
這裡我們都是使用 Python
20:30.060–20:32.060
SQL 查詢的一些工具
20:32.060–20:33.800
其實它背後的核心實現邏輯
20:33.800–20:35.860
就是把使用者的輸入語言
20:35.860–20:37.080
把它轉換成對應的 SQL 代碼
20:37.080–20:39.260
接著再進行檢查
20:39.260–20:40.740
檢查 Sirco 程式碼本身的格式
20:40.740–20:41.920
那麼接下來就可以開始執行
20:41.920–20:45.540
這就是基本的操作方法
20:45.540–20:49.040
接下來介紹這些工具的建立方式
20:49.040–20:51.360
然後我們就可以將這個工具
20:51.360–20:55.720
連結到當前的 Responses API 中
20:55.720–20:57.940
那麼接下來下面有一個 Stream
20:57.940–20:59.160
以列印的方式輸出
20:59.160–20:59.800
那麼接下來呢
20:59.800–21:01.640
我們說一個極簡的
21:01.640–21:03.380
一個簡單的 agent
21:03.380–21:04.940
實際上就相當於完成了
21:04.940–21:06.940
當然我們這裡其實每個
21:06.940–21:09.100
每個外部函數
21:09.100–21:11.780
它具體完整的定義方法啊
21:11.780–21:12.300
這裡面呢
21:12.300–21:13.540
大家可以自己去看一下啊
21:13.540–21:14.940
因為實際上我們說啊
21:14.940–21:16.460
這個每個外部函數的定義呢
21:16.460–21:17.720
都會比較複雜啊
21:17.720–21:19.640
但是這裡先給大家簡單的
21:19.640–21:20.860
留下這個印象啊
21:20.860–21:22.180
就是對於現在的
21:22.180–21:23.340
我們在進行啊
21:23.340–21:24.820
這個 agent 的開發過程中啊
21:24.820–21:26.620
那麼如果你需要去搭建一個
21:26.620–21:28.200
數據分析這樣的 agent 的話
21:28.200–21:31.420
然後如果你現在去使用這個 Responses API 的話
21:31.420–21:33.120
實際上實現起來會非常簡單
21:33.120–21:34.800
我們說你只需要定義好
21:34.800–21:37.460
我們剛剛所說的擁有這些功能的外部函數
21:37.460–21:41.820
然後把這些函數和當前的 model 模型放在一起
21:41.820–21:43.520
對不對來進行封裝
21:43.520–21:47.060
然後最後它就可以直接變成一個簡單的 agent
21:47.060–21:48.720
就可以直接順利執行
21:48.720–21:49.480
就是這麼回事
21:49.480–21:52.360
但這裡其實會具體涉及到很多的一些程式碼
21:52.360–21:54.740
就比如說我們如何把自然語言轉化成 Sirco
21:54.740–21:55.300
對不對
21:55.300–21:59.900
接著，Sircle 本身的程式碼如何提升其準確性等等，這些都是我們需要考慮的。
21:59.900–22:03.360
這部分可能屬於比較進階的功能。
22:03.360–22:06.140
在我們的公開課程中，可能沒有足夠的時間來詳細展開說明。
22:06.140–22:09.040
但是，這裡提供給大家的這些程式碼，
22:09.040–22:12.380
實際上每一段程式碼都可以真實地執行。
22:12.380–22:14.200
如果大家感興趣的話，
22:14.200–22:16.260
課後可以單獨再去查看這些程式碼。
22:16.260–22:19.800
或者你也可以直接將其匯入到你本地的環境中。
22:19.800–22:23.560
正如我們所說，每一個核心的外部函數，
22:23.560–22:26.560
我們下面都有完整的腳本及其功能的定義。
22:26.560–22:29.500
你可以直接使用它們，這也是沒問題的。
22:29.500–22:31.840
只是這裡我們要跟大家強調的一點是，
22:31.840–22:35.120
其實對於當前的 Response API 來說，
22:35.120–22:37.280
如果你想創建一個數據分析 Agent，
22:37.280–22:38.940
其實這也可以非常簡單。
22:38.940–22:39.500
對吧？
22:39.500–22:42.740
我們不過就是把工具封裝在一起。
22:42.740–22:44.660
然後用戶輸入一個業務問題，
22:44.660–22:46.640
我們就查看需要使用哪些工具。
22:46.640–22:47.240
對吧？
22:47.240–22:49.180
然後透過 Response API，
22:49.180–22:50.800
它本質上實際上是一個 Agent 循環（agent loop）。
22:50.800–22:55.440
這是一個不斷循環的操作過程。
22:55.440–22:58.620
它會不斷嘗試調用各種各樣的工具，
22:58.620–23:00.240
進行多步驟的工具調用，
23:00.240–23:02.220
或是工具的並發使用等等。
23:02.220–23:05.200
然後最後完成時，
23:05.200–23:07.600
最終會輸出一段這樣的結果。
23:07.600–23:11.420
最後我們也可以讓它繪製一些表格等。
23:11.420–23:13.760
它基本上就是這樣的一個過程。
23:13.760–23:14.720
但是它的底層，
23:14.720–23:16.900
我們說上面其實是大模型運行的層級，
23:16.900–23:20.560
底層實際上我們肯定需要有維護的數據庫。
23:20.560–23:25.660
這裡我們預設的數據庫是 CircleLite 和 MyCircle 這兩種數據庫。
23:25.660–23:30.880
然後，我們上面生產出的各種消息，
23:30.880–23:34.920
或者你的 Circle 從數據庫中具體執行等，
23:34.920–23:36.300
然後執行完畢之後，
23:36.300–23:41.700
你最後返回的 Circle 數據庫內容也會拼接回我們原始的消息列表中，
23:41.700–23:44.020
然後共同回覆用戶當前的問題。
23:44.020–23:45.360
就是這樣的一個過程。
23:45.360–23:48.460
所以其實現在我們在進行 Agent 開發的過程中
23:48.460–23:51.420
本質上來說，如果從最底層來看
23:51.420–23:52.860
無非就是建立好工具
23:52.860–23:56.140
然後將你當前的 Agent 與之結合
23:56.140–23:58.020
接著進行一些測試
23:58.020–23:58.920
進行運行
23:58.920–24:00.880
看看能否順利運行
24:00.880–24:02.080
在上面我們最底層
24:02.080–24:03.220
最上面的這個腳本
24:03.220–24:04.280
最後面這兩個腳本
24:04.280–24:07.960
實際上是去查詢我們當前的數據
24:07.960–24:10.660
一段時間內的銷售結果
24:10.660–24:12.000
各式各樣的
24:12.000–24:15.280
巴西電商各式各樣不同品類的商品
24:15.280–24:19.420
其實際銷售量的分佈情況
24:19.420–24:23.220
這是我們進行的一個查詢
24:23.220–24:25.200
然後最後生成了一張圖片
24:25.200–24:26.240
就是這麼一回事
24:26.240–24:29.200
那麼實際上具體運行腳本和代碼
24:29.200–24:30.880
實際上就是上面這些腳本和代碼
24:30.880–24:34.080
這是在數據庫中查詢數據的完整腳本
24:34.080–24:36.140
那下面是查詢完數據之後
24:36.140–24:38.520
生成最終運行結果的腳本
24:38.520–24:42.800
那麼裡面實際上本質上都是去關聯到我們當前的 Agent
24:42.800–24:44.500
進行一輪又一輪的運行
24:44.500–24:45.300
是怎麼一回事
0:00.000–0:01.531
zh那么紧接着我们就来看看,
那麼接下來我們就來看看
0:01.531–0:04.720
zhResponse API到底应该如何上手来进行使用。
到底該如何上手使用 Response API。
0:04.720–0:09.139
zh这个其实是我们现在在去做开发的过程当中,
這其實是在我們現在進行開發的過程中
0:09.139–0:14.000
zh可能都需要会涉及到一些底层的通信格式的讲解。
可能都會涉及到一些底層通訊格式的講解。
0:14.000–0:15.303
zh当然如果是去年的话,
當然如果是去年的話
0:15.303–0:16.997
zh这部分内容应该是非常核心,
這部分內容應該是非常核心
0:16.997–0:18.720
zh非常重要的一部分的内容。
非常重要的一部分內容。
0:18.720–0:20.400
zh还有底层的开发范式,对不对?
還有底層的開發範式，對吧？
0:20.400–0:22.680
zhOpenAI的Response API,
OpenAI 的 Response API
0:22.680–0:25.560
zh还有之前的ChatComplations API,
還有之前的 ChatCompletions API
0:25.560–0:27.240
zh这都是我们将用大模型的基础。
這都是我們將使用大模型的基礎。
0:27.240–0:30.080
zh到现在在webcoding时代
到現在在 webcoding 時代
0:30.080–0:30.900
zh这些很多功能
這些很多功能
0:30.900–0:32.200
zh我们其实都可以让大模型
我們其實都可以讓大模型
0:32.200–0:32.820
zh帮我们完成
幫我們完成
0:32.820–0:34.520
zh所以像这部分内容
所以像這部分內容
0:34.520–0:35.560
zh仍然是很重要
仍然很重要
0:35.560–0:37.120
zh但是我们可能就不需要
但是我們可能就不需要
0:37.120–0:39.140
zh去特别深入的吸引到
去特別深入地鑽研到
0:39.140–0:39.920
zh每一行代码
每一行程式碼
0:39.920–0:40.700
zh每一个参数
每一個參數
0:40.700–0:41.820
zh分别代表什么样的含义
分別代表什麼樣的含義
0:41.820–0:43.040
zh这个程度来进行理解
這個程度來進行理解
0:43.040–0:43.900
zh你只需要知道是
你只需要知道是
0:43.900–0:45.120
zh它是干什么的
它是做什麼的
0:45.120–0:46.020
zh有什么用
有什麼用
0:46.020–0:47.760
zh以及你能怎么用
以及你能怎麼用
0:47.760–0:49.340
zh这个东西其实是最重要的
這個東西其實是最重要的
0:49.340–0:50.760
zh那么我们接下来就来看看
那麼我們接下來就來看看
0:50.760–0:53.200
zhOpenAI的Responses API
OpenAI 的 Responses API
0:53.200–0:54.200
zh到底是什么
到底是什麼
0:54.200–0:56.480
zh当然这里大家如果不太了解
當然這裡大家如果不太了解
0:56.480–0:58.220
zh这个Response API到底是什么的话
這個 Response API 到底是什麼的話
0:58.220–1:00.940
zh你可以把它想象成就是OpenAI版的LongChain
你可以把它想像成就是 OpenAI 版的 LangChain
1:00.940–1:04.140
zh专门负责给我们开发者一个接口
專門負責給我們開發者一個介面
1:04.140–1:06.820
zh去更好的去调用这样的一些大模型
去更好地呼叫這樣的一些大模型
1:06.820–1:10.100
zh然后把它们和一些工具给它绑在一块
然後把它們和一些工具綁在一起
1:10.100–1:11.620
zh最后做成一个Agent
最後做成一個 Agent
1:11.620–1:12.840
zh就是这样的一个API
就是這樣的一個 API
1:12.840–1:14.140
zh可以这么来进行理解
可以這麼來進行理解
1:14.140–1:16.120
zh当然其实这个Response API
當然其實這個 Response API
1:16.120–1:17.580
zh是去年3月11号
是去年 3 月 11 號
1:17.580–1:22.440
zhOpenAI正式开源的一个全新的一种大模型调度的一种方法
OpenAI 正式開源的一種全新的大模型調度方法
1:22.440–1:25.240
zh然后官网在OpenAI官网上也有非常详细的
然後官網在 OpenAI 官網上也有非常詳細的
1:25.240–1:28.500
zh关于使用这个Response API的一些好处啊
關於使用這個 Response API 的一些好處啊
1:28.500–1:32.300
zh和怎么去进行迁移呀的一些这个方法啊
和怎麼去進行遷移呀的一些方法啊
1:32.300–1:33.780
zh当然这里我们要说明的是
當然這裡我們要說明的是
1:33.780–1:36.980
zh其实每一家啊大保险厂商都有资格的啊
其實每一家大廠都有資格啊
1:36.980–1:38.700
zh这个API的调度的这个范式
這個 API 調度的這個範式
1:38.700–1:40.560
zh比如说对于这个
比如說對於這個
1:40.560–1:42.880
zhAnthelope来说啊
Anthropic 來說啊
1:42.880–1:45.460
zh他们呢自己有一套Anthelope API啊
他們自己有一套 Anthropic API 啊
1:45.460–1:47.680
zh还有一套Cloud Agents SDK啊
還有一套 Cloud Agents SDK 啊
1:47.680–1:49.360
zh那么对于OpenAI来说呢
那麼對於 OpenAI 來說呢
1:49.360–1:51.480
zh他们家啊有这个Response API啊
他們家有這個 Response API 啊
1:51.480–1:53.880
zh和Agent SDK啊两套开发框架啊
和 Agent SDK 啊兩套開發框架啊
1:53.880–2:00.700
zh这个其实每一家他们都会有推出一些适配自己家模型的一些agent通信和开发范式
這個其實每一家他們都會推出一些適配自家模型的 agent 通信和開發範式
2:00.700–2:01.600
zh是这么一回事
是這麼一回事
2:01.600–2:03.240
zh那么对于openAI来说
那麼對於 OpenAI 來說
2:03.240–2:10.640
zh他们其实当然这个responses API就是现在他们来进行模型调度的过程当中最核心的响应的这样的方法
他們當然這個 responses API 就是現在他們進行模型調度過程中最核心的響應方法
2:10.640–2:13.280
zh然后对于这个deep seek来说
然後對於這個 DeepSeek 來說
2:13.280–2:17.000
zh他现在是接入到了responses API这功能体系里面来
他現在是接入了 responses API 這個功能體系裡面來
2:17.000–2:19.760
zh当然这里其实有一个很有意思的一个点
當然這裡其實有一個很有意思的一個點
2:19.760–2:22.380
zh就在于说其实之前有同学会问到说
就在於說其實之前有同學會問到說
2:22.380–2:27.280
zhDeepseek他们是怎么去考虑去接入OpenAI的Response API的呢
DeepSeek 他們是怎麼考慮去接入 OpenAI 的 Response API 的呢
2:27.280–2:28.640
zh当然我们说对Deepseek来说
當然我們說對 DeepSeek 來說
2:28.640–2:30.840
zh他一旦接入OpenAI这个Response API之后
他一旦接入 OpenAI 這個 Response API 之後
2:30.840–2:33.780
zh他实际上就可以无缝的接入Codex的体系了
他實際上就可以無縫接入 Codex 的體系了
2:33.780–2:35.060
zh那他是怎么接入的呢
那他是怎么接入的呢
2:35.060–2:35.680
zh其实非常简单
其實非常簡單
2:35.680–2:36.940
zh就是在后训练的过程当中
就是在後訓練的過程當中
2:36.940–2:40.960
zh给了他很多的一些指令方面的训练集
給了他很多的一些指令方面的訓練集
2:40.960–2:45.860
zh让他的响应格式能够和Response API的响应格式来进行兼容
讓他的響應格式能夠和 Response API 的響應格式來進行兼容
2:45.860–2:48.720
zh这里其实就会说的会比较底层了
這裡其實就會說得比較底層了
2:48.720–2:49.760
zh因为其实大家知道
因為其實大家知道
2:49.760–2:51.580
zh对于任何大模型来说
對於任何大模型來說
2:51.580–2:53.760
zh它原始的这个输出这个内容
它原始的這個輸出這個內容
2:53.760–2:55.680
zh实际上就是一个又一个token
實際上就是一個又一個 token
2:55.680–2:57.440
zh或者一个又一个字符
或者一個又一個字符
2:57.440–2:59.940
zh这个字符里面内容其实会非常非常多
這個字符裡面內容其實會非常非常多
2:59.940–3:01.680
zh然后大模型输出的
接著是大模型輸出的
3:01.680–3:03.820
zh实际上是一段非常非常长的这个字符
實際上是一段非常非常長的這個字串
3:03.820–3:05.120
zh那么我们每次呢
那麼我們每次呢
3:05.120–3:08.280
zh在去进行大模型的这个聊天的过程当中
在進行大模型聊天的過程中
3:08.280–3:10.860
zh实际上后台是需要把很长的这段字符
實際上後台需要將很長的這段字串
3:10.860–3:13.060
zh来进行各式各样的格式解析的
來進行各種格式的解析
3:13.060–3:14.200
zh这段是什么
這段是什麼
3:14.200–3:15.180
zh那段是什么
那段是什麼
3:15.180–3:16.300
zh那么有一些呢
那麼有一些呢
3:16.300–3:19.180
zh他输出这个结果是给用户去看的
它輸出這個結果是給用戶看的
3:19.180–3:20.820
zh原来某一段话的回复
原來某一段話的回覆
3:20.820–3:22.360
zh那么也有一些输出这个结果
那麼也有一些輸出這個結果
3:22.360–3:24.740
zh可能是比如说工具调用信息
可能是例如工具調用資訊
3:24.740–3:27.780
zh他自己运行当中的一些状态信息等等等等
它自己運行過程中的一些狀態資訊等等
3:27.780–3:29.680
zh总之是有很长很长这段信息
總之有很長很長的這段資訊
3:29.680–3:32.700
zh那么这个信息是以什么样的格式来进行输出
那麼這個資訊是以什麼樣的格式來進行輸出
3:32.700–3:34.580
zh他就可以被什么样的格式来进行解析
它就可以被什麼樣的格式來進行解析
3:34.580–3:35.480
zh你可以这么来经理解
你可以這麼來理解
3:35.480–3:37.820
zh那只不过现在对于DeepseekV4
那只不過現在對於 Deepseek V4
3:37.820–3:39.300
zh整个正式版的模型来说
整個正式版的模型來說
3:39.300–3:43.960
zh他们选择了是以Responsees API这样的一个形式来进行输出
他們選擇是以 Responses API 這樣的形式來進行輸出
3:43.960–3:46.640
zh所以他们就可以被Response API来进行解析
所以他們就可以被 Response API 來進行解析
3:46.640–3:48.080
zh所以他就跟他兼容了
所以它就與它相容了
3:48.080–3:49.980
zh这么来进行理解就可以了
這麼來進行理解就可以了
3:49.980–3:50.600
zh是这么一回事
是這麼一回事
3:50.600–3:53.360
zh是他在训练过程当中进行的非常深度的设置
是它在訓練過程中進行的非常深度的設定
3:53.360–3:54.440
zhOK好
好的
3:54.440–3:57.020
zh那么问题是Response API它是什么东西
那麼問題是 Response API 它是什麼東西
3:57.020–3:57.680
zh对不对
對吧
3:57.680–4:01.440
zh它怎么样来进行的解析
它怎麼樣來進行解析
4:01.440–4:05.180
zh那么非常完整的一次Response API的调用
那麼非常完整的一次 Response API 的呼叫
4:05.180–4:07.420
zh大家可以看这段代码
大家可以看這段程式碼
4:07.420–4:10.040
zh那么这个代码实际上就是一次非常完整的
那麼這個程式碼實際上就是一次非常完整的
4:10.040–4:10.840
zh非常底层的
非常底層的
4:10.840–4:11.760
zh我们使用Python
我們使用 Python
4:11.760–4:12.700
zh当然你使用这个
當然你使用這個
4:12.700–4:14.420
zh使用这个TS
使用這個 TS
4:14.420–4:16.000
zh其实也是类似的
其實也是類似的
4:16.000–4:17.100
zh这样的语法规则
這樣的語法規則
4:17.100–4:19.460
zh来去完成一次通过Response API
來去完成一次透過 Response API
4:19.460–4:20.660
zh调用底层模型的
呼叫底層模型的
4:20.660–4:22.480
zh一整个完整的这样的一个流程
一整個完整的這樣一個流程
4:22.480–4:23.460
zh那它是什么样的呢
那它到底是什麼樣子呢
4:23.460–4:24.640
zh首先我们需要
首先我們需要
4:24.640–4:27.580
zh这个import OpenAI
這個 import OpenAI
4:27.580–4:28.580
zh就导入这样的库
就是匯入這樣的函式庫
4:28.580–4:30.340
zh然后导入这个库之后
然後匯入這個函式庫之後
4:30.340–4:31.500
zh接下来我们需要实力化
接下來我們需要實例化
4:31.500–4:32.680
zh一个OpenAI的客户端
一個 OpenAI 的客戶端
4:32.680–4:34.680
zh然后在OpenAI客户端里面
然後在 OpenAI 客戶端裡面
4:34.680–4:36.060
zh输入你的Deepseek API key
輸入你的 Deepseek API key
4:36.060–4:37.880
zh和Deepseek的这个base URL
和 Deepseek 的這個 base URL
4:37.880–4:39.380
zh这个base URL是定死的
這個 base URL 是固定不變的
4:39.380–4:40.600
zh然后这个Deepseek API key
然後這個 Deepseek API key
4:40.600–4:41.800
zh你需要自己去注册一个
你需要自己去註冊一個
4:41.800–4:45.160
zh那么这里就实力化了一个open AI的这样的客户端
那麼這裡就實例化了一個 OpenAI 這樣的客戶端
4:45.160–4:46.900
zh然后有了这个客户端
然後有了這個客戶端
4:46.900–4:49.300
zh或者你可以把它理解成是一个负了值的
或者你可以把它理解成是一個賦予了值的
4:49.300–4:52.620
zh一个open AI对象的一个实力化的一个对象
一個 OpenAI 物件的實例化物件
4:52.620–4:53.260
zh就这么一回事
就是這麼一回事
4:53.260–4:59.140
zh然后接下来就可以调用client.response.create这样的一个命令
然後接下來就可以呼叫 client.response.create 這樣的指令
4:59.140–5:03.800
zh就可以去获得一次对应的模型回复的这样的响应结果
就可以去獲得一次對應的模型回覆這樣的響應結果
5:03.800–5:06.440
zh这里我们输入modal等于deep seek v4 flash
這裡我們輸入 model 等於 deep seek v4 flash
5:06.440–5:09.220
zh然后这个instructor代表的含义
然後這個 instructor 代表的意義
5:09.220–5:10.860
zh实际上就是system prompt
實際上就是 system prompt
5:10.860–5:11.880
zh你可以这么来自己理解
你可以這麼來自己理解
5:11.880–5:15.100
zh就是我们整个的agent运行的方式当中
就是說我們整個 agent 運行的方式當中
5:15.100–5:15.960
ensystem prompt
系統提示詞
5:15.960–5:17.500
zh然后有一个input
然後有一個 input
5:17.500–5:18.500
zhinput代表的含义就是
input 代表的意義就是
5:18.500–5:20.380
zh我现在跟他来进行的对话
我現在跟他來進行對話
5:20.380–5:20.740
zh对不对
對不對
5:20.740–5:22.820
zh然后下面还有其他的参数
然後下面還有其他的參數
5:22.820–5:24.220
zh这下我们可以都不管
這下我們可以都不管
5:24.220–5:25.820
zh然后通过这样的方式
然後通過這樣的方式
5:25.820–5:27.860
zh就可以完成一次模型的调用
就可以完成一次模型的呼叫
5:27.860–5:29.240
zh当然我这里给大家举的例子
當然我這裡給大家舉的例子
5:29.240–5:31.340
zh都是生成的英文的提出词
都是生成的英文的提示詞
5:31.340–5:32.680
zh但用中文也是一样的
但用中文也是一樣的
5:32.680–5:33.380
zh没有任何影响
沒有任何影響
5:33.380–5:36.100
zh总之就可以完成一次对应的响应
總之就可以完成一次對應的回應
5:36.100–5:38.340
zh比如说我们这就可以让他来进行运行
舉例來說，我們就可以讓它來進行運行
5:38.340–5:40.440
zh我这个是在线的这个环境
我這個是在線的這個環境
5:40.440–5:41.540
zh就可以直接来进行运行
就可以直接來進行運行
5:41.540–5:42.440
zh也是一样对不对
也是一樣對不對
5:42.440–5:44.400
zh这个Response API
這個 Response API
5:44.400–5:46.700
zh先做好一个Client
先做好一個 Client
5:46.700–5:48.120
zh然后这Client
然後這個 Client
5:48.120–5:49.960
zh然后接下来就可以跟他来进对话了
然後接下來就可以跟它來進行對話了
5:49.960–5:50.720
zh就这么一回事
就這麼一回事
5:50.720–5:52.200
zh那么这个Client
那麼這個 Client
5:52.200–5:55.080
zh实际上我们现在所说的这个Response API
實際上我們現在所說的這個 Response API
5:55.080–5:57.300
zh实际上就是这Client里面的一个方法
實際上就是這個 Client 裡面的一個方法
5:57.300–6:01.320
zh通过他能够去获取一次又一次模型的响应结果
透過它能夠去獲取一次又一次模型的回應結果
6:01.320–6:02.900
zh是什么样的一个情况
是怎麼樣的狀況
6:02.900–6:04.420
zh好
好
6:04.420–6:07.880
zh那么对于我们当前的这个Response API来说
那麼對於我們當前的這個 Response API 來說
6:07.880–6:10.180
zh其实它返回的这个结果里面
其實它返回的這個結果裡面
6:10.180–6:11.700
zh包含的消息会非常多
包含的訊息會非常多
6:11.700–6:12.720
zh它会包含你的
它會包含你的
6:12.720–6:13.900
zh比如说Reasoning Item
舉例來說 Reasoning Item
6:13.900–6:15.680
zh推理的字段的内容
推理欄位的內容
6:15.680–6:17.280
zh会包含这个Message的内容
會包含這個 Message 的內容
6:17.280–6:18.620
zh会包含这个Function Call
會包含這個 Function Call
6:18.620–6:19.840
zh就是你工具调用这个内容
就是你工具調用這個內容
6:19.840–6:20.360
zh等等等等
等等等等
6:20.360–6:21.460
zh价格式各样这个内容
各式各樣這個內容
6:21.460–6:23.620
zh然后这个Message里面还会包含
然後這個 Message 裡面還會包含
6:23.620–6:25.580
zh它模型本身的output
它模型本身的輸出
6:25.580–6:28.060
zh或者其他的一些警告
或者其他的一些警告
6:28.060–6:29.440
zh拒绝的一些信息
拒絕的一些資訊
6:29.440–6:31.240
zh还有包括文本图像的一个信息
還有包括文本圖像的資訊
6:31.240–6:31.720
zh等等等等
等等等等
6:31.720–6:32.740
zh也就是它实际上
也就是說它實際上
6:32.740–6:33.460
zh你可以把理解成
你可以把它理解成
6:33.460–6:35.760
zh就是一个完整的一种响应格式
就是一種完整的回應格式
6:35.760–6:37.960
zh是这么样的一个基本的定位
是這麼樣的基礎定位
6:37.960–6:39.720
zh所以也是基于这样的响应格式
所以也是基於這樣的回應格式
6:39.720–6:43.720
zh我们才能够去很好的去跟当前大模型来进行对话
我們才能够去很好地跟當前大模型來進行對話
6:43.720–6:46.660
zh能够把它的对应结果来进行一个输出
能夠把它的對應結果來進行一個輸出
6:46.660–6:47.900
zh来进行一个响应
進行回應
6:47.900–6:48.820
zh那么上面也是一样的
那麼上面也是一樣的
6:48.820–6:49.480
zh我们又来了一遍
我們又執行了一遍
6:49.480–6:52.300
zh这个Response API完整的执行流程
這個 Response API 完整的執行流程
6:52.300–6:54.160
zh那么只不过在执行的过程当中
只不過在執行的過程中
6:54.160–6:57.600
zh我们这里是考虑把每一个Response里面的所有内容
我們這裡是考慮把每個 Response 裡面的所有內容
6:57.600–6:58.580
zh单独给你打印出来
單獨列印出來
6:58.580–7:00.420
zh来看一看它到底回复哪些东西
來看看它到底回覆了哪些東西
7:00.420–7:03.140
zh那么它回复内容包括什么Response ID
那麼它回覆的內容包括 Response ID
7:03.140–7:04.540
zhResponse的State
Response 的狀態
7:04.540–7:05.540
enResponse Model
Response 的模型
7:05.540–7:06.220
zh等等等等
等等等等
7:06.220–7:07.100
zh总之就是
總之就是
7:07.100–7:08.800
zh它的每一条消息回复里面
它的每一則訊息回覆裡面
7:08.800–7:10.660
zh实际上会包含我们当前
實際上會包含我們目前
7:10.660–7:13.720
zh所有的回复的内容
所有的回覆內容
7:13.720–7:15.680
zh所有当前模型运行的
所有目前模型運行的
7:15.680–7:17.060
zh全部的这样的信息
全部的這類資訊
7:17.060–7:17.940
zh换而言之就是
換言之就是
7:17.940–7:19.760
zh我们当前这样的模型
我們目前這樣的模型
7:19.760–7:21.960
zh在执行当前任务的时候
在執行當前任務時
7:21.960–7:23.100
zh所有的状态信息
所有的狀態資訊
7:23.100–7:24.340
zh你可以这么来进行理解
你可以這麼來理解
7:24.340–7:24.820
zh好
好
7:24.820–7:27.940
zh那么它和另外一个
那麼它和另一個
7:27.940–7:29.900
zh就是我们经常会讨论的
就是我們經常討論的
7:29.900–7:31.560
zh叫Chat Compilation API
稱為 Chat Completion API
7:31.560–7:33.040
zh它们两者之间
它們兩者之間
7:33.040–7:34.780
zh到底是什么样的一个
到底是什麼樣的
7:34.780–7:36.840
zh什么样的区别
什麼樣的區別
7:36.840–7:38.980
zh这里我们是首先需要放在这
這裡我們首先需要把它放在這裡
7:38.980–7:40.120
zh来给大家来进行个探讨
來給大家進行探討
7:40.120–7:41.600
zh因为其实很多同学之前
因為其實很多同學之前
7:41.600–7:42.940
zh其实是了解
其實是了解
7:42.940–7:45.100
zhOpenAI的Chat Compilations API的
OpenAI 的 Chat Completion API 的
7:45.100–7:46.400
zh那么这里面
那麼在裡面
7:46.400–7:48.440
zh我们说OpenAI是原上一版本的
我們說 OpenAI 是上一版本的
7:48.440–7:49.680
enChat Compilations API
Chat 彙編 API
7:49.680–7:51.340
zh它的核心的功能
它的核心功能
7:51.340–7:53.440
zh是去围绕Message消息列表
是去圍繞訊息列表
7:53.440–7:54.560
zh来进行编辑
進行編輯
7:54.560–7:55.620
zh也就是说它实际上
也就是說它實際上
7:55.620–7:57.480
zh是去维护一个又一个消息列表
是去維護一個又一個的消息列表
7:57.480–7:58.440
zh那一个消息列表里面
那一個消息列表裡面
7:58.440–8:00.000
zh我们需要由System
我們需要由System
8:00.000–8:05.400
zh也就是说它实际上是去维护一个又一个消息列表,那一个消息列表里面我们需要有systemmessage,需要有usermessage,有的时候还会有大模型回复回来message,
也就是說它實際上是在維護一個又一個的消息列表，而在那個消息列表裡面，我們需要有system message、user message，有時還會有大模型回覆回來的message。
8:05.400–8:14.600
zh但总之我们实际上重点是去维护它的模型每次运行过程当中消息列表,然后给它导入到当前模型里面去来进行一个运行,
但總之，我們實際上的重點是去維護它的模型在每次運行過程中的消息列表，然後將其導入到當前模型中進行運行。
8:14.600–8:16.000
zh来进行一个测试
進行測試
8:16.000–8:17.760
zh然后最后的模型也给你返回出一个消息
然後最後的模型也會給你返回一條消息
8:17.760–8:21.200
zh它返回消息的本质的也是一条消息
它返回消息的本質也是一條消息
8:21.200–8:23.880
zh所以原来的openAI它上一代的
所以原來OpenAI上一代的
8:23.880–8:24.900
zh或者deep seek也是一样
或者DeepSeek也是一樣
8:24.900–8:27.680
zh它之前支持的主要是chatcompletions API
它之前支持的主要是chatcompletions API
8:27.680–8:30.640
zh那么它那些主要是去维护一个消息列表
那麼它那些主要是去維護一個消息列表
8:30.640–8:33.100
zh而现在升级到了response API
而現在升級到了response API
8:33.100–8:37.100
zh你会发现它实际上是维护你当前运行的一个状态
你會發現它實際上是在維護你當前運行的狀態
8:37.100–8:39.120
zh所谓当前运行的状态
所謂當前運行的狀態
8:39.120–8:41.740
zh就指的是我们现在在运行的过程当中
指的就是我們現在在運行的過程中
8:41.740–8:45.020
zh一个模型它其实每次在进行响应的过程当中
一個模型其實每次在進行響應的過程中
8:45.020–8:47.860
zh它会有很多很多的一些状态方面这样的信息
它會有很多很多關於狀態方面的信息
8:47.860–8:50.240
zh而原来我们重点维护的消息列表
而原來我們重點維護的消息列表
8:50.240–8:52.720
zh你可以把理解成只是状态当中的一个维度
你可以把它理解為只是狀態當中的一個維度
8:52.720–8:53.640
zh仅此而已
僅此而已
8:53.640–8:55.800
zh那么现在我们说借助Response API
那麼現在我們說借助Response API
8:55.800–8:57.080
zh实际上对于开发者来说
實際上對於開發者來說
8:57.080–8:59.480
zh其实就能够非常便捷的把一些工具
其實就能夠非常便捷地把一些工具
8:59.480–9:02.040
zh把一些这个extract给它放到一块
把一些這個extract放到一塊
9:02.040–9:03.800
zh就可以迅速的构成一个agent
就可以迅速地構成一個agent
9:03.800–9:05.420
zh然后你只需要输入一个input
然後你只需要輸入一個input
9:05.420–9:08.900
zh它背后就可以完整的去执行一整个agent loop
它背後就可以完整地執行一整個agent loop
9:08.900–9:10.620
zh那所谓agent loop
那所謂agent loop
9:10.620–9:12.900
zh这点大家也可以这么理解一下
這點大家也可以這麼理解一下
9:12.900–9:14.820
zh就是我现在agent要调用一些工具
就是現在我的agent要調用一些工具
9:14.820–9:16.380
zh来完成一些事项
來完成一些事項
9:16.380–9:16.720
zh对不对
對不對
9:16.720–9:17.820
zh那这工具有的时候
那這些工具有時候
9:17.820–9:20.660
zh我们需要多部的进行调用
我們需要多部進行調用
9:20.660–9:23.260
zh有的时候也需要并发的来进行调用
有時也需要並發地進行調用
9:23.260–9:23.560
zh对不对
對不對
9:23.560–9:25.420
zh那原来我们需要实现多部
那原來我們需要實現多部
9:25.420–9:26.840
zh或者并发的这样的工具调用
或是並發地進行工具呼叫
9:26.840–9:28.760
zh你可能得编写更加复杂的
你可能需要編寫更複雜的
9:28.760–9:29.400
zh这样的一个程序
這樣的程式
9:29.400–9:31.460
zh或者是用比如说像long chain
或是使用例如像 LangChain
9:31.460–9:32.580
zh这样的agent开发框架
這樣的 Agent 開發框架
9:32.580–9:33.000
zh对不对
對吧
9:33.000–9:35.020
zh它其实是支持内部
它其實支援內部
9:35.020–9:37.560
zh去完成agent loop这样的工作的
去完成 Agent Loop 這樣的工作
9:37.560–9:39.480
zhagent loop就是它不断不断去调用工具
Agent Loop 就是它不斷地呼叫工具
9:39.480–9:42.020
zh直到它能够完成当前的请求为止
直到它能完成目前的請求為止
9:42.020–9:42.480
zh好
好
9:42.480–9:43.920
zh现在我们说这些功能
現在我們說這些功能
9:43.920–9:47.960
zh其实也是可以被responses API来去完成的
其實也可以由 Responses API 來完成
9:47.960–9:51.380
zh这个其实是它的一个功能上面这样的进阶
這其實是它在功能上的進階
9:51.380–9:53.900
zh如果原来你是使用chat completion API的话
如果你原本是使用 Chat Completion API
9:53.900–9:56.080
zh你可能就需要不断的去维护它的消息例表
你可能就需要不斷地去維護它的訊息列表
9:56.080–9:57.980
zh其实整个过程会非常的繁琐
其實整個過程會非常繁瑣
9:57.980–10:00.180
zh如果你需要去实现agent loop的话
如果你需要去實現 Agent Loop
10:00.180–10:01.740
zh其实你需要手动来进行搭建
其實你需要手動來搭建
10:01.740–10:03.300
zh而现在是用responses API
而現在是使用 Responses API
10:03.300–10:04.060
zh其实不需要
其實不需要
10:04.060–10:07.040
zh它内部是可以帮你去全自动的
它內部可以幫你自動地
10:07.040–10:09.140
zh完成agent loop这样的工作的
完成 Agent Loop 這樣的工作
10:09.140–10:12.020
zh所以其实对于Responses API来说
所以其實對於 Responses API 來說
10:12.020–10:13.820
zh它其实也就是你可以把它理解成
它其實也就是你可以把它理解成
10:13.820–10:15.500
zh就是一个类似于LongChain这样的一个
就是一個類似於 LangChain 這樣的
10:15.500–10:17.880
zhagent和工具把它绑定一块的一个脚手架
將 Agent 和工具綁定在一起的脚手架
10:17.880–10:20.660
zh这个是它的一个基础的认知
這是它的一個基礎認知
10:20.660–10:26.380
zh当然在OpenAI官方的给出的Responses API的说明里面
當然在 OpenAI 官方給出的 Responses API 說明裡面
10:26.380–10:27.780
zh它其实也有谈到说
它其實也有談到說
10:27.780–10:29.400
zh我们现在使用Responses API
我們現在使用 Responses API
10:29.400–10:32.920
zh相比于上一代的Chat Completions API来说
與上一代的 Chat Completions API 相比
10:32.920–10:34.760
zh其实它的性能是增长了3%
其實它的效能提升了 3%
10:34.760–10:38.480
zh它是在terminal的榜单上
它是在 Terminal 的排行榜上
10:38.480–10:40.560
zh它性能是增上了3%
它的效能提升了 3%
10:40.560–10:42.240
zh也就是说明有了框架
也就是說有了框架
10:42.240–10:43.720
zh去搭建一些agent
去搭建一些 Agent
10:43.720–10:45.640
zh实际上是能够更好的
實際上能夠更好地
10:45.640–10:48.660
zh更加稳定的去维护这些agent运行的
更穩定地去維護這些 Agent 的運作
10:48.660–10:50.820
zh它是有这样的一个功能在这
它是有這樣的功能在裡面
10:50.820–10:51.200
enOK
好的
10:51.200–10:53.960
zh这个是所谓的Responses API
這就是所謂的 Responses API
10:53.960–10:56.960
zh当然我们说对于Responses API来说
當然我們說對於 Responses API 來說
10:56.960–10:58.420
zh我们下面还有很多的一些
我們下面還有很多的一些
10:58.420–11:01.200
zh大家可以课后自己再去来进行
大家可以課後自己再去來進行
11:01.200–11:03.580
zh深度学习的一些内容和素材
深度學習的一些內容和素材
11:03.580–11:06.820
zh比如说它也是支持一些参数这样的调整的
比如說它也是支援一些參數這樣的調整
11:06.820–11:07.160
zh对不对
對不對
11:07.160–11:08.780
zh比如说什么temperature
比如說什麼 temperature
11:08.780–11:12.440
zh还有topia这样的一些底层的模型运行参数
還有 top_p 這樣的一些底層模型運行參數
11:12.440–11:13.200
zh这样的调整
這樣的調整
11:13.200–11:18.180
zh比如说你这个temperature调整的范围是在0到2之间
比如說你這個 temperature 調整的範圍是在 0 到 2 之間
11:18.180–11:20.420
zh然后temperature越高
然後 temperature 越高
11:20.420–11:21.860
zh那么它生成结果越就越不稳定
那麼它生成結果就越不穩定
11:21.860–11:22.700
zh然后temperature越低
然後 temperature 越低
11:22.700–11:24.140
zh它生成结果越稳定等等等等
它生成結果越穩定等等等等
11:24.140–11:28.480
zh同时它也是支持直接通过一些json schema
同時它也是支援直接透過一些 json schema
11:28.480–11:30.940
zh这个是来进行structured output
這個是用來進行結構化輸出
11:30.940–11:32.260
zh就是结构化的输出
就是結構化的輸出
11:32.260–11:33.220
zh那么结构化输出呢
那麼結構化輸出呢
11:33.220–11:35.500
zh实际上在现在很多的agent开发场景下
實際上在現在很多的 agent 開發場景下
11:35.500–11:37.100
zh都会非常非常的重要
都會非常非常的重要
11:37.100–11:37.480
zh对不对
對不對
11:37.480–11:39.000
zh你可以通过类似这样的方式
你可以透過類似這樣的方式
11:39.000–11:42.840
zh去设置好对应的这个结构化输出的
去設定好對應的這個結構化輸出的
11:42.840–11:44.980
zh这个结构化这个文本的这个要求
這個結構化這個文本的這個要求
11:44.980–11:45.640
zh然后呢
然後呢
11:45.640–11:47.760
zh把它直接带入到我们的
把它直接帶入到我們的
11:47.760–11:50.080
zhResponses API的这个text参数里面去
Responses API 的這個 text 參數裡面去
11:50.080–11:52.100
zh就让它能够进行结构化的输出了
就讓它能夠進行結構化的輸出了
11:52.100–11:52.840
zh是这么一回事
是這麼一回事
11:52.840–11:54.140
zh当然我们现在公开课
當然我們現在公開課
11:54.140–11:55.860
zh其实一般来说就不会围绕
其實一般來說就不會圍繞
11:55.860–11:56.940
zh比如说结构化输出里面
比如說結構化輸出裡面
11:56.940–11:58.640
zh具体它是规定哪些结构
具體它是規定哪些結構
11:58.640–12:00.140
zh这个Json schema的这个对象
這個 Json schema 的這個物件
12:00.140–12:01.540
zh到底代表什么样的含义
到底代表什麼樣的含義
12:01.540–12:02.600
zh来展开来说
來展開來說
12:02.600–12:03.860
zh实际上也是因为
實際上也是因為
12:03.860–12:05.660
zh这东西都可以让大模型来完成
這東西都可以讓大模型來完成
12:05.660–12:07.060
zh重点是你需要知道的是
重點是你需要知道的是
12:07.060–12:08.500
zh有这个responsive API之后
有了這個 Response API 之後
12:08.500–12:10.740
zh它的结果化输出会非常稳定
它的結果化輸出會非常穩定
12:10.740–12:13.400
zh是这么样的一个情况
就是這麼一個情況
12:13.400–12:14.520
zh具体怎么稳定
具體怎麼穩定
12:14.520–12:16.160
zh它其实有很多层的检验
它其實有很多層的檢驗
12:16.160–12:18.400
zh什么text format
像是 text format
12:18.400–12:20.320
zh一层的检验
一層的檢驗
12:20.320–12:22.260
zh返回结果的Json格式的
返回結果的 JSON 格式
12:22.260–12:23.760
zh一层本地的教验
一層本地的檢驗
12:23.760–12:26.780
zh最后再给你返回一个结果化输出
最後再給你返回一個結果化輸出
12:26.780–12:27.440
zh这样的文本
這樣的文本
12:27.440–12:30.640
zh它是可以经过多层的教验和反馈
它是可以經過多層的檢驗和反饋
12:30.640–12:33.020
zh最后给你输出一个结构化的文本
最後給你輸出一個結構化的文本
12:33.020–12:34.640
zh这个其实是没有什么问题的
這個其實是沒有什麼問題的
12:34.640–12:36.960
zh然后同时对于Response API来说
然後同時對於 Response API 來說
12:36.960–12:39.680
zh它还有非常关键的Tours的参数
它還有非常關鍵的 tools 參數
12:39.680–12:40.060
zh对不对
對不對
12:40.060–12:42.000
zhTours的参数我们一会儿就看到
tools 參數我們一會兒就看到
12:42.000–12:44.100
zh它其实和Launcher里面的Tours的参数
它其實和 Launcher 裡面的 tools 參數
12:44.100–12:45.440
zh实际上就是一样的
實際上就是一样的
12:45.440–12:46.740
zh给它输入一个工具
給它輸入一個工具
12:46.740–12:47.800
zh然后它就可以调用这工具
然後它就可以調用這個工具
12:47.800–12:49.440
zh来完成对应的工作
來完成對應的工作
12:49.440–12:50.580
zh是怎么样的情况
是怎麼樣的狀況
12:50.580–12:53.180
zh所以对于整个的Response API来说
所以對於整個 Response API 來說
12:53.180–12:55.040
zh核心样的参数就这么些
核心的參數就這麼些
12:55.040–12:57.600
zh模型instruction系统开发指令
模型 instruction 系統開發指令
12:57.600–12:58.280
zh对不对input
對不對 input
12:58.280–13:00.460
zh本次任务的基本请求
本次任務的基本請求
13:00.460–13:03.480
zh然后还有这个什么maxoutputtoken
然後還有這個什麼 max_output_tokens
13:03.480–13:05.700
zh这个最高的模型输出结果上线
這個最高的模型輸出結果上限
13:05.700–13:07.640
zh还有这个temperaturetoppr reasoning
還有這個 temperature、top_p、reasoning
13:07.640–13:08.600
zh对它推理强度
對它推理強度
13:08.600–13:09.360
zh刚不说了吗
剛才不是說了嗎
13:09.360–13:10.460
zh这个V4这个模型
這個 V4 這個模型
13:10.460–13:11.800
zh有三档推理强度
有三檔推理強度
13:11.800–13:13.820
zh然后下面还有这个text
然後下面還有這個 text
13:13.820–13:16.680
zh主要是去进行结构化输出的一些参数
主要是去進行結構化輸出的一些參數
13:16.680–13:17.500
zh然后还有这个tours
然後還有這個 tools
13:17.500–13:19.740
zh是可以绑定一些外部的这样的工具
可以綁定一些外部工具
13:19.740–13:21.140
zh然后它还有这个tourchoice
此外還有這個 tourchoice
13:21.140–13:22.060
zh代表的含义是
代表的意義是
13:22.060–13:23.220
zh我们每次运行的时候
我們每次執行時
13:23.220–13:24.780
zh指定的工具来进行运行
指定要使用的工具來進行運行
13:24.780–13:25.820
zh还有这个stream
還有這個 stream
13:25.820–13:26.260
zh对不对
對吧
13:26.260–13:27.820
zh流式打印等等等等
串流列印等等
13:27.820–13:28.900
zh有很多很多这些参数
有很多這樣的參數
13:28.900–13:30.320
zh基本上如果你看这参数
基本上如果你看這些參數
13:30.320–13:33.580
zh你会感觉他整个的运行的状态
你會感覺它整個的運行狀態
13:33.580–13:38.940
zh差不多就和LongChain的CreateAgent是非常类似的
跟 LongChain 的 CreateAgent 非常類似
13:38.940–13:39.360
zh对不对
對吧
13:39.360–13:44.160
zh那这个是现在对于DeepSeq V4正式版模型来说
這是目前針對 DeepSeq V4 正式版模型
13:44.160–13:46.940
zh他所选择的一套基本的API
所選擇的一套基本 API
13:46.940–13:49.640
zh当然下面还有关于什么流失打印
當然下面還有關於串流列印
13:49.640–13:51.080
zh是怎么样来进行操作的
是如何操作的
13:51.080–13:53.400
zh这一点大家也可以自己去看一下
這一點大家也可以自己去看一下
13:53.400–13:57.280
zh下面还有对应的可以来进行测试和运行的代码
下面還有對應的測試和運行代碼
13:57.280–13:59.180
zh关于流失打印其实也是一样的
關於串流列印其實也是一樣的
13:59.180–14:00.500
zh就是人工讲应起来
就是人工講起來
14:00.500–14:00.920
zh其实会非常
其實會非常
14:00.920–14:02.900
zh其实人工编写其实非常麻烦
其實人工編寫其實非常麻煩
14:02.900–14:04.480
zh但是对于现在的agent来说
但對於現在的 Agent 來說
14:04.480–14:05.940
zh他们编写其实非常简单
他們編寫其實非常簡單
14:05.940–14:06.760
zh所以你只需要知道
所以你只需要知道
14:06.760–14:08.740
zh他其实这个是可以非常顺利的
它其實可以非常順利地
14:08.740–14:09.820
zh来进行实现的
來進行實現
14:09.820–14:10.480
zh就没有什么问题
就沒有問題
14:10.480–14:11.460
zh然后同时
同時
14:11.460–14:13.760
zh他由于是维护每次运行的状态
由於它會維護每次執行的狀態
14:13.760–14:16.240
zh所以他也是可以把之前对话状态
所以它也可以將之前的對話狀態
14:16.240–14:17.040
zh给他传入进去的
傳入進去
14:17.040–14:19.760
zh把之前对话状态传入进去
將之前的對話狀態傳入
14:19.760–14:20.620
zh实际上相当于是
實際上相當於
14:20.620–14:22.800
zh把上一次任务执行记录的全部信息
把上一次任務執行的全部資訊
14:22.800–14:25.300
zh包括上一次咱们对话这个信息
包括上一次我們的對話資訊
14:25.300–14:26.240
zh都给他输入进去
都輸入進去
14:26.240–14:28.500
zh然后他就可以来实现多种对话了
然後它就可以實現多種對話了
14:28.500–14:29.100
zh就这么一回事
就是這麼一回事
14:29.100–14:34.700
zh这个其实是它的多轮对话的历史保存的一个基本的方法
這其實是多輪對話歷史保存的一個基本方法
14:34.700–14:39.900
zh就是把它的之前上一轮的response id给它传入进去
就是將上一輪的回應 ID 傳入進去
14:39.900–14:43.300
zh那么它接下来就可以顺利的来进行多轮对话了
這樣接下來就能順利進行多輪對話
14:43.300–14:45.400
zh这个是它的一个基本设置
這是它的一個基本設定
14:45.400–14:49.700
zh然后同时下面还有关于function calling的完整的外部循环
同時下方還有關於 Function Calling 的完整外部循環
14:49.700–14:51.860
zh就是我们现在要去定一个外部工具
就是我們現在要去定義一個外部工具
14:51.860–14:52.300
zh对不对
對吧
14:52.300–14:54.100
zh你这个什么查询天气的外部工具
像是查詢天氣的外部工具
14:54.100–14:55.700
zh各式各样的外部工具
各種各樣的外部工具
14:55.700–14:59.000
zh包括这里面是个结构化信息的匹配的一个外部工具
包括這裡面是結構化資訊匹配的外部工具
14:59.000–15:03.320
zh等等等等 都可以通类似使用类似这样的方式来进行一个定义
諸如此類，都可以透過類似這樣的方式來進行定義
15:03.320–15:07.720
zh定义好了外部工具之后 接下来在Responses API里面直接输入tools
定義好外部工具之後，接下來直接在 Responses API 中輸入 tools
15:07.720–15:11.960
zh然后把你的工具给它放进去 然后它就可以顺带进行运行 就这么简单
然後把你的工具放進去，它就能順帶執行，這麼簡單
15:11.960–15:16.440
zh当然如果你去拆 如果你去看它底层的响应的过程的话
當然如果你去拆解，如果你去看它底層的回應過程的話
15:16.440–15:20.920
zh这里其实就是一个我们去看它底层响应的过程完整的事例了
這裡其實就是我們去看它底層回應過程的完整範例
15:20.920–15:24.760
zh那么你会发现 它其实底层仍然还是一个function calling的完整流程
那麼你會發現，它底層其實仍然是一個 Function Calling 的完整流程
15:24.760–15:27.880
zh就是你给它关联工具之后 你先给工具发送个请求
就是你給它關聯工具之後，你先給工具發送請求
15:27.880–15:30.280
zh然后公共运行完了之后呢 给你一个function response message
然後公共運行完畢後，給你一個 Function Response Message
15:30.280–15:32.280
zh然后你接收到function response message之后呢
然後你接收到 Function Response Message 之後呢
15:32.280–15:34.080
zh再开启你的second response啊
再開啟你的第二次回應啊
15:34.080–15:36.280
zh就是再去结合最开始用户的问题啊
就是再去結合最初用戶的問題啊
15:36.280–15:38.280
zh去给用户来进行回复啊 是这么一回事啊
去給用戶進行回覆啊，是這麼一回事啊
15:38.280–15:40.680
zh所以这个呢实际上是一个验证的过程啊
所以這個呢實際上是一個驗證的過程啊
15:40.680–15:42.880
zh你要说一下啊 对于response API来说呢
你要說一下啊，對於 Response API 來說呢
15:42.880–15:44.680
zh他的这个也是一样的
他的這個也是一樣的
15:44.680–15:48.080
zh他的这个工具要用其本质上啊 也是这个function calling啊
他的這個工具要用其本质上啊，也是這個 Function Calling 啊
15:48.080–15:51.680
zh跟现在所有的其他的这个agent开发框架的这个function calling啊
跟現在所有的其他的這個 Agent 開發框架的 Function Calling 啊
15:51.680–15:52.680
zh也全部都是一样的
也全部都是一樣的
15:52.680–15:56.080
zh当然他其实非常完善好 整个response API里面
當然他其實非常完善好，整個 Response API 裡面
15:56.080–15:57.680
zh他其实有非常完善的功能
他其實有非常完善的功
15:57.680–16:04.040
zh包括它工具室外的时候
包括它工具室外的时候
16:04.040–16:14.960
zh所以也是基於response API,我們說deepseek它現在是擁抱了response API,才能夠更好的去接入到我們現在的codex裡面來進行運行。
所以也是基於 Response API，我們說 DeepSeek 它現在是擁抱了 Response API，才能夠更好的去接入到我們現在的 Codex 裡面來進行運行。
16:14.960–16:20.960
zh否则的话 如果Deepseekv4本身这个模型 它并不兼容Responsees API的话 那么它其实是没有办法
否則的話，如果 DeepSeek v4 本身這個模型，它並不相容 Responses API 的話，那麼它其實是沒有辦法
16:20.960–16:27.360
zh完整接入到Codex里面去 并且能完整的释放现在Codex的完整性能 这个其实做不到
完整接入到 Codex 裡面去，並且能完整的釋放現在 Codex 的完整性能，這個其實做不到
16:27.360–16:34.960
zh当然其实我们上面关于底层的API这个讲解 一个其实比较快 第二个其实我们也是希望主要是给大家留下一些印象
當然其實我們上面關於底層 API 這個講解，一個其實比較快，第二個其實我們也是希望主要是給大家留下一些印象
16:34.960–16:40.560
zh知道是怎么一回事就可以了 因为之后的编写主要是让我们AI来进行编写
知道是怎麼一回事就可以了，因為之後的編寫主要是讓我們 AI 來進行編寫
16:40.560–16:43.480
zh所以我们可能就不像之前的公块课一样
所以我們可能就不像之前的公塊課一樣
16:43.480–16:45.940
zh围绕每一个API的每一行代码来进行讲解
圍繞每一個 API 的每一行代碼來進行講解
16:45.940–16:47.980
zh因为现在来看其实意义不是很大
因為現在來看其實意義不是很大
16:47.980–16:49.560
zh你总之你核心是要知道
你總之你核心是要知道
16:49.560–16:51.520
zh这个Response API到底是干什么的
這個 Response API 到底是做什麼的
16:51.520–16:53.080
zh这点其实会非常重要
這點其實會非常重要
16:53.080–16:55.800
zh当然下面我们其实是围绕Response API
當然我們下面其實是圍繞 Response API
16:55.800–16:56.940
zh做了一个小小的实验
做了一個小小的實驗
16:56.940–16:59.820
zh我们来搭建了一个简单的一个agent
我們來搭建了一個簡單的 agent
16:59.820–17:02.560
zh然后这个agent基本上就是
然後這個 agent 基本上就是
17:02.560–17:04.940
zh现在有很多很多张表
現在有很多很多張表
17:04.940–17:07.320
zh然后我们来做一个简单的数据分析
然後我們來做一個簡單的數據分析
17:07.320–17:09.400
zh然后核心是从各个表当中
然後核心是從各個表當中
17:09.400–17:11.680
zh来进行数据提取跟数据查询
來進行數據提取跟數據查詢
17:11.680–17:15.180
zh当然我们这里为什么跟大家去先使用这个Response API
當然我們這裡為什麼跟大家去先使用這個 Response API
17:15.180–17:16.200
zh搭建一个简单的数据分析
搭建一個簡單的數據分析
17:16.200–17:17.640
zh因为从下一个小节开始
因為從下一個小節開始
17:17.640–17:20.800
zh我们在使用Codex这样更加复杂的工具的时候
我們在使用 Codex 這樣更加複雜的工具的時候
17:20.800–17:23.300
zh实际上我们最后的目标这不就是搭建
實際上我們最後的目標不就是搭建
17:23.300–17:23.780
zh对不对
對吧
17:23.780–17:25.880
zh长成这样的一个数据分析系统吗
長成這樣的一個數據分析系統嗎
17:25.880–17:29.100
zh只不过我们现在从最底层的API出发
只不過我們現在從最底層的 API 出發
17:29.100–17:30.240
zh一点点来进行学习
一點點來進行學習
17:30.240–17:33.980
zh到最后能搭建这么一个比较复杂的数据分析系统
到最後能搭建這麼一個比較複雜的數據分析系統
17:33.980–17:35.460
zh其实有很长的路要走
其實有很長的路要走
17:35.460–17:38.000
zh所以我们在最一开始就给大家举一个小例子
所以我們在最初就給大家舉一個小例子
17:38.000–17:41.660
zh如果我们现在是使用Response API来搭建一个数据分析系统的话
如果我們現在是使用 Response API 來搭建一個數據分析系統的話
17:41.660–17:42.700
zh那么未来它是一个
那麼未來它是一個
17:42.700–17:45.980
zh那么它首先这第一步应该怎么卖出去
那麼它首先這第一步應該怎麼賣出去
17:45.980–17:48.860
zh然后我们再来考虑使用这Codex之后
然後我們再來考慮使用這 Codex 之後
17:48.860–17:53.240
zh你整个搭建数据分析系统的效率跟速度就可以起飞
你整個搭建數據分析系統的效率跟速度就可以起飛
17:53.240–17:53.580
zh对不对
對吧
17:53.580–17:56.480
zh我们来一步一步来看它是怎么样来进行运行的
我們來一步一步來看它是怎麼樣來進行運行的
17:56.480–17:58.480
zh当然这里我们涉及到一个数据集
當然這裡我們涉及到一個數據集
17:58.480–17:59.640
zh叫Allist
叫 Allist
17:59.640–18:02.120
zh它是巴西电商公司的一个开源数据集
它是巴西電商公司的開源數據集
18:02.120–18:04.380
zh这个数据集其实非常庞大
這個數據集其實非常龐大
18:04.380–18:08.040
zh里面总共有这么十几万行的这个数据
裡面總共有這麼十幾萬行的這個數據
18:08.040–18:09.580
zh那这个数据集也是我们之后
那這個數據集也是我們之後
18:09.580–18:13.380
zh在做我们当前整个数据分析系统的性能测试的时候
在做我們當前整個數據分析系統的性能測試的時候
18:13.380–18:14.560
zh最核心的这个数据集
最核心的這個數據集
18:14.560–18:15.380
zh所以大家可以看一下
所以大家可以看一下
18:15.380–18:18.360
zh当然其实对于所谓这个电商的这个数据
當然其實對於所謂這個電商的這個數據
18:18.360–18:20.460
zh其实主要是分成这么两大类
其實主要是分成這麼兩大類
18:20.460–18:21.820
zh一个是orders
其中一類是訂單
18:21.820–18:23.060
zh一个是customers
另一類是客戶
18:23.060–18:25.720
zh这么两类的这个数据表格
這兩類數據表格
18:25.720–18:28.000
zh它这个数据集不是一个单独的数据集
這個數據集並非單獨的數據集
18:28.000–18:30.580
zh是分了好多好多好多个这个子数据的这个数据集
而是分為許多許多許多子數據集
18:30.580–18:32.580
zh然后这个orders就是你订单
然後這個orders就是你訂單
18:32.580–18:34.220
zh然后customer就是当前的客户
然後customer就是當前客戶
18:34.220–18:35.420
zh等等非常非常多
等等非常多非常多
18:35.420–18:40.580
zh总之近期订单历史订单非常非常多
總之近期訂單歷史訂單非常多非常多
18:40.580–18:42.760
zh总共是一个世界外行的数据表格
總共是一個世界外行的數據表格
18:42.760–18:45.620
zh那么这个数据表其实会有点复杂
那麼這個數據表其實會有點複雜
18:45.620–18:48.400
zh我们一会儿都会看到这个数据表里面完整的内容
我們等一下都會看到這個數據表裡面完整的內容
18:48.400–18:49.740
zh总之大家需要知道是
總之大家需要知道是
18:49.740–18:50.920
zh哎呀 这里有个数据表格
哎呀 這裡有個數據表格
18:50.920–18:53.360
zh好 那么如果你现在想要使用
好 那麼如果你現在想要使用
18:53.360–18:55.360
zh比如说Deepseek v4这样的模型
比如說Deepseek v4這樣的模型
18:55.360–18:58.700
zh搭配着它现在已经兼容的Responsees API
搭配著它現在已經兼容的Responses API
18:58.700–19:00.500
zh去搭建一个数据分析系统
去搭建一個數據分析系統
19:00.500–19:03.760
zh大家可以想想看有哪一些想法
大家可以想想看有哪一些想法
19:03.760–19:04.280
zh对不对
對不對
19:04.280–19:06.000
zh其实我们对于现在的agent开发来说
其實我們對於現在的agent開發來說
19:06.000–19:08.100
zh首先你得有一个基本的思路
首先你得有一個基本的思路
19:08.100–19:09.840
zh和一些基础的想法
和一些基礎的想法
19:09.840–19:11.560
zh可能我们就会涉及到
可能我們就會涉及到
19:11.560–19:13.440
zh比如说我现在数据库
比如說我現在資料庫
19:13.440–19:14.780
zh数据存储的数据库里面
數據存儲的資料庫裡面
19:14.780–19:16.520
zh所以我需要有一些
所以我需要有一些
19:16.520–19:19.120
zh从数据库里面取出数据的这样的工具
從資料庫裡面取出數據的這樣的工具
19:19.120–19:19.720
zh对不对
對不對
19:19.720–19:21.680
zh然后也需要有一些
然後也需要有一些
19:21.680–19:23.840
zh我们去查询数据这样的工具
我們去查詢數據這樣的工具
19:23.840–19:26.700
zh然后同时还需要有一些读取数据的工具
然後同時還需要有一些讀取數據的工具
19:26.700–19:28.320
zh然后同时还需要有一些
然後同時還需要有一些
19:28.320–19:31.100
zh查询具体的每一个数据里面的
查詢具體的每一個數據裡面的
19:31.100–19:32.120
zh航和列之间的工具
行和列之間的工具
19:32.120–19:34.060
zh这里面其实我们是给出一系列工具
這裡面其實我們是給出一系列工具
19:34.060–19:35.040
zh列出数据表格
列出數據表格
19:35.040–19:37.240
zh然后查询每一个数据表
然後查詢每一個數據表
19:37.240–19:38.500
zh什么来源表明
什麼來源表明
19:38.500–19:39.800
zh然后什么查询
然後什麼查詢
19:39.800–19:41.220
zh什么每一个数据的
每個數據項目的
19:41.220–19:42.560
zh这个原数据
原始數據
19:42.560–19:43.220
zh它的来源
其來源
19:43.220–19:45.020
zh它的最大最大行数
其最大行數
19:45.020–19:47.360
zh它的编写设计数代码来进行运行
透過編寫設計代碼來執行
19:47.360–19:48.560
zh同时还需要
同時還需要
19:48.560–19:51.140
zh去创建
去建立
19:51.140–19:53.640
zh去实现一个能够单独去创建数据集的
去實現一個能夠單獨建立資料集的
19:53.640–19:55.000
zh这样的一个外部工具等等
這樣的外部工具等等
19:55.000–19:58.160
zh这个其实是我们现在的建议数据分析的过程当中
這其實是我們目前建議的數據分析過程中
19:58.160–19:59.180
zh我们最核心
我們最核心
19:59.180–20:00.060
zh最常用的
最常用的
20:00.060–20:01.560
zh无聊数据库来进行操作的啊
使用資料庫來進行操作的啊
20:01.560–20:02.860
zh是像四项工具啊
像是四項工具啊
20:02.860–20:03.540
zh列数表格
列數表格
20:03.540–20:04.020
zh对不对
對不對
20:04.020–20:05.360
zh查他的这个原数据啊
查詢它的原始數據啊
20:05.360–20:07.200
zh就是查这个数据表格的这个真实情况
就是查詢這個資料表格的真實情況
20:07.200–20:08.240
zh然后呢编写circle啊
然後呢編寫 SQL 啊
20:08.240–20:09.420
zh来进行这个读数啊
來進行這個讀取啊
20:09.420–20:10.620
zh然后呢去创建表格
然後呢去建立表格
20:10.620–20:11.760
zh把这个数据给取出来啊
把這個數據給取出來啊
20:11.760–20:13.240
zh基本上我们说这四个工具呢
基本上我們說這四個工具呢
20:13.240–20:14.340
zh是非常核心的
是非常核心的
20:14.340–20:15.220
zh这么四个工具
這四個工具
20:15.220–20:15.420
zh好
好
20:15.420–20:15.980
zh那么下面啊
那麼下面啊
20:15.980–20:17.420
zh其实就是关于这四工具的
其實就是關於這四項工具的
20:17.420–20:19.620
zh这样的一个定义的这个方法了啊
這樣的定義方法了啊
20:19.620–20:20.380
zh那么这里面呢
那麼這裡面呢
20:20.380–20:22.420
zh其实各个不同类型的这个工具啊
其實各種不同類型的這個工具啊
20:22.420–20:22.740
zh他呢
它呢
20:22.740–20:23.740
zh其实呃
其實呃
20:23.740–20:25.060
zh我们上面他的具体的功能
我們上面提到的具體功能
20:25.060–20:26.240
zh其实定义还是非常清楚的啊
其實定義還是非常清楚的啊
20:26.240–20:30.060
zh这里我们都是使用的python
這裡我們都是使用 Python
20:30.060–20:32.060
zhSirco查询的一些工具
SQL 查詢的一些工具
20:32.060–20:33.800
zh其实它背后的核心实现逻辑
其實它背後的核心實現邏輯
20:33.800–20:35.860
zh就是把用户的输入的语言
就是把使用者的輸入語言
20:35.860–20:37.080
zh把它转换成对应的Sirco代码
把它轉換成對應的 SQL 代碼
20:37.080–20:39.260
zh然后把它再去检查一下
接著再進行檢查
20:39.260–20:40.740
zhSirco代码本身这样的格式
檢查 Sirco 程式碼本身的格式
20:40.740–20:41.920
zh那么接下来就可以来进行运行
那麼接下來就可以開始執行
20:41.920–20:45.540
zh就这么样的一个基本的使用方法
這就是基本的操作方法
20:45.540–20:49.040
zh下面就是这些工具的一些创建这样的方式
接下來介紹這些工具的建立方式
20:49.040–20:51.360
zh然后紧接着我们就可以把这工具
然後我們就可以將這個工具
20:51.360–20:55.720
zh给它关联到我们当前的Responses API里边来
連結到當前的 Responses API 中
20:55.720–20:57.940
zh那么接下来下面有一个Stream
那麼接下來下面有一個 Stream
20:57.940–20:59.160
zh就打印的这样的方式
以列印的方式輸出
20:59.160–20:59.800
zh那么接下来呢
那麼接下來呢
20:59.800–21:01.640
zh我们说你的一个极简的啊
我們說一個極簡的
21:01.640–21:03.380
zh一个简易的这个agent啊
一個簡單的 agent
21:03.380–21:04.940
zh实际上就相当于是完成了啊
實際上就相當於完成了
21:04.940–21:06.940
zh当然我们这里其实有个每一个
當然我們這裡其實每個
21:06.940–21:09.100
zh有每一个的这个外部函数
每個外部函數
21:09.100–21:11.780
zh它具体完整的这样的这个定义方法啊
它具體完整的定義方法啊
21:11.780–21:12.300
zh这里面呢
這裡面呢
21:12.300–21:13.540
zh会有大家可以自己去看一下啊
大家可以自己去看一下啊
21:13.540–21:14.940
zh因为实际上我们说啊
因為實際上我們說啊
21:14.940–21:16.460
zh这个每个外部函数的这个定义呢
這個每個外部函數的定義呢
21:16.460–21:17.720
zh都会比较复杂啊
都會比較複雜啊
21:17.720–21:19.640
zh但是这里面先给大家简单的啊
但是這裡先給大家簡單的
21:19.640–21:20.860
zh留下一个这个印象啊
留下這個印象啊
21:20.860–21:22.180
zh就是对于现在的
就是對於現在的
21:22.180–21:23.340
zh我们在进行啊
我們在進行啊
21:23.340–21:24.820
zh这个agent的开发过程当中啊
這個 agent 的開發過程中啊
21:24.820–21:26.620
zh那么如果你需要去搭建一个
那麼如果你需要去搭建一個
21:26.620–21:28.200
zh数据分析的这样的agent的话
數據分析這樣的 agent 的話
21:28.200–21:31.420
zh然后如果你现在去使用这个Responses API的话
然後如果你現在去使用這個 Responses API 的話
21:31.420–21:33.120
zh实际上实现起来会非常简单
實際上實現起來會非常簡單
21:33.120–21:34.800
zh我们说你只需要定义好
我們說你只需要定義好
21:34.800–21:37.460
zh我们刚刚所说的拥有这些功能的外部函数
我們剛剛所說的擁有這些功能的外部函數
21:37.460–21:41.820
zh然后把这函数和我们当前的model模型放在一块
然後把這些函數和當前的 model 模型放在一起
21:41.820–21:43.520
zh对不对来进行一个封装
對不對來進行封裝
21:43.520–21:47.060
zh然后最后它就可以直接就是一个简单的agent
然後最後它就可以直接變成一個簡單的 agent
21:47.060–21:48.720
zh就可以直接顺利来进行运行
就可以直接順利執行
21:48.720–21:49.480
zh就这么回事
就是這麼回事
21:49.480–21:52.360
zh但这里其实会具体涉及到很多的一些代码
但這裡其實會具體涉及到很多的一些程式碼
21:52.360–21:54.740
zh就比如说我们如何把自然预言转化成sicle
就比如說我們如何把自然語言轉化成 Sirco
21:54.740–21:55.300
zh对不对
對不對
21:55.300–21:59.900
zh然后呢Sircle本身这样代码如何去提升它的这样的准确性等等等等
接著，Sircle 本身的程式碼如何提升其準確性等等，這些都是我們需要考慮的。
21:59.900–22:03.360
zh那么这个可能就属于这个比较进阶的一些功能了
這部分可能屬於比較進階的功能。
22:03.360–22:06.140
zh这个我们公开课可能就没有时间展开来说了
在我們的公開課程中，可能沒有足夠的時間來詳細展開說明。
22:06.140–22:09.040
zh但是呢这里给大家提供的所有的这些代码呢
但是，這裡提供給大家的這些程式碼，
22:09.040–22:12.380
zh实际上每个代码都是可以真实的来进行运行的
實際上每一段程式碼都可以真實地執行。
22:12.380–22:14.200
zh然后呢大家如果感兴趣的话
如果大家感興趣的話，
22:14.200–22:16.260
zh课后呢可以单独再去看一下这个代码
課後可以單獨再去查看這些程式碼。
22:16.260–22:19.800
zh或者你也可以直接能把它导到你本地的这个环境里边去
或者你也可以直接將其匯入到你本地的環境中。
22:19.800–22:23.560
zh让它呢反正我们说每一个这个核心的这个外部函数
正如我們所說，每一個核心的外部函數，
22:23.560–22:26.560
zh我们下面都有完整脚本和它的功能的这样的定义
我們下面都有完整的腳本及其功能的定義。
22:26.560–22:29.500
zh你可以直接用它来进行的使用也是ok的
你可以直接使用它們，這也是沒問題的。
22:29.500–22:31.840
zh只不过这里我们就跟大家说的一点
只是這裡我們要跟大家強調的一點是，
22:31.840–22:35.120
zh是其实对于当前的Response API来说
其實對於當前的 Response API 來說，
22:35.120–22:37.280
zh如果你想创建一个数据分析agent
如果你想創建一個數據分析 Agent，
22:37.280–22:38.940
zh我知不知道它也可以非常简单
其實這也可以非常簡單。
22:38.940–22:39.500
zh对不对
對吧？
22:39.500–22:42.740
zh我们无非就是我的工具给它封闹到一起去
我們不過就是把工具封裝在一起。
22:42.740–22:44.660
zh然后用户输入一个业务的问题
然後用戶輸入一個業務問題，
22:44.660–22:46.640
zh我们就看需要使用哪些工具
我們就查看需要使用哪些工具。
22:46.640–22:47.240
zh对不对
對吧？
22:47.240–22:49.180
zh然后通过Response API
然後透過 Response API，
22:49.180–22:50.800
zh它本质上实际上是一个agent loop
它本質上實際上是一個 Agent 循環（agent loop）。
22:50.800–22:55.440
zh它是一个不断循环的这样的一个操作
這是一個不斷循環的操作過程。
22:55.440–22:58.620
zh它就会不断的尝试去调用各式各样的工具
它會不斷嘗試調用各種各樣的工具，
22:58.620–23:00.240
zh来进行多部工具调用
進行多步驟的工具調用，
23:00.240–23:02.220
zh或者工具的这样的并发使用等等
或是工具的並發使用等等。
23:02.220–23:05.200
zh然后最后完成了
然後最後完成時，
23:05.200–23:07.600
zh最后就给输出一段最终这样的结果
最終會輸出一段這樣的結果。
23:07.600–23:11.420
zh然后最后我们也可以让它去绘制一些表格等等
最後我們也可以讓它繪製一些表格等。
23:11.420–23:13.760
zh它其实基本上就是这么样的一个过程
它基本上就是這樣的一個過程。
23:13.760–23:14.720
zh但是它底层
但是它的底層，
23:14.720–23:16.900
zh我们说上面其实大模型的运行的层
我們說上面其實是大模型運行的層級，
23:16.900–23:20.560
zh底层实际上我们肯定是需要有维护的收据库
底層實際上我們肯定需要有維護的數據庫。
23:20.560–23:25.660
zh这里其实我们默认的数据库是CircleLite和MyCircle这么两种数据库
這裡我們預設的數據庫是 CircleLite 和 MyCircle 這兩種數據庫。
23:25.660–23:30.880
zh然后那么无非就是下来我们上面各式各样生产出来的消息
然後，我們上面生產出的各種消息，
23:30.880–23:34.920
zh或者你的Circle从你的数据库当中具体来进行运行等等
或者你的 Circle 從數據庫中具體執行等，
23:34.920–23:36.300
zh然后运行完了之后
然後執行完畢之後，
23:36.300–23:41.700
zh你最后返回的Circle数据库这样的内容也会拼接到我们原始的消息列表里面去
你最後返回的 Circle 數據庫內容也會拼接回我們原始的消息列表中，
23:41.700–23:44.020
zh然后共同回复用户当前这样的问题
然後共同回覆用戶當前的問題。
23:44.020–23:45.360
zh就是这样的一个过程
就是這樣的一個過程。
23:45.360–23:48.460
zh所以其实现在我们在进行Agent的开发过程当中
所以其實現在我們在進行 Agent 開發的過程中
23:48.460–23:51.420
zh本质上其实如果说最底层的话
本質上來說，如果從最底層來看
23:51.420–23:52.860
zh无非就是创建好工具
無非就是建立好工具
23:52.860–23:56.140
zh然后和你当前的agent给他放在一块
然後將你當前的 Agent 與之結合
23:56.140–23:58.020
zh然后最后来进行一些测试
接著進行一些測試
23:58.020–23:58.920
zh来进行运行
進行運行
23:58.920–24:00.880
zh看一下能不能够来进行顺利的运行
看看能否順利運行
24:00.880–24:02.080
zh上面我们最下面
在上面我們最底層
24:02.080–24:03.220
zh最上面这个脚本
最上面的這個腳本
24:03.220–24:04.280
zh最后面这两个脚本
最後面這兩個腳本
24:04.280–24:07.960
zh实际上是去查询我们当前的数据
實際上是去查詢我們當前的數據
24:07.960–24:10.660
zh它一段时间的销量的结果
一段時間內的銷售結果
24:10.660–24:12.000
zh它的各式各样的
各式各樣的
24:12.000–24:15.280
zh巴西店商各式各样不同品类的这样的商品
巴西電商各式各樣不同品類的商品
24:15.280–24:19.420
zh它实际上销量的一个分布情况
其實際銷售量的分佈情況
24:19.420–24:23.220
zh这个是我们来进行的一个查询
這是我們進行的一個查詢
24:23.220–24:25.200
zh然后最后生成了一张图片
然後最後生成了一張圖片
24:25.200–24:26.240
zh是这么一回事
就是這麼一回事
24:26.240–24:29.200
zh那么实际上具体运行脚本和代码
那麼實際上具體運行腳本和代碼
24:29.200–24:30.880
zh实际上就是上面这些脚本和代码
實際上就是上面這些腳本和代碼
24:30.880–24:34.080
zh这个是在数据库中查询数据的一个完整的脚本
這是在數據庫中查詢數據的完整腳本
24:34.080–24:36.140
zh那下面是查询完数据之后
那下面是查詢完數據之後
24:36.140–24:38.520
zh生成最终运行结果的这样的脚本
生成最終運行結果的腳本
24:38.520–24:42.800
zh那么里面实际上本质上都是去关联到我们当前agent
那麼裡面實際上本質上都是去關聯到我們當前的 Agent
24:42.800–24:44.500
zh来进行一轮又轮的运行
進行一輪又一輪的運行
24:44.500–24:45.300
zh是怎么样一回事
是怎麼一回事
影片筆記：DeepSeek V4正式版+Codex工业Agent开发实战！从零手搓AI数据分析Agent，Responses API调用流程与Codex核心功能详解！ p03 03.Responses API入门介绍与数据分析Agent开发入门
一句話總結
本段影片介紹了 OpenAI 的 Response API 核心概念，說明其如何自動處理 Agent Loop 並簡化開發，同時解析 DeepSeek V4 正式版如何透過後訓練兼容該 API 以接入 Codex 體系，並透過 Python 實例與巴西電商數據集案例，演示如何構建具備 SQL 查詢與可視化能力的數據分析 Agent。
核心重點
- Response API 的定位與優勢：
- 被比喻為「OpenAI 版的 LangChain」，旨在提供統一接口，將大模型與工具綁定，自動處理 Agent Loop（代理循環）。
- 相比舊版 Chat Completions API 需手動維護消息列表，Response API 維護的是「當前運行的狀態（State）」，能自動完成多步或並發的工具調用，簡化開發者工作。
- 支持結構化輸出（Structured Output）、流式打印（Streaming）及多輪對話狀態保存。
- DeepSeek V4 與 Response API 的兼容性：
- DeepSeek V4 正式版在後訓練階段，通過大量指令訓練集對指令格式進行訓練，使其輸出格式兼容 OpenAI 的 Response API。
- 這種兼容性使得 DeepSeek V4 能無縫接入 Codex 體系，若無法兼容則無法完整接入 Codex 並釋放其完整性能。
- 技術實現與參數解析：
- 透過 Python 代碼實例，展示如何初始化 Client、設置 API Key 與 Base URL，並調用
client.response.create。 - 關鍵參數包括：
model、instruction（System Prompt）、input、max_output_token、temperature、reasoning（推理強度）、text（結構化輸出）、tools及tool_choice。
- 實戰應用：數據分析 Agent：
- 使用巴西電商數據集（Allist，含 Orders 與 Customers 數據，約數十萬行）。
- 定義外部工具：列出數據表格、查詢元數據、編寫 SQL 代碼、創建表格。
- 實現邏輯：將自然語言轉換為 SQL，檢查格式後運行，通過 Response API 的 Agent Loop 不斷嘗試調用工具，最終返回結果並可繪製表格（如銷量結果及商品銷量分佈）。
詳細大綱
一、 Response API 的核心概念與定位
- 基本定義：OpenAI 於去年 3 月 11 日正式開源的全新大模型調度方法。
- 行業對比：各家大模型廠商均有自己的調度範式（如 Anthropic 的 API 與 Cloud Agents SDK，OpenAI 的 Response API 與 Agent SDK）。Response API 是 OpenAI 目前模型調度中最核心的響應方法。
- 核心價值：讓開發者無需深入理解每一行代碼或參數含義，只需知道其功能與用法，自動處理 Agent Loop。
二、 DeepSeek V4 與 Response API 的兼容性
- 接入原理：DeepSeek V4 正式版選擇以 Response API 的形式進行輸出，因此可被 Response API 解析。
- 後訓練機制：在後訓練過程中，通過大量指令訓練集，使模型的響應格式與 Response API 的響應格式兼容。
- 底層邏輯：大模型原始輸出為 Token/字符序列，後期通過格式解析區分用戶回覆、工具調用信息及狀態信息。DeepSeek V4 在訓練階段進行了深度設置以兼容此格式。
- 接入意義：一旦接入 OpenAI Response API，DeepSeek 即可無縫接入 Codex 體系。
三、 Response API 的技術實現與參數解析
- 代碼流程：
- 導入
OpenAI庫。 - 實例化
OpenAI客戶端（Client），輸入 DeepSeek API Key 及固定的 Base URL。 - 調用
client.response.create獲取模型響應。
- 響應內容結構：返回結果包含 Response ID、Response State、Response Model、Reasoning Item、Message、Function Call、警告/拒絕信息、文本/圖像信息等。本質上是一個完整的狀態響應格式。
- 核心參數說明：
model：指定模型。instruction：系統開發指令（System Prompt）。input：本次任務的基本請求。max_output_token：最高模型輸出結果上限。temperature：控制生成結果的穩定性（0-2 之間，越高越不穩定）。top_p：模型運行參數。reasoning：推理強度（V4 模型有三檔推理強度）。text：用於結構化輸出的參數。tools：綁定外部工具。tool_choice：指定每次運行使用的工具。stream：流式打印設置。
四、 Response API 與 Chat Completions API 的區別
- Chat Completions API（舊版）：
- 核心功能圍繞「消息列表（Message List）」進行編輯。
- 維護 System Message、User Message 及模型回覆 Message。
- 實現 Agent Loop 需手動搭建，過程繁瑣。
- Response API（新版）：
- 維護的是「當前運行的狀態（State）」，消息列表僅是狀態中的一個維度。
- 內部可自動完成 Agent Loop（不斷調用工具直到完成請求，支持多步或並發調用）。
- 開發者只需輸入 Input，後台自動執行完整 Agent Loop。
- 性能提升：在 Terminal 榜单上性能增長約 3%，能更穩定地維護 Agent 運行。
五、 高級功能與 Agent 開發實踐
- 結構化輸出（Structured Output）：支持通過 JSON Schema 設置結構化輸出要求，經過多層檢驗後輸出結構化文本，結果非常穩定。
- 多輪對話與狀態保存：通過傳入上一輪的
Response ID，可將之前對話狀態傳入，實現多輪對話歷史保存。 - 工具調用（Function Calling）機制：本質上仍是 Function Calling 流程，發送工具請求 -> 工具運行返回 Function Response Message -> 結合用戶問題進行第二次響應給用戶。
- 實戰案例：數據分析 Agent：
- 數據集：Allist（巴西電商公司開源數據集，含 Orders 訂單與 Customers 客戶數據，數十萬行）。
- 核心工具定義：列出數據表格、查詢數據表真實情況（元數據）、編寫 SQL 代碼進行讀數、創建表格以取出數據。
- 實現邏輯：將自然語言轉換為 SQL 代碼，檢查格式後運行，將工具封裝並與模型綁定，通過 Response API 的 Agent Loop 不斷嘗試調用工具，最終返回結果並可繪製表格。
- 底層數據庫：默認使用 SQLite 和 MySQL。
- 運行結果：查詢一段時間銷量結果及不同品類商品銷量分佈，生成圖片。
工具 / 模型 / 名詞整理
- OpenAI
- Response API (或 Responses API)
- Chat Completions API (或 Chat Compilations API)
- Anthropic (或 Anthelope)
- Anthropic API
- Cloud Agents SDK
- Agent SDK
- DeepSeek (或 Deep seek, DeepSeq)
- DeepSeek V4 (或 DeepSeq V4)
- DeepSeek V4 Flash (或 Deep Seek V4 Flash)
- Codex
- LangChain (或 LongChain)
- Python
- TypeScript (TS)
- SQL (或 Sirco, Sircle)
- SQLite (或 CircleLite)
- MySQL (或 MyCircle)
- Allist (數據集名稱)
- JSON Schema
- Agent Loop
- Structured Output
- Streaming (或 流式打印, 流失打印)
- System Prompt (或 instructor)
- Function Call
- Reasoning Item
- Response ID
- Response State
- Response Model
- Message
- Client
- API Key
- Base URL
操作流程整理
- 環境準備與初始化：
- 導入
OpenAI庫。 - 實例化
OpenAI客戶端（Client），配置 DeepSeek API Key 及 Base URL。
- 配置請求參數：
- 設置
model(如 deep seek v4 flash)。 - 設置
instruction(System Prompt)。 - 設置
input(對話內容)。 - 可選設置：
max_output_token,temperature,top_p,reasoning,text,tools,tool_choice,stream。
- 調用 API：
- 執行
client.response.create獲取模型響應。
- 解析響應與工具調用：
- 檢查響應內容，若包含
Function Call，則執行對應工具。 - 工具運行後返回
Function Response Message。
- Agent Loop 循環：
- 將工具返回結果結合用戶問題，進行第二次響應（Second Response）。
- 若仍需調用工具，則繼續循環，直到完成請求。
- 最終輸出：
- 返回最終結果，可能包含結構化文本、可視化圖片或數據查詢結果。
- 若需多輪對話，保存
Response ID以便下一輪傳入。
值得注意的限制或風險
- 兼容性依賴：DeepSeek V4 必須在後訓練階段兼容 Response API 格式，否則無法無縫接入 Codex 體系。
- 參數設置影響：
temperature設置過高（接近 2）會導致生成結果不穩定；reasoning強度設置影響推理能力。 - 工具調用複雜度：雖然 API 自動處理 Agent Loop，但開發者仍需正確定義和封裝外部工具（如 SQL 查詢邏輯），否則可能導致錯誤的數據查詢或格式檢查失敗。
- 數據集規模：實戰案例使用數十萬行的數據，需注意查詢效率與工具調用的次數限制。
逐字稿辨識疑點
- LongChain / LangChain：逐字稿中多次提及「LongChain」，根據上下文應指開發框架 LangChain。
- Anthelope / Anthropic：逐字稿中提及「Anthelope」，根據上下文應指 Anthropic。
- Deep seek / DeepSeek / DeepSeq：逐字稿中混用「Deep seek」與「DeepSeek」，以及「DeepSeq V4」，應均指 DeepSeek。
- Sirco / Sircle / SQL：逐字稿中提及將自然語言轉換為「Sirco」或「Sircle」代碼，根據上下文應指 SQL。
- CircleLite / SQLite：逐字稿中提及數據庫「CircleLite」，根據上下文應指 SQLite。
- MyCircle / MySQL：逐字稿中提及數據庫「MyCircle」，根據上下文應指 MySQL。
- Modal / Model：逐字稿中提及「modal 等於 deep seek v4 flash」，根據上下文應指參數
model。 - Instructor / Instruction：逐字稿中提及「instructor 代表的含義實際上就是 system prompt」，根據上下文應指參數
instruction。 - Tours / Tools：逐字稿中提及「Tours 的參數」，根據上下文應指參數
tools。 - Tourchoice / Tool Choice：逐字稿中提及「tourchoice 代表的含義」，根據上下文應指參數
tool_choice。 - 流失打印 / 流式打印：逐字稿中提及「流失打印」，根據上下文應指
streaming或流式輸出。 - 編寫設計數代碼 / 編寫代碼：逐字稿中提及「編寫設計數代碼」，語意不明，應指編寫代碼。
- 封鬧 / 封裝：逐字稿中提及「工具给它封鬧到一起去」，根據上下文應指「封裝」。
- 教驗 / 檢驗：逐字稿中提及「多層的教驗和反饋」，根據上下文應指「檢驗」。
- 航和列 / 行和列：逐字稿中提及「航和列之間的工具」，根據上下文應指「行和列」。
- 世界外行 / 數十萬行：逐字稿中提及「總共是一個世界外行的數據表格」，根據上下文應指「數十萬行」。
- 巴西店商 / 巴西電商：逐字稿中提及「巴西店商」，根據上下文應指「巴西電商」。
- OpenAI的Responses API / Response API：逐字稿中混用，應指 Response API。
- Chat Compilations API / Chat Completions API：逐字稿中提及「Chat Compilations API」，應指 Chat Completions API。
- 負了值 / 實例化：逐字稿中提及「負了值的 一個open AI對象的一個實力化的 一個對象」，應指實例化。
- 實力化 / 實例化：逐字稿中多次提及「實力化」，應指實例化。
- 大保险厂商 / 大模型廠商：逐字稿中提及「每一家啊大保险厂商都有资格的」，應指大模型廠商。
- 提出詞 / 提示詞：逐字稿中提及「生成的英文的提出詞」，應指提示詞。
- 经理理解 / 來理解：逐字稿中提及「你可以这么来经理理解」，應指來理解。
- 响应的这样的方法 / 響應的方法：逐字稿中提及「最核心的响应的这样的方法」，應指響應的方法。
- 接入了responses API这功能体系里面来 / 接入 Response API 功能體系：標記為疑似表述不清。
- 后训练的过程当中 / 後訓練過程：標記為疑似表述不清。
- 指令方面的训练集 / 指令訓練集：標記為疑似表述不清。
- 各式各样的格式解析 / 各種格式的解析：標記為疑似表述不清。
- 原来某一段话的回复 / 原來某一段話的回覆：標記為疑似表述不清。
- 他自己运行当中的一些状态信息 / 自身運行中的狀態信息：標記為疑似表述不清。
- Response ID / Response ID：標記為疑似表述不清。
- Response State / Response State：標記為疑似表述不清。
- Response Model / Response Model：標記為疑似表述不清。
- Reasoning Item / Reasoning Item：標記為疑似表述不清。
- Function Call / Function Call：標記為疑似表述不清。
- Message / Message：標記為疑似表述不清。
- System Prompt / System Prompt：標記為疑似表述不清。
- Input / Input：標記為疑似表述不清。
- Client / Client：標記為疑似表述不清。
- API Key / API Key：標記為疑似表述不清。
- Base URL / Base URL：標記為疑似表述不清。
- DeepSeek API Key / DeepSeek API Key：標記為疑似表述不清。
- DeepSeek Base URL / DeepSeek Base URL：標記為疑似表述不清。
- OpenAI Client / OpenAI Client：標記為疑似表述不清。
- Client.response.create / Client.response.create：標記為疑似表述不清。
- Model / Model：標記為疑似表述不清。
- Deep Seek V4 Flash / Deep Seek V4 Flash：標記為疑似表述不清。
- System Message / System Message：標記為疑似表述不清。
- User Message / User Message：標記為疑似表述不清。
- Agent Loop / Agent Loop：標記為疑似表述不清。
- Structured Output / Structured Output：標記為疑似表述不清。
- JSON Schema / JSON Schema：標記為疑似表述不清。
- Text Format / Text Format：標記為疑似表述不清。
- Local Validation / 本地檢驗：標記為疑似表述不清。
- Streaming / 流式打印：標記為疑似表述不清。
- Response ID / Response ID：標記為疑似表述不清。
尚未產生學習筆記
請在 Telegram 指令最後加上「學習」，例如：videonote 網址 英文 雙語 學習