Title: Box CEO：你的软件，是为人设计的还是为 Agent 设计的？ 丨 a16z | BestBlogs.dev
URL Source: https://www.bestblogs.dev/article/c1824e0c
Published Time: 2026-04-12 12:30:00
Markdown Content: 87
This article compiles and organizes the core viewpoints of Box CEO Aaron Levie from the a16z podcast, exploring the design paradigms for enterprise software in the era of AI Agents, the moat value of domain knowledge, the implementation path of AI in enterprises, and the future challenges of engineering compute budgets. 晚 晚点再听LaterCast
Today 4359 words (about 18 min) View Source →
原创 Capihom 2026-04-12 20:30 北京
全文约 3500 字，如果你现在没有时间，试试转成播客稍后再听"如果 Agent 的数量是你员工的千倍，那你的软件就必须为 Agent 而建，而不是为人。
我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。全文约 3800 字，如果你现在没有时间，试试转成播客稍后再听晚点再听LaterCast
"如果 Agent 的数量是你员工的千倍，那你的软件就必须为 Agent 而建，而不是为人。"
"用 vibe coding 搭出 SAP？这个想法本身就是荒谬的，那些领域知识，不是什么整洁的数据层能装得下的。"
"工程计算预算的讨论，将是未来几年最疯狂的一场对话。"
Aaron Levie 是 Box 的联合创始人兼 CEO。Box 是全球最大的企业内容管理云平台之一，服务超过十万家企业客户，其中不乏通用电气、AstraZeneca 这样的巨头。作为一个从云计算浪潮里走出来的创始人，Levie 对企业软件的理解有着独特的历史纵深。这一期他坐进了 a16z 的播客，和两位主持人聊了将近一小时，话题核心只有一个：当 AI Agent 的时代真正来临，企业软件会走向何处？这场对话没有给出整齐的答案，但它提出了几个值得每一个产品人和工程师认真想的问题。Levie 不是在预测未来，而是在描述他已经看到的变化——这让整场讨论格外有分量。
你的软件，是为人设计的还是为 Agent 设计的？
节目开头，Levie 抛出了一个让人坐直身体的问题：如果未来你的组织里，AI Agent 的数量是真实员工的一百倍甚至一千倍，那你今天的软件，还能适用吗？这不是一个科幻问题，而是一个在工程和产品设计上已经开始发生的挑战。Agent 和人类用户的需求根本不同：人打开浏览器点界面，而 Agent 通过 API、CLI 或者 MCP 与系统交互。如果你的系统只为人类界面设计，Agent 就要绕路、就会出错、就会失效。Levie 说，Box 现在同时在维护两套设计——一套给人，一套给 Agent。不是因为这是时髦的事，而是因为这两套系统所需要的权限模型、安全机制和交互逻辑，根本就不一样。他们花在 Agent 接口设计上的时间，已经和花在人类界面设计上的时间相当。这个现实，对那些还只在做"AI 功能"的产品团队，是一个值得警惕的信号。
"我们现在花在 Agent 接口设计上的时间，已经和花在人类接口设计上的时间一样多了。因为如果 Agent 的数量是员工的千倍，那软件的主要用户，就不再是人了。"
Vibe Coding 搞不定 SAP：领域知识才是真正的护城河
今年"vibe coding"风靡一时，有人开始畅想：AI 是不是很快就能替代 SAP 这类积累了几十年的企业系统？Levie 对这个论断的回应非常直接："用 vibe coding 搭出一个 SAP，这个想法本身就是荒谬的。"SAP 里存的不只是代码，而是几十年来来自数百个行业、数千个客户积累的领域知识。这些知识没有被整洁地存放在某个数据层里，而是散落在每一个配置项、每一条工作流规则、每一个边缘情况的处理逻辑里。AI 能加速写代码，但它无法理解为什么某个德国制造业客户的应付账款周期是 42 天——那背后是监管要求、税法差异、行业惯例和十几年合同关系共同堆砌出来的东西。代码可以被自动生成，领域知识不能。这正是很多人在讨论 AI 冲击时最容易忽视的那一层：真正难以复制的护城河，往往藏在最无聊的细节里。
"最大的问题是，所有人都在试图搞清楚这件事的经济学，但他们对市场机会的估算，至少差了一个数量级。"
抽象层永远在上移：从算账员到表格到 Agent
对于"AI 是否会导致大规模失业"这个老问题，Levie 没有喊口号，而是讲了一个很有年代感的故事。他的表姐 MBA 毕业时，正好赶上 Excel 诞生。她所在的投行那一届毕业生，很多人直接拒绝学 Excel，公司索性给她配了一整屋子的实习生来手动做计算。两年后，全公司都用上了 Excel，那些做手工计算的实习生被迫去做更高阶的工作，而她自己也成了 Excel 高手。这就是抽象层上移的历史逻辑：技术不是消灭工作，而是把工作的门槛往上推一层。从算盘到计算器，从计算器到大型机，从大型机到 PC，从 PC 到 SaaS——每一次跃迁都有人恐慌，每一次也都有人在新的抽象层上找到了新的位置。Agent 不过是下一层。Levie 说，他现在跟朋友谈 AI 的感觉，就像是在感恩节餐桌上，他已经用上了 Excel，而朋友还在讨论"这东西有没有用"。再过两年，她就明白了。
"我现在跟朋友谈 AI 的感觉，就像是在感恩节餐桌上，我已经用上了 Excel，而她还不理解为什么这东西有用。再过两年，她就明白了。"
写代码、调 API、操控界面：三种路径正在合并成一件事
在讨论 Agent 如何与系统交互时，出现了一个有意思的历史观察：AI 的实现路径，似乎在经历一次"轮回"。最早大家以为 AI 的终极形态是"直接生成代码"；后来发现结构化的 API 调用更稳定可靠；而今年，"计算机操控"（computer use）成了新的热门范式——Agent 像人一样使用鼠标键盘，点击界面完成任务，而不是通过结构化接口。这三条路是否存在优劣之分？Levie 认为，它们正在合并成同一件事。Box 自己在构建的 Agent，已经具备了实时判断的能力：对于这个特定的任务，到底是调用现有工具更高效，还是使用 Box 的原生 API，还是临时写一段代码来完成？模型好到一定程度，这三种方式不再是"谁替代谁"的竞争关系，而是同一个工具箱里的不同扳手，由 Agent 自行按需取用。这个能力本身，已经是当前阶段最令人惊讶的属性之一。
"我们的 Agent 会自己决定：这个任务，是用现有工具、调 Box 的 API，还是临时写段代码来完成？这种灵活性本身，就已经是非常惊人的能力了。"
消费层 vs 系统记录层：AI 对企业软件的冲击有两种速度
Levie 提出了一个值得仔细分辨的区分：AI 对企业软件的冲击，在"消费层"和"系统记录层"之间，速度和方式完全不同，不能混为一谈。消费层——也就是人如何与系统交互——AI 已经可以做到近乎液态的体验。用户不需要知道 SAP 的菜单在哪、Excel 的公式怎么写，只要说出想要什么，AI 就能找到、调用、返回结果。这个价值是真实的，而且是短期内就能看到的。然而在系统记录层，情况复杂得多。那里的数据结构、权限逻辑、审计记录，是 25 年来以一种极为特定的方式积累起来的，不是让 AI"接管"就能解决的问题。更可能的路径，是 AI 在核心系统的边缘做集成和查询路由，而不是替换底层。消费层的改变很快，系统记录层的变化将非常缓慢。这两种不同的速度，决定了两种截然不同的产品策略和投资时序。
"人类，是过去 25 年企业软件能力释放的最大瓶颈。功能早就在那里了，只是没人会用。就像我在飞机上看到旁边的人在 PowerPoint 里挣扎，我只能说：点那个按钮就好了。"
按需集成：AI 在企业里最快落地的那条路
那 AI 在企业软件里，哪件事最接近能立刻兑现价值？Levie 和主持人最终达成了一个共识：按需集成（integration on demand）。以往，IT 团队需要把 A 系统和 B 系统的集成"提前连好"。业务部门需要一个新的数据视角，就得等 IT 去改接口、写脚本，往往一等就是几周。现在，这件事可以在运行时完成——用户描述需求，AI 在当下完成集成、构造查询、返回结果，IT 团队不再是中间那道门。Levie 举了一个具体的例子：美国退伍军人事务部（VA）的 CIO，花了多年时间干的核心工作，就是把内部 75 个子系统互相粘起来。这个工作，本质上就是集成。而 AI 带来的最直接改变是：这种集成不再需要提前预设，可以在用户提需求的那一刻即时发生。这不是遥远的愿景，而是在结构化程度较高的系统里，今天已经能做到的事。对于正在做 B2B 软件或企业工具的产品人，这可能是当下最值得优先落地的一个方向。
"以前 IT 团队干的，就是把 75 个系统互相粘起来。现在这件事可以在运行时发生——你要的那条查询，不需要 IT 事先写好了。"
工程计算预算：未来几年最疯狂的那场管理层讨论
整场对话里，让所有人都兴奋但又没有人有答案的一个问题是：公司该为 AI 工具花多少计算预算？Levie 说，这将是未来两三年内最激烈的管理层讨论之一。道理很简单：公司在工程师身上花了 X 元，那理论上，工程师的 AI 工具配套应该花多少计算资源才是合理的？有人说收入的 1%，有人说纯计算成本可能超过整个工程团队的薪资总和。CFO 们必须给出一个数字，但没有历史数据参照。主持人之一调侃说"我愿意牺牲几个 CFO，供奉在这个问题的祭坛上"。当下的处境，像极了 2000 年代初企业在讨论"该花多少钱买云"的那个时期：有人冻结决策，有人豪赌，有人在某个细分市场上押了重注然后成了赢家。Levie 的判断是：token 的成本最终必然会随着供给增加而下降，就像 IBM 当年按 MIPS 定价大型机，结果发现自己在以越来越低的价格卖越来越多的 MIPS，直到整个定价逻辑崩塌——这个终点是保证的，只是不知道什么时候到。但在那一天到来之前，每一个工程负责人都得和自己的 CFO 打一场没有历史经验可借鉴的仗。
"我愿意牺牲几个 CFO，供奉在这个问题的祭坛上——因为这是一个现在就必须有答案，但根本没有答案的问题。"
AI 的扩散速度，比硅谷想象的要慢
对话临近结尾时，Levie 说了一句很值得记住的话：AI 能力的扩散，将比硅谷圈子里的人预想的要慢得多。不是因为技术不够好，而是因为组织的惰性、人的适应速度、以及领域知识的转移成本，都远比代码复杂。那些认为"大模型一出，所有行业三年内重构"的判断，低估了每个行业里那层沉默的、无处不在的"为什么这么做"的知识积累。这不是悲观主义，而是一种更务实的路径：找到 AI 真正能加速的那条路，而不是坐等一个全面替代的时刻出现。当然，Levie 也没有否认大势——方向是确定的，变化只是比你以为的慢一点。但也比大多数组织真正行动的速度，快一点。对于正在做企业软件或者用 AI 构建产品的人来说，这可能是整场对话里最有用的一句话：不要等 SAP 消失，要找到今天 AI 能替你省掉的那道门槛。
"AI 能力的扩散，将比硅谷里的人预想的要慢。但也比大多数组织真正行动的速度，要快。"
内容来源："The Era of AI Agents"丨The a16z Podcast
原视频：https://www.youtube.com/watch?v=dvt_74kV-RM
相关文章 Every CEO：我们从给每位员工配备AI Agent中学到了什么丨Every Anthropic增长主管：工程师越多，产品经理越稀缺丨Lenny's Podcast Claude设计总监：设计流程已死，取而代之的是以下这些 | Lenny's Podcast 前Netflix AI产品总监：AI PM不是你想的那种，看完这个再去投简历丨Aakash Gupta Claude Cowork产品技术负责人：AI同事、本地优先Agent以及知识工作的未来 丨Latent Space 我用9个AI Agent管理工作和家庭，省出来的时间你想象不到丨Lenny's Podcast Anthropic主管：顶尖1%学习者如何利用AI提升思维能力 | EO
如果你喜欢深度好文，可以用「晚点再听 LaterCast 小程序」，将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ 跳转微信打开