上一篇文章里，我讨论了 EDA、CAD、PLM 和工程仿真这些“显性软件卡点”。

所谓显性，并不是说它们一定比其他软件拥有更深的护城河，而是它们为什么难以被绕过，相对容易理解。一颗芯片最终仍然需要 Verification 和 Sign-off；一个真正要制造的产品仍然需要正式的 Geometry、BOM、PLM 和工程仿真。

最近行业里也出现了越来越多类似的现实案例：AI 并没有简单绕过 EDA，反而正在逐渐进入 EDA 的设计、验证和优化流程。

这说明一个很重要的问题：

AI 能力越来越强，并不意味着所有软件卡点都会消失。有时候，AI 反而会成为这些软件的新用户。

但 EDA 只是最容易看见的一类。

如果把视线从芯片、机械和建筑转向企业办公室，会发现另一批卡点开始浮现出来。它们不像 Sign-off、仿真或者正式工程模型那么显眼，却可能决定 Agent 能不能真正进入一家企业工作。

一个 Agent 真正进入公司以后，至少要连续回答三个问题：

它知道什么是真的？它有没有权这么做？事情接下来应该怎么流转？

对应的，就是三层很容易被忽视的软件基础设施：

企业记忆、权限与工作流。

这篇文章想讨论的，就是这些“隐藏软件卡点”。

一、Agent真正缺少的，可能不是知识，而是Context

今天的大模型已经知道很多东西。

它可以写代码、做分析、读财务报表、总结合同，也能处理大量公开信息。

但让它进入一家具体公司以后，一个很有意思的问题马上出现：

它知道整个世界，却不知道你的公司昨天发生了什么。

假设公司的文件系统里同时有两份合同：

Contract_Final.pdf

和

Contract_Final_v2_Revised.pdf

模型当然可以读懂两份文件。

但它并不知道哪一份真正发给过客户，不知道第二份是不是某个员工私下修改、从未获得批准的版本，也不知道某一条价格是不是后来在一次会议里又被改过。

所以企业真正重要的数据，从来不只是文件里的 Content。

它还包括版本、Metadata、权限、审批历史、时间、项目关系、人员关系，以及某个决定为什么会在当时发生。

这些东西组合起来，我更愿意叫它：

Enterprise Memory——企业记忆。

如果 Agent 没有这一层，它就像一个能力极强、但入职第一天而且完全失忆的新员工。

这里放我们做的“企业记忆 → 权限 → 工作流”那张图。

二、企业真正稀缺的，不只是文件，而是文件背后的上下文

这也是 Enterprise Memory 最容易被误解的地方。

今天很多软件都可以保存文件。Google Drive、SharePoint、Box、Dropbox 都可以完成这件事。

所以“我有很多文件”当然不是卡点。

真正困难的是：

Agent 能不能知道一份文件在组织里的状态。

两个合同内容可能几乎一样，但一份已经正式签署，另一份只是草稿。

两个数字可能只差 2%，但一个经过 CFO 批准，另一个只是分析师自己的预测。

某个销售方案看起来仍然有效，但某个地区团队可能三个月前已经放弃。

这些信息，人类员工往往通过长期工作自然知道。

但 Agent 没有“在公司工作十年”的经历。

因此，当越来越多任务从人转移给机器以后，企业过去几十年留下来的数字轨迹，反而开始拥有新的价值。

左边是文件正文、图片、表格、邮件；右边是版本、权限、审批历史、Metadata、项目关系和活动记录。

三、Box真正值得观察的，不是“AI帮你搜文件”

这也是为什么 Box 很适合作为 Enterprise Memory 的案例。

如果 Box 的价值只是帮助企业保存 PDF、Word 和 PowerPoint，那么 AI 并不会让它突然变成完全不同的公司。

真正值得观察的是另一种可能：

未来企业不会只有一个 Agent。

一家大型公司完全可能同时使用不同模型、不同部门的 Agent，以及大量内部开发的自动化系统。

如果每一个 Agent 都自己复制一套文件、版本和权限体系，企业很快会遇到非常严重的安全和治理问题。

更自然的一种架构是：

Agent 可以换，模型可以换，但正式企业内容仍然来自同一个可信内容层。

这时候 Box 的角色就可能从传统的 Enterprise Content Management，进一步向一种更底层的位置靠近：

Agent-neutral Enterprise Content Layer。

也就是说，它不一定需要自己成为最强的 Agent。

它真正需要证明的是：

无论企业前端使用哪一种 Agent，最终都需要安全地进入同一套正式内容、版本与权限体系。

当然，这并不是 Box 独占的机会。

Microsoft SharePoint 和 OneDrive 同样拥有非常强的基础。

所以这里真正值得观察的问题不是“谁有 AI 功能”，而是：

未来企业是否需要一层独立于模型之外的可信内容基础设施。

四、Microsoft可能是这一层最强的结构性参与者

讨论企业记忆，很难绕过 Microsoft。

因为一家公司的大量真实工作，本来就发生在 Outlook、Teams、SharePoint、OneDrive、Word、Excel 和日历里面。

微软知道的不只是文件内容。

它还可能知道谁发过邮件、谁参加过会议、谁修改过文档、哪些人在同一个项目里长期合作。

换句话说，它天然拥有很多构建企业 Context 所需要的原材料。

而且微软还有一个额外优势：

Identity。

如果把 Microsoft 365 的内容和工作历史，与 Entra 的身份和权限体系，再加上 Copilot 这样的 Agent 入口连接起来，它实际上有机会同时覆盖：

Memory + Identity + Productivity + Agent Entry。

这也是所有独立企业软件都会面对的一个长期问题：

如果微软能够把这些东西打包，企业为什么还需要额外购买独立平台？

不同软件必须给出不同答案。

Box 要回答的是：企业为什么需要一个更加中立的内容层。

ServiceNow 要回答的是：跨系统 Workflow 为什么仍然需要一个独立控制层。

Salesforce 要回答的是：Customer System of Record 为什么仍然不能被新的 Agent 层轻易替代。

这比单纯比较谁的 AI 助手更聪明重要得多。

五、第二道门：Agent知道什么是真的以后，它有没有权这么做？

企业 Agent 和普通 Chatbot 最大的区别，不只是模型能力，而是：

它开始行动了。

一个 Chatbot 读取公司现金余额，只是信息访问。

一个 Agent 可以直接发起付款，就是完全不同的事情。

所以 Agent 真正进入企业以后，也必须拥有类似员工的身份和权限体系。

企业需要知道它代表谁、可以访问什么系统、可以读取哪些数据、可以修改哪些记录、什么时候必须获得人工批准，以及任务完成以后权限是否应该自动失效。

过去 Identity 系统主要回答的是：

这个人能做什么？

未来还必须回答：

这个 Agent 代表这个人能够做什么？

这会让 Identity、Permission、Audit Trail 这些过去看起来非常 IT 化的基础能力，变得越来越重要。

因为 Agent 的危险之处恰恰在于执行速度。

一个人拿到错误权限，也许要过几天才造成问题。

一个 Agent 拿到错误权限，可能几秒钟就能访问、复制或者修改大量信息。

因此 AI 越自主，企业越需要明确：

它是谁、它能做什么、什么时候必须停下来。

六、Okta代表的是另一种隐藏卡点

Okta 就是理解这一层比较典型的案例。

过去大家理解 Identity，更多是单点登录、员工账号和访问控制。

Agent 出现以后，被管理的对象开始从人扩展到机器。

未来一个企业可能拥有大量内部 Agent。

这些 Agent 同样需要身份，需要授权，也需要定期重新确认：

它是否还应该拥有某项权限。

从产业角度看，这个变化很容易理解。

Agent 越自主，对最小权限、授权有效期、访问审核和行为审计的要求越高。

但这里也说明了另外一个问题：

隐藏卡点本身，并不等于某一家现有公司天然拥有这个市场。

Microsoft Entra、本地安全平台以及其他 Identity 厂商，都可能参与这一层竞争。

因此研究 AI 时代的软件，始终要区分两个问题：

“这一层是否会更加重要”，和“今天谁最终会控制这一层”。

七、第三道门：Agent知道，也有权限，但它知不知道下一步怎么办？

这就是 Workflow 真正重要的地方。

现实中的企业工作很少是一个孤立动作。

例如采购一台服务器，往往需要经过需求提出、预算确认、技术评估、供应商询价、法务审核、管理层批准、付款和资产登记。

而且中间还有大量例外。

金额超过某个阈值怎么办？供应商不合规怎么办？合同改了以后是不是必须重新审批？付款失败以后应该回到哪一步？

AI 可以替代其中很多人工操作。

但流程本身不会因为人被替代而消失。

恰恰相反。

人类员工遇到异常情况时，可以凭经验决定“去问一下老板”。

Agent 没有这种默认的组织常识。

企业必须明确告诉它：

什么时候继续，什么时候停止，什么时候升级给人，以及失败以后应该回到哪里。

所以 Workflow 的价值可能发生一个很重要的变化：

过去主要管理的是：

Human Workflow。

未来可能逐渐演变成：

Human + Machine Workflow。

八、这可能是ServiceNow真正值得关注的AI逻辑

所以看 ServiceNow，最没有信息量的问题其实是：

“它有没有 Agent？”

今天几乎所有企业软件公司都有 Agent。

真正值得关注的是，ServiceNow 原本就处在企业 Workflow 和 IT 运行的控制层。

如果企业未来拥有几十、几百甚至上千个 Agent，那么谁来负责：

这些 Agent 可以访问哪些系统、任务怎么分配、异常怎么升级、审批在哪里发生、做错以后如何追踪？

这才是 ServiceNow 更深的一层机会。

过去，它帮助企业管理：

人应该按照什么流程工作。

未来则可能进一步帮助企业管理：

人和机器如何按照同一套公司规则工作。

从这个角度看，Agent 并不一定削弱 Workflow 软件。

反而可能把 Workflow 从“员工操作工具”升级成更加底层的执行基础设施。

左边是 EDA / CAD / PLM / Simulation，右边是 Enterprise Memory / Identity / Workflow。

九、但并不是所有有Workflow的软件，底都一样硬

这也是这篇文章最需要避免的一个误区。

如果只要有数据、有 Workflow 就叫卡点，那几乎所有 SaaS 都可以这么说。

Salesforce、HubSpot、monday、Asana、Adobe、Intuit 都拥有自己的数据和流程。

真正需要判断的是：

Agent 离开这个系统以后，能不能比较容易重建同样的东西。

如果可以，卡点并没有那么深。

如果不能，事情才开始变得有意思。

十、Salesforce：前台可能被抽象，但Customer System of Record仍然存在

Salesforce 是非常典型的案例。

AI 的确可能影响 CRM 的很多上层价值。

销售人员未来可能越来越少直接进入传统 CRM 界面，大量报表、会议记录、邮件生成和自动化操作，也可能逐渐由 Agent 完成。

所以 UI、Feature 和部分 Seat 价值确实会受到挑战。

但 Salesforce 保存的并不仅仅是一套界面。

它还保存客户是谁、Pipeline 到哪一步、报价是什么、折扣由谁批准、合同现在处于什么状态，以及围绕客户运行的 Business Logic 和 Workflow。

未来一个销售 Agent 完全可以不打开 Salesforce 的传统页面。

但它真正替销售工作时，仍然需要回答一个问题：

公司正式认为这个客户现在是什么状态？

所以 Salesforce 真正面临的并不是简单的“会不会被 AI 替代”。

更重要的是：

AI 拿走上层交互价值以后，底层 Customer System of Record 能保留多少战略价值。

十一、HubSpot类似，但卡点深度可能不同

HubSpot 与 Salesforce 也有相似之处。

它拥有客户数据、销售流程、营销和服务 Workflow。

但它更多服务中小企业，因此企业流程通常更轻，系统迁移成本也可能相对更低。

这意味着，即使两家公司都叫 CRM，它们的“底”并不一定一样硬。

新一代 Agent-native CRM，从中小企业市场向上切入，也会比直接替换大型企业核心 CRM 容易得多。

这说明一个很重要的问题：

System of Record 不是一个非黑即白的标签。

同样是记录系统，也有深浅之分。

十二、Intuit为什么显得不太一样

Intuit 是一个很特殊的例子。

QuickBooks 保存的不只是一般意义上的企业工作状态。

它保存的是：

账本。

交易、工资、支付、税务和财务记录，本身具有正式的经济含义。

AI 当然可以自动分类交易、做对账、处理应收应付，也可以让很多传统会计操作变得更加自动化。

但最后仍然需要一个正式账本告诉企业：

账到底是多少。

所以 Intuit 和普通项目管理软件存在一个很重要的区别。

它的底层数据不仅仅是“工作进展”，而是一套具有正式业务含义的记录体系。

这类软件其实已经开始接近另外一个值得单独讨论的主题：

专业工作流。

十三、Adobe说明：同一家公司内部也可以一半硬、一半软

Adobe 是另外一个很有意思的例子。

生成图片、视频、简单编辑，以及大量传统 UI 功能，本来就是 AI 最容易直接进入的地方。

所以 Creative Cloud 的一些价值层，确实会受到明显冲击。

但 Adobe 又不只有 Photoshop。

企业端还涉及品牌资产、客户体验、内容管理和营销 Workflow。

因此讨论 Adobe 时，不能简单说：

“AI 会替代 Adobe。”

也不能反过来说：

“Adobe 有企业数据，所以没有风险。”

更准确的方法是：

把同一家公司的不同价值层拆开。

有些层很容易被模型商品化，有些层则更接近企业正式流程和内容体系。

这也是为什么我认为 AI 时代的软件研究，越来越不能只看“公司名称”。

必须看它到底控制了哪一层。

十四、monday和Asana：Work Graph到底是不是正式记录？

monday.com 和 Asana 也都强调自己的 Work Graph。

谁负责什么、任务之间如何依赖、项目推进到了哪一步，这些信息对 Agent 显然非常有价值。

但真正的问题不是：

“Agent能不能读取这些信息。”

而是：

这些数据到底是不是公司唯一可信的正式工作状态？

如果 Agent 可以通过邮件、Slack、GitHub、CRM 等其他系统，很容易重新推导出当前项目情况，那么项目管理软件的底就没有那么硬。

但如果一个企业几年下来，已经真正把正式 Workflow、依赖关系和决策历史沉淀在里面，那么情况会完全不同。

所以 monday 和 Asana 真正要证明的，是从：

Project Management Tool

升级成：

Work System of Record。

这里放 Enterprise State 那张图：

内容状态 → Box / SharePoint
 客户状态 → Salesforce / HubSpot
 账本状态 → Intuit
 身份状态 → Okta / Entra
 流程状态 → ServiceNow / monday / Asana

十五、比“谁拥有最多数据”更重要的，可能是“谁拥有正式状态”

讲到这里，我觉得可以把前面这些软件再抽象一层。

过去讨论 AI 软件时，经常会说：

“谁有数据，谁就有优势。”

这个判断不完全错。

但它可能太宽泛。

数据可以复制，可以重新计算，也可以通过 API 从不同系统读取。

更难重新建立的，往往是一家公司对某件事情的：

正式状态。

哪一份合同是正式版本；

客户到底处在哪个销售阶段；

公司账面到底是多少；

这个 Agent 到底是谁；

一项任务现在应该流转到哪一步。

这些状态不能由 Agent 自己随便“猜”。

企业必须指定一个系统告诉它：

现在事实是什么。

所以我越来越觉得：

Agent 时代软件最重要的一个词，可能不是 Data。

而是：

State

谁掌握企业某一件事情的正式状态，谁就更接近真正的软件卡点。

十六、这也解释了为什么隐藏卡点比显性卡点更难识别

显性卡点比较简单。

一颗芯片必须验证。

一个工程设计必须形成正式模型。

因此 EDA、CAD、PLM 为什么存在，比较容易理解。

隐藏卡点则没有这么明显。

企业文件、审批、客户状态、权限和 Workflow，看起来都只是普通的软件功能。

因为过去人类员工会自动填补软件之间的空白。

员工知道哪份文件是真的，也知道发生异常时应该去问谁。

Agent 出现以后，这些“人脑里的组织常识”第一次需要被真正软件化。

所以隐藏卡点往往要等到 Agent 开始执行真实任务以后才暴露出来。

这也是为什么它们可能比工业 Agent 更早进入实际业务，但又比 EDA 更难提前识别。

十七、最大的反方仍然是“大一统”

这个逻辑最后必须面对一个最大的反方。

如果未来 Microsoft，或者某一个新的大型 Agent 平台，可以统一完成企业记忆、身份、权限、工作流和 Agent 入口，那么今天大量独立 SaaS 的所谓卡点都可能被削弱。

Microsoft 是最现实的例子。

但我并不认为大型企业最终一定会走向完全统一。

现实中的企业软件栈通常非常复杂。

客户数据可能在 Salesforce，财务在 SAP 或 Oracle，文件同时存在 Box 和 SharePoint，Workflow 在 ServiceNow，研发任务在 Jira，Identity 又可能来自 Microsoft 或其他平台。

有意思的是，Agent 的出现反而可能让这种异构环境继续存在。

因为 Agent 最大的能力之一，就是降低员工在不同软件之间切换的成本。

过去更换底层软件的一大理由，是员工不愿意每天学习十套复杂界面。

未来如果 Agent 可以替员工操作这些系统，企业反而可能没有那么强的动力立刻替换已有 System of Record。

于是出现一个非常反直觉的可能：

Agent可能削弱每一个软件的UI，却同时延长底层专业系统的寿命。

这也许是目前讨论 SaaS 与 AI 时，最容易被忽略的一种路径。

总结：隐藏软件卡点的三种产业状态

第一类：卡点已经清晰
 第二类：上层受冲击、底层仍需验证
 第三类：传统角色稳定、Agent带来新用途

结语：Agent时代真正争夺的，可能是企业的“正式状态”

我们三篇AI相关的文章中，

第一篇文章讨论的是，从 SaaS 到 Agent，软件价值如何从 UI 和 Feature 向更底层迁移。

第二篇讨论的是 EDA、CAD、PLM 和 Simulation 这些显性软件卡点：AI 可以生成，但现实产品最终仍然需要正式工程系统完成。

这一篇转向企业办公室之后，问题变得更加隐蔽。

Agent 已经越来越会写邮件、分析数据、搜索文件和调用软件。

真正限制它的开始变成：

哪一份信息是真的？企业正式认为某个客户现在是什么状态？这个 Agent 有没有权修改它？异常发生以后应该走哪一步？谁最终对结果负责？

所以未来企业软件真正争夺的，可能不再是：

谁拥有最多 Feature。

甚至不只是：

谁拥有最多 Data。

而是：

谁掌握企业不能随便重新生成的“正式状态”。

Box、Salesforce、Intuit、ServiceNow、Okta、monday、Asana，以及 Microsoft，并不是同一种软件，也不会因为 Agent 出现而得到同一种结果。

有些控制企业内容，有些控制客户状态，有些控制账本，有些控制身份，有些控制工作流。

真正值得长期观察的，是这些系统能不能从“给人使用的软件”，进一步变成：

给人和 Agent 共同使用的企业基础设施。

而判断一款软件在 Agent 时代究竟还剩下多少价值，我觉得可以一直追问三个问题：

AI首先会拿走它什么？拿走以后还剩下什么？剩下的那部分，到底是不是企业无法随意重建的正式状态？

如果这三个问题能够回答清楚，很多所谓“AI 会不会替代 SaaS”的争论，可能也就没有那么复杂了。