Windsurf 发布：“ What is an Agent？” （1.5万字长文）

显示全部楼层

“在 2025 年的今天，智能体这一词汇已被广泛使用，却也因含义的多样性而逐渐失去精准的交流价值。因为每个人都自信地用它来指代不同的事物。然而，当我们深入探索智能体的核心概念与发展历程，便会发现它在 AI 领域的重要地位以及与以往 AI 工具的显著差异。”

Agent?" class="rich_pages wxw-img" data-ratio="0.5629251700680272" data-type="png" data-w="1764" data-imgfileid="100004129">

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">大家好，我是肆〇柒。我周日的时候，看到“觉察流”社群小伙伴的分享——Windsurf（AI Coding 领域知名 Agent 应用）发布了 Blog 文章。Windsurf 以其自身的实践视角阐述了“什么是智能体”，为了阐述这个问题，Windsurf 还用心的做了示意动画。下面我们一起看看这篇 Blog 说了什么。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">这次我偷个懒，做一下素材的排版，然后仅输出一下阅后感想，见谅。以下是这篇文章的全文翻译：

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;padding: 0.5em 1em;color: rgb(63, 63, 63);text-shadow: rgba(0, 0, 0, 0.1) 2px 2px 4px;">什么是智能体？

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">欢迎来到 2025 年版的 “一个被过度使用的术语，以至于它开始在对话中失去任何实际意义，因为每个人都自信地用它来指代不同的东西”。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">如果你是一个试图构建智能体解决方案的构建者，本文可能不适合你。本文是为那些在会议、董事会或对话中，听到有人谈论 AI 智能体时，要么（a）不太确定智能体是什么以及它与我们目前所见过的生成式 AI 能力有何不同，要么（b）不太确定使用该术语的人是否知道智能体是什么，或者（c）可能在阅读本文第一句之前自认为知道智能体是什么的人准备的。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">虽然我们会在这篇文章中引用 Windsurf 来使一些理论概念更易于理解，但这并不是一个销售宣传。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">让我们开始吧。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;padding: 0.5em 1em;color: rgb(63, 63, 63);text-shadow: rgba(0, 0, 0, 0.1) 2px 2px 4px;">最基本的核心概念

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">要回答本文的标题，一个智能体 AI 系统可以简单地被理解为一个接收用户输入，然后交替调用以下组件的系统：

• 一个大型语言模型（我们称之为 “推理模型”），用于根据输入、潜在的额外自动检索的上下文以及不断累积的对话来决定采取什么行动。推理模型将输出（a）推理下一步行动应是什么的文本，以及（b）指定行动的结构化信息（哪个行动、行动输入参数的值等）。输出的 “行动” 也可能是没有剩余要执行的行动。
• 工具，这些工具不一定要与大型语言模型有任何关系，可以执行推理模型指定的各种行动，以生成结果，这些结果将被纳入下次调用推理模型的信息中。推理模型本质上是在被提示在系统可访问的工具和行动集中进行选择。

这就创建了一个基本的智能体循环：

确实如此，这就是全部内容。考虑到智能体循环如何向用户展示，智能体系统有不同的变体，我们稍后会讨论这一点，但如果你理解了大型语言模型不是作为纯内容生成器（如 ChatGPT）使用，而更多是作为工具选择推理组件，那么你就已经掌握了大部分概念。

“推理” 这个术语也被过度使用了 —— 在智能体世界中，它有非常特定的含义。它指的是使用大型语言模型来选择下一步要采取的行动，即应该调用哪个工具以及使用什么参数。

OpenAI 的 o1 等模型也使用了 “推理” 这个术语，但那里的意思完全不同。对于这些大型语言模型，“推理” 指的是链式思考提示。这种想法是，模型会先输出中间步骤，然后再尝试提供对查询的最终回答，试图更像人类思考问题的方式，而不是依赖纯模式匹配的魔力。对于这些模型，没有工具被调用（如智能体世界中的情况），只是以一种看起来像是将多个思考调用串联在一起的方式生成大型语言模型的输出，因此得名 “链式思考”。

“智能体” 的另一个误用是指所谓的 “AI 工作流”。例如，有人可能会构建一个自动化或工作流，接收原始文档，使用大型语言模型进行对象识别，然后清理这些提取的元素，再使用另一个大型语言模型对元素进行总结，最后将总结添加到数据库中。这里有多个大型语言模型调用，但大型语言模型并不是作为工具调用推理引擎使用的。我们提前指定了应该调用哪些大型语言模型以及如何调用，而不是让大型语言模型实时决定应该调用哪些工具。这只是一个自动化，而不是智能体。

一个非常简单的例子来理解智能体与非智能体的区别：假设你让一个 AI 系统给你一个制作披萨的食谱。在非智能体世界中，你会将该提示传递给大型语言模型，让它生成结果：

在智能体世界中，智能体可能拥有的其中一个工具是从食谱书中检索食谱，其中有一个食谱是披萨的。在这个智能体世界中，系统将使用大型语言模型（推理模型）来确定，根据提示，我们应该使用 “食谱工具” 并输入 “披萨” 来检索正确的食谱。然后将调用该工具，输出该食谱的文本，然后推理模型将使用该工具调用的输出，确定没有更多的工作要做，并完成其 “循环”。

虽然现在可能明白了区别，但你可能会问 —— 这有什么有趣的呢？这似乎只是方法上的一个技术细节。

嗯，有几个原因使这很有趣：

• 想象一下，这个例子更高级一些。比如 “用那不勒斯风格的健康食材获取一个披萨食谱。” 非智能体系统有可能通过生成模型的特性得到一个合理的结果，但随着请求变得更加详细和多层次，单次调用大型语言模型就能准确完成请求的可能性越来越小。另一方面，智能体系统可能会首先推理使用一个调用大型语言模型的工具来描述那不勒斯是如何制作披萨的，然后推理使用一个工具对什么食材可以算作健康进行网络搜索，最后才推理使用检索食谱的工具，并且前两个步骤的信息将告知这个最终工具的潜在可配置输入。这种步骤的分解应该感觉很自然，因为这就是我们人类工作的方式，并且应该减少潜在结果的差异性，因为智能体使用的是我们更了解且能更好地控制的工具。虽然不能保证成功，但这种方法比非智能体方法更有可能让 AI 系统正确完成任务。
• 我们可以为智能体提供的工具可以帮助弥补大型语言模型不擅长的地方。记住，大型语言模型是基于自然语言模式的随机系统。它们对非文本概念没有内在理解。大型语言模型不擅长数学？我们可以添加一个计算器工具。大型语言模型不知道当前时间？我们可以添加一个系统时间工具。大型语言模型无法编译代码？我们可以添加一个构建工具。现在，推理模型（智能体世界中的大型语言模型）不需要内在地知道如何进行数学运算、告知时间或编译代码。相反，它只需要知道何时适合使用计算器、查找系统时间或尝试构建源代码，并且能够确定这些工具的正确输入是什么。知道如何调用这些工具是更可行的，并且可以基于文本上下文。
• 工具实际上可以改变世界的状态，而不仅仅是提供文本响应。例如，在披萨例子中，我们希望 AI 将披萨食谱发送给我的妹妹。也许智能体有访问我的联系人和发送短信的工具。智能体将进入一个循环 —— 首先推理检索食谱，然后推理检索我妹妹的联系信息，最后推理发送短信。前两个步骤可能可以通过一些非常智能的 RAG（检索增强生成）来实现，但最后一步？那种能够真正采取行动而不仅仅是生成文本的能力，使得智能体系统有可能变得非常强大。

恭喜你，现在你知道什么是智能体了！但还有一些背景信息和内容可以让你在围绕 “智能体” 的对话中变得危险……

我们是如何走到这一步的以及为什么是现在

在我们进入可以用来进行有意义对话的心智模型之前，我们会快速回顾一下我们是如何发展到这一步的，并在我们的领域——软件工程的背景下，对基于 AI 的工具类型进行一些澄清，这样就不会完全抽象。

如果你还记得几年前的世界，人类在生成式 AI 工具出现之前实际是在工作的。这项工作可以表示为一系列行动的时间线。在软件工程中，这可能包括从在 StackOverflow 上进行研究到运行终端命令，再到实际编写一些代码：

随着大型语言模型的出现，我们开始得到能够很好地完成特定任务的系统。ChatGPT 用于回答问题，GitHub Copilot 用于自动完成几行代码等。这些工具可以被信任，因为它们同时满足了两个条件：

• 它们解决了对用户来说重要的问题（例如，每个开发人员都讨厌编写样板代码，所以自动完成这些文本是有价值的）
• 大型语言模型技术足够好，能够以足够稳健的水平解决这些问题，使用户能够信任它用于特定应用（例如，开发人员不喜欢自动完成建议？没关系，他们可以继续输入并继续下去）

后者实际上非常关键。多年来，人们一直在构建基于大型语言模型的系统解决极其复杂任务的令人印象深刻的演示。然而，其中许多只是演示，无法被产品化和信任，这导致了炒作与现实之间的脱节，以及随之而来的幻灭低谷。以总结拉取请求为例。这对用户有明显的价值（没有人喜欢编写拉取请求描述），但想想用户长期信任它所需的准确性。第一次 AI 把描述弄错？用户将永远检查所有文件并自己编写描述，从而抹杀了工具的价值。这种用例所需的稳健性门槛非常高，可能今天的技术无法满足。尽管如此，虽然这种大型语言模型技术并不完美，但它也在迅速改进，因此能够以足够稳健的方式解决的复杂任务的前沿也在不断进步。总有一天，AI 将能够稳健地编写拉取请求描述。

我有点跑题了。最初有用和可能的交汇点仅限于我所称的 “副驾驶类” 系统。这些是能够通过单次调用大型语言模型来解决非常特定任务的 AI 系统，比如响应提示或生成自动完成建议。人类总是会在循环中审查结果，然后再 “接受” 它，因此人工智能失控的潜在问题不是一个问题。主要问题是幻觉问题，指的是模型由于在互联网上的文本上进行训练（每个人在互联网上都很自信）以及没有必要的知识将响应基于现实（说到底，这些模型只是超级复杂的模式匹配算法）而提供不准确的结果。

因此，这些副驾驶类系统通过越来越强大的检索增强生成（RAG）方法得到了改进，这是一种花哨的说法，即这些系统首先会检索与用户查询相关的信息，用这些信息增强用户的查询，然后将这些累积信息传递给大型语言模型以进行最终生成。这种对能够执行特定任务的 AI 系统的知识访问定义了基于大型语言模型的应用程序的最初几年 —— “副驾驶（Copilots）时代”：

这些副驾驶类的非智能体系统是推动长期可信赖的稳定价值的系统。然而，这并不意味着 “智能体系统” 的概念是新的。

第一个流行的智能体框架 AutoGPT 实际上是在 ChatGPT 推出后不久的 2023 年初发布的。这里的智能体方法是让智能体循环自主进行，因此用户只需提供提示，让智能体自行处理，然后审查结果。本质上，由于这些系统可以访问工具并进行多次大型语言模型调用，它们的运行时间更长，能够完成的范围比副驾驶类系统大得多：

然而，尽管 AutoGPT 仍然是有史以来最受欢迎的 GitHub 仓库之一，但用该框架创建的智能体并没有真正起飞。一年后，Cognition 推出了 Devin，宣传为一个可以替代人类软件开发人员的全功能 AI 开发人员。同样，一个完全自主的智能体系统，拥有一些非常强大的工具，但今天只能解决相对简单的问题。

发生了什么？如果智能体如此强大，为什么用户主要从基于 RAG 的非智能体副驾驶系统中获得价值，而不是这些智能体系统？

好吧，记住 “有用问题” 和 “技术足够稳健” 之间的交汇点？这是这些自主智能体系统面临的普遍挑战。虽然这些自主智能体是世界明显的发展方向，但今天的大型语言模型可能还不足以在没有任何人类参与或纠正的情况下完成这些任务的复杂性。

这一现实催生了一种新的智能体方法，它基于对人类应该做什么和智能体应该做什么之间将存在某种平衡的认识。为了与自主智能体方法区分开来，我们称这些为协作智能体，或简称为 AI 流程。

战术上：

• 必须有明确的方式让人类在流程执行过程中观察流程正在做什么，以便如果流程偏离方向，人类能够在早期纠正它。换句话说，重新引入副驾驶类系统的一些 “人类在循环中” 的协作方面。
• 这些流程必须在人类工作的同一环境中运行。大多数自主智能体的尝试，因为它们独立于用户工作，所以是从与用户手动工作时不同的表面调用的。例如，Devin 是从一个网页调用的，而实际上开发人员会在 IDE 中编写代码。虽然在一个智能体可以做任何事情的世界里这可能没问题，但通过不在用户手动工作的地方运行，这些自主智能体系统将无法意识到人类手动做的很多事情。因此，它们会错过从这些动作中得出的许多隐含上下文。例如，如果智能体在 IDE 中运行，那么它将意识到最近的手动编辑，这将隐含地告知智能体接下来应该做什么。

换句话说，在这种情况下，重要的是人类能够观察智能体做什么，同样重要的是智能体能够观察人类做什么。

回到 “有趣的问题” 和 “足够稳健的技术” 之间的交汇点，协作智能体方法所需的稳健性门槛显著低于自主智能体方法。这是因为人类总能在中间步骤纠正 AI，需要批准 AI 的某些动作（例如，执行终端命令），并对变化进行实时审查。

这就是为什么这是今天所有普遍可访问的智能体应用程序所采用的方法，这些应用程序普遍增加了价值，例如 Windsurf 的 Cascade、Cursor 的 Composer Agent 和 GitHub Copilot Workspaces。在流程中，人类和智能体始终在世界的状态上进行操作：

我们经过这么多努力来区分自主智能体和协作智能体，因为它们实际上是构建 “智能体系统” 的截然不同的方法。不同的循环中人类参与程度、不同的信任水平、不同的交互方式等。由于 “智能体” 这个词被过度使用，关于构建自主智能体并以 Windsurf 的 Cascade 等智能体系统作为智能体工作的证据的讨论很多，但现实是这两种方法截然不同。

如何解剖 “智能体系统”

好的，最后是你一直等待的内容 —— 一个快速的清单，综合了我们所涵盖的所有内容，以便（a）在关于 “智能体” 的对话中进行推理，以及（b）提出能够直击技术核心的问题。其中许多问题本身可以成为一篇文章，但我会尝试提供有用的初步问题。

问题 1：所讨论的系统真的是智能体吗？

很明显，太多人将系统称为 “智能体”，而它们实际上并不是。大型语言模型是被用作工具调用推理模型，并且实际调用了工具？还是只是某种链式思考推理或其他使用相同术语但含义不同的东西？

问题 2：它是自主的还是协作的？

智能体系统的方法是让智能体在后台工作而无需人类参与，还是让智能体有能力独立采取多个步骤，但嵌入在现有工作系统中，并且仍然有一个循环中的人类？

如果是前者，提出后续问题 —— 今天的模型是否真的足够好，能够在用户能够依赖整个智能体的一致性的情况下，对所涉及的数据和工具的规模和复杂性进行推理？或者让自主智能体的建议在理论上听起来很棒，但实际上不可行？

问题 3：智能体是否拥有强大所需的所有输入和组件？

这开始涉及区分不同智能体（特别是协作智能体，或流程）实现的实质内容，它们试图解决相同任务。

问题 3a：智能体可以访问哪些工具？

不仅是工具列表，而且这些工具是如何实现的？例如，Windsurf 的 Cascade 在执行网络搜索时采用了一种独特的方法，即将网站副本分块和解析。此外，添加自己独特的工具是否容易？Anthropic 的模型上下文协议（MCP）等方法旨在标准化一种低摩擦的方法，将新工具纳入现有的智能体系统。

问题 3b：智能体使用什么推理模型？

重要的是要记住评估大型语言模型在工具调用方面的能力，而不是它是否在各种任务和主题的标准基准上是最好的模型。仅仅因为一个模型在回答编码问题方面非常出色，并不一定意味着它在以智能体的方式解决编码相关任务时会选择正确的工具。没有在所有任务中都是最佳推理模型的大型语言模型，尽管 Anthropic 的 Claude 3.5 Sonnet 在历史上一直是工具调用方面最好的模型之一，但这些模型正在迅速改进。因此，提出是否应该确保智能体可以有使用不同模型的选择是很有用的。

问题 3c：智能体如何处理现有数据？

智能体可以访问哪些数据源？智能体对其数据源的访问是否尊重用户现有的访问控制规则（特别是在协作智能体的世界中）？有时答案并不像数据源本身那么简单 —— 对于代码库来说，智能体是否只能访问用户在 IDE 中当前检出的仓库，还是可以访问其他仓库中的信息以帮助为结果提供依据。后者可以增加价值，因为代码分布广泛，但围绕访问的问题变得更加重要。

总的来说，智能体方法改变了思考数据检索问题的范式。在副驾驶类系统中，你只有一次调用大型语言模型的机会，所以你只有一次检索的机会，这导致越来越复杂的 RAG 系统。在智能体中，如果第一次检索返回的结果不佳，推理模型可以简单地选择使用不同的参数进行另一次检索，直到确定已经收集了所有相关信息以采取行动。这与人类查找数据的方式非常相似。因此，如果围绕 RAG、解析和中间数据结构的讨论变得过于深入，问 —— 我们是否在智能体世界中过度复杂化了这个问题？稍后会更多地讨论这一点。

也就是说，如果数据中有结构，询问这些数据源中的信息是如何被处理的是公平的。例如，我们处理代码库，而代码是高度结构化的，因此我们可以做诸如抽象语法树（AST）解析等巧妙的技术，以智能地将代码分块，以便任何试图推理或在代码库上进行搜索的工具使用。智能的预处理和多步骤检索并非互斥的。

问题 3d：协作智能体或流程如何捕捉用户意图？

是否有任何隐含信号可以被人类用户手动操作所捕捉，而这些信号永远不会被明确编码？现在，智能体可能不知道在茶水间说了什么，但通过 “读懂用户的心思”，通常可以创造出更宝贵、更神奇的体验。在我们的世界中，这种意图可以在用户在 IDE 中打开的其他标签页、他们刚刚在文本编辑器中所做的编辑、他们刚刚执行的终端命令、他们粘贴到剪贴板的内容等等中找到。这又回到了降低使用智能体的激活能量 —— 如果每次用户都期望明确说明可以从未知信息中得出的每个细节，那么用户对 AI 结果质量的期望就会更高。

问题 4：是什么让这个智能体的用户体验真正出色？

到目前为止，我们讨论了所有会影响智能体结果质量的因素。你可能会发现关于智能体系统的对话集中在这些因素上，但任何认真创建实际被用户采用的智能体系统的人都应该关注所有轴的用户体验，即使底层智能体没有任何变化。许多这些用户体验的轴并不容易构建，因此需要仔细思考。

问题 4a：这个智能体系统的延迟是多少？

想象一下，两个智能体系统为特定任务做同样的事情，但一个需要一个小时，而另一个只需要一分钟。如果你知道这些系统肯定会成功完成任务，也许你不太在意时间差异，因为你可以在这段时间做其他事情。但如果智能体有可能不成功呢？你会非常希望选择后者，因为这样你可以更快地看到失败，也许改变一些提示，给智能体一些更多指导等。对于完全自主的智能体来说，延迟问题一直是主要挑战之一，因为它们通常比人类手动完成工作需要更长时间完成任务；除非自主智能体达到非常高的成功率，否则它根本不会被使用。

明确指出延迟有两个原因。首先，智能体构建者经常添加复杂、缓慢的工具来提高质量，而没有考虑对用户体验的影响，并思考这种权衡。其次，在堆栈的每个部分提高延迟都是一个非常困难的问题——模型推理优化？提示构造以最大化缓存？在工具内并行化工作？它通常需要一组完全不同的工程师技能来提高延迟。

问题 4b：用户如何观察和指导智能体？

这是协作智能体相对于自主智能体的大优势，但执行起来很少是琐事。例如，如果一个编码智能体可以在 IDE 中对多个文件进行多次编辑，开发人员如何有效地审查这些更改与查看单个自动完成建议或在聊天面板中查看回复是完全不同的。

同样，人们需要时间来积累在特定环境中执行特定任务的最佳实践的上下文。你能构建什么样的用户体验，可以让人类指导智能体这些最佳实践？例如，Windsurf 的 Cascade 可以接受用户定义的规则，或通过简单的方法标记上下文来引导已知上下文。是的，任何智能体的目标是能够自己完成任何事情，但如果人类可以轻松地让智能体的工作变得更简单，那么智能体将能够更快地完成更高质量的工作。

问题 4c：智能体如何在应用程序中集成？这都归结为调用智能体和利用其输出的抛光度。ChatGPT 的流行使聊天面板成为调用任何基于 AI 系统的默认方法。虽然这可能是一种方式，但它不一定是唯一的方式。例如，Windsurf 的 Cascade 可以通过其他方式调用，例如一个简单的按钮来解释代码块，上下文可以通过许多不需要复制粘贴文本的方式传递给 Cascade，例如预览允许控制台日志和 UI 组件传递给 Cascade。

问题 4d：智能体体验如何与非智能体体验平衡？这可能出乎意料，但并非一切都需要是智能体。例如，如果开发人员只是试图进行本地化重构，他们应该使用某种组合的命令和 Tab，这两种都是非智能体的 “副驾驶类” 体验，对于这些任务来说快速且高效。智能体是新前沿，但我们不能因为有了新锤子就把每个问题都当成钉子！通常很有用的是问 “我们是否需要为这个任务构建一个智能体？”

再次说明，我们只是触及了表面，但这个清单应该可以帮助你进行关于智能体的对话，提出能够直击核心的问题，并为想法注入一些现实感。

苦涩的教训

但是，还有一件事。我将其单独分开，因为如果这是你从这篇文章中最终使用的一个问题，那就是：我们是否违反了 “苦涩的教训”？

“苦涩的教训” 来自于 Richard Sutton 的同名文章（见本文附录），主要（改述的）收获是，更多的计算能力、更多的数据，以及技术的总体更大规模，最终总是会超越任何依赖人类定义的结构或规则的系统。我们在计算机视觉中看到了这一点，CNN 在边缘和形状检测方面超越了手工制作的规则。我们在更复杂的游戏中看到了深度搜索然后是深度神经网络超越了任何基于规则的计算机系统。即使是大型语言模型也是这一趋势的例子，超越了任何 “传统” NLP 方法。

对于智能体，我们再次有可能忘记苦涩的教训。我们可能认为我们对特定用例了解更多，所以我们需要花很多时间来制作正确的提示，或者确保我们明智地选择有价值的工具子集，或者尝试任何其他方法来注入 “我们的知识”。最终，这些模型将继续改进，计算能力将继续变得更便宜且更强大，所有这些努力都将徒劳无功。

不要掉入苦涩教训的陷阱。

附录苦涩的教训

这篇文章是理查德·萨顿（Rich Sutton）在 2019 年 3 月 13 日撰写的一篇关于人工智能研究教训的文章，全文翻译如下：

苦涩的教训（作者：Rich Sutton）

• 2019 年 3 月 13 日

从 70 年的人工智能研究中可以得出的最大教训是，利用计算的通用方法最终是最有效的，并且优势非常明显。其根本原因是摩尔定律，或者说单位计算成本持续呈指数级下降的规律。大多数人工智能研究都是在假设智能体可利用的计算能力是固定的前提下进行的（在这种情况下，利用人类知识是提升性能的少数方法之一），但从一个比典型研究项目稍长的时间来看，必然会有大量更多的计算能力可用。为了在短期内取得进展，研究人员试图利用他们对领域的人类知识，但从长远来看，唯一重要的事情是如何利用计算。这两者并非必然相互矛盾，但在实践中往往如此。花在其中一个方面的时间就无法花在另一个方面。在一种方法或另一种方法上会有心理上的投入。而且，基于人类知识的方法倾向于使方法复杂化，使其不太适合利用通用方法来发挥计算能力。有许多人工智能研究人员迟来的这一沉痛教训的例子，回顾其中一些最突出的例子是很有启发性的。

在计算机国际象棋领域，1997 年击败世界冠军卡斯帕罗夫的方法是基于大规模、深度搜索。当时，大多数从事计算机国际象棋研究的研究人员对这种方法感到沮丧，他们曾追求利用人类对国际象棋特殊结构的理解的方法。当一种更简单、基于搜索的方法（配有特殊硬件和软件）被证明更加有效时，这些基于人类知识的国际象棋研究人员并不是很好的失败者。他们说“暴力搜索”可能这次赢了，但它不是通用策略，而且反正也不是人类下棋的方式。这些研究人员希望基于人类输入的方法能够获胜，当它们没有获胜时，他们感到失望。

计算机围棋的研究进展呈现出类似的模式，只不过延迟了 20 年。最初的巨大努力是试图通过利用人类知识或游戏的特殊特征来避免搜索，但一旦有效地大规模应用搜索，所有这些努力都变得无关紧要，甚至更糟。同样重要的是利用自我对弈来学习价值函数（这在许多其他游戏甚至国际象棋中也是如此，尽管学习在 1997 年首次击败世界冠军的程序中并没有发挥很大作用）。自我对弈学习和学习本身，就像搜索一样，能够使大量计算能力得以发挥。搜索和学习是人工智能研究中利用大量计算能力的两类最重要的技术。在计算机围棋中，就像在计算机国际象棋中一样，研究人员最初的努力是利用人类理解（以便减少搜索需求），而后来通过拥抱搜索和学习才取得了更大的成功。

在语音识别领域，20 世纪 70 年代由 DARPA 赞助的一场早期竞赛中，参赛者包括许多利用人类知识的特殊方法——对词汇、音素、人类声道等知识的利用。另一方面，一些更新的、更统计化的方法基于隐马尔可夫模型（HMMs）进行了更多的计算。同样，统计方法战胜了基于人类知识的方法。这导致了自然语言处理领域的重大转变，逐渐在几十年间，统计和计算开始主导该领域。而深度学习在语音识别中的最近兴起是这一持续方向的最新一步。深度学习方法对人类知识的依赖更少，使用更多的计算能力，并结合在巨大训练集上的学习，产生了显著更好的语音识别系统。就像在游戏中一样，研究人员总是试图让系统按照他们认为自己的大脑工作的方式来工作——他们试图将这些知识融入他们的系统中——但随着摩尔定律使得大量计算能力变得可用，并且找到了利用这些计算能力的方法，这最终被证明是适得其反的，并且浪费了研究人员大量的时间。

在计算机视觉领域，也出现了类似的情况。早期的方法将视觉视为寻找边缘、广义圆柱体或 SIFT 特征等等。但如今，所有这些都被抛弃了。现代的深度学习神经网络只使用卷积和某些不变性的概念，性能却要好得多。

这是一个重要的教训。作为一个领域，我们尚未彻底吸取这一教训，因为我们仍在犯同样的错误。为了看到这一点，并有效地抵制它，我们必须理解这些错误的吸引力。我们必须从沉痛的教训中吸取教训，即构建我们认为自己的思维方式并不奏效。沉痛的教训基于历史观察，即 1）人工智能研究人员常常试图将知识构建到他们的智能体中，2）这在短期内总是有帮助的，并且对研究人员来说是个人满意的，但 3）从长远来看，它会趋于平稳甚至阻碍进一步的进展，而 4）通过基于搜索和学习来扩展计算的对立方法，突破性的进展最终到来了。最终的成功带有苦涩的意味，并且往往没有被完全消化，因为它是对一种受欢迎的、以人类为中心的方法的胜利。

从沉痛的教训中应该学到的一件事是通用方法的巨大威力，这些方法即使在可用计算能力变得非常强大时也能随着计算能力的增加而扩展。似乎在这两种方法中可以任意扩展的是搜索和学习。

从沉痛的教训中要学到的第二个普遍观点是，心灵的实际内容是极其复杂且不可救药的；我们应该停止尝试找到思考心灵内容的简单方式，例如思考空间、物体、多个智能体或对称性的简单方式。所有这些都是任意的、本质上复杂且外在的世界的一部分。它们不应该被内置，因为它们的复杂性是无止境的；相反，我们应该只构建能够发现和捕捉这种任意复杂性的元方法。这些方法的关键在于它们能够找到好的近似，但寻找它们的过程应该由我们的方法来完成，而不是由我们自己。我们希望人工智能智能体能够像我们一样发现，而不是包含我们已经发现的东西。将我们的发现内置进去只会让发现过程变得更加难以理解。

我的一点感想

在 Windsurf 去年底刚发布出来的时候，我曾经一度退订了 Cursor 而只用 Windsurf。虽然我后来又改订 Cursor ，但这依然不可否认 Windsurf 是一款优秀的 AI Coding 产品！看完 Windsurf 的这篇 Blog 以后，我谈一些收获或者叫感想吧。

这篇文章从 Windsurf 的视角详细阐述了智能体系统的构成要素和判断标准。也就是，真正的智能体必须具备利用LLM作为工具来调用、推理模型，并且具备实际调用工具来执行相应任务的能力，并不是仅依靠LLM生成一些内容或进行CoT等就可被称为智能体。这种明确的界定还是蛮通俗的，能够让初学者准确地识别和理解什么是真正的智能体，避免概念上的混淆和误用。

智能体系统的分析框架

文章提供了一套较为清晰、细致的分析框架，从多个维度来解剖一个智能体系统，包括是否真正智能体、自主与协作的区别、智能体的输入和组件、用户体验等方面。这个框架像一个严谨的思维导图，可以让我们系统地去剖析一个智能体系统的各个关键要素，而不是零散地、片面地看待问题。例如，在分析一个智能体系统时，要先去判断它是否符合智能体的基本定义，然后再去看它是自主的还是协作的，进一步去探究它所拥有的工具、推理模型、数据处理方式等，最后再从用户体验的角度去考量它的优劣。这算是个轻量级的方法，很实用！

对智能体系统关键要素的Review

•工具与推理模型：强调了工具对于智能体的重要性以及推理模型在调用工具方面的关键作用，智能体的强大不仅仅取决于其本身的算法和模型，还依赖于它所拥有的工具以及如何合理地利用这些工具。在构建或研究智能体系统时，不仅要关注模型的性能优化，还要注重工具的扩展性和适配性，以及如何通过有效的推理模型来精准地调用这些工具，从而发挥出智能体的最大效能。
•数据处理与用户意图捕捉：指出了智能体对现有数据的处理方式以及如何捕捉用户意图是其性能的重要影响因素。数据是智能体决策和行动的基础，而用户意图则是智能体工作的方向标。通过合理地处理数据，智能体可以更好地理解和应对各种复杂任务场景；准确捕捉用户意图则可以使智能体的工作更加贴合用户需求，提高任务完成的质量和效率。在智能体系统的开发中，需要充分重视数据管理和意图识别技术的研发，以提升智能体系统的智能化水平和实用性。而这与我自身的实践是有共鸣的！当你做智能体应用越做越深的时候，就会越来越认识到数据和意图的重要性。这两者也是提升智能体系统性能的上游关键要素（上游是指初始触发智能体行动的要素，比如 Input 指令和数据）。我曾在社区群里分享过一个自己的观点，大家也可以帮我看看对不对。即，Agent 自身通常在运作的时候，需要面对“灵魂三问”。（我是谁，在哪？我有什么？要到哪里去？）

为了成文，我把在社群里share的观点再细化一下，如下：
1.“我”是谁？在哪里？（认知）
这一问题涉及 Agent 的元定义与环境认知，具体要素如下：

• 元定义：包括角色定义、规则定义、制度制约等，明确 Agent 在系统或环境中的职责和权限。如在智能客服系统中，Agent 的角色是为客户提供咨询、解决问题等服务，需遵循相关服务规则与制度。
• 环境认知：涵盖环境情况、数据实体、上下文等，帮助 Agent 确定自身所处的具体位置和环境状态。例如，数据实体是 Agent 运作的基础，如客户信息、订单数据等；上下文则涵盖了当前任务的背景信息，对于智能客服 Agent 来说，对话上下文能帮助其更好地理解用户的意图和需求，从而提供更精准的服务。
• 更细致的元定义分类：除制度制约外，文化背景、组织架构等因素也对 Agent 角色定义有重要影响。例如，在跨文化环境中运行的 Agent，需理解不同文化背景下的行为规范和价值观差异，以更好地适应和融入环境。
• 动态感知与更新机制：Agent 应具备对自身身份和位置的动态感知能力，及时根据环境变化调整认知。如在智能工厂的生产调度 Agent 中，当生产线布局或设备状态发生变化时，它要迅速感知并更新自身对所处环境和角色定位的认知，以便做出准确的调度决策。

2.“我”有什么？（数据）
这一问题关乎 Agent 的能力与资源认知，具体要素如下：

• 能力：明确自身具备何种能力，如文本处理、图像识别、数据分析等能力，这些能力决定了 Agent 能够完成哪些任务。
• 工具：了解可以使用的工具，如各种软件工具、硬件设备等，这些工具能辅助 Agent 更高效地实现目标。
• 数据：通过数据定义（如 Schema 等）方式，对数据进行组织、存储和管理。明确数据的结构和格式，有助于 Agent 更好地理解和利用数据，为后续决策和行动提供支持。
• 能力评估与优化机制：Agent 不仅要明确自身能力，还需具备评估和优化能力。随着环境和任务的变化，Agent 要能识别自身能力的不足，并通过学习、升级等方式进行优化。例如，智能医疗诊断 Agent 可随着医学研究进展和临床数据积累，不断优化诊断算法和知识库，提高诊断准确性。
• 工具选择与组合策略：根据任务和环境动态性，Agent 要灵活选择和组合工具。不同的任务阶段和环境条件可能需要不同的工具组合。如在复杂数据分析任务中，Agent 可根据数据类型、分析目标等因素，灵活选择数据挖掘、统计分析、机器学习等多种工具进行组合应用，以实现最佳分析效果。

3.“我”要到哪里去？（意图）
这一问题聚焦于 Agent 的目标与意图认知，具体要素如下：

• 语义理解：通过语义理解技术，分析人类的语言、文字等表达，提取其中的语义信息，明确人类希望 Agent 完成的具体任务。
• 意图挖掘：Agent 应深入挖掘用户潜在意图和需求，而不仅仅是理解显性意图。例如，当用户咨询旅游目的地时，Agent 除了提供热门景点信息外，还应通过分析用户的偏好、历史记录等，挖掘其对旅游体验、文化特色、美食等方面的潜在需求，提供更个性化、全面的旅游建议。
• 目标结合：将当前任务的短期目标与长期目标相结合。例如，在智能个人助理中，不仅要完成用户当前安排日程的任务，还要考虑如何帮助用户实现长期的职业发展规划、健康管理目标等，为用户提供个性化、多元化的辅助。
以上，对比人类的组织管理，是不是有点像员工治理的部分。比如组织能力模型杨三角中的——想不想（员工意愿），能不能（员工能力），允许不允许（环境许可）；把 AI 当人用，这很有趣。那么，在 Agent 的实际运作中，上面提到的这些方面相互关联、相互影响。Agent 需要不断动态地感知和调整自身的角色、能力、数据等要素，以更好地适应环境和满足人类需求。而这其中，意图、数据、数据流，在要素占比中相当大。这是我在实践所得到的认知。所以我才在上文说到，认同“在智能体系统的开发中，需要充分重视数据管理和意图识别技术的研发，以提升智能体系统的智能化水平和实用性”。

•用户体验：将用户体验作为一个独立且重要的部分进行详细阐述，体现了Windsurf以用户为中心的设计理念。一个优秀的智能体系统不仅仅要具备强大的功能，还要为用户提供更加良好的体验，包括低延迟、易于观察和指导、良好的集成方式以及合理的智能体与非智能体体验平衡等。在构建 AI 产品的时候，不能忽视用户体验，要从用户的实际需求和使用感受出发，不断优化智能体系统的各个环节，使智能体能够更好地服务于用户。Windsurf 对用户体验的这个轻量级拆解，是适合大家学习并容易掌握的。

对技术应用与发展的现实思考

文章还提到“苦涩的教训”，我把《苦涩的教训》的原文也附在上面的附录中。（这一篇我实在是太懒了）

原文中有讲到，在智能体系统的发展过程中，我们不能过度依赖人类预设的规则和知识，而要顺应技术发展的趋势，充分利用大规模计算、数据和模型的不断进步来推动智能体性能的提升。所以，在智能体技术的研发和应用中，既要注重当前的技术手段和方法，又要保持对技术发展趋势的敏锐洞察，不断地探索和创新，以适应未来智能体技术发展的需要。

因此，我们在思考构建智能体系统时，是否应该优先考虑如何利用大规模计算的能力，而不是试图通过人为设计的规则来限制系统的行为。当然，这并不是否定人类知识在系统开发中的价值。而是说，我们应该将重点放在如何利用计算资源来发现和学习复杂问题的解决方案，而不是简单地将我们的既有认知直接编码嵌入进系统中（而这目前在模型层其实是遇到瓶颈的）。这需要我们探索 AI Agent 的 Scaling Law ！这值得进一步思考和探索。Windsurf 的这个思考，最近在业内几个头部的 Agent 框架团队中，我也看到了，这很有趣！也许这会成为一个行业的动向。