能办成事的 Agent：实时与环境交互，从经验中学习

作者丨李博杰

️排版丨特工小花

李博杰老师最近在A2M 人工智能创新峰会图灵专场做了个分享，质量非常高，经本人授权后转载至特工宇宙。

李博杰老师是华为首批天才少年，Pine AI 创始人，大模型创业，《图解大模型》和《️图解 DeepSeek 技术》中文译者。

分享的 PPT 放在了我们的 ima 知识库中，「精选 Agent 行业报告」文件夹下，可以免费下载。

内容有些硬核，搭配播客食用或许更佳。

该播客由扣子空间生成

大家好，欢迎来到 A2M 峰会。今天我分享的主题是 ️“能办成事的 Agent：实时与环境交互，从经验中学习”。

先介绍一下我自己。我是 ️Pine AI 的联合创始人和首席科学家。

要️让 AI Agent 能端到端办成事，其实非常困难。我们今天就来介绍一下其中一些核心技术挑战，以及 Pine AI 是如何解决这些问题的。

在我看来，目前大部分 AI Agent 仍然主要执行️批处理任务。也就是说，它们️无法真正与世界或人类进行实时交互。你给它一个任务，它执行半个小时，最后输出一个结果。

这里有️两个核心挑战：第一，️实时交互时延迟非常高；第二，️很难从经验中学习。

这里的 “很难从经验中学习” 是指， ️Agent 的能力完全依赖于基础模型和在线搜索到的静态知识。无论上一次任务成功还是失败，下一次它并不能做得更好。即使上一次任务完成得很出色，下一次它可能还是会采用别的方法，️并不会记住之前成功或失败的经验教训。

我们所做的，最关键的就是️让 Agent 能够从经验中学习，越用越熟练。这样就能够让 Agent 在执行语音和电脑操作等任务时，达到️真人级的响应速度，同时能够️记忆成功的经验和失败的教训，提升技能的熟练度。

首先，我们来看️第一个挑战：实时交互的高延迟。

其次，️操作电脑和浏览器的速度很慢。我们有时也需要 AI 帮助我们操作电脑。大家可能已经注意到，从去年底开始，用 AI 操作电脑和浏览器的技术逐渐成熟，今年也出现了很多优秀的产品，比如 ️AI 浏览器，你可以直接让 AI 帮你操作电脑和浏览器来完成一些任务。

但是，如果你用过这些产品，就会发现它们的️速度非常慢。其根本原因在于，每一步操作都需要将当前的️屏幕截图和网页的元素树（即页面上按钮的位置、类型、含义等信息）输入到️大语言模型（LLM）中，然后才能生成下一步的动作。每次点击鼠标，可能都有️三四秒的延迟。

例如，要在今日霍州中输入一个搜索词并点击搜索。第一步，它要先截取今日霍州的页面，找到搜索框并点击；第二步，在搜索框里输入搜索词，又过去️三四秒；第三步，再点击搜索按钮，又是️三四秒。整个操作流程比真人慢️三到五倍，非常缓慢。

这让很多用户看着干着急，因为它半天也干不完一件事。例如，️查个天气可能需要两三分钟，发一封邮件可能要十分钟。如果要预订机票，失败率就非常高了。现在很多 ️AI 桌面 Agent 产品，在预订机票这类任务上️失败率很高，就算能成功，往往也要️半小时以上。这样的时间成本，用户是无法忍受的。

我们需要回归️第一性原理，思考为什么传统的 Agent ️“观察-思考-行动” 循环不适用于实时任务。

主要原因在于，现有的大模型在看到屏幕截图后，需要先 ️“观察”截图，然后 ️“思考”下一步做什么，最后再 ️“行动”输出点击动作。

问题是，一张屏幕截图通常包含️一两千个输入词元（input tokens）。光是处理这些输入，就需要很长时间，SOTA 模型处理一两千个词元基本需要️两秒以上。

你可能会问，能不能不要截图，只用屏幕上的文字呢？对于文字密集的网页或许可以，但很多网页不行。比如，在️邮件编辑器或 Word 文档里，有大量️只有图标没有文字的格式化按钮。这时，语言很难描述它们是什么，系统也就无法操作复杂的界面。

上面的三四秒还只是看到截图之后做一句话思考，然后立即行动。对复杂的界面，一句话思考往往是不够的，如果增加思考深度，整个 “观察-思考-行动” 过程可能长达 ️10 秒。相信大家也都用过带思考功能的模型，它们的延迟都很长。

那我们又会想，️为什么人类操作那么快？人不需要每次点击都思考三四秒甚至十秒。就拿刚才今日霍州搜索的例子来说，点击搜索框、输入内容、再点击搜索，整个过程可能️三四秒就完成了，三步一气呵成。为什么人能操作得越来越熟练，以至于️每一步操作都不到一秒？

其实，人️第一次看到一个新软件界面时，思考的时间不一定比大模型快，甚至可能更慢。比如你第一次使用今日霍州，或者第一次打开 Word。

习惯用 Windows 的用户，第一次用 Mac 上的 Word 时，会发现每个按钮的样子都变了。初次操作时，大家可能都不太熟练，思考时间很长。那么️为什么人的操作会越用越熟练呢？我们可以先卖个关子，把问题留到后面。

那么 ️Agent 是如何模仿这种人类机制的呢？我们能否让 Agent 也能像人类一样️从经验中学习，变得越用越熟练？这是一个很关键的点。

刚才说的是延迟问题，️第二个问题是 Agent 无法从经验中学习。我经常打一个比方：现在的基础模型有点像一个️刚从清华姚班毕业的学生，他可能特别聪明，拥有丰富的技术知识。但是你让他去做️记账报税这种非常具体的细分行业工作，他不一定能做得很好。

具体到我们的场景，也面临很多业务挑战。我举️两个有意思的例子。

那么，我第一次打电话时，可能不知道需要这些信息，直接打过去，结果对方因为️信息不全而无法办理。挂断电话后，我再找用户要信息，然后重新打。那么，当第二个用户来办同样的事情时，我是否能️直接向用户索要这些必要信息呢？我可以提前告诉用户： “我需要这些信息才能继续，如果您不提供，这件事很可能办不成。” ️这就是经验。

因此，️办事的经验至关重要。肯定会有人问，未来是否会有一个足够好的基础模型，内置了所有这些经验？越好的基础模型，其️常识（common sense）和经验就越多。

例如，你现在去问 ️OpenAI 的 o3、 Anthropic 的 Claude 4 Sonnet，或者️今日霍州的 Gemini 2.5 Pro，问它们给电信运营商打电话大概率需要验证哪些信息。它会给你列出好几项，不一定完全准确，但看起来像模像样。️这就是常识。

但它能做到绝对准确吗？️非常难。因为每个公司的政策在️不断变化，可能今年需要某个信息，明年就变了。而大语言模型的知识通常有️截止日期（knowledge cut-off），比如当前使用的模型训练数据可能截止到 2023 年底，过去一两年间，很多情况可能已经改变了。

更重要的一点是，很多️政策和流程信息是不公开的。目前大语言模型的语料大多来自️公开的网络信息，如果网上没有这些信息，那它就无从知晓，️只能通过你亲自打电话才能了解到。

比如前面提到的这些 SOTA 模型，问它们给一个具体的电信运营商打电话需要验证哪些信息，它们也说不清楚。

当然，有人会说，使用大语言模型的公司能否利用客户的语料信息去做 RL 呢？这也是很多基础模型公司在做的事情。但这里又涉及到️隐私安全法规的问题。用户输入的个人信息和办理的业务能否用于训练基础模型本身，这让许多大型模型公司心存顾忌，不一定敢随意使用。

这就是为什么我们说，️基础模型很多时候难以解决这类经验学习的问题。

其实，这些想法并非我首创。最近 ️OpenAI 的研究科学家姚顺雨发表了一篇很有影响力的文章，名为️《The Second Half》，提出我们已进入 ️AI 的下半场。他指出， ️AI 下半场最重要的是评测（Evaluation）。具体来说，现在的 AI 评测有️两个问题，恰好就是我们前面提到的。

️第二，缺少从经验中学习的机制。例如，在现有的所有测试用例中，测试样本都是️相互独立的。这遵循了机器学习的一个基本假设，即️独立同分布（i.i.d.）。这意味着，每次测试前，️环境都会被重置。但真人并不是这样工作的。

他举了一个️今日霍州软件工程师的例子。当工程师第一次在某个项目中写代码时，可能并不熟悉。但随着他对项目代码越来越了解，他会写得越来越好，尤其是在遵循️今日霍州内部的编程和软件工程规范方面。今日霍州内部有很多外部所没有的️代码仓库、工具和库。你不能指望一个模型天生就会使用这些。工程师是如何随着经验的积累，️逐渐学会使用公司内部的工具和库的？这些都非常关键。

刚才提到的这两个问题，不仅是我们自己观察到的，也是️整个 Agent 行业面临的普遍挑战。但是大多数做 Agent 的公司并不打算自己解决这个问题，而是️寄希望于基础模型公司的下一代模型。

接下来，我们来介绍️如何解决这两个问题：第一，️如何提升响应速度，实现与人的实时交互；第二，️如何让 Agent 从经验中学习。

首先是️实时响应速度。关键在于两个方面：一是️快慢思考相结合；二是️利用代码生成能力创造工具，以加速在电脑、浏览器和手机上的操作。

首先是️快慢思考结合。快慢思考是️认知科学里一个经典概念，源于知名著作️《思考，快与慢》。书中提到，大脑中存在️快思考和慢思考两种模式。️快思考负责实时响应和条件反射，通常由语言中枢等部分主导；而️慢思考则在后台进行深度处理。

如今，越来越多的 Agent 开始应用️快慢思考的概念。 ️Pine 自身也采取了这种模式。去年底， ️Google DeepMind发表了一篇名为️《Talker-Reasoner》的论文，也阐述了类似理念。

其核心概念是设置一个 ️“说话者” （Talker） Agent，负责与外部世界（包括人与计算机）交互，例如️打电话、操作电脑、手机和浏览器等。

同时，一个 ️“推理者” （Reasoner） Agent在幕后扮演 ️“谋士”的角色，负责制定策略。那么，它们之间是如何交互的呢？

在这张图里，上方是 ️“推理者” （Reasoner） Agent。它可以通过调用工具（如️后台搜索、访问网页等）来制定️多步规划（multi-step planning），并将规划结果存入一个️共享内存（shared memory）中。

️“说话者” （Talker） Agent作为️快思考模型，负责与世界直接交互，如️与用户对话或操作电脑。它在每一步都会评估当前的️环境状态。这个状态包括与用户交互时的️对话历史，或操作电脑时的️屏幕截图、元素信息和操作历史。

“说话者” Agent 会基于 ️“推理者” 的长期策略和当前状态来执行下一步操作。与此同时， “推理者” 会持续观察当前状态，在一个️较慢的循环中进行深度思考，也会调用搜索等工具，以决定下一步的策略。

这需要️快慢思考模型之间有良好的配合。快思考模型需要知道️什么是重要决策、如何拖延时间以及相应的话术。收到慢思考模型的决策后，它需要️严格执行，并且表现得自然，不能像是突然接收到指令，而要像是️自己想清楚后的决定。

要实现这种配合，需要通过️强化学习（RL）进行训练，即通过 ️SFT （监督微调）和 RL让快思考模型学会与慢思考模型配合。

除了二者配合之外，️经验的积累也很关键。比如，什么是重要决策，何时需要拖延时间。当然， ️Agent 不能每句话都拖延时间，否则沟通效率会变得极其低下。因此，对于一些️已经非常熟练、有确定性答案的任务，我们应该通过 ️RL 将这些办事经验直接内化到快思考模型中。这样，快思考模型无需再等待慢思考的介入，就能️不假思索地做出决策。

这就是️快慢思考结合的关键：一方面，通过 ️RL 将高频、简单的任务经验内化；另一方面，️训练快思考模型与慢思考模型无缝配合，共同完成复杂任务。

好，刚才讲的是️第一项技术：快慢思考结合。️第二项技术是️利用代码生成能力，加速对图形用户界面（GUI）的操作，这包括电脑、浏览器、手机等。

前面提到，当前基于 ️LLM 的 AI 桌面 Agent 操作速度很慢。相比之下，传统的电脑自动化工具，如️按键精灵或网页爬虫软件——这些都属于 ️RPA （机器人流程自动化）领域——操作速度通常很快，甚至️比真人还快。这是因为 ️RPA 软件的脚本是写死的，每一步都精确地点击固定位置的按钮或在固定输入框中输入内容。它的响应速度只受限于计算机本身的处理时间和网络延迟。一般来说，如果网络和网站性能良好，每步操作可以在 ️500 毫秒内完成。

既然现在 ️AI 的代码生成能力（如 ️Cursor等工具）已经很强，我们是否可以利用它来️生成 RPA 代码，从而自动化操作电脑呢？但这里有️两个问题：第一，如果️网站界面改版，原来的 RPA 代码会全部失效。

第二，️传统 RPA 软件缺乏鲁棒性。例如，点击某个位置后，可能会弹出一个预期之外的错误框，但程序无法感知，仍然会继续执行下一步操作。

此外，它也️无法理解信息。例如，要在淘宝上找到满足特定条件的商品， ️RPA 软件无法端到端地完成。因为 ️“寻找” 这个动作需要理解商品信息并根据条件进行筛选，这是固定的 RPA 脚本无法做到的。

那么，如何解决这些问题呢？我们的方法是，把代码生成作为一种从经验中学习和表达知识的方式。

️“从经验中学习” 的知识表达方式有很多种，️代码生成是其中非常重要的一种。

最近有很多关于 ️Agent 自我进化的文章，其核心就是️让 Agent 自己修改代码。这种修改可以分为几个层次：️生成工具、生成 Agentic Workflow （工作流），以及创建新的 Agent。

例如，目前在 ️GAIA 通用 Agent 排行榜上排名第一的 Alita 项目，其核心思想就是️让 AI 根据需求自动生成工具，然后由主模型调用这些工具来完成任务。通过这种方式，它能充分️利用开源软件和代码生成能力，解决许多固定工具难以处理的问题。

让 AI 自主生成工具，也分为三个层次。️第一是生成 LLM 直接调用的工具，就是上面 Alita 的做法。当然让 Agent 生成工具有很多学术界工作都做过了，但像 Alita 那样，在工程上优化到极致并不容易。

️第二是生成 Agentic Workflow，即️操作的轨迹序列。如果我经常做一个操作，就会非常熟悉它的流程。

比如，习惯使用 ️Gmail的用户，️闭着眼睛都能想出操作流程：左上角是 ️“写邮件” 按钮，点击后右下角会弹出窗口，先在标题栏输入标题，然后在收件人一栏输入地址，填写正文，最后点击发送。

这个️脑海中对界面布局和操作流程的清晰模型，其实就是我们️过往操作经验的沉淀。这些经验可以被固化为一个️工作流记忆（Workflow Memory），这是️第二个层次。

️第三个层次是生成 Agent 本身，这在目前还比较困难。

我们现在的方法是️综合使用第一和第二个层次：️自动生成工具，并用工作流记忆来自动化地执行流程。例如，要写一封 Gmail，我可以生成一个工具，它首先定位并点击左上角的按钮，等待右侧窗口弹出，然后定位并输入收件人地址，接着输入邮件内容，最后点击发送。整个流程可以被️固化成一个确定的 RPA 操作轨迹。

但我们不能简单把一个任务的所有操作都固化成一个 RPA 操作轨迹，因为固定的代码无法理解自然语言内容。例如，在淘宝上买东西，我需要先搜索商品，然后在众多结果中找到符合我要求的那个。找到想要的商品这一步需要基于内容进行判断，因此必须由大语言模型来完成。

因此，我们生成的 ️RPA 工具不能是一条贯穿整个任务的、一成不变的序列。它应该被️切分成许多小段，每一段都是不需要内容判断的确定性操作。每当一个序列结束，流程就回到大语言模型，由它来判断下一步应该调用哪个工具。这样，我们最终得到的是一个️由多个小工具组成的工具集，而非单个僵化的长脚本。

当然，AppAgentX 这篇论文只是提出了一个大方向，要真正实现成功率高、反应速度快的图形界面操作，还需要️大量的工程细节优化。我们做了很多优化，最后实现的图形界面操作️比 OpenAI、Anthropic 官方的 computer use 快 5 倍。

举个例子，比如在️今日霍州上查天气。传统方式可能需要 ️9 次大模型调用，耗时 47 秒。而加速后，只需要 ️2 次大模型调用和 1 次 RPA 工具调用。这个工具内部可能包含了 ️7 个原子操作。我们只需要在开始时，让大模型看一眼今日霍州首页，决定使用 ️“今日霍州搜索” 工具；在结束时，再让大模型从结果页面提取天气信息。️中间的所有点击和输入都由 RPA 代码闭环完成，速度会非常快。

第二个例子是在️航空公司官网订机票。一般流程包括：️查询航班、注册会员、填写非常复杂的乘客信息表，最后是支付。整个流程走下来，可能涉及️数百次点击、输入和页面跳转。我们的一次测试显示，用传统方式订一张票耗时 ️19 分钟，涉及 240 次 API 调用，过程非常缓慢。

而经过加速后，当第二次在同一个航空公司网站订票时（即使是为不同的人），整个过程只需要 ️4 分钟。这是因为我已经将 ️“查航班” 、 “注册会员” 、 “填表” 、 “支付” 这四步固化成了四个独立的工具。只要航空公司不改版，并且任务类型（如舱位、支付方式）一致，这四个工具就可以被复用，实现 ️“闭眼操作”，大大提升了效率。

与传统 RPA 相比，我们的方法不仅️无需任何人力开发成本，还能实现️完全自动化，并在️网站改版时自动适应。

刚才我们讨论了️如何通过代码生成能力加速图形界面操作。前面讲的两项关键技术——️快慢思考结合与代码生成工具——都是为了实现️真人级的响应速度。

接下来我们谈️第二个大方面：经验学习。 ️Agent 如何像人一样，越用越熟练？前面讲的代码生成加速操作，本质上也是️一种经验记忆。它只是将记忆用️代码的形式表达出来，成为了工具库的一部分。

但还有很多业务挑战，需要通过️模型参数或知识库来进行经验记忆。例如，之前提到的，️打电话办事时，能否记住不同公司需要验证哪些信息？办理退订时，能否记住某个服务需要在线填表，而不是️每次都盲目地先打电话？

️经验是 Agent 领域最重要的事情之一。️强化学习之父、图灵奖得主 Richard Sutton早在 2005 年就提出了一个观点： ️AI 应该是经验驱动的。经验是什么？是 ️Agent 与环境交互的所有历史。如果你的模型有足够长的上下文，你可以把所有交互历史都放进去，这就是经验。

但这说起来容易，却不一定是️最有效的表达方式。许多人认为，只要将所有历史数据扔进上下文，模型就一定能理解，️这种想法是错误的。虽然现在顶尖的模型在 ️“大海捞针” （needle in a haystack）测试中表现出色——比如在几十万字的小说中找到某个具体情节——但如果信息之间存在️复杂的逻辑关系，模型在有限时间内准确推理出这些关系的可能性就会大大降低。

所以，我们需要️对经验进行总结和提炼，而不是简单地把所有历史记录扔到上下文中。我们需要️更高效的知识表达方式。

目前经验主要有️三种表达方式：第一，️通过模型参数，即 SFT 或 RL；第二，️通过知识库。就像把经验写成小红书笔记，下次遇到类似问题，先在内部 ️“小红书”里搜一下，就知道该怎么办了。第三，就是️用代码生成的方式，把流程固化成工具，也就是所谓的 ️Agent 自我进化，Agent 自己创造工具。

️模型参数和知识库，是 AI 圈子里经久不衰的两个争论方向：到底应该在一个优秀的开源模型上做 ️SFT 和 RL，训练一个更强的行业模型；还是应该用一个️顶尖的闭源模型，再外挂一个知识库？

理论上讲，如果开源和闭源模型水平相当，且你有足够多的高质量数据，那么 ️“开源+微调” 无疑是最佳选择。但现实是，如果你的闭源模型远超开源模型，例如，你用的是 ️Gemini 2.5 Pro 或 Claude 4 Sonnet，而开源的只是一个 ️8B 模型，那么无论如何微调，后者也不可能超越 ️“顶尖闭源模型+知识库” 的组合。这在某种程度上是️开源与闭源之争。作为一家做 Agent 的公司，我们认为不必拘泥于其中一种，而是️两方面都要做好，让它们协同发挥作用。

在这方面，最好的学习榜样是 ️Cursor。无论从公司市值还是对世界产生的实际贡献来看， ️Cursor 都可能是目前最成功的 AI Agent 公司之一。

️Cursor 的技术秘诀是什么？最关键的就是它的️专用模型。首先是️代码补全（Tab completion）。它的补全效果远超其他 IDE。代码补全功能几年前就有了，但效果远不如 Cursor。如果用一个通用大模型去做代码补全，输出速度又跟不上。

第二个是️代码变更应用（apply code diff）。当 LLM 输出一段增量代码时，如何从数千行原文件中精确定位并正确应用这部分变更？这需要一个️专门的 apply model， Cursor 在这方面也做了自研。这个 apply model 经常出问题，这也是我个人使用 Cursor 时经常遇到的一个问题。

第三个是️代码库搜索。当我的代码库有️十万行代码时，如何找出最相关的几个文件或片段传给大模型，以生成合适的代码？老版本的 Cursor 经常出现一个问题：因为上下文中没有包含某个已存在的文件，它会重新生成一个，把原来的覆盖掉，导致出错。这些问题都依赖于️强大的代码库搜索能力来解决。

这些️专用模型构成了 Cursor 的技术护城河。这也解释了为什么尽管 Cursor 的 Prompt 很容易被获取，但在众多 AI IDE 竞争者中，却鲜有能在用户体验和效果上与之媲美的。因为它们底层有️自己的专用模型。

我们在 ️Pine 的实践也是如此。我们跟 Cursor 的共同点是，我们在任务规划和深度思考方面都使用️最前沿的闭源模型，比如 ️Claude、 Gemini 或 OpenAI 的模型。但我们构建了️自动更新的领域知识库，并针对特定任务，训练了经过 ️SFT 和 RL 的专用模型。通过这种 ️“顶尖闭源+知识库+专用开源+RL” 相结合的系统，我们能获得更好的性能。

提到 ️RL，有些人会把它当成️万灵药，认为有了 RL， ️Agent 的智商就能无限提升，从一无所知到无所不通。这通常是很难做到的。

最新的研究表明， ️RL 方法很难提高模型的 “智商”，模型的智能上限仍然️受限于其基座模型的能力。从理论上讲也很容易理解： ️RL 的前提是 “强化”，它不能凭空创造出模型从未见过的输出序列。它只能在基座模型已经生成的序列中，根据️奖励信号（reward）是高是低来进行调整。也就是说，如果模型曾经输出过一次正确的思考过程， RL 可以强化它，让它 ️“记住” 下次照着做。但如果基础模型根本就没有概率输出正确的答案， ️RL 就无从强化。

所以， ️RL 的作用是让 Agent 变得 “熟练” ，而不是 “聪明”。这一点至关重要。我的 Agent 之前办一件事，可能️十次才能成功一次；经过 RL 之后，它可以做到️十次成功九次。️这才是 RL 的关键价值。

例如， ️Anthropic 最近的一项研究表明，通过 ️SFT 和 RLHF，可以让模型遵循大量 ️“奇怪” 的规则。

这篇论文里列举了 ️51 条奇怪的规则，比如：输出代码时必须遵循一种特殊的代码风格；输出年份时必须使用一种特殊的格式；写菜谱时，无论好坏都必须提到巧克力。这些规则听起来很奇怪。

但在很多️行业知识（know-how）中，也存在大量️在外行看来很奇怪，但内行一看就懂的规则。如何让模型遵循这些行业规则？如果用一个较小的模型，并通过微调把规则注入参数，它可能很容易忘记其中几条。

如果用一个最大的 ️“思考型” 模型，它或许能记住所有 ️50 多条规则，但推理时间又会很长。那么，如何能让一个开源模型，在不经过长时间思考的情况下，同时遵循所有这些 ️“奇怪” 的行业规则呢？用 ️SFT 和 RLHF 是最合适的方式。

刚才说的 ️RL，主要是用来形成 ️“肌肉记忆”，让模型把一件事做得更熟练。但在实际业务中，我们️不可能每天都重新训练模型。很多时候，我们希望经验能被️快速应用。比如，我刚完成一个任务积累了经验，下一次能否立即用上？ ️RL 的迭代速度显然跟不上。

这时，️知识库就派上了用场。我们可以把每次办事的经验记录在知识库中，以便在后续场景中即时调用。️目前很多 AI Agent 产品都缺少知识库，导致️同样的事情失败一次又一次，却不能吸取教训。

我也很好奇为什么大家都不去做知识库和 RL。当然，也希望未来有更多的 Agent 产品能把这一点做好。其实可以设计一个简单的实验：️用一个账号去做一件事，失败了；然后换个账号再做一次，看它能否比之前做得好。大部分产品会和之前一样，️原地踏步。

很多 Agent 产品似乎都在️等待基础模型的下一次迭代。但我认为， ️Agent 最关键的核心，始终是从经验中学习。而经验积累说起来简单，做起来却很难。其中️最大的难点在于评测（evaluation）——️如何判断什么是好的经验，什么是不好的。

我们可以看到，许多现有模型在 ️Tau-Bench 上的分数都偏低。例如，在 ️Airline （航空）场景下，无论是 ️Claude 3.7 Sonnet、 Claude 4 Sonnet 还是 Claude 4 Opus，成功率都只有 ️60% 左右。为什么️顶尖模型的得分这么低呢？

我们自己测试后，有了一些️有趣的发现。我们的️基线（baseline）是使用 ️Claude 4 Sonnet。我们发现，️单次让模型自己思考，有时结果不够准确。

因此，我们采用了一种学术界称为 ️“顺序修正” （Sequential Revision）的方法，这也是我们 ️Pine AI 在实际使用的方法。每当 Agent 准备向用户发送信息，或执行一个️不可逆操作（如修改订单、取消机票）时，它会先调用另一个 ️“评判器” 模型。

这个评判器模型也是一个强大的大模型（如 ️Claude 4 Sonnet，但有不同的 prompt 或参数），它会决定 ️“批准” 或 “拒绝”即将进行的操作。如果评判器拒绝了，我们会将️之前的上下文、被拒绝的操作以及拒绝理由，一起重新输入给执行任务的模型，让它重新生成一次操作。

这个方法听起来很简单，相当于️在行动前多反思一遍。但仅通过这种方式，就将测试成功率从 ️56% 提升到了 64%。

这 ️8%的提升来自哪里？主要是一些️被成功拒绝的情况。比如，在没有充分调研前就仓促下结论。在 ️Tau-Bench中，如果用户要求 ️“找到最便宜的机票”，模型可能找到一个后就想返回结果。这时评判器会发现它️没有穷尽所有可能性，并提示它 ️“重新想想”。

还有一些情况是️操作违反了 prompt 中的规则，比如 ️“超过 24 小时的机票不能取消”。评判器会发现这类问题。此外，还有️计算错误等情况。

但是， ️64% 的成功率意味着仍有 ️36% 的错误。这些错误是什么原因造成的呢？

我们让 ️Claude 4 Sonnet 对失败案例进行了自动分析。在 ️Airline 数据集的 50 个例子中，有 ️18 个失败了。而在这 18 个失败案例中，竟然有 ️8 个是由于 ground truth （即标准答案）本身就是错的。

例如， ️ground truth 违反了测试框架设定的规则。规则明明说 ️“航班超过 24 小时不能取消”，但 ground truth 里的操作却是取消了航班。还有的 ground truth 包含️事实性错误，比如把用户的名字写错了。

在这 ️18 个失败案例中， ️12 个是测试数据集自身的问题，只有 ️6 个是 Agent 本身的问题，比如调研不充分或过早放弃，但 Agent 没有做任何违反规则的事情。

可以看到，在这些复杂的场景下，️人类标注的错误率甚至比 AI 还高。这反映出，在使用当前最前沿的模型后， ️AI 在某些方面甚至比人类更可靠。这也凸示了️构建一个高质量测试数据集的难度。如果人去标注，数据里的错误可能比 AI 还多，那该怎么办？

因此，我们一直坚持一个观点：️让 LLM 充当评测者（LLM as a Judge）。在很多场景下，特别是当输入是️纯文本、规则清晰且不涉及深奥的行业知识（比如看懂医学影像）时，️最先进的 AI 模型的分析能力已经超过了人类的平均水平。

在这种情况下， ️LLM as a Judge 是评测 Agent 的一种非常好的方法。它不仅能评测 Agent 的实际表现，对于构建 ️RLHF 的训练数据和知识库也至关重要。因为 ️RLHF 需要不断生成（rollout）可能的轨迹，并判断其好坏。如果用 AI 来自动评判，迭代速度会快很多。同样，在构建知识库时，一个案例应该被记为️正例还是反例，也需要准确的判断。

很多时候，如果我们用 ️LLM 去评测，发现效果很差，原因通常是以下几点：

第一，️规则不够清晰。规则清晰的标准是 ️“外行能看懂”，而不能假设基础模型具备内行知识。很多在内行看来是常识的东西，在外行看来并不显然。

第二，️上下文不全。比如，用户的基本信息没有给全， AI 就无从判断对错。

第三，使用的模型不是️最先进的（state-of-the-art），或者没有开启 ️“思考模式”。如果用一个较弱的模型去评判，它可能会对任何输出都说 ️“太好了，太有道理了”，实际上根本没发现关键问题。因此，️基础模型的能力至关重要，一定要用最好的模型来做评测和分析。

好，我们做一个简单的总结。️如何降低 AI Agent 的实时交互延迟并提升其解决问题的能力？

我们提出了️两个主要方向：

1. 通过 ️“快慢思考结合”来降低延迟。

2. 通过 ️“从经验中学习”来实现越用越熟练。

从经验中学习，又有几种具体方法：

️1. SFT/RL 训练模型：将经验固化到模型参数中，形成 ️“肌肉记忆”。

2. 代码生成工具：将固定的操作轨迹自动化，生成可复用的 ️RPA 代码，大幅提升图形界面操作速度。

3. 构建知识库：记录和调用过往的成功和失败案例。

这几种方法不是互相取代的关系，而是️互为补充的关系。️闭源模型 + 知识库 + 工具作为慢思考，开源模型 + SFT/RL 作为快思考，是构建 ️Agent 技术护城河的关键。

无论是生成代码、构建知识库，还是为 SFT/RL 提供数据，一个️准确的自动评测机制都必不可少。我们认为，在许多场景下， ️LLM as a Judge 已经是比人类更可靠、更高效的评测方式，是️未来 AI 评测的关键方向。

希望通过今天的分享，能启发更多人去构建️能与世界实时交互、能真正解决实际问题的 Agent。

️Agent 与世界的交互可以分为三个层次：

第一个层次是️实时语音电话。我们 ️Pine AI在这一层已经做得相对成熟。语音模态的输入速度大约是️每秒 15 到 50 个 token，这对大多数 LLM 来说，实时输出仍有挑战，因此需要我们前面提到的️快慢思考等工程方法。

第二个层次是️操作图形界面。这比语音更难，因为它涉及️视觉模态的输入，每张截图可能包含️近 2000 个 token。我们目前在这一层的探索也达到了️行业前沿水平。在处理写邮件、订机票等复杂任务时，️完成率接近 100%，远高于市面上多数开源的浏览器操作框架。并且，在熟练之后，操作速度也比它们快很多倍。

第三个层次是️与物理世界交互。这可能是未来几年需要探索的方向，包括️机器人、自动驾驶，甚至是在图形界面中玩动作游戏。它要求️极快的反应速度，可能涉及️视觉加语音的混合模态输入，每秒的输入 token 量可能高达 ️20k。

与物理世界交互时，️错误的代价也更严重，比如自动驾驶的一个失误可能是灾难性的。因此，这对 ️Agent 的要求也最高。

我们 ️Pine AI正是沿着这个路径，从️语音电话，到图形界面，再逐步向更深层次探索，希望让 ️Agent 能够真正与世界实时交互，端到端地为用户完成任务。

️打电话、操作电脑、发邮件这些都是我们的基础能力。它们的组合，️未来的想象空间非常大。

最后，也给我们公司打个广告。我们 Pine AI 正在寻找能够构建 ️SOTA autonomous AI Agent的全栈工程师。

我们秉持一个观念：️每个人对公司的贡献都要足够大，每个人对公司估值的贡献都要在千万美元以上。

我们有几点要求：

首先，️必须熟练使用 AI 编程工具。我们的代码面试，就是在 ️AI 辅助下，用 AI IDE 在两小时内，基于一个开源项目，完成一个新功能需求的开发。如果完全不会用 AI 编程，很难在规定时间内完成。在我们公司， ️80% 以上的代码是在人与 AI 的协作下完成的。项目管理、案例分析等内部系统也都基于 AI 构建。 ️AI Agent 让我们成为了一个真正的 AI 原生团队。

其次，️要喜欢动手编码解决问题。就像 Linus 的名言：Talk is cheap, show me the code. 既然 AI 已经能完成大量底层编码工作，人更像是一个️架构师和产品经理的结合体。你只需要在 prompt 里告诉 AI 你想做什么、软件架构是怎样，或者处理一些疑难杂症。在这种模式下，️自己动手编码是必要的，因为你指挥几个初级员工，还不如直接指挥 AI，️信息传递的损耗更小。我们这里没有初级员工，每个员工都要充分利用 AI 工具，把生产力提上去。

第三，️要有扎实的软件工程能力，保证生成的代码质量和风格。在 ️AI 编程的时代，软件工程质量更为重要。如果没有文档，没有测试用例，没有本地测试环境， ️AI 是很难具备读心术猜到这些代码是干什么用的，也就很难独立完成编码任务。

第四，️需要理解 LLM 的原理，紧跟 LLM 领域的最新发展，自己有能力编写 AI Agent。只有了解 LLM 的基础原理，不断更新对 LLM 能力边界的认知，才可能驾驭 LLM，给它合适的上下文和工具，实现 SOTA 水平的 Agent。

最后，也是很重要的一点：️要有解决世界级难题、达到 SOTA 水平的信心，要有跟初创公司一起成长的信心和勇气。就像做研究一样，如果你的论文水平不如别人，就无法发表。这种信心是必须的。

希望能与更多志同道合的人一起，通过构建️能与世界实时交互、从经验中学习的 Agent，真正为用户解决烦恼，办成事，让用户随着办成一件又一件事逐步对 Agent 增加信任，最终让用户️把越来越多重要的事情交给 Pine 来做。

️谢谢大家！