When the "Agent Era" Arrives: Traditional Enterprise Transformation, the End of Software Companies, and Wall Street's "Underestimation"

当 AI 智能体取代人类成为企业软件的 “主要用户”，传统 SaaS 的商业模式、API 调用计费以及企业的算力成本结构，即将迎来一场指数级的颠覆与重构。

4 月 8 日，a16z 发布深度行业访谈的播客内容，播客主播 Erik Torenberg 对话知名云存储公司 Box CEO Aaron Levie、前微软高管及知名投资人 Steven Sinofsky，以及 a16z 合伙人 Martin Casado，就 “AI 智能体” 时代下的企业软件变革、算力成本激增以及华尔街的定价模型误区展开了激烈讨论。

（从左到右依次：Erik Torenberg、Steven Sinofsky、Aaron Levie、Martin Casado）

云存储公司 Box CEO Aaron Levie 提出了一个核心假设：

如果你拥有的智能体数量是人类的 100 倍或 1000 倍，那么你的软件必须为智能体而构建。

这意味着，软件的交互界面正从面向人类的 UI（用户界面）转向面向 AI 的 API（应用程序接口）、CLI（命令行界面）或计算机使用（Computer Use）。

企业级软件的逻辑，正在从 “人类使用工具” 演变为 “智能体调用系统”。

然而，由于大型企业的合规摩擦与 IT 预算体系的僵化，AI 在真实商业环境中的渗透速度或将不及预期，但其最终爆发的市场规模，将远远超出当前资本市场的测算。

打破华尔街的 “零和思维”，SaaS 商业模式的增量空间

在市场普遍担忧 AI 可能摧毁传统 SaaS 商业模式时，与会嘉宾给出了截然不同的研判，认为现有的财务模型完全算错了这笔账。

Steven Sinofsky直言，目前市场最大的误判在于华尔街的财务模型：

现在最大的问题是，每个人都在试图弄清楚这一切的经济学原理，但他们对于这个机遇究竟有多大，预估至少差了一个数量级。

Steven Sinofsky 直言不讳地指出，华尔街目前充斥着 “固定的收入蛋糕和零和博弈思维”，他们仍旧用线性的增长曲线来论证 GPU 和 Token（词元）的庞大支出。

Sinofsky 将当下的 AI 类比为早期的 PC 和云计算时代。过去，市场认为云计算只是将本地服务器的预算转移到云端，却根本没有预料到 “资源平权后，人们会消耗一千倍以上的计算资源”。

在 AI 时代，随着软件代码生成量的呈指数级暴增，以及移动端设备全面接入 AI，算力资源的消耗将以惊人的速度扩张。

对于企业未来的业绩想象空间，Aaron Levie 以 Box 自身的业务为例给出了乐观的指引：

我们感到兴奋的是，每个智能体都非常喜欢处理文件。因此，未来的文件数量将比以前多得多。我们能否建立一个平台，让智能体极其容易地处理这些数据？我们押注这对我们的商业模式是一个非常乐观的结果。

当智能体主导决策时，它们将不受限于人类在微交易上的摩擦成本。Levie 指出，在未来，智能体可能会为了完成一项深度研究任务而自动支付 3 美元去获取医疗数据，这将催生出全新的微支付与 API 调用变现模式。

当 Agent 数量激增 1000 倍，所有软件的接口将为机器而生

在业务和订单层面的前瞻指引上，企业软件（SaaS）的底层逻辑正在被彻底颠覆。

Aaron Levie 强调：

如果你有比人类多 100 倍或 1000 倍的 Agent，那么你的软件就必须为 Agent 而构建。

未来的核心课题不再仅仅是研究人类的用户界面（UI），而是要研究 Agent 如何通过 API、CLI（命令行界面）等方式与系统交互。

Martin Casado 认为：

今年将是 ‘计算机使用（Computer Use）’ 之年。

早期的 AI 是在企业软件上加个 AI 按钮，后来是让 AI 写代码，而现在的范式是：企业软件依然是企业软件，但 AI 智能体把企业软件当作计算机来使用。 AI 智能体能够在阅读数据的同时，根据需要自行决定是调用现有的 API，还是 “实时编写代码” 来完成特定操作。

这也意味着未来的软件商业模式将被重塑。

Aaron Levie 认为未来的业务表现，将取决于你的 AI 智能体获取所需信息的能力。那些能提供高质量 API、并妥善处理智能体身份和权限的软件公司，将获得巨大的增量收入，因为智能体处理数据和文件的频率将远超人类。

Steven Sinofsky 则警告说：

试图靠 ‘自然语言编写代码’（vibe code）来取代 SAP 等成熟的系统简直是荒谬的，深度的行业领域知识仍是核心护城河。

算力预算与 Token 之争，CFO 即将面临的 “疯狂时刻”

随着 AI 用量的激增，企业未来的业绩指引和利润率表现将发生剧变。

过去的软件支出是资本支出或固定的运营支出，而在 AI 时代，底层资源变成了按量计费的 Token 词元。Aaron Levie 强调：

工程算力预算的讨论，将是未来几年最疯狂的话题。CFO 们必须知道答案，华尔街也会逼迫他们给出答案。

Aaron Levie 补充道：

对于任何一家上市公司来说，研发费用通常占收入的 14% 到 30%。如果算力成本变成你工程团队成本的两倍，或者仅仅增加 3%，这都会直接吞噬你的每股收益（EPS）。

在实际操作中，工程主管需要权衡是否允许开发人员并行运行大量可能浪费 Token 的智能体实验。这种弹性的、难以预测的算力消耗，与传统企业习惯的固定资本支出或可预测的运营支出形成了激烈冲突。

AI 落地的现实阻碍，为什么硅谷的预期过于乐观？

尽管长期趋势确定，但 Levie 也向市场传递了一个清醒的现实预期：

AI 能力的普及所需的时间，将比硅谷人们意识到的要长。

阻碍 AI 在大型企业快速生成订单的核心问题在于系统集成与安全边界。在理想状态下，智能体可以无缝穿梭于各种系统之间，但现实中，赋予智能体与人类同等的系统访问权限带来了极大的合规风险。

Levie 警告称：

风险被放大了 1000 倍。

Levie 强调：

你不能完全把它们（智能体）当成人类对待。对于普通员工，你不需要每天登录他们的账号去监督，他们对自己在现实世界中的执行负责。但对于智能体，你拥有它所做一切的全部责任，它们没有隐私权。如果智能体被社会工程学欺骗，它们会轻易泄露你的并购文件。

在建立起完善的 AI 安全标准和全新的访问控制层之前，大型企业的 CIO 们将保持谨慎，甚至会 “封锁一切”。

这意味着，AI 在软件行业的渗透率提升将呈现分化：没有历史包袱的初创公司将快速试错并全盘接入，而拥有庞大系统记录的传统大型企业则需要更长的消化周期。

对话全文如下（AI 辅助翻译）：

Aaron Levie：我认为如今的趋势已经很明朗了，对吧？我们现在花在"智能体界面"上的时间，和人类花在软件交互界面上的时间一样多。

Martin Casado：是的。

Aaron Levie：对。我们之所以这样做，是因为我们的假设是：如果智能体的数量比人多一百到一千倍，那么软件就必须为智能体而构建。智能体与系统交互的方式，将通过 API、CLI、MCP 或其他类似协议来实现。

目前来看，一个正在兴起且已初见成效的范式是：让编程智能体访问你的 SaaS 工具，以及访问你的知识工作流程和相关上下文。这种组合本身就成为了一种超级能力——智能体不仅仅是能读取一些数据、理解一些信息，它还能通过编写代码或调用 API 来完成它所要实现的任何任务。

这个范式看起来已经开始形成复合效应。这正是 Claude 的 Cloud 协作现象，也是 OpenAI 在超级应用、Perplexity、Computer Use 等方向上正在探索的东西。我认为这是这一切发展的终极体现，是合乎逻辑的。

Steven Sinofsky：我认为你说得对，从理论上来讲是说得通的。

Aaron Levie：但——

Steven Sinofsky：但在实践层面，我们必须非常谨慎。换个说法，"算法思维"对于绝大多数人来说是极其困难的。最简单的例子是：如果你走到任何一个人面前，让他为某项具体工作画一张流程图，他们大概率会失败。

就拿一个大型产品线的市场营销团队来说，假设有 50 个人在做营销，其中能真正理解并文档化整个流程图的，可能只有一个人。所以如果你把这类智能体工具放到所有人面前，让他们去创建这些东西，他们向工具解释"该做什么"的能力是非常有限的。

Aaron Levie：那么，如果这就变成了人类与计算机交互的新方式呢？你就必须持续迭代和适应。

Steven Sinofsky： 那你其实只是在回到老路上——你不过是在开发下一个抽象层，用于人与计算机的交互。而从历史上看，每一层底层逻辑的构建，都是由组织内极少数高技能、高度专业化的人来完成的。他们构建出来的小模块，就像散落在各处的小零件，有些人能把它们拼接在一起，有些人则不能。这种现象从回形针和图钉时代就存在，以后也还是会存在。

Aaron Levie：我认为，不变的规律是：工作只是向上移动了一个层级，人们需要学习一套新的技能。所以我并不认为这次有什么本质上的不同，只是这次所获得的杠杆效应显然格外惊人。

最近有一条病毒式传播的推文，关于 Anthropic 的增长营销负责人——你们看到了吗？基本上是一个人，他当时使用 Claude Code，差不多自动化完成了原本需要五到十个人分散在不同岗位上才能完成的工作。

这件事之所以有趣，是因为你必须具备系统性思维才能做到这一点。他显然已经足够有技术能力才能实现这些，但它确实代表了一种可能性：如果你在经济体中从事某项工作，而在你旁边有一个无限量的工程师池，可以自动化你想做的任何事情，那这份工作在未来会是什么样子？

我同意，你必须找到一种方式，把自己的工作理解为一个系统，才能做到这一点。也许智能体会越来越擅长引导你朝这个方向思考。但确实有理由相信，人们会开始尝试将很多工作自动化，比如："为什么不把 Google Ads 中有效的关键词迁移到 Facebook，确保它们被同步，然后再获取市场最新动向的信号。"

Steven Sinofsky：那已经是很大的进步了。

Aaron Levie：刚才讲的 Anthropic 增长营销那个例子，那其实是大多数工作的缩影。

Steven Sinofsky：对，类似的工作我也能做。当需求无限、供给也无限的时候，那就不是什么难事了。

Steven Sinofsky：所以你不妨去做那个 600 美元预算的营销人员，看看你能做到什么。那才是真实的工作。

Aaron Levie：我们需要一个更好的例子。

Steven Sinofsky：但这确实很有意思。让我举个老例子，一个老派的例子。我表妹拿了名校 MBA，获得了第一份工作，那正好是计算机普及的节点。她在研究生院并没有用过电子表格，等电子表格出现时，她也不是那种会用电子表格的人。

所以公司告诉她：你想要多少实习生就招多少。于是她第一年实际上管理了整整一屋子的"人肉智能体"——来自大学的年轻人专门负责所有的电子表格工作。

然后，接下来几年里，神奇地发生了转变——她和她那一届的人全都成了会用电子表格的人。以前那种"在银行做管理，两年资历就能有一群人帮你做所有繁琐运算"的模式消失了，整个抽象层向上移动了。

在电子表格出现之前，你就是坐在那里，靠计算器甚至 HP 计算器来推演某个并购交易的模型，而且在出方案之前，往往只能做两次迭代。电子表格出现之后，他们自己就能做三十次迭代了。

我认为，我们现在与智能体的关系，正处于那个阶段——你以为你需要 50 个人，而整个抽象层还是以细碎的分工方式运转，由一个超级聪明的人来统筹协调。但很快，这一切都会合并融合，最终只是一段代码，我们叫它"营销类智能体"。你可以向它问营销相关的问题，下一步就是让它去真正执行这些事情。

Steven Sinofsky：在 AI 这种不可复现性和随机性问题彻底解决之前，我对"让智能体去执行"这件事还是有些怀疑的。执行层面的代价会非常高。这又会引发关于"人机协同"的讨论。但我觉得我们确实正处于那个临界点——当我和那些正在尝试用 AI 做事的人交流时，我有一种感觉，就像我在感恩节饭桌上，遇到了那个入职六个月的表妹，而我已经在用电子表格了。那时候我会想：我不明白为什么这么难，直接用就好了。然后两年后，她也用上了。

我觉得，现在要搞出四十二个智能体并把它们全都跑起来，你得既是火箭科学家，又是增长营销专家。但这种"火箭科学"的门槛，在很短的时间内就会消失。到那时，你面对的是大量的领域专业知识。

Aaron Levie：对，又回到了领域专家这个话题。

Martin Casado：我想对你说的内容提出另一种视角。我认为大家很容易陷入一种想法：智能体会去写代码、去做 X。但我认为我们实际上在走相反的路。我们最初的做法是在一个现有的软件上叠加 AI，这是一种 AI 赋能的方式，也是使用代码来解决这类问题的极端版本。

但现在我们实际上在做什么？SaaS 软件还是 SaaS 软件，智能体像使用电脑一样使用它——因为它在这方面其实非常擅长。所以我会说，我们从代码出发，转向了终端，而终端实际上比代码涉及的编码更少。

今年将会是"Computer Use"之年。智能体越来越像人类在使用计算机，而不是在生成代码。这感觉像是一个中间过渡状态。而我本人恰恰来自"生成代码"那个阵营，但我认为这种做法正在减少，而不是增加。

Aaron Levie：对我来说，不管是 Computer Use API，还是即时编写代码，我可能有些不恰当地把它们归为同一类。

Martin Casado：但它们是非常不同的。

Aaron Levie：不过我们正在做的一个智能体，它能够自主判断：应该使用一个现有的技能、调用 Box 的一个现有工具，还是自己写代码来解决这个问题。它能在任何时刻灵活选择这三种方式之一，这最终是极其有用的。

因为有时候你想要执行某个特定操作，直接写代码是最快的，我们也没有办法预先规划用户对文档的所有可能需求。所以模型具备即时编写代码的能力，即使可能 90% 的情况下直接使用现有工具就够了，这个特性依然是一个令人惊叹的属性。

Martin Casado：从帕累托原则来看，随着时间推移，就像人们手机上常用的只有七个应用一样，这些工具也会慢慢收敛整合。

Aaron Levie：但"七个应用"的问题，是人类的问题——人类不想反复学习新东西，我没有足够的精力去掌握那么多应用。但一个使用工具、调用 API、还能写代码的智能体，根本没有这些限制。

Martin Casado：你也可以说，要做的事情太多了，把界面做得足够通用就行了。

Steven Sinofsky：这个说法不无道理。我觉得你说的很有意思，让我补充一点我非常认同的东西。软件发展到今天，比如我整天用 SAP，我需要生成各种报告。然后某人过来说，我想要一个以某种方式切片查看数据的报告，我就犯难了——我不知道怎么做到这个。

然后我得翻遍 SAP 的帮助文档去找。AI 在这方面可以做得非常好——它能更好地浏览这些功能区域，帮助文档都在那里，只是需要找到它、将语言映射起来。而人类在过去二十五年里，一直是挖掘软件功能的瓶颈。

我坐飞机时遇到旁边的人问我："怎么让 PowerPoint 做到 X？"

Aaron Levie："去找功能区啊！"

Steven Sinofsky：对，真的很痛苦，眼睁睁看着有人在 Word 里被项目符号和编号折磨，或者在 Excel 里试图做一个双轴图——这几乎是火箭科学级别的操作，很少有人会，但这需求又极其普遍。所以那种人机界面上的阻抗失配一直存在。

Martin Casado：在消费层，我完全认同——就是那种完美流畅的 UI 或消费层。但我对后端，对那些系统记录层有疑问。

Aaron Levie：最终可能会……

Martin Casado：最终会收敛到某种数据库，某套通用 API，然后将它们连接起来。这似乎是发展的方向。我同意。

Steven Sinofsky：我插一句。

Martin Casado：我上周花了整个周末在实现我的 Nano Club Bot。刚开始的时候，感觉像是在为每个平台单独构建集成——OpenAI 有所有的集成，Data Cloud 只有几个，所以你得自己构建很多工具。但经过两三天之后，你基本上就有了你需要的工具集成。

Aaron Levie：但刚才我们说的是个人生产力，大概是在整理个人生活之类的事情吧？

Martin Casado：不，是工作产出。

Aaron Levie：好，那是工作生产力。但如果是 SAP 这样的系统——就有无限的复杂性了。比如某家跨国供应链公司，要处理来自三十个不同系统的七十五类信息，那对智能体的运算能力要求，是我们至今任何架构都无法支撑的。

Steven Sinofsky：但你刚才描述的，正是它过去五十年一直在做的事，以后也会继续做——我有个朋友曾是美国退伍军人事务部的 CIO，他所有时间都花在把七十五个系统粘合在一起，全是集成工作。

Martin Casado：对，对于集成这件事我完全认同——这类 AI 工具是最好用的，就是把两个系统拼接在一起。

Aaron Levie：但我认为现在正在发生的，是"按需集成"——就是那种 IT 团队没有预先接线，但我现在需要它在运行时实时发生的新查询。

Steven Sinofsky：好，让我说个现实场景。我最近参加了一个 CFO 和 CIO 的会议，当我说了一些类似的话时——虽然没有你说得那么乐观——会议结束后有六个人跑过来对我说："你疯了，你已经完全失去我对你的信任。"

Martin Casado：太好了！具体是什么观点让他们这么激动——是说智能体会做集成这件事吗？

Steven Sinofsky：我说集成问题会变得更容易，他们反对的不是这件事本身，而是让普通人去做集成——把权力释放给人类去做集成——这才是他们害怕的。因为一旦人们开始随意创建新的集成，你等于是在说：请来破坏我的系统记录吧。在系统 27 和系统 38 之间随意建一个新 API，如果只是用来看报告，那无所谓，因为那是他们自己的事；但你不能——

Aaron Levie：我认为这件事在相当长一段时间内会停留在只读层面。

Steven Sinofsky：对，"相当长"这个时间会非常长。

Martin Casado：现在很多 AI 的应用其实都是消费层，消费者是人类，真正的落脚点还是消费侧。

Aaron Levie：是的。我们刚刚正式推出了 Box CLI，谢谢你点赞了那条推文。

Steven Sinofsky：我点赞了，我也用了，有些反馈想和你说。

Aaron Levie：欢迎所有反馈。这是一件很有趣的事。我们内部有很多讨论：把 Claude Code 和 Box CLI 结合起来，你就可以用自然语言操作整个 Box 系统，并且有 Opus 4.6 作为编排器来执行一系列操作——某种程度上令人叹为观止。

你可以说"把我桌面上的这整个文件夹上传到 Box"，它就能做到；或者"处理这个文件夹里的所有文档"，它也能做到，非常惊人。

然后我们开始深入思考：假设一家公司有五千名员工，大家都能访问某个共享的知识库——工程文档、市场资产之类的——而且每个人都在跑 Cloud Code 或 Codex 加上 CLI。

这就出现了一些非常有趣的新挑战。比如如何协调并发——你可能每小时向系统发起一万次请求；不是性能问题，而是如何确保在某人进行写入操作时，没有其他人意外地移动了一个文件，而另一个人同时试图删除某些东西。因为你会有这些智能体在系统里到处乱跑。这将成为每一位 CIO、CFO 都要焦头烂额应对的新重大议题。

Steven Sinofsky：这正是我遇到的情况——我按照你的例子操作，创建一个营销计划目录，结果进入了某种死循环，不断地创建目录。

Aaron Levie：它会跑到死为止。

Steven Sinofsky：对，我当时就在想，Box 上目录数量有没有上限，因为我快要撞上了。

Aaron Levie：我们也会一起发现这个答案的。

Martin Casado：我的感觉是，很多人的直觉反应是：再加一层控制层。但实际上在实践中，大家做的恰恰相反。举个例子：当我们刚开始使用这些个人智能体时，我们会把自己的 API 密钥、邮箱地址给它，让它去访问这些资源，同时担心"怎么阻止它乱来"。而现在大家的做法是给它一个专属的手机号，甚至给它一张独立的信用卡。

Steven Sinofsky：是 CBS 买的那种 Visa 借记卡，里面只存了一点钱。

Martin Casado：对，还给它单独的 Gmail 账号，而 Gmail 本身有完善的 RBAC 权限系统。所以你可以说，其实我们已经在很多地方内置了这些权限系统——你需要把它当成一个独立的人来对待，而不是不断叠加新的控制层。

Aaron Levie：好，我能立刻反驳这个我们即将遇到的问题吗？对于个人生产力，这套逻辑很美好。但在企业场景里，问题就来了。

举个简单例子：假设有一个五十人的团队，是不是基本上就会变成五十个人类和五十个智能体共同在同一个空间里协作？我当然能完全掌控我自己的智能体，但如果我的智能体与别人协作，意外获得了我本不该有权限访问的某个资源，而这个自主的、有状态的智能体还在继续为别人工作——这该怎么办？

Martin Casado：把智能体当人对待，问题就解决了。

Aaron Levie：但不能完全把它们当人对待。原因如下：对于普通员工，你没有权利查看他们的 Slack 频道，没有权利以他们的身份登录，没有权利监督他们的一切，他们对自己的行为承担责任，你不会因为他们的失误而被连带惩罚。但对于智能体，你要承担它所有行为的全部责任，你需要保持完全的监控，而它没有任何隐私权。所以有些地方，"把它当人看"这个类比是不成立的。

我需要能够给它授权，但也需要能够随时以它的身份介入，查看它做了什么，甚至撤销一切操作。但如果我能随时以它的身份登录，那它怎么可能在现实世界里与他人协作，同时保有任何形式的保密性或安全性？所以它本质上只能是你自身的延伸，几乎没有办法绕开这一点。

这是一个我们目前还不知道如何在短期内解决的问题——你可以随时欺骗智能体让它泄露信息，这就是为什么给智能体完全独立的资源访问权、让它完全自主决策，目前还做不到。

Martin Casado：这个逻辑并不是必然成立的。比如，对我的员工，我在必要时也可以访问他们的邮件。

Aaron Levie：但你在日常中不会这么做。你可以在必要时获取访问权，但那是特殊情况，比如诉讼，而不是常态化的监控。

Martin Casado：用正确的操作模型对待智能体，道理是一样的——

Aaron Levie：但风险是一千倍级别的。智能体会在被提示的情况下毫不犹豫地把信息发给任何人。

Martin Casado：我认为，这些东西最终的状态，是它们始终是"不够精确的计算机"，它们永远无法完全保密信息。

Aaron Levie：我不太喜欢"不够精确"这个说法，不过如果是口语化的意思的话——让上下文窗口里的内容保密，就是"告诉它不要泄露 X"，我认为这是一个非常难解决的问题。因此，只要有任何东西进入上下文窗口，你就必须假设它有可能被提示注入攻击所提取出来。我们目前还没有找到解决方案。

而且，如果我知道你的智能体邮箱地址，我可以给它发邮件。我对一个智能体进行社会工程学攻击，比欺骗一个人类要容易得多——它同时还能访问你的 M&A 文件，这就很危险了。

Martin Casado：但这难道不就是当下 AI 面临的整体处境吗？

Aaron Levie：具体说的是哪个方面？

Martin Casado：就是现在我们使用这些 AI 系统和智能体的方式——共享系统、共享上下文。

Aaron Levie：对，而这正是为什么现在你基本上是"以自己的身份"在使用它们，而我们还不知道如何让它们不以你的身份运作。

Steven Sinofsky：让我给个例子。

Aaron Levie：解决这个问题，关键在于：你可以轻易骗到智能体，让它泄露信息。所以让它拥有完全属于自己、能够自主决策的独立资源，目前还是无法做到的。

Steven Sinofsky：这里有一个完美的类比——我们已经经历过开源的历程。开源的模型就是"一切都在那里，你自己用，爱取什么取什么"，当时也没什么争议，因为那时候世界很小，没有人在网上开播客讨论这些。

但很快大家就意识到了你刚才提到的所有问题：在大公司里，你不能随便让人把开源代码复制粘贴进你的商业产品，涉及许可证问题、质量问题等等，于是各种规范慢慢发展起来了。

我们现在正在经历的这场讨论，是新技术发展过程中一个非常有趣的现代现象——这一切都在实时发生。当年开源的时候，我们坐在会议室里讨论 Windows 或 Office 可以使用多少开源代码，网上没人知道我们在进行这场辩论。

而现在，关于这一切走向何方的讨论，是在大庭广众之下发生的，所有人都在试图抢先到达终点，但速度远远超过了我们真正能抵达终点的速度。所以真正需要的，是人们踏踏实实地去构建东西。

Aaron Levie：我们需要标准，我们需要——

Martin Casado：我认为我们对终态有不同的直觉。

Steven Sinofsky：你不想听我的直觉。

Martin Casado：你可以构建一个端到端的论证，说这些智能体最终会收敛到与人类同等的可靠性——就像我们看待自动驾驶的方式一样。到那个时候，你就可以用对待人类的同一套机制来进行保护——考虑内部威胁，考虑被收买的可能性，考虑人为失误的可能性，进行风险评估，建立操作流程。这是一种直觉。但也存在另一种直觉——

Aaron Levie：我说的只是我们现在所处的位置，关于终态我们未必有分歧。而且从战略上来说，我们也在两边下注——我们会构建智能体用户和相应的注册机制，我很喜欢 Open Claude 拥有一个 Box 账号并独立运作这个想法。

Steven Sinofsky：对，账户数量直接翻倍。

Aaron Levie：完全支持。我只是说，就现在而言，我们还不知道如何安全地把一个 M&A 数据间交给智能体。

Steven Sinofsky：但这实际上比你描述的还要难。因为威胁向量将会远比今天的人类威胁复杂得多。你不能假设智能体的行为和今天的人类一样，因为在某种意义上，被注入了恶意指令的智能体，就是有史以来最快速、最缜密、最无所不能的"超级人类"，它会全力以赴地试图泄露信息。

所以接下来会发生的是：企业客户会先把一切都锁死，直到这一切有了某种秩序感为止。而与此同时，个人用户，尤其是开发者，会拥有巨大的先发优势。我认为，这正是最令人兴奋的张力所在——企业会落后于这些高度个人化的"超级个体"，这些人看起来就像是新兴创业公司。创业公司因为没有历史包袱，将会以远超大企业的速度前进。当然，智能体在创业公司里"脱轨"可能会是家常便饭，不过那不过是一集《硅谷》剧情。

Aaron Levie：关于风险，我同意大方向，但有几点差异。比如，我没有办法用"不然就开除你"来威胁 Claude Code，但对于普通员工，你至少有那条线——95% 的人不会主动做坏事。

Steven Sinofsky：他们不是主动为恶，但无意中造成损害的能力……

Aaron Levie：我认为，让普通员工不向公司外部错误地分享文件，要比让智能体遵守同样一套指令容易得多。

Steven Sinofsky：而且你现在有工具，可以在一个更高的抽象层级上阻止这种行为，这正是为什么必须把这些能力内置到软件里。

Aaron Levie：是的。我认为，把刚才你最后这个观点提炼一下，这很大程度上解释了为什么 AI 能力的普及扩散，将比硅谷的人们预想的花费更长时间。我们看到的是从零开始的创业公司，因为没什么可炸掉的，所以可以无顾虑地出发，于是我们把这当成普遍适用的轨迹。但当你去面对摩根大通，问他们"你们打算如何让 Nano Claude 在近期内真正实现业务自动化"——那之间的差距可就大了。

Steven Sinofsky：你们怎么看这个大与小、创业公司与企业之间的分裂问题？我认为这引出了一个很有趣的问题。

那些正在经历"SaaS 末日"的现有 SaaS 厂商——我不完全认同这种说法，但他们确实面临一个真实困境：他们卖的本质上不只是数据，而是封装在整个系统里的智能和领域知识。

而智能体那一侧现在只想买数据，只想授权访问数据，想要无限制地访问数据——但 SaaS 厂商从来没有真正开放过这一点，这从来不是他们的商业模式，这也是 Workday、SAP 等厂商长期以来的核心张力之一，关于开放多大程度的 API 访问。Salesforce 就经历了三次大规模的平台重构。

我认为这是一个特别有趣的问题——不是华尔街那种视角，华尔街对经济逻辑和问题的判断全都是错的，但从技术视角来看，当所有人都想直接访问数据时，"系统记录"到底意味着什么？

Martin Casado：是用于模型训练，还是用于其他目的？

Steven Sinofsky：他们真正担心的是，某些大客户的供应商想用客户的数据来训练模型。

Aaron Levie：其实即使不涉及训练，这个问题也存在。因为以前用户在你的 UI 里操作，现在只是通过网络发送一个 API 请求，两种方式的变现能力有天壤之别。

Steven Sinofsky：但变现问题是华尔街视角。我认为，像 SAP 这样的系统，里面有大量的领域知识，它们不会消失，这绝对是事实。认为你能靠"氛围编程"取代 SAP，是非常荒唐的。SAP 里那些领域知识不只存在于某个精心设计的数据层里，它还存在于 UI 里、中间件里、以及系统的使用方式本身里。

所以我真的不确定这会如何演变，因为 SAP 不会消失，这就会减缓 AI 在那部分数据上的普及速度——不管是智能体主动操作数据，还是只读查询报告。你怎么看这个问题？

Aaron Levie：好，我来说一个可能有点大胆的观点。

Steven Sinofsky：说吧，你不说就别想再被邀请来了。

Aaron Levie：我已经完全相信了"为智能体构建产品"这个理念。过去一年里，这个概念逐渐清晰，我认为我们其实在这一点上是一致的——经过足够多的迭代之后，在某个时刻，智能体将在很大程度上主导它想要使用什么工具。

智能体当然无法更换一套企业系统，但再过几代之后，智能体也许会遇到太多你的软件设置的障碍，然后直接说："你得把这套旧 HR 系统彻底换掉，否则我没有办法为你自动化这个工作流。"

所以确实存在一种很有趣的动态——回到"智能体体量是人类的百倍乃至千倍"这个逻辑，重复足够多次，软件栈就必须为智能体而构建。也许会有几个顽固分子，几套 ERP 系统是最后的守旧者，但其他一切都会是：你的业务表现，将与你的智能体能否顺畅获取所需信息高度相关。

因此，你的企业 IT 基础设施必须支撑智能体的高效运转，智能体将变相掌控一切——因为你的软件必须让那些智能体有效工作。这意味着每一家 SaaS 公司或软件公司，都要面对这个核心问题：你能不能构建高质量的 API？你能不能实现变现？你能不能处理智能体的身份和访问控制？这就是你构建软件公司时必须解决的新问题。

变现怎么实现？Workday 会为每次 HR 记录查询收取一分钱吗？这我们以后会搞清楚。我认为有些业务可能收入会减少，另一些则可能大幅增加。

我们感到兴奋的是：每个智能体都非常喜欢处理文件，所以未来可能会有比以前多得多的文件。我们能否构建一个让智能体非常容易处理这些数据的平台？我们押注这对我们的商业模式是一个乐观的结果。当然也会有一些商业模式受到压缩，因为在那种未来场景里，智能体创造的价值远大于软件本身；而介于两者之间的，则是大多数情况。

Martin Casado：我能对一件事提出异议吗？

Aaron Levie：我以为我说的没什么争议……

Steven Sinofsky：我们在这里就是要提出异议的。

Martin Casado：我认为 Paul Graham 以及很多人忽略了一件事——他们关注的是界面，会说"为智能体构建产品"之类的话。但我认为这几乎完全是错的。

Aaron Levie：公平地说，Paul Graham 其实没有——

Steven Sinofsky：被过度引申了。

Aaron Levie：是我把 Paul Graham 拉进来的。

Martin Casado：好，那我说的是那些在抽象层面谈论这个问题的人。他们会说"现在你是在向智能体做营销，最重要的是你得有个好 API"。我认为这几乎完全是错的。

Aaron Levie：这个观点很重磅。

Martin Casado：智能体真正擅长的，是自己找到解决路径。归根结底，真正重要的是语义。在我的经验里，智能体非常善于为手头的任务选择正确的后端——它们不会说"这个界面很好用"，它们考虑的是成本参数、持久性之类的实质性因素，运用着我们使用这些平台的集体智慧。

比如云平台，现在有很多，每次我让智能体选择一个平台，它实际上是在用真正有意义的标准做判断，而不是界面层的东西。所以我认为，作为一个行业，我们太过关注界面了——"哦，你得给智能体做好营销之类的"。但实际上，真正决定胜负的，是你有没有构建一个更好的系统。

Aaron Levie：好，我觉得我们其实没有分歧。我不是从营销的角度来看这件事的，我更多想说的是：如果你的工具对智能体是封闭的，智能体最终会为那家公司找到更好的替代工具。以前你去找 Gartner 咨询用什么系统，迭代足够多次之后，智能体就会说："你应该用这种数据库来处理这类操作。"如果你不在那个推荐名单里，你就出局了。

Martin Casado：我认为这其实值得庆祝，因为智能体在选择技术上相当聪明。过去，影响采购决策的往往是很多与技术本身无关的因素。

Aaron Levie：不过别担心，在硅谷，我们很快就会把这种精英竞争机制给破坏掉的——

Steven Sinofsky：有人会开始贿赂算法推荐。Workday 的营销智能体会想办法购买推荐排名……

Aaron Levie：想办法给智能体送牛排晚餐。

Steven Sinofsky：对，就这意思。但确实有一个真实且有趣的现象——这就像当年在互联网时代，每家公司的内网文件共享里都有最好的文档、最好的 PPT、最好的财务模型。人们会熟悉这些，找不到合适的就创建一个新的。很多组织就这样运作，某种程度上是一个自由市场。

Box 出现之前，如果不是数据库里的文件，IT 人员根本不在乎；他们只关心 SQL 里的东西。你描述的模型的风险在于：智能体自身会生成一套事实上的新参考系统，在 IT 部门眼里，这些都是"中间件"层面的终端用户乱搞。而且这套系统会以碎片化的方式蔓延，这是真实的风险。

某种程度上，就像"宏代码最终接管了整个公司"。IT 部门见过这种事，也见过让营销部门自己去网上买个活动网站，结果变成重大安全漏洞，邮件列表泄露，公司被告上法庭的情况。所以这种动态里存在比我们刚才说的更多的真实世界张力。

而且，不同组织的推进速度会非常不同。摩根大通会是最慢的，创业公司会是最快的，但差距非常大。即便是创业公司，这件事也还差一段距离，因为创业公司在某个时刻也需要系统记录，它们也都会使用 SaaS，而且不会很快替换掉。所以我认为这件事比看起来更复杂。

Martin Casado：感觉有两种截然对立的观点。一种是埃隆说的那种——你输入一个提示词，直接输出机器代码，也就是"层级坍塌论"：过去建立的所有现有界面和层级都会消失，直接从提示词到机器代码。

另一种是系统历史的视角——层级从来不会消失，只会继续叠加，因为很多层级实际上是组织边界、状态边界——

Steven Sinofsky：或者兼容性需求，它们因为兼容性而留存。

Martin Casado：另一种论点是：我们建立这些层级是有原因的，是为了满足人类和组织的需求，这些需求不会改变，智能体将会适应这些层级，而不是打破它们。我倾向于后者。我认为系统仍将以相当类似的方式运作，也许会有更多智能体在使用它们，但我不认为系统本身会有太大的演变。

Aaron Levie：也许"Anthropic 增长营销负责人案例"那个类别的人，就是最接近第一种情况的——因为他们从第一性原理出发构建了最纯粹的 AI 原生工作方式。而对于普通人来说，我们还是想用一套现成的 CRM 系统。

Steven Sinofsky：这不是没有被尝试过的事情。如果你从第一性原理出发重新设计一套 ERP 系统——SAP 当年在 1970 年代创立时有一套假设，今天你会有完全不同的假设，架构会非常不同。但那套新架构十年后你又会觉得："当初那个决策真是错了。"

所以层级的存在有其必然性，但第一性原理思维也永远会存在，因为在任何时间节点，你基于当时的约束条件所能做出的决策，会决定整个系统的走向。就像激光雷达，十年前完全合理，但你还是需要十到十五年才能证明"不用激光雷达也行得通"。然后又会有一堆新的东西让你说："当初完全可以用不同的方式做。"

所以我的感觉是，我们现在的讨论是在试图赶到一个终点，但先让我们看到你所描述的事情真实发生的第一个案例——那才是真正的信号。我认为企业只会回到层级和架构模型，因为那是唯一可行的方式。

Martin Casado：对于安全和合规来说，这是必须的。

Steven Sinofsky：也是构建系统的唯一方式。否则你只是在写一个应用。如果这个应用只做一件事，那就完全是另一种做法了。

Aaron Levie：我特别感兴趣的一件事——我没有什么惊人的数据点，但至少从概念上来说——那些在服务类行业从零开始、以第一性原理构建的新公司：营销代理机构、工程咨询公司，或者法律事务所，也许还有施工设计、建筑设计，任何类型的知识型服务公司。

如果你没有任何历史包袱、没有信息壁垒和访问权限边界，你可以把所有上下文都给智能体，随时为特定需求写代码，你确实可以以非常不同的方式构建你的公司。我认为这将具有相当大的颠覆性，直到那些大型 incumbents 能够赶上来为止。这至少会创造出一些先例和案例，展示这种新型组织形态是什么样的。

当然，随着时间推移，它们终究还是会遇到所有其他公司遇到的问题——

Steven Sinofsky：地理扩张、市场细分、分发渠道……凡是超出你那四堵墙的，都会遇到现实世界的阻力。

Aaron Levie：我确实喜欢"新商业模式得以开启"这个想法。当然，因为有大量信息和软件的利用率，比其实际经济价值低一百倍——原因很简单，没有人愿意为访问一条数据支付 5 分钱，或者只用一次某个工具支付 1 美元。

但一旦给智能体一个预算和一套协议，它就能够即时获取医学研究资料并支付 3 美元——这件事反而做成了。智能体可以直接完成这些微交易。这开启了一整套新的商业模式。

Steven Sinofsky：互联网的历史……好，我忍住不说太多了。但那个观点，我认为是目前最重要的"悬而未决"的问题之一：所有人都在试图搞清楚这一切的经济逻辑，但他们对这个机会量级的估计，至少差了一个数量级。原因是没有人知道新商业模式会是什么，但它们一定会出现，每一次新技术都是这样。

现在讨论的制约因素是：一堆金融和华尔街人士正在努力为 GPU、词元这些东西建立盈利模型，好像我们还活在旧世界一样，把收入看作某种线性增长曲线。

这就像 PC 时代，人们把 PC 视为一个有限市场，因为他们只是把算力当成一个有限的消耗品，没有想到如果把这些算力放到每一台桌面上会发生什么。他们以为软件是随硬件捆绑销售的，没人想到可以单独卖软件。直到有一个人想到了，结果证明那是一个非常好的主意——Bill 和 Paul。

同样的事情也发生在云计算上——人们看着云说，我们只是要把服务器业务，大约每年六万台的量，搬到别人的数据中心，然后按比例分摊价格。没人说"人们使用资源的量会增加一千倍"。这正是让我抓狂的地方——华尔街的模型总是把收入蛋糕看成固定大小的。

Martin Casado：是个接近于零的东西……

Steven Sinofsky：对，在某个地方趋近于零。他们认为一家公司的支出总量是固定的。这也是 Salesforce 当年面临的问题——Mark Benioff 正在开拓一条新路：CRM 市场当时是 20 亿美元一年，而且这 20 亿需要你买一堆服务器、Oracle 许可证，经历漫长的部署和咨询过程。但如果你能让销售人员直接个人注册，他们都会注册，零摩擦，对吗？这就是当下 AI 正在发生的事，毫无疑问。

Martin Casado：我来举个例子。我做了十年投资，大概有 240 家公司的组合，其中约 50 家是基础设施公司，历史上有做得好的也有做得不好的。过去六个月里，这 50 家公司无一例外地全部进入了曲线的指数增长段。

原因很简单：现在每天被写出来的软件，比以往任何时候都多——而且不是因为他们有了大型企业客户，纯粹是基础设施层的消耗在爆炸式增长。随着更多软件、更多智能体的出现，计算资源的消耗量将会更大。

Steven Sinofsky：我们甚至还没有到"每个人的手机都在大量消耗 AI"的那个节点。一旦设备端 AI 真正落地，这个数量将会再增加十亿倍。

Aaron Levie：你支持微支付这个方向吗？

Steven Sinofsky：总体上是支持的，但历史上每次技术革命都会有一波人认为微支付会成为主流，最终在企业场景里，大家还是更倾向于批量授权或打包购买，因为更简单、更可预期。

Aaron Levie：大家想要的是可预测性。

Steven Sinofsky：对，不想时刻计算成本。但我也喜欢这个想法——

Aaron Levie：我喜欢的是，这是第一次你有一个主体，它完全不在意小额交易的摩擦。第一次出现了一个愿意为付费墙后面的资源实际付费的参与方。

Steven Sinofsky：而整个世界已经建立了基础设施，能够把这些支付聚合成对客户来说高效的形式。

Martin Casado： 因为词元现在是成本的重要组成部分，这正在推动整个行业向使用量计费转型。我记得从永久授权到订阅的转变，那需要极大的预算和组织变革。我们现在正在经历同样的转变，走向使用量计费，而使用量计费非常细粒度——

Steven Sinofsky：我们在 AWS 时代就经历过这个——人们当时非常害怕云计算的弹性成本，催生了一批帮助企业找到最低价格的中间商公司。

Martin Casado：对，就是那个。

Aaron Levie：好，把词元引入进来，这个话题我不知道我们在这段对话里有没有时间展开。但工程计算预算这个话题，在未来几年将会是最疯狂的讨论之一。应该把多少工程费用分配给词元？不同的人给出的答案可能从 1% 到 100% 都有。

Steven Sinofsky：是的，但这……

Aaron Levie：CFO 必须真的给出一个答案。

Steven Sinofsky：CFO 总是想知道那些没有答案的问题的答案。

Aaron Levie：华尔街会逼他们给出答案。

Steven Sinofsky：华尔街会逼他们编一个数字，然后拿着这个数字追责，然后 CFO 被炒，然后这件事就过去了。

Aaron Levie：研发支出通常是任何上市公司收入的 14% 到 30%。如果计算资源的成本是工程团队薪酬的两倍，或者只多 3%，这之间的差距是巨大的，直接影响到 EPS。我们不得不搞清楚这件事。

Steven Sinofsky：我不介意牺牲几个 CFO。这是个好片段，顺便说。但原因依然是：我们在试图回答一个当下根本没有答案的问题。这在互联网带宽时代也发生过，在——

Aaron Levie：不，这和网络带宽完全不是一个级别的事情。

Steven Sinofsky：是的它是，它发生在真空管时代，发生在晶体管时代，每次新技术都会经历这个阶段。甚至发生在程序员身上——在我有生之年，曾经有那么一段时间，人们觉得程序员将会吞噬所有公司的成本预算。

Aaron Levie：但我认为我们从来没有经历过这种情况：组织里的每个终端用户都拥有完全弹性的、能够代表自己发起计算请求的能力。

Martin Casado：这听起来和 2016 到 2018 年云计算时代发生的事情非常相似——当时也有一整套公司，基本上就是帮你管云支出仪表盘的，比如 Finops 类的工具。开发者有了云访问权限，但云支出开始失控，于是就出现了"这是你的 Twilio 支出，这是你的 AWS 支出"这类工具。

Aaron Levie：但这是很不一样的，而且我等着 YouTube 评论区来纠正你。那时候你可以把团队叫进会议室说："能不能把这个算法稍微优化一下，别在深夜占用那么多集群资源。"会议结束了，有人去改，搞定了。

现在的问题是，每个工程师的每一个提示词都涉及到这些决策：这个任务要不要设计成长时运行？要不要并行化？你对浪费词元的容忍度是多少？现在我的答案是，我们应该多浪费一些词元，因为那意味着我们在尝试新东西。你的工程负责人应该高兴地看到你同时跑十个实验吗——虽然 90% 的词元被"浪费"了，但你会从中选出一条成功路径？还是要告诉团队，先完整设计好系统再去执行？

以录制这期节目的此刻为例，大家现在正在为新的 Cloud Code Max 计划产生的词元限制而抓狂，三个提示词就被卡住了。这将是一个非常真实的话题，直到我们真正能够扩建数据中心容量为止。

Steven Sinofsky：那是另一个问题了。假设我们建了更多容量，价格会下降，因为现在的高价是有限供给造成的。但——

Steven Sinofsky：这件事终究会解决，我为那些现在必须立刻做出决定的人感到同情——这周哪十七个人不能再用词元了，或者每个人揣着一张词元卡排队打饭。但你知道，就像我们以前在命令行工具里输出命令运行时间，以便知道有没有变好或变慢——这一切，这些问题，都终将消失。毫无疑问。

Aaron Levie：时间框架上，我百分之百同意。

Steven Sinofsky：最根本的原因是需要做 Benioff 那种算术：如果你付给一个企业销售人员一百万美元一年，那他的工具值多少钱？如果你付给一个工程师 X 美元一年，那他的工具在某个时间点就是完全值得投入的。这不会成为一个问题。

如果短期存在产能瓶颈，那是一个不同的问题，是供给驱动的价格，而不是说我们永远都要做这种成本预算练习。

Aaron Levie：我认为大数定律会解决这个问题，因为最终会有足够多的工程师使用足够多的计算资源。但我们现在处于一个过渡阶段——两年前大多数人认为 AI 支出就是一个聊天机器人，结果他们错了，我们试图提醒他们，但他们还是错了。

Steven Sinofsky：他们错了，是因为他们只看到了这个特定的应用场景。但就像真空管那个例子——曾经有人认为达科他州会被真空管仓库覆盖，还有穿着轮滑鞋的工人沿着走廊飞奔更换真空管，以支撑二战的运算需求。

然后有人说，不然用晶体管？我们也会在 AI 领域迎来属于我们的"晶体管时刻"，可能是供给端的扩张，也可能是算法层面的根本性突破，或者是硬件的变革——很多事情都可能改变这个当下时刻。

我认为，现在每个人都把目光锁死在词元上，这是一件特别奇怪的事情——就像当年 IBM 的大型机时代，大家都在看计算能力（MIPS），直到某天有人指出，IBM 每年都在以更少的钱卖出更多的计算能力（MIPS），而他们自己还没意识到，还在按 MIPS 定价，直到有人告诉他们，他们已经站在一条下行的曲线上——因为他们生产 MIPS 的速度，快于他们收费的速度。同样的事情一定会发生。我就这么说。

Martin Casado：听起来非常有信心。

Steven Sinofsky：对，听起来就像是我知道自己在说什么一样。

Aaron Levie：我可能应该相信这一点。