Agent 是什么？一篇让你彻底理解 AI 新物种的深度好文

Agent 是 2025 年最火的概念之一，身边很多朋友都在谈论它。偶然间看到了 Windsurf 的这篇文章，觉得写得很好，分享给大家。

原文链接：https://windsurf.com/blog/what-is-an-agent^[1]

文章有点长，建议先收藏！正文从下面开始～

如果你是一名试图构建智能体解决方案的开发者，这篇文章可能不适合你。

本文适合那些在会议、董事会或对话中听到有人谈论AI智能体，却（a）不确定智能体是什么，以及它与我们目前所见的生成式AI能力有何不同；（b）怀疑使用该术语的人是否真正了解智能体的含义；或（c）以为自己知道智能体是什么，直到读到本文第一句话的人。

虽然我们会引用Windsurf^[2]来让一些理论概念更易于理解，但这并非推销广告。

让我们开始吧。

最基础的核心概念

回答本文标题：一个智能体AI系统可以简单理解为接收用户输入后，交替调用以下组件的系统：

• 大语言模型（LLM）（我们称之为“推理模型”）：根据输入、可能自动检索的额外上下文以及累积的对话内容，决定下一步行动。推理模型会输出（a）解释下一步行动的文本，以及（b）结构化信息以指定具体行动（选择哪个工具、输入参数值等）。输出“行动”也可能表示无需进一步操作。

• 工具（与LLM无关）：执行推理模型指定的各种行动，生成的结果将纳入下一次推理模型调用的信息中。

本质上，推理模型的作用是在系统可用的工具和行动集合中进行选择。

这就形成了一个基础的智能体循环：

没错，就这么简单。

根据这个循环如何向用户呈现，智能体系统有不同的变体（后文会详述）。但只要你理解这些LLM不是作为纯内容生成器（如ChatGPT），而是作为工具选择的推理组件，就已经掌握了核心概念。

“推理”这个术语同样被过度使用——在智能体领域，它有非常具体的含义：指利用LLM选择下一步行动，即决定调用哪个工具及其参数。而像OpenAI的o1等模型提到的“推理”则完全不同，那里指的是思维链提示（chain-of-thought prompting），即模型在给出最终答案前先输出中间步骤，试图模仿人类解题过程而非依赖纯粹的模式匹配魔法。在这些模型中，并没有调用任何工具（如同在智能体世界那样），只是以看似串联多个思考调用的方式生成大语言模型的输出（因此称为“思维链”）。

另一个对“智能体”的误用，是指那些可以被称为“AI工作流”的东西。例如，有人可能会构建一个自动化流程或工作流，接收原始文档，使用大语言模型进行对象识别，然后清理提取的元素，接着用另一个大语言模型总结这些元素，最后将摘要添加到数据库中。

这里涉及多次大语言模型调用，但这些模型并未被用作工具调用的推理引擎。我们预先指定了应该调用哪些大语言模型以及如何调用，而不是让大语言模型实时决定该调用哪些工具。这仅仅是自动化，而非智能体。

举个超级简单的例子来理解智能体与非智能体的区别：假设你向一个AI系统索要制作披萨的食谱。

在非智能体世界中，你只需将提示词输入大语言模型并让它生成结果：

而在智能体世界中，智能体可能拥有的工具之一是从烹饪书中检索食谱，其中就包含披萨食谱。在这个世界里，系统会使用大语言模型（推理模型）判断：根据提示词，我们应该使用输入为”披萨”的”食谱工具”来检索正确配方。随后调用该工具，输出食谱文本，接着推理模型会根据工具调用的输出判定无需继续工作，从而完成其”循环”。

虽然现在区别可能已经明晰，但你可能想问——这有什么值得关注的？看起来只是技术实现上的差异。实际上，其重要性体现在几个方面：

• 试想一个更复杂的例子。比如”获取一份采用健康食材的那不勒斯风格披萨食谱”。非智能体系统或许能凭借生成模型的特性给出合理结果，但随着请求变得更详细、更复杂，单次大语言模型调用能精准满足需求的可能性会越来越低。而智能体系统可能先推理使用工具调用大语言模型描述那不勒斯的披萨特色，再推理使用工具进行健康食材的网页搜索，最后才推理调用食谱检索工具——前几步获得的信息将成为最终工具的可配置输入。这种步骤分解符合人类工作逻辑，由于使用的是我们更理解且更可控的工具，结果的可变性也会降低。虽然不能保证绝对成功，但智能体方式比非智能体更能让AI系统正确处理任务。

• 我们为智能体提供的工具可以弥补大语言模型的短板。记住：大语言模型是基于自然语言模式的随机系统，对非文本概念没有本质理解。大语言模型不擅长数学？我们可以添加计算器工具。不知道当前时间？添加系统时间工具。无法编译代码？添加构建工具。这样，推理模型（智能体世界中的大语言模型）本质上不需要懂得数学运算、报时或代码编译，只需判断何时该调用计算器、查询系统时间或尝试构建源代码，并能确定正确的工具输入参数。判断何时调用这些工具更具可操作性，且可以基于文本上下文实现。

• 工具不仅能提供文本响应，更能实际改变世界状态。比如在披萨案例中，假设我们希望AI将食谱发送给妹妹。如果智能体拥有访问通讯录和发送短信的工具，它就能进入工作循环：先推理获取食谱，再推理获取妹妹的联系方式，最后推理发送短信。前几步或许能用高级RAG实现，但最后一步呢？这种实际采取行动（而非仅生成文本）的能力，使智能体系统可能变得极其强大。

恭喜，你现在明白什么是智能体了！但关于”智能体”的讨论还需要更多背景知识让你游刃有余…

发展历程与当下契机

在介绍可用于深入讨论智能体系统的思维模型前，我们先简要回顾发展历程，并根据不同技术路线对基于AI的工具进行分类说明。我们将以软件工程领域为例，避免讨论过于抽象。

还记得几年前的世界吗？在生成式AI工具出现前，人类确实需要亲力亲为。这些工作可以表示为一系列动作的时间线。在软件工程中，可能包括在StackOverflow上搜索研究、运行终端命令、或是实际编写代码：

随着大语言模型的出现，我们开始获得能出色完成特定任务的系统。ChatGPT用于回答问题，GitHub Copilot用于自动补全几行代码^[3]等工具之所以能被信任，是因为它们同时满足两个关键条件：

• 解决用户痛点（例如：开发者厌恶编写模板代码，自动补全这类文本就极具价值）

• 技术可靠性达标（例如：大语言模型的能力足以稳健解决特定场景问题，用户若不满意自动补全建议，只需继续输入即可）

后者尤为关键。多年来，人们不断展示大语言模型处理复杂任务的惊艳演示，但多数仅停留在概念阶段——无法产品化并建立长期信任，导致预期与现实的割裂，最终陷入幻灭低谷。以「自动生成PR描述」为例：虽然能解决用户痛点（没人喜欢写PR说明），但用户对准确度的要求极高。一旦AI出错，用户便会永久回归手动检查文件并自行撰写描述，工具价值即刻归零。这类用例对技术稳健性的要求远超当前水平。

不过，尽管现有技术尚不完美，其进化速度却极快。终有一天，AI将能可靠地撰写PR描述——但这是后话。最初的技术应用边界，被我称为「副驾驶式」系统：通过单次调用大语言模型完成高度限定的任务（如响应提示或生成补全建议），且始终需要人类审核结果。这种设计规避了AI失控风险，核心挑战在于「幻觉问题」——模型因训练数据（互联网文本的普遍过度自信）和本质缺陷（终究只是复杂模式匹配算法）而输出虚假内容。

于是，更强大的检索增强生成（RAG）技术开始优化这类系统。简言之，RAG会先检索相关信息锚定用户查询，将检索结果与原始查询结合后输入大语言模型生成最终响应。这种「知识接入+限定任务」的模式定义了大语言模型应用的头两年——「副驾驶时代」：

这些非Agent式的副驾驶系统以稳定的输出质量创造了用户愿意长期信任的真实价值。但「智能体系统」的概念并非新事物。首个热门智能体框架AutoGPT^[4]早在2023年初ChatGPT发布后便已问世，其设计理念是让智能体自主运行循环，用户仅需提供初始指令并验收结果。本质上，由于这些系统能够调用工具并执行多次大语言模型交互，它们的运行时间更长，能完成比类Copilot系统范围更广的任务：

然而，尽管AutoGPT仍是有史以来最受欢迎的GitHub仓库之一，基于该框架构建的智能体并未真正普及。

一年后，Cognition公司推出了Devin，宣传其为能取代人类开发者的全功能AI程序员。

这同样是一个完全自主的智能体系统，配备了一些极其强大的工具，但至今仍只能解决相对简单的问题。

发生了什么？

如果智能体本应如此强大，为何用户主要从基于RAG的非智能体类Copilot系统中获得价值，而非这些智能体系统？

还记得”有价值的问题”与”技术足够成熟”的交集吗？

这正是这些自主智能体系统面临的普遍挑战。

虽然世界显然正朝着自主智能体的方向发展，但目前的大语言模型可能还不足以在完全无需人工干预或修正的情况下，端到端地完成这些复杂任务。

这一现实催生了一种新的智能体构建方法——其核心理念在于承认人类与智能体之间需要责任划分。

为区别于自主型智能体，我们将其称为协作型智能体，或简称为AI工作流^[5]。

具体实现上：

• 必须建立清晰的观察机制，让人类在执行过程中能监控工作流动向，以便在偏离轨道时及时纠正。

换言之，重新引入类Copilot系统中”人在回路”的协作特性。

• 这些工作流必须运行在人类原本的工作环境中。

多数自主智能体尝试由于独立于用户运行，其调用界面与用户手动操作的场景分离。

例如Devin通过网页调用，而开发者实际工作场景是IDE。

在智能体无所不能的理想世界里这或许可行，但脱离人类工作环境的自主系统将无法感知人工操作。

因此它们会丢失大量隐含上下文信息。

举例来说，若智能体存在于IDE中，它就能感知最近的手动编辑，从而隐式指导后续行动。

换言之，现实中必须实现双向观察：人类需要监控智能体行为，智能体也需要感知人类操作。

回到”有趣问题”与”成熟技术”的交集，协作型智能体对技术鲁棒性的要求远低于自主型智能体。

因为人类可以随时修正AI的中间步骤，审批关键操作（如终端命令执行），并实时审核变更。

这正是当前所有被验证有价值的可访问智能体应用采用的方案，包括Windsurf的Cascade^[6]、Cursor的Composer Agent以及GitHub Copilot Workspaces。在流程中，人与智能体始终基于同一世界状态协同运作：

我们如此大费周章地区分自主智能体与协作智能体，是因为它们本质上是构建”智能体化”系统的两种截然不同的路径。

人机协作程度不同、所需信任级别不同、交互方式各异…由于”智能体”一词被过度使用，人们常将自主智能体的构建与Windsurf的Cascade等智能体化系统混为一谈，实则二者存在根本差异。

如何解构”智能体化系统”

终于来到核心部分——我们将整合所有要点，提供一套快速检验清单，助您（a）理性分析关于”智能体”的讨论（b）提出直指技术本质的问题。这些问题每个都值得专文探讨，但我会先给出基础框架。

问题1：讨论的系统是否真正具备智能体特性？

显然，太多系统被误贴”智能体化”标签。当前LLM是作为工具调用推理模型使用吗？确实有工具被调用吗？还是仅在使用相同术语的思维链推理或其他技术？

问题2：系统属于自主型还是协作型？

该智能体系统设计为无需人工干预的自动化运作，还是能在工作流中自主执行多步骤、同时保持人机协作？若是前者，需追问：现有模型是否真能稳定处理目标数据与工具的规模复杂度？所谓自主智能体是否只是理论美好却难以落地？

问题3：智能体是否具备完整的能力要素？

这触及不同智能体实现（尤其是解决同类任务的协作智能体或流程）的核心差异。

问题3a：智能体拥有哪些工具？

不仅要列出工具，更要关注实现方式。例如Windsurf的Cascade采用独特的网页内容分块解析搜索技术。另外，自定义工具的便捷性如何？像Anthropic的模型上下文协议（MCP）正致力于标准化工具集成规范。

问题3b：采用何种推理模型？

关键要评估LLM的工具调用能力，而非其在常规任务基准测试的表现。擅长编程问答的模型未必能有效选择工具来解决编码任务。没有放之四海皆准的最佳LLM，虽然Claude 3.5 Sonnet在工具调用方面表现突出，但技术迭代极快。因此需考虑是否应赋予智能体多模型切换能力。

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

智能体能访问哪些数据源？在协作场景中是否遵循用户的权限控制？对于代码库，是仅能访问IDE当前签出的仓库，还是可跨仓库检索？后者在分布式开发中价值显著，但权限管理更为关键。总体而言，智能体化思维彻底改变了数据检索的范式——传统副驾式系统单次LLM调用只能做一次检索，导致RAG系统日趋复杂。

在具备自主性的智能体中，如果首次检索结果不佳，推理模型可以自主调整参数重新检索，如此循环直至确认已收集全部必要信息再采取行动——这种运作方式更接近人类的资料查阅行为。因此当讨论过度聚焦于RAG技术、数据解析和中间数据结构时，我们应当反思：在智能体主导的范式下，是否陷入了过度复杂化的陷阱？

（关于这一点后续还会展开…）

需要强调的是，面对结构化数据时，探究其处理逻辑依然必要。以代码库为例：借助抽象语法树(AST)解析等智能分块技术，能显著提升代码推理与检索工具的效能。值得注意的是，智能预处理与多轮检索并非互斥选项。

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

是否存在某些用户操作隐含的、永远不会显式表达的信号？虽然智能体无法捕捉茶水间的闲聊，但通过”读心术”般理解用户行为（如IDE中打开的标签页、文本编辑记录、终端命令、剪贴板内容等），往往能创造惊人的用户体验。这本质上是在降低使用门槛——若每次都需要用户详述本可自动推导的细节，其对AI产出的预期标准自然会水涨船高。

问题4：如何打造卓越的智能体用户体验？

除了结果质量，真正希望产品被用户采纳的开发者必须关注所有影响使用流畅度的体验维度。许多体验优化点看似非核心，却需要系统化思考：

问题4a：系统延迟如何？

假设两个智能体执行相同任务，一个耗时1小时，另一个仅需1分钟。在成功率相同的情况下，时间差异或许不重要；但若存在失败可能，用户必然倾向后者——快速失败能及时调整策略。延迟问题正是全自动智能体的主要瓶颈：当执行效率低于人工操作时，除非达成极高成功率，否则必然遭弃用。特别强调延迟有两大原因：其一，开发者常为提升质量盲目添加低效工具；其二，优化延迟涉及模型推理、提示词构造、工具并行化等全栈技术，需要专项人才攻坚。

问题4b：用户如何监督指导智能体？

这是协作型相较自主型的核心优势，但实现颇具挑战。例如当编程智能体需要跨文件多位置编辑时，如何设计比聊天窗口更高效的审查机制？再如特定场景的最佳实践往往需要人工调教，能否像Windsurf的Cascade那样，通过标签系统或自定义规则实现知识传递？让人类轻松赋能智能体，才能加速高质量产出。

问题4c：智能体如何与应用集成？

关键在于触发机制与输出利用的打磨。虽然ChatGPT让聊天窗口成为主流交互方式，但绝非唯一选择。以Cascade为例，既支持代码块解释按钮等轻量触发，也允许通过预览窗传递控制台日志/UI组件等非文本上下文。

问题4d：如何平衡智能与非智能体验？

并非所有场景都需要智能体介入。例如进行局部代码重构时，Command+Tab组合这类”副驾驶”模式反而更高效。新范式就像新锤子，但切记不是所有问题都是钉子！决策时不妨先问：这个任务真的需要构建智能体吗？

苦涩的教训

（最后还有重要提醒…）

我将这一点单独列出，是因为如果这篇文章中只有一个问题值得你深思，那便是：“我们是否正在重蹈‘苦涩教训’的覆辙？”

苦涩教训^[7]源自理查德·萨顿的同名文章，其核心观点（重新表述后）是：更多的算力、更多的数据，以及技术规模的持续扩大，终将催生出超越任何依赖人工定义结构或规则的系统。

这一规律已在多个领域得到验证：

• 计算机视觉中，CNN超越了手工设计的边缘和形状检测规则；

• 国际象棋、围棋等复杂游戏中，深度搜索和深度神经网络击败了所有基于规则的计算机系统；

• 就连大语言模型（LLMs）也延续了这一趋势，性能碾压所有“传统”NLP方法。

如今在智能体领域，我们再次面临遗忘“苦涩教训”的风险。

我们可能自以为更了解某个具体用例，于是耗费大量时间精心设计提示词、谨慎筛选工具子集，或尝试各种方法强行注入“人类知识”。但归根结底，这些模型将持续进化，算力会越来越廉价强大，而所有这些努力终将徒劳无功。

切勿落入“苦涩教训”的陷阱。

结语

以上就是全部内容！

你现在已经掌握了智能体系统的基础知识。

若想通过视频形式深入学习，并观看软件开发智能体的实际应用，可以参考我们与DeepLearning.ai团队合作开发的这门课程^[8]。