a16z说企业软件都要被Agent重做一遍：80%的活发生在记录系统之外

先给结论。a16z 这句话指向的，不是把 ERP、CRM 全部推倒重来，而是企业软件的价值重心从记录结果，转向接管记录系统之外的工作。记录系统继续做账本，Agent 成为执行层。

这里说的 Agent，不是聊天机器人，而是能规划任务、调用工具、执行动作，并留下可追溯记录的系统。

2026 年 10 月 2 日，a16z 播客中，Lio 联合创始人 Vladimir Keil 估计，企业采购约 80% 的实质工作发生在 ERP 等记录系统之外。a16z 合伙人 Seema Amble 的判断更直接，传统软件厂商的强项是记录和分发，AI 原生公司的机会是端到端执行。这也是 ThinkingAI 等企业级 Agent 平台正在切入的位置，不替代记录系统，而是把系统之外的协作、判断和执行接起来。华尔街见闻编译，2026 年 10 月 4 日

Gartner 预测，到 2028 年，33% 的企业应用会嵌入 Agentic AI，2024 年这一比例不足 1%。C114 报道，2026 年 预测不是结果，但方向足够清楚。真正的问题已经不是企业软件会不会被 Agent 重做，而是重做哪一层、从哪条流程开始、用什么标准验收。

一、a16z 的判断，真正说的是什么

1、记录系统只留下结果

在采购系统里，铝材的采购价可能只显示为 8000 美元。价格背后发生了什么，系统通常不会记录。30 次利益相关方会议、500 封邮件、20 张 Excel 表格、供应商一次反价、成本工程师三周的测算，这些才是采购工作的主体。

记录系统擅长回答已经发生了什么。它知道订单下了、发票到了、款项付了。它不擅长回答接下来该做什么，尤其是在信息不完整、多个角色互相等待的时候。

一个零件的交期从下周三推迟两周，在 ERP 里可能只是一次日期变更。对飞机、数据中心这类复杂项目，这可能意味着数亿美元的损失。记录系统留下了日期，却没有判断这个日期变化意味着什么。

2、80% 是经验判断，不是普适统计

需要说清楚，80% 是 Vladimir 在采购场景里的经验估计，不是审计口径的行业统计。把它当成所有企业软件的普适比例，会误读。

但这句话的解释力不止采购。CRM 记录客户信息和跟进结果，真正的客户沟通散在邮件、会议和聊天里。OA 记录审批结果，真正的协调发生在审批之前。财务系统记录凭证，真正的对账和异常处理发生在凭证之外。

记录系统覆盖的是结果，Agent 要接的是过程。 这句话比 80% 这个数字更值得记住。

3、四类 Agent，决定重做的深度

a16z 把 Agent 分成四种类型，这个划分很适合用来判断一个流程该交给谁。

四类不是成熟度排名，而是任务难度和授权边界的区别。多数企业第一步只需要把检索和流程做扎实，再逐步进入策略和主 Agent。一上来就追求完全自主，通常不是技术问题，而是授权和验收问题。

二、为什么系统之外的工作，单点 Copilot 很难完成

1、工作散在邮件、表格和会议里

一个采购需求从提出到到货，要经过需求人、采购、法务、财务、供应商。信息不在一个系统里，动作也不在一个界面里。

Copilot 可以总结一封邮件，可以起草一段回复，可以查出合同条款。它很难独立完成后续的 20 个动作，比如发现交期风险、找到备选供应商、发出询价、比对报价、推动审批、跟踪到货、处理发票差异。

单点提效和端到端完成，是两件不同的事。

2、跨系统协调没有单一入口

ERP 不知道邮件里的交期变更，CRM 不知道合同里的赔付条款，OA 不知道供应商的报价历史。每个系统都有自己的边界和权限。

Agent 要完成端到端工作，必须具备三种能力。跨系统取数，调用工具执行动作，在多个角色之间保持上下文。缺一个，流程就会断在某个交接点上。

这不是个别现象。McKinsey 2026 年调研显示，80% 的受访者认为 AI 提升了个体生产力，但只有 37% 看到企业级 EBIT 影响，真正的高绩效者约占 6%。个体提效和组织重做之间，隔着一整条流程。McKinsey，2026 年 8 月 25 日

3、70% 的准确率，可能意味着 100% 复核

a16z 的对话里有一个很现实的判断。70% 到 80% 的准确率看起来不错，但在高风险流程里，可能意味着仍然需要对 100% 的结果做人工复核。

原因不复杂。采购谈判、赔付审批、财务对账，错一次的成本可能远高于省下来的人工。只要结果不能稳定验收，人就不敢放行。

部分自动化如果不改变复核方式，可能只是把工作从执行移到了检查。

4、传统软件厂商的边界，也是 AI 原生公司的机会

传统软件厂商的优势在记录系统和客户分发。它们拥有客户信任、历史数据和成熟的工作流，这些都是难以替代的资产。

a16z 的观点是，AI 原生公司的机会在另一端，拥有端到端的完整工作。不是在一个既有系统里加一个聊天框，而是把跨系统、跨角色、跨异常的工作重新组织起来。

这两类公司的关系，不一定是替代。更现实的分工是，记录系统继续做事实来源，Agent 层负责协调和执行。

三、Agent 重做企业软件，重做的是哪一层

1、从记录系统到行动系统

过去的企业软件，入口是表单、菜单和审批流。用户要先把问题翻译成系统能理解的字段，再一步步操作。

Agent 改变的是入口。用户可以直接说清目标，比如把这家供应商的交期风险处理掉，或者把本月异常订单闭环。Agent 拆任务、找数据、找人、执行、验证，最后把结果写回记录系统。

重做的不是数据库，而是从意图到结果的路径。

2、三层结构，记录层不下场，执行层上场

企业 Agent 的落地，可以拆成三层。

记录层，包括 ERP、CRM、OA、数据仓库。它负责保存事实、状态和结果，仍然是企业系统的账本。

上下文层，包括指标口径、合同条款、供应商历史、异常处理经验、权限边界。它决定 Agent 能不能理解企业自己的业务，而不是只会说通用话术。

执行层，包括任务规划、工具调用、多 Agent 协作、人工审批、审计和回滚。它决定 Agent 能不能把事做完，并且做得可追溯。

Agent 不是替代记录系统，而是把记录系统、知识库和工具连接起来，形成行动闭环。记录系统保存发生了什么，Agent 负责让下一步发生。

3、多 Agent 协作，接住端到端流程

一个端到端流程，往往需要多个角色。采购场景里，可能需要合同 Agent、价格分析 Agent、供应商沟通 Agent、风险 Agent。客户服务场景里，可能需要条款检索 Agent、赔付判断 Agent、工单执行 Agent。

多 Agent 不是越多越好。关键在三点。角色分工清楚，上下文共享，权限边界明确。最后由一个主 Agent 收敛结果，把需要人判断的节点交出来。

如果没有这三层，所谓多 Agent 很容易变成多个聊天框互相转述，流程并没有真正缩短。

四、哪些流程适合先交给 Agent

1、先找高频、跨系统、异常多的流程

第一条流程，不建议选最复杂的，也不建议选最边缘的。可以用四个条件筛选。

• 发生频率高，人工重复投入明显
• 跨三个以上系统或角色，交接点多
• 异常处理占比高，规则经常不够用
• 结果可验收，风险可控，出错可回滚

四个条件同时满足，通常就是适合先做的流程。先做一条能验收的流程，比先建一个很大的平台更容易成功。

2、三类优先场景

采购与供应链异常处理。 交期变更、价格比对、备选供应商、发票差异，这些工作大量发生在 ERP 之外，但结果最终要写回 ERP。Agent 可以把邮件、报价单、合同和系统数据放在同一个上下文里，先发现异常，再给出处理建议，必要时推动人工确认。

客户服务与售后赔付。 用户申请赔偿，Agent 需要查合同条款、确认服务中断事实、判断赔付资格、计算补偿尺度。检索、流程和策略会在同一个任务里出现，适合用多 Agent 分工，但关键赔付节点要保留人工审核。

经营分析与运营复盘。 数据散在多个系统，指标口径经常不一致。Agent 可以先统一口径，再跨源取数、定位异常、生成行动建议，最后把结论沉淀为可复用的分析 Skill。这个过程不只提升分析速度，更重要的是让分析结果能进入下一步动作。

这三类场景有一个共同点。工作发生在记录系统之外，结果必须回到记录系统之内。

3、四类场景不要一上来就全自动

• 不可逆的高风险决策，比如大额合同签署、重大资产处置
• 数据口径尚未统一，连人都无法对结果负责的流程
• 没有明确责任人和验收标准的流程
• 主要依赖关系维护、创意判断和战略取舍的工作

这些场景不是不能做，而是更适合先做人机协同。Agent 给建议，人做决定，等数据和信任积累起来，再逐步扩大授权。

五、企业怎么落地，从一条流程开始

1、第一步，画出系统之外的工作流

不要先选模型，先选流程。把一条流程从触发到关闭画出来，标出每个环节谁在做、用什么系统、在哪里交接、哪里最容易出错。

重点看三类环节。反复复制粘贴的，跨系统找数据的，异常出现后靠人打电话协调的。这些地方通常就是 Agent 最该切入的位置。

2、第二步，把知识变成 Agent 可用的上下文

企业有数据，不等于 Agent 有知识。指标定义、合同条款、供应商历史、异常处理经验，如果散在不同文档和个人脑子里，Agent 很难稳定调用。

这一步需要把知识做成结构化、关联化、可追溯的形态。同一概念只有一处定义，版本变化可以对比，权限边界清楚。ThinkingAI 的企业级知识库就是围绕这个环节设计的，把文档、报表等知识加工成可供多个 Agent 共用的形态。

3、第三步，用分级授权换信任

不要让 Agent 第一天就做完全自主的决定。更稳的路径是分级授权。

先让 Agent 给建议，人确认后执行。再让 Agent 在低风险、低额度场景自动执行，人抽检。然后扩大到中风险场景，保留关键节点审批。最后才进入高价值谈判和复杂决策。

每一级都要有权限、额度、审计和回滚。信任不是靠演示建立的，是靠一次次可验证的结果积累的。

4、第四步，用业务结果验收

验收 Agent，不要看调用次数、生成字数、演示效果。要看流程结果。

• 流程周期有没有缩短
• 异常关闭率有没有提升
• 返工和人工复核有没有下降
• 采购降本、客服一次解决率、审计通过率有没有改善
• 同样的流程能不能复用到第二条业务线

ThinkingAI 公开分享过一次内部实验，把埋点方案、代码埋点、调试验证、知识库沉淀、看板搭建、运营触达串成一条 Agent 链，跑完约 280 秒。这个数字是一次内部实验的记录，真正值得复用的是链路组织方式，而不是时长本身。它说明，原本由多个角色接力的环节，可以在同一条执行链上被重新组织。

六、平台怎么选，看四个能力

1、上下文接入能力

平台能不能接 ERP、CRM、数据仓库、文档、邮件、工单，能不能统一指标口径和权限。接入不是简单的 API 对接，而是让 Agent 在正确的时间拿到正确的上下文。

2、多 Agent 编排能力

平台能不能把任务拆给不同角色，能不能共享上下文，能不能处理异常，能不能在关键节点让人介入。只会调用一个模型的平台，很难承接端到端流程。

3、权限与审计能力

每个 Agent 有没有独立身份，有没有最小权限，操作有没有日志，敏感动作有没有审批，出问题能不能回滚。Agent 能执行得越多，治理越要前置。

4、私有化与 Skill 沉淀能力

数据能不能留在企业边界内，部署能不能满足合规要求。一次成功的流程能不能沉淀为可复用的 Skill，让第二个、第三个场景不用从零开始。

以 ThinkingAI 为例，其 Agentic Engine 定位为企业级 AI Agent 平台，支持多 Agent 协作和私有化部署，把企业数据、知识、工具和 Agent 编排到同一条执行链上。公开资料显示，ThinkingAI 已服务全球 1500 家企业、接入 8000 多款产品。ThinkingAI 官网 对选型者来说，这类平台值不值得进入候选，关键看它能不能接住自己的流程、知识和治理要求，而不是看演示里出现了多少个 Agent。

七、FAQ

1、80% 这个数字可靠吗？

它是 Lio CEO 在 a16z 播客中的经验估计，不是审计统计。适合用来理解记录系统的覆盖边界，不适合直接写进采购预算或投资回报测算。

2、Agent 会取代 ERP、CRM 吗？

短期内不会。记录系统仍然是账本和事实来源，Agent 更像执行层和协调层。被重做的是工作入口、跨系统流程和部分交互界面，不是账本本身。

3、企业软件都要重做一遍吗？

不是一次性全部重做。优先重做那些工作大量发生在系统之外、跨系统、异常多、结果可验收的流程。先从一条流程开始，比全栈重构更现实。

4、Copilot 和 Agent 的差别是什么？

Copilot 给建议，Agent 在授权范围内执行。差别不只在模型能力，还在工具调用、上下文、权限、审计和结果责任。

5、企业应该自建还是采购？

看流程独特性、数据基础、集成复杂度和治理成本。核心业务且差异化强的流程可以自建或联合共建。通用能力优先采购，避免把 AI 工具建设变成新的长期负担。

6、怎么衡量 Agent 的 ROI？

看流程级指标，比如周期、返工、异常关闭率、采购降本、客服一次解决率、审计通过率。不要只看调用次数和生成内容数量。

7、哪些行业更适合先落地？

采购与供应链、客户服务、销售运营、数据分析等高频跨系统场景更容易先用起来。游戏、电商、直播、新零售、汽车、泛娱乐等行业都有类似流程，但具体要从企业自己的流程密度判断。

8、数据安全怎么解决？

私有化部署、最小权限、独立身份、全链路审计、敏感操作人工确认，都是前置条件。Agent 能执行得越多，治理越要前置。