编辑部 整理自 AIGC2026
量子位 | 公众号 QbitAI

当全民都在“养龙虾”的时候,真正的问题才刚开始浮现。

在刚刚结束的2026中国AIGC产业峰会上,亚马逊云科技产品技术部技术总监王晓野带来了一组直观数据:

87%的企业宣称已经大规模部署了AI,而真正从中获得价值的,只有10%

很显然,Demo从来都不难做,难的是让它在企业生产环境里真正跑起来。



在他看来,个人在Mac mini上跑一个好玩的Agent、随时可以拔电源重启,和让几千个Agent在企业分布式环境里安全、可信、不中断地稳定运行,完全是两个维度的工程复杂度。

这场分享还用最硬核的工程视角直击了企业痛点——

别再指望靠一个模型去搞定所有事了。

算力够不够划算、数据安不安全、Agent会不会玩失忆或记忆串台……从底层基础设施到上层应用,每一层都是必须硬啃的真问题。

为了完整体现王晓野的思考,在不改变原意的基础上,量子位对演讲内容进行了编辑整理,希望能给你带来更多启发。

2026中国AIGC产业峰会是由量子位主办的行业峰会,近20位产业代表与会讨论。线下参会观众超千人,线上直播观众近400万,获得了主流媒体的广泛关注与报道。

核心观点梳理

以下为王晓野演讲原文:

企业级Agent落地的四大鸿沟与落地体感

大家上午好!非常感谢量子位的邀请。

我今天演讲的主题叫《跨越Agent落地鸿沟:从模型到企业级AI Agent落地》

跟前面几位嘉宾分享的方式不太一样,我会直白一些,也会通过一系列产品和案例,跟大家分享我们对企业级Agent落地的思考。

作为一家长期服务全球客户的科技企业,亚马逊云科技一直在通过云服务支持数百万企业客户,今天我也想借由我们产品更新背后的思路,跟大家聊聊:真正把Agent落到企业生产环境时,企业需要回答哪些问题。



过去几年,无论是Agent产品,还是Agent构建框架,都可以说层出不穷。

但真正能够在生产环境里大规模、稳定运行的Agent,其实寥寥无几。这里面到底存在怎样的差距?

接下来我会结合亚马逊云科技跟客户一起实践、总结出来的经验,通过一些产品能力更新,来分享我们的答案。

我们先快速看一下AI现在的大趋势。

过去我们经常会先跟客户聊AI应用的use case,也就是它到底能用在什么场景。

但相信很多细分场景大家已经很熟悉了,如果往大的方向总结,大致可以看到几个方向。

第一类是AI生成音频、视频、音乐,这些方向已经走得非常前沿,大家每天都能感受到日新月异的变化。

第二类是基础模型,从语言模型开始,大家真正感受到了AI的力量,同时也意识到这件事可能还有一段路要走。

第三类是具身智能

我们从具身智能企业的变化中可以看到,去年大家还更多关注动态控制,今年已经明显转向——如何收集数据,如何跟物理世界形成感知,再形成行动反馈。

还有一个更火、也可以说离成熟更接近的方向就是Agent

今天我会聚焦在Agent这个话题上,因为它离企业真正落地更近。从落地的角度来看,Agent是当前最值得重点讨论的方向。

相信很多嘉宾都反复提到了养龙虾在中国已经成为一个非常火热的话题,很多个人用户都在尝试,全民都在养龙虾,甚至有新闻提到深圳的工程师会帮个人用户安装、配置这些工具。

但个人养龙虾和企业养龙虾是两件事。

个人环境里,配置好之后可能很少需要再去改动;但在企业环境里,你能不能让几千个Agent在企业环境中安全、可信地运行起来?背后其实有不少鸿沟需要跨越。

首先是模型选择和响应速度

企业出于性价比考虑,也因为模型能力每天都在快速变化,所以需要及时响应模型变化,并且能够在多个模型之间灵活选择。

第二是构建复杂度

云时代我们都知道,一个分布式系统要长期稳定运行,本身就是非常困难的事情。

一个能跑在Mac mini上的龙虾,个人用户可以随时拔电源、重启;但到了企业生产级场景,它能否可靠、稳定地运行,能否自动重启且不中断,能否可信地处理数据,就完全是另一层工程复杂度。

第三是使用门槛

无论是Hermes,还是龙虾,还是其他自主性Agent,对工程师来说,使用门槛已经比过去传统IT系统低很多。

但对于业务人员来说,比如营销、HR等岗位,他们能否真正把这些工具用起来,依然存在门槛。

第四是人才gap

前面提到的很多问题,最终都需要人来解决,需要企业里的平台部门把AI能力赋能给整个组织。

但今天具备端到端推动Agent落地能力的人才,依然有很大缺口。

三个礼拜前,在亚马逊云科技全球发布中,亚马逊云科技CEO Matt Garman也分享了几个观点。

第一,他认为AI和Agent带来了极大的市场构建范式变化,很多应用都应该被重新改造一次。

这句话听起来可能很熟悉,但今天再看,味道已经跟过去不一样了。

过去我们更多是在畅想未来,但今天我们是基于已经看到的事实,基于企业里已经落地的东西,来表达这样的观点。

Matt还有一句话,我个人也非常认同。他认为,过去30年里,个人生产力其实从来没有被真正大规模颠覆过。

大家回想一下,无论是使用Office,还是使用各类通信软件,软件本身一直在迭代,但我们的工作方式并没有发生太大的变化。

但今天Agent的出现,尤其是大家使用龙虾后的体感,会让人明显感受到:我们确实走到了一个节点,个人的工作方式正在发生变化。

在讲趋势之前,我们先用几组数据找一下感觉。

Gartner的分析显示,从2028年到2030年,会有超过15%的企业日常工作决策由Agent或AI自主完成。

这里说的不是人辅助决策,而是由Agent完全自主地完成决策,也不只是帮人执行任务。

一些关于劳动力的研究报告也提到,在2026年到2028年期间,82%的企业领导者表示会增加雇用“数字员工”的比例,为企业服务,而不只是招聘人类员工。

麦肯锡的分析则显示,Agent以及生成式AI带来的增量商业市场规模,可能从2.6万亿美元增长到4.4万亿美元,接近翻倍。

那这是不是炒作?

我们再看一些实际企业通过调研反馈回来的数据。

同样是麦肯锡的报告提到,今天已经有87%的企业宣称实现了AI在公司里的大规模生产部署,而一年前这个数字还是78%,进展非常快。

同时,德勤的一些报告也反馈,真正把AI用到生产系统的企业中,确实有一部分企业反映生产力获得了收益。

这些信号听起来可能有些矛盾,但本质上都在说明同一件事:今天AI Agent在企业层面的渗透率已经很高,但真正获得价值、走到生产层面的比例仍然有限。麦肯锡同一份报告里也提到,这个比例可能只有10%左右



像龙虾这样的Agent,让我们看到了河对岸长什么样。但企业要真正走到生产落地,中间还需要一座桥。

今天我想通过一些产品能力更新,来跟大家分享这座桥应该长什么样。

从Demo走向生产的那座桥

简单来说,亚马逊云科技认为,企业IT平台和企业技术决策者真正推动Agent从Demo走向生产时,需要关注五大能力

第一层是AI Agent所需的算力

如果回到Agent这个话题,算力可能更强调推理部分。过去我们更多讨论训练算力,但Agent场景对推理算力的需求会更加突出。

第二层是模型

企业需要能够快速获取行业前沿模型,或者是最适合自身场景的模型,同时还要具备很高的性价比。

第三层是数据和知识

Agent虽然把回答问题转变成了行动能力,但就像炒菜一样,如果没有企业知识这类“独家配方”,它永远只能做出西红柿炒鸡蛋这类大众化动作,真正进入企业流程时,Agent需要的是企业自己的数据和知识。

第四层是Agentic平台

今天大家已经越来越清楚,AI不只是模型能力,Harness也至关重要。

第五层是Agent应用

并不是所有事情都需要企业自己构建,很多通用能力已经可以通过垂直、专用或通用Agent应用的形态直接采购和使用。

接下来我会按照这五层展开,分享我们在产品设计理念上如何思考这些问题。

先看AI基础设施这一层。今天我们仍然在讨论Token消耗量、讨论延迟,背后的潜台词是什么?

就是企业在性价比上还没有达到可以随意使用的状态。这有点像早年大家会计算一条短信多少钱,而不是像今天发微信一样,完全不需要考虑成本。

所以最底层能够帮助企业降本增效的能力,应该来自算力层的大量优化

亚马逊云科技的优势来自20多年服务云客户的经验。我们服务了几百万客户,也知道客户在云上跑什么样的负载。

即使是推理,我们也会关注这个Agent是更多以规划为主,还是以执行简单任务为主,或者更倾向于Workflow。

针对这些不同负载,大家其实会有一个共识:

通用芯片无法在所有场景中都提供最好的性价比。

亚马逊云科技从十几年前就开始自研芯片,把一些虚拟化技术通过硬件能力实现;之后又推出基于Arm的CPU计算Graviton,目前已经走到第五代;再到专用AI芯片Trainium,也已经走到第三代。

简单来说,在计算这一层,我们认为客户应该享受到面向具体场景的最优性价比计算能力

模型这一层,我们秉承的观点很多年来都没有变:

客户和企业需要的是选择,而不是被绑定在一个模型上。

Amazon Bedrock也是通过不断扩大模型能力来支持这一点。包括中国一些优秀模型,比如智谱GLM、MiniMax的模型,我们都在积极推进上架到Bedrock平台。



当然,在企业语境下,Bedrock除了提供平台能力,更重要的是提供企业数据保护和隐私保护

整个平台基于20多年云计算积累下来的信任能力,企业可以通过云上的VPC等技术,保证自己的数据不会被中间的一些路由工具截取或获得。

数据和知识这一层,我们认为今天需要看到一个变化:传统的数据平台、数据底座或数据基石,过去主要是服务于人的;但今天,企业平台部门和技术部门需要关注的是,数据平台能否服务好AI Agent

Agent对数据的调用方式跟人类不一样。我们面对的可能是数十亿个Agent的规模,一次任务也可能带来无数次调用。

因此企业真正需要的是一个AI-ready的数据平台,这会带来跟过去传统数据平台非常不同的挑战。

结合我们跟客户共创的经验,可以举几个例子。

第一是记忆的共享、隔离与并存

当企业里几千个不同用户、不同Agent同时使用时,既需要大家拥有一定共享记忆,同时又不能串台。

如何通过企业传统授权和权限管理,把记忆的共享、隔离、长短期管理都做好,是非常重要的事情。

第二是记忆生命周期管理

很多人会认为记忆存得越多越好,但其实并不是。就像人一样,如果长期记忆里有错误知识、老旧信息,甚至有自相矛盾的知识,都会影响Agent最终的判断,这也是为什么长期记忆管理非常重要

记忆的生命周期管理,是对底层数据引擎提出的新挑战。

还有就是Token使用效率

大家都在关注Token消耗多、Token贵,但真正导致Token贵的,很大一部分原因容易被忽略:并不只是Token单价贵,而是你在调用模型时喂给了模型太多没用的信息。

比如把几千个skills一股脑扔给模型,让它自己去选;又比如在抽取和提取记忆时,没有优化好最终喂给模型的信息。这些都会导致Token使用量爆炸。

反过来说,在全链条上,我们能不能观察到模型是怎样被调用的?能不能观测到它是否产生幻觉?这种全链路可观测性,也是AI-ready数据平台需要满足的新能力。

如果总结我们在构建数据产品时秉承的理念,可以分成三大基座。

第一是面向AI-ready,同时坚持可信。

除了云语境下端到端的静态数据加密、传输中数据加密和安全保证之外,真正让数据可信,还需要清楚了解数据代表的业务意义——

它是如何产生的,是由Agent自进化而来,还是由业务输入而来;它在全链路中如何影响决策。

对于数据可解读、可管理、可治理的需求,我们试图通过SageMaker Catalog等能力来解决。

第二是底层数据引擎不应该成为上层Agent应用的阻碍,因此需要有卓越的数据底层。

展开来说,就是可信可靠、性能、性价比和持久性等能力,都需要保持在很好的水平。

亚马逊云科技这些年也通过丰富的数据经验,在引擎层不断优化。

这里举一个例子,今天在几乎所有数据引擎里,我们都支持向量能力。

为了适应Agent大规模扩展,我们也推出了S3 Vectors,把11个9持久性的对象存储原生支持到大规模向量检索和存储中。

第三是坚持开放的数据架构,不应该形成任何数据技术厂商锁定或技术锁定。

比如在数据湖、多模态数据湖以及治理理念上,我们会围绕Iceberg这样的开放结构,推出S3 Tables,允许不同数据引擎进行访问。

最近由于Agent被广泛使用,大家也知道,无论是管理记忆,还是管理一些其他文件,很多时候都是通过文件系统、Markdown文件等方式实现的。

我们也通过开放方式,让对象存储直接支持相应的文件语义,让Agent可以直接调用。

这些都是我们在产品设计中的一些理念,未来也会有更多对客户数据能力的支持。

从企业级Harness平台到智能化工作应用

接下来这一层,是我更想重点分享的内容。

除了模型之外,企业构建Agent需要的是一整套走向生产的能力

两年前我也曾在这个舞台上分享过类似信息,我们一直传递的观点没有变:

AI真的不只是大模型这一件事。

到了2026年,在Agent语境下,大家通过使用龙虾,通过感受软件工程能力,已经更清楚地意识到,把模型拿掉之后,剩下所有关于生产、控制、管控的生产级要求,都可以叫做Harness,也就是如何驾驭它。

打个比方,如果把模型看作CPU,那么真正使用电脑时,没有人会把一块焊着CPU的主板直接给用户用。

我们还需要软件、操作系统,以及各种可使用的能力,Harness就是把这些可使用、可操作、可管控的能力放在一起,最终让Agent呈现为一个完整应用形态。

对应到亚马逊云科技的产品,Harness就是Amazon Bedrock AgentCore。



它的核心价值,是让用户不用在Harness上花太多功夫,而是关注自己的业务价值。同时它保持开放,可以接入开源框架,比如LangChain、CrewAI等,都可以自由集成。

它也管理企业需要考虑的大规模安全、稳定、自重启、可靠性等生产级需求。

如果把Bedrock AgentCore的九大功能模块快速分成三类。

第一类是让Agent跑起来

Runtime提供自动横向扩展能力,让Agent可以按照任意规模快速扩展;Memory管理记忆和上下文;Code Interpreter和Browser则给Agent加上调用浏览器、操控代码等能力。

第二类是让企业里的数据和系统真正接进来

Identity和Gateway允许企业把现有系统,比如CRM、ERP等很好地集成进来,同时还能继承员工使用这些系统时的真实权限。

Agent执行任务时代表的是具体员工,而不是一个拥有无限的管理权限。

第三类是让Agent真正管得起来、管得住

通过Policy、Evaluation和Observability等功能,企业可以在Agent执行任务时设置边界,评估执行结果是否达到预期,并对整个过程形成可观测能力。

前一阵,我们也跟OpenAI进行了官方联合发布,把提供给企业直接使用的Agent构建能力再往上升一级,加入由OpenAI提供支持的Managed Agent。



可以这样理解:如果大家认为ChatGPT已经远远不只是聊天机器人,而是一个可以帮你执行任务的不错Agent,那么Managed Agent就是由OpenAI提供前沿模型,也由OpenAI提供他们在构建Agent过程中积累的最佳实践Harness,再结合亚马逊云科技底层安全基础设施体系,打包形成的一套能力。

如果企业更希望通过OpenAI的能力来执行任务,可以直接采用这个方案。

相比之下,Bedrock AgentCore提供更加开放灵活的Agent框架选择和模型选择。

但不变的是,这两类能力都在同一个平台上,企业可以同时选择,并继承亚马逊云科技针对企业安全和信任的管控与保护。

这里也快速引用一个客户案例,紫讯采用AgentCore后,解决的核心问题是:他们不需要过度规划自己的计算资源,可以更经济地快速迭代,也不需要投入大量精力优化底层Harness需要处理的生产工程问题。

这样企业可以更快实现业务价值,同时更好地做成本优化,把精力放在自己的业务诉求上。

Agent应用的落地与展望

最后一层,是企业直接使用Agent应用时需要讨论的问题:

谁来用?怎么用?

Coding Agent大家已经普遍认为比较成熟了。

但在工作场景下,Working Agent也是我们认为下一个会爆发、会被广泛使用的方向,因为我们已经看到了这类能力。

这里有一个矛盾的问题是:员工希望Agent什么事都帮自己做,了解自己的日常,了解自己的信息;企业则希望员工安全地使用Agent,希望有管控,不能让Agent什么事都做。

这两者其实可以兼得。

在亚马逊云科技,我们的答案是通过Quick这样的深度个性化产品来实现。

简单来说,最近我们听到同事分享最多的一句话是:它真的像日常小助手一样。

我快速分享几个自己的体验。

第一,我每天会在CRM、聊天工具、邮件和各种平台之间切换,早上可能要花20分钟到1个小时清理需要处理的任务。

Quick的主动提醒功能,能把这些连接汇聚在一起。它不只是提醒我有哪些事情,还会主动建议我应该给某位同事约一个会,或者给另一位同事做某件事。

第二,它真正执行任务时,能够帮我们打破传统工作的边界。

比如今天这份PPT里,有很多需要外部确认的调研数据。过去我可能要花很多时间咨询各位同事,现在通过Quick很快就可以完成。

第三,它在帮我规划任务时,会随着我的使用不断沉淀。

每个人在使用时都会形成个人知识图谱,随着使用越来越多,它的决策也会越来越像我,以上是我认为Quick带来的几个非常值得关注和体验的点。

最后简单总结一下,我们通过这五层能力,想分享的是:企业真正把Agent从Demo带到生产,需要关注哪些点。

这里也可以重新回顾一下我们跟OpenAI的联合发布。

除了刚才提到的Managed Agent,也包括OpenAI最前沿的模型在Bedrock上可用;同时,它的Coding Agent Codex也在Bedrock上可用。

也就是说,在我们五层架构里的三层,通过跟OpenAI的合作都有了新的能力升级。

未来,在这五层能力上,我们也会持续迭代产品,加速对企业的赋能。

简单来说,我们希望做的事情,就是让更好的模型,通过可信的数据,真正把生产级平台带给用户。

Matt Garman说,每一个应用都将会被重构。

我们确实已经看到领先企业走在这条路上,也希望通过五层架构的不断迭代,跟大家一起加速重构,拥抱Agent时代,谢谢大家。