2025年AI产业深度报告：AI Agent的技术演进与产业洞察

1. AI Agent 浪潮初现：早期定义与发展

早期 Agent 的定义已强调其自主、社交、反应和主动的特性，奠定了 AI Agent 后 期的发展路径；传统 Agent 架构受限于硬件条件和预编程机制，仅具备有限的自 主性与对动态环境的适应能力，尚不具备当今 AI Agent 的生成、学习和环境感知 的“智能”。

1.1. Agent 的早期定义

Agent 的概念源于 1959 年约翰·麦卡锡提出的“建议接受者”（advice taker），其 核心是具备感知、推理与行动能力的常识性程序。1995 年，斯图尔特·罗素与彼 得·诺维格将其定义为“能通过传感器感知环境并以执行器作用于环境的任何事 物”。同年，伍尔德里奇与詹宁斯提出了强弱 Agent 的概念，其中 Agent 的“弱定 义”是相对普遍的用法，指任何具备某些基本属性的硬件或（更常见的）软件系 统。这些属性包括：自主性（autonomy）、社交能力（social ability）、反应性 （reactivity）和主动性（pro-activeness）。从概念上讲，这种 Agent 可以看作一个 自包含的、并发执行的软件进程，该定义也因其通用性而被广大学者接受，并成 为后来 AI Agent 技术应用的基础。

1.2. 传统 Agent 架构发展

在 20 世纪 70 到 90 年代，研究者提出了几种截然不同但影响深远的架构：审议式 （Deliberation）架构基于逻辑以及人类的理性，将智能决策过程建模为严谨的逻 辑推导；反应式（Reactive）架构从生物行为中汲取灵感，强调快速、鲁棒的应激 行为；混合架构则融合了这两种架构的优势。

1.2.1. 审议式架构：BDI 架构（Belief-Desire-Intention Architecture）

审议式架构，也被称为符号架构（Symbolic-based Architecture），是一种早期的智 能体设计方法，其核心思想是使用符号表示来建模环境和智能体的行为。该架构 建立在艾伦·纽厄尔和赫伯特·西蒙于 1975 年提出的物理符号系统假说之上，该 假说认为通用的智能行为源于物理符号系统。 审议式架构中最杰出的代表是“信念-愿望-意图”（BDI）架构。在该架构中，信念 是所有可能性的集合。而目标是对信念的第一次筛选，只保留期望的结果。意图 则是对目标的第二次筛选，锁定一个具体的、承诺要执行的计划。 在 BDI 架构下，Agent 能够像人类一样，在信念的基础上，从多个愿望中选择并 确定当前意图，然后执行相应的计划。这种架构适合需要进行长期规划、协商和 理性决策的复杂应用场景。

1.2.2. 反应式架构：包容架构（Subsumption Architecture）

与审议式架构的自上而下、基于模型的思想形成鲜明对比的是反应式架构。其中 最具代表性的是罗德尼·布鲁克斯于 1986 年提出的包容架构，该架构最初被应用 于机器人自动化领域的架构设计。布鲁克斯认为，将智能分解为“感知-规划-行动” 的串行功能模块是错误的，构建复杂的、中心化的世界模型是一条走不通的路。 包容架构的核心创新在于其分解方式：按任务达成的行为进行水平分解，形成一 个由多个能力递增的并行层级组成的控制系统，每一层都是一个自足的行为产生 系统。其中，最底层实现最基本的行为，如等级 0 的能力是“避免与物体接触”。 更高层则实现更复杂的行为，例如等级 1 的“随意漫游”或等级 2 的“探索世界”。

包容架构本质上是一种分布式设计，高层控制系统通过包容低层的角色来取得 控制权。这种机制允许多个目标并行处理，由抑制机制来协调最终采取的行动。 其结果是系统具有很高的鲁棒性：即使高层模块因故无法及时产生结果，底层 已经过充分调试的模块仍会继续运行，确保 Agent 能表现出基础但合理的行为。

1.2.3. 混合架构：Touring Machine 架构

审议式架构虽然具有远见，但反应迟缓且在意外情况面前显得脆弱；而反应式架 构虽然鲁棒且响应迅速，但行为短视，可能导致次优甚至有害的结果。认识到这 两种极端架构的局限性后，研究者开始探索将二者结合的混合架构，融合反应式 控制的鲁棒性和实时性，以及审议式规划的目标导向性和前瞻性。 Innes Ferguson 于 1992 年提出的的 Touring Machine 架构由三个并行运作、独立驱 动的控制层构成，为动态环境中的自主移动 Agent 提供所需的多样化行为能力。 其关键在于控制框架，通过一套“审查规则”（censor rules）和“压制规则” （suppressor rules）来协调不同层级提出的行动指令。这些规则充当过滤器，确 保在任何时间片内，只有一个行动指令被最终执行。这种机制使得 Agent 能够根 据当前情境和任务需求，在审议式和反应式行为之间进行动态切换，从而兼具两 者的优点。

1.2.4. 传统 Agent 架构对比

BDI 与包容架构之间的争论，不仅是技术实现上的差异，更反映了关于 Agent 智 能本质的哲学差异：BDI 架构认为智能是对符号表征进行逻辑推演的过程，而包 容架构认为智能是系统与环境交互的产物。Touring Machine 为代表的混合架构， 是技术上的折衷，但也让研究者认识到，一个完整的 Agent 既需要审议式的前瞻 性，也需要反应式的现实根基。

1.3. 传统 Agent 架构的局限性

传统 Agent 架构的发展，普遍受限于由硬件性能与静态预编程共同构成的系统性 困境：主流硬件 CPU 不擅长处理大规模复杂并行任务，内存发展速度不及 CPU 导致“内存墙”现象；依赖预编程行为，而非学习驱动与情境感知能力，而无法 适应动态环境。 1) 硬件桎梏：CPU 不擅长处理复杂并行指令，且内存发展速度不及 CPU。传 统 Agent 架构的发展，其制约因素之一在于当时的硬件资源限制。彼时的主 流硬件是 CPU，其串行指令处理特性（一次仅能执行单条指令）使基于推理 循环的 BDI 架构成为了主流。此外，20 世纪 90 年代的“内存墙”现象揭示 了处理器与内存子系统发展的严重失衡：处理器性能呈指数级提升，而内存 带宽和延迟的改善却相对缓慢。这种限制使得决策过程耗时过长，难以适应 动态变化的环境需求。 2) 知识更新：静态预编程行为难以实现动态知识更新。传统 Agent 架构，最核 心的局限性在于对预编程行为的依赖。其行为逻辑和计划通常由开发者根据 专家知识预先设计和硬编码。这种方法假定可以为 Agent 面临的大多数情况 预先制定解决方案。然而，这种预设行为的僵化特性使其难以应对复杂、动 态且不可预测的真实世界。

2. AI Agent 现代范式：大语言模型塑造 LLM-based Agent 和 LLM-MAS

LLM 重塑 AI Agent 范式，大语言模型智能体（LLM-based Agent）成为当下 AI Agent 的主流；其组成包括认知和决策核心的大脑（LLM）模块、多模态感知模 块和执行决策的行动模块。大语言模型多智能体系统（LLM-based Multi-Agent Systems, LLM-MAS）的诞生旨在解决复杂多任务处理的难题，其多样性源于编排 方式、通信结构、协作类型和策略的不同组合；行业内头部企业针对 LLM-MAS 不同层级开发相应的交互协议，其中 MCP 已被广泛应用。

2.1. LLM 革命性突破与现代 AI Agent 的定义

2017 年谷歌大脑（Google Brain）团队提出的 Transformer 架构彻底打破了传统架 构的循环结构。首次引入了一种完全摒弃循环结构的架构，核心在于自注意力机 制。该机制使模型在处理任意词时，能并行计算序列中所有词对该词的重要性权 重，从而直接建模长距离依赖关系。这种高度并行化的计算范式显著提升了训练效率，成为后续绝大部分 LLM 的基础架构。这一架构成为了现代 LLM 的核心基 石，也催生了现代 LLM-based Agent 的诞生。 目前业界讨论的 AI Agent 主要是 LLM-based Agent，其定义主要由大型科技公司 及头部 AI 初创企业塑造，包括谷歌、微软等巨头，以及 OpenAI、Anthropic、深 度求索（DeepSeek）等以 LLM 开发为主的独角兽企业。虽然各家企业定义具体表 述存在差异，但产业界已形成核心共识，即 AI Agent 应具备自主规划决策、环境 感知及工具调用能力。这些定义依然继承了 Agent 的早期“弱定义”中自主性、 社交能力等特性，但同时也强调了 LLM-based Agent 独特的部分，如工具使用、 记忆、决策能力等。

2.2. LLM-based Agent 的核心组件

自 2022 年 ChatGPT 3.5 发布以来，AI 领域经历了一场前所未有的范式转变。LLM 的崛起，重塑了 AI Agent 的架构设计。LLM 时代的架构核心在于如何控制和编 排强大的通用智能。LLM 不仅是系统的一个组件，而是成为了整个 AI Agent 的 认知核心，这一范式转变也催生出一种全新的 AI Agent：LLM-based Agent。 LLM-based Agent 是能够感知环境、进行自主决策并执行任务以实现特定目标的 智能体。其核心架构可以分为几个协同工作的基本模块，这些模块共同构成了一 个类似人类的认知循环： 1) 大脑（Brain）：作为系统的认知核心，通常由一个或多个 LLM 构成。它负责 处理信息、进行推理与规划、存储知识与记忆，并做出最终决策。 2) 感知（Perception）：相当于智能体的感觉器官，使其能够接收并处理来自外 部环境的多模态信息，如文本、图像、音频及其他传感器数据，从而超越纯 文本交互的局限。3) 行动（Action）：作为智能体与环境交互的执行器，它将大脑的决策转化为具 体输出。这些行动不仅限于生成文本，还包括使用外部工具、调用 API 或在 物理世界中执行具体操作。

2.2.1. 大脑：Agent 的认知与决策核心

大脑是 LLM 智能体的中央处理器，负责所有高级认知功能，确保智能体能够以智 能、连贯且目标导向的方式行事。其内部结构主要可分为画像定义、记忆机制和 规划能力三大关键组件。

2.2.1.1.画像定义（Profile Definition）

画像定义模块负责塑造智能体的身份、角色和行为模式，是其所有后续决策和互 动的基础。这一个性化的设定直接影响智能体在特定场景下的表现，确保其行为 与预设目标保持一致。实现画像定义主要有以下几种技术策略： 1) 人工策划静态画像：由领域专家通过提示工程（Prompt Engineering）等方 式，手动为 Agent 编写详细的角色描述、规则和特定领域的知识。这种方法 可以确保智能体在需要高度一致性和可解释性的任务中（如模拟软件开发流 程）表现稳定。例如，在 ChatDev 和 MetaGPT 等框架中，系统通过为智能体 分配程序员、产品经理等预设角色，并规定它们之间的互动协议，来协调完 成复杂的软件开发任务。 2) 批量生成动态画像：利用 LLM 本身的能力，通过参数化初始化或基于模板 的提示，批量生成具有多样化个性特征、知识背景和价值观的 Agent 画像。这种方法对于模拟复杂的人类社会行为或生成大规模的模拟用户数据至关重 要，因为它能创造出具有统计多样性的智能体群体。

2.2.1.2.记忆机制（Memory Mechanism）

为了确保行为的连贯性和实现长期学习，Agent 必须具备有效的记忆机制来存储 和调用历史信息。面对 LLM 有限的上下文窗口，已经开发了多种记忆架构和技 术。其核心功能是存储智能体过去的观察、思考和行动序列，并在需要时提取相 关信息以指导当前决策，通常涉及记忆的写入、读取（检索）和反思。 记忆结构： 1) 短期记忆（STM）：通常通过“上下文学习”（In-context Learning）来实现， 将最近的交互历史和环境反馈直接置于 LLM 的提示中。这种记忆是短暂的， 主要用于处理即时任务，但会受限于上下文窗口的长度。 2) 长期记忆（LTM）：为了实现持久化存储，智能体通常会借助外部知识库，如 向量数据库。过去的经验和知识被编码为向量并存储起来，以便在需要时快 速检索。 3) 混合记忆：大多数先进的智能体采用混合记忆结构，结合了短期记忆的即时 性和长期记忆的持久性，从而实现更强大的长期推理和经验积累能力。 实现技术： 1) 检索增强生成（RAG）：这是实现记忆检索的关键技术。当智能体需要回忆信 息时，它会使用当前任务作为查询，从外部向量数据库中检索最相关的记忆 片段，并将其整合到提示中以生成更精准的响应。 2) 记忆格式：记忆的存储格式多种多样，可以是原始的自然语言文本、高效检 索的嵌入向量、结构化的数据库（通过 SQL 等语言操作），或是层次化的列 表。 3) 记忆反思：这是一种更高级的记忆操作，智能体能够自主地总结、归纳过去 的零散经验，形成更高层次的抽象见解或可复用的技能。例如，Generative Agents 框架中的智能体能够通过反思日常观察，提炼出关于其他智能体性格 特征的深刻洞见。

2.2.1.3.规划能力（Planning Capability）

规划能力是 Agent 智能的核心体现，它使智能体能够将复杂、模糊的长期目标分 解为一系列清晰、可执行的子任务。其流程为先分析目标，然后制定行动蓝图。 这一过程可以是有反馈的动态迭代，也可以是一次性生成静态计划。 静态规划： 1) 思维链（Chain of Thought, CoT）：这是一种典型的单路径规划技术，通过在 提示中展示一步步的推理过程，引导 LLM 模仿这种逻辑链条来解决问题。 “Zero-shot-CoT”则更进一步，仅用一句简单的指令（如“让我们一步步思 考”）就能激发模型的推理能力。 2) 思维树（Tree of Thoughts, ToT）：相较于 CoT 的线性推理，ToT 允许智能体 在每个决策节点探索多个可能的后续步骤，形成树状的推理结构。智能体会 评估每个分支的优劣，并可以进行回溯，从而在复杂的解空间中找到更优的 路径。

反馈驱动的动态规划：在动态环境中，仅有静态计划是不够的。智能体需要根据 执行行动后收到的反馈来不断修正其计划： 1) ReAct 框架：该框架将“思考”（Reason）和“行动”（Act）相结合，形成“思 考-行动-观察”的循环。智能体根据行动后从环境中得到的观察结果（如 API 返回、网页内容变化）来调整其下一步的思考和行动，实现动态适应。 2) 自我修正（Self-Refine）：智能体可以利用 LLM 本身进行“模型反馈”，即让 一个 LLM 实例（或其自身）评估并修正另一个 LLM 实例生成的计划或输出。 这种自我迭代的能力极大地提升了规划的鲁棒性和准确性。 3) 外部规划器（External Planner）：对于需要高度专业化或最优规划能力的领 域，Agent 可以将问题转化为形式化语言，并调用外部的专业规划求解器来 生成行动序列。 ReAct 与 ToT 对比：ReAct 和 ToT 都是增强大型语言模型解决复杂问题能力的先 进框架，但它们的策略截然不同。ReAct 的核心在于将推理（Reason）与行动（Act） 相结合，通过一个线性的迭代循环来工作：模型先生成“思考”来规划步骤，然 后执行一个“行动”来与外部环境互动，最后接收“观察”到的结果以指导下一 步思考。这种模式使 ReAct 能够获取并整合外部世界的实时、准确信息，极大地 减少了事实性错误和内容幻觉，特别适用于需要事实依据的知识密集型任务，如 问答和事实核查。 ToT 则专注于模型内部的思考和规划。它将问题求解过程构建为一棵“思想树”， 而不是单一的思路链。在树的每个节点，ToT 会生成多个并行的候选“思想”或 解决方案路径。接着，它利用语言模型自身进行“自我评估”，为这些路径打分， 并结合广度优先（BFS）或深度优先（DFS）等搜索算法来决定探索哪个最有希望 的分支，甚至可以在发现此路不通时进行回溯。这种系统性的探索、前瞻和回溯 能力，使得 ToT 在解决需要复杂规划、策略性或搜索的任务（如 24 点游戏、创 意写作）时，表现远超传统方法。

2.2.2. 感知：Agent 与世界的接口

感知模块赋予 Agent 超越纯文本的理解能力，使其能够接收并处理来自物理世界 或数字环境的视觉、听觉等多种模态的信息。工作流程通常是先接收原始感官数 据，然后使用专门的编码器处理，最后将编码结果对齐到 LLM 的嵌入空间。 实现技术： 1) 视觉输入：为了让智能体“看见”世界，研究人员采用了多种技术。最初的 方法是图像描述（Image Captioning），即将图像转化为文本描述。然而，这种 方法会丢失大量视觉细节。更先进的方法是使用视觉编码器（Visual Encoder）， 如 Vision Transformer（ViT），将图像直接编码为向量。为了将视觉编码器的 输出与 LLM 对齐，通常会引入一个可学习的接口层。例如，BLIP-2 模型使 用了一个名为 Q-Former（Querying Transformer）的模块来提取与语言相关的 视觉特征，而其他模型则采用更简单的线性投影层。 2) 听觉输入：智能体的听觉能力可以通过两种主要方式实现。一种是级联方式， 即利用 LLM 作为总控中心，调用现有的成熟音频处理模型（如用于语音识别 的 Whisper）来处理音频数据。另一种方法则借鉴了视觉处理的思路，将音频 信号转换为音频频谱图（Audio Spectrogram），并将其作为二维图像输入给类 似 ViT 的架构进行处理。

2.2.3. 行动：Agent 影响世界的手段

行动模块是智能体将其内部决策转化为外部影响的最终环节，是智能体与环境互 动的物理或数字“肢体”，负责执行大脑规划好的任务，其输出形式可以是生成文 本、调用工具或执行物理动作。具体主要通过以下方式实现： 1) 函数调用（Function Calling）：函数调用是 LLM 与外部工具交互的核心机 制。模型会分析用户输入并预定义的工具列表，决策是否需要调用工具。若 需调用，LLM 不直接回答，而是输出一个包含目标函数及参数的结构化指令。 该指令由外部系统在模型之外执行，其执行结果将在第二次调用时被返回给 LLM。最终，LLM 整合这次返回的真实数据，生成一段完整的自然语言回复。 整个流程构成了“决策-执行-整合”的技术闭环，是 LLM 调用外部能力解决 复杂问题的关键。2) 调用外部 API：Agent 可以调用各类 API，如搜索引擎（WebGPT）、计算器、 代码解释器或与其他软件交互的 RESTful API。通过策略性地调用外部 API， LLM-based Agent 能够获得原生模型不具备的感知、计算与执行能力，显著提 升任务解决范围与可靠性。 3) 具身行动（Embodied Action）：在模拟环境（如游戏）或物理世界（如机器 人）中执行的动作。在这种场景下，LLM 通常扮演高层规划者的角色，将复 杂指令分解为机器人可以执行的低层技能命令。例如，SayCan 模型将语言模 型的知识与机器人的物理能力（“我能做什么”）相结合，实现了更符合物理 规律的行动决策；Voyager 项目则展示了智能体在《我的世界》这样的开放世 界中，通过 LLM 驱动的迭代探索和技能库积累，实现终身学习的能力。

2.3. LLM-MAS 解析

LLM-based Agent 通过 LLM 作为核心的“大脑”，集成感知、记忆和行动等模块， 能够自主地与环境交互并执行任务，在推理和决策方面表现出强大的能力，但在 处理需要集体智慧或大规模协调的复杂动态任务时，则有一定局限性。 为了应对这一局限性，大语言模型多智能体系统（LLM-MAS，Multi-Agent Systems） 随之出现。LLM-MAS 是一个由多个相互作用的 LLM-based Agent 组成的计算系 统，它通过让多个专业化的 Agent 进行协作或竞争，来解决远超单个 Agent 能力 范围的复杂问题。这种从独立的个体智能向协作式的集体智能的转变，不仅更精 确地模拟了现实世界中多决策者共存的场景，还通过任务分解、角色专业化和信 息共享，提升了系统的稳健性、灵活性和整体性能。

2.3.1. LLM-MAS 的核心机制

为了使多个 Agent 能够高效地协同工作，LLM-MAS 依赖于一套复杂而精细的核 心机制，主要包括编排架构、通信结构、协作类型以及协作策略。编排 （Orchestration）是最高层次的控制机制，它决定了协作流程的宏观组织方式， 即这个流程是静态的还是动态的。在编排方式的治理下，一个具体的协作场景或 “协作通道”必须由三个基本支柱共同定义： 1) 通信结构（Communication Structure）：定义 Agent 之间信息流动的网络拓 扑，是协作的物理或逻辑骨架。2) 协作类型（Collaboration Type）：定义 Agent 互动的根本目标或意图，是协 作的内在驱动力。 3) 协作策略（Collaboration Strategy）：定义 Agent 在互动中应遵循的行为准则 或协议，是协作的具体执行规则。

2.3.1.1.编排

编排是最高层次的机制，它定义了协作渠道如何被创建、排序和管理，是整个 LLM-MAS 互动的主干。LLM-MAS 的编排方式主要有两种： 1) 静态编排（Static）：协作渠道和工作流是预先定义好的，通常基于领域知识 来优化系统性能。例如，通过顺序链接多个 Agent 来形成一个固定的处理管 道，前一个 Agent 的输出作为后一个的输入。 2) 动态编排（Dynamic）：系统能够根据任务需求和环境变化实时调整角色分配 和协作渠道。通常会有一个“管理 Agent”或“编排器”，它能够动态地构建 协作图（如 DAG），并根据任务依赖关系来安排 Agent 的并行或顺序执行。 这种架构适应性强，能够有效处理复杂多变的任务。

2.3.1.2.通信结构

通信是 LLM-MAS 的基础，智能体通过标准的通信语言进行互动。这些互动发生 在特定的协作通道中，通道决定了信息的交换方式。一个协作通道由其参与的智 能体、协作类型、策略和通信结构共同定义。有效的通信机制确保了智能体能够 清晰、无误地理解彼此的意图和信息，这是实现任何形式协作的前提。通信结构 定义了信息在 Agent 之间如何流动，塑造了系统的高层设计和微观互动模式。 LLM-MAS 的通信结构主要有四种： 1) 中心化结构（Centralized）：所有 Agent 都与一个中心 Agent（或称为协调器、 聚合器）连接，由该中心 Agent 管理和控制所有通信与协作。这种星型结构 简单易于实现，但中心节点可能成为瓶颈或单点故障源。 2) 去中心化/分布式结构（Decentralized/Distributed）：Agent 之间以点对点的方 式直接通信，没有中心控制节点。这种结构（如全连接的图结构或环形结构） 具有高稳健性和灵活性，但可能会带来较高的通信开销和协调难度。 3) 层级结构（Hierarchical）：Agent 被组织成一个树状或分层的系统，上层 Agent 负责监督和协调下层 Agent。这种结构适用于需要角色专业化和明确指挥链 的复杂任务，例如一个高级项目经理 Agent 管理下属的设计、编码和测试 Agent。 4) 混合结构（Hybrid）：结合了多种结构的特点，以适应更复杂和灵活的问题解 决场景。例如，系统可能在顶层采用层级控制，而在各个子团队内部采用去 中心化的点对点协作。

2.3.1.3.协作类型

协作是 LLM-MAS 的核心理念，它使得多个智能体能够朝着共同的目标努力。协 作机制可以发生在不同阶段，从早期的共享数据和环境，到中期的共享模型参数， 再到后期的共享任务输出。为了管理协作，系统需要协调与编排机制。这些机制 可以是静态的，即根据预定义的规则和领域知识来设定协作通道；也可以是动态 的，即系统能够根据任务需求和环境变化实时调整角色和协作方式。 协作类型定义了 Agent 之间为何要进行通信和互动，这决定了系统的基本动态和 行为模式： 1) 竞争（Competition）：当 Agent 拥有相互冲突的目标或需要争夺有限资源时， 就会出现竞争关系。在这种模式下，每个 Agent 都优先考虑自身利益最大化。 竞争可以激发 Agent 发展出更高级的策略和更具创造性的解决方案，例如在 模拟辩论或战略游戏中，Agent 需要不断适应对手的策略来获胜。 2) 合作（Cooperation）：最常见的协作类型，所有 Agent 为了一个共同的、互利 的目标而协同工作。例如，在软件开发中，扮演“程序员”、“测试员”、“设 计师”等不同角色的 Agent 各司其职，共同完成项目。合作可以是直接的， 也可以是通过辩论的方式，即 Agent 通过批判性对话来审视不同观点，最终 达成更优的解决方案。 3) 竞合（Coopetition）：合作与竞争的混合体。Agent 可能在某些子任务上进行 合作，以实现共同利益，同时在其他方面展开竞争。这种模式在模拟谈判场 景中尤为常见，Agent 需要在维护自身利益和达成互利协议之间寻找平衡。

2.3.1.4.协作策略

协作策略规定了 Agent 在互动中应遵循的具体行为准则或协议，主要有三种： 1) 基于规则（Rule-based）：Agent 的互动严格遵循预定义的规则，确保其行为 的可预测性和一致性。这种策略高效且易于实现，但适应性较差，难以应对 规则之外的突发情况。 2) 基于角色（Role-based）：为每个 Agent 分配明确的角色和职责，使其在特定 领域内发挥专长。例如，在 MetaGPT 框架中，通过为 Agent 编码标准操作流 程（SOPs），使其像在流水线上一样高效协作。这种策略有利于任务的模块化 和专业化，但对角色定义的准确性要求很高。 3) 基于模型（Model-based）：Agent 基于对环境、共享目标和不确定性的概率性 推断来进行决策。这种策略赋予 Agent 高度的灵活性和鲁棒性，使其能够适 应动态变化的环境，但实现起来也最为复杂和计算密集。

2.3.2. LLM-MAS 的核心协议

从单 Agent 到复杂的 LLM-MAS，AI Agent 对协作的要求逐渐增加，但也暴露了 一个核心瓶颈：缺乏通信标准。在缺乏统一标准的世界里，由不同技术框架、不 同厂商构建的智能体如同沟通不畅的技术孤岛，无法互通有无，其协同工作的巨 大潜能被严重制约。 为打破这些壁垒，各大厂商推出了实现标准化交互的 AI Agent 协议。这些协议功 能互补、层次分明，解决了从底层到顶层的全链路通信问题。其中，MCP 负责打 通智能体与外部工具的连接，是能力调用的基础；A2A 与 ACP 则分别为云端和 边缘的智能体们提供了标准化的“对话”语言，实现了 Agent 之间的协作；而 AGUI 架起了 Agent 与前端用户界面之间的实时桥梁，优化了人机交互体验。

2.3.2.1.MCP：为大模型交互设定上下文标准的开放协议

由 Anthropic 公司发起并开源的“模型上下文协议”（Model Context Protocol，简 称 MCP），为 AI 应用向 LLM 提供上下文信息建立了统一的开放标准。其核心目 标是创建一个如同“AI 应用的 USB-C 端口”的通用规范，让 AI 模型能够安全、可 靠地连接到多样化的数据源和工具，从而生成更精准、更具相关性的回应。 1) MCP 的定位：专注模型上下文的“最后一公里”。MCP 专注于解决 AI 模型 与外部世界（如文件、数据库、API 等）连接时的标准化问题。作为 Agent 之 间通信协议的补充，MCP 专门处理 Agent 执行任务时，如何获取和理解所需 背景信息这一关键环节。通过提供一个标准化的“插座”，让开发者不必为每 个模型或数据源单独开发集成方案，简化了构建复杂工作流的难度。

2) 核心机制：基于客户端-服务器架构的安全双向连接。MCP 协议的核心是其 “客户端（Client）-服务器（Server）”架构。应用程序（如 AI 助手、IDE 插 件）作为“MCP 主机（Host）”，通过该协议连接到一个或多个“MCP 服务 器”。这些服务器则负责安全地访问本地数据源（如电脑文件）或远程服务（如 企业内部 API、网络服务）。整个过程实现了安全的双向通信：应用不仅能向 模型注入上下文，模型也能通过协议调用外部工具或从服务器请求数据。

3) 生态与愿景：构建开放、可互操作的 AI 数据生态。MCP 作为一个开放标准， 正迅速获得行业巨头的采纳，其生态系统已从单一工具扩展至大型企业平台。 Salesforce 已宣布其 Agentforce 平台将原生支持 MCP，吸引了包括 AWS、Google Cloud、IBM、PayPal、Cisco、Notion 在内的超 30 家行业领导者；同 时，Anthropic 官方认证的核心工具集成也在不断增加，用户已可以通过 MCP 将 Claude 无缝连接到 Atlassian（Jira, Confluence）、Notion 和 PayPal 等关键 生产力工具。

2.3.2.2.A2A 协议：打破异构智能体壁垒的开放通信标准。

谷歌（Google）推出的 Agent2Agent（A2A）协议，旨在实现异构、不透明智能体 应用之间的通信和互操作性。其核心目标是为 AI Agent 提供一种通用语言，使它 们能够无缝协作，而无关其底层框架、供应商或服务器实现。 1) A2A 与 MCP：水平协调与垂直整合的分层协作。A2A 协议和 MCP 是互补的 框架，它们在 AI 交互堆栈的不同层面上运作，共同参与构建复杂的智能体系 统。MCP 专注于智能体与外部工具、API 和数据源的连接方式；A2A 则专注 于标准化独立的 AI Agent 之间如何作为对等方进行水平协调，为 Agent 发现 彼此、协商交互模式、管理共享任务以及交换上下文或复杂结果提供了一个 应用级协议。

2) 核心机制：基于“智能体卡片”发现与不透明执行的安全协作流。A2A 协议的 核心优势在于其强大的互操作性、对复杂工作流的支持以及企业级的安全保 障。通过开放标准（HTTP 上的 JSON-RPC）和“智能体卡片（Agent Card）” 机制，允许基于不同平台（如 LangGraph, CrewAI）构建的 Agent 发现彼此并 无缝连接。在工作流程上，客户端智能体首先通过获取服务器 Agent 的“智能 体卡片”来发现其能力与端点，随后发起任务请求。协议原生支持同步请求、 用于实时更新的流式传输（SSE）以及用于长时间任务的异步推送通知，以适 应不同复杂度的任务需求。整个交互过程遵循“不透明执行”原则，Agent 协作 时无需暴露内部逻辑或专有数据，结合内置的认证授权机制，有效保护了知 识产权并增强了系统安全性。

3) 生态支持及应用场景。A2A 协议自推出以来获得了广泛的行业支持。该项目 由谷歌发起，并已捐赠给 Linux 基金会进行开放治理，吸引了超过 100 家技 术公司和合作伙伴的支持。主要参与者和贡献者包括 AWS、微软、Salesforce、 SAP、ServiceNow、Atlassian、思科（Cisco）、MongoDB、PayPal 和 Workday等行业巨头。这种广泛的生态系统支持确保了其作为跨平台标准的快速发展 和采纳。

2.3.2.3.ACP 协议：为本地与边缘设备打造的低延迟自主通信框架

ACP（Agent Communication Protocol）是旨在实现本地和边缘环境中多智能体高 效、自主协作的开放协议。该协议由 IBM Research 及 BeeAI 社区推动，其设计核 心是提供一个轻量级、低延迟且不依赖云端的通信标准，尤其适用于对隐私安全、 网络带宽和资源消耗有严格要求的场景，如物联网（IoT）、机器人集群及嵌入式 设备等。 1) ACP 与 A2A：边缘自主与云端互联。ACP 和 A2A 代表了多智能体通信领域 的两种主流技术路线：“本地/边缘自主”与“跨平台互操作性”。二者的核心 区别在于设计哲学与应用场景的侧重。A2A 由谷歌领导，专为云原生和大规 模分布式环境设计，强调跨厂商、跨平台的强大互操作能力和丰富的任务协 作机制。而 ACP 则优先考虑本地部署和边缘计算，其核心优势在于低延迟、 低资源消耗和云端独立性，允许 Agent 在无网络或网络不佳的环境中实现自 主发现与通信。 2) 核心机制：基于事件驱动与 RESTful 架构的灵活通信。ACP 的核心架构是 事件驱动和去中心化的，它通过一个标准化的 RESTful API 来暴露智能体的 能力。这使得智能体之间的集成变得非常简单，甚至可以直接使用 curl 等标 准 HTTP 工具进行交互。该协议支持多种通信机制，包括 RESTful HTTP、 gRPC、ZeroMQ 和本地总线等，赋予开发者根据实际需求灵活定制和扩展通 信层的能力。在工作流程上，ACP 客户端可以向托管一个或多个智 Agent 的 ACP 服务器发出请求，服务器根据 Agent 元数据将任务路由至合适的智能体 执行，并以标准化的格式返回结果，整个过程实现了高效的本地自主协作。 3) 生态支持及应用场景。ACP 协议主要由 IBM Research 和 BeeAI 社区驱动， 其参考实现与核心应用场景集中在 BeeAI 平台、机器人技术和边缘 AI 领域。 作为一个开放标准，它正在积极吸引来自开源社区和学术界的贡献者。该协 议特别适用于需要本地化、低延迟和高隐私保护的多智能体系统，例如在物 联网（IoT）与机器人集群中，其本地优先的特性可确保设备在离线状态下也 能自主协作；在金融、医疗等隐私敏感环境中，其云端独立的部署能力满足 了严格的合规要求。此外，通过“路由代理”（Router Agent）等组合模式， ACP 还能实现复杂的任务分解与多智能体协同，提升任务执行效率。

2.3.2.4.AG-UI 协议：连接前端与智能体的轻量级实时交互桥梁

AG-UI（Agent User Interaction Protocol）是一个开放协议，旨在充当前端应用与 AIAgent 之间的通用桥梁，以标准化它们之间的交互。它通过轻量级、事件驱动 的架构，专注于解决需要实时通信、状态同步和人机协作的复杂 AI 工作流程中的 通信难题，让任何前端都能轻松地与用不同框架（如 LangGraph, CrewAI 等）构 建的 AI Agent 进行顺畅集成。

1) AG-UI 在协议栈中的角色：专注于智能体与用户界面的顶层交互。AG-UI 专 注于处理前端用户界面与 AI 智能体之间的交互层，而 A2A 协议负责处理不 同 AI 智能体之间的通信，MCP 则管理模型与上下文的交互。因此，AG-UI 是在这个 AI 智能体生态系统中，通过与 A2A 和 MCP 等其他协议协同工作， 共同完善和增强整体架构的功能，各自负责不同层面的通信和数据处理。

2) AG-UI 核心机制：通过事件驱动与流式更新实现动态人机协作。AG-UI 协议 通过提供一个开放、轻量级的标准，简化了 Agent 与用户界面的集成。其核 心特性在于采用事件驱动架构，通过流式传输标准化的 JSON 事件来统一通 信方式，并兼容 LangGraph、CrewAI、LlamaIndex 等多种主流 Agent 框架。 工作流程上，当用户在前端应用中进行操作时，客户端会向 Agent 端点发出 请求；Agent 在执行任务时，会持续发出一系列定义清晰的事件流（如文本生 成、工具调用开始/结束等），客户端则监听这些事件并实时更新 UI。这种机 制不仅能将语言模型增量生成的内容即时呈现在界面上，避免了延迟，还能 通过仅发送状态变化的“补丁”来高效同步共享数据，从而实现了 Agent 与用 户之间流畅、动态的实时协作。

3) 生态支持及应用场景。AG-UI 协议由 CopilotKit 社区及领先的智能体框架合 作开发，获得了多个流行 AI 开发框架的官方支持和集成，例如 LlamaIndex、 LangGraph、CrewAI 和 Mastra 等都已提供集成支持或演示。作为一个开放标 准，它正被更多社区和工具采纳，以促进前端与 AI 后端之间更加标准化的协 作。该协议特别适用于需要 AI 与用户进行实时、动态交互的场景。例如，它 能支持 AI 辅助编程中的代码实时生成、商业智能仪表盘中根据用户自然语 言提问动态展示分析过程与可视化结果，或是在复杂工作流中让用户介入决策（人机协作），从而打造响应迅速且体验流畅的智能化应用。

3. AI Agent 的产业链解构

AI Agent 的产业链正迅速形成由上、中、下游构成的完整生态；AI Agent 开源框 架和商业开发平台面向不同用户，降低了 AI Agent 开发门槛；下游应用呈现出两 大类别：一是自主完成复杂多任务的通用型 AI Agent，二是在专业领域深耕的垂 直 AI Agent。前者由于 LLM 能力的限制目前尚不够成熟，后者通过与行业知识 和工作流的深度融合，已展现出巨大的商业价值和变革潜力。

3.1. AI Agent 产业链结构概览

AI Agent 作为重塑数字交互与生产力的新范式，背后庞大复杂的产业链正快速成 型。结合其核心技术堆栈，可将这条产业链解构为上、中、下三个核心环节：上 游提供交互协议和接口以及作为 Agent“大脑”的基础大模型的核心技术；中游 负责提供开发框架和部署平台；下游则是直接面向消费者或企业，提供具体场景 解决方案的终端应用与服务层。此外，在上游大模型的开发层面，还需要算力和 数据提供商为其提供支持。AI Agent 产业链每层之间连接紧密且呈现出以下几个 特点：

首先，大型科技企业凭借资金、技术、数据和生态方面的优势，在产业链的多个 环节均有深度布局，形成了极强的垂直整合能力。以谷歌为例，其整合路径清晰 地贯穿了上下游：上游自研 TPU 系列芯片提供核心算力，开发视觉模型（ViT）， 推出基础大模型 Gemini 系列，并联合业界探索 A2A 等交互协议以图建立生态标 准；中游通过 Vertex AI Studio 平台提供 Agent 构建的一站式工具链；最终，这些 技术能力在下游催生出如 Gemini Deep Research、Project Astra 等 AI Agent 应用原 型，展示了其整合生态的强大实力。 其次，上游基础大模型迭代速度快，各厂商竞争激烈，AI 头部企业抢先制定 AI Agent 交互协议。构成 AI Agent“大脑”的基础大模型竞争激烈，因为领先的 LLM 直接决定了 AI Agent 的能力。这其中包括大型科技公司（如 Google，Meta，阿里巴巴，腾讯等）和新兴独角兽企业（如 OpenAI，Anthropic，xAI，DeepSeek，月 之暗面等）。在决定 Agent 之间如何沟通协作的交互协议方面，领导者主要是 Anthropic（MCP）、谷歌（A2A）等国外厂商。当前正处于抢占下一代 AI Agent 应 用入口和通信协议标准的关键节点；交互协议成为事实标准，就能吸引更多的开 发者、建立更强的生态壁垒，并最终定义未来 AI Agent 应用的基础设施层；这对 于企业和国家在 AI Agent 时代的生态话语权具有重大的战略意义。 再次，中游开发框架与开发平台的并行发展，显著降低了 AI Agent 的开发门槛。 在开发框架层面，以 LlamaIndex、AutoGen 等为代表的开源框架，基于不同设计 理念，为开发者提供了灵活的构建工具。在开发平台层面，呈现开源与闭源两种 面向不同用户的发展格局，既有 Dify、Langflow 这样开放、可定制的开源平台， 也有微软 Copilot Studio、阿里云百炼、字节 Coze 等背靠巨头生态、提供一站式便 利的商业化平台。这反映了不同类型的用户（大型企业、中小型企业、个人开发 者）背后对生产力解放的大量需求。 最后，下游应用端展现出巨大的商业潜力，但整体市场尚不成熟。通用型 AI Agent 产品开始落地但仍不够成熟，其产品形态的差异反映了厂商探索人机交互方式上 的哲学差异；垂直领域 AI Agent 应用需要深度的行业知识（Know-how）和高质量 的专有数据，对数据质量和应用稳定性要求高，商业价值更为清晰，目前已在法 律、金融、医疗等领域开始应用；这预示着 AI Agent 应用端的未来发展，将是在 通用能力持续突破的同时，向各个垂直行业深度渗透和赋能的过程。

3.2. AI Agent 开发框架

LLM 增强了 AI Agent 的核心能力，海量的 API 拓展了 AI Agent 的外部能力，但 完整搭建一个 AI Agent 工作却极其复杂且容易出错。为简化和标准化构建 AI Agent 应用的过程，开源的 AI Agent 开发框架提供了预制组件、库和特定抽象概 念的软件开发工具包（SDK）。其核心价值在于以标准化的形式将这些分散的能力 高效整合，并围绕 Agent 间的交互、状态管理与工作流编排制定一套规则。 不同的 AI Agent 开发框架间的差异反映了各开发团队对理想的 LLM-based Agent 内部各组件构建方式和 LLM-MAS 编排、通信结构、协作类型和策略的不同理解。 四个主流框架分别代表了不同的设计路径：LlamaIndex 从一个专业的检索增强生 成（RAG）工具，战略性地扩展为一个构建“以数据为基础的 AI Agent”的综合 性框架、微软研究院的 AutoGen 将协作视为“对话”（Conversation-as-Computation）， LangChain 的 LangGraph 将其建模为“状态机”（State-machine-as-Workflow），而 CrewAI 则抽象为“团队自动化”（Role-based-Team-as-Process）。

3.2.1. AutoGen：为多 Agent 对话而生的框架

AutoGen 是由微软（Microsoft）、宾夕法尼亚州立大学（Pennsylvania State University） 与华盛顿大学（University of Washington）的研究人员共同开发的开源 Agent 开发 框架，其研究论文发布于 2023 年 8 月。2024 年 5 月 30 日，AutoGen 发布了 v0.4 版本，对核心架构进行了重构，提升了框架的可扩展性与易用性。

1) 统一泛化的 Agent 抽象。AutoGen 的核心是一套统一的 Agent 接口，所有 Agent 均继承自一个通用的基类，极大简化了自定义 Agent 的创建与交互。 AutoGen 将 Agent 作为基本构建单元，任何对象只要实现了 reply（messages） 方法，就可以成为 Agent 并参与对话。这种设计不仅使框架更加灵活，允许 开发者轻松创建具有特定行为（如调用工具、请求人类输入或与其他 Agent 交互）的智能体，还统一了 Agent 之间的交互方式，所有协作都通过标准化 的消息传递完成，从而增强了系统的模块化与可扩展性。 2) 灵活且可编程的对话模式。该框架通过“对话式编程”范式来编排工作流， 支持从动态涌现到静态预定义的多种对话模式。开发者既可以利用GroupChat 和 GroupChatManager 来实现多个智能体围绕一个共同目标进行动态、灵活的 自由讨论，让解决方案在交互中自然涌现；也可以通过编程方式定义静态的、基于图（Graph）的对话路径，从而对工作流进行精确控制，确保任务执行的 确定性和可预测性。这种双模支持的设计，使 AutoGen 既能胜任需要探索和 创造力的研究性任务，也能满足对流程稳定性有严格要求的生产级应用。 3) 原生且简化的工具使用与功能扩展。AutoGen 将工具（Tools）作为智能体能 力扩展的核心，简化了集成过程。开发者可以将任何 Python 函数注册为智能 体的工具，智能体（特别是基于 LLM 的 AssistantAgent）能够自动理解何时 以及如何调用这些工具来完成任务，并将工具执行结果整合到对话中。 AutoGen 原生支持符合 OpenAI 规范的工具调用，使得智能体可以无缝利用 外部 API、执行代码、查询数据库或与本地文件系统交互。

3.2.2. LlamaIndex：以数据为中心的 Agent 框架

LlamaIndex 最初名为 GPT Index，由 Jerry Liu 于 2022 年 11 月 9 日发布，该名称 揭示了其早期专注于为 GPT 模型使用的数据建立索引的核心功能。从“GPT Index” 到“LlamaIndex”的演变，再到其当前“为复杂企业文档构建 Agent 工作流”的定 位，标志着它已从一个专业的检索增强生成（RAG）工具，战略性地扩展为一个 构建以数据为基础的 AI Agent 的综合性框架。 1) 以数据为核心：为上下文增强的 LLM 应用提供支持。LlamaIndex 的架构和 演进过程揭示了一种“数据优先”的 Agent 构建哲学：若要实现可靠且复杂 的 Agent 行为，必须首先建立一个强大的底层数据处理框架，涵盖数据接入、 解析、索引和检索的全过程。框架的起源“GPT Index”确立了其在 LLM 技 术栈中对数据处理的初始关注点。其核心组件-数据连接器、索引和引擎-本质 上都是数据处理的原语。特别是 LlamaCloud 和 LlamaParse 等企业级解决方 案的推出，表明其致力于解决企业场景中至关重要的“脏数据”问题，这不 仅是高质量 RAG 的前提，也是构建可靠 Agent 的基础。因此，LlamaIndex 的 Agentic 能力是其数据处理能力的自然延伸，其 Agent 层（Workflows）也是 构建在坚实的数据层之上。 2) 架构组件：从数据接入到查询引擎的完整链路。其核心是一个专为稳健数据 处理而设计的模块化管道。整个流程始于数据连接器（Data Connectors），它 作为数据流的入口，通过 LlamaHub 社区提供的数百个连接器，能够从 API、 PDF、SQL 数据库等多样化的源头接入数据。数据在被接入后，会由数据索 引（Data Indexes）模块处理并构造成便于 LLM 高效检索的中间表示形式（如 向量存储）。最终，用户通过自然语言与这些索引数据进行交互，这得益于框 架提供的两种核心引擎（Engines）：专为问答（RAG）场景设计的查询引擎 （Query Engines），以及支持多轮对话的聊天引擎（Chat Engines）。为进一步 满足企业级需求，LlamaIndex 还推出了 LlamaCloud 托管服务，其中包含专有 的高精度文档解析方案 LlamaParse，能够精准处理带有嵌套表格、图表乃至 手写笔记的复杂文档，确保在企业环境中实现高质量的数据提取。

3.2.3. CrewAI：通过角色扮演的 Agent 促进协作智能

CrewAI 是由 João Moura 于 2023 年 11 月创建的开源框架，其设计初衷是编排能 够扮演角色、自主行动的 AI Agent，通过促进协作智能来解决复杂任务。CrewAI 的核心理念是一个由多位专家组成的“工作组”（crew）共同完成一个项目。这种 抽象使得 LLM-MAS 的设计更加直观，开发者无需编写复杂的控制流代码，而是 专注于定义团队成员的角色以及他们需要完成的任务。该框架完全由 Python 从零 开始构建，独立于 LangChain 等其他框架。

1) Crew 范式：Agent、任务与流程。CrewAI 通过将复杂的系统解构成 Agent（角 色）、Tasks（任务）和 Process（流程），提供了一种高度抽象的、声明式的方 法来构建多 Agent 协作。CrewAI 的基本构建模块是 Agents、Tasks 以及负责编排它们的 Crew。Agent 由角色（如“高级研究员”）、目标（旨在实现的目 的）和背景故事（用于引导其个性和行为）来定义；Task 是分配给 Agent 的 一个具体工作单元，也是 CrewAI 的核心。它包含一个描述（需要做什么）和 一个预期产出；Process 定义了工作组的协作模式。支持顺序执行和层级化流 程。 这种结构提供了很高的抽象层次。开发者的主要工作是声明式的：定义“谁 来做”（Agents）和“做什么”（Tasks）。而“如何做”则主要由框架的 Process 和 Agent 的自主决策来处理，包括在允许的情况下，Agent 之间可以相互委托 任务。

2) 自主协作与编排。CrewAI 的核心是 Crew 对象，它作为最高层级的编排者， 根据预设的流程自主驱动 Agent 完成协作任务。Crew 是最高级别的编排器， 它将 Agent 和任务整合在一起。当调用 crew.kickoff()方法时，Crew 会根据定 义的 Process 来管理任务的分配和执行。前一个任务的输出可以作为后一个 任务的上下文，从而实现协作式的工作流。CrewAI 为自主协作进行了优化， Agent 之间可以智能地委托和交互，而无需开发者指定每一个微小的步骤。 这非常适合解决方案和路径未知的创造性任务，例如生成市场营销策略或撰 写全面的研究报告。 CrewAI 框架内部的 Crews 和 Flows 这两种模式的并存，实际上是更广泛的 Agent 框架设计理念辩论的一个缩影。它引入了两种方法：Crews 和 Flows。 Crews 专为“自主性和协作智能”而设计，其中 Agent 拥有自主决策权。而 Flows 则用于“生产就绪的、事件驱动的工作流，提供精确的控制”，负责处 理条件逻辑和状态管理。这种二元性恰好反映了其他框架之间的哲学差异： Crews（自主的、基于角色的）在概念上类似于 AutoGen 的对话式 Agent 团 队；而 Flows（精确控制、状态管理、事件驱动）则在概念上类似于 LangGraph 的有状态图。CrewAI 提供了一个统一的解决方案，覆盖从自主探索性任务到 确定性生产工作流的整个范围。这也反映了其团队对 Agent 设计理念的一个 认识，即没有任何单一的范式（纯粹的自主性或纯粹的控制）足以应对所有 情况，理想的 Agentic 系统需要在 Agent 的自主性和开发者的明确控制之间 取得平衡。

3.2.4. LangGraph：编排有状态、可循环的 Agentic 系统

LangGraph 是由 LangChain 公司于 2024 年 1 月创建的一个开源库，旨在利用 LLM 构建有状态的、多角色的应用程序。其目标是为 LLM 应用引入循环（cycles）， 这使其与传统的、基于有向无环图（DAG）的框架（如其母项目 LangChain）形 成了鲜明对比。LangGraph 的诞生，直接回应了简单的线性链式结构在构建复杂 Agent 时所暴露的局限性。现实世界中的 Agent 行为常常需要循环（用于重试或 精炼）、分支（用于条件逻辑）以及人工干预的能力。LangGraph 正是为了对这些 复杂的、非线性的控制流进行建模而构建的。

1) StateGraph 范式：中心化的状态管理。LangGraph 的核心是 StateGraph，一 个通过显式、中心化的状态对象来协调所有计算节点的范式。LangGraph 中 最核心的抽象是 StateGraph。这种图由一个状态对象（例如 Python 中的 TypedDict）进行参数化，该状态对象会在每次计算时传递给图中的每一个节 点。每个节点的计算都会从这个中心化的状态中读取信息，并返回用于更新 状态的操作。状态的属性可以被配置为完全覆盖旧值，或是累加新值（例如， 将新的消息追加到消息列表中）。这种显式的、中心化的状态管理是 LangGraph 的特征。与数据仅从一个步骤流向下个步骤的无状态链不同， StateGraph 为系统中的所有角色提供了一个共享的“内存”或“草稿板”。这 十分有利于持久化执行，图的状态可以被检查点记录并随时恢复，同时也促 进了复杂的交互，因为任何节点都可以访问到计算过程的完整历史记录。 这种设计理念使得 LangGraph 更像是“Agent 操作系统”的内核，在操作系 统中，内核负责管理系统状态、调度进程和处理中断。因此，使用 LangGraph 的开发者不仅是在构建一个工作流，更是在为 Agent 设计一个微型的、专门 的操作系统。这赋予了开发者巨大的能力和控制权，但同时也要求他们对状 态管理和控制流逻辑有比其他更抽象的框架更深刻的理解。

2) 控制流的构建模块：节点与边。LangGraph 通过节点（Nodes）和边（Edges） 的组合，为开发者提供了以编程方式定义 Agent“认知架构”的强大能力。一 个 LangGraph 由 Nodes 和 Edges 构成。Nodes 是计算单元，通常是一个 Python 函数或一个 LangChain 表达式语言（LCEL）的可运行对象。它们接收当前 状态作为输入，并返回一个包含更新值的字典。Edges 定义了节点之间的控制 流。LangGraph 支持多种类型的边：Starting Edge（起始边）作为图的入口 点；Normal Edges（普通边）定义了固定的、从节点 A 到节点 B 的流转；而 Conditional Edges（条件边）则是实现动态行为的关键。条件边利用一个函 数的输出来决定图的下一个走向，可以路由到多个可能的后续节点之一，其 中也包括一个特殊的 END 节点，用于终止循环。这种受 NetworkX 等图论库 启发的节点与边模型，提供了一种可视化的、程序化的方式来定义 Agent 的 “认知架构”。开发者可以明确地绘制出每一种可能的状态转换路径，使得 Agent 的逻辑变得易于审计和调试。

3) LangGraph 生态系统：开源库与商业平台。LangGraph 通过提供免费的开源 库和商业化的部署平台，为开发者构建了一条从本地原型到生产级部署的完 整路径。LangGraph 有两种模式：一个是免费的、采用 MIT 许可证的开源库， 另一个是专有的、商业化的 LangGraph 平台。开源库提供了定义和运行有状 态图的核心框架。而平台则在此基础上，提供了用于部署、扩展、持久化（通 过托管的 Postgres）、容错和监控的生产级托管基础设施，并附带了一个名为 LangGraph Studio 的可视化 IDE。这种双层产品策略为开发者创造了一条从 本地开发到生产部署的清晰路径。开发者可以使用开源库自由地进行原型设 计，当面临扩展性、状态持久化和可观察性等生产级挑战时，可以直接采用 同一供应商提供的付费托管解决方案。

3.3. AI Agent 开发平台

AI Agent 开发框架虽然功能强大，但其陡峭的学习曲线、复杂的调试过程和频繁 的更新，给生产环境的落地带来了巨大挑战。为简化 AI Agent 的开发、调试、部 署和运维过程，AI Agent 开发平台通过封装 LLM、记忆、工具和编排引擎等核心 组件，提供预置的模板、工作流和插件生态，以其低代码（或无代码）的特性， 为企业、开发者、业务人员和个人用户提供 SaaS 为核心的产品。 当前，AI Agent 开发平台正沿着两条路径演化：大型科技公司的商业闭源平台面 向需要从技术到运维提供全托管服务的用户，深度绑定自身庞大的云服务与大模 型体系，提供预制模板，构筑起生态壁垒。竞争逻辑是构建一个与其核心业务（如 云服务、CRM、办公套件）深度绑定、难以分割的平台，让客户对平台的依赖性 随着其在生态内数据和流程的沉淀而指增长，从而构筑竞争优势；开源平台面向 需要定制个性化服务的企业或个人，其核心价值在于庞大的开发者社区、技术透 明度以及灵活的供应商选择。开源开发平台允许用户自由组合最佳工具，赋予了 更高的灵活性和控制权，但同时也要求用户承担更多的集成与维护工作。

AI Agent 开发平台的市场是一个正在迅速分化和扩张的全新领域，参与者众多， 未来，商业闭源和开源平台将分别通过两种方式加深各自的护城河：企业通过构 建更深的生态护城河来锁定高价值客户；开源平台通过提供更灵活强大的工具， 赋能需要定制化服务的个人和企业。

3.3.1. Microsoft Copilot Studio：企业生态的低代码 AI 构建器

Microsoft Copilot Studio 是微软推出的一个低代码对话式 AI 平台，于 2023 年推 出，旨在让组织能够自主创建和定制专属的 Copilot，并将其部署在网站、移动应 用及 Microsoft Teams 等多个渠道中。该平台深度整合了 Microsoft 的各项服务， 允许开发者和业务用户通过图形化界面和生成式 AI 能力，连接到企业后端系统 和数据源，如 SAP、Workday 等。 1) 深度生态集成与企业级基因的融合：Copilot Studio 最核心的护城河在于其与 Microsoft Teams、Power Platform、SharePoint 及 Office 365 等微软全家桶产品 的无缝集成。它具备强大的企业级管理和安全功能，包括精细的权限管理、 数据丢失防护（DLP）和智能监控机制，使其能轻松调用企业内部数据与服 务。这种企业级基因使其更适合需要严格数据安全与合规管控的企业级应用， 如内部流程自动化。 2) 以“主题”为核心的对话式设计模型：在 Copilot Studio 中，智能体的构建过 程围绕着创建“主题”（Topics）展开，每个主题代表一段独立的对话流程。 开发者在一个可视化的画布上，首先定义主题的“触发器”（Trigger），可以 是由用户的特定短语（Phrases）激活，也可以是程序化的事件激活。随后， 通过拖拽和连接不同的“节点”（Nodes），如“提问”（Question）、“条件”（Condition）和“消息”（Message），来构建复杂的对话逻辑。平台还引入了 生成式 AI 能力，允许用户通过简单的自然语言描述来自动创建主题，进一步 降低了开发门槛。而智能体的“行动”（Actions）能力，如调用一个 Power Automate 流程，则是其连接外部系统、执行实际任务的主要方式。

3.3.2. IBM watsonx Orchestrate: 企业流程自动化的数字劳动力编排器

IBM watsonx Orchestrate 是 IBM 推出的企业级的“数字劳动力”平台，其核心目 标是创建、管理并编排能够自动化复杂和多步骤业务流程的 AI Agent，从而将 AI 从简单的任务执行者提升为能够处理完整业务职能（如人力资源、采购和销售） 的合作伙伴。 1) 面向复杂业务流程自动化的多智能体编排：watsonx Orchestrate 的核心是编 排协同工作的 AI Agent 团队，自主规划并执行任务，无需人工微观管理。其 “编排器 Agent”作为智能自动化层，能动态选择行动或调用最合适的 Agent， 并管理依赖关系与控制流。这揭示了 IBM 的战略意图：它是一个专为业务流 程再造（BPR）设计的系统，旨在对整个业务单元进行大规模自动化改造， 而非构建小型、独立的 AI 应用。 2) 面向业务与技术用户的双轨开发模式：IBM 为创建 Agent 提供了两条截然不 同的路径，同时满足业务与技术用户的需求。业务用户可通过无代码的“Agent 构建器”快速构建、测试和部署 AI Agent，定义其画像、连接工具并配置行为。 专业开发者则可使用基于 Python 的“Agent 开发工具包”（ADK），以编程方 式构建高度定制化的 Agent，并支持与第三方框架集成。这种双轨模式是 IBM 渗透大型企业的战略举措，它通过同时提供自助服务能力和深度定制的“逃生 舱口”，解决了企业内部业务部门追求速度与 IT 部门要求可控性之间的常见 摩擦。 3) 聚焦混合部署与预置资产的企业级就绪能力：watsonx Orchestrate 能无缝融 入复杂的企业 IT 环境，强调集成、复用和部署灵活性。平台支持云端 SaaS 和本地部署（通过 Cloud Pak for Data），满足金融、医疗等受严格监管行业的 需求。为加速价值实现，IBM 提供了包含大量预置 AI Agent 的“Agent 与技能 目录”，这些 Agent 内置领域知识并预集成了 SAP、Oracle 等常见企业应用。 平台还强调其“开放式设计”，能通过 OpenAPI 规范连接绝大多数企业工具， 并与 IBM 现有的 RPA 等自动化产品集成，保护客户已有投资。

3.3.3. Amazon Bedrock Agents：开发者优先的模块化 Agent 构建基石

Amazon Bedrock Agents 是亚马逊云科技（AWS）提供的一项全托管服务，旨在帮 助开发者轻松创建能够代表用户执行复杂业务任务的生成式 AI 应用。该服务构 建于 Amazon Bedrock 之上，利用其基础模型（Foundation Models, FMs）能力，通 过自动化的提示工程和模型编排来理解用户请求、拆解任务并调用必要的 API 来 完成操作。 1) 面向 Agentic 系统的基础性、框架无关的工具集：Bedrock Agents 的核心理念 是提供构建 Agentic 系统所需的基础组件，延续了 AWS 经典的 IaaS/PaaS 哲 学，为开发者提供一套灵活、非绑定的构建模块。开发者可以从大模型提供 商（如 Anthropic、Meta）及亚马逊自家的模型中选择，并组合行动组（工具） 和知识库（RAG）来构建 Agent。整个复杂的编排循环由 Bedrock 服务在后 台处理，灵活且便于控制。 2) 以行动组和基础设施即代码为核心的开发者中心构建模式：该平台的主要开 发体验是专业代码驱动的，其核心是通过 API 定义工具，并以编程方式管理 Agent 生命周期。为 Agent 提供工具的核心机制是“行动组”，每个行动组通过一个 OpenAPI 规范来定义，业务逻辑则在 AWS Lambda 函数中实现。AWS 使用基础设施即代码（IaC）框架（如 CloudFormation 或 CDK）来管理 Agent， 将其视为 CI/CD 流水线中的软件构件。这种方法将 Agent 开发植根于现代软 件工程实践中，对于已采纳 API 驱动架构的组织，极大地降低了采用门槛。 同时，控制台也提供了一个“Agent 构建器”界面用于快速原型设计。 3) 多智能体协作与企业级可扩展性：AWS 不仅支持构建由一个“主管”Agent 协调多个专业“子 Agent”工作的多智能体系统，还推出了 Amazon Bedrock AgentCore 服务框架，用于解决大规模运行 Agent 的运维。其中包括提供安 全隔离环境和长达 8 小时异步任务支持的 AgentCore Runtime，以及用于安全 连接的 AgentCore Gateway 和管理记忆的 AgentCore Memory。

3.3.4. Palantir AIP：基于本体的 AI 指挥与控制系统

Palantir Technologies 于 2023 年 4 月推出了其人工智能平台（Artificial Intelligence Platform, AIP），旨在将 LLM 和其他前沿人工智能技术安全应用到其核心平台 Gotham 和 Foundry 中。AIP 不是独立的产品，而是深度集成在现有平台之上，赋 能客户利用 AI 来加速决策、自动化任务和发现新洞察。其构想是赋能组织机构， 有效整合数据、决策和运营，将企业中复杂、碎片化的数据转化为一个连贯可操 作的基础。

1) Ontology（本体）：为决策中心型 AI 打造的“数字孪生”。AIP 最差异化特性 是其 Ontology（本体），这是一个语义层，能够创建整个企业动态的、以决策 为中心的模型。通过整合任何决策的三个核心要素：数据（业务的“名词” 或对象，如供应商、零部件和设施）、逻辑（管理交互的业务规则和模型）以 及行动（影响现实世界的“动词”或可执行操作），构建了一个全面的企业“数 字孪生”。这种设计使得 AIP 不仅能理解数据点，更能理解它们所代表的复 杂关系网络和运营现实。通过映射和连接从 ERP 数据、物联网流到非结构化 文档和地理空间信息等一切事物，Ontology 为员工和 AI Agent 提供了共享操 作，以便他们进行查询和推理等操作。这种深度集成和建模过程本身就构筑 了强大的壁垒。一旦企业将其全部的运营逻辑、数据关系和行动路径编码到 这个“中央神经系统”中，将这个“数字孪生”迁移到其他平台所需的时间、 资本和运营中断成本将非常高。

2) AI Agent 工具：从无代码 AI 到自主运营。AIP 最核心的特点是其提供了一 个全方位、多层次的工具集，将 AI 能力与企业既有的、高度复杂的运营环境 进行安全、可控的融合，从而实现从数据洞察到业务行动的无缝连接，构建 完整的生态系统：首先，通过与 Foundry 本体（Ontology）的深度绑定，确保 所有 AI 的交互都严格遵守企业预设的数据权限和治理规则，从根本上解决 了在敏感环境中使用 AI 的安全与合规问题；其次，AIP 为不同角色的用户提 供了从低代码（如 AIP Logic、Workshop 微件）到专业代码（如 Pipeline Builder、 函数和代码工作区）的全光谱开发工具，使得业务分析师和软件工程师都能 利用 AI 构建和增强工作流；最后，它强调“行动导向”，通过 AIP Automate 和 AIP Agent 等功能，将 AI 的分析结果转化为可自动执行的业务操作。这种 将 AI 能力完全整合进一个统一、安全且以行动为导向的操作平台中的设计， 构筑了其核心壁垒-客户所依赖的并非某个单一的 AI 功能，而是一个深度嵌 入其业务流程、难以剥离的“AI 操作系统”。

3.3.5. Salesforce Agentforce：CRM 数据驱动的可信平台

Salesforce 已将其 Agentforce 定位为其主要的 AI Agent 平台，旨在成为“世界第 一的数字劳动力平台”，通过大规模部署 AI Agent 来增强每一位员工并改变客户 体验。其最重要的优势和差异化特征在于其与 Salesforce Customer 360 平台及 Data Cloud 中海量可信客户数据的原生、深度集成。所有 AI Agent 活动都受到 Einstein信任层强大的安全和隐私框架的治理，确保 AI 安全、负责地运行。 1) 与可信 CRM 数据的深度集成：Agentforce 的差异化能力在于其能够基于 Salesforce 内部丰富的、有上下文的数据进行推理和行动-对于全球许多大公 司而言，Salesforce 是客户关系的唯一真实来源。Agentforce 生于 CRM 内部， 其 Agent 能够原生理解客户历史、服务案例、购买记录和营销互动的完整背 景，从而生成高度个性化和相关的响应与行动。这种根植于可信、专有数据 的特性是提供准确、一致体验并避免无根据模型产生通用或“幻觉”响应的 关键。Salesforce 最大的资产是其掌握的客户数据库，Agentforce 是一项将这 一“数据护城河”加深的能力。 2) 低代码定制与全面的开发工具：Salesforce 为 Agentforce 提供了一套强大的 低代码工具，包括 Agent Builder, Prompt Builder, Model Builder 和 Flow Builder 等，使企业能够轻松地构建、测试、管理和定制化自己的 AI Agents。这意味 着企业可以根据自身独特的业务需求，快速创建和部署 AI Agents，而无需深 厚的编程知识。这种灵活性和易用性，结合预置的 agents 模板，大大降低了 企业应用 AI 的门槛，加速了从概念到实践的进程。 3) 自主与自动化能力：Agentforce 的 AI agetns 拥有高度的自主性，能够在预设 的护栏（guardrails）内独立运作，它们可以理解人类意图、检索相关数据、 创建行动计划并执行任务，而无需持续的人为干预。这种自主性使得 Agentforce 能够 7x24 小时不间断地处理从客户服务、销售线索跟进到内部员 工支持等多种复杂业务流程，从而显著提升效率，降低运营成本，并将员工 从重复性工作中解放出来，专注于更具战略性的任务。

3.3.6. 腾讯云智能体开发平台和腾讯元器：面向 B 端和 C 端的两大定制平台

腾讯云智能体开发平台：腾讯云智能体开发平台（TCADP）于 2025 年 5 月 21 日 正式发布，是腾讯面向 B 端的 Agent 开发平台，其特色在于灵活的开发模式和扎 实的工程技术，能够满足不同复杂度的企业需求。 1) 双模式开发与画布式编排：TCADP 同时支持低代码拖拽搭建（适合智能问答） 和面向专业开发者的代码态（通过原子能力接口实现复杂逻辑），兼顾了易用 性与功能的深度。开发者在可视化的画布上，可以灵活编排 LLM+RAG、 Workflow 或 Multi-agent 等多种框架的节点，将企业 API 接入智能体，确保 输出稳定可控。 2) 高性能 RAG 与多端场景验证：TCADP 结合了 DeepSeek 等优秀模型和腾讯 自家的向量数据库，实现了平均响应时间小于 1 秒的高效知识检索，并支持 GPU 加速和缓存优化。它在零售、政务、校园等场景得到充分验证，并支持 发布到企业微信等腾讯系协作工具，非常适合需要与腾讯生态打通的企业应 用。

腾讯元器：腾讯元器发布于 2024 年 5 月 17 日，是面向个人开发者和中小企业的 轻量级 AI Agent 开发平台，强调低代码开发、快速分发和生态集成，适合快速构 建对话式智能体、公众号客服等场景。2025 年 7 月 3 日，元器推出了微信支付 MCP，旨在实现智能体商业化并提升用户支付体验。 1) 轻量级低代码快速开发：通过提示词、工作流、知识库等模块实现快速搭建 Agent；深度整合了腾讯生态，提供基础插件（如网页解析、图片生成）和简 单工作流编排，适合非技术用户；聚焦个人助手和微信公众号平台，适用轻 量级场景，如公众号客服、教育问答、个人助手等，强调快速上线和低成本 运营。2) 便捷的 Agent 商业化支付解决方案：微信支付 MCP（商户合作平台）是腾讯 元器提供的一项核心商业化能力，它允许智能体创建者通过微信支付接收用 户的打赏或付费。微信支付 MCP 支持多种支付场景，包括在 PC Web 端生成 支付二维码以及在移动端 H5 环境中拉起微信支付，创作者可以根据预设的 提示词或通过工作流中的特定逻辑来触发支付流程，为 Agent 的商业化提供 了灵活且便捷的途径。

3.3.7. 百度智能云千帆 AppBuilder 和文心智能体平台 AgentBuilder：面向企业级与 开发者生态的双轨开发平台

百度智能云千帆 AppBuilder：千帆 AppBuilder 由百度于 2024 年 4 月 16 日推出， 定位为 AI 原生应用开发工具，现已转变为面向 B 端的全链路大模型应用开发管 理平台。千帆 AppBuilder 提供从 RAG、Agent 到工作流、UI Builder 的完整工具 链，并预置百度 AI 搜索、iRAG 等特色组件，支持零代码、低代码、全代码三种 开发方式，旨在帮助企业在最短时间内完成大模型应用的开发、部署与迭代。 1) 零代码、低代码、全代码一体化：AppBuilder 同时支持“零代码”拖拽式可 视化搭建、“低代码”组件化拼装，以及面向专业开发者的 OpenAPI 与 SDK 全代码开发。用户可在 UI Builder 中快速配置对话界面、卡片样式与多轮交 互逻辑，亦可通过工作流节点或原子能力接口实现复杂业务与企业 API 的深 度集成与定制。 2) 全链路 AI 能力与生态接入：平台内置 RAG、Agent、Workflow 三大开发范 式，并预置百度 AI 搜索、iRAG、文档理解、图像理解、语音识别等丰富组 件；同时提供知识库管理、向量数据库、团队协作、批量任务、MCP 服务等 扩展模块，打通模型调用、数据治理、应用分发与商业化变现的“最后一公 里”。

文心智能体平台 AgentBuilder：文心智能体平台 AgentBuilder 由百度于 2024 年 4 月 16 日发布，定位是面向 C 端个人开发者、自媒体及中小企业的轻量化 Agent 开 发平台，可通过自然语言描述即可生成对话机器人、公众号客服、学习助手等应 用，并直接发布到微信公众号、微信小程序、企业微信、小米应用商店等多端。 1) 多模态模型与数据自定义：平台内置“文心一言”等大语言模型，并支持用户 上传自有文档、表格、图片等多源数据，自主完成索引与切片管理，可构建 高度契合专业场景的知识库，为智能体提供精准、可控的回答依据。 2) 灵活开发与多端分发：文心智能体平台提供智能体、工作流、工作流智能体 等多种开发模式，兼顾低门槛快速试验与深度定制化需求；完成开发后，可 一键发布到微信小程序、企业微信、公众号、网页嵌入等多端，并支持 MCP 服务实现商业化收入闭环。

3.3.8. 阿里云百炼（Model Studio）：深度融合云生态的企业级智能体平台

阿里云百炼（Model Studio）是一个一站式的大模型开发与应用构建平台，旨在让 开发者和企业能够轻松地进行大模型应用的开发、训练和部署，将更多精力投入 到应用创新中。 1) 面向企业的零代码 AI 应用构建器：百炼平台的核心定位是成为一个企业级 的、零代码的解决方案，帮助企业快速构建智能应用。其构建流程设计得极 为简化，用户首先在控制台中选择一个基础大模型（如通义千问系列），然后 通过一个简洁的界面定义系统提示词（System Prompt）来设定智能体的角色 和行为准则。之后，用户可以通过添加“知识库”（Knowledge Bases）来注入 私有领域知识以实现 RAG，或通过选择“插件”（Plugins）来赋予智能体调用外部工具（如文生图、天气查询）的能力。 2) 深度融合云基础设施的战略定位：百炼平台最显著的特征是其与阿里云基础 设施的原生集成。它不仅仅是一个模型调用工具，更是企业利用阿里巴巴全 栈云能力（从底层算力、对象存储到上层大模型服务）构建 AI 应用的中枢。 平台的设计支持构建单智能体应用，同时也提供了“智能体编排应用”的能 力，可以构建具备自动规划和协同能力的多智能体群组，以处理更复杂的任 务。这表明其战略意图是成为企业在阿里云上部署 AI 战略的统一入口。

3.3.9. 字节跳动扣子（Coze）：无代码 AI 智能体构建与多渠道分发平台

扣子是由字节跳动于 2024 年 2 月推出的的新一代 AI 应用开发平台。其核心定位 是成为一个面向所有技能水平用户的零代码平台，旨在简化 AI 聊天机器人和 Agent 的创建过程，让非程序员也能快速将想法变为现实。2025 年 7 月 26 日，扣 子将其核心项目扣子开发平台（Coze Studio）与扣子罗盘（Coze Loop）开源，相 对商业版缺少了用户组管理、快速拖拽界面开发、大量插件等重要功能。 1) 零代码与极速部署的“快餐式”体验：扣子是目前入门最简单的平台之一， 用户通过对话和点选，5 分钟即可创建一个聊天机器人。其核心优势在于一 键发布到抖音、飞书、豆包、Telegram 等多个平台，极大地简化了分发流程。 2) 基于“技能”的插件化构建与生态整合：构建过程围绕为智能体添加“技能” 展开，包括“插件”（工具）、“知识库”（RAG）和“数据库”（长期记忆）。 平台与抖音、飞书等字节生态深度绑定，并提供超过 60 种内置插件（如新闻 搜索、文生图）和工作流功能，用户可以像搭乐高一样组合能力，实现多步 骤任务。尽管其对复杂业务逻辑的支持有限，但非常适合个人开发者和新媒 体运营快速验证想法。

3.3.10. n8n：节点式工作流与代码灵活性的开源自动化平台

n8n 是由 Jan Oberhauser 于 2019 年在柏林创立的一个工作流自动化平台，旨在为 技术团队提供开箱即用的可视化自动化解决方案，支持自托管和云端部署，帮助 用户通过拖拽式工作流和丰富的节点生态，高效地连接各类服务并自动化复杂业 务流程。 1) 开源 fair code 许可与可扩展生态：n8n 采用源代码公开且混合 MIT/商业的 fair code 许可，核心代码托管于 GitHub，允许社区无限制地贡献节点、功能 和改进，同时企业用户也能选择付费获得附加支持与高级功能。这种模式在 保持透明度与安全性的同时，为不同规模的组织提供了灵活的扩展能力。 2) 低代码可视化流程构建与 AI 原生集成：平台提供直观的节点式编辑器，用 户可通过拖拽式触发器与操作节点快速设计端到端工作流。目前内置 400 多 个预置集成节点，并支持在流程中嵌入 JavaScript/Python 代码和接入 Anthropic、OpenAI 等 AI 模型，从而实现文本生成、数据处理及多智能体循 环等复杂任务。 3) 灵活的部署与企业级安全：n8n 支持 Docker、Kubernetes 等多种自托管方式， 也提供 n8n Cloud 全托管服务。自托管可在私有网络或离线环境中运行，确 保数据完全掌控；云端服务则免除运维、并提供多环境管理、日志监控和基 于 SAML/LDAP 的细粒度权限控制，满足从小型团队到大型企业的多样化需 求。

3.3.11. Dify：开源的生产级 LLM 应用开发平台

Dify（2023 年 5 月 9 日发布）是一个以应用为中心的开源 LLMOps 平台，旨在简化生产级生成式 AI 应用的构建、运营和管理。其架构将后端即服务（Backend-asa-Service, BaaS）和 LLM 运营（LLMOps）的概念融为一体。 1) 面向 AI 应用的后端即服务（BaaS）架构：Dify 的架构创新地融合了后端即 服务（BaaS）和 LLMOps 的概念，提供了一个完整的后端技术栈，封装了模 型集成、数据管理、API 服务等复杂性，让开发者可以专注于应用逻辑本身。 它支持广泛的模型提供商，包括 OpenAI、Anthropic、Google 以及众多开源模 型和国内模型，如智谱 AI、文心等，为开发者提供了极大的灵活性。 2) 通过提示词 IDE 和工作流节点进行编排：在 Dify 上构建应用主要围绕两个 核心组件。一个用于精心设计和测试提示词的“Prompt IDE”，以及一个可视 化的工作流编排器。开发者可以选择创建基础的“对话型”应用或更复杂的 “工作流型”应用。而在工作流模式下，开发者可以通过可视化界面拖拽和 连接代表大语言模型（LLM）、知识库（实现 RAG）和工具的节点，从而构 建出复杂的数据处理和内容生成管线。这种模式特别适合需要多步骤逻辑处 理的应用场景。 3) 开放社区和强大的可拓展性：Dify 的开源属性和对开放标准（如 OpenAPI） 的拥抱，使其工具生态系统具有极强的可扩展性。当一个新的流行 API 出现 时，社区成员可以迅速为其创建 Dify 工具，从而让所有 Dify 用户都能享受 到最新的技术红利。

3.3.12. Langflow：LangChain 的可视化多智能体构建框架

Langflow 是一个开源的可视化框架，于 2024 年 6 月正式发布，它本质上是为 LangChain 开发者服务的专业可视化 GUI，将复杂的代码逻辑转化为直观的、可 拖拽的流程图。 1) 为 LangChain 设计的可视化编程界面：Langflow 的核心创新在于为原本需要 大量编码的 LangChain 框架提供了一个直观的、拖拽式的可视化界面。用户 可以在画布上将代表 LLM、提示词、工具、链（Chains）和智能体的组件进 行连接，以可视化的方式构建复杂的逻辑流。这些流程可以被导出为 JSON 格 式，以便在 Python 应用中复用，也可以直接部署为一个 API 端点。 2) 聚焦于高度定制化的流程编排：Langflow 非常适合中高级开发者构建高度定 制化的 AI 应用。它支持自定义组件开发和精细的流程控制，可以模拟复杂的 多智能体协作。然而，它更侧重于流程的“编排”而非 Agent 的“自主决策”， 且对于非技术人员上手门槛较高，自部署也需要一定的运维能力。平台支持 MCP 协议，显示了其在多智能体方向的雄心。

3.3.13. RAGFlow：基于深度文档理解的开源 Agent 开发平台

RAGFlow 是由 InfiniFlow 团队于 2024 年 4 月 1 日官方开源的一个 RAG（Retrieval Augmented Generation，检索增强生成）引擎，基于深度文档理解，整合各类大模 型以提供带有可溯源引用的问答能力，同时支持对多种复杂格式的文档进行智能 解析与检索，已形成“RAG＋Agent”一体化架构。 1) 深度文档理解与可解释分块：RAGFlow 的“DeepDoc”模块专注于对 PDF、 DOCX、Markdown、表格、甚至扫描件进行布局分析和 OCR 识别，结合模 板化的分块策略（chunking），实现对海量非结构化数据的精准抽取。其 “Quality in, quality out”理念保证了输入文档质量与输出答案的可信度。 2) 可信检索生成与引用管理：平台构建了多阶段检索-重排序（recall & rerank） 流程，在结合 Agent 生成回复时自动附带原文段落与来源链接，显著降低 AI 幻觉风险。用户可在对话界面一键查看所有引用，实现答案的可审计与可验证。 3) 插件化组件与 Agent 生态：除了核心的 RAG 引擎，RAGFlow 提供文件管理、 知识库（Datasets）和 AI Chat 等模块，还支持 Agent 框架下的 Python/JavaScript 代码执行组件（Sandbox Code Executor），允许用户编写脚本来扩展检索、分 析或外部系统交互能力。插件化设计可接入 OpenAI、Anthropic 等多个模型 供应商，也方便定制新的数据源与工具。

3.3.14. Flowise：开源可视化构建 AI Agents 与工作流平台

FlowiseAI 是一个通过可视化方式构建开源 AI Agent 平台，与 Langflow 类似，是 LangChain 框架的一个可视化前端。其核心理念是让用户能够通过拖拽式的用户 界面，在几分钟内构建出定制化的 Agent 应用，支持从 Chatbot 到 MAS。 1) “拖拽即编排”的可视化工作流：Flowise 的核心是其“Chatflow”（聊天流） 画布，用户通过直观的拖拽和连接节点来设计 AI 的逻辑。每一个节点代表一 个具体的功能模块，例如一个语言模型、一个 API 工具、一份本地文档或一 个向量数据库。其优势在于极大的易用性和灵活性，非技术人员也能轻松上 手，同时开发者也能通过自定义节点来扩展平台的边界，快速验证和迭代 AI 应用原型。 2) 高度模块化与可扩展的组件生态：Flowise 的强大之处在于其背后的组件库和 开放的架构。平台内置了对上百种主流大语言模型、向量数据库、数据加载 器和 API 工具的即用型集成节点。用户可以自由组合这些模块来满足特定需 求，例如构建一个能读取 PDF 文档并回答问题的 RAG（检索增强生成）系 统，或是一个能调用外部搜索引擎来获取实时信息的智能体。这种模块化的 设计确保了平台能够随着 AI 技术的发展不断融入新的工具和模型。 3) 灵活的部署选项与企业级特性：为满足不同用户的需求，Flowise 提供了从本 地部署到云端托管的多种方案。用户可以通过 Node.js 或 Docker 将 Flowise 完全私有化部署在自己的服务器上，确保数据的安全可控，这对处理敏感信 息的企业尤为重要。同时，平台也提供官方的云托管服务，节省维护和扩展 基础设施成本。其后端架构基于 Node.js，前后端分离，并提供完整的 API、 SDK 和嵌入式组件，便于将构建好的 AI 应用无缝集成到现有网站或业务流 程中，具备应对生产环境需求的扩展能力。

3.3.15. FastGPT：融合知识库与可视化工作流的开源 AI 应用构建平台

FastGPT 一个开源知识库问答与可视化流程编排平台，旨在帮助开发者和业务人 员快速构建、部署和管理基于大模型的智能问答系统。该平台集成了数据预处理、 向量检索（RAG）和可视化工作流三大核心能力，无需复杂配置即可上手使用。 1) 一体化知识库与可视化流程编排：FastGPT 将知识库管理与工作流编排深度 融合，提供“Flow”可视化编辑器，用户可通过拖拽节点实现从文档导入、向 量化检索到模型调用的端到端流程。在对话过程中，系统能自动给出下一步 执行提示，并追踪各模块中间输出，支持多层级模块封装和子流程复用，大 幅简化复杂问答场景的构建流程。 2) 多源数据与插件化模型集成：平台支持多种数据源与文件格式（PDF、DOCX、 TXT、HTML、MD、CSV、PPT、Excel 等），并可针对不同知识库节点指定 专用向量模型；同时提供灵活的插件化模型接入方案，既可调用 OpenAI、 Anthropic 等云端模型，也可通过 OneAPI、SiliconCloud、PPIO 等接入本地或 第三方大模型，实现模型按需替换与混合骨干部署。 3) 极速部署与多模式运行：FastGPT 支持 Docker Compose、Kubernetes 以及Sealos 一键部署，用户可在几分钟内完成私有化部署并上线服务；开源版遵 循基于 Apache 2.0 的 FastGPT Open Source License 开源协议，允许直接用作 后端服务，商业版则提供更多企业级定制功能。无论是本地自托管还是 FastGPT Cloud（fastgpt.io）全托管模式，都能满足从小团队 PoC 到大规模生 产的多样化需求。

3.4. AI Agent 通用应用

自 2025 年 3 月 Monica 团队发布通用 Agent-Manus 以来，多个 AI Agent 的通用应 用也相继落地。目前的产品主要以能自主完成复杂工作流的通用 Agent 为向主， 以及集合了多种功能的 Agent 一体化平台。AI Agent 通用应用的共同特征是依赖 复杂的多模型、多工具后台编排系统，强调人机协同，面向日常和工作生产力场 景。

3.4.1. Manus：透明化的通用 AI Agent

Manus 是由 Monica 于 2025 年 3 月 6 日发布的通用型 AI Agent，其核心定位是作 为“数字员工”，能够在隔离的沙盒环境中自主运行，并调用各类工具完成复杂任 务。该应用将基础模型（如 Claude 和 Qwen）封装在一个强大的执行框架内。其 目标是让 AI 从一个被动的问答工具，转变为一个能够理解用户意图、自主规划并 执行多步骤任务的主动工作伙伴。 1) “CodeAct”范式下的自主代码执行。Manus 的核心创新在于其“代码即行 动”（CodeAct）范式，即将可执行的 Python 代码作为与数字世界交互的主要 方式，而非依赖有限的预设指令。这种理念将代码视为描述复杂操作的最通 用语言，使得 AI 在接到任务时，能像人类开发者一样生成包含条件逻辑、循 环和错误处理的脚本来完成动作。其优势在于极大的灵活性和强大的能力， AI 可以在代码执行出错后分析信息、修改代码并重试，实现“自主调试”，从 而将自身的操作空间扩展到数据分析、软件开发等几乎无限的编程领域。 2) 沙盒化的云端环境与模块化工具集。为确保安全与稳定，Manus 在云端一个 完全隔离的虚拟计算环境中运行。每个任务都会被分配一个独立的沙盒 （Sandbox），这本质上是一个预装了完整操作系统的 Docker 容器。在这个受 控的环境中，Manus 被授予了一套强大的模块化工具集，可以像人类一样使 用终端执行系统命令、控制无头浏览器浏览网页并交互、在文件系统中读写 数据以保存工作进度。这种沙盒化的架构，既赋予了 AI 强大的执行能力，又 保证了所有操作都在安全可控的范围内进行，不会影响外部系统。 3) 多模型、多智能体的后台编排架构。Manus 的强大能力由一个复杂的后台编 排系统支撑，该系统能够动态调度多种 AI 模型和内部模块。虽然 Manus 并 未公开其技术细节，但根据技术架构推测，Manus 的“大脑”并非单一模型， 而是根据任务性质灵活调用 Claude、Qwen 乃至 GPT-4 等不同模型的混合骨 干。系统的运作遵循一个“分析-规划-执行-观察”的清晰智能体循环，确保 每一步行动都稳健且可控。此外，其架构支持多智能体协作，通过规划智能 体（Planner Agent）、执行智能体（Execution Agent）和验证智能体（Verification Agent）三个核心智能体的协同工作来处理任务，从而高效地完成生成完整报 告或部署网站等复合型任务。

3.4.2. Genspark Super Agent（Genspark 超级智能体）：一体化 Agentic 工作空间

Genspark Super Agent 是由 MainFunc 所推出的 AI 原生工作平台。该产品最初于 2024 年 6 月 18 日以“AI Agentic Engine”的定位面世，经过快速迭代，现已发展 成全面的智能工作系统。它集成了一系列功能强大的 Agents，包括能够处理复杂 任务的高级 Agents（如 AI Slides、AI Sheets、AI Docs 和 Deep Research 等），以及 支持多模态内容创作的基础智能体（如 Image Studio 和 Generate Video）。其目的 是通过“智能体混合系统”将用户从繁琐的执行流程中解放出来：用户提出目标， Genspark 便能自主完成研究、分析、内容创作及信息核实等一系列复杂任务。 1) “Vibe Working”理念下的无缝自动化体验：Genspark 的核心产品哲学是 “Vibe Working”，旨在通过自然语言提示实现所有工作的自动化，从而根本 性地提升工作效率与体验。这一理念贯穿其所有产品线，其核心假设是，在 AI 时代，用户应专注于表达意图（“Vibe”），而非构建复杂的工作流。例如， Genspark 在 2025 年 7 月 2 日推出的 AI Docs 产品允许用户通过单一提示创 建任何类型的文档，而 Super Agent 则能自主处理诸如拨打电话、生成演示文 稿等复杂任务，无需用户进行任何工作流配置或设置。 2) 垂直整合的全 Agentic 工具套件：Genspark 通过系统性地发布一系列互联互 通的 Agentic 工具，构建了一个其称之为“一体化 AI 工作空间”的闭环生态 系统。这个产品矩阵始于 AI 搜索，并扩展至 AI 浏览器、AI Docs、AI Slides、 AI Sheets、AI Drive 等核心生产力工具，形成了 Genspark 所描述的“AI 时代 的经典生产力三件套”。 3) 多模型、多工具的后台编排架构：Genspark 的强大功能由一个复杂的后台编 排系统支撑，该系统能够动态地调度和管理多种 AI 模型与工具。Genspark 在 后台协同运作 9 个专业化的大型语言模型和超过 80 个集成工具，为每个子任 务动态分配最合适的组件。其系统深度集成了 OpenAI 的模型，包括 GPT-4.1 和用于图像生成的 GPT-image-1。其语音智能体功能“Call For Me”则利用 OpenAI Realtime API 实现自然流畅的实时通话，并通过一个独特的双层系统 （由 Realtime API 处理实时对话，一个“影子模型”通过消息队列进行监控和引导）来确保交互的连贯性。此外，Genspark 还发布了自有的“混合智能 体（Mixture-of-Agents, MoA）”系统，并在其 v2 版本中集成了 Gemini 2.0 等 业界领先模型，以追求最佳性能。这种将复杂性作为服务（Complexity as a Service）的模式，是 Genspark 的核心价值主张。用户无需关心底层模型的选 择与工具的调用，平台本身就是那个智能的“调度中心”。

3.4.3. Fellou：Agentic 浏览器及其 Eko 框架

Fellou 是一款智能体浏览器（Agentic Browser），2025 年 5 月 11 日发布，深度融 合了浏览器、机器人流程自动化（RPA）与自主智能体技术，能够精准理解用户的 自然语言指令，并将复杂任务自主拆解为跨网页的自动化工作流，以执行深度搜 索、数据整合及报告撰写等操作。 1) 作为开源基础的 Eko 框架。Eko（Eko Keeps Operating 的缩写）是一个生产 级的开源 JavaScript 框架，专为创建从简单命令到复杂工作流的可靠 AI 智能 体而设计。它是 Fellou 浏览器的技术基石，但也被作为一个独立的开发者工 具提供。Eko 框架的核心特性是其统一的接口，支持智能体在计算机和浏览 器两种环境中无缝运行。它具备多智能体协同、灵活的工具与智能体定制、 人机协同（Human-in-the-loop）干预以及动态选择大型语言模型等高级功能。 Eko 的开源性质及其详尽的文档，使其成为开发者构建自定义 Agentic 工作流 的强大基础。 2) 用于跨应用自动化的“深度行动”工作流。Fellou 浏览器的标志性功能是其 “深度行动-工作流”（Deep Action-Workflow），它允许智能体自主执行跨越多 个应用程序的复杂任务。用户只需给出一个简单的高级指令，例如，“查找下 个月从纽约到伦敦的最便宜航班，预订最佳选项并将其添加到我的日历”，智 能体便会接管浏览器甚至其他桌面应用，自主完成整个多步骤流程。它能够 像人类用户一样“看到”屏幕，点击按钮，填充表单，并在不同网站之间无 缝跳转，全程无需人工干预。此外，用户还可在任务执行中随时进行实时干 预以调整方向，避免重复操作；通过 Deep Action 可视化编辑功能，用户能以 拖拽方式直观地调整步骤，使规划流程完全透明可控。这些强大能力背后是 Eko 框架对浏览器和计算机自动化任务的底层支持。 3) 面向开发者的混合语言设计。Eko 框架从设计之初就强调其“生产级”的可 靠性，并通过一种独特的混合设计语言来满足开发者的需求。该框架允许开 发者同时使用自然语言和传统的编程语言（JavaScript/TypeScript）来编写智 能体。这种设计旨在弥合高级、模糊的任务描述与底层、精确的系统操作之 间的鸿沟，这对于构建商业级的可靠应用至关重要。许多早期的智能体框架 虽然擅长快速原型验证，但在可靠性和确定性上表现不佳。Eko 的混合语言 设计直接解决了这一痛点：开发者可以用自然语言定义工作流的灵活部分， 同时用经过严格测试的代码来控制关键的、不容出错的操作。这种对生产可 靠性的关注，使得 Eko 对于那些希望构建商业化智能体应用的开发者极具吸 引力。

3.4.4. Skywork Super Agents（天工超级智能体）：高效智能 Agent 平台

Skywork Super Agents（天工超级智能体）由昆仑万维旗下“天工 AI 搜索引擎”发 展而来，在历经数次版本迭代后，于 2025 年 5 月 22 日正式发布。作为一款集搜 索增强、多模态生成与复杂任务分解能力于一体的智能平台，Skywork 的核心是 其基于混合专家模型（MoE）构建的智能体（Agent）系统。该系统利用高效的推 理与多任务处理能力，将用户的自然语言指令转化为复杂的自动化工作流，实现 从内容生成到数据分析的全流程赋能。

1) 强大的混合模型架构。Skywork 的核心驱动力是其专有的混合专家模型 （Skywork-MoE），该模型通过动态分配专家模块来处理多样化任务，显著提 升推理效率和准确性。Skywork-MoE 支持多模态输入（如文本、图像），并能 自动优化资源分配，确保在内容生成、代码编写或数据分析等场景中实现高 性能输出。这种架构类似于“复杂性即服务”，用户无需手动配置模型细节， 平台即可智能调度。 2) 一体化 Agentic 工作空间。Skywork 提供了一套垂直整合的智能 Agent 工具， 包括 AI 写作、图像生成和数据分析等功能。这些 Agent 被设计为互联互通， 形成一个闭环生态系统。例如，用户可以通过单一提示启动“AI Writer”Agent 来自动生成文档，或使用“Image Studio”Agent 进行多模态创作。其目标是 让用户专注于意图表达，而非工作流构建，从而提升生产力。 3) 多工具与 API 集成。Skywork 的后台系统支持与多种外部工具和 API 的无缝 集成，如结合 OpenAI 模型或自定义 SDK。通过动态编排机制，Skywork 可 以调用超过 50 个集成工具（包括数据处理和实时通信模块），以处理复杂任 务。例如，在语音交互场景中，Skywork 利用类似“Call For Me”的 Agent 实 现自然对话，并通过双层监控系统确保交互连贯性。

3.4.5. Minimax Agent：具有全栈能力的“靠谱”数字员工

Minimax Agent 是由稀宇极智（MiniMax）研发的 AI 智能体，其核心定位是成为 一个“靠谱”的数字员工。通过一套自研的复杂技术架构，调度多个“专家模型” 协同工作，Minimax Agent 旨在理解用户的复杂指令，并自主规划、执行包含多个 步骤的长程任务，最终交付高标准、可直接使用的成果，将 AI 从被动的问-答工 具转变为真正赋能生产力的主动工作伙伴。 1) “一句话开发”的全栈应用构建能力：2025 年 7 月 16 日，Minimax Agent 正 式上线全栈开发功能。用户仅需用一句话描述需求（例如“帮我做一个类似 Netflix 的电影推荐网站”），Agent 便能自主完成从前端界面设计、后端逻辑 开发、数据库搭建到最终部署的全过程。它不仅能编写代码，还能主动进行 功能测试和 UI 自动化测试，确保交付应用的完整性和可用性。这种端到端的 自动化能力，极大地降低了复杂软件应用的开发门槛。 2) 强大的自主调试与闭环纠错机制：该智能体的核心优势之一在于其强大的自 主纠错能力。在执行任务（尤其是编程任务）时，如果遇到代码执行失败、 环境配置错误或 API 调用不通等问题，Minimax Agent 能够像人类资深开发 者一样，主动阅读和分析错误日志（stack trace），定位问题根源，然后自主编 写新的代码来修复 bug 或解决环境问题，并重新尝试执行。这种“分析-试错 -修正”的闭环工作流，使其能够攻克传统代码生成模型难以处理的动态错误， 从而极大地提升了任务的成功率和交付成果的可靠性。 3) 领先的多模态理解与内容生成生态：Minimax Agent 的能力构建于其强大的 自研多模态基础模型之上。它通过一个名为 MCP（Multimodal Content Provider） 的生态系统，集成了业界领先的文本、图像、音频、视频生成能力。这使其 在执行任务时，不仅能处理和分析文本信息，还能深度理解多种媒体格式的 输入，并一键式地输出图文并茂、音画结合的丰富内容，例如在制作演示文 稿或研究报告时，能自主配图、生成数据图表，甚至嵌入解说音频。4) 面向复杂长程任务的智能“专家模型”调度架构：为了高效、可靠地完成“长 程复杂任务”（Long Horizon Complex Tasks），Minimax Agent 的后台采用了 一套创新的调度系统。该系统会首先将用户的宏观指令拆解成一系列有序的 子任务，然后在执行每个子任务时，根据当前任务的性质（例如，规划、编 码、内容撰写、数据分析、验证等），从其模型库中智能地调用最擅长该领域 的“专家模型”来执行。这种灵活的、各司其职的模块化协作模式，确保了 任务流中每一个环节都能达到最优的输出质量，从而保障了最终成果的专业 性与可靠性。

3.4.6. ChatGPT Agent：融合 OpenAI 最新技术的智能体

OpenAI 于 2025 年 7 月 17 日正式推出 ChatGPT Agent，其核心本能力在于代表用 户在网络上执行复杂的、端到端的工作流，例如预订行程、管理邮件、构建网站 乃至进行深度研究并生成报告。

1) 融合深度研究与自主行动的统一架构：ChatGPT Agent 的核心在于整合了 OpenAI 此前分别推出的两个专业工具：“Operator”和“Deep Research”。 Operator 专注于通过模拟人类交互来浏览和操作网站，而 Deep Research 则擅 长进行多源信息综合与分析。将两者的能力无缝结合，ChatGPT Agent 既能进 行深入的、跨越多个来源（包括公共网站、用户上传的文件和连接的第三方 应用）的研究，又能基于研究结果采取具体行动，如填写表单或编辑电子表 格。

2) 强大的工具集与虚拟计算机：为实现自主操作，该智能体被授予了一个强大 的工具集，并在虚拟计算机中运行。该工具集包括：通过图形用户界面与网 络交互的可视化浏览器、用于简单推理型网络查询的文本浏览器、终端以及 直接 API 访问权限，以及访问公开 API 的能力。这种多工具方法使智能体能 够根据任务的性质选择最高效的执行方式，例如，在需要视觉理解的网站上 使用可视化浏览器，在处理数据时则调用终端。

3) 连接器与第三方生态系统集成：ChatGPT Agent 通过“连接器”（Connectors） 功能，能够安全地访问用户的第三方应用程序，如 Gmail、Google Drive 和 GitHub。一旦用户授权，智能体就可以读取邮件、检索云端文件或访问代码 库，从而将用户的个人和工作数据作为其执行任务的上下文。例如，它可以 根据用户日历和邮件内容来规划会议，或利用 Google Drive 中的文档来创建 PPT。

4) 用户协同与安全控制：ChatGPT 智能体的设计仍确保用户始终处于控制地位。 智能体在执行发送邮件或提交表单等关键操作前会暂停并请求用户确认。用 户可以在一个侧边窗口实时监控智能体的所有行动，并随时介入以修改指令、 暂停或完全终止任务。对于需要输入密码等敏感信息的登录过程，智能体会 提示用户进入接管模式，在此模式下由用户手动输入，期间系统不会记录截 图或密码，以保障账户安全。

3.5. AI Agent 垂直应用

相较于通用 AI Agent 应用，垂直领域的 AI Agent 在软件开发、法律、金融和医疗 等特定的专业场景中深耕。通过在行业数据上进行深度训练、与现有工作流无缝 集成，并将专家知识固化为自动化流程，垂直领域的 AI Agent 了提供更高精准度 和效率，也正因此特性，部分 AI Agent 垂直应用的商业价值已经得到了市场认 定。这标志着自软件即服务（SaaS）兴起以来，企业软件领域最重要的一次进化， 它将对生产力、劳动力结构和价值创造方式产生深远影响。

3.5.1. Cursor：为开发者打造的 AI 原生代码编辑器

Cursor 是一款 AI 代码编辑器，由 Anysphere Inc.公司开发并于 2023 年推出。与作 为现有 IDE 插件的工具不同，Cursor 是一个独立的、AI 原生的编辑器（基于 VS Code 分支开发），其设计从一开始就旨在将 AI 深度融入开发的每一个环节。它将 自身定位为比 Copilot 效率高出至少一倍的工具。截止 2025 年 6 月 6 日，Cursor 宣布其年度经常性收入（ARR）已超过 5 亿美元，被超过半数的财富 500 强企业 采用，并在最新一轮融资中以 99 亿美元的估值筹集了 9 亿美元。 1) “代码库感知”的上下文理解能力：Cursor 的关键差异化优势在于其理解整 个项目上下文的能力。通过输入@符号，开发者可以引用代码库中的任何文 件或符号，并将其直接提供给 AI，从而生成更准确、更相关的代码或修改。 这种由定制检索模型支持的“代码库感知”方法，最大限度地减少了手动复 制粘贴的需求，并使 AI 能够在深刻理解依赖关系的基础上，进行复杂的多文 件代码更改。 2) 智能体化的“Ctrl+K”与自动补全：Cursor 的核心交互模型是围绕其“智能 体”模式构建的，通过 Ctrl+K 进行内联编辑，或通过 Ctrl+I 执行更广泛的任 务。该智能体能够自主运行终端命令，在遇到代码规范错误时循环修正，并 将更改应用到整个代码库。此外，它还配备了一个强大的多行自动补全功能 （“Tab”），能够预测开发者的下一步编辑操作，并根据最近的更改预判出整 个逻辑块。 3) 熟悉的用户体验与企业级就绪：通过构建在 VS Code 的基础上，Cursor 为开 发者提供了无缝的过渡体验，支持所有现有的扩展、主题和快捷键。这极大 地降低了采纳门槛。此外，它通过提供“隐私模式”和 SOC 2 认证，直接解 决了企业的核心关切，确保专有代码在未经同意的情况下不会被远程存储。 4) 技术与架构：Cursor 由“专门构建的前沿模型”混合驱动，即采用了一种混合方法，即在使用来自 OpenAI、Anthropic、Google 等供应商模型的同时，也 使用了自己为编码任务优化的专有模型。其 B 轮和 C 轮融资公告明确提到， 将投资于“系统、模型和产品的前沿研究”，这表明 Cursor 在构建自身技术 壁垒，而非简单封装第三方 API。

3.5.2. Devin：自主的 AI 软件工程师

Devin 是由 Cognition AI 开发的自主 AI 智能体，于 2024 年 3 月 12 日正式推出。 其市场定位是“全球首位 AI 软件工程师”，能够从头到尾处理复杂的工程任务。 在与 Nubank 合作的一个大型代码重构项目中，Devin 实现了 12 倍的工程效率提 升，成本节约超 20 倍。截止 2025 年 3 月，该公司已获得 40 亿美元的估值。 1) 端到端的自主任务执行：Devin 的核心能力在于接收一个高层次的任务指令 （例如来自 Jira 工单的功能需求），然后自主执行一个完整的计划。这包括通 过阅读文档来学习不熟悉的技术、编写代码、构建和部署应用程序，以及自 主发现并修复其中的错误。 2) 集成的开发环境与工具使用：Devin 在一个隔离的沙盒环境中运行，并内置 了独立的 shell、代码编辑器和浏览器。这使其能执行人类开发者的各种操作， 例如安装依赖、运行测试、以及在网上搜索信息来解决问题。 3) 人机协同的工作流程：直接与 Jira、Linear 和 Slack 等项目管理工具集成，允 许通过标签或提及（@）的方式分配任务。Devin 会提供一个实时的执行计划 供人类审查，测试自己的代码变更，并最终提交一个拉取请求（Pull Request） 供人类批准。该工作流在自动化繁琐工作的同时，将最终的控制权交还给开 发者，这对于企业采纳十分重要，因为它结合了 AI 的速度与人类的监督和质 量控制。 4) 技术与架构：Devin 是一个专有的、闭源的 SaaS 产品。尽管其具体的底层模 型并未公开，但其展现出的能力表明，它建立在一个复杂的前沿大语言模型 编排系统之上。Cognition 对 Windsurf 的收购，以及其创始团队在竞争性编程 和在 Google DeepMind、Cursor 等公司的应用 AI 经验，都表明其在定制模型 开发和智能体架构方面的深度投入。

3.5.3. Kasisto：金融服务领域的可信智能体

AI Kasisto 提供一个名为 KAI 的“可信智能体 AI 平台”，该平台专为金融服务行业量 身打造，已被摩根大通和西太平洋银行等全球性银行部署。通过自动化和主动参 与来削减运营成本并增加收入，其设计宗旨是超越简单的对话式聊天机器人，以 执行智能操作、主动与客户互动并确保严格的合规性。 1) “零幻觉”的多智能体架构：KAI 平台的一个核心特性是其“零幻觉”承诺， 这是通过一个多智能体架构实现的。KAI 不依赖于单一的庞大模型，而是协 调多个协同工作的专业 AI 智能体。这使得任务可以并行处理，并对输出进行 交叉验证，从而显著提高了贷款申请或欺诈检测等复杂、多步骤金融工作流 的准确性和可靠性。 2) KAI-GPT 与行为个性化：该平台由 KAI-GPT 驱动，这是一个专有的、结合 了 Kasisto 自有模型和 GPT 技术的大语言模型，并针对银行业的语言和流程 进行了专门的训练和微调。这与一个“行为引擎”相结合，该引擎分析真实 的金融行为模式，以提供主动和个性化的客户互动，例如根据客户过去的行 为预测其资金转移的需求，或根据其交易历史推荐储蓄产品。 3) 全面的解决方案套件（客户、坐席、员工辅助）：Kasisto 提供了一套针对金 融机构内不同用户群体的解决方案。Customer Assist 为银行客户提供全天候的自助服务。Agent Assist 和 Employee Assist 由 KAI Answers 组件驱动，为 人工坐席和银行员工提供由生成式 AI 驱动的对机构内部知识库、政策和程 序的即时访问。

3.5.4. Harvey：专为法律领域打造的专业

AI Harvey 是专为法律行业设计的 AI 平台，旨在变革法律研究、文档分析和起草等 工作流程。自 2022 年成立以来，其增长迅速，获得了超过 5 亿美元的融资，估值 达到 50 亿美元（截止 2025 年 6 月 23 日），并吸引了包括顶级律所和拜耳（Bayer） 等企业法务部门在内的超过 235 家企业客户。 1) 集成的多组件平台：Harvey 并非单一任务工具，而是一个由四个核心集成组 件构成的综合平台。Assistant 提供了一个对话式界面，用于起草和分析；Vault 是一个安全的项目工作区，用于存储和分析数千份文档；Knowledge 模块支 持复杂的法律研究，并提供准确的引用；Workflows 是由多模型驱动的 Agent， 可自动化处理尽职调查或合同审查等复杂的法律流程。这种集成设计使律师 能够在一个单一、安全的环境中无缝地从研究过渡到分析再到起草。 2) 工作流构建器与专业知识的固化：Workflow Builder 作为自助服务工具，允许 法律团队在不编写代码的情况下创建定制的、由 AI 驱动的工作流。律所能够 将其独特的、专有的专业知识和流程编码到平台中。例如，一家律所进行并 购尽职调查的特定方法可以被转化为一个可复用、可扩展的工作流。 3) 企业级安全性与领域专用模型：Harvey 建立在信任和安全的基础之上，利用 Microsoft Azure 进行数据处理和存储，这对高度管制的法律行业非常重要。 其 AI 模型并非通用模型，而是建立在 OpenAI 的 GPT-4 之上，但经过了针对 大量法律专用数据集（包括判例法、法规和多语言法律语料库）的进一步定 制和微调。这种领域专用的训练，结合从律所自有文档中学习的能力，确保 了其在处理法律任务时比通用模型具有更高的准确性和上下文相关性。

3.5.5. Dragon Medical One：高精度临床记录员

Dragon Medical One 是由 Nuance（现为微软子公司）推出的基于云的、由 AI 驱动 的语音识别解决方案。作为临床医生的对话式工作流助手和文档伴侣，在该领域 具有领先地位。目前拥有超过 55 万名临床医生用户，受到 77%的美国医院的信 赖。该解决方案能够将临床文档记录时间减少 50%，并连续五年（2021-2025 年） 被评为 KLAS（医疗 IT 领域的一个关键基准）排名第一。 1) 强大的语音识别与临床文档记录：Dragon Medical One 的核心功能是提供高 精度的、实时的临床口述转录，并直接录入电子健康记录（EHR）。它无需初 期的语音配置，利用自动口音检测技术，确保高准确性，这一核心功能可为 临床医生节省 50%的文档记录时间。 2) 深度 EHR 集成与工作流自动化：除了简单的听写，Dragon Medical One 还深 度集成到 Epic、Cerner 和 MEDITECH 等主流 EHR 系统中。允许临床医生使 用语音命令来导航 EHR、下达医嘱、签署病历以及执行其他常见任务。 “AutoText”功能允许为重复性笔记创建声控模板，进一步简化了工作流程 并减少了点击次数。 3) 安全、便携且多模态：作为一种基于云的解决方案，临床医生的语音配置文 件可在医院内的任何工作站上使用。PowerMic Mobile 应用程序可将任何智 能手机变成一个安全的无线麦克风，实现在移动中记录文档。这种灵活性和 便携性非常适应快节奏的临床环境。且所有数据都经过企业级安全处理，这 是医疗应用的基础保障。

4. AI Agent 的挑战与系统性风险

当前 AI Agent 的发展仍面临一些挑战和风险，其中包括：规划与推理能力脆弱， 因“幻觉”和无法识别不可行目标而导致推理链断裂；有限的上下文窗口和低效的 外部记忆检索机制构成了严重的记忆瓶颈，限制了其处理长期复杂任务的能力； 模型固有的幻觉问题可能会被放大，导致事实不可靠，对高风险应用的可靠性构 成致命威胁；在多 Agent 协同中，信息丢失、控制冲突和低效沟通普遍存在，易 引发系统性混乱；现有的评估体系无法全面衡量 Agent 在成本、安全、鲁棒性等 真实世界维度上的综合能力，严重阻碍了其发展和部署。

4.1. 规划与推理挑战：推理链的脆弱性

AI Agent 的核心价值在于其自主完成复杂任务的能力，但这高度依赖于其规划与 推理的质量。然而，当前 LLM-based Agent 在面对复杂任务时，常出现“推理链 断裂”和“抽象思维不足”的问题，且自我纠错能力有限。对 LLM 规划能力的大 量研究综述揭示了其内在的脆弱性。这些失败源于 LLM 作为规划器时固有的几 种缺陷： 首先是规划幻觉。LLM 在规划时可能会生成不可行的动作或不存在的对象，这直 接导致推理链在与现实环境交互时发生断裂。其次，LLM 在识别不可达目标方面 表现不佳。一个完备的规划器在面对一个无法实现的目标时，应能识别其不可行 性并终止规划。然而，即便是顶尖的 LLM（如 GPT-4）也常常因为幻觉问题，无 法准确判断一个规划问题是否无解，从而构建出错误的规划路径。最后，LLM 规 划出的路径往往是次优的。LLM 在路径规划等任务中常常生成不必要冗长的计划， 这可能是由于模型本身存在的长度偏见，这种偏见与人类追求效率、简洁和低认 知负荷的偏好相悖。

4.2. 记忆约束：上下文窗口与检索失灵

尽管 LLM 通过其上下文窗口具备了一定的短期记忆能力，但这对于需要处理长 期、复杂任务的智能体而言，已成为严重的技术瓶颈。智能体在与环境的持续互 动中会产生大量的观测、思考和行动历史，这些信息对于后续决策至关重要。然 而，当这些交互记录的长度超过了 LLM 架构（如 Transformer）的上下文窗口限 制时，智能体将截断或遗忘早期的关键信息，从而丧失利用过去经验进行反思和 决策的能力。 记忆的挑战并不仅限于上下文窗口的物理长度。即便采用了外部记忆数据库等扩 展方案，如何从海量的历史数据中高效、准确地提取出与当前决策最相关的记忆， 本身就是一个极为复杂的问题。随着智能体经验的积累，其记忆库会变得异常庞 大，低效或错误的记忆检索机制可能导致智能体做出与当前情境不符的、次优的 行动，从而影响任务的整体表现。

4.3. 事实不可靠：幻觉与脆弱性

幻觉（Hallucination）即模型生成看似合理但与事实不符或完全捏造的内容，是 LLM 固有的问题。在 AI Agent 中，这一问题被显著放大，并构成了对其可靠性 的致命威胁。当 Agent 的行动是基于一系列连续的推理步骤时，链条中的任何环 节出现幻觉，都可能导致整个任务流程被彻底带偏。例如，用于软件开发的智能 体如果在一个步骤中“幻觉”出不存在的函数库，其后续的所有代码生成和调试 工作都将建立在错误的基础之上，最终导致任务失败。 这种内在的不可靠性使得完全自主的智能体在处理高风险、严肃的现实世界应用 时显得异常“脆弱”和不可信。在科学研究、医疗诊断或金融分析等需要深厚领 域知识和严格事实准确性的专业领域，幻觉问题尤为致命。在能够有效抑制幻觉之前，将关键决策完全托付给完全自主的 AI Agent 仍存在巨大风险。

4.4. 多 Agent 协同挑战：系统性的混乱

当任务复杂度提升，LLM-MAS 成为重要方向，但协同本身也引入了新的系统性 挑战，主要体现在信息与控制的崩溃，以及流程与目标的低效。 首先，在信息层面，上下文丢失问题普遍存在。多 Agent 间的密集交互会迅速填 满 LLM 有限的上下文窗口，导致关键的早期指令或中间结论在传递中丢失，形成 “信息断链”，使后续 Agent 在不完整的背景下做出错误决策。这源于管理复杂和 分层上下文信息的困难，Agent 需要同时对齐总体任务、自身角色以及其他 Agent 的动态输入，这极易导致信息过载。与信息丢失相伴的是控制层面的权限不清。 当多个 Agent 试图同时修改同一共享资源（如文件或数据库条目）时，若无成熟 的控制机制，便会引发任务冲突、数据覆盖和执行混乱。这是源于缺乏分层记忆 存储和访问控制，即系统无法有效区分所有 Agent 都可访问的“共识记忆”和单 个 Agent 的私有敏感信息，从而带来严重的数据完整性和安全风险。 其次，在流程与目标层面，多智能体系统面临协同效率低和终止条件模糊的困境。 许多系统严重依赖自然语言作为 Agent 间的交互媒介，这种方式不仅速度慢、信 息密度低，还容易产生歧义。此外，现有的 MAS 普遍采用顺序执行模式，导致 Agent 轮流工作而其他 Agent 处于闲置状态，造成了巨大的计算资源浪费和时间 开销。对于许多开放式或探索性的复杂任务，系统很难预先定义一个明确的“完 成”标准。这导致多智能体系统常常陷入无休止的“死循环交互”中，Agent 之间 反复传递信息、进行辩论，却始终无法收敛到一个最终满意的结果。这种现象深 刻地反映了当前 MAS 在全局规划和工作流设计上，普遍缺乏一个协调器来引导 Agent 群体走向最终目标。

4.5. Agent 评估的困境：无法衡量真正的能力

尽管 AI Agent 的发展日新月异，但科学、全面地评估其能力，却已成为一个严重 的瓶颈。现有的评估方法往往无法捕捉智能体在真实世界中取得成功所必需的关 键属性，导致对智能体的真正能力和局限性的理解存在偏差。 当前用于评估 LLM-based Agent 的基准测试和框架存在一个根本性问题：混淆简 单的 LLM 聊天机器人与 AI Agent 之间的区别，未能有效评估后者所独有的、在 与环境动态交互中体现出的高级能力。许多基准测试过度关注最终任务的准确率 或成功率，这种评估虽然提供了一个粗粒度的性能信号，但却无法揭示智能体为 何成功或为何失败。一个 Agent 可能仅因为运气或通过一种极低效、不安全的方 式完成了任务，但这些在最终结果中都无法体现。 对于智能体在现实世界中的部署而言，许多重要的维度在当前的评估体系中被严 重忽视了。例如，成本效益。智能体在完成任务过程中的资源消耗（如 API 调用 次数、token 使用量、计算延迟等）很少被纳入评估指标。这导致研究可能偏向于 开发能力强大但成本高昂、不切实际的系统；安全性与鲁棒性。基准测试普遍缺 乏对智能体合规性、可信度以及抵御对抗性输入能力的全面测试。这使得我们无 法在部署前充分了解其在面对恶意攻击或非预期输入时的表现；可复现性。由于 某些智能体行为的非确定性，其性能表现难以稳定复现，这给不同方法之间的公 平比较带来了巨大挑战。

5. AI Agent 的未来趋势

AI Agent 的发展正朝着更高级的形态演进，其能力上下限由不断迭代的 LLM 决 定；随着视觉、听觉等多模态感知能力的提升，将实现对物理与数字世界的更深更全面的理解；在商业化路径上，高精度、高可靠性的垂直领域专用 Agent 将率 先落地，为企业创造实际价值；软硬件生态的重塑将催生为 Agent 设计的全新技 术栈，实现从手动操作到 Agent 自主协同的范式转变；AI Agent 被视作通往通用 人工智能（AGI）的关键路径，尽管实现 AGI 的具体方法仍在探索中。

5.1. 基础 LLM：决定 Agent 能力上下限的关键

AI Agent 的能力上下限，本质上由其“认知核心”即基础 LLM 所决定。Agent 的 规划、记忆和行动等所有模块，都是围绕 LLM 的能力进行构建与发挥。目前各家 大模型提供商都在快速迭代，每次迭代都伴随各项高难度基准上的性能提升，这 种提升将直接转化为 Agent 更强的自主任务执行能力。 未来，Agent 能力的突破将依赖于其核心 LLM 的持续进化。这一进化体现在多 个层面：更优的模型架构，能够支持更复杂的推理和规划；专用硬件的持续迭代 将提供更强大的算力支持，加速从训练到部署的全过程；同时，推理成本的大幅 下降将使得更强大的模型得以普及，以便拓展到更广泛的应用场景。

5.2. Agentic AI 重构软硬件生态

Agentic AI 的崛起正在重塑计算平台，其核心趋势体现在硬件革新与软件范式的 双重转变。专为 Agent 打造的、从底层芯片到顶层应用的全新 Agent 技术栈将形 成：硬件层面，边缘计算的进步将使 LLM 得以在个人设备上高效运行，例如在可 穿戴设备上运行 AI 接听电话助手。边缘计算将为这些设备带来低延迟和高隐私 性优势；在软件层面，交互范式将从手动调用工具转变到 Agent 自主协同。用户 不再需要一步步操作软件，而是直接向 Agent 提出最终目标，由它作为智能中枢 来分解任务、并自主调用和协同各类软件工具完成全流程操作。

5.3. 多模态发展：迈向物理与数字世界感知的普及

AI Agent 正在从纯文本交互向融合视觉、听觉和物理世界感知的多模态智能体演 进。AI Agent 的能力进化，得益于多模态大模型的飞速发展。这些模型能够同时 理解和处理来自不同“感官”（如文本、图像、音频、视频）的信息，从而对世界 形成更全面、更准确的认知。此外，具身智能的发展也意味着 AI Agent 将能够通 过传感器（如摄像头、麦克风）感知物理环境，并作出实际的交互和行动。

5.4. 垂直 AI Agent 应用和 AI Agent 平台：商业化落地加速

随着企业智能化转型的深入，对 AI Agent 应用和开发平台的需求将持续升温，低 风险高精度的 AI Agent 垂直应用和 AI Agent 开发平台商业化进程将加速。尽管 通用 AI Agent 应用更受关注，但率先在商业领域实现规模化落地并带来可衡量投 资回报（ROI）的，将是专注特定行业的垂直类 AI Agent 应用。与通用 AI Agent 应用相比，垂直 AI Agent 应用的优势在于高精度、高可靠性以及对特定领域工作 流的深度理解（Know-how），而这些特性对于企业来说是至关重要的。垂直 AI Agent 应用的成功案例已遍及多个行业。这些应用通过解决具体痛点，为企业带来 了切实的效率提升和成本节约，也为 AI 技术的企业采纳起到了推动作用。通过在 单一、可控的场景下证明价值，逐步建立企业内部对 AI Agent 的信任和使用能力， 未来将面向更广泛、更复杂的 AI 部署。 对于 AI Agent 开发平台，能提供低风险和高精度解决方案的供应商将更受欢迎。 低风险意味着开发平台必须提供企业级的安全保障、严格的权限管控和清晰的合 规性框架，确保 AI Agent 的行为可追溯、可审计；而高精度则要求 Agent 不仅能 执行任务，更能基于企业内部的私有知识库进行精准决策和可靠行动，最大限度 地避免事实错误和业务流程偏差。

5.5. 终极问题：通往 AGI 的方向

AI Agent 与通用人工智能（AGI）的关系是当前人工智能研究的核心议题。Agent 被看作是通往 AGI 的“有前途的载体”，因为它将 LLM 被动的知识能力，与感知、 行动、交互和学习等动态能力相结合，是迈向通用智能的关键一步。然而，关于 这条路具体该如何走，仍存在不同看法。规模化路径和架构创新路径是比较主流 的两种观点：规模化路径认为通过在足够大规模、多样化的数据上训练，LLMbased Agent 可以自发涌现出 AGI 所需的能力；架构创新路径则认为当前 LLM 架 构存在根本性缺陷，无法真正“理解”世界，需要研发包含世界模型等新组件的 新型智能架构。

编辑：火腿肠