我是张弛，博士毕业于新加坡南洋理工大学，现在在腾讯公司担任高级研究员博士期间，我主要从事的是计算机视觉，还有机器学习相关的研究课题。然后毕业之后，我加入腾讯的QQ影像中心，现在专注于用大模型解决问题，目前我比较感兴趣的就是这个AIGC方向还有多模态大语言模型。以及今天要探讨的这个agent方向。所以今天我的报告主要是这几个方面，一个是这个重点介绍一下我们做这个多模态大语言模型的。基于多模态大语言模型的一个agent应用，APP agent。
然后其次，我会简单讲一下我们围绕这个多模态大模型做了一些其他的研究工作。自从去年年初的这个Chart GPT出现之后，大语言模型。在很多领域都引发了一场革命。那这个模态大圆模型，仿佛赋予了这个大圆模型以视觉能力。与传统的多模态模型不同，例如image captioning模型，GPT-4这种多模态大模型在背后是蕴含知识的。例如，从图像中理解幽默成分或笑话，这是过去那种只是简单进行图像到语言信号翻译的工作所做不到的。GPT-4可以在各种场景中被应用，比如在OCR场景，或者多语言OCR场景。还有在理解特殊图像，如图表上也表现得很好。另外，它还具有一种叫做视觉指代的能力，当我们在一张图上点点画画时，这个多模态大模型能够理解我们想要表达的含义。此外，它还可以理解视频，将视频以采样帧的形式送入多张连续的图片，它就能实现对一个视频片段的连续过程的理解。还有就是对于用户界面的理解，它可以理解界面的一些元素和含义，然后你可以问它问题，它会告诉你去点击哪个位置。
对于更复杂的场景理解和规划，例如一个简单的问题，假如你扮演了一个机器人，在一个屋子里，想去厨房拿东西，你应该怎么做？然后，这个GPT-4它可以做好规划，告诉你要怎么走，并告诉你推理过程。所以，有了这样的能力之后，其实有一个很自然的想法，就是既然它可以思考，也可以观察，也可以告诉你怎么做，那其实这个事情就可以让它自己去执行，并不断的重复这个过程。这样的话，一个大语言模型就成为了一个所谓的agent，中文翻译叫代理，也就是说，在不用人的干预的情况下，让大模型自己去进行感知、思考、输出控制这样一个连续的操作。
在agent方向有很多优秀的工作，比如说像MetaGPT，那它是让这个不同于单个的这个GPT去执行一个任务时，它会让不同的GBT扮演不同的角色，然后配合起来，比如说开发一个软件。此外，像AutoGPT这样的技术，它允许GPT拥有一些权限，比如上网搜索、读写文件，甚至在电脑上执行命令。这样的话，它就可以代替人去操作电脑，或者是做一些复杂的任务。
今天，我主要讲的是一个能够操作手机的agent，叫做APP agent。它的最大特点是它是一个多模态agent。刚才我们讲的，比如Auto GPT或者是MetaGPT，它们其实还是在文字层面上进行的一些过程，不论是其感知还是输出，都是以文字为媒介。而多模态agent则不同，当它感知这个世界的时候，它并不是把这个世界用语言描述出来送给语言模型，而是直接通过它的视觉能力去看这个世界，然后去做后面的行为。
下面，我将展示一些demo。这些demo展示了APP agent如何像人一样去操作各种各样的APP，做不同的事情。比如说，发送一个邮件。我们只需要告诉它一句话，让它给某某人发个邮件问什么事儿。然后这个APP agent就可以去操作这个APP，填写收件人、主题以及邮件内容，这些都可以通过语言模型的能力去自我撰写。
还有一个比较有意思的例子，也是最典型的一个例子，就是P图的能力。假如说现在有这么一张图，看起来很暗。那我们想让它去用Lightroom这样一个P图软件把图修好。我们给它的指令就是你把这张图修好，也不告诉它这张图有什么问题，也不告诉它可以用什么工具以及每个工具的含义，只是告诉它一个很高层次的抽象任务。它就可以熟练地使用这样一个APP，把图修改到一个满意的状态。
接下来是使用推特的部分，例如，现在让它去搜索一个用户。这是可以做到的。这个程序可以一步一步地搜索到用户，并关注他们。还有一个比较有趣的地方是，当这项工作刚发布时，很多人担心它是否能通过图灵测试。于是我们尝试让这个智能体去测试一下推特的真实身份验证测试。由于这个GBD4具有强大的推理能力，它可以正确地做出选择，并通过这样的测试。所以，总的来说，这项工作就是让智能体像人一样使用手机。
在尝试创建这样一个系统的过程中，我们面临了许多挑战。第一个挑战就是如何高效地输出控制。控制其实是机器学习领域，或者说人工智能领域一个比较重要的课题。例如，机器人的控制就会非常复杂，也有很多专业领域和专业的人在做这件事。手机的控制其实也不容易，因为手机操作包括点击、滑动，还有一些更复杂的多点触控，甚至手势操作。这些手势用参数表示起来也是很复杂的。所以，控制这个问题是很重要的。
然后第二个挑战就是如何做到泛化。我们想要的是一个能操作各种各样的手机的智能体，而不仅仅是一个应用程序。泛化这件事真的那么容易做到吗？首先我们要思考的一个问题就是人能做到泛化吗？按照我们的分析来说，人其实做不到完全的泛化。给一个新的应用程序，人也无法直接去高效地使用它。但是人对应用程序的认知是非常充分的，人知道应用程序是一个什么样的东西，对于不同功能的应用程序有什么样的逻辑。所以，人的特点就是虽然不能泛化到所有新的应用程序，但是可以快速学习使用一个应用程序，只要通过简单的摸索。
人们可以上手一个APP，然后熟练地使用它，这是人的特点。呃，第三个挑战是什么样的学习是好的学习。这里呢，我其实总结了两个方向。一个是基于先验知识的简单学习，就像刚才讲的那样。如果人去学习一个新APP，比如这个APP是一个聊天软件，那它们的操作逻辑是很相似的，界面也不是很复杂，这种情况下我们学习起来可能就比较容易。那还有一种情况，就是先验知识不足，或者是一个特别复杂的学习。比如说，一旦你去使用一个专业软件，
接下来是第三个方面，即高效的训练与部署范式。训练这个大语言模型实际上是一个非常艰巨的任务。如何实现高效的训练呢？这也是一个重要的目标。
简单介绍一下，我们这个项目的实验环境是基于安卓系统的。我们有一个命令行接口，可以通过命令行来控制手机。比如，命令行中的“tap xy”就表示我们要点击xy的位置，这是一个接口。而安卓的开发输入软件有一个XML文件，可以解析出当前页面上所有可交互的元素。
在获取到所有可交互的元素之后，我们为每一个元素分配一个ID，并在ID上标注一个数字。这样，在这个界面上，每个元素都有一个对应的数字标注。比如，这个按钮是九号，那个按钮是七号，另一个按钮是六号。然后，LM（可能是指某种模型或算法）通过选择这些元素来操作APP。
控制是非常重要的。原来的命令行接口控制其实很复杂。比如，你想做一个简单的滑动手势，它需要输入很多参数，包括初始的xy坐标、结束的xy坐标，还有滑动的速度。实际上，GBT4（可能是指某种模型或算法）并不擅长预测这种连续的数字，它更擅长的是逻辑语言。所以，如果你问它应该选择哪个元素，它可以做得很好。但如果你让它输出屏幕上的xy坐标，它可能就做不好了。
另外，刚才讲的原手势操作参数过于复杂，这给agent的预测带来了额外的负担。我们这里首先简化了它的动作空间。我们可以提取出所有可交互的元素，然后只要把参数围绕这些元素的ID来做就可以了。比如，最简单的点击操作，只要你想点哪个元素，就把这个元素的标号作为参数传进去就行了。对于长按操作，原来可能需要预测长按的时间，但实际上这个时间在大多数场景下并不重要，我们只要设成一个定值就可以了。
比如说疫苗，那这个滑动也是滑动，大多数场景我们滑动是上滑下滑，左滑右滑。其实我们的参数也简化成了一个固定的方向，只要让语言模型去判断上下左右就可以了。然后，同样的滑动距离，我们也设定成几个定值：短、中、长。另外还有一个action，就是输入文字的action。人打字的话，可能要在键盘上不断地点击，但其实对于计算机来说就没有必要这么麻烦，只要把想输入的文字输入进去就可以了。其实我们这里就是text，它的参数就是你想输入的文字。
然后还有两个系统级的函数action，一个是返回，它直接去跳到上一个UI的界面。最后一个就是结束，表示整个任务都完成了，之后我们可以靠这个方式来终止任务。在我们的工作中，我们也在这方面做了一些丰富，比如说加了一个叫call grid的函数。那就是说，当我们想交互的区域不在这个ID上的时候，比如说我们现在想打五星，但是五星这里没有一个ID分配给它，那我们就可以套出这样一个网格，然后通过选择这个网格的序号来实现任意位置的交互。
对，这个是控制一侧。那这个控制一侧在手机APP上还是相对来说简单的一个任务。那重要的就是刚才我们讨论过的一些挑战。其实我们总体的思路就是，整个框架要设计成一个探索阶段和一个部署阶段。这个也是受人使用APP的启发。人虽然不能认识所有APP，但是对于一个新APP，它可以快速上手。一个是自己可以摸索一下，然后通过试错来知道APP如何使用。另外一个就是看别人如何使用，也可以很快的知道这个APP是怎么用的。所以，对于任何APP，我们都有一个探索阶段。探索完了之后，就了解了这个APP如何使用。那这个时候，我们就生成一份这个APP的使用文档，作为一个知识库。那当我们以后想高效地使用这个APP来完成各种各样任务的时候，就可以通过调用每个页面的文档来辅助决策。总体来说就是这样一个框架。
那探索到底是怎么探索呢？比如说现在这个APP，左边是这样一个界面，我现在点了这个15号这个位置，然后它变到了这样一个界面。探索其实就是通过这个过程来理解APP的使用方式。
关于15号的功能，这个UI的功能是什么呢？如果在这个上面进行某种操作，会发生什么呢？比如现在我们点击了这个位置，发现了关于temperature的颜色设置。那么我们可以总结下来，点击这个UI的区域会打开颜色设置，而这个颜色设置可以调整颜色。这就是一个典型的探索过程。
对于一个APP，我们就在这个APP内不断地点击、观察，最后就可以总结出一个详细的文档。这个文档记录了UI里面每个元素的功能。有了这样一个探索过程之后，我们就整理好了一个很详细的文档。在部署的时候，我们就参考这个文档来做一些比较复杂的事情。
比如说现在给一张图，我们要去优化、美化这张图。最开始到了这样一个界面之后，我们让这个agent首先去观察一下这个用户界面，也就是observe。然后再去思考，为了美化这张图，应该怎么做？这个act就是行为，也就是刚才讲的那个action，就是要输出这个action。最后，再总结一下我们现在完成的一个阶段。
在这个过程中，它是要参考这个文档的。这个文档会提供这个界面中每个元素的功能，就像一个说明文档一样。它会把所有的元素的功能描述都提供给agent，来帮助agent做决策。然后，它会不断重复这个过程，一直到把这个任务完成。
所以我们觉得最骄傲的一个点就是这个文档的设计。这个文档的设计能够保证这个agent每次做决策都有依据，而且都是比较确定的信息。这里展示一个agent执行过程的一个状态，比如说observation观察。它会先描述一下UI里面有什么样的东西，他们分别是什么标号。
然后，这个图是underexposed，就是欠曝光的。比如说这个图需要被优化，它认识到这个问题之后，就要思考该怎么做。然后它说，如果要提高这个图像的质量，我们应该解决这个欠曝光的问题，需要提高曝光。曝光的这个pack是20号，然后我们要向右滑，20号能提高这个曝光。最后它决定采取这样一个action，就是滑动20号向右以中等的距离。
在这个时候，图像的亮度明显被提高了。在我们定量的实验方面，我们也进行了大量的实验。我们选择了十个APP，并设计了大约50个任务来进行实验。其中，定量的部分涉及45个任务和九个APP，有40个人参与。例如，如果我们直接让GPT4去执行任务，而它的动作空间（action space）是原版的在线接口（come online interface）的动作空间，那么它的成功率只有2.2%，几乎就是全军覆没的程度。但是，如果我们把它的动作空间变成我们精心设计的一个动作空间，那么它的成功率可以提高到48.9%。也就是说，凭借GPT4强大的先验能力，它可以在接近一半的任务上都做得很好。然而，这个时候还没有引入文档（document）的设计。
在我们的设计中，我们探讨了文档的影响。首先，我们让它进行自主探索，也就是在这个APP里随便摸索、点按，然后观察效果。这样产生的一个文档可以把正确率提高到73.3%，提高了20多个百分点，这是一个很明显的提高。然后，我们尝试了另外一种文档，就是通过观看人类演示来总结的文档，它又可以进一步提高十个百分点。最后一种，这个菜单（menu）可以作为一个上限，也就是说文档设计的一个上限。假如我们人类去手动撰写这个文档，那么正确率可以达到95.6%，也就是说，几乎所有任务它都可以完成得很好。
这个就是成功率（successful rates），也就是说这个文档设计是非常有用的，而且这三种设计的情况下都可以带来明显的提高。其中，纯自主探索要比基线（baseline）提高很多，然后观看人类演示就可以避免很多不必要的操作，可以进一步提高效率，并把这个文档做得信息密度更高一些。如果是人类去手动转写的话，就会达到一个非常好的效果。也就是说，文档质量和任务完成的成功率是正相关的。这也意味着，假如真的有一天这个东西要投入部署使用的时候，我们可以通过人为地去提高这个文档来把这件事做得更好。
然后，我们探讨一些应用的可能点。这也是很多人找我聊过之后，我总结的一些点。首先第一个是软件开发测试。
有一个比较匹配的方向，很多时候在开发好一个软件后，我们会提供一个很详细的文档，然后让别人去测试一下，看是否存在bug。让agent去做这件事就非常适合。如果发现参考文档使用起来不顺畅，那可能软件的某个环节就会有问题。这可以作为初步筛选的一种可能。第二个方向是车载操作系统。在操作界面（UI）驾驶时可能是特别需要的，因为这时很难一边开车一边用手去操作UI。如果可以用语言作为操作UI的途径，那将是非常匹配的。第三个方向是软件的自动化操作。这里面其实情况就很多了，比如，如果是一个简单的手机APP，那它就可以像一个助手一样帮你去做一些繁琐的简单的事情。如果是专业的APP，比如是图像或3D的设计软件，或者是一些不同学科的专业软件，那这个时候事情会变得很复杂，你需要去专门训练一个语言模型，让它拥有相关的知识，才能把这个事情做好。这里面还涉及到快速学习与特殊适配的区别。假如说一个简单的APP，我们就可以通过快速学习的方式让它掌握。如果是一个非常专业的软件，那就需要从语言模型、视觉感知模型等方面做能力的增强。最后就是新一代人机交互的方式。很多人也有类似的感受，包括我自己。回顾软件的发展，最开始是命令行界面，面对的都是专业人士。后来有了图形用户界面，很多非专业人士也知道怎么用计算机来完成各种任务。那未来就是语言。如果agent可以把这个事情做好，那只要动动嘴就可以把这个事情做好了，连UI都不需要了。然后，因为我们的AppAgent是基于GPT-4v这个版本来做的开源，如果我们想做一个本地的模型，比如说基于某种特定需求去做这件事，那需要有哪些能力呢？这里总结一下，比如说第一个就是长上下文的一个能力，因为我们需要重复去做一个agent的思考和执行过程，你需要连续输入图片和相对来说较长的上下文。
第二个能力是OCR（光学字符识别）能力，因为操作APP离不开对用户界面（UI）中文字的理解，所以这也是一个非常基础的能力。接下来还有visual pointing（视觉指示）的能力，比如我们刚才在这个元素周围标了一二三四五六。智能体需要知道，这个按钮是通过“一”来表示的，那个按钮是通过“二”来表示的，这也是一个非常基础的能力。
然后还有调用函数和工具的能力。当我们观察思考完之后，为了达到某个目的去调用正确的函数，这一点也很重要。下一个能力是in-context（上下文理解）能力，这个可以理解为举例子的能力。当我们举了一个例子，智能体能否从这个例子中抓到精髓，比如说我希望他按照某个固定的格式返回给我，他要知道这个例子主要是用来表达格式的，而不是用来表达例子中的具体信息。
除此之外，APP UI的显眼性也很重要。刚才我们看到在没有文档设计的情况下，GPT4也能达到50%的成功率，这说明丰富的视觉效果是很重要的。这和人很像，因为人用过无数的APP才能很快地适应新APP。假如一个人从来都没用过智能手机，你让他去快速适应，他也不一定能做得好。
还有就是特殊图像的内容判断能力。刚才讲了，如果是专业软件，你需要在感知这一侧把事情做好。如果要是比如物理化学这样的医学软件，那不光是感知，还要拥有背后的知识，然后才能对当前的状态做出判断。
关于这个领域的开源工作，现在已经有很多了。比如说早期的像这个命基比利斯拉瓦等这些工作都是非常好的。这里我简单讲一下我们团队做的一些其他的相关工作，也是围绕这个多模态的内容。比如说现在这种开源模型都是把开源的视觉模型和开源的语言模型通过一些数据拼接在一起，然后做一些微调。首先，找这种图文数据其实是一个很难的事情。这种图文数据有公共的可用数据，但往往比较嘈杂（noisy）。那你如果在有噪声的数据下工作，你就得把数据量拉上去，到这个几百万、几千万，甚至到几十亿的级别都是很正常的。还有就是instruction（指令）的构造。
所谓“指令”，就是问答对。我们希望我能提出各种问题，而你能给出准确的回答。这就要求你的训练数据也必须丰富多样。目前的方法大多是基于公共数据集，如COCO，来构造各种问答。但这种方法实际上限制了图像的类型和问题的类型。那么，专业领域的图像如何处理？例如，图表这种图像就无法通过生活中的图像来构造问答对。这也是一个亟待解决的问题。
针对这些问题，我们也做了一些尝试。首先，我们尝试构造更高效的问答对数据，即所谓的“指令调优”数据。我们希望能够增强一些我们特别需要的能力，如对风格化图像的理解，并产生更符合生活场景的提问形式。例如，我们可能会一次询问多张图片的区别，或者混合图文进行提问。这些都是我们非常看重的点。
例如，我们最近的一项名为“Stable Llama”的工作，其思路非常简单。我们借助AI生成对抗网络（GC）的生成能力，同时去构造和生成图像和对话。因为图像是自己生成的内容，所以我们非常清楚其信息，可以基于这些信息去构造对话。其好处在于主题多样，我们可以构造生活图、科幻图，甚至是现实生活中不可能出现的、反常识的图。基于这些图像，我们可以构造各种各样的问题。而且，这种方式构造的数据集规模不受限制，可以随意扩大。
当时我们的思路很简单，就是使用ChatGPT去生成Stable Diffusion的提示（prompt），同时也让ChatGPT去生成对话。这样一来，我们就有了图像和对话的数据。比如这里有一些生成的例子，左边是一个教做菜的图文混合对话。如果这种数据要手动收集的话，并不容易。因为很难收集到这么多高质量的、主题多样的图文混合数据。但是，通过纯构造的方式就可以很容易地做到。
这项工作在多个基准测试上也展示了其有效性。只要简单地添加一些这样的数据，就可以明显提高基线模型的性能。
接下来，我们尝试解决特殊的图形问题，如图表。
嗯，图表确实非常有用。对于图表的理解，因为它处于OCR（光学字符识别）和纯图像之间的一个状态，既有图形的表示，又有文字的表示。我们的另一项工作，Chart Llama，提供了一个关于图表理解的功能。这强化了它对图形和文字的理解能力，而且我们可以执行很多任务，不仅仅是简单的问答。我们可以做内容总结、图表的代码生成、代码编辑，还有数据抽取，甚至可以根据数据去绘制图表。这个思路其实跟刚才讲的那个Stable Llama挺像的，也是借助GBT-4这种大型语言模型的代码能力，我们去生成一些图表的数据。同时生成这个数字的数据，还有这个图表代码的数据。有了这些信息之后，我们可以做各种各样的提问，围绕这些数据来提问，围绕数据趋势来提问，围绕代码来提问。对，这种灵活性就让我们可以无限地去构造数据。比如说，我们就构造了一批简单的数据。这个数据量并不多，相比之前的数据集，之前可能有几百K的数据，我们只要11K的数据，但是我们支持的图表类型可以很多。比如说我们这里做了十种，其实还可以再多，因为它并不受限制。而且这个instruction tuning的数据我们可以做到很多，各种各样的问题。任务类型也可以做到很多，比如说我们支持七种任务，过去的话呢，可能只支持一两种。那这个，训练的结论就是，我们也是以这种自动化构造数据的方式，很好地提高了贝斯拉模型在这个任务上的效果，包括我们新提出的一些图表编辑之类的任务的效果。
除此之外，我们团队在3D和语言模型这方面也做了很多尝试，包括在这个mesh shape上做了一些关于3D的生成和提问，还有在点云空间下对这个场景的一些提问检测、路径规划等等。这个就是今天我对多模态语言模型和多模态agent的一个介绍。后面我们进入提问环节，大家有什么问题我们可以去交流一下。好的，感谢张石老师的精彩分享，下面是问答环节，大家可以在互动区留言提问。
第一个问题是，这个只要一张截图就可以了吗？标注了半透明的数字序号。若要多张截图，有注意事项吗？关于截图，我们是在感知UI的上下文中使用它，实际上，你截取一张图，然后我们在图上动态地标注序号，让GPT4基于这样的图进行感知。然后做出相应的行动。如果每次都是基于当前状态的UI，比如你做了一个操作，它进入下一个界面，那就再截一张图，让它进行思考。
关于人类示范需要的XML文件，这个文件的格式是什么？有模板吗？或者说工具。这个XML和人类示范没有关系，它是安卓软件开发中能获得的一种信息。就是一个安卓软件，你可以通过它内嵌的一个XML文件知道这个界面里哪些东西是可以交互的。比如这是一个背景，点击它不会有反应，但那块是个按钮，点击它会有反应。它和示范探索没有关系。document，对，所以document和这个XML没有关系，document是我们总结的一个知识库，就是把每个按键、按钮的功能记录下来，这其实灵活性很高，比如结合当前热门的检索增强，可以把这一块做得更好。agent可以自动生成sop，不需要人类通过prompt来设计clip算法。
在软件测试中有什么建议吗？对，我觉得建议可以有很多方面。假如现在是在整个语言模型或者agent的早期阶段，那么agent可以作为一种测试的初审。就是可以让它大量地去测试，然后把它发现的问题作为一个初步的结果。但我觉得现在还不会到一个能直接取代测试人员的程度，但可以做一个初步的测试。下一个问题是自己下载相关的论文，可以让他学习总结重点内容和分析方法。这个没有问题，这个其实和agent没有关系，这个完全就是大语言模型自己就能做的。
通过一些简单的提示技巧，你可以做得很好。例如，你使用GPT-4，上传一个文件，比如PDF，然后让它进行总结、分析、方法归纳等等，它都可以做得很好。这并不涉及到代理的一些核心问题，比如执行等操作。
文档大小有限制吗？我看到文档里最多支持十个页面。首先，文档并不是记录页面的信息，而是记录APP中交互元素的信息。这个没有限制，比如你记录了一万个，或者说你有一个特别复杂的软件，它有一万个不同的交互元素在不同页面里，你都可以记录到一个文档里。到时候它调用这个文档，比如你在部署这个APP的时候，部署到代理上，想去做一个APP的时候，它不是一次性把文档全部拉进来，而是只去调用和当前页面、当前UI出现的元素相关的信息，并不是所有的信息。
下一个问题是XML解析的过程中，有时候发现当前页面可点击的地方在XML文件中却被标记为disable，这样就不会被标记出来。这个问题怎么解决？这个问题其实挺好的。不光是这个XML解析不出来的问题，如果你进入到一个特殊的UI界面，比如你到了浏览器界面，浏览器的内容其实不属于安卓的XML来管理，它内部可以非常复杂，比如一个浏览器里面是一个动画、播放的视频或者是一个纯HTML文件，那你用安卓的方式去解析它都解析不了。这个时候我觉得可以通过很多的技巧来解决，比如你可以直接把文字作为一种解析的元素，比如这个里面有一个按钮的名字，你把这个按钮名字记录下来。当然这个也可能会有它的问题，比如出现重复了。或者就是基于视觉的方案，你比如说有same，你把这个界面分割出来，然后把每个元素以image embedding的形式存到document里面，以一个向量的形式，到时候你检索的时候通过向量的比对来做也是可以的，但这个肯定就没有像XML里面那么好了。XML可以直接告诉你哪些是可以交互，哪些是不可以交互，但如果你基于视觉的方案，比如分割，那可能就需要更多的处理和分析。你也不知道哪个分割块是可以交互的，只能一个一个去试，这完全是自主探索。如果是人类进行演示的话，那么可以认为人类演示过的区域是可以交互的，没演示过的区域则不能交互。这样的话，效率会高很多。
训练智能体（agent）的数据需要手工标注每一个动作的结果吗？这里的训练其实和我这个工作中的训练不是一回事，我这里面的训练不涉及到对语言模型的参数优化。它是探索，或者说叫few-shot learning，，那它其实就是通过观察UI的变化，总结UI的功能，然后归纳到一个文档里面，这里面不需要人去标注。但是，如果你想训练这个语言模型的话，那一般来说一个常见的做法就是，你让GPT-4或者说一个更强大的语言模型agent去做一遍这件事。如果它可以做得很好，你就把它的这个想法、这个做法，作为要学习、要训练的内容去优化语言模型，这样能使你的模型很快达到和这个GPT可比的结果，但是你还是没法超越它。如果想超越它的话，可能就需要去构造一些数据，无论是标注也好，或者是自动构造也好。
大概需要多少智能体（agent）数据才能有效果？这个可能和刚才那个人的情况类似，就是我们这里不涉及到拿数据去训练模型，所以没有“多少数据才能有效果”这个概念。但是，如果你说的是探索的话，那么这里可能你演示的次数越多，它对界面中元素的理解会更好。在learn阶段，只要一张截图就可以了吗，标注了半透明的数字序号是吗？还是说需要多张截图，并且标注了半透明的数字序号？这个和截图没有直接关系，截图是它感知UI的方式，不论是在所谓的learn阶段还是在部署（deployment）阶段，都是通过送入这个截图，然后它看到这个截图上面带了标号，只要它去做选择，我现在要点一号位置，我现在要画二号位置，我现在还是要长按三号位置。不论是在learn阶段还是在deployment阶段，都是这么做的，都是通过送入UI的截图来让它做感知，然后执行这个action的行为，和是learn还是deploy没有关系。
除了GPT-4，其他语言模型能比较好地支持智能体（agent）吗？最近，在我们的智能体（agent）的官方GitHub上更新了那个通用1000万的API。那个API目前仍然是免费的，大家可以尝试一下。直接替换成那个API是可以用的，但效果没有GPT-4V好。
文档是按照页面来区分的吗？还是按照元素？我们是按照元素为每个元素分配一个特殊的ID。这个ID的构造其实也有一些技巧。比如说，你可能会根据XML本身的一些内容来构造，但这个ID不是很全，有时候会缺失。那么这个时候，我们可以把一些元素的长宽高位置等信息拼接到这个ID里面。这样的话，就能保证不同的元素不会重复。
多轮产生的数据会使得上下文非常长，需要丢掉前面的数据吗？这里有两种解决思路。第一种就是无所谓长短，只要我的context length足够长就行。第二种就是我们把之前的信息总结好，保留下来。所谓的丢掉，相当于我现在又重启一段对话。那重启对话呢，我们需要把这个任务之前已经执行到的阶段，包括任务最开始的目标等，都记录下来，然后让agent参考这些继续进行操作。
这篇paper可以发SCI吗？AI agent作为客户研究方向可以吗？有什么具体一点的研究方向吗？如果你从事的是agent的研究，肯定是可以发表论文的，不论是在期刊还是会议上。对，而且agent目前是比较热门的一个方向，工业界和学术界都比较感兴趣。可能每个任务有不同的agent设计。你针对一个有价值的任务，做出一些有针对性的、有价值的设计，就是可以发表论文的。而且我觉得这个对新手特别友好，对不懂deep learning的人也特别友好。因为比如说你基于一个给定的语言模型，在它上面做agent的开发，那你可能只需要较强的扣定能力就能把这件事做好。
初步测试相当于随机测试吗？还是说编写用力进行测试？另外，输出结果是什么样？这个我没听懂，初步测试是什么意思？可能是指探索吗？探索是有一个自主探索的阶段的。这个问题我先搁置吧。
您说APP里对应XML文件意思是我从应用市场里下载的某个APP是自带着XML文件是吗？什么样的方式能得到APP对应的XML文件啊？这个就是你可以参考我们的那个开源项目，里面有一个Android的debug套件。这个套件可以让每个安卓开发软件都能得到一个XML文件，而且是当前页面的XML文件。这个在对抗决策任务上有用吗？比如在游戏之类的应用上？理论上是可以泛化的，理论上是可以用于玩游戏之类的，但实际上问题很多。比如响应速度，游戏的响应速度非常高，复杂的游戏都是在几十到几百FPS上的。如果说是下棋这种任务，那倒是可以，但下棋的规则又是一个背后的复杂知识。简单的文档总结不足以涵盖这个任务的知识，比如你让他下围棋，你不可能在文档中把下围棋的方法都总结下来。
Agent一般需要观看多少演示视频呢？在执行命令的时候，是将所有文档输入给Agent吗？理论上讲，一个视频就够了。因为它不是通过演示视频来训练模型的，它是观看这一个视频中的点了什么位置、发生什么样的变化来总结按钮的规律的。所以，它不需要很多演示视频。至于是否所有文档都输入给Agent，并不是这样。执行命令的时候，它只把当前页面出现的相关元素的信息从文档中调用出来，输给Agent，并不是所有的信息。假如你Agent记录了一个APP中一万个元素，那你不可能把一万个元素的说明都调进来，而是只把当前页面出现的元素的信息调用出来。
阿里也有一个mobile agent。我建议大家可以搜一下APP agent，在google scholar上搜APP agent，引用APP agent的论文有很多。最近有很多关于用户界面理解的agent出现，有在电脑上的，有在手机上的。我是觉得有很多人关注这个方向是很好的，很有价值的。包括阿里的mobile agent，还有微软的那个OS copilot，以及其他的什么UFO之类的，我最近看到的都挺不错的。可能他们都在解决一些框架上能力没涵盖的一些思路、一些场景。
这只是初步测试的意思，你可能需要更深入地了解或尝试。
我说的初步测试是什么意思呢？它指的是软件开发测试。如果我们用这个框架去做软件开发测试，就是让现在的agent，尽管目前语言模型还没强大到可以完全接管人类的能力，去初步尝试。初步测试的意思就是，假如我们的测试目的是发现软件中的一些bug，那么可以先让这个agent去做，比如说做一万次测试，一万次尝试。然后，假如它在这一万次里面没有检测出任何bug，那并不代表这个软件没有bug，因为它只是一个初步筛选而已，之后还是需要人去进一步测试。那假如说我们先让它做一万次测试，它检测出了几十个bug，那当然很好了，人们可以参考它检测的结果，去做进一步的观察。
应用的风控会怎么解决？会封号吗？比如微信。理论上讲是不会的，就目前来看是不会的，因为我们的操作方式是点按屏幕，这和人的实际操作其实是一样的，所以它不会封号，至少现在不会。但是如果它的检测方式变了，比如说它根据响应时间，假如AI的响应时间做得非常快，UI一出现问题，它就能立即点击，那么你连续的UI配置变化，可能会导致后台监测系统把这个检测为是AI的操作。那未来可能当这个agent应用得多了之后，可能会有这样的风险。
请问老师，GPT多轮对话是如何缩减上文对话历史的长度的？这个是缩不了的。时间长了，你依然可以聊，但是它对上文的记忆就会衰减很多。现在缩减上下文长度的并不是研究方向，现在大家的研究方向是把这个上下文拉得很长。而且现在有很多很厉害的工作在增加上下文的长度。
