当AI Agent数量超过员工百倍时，软件该为谁而建？a16z最新观点指出：API将比UI更重要，系统质量胜过营销包装。本文探讨Agent主导下的软件重构、Token预算管理、企业安全困境，以及初创公司的颠覆性机遇。

你有没有想过，我们构建软件的整套逻辑可能要被彻底推翻了？过去几十年，所有软件都是为人类设计的。我们花无数精力优化用户界面，让按钮更好找，让菜单更清晰，让操作流程更顺畅。但如果未来软件的主要用户不再是人类，而是 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 更重要，系统的质量会比营销更重要，计算成本会持续下降而使用量会指数级上升。

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

这场变革才刚刚开始。