Box CEO 谈 AI agent 以及为什么企业跟不上——a16z

▲ 全程三分屏布局——左 Steven Sinofsky（前微软 Windows/Office 负责人）、中 Martin Casado（a16z 合伙人、主持）、右 Box CEO Aaron Levie（嘉宾，身处高层办公室）。下方字幕条标注三人 X 账号。

• 一场 a16z 三人直播圆桌：主持 Martin Casado（前 VMware 网络虚拟化创始人、现 a16z 合伙人）+ Steven Sinofsky（前微软 Windows/Office 负责人），对谈 Box CEO Aaron Levie。开场互相调侃发量，用大模型术语自嘲（Aaron「参数太多」，Martin「你这是个蒸馏过的模型，我是本地跑的 I run local」），定下轻松底色。→ 详细
• Aaron 自陈是「最扎在一线、每天真真切切跟企业客户聊」的 CEO，给自己一句金句定位：「我现在的工作就是尽可能地把现实带给硅谷，再把硅谷带回到现实里（bring reality to the valley and then bring the valley to reality）」——硅谷对企业现实有巨大误解，他来回当翻译，当下这中间「存在一种近乎疯狂的鸿沟」。→ 详细
• 三人开场唯一共识是「共识会很快消退」——先把同意的点说完，后面整场各执己见、开吵。→ 详细

• 这道鸿沟的根源，是「硅谷和工程岗位上那种工作方式，跟世界上其他地方的工作方式之间的差异」。Aaron 一口气列出工程师身上「五到十个因素（five or 10 things）」让 agent 在工程场景跑得通：① 工程师的「技术素养高到离谱（insanely high）」；② 对互联网正在发生什么有极强的「线上即时连接感（wired-in-ness）」——随时知道最新工具、最新动态；③ 自己挑工具、自己做选择的能力极强；④ 选的系统出了岔子能「很快 debug 掉、再调成顺手的样子」；⑤ 模型本身就很擅长写代码；⑥ 而且工程成果是「可验证的（verifiable）」——代码跑不跑得通一目了然。这些条件叠加，让 agent 在工程或创业场景里天然好使。→ 详细
• 而企业里的 workflow（工作流程）「截然不同」：用户没那么懂技术、数据「更加碎片化（more fragmented）」、系统「老旧得多（much more legacy）」。Aaron 把核心挑战形象地概括为：怎么把 coding agent、会操作电脑的 agent 身上看到的「所有好东西统统装进瓶子里（bottle up all of the greatness）」，再把它带进这个截然不同的企业环境。这个「装进瓶子里」的比喻贯穿全场——好东西在硅谷已经存在，难的是搬运过去。→ 详细
• 他强调这「甚至都不是各说各话」的那种经典立场之争（如「政府 vs 产业界」），而是「纯粹就是 workflow 和技术栈层面实打实的分裂（a pure workflow and technology set divide）」。正因为是实打实的结构性分裂，这种扩散（diffusion，技术从前沿渗透到大众的过程）要「花上好些年（a number of years）」才能从硅谷蔓延到其余知识工作。→ 详细

• Martin 补一层：像互联网这种「长周期趋势（secular trend，持续多年、跨越经济周期的大方向）」其实「真的是从个人开始的」，而大公司「往往是集中决策的（make decisions centrally）」。落差由此而生——大公司里「很可能有一大堆个人已经在用了，只不过公司本身根本不知道该怎么去看待它」，而 AI 又恰是「增长最快的长周期趋势之一」。→ 详细
• 基于这个落差，Aaron 直接反驳那条被广为引用的统计——「MIT 有个统计，大公司里 95% 的 AI 项目都失败了」。他说「那显然很傻（clearly silly），因为我敢肯定每个人都在非常高效地用 ChatGPT」。失败的不是「AI 本身没用」，而是自上而下、集中式立项的搞法。→ 详细
• 失败剧本（全场第一句金句，开场和正文各讲了一遍）：「董事会去找 CEO，董事会怎么说？我们得多搞点 AI（We need more AI）。CEO 怎么回？哦，好的，那我请个咨询顾问来多搞点 AI（I'll get like a consultant to do more AI）。然后他们就立了个集中式项目，没人搞得懂它怎么运作，业务运营也没理顺（haven't aligned their operations），这种项目注定要失败。」Aaron 特意点明自己「也在这些董事会里坐着」——这不是外人看热闹，是亲历者的吐槽。→ 详细

• Martin 说最近几个月「终于有了一些真正打进 enterprise 的进展」，但「还很温吞（tepid）」。原因之一：组织「不知道该怎么去调整那些围绕数据、治理（governance）、运营、合规（compliance）等等、被打磨了十来年的敏捷流程」——这些本是稳定运转的保障，现在反成接纳 AI 的摩擦点。→ 详细
• 另一关键原因是「大量的怀疑情绪（a lot of skepticism）」：董事会想要 AI，可「CEO 们搞 AI 失败过，留下了一些挫伤（some amount of bruising）」——第一轮失败让人心有余悸，得「先迈过这道坎，才能开始第二轮尝试（the second go at it）」。→ 详细
• Martin 精准概括 Aaron 的处境：他「正好卡在长周期趋势和组织决策机构这两者之间（right between the secular trend and the organizational decision body）」——一边是势不可挡的大趋势，一边是行动迟缓的决策层，Box 被夹在中间。→ 详细

• Aaron 声明这只是「次要因素，大概只占问题的 5%（a 5% of the problem）」但很好玩：历史上「拖垮一个项目最简单的办法之一，就是卡在架构上」——为「用什么语言、走哪条架构路线」吵起来「可能要花上好几个月」，AI 变化太快把这老问题放大了。→ 详细
• 瘫痪在哪：各家实验室「显然在频繁地互相反超（leapfrogging each other so frequently）」，但范式不统一——agent 怎么 deploy、harness（agent 运行的「外壳/沙盒」）在电脑里还是电脑外、自己的云还是托管、能访问哪些工具……Aaron 强调「远没到这些技术可以完全互相替换（fungible）的地步」。→ 详细
• 结果是「瘫痪（paralysis）」：架构团队会想「我到底该押哪匹马（what horse do I want to get behind）」，因为「三四年前在 AI 上做错过选择、被坑过」。Aaron 去问 CIO「核心的 agent 编排（orchestration）用什么」，几乎每个客户都回答「我们正在这两三种范式之间争论不休」。不锁死也有代价（要为某种「两头兼顾」duality 开发）。但 Aaron 反而觉得「没什么大不了」——基础设施本就有大量升级活儿，只是这次变化速度「削弱了技术扩散进那些真正至关重要的 workflow 的能力」。→ 详细

• Martin 描述「非常重大的架构和思维转变」：与其把 AI 当软件硬融，不如「就把它当成一个用户（just view it as a user）」——把产品做成 CLI 工具（命令行，机器最易调用的形态），让 AI 当「真正去使用它的 agent」，「你就不是把两者硬融，而是单纯让它对 AI 更好用」。→ 详细
• Box 自己一年内被迫「把软件重新架构了两次（re-architect twice）」：① 一开始是「纯产品（pure product）」；② 搞了个「AI 与软件的混合体（AI software hybrid）」——「结果它没跑通（hasn't worked）」；③ 现在转向「agentic 模式」——「那个 agent 可以是任何东西，可以是 Claude Code 之类，而我的产品现在就应该只是个能被它消费的东西」。Aaron 说全行业都在经历这种两难、拼命搞清最终形态。→ 详细
• Steven 类比：云计算当年也有「混合版本」「远程桌面（remote desktop）」这类过渡形态。Martin 说现在「差不多是在『速通』那段演化（speed running that evolution）直奔最终形态」，但中间形态一个不落——并点出硅谷盲区：「硅谷的人不太能体会，当一家大公司说『我们得把要押的赌注规划清楚（map out our bet）』时是什么意思。」→ 详细

• Martin 调侃：在创业者眼里规划长期赌注「就显得很蠢（seems stupid）」，因为「如果你的履历是在创业公司里待过五段、每段两年，从种子轮到 A 轮再到被收购，那你其实啥也没学到」——这种履历从没经历过为十年后负责的决策。→ 详细
• Aaron 补一个极具画面感的对照：「你的参照系里压根没有『挑一套要用上四十年的应付账款（accounts payable，企业付供应商货款的财务系统）系统』这种事。」创业者两年就退出，不会去想一套系统稳定服役四十年是什么概念——而大企业天天面对这种决策。→ 详细

• Aaron 准备了「一堆视觉道具」。第一个：硅谷终极工程师典型是美剧《硅谷》里的 Gilfoyle——「我不想跟任何人说话，我就负责写代码」；企业里也有人想这么干，但「只会在集成这一关撞墙」。他第二次完整重申主旋律：任何超 1000 人或超 10 年的企业都堆着一大坨等待集成的东西，「你不能光嘴上说一句它会自动集成，AI 其实根本帮不上集成的忙」。→ 详细
• 律所出现 AI 幻觉（hallucination，模型一本正经编造不存在的信息，如虚构判例）毁掉官司的真正原因，Aaron 一针见血：「之所以会这样，是因为那个 25 岁的助理（the 25-year-old associate）早就已经在成功地用 AI 了，而且已经用了一年。」采用（adoption）是自下而上、悄悄发生的，幻觉事故只是这股暗流浮出水面，不代表 AI 没被用起来。→ 详细
• Martin 说现实「比那还要糟一点」：很多公司激励员工用 AI 的方式是去「数 token 消耗量（counting tokens）」——把烧掉多少 token 当 KPI。他转述某大公司员工原话（出于保护没点名）：「我和我同事让 agent 去干一些毫无用处的活儿，纯粹就是为了……（Me and my coworkers have agents do useless tasks just so that we can…）」配上经典谚语「你考核什么就会得到什么（you get whatever you measure）」，结论是：你会得到一批人「假装高产（fake productive）」，搞出一大堆「有点麻烦的产物（problematic artifacts）」——激励错位的典型恶果。→ 详细

• Aaron 先用「死网页」小故事铺垫互联网早期乱象（每个内部团队找供应商写 HTML 做网站，团队半年就重组，于是公司里「堆满成千上万个死掉的网页 dead web」），再切正题：用打客服电话作比——系统搞不定时「你就会被实实在在地转给另一个人（bounced to another human）」（「哦那得找经理」「你说的是付款，不是预订」），因为「每个人手上其实是一套不同的访问控制权限（access controls）」，而 agent「目前还没有真正的机制能不掉进同样的坑」。→ 详细
• 关键安全逻辑：agent 若能「绕过其中任何一步」，「你瞬间就会引入安全风险」——那些层层转交的步骤本身就是保护，「你必须得走完那些步骤，这样你才不会一不小心拿到错误的信息」，中间「还有验证环节（verification）」。所以让 agent 跟所有系统打交道「还有很多东西要搭建起来」。→ 详细
• 更要命：大多数 legacy（遗留）环境「根本就没有最权威的那套访问控制」。人靠「嘿 Sally，能不能把那个我没权限看的东西分享给我？」「嘿 Bob，这个数字是多少？」临时打通；可 agent「拿到的权限跟你完全一样」就会「到处碰壁（run into these walls everywhere）」，且「不会想到要去找 Sally 聊、问 Bob」，结果卡在那儿，拿到「错的数字、错的文档」，在并非权威信息源的系统里瞎转悠。→ 详细

• Aaron 说创业公司是「绝佳的时机」——「你从一开始就把所有问题都摸清了（know all the problems right out of the gate），可以把组织设计成尽量避开这些坑」。但对大公司，「要做的功课是实打实的」：怎么升级系统？怎么把技术环境现代化（modernize）？怎么保证 agent 能拿到「正确的数据、正确的文档、正确的上下文」？这些就是「接下来要做的事」。→ 详细
• 一个被误读的新闻：OpenAI 用 Codex（OpenAI 的编程 agent）跟 Accenture（埃森哲）、Deloitte（德勤） 这些大型系统集成商（system integrator，专门帮企业部署、对接 IT 系统的咨询公司）合作。网上「阴阳怪气」觉得讽刺——「我们居然得请人来部署那些要去把人自动化掉的 agent」。Aaron 说这恰恰显示「搞技术的人和其他所有人之间的鸿沟有多大」，在他看来这是「史上最显而易见的一个公告（the most obvious announcement of all time）」：大企业「必然要经历变更管理（change management，引入新系统时配套的流程改造、人员培训、迁移）、系统实施、技术集成这一整套流程，agent 才能真正上岗干活」——「你确实得做海量的工作」。→ 详细
• 商业含义：「会有公司专门做这个，一做就是几十年（businesses doing that for decades）」——这对「下一代的服务公司，以及那些愿意拥抱这件事的现有公司来说，都是个不得了的机会」。→ 详细

• Aaron 提醒「不该幸灾乐祸于这些项目失败」——但它们「一定会失败」，因为「很多都是那种自上而下的强制指令（top-down mandates）」。典型机制：高层「挑了公司里最尖锐的那个问题（the most acute problem），然后想『AI 能去把它解决掉』」，结果「IT 那帮人会想『我的天，这是最最糟糕的系统去硬上这个的对象』」——被挑中的往往恰恰是最难、最不适合先上 AI 的那个。→ 详细
• 但高层会「执着于解决它」（「最可能是客服那边的人会特别执着」）。这种「优先级错配 + 高层执念」是企业 AI 项目失败的常见根因：不从最容易见效处起步，而被最痛、最难啃的问题牵着走。→ 详细

• Aaron 第一条建议：别只想着「我只跟市面上所有的 headless（无头，剥掉图形界面、只留可被程序调用接口的软件形态）SaaS 软件打交道」，「因为根本就不会有那么多 headless 软件」；你真正能做的是「把你提供的价值结构化（structure the value that you offer）」。→ 详细
• Martin 点出关键岔路口（fork）：「这个 agent 是去寻找信息、然后呈现给某个人看的？还是这个 agent 应该去采取行动、去做某件事？也就是它是在『获取（acquiring）』还是在『执行（doing）』？」他借互联网史佐证：「互联网变得极其有价值，是从它第一步只是给人们提供访问各种东西的能力开始的」——先「看得到」再谈「做得了」。→ 详细
• 网页怎么「成了集成层（integration point）」：当人们能查「按部门拆分的报销报表」、查「我们收购的那两家公司合在一起的当前库存状态」时，网页就从展示页变成接入点。Martin 点名 Aaron：正因为有 Box，「跨文件去学习这件事，变得比以往任何时候都更可行了」，甚至「AI 可能是头一回让公司内部搜索（inside a company search）真正能立刻产生价值的时候」。汇聚信息后再加一个「带『批准 approve』『拒绝 reject』按钮的 agent」，就从「获取」过渡到「执行」。→ 详细

▲ 字幕条直接点题「DEBATING AGENTS」——整场是围绕「该把 agent 当软件还是当人」展开的辩论；右侧直播弹幕也在围观这场分歧。

• 全场最重的一段。Aaron 先承认对方观点「是个非常站得住脚的观点（a very legit view），但它不是唯一的观点」。他把主流看法复述清楚：「AI 就是软件，它以一种不同的方式运作；我们有一套现有系统，得把这种新型软件跟已有系统集成起来，让它能拿到数据、能干活，但要以一种安全的方式。」→ 详细
• 然后抛出「端到端论证（end-to-end argument）」，说明为什么这「其实不是关于演进软件系统的」：「这些 LLM 是非确定性的（non-deterministic，同样输入未必给同样输出），它们很聪明，它们能应对那条长尾的复杂性（the long tail of complexity，各种零碎、罕见、难穷举的情况）。而结果发现，这些恰恰也是人类在做的事。我们花了四十年去构建界面、流程和设计，就为了应对乱糟糟的人类（messy humans）。我们知道该找谁、我们有访问控制。」→ 详细
• 结论：「如果你抱着『agent 更像是一个人』的心态去看待它——你雇了这个 agent，给它一个自己的邮箱地址，它能像人一样访问文档，能登录，能去申请它需要的东西——那么它就会顺势搭上我们为人类（而不是为软件）建立起来的那一整套流程的便车（drafting on all of the process）。」他承认自己的立场转变：「我跟你们一样是搞软件出身的，我总是把每个系统都当成软件来想，但这些模型跟软件集成得并不好。我其实觉得……如果你把它们更当成人来看，顺势用上我们为人类建立的那些机制，它们反而会容易集成得多。」Martin 当场表示「这点我们绝对是认同的」，分歧只在后面。→ 详细

• Martin 反驳：人类有「一堆 agent 没有的额外优势」——大量上下文是「天生免费获得的（gets for free）」，因为「我们能记住自己在组织里建立起来的那一大堆错综复杂的关系（myriad relationships），知道在需要把某件事办成、或拿到某个信息时该去拍谁的肩膀（who to tap on the shoulder）」，而这些「在公司里目前还没有被记录下来，至少没有以一种 agent 能直接顺势利用的方式记录下来」。→ 详细
• 他给出 agent 的两面对比：agent「既处在一个巨大的优势上，能并行工作、几乎能无限扩展规模（work in parallel at infinite scale）；又处在一个劣势上，就是它们不知道该去拍谁的肩膀」。优势是规模，劣势是隐性社会关系网。→ 详细
• 半玩笑半认真的解决方案——「agent 入职（agent onboarding）」：Martin 说「我完全支持给 agent 做入职。比如 agent 来了，先去参加入职培训（orientation），然后 CEO 给它讲一通公司文化（culture discussion），接着每个部门都做一遍介绍——我没开玩笑（I'm not kidding）」。Aaron 补理论支撑：「鉴于这些 agent 的技术特性，以及它们身上有多少熵（entropy，混乱度/不可预测性）、有多么不受控（unruly），我们将不得不沿用我们围绕人类打磨出来的那些流程。」上升为方法论：这件事「更多是关于给它们提供学校（providing schools），而不是去搭建什么花里胡哨的索引数据库（fancy index database）」——与其给 agent 造全新机器索引，不如直接让它走人类那套培养流程。→ 详细

• Aaron 指出这跟「人形机器人（humanoid robots）会是最好的那种机器人」是「同一个论证」：根本理由是「我们有一整个为人类设计的世界（a whole world designed for humans）」——世界按人的尺寸、人的交互方式造，越像人的机器/agent 越能直接复用它。→ 详细
• CES（消费电子展）真实案例，极生动：Aaron 看到「一个机器人走进电梯，电梯里还有另一个专门按按钮的机器人」。为什么两个？因为前一个「是个小不点儿，像地上的扫地机器人（Roomba），它够不着按按钮」。于是「发明那个机器人的同一家公司，又发明了一个你买来装在电梯里、专门帮忙按按钮的装置」。Aaron 追问厂商「你们为什么需要一个装置去按按钮」，对方答：「因为电梯没有可以让机器人接入的系统，电梯里没有『用 Wi-Fi 按按钮』这种能力」——「没有那个 API，压根就没有 headless 版本的电梯（no headless version of the elevator）」。→ 详细
• 这个电梯故事被 Aaron 定为「企业用 agent 实际要解决问题的绝妙比喻」：世界上「就是有两类系统，一类是给人用的，一类是给软件用的（those for humans and those for software）」；而这些 agent「更像人」，所以「我们应该尽量顺势搭人类那一套的便车，而不是想方设法去硬改它们（rather than try to retrofit them）」。→ 详细

• 上周大新闻：Salesforce（全球最大的客户关系管理 CRM 软件公司）「彻底 headless 化（went full headless）」，基本是在说「我们想让我们各种各样的 agent 在各处都能被用上（used everywhere）」。从反应看「似乎确实有点出乎意料」。Aaron 把它看作「一个有点风向标意义的事件（a bit of a bellwether）」，并给出判断：「Salesforce 怎么走，很大一部分 enterprise 软件就会跟着怎么走。」→ 详细
• headless 世界的新商业模式仍悬而未决，Aaron 抛出两个可能：「你是收一点点小小的 API 税（a small API tax）？还是给 agent 设一个席位（seat，软件按『一个使用者』计费的单位）？」（他提到 Steven 有条推文也讲到其中复杂之处。）他认为这个时刻「作为一个标志性时刻是件大事」，因为它是一种承认：「软件将会在后台运行——它一直都是这样为机器用户和应用程序服务的，而现在它要为这些概率型的机器用户、或者说非确定性的机器用户（probabilistic / non-deterministic machine users）服务了。」→ 详细
• 为什么让 Aaron 兴奋：一看到公告，「脑子里马上就冒出五到十个我个人的用例（five to 10 personal use cases），我会需要一个 headless 版本的 Salesforce」，因为他「总是在做海量的客户相关情报工作（customer related intelligence work）」——「我要去开个会，我需要一些信息；我要去某个城市，我该跟谁见面？」核心红利在规模：「headless 用户可以达到那些人类用户一百倍、一千倍的规模（100 or 1,000 x the scale）」。过去「你通常是被这些平台上的人数给卡死的」，现在打开了「相当疯狂（pretty wild）」的用例空间。→ 详细

• Aaron 说「用『agent 只是一个实体（entity）』这个观念来看，对我来说极其显而易见的是，它就是又一份 license（许可证）」。它的「license 模式也许不一样，但它必须得有一个身份（has to have an identity）」。他举 Box 自家 CRM 为例（顺口问 Martin「我不知道你们用不用 Salesforce」）：在里面查东西「必须是一个『人』，带着一定量的访问权限」。→ 详细
• 权限分层的例子：「你作为 CEO，大概能访问一大堆东西，但也有很多情况下，他们其实并不希望你在某些时刻拥有某些权限。」比如「你也许能看到账户上有哪些人，但你不需要看到这些销售人员最新的业绩配额（up-to-date quota），那可能涉及 HR 敏感信息，你大概得有另外一个层级才能去看」。由此引出核心原则：「顺着组织往下走，agent 永远不会拥有比那个指使它去干活的人更多的权限（the agent is never going to have more permissions than the person who's getting it to go do something）」，「它就会像组织里另一个人的同侪（a peer）一样」。否则就会出现漏洞——「一个人可以直接说『给我弄一个无所不知的超级聪明 agent，把我本不被允许知道的东西都告诉我』」。→ 详细
• 为什么必须「从一开始就把它建对（build it right from the get-go）」：你「不能让 agent 先把结果拿到手，然后再回头去琢磨哪些能用哪些不能用」。因为 LLM 是随机性模型（stochastic），输出「不像 SQL 表里的一条记录，你可以直接套个 ACL（Access Control List，访问控制列表）上去」——它的输出「可能是一句话里的某些词，或者只是冒出来的一个数字」，没法事后逐条贴权限。Aaron 直言：SaaS 公司若想「用另一个人的凭据（use the credentials of another human）」就是「疯了，那从一开始就是糟糕的安全实践（bad security practice from the get-go）」。→ 详细

• Aaron 的金句式判断：整个关于 headless 的讨论，「让那个所谓的『SaaS 末日论（SaaSpocalypse，认为 AI 会让传统 SaaS 软件消亡的论调）』显得比它本来就有的还要更蠢——它本来就已经够蠢了」。他形象描述认知过程：「一开始它很蠢，然后我心想『我的天，它实际上比我一开始以为的还要蠢得多』。」→ 详细
• 理由是「你将会迎来一场大爆炸（explosion）」——指席位数量的暴增。Aaron 也留余地：「可能有人会想出一套很聪明的定价方案，让 agent 不知怎么地成本更低——也许头五年它们是只读的（read-only），或者它们总是被绑定到某个人身上之类的。」但底线不变：「它就是又一个席位（seat），这事儿没有任何办法绕过去（no way around it）。」既然每个 agent 都是一个席位，软件席位只会暴涨而非消亡，SaaS 末日论自然站不住。→ 详细

• 轮到 Martin「旗帜鲜明地站到对立面」，论证「headless SaaS 本身就讲不通」。第一个例证：用 OpenClaw（一种能操作电脑的开源 agent 工具）为什么要「配一台 Mac mini」？「第一个原因就是为了 iMessage」——iMessage（苹果私有消息服务）「没有 headless 版本，所以你就只能这么用」，本质是为了集成进苹果生态。→ 详细
• 第二个例证更有意思：「如果你试过让 agent 用 headless 浏览器，问题就在于，所有的网站都有反爬措施（anti-scraping measures），所以它们没法用。」于是「你得用一台 Mac mini，好让它能真正调用正经的 Safari（use Safari proper）」。Martin 给场景：想在 Zillow（美国最大房产估值网站）查房子估值，「headless 浏览器根本就不管用，因为 Zillow 早就受够了被人爬数据」，必须「弹出一个 Safari、直接用正经的 Safari，然后突然之间它就好使了」。→ 详细
• 核心论点：任何「headless 化」设想都「假设了整个互联网都会走向 headless」，可现实是「所有这些模型——所有的数据其实都是人在那些非 headless 的真实应用上操作产生的，那才是全部的数据来源」。所以模型「会非常擅长就像今天这样直接用那些应用」，「正在被实际使用的恰恰是非 headless 的版本」。因此「那就只是 Salesforce 本身，不是 headless 的」——agent 会直接跑去用浏览器、用真 app。（Aaron 夸张地连说一长串「等等」要打断，确认「你的意思真的是 agent 跑去用浏览器？」）→ 详细

• Aaron 让步一半：「任何一个有好用 API 的软件，agent 绝对会更愿意去用那个 API」，只在「碰到某种执行问题、跑不下去的那一刻，才弹进浏览器里去」。但他坚持反驳：现在「如果你真去看这些 agent 的采用情况和实际用法，它们的行为方式更像人类会做的事，而不像一个程序会做的事（far more like what a human would do than what a program would do）」——「也许你说得对（指未来），但首先，我们现在看到的并不是这样」。他还把「端到端论证」拉来佐证：现有管控会默认「这些 agent 本质上会执行和人类一样的操作」，API「会遵循同样的访问控制，取决于背后是哪个用户在操作」。→ 详细
• Martin 反击要害：那套面向 agent 的东西「他们得重建（they have to rebuild it）」——「你有一个现成的 app，模型是基于所有用这个 app 的人训练出来的」，所以模型天然会用界面而非新 API。Aaron 回应这是「完全成立的观点」，但猜测「随着时间推移，你会有非常精准、非常严谨的数据集，让模型可以针对每个 SaaS 平台的 MCP（Model Context Protocol，让模型标准化调用外部工具/数据的协议）、每个 SaaS 平台的 API 去训练」——「其实现在就已经在做了，他们已经在针对我们（Box）产品和 API 的所有文档做训练了」。Steven 贡献金句：「层（layer）永远不会消失，它们只会一层叠一层（layers never go away, they just get layered）。」→ 详细
• Aaron「这一点上我支持你 50%」：「如果你需要搜一份文档，我们的搜索 API 会比你在界面上点来点去更快。」但他用一个亲身震撼承认对方有理——桌面端那个新的 Codex computer use（让模型直接控制鼠标键盘操作电脑）「真的太离谱了（just insane）」：「我看着我自己在移动鼠标，然后另一个鼠标也在移动、在点东西，我当时就想：我已经看不懂电脑了（I don't understand computers anymore）。」Martin 定性：「你俩说的其实是同一件事，只是有个时间维度的差别（the same thing, but there's a time dimension）」——一个讲现在、一个讲未来。→ 详细

• Aaron 给出双方都能接受的折中：他「第一反应是把它用在那种我知道没有现成 API 的场景」，所以「确实马上就拿它去做了一件没有 API 可用的事」。长远看「agent 大概得学会判断：这个操作有没有现成的 MCP 或 CLI，如果没有，那我就切到某种云端浏览器、云端电脑、或本地的东西里去，开个并行线程然后去执行」。但「我还是会在 headless 模式下疯狂调用 Salesforce API，因为那才是查记录的高效方式」——有 API 用 API，没 API 退浏览器。→ 详细
• Steven 的历史类比（极有说服力）：当年微软「关于怎么用 Word 和 Excel 的几百万乃至天文数字级别（8 million quadrillion pages）的网页」，「以前是随产品一起发货（ship them with the product）、存在硬盘上、不联网」。用户问「我怎么做一张冰柱图（ice chart）？」之类的「从来都搞不定」。互联网带来的「净结果（net result）」是连环改进：① 大家都能找到信息；② 这「促使我们把文档做得更好」；③ 「让 Google 搜索更擅长找到它需要的信息」；④ 「这又彻底改变了我们对待做文档这件事的思路」。Aaron 点睛：互联网没改变「问题本身（我就是想做一张图表）」，但改变了「信息被暴露和检索的方式」——这正对应今天 headless 之于 agent。→ 详细
• 由此推出 API 必变：Salesforce 今天的 headless API「我几乎可以肯定，要是我去看一眼，它一定长得像套了一层 CLI 的开发者 API（developer API behind a CLI）」。但这「根本不是人在用 Salesforce 时的交互方式」——人想解决的是「我正站在电梯里准备去见客户，我现在需要知道哪些信息？」（呼应电梯比喻）「这种映射关系完全不一样」，所以「随着时间推移，那个 API 一定会发生很大变化」。→ 详细

• Aaron 指出 agent 相比人形机器人的根本优势：「不像人形机器人那种类比——物理世界有各种有意思的物理限制，你迟早会撞上——数字世界是没有这些限制的。」所以「到某个时候，你的 agent 可以并行跑 500 次（run in parallel 500 times）」，比如「我想给财富 500 强（Fortune 500）的客户做一张市场地图（market map）」，agent 能「扇出（fan out，把一个任务分裂成大量并行子任务）去完成，而我作为一个坐在浏览器前的人是做不到的」。一句话：「agent 让你能够弯折那些基于人类的正常 workflow 的法则（bend the laws of normal human-based workflows）。」→ 详细
• 由此推断 API 演化方向：API「也许最终会演化，但显然不是朝着面向终端用户的产品那个方向，而更可能是朝着一套 agent 式的 workflow（agentic workflows）去演化：那个 agent 到底想做什么？」——API 要服务的是 agent 的并行意图，不是人的点击节奏。→ 详细
• 真实例子把 Box agent 和电梯比喻打通：Box 发布的一个 agent「能在你整个 Box 环境里做搜索，但它没有人类搜索那种局限——人类是打一个查询、拿回一组结果、再翻看一遍——而它会扇出去做多个查询，瞬间翻遍上百条结果（look through hundreds of results instantly），并对结果做自己的重排序（re-ranking）」。Aaron 说「你绝不会想让一个 agent 被人类那套流程的速率给限制住（rate limited by the same process that a human went through）」——对应人形机器人：「你会接受『人形机器人还是会走进电梯、按按钮』，但在 agent 世界里，你会想说『不不，我直接要你瞬间按到我要去的那一层』。」→ 详细

• Martin 提出一个需厘清的区分：「你会不会去建一套只为 AI、而完全不为人类服务的索引（an indexing that's only for AI and not for a human）？」他判断「这就没那么显而易见了」——「很明显，自动化会带来性能上的收益，我们确实得为此演进架构」，但「如果你找到了一种很棒的方式去给文档建索引，却不把它暴露给人类」，他对此存疑。换句话说，纯机器索引未必是终态。→ 详细
• Box 的实践印证 Steven 的「文档类比」，并给出一条良性循环（four-step loop）：① 搭下一代 agent 时「先给了它现有的这套工具，看它怎么用」；② 慢慢发现「其实有更好的方式可以让 agent 来做这件事」；③ 于是「改进了底层的脚手架（scaffolding，支撑 agent 运行的底层工具与框架）」；④ 「那个改进其实也会帮到终端用户」。Aaron 把这机制叫作「把成果反哺回技术进步的『母舰（mothership）』里，从而水涨船高地抬升你所有用户的体验（lift all the boats）」——为 AI 做的优化最终也惠及人类用户，不是非此即彼。→ 详细

• Martin 抛出让他「整个人都绷紧了」的担忧：「我们今天有一万个人在打我们的 SaaS 系统，全跑得好好的。但现在要凭空多出一万个新『人』，也就是这一万名员工各自对应的 agent，它们对系统的访问量其实是原来的 500 倍。」结论是「那这个 SaaS 产品就会崩（will collapse）」——「这是第一阶效应（first order effect），因为它当初根本没按这个量级设计」，且「不只是 token 的问题，是实打实的：我们根本没有那么大的网络带宽和吞吐量，去为任何一个客户扛住 500 倍的量」。→ 详细
• 历史先例 BI 工具（Business Intelligence，商业智能/数据分析）：「当所有 BI 工具冒出来时，它们突然都盯上了 SAP（全球最大企业资源管理软件）的数据，想每晚把整个数据库吸收进来（absorb the whole thing every night）做切片切块（slice and dice）」。结果「所有做 ERP 的人都说『我们不干这个』」，BI 厂商「只能自己去把这一整套都建出来，因为他们才掌握着数据的知识；ERP 的 API 压根不是为这种工作量设计的」——访问模式被彻底改变时，旧 API 顶不住，新需求只能由更懂数据的一方另起炉灶。→ 详细
• Martin 自抛一个「挑衅性的旁支观点」：他「不确定『agent 更多了』算不算多大的架构转变」——「如果是只读数据，你就缓存它（cache it）；所有状态问题都围绕着可变的、全局共享的状态（mutable globally shared state），我们清楚边界、知道怎么绕开，当年上互联网这些问题就得解决一遍」。所以扛不住「只能说你系统建得烂，那就去重建一个不烂的呗」，这「其实是挺标准的计算机科学」。（这段还插科打诨用网络黑话「mogging / mog」，Martin 旋即强调「不，问题还在那儿」，铺垫下一个真正棘手的。）→ 详细

• Martin 用编程举一个「我真心认为工作方式会发生转变的地方」：「当你用 AI 写代码时，你的代码会随着时间推移变得明显更糟（gets worse over time pretty materially）。所以几乎就像，你在引入的问题和你在解决的问题一样多（introducing as many problems as you are solutions）。我觉得我们其实还没真正搞清楚怎么管理这件事。」他强调「现在全世界都百分之百是这样」。→ 详细
• 由此提炼全场最深的「悬而未决的问题（open question）」：当你「在现有系统上用 agent 去创造东西时，我们到底知不知道怎么把那不断膨胀的熵给包住、管住（wrap the growing set of entropy around that）？」Martin（声明「我跟很多 AI 编程公司关系都很近，我对它非常看好」，不是唱衰）坦言：「看着各家公司在 AI 编程上挣扎，我觉得我们还不知道怎么做到这件事。」→ 详细
• 关键区分（他全场最重要的一刀）：「把 agent 用在一套系统上，我觉得我们能用已知的技术（known techniques）去应对」——这是工程问题，可解；「但是在组织层面把 agent 用在那种长期运行的事情上（long-running things organizationally），让宇宙保持得像你刚开始三天后那样干净，我真不太确定我们到底知不知道该怎么做。」短期单系统可控，长期全组织的熵失控才是真正的未知。→ 详细

• Aaron 说这个熵的难题「又绕回开头那个点：规模化和非规模化的区别」，也解释了为什么大公司说「绝对没门，这玩意儿别想进我们公司（No freaking way is this coming into our company）」是「完全理性的」——因为大公司、事业部、产品「随时都快散架了（the wheels are going to come off at any minute）」。→ 详细
• 巨型公司高管的「典型一天」（金句，Martin 和 Steven 都当过大公司高管）：「我们每天早上醒来真的就在想——哦，今天轮子要掉了，这就是末日了，五点我就要被炒了（I'm getting fired by the 5:00）；昨天我走时本以为已经晚了三个月，结果现在变成晚了九个月了。」这是「稀松平常的一天」。而「它之所以最终没真散架，是因为你在所有地方都设了约束（you put constraints all over the place）」——约束不是官僚主义，是大公司不解体的命根子。→ 详细
• 这正好解释两类人为何水土不服：「Gilfoyle 没法在大公司干活，因为他自以为什么都懂」；那些「一发入魂」的 vibe coding（凭感觉让 AI 一把生成代码、不细究细节）派会毫无负担地说「没事的」，是「因为他们从来没在那种环境里活过——在那种环境里，约束的存在就是为了防止整个东西自己塌掉（prevent the whole thing from imploding）」。→ 详细

• Martin 抛出一个漂亮框架（自承「听起来有点跑题，但其实接得上」）：「核心技术往往都迎合了人类的某种需求（catered to some human need）——互联网迎合的是连接（connectivity），社交网络迎合的差不多是虚荣（vanity），而我觉得 AI 迎合的是我们想要『高产』的需求（our need to be productive）。」每代技术都踩中一个人性按钮。→ 详细
• 危险之处与「假装高产」「熵累积」首尾呼应：「我们做这一切的时候，会觉得自己特别高产（feel like we're being very productive），但我们也许实际上是在给自己堆出一座又一座额外要做的活儿（creating mounds of extra work to do）。」迎合「想高产」的快感，可能反而制造更多隐性债务。→ 详细

• Martin 直接点 Box 现身说法：「Aaron，你现在正在部署 AI 啊，Box 整个都押上去了（all in），分享个故事吧——轮子掉下来的，或者没掉下来的。」Aaron 说 Box「大概处在那条光谱上比较务实的那一段（the more pragmatic part of the continuum）」，所以「不会声称这给我们工程团队带来了 10 倍的生产力提升」——因为「我们设了很多护栏（guardrail），它们会在系统里自动制造出这些约束」，并且「仍然非常依赖代码评审（code review）和安全评审（security review）」。→ 详细
• 一个具体的「限速」故事：「我们新发布了一个功能，我当时就喊『冲冲冲冲（go go go go）』，AI 大概搭出了这个功能的 80% 到 90%。」但「真正拖慢它发布的，是我们必须做一次完整的安全评审，因为我们不能让我们造出来的东西里出现任何意外的代码注入（accidental code injection，恶意或意外的代码被塞进系统造成安全漏洞）」。结论：「有很多地方，你前面跑得超快，但接着还是会被流程中的另一个环节给限速、给卡住（rate limited or constrained by some other part of the process）」——可能是安全评审、代码评审，或「把东西推上生产环境的那条流水线（pipeline）」。→ 详细
• 量化结论：「我不觉得这是 5 到 10 倍的提升，我确实认为它差不多是全方位 2 到 3 倍的提升（two to three x gain across the board）。你仍然会被『你能多快地评审这些东西、检查这些工作』给限速。」所以 Box「正在对整个产品研发生命周期（product development life cycle）做相当多的重新改造（retooling）」。Aaron 还点出一个顺序判断：「工程师会最先碰到它，也会最先找到那个合适的均衡点（equilibrium）；更难的部分仍然留在其余的知识工作里。」→ 详细

• 会计场景的「均衡点」还不清楚：「如果你是做会计的，我们还不太清楚你什么时候能放手让 AI 去做一整套完整的会计审计（full accounting audit），因为现在还做不到」——这是一个还没法完全交给 AI 的高风险环节。→ 详细
• AI 现在能做、且很有价值的部分：「让 AI 去梳理海量到没有上限的数据（comb through unlimited amounts of data），找出那些异常（anomalies），提醒你的财务团队：我们得深入查一下这个。」Aaron 称这「特别棒，因为这是一种全新增加的可见度（net new level of visibility）」——不是替代人，而是凭空多出一双能看遍全部数据的眼睛。而「用细齿梳一根根去核对、确保每一个数字都准确无误（a fine-tooth comb）的环节，现在大概还是得靠人」。Aaron 把全行业任务概括为：找到生产力「在哪里最有效、能拿到收益、副作用又最小（most potent, get the gain, with less of the downside）」的那个点。→ 详细

• Aaron 对就业「依然抱有难以置信乐观态度（unbelievably optimistic on jobs）」。理由：「在判断哪些地方会把人从流程里剔除出去这件事上，我们一直搞错了（we've gotten it wrong），因为你在流程里某个环节始终还是需要一个人（you still need a human somewhere in the loop）。」→ 详细
• 他承认抽象层次抬高了：「也许你不再需要像一年前那样在每一个阶段都有人盯着（don't need the human in the loop at every single stage）」，但人的角色没消失、而是上移——「你确实需要有人去启动整个流程（kicking off the process）、审阅流程（reviewing）、并把产出成果整合进去（incorporating）」。所以这「在这些组织里仍然创造了海量的就业机会」。→ 详细

• Martin 举书为证：90 年代有本《工作的终结（The End of Work）》「差不多在互联网爆发前六个月出版」，核心论点是「技术革命彻底失败、生产力毫无收获；但再也不会有新工作了，因为经济停滞——而写这书的家伙自称是个未来学家（futurist）」。他借此点出认知模式：「很多观点你第一次听到觉得它蠢，回头想想会发现『天哪，它其实蠢得更彻底（way stupider）』。」→ 详细
• 会计师先例：「『AI（计算机）就是要消灭工作』的想法跟会计师那个例子一样古老，那基本就是 IBM 在 1965 年左右的推销话术（IBM's pitch in like 1965）。」但「计算机实际带来的结果是：既然会计师不用整天就只是加数字了，我们现在能在会计这件事上做多得多的事」——技术没消灭会计，反而把它做大了。→ 详细
• 核心经济学论断：对「懂行的人」来说「AI 是一个加速器（accelerant）」，而「企业会突然想要更多这样的人，去生产更多这样的信息」。更关键的闭环：「如果 AI 在创造有价值的信息、而且信息越来越多，那就需要更多人去消化这些信息、去做点什么。」因为——全场反复出现的命题——「一家公司的本质，就是依据信息采取行动（the essence of a company is acting on information）」。所以「『信息将被轻易生产、然后供给过剩却没人用』的想法，完全说不通」。→ 详细

• Aaron 点出瓶颈转移：「在非结构化信息（unstructured information，指文档、邮件、合同、图片等没有固定字段格式的信息）的世界里，问题在于你能造出信息，但对它的消化吸收才是真正的瓶颈（the consumption of it effectively is the gating factor）。」生产端被 AI 解放，消化端反成新卡点。→ 详细
• CPA（Certified Public Accountant，美国注册会计师）案例：Box 审计委员会主席（CPA 出身）讲职业生涯早期工作流程，Aaron 说「听起来太手工了，我都不知道那个世界是怎么运转的」。关键洞见（「正好出自你 Steven 书里的观点」）：「正因为当时一切都没数字化、相对纯手工，所以你能做的事在数量上其实相当有限，流程反而很简单（quite simple）。」手工时代不是更复杂，而是被复杂度天花板压住、只能做少量简单的事。→ 详细
• 计算机的真实作用：它「实际上只是让它变得更复杂、更全面（more comprehensive），从而创造出更多工作」。这是会不断重演的规律——「现在我们终于负担得起把事情做得更复杂（afford to make things more complex）」，而「一旦你把事情做得更复杂，最终你又会撞上新的约束——谁能理解这种复杂性（who can understand that complexity）」。复杂度提升 → 创造新工作 → 又撞新约束，循环往复。→ 详细

• 全场核心金句（Aaron 开场和此处各完整说了一遍，首尾呼应）：「最好笑的概念就是：我们写的代码越多，就越不需要工程师（the more code we write, the less we would need engineers）。恰恰相反，因为现在你的系统比以前更复杂了，这意味着你会撞上更多挑战——当你需要做系统升级、或出现宕机（downtime）、得搞清楚『这问题到底怎么修』，又或出了安全事故（security incident）的时候。」代码越多，要维护、要救火的复杂系统就越多，工程师只会更不够用。→ 详细
• 一句收束：「在就业这件事上，我们才刚刚起步（we're just getting started with the jobs on this front）。」→ 详细

• Martin 用一线数据落地：「我们其实已经进入这个阶段好几年了，你完全可以看看数据。哪些公司招人招得最快？正是那些 AI 原生公司（AI-native companies）。它们在疯狂招人（hiring like crazy）。」需求在涨，不是在消失。→ 详细
• 一个被现实打脸的早期预言：「早期有这么一个预言——AI 写代码会消灭基础设施、会把基础设施商品化（commoditize infrastructure）。这是个相当奇怪的预测，因为现在写出来的软件比以往任何时候都多。」Martin 用自己的董事会席位佐证：「我在一堆基础设施公司的董事会里，其中有些公司业绩平了一阵子，但它们现在全都干得特别好（all doing fantastic），因为软件太多了。」结论斩钉截铁：「如果你看一线公司的真实数据，就是软件更多、AI 原生公司招人招得最猛——所以非常清楚，我们正处在一个扩张期（an expansion phase）。」→ 详细

• Aaron 最后一个大点：硅谷对工程岗「有点目光短浅（a little bit of a myopic view）」，总以为「工程岗位就是你去 Google 上班、或随便哪家科技公司、初创公司」，被「我们都身处的这个生态」束缚住了。他列举一长串被忽视的「真实世界」雇主：John Deere（约翰迪尔，农机巨头） 正在做「自动化拖拉机」、Caterpillar（卡特彼勒，工程机械巨头） 想要「AI 系统」、Eli Lilly（礼来，制药巨头） 想要「设计出更多的药物、治疗方案（therapeutics）」——「你还可以一路数过另外五千家公司（5,000 other companies）」。→ 详细
• 这些公司「现在都将拥有下一代工程师（the next set of engineers）」，他们会「用 Claude Code、Codex 和 Cursor（三款主流 AI 编程工具）去把自家业务的更多环节自动化，去为他们的 workflow 和系统设计、开发出更多软件」。Aaron 给出生动的职业图景转移：「可能只是说，你不再去某个社交网络工作、去改进社交网络算法，而是去 John Deere 上班、去改进那个智能农业算法（intelligent farming algorithm）。」→ 详细
• 这正是 Marc Andreessen（马克·安德森，a16z 创始人） 15 年前「软件将吞噬世界（software's going to eat the world）」预言的真正含义：它「意味着每个人都将拥有大量软件（everybody's going to have lots of software）」。AI「给了每个人终于能拥有大量软件的能力，但你仍然需要一个专家、或者半个专家（an expert or a semi-expert），去真正给那个 agent 下提示、告诉它该做什么，去审阅它的工作、去管理它搭建出来的系统」。所以那些「『别去搞编程、别去做软件工程』的预言，我认为会被证明是大错特错的（proven quite quite wrong）」。→ 详细

▲ Steven（左）举起一篇旧报道《Fighting the Paper Chase（与纸海搏斗）》当视觉道具——印证「每一代技术初期都被预言成只会『把纸质工作自动化』，却没人料到它其实放大了工作量」。

• Martin 的「基本盘（base case）」：「这一切的基本盘就在于，现在外面有太多人不喜欢技术，而且用一种静态的眼光看世界（a static view of the world）。所以当人们听到『自动化』这个词时，就直接假设它会把东西夺走（assume it's going to take things away）。」用静态视角看，自动化必然零和；但世界其实是动态扩张的。→ 详细
• Steven 给出 1981 年《时代（Time）》杂志的例子：当时「对计算机将要做什么的整体看法是：它们会把公司里的纸质工作自动化」，所以「第一代计算机的整个理念，字面意义上就是把纸质表格搬到屏幕上，再打印出来」——预言又一次只看到「替代」没看到「放大」。（他还提到文章《与纸海搏斗（Fighting the Paper Chase）》。）→ 详细
• 律师案例（最完整的「计算机化反而扩张职业」例证）：「曾经有个年代律师是不打字的——他们雇一批『律师助理（paralegal）』负责所有打字。」Steven 讲史实：80 年代初「哈佛有几个学生把一台最原始的笔记本电脑带进课堂，结果因为用它被赶了出去」（因为「过去读法学院你得用手在本子上写文章 write essays in longhand」）；而「现在你当然是直接打字，还能访问所有判例引用的数据库（the database of all the citations）」。结论极有力：「现在没人会去找一个不用『修订模式（track changes）』跟你处理合同的律师」；「据我所知，今天的律师比 30 年前多得多（way more lawyers today），而且你接触到的每一个真人律师都是『计算机化的律师（computerized lawyer）』。」技术没消灭律师，反而让律师更多、人人更强。→ 详细

• Aaron 做了一段自我修正（坦言「作为一个特别热爱技术的人，我真希望这是真的」）：「我们也许过度假设了——好像每个人的工作就是待在 Microsoft Word 里、就是在敲一份 Word 文档（typing a word document）。」这个假设把工作想得太「干净」了。→ 详细
• 他用跟律师打交道的真实体验反驳：「大多数时候我跟律师在一起，都是在谋划某件事（strategizing something）。」他当然「可以去找 AI 要建议」，但「那其实大概只会增加我去打电话给律师的概率（only increase the chance that I go and call a lawyer）」——去问「你怎么看我们正在处理的这个情况？」AI 不替代专家，反而催生更多咨询需求。原因是「很多这类工作都带有大量上下文，这些上下文并不是干干净净地就摆在电脑上等着干活的（not sitting literally on the computer）」，工作「确实需要去『接接地气（touch grass，网络俚语，原意去户外走走、别老对着屏幕，此处指回到真实世界的语境）』，这是工作的一部分」。→ 详细
• 终局观点：「AI 会帮忙把内容和信息的创造、生产以及审阅自动化，但接下来这些还得被整合进真实世界、整合进真正价值的生产里（incorporated into the real world of real value production）。」结尾很真实——三人直播状态、约定 4:00 结束，Aaron 现场即兴：「我猜这意味着我们就这么停下，然后灯光淡出或者怎样。我们谁都没干过这个，不知道接下来该发生什么。」最后「有人朝我挥手、微笑着说『是的，你说得对』——那个微笑的意思是『别说了（stop talking）』」，于是仓促道别「各位再见」。→ 详细

• 「我现在的工作就是尽可能地把现实带给硅谷，再把硅谷带回到现实里。」（Aaron 自述定位）→ 详细
• 失败剧本：「董事会说『我们得多搞点 AI』→ CEO 说『好，我请个咨询顾问来多搞点 AI』→ 立了个没人懂、运营没理顺的集中式项目 → 注定失败。」→ 详细
• 「AI 没什么不同、agent 解决不了、什么都解决不了的一点是：任何超过一千人、或者成立超过十年的企业，都堆着一大坨东西在那儿等着被集成……AI 其实根本帮不上集成的忙。」（全场主旋律）→ 详细
• 「如果你把它们更当成人来看，顺势用上我们为人类建立的那些机制，它们反而会容易集成得多。」（端到端论证）→ 详细
• 「没有 headless 版本的电梯。」（CES 电梯按钮机器人，世界只有两类系统：给人用的、给软件用的）→ 详细
• 「agent 永远不会拥有比那个指使它去干活的人更多的权限。」（权限分层原则）→ 详细
• Steven：「层永远不会消失，它们只会一层叠一层。」→ 详细
• 「我看着我自己在移动鼠标，然后另一个鼠标也在移动、在点东西，我当时就想：我已经看不懂电脑了。」（Aaron 谈 Codex computer use）→ 详细
• 「用 AI 写代码，你的代码会随着时间推移变得明显更糟……你在引入的问题和你在解决的问题一样多。」（熵的累积）→ 详细
• 大公司高管的典型一天：「每天早上醒来就在想，哦，今天轮子要掉了，这就是末日了，五点我就要被炒了……它之所以没真散架，是因为你在所有地方都设了约束。」→ 详细
• 「互联网迎合连接，社交网络迎合虚荣，AI 迎合我们想要『高产』的需求……但我们也许实际上是在给自己堆出一座又一座额外要做的活儿。」→ 详细
• 「一家公司的本质，就是依据信息采取行动。」（所以信息过剩没人用的设想说不通）→ 详细
• 「最好笑的概念就是：我们写的代码越多，就越不需要工程师。」（恰恰相反）→ 详细
• 「软件将吞噬世界，意味着每个人都将拥有大量软件」——但仍需要专家去给 agent 下提示、审阅、管理它搭的系统。→ 详细
• 「很多工作带有大量上下文，并不是干干净净地就摆在电脑上等着干活的……需要去接接地气。」（收尾）→ 详细

本场为自由对谈，无独立「闪电问答」环节。收尾要点已在主题 37 收录，核心收束如下：

• Aaron 的终局判断：AI 会帮忙自动化内容/信息的创造、生产与审阅，但产出「还得被整合进真实世界、整合进真正价值的生产里」；很多工作带大量「不在电脑上」的上下文，需要「接接地气（touch grass）」。→ 详细
• 全场被引用的具体作品/产品：书《工作的终结（The End of Work）》（90 年代）、1981 年《时代》杂志封面、文章《与纸海搏斗（Fighting the Paper Chase）》；产品/工具：Salesforce、Box（CRM 与 Box agent）、Claude Code、Codex、Cursor、OpenClaw、Zillow、iMessage/Safari、Mac mini；公司案例：OpenAI×Accenture/Deloitte、John Deere、Caterpillar、Eli Lilly、IBM（1965）；流行文化：美剧《硅谷》里的 Gilfoyle。→ 详细
• 三人是直播状态，约定 4:00 结束，因「谁都没干过这个、不知道该发生什么」，靠现场人微笑示意「别说了」而仓促道别。→ 详细