撰文：深思圈

你有没有想过，我们构建软件的整套逻辑可能要被彻底推翻了？过去几十年，所有软件都是为人类设计的。我们花无数精力优化用户界面，让按钮更好找，让菜单更清晰，让操作流程更顺畅。但如果未来软件的主要用户不再是人类，而是 AI agent 呢？如果一家公司有一百个人，却有一千个 AI agent 在工作，那我们还应该把重心放在优化人类界面上吗？

最近在 a16z 的一期播客中，Erik Torenberg、Steven Sinofsky 和 Martin Casado 与 Box CEO Aaron Levie 展开了一场极其深刻的对话。他们讨论的核心问题是：当 AI agent 成为企业软件的主要用户时，整个软件行业将如何重构。这场对话让我意识到，我们正站在一个比大多数人想象中更加剧烈的范式转变的边缘。这不是简单地给现有软件加个 AI 功能，而是从根本上重新思考软件应该如何构建、如何交互、如何被使用。

软件必须为 AI Agent 而建

Aaron Levie 在对话中提出了一个让我深思的观点：如果你有一百倍甚至一千倍于员工数量的 AI agent，那么你的软件就必须为 agent 而建。这不是选择题，而是必然趋势。Box 现在花在思考 agent 界面上的时间，已经和思考人类界面的时间一样多了。这个转变的速度之快，超出了我的预期。

这背后的逻辑其实很简单。当 AI agent 成为主要的软件使用者时，它们会通过 API、CLI（命令行界面）或者 MCP（Model Context Protocol，模型上下文协议）这样的协议来与系统交互。而目前看起来最有效的范式是什么呢？给一个会写代码的 agent 提供对 SaaS 工具的访问权限，让它能够访问你的知识工作流程和上下文信息。这样的 agent 不仅能够读取和理解信息，更关键的是它能够通过编写代码或使用 API 的方式来完成任务。

Anthropic 的 Claude Code、OpenAI 正在开发的超级应用，以及 Perplexity 的计算功能，都在朝着这个方向发展。我认为这种能力的复合增长才刚刚开始。想象一下，一个 agent 不仅能理解你说"帮我分析上季度销售数据"，还能自己写代码去提取数据、进行分析、生成可视化图表，甚至主动发现你没有注意到的趋势。这种能力的边界在哪里？我现在还看不清楚。

但这里有个关键问题让我一直在思考：人们经常说要"为 agent 构建东西"、"向 agent 营销"、"拥有好的 API 和接口描述语言"。Martin Casado 在对话中提出了一个我非常认同的反向观点：这种说法几乎完全错了。为什么？因为 agent 恰恰最擅长的就是找到正确的工具和后端系统。它们不会因为你的 API 文档写得漂亮就选择你，而是会基于成本参数、系统可靠性、数据持久性等实质性因素来做出选择。Agent 拥有的是人类使用这些平台的集体智慧。

这个观点让我恍然大悟。作为一个行业，我们太过关注界面和接口，却忽略了本质：我们需要构建更好的系统本身。Agent 会推动我们回归技术本质，而不是营销包装。过去，企业软件的采购决策往往受到销售能力、品牌影响力、甚至是商务宴请的影响。但在 agent 主导的世界里，这些因素的权重会大幅下降。Agent 会基于技术优劣做出更加理性的选择。这对那些真正专注于技术本身的公司来说，是巨大的机遇。

算法思维的门槛：不是每个人都能指挥 AI Agent

对话中有一段让我印象深刻的讨论：关于非技术人员使用 AI agent 的现实挑战。Steven Sinofsky 提出了一个尖锐的观点：算法思维对绝大多数有工作的人来说真的非常非常难。如果你让任何一个人为他们需要完成的任务画一个流程图，他们很可能会失败。

这个观察击中了要害。想象一下，在一个有 50 个营销人员的团队中，负责一条庞大产品线的营销工作，可能只有一个人真正理解并能够文档化整个工作流程。如果你把这些协作工具或 AI agent 放到普通员工面前，让他们创建自动化流程，他们解释清楚"要做什么"的能力其实非常有限。

Aaron Levie 对此的回应是：这只是工作向上移动了一个台阶，你需要学习一套新技能。这和历史上的每次技术变革没什么不同。他举了一个很有意思的例子：Anthropic 的增长营销人员，一个人使用 Claude Code 完成了原本需要五到十个人的工作。这个例子之所以有意义，是因为这个人本身就是系统思维者，已经足够懂技术才能做到这一点。

但问题的关键在于：如果你想象每个岗位旁边都有一个无限的工程师资源池，可以自动化这个人想要的任何工作，那这个岗位在未来会变成什么样？我觉得这是一个值得深思的问题。也许 agent 会越来越擅长引导用户朝着系统化思维的方向发展，但至少在现阶段，能够有效使用这些工具的仍然是少数人。

Steven Sinofsky 分享了一个精彩的类比。他的表姐从精英商学院毕业后，加入第一份工作时正好赶上了计算时代的开端。她在研究生院没用过电子表格，第一年工作时被告知可以雇用任意数量的实习生，于是她管理了一整个房间的"agent"——那些大学生来做所有的电子表格工作。但神奇的是，在接下来的几年里，她和她的同事们都变成了电子表格专家。整个抽象层向上移动了。以前那些实习生用计算器和 HP 金融计算器做的工作，现在她自己用电子表格做，而且可以做 30 次迭代而不是只有 2 次。

这个故事让我意识到，我们现在处在 AI agent 发展的类似阶段。你会觉得需要 50 个小型 agent，由一个超级聪明的人来协调它们。但很快，这些东西会相互折叠，最终变成一个技能集合——一段代码，我们称之为 agent——它懂营销。你可以问它营销相关的问题，然后下一步，让它去执行任务。

我认为关键的转折点是：现在你必须是个火箭科学家级别的人才能创建 42 个 agent 并让它们全部运转起来。但这种"火箭科学"的门槛很快就会消失，然后一大块领域专业知识会回归到领域专家手中。这和电子表格的演化路径几乎一模一样。

企业的恐惧：失控的集成和权限噩梦

对话中有个让我触动很深的场景。Aaron Levie 说他最近在一屋子的 CFO 和 CIO 面前表达了类似的乐观观点，结果六个人跑过来说："你疯了，你在我这里失去了所有可信度。"为什么？因为他说集成问题会变得容易很多。

这些企业 IT 负责人的担忧不是没有道理。他们害怕的不仅是 agent 本身，更是人类被授权做集成这件事。当你让员工可以创建新的集成时，你基本上就是在说"请来破坏我的核心系统"。想象一下，有人在系统 27 和系统 38 之间创建了一个新的 API 连接，如果只是用来生成报告，那个人想错就错了，是他自己的事。但如果涉及到写入操作呢？

Aaron Levie 认为，在未来相当长的一段时间内（N 是一个很大的数字），我们会有一个只读版本的 agent 集成。很多 AI 应用现在都是消费层面的——人类是最终的消费者。但即使在这个层面，企业也面临着新的挑战。

Box 刚推出了官方 CLI，Aaron 描述了一个场景：你给 Claude Code 提供 Box CLI，现在你可以用自然语言与整个 Box 系统交互，用 Opus 4.6 这样的强大模型来 orchestrate（编排）一系列操作。这听起来很酷，你可以说"把我桌面上这整个文件夹上传到 Box"，或者"处理这个文件夹里的所有文档"，它都能完成。

但随之而来的问题让人头疼。想象一个有 5000 名员工的公司，每个人都能访问共享的工程文档和营销资料仓库，每个人都在使用 CLI。现在我们面临一些非常有趣的新挑战：如何协调可能每小时对系统发起 10000 次的请求？不是性能问题，而是如何确保当一个人的 agent 在移动文件时，另一个人的 agent 不会同时尝试在另一个文件夹上进行写入操作，而第三个人的 agent 又在尝试删除什么东西？当这些 agent 疯狂运行时，这将是每个 CFO 和 CIO 头发着火般要解决的新问题。

Aaron Levie 自己在测试时就遇到了这个问题。他在尝试创建一个营销计划目录结构的示例时，陷入了某种循环，不断创建嵌套目录。他开玩笑说："我想知道 Box 对嵌套目录的深度限制是多少，因为我快要触及了。"

这个小插曲反映了一个更大的问题：当 agent 被赋予执行能力时，它们可能会做出我们意想不到的事情。而这种不可预测性，正是企业最害怕的。

把 AI Agent 当员工对待？没那么简单

对话中有一段关于如何管理 AI agent 的讨论让我觉得特别有意思。当大家开始使用个人 agent 时，会给它们自己的 API 密钥、自己的电子邮件地址。那么如何防止它们做出不该做的事呢？

Martin Casado 分享了一个实践：给你的 agent 自己的电话号码、自己的信用卡（希望是从 CVS 买的预付费 Visa 卡）、自己的 Gmail 账户。Gmail 实际上有很多 RBAC（基于角色的访问控制）权限机制。你可以争论说，我们已经构建了很多这样的权限系统，我们应该把 agent 当作一个独立的人类来对待。

但 Aaron Levie 立即指出了这个模型的问题。在 50 人的团队中，我们是否会有 100 个"人"在协作——50 个人类和 50 个 agent，都在同一个共享空间里？我显然对我的 agent 有完全的监督权，但如果我的 agent 与别人协作，不小心访问了我本不该访问的资源怎么办？现在这个自主的、有状态的 agent 在处理别人的信息。

这里有个根本性的矛盾。对待真正的员工，你不能查看他们的 Slack 频道，不能以他们的身份登录，不能监督他们的一举一动。他们要为自己的执行负责，在现实世界中，你不会因为他们搞砸了什么而受罚。但对于 agent，你要承担它做的一切的责任。你需要有完全的监督权，它们没有隐私权。

所以出现了一些矛盾的地方。我需要能够给 agent 访问权限，但我也需要能够随时以它的身份登录，比如"不行，你把整件事搞砸了，我需要撤销所有操作。"但如果我能以它的身份登录，它怎么能在现实世界中与其他人合作，并保持任何信息的机密性或安全性呢？所以，agent 实际上几乎不可能不是你的延伸。

Aaron Levie 还提出了一个更深层的安全问题：我们还不知道如何让 agent 保守秘密。如果你告诉 agent"不要透露上下文窗口中的 X 信息"，要解决这个问题非常困难。如果任何东西都可以进入 agent 的上下文窗口，因为它们有权限访问资源，那么理论上你应该假设这些信息可能会被 prompt injection（提示词注入）的方式泄露出去。

这意味着什么呢？意味着如果我知道你的新 agent 的电子邮件地址，我可以给它发邮件，我能够社交工程它，这比社交工程一个人类容易十倍。很难让这个 agent 同时也能访问你的并购文档之类的敏感信息。

我认为这是当前 AI agent 面临的最大技术障碍之一。在这个问题得到根本性解决之前，agent 很难真正被授予独立的决策权和资源访问权。它们会一直作为人类的延伸而存在，而不是独立的实体。

初创公司的优势：无所顾忌地拥抱 AI Agent

对话中有一个观点让我特别有感触：AI 能力的扩散速度会比硅谷人士意识到的要慢得多。这背后的原因是初创公司和大企业面临的约束完全不同。

Aaron Levie 说，我们看到初创公司可以从零开始构建，没有我们讨论的那些风险，因为它们没有什么可以搞砸的。所以我们把这看作我们所处的发展轨迹。但当你去摩根大通，问他们如何设置 NanoClaw（一个假设的 AI agent）来自动化业务时，你会发现存在巨大的鸿沟。

这个鸿沟体现在哪里呢？大企业有 75 个遗留系统需要集成，有严格的合规要求，有数十年积累的数据安全标准，有复杂的权限管理机制。而更关键的是，它们有太多东西可以输不起。一个初创公司如果 agent 出了问题，最多是个笑话，可能还会成为《硅谷》剧中的一集。但一个大银行的 agent 如果泄露了客户数据，那是可能导致公司倒闭的灾难。

Steven Sinofsky 提出了一个精彩的预测：初创公司会烧光可用资本，假装计算成本不是问题。很多大公司会因为太害怕而冻结，什么都不做。然后普通员工会开始自己购买和使用这些工具，做所有大公司有钱但不想花钱时员工会做的事情。

在这中间，会有一些公司因为各种原因愿意下注，因为它们的财务状况允许。这些公司会成为各自领域的领导者，只要它们能够维持财务健康。不会有那种因为 CFO 害怕被解雇所以没人敢进场的情况。会有 CFO 犯错的情况，但那很正常。

我认为这会创造一个非常有趣的市场分化。那些敢于早期投入、愿意承担风险的中型公司，可能会获得对大企业的竞争优势。它们既有足够的资源来投入 AI，又不像巨型企业那样被遗留系统和风险厌恶所束缚。

同时，会出现一批全新类型的服务公司。想象一下，如果你从零开始创建一个营销机构、工程咨询公司或建筑设计公司，你完全基于 AI agent 的第一性原理来构建，不存在信息壁垒和边界，可以给 agent 完成工作所需的所有上下文，可以随时为特定需求编写软件。这种公司在一段时间内会具有相当大的颠覆性，直到那些更大的现有企业能够摆脱束缚。

Token 预算：工程管理的新战场

对话中有一段关于 token 预算的讨论让我觉得既现实又荒诞。Aaron Levie 说："工程计算预算对话将是接下来几年中最疯狂的对话之一。"

为什么这么说？因为工程费用在任何上市科技公司的收入中占 14% 到 30%。计算成本是工程团队的 2 倍，还是只多 3%，这之间的差异可能就是公司所有的 EPS（每股收益）。

但 Steven Sinofsky 认为，我们还不知道答案，而 CFO 总是想知道他们不知道答案的问题的答案。华尔街会强迫他们给出一个数字并对此负责，然后他们会被解雇，然后这个循环会继续。这不是新鲜事，我们在互联网带宽、真空管、晶体管、程序员数量等每一个新技术上都经历过同样的事情。

但 Aaron Levie 坚持认为这次确实有些不同。他提出了一个很好的观点：我们从未有过这样一个时刻，组织中的每个最终用户都有完全弹性的能力来代表他们启动资源。而且在很多情况下，他们启动这些资源是完全合理的。

这确实和 2000 年代初的云计算转型类似，当时我们从 CapEx（资本支出）转向 OpEx（运营支出），然后变成无限支出。Aaron 回忆起当年在 Box 的简报中心，CFO 们会说"你不明白，我们是农业公司，我们只懂 CapEx"或者相反"我们是 OpEx 公司，我们喜欢云"。会计规则的差异真的会影响技术采用。

但 token 预算的问题更加细粒度。作为工程领导者，你现在需要决定：要不要让工程师在做每个提示词时都考虑计算预算？你是想要长时间运行的提示词，还是短的？你想并行化吗？你对浪费 token 的容忍度是多少？

Aaron 说他现在的态度是应该浪费很多 token，因为那意味着我们在尝试新东西。那么工程负责人应该对团队并行运行 10 个实验感到高兴吗？即使这显然会浪费 90% 的 token，但你会选择一条成功的路径。还是应该告诉团队在做之前要真正设计出完美的系统？

当这段对话录制时，人们正在为 Claude Code 的新 Max 计划感到恐慌，因为他们在三个提示词之后就被限制了。这将是一个非常现实的话题，直到我们能够真正建立起数据中心容量。

但我认同 Steven Sinofsky 的长期观点：这个问题最终会消失。最大的原因是你必须做 Benioff 式的数学计算。如果你给一个企业销售人员每年支付 100 万美元，你必须问他们的工具值多少钱。如果你给一个工程师每年支付 X 美元，那么他们的工具在某个时刻绝对值得这个投资。

而且大数定律会解决这个问题。最终你有足够多的工程师，他们使用这么多计算资源，事情会趋于平衡。我们现在处于过渡阶段，大多数人在两年前以为 AI 的支出水平就是一个聊天机器人。但他们错了，因为他们把它看作一个特定用例，而实际上它是一个平台级的转变。

SaaS 系统的未来：数据层的价值回归

对话中有一段关于企业系统未来的讨论让我印象深刻。Martin Casado 提出，当前的 SaaS 供应商正在经历一个有趣的问题：它们实际上并不销售业务线数据，它们销售的是这个智能、领域专业知识和整个系统。但 agent 方面只想购买数据，只想授权数据并拥有无限访问权，但这从来不是它们的业务模式。

这一直是与 Workday、SAP 这类系统的长期紧张点——允许多少 API 访问。Salesforce 为此经历了三次大规模平台重新设计。这是一个技术层面特别有趣的问题：在人们想要访问数据的情况下，系统记录（system of record）意味着什么？

Steven Sinofsky 说得很直白："想要用类似 vibe coding 的方式做出 SAP 这样的系统，简直荒谬。"SAP 中的所有领域知识，不仅仅存在于某个精心编排的数据层中。它存在于 UI 中，存在于中间层，存在于你使用它的方式中。

但 Aaron Levie 对此有不同看法。他认为，如果你做足够多的迭代，agent 最终会在很大程度上负责选择它想要实现和使用的工具。虽然 agent 无法更换企业系统，但经过足够多代的发展，agent 可能会遇到你的软件的太多障碍，以至于它会说："你需要最终淘汰你的遗留 HR 系统，否则我无法为你自动化这个工作流程。"

这是一个颠覆性的观点。想象一下，当 agent 的数量是人类的一百倍或一千倍时，如果反复出现这种情况，最终必须为 agent 构建软件堆栈。也许会有几个坚守阵地的系统，比如几个 ERP 系统是最后的坚守者，但其他所有东西你的业务表现将与你的 agent 能够多好地访问它们需要的信息来完成工作相关联。因此你的企业 IT 堆栈必须以支持这些 agent 有效工作的方式来设置。

Martin Casado 提出了一个我非常认同的细微差别。人们经常抽象地说"现在你在向 agent 营销"、"你需要成为一个 API"、"你需要有好的接口描述语言"。他认为这几乎完全错了。Agent 真正擅长的恰恰是找到正确的后端。所以它们不会说"这个接口很好，文档很好"，它们会说"这个的成本参数、那个的持久性"。它们实际上拥有我们使用这些平台的集体智慧。

他举了个例子：每当他让 agent 选择一个云平台时，agent 使用的是有意义的东西，而不是界面相关的东西。所以作为一个行业，我们过于关注这些界面，认为"你需要向 agent 营销"这样的话题，而实际上我们将被推动去构建更好的系统，那才是会被选择的东西。

我认为这个观点非常深刻。在 agent 时代，技术优劣会变得更加重要，而营销和包装的重要性会下降。那些真正在技术上有竞争力的产品会脱颖而出，而那些主要靠销售驱动的产品会面临挑战。

我的思考：我们低估了这场变革的规模

听完整场对话，我最大的感受是：华尔街和整个行业都在用错误的框架来理解这场变革的经济影响。Aaron Levie 说得对，最大的问题是每个人都在试图搞清楚所有这些的经济效益，但他们对机会规模的估计至少偏差了一个数量级。

Steven Sinofsky 用历史案例说明了这一点。人们看待 PC 时，认为 MIPS（百万条指令每秒）的消耗是有限的市场，没想到如果我们把所有这些 MIPS 放在每个桌面上会发生什么。而且人们以为软件只是随着 MIPS 一起来的，只有一个人（指比尔·盖茨和保罗·艾伦）想到了可以单独销售软件。

同样的事情发生在云计算上。人们看待云时，认为我们只是把服务器业务（每年大约 60000 台）搬到别人的数据中心。没人想到使用量会增长一千倍。

对于 AI，同样的事情正在发生。华尔街模型有一个固定的收入饼，是零和思维。他们认为公司每年会在某个东西上花费的金额是固定的。但当云计算来临时，Salesforce 面临的问题是 CRM 业务每年是 20 亿美元，涉及购买所有这些服务器、Oracle 许可证和巨大的部署痛苦以及多年的咨询。但如果你能让销售人员个人注册，他们都会无摩擦地注册，这正是发生的事情。

我认为 AI agent 会带来类似甚至更大规模的市场扩张。当每个知识工作者身边都有一个或多个 agent 在工作时，软件的使用量、数据的处理量、计算的消耗量都会呈指数级增长。这不是一个零和游戏，不是简单地把现有工作从人类转移到 agent，而是会创造出全新的可能性和价值。

Aaron Levie 提到，他作为投资人接触的大约 240 家基础设施公司，过去六个月都呈现渐近线式的增长。为什么？因为现在编写的软件比以往任何时候都多。随着更多软件、更多 agent，将会有更多的计算资源消耗。当每个人的手机都大量消耗 AI，当手机上的设备端 AI 成为现实时，使用量将增加十亿倍。

我相信我们正在经历一次 "晶体管时刻"。Steven Sinofsky 用真空管的例子说明了这一点。曾经有一段时间，人们认为整个达科他州都要被真空管仓库覆盖，人们穿着溜冰鞋在过道里更换真空管，只是为了打第二次世界大战。然后有人说：不如用晶体管吧。

Token 可能就像当年 IBM 的 MIPS 一样。IBM 每年以更低的价格销售更多的 MIPS，但仍然按 MIPS 定价大型机，直到有人指出它们的曲线在下降，因为它们制造 MIPS 的速度比收费速度快。同样的事情会发生在 token 上。

但在短期内，我们会看到巨大的混乱和不确定性。企业会在投入多少、如何控制成本、如何管理风险之间挣扎。初创公司会大胆押注并快速移动。会有失败，会有成功。但长期来看，方向是明确的：软件必须为 agent 而建，API 会变得比 UI 更重要，系统的质量会比营销更重要，计算成本会持续下降而使用量会指数级上升。

我们不是在经历一个简单的工具升级，而是在经历一次计算范式的根本转变。那些理解这一点并采取行动的公司和个人，将定义未来十年的科技格局。而那些仍然用旧框架思考的人，可能会发现自己被远远甩在后面。

这场变革才刚刚开始。

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。