State of Enterprise AI 2026: Aaron Levie on Tokenmaxxing, Rise of Headless, and AI-Proofing Your Job

可以这么说：假如你现在拿到 GBT 5.5 或 Opus，然后立刻拍板定方案，你大概也许能在两三年内把这种 diffusion（扩散式）能力落地进去，而我们作为整个 ecosystem（生态系统）也许也能集体完成这些 change management（变更管理）。问题在于，突破发生的速度一直比客户实施任何一种标准架构的速度还快。而这些突破往往又会让你上一次刚实施的东西变得过时。这是一种很苦乐参半的情况：技术进步太快了，快到会让你之前部署的东西失效，而这实际上反而意味着整体 rollout（推广落地）会花更长时间。

大家好，我是来自 Firstmark 的 Matt Turf，欢迎来到 Mad Podcast。今天我非常高兴再次请到 Box 的 CEO Aaron Levy。说到 agentic AI（代理式 AI），Aaron 毫无疑问是当今科技行业里思考最深入的 CEO 之一，而且他正处在第一排，直接观察 AI 实际上是如何在全球最大型企业内部被部署的。

这一期里，我们会聊到当前 enterprise AI（企业 AI）最紧迫的话题，包括飙升的 token 成本、为什么 AI model（模型）的进步反而会悖论式地拖慢企业部署、headless software（无头软件）的兴起、内部 FDE 的出现，以及创业公司还能够在哪些地方胜出。请大家欣赏我与一如既往非常出色的 Aaron Levy 的这场对话。嘿，Aaron，很高兴见到你。

嗨，很高兴，很高兴再次回来。感谢邀请。

是的，感谢你再次来和我们聊。我觉得你在我们的科技生态里扮演着一个非常特殊的角色，也处在一个非常特殊的位置，因为一方面，你已经做了很久的 Silicon Valley 圈内人，而现在的你几乎可以说是最彻底的 agent built（以 agent 为核心构建）那一类人了。但另一方面，你又是一家上市公司的 CEO，而且你的公司服务的是全球最大的 enterprises（企业）。所以，从 GE、Procter and Gamble、Morgan Stanley 这些公司开始聊，感觉会是个很好的切入点。

如今，Silicon Valley 和 Bay Area 与更广义上的整个科技体系之间，以及 Global 2000 这类大型企业之间，这种差距到底有多大？

很有意思的是，我们其实一直都在扮演这样一种角色。而如果一定要把我们长期以来的核心理念提炼成一个单一概念，那基本上就是：我们的工作是把超级先进的技术突破，连接到现实世界。比如在 cloud computing（云计算）的 very early stages（非常早期），当时像是：哦，我们现在终于可以把近乎无限的存储搬到云上了。可如果要把这件事真正交到大多数企业手里，你就需要一个简单的 interface（界面），还需要先进的 security（安全能力）。所以我们一直都在充当这样一座桥梁。这也让我们能够同时踏在两个世界里。

一个世界是那种超级前沿、几乎所有事情都以每秒百万英里的速度在前进的世界。另一个则是现实世界：那里有 change management（变更管理），有必须升级的 systems（系统），以及诸如此类的各种问题。所以我们当年在 cloud（云）上就看到了这种情况。而现在，随着 AI，我们显然又一次看到了它的另一个版本。不过我觉得这里有一个小小的 asterisk（补充说明），那就是，这其实不只是 Silicon Valley 和其他所有人的对比，更像是 Silicon Valley engineering（Silicon Valley 的工程体系）与其他所有人的对比。

不过先说清楚，就 engineering 而言，我会这么说：如果你现在已经深度接入 AI，而且你在那些头部公司之一做 engineering，那你的状态大概率已经和 Silicon Valley 相当接近了。所以更大的问题其实是：Silicon Valley 与某种意义上的非 engineering 知识型工作之间的对比。眼下真正的大问题就是：我们已经知道 AI coding agents（AI 编码 agent）显然已经完全达到 escape velocity（自我加速扩张的临界点），那么从这里走向组织其余部分的 agentic work（agent 驱动的工作），这条路径会是什么样？这种 rollout（推广部署）会怎么展开？use cases（使用场景）又会是什么？

这些东西要怎么落地实施？不用说，这已经是我们现在与每一位客户交流时排名第一的话题了。我觉得我的样本量还算可以——仅今年一年，在 Fortune 500、Global 2000 这一类 cohort（企业群体）里，我大概就接触了几百位 CIO。我会说，这是我们与企业互动中唯一一个占据主导地位的话题。它是每一家 enterprise（企业）都在努力搞清楚的最主要、最核心的事情。

我们仍然处在极其早期的阶段。所以这大概就是最重要的 TLDR（太长不看版结论）。有意思的是，我们之所以还很早期，尽管看起来会觉得——好吧，假设 AI 这一波已经持续了三到四年——是因为大家其实才刚刚开始弄清楚自己在 enterprise（企业）内部对 chat system（聊天系统）的最终 rollout plan（部署方案）。而且人们也完全有理由为此感到自豪和高兴，因为他们终于把那套东西推出来了。需要说明的是，在一些组织里，这件事现在还在 rollout（持续推广）中；就知识型工作而言，光是 chat system 的增长，我们都还有五年的发展空间。

但就在这件事发生的同时，这种 capability（能力）又进一步延伸了。于是所有人都在想：好，现在我们要从 chat 走出去——也就是我提一个问题，它返回一个答案，因此生产力提升某种程度上还受限于人类发起对话的能力——转而真正部署一个 agent，让它在 enterprise（企业）里做事、产出真实工作，也许是处理任务，也许你是通过 chat 来触发它，也许它只是以一种 stateful（有状态）的方式持续运行。可能是我去 ping 它，也可能是它在某个 workflow（工作流）里被触发启动。

所以现在大家都在说：好，我们大致知道 chat 这件事是怎么运作的了。顺便说一句，即便他们知道怎么运作了，我还是会说，market share（市场份额）的变化态势依然在持续演变，人们实际在部署什么也还在发生很多变化。现在所有人都在说，我们要去部署 agents。这些东西会先进得多，能力也强得多。而我会说，这才是真正的大话题；作为一个行业，我们在这件事上其实才刚刚进入 day one（第一天）。

对。你会怎么形容现在的情绪？你提到 chats 很有意思，因为在我自己的对话里——当然，我的样本量比你小——但你知道，Global 2000 这批企业里至少有一部分人会这么说：是啊，两年前你们来找我们，说我们已经必须得做这个 chat 的事了，而且特别紧急，不然我们就会落后，感觉像是“做个该死的 chat，不然你就完了”。后来我们做了 pilot（试点），结果也确实不错。所以现在你们两三年后又回来跟我说，不不不不不，agent 才是关键，而且这次如果你不做，你就又要完了。

如果把态度放在 skeptical（怀疑）和 enthusiastic（热情）这个光谱上，你会把大型 enterprise（企业）目前的情绪放在什么位置？

我会说，如果看最广泛的样本，我觉得整体情绪在统计意义上会更偏向乐观，而不是你刚才那个框架里呈现出的感觉；我猜你可能是碰到了几个格外 cynical（愤世嫉俗）的 CIO。我这么想是因为，CIO——而我们的主要受众也正是 CIO——当我们和 CIO 交流时，他们知道自己的 engineering 团队在使用 Cloud Code、Codex 和 Cursor，也看到了这些团队释放出来的生产力提升。他们会说：对，我们的团队现在构建 app 的速度就是快了很多，处理 IT project（IT 项目）的速度也快得多。

比如说，我们做 security review（安全审查）的速度更快了。也就是说，他们正在自己所在的职能里看到生产率提升。我觉得他们常常会问：我怎么把这些 IT 领域的生产率提升带到组织里那些非 IT 的部分？而且业务部门也在反过来推动他们，说我想用 co work，我想用 Codex，我也想用这些工具。所以现在这些工具确实带着某种“吸引力”，业务部门有点像在主动要求：我想搭上 agentic（代理式）这班车，因为我已经看到了这么多很棒的 use case（用例）。

所以我觉得，整体氛围其实是格外乐观、兴奋和积极的，而不是那种——你知道的——典型的“幻灭低谷”，也就是 Gartner 的 hype cycle（技术炒作周期）里常说的那一段。我认为大家现在都很清醒地意识到，这里面没有免费的午餐，它不会立刻就把我们的生产率彻底改变。我们现在已经不再停留在那种讨论阶段了。也许两三年前我们还在那个阶段，但现在我觉得每个人都非常明确地知道：这东西不是部署下去就会神奇地自动改造整个业务。但与此同时，他们的员工也在说，实际上，我希望这东西能替我审阅我所有的文档；我希望它能加快我们的客户 onboarding（入驻）流程。

我希望它能在我们的营销 campaign（活动）流程中生成 digital assets（数字素材）。所以我觉得，需求是从业务部门那边来的，而 IT 组织已经看到了 coding（编码）方面的收益。现在更多变成了一些非常实际、战术层面的问题，我们肯定接下来会谈到其中一些。比如 token 成本问题；比如你到底该怎么把这套东西真正 rollout（推广部署）出去。

再比如，你有没有足够的人才去部署这些东西？所以，我现在感受到的讨论总体上都相当积极，而且目标也越来越有雄心，但同时又带着一种现实感，而且是很强烈的现实感：这里面没有任何东西是“免费”得到的——甚至不只是成本层面的免费，而是从 deployment（部署）方式上来说，也绝不是轻轻松松就能完成的。

既然你提到了 token 成本，我们就来聊聊这个吧。这是个特别有意思的话题。而且在我们录这段对话的时候，它也恰好非常应景。本周有消息说，Microsoft 取消了他们内部的 cloud code license（云端代码许可证），因为按 token 计费之后，成本高到了无法承受。我记得几周前，Uber 的 CTO 也在谈同样性质的问题。

所以这显然是一个正在大型企业里浮现出来的话题。

对。不过公平地说，公平地说，我觉得 Microsoft 那件事可能被用一些很有意思的方式解读和传播了，因为那可能更多反映的是，他们想转向——对。

Code Code，而不是 Codex。对，对。

对。就像他们会把钱花在 token 上一样。也就是说，这实际上就是要跑在他们的基础设施上。所以，但是，但是，所以我觉得媒体真的很喜欢去改写、调整这件事的叙事。

对。这个说法很公平，非常公平。不过，这确实似乎是大家最关心的话题之一。而且，这里面还有一点那种张力：一边是 Silicon Valley 那套“入场券”式系统，在那里 token 最大化（token maxing）确实很流行；另一边是企业更担心成本。所以你听到的情况是什么？你会建议别人怎么做，或者说你的客户该怎么做？

说实话，我现在还不知道自己是否已经有很好的建议，但我会说，我们现在去和各个组织讨论 agent、token、token 成本、预算和预算规划这些事情时，这大概至少占到所有和 AI 相关热点问题的三分之一。而且有一半的时候，它甚至可能并列第一。因为他们看到的是一种转变——大家都把它称为整个行业之前一直在做补贴（subsidization）。我自己其实不完全这么看。我会说，当时的成本只是低到足以让这些东西被直接包含进去而已。

比如 Cursor 以前就包含了大量用量，可能某种程度上也有补贴，但更准确地说，其实是他们可以把这件事相当干净地纳入自己的订阅费模型里。然后突然之间发生的事情是，这些 agent 能做的工作多了太多，它们的 context window（上下文窗口）大了很多，inference（推理）成本高了很多，因为它们的参数多得多，能力也强得多。所以，我们其实是从 chatbot 那种定价模型，或者像 GitHub Copilot 里的 type-ahead（输入联想）功能那种定价模型，走到了一个新阶段：当一个 coding agent 在单个任务上就可能消耗 1,000 美元的算力时，原来的定价模型就不成立了。很显然，你不可能再把这一切都塞进每用户每月 20 美元的收费里。所以这才是真正发生的跃迁。

而且这一切都只是在一年内发生的，甚至可能还不到一年。我的意思是，这基本上完全对应着——你只要去看一下 Andropic 的营收曲线就行——也就是在那段时间里，关于成本建模和 token 预算的一切，几乎都被彻底颠覆了。

对，不过 Frontier token 的单 token 成本确实上升了，是吧？也就是说，不只是运行时间更长的 agent 在消耗更多 token，实际上的 Frontier token 成本本身也提高了。我觉得这和过去几年我们一直互相讲述的那套叙事完全相反：token 的成本不是应该一直在下降吗？

对，百分之百是这样。但我觉得这里有一个细微之处：我不是——当然，最好还是请一些 lab 的人来谈——我也不是百分之百确定，这更多只是补贴变化的问题；更像是，这些模型本身就是大得多，而且硬件短期内也不会变得更便宜。再加上我们还面临产能约束。所以你会看到一些不同于常规计算的反常模式：通常来说，会有规模经济，而且你不会遇到同样类型的短缺。

所以按理说，随着建设规模扩大，一切都会变得更便宜，而且还会有 Moore's Law（摩尔定律）在起作用。但我们其实是把本来通常应该在十年 rollout（铺开）过程中发生的事，压缩到了大约十八个月里。于是很自然地，data center 提供商、各家 lab 等等就拥有了定价权，他们没有必要下调任何东西的价格。所以你现在看不到那些通常会压低 compute（算力）成本的因素。我非常乐观地认为，这种情况会在未来五到十年内出现变化，但很显然，现在还没有发生。

所以我们并没有看到正常十年 compute（算力/计算）周期里你本该看到的那条曲线，因为那十年现在会在十二个月里发生。所以企业现在的反应是：好吧，说实话，这些账单让我很意外。而且这种意外，更像是一种不太舒服但不得不接受的意外，而不是“我再也不用这个了”的那种意外。因为他们确实在经验上得到了生产力提升，否则他们根本不会付这些账单。只是现在他们开始意识到：哦，原来这在业务里是一项非常真实的支出。这不是那种我们只是在脑子里按每个用户多加 20 美元、算进 headcount（人头成本）里的费用。

而现在它已经解决了这个问题。所以接下来会发生的一个细微但重要的变化是：我认为在 AI 的头两到三年里，IT budget（IT 预算）某种程度上还能消化 AI 成本。这种情况会表现为：公司升级到了 Microsoft Copilot，或者给某个 XYZ vendor 的 AI 产品买了 add-on（附加功能），又或者他们还能把 Cursor 的 license（许可证）塞进 IT spend（IT 支出）里。你也知道，IT spend 基本上通常占公司 revenue（营收）的 3% 到 7%。有时更低，有时更高，但大体上就是被卡在这个区间里。

那接下来的问题就是：一个组织里另外那 60%、70%、80% 的 revenue 都在哪里？是在 OpEx（运营支出）里，也就是整个业务里的通用型 OpEx。所以如果 AI 真的在给你的工程团队、客户 onboarding（客户接入）流程，或者营销团队带来生产力提升，那显然你不会想被业务里这 3% 到 7% 的比例困住；你会想摆脱它，预算也会转移到各条业务线的预算里去。从一方面看，这对 AI 行业其实是好事，因为你不再会被组织内部的 IT spend 预算所限制。但另一方面，后面也会出现一堆有意思的新问题，比如业务线未必知道该怎么给 compute 做预算。

这不是他们原来就有能力处理的事；营销团队没有 FinOps（云财务运营），销售团队也没有 FinOps。那原本是 cloud（云）相关团队才有的东西，IT team 也基本可以把它限制在自己的范围内处理。所以我觉得接下来会发生的是，首先很有意思的一点是，你会看到 finance team、line of business（业务线）和 IT team 之间出现一场拉扯：到底这些事情该怎么分诊、怎么协调？在某种程度上，你还是会把 IT systems（IT 系统）的管理、采购什么东西的管理，继续集中起来。

但与此同时，你又必须把“如何使用这些东西”的决策分散下去。因为说到底，应该由 CMO 来决定：他们是想花 100 万美元买 compute，还是花 100 万美元办 marketing events（营销活动）或者做别的事。像这种选择，最终只能由推动这些决策的业务负责人来做。所以这又变成了一种全新的管理模式：你要怎么在 marketing budget、sales budget，乃至 global manufacturing budget（全球制造预算）里去管理 compute budget（算力预算）。这整件事现在都得由大家重新摸索。

我们目前还没有的一类 tooling（工具）是：怎么衡量 tokens（token 用量）的 ROI（投资回报率）？你知道，我觉得在这个周期这么早的时候就开始谈 ROI，某种程度上既荒诞又好笑。但我也认为这其实非常实际：我现在在电脑上就能做一些事，而它花掉的钱可能和公司给我提供的一顿午餐差不多。我只要按一个按钮，就可能花掉我那顿“免费午餐”的成本。所以很显然，公司不可能说：“好，我们部署一大堆工具，让大家随便按按钮”，然后十秒钟之内就烧掉相当于 10 顿午餐的钱，却还不知道你做的事到底有没有真正为组织创造价值。

而这正是目前没人有 tooling 的地方。员工其实并不真正知道 compute 的成本是多少。所以他们会尽可能自由地使用这些系统，却不知道：是的，你交给那个 agent（智能体）的一个小任务，可能就要花 200 美元，因为你刚好把 query（查询）结构写错了。然后它就会在一堆系统之间 fan out（扩散式展开），去读取你系统里的每一份文档、每一条数据。

接着它还会把这些全都算一遍——而那个 prompt（提示词）的结构差异，可能就决定了你又一次花掉了相当于你在那家公司一个月全部福利成本的钱。所以我们该怎么处理这一切？其实我没有答案。这会成为最有意思的问题之一，最后大概会是几种方法的混合：一部分靠员工培训，一部分靠集中式的 capacity planning（容量规划），再配合分散式的“具体怎么落地”的决策。你还会需要新的软件，甚至很可能会出现一家估值 50 亿美元的 startup，专门做 AI compute 的 ERP——本质上就是：我怎么判断这些东西都在被以正确的方式使用？

我该如何衡量这些价值确实正在被产出？我又该如何确保它被推广到正确的团队？所以我觉得，这些问题现在都还悬而未决。而且我认为这件事太新了，我们目前非常缺乏 best practices（最佳实践）。

你看，这不就是在 podcast 里直接送上的免费 startup 点子吗。谢谢。

等等。所以这里有没有类似 royalty（版税 / 分成）的做法，还是说这到底是怎么运作的？

之前没有，但我们现在需要了。从现在开始。我们会分享 referral fee（推荐费）。谢谢。关于这件事。你刚才提到不做 subsidizing（补贴），但看起来 labs 已经开始做出反应了，或者说 OpenAI 推出了一种 pricing arrangement（定价安排），只是为了让 pricing（定价）更透明一些。

你觉得这也会成为这个行业演进方式的一部分吗？

在我前面那段关于各种问题的长篇大论里，我是说，有几件事是必然会发生的。其中一件必然会发生的事是，OpenAI 有一个很不错的项目，有点像 dedicated capacity（专属容量）；如果你大致了解自己的 workload（工作负载），我们就能锁定某些 pricing（定价），这会有助于支持那种安排。比如说，这就是一种可以保护你成本的方式。我认为另一件将会发生的事是，你会看到一种分化；而不是像两年前那样——那时我可能会预测会趋同——但现在我们还是按相反方向来看。Frontier（前沿）AI model（模型）能力会被应用到 coding、advanced life sciences（先进生命科学）、contract process（合同流程）以及 financial planning process（财务规划流程）这类场景中。

所以，在这些地方你会用上，比如 GPT 5.5、high、Opus four、seven，以及别的什么模型。但一旦你遇到某个任务——就是说，你现在已经能够稳定地执行这个任务——当这种能力已经趋于饱和，而且你能够以可靠的方式完成这个任务时，你就可以把它剥离出来，交给一个成本更低的模型，并在后续持续运行。我们在这方面其实还没有太多成熟经验，因为说真的，直到过去大概六到十二个月，模型还无法那么可靠地完成我们任何任务。随着这种情况开始出现，你就可以说，对于某一次 customer service（客户服务）交互，我现在可以把它的成本上限定在每百万 tokens（token）50 美分，而且它绝不会高于这个价格。事实上，它只会越来越低，因为我可能还会把它替换成 OSS model（开源软件模型）之类的。

但对于 coding，我其实仍然想要最高能力的模型。所以我认为将会发生的是，企业里会出现一种 model（模型）马赛克。我认为普通企业肯定会在组织内使用半打左右的模型。你不会把所有东西都扔给那种从性能角度看像 Ferrari 一样的模型。所以企业必须在这方面做得更好。

所以你需要对如何把任务切换到不同层级的 compute（算力）上，有某种更深入的理解和能力。回到那种 startup idea（创业点子）的话题，我们还会有新的方式来衡量这一切。我认为公司最终会逐渐意识到某些 use case（使用场景）：哦，实际上，也许这件事我甚至根本不需要 agent（智能体）来做。我只是需要把 software（软件）部署进去就行了。而且其实 software 更便宜，因为它就是跑在 CPU 上。

等等。Software，软件？这东西居然还存在？

对，software。事实证明，也许你并不想让你的 agent 每天早上都重新渲染一次 UI，而且那样光是用这个 interface（界面）一天就要花 30 美元。所以我觉得这里会出现很多混合式解决方案，更不用说市场里还会有良性的竞争，大家会说，你知道吗，为什么不做一些更便宜的 models（模型）出来？我们该怎么开始推动这件事——我觉得市场大体上会像你预期的那样运作：总会有人说，哦，这里其实有创新机会，然后就去进攻市场中的某些细分部分。

好。那么我们谈了企业端的整体情绪，也谈了成本问题。除此之外，在阻碍进展这件事上，还发生了什么，尤其是在技术和产品层面？比如，人们需要 harnesses（编排/约束工具）吗？

他们需要更多 vendors（供应商）？他们需要更多 open source models（开源模型）？为什么，到底需要什么

他们确实需要。更多 vendors。他们需要多得多的 vendors。答案永远是：更多 vendors。

VC backed vendors（有风投注资支持的供应商）。

百分之百同意。但理想情况下，最好还是由 VC 补贴的 VC backed vendors。

所以这些都是很优秀的上市公司。对。

之前有一条 tweet。我是说，这件事已经被提过很多次了，大意就是：趁现在这些产品里有一些还在被补贴，赶紧在人类能力所及的范围内尽可能多写代码。而且这其实是个有点好笑的概念。因为如果你真的很懂行，市场里大概确实有一些地方，你会觉得：哦，我好像可以某种程度上利用这些 LP capital 来替我的 startup 干活。而且确实存在这样一个时间窗口，让你能找到这些可利用的漏洞。

说到底，capital 在这个世界上其实也确实有它的用途，比如补贴 Uber，再比如补贴你的 token。不客气。

所以，虽然眼下最热的话题可能是 token，只是因为它有媒体关注，而且你知道，这种东西也很容易“惊到” CFO，但我觉得，最现实、最实质性的问题和挑战，大概率还是技术实现，以及 AI 以 agent 这种形态在知识工作中的扩散。你之前已经谈过很多这方面内容了，也请过一些很棒的嘉宾，我觉得他们已经把这个问题讲得很好了。我不知道自己还能给这场讨论增加多少新的轮廓，但就我目前看到的情况来说，我觉得这类事情你某种程度上必须亲自经历过一段 AI psychosis（AI 狂热）时期，然后再从另一边走出来。像我自己也经历过这样的阶段：整个周末都在埋头做项目，然后觉得，天啊，这简直是人类历史上最了不起的东西。

而且很显然，你会想，未来肯定会出现只有一个员工却能包办一切的公司。然后等你真正走过那一段，再回头看，就会觉得：哇，实际上，维护那套东西要花很多功夫。我得不停地去抓它犯的各种错误。所以项目做完以后，我花在复查、修改、调整上的时间几乎一样多；或者模型一升级，就把我刚做好的东西全弄坏了，我又得重新设计一遍。当你走出那段 AI psychosis（AI 狂热）之后，你会落到另一个更现实的位置上。

我想，我的一个优势在于，我一方面是这些工具的重度用户，另一方面又能看到真实世界，所以我会意识到：哦，原来在你们那种具体环境里，你根本不可能把我周末拿来玩的那些东西真正做起来。因为从安全角度，我就绝不会允许那样的事情发生，或者你随便说别的原因也行。所以，接下来真正要做的工作，大致就是下面这一串。假设你用了 Claude code 或 codex，然后觉得：这显然是有史以来最大的突破，它显然会迅速席卷知识工作，会在一夜之间改变一切，或者所有工作岗位都会被彻底影响。那我就快速列个账。

先说 coding，在这个场景里，你面对的是高度技术化的用户，用的是在 coding 上经过超强训练的模型，而且工作的结果实际上是可验证的，因为代码要么能跑，你可以对它做 QA，也可以给它加 tests，要么就是不行。再回到“技术型用户”这一点，这其实不是个小问题。那个技术型用户一旦发现 agent 做了蠢事，或者卡在某个问题上，用户自己就知道怎么把它修好、把它拉回正轨。而且正因为他们本身技术很强，又深度嵌在这个生态里，所以他们获取新闻的速度更快，因而掌握 best practices（最佳实践）的速度也更快。所以当有人问，哦，你的 skills file 怎么样了？

或者问你的 agents MD file 呢？他们会说，哦，对，里面有这个和这个，存放在这里，可以从这里访问。像这样的对话和语言，并不是那种普通知识工作者会使用的。这一点已经被很多人反复谈过了，甚至包括 Dorkesh，我记得 Dario 在这方面也有过一场很精彩的讨论。就是说，在 coding 里，code base 本身就承载了大量 context（上下文）；而在其他大多数知识工作中，context 分散在大概 20 种不同的东西里，其中一些是数字化的，另一些则明显不是数字化的那种媒介。

然后还有一个算是相对没那么吸引人的点，但它可能会是最重要的，那就是你代码库里的 access controls（访问控制）。比如说，我去看大多数工程团队时，他们通常都能访问自己需要处理的那部分工作内容。反过来，在 knowledge work（知识工作）里，你会不断碰到这样的情况：要么是 Bob 实际上对某些东西权限太大了，要么是 Sally 对某些东西权限又太少了。于是 Sally 得去申请权限，而 Bob 实际上应该被收回一些权限。在这两种情况下，那个在 coding（编程）场景里的 agent 对应物，本来只要读取自己所需的整个代码库并生成需要的东西就行；但到了 knowledge work 里，这个 agent 要么会立刻撞上 entitlement（权限授予）问题，拿不到某个资源；要么又会拿到过多资源访问权限，接着开始用它本不该接触的数据来回答问题，因为公司并没有把 access controls 做成一个干净清晰的环境。

所以，大概有五六个原因，解释了为什么 AI coding（AI 编程）看起来和其他大多数 knowledge work 非常不一样。这带来的含义是，技术扩散基本上需要时间。现在我们已经越来越多地拥有适合这件事的应用了，比如 Cloud Coworker 很棒，显然 Codex 作为一个 super app（超级应用）也正在出现，成为强大的 workhorse（主力工具）。Gemini 加上我想是 Spark 之类的，还有一些传闻说 cursor 可能会基于和 SpaceX 的关系继续演进。所以我觉得，这些工具正在越来越多地出现，或者说已经到位了。

现在真正难的部分来了：我该如何把这些东西部署到我的组织里，既安全、又可靠，还能避免员工制造出某种巨大的安全 blast radius（爆炸半径、连带影响范围）；以及，如何让员工知道，怎样把这个 workflow（工作流）正确接起来，最终对他们真正有用。所以你现在有了这项技术，也面临着一个巨大的 AI 扩散挑战。和我们在 chat（聊天）范式下已经习惯的问题相比，这其实是一个技术性强得多的问题，因为 chat 基本上只能做两件事：它可以访问 search（搜索），也可以访问 LLM（大语言模型），而这本身已经很惊艳了。但是，问题就在这里。

这两件事都不存在 permission（权限）问题，也都不需要接入某个其他系统，从而引发大规模数据泄露。

对，最糟也不过就是个 DLP（Data Loss Prevention，数据泄露防护）问题，对吧？

就只是个 DLP 问题。而且说实话，在很多方面，这和某个人去 Google 搜“我想研究一下这个客户”，相比去 Chatuche BT 里说“我想研究一下这个客户”，其实没那么不同。也就是说，这家企业的安全范式几乎没有发生什么变化。也许 prompt（提示词）里可能会多带一点 IP（知识产权/内部敏感信息），但你当时做的工作，其 blast radius 其实是相当可控的。反过来，如果我去用一个 agent，而且我刚好还能访问 Salesforce MCP server，

那事情就真的很惊人了。这其实也是我完全相信 headless software（无头软件）的原因之一。因为有了这个，我能做很多工作，能拉出大量数据，还能提出很多非常强大的问题。于是公司就必须回答：是不是每个员工都应该拥有同等级别的访问权限？我们又该如何确保已经把这方面的 access controls 清理好了？

以及，我们该如何再次告诉大家：他们应该发起什么类型的 query（查询），因为不同查询会对应不同的 cost profile（成本特征）？而且现在，你得针对每一家 software vendor（软件供应商）和每一个应用都做这件事。然后你还得想清楚，这一切另一端的新 workflow 到底应该是什么样的？你真的希望员工整天靠不停写 prompt 在各种系统之间推进工作吗？还是你更想要一些标准化的 best practices（最佳实践）？