开云体育,开云体育官方网站,开云体育APP下载微软 CEO Satya Nadella 高调宣称：“我们所知的 SaaS 时代即将结束……Agent 将成为核心驱动力”。而 Salesforce CEO Marc Beinoff 则直接嘲讽微软的 Copilot，称其为“Clippy 2.0”：“根本不起作用，而且没有任何准确性”。Clippy（回形针）即 Office 虚拟助手，是微软上世纪推出的基于规则的代理，为用户吐槽最多的失败设计之一。

　　大模型公司或云资源提供商大多支持这种“通用”入口性质的路线。比如 OpenAI 就肯定倾向于 Nadella 的思路，因为在它看来，所有的 Agent 本质上都是对其大模型能力的延伸和增强。对 OpenAI 来说，构建通用 Agent 能将所有应用集成在自己的能力框架之下，使其成为一个统一入口。类似的例子还有 Manus，以及 AutoGLM 沉思等。无论是微软、OpenAI，还是 Manus、沉思，这背后体现的，依然是一场关于“谁来掌握 AI 入口权”的竞争。

　　从 Salesforce 架构师的公开演讲 来看，Einstein Copilot 在与用户进行交互时使用的是“Chain of Thought”（思维链）模式，而 Agentforce 的一个关键进展，就是用 React prompting 替代了效果不好的传统的思维链。其次是引入 Topic 分类机制，解决 Copilot 在对话过程中难以将任务限定在某个特定的范围内的问题。然后是改进了 LLM 的响应方式，Copilot 直接返回未经处理的后端数据，导致用户难以理解，而 Agentforce 则会利用 LLM 对原始数据进行自然语言包装，使其更易读懂。最后是引入了主动触发能力，与 Copilot 依赖用户主动发起对话不同，Agentforce 希望实现基于特定数据库操作的自动触发，无需用户干预即可启动 Agent 执行任务。

　　微软对 Agentic AI 的设想是“OS”级别的变革。它构想中的 AI 操作系统不仅要能够调度多个智能体，还要持续保持上下文状态、理解用户意图，并在多种数据源和系统能力之间进行协调。在这一架构中，业务逻辑将由 Agent 全面接管，而“状态管理器”（State Manager）被视为 AI 操作系统的核心组件——只有具备对用户状态的持续记忆，Agent 才能真正理解用户是谁、在做什么、希望实现什么目标，类似于 AI 世界中的“内存管理”。为此，微软正在打通自身所有产品线，并与 OpenAI 这样的企业合作，构建一个开放的智能体生态平台。

　　郭炜认为，甚至 Nadella 所描述的“代理程序在多个数据库之间工作”的设想，还不够 Agentic AI。因为在这一新范式下，整体的技术框架都会要被重新设计。传统数据库的设计初衷，是为了服务于“人类决策”的时代。从数据库到数据仓库，所有的设计都是上个世纪，为了辅助人类做决策、完成信息记录而构建的。于是我们看到了复杂的 CRUD 操作、DAO 层、数据库层、数据仓库层以及 ETL 流程，它们共同支撑起了人与数据之间的交互逻辑。

　　AWS Agentic AI 主任科学家章毅也赞同整个技术架构生态体系会被重构，他进一步指出，当前 Agent 利用 API 调用已有的数据库系统进行知识查询和整合（典型 RAG 架构）能够覆盖一些基本的业务逻辑，但是知识、信息碎片化（以不同模态和格式存储于多个数据库中）对 AI Agent 高效搜索、链接、归纳、提炼、使用与更新信息带来很大的困难。这必然会带动对数据存储、管理系统进行重新思考和设计。

　　微软设想的“AI 操作系统”中，状态管理的关键在于让 AI 能够跨不同的应用和设备记住信息，并需要有一种结合短期交互与长期语义记忆的机制。这实际上是将来 Agentic AI 时代替代数据库地位的关键组件，然而在实际架构层面，挑战远超预期。也有观点认为这并不是一个简单的“状态管理”，而是是在云端为每个用户构建一个“虚拟人生”——系统需要持续记录用户的行为、偏好与选择，形成大模型的短期记忆和长期语义。问题在于，这种能力无法用向量将它描述清楚，并且目前还不知道可以用什么技术实现。

　　更重要的是，所谓“通用”与“垂直”的两条路线，从产业实践来看，并非互斥，而是根据不同企业的战略优势进行差异化布局。微软聚焦平台型能力，将 Agent 集中于 Copilot 品牌下统一推进，同时也不放弃在 Microsoft 365 等具体场景中的垂直落地。Salesforce 以 SaaS 为核心，在 CRM 等场景深耕垂直 Agent，同时借助 Agentforce 等平台工具，向多云生态拓展。平台化和垂直场景的结合，正成为行业主流趋势。

　　当业务流程仅涉及少量节点时，编排复杂度尚在可控范围内。然而当节点数量增长至 10 个、20 个甚至 100 个量级，且涉及多系统、API 和工具的协同工作时，确定正确的线性执行顺序（如 ABCDEFG... 或 ACBDEFG...）将面临组合爆炸问题——100 个节点的全排列组合达 100! 种。每新增一个节点，系统复杂度将以阶乘级数倍增，这种非线性增长特性使得大规模编排系统极易产生级联错误。正如李飞博士指出的：“当编排网络中出现单个节点顺序错位时，整个拓扑结构的执行逻辑都将发生系统性偏差。”

　　如今的大模型在各种基准测试中表现越来越好，但要真正实现具备自主性的 Agent 系统，还存在不小的挑战。Google首席科学家 Jeff Dean 刚好在 4 月底的一次演讲中透露了目前大模型实际能力：当前模型大致能以 60% 到 70% 的准确率，完成三到五步的小任务，能在有限范围内调用工具处理一些简单请求。但真正理想的智能体，应当能够面对模糊而复杂的目标，自主拆解并完成上千个步骤，完成相当于一个月人类工作量的任务，且准确率达到 95%。

　　如果按当前国内大模型的标准报价（如 0.0008 元 / 千 token）折算，这“每次 2 美元”的对话，意味着系统可能要消耗接近 1800 万 token。这不仅意味着成本高昂，也从侧面反映出任务流程可能执行起来极其复杂。一旦规模化使用，成本压力会骤然放大：以一家中型企业为例，1000 名员工、每人每天调用 10 次，每天光软件费就超过 2 万美元，月支出高达 60 万美元。有从业者直言：“比传统软件贵多了。”

　　技术部署要看“性价比”。李飞直言：“如果不是十倍时效，这个场景的意义其实不大”。也就是说，如果原来 20 小时能完成一个任务，现在 Agent 缩短到 10 小时，效率虽提升了一倍，但不足以支撑 AI Agent 高昂的部署成本，其实企业很可能不买账。特别是在企业端，Agent 本质上是对业务流程的自动编排，必须依赖业务与技术的深度协同：业务人员提供流程知识，技术人员将这种 Know-how 嵌入 Agent 开发中，才能让 Agent 真正融入企业工作流。

　　目前一些企业已经准备好了部署 Agent，但“通用 Agent”更适合 C 端用户。因为 C 端的容错性更高，“这个任务不行就换下一个”，但企业不能容忍任务中断或出错，一旦流程关键环节失败，就可能影响整个业务判断。“在企业当中，大部分工作都是严谨的，你这个任务给我执行错了或者执行不出来，我就认为你这个软件不行。”因此，企业更倾向从垂直场景做起，把 Agent 深度嵌入到已有业务流程中，通过产品设计和流程兜底，把错误率降到最低，才能真正达成企业级可用。“垂直 Agent 在今年其实已经准备好了采购”，但不同领域成熟度差异较大，最终落地效果也存在显著差异。同时还应优先选择容错性相对较高的任务切入，比如在“研报分析”这类允许人工校验和干预的内容生成任务，避免一上来就部署端到端决策系统，“Human-in-the-loop”机制可以显著降低幻觉和错误的风险。

　　在全球范围内，亚马逊是最早系统化推动 Agentic AI 的企业之一。从 Alexa 的智能化重构、“Buy for Me” 融入购物体验，到 Amazon Q 面向开发者的代码助理，再到电商目录处理、合规审核，或者服务于公司员工的 HR 信息系统，Agent 技术已在其多个业务线并行推进。从这些项目中，可以看到亚马逊“全面拥抱 AI agent 技术的明显趋势”。正如章毅所说：“公司各个业务部门都非常重视 AI Agent 可能带来的机遇和挑战，所以有各类并行的、针对不同应用场景的尝试。”值得一提的是，亚马逊对 Agent 架构持开放态度，并不执着于单一标准化框架。AI agent 作为一个新兴的领域，技术架构仍然有很大的不稳定、不确定性，新生框架鳞次栉比。有的框架诞生不到六个月，时间长的也不过只有两年多。在它们成熟、演化、归一的过程中，亚马逊会对这些框架灵活应用。

　　不过，中国软件市场定制化需求多，因此生态不如海外 SaaS 软件标准，“哪怕是用 Salesforce 模式做的 Agent，也需要千人千面的定制开发。整体来看，在中国没有出现大型全球性软件企业生态之前，中国本土 Agent 还是在沙滩上的楼阁。先做好软件，再说软件上的自动化。”总的来说，对国内开发者和企业来说，从 App Stack 到 Agent Stack 的转变，是一次前所未有的“弯道超车”的机会。