Windsurf 团队的联合创始人 Anshul Ramachandran 最近发布了一篇关于 Agent 的科普文章，对于现下被广泛讨论，且经常被误用混淆的各种 Agent 概念进行了辨析，同时对 Agent 系统的核心构成进行了拆解。如果你想要通过一篇全面地了解关于 Agent 的基础情况，这是一篇相当不错的资料。
以下为《What is an Agent？》全文内容，Founder Park 进行了编译和适当的调整。
Windsurf 团队的联合创始人 Anshul Ramachandran 最近发布了一篇关于 Agent 的科普文章，对于现下被广泛讨论，且经常被误用混淆的各种 Agent 概念进行了辨析，同时对 Agent 系统的核心构成进行了拆解。如果你想要通过一篇全面地了解关于 Agent 的基础情况，这是一篇相当不错的资料。
以下为《What is an Agent？》全文内容，Founder Park 进行了编译和适当的调整。
高浓度的主流模型（如 DeepSeek 等）开发交流；
资源对接，与 API、云厂商、模型厂商直接交流反馈的机会；
好用、有趣的产品/案例，Founder Park 会主动做宣传。
欢迎来到 2025 年，这一年 「Agent」 一词的使用频率极高，其含义也变得相当宽泛。在日常交流中，人们基于各自的理解 confidenty 地使用这个词，反而使其原本清晰的含义逐渐模糊。
如果你是一名开发者，正在构建与 Agent 相关的解决方案，那么本文可能并不适合你。本文更适合以下几类人群：
在会议、讨论或日常对话中听到他人提及 AI Agent 时心存疑惑的朋友，或许你对 Agent 的定义及其与现有生成式 AI 能力的差异不太确定；或许你怀疑使用这个词的人是否真正了解 Agent 的含义；又或许你在读到本文第一句话时，才开始质疑自己此前对 Agent 的理解是否准确。
（本文在解释某些理论概念时会提及我们的产品 Windsurf，但并非进行产品推介。)
Agent 核心概念解析：
「LLM+工具」的循环
回答本文标题的问题，我们可以将 Agent 系统简单理解为一个接收用户输入后，交替调用以下两部分的系统：
一个 LLM（在这里我们称其为「推理模型」）：依据输入、可能自动检索到的额外上下文以及累积的对话历史，来决定下一步的行动。推理模型会输出一段文字，解释采取下一步行动的原因，以及结构化的信息，具体指定行动的细节，例如调用哪个工具、工具所需的参数值等。这里的 「行动」 也可能表示没有更多需要执行的任务。
工具（Tools） ：用于执行推理模型指定的各种行动并产生结果，这些结果将纳入到信息流中，供推理模型在下一次调用时使用。需要注意的是，这些工具本身未必与 LLM 相关，推理模型的主要职责是从系统可用的工具和行动集合中进行选择。
由此构成了一个基本的 Agent 循环，核心就是如此简单。Agent 系统根据该循环呈现给用户的方式不同，会表现出多种形式，后续将详细探讨。但若你能理解这一概念，即 LLM 在此并非仅作为纯粹的内容生成器，而是更像一个负责选择工具的 「推理」 组件，那么你就已基本掌握了 Agent 的要义。
「推理（Reasoning）」 一词在 Agent 领域有着特定的含义，它指的是利用 LLM 来决定下一步要采取的行动，即确定调用哪个工具以及使用何种参数。
然而，「推理」 一词在其他语境下也被用于完全不同的概念，例如 OpenAI 的 o1 模型所指的 「推理」，是思维链（CoT）提示，即模型在给出最终答案前，先输出一系列中间步骤，模仿人类解决问题时的思考过程，而非单纯依赖模式匹配的能力，这类模型并未调用外部工具，只是以一种类似串联多个思考过程的方式生成 LLM 自身的输出，因而得名 「思维链」。
另一种常见的对 「Agent」 一词的误用是将其应用于所谓的 「AI 工作流（AI workflows）」。例如，有人构建一个自动化流程：先接收原始文档，用一个 LLM 进行对象识别，再清理提取出的数据，接着用另一个 LLM 总结数据，最后将总结添加到数据库。尽管该流程涉及到多次 LLM 调用，但 LLM 并未作为决策调用哪个工具的推理引擎，而是在工作流中事先规定好了要调用的 LLM 及其调用顺序和方式，而非让 LLM 在实时运行中自行决定调用哪些工具，这只是一个自动化流程，并非 Agent。
以一个简单的「披萨食谱」作为例子来进一步理解 Agent 系统和非 Agent 系统。假设你请求一个 AI 系统提供披萨食谱，在非 Agent 系统中，你可能直接将请求输入到一个 LLM，由其生成结果。而在 Agent 系统中，Agent 可能拥有的工具之一是 「从食谱书中检索食谱」，系统会先使用 LLM（推理模型）进行判断，根据用户请求使用 「食谱工具」，输入参数为 「披萨」，以找到对应的食谱，然后调用该工具获取食谱文本，接着推理模型根据工具输出判断无需进一步处理，结束 「循环」。
尽管你现在可能理解了 Agent 的区别，但你或许会问这为何有趣，看起来不过是方法上的技术细节。原因主要有以下几点：
当需求稍显复杂，如 「要一份那不勒斯风格的健康食材披萨食谱」 时，非 Agent 系统可能凭借生成模型的强大能力给出像样的结果，但随着请求越来越详细、层层递进，试图通过单次调用 LLM 完美满足所有要求的可能性会降低。而 Agent 系统可能会先推理决定使用一个工具，通过 LLM 描述披萨的制作方式；接着推理决定使用另一个工具进行网络搜索来确定健康食材；然后进行推理决定使用最终检索食谱的工具，前几步获得的信息同样可用于指导或配置该工具的输入。这种将任务分解成步骤的方式，与人类处理事情的方式相似。同时，因为 Agent 使用的是人类更了解、更易控制的工具，可以降低结果的不确定性。虽然不能保证一定成功，但 Agent 方法比非 Agent 方法更有机会让 AI 系统把事情办对。
我们能为 Agent 提供的工具可以弥补 LLM 的短板。LLM 是一个基于自然语言模式运作的随机系统，对非文本概念没有内在理解。如 LLM 不擅长数学，可添加计算器工具；LLM 不知道当前时间，可添加系统时间工具；LLM 无法编译代码，可添加构建工具。这样，Agent 系统中的推理模型无需内在地掌握这些领域的知识，只需知道何时调用相应工具及确定传递给工具的正确输入参数即可，这比让 LLM 掌握所有领域知识更易于实现，且判断可基于文本上下文。
工具可改变 「世界」 的状态，而不仅仅是提供文字响应。在披萨食谱的例子中，若希望 AI 不仅给出食谱，还能将其发给他人，且 Agent 有权访问联系人及发送短信工具，它就会进入循环：先推理决定检索食谱，再推理决定检索妹妹的联系信息，最后推理决定发送短信。前两步可能通过一些非常聪明的 RAG（检索增强生成）也能实现，但最后一步真正采取行动的能力，是 Agent 系统具备更强大的能力的体现。
现在你已基本了解 Agent 是什么，但还有更多背景信息可助你在谈论 「Agent」 时更专业。
通过工具弥补 LLM 自身不足，
协作式 Agent 更具潜力
在探讨更好地理解 Agent 系统中的思维模型之前，接下来我们先简要回顾是如何发展到今天的，并根据不同类型的 AI 工具与 Agent 方法的契合度进行区分，同时结合软件工程领域展开讨论。
几年前，在生成式 AI 工具出现前，人类依靠一系列行动完成工作，例如软件工程领域包括在 StackOverflow 上搜索资料、运行终端命令、编写代码等。
随着 LLM 的出现，我们拥有了能很好完成特定任务的系统，如 ChatGPT 用于回答问题，GitHub Copilot 用于自动补全代码等。这些工具能赢得使用者的信任，是因为它们满足了两个条件：一是解决了用户真正关心的问题，且 LLM 技术足够成熟，能以足够可靠的水平解决问题，让用户在特定场景下愿意信任它。二是多年来人们构建了许多基于 LLM 的系统，来展示其解决复杂任务的能力，但许多成果仅停留在演示阶段，无法投入生产环境并获得用户长期信任，导致炒作与现实脱节。如总结拉取请求对用户有价值，但用户对其准确度的要求很高，若首次使用 AI 时给出的总结是错的，那用户可能就不再信任该工具。尽管 LLM 技术不完美，但发展迅速，因此能以足够高的可靠性来解决任务，同时能解决任务的复杂度也在不断提升。
最初 「有用」 与 「可能实现」 的交集仅限于 「Copilot 式」 系统，这些 AI 系统通过单次 LLM 调用解决非常有限的任务，如回复提示或生成自动补全建议等，在人类与 AI 协同工作 （human-in-the-loop）中，在采纳结果前进行审查，因此不必担心 AI 「失控」。AI 主要的挑战是 「幻觉」 问题，即模型给出不准确的结果，这源于模型内在的 「自信」 （这些模型是在互联网文本上进行训练，而互联网上谁都显得很自信）以及缺乏使回答符合现实的知识。因此，人们通过更强大的 RAG （Retrieval Augmented Generation）方法改进 Copilot 式系统，简单来说，RAG 就是先检索相关信息为查询提供事实依据，再将整合后的信息传递给 LLM 生成最终响应，这种能力定义了基于 LLM 应用的最初几年。
正是这些类似 Copilot 的非 Agent 系统，以用户愿意长期信赖的稳定水平创造了实际价值。但「Agent 系统」 这一概念并非新事物。
首个流行的 Agent 框架 AutoGPT 早在 2023 年初就问世了，其方法是让 Agent 循环自主运行，用户只需提供提示，由 Agent 自行执行并审查结果。由于可访问工具并进行多次 LLM 调用，这些系统运行时间更长，能完成比 Copilot 式系统范围更广的任务。
尽管 AutoGPT 仍是 GitHub 上最受欢迎的仓库之一，但用它创建的 Agent 并未真正普及。一年后，Cognition 公司推出 Devin，一个号称功能齐全、能取代人类软件开发者的 AI 开发者，这是一个完全自主的 Agent 系统，拥有强大的工具，但至今能解决的仍是相对简单的问题。
这就引出了一个问题：若 Agent 如此强大，为何用户主要从 RAG 驱动的非 Agent 的 Copilot 式系统中获得价值，而非 Agent 系统？
这与上文提到的 「有用问题」 与 「技术足够成熟可靠」 的交集有关，是自主 Agent 系统面临的普遍挑战。虽然自主 Agent 是未来发展方向，但当前 LLM 可能在无人干预或纠正的情况下，难以端到端地完成复杂任务。
基于此，催生了 Agent 的一种新方法，即认识到人类和 Agent 之间需要某种平衡，这类 Agent 被称为 「协作式 Agent」（collaborative agents），或简称为 「AI Flows」。
具体而言：
必须有清晰的方式让用户在工作流执行过程中观察其进展，以便及时纠正偏差，重新引入 Copilot 式系统中 「human-in-the-loop」的协作特性。
这些工作流必须在人类习惯工作的同一环境中运行。大多数自主 Agent 项目独立于用户运行，其调用界面与用户手动完成工作时的环境是脱节的，如 Devin 通过网页调用，而开发者在 IDE 中编写代码。若 Agent 不在人类工作的主环境中，就无法感知手动操作，会错过许多隐式上下文。
总之，在现实应用中，Agent 能观察人类行动很重要，反过来人类能观察 Agent 的行动也同样重要。
协作式 Agent 方法所需的可靠性门槛显著低于自主 Agent 方法，因为人类可以在中间步骤纠正 AI，在 AI 执行某些行动时确认，并负责实时审查改动。目前，所有能为用户带来切实价值且普通用户可接触到的 Agent 应用，都采用了这种方法，如 Windsurf 的 Cascade、Cursor 的 Composer Agent 和 GitHub Copilot Workspaces，在这些工作流中，人类和 Agent 始终在同一 「世界状态」 下协同运作。
我们如此详细地区分自主 Agent 和协作式 Agent，是因为它们是构建 「Agent 系统」 的截然不同的两种方法，这两种方法在「human-in-the-loop」的 参与程度、所需信任水平、交互方式等方面差异巨大。由于 「Agent」 一词被过度使用，有人热衷于讨论构建自主 Agent，并以像 Windsurf 的 Cascade 这样的系统作为 Agent 可行的证据，而实际上这两种方法本质上并不同。
全方位理解和剖析 「Agent 系统」
以下是一个包含所有前文内容的速查清单，帮你理解关于 「Agent」 的对话，并提出触及技术核心的问题。这些问题中可以分别延展成独立的文章探讨，这里我们先进行基础的探讨。
问题 1：讨论的系统真的是 Agent 吗？
太多非 Agent 系统被冠以 「Agent 系统」 之名，需明确其中的 LLM 是否作为工具调用的推理模型，是否真的有工具被调用，还是仅为思维链推理或其他含义完全不同的东西。
问题 2：它是自主的还是协作式的？
该 Agent 系统是让 Agent 在后台自主工作无需人工参与，还是具备独立完成多步任务的能力但却嵌入到现有的工作系统中仍需要人类参与？若是前者，即自主 Agent，需要追问当前模型是否足够强大，能以用户信赖的稳定性水平处理数据和工具的规模及复杂性，还是构建自主 Agent 的想法并不切实际？
问题 3：Agent 是否拥有内在强大的所有输入和组件？
问题 3a：Agent 可以访问哪些工具？
不仅要了解工具列表，还要探究工具的实现方式，如 Windsurf 的 Cascade 采用了独特的网页内容分块和解析方法。以及，添加独特工具的难易程度如何？
问题 3b：Agent 使用的是哪个推理模型？
评估 LLM 时，应关注其在工具调用方面的能力，而非其在标准基准测试中的表现，不存在胜任所有任务的最优 LLM，需考虑 Agent 是否具备使用不同类型模型的灵活性。
问题 3c：Agent 如何处理现有数据？
Agent 能访问哪些数据源？在协作式 Agent 场景下，它对这些数据源的访问是否遵循了用户已有的访问控制规则？比如对于代码库，Agent 是仅能访问用户当前在 IDE 中检出的仓库，还是也能访问其他仓库的信息来辅助结果生成？从代码的分布式特性来看，能访问更多仓库可能更有价值，但访问控制的难度也会相应增加。
Agent 方法改变了我们思考数据检索的方式。在 Copilot 式系统里，只有一次调用 LLM 和检索的机会，这使得 RAG 系统愈发复杂。而在 Agent 系统中，若首次检索结果不理想，推理模型可更改参数重新检索，直到收集到足够的信息采取行动，这更贴近人类查找数据的模式。所以，当讨论深入到 RAG、解析及中间数据结构时，不妨想想我们在 Agent 领域是否把问题想复杂了。
不过，如果数据本身有结构，那询问这些数据源的信息如何处理是合理的。比如 AI 编程工具处理的代码库是高度结构化的，就可以利用抽象语法树（AST）解析等技术，对代码智能分块，方便理解或搜索代码的工具处理。智能预处理和多步骤检索是可以并存的。
问题 3d：协作式 Agent 或 AI Flow 如何捕捉用户意图？
在人类用户的手动操作中，存在一些无法明确编码的隐式信号。虽然 Agent 不知道你在饮水机旁聊了什么，但仅通过捕捉这些隐式信号，就能创造出极有价值的体验。在我们领域，这些用户意图可能体现在 IDE 中打开的其他标签页、刚刚在文本编辑器中的编辑、执行的终端命令、剪贴板内容等。这关乎降低用户使用 Agent 的「激活能垒」——若每次使用 Agent 都要用户详细描述本可通过隐式信号推断的细节，那用户对 AI 结果质量的期望就会过高。
问题 4：这个 Agent 的用户体验为何特别好？
我们之前主要探讨了影响 Agent 结果质量的因素。但若想打造一款真正被用户接纳的 Agent 系统，仅关注结果质量还不够，还需关注提升用户使用流畅度的各方面体验，即便底层 Agent 本身没变。这些体验维度很多都不易构建，需要深入思考。
问题 4a：Agent 系统的延迟如何？
假设有两个 Agent 系统能完成同一特定任务，一个耗时一小时，另一个只需一分钟。若确定两者都能成功，你可能不太在意时间差，毕竟等待时可以做别的事。但若 Agent 有可能失败呢？你肯定会更倾向后者，因为能更快知晓失败，及时调整提示或给 Agent 更多指导。延迟问题是全自主 Agent 的主要挑战之一，它们完成任务的耗时通常比人类手动操作更长，除非自主 Agent 的成功率极高，否则用户不会选择使用它。
特别强调延迟问题的原因有二：其一，Agent 开发者为提升结果质量，常添加复杂耗时的工具，却忽视了对用户体验的影响，没做好权衡；其二，减少延迟是技术栈各环节的难题——是模型推理优化，还是构造提示以提高缓存命中率，或是在工具内部实现并行计算？这需要不同技能的工程师协同攻克。
问题 4b：用户如何观察和引导 Agent？
这是协作式 Agent 相较自主 Agent 的一大优势，但实现起来并不容易。例如，若编程 Agent 能在 IDE 的多个文件中多次修改代码，开发者该如何有效审查这些改动？这和查看单个自动补全建议或在聊天面板审查回复完全不同。
此外，人们需要时间来建立特定环境下的任务最佳实践上下文。你能设计出怎样的用户体验，让用户引导 Agent 遵循这些最佳实践？比如，Windsurf 的 Cascade 可接受用户定义的规则，或通过简单方式标记已知上下文以指导 Agent。虽说 Agent 的目标是能独立完成任务，但如果用户能轻松帮助 Agent 降低任务难度，Agent 就能更快地输出高质量成果。
问题 4c：Agent 如何集成到应用中？
这取决于如何优雅地调用 Agent 以及利用其输出。如今，ChatGPT 的流行让聊天面板成为调用 AI 系统的常见方式，但这不是唯一选择。例如，Windsurf 的 Cascade 可通过一个简单按钮调用以解释代码段，并且能通过 Previews 功能将控制台日志和 UI 组件等上下文信息传递给 Cascade，无需复制粘贴文本。
问题 4d：Agent 体验如何与非 Agent 体验平衡？
并非所有任务都需 Agent 来做。比如开发者进行局部重构时，使用 Command 和 Tab 等快捷键组合这类非 Agent 的「Copilot 式」体验，既快速又高效。Agent 是新兴领域，但不能盲目用 Agent 解决所有问题。问问自己「这个任务真的需要构建一个 Agent 吗？」往往很有必要。
当然，以上只是初步探讨，但这份清单能帮你更好地理解 Agent 相关对话，提出关键问题，为想法增加现实主义的视角。
构建 Agent 同样需要注意「苦涩的教训」
最后，有一个重要问题值得单独列出，若你从本文只记住一个问题，那应该是 「我们是否正在违背‘苦涩的教训’？」 「苦涩的教训」 源自 Richard Sutton 的同名文章，其核心观点是：更多的算力、数据以及更大规模的技术，终将超越依赖人类定义结构或规则的系统。这一趋势在计算机视觉、游戏、NLP 等领域得到印证，如 LLM 的性能超越了传统 NLP 方法。
在使用 Agent 时，我们可能再次忘记 「苦涩的教训」，认为对特定用例的深入了解，需花费时间精心设计提示、选择工具集合或注入人类知识。然而，模型持续改进，计算能力变得更便宜、强大，这些努力最终可能付诸东流。因此，要避免落入 「苦涩的教训」 的陷阱。
OpenAI报价30亿，三个月实现收入翻倍，Windsurf做对了什么？
转载原创文章请添加微信：founderparker
内容中包含的图片若涉及版权问题，请及时与我们联系删除
评论
沙发等你来抢