Agent 正在成为 2025 年 AI 世界最炙手可热的关键词之一。
无论是大模型厂商、AI 初创公司，还是企业级应用团队，几乎都在讨论“多智能体协作”“自动化决策流程”以及“具备工具调用能力的 AI 系统”。
谷歌、英伟达等科技巨头纷纷布局，上个月亚马逊还成立了一个专注于 Agentic AI 的新部门，初创公司们也争相推出各类“Agent”产品。开源社区也不甘示弱，从 LangGraph 到 Agent SDK、AutoGen、CrewAI，一波 Agent 框架竞相登场，掀起了继大模型之后的第二轮工具潮。
连大厂掌门人也开始在公开场合“互呛”。
微软 CEO Satya Nadella 高调宣称：“我们所知的 SaaS 时代即将结束……Agent 将成为核心驱动力”。而 Salesforce CEO Marc Beinoff 则直接嘲讽微软的 Copilot，称其为“Clippy 2.0”：“根本不起作用，而且没有任何准确性”。Clippy（回形针）即 Office 虚拟助手，是微软上世纪推出的基于规则的代理，为用户吐槽最多的失败设计之一。
言辞之锋利，背后其实是对 Agentic AI 两种截然不同落地路径的分歧。
一条是微软 Nadella 倡议的“面向全平台的智能代理框架”路线。按照他们的设想，未来将出现一个 AI 操作系统，能够调度多个智能体，并且这些智能体可以在整个企业内无缝地传递任务、消息和知识。
Nadella 认为，这是一场从“App Stack”到“Agent Stack”的根本性变革。过去，我们依赖前端 UI 驱动的应用形态，每一个业务场景都被拆分为独立的 App，用户通过操作完成任务。未来，主导者将是 Agent，它能感知用户意图，基于数据、模型和推理链条，完成决策和自动执行。
在这种架构转变下，当前的 SaaS 等应用因为其本质上是嵌入商业逻辑的数据库，未来这些逻辑会被 Agent 接管，由 Agent 去做增删改查，在多个数据库之间工作，所有的逻辑都会转移到 AI 层。而一旦 AI 层成为主导，背后的数据库最终也会开始被替代。
本质上，这是微软构建通用人工智能代理体系、通过底层架构向企业应用生态渗透的战略布局。正如数势科技 AI 负责人李飞博士在分析中指出，微软此举旨在依托其既有生态系统优势，打造覆盖全场景的 AI 接入平台，形成对垂直领域应用的聚合效应。通过构建人工智能交互的核心枢纽，微软试图确立其在产业智能化转型中的顶层平台地位，实现对各类专业化应用的系统性整合。
大模型公司或云资源提供商大多支持这种“通用”入口性质的路线。比如 OpenAI 就肯定倾向于 Nadella 的思路，因为在它看来，所有的 Agent 本质上都是对其大模型能力的延伸和增强。对 OpenAI 来说，构建通用 Agent 能将所有应用集成在自己的能力框架之下，使其成为一个统一入口。类似的例子还有 Manus，以及 AutoGLM 沉思等。无论是微软、OpenAI，还是 Manus、沉思，这背后体现的，依然是一场关于“谁来掌握 AI 入口权”的竞争。
与之相对，另一条路线则由 Salesforce 所代表。
Salesforce 的思路是从现有企业软件栈出发，强调以垂直领域（如 CRM）为根基，推动业务逻辑的 AI 原生重构。他们不认为 AI 会“取代”现有 SaaS 应用，而是主张 AI 和 SaaS 深度集成，将 Agent 机制嵌入业务流程中，通过业务数据和流程去驱动 Agent 的运行和决策。Agent 不是一个外部工具或统一入口，而只是整个流程当中的一个节点。
相较于微软自底而上的通用化策略，Salesforce 的设计思路是自顶向下，从实际的业务流程出发，反向构建 Agentic AI 能力，旨在复用并增强现有的各类 SaaS 应用。
事实上，许多没有庞大通用平台基础、专注于 ToB 软件或垂直场景的企业，可能会更倾向于 Salesforce 这种贴近业务、务实的路线。他们往往是先搭建好业务或工作流程，然后将 Agent 融入这些流程中，使其专注于解决特定垂直场景的问题。
哪种路径更具可行性？
贴补丁式 Agentic，能落地但改不了旧系统的命
Salesforce 的 CEO 对微软 Copilot 的攻击颇为犀利，甚至直言这是“微软的一场巨大灾难”。他公开表示，自己与多位微软客户交流后发现，“他们并没有发现自己因为这项 Copilot 技术而发生了改变，很多人几乎没怎么使用这个功能”。相比之下，Salesforce 则宣称其平台每周处理多达两万亿笔企业 AI 交易。
有意思的是，Salesforce 自家的平台最初也叫 Einstein Copilot。更耐人寻味的是，在弃用“Copilot”这个名称后，Benioff 便开始公开批评微软的 Copilot 产品。并且 Salesforce 坚称，从 Einstein Copilot 更名为 Agentforce，绝不仅仅是换了一个名字，而是其底层架构也经历了重要的调整。
从 Salesforce 架构师的公开演讲 来看，Einstein Copilot 在与用户进行交互时使用的是“Chain of Thought”（思维链）模式，而 Agentforce 的一个关键进展，就是用 React prompting 替代了效果不好的传统的思维链。其次是引入 Topic 分类机制，解决 Copilot 在对话过程中难以将任务限定在某个特定的范围内的问题。然后是改进了 LLM 的响应方式，Copilot 直接返回未经处理的后端数据，导致用户难以理解，而 Agentforce 则会利用 LLM 对原始数据进行自然语言包装，使其更易读懂。最后是引入了主动触发能力，与 Copilot 依赖用户主动发起对话不同，Agentforce 希望实现基于特定数据库操作的自动触发，无需用户干预即可启动 Agent 执行任务。
可以说，早期的 Einstein Copilot 侧重于通过对话触发和调用预设的比如销量预测等算法，实现人机协作。而 Agentforce 的目标似乎是转向更自主的任务执行模式，用户设定目标后，系统能够自主规划并执行工作流程，最终呈现结果。
因此，尽管 Salesforce 强调这是架构的演进，但其核心仍然是提升 AI 在任务执行中的自主性和智能化水平。
不仅如此，Beinoff 还评价微软是“快速追随者”，并称：“他们肯定会像往常一样想抄袭我们，向我们靠拢。但我们现在已经有数千客户在实际使用我们的产品。”
根据截至 3 月的最新数据显示，双方的 Agent 都有大规模的落地，Salesforce 宣称拥有约 15 万名客户，微软则表示已有 16 万客户，基于 Copilot 打造出了 40 万个 Agent。
然而，白鲸开源 CEO 郭炜一针见血地指出，当前微软的 Agent 只是个人用户辅助工具，和 Nadella 技术路线里要实现的最终理想，并不是同一个东西。
微软对 Agentic AI 的设想是“OS”级别的变革。它构想中的 AI 操作系统不仅要能够调度多个智能体，还要持续保持上下文状态、理解用户意图，并在多种数据源和系统能力之间进行协调。在这一架构中，业务逻辑将由 Agent 全面接管，而“状态管理器”（State Manager）被视为 AI 操作系统的核心组件——只有具备对用户状态的持续记忆，Agent 才能真正理解用户是谁、在做什么、希望实现什么目标，类似于 AI 世界中的“内存管理”。为此，微软正在打通自身所有产品线，并与 OpenAI 这样的企业合作，构建一个开放的智能体生态平台。
而 Salesforce 的 Agentforce，“它都不是行业智能体，只是 CRM 生态线的智能体。目前技术手段都实现了个高级版本 RPA/ 按键精灵，只不过通过大语言模型交互可以自动做一些分拆动作，做一些组合罢了。
和当年移动互联网出来时候的塞班操作系统一样，属于早期‘婴儿’版本的 Agentic AI。”
当前 Salesforce 模式虽能被快速推广落地，但是这件事情的门槛也不高，很多创业公司都可以做到类似的事情，大公司就更不用说了。
这些做法本质上仍停留在对原有软件和交互流程的增强层面，就像当年微软试图将 Windows 系统移植到手机上一样——看似容易实现，但并不是最优解。真正开启移动互联网时代的，是 iPhone 和 iOS 的诞生，它们从底层重新定义了系统与用户之间的交互逻辑。
正因如此，Nadella 才会提出“所有软件和 SaaS 都将被重构”的观点，因为他预见到了 Agentic AI 时代的来临。如果我们只是把 Agent 嵌入到现有软件中去打补丁，就像是把 Windows 装在手机上——表面上可行，但远未触及这场变革的真正核心。
真正的 Agentic AI 将倒逼整个技术体系重建
短期来看，复用现有 SaaS API 或许是 Agentic AI 实现功能落地的捷径，对现有流程体系的冲击也相对较小。然而，从长期视角出发，Nadella 所代表的观点显然更具颠覆性：大模型和 Agent 的到来会彻底重塑整个软件和 SaaS 生态。
郭炜认为，甚至 Nadella 所描述的“代理程序在多个数据库之间工作”的设想，还不够 Agentic AI。因为在这一新范式下，整体的技术框架都会要被重新设计。传统数据库的设计初衷，是为了服务于“人类决策”的时代。从数据库到数据仓库，所有的设计都是上个世纪，为了辅助人类做决策、完成信息记录而构建的。于是我们看到了复杂的 CRUD 操作、DAO 层、数据库层、数据仓库层以及 ETL 流程，它们共同支撑起了人与数据之间的交互逻辑。
然而，在 Agent 成为主要用户的背景下，这些为“人类使用”而生的复杂数据处理体系是否仍然必要，正面临质疑。未来的存储不一定是数据库形式了，使用的方式也必然不是 SQL 了。
顺着 Satya 的逻辑推演，被重塑的不只是 SaaS，更是整个技术架构生态。数据库技术，甚至是基础理论会被倒逼升级，传统的 No-SQL，New-SQL 都不适用于未来 Agentic AI 的场景。就像从软件工程学角度来看，所有的软件设计都是从 Use Case（UML）图开始设计的，而 User 都变了，凭什么底层的技术还是原来的技术体系呢？
AWS Agentic AI 主任科学家章毅也赞同整个技术架构生态体系会被重构，他进一步指出，当前 Agent 利用 API 调用已有的数据库系统进行知识查询和整合（典型 RAG 架构）能够覆盖一些基本的业务逻辑，但是知识、信息碎片化（以不同模态和格式存储于多个数据库中）对 AI Agent 高效搜索、链接、归纳、提炼、使用与更新信息带来很大的困难。这必然会带动对数据存储、管理系统进行重新思考和设计。
而且，作为 AI 操作系统的核心的记忆层“能否实现”也是未知数。
Salesforce 的 Agentforce 架构在预设的业务流程中，Agent 可以有效地访问和利用先前操作产生的数据和状态信息，形成一种上下文记忆。但一旦进入微软所设想的跨系统、跨复杂场景环境，Agent 就没有一个稳定的获取记忆的依托点，出错概率显著增加，显然比 Salesforce 这种嵌入式设计的难度系数大。
微软设想的“AI 操作系统”中，状态管理的关键在于让 AI 能够跨不同的应用和设备记住信息，并需要有一种结合短期交互与长期语义记忆的机制。这实际上是将来 Agentic AI 时代替代数据库地位的关键组件，然而在实际架构层面，挑战远超预期。也有观点认为这并不是一个简单的“状态管理”，而是是在云端为每个用户构建一个“虚拟人生”——系统需要持续记录用户的行为、偏好与选择，形成大模型的短期记忆和长期语义。问题在于，这种能力无法用向量将它描述清楚，并且目前还不知道可以用什么技术实现。
可以说，微软的 Agentic AI 代表了一种技术理想主义。
虽然很多厂商在尝试，但这个模式整体还太早，大模型和 Agent 本身都还没有进化完全。当前阶段，更现实的路径是 Salesforce 式 Agent，其类 RPA 的特性使其更容易被企业接受。毕竟，在当下，企业更愿意为确定性买单。
但长期来看，传统企业软件终会被取代，因为软件只不过是规范流程，信息传递，实现多人协同的一种方式，如果有更先进的更高效的管理和交流模式，旧有模式一定会替换。今天的企业软件形态必然会被颠覆，这正如固定电话被移动设备取代、再被微信等应用彻底重构通讯方式一样。Agentic AI 时代会是一个和移动互联网一样的全新的时代。
不过，这需要的是一次自底向上全套生态的改变，挑战不亚于当年的“云原生”转型，甚至更甚。这种全模式的创新，或许只有在底层信息科学取得突破之后，才有真正实现的可能。
“MoE”是个折中选择
微软式的通用 Agent 路线，听起来诱人，但在现实中目前还行不通。而在大模型的最新演进中，已经出现越来越多转向 Mixture of experts（MoE）架构的趋势。
MoE 背后的理念正是将任务拆分给更擅长的“专家”，而不是试图构建一个无所不能的模型。
如果在大模型里大家能接受 MoE 的思想，那么，同样的道理，在实现 Agent 的时候，也一样可以采用这种方式：不是打造一个“超级大脑”，而是强调分工协作、各尽其职。
而且，当前现实来看，因为 Agent 能力太弱，还是多个专科 Agent 来做比较合适，例如 Salesforce 的 Agent、SAP 的 Agent 等等。
就算未来的 Agent 即使是基于一个“超级大脑”的路线，这个“大脑”中也必然存在多个并行的、具有不同专属能力的组件，而不是靠一个模型包打天下。事实上，哪怕使用少数甚至是同一个基础模型，构建多个专家 Agent 并通过高效协同完成复杂任务，无疑是一个有效的设计范式，是同大模型能力提升演化协同共进、互补互助的方法。
更重要的是，所谓“通用”与“垂直”的两条路线，从产业实践来看，并非互斥，而是根据不同企业的战略优势进行差异化布局。微软聚焦平台型能力，将 Agent 集中于 Copilot 品牌下统一推进，同时也不放弃在 Microsoft 365 等具体场景中的垂直落地。Salesforce 以 SaaS 为核心，在 CRM 等场景深耕垂直 Agent，同时借助 Agentforce 等平台工具，向多云生态拓展。平台化和垂直场景的结合，正成为行业主流趋势。
打平台牌需要非常大量的固有成本。对于中小企业而言、迅速找到垂直 Agent 应用并落地，会是更重要的当务之急。
从“能不能做”到“做得成、做得起”
回顾 Agentic AI 近两年多的发展，我们看到，行业正经历着从对大语言模型的初步探索，到逐步赋予其感知、理解和行动能力的关键阶段。
从最初直接依赖 LLM 进行信息处理，逐步演进到利用检索增强生成（RAG）技术来扩展其知识覆盖范围。随后，多模态模型的出现使其能够处理更丰富的输入和输出形式。
紧接着，行业进入了“Agentic 对话”阶段，核心在于赋予模型执行动作的能力，使其不再仅仅是内容生成工具。为模型添加可执行功能被视为一个重要的里程碑。
关于 Agentic AI 最早的雏形，存在两种主要观点：一种认为是 OpenAI 推出的“Function Call”功能，它使得大模型能够根据需求调用外部函数。另一种观点则认为，真正的更早出现的 AutoGPT，因为 Function Call 并不是一个完整的链路。AutoGPT 是在 OpenAI 的 ChatGPT (GPT-3.5) 发布后，由 Toran Bruce Richards（苏格兰爱丁堡人工智能公司 Significant Gravitas Ltd. 的创始人兼首席开发者）在 2023 年 3 月份创建的演示项目，展示了如何利用大型模型实现任务的自动分解和执行。
此后，Agent 的完整生态闭环首次被较为系统地提出，这要归功于 OpenAI 研究员 Lilian Weng 在 X（原 Twitter）上分享的 Agent 工作流程文章，清晰地描绘了包括“目标规划、工具调用、执行、结果反思”等关键环节，被认为是 Agent 架构逐步演进的重要起点。受此启发，业界围绕 AI Agent 展开了大量的探索与实践，并逐渐形成了更为系统化的工程方法。
数势科技的 Agent 系统演进，也反映了 Agent 技术自身的发展历程。其系统经历了从 1.0 到 3.0 的迭代：初期的 1.0 阶段，主要实现了单个 Agent 对数据工具的调用。进入 2.0 阶段，系统引入了与环境交互的反馈机制，并强化了自我反思与迭代能力。发展到 3.0 阶段，则根据用户需求，从单 Agent 升级为多 Agent 协作机制，以覆盖更广泛的场景和角色。
Agentic AI 还有哪些挑战？
当前，Agentic AI 系统构建中，任务编排依然是极具挑战的技术难题。
相较于 Salesforce 等平台采用的预定义工作流模式（其泛化性受限），微软提出了通过 AI 实时理解规则并动态生成编排规则，进而连接现有 API 的设想。但真正落地时，问题远比想象中复杂。
当业务流程仅涉及少量节点时，编排复杂度尚在可控范围内。然而当节点数量增长至 10 个、20 个甚至 100 个量级，且涉及多系统、API 和工具的协同工作时，确定正确的线性执行顺序（如 ABCDEFG… 或 ACBDEFG…）将面临组合爆炸问题——100 个节点的全排列组合达 100! 种。每新增一个节点，系统复杂度将以阶乘级数倍增，这种非线性增长特性使得大规模编排系统极易产生级联错误。正如李飞博士指出的：“当编排网络中出现单个节点顺序错位时，整个拓扑结构的执行逻辑都将发生系统性偏差。”
基于实际构建 Agent 的经验，合理的工作流编排是核心难点。一旦工作流得以确定，后续 API 的输入输出参数便相对固定。因此，能否实现准确高效的工作流编排，直接关乎 Agentic AI 系统的可靠性。
尽管如此，Agentic AI 根本性的进步仍然依赖于底层大模型能力的提升。“大模型基座本身有错误率，Agent 和软件其实是在给大模型的错误率或者幻觉去做兜底的。”因此无论上层应用多么创新，如果底层模型能力没有显著进步，系统所能解决的问题依然有限。
如今的大模型在各种基准测试中表现越来越好，但要真正实现具备自主性的 Agent 系统，还存在不小的挑战。Google首席科学家 Jeff Dean 刚好在 4 月底的一次演讲中透露了目前大模型实际能力：当前模型大致能以 60% 到 70% 的准确率，完成三到五步的小任务，能在有限范围内调用工具处理一些简单请求。但真正理想的智能体，应当能够面对模糊而复杂的目标，自主拆解并完成上千个步骤，完成相当于一个月人类工作量的任务，且准确率达到 95%。
从现在的能力到这一目标之间，仍有巨大差距。这一演进过程可能会经历多个阶段——从胜任 3～5 步的任务，提升到能够稳定完成 10 步以上的流程，最终迈向真正具备规划、执行、反馈能力的智能体系统。
章毅则进一步指出，目前的前沿大模型中能够全面达到打造具有高智能、高自主性 Agent 要求的选择并不多、甚至可以说非常少。
即便是在大模型服务平台如 AWS Bedrock 提供了多个主流模型（如 Claude、LLaMA、Amazon Nova、Mistral Mixtral 等等）供开发者选择的背景下，真正能够满足构造 Agent 能力要求的模型还是主要局限于 Anthropic Claude 的几个最新版本（Sonnet 3.5/3.7 或者 Haiku 3.0/3.5）。
从短期落地的可行性角度看，聚焦一个或少数几个前沿大模型会得到比较好的投资回报率。
“每次对话 2 美元”
“节省数百万美元”“一半客服被 AI 替代”——这类故事，已经成为 AI 圈标配的营销剧本。Salesforce 和微软正是靠这样的案例，推广他们的智能 Agent 系统。
这些故事构建了一个极具吸引力的愿景：AI 代理系统不仅能显著提升效率，还能直接压缩运营成本，甚至重塑组织结构。但真正落地到企业环境中，很多人才发现，这场变革的代价远比想象中高。
以 Salesforce 的 Agentforce 为例，其官网宣传“每次对话 2 美元起”。但在实际合同中，超出 1000 次免费额度的部分，会按每次 2.50 美元收费。也就是说，虽然预购有折扣，但一旦使用超额，就需要按每次 2.50 美元支付。相比微软 Copilot 那种更强调“按有效消息计费、结果导向” 的模式，Salesforce 更像是“按次数定额收钱”，不管任务是否真正成功完成。
如果按当前国内大模型的标准报价（如 0.0008 元 / 千 token）折算，这“每次 2 美元”的对话，意味着系统可能要消耗接近 1800 万 token。这不仅意味着成本高昂，也从侧面反映出任务流程可能执行起来极其复杂。一旦规模化使用，成本压力会骤然放大：以一家中型企业为例，1000 名员工、每人每天调用 10 次，每天光软件费就超过 2 万美元，月支出高达 60 万美元。有从业者直言：“比传统软件贵多了。”
对于像 Dow 这样有能力重构系统流程的大企业而言，AI Agent 可能真能创造“几百万美元的节省”；但对大多数公司来说，这种奇迹并不容易复刻。节省成本的路径，远比那些营销故事复杂。
这也引出了一个更现实的问题：企业到底该怎么上 Agent？
你的企业该怎么上 Agent？
对大多数企业来说，“要不要上 Agent”其实早就不是问题了。一旦基础系统和生态完备，未来 Agentic AI 就像移动互联网一样蓬勃发展。技术领袖的共识也正在浮现：AWS 等云厂商认为 AI Agent 将会重新定义云服务的未来，明确将 Agent 定位为“下一代基础设施”，提供模型托管、推理算力以及致力开发针对 AI Agent 的可重用组件和功能模块。
但越是全行业热捧的趋势，越需要冷静评估其落地的现实条件。
“不是十倍提效，就不值得上。” 技术部署要看“性价比”。李飞直言：“如果不是十倍时效，这个场景的意义其实不大”。也就是说，如果原来 20 小时能完成一个任务，现在 Agent 缩短到 10 小时，效率虽提升了一倍，但不足以支撑 AI Agent 高昂的部署成本，其实企业很可能不买账。特别是在企业端，Agent 本质上是对业务流程的自动编排，必须依赖业务与技术的深度协同：业务人员提供流程知识，技术人员将这种 Know-how 嵌入 Agent 开发中，才能让 Agent 真正融入企业工作流。
“通用 Agent，不适合企业。” 目前一些企业已经准备好了部署 Agent，但“通用 Agent”更适合 C 端用户。因为 C 端的容错性更高，“这个任务不行就换下一个”，但企业不能容忍任务中断或出错，一旦流程关键环节失败，就可能影响整个业务判断。“在企业当中，大部分工作都是严谨的，你这个任务给我执行错了或者执行不出来，我就认为你这个软件不行。”
因此，企业更倾向从垂直场景做起，把 Agent 深度嵌入到已有业务流程中，通过产品设计和流程兜底，把错误率降到最低，才能真正达成企业级可用。“垂直 Agent 在今年其实已经准备好了采购”，但不同领域成熟度差异较大，最终落地效果也存在显著差异。同时还应优先选择容错性相对较高的任务切入，比如在“研报分析”这类允许人工校验和干预的内容生成任务，避免一上来就部署端到端决策系统，“Human-in-the-loop”机制可以显著降低幻觉和错误的风险。
“不要急着全部用 Agent。”“现在的 Agent 就像当年的 Windows Phone。”郭炜给出了一个务实的策略：不要过早的迷信于现在的 agent，先采用 RPA+Agent 模式来实现企业内部流程自动化，等待外部技术条件成熟（10 年 +），在开始考虑公司全面 Agent 化。
“不执着于单一的架构范式。” 在全球范围内，亚马逊是最早系统化推动 Agentic AI 的企业之一。从 Alexa 的智能化重构、“Buy for Me” 融入购物体验，到 Amazon Q 面向开发者的代码助理，再到电商目录处理、合规审核，或者服务于公司员工的 HR 信息系统，Agent 技术已在其多个业务线并行推进。从这些项目中，可以看到亚马逊“全面拥抱 AI agent 技术的明显趋势”。正如章毅所说：“公司各个业务部门都非常重视 AI Agent 可能带来的机遇和挑战，所以有各类并行的、针对不同应用场景的尝试。”
值得一提的是，亚马逊对 Agent 架构持开放态度，并不执着于单一标准化框架。AI agent 作为一个新兴的领域，技术架构仍然有很大的不稳定、不确定性，新生框架鳞次栉比。有的框架诞生不到六个月，时间长的也不过只有两年多。在它们成熟、演化、归一的过程中，亚马逊会对这些框架灵活应用。
“Agent 是个日新月异的领域，保持灵活性而不迷信某一种架构，将会是更务实的做法。”对于正处于数字化转型关键阶段的企业，建议从具体场景出发，快速构建 Agent 原型并验证可行性。他提醒，尽管开发门槛已降低，但有效的评测机制仍是选型与演进的关键。
相比之下，中国企业在 Agentic AI 落地上正面临不同的挑战与机会。
从落地模式来看，郭炜认为目前大多数中国企业更倾向于 Salesforce 式的“融合”路径，而非微软式的“重构”：“我个人希望中国可以像新能源车一样，在 Agentic AI 上通过重构实现弯道超车，颠覆传统软件。但是当前仍缺少一些基础信息学理论的突破，因此融合模式更现实，也更容易落地。”
不过，中国软件市场定制化需求多，因此生态不如海外 SaaS 软件标准，“哪怕是用 Salesforce 模式做的 Agent，也需要千人千面的定制开发。整体来看，在中国没有出现大型全球性软件企业生态之前，中国本土 Agent 还是在沙滩上的楼阁。先做好软件，再说软件上的自动化。”总的来说，对国内开发者和企业来说，从 App Stack 到 Agent Stack 的转变，是一次前所未有的“弯道超车”的机会。
写在最后
AI 技术的演进史，总在狂热与反思的交织中螺旋上升。
两年前，微软投入数十亿美元以及大量人力打造 Microsoft Copilot，宣称它将成为“新一代的开始菜单”；与此同时，向量数据库 Pinecone 一举拿下 1 亿美元融资，VC 们争相下注，仿佛“新数据库时代”已经到来。
但现实很快泼下了一盆冷水。预装在 15 亿台 Windows 设备中的 Copilot，其月活用户量却始终徘徊在 ChatGPT 的 5%，最终迫使微软放弃 Copilot 键的唯一性，允许用户将其恢复为传统菜单键。而向量数据库也在短短半年内从“下一代数据库”沦为通用功能模块，初创公司估值迅速回落。
时间到了 2025 年，Agentic AI 站上新的风口。回望 Copilot 和向量数据库的发展，我们不禁要问：这一次，那些看似前景光明的技术，能否真正落地生根，摆脱昙花一现的命运，成为推动下一轮 AI 革命的关键引擎？
文章来自于“InfoQ”，作者“Tina”。