Windsurf团队关于Agent的认知，相当精彩

刷朋友圈，偶然看到大厂朋友转发一篇关于 Agent 的文章，还特意点评：写得真精彩。我点进去读了下，确实不错，原来出自 Windsurf 团队。

这段时间 “Agent” 成了热词，开会、聊天、朋友圈，大家都在聊。但每个人说的 “Agent” 其实都不一样，听多了反而更迷糊：究竟什么是 Agent？和我们熟悉的生成式 AI 有什么不同？

这是我目前见过最清晰解释 Agent 的文章。

#01

基本核心概念

可以简单地把 Agent 系统理解为一个接受用户输入，并交替执行以下两种调用的系统。

• LLM，会根据用户输入、可能自动检索到的额外上下文信息，以及不断积累的对话内容，决定下一步要采取的行动。
• 推理模型会输出：（a）一段文本，解释接下来应该采取什么行动；以及（b）一段结构化信息，用来明确说明该行动的细节（具体是哪一个行动，该行动的输入参数值等）。
• 有时候，输出的 “行动” 也可能是判断 “当前没有任何行动需要再执行”。工具，指的是可以实际执行各种行动的组件，它们不一定非要与 LLM 有任何关系。这些工具根据推理模型的指令来执行任务，并生成结果，而这些结果会被纳入下一次调用推理模型时所使用的信息中。推理模型的作用本质上是在可用的工具和行动之间做出选择。

这就构成了一个基本的 Agent 循环：

真的，就是这样。一个 Agent 系统可能会因为其 Agent 循环向用户暴露的方式不同而呈现出不同的 “风格”，我们稍后会展开讲。

但只要你理解了这个概念——这些 LLM 不是被当作一个纯粹的内容生成器（比如 ChatGPT），而是被当作一个 “工具选择的推理组件” 来使用——你其实已经掌握了大部分要点。

“推理（reasoning）” 这个词本身也被过度使用了——但在 Agent 系统的语境下，它有一个非常具体的含义：指的是使用 LLM 来选择下一步应该执行什么动作，也就是应该调用哪个工具、传入哪些参数。

“推理” 这个词也被像 OpenAI 的 o1 这样的模型使用过，但在那里的含义完全不同。对这些 LLM 来说，“推理” 指的是 “链式思考提示（chain-of-thought prompting）”。

这种方法的核心理念是：模型会先输出一些中间步骤，再尝试给出最终答案，目的是模拟人类解决问题时的思考过程，而不是单纯依赖模式匹配的魔法。

对于这些模型来说，并不会调用任何工具（不像在 Agent 系统中），而是以一种看似多次调用思考过程的方式输出回答内容（这也是 “chain-of-thought” 这个说法的由来）。

另一个对 Agent 的误用，是把它混淆成所谓的 “AI 工作流（AI workflows）”。

举个例子，有人可能会构建一个自动化流程，输入一份原始文档，先用一个大语言模型进行目标识别（object recognition），然后对提取出的元素进行清洗，再用另一个大语言模型对这些元素进行摘要，最后把这个摘要添加进数据库。

这个过程中虽然涉及多次调用 LLM，但这些 LLM 并不是作为 “工具调用推理引擎” 来使用的。我们事先就明确规定好了应该调用哪些 LLM、如何调用，而不是让 LLM 在实时运行中决定要调用哪些工具。这只是一个自动化流程，不是一个 Agent 系统。

理解 “Agent 系统” 与 “非 Agent 系统” 的一个非常简单的例子是：假设你问一个 AI 系统怎么做披萨。在非Agent 系统中，你只是把这个提示词直接输入给 LLM，然后它就生成一个结果。

而在 Agent 系统中，Agent 所拥有的工具之一可能是 “从某本食谱书中检索菜谱”，而这本书中包含披萨的做法。在这个 Agent 系统中，系统会使用 LLM（也就是推理模型）来判断：根据这个提示词，应该调用 “菜谱工具”，并传入 “披萨” 作为输入，以检索正确的菜谱。

接着系统会调用这个工具，得到对应菜谱的文本输出；随后，推理模型会基于这次工具调用的输出判断：已经没有其他工作需要继续执行了，于是它会结束这一轮循环。

虽然你现在可能已经理解了它们之间的区别，但你可能会问——这有什么好玩的？这不就是一种技术实现方式的细节问题吗？

其实，这之所以有趣，有几个原因：

想象一下，前面的例子如果再复杂一点，比如 “获取一份使用健康食材、并符合那不勒斯风格的披萨菜谱”。

非 Agent 系统可能靠生成模型的强大能力，仍然可以给出一个差不多的答案，但当请求变得越来越复杂、层次越来越多时，单次调用一个 LLM 就很难完全满足需求。

而 Agent 系统则可能会先推理出需要调用一个工具，让它去描述那不勒斯是怎么做披萨的，然后再推理出应该使用另一个工具去搜索哪些食材被认为是健康的，最后才推理出应该调用检索菜谱的工具，而前面几个步骤的信息又可以作为最终工具的可配置输入参数。

这种任务拆解的方式听起来应该是很自然的，因为这本来就是人类解决问题的方式；同时也能降低生成结果的随机性，因为 Agent 系统使用的是我们更熟悉、更可控的工具。虽然这并不意味着一定能成功，但相比非 Agent 方法，这种 Agent 路径更有可能得到正确结果。

我们可以为 Agent 系统提供各种工具，来弥补 LLM 本身不擅长的事情。要记住，LLM 是一种基于自然语言模式运行的随机系统。它对非文本概念没有内在理解。

LLM 不擅长数学？那我们就加一个计算器工具。LLM 不知道当前时间？那我们就加一个系统时间工具。LLM 无法编译代码？那我们就加一个构建工具。

于是，在 Agent 系统中，推理模型（也就是 LLM）就不需要自己真的知道怎么做数学计算、怎么看时间或怎么编译代码，而只需要知道什么时候该用计算器，什么时候该查询系统时间，什么时候该尝试构建源代码，并能判断应该给这些工具传入哪些正确的输入。

知道怎么调用这些工具，是一个更容易处理的问题，可以基于文本上下文来做。

这些工具不仅可以提供文本响应，它们还可以真正对现实世界的状态进行改变。

比如，回到披萨的例子，如果我们希望 AI 把披萨菜谱发给我妹妹，假设 Agent 具备访问我的联系人和发送短信的工具，它就可以进入一个循环——先推理出要检索菜谱，然后推理出要获取我妹妹的联系方式，最后推理出要发送短信。

前两个步骤可能靠非常聪明的 RAG（检索增强生成）也能完成，但最后一步呢？那种 “真正采取行动” 的能力，而不仅仅是生成文本，这让 Agent 系统具备了成为强大系统的潜力。

恭喜你，你现在已经知道什么是 “Agent” 了！不过，如果你想在 “Agent” 相关的谈话中真正游刃有余，还有更多背景知识值得了解。

#02

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

在进入 “你可以用来与他人进行有意义讨论” 的 Agent 系统心智模型之前，我们先简单回顾一下我们是如何走到这一步的，并澄清一下不同类型的 AI 工具在 Agent 上的表现方式。

我们会以我们所处的领域——软件工程——为背景来讲，这样就不会显得过于抽象。

如果你还能记得几年前的世界，那时候在生成式 AI 工具出现之前，是人类在做这些工作。这些工作可以看作是一个个连续的动作组成的时间线。在软件工程中，这可能包括：在 StackOverflow 上查资料、运行终端命令、真正写代码等等：

接着，随着 LLM 的出现，我们开始拥有了一些能很好完成特定任务的系统。比如 ChatGPT 可以用来回答问题，GitHub Copilot 可以自动补全几行代码等等。这些工具之所以能被信任，是因为它们同时满足了两个条件：

• 它们解决了用户真正关心的问题（例如，每个开发者都讨厌写样板代码，所以能自动补全这类内容就非常有价值）

• LLM 技术本身已经足够强大，能够在某些特定应用场景中以足够可靠的水平解决这些问题，从而让用户愿意信任它（比如：开发者不喜欢某个补全建议？没关系，他可以直接继续打字，忽略掉就行）。

第二个条件其实很重要。多年来，人们一直用 LLM 做出非常炫酷、超复杂任务的演示（demo），但大多数 demo 并不能真正落地、也难以被信任，这就导致了人们在炒作与现实之间产生了普遍的脱节，最终进入幻灭低谷期。

拿 “总结一个 PR” 这个例子来说：这对用户来说显然是有价值的（没人喜欢手动写 PR 描述），但你想想要达到用户愿意长期信任它所需要的准确度有多高。

只要 AI 第一次总结错了，用户以后就会每次都手动检查所有文件，自己写描述，这个工具的价值也就等于被抹消了。

这个用例对系统稳健性的要求非常高，而今天的技术或许还达不到。不过话说回来，尽管当前的 LLM 技术并不完美，但它也在快速进步，因此可以稳健地完成的任务复杂度上限也在不断提高。终有一天，AI 会足够可靠地写出 PR 描述。

我有点跑题了。我们刚开始看到的 “有用” 与 “可实现” 交集，其实仅限于我所说的 “类 Copilot 系统”。这些 AI 系统会对某个非常具体的任务进行一次 LLM 调用，比如响应提示词、生成代码补全建议等等。

人在循环中始终处于 “审阅结果” 的位置，在 “接受” 结果之前先确认，因此无需担心 AI 失控的问题。

主要的问题反而是 “幻觉”——模型输出了不准确的结果，这一方面是因为它们天然自信（这些模型是在互联网文本上训练出来的，而网上的每个人都很自信），另一方面是因为它们缺乏把答案锚定在现实上的知识（归根结底，它们只是超级复杂的模式匹配算法）。

于是，这类 Copilot 系统逐步被更强大的 “检索增强生成（简称 RAG）” 方法所改进。本质上，它的意思是：系统会先检索与用户问题相关的信息，用这些信息来 “增强” 原始问题，再将增强后的信息一并传给 LLM 去生成最终回答。

这种给 AI 系统赋予 “知识访问能力”，并且仍然只针对特定任务使用的方式，构成了基于 LLM 的应用最初那几年发展的核心特征——也就是所谓的“Copilot 时代”：

这些类 Copilot 的非 Agent 系统，才是真正在用户能够长期信任的稳定水平上持续创造实际价值的系统。但这并不意味着 “Agent 系统” 这个概念是全新的。

第一个广为人知的 Agent 框架是 AutoGPT，它其实早在 2023 年初，ChatGPT 刚发布不久后就已经问世了。它对于 Agent 系统的设计方式是：让 Agent 循环以一种自主的方式运行——用户只需提供一个提示词，然后让 Agent 自己执行一系列操作，最后再来查看结果。

本质上，由于这些系统能够访问工具，并进行多次 LLM 调用，它们运行时间更长，能够完成的任务范围也比类 Copilot 系统大得多：

然而，尽管 AutoGPT 仍是 GitHub 上最受欢迎的开源项目之一，用这个框架创建的 Agent 系统其实并没有真正普及开来。

一年后，Cognition 推出了 Devin，一个被宣传为能够取代人类软件工程师的全功能 AI 开发者。同样是一个完全自主的 Agent 系统，具备一些非常强大的工具，但直到今天，它也只能解决相对简单的问题。

那到底发生了什么？如果 Agent 真的那么强，为什么真正带来价值的，还是那些 RAG 加持的、非 Agent 的 Copilot 系统？

回想一下我们之前提到的 “有价值的问题” 与 “技术是否已经足够可靠” 之间的交集？这正是这些 Agent 系统所面临的普遍挑战。

虽然 Agent 系统代表着未来的发展方向，但今天的 LLM 可能还不具备足够的能力，在没有任何人类参与或纠正的情况下，从头到尾完成这些复杂任务。

现实促使人们开始采取一种新的 Agent 系统方法，这种方法基于一个共识：在人类与 Agent 之间，应该存在一种合理的任务分配平衡。为了与完全自主的 Agent 方式加以区分，我们将这种方法称为 “协作式 Agent ”，或简称为 “AI flows”。

具体来说：

需要有清晰的方式让人类在流程执行过程中观察它的行为，这样一旦流程偏离预期，人类可以尽早进行纠正。换句话说，是将类 Copilot 系统中的人机协作机制重新引入进来。

这些流程必须运行在与人类进行实际工作的相同环境中。大多数完全自主 Agent 的尝试，都是在与用户操作界面完全分离的环境中运行的，因为它们本身就是 “独立” 工作的。举个例子，Devin 是在网页中被调用的，而现实中开发者是会在 IDE 中写代码的。

如果我们真的处在一个 Agent 可以完成所有事情的世界里，这样做也许没问题，但由于这些自主 Agent 系统并不生活在用户实际工作的场景中，它们就无法观察人类是如何手动完成工作的。因此，它们会错过很多可以通过人类行为推断出来的隐含上下文。

比如，如果 Agent 系统是嵌入在 IDE 中运行的，那么它就能察觉到最近的手动编辑，这些信息可以隐性地告诉 Agent 接下来应该做什么。

换句话说，在这个现实中，让人类观察 Agent 在做什么很重要，而让代 Agent 观察人类在做什么也同样重要。

回到 “有价值的问题” 与 “技术是否已经足够可靠”之间的交集，协作式 Agent 方法所需的稳健性门槛要远低于完全自主的 Agent 方法。这是因为人类可以随时在中间步骤中对 AI 进行纠正，可以被要求批准 AI 的某些操作（例如执行终端命令），并且需要实时审查其所做的更改。

这正是当下所有真正创造实际价值、并广泛可用的 Agent 应用所采用的方法，例如 Windsurf 的 Cascade、Cursor 的 Composer Agent，以及 GitHub Copilot Workspaces。在这些 flow 中，人类与 Agent 始终在同一个世界状态下协作运行：

我们花这么大篇幅来区分 “自主 Agent” 和 “协作式 Agent”，是因为这两种方式在构建 Agent 系统时，其实是截然不同的路径。它们涉及到完全不同程度的人机协作、不同程度的信任需求、不同的交互方式等等。

而由于 Agent 这个词被过度使用，人们常常在谈论构建自主 Agent 的同时，又把 Windsurf 的 Cascade 这样的 Agent 系统当作 “Agent 成功” 的例证，但实际上，这两种方法之间的差异非常大。

#03

如何理解一个 Agent 系统的运作方式

好了，终于到了你可能一直在等的部分——一份快速清单，结合我们上面所讲的一切，帮助你（a）在对话中更好地理解 Agent 相关内容，（b）提出能切中技术核心的问题。很多问题其实本身都可以单独写成一篇文章，但我会尽量先提供一个有用的起点。

问题 1：我们讨论的系统，真的算是 Agent 吗？

如你所见，现在有太多人在把一些其实并不是 “Agent” 的系统贴上 “Agent” 的标签。这个系统真的在使用 LLM 作为 “工具调用推理模型” 吗？它真的调用了工具吗？还是说它只是用了类似“思维链”之类的推理方式，只是叫 Agent，但其实是完全不同的概念？

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

这个 Agent 系统的设计方式，是希望 Agent 在没有人类参与的情况下在后台运行？还是 Agent 能够独立执行多个步骤，但嵌入在已有的工作系统中，并且仍然有人类参与其中？

如果是前者，那么你需要追问一个问题：当前的模型是否真的已经足够强大，能够以用户可以信赖的稳定性，对相关数据和工具进行复杂、规模化的推理？还是说，“构建一个自主 Agent”听起来很美好，但在现实中却并不实用？

问题 3：这个 Agent 拥有让它强大的输入和组件吗？

这个问题开始触及到不同 Agent 实现之间的真正区别（尤其是协作式 Agent 或 Flow），即使它们试图解决的是相同的任务。

问题 3a：Agent 可以访问哪些工具？

不只是工具的列表，还要考虑这些工具是如何实现的？例如，Windsurf 的 Cascade 在执行网页搜索时采用的是对网页内容进行分块和解析的独特方法。另外，是否可以轻松添加你自己开发的独特工具？Anthropic 提出的 Model Context Protocol（MCP）等方法正试图标准化一种接入方式，将新工具集成到现有 Agent 系统中。

问题 3b：Agent 使用的是哪种推理模型？

评估 LLM 时，关键是看它是否擅长进行 “工具调用”——而不是看它在各种任务和领域的标准基准测试中表现是否最好。一个模型在回答编程问题上非常擅长，并不意味着它也擅长以 Agent 方式选择合适的工具来解决这些编程任务。

没有哪个 LLM 能在所有任务上都是 “最好的推理模型”，虽然像 Anthropic 的 Claude 3.5 Sonnet 被认为是工具调用方面表现最好的模型之一，但这些模型正在快速演进。因此，值得思考的一个问题是：这个 Agent 系统是否支持使用不同模型的灵活性？

问题 3c：Agent 如何处理现有数据？

Agent 可以访问哪些数据源？对于这些数据源的访问，Agent 是否遵守了对用户而言已存在的访问控制规则（尤其是在协作式 Agent 的场景下）？

有时问题并不仅仅是 “能否访问数据源” 这么简单——比如在处理代码库时，Agent 是否只能访问用户在 IDE 中当前检出的仓库？还是说，它也可以访问其他仓库中的信息来帮助增强结果的准确性？在代码高度分布的现实环境中，后者可能更有价值，但这也使得 “访问权限” 相关的问题变得更加重要。

总体而言，Agent 在处理数据检索问题时带来了新的范式。在类 Copilot 系统中，只有一次调用 LLM 的机会，因此也只有一次检索机会，这也催生了越来越复杂的 RAG 系统。

而在 Agent 系统中，如果第一次检索的结果不好，推理模型可以选择重新进行一次带有不同参数的检索，一遍遍重复，直到确定已收集到所有足以执行操作的相关信息。这种方式与人类查找信息的行为方式更为相似。

因此，如果某次讨论开始在 RAG、解析或中间数据结构上过于深入，你可以提出一个问题：我们是不是在 Agent 系统的场景中过度复杂化了这个问题？这一点我们稍后还会进一步探讨……

当然，如果数据中本身是有结构的，那么询问这些数据是如何被处理也是合理的。

举例来说，我们日常处理的是代码库，而代码本身就是高度结构化的，因此我们可以使用一些巧妙的技术，比如抽象语法树（AST）解析，把代码进行更智能的分块，使得那些尝试在代码库上进行推理或搜索的工具更容易处理这些信息。智能预处理和多步检索并不冲突。

问题 3d：协作式 Agent（或 Flow）是如何捕捉用户意图的？

有没有什么隐性信号（implicit signals）可以用来推测用户真正的意图？当然，Agent 无法知道茶水间的闲聊内容，但 “读懂用户意图” 常常可以带来更具价值、更具魔力的体验。

在我们的场景中，这些意图可能隐藏在：用户在 IDE 中打开的其他标签页、他们刚刚在文本编辑器中做出的修改、他们刚刚在终端中执行的命令、他们剪贴板里粘贴的内容，甚至更多。

这又回到了 “降低使用 Agent 的激活能量” 这个问题——如果每一次都要求用户显式写清楚那些其实可以从这些隐性信号中推断出来的内容，那么用户对 AI 结果质量的期待门槛就会变得更高。

问题 4：这个 Agent 的用户体验好在哪里？

到目前为止，我们讨论的都是影响 Agent 输出结果质量的各种因素。你会发现，大多数关于 Agent 系统的讨论都集中在这些方面，但如果你真正想打造一个能够被用户广泛采用的 Agent 系统，那就必须关注那些能让 Agent“用起来更顺畅” 的用户体验维度——即 Agent 理底层的功能完全没有改变。这些用户体验维度并不容易实现，因此需要认真思考。

问题 4a：这个 Agent 系统的响应延迟有多高？

想象一下，有两个 Agent 系统在处理同一个任务时能做出相同的结果，但一个要一个小时才能完成，另一个只需要一分钟。如果你知道它们一定能完成任务，也许你不会太在意这个时间差，你可以在此期间去做别的事。

但如果这个 Agent 有可能失败呢？你一定会更倾向于后者，因为你可以更快看到失败结果，从而有时间修改提示词、给予更多引导等等。

这个 “延迟” 问题其实是完全自主 Agent 系统长期以来的核心难题之一——它们完成任务所花的时间常常比人类手动完成还要长；除非它们的成功率极高，否则用户根本不会愿意用它。

明确提出延迟问题有两个原因。

第一，构建 Agent 的开发者往往会为了提升结果质量而引入复杂、缓慢的工具，却没有充分考虑这对用户体验的影响和权衡。

第二，优化延迟是一个非常难的问题，涉及整个技术栈的方方面面——比如如何优化模型的推理速度？如何设计提示词，让系统更容易命中缓存、减少重复生成？如何在工具内部并行处理任务？这些通常都需要一套完全不同的工程能力来解决。

问题 4b：用户如何观察并引导 Agent？

这是协作式 Agent 相较于自主 Agent 的一大优势，但要真正落地却并不容易。例如，如果一个代码 Agent 会在 IDE 中对多个文件做出多次修改，开发者该如何有效地审查这些更改？这可远比检查一个补全建议或聊天面板里的回答复杂得多。

此外，人们会花时间积累某些任务在特定环境下的最佳实践。那你要怎么设计用户体验，让人可以引导 Agent 走向这些最佳实践？

举个例子，Windsurf 的 Cascade 支持用户通过定义规则或标记已有上下文的方式来进行引导。是的，任何 Agent 的最终目标都是 “能自己完成所有事”，但如果用户能很轻松地让 Agent 的任务变简单，那 Agent 就能更快地完成更高质量的工作。

问题 4c：Agent 是如何集成在应用中的？

归根结底，这取决于调用 Agent 的方式是否流畅、以及如何使用其输出结果。ChatGPT 的流行让 “聊天面板” 成为调用任何 AI 系统的默认方式。虽然这种方式可行，但它不必是唯一的方式。

例如，Windsurf 的 Cascade 也可以通过其他方式调用，比如点击一个按钮来解释一段代码。并且上下文也可以通过多种方式传给 Cascade，而无需复制粘贴文本，比如通过 Previews 将控制台日志或 UI 组件传入。

问题 4d：Agent 体验如何与非 Agent 体验进行平衡？

这可能是个意料之外的问题，但并不是所有事情都需要 Agent 来处理。举例来说，如果一个开发者只是想做一个局部重构，那么使用 Command 和 Tab 这样的组合就会非常高效且迅速。Agent 确实代表了新前沿，但拥有一把新锤子，并不意味着所有问题都是钉子！很多时候，我们应该直接问一句：“这个任务，真的需要一个 Agent 来完成吗？”

当然，这里我们也只是触及了表面，但这个检查清单应该可以帮助你更深入地参与关于 Agent 的讨论，提出直击核心的问题，并为那些 “好听但不现实” 的想法注入一点现实感。

#04

The Bitter Lesson

但还有最后一点。我把它单独列出来，是因为如果你从这篇文章中最终只记住一个问题，那就应该是这个：“我们是否违背了 The Bitter Lesson？”

“The Bitter Lesson（苦涩的教训）” 来自 Richard Sutton 的同名文章，其核心观点是：更强的算力、更大的数据规模，以及更广泛的技术规模，最终总是会带来比任何依赖人类设定结构或规则的系统更强的表现。

我们已经在很多地方见过这一点：比如，在计算机视觉中，卷积神经网络（CNN）最终打败了人类手工设计的边缘检测、形状识别算法；在游戏领域，深度搜索和后来的深度神经网络也超越了任何基于规则的系统，无论是国际象棋、围棋，还是更复杂的游戏。

甚至 LLM 本身也是这一趋势的体现，它们已经超越了所有 “传统” 的自然语言处理方法。

而在 Agent 系统上，我们又一次面临可能忘记 “苦涩教训” 的风险。我们可能会觉得自己对某个特定用例理解更深，于是就投入大量时间去精心设计提示词，或者谨慎挑选哪些子集工具才有价值，或者尝试各种方式把 “我们自己知道的东西” 灌输进去。

但最终，这些模型还会继续进化，算力会持续变得更便宜、更强大，而我们所做的这一切努力，很可能最终都会被淘汰。

不要再次掉入 Bitter Lesson 的陷阱。

文章来自微信公众号 “ AI产品阿颖 “，作者 阿颖