AI 正在重写 ToB 软件,未来卖的不是功能,而是可被 Agent 执行的业务能力

过去两年，ToB 软件做 AI，大致走了三条路。

第一条是在原有页面里增加总结、生成、解释和推荐。打开一条客户记录，AI 帮你总结；打开一份合同，AI 帮你找风险；填写一张表单，AI 帮你补内容。

第二条是做企业知识库和问答助手。把制度、产品资料和业务文档交给 AI，让员工能够直接提问。

第三条是提供 Agent、工作流、知识库和插件搭建平台，让企业自己组合 AI 应用。

这些能力都有价值。它们降低了信息获取和内容生产的成本，也让 AI 第一次真正进入了企业软件。

但它们有一个共同的局限：AI 可以说、可以写、可以建议，却不一定能把业务往前推进。

它可以告诉销售哪些客户可能流失，却不一定能创建跟进任务；可以识别合同风险，却不一定能发起修改和审批；可以回答采购制度，却不一定能生成采购单、校验预算并提交流程。

这也是为什么“接入了大模型”和“拥有可以交付的 AI 产品”，中间仍然隔着很长一段距离。

模型接入、知识库、工作流、MCP、工具调用和 Agent Builder 已经快速普及。但基础组件变得常见，不等于生产级 Agent 已经成熟。

Deloitte 在 2026 年发布的企业 AI 调查覆盖了 24 个国家、3,235 名企业与 IT 负责人。调查显示，只有 25% 的受访者把至少 40% 的 AI 试点推进到了生产环境；只有 30% 的组织真正围绕 AI 重新设计了关键流程。接近四分之三的企业计划在两年内部署 Agentic AI，但只有 21% 认为自己已经具备成熟的 Agent 治理模型。

市场不是已经完成了从 Demo 到业务价值的跨越。恰恰相反，大家正在撞上同一堵墙：怎样让 AI 从一次回答，进入一个真实、受约束、可持续的业务过程。

过去，企业软件主要是给人操作的。

员工理解任务，找到对应应用，打开页面，读取数据，填写表单，点击按钮，再根据结果决定下一步。软件负责承载数据和规则，人负责在不同页面、流程和系统之间推动事情发生。

如果把这个过程展开，大致是：

Agent 带来的变化，不只是多了一个自然语言入口，而是其中一部分执行工作开始从人转移给 AI：

还是前面的客户续约任务。这套 CRM 可能已经能够识别风险客户、解释部分风险原因，并提供续约提醒。销售经理接下来仍要核对合同承诺、严重工单和最近沟通，判断不同客户需要产品介入、商务谈判、高层拜访还是继续观察，再分别安排后续动作。

当 Agent 接手其中的信息组织和任务推进，经理可以直接交代目标，把精力留在客户分级、行动取舍和外部承诺这些关键位置。

这里最值得关注的，不是自然语言替代了几个按钮，而是谁在理解目标、组织信息和决定下一步。

当然，这不意味着所有界面都会消失，也不意味着 Agent 会替代所有操作。

低风险、规则清楚、结果可逆的任务，可以逐步交给 Agent；信息不完整的任务，可以由 Agent 追问并生成草稿；涉及金额、外部承诺、数据修改和责任转移的动作，仍然需要人确认；面对模糊判断、复杂例外和高风险决策，人依然应该处于主导位置。

企业软件因此会同时保留两种工作方式。

有时候，人仍然会打开应用，查看业务对象、处理异常和做复杂判断，Agent 在旁边解释、生成和检查。有时候，人只需要提出目标，Agent 在后台调用多个系统推进任务，再把需要判断的部分交还给人。

真正的变化不是“聊天框替代 SaaS”，而是：人开始从大量寻找、搬运和机械操作中退出一部分，把更多精力放在目标、判断、例外处理和责任上。

如果只看传统企业软件厂商，我们很容易把未来理解成：每一家 SaaS 都在自己的产品里增加一个 Agent，然后继续争夺原来的客户和入口。

但 Codex、WorkBuddy 这类产品展示了另一条路线。

它们不是从 CRM、ERP 或 HR 这样的业务系统出发，而是先进入一个人的电脑、文件和日常工作。用户直接交代目标，Agent 读取资料、操作工具、拆解任务，最后交付报告、表格、演示文稿、代码或者一个可以运行的小工具。

这类产品表面上更像 ToC 的个人生产力工具，处理的却大量是企业里的真实工作。

OpenAI 在 2026 年 6 月提到，Codex 的知识工作者已经约占用户的 20%，而且增长速度超过开发者三倍。他们用 Codex 制作报告、电子表格、演示文稿和合同，也用它做研究、数据分析、流程自动化，以及构建过去需要工程支持的轻量工具。

腾讯对 WorkBuddy 的定位也不是一个只负责回答问题的助手，而是“全场景 AI 办公工作台”：它可以读取和修改本地文件，自主拆解任务，在云端持续运行，让多个 Agent 并行工作，并通过专家、Skill 和连接器扩展能力。企业版又进一步加入统一身份、组织架构、企业 Skill、用量控制、安全审计、专属网络和私有化部署。

所以，更准确的说法不是它们“从 ToC 进入 ToB”，而是：它们先从个人生产力获得入口，再顺着个人每天真正要完成的工作，进入团队协作和企业系统。

这会直接动摇传统 SaaS 对入口的理解。

用户可能不再关心“我应该打开哪个软件做报告”，而只关心“我把资料交给 Agent，它能不能把报告交给我”。过去分散在多个办公软件里的资料整理、数据分析、内容生成和文件处理，很可能被一个通用工作 Agent 重新组织起来。

它们最先拿走的，是软件的操作层和产出层。

但 ToB 工作还有另一部分：修改客户归属、变更合同状态、发起采购审批、调整库存、执行付款、核销财务数据。这些动作会让企业里的真实业务状态发生变化，涉及身份、权限、事务一致性、审批、合规和责任。

通用 Agent 可以越来越像一个非常能干的员工，但它仍然需要进入 CRM、ERP、HR、财务和流程系统，才能真正把这些事情办成。

因此，未来并不只是“通用 Agent 吃掉 ToB SaaS”，而是两条产品路线在业务动作层相遇。

一条路线从上往下：通用工作 Agent 先获得用户和个人上下文，再跨文件、网页和应用组织任务，最后调用企业业务动作。

另一条路线从下往上：现有 ToB SaaS 把业务对象、数据、权限和流程开放成 Agent 可调用的能力，再向上增加任务入口和场景 Agent。

双方最后争夺的是同一个问题：谁来理解用户目标，谁来组织任务，谁来提供具有业务效力的动作，谁来保证这些动作合法有效。

说到这里，很多 ToB 公司负责人会有一个更现实的担心。

如果用户开始从 ChatGPT、Claude、Microsoft 365、钉钉或者其他 AI 入口提出任务，谁还会打开我的软件？投入多年做出来的页面、功能和流程，还有没有价值？

这个担心不是多余的。AI 确实可能改变软件入口。

SaaS 产品原本需要把用户带进自己的应用，让用户熟悉菜单，再按照既定方式完成操作。统一的 AI 入口改变了这件事：用户可以留在一个地方提出任务，再由外部 Agent 调用不同业务系统。部分软件的使用时长、页面访问和功能入口价值，可能因此下降。

但这不等于业务系统本身失去价值。

当 Agent 真正开始办事，五类过去容易被藏在页面后面的资产可能变得更重要。

第一类是业务语义。

客户、商机、合同、工单分别是什么？“高风险客户”意味着什么？一个合同进入“待续约”状态，需要满足哪些条件？这些不是模型从字段名里猜出来就能稳定使用的。

第二类是业务上下文。

当前用户是谁，客户处于什么状态，之前发生过什么，还有哪些未完成事项。没有上下文，Agent 只能给出听起来合理、却未必适合当前业务现场的建议。

第三类是业务动作。

创建跟进任务、更新商机阶段、提交合同审批、分配工单、催办流程。企业需要的不是 Agent 会描述这些动作，而是它能通过受控方式真正执行这些动作。

第四类是业务约束。

谁可以读取什么，谁能修改什么，金额达到多少必须审批，哪些动作可以自动完成，哪些必须由人确认。权限和规则不能只写在提示词里，它们必须由业务系统强制执行。

第五类是业务反馈。

动作有没有成功，流程走到了哪里，任务是否真正完成，失败原因是什么，用户后来有没有推翻 Agent 的判断。没有反馈，Agent 就无法知道自己到底是在推进业务，还是只完成了一次看起来不错的表演。

所以，数据本身不是 Agent 的燃料。带着身份、语义、状态和权限的数据，才是。

这些能力原本被包在页面、表单、按钮和流程里，主要供人操作。ToB 产品需要做的，是让它们同时可以被 Agent 理解、查询、调用和约束。

但这里必须加一个条件：这些资产的价值不会自动保留。

如果业务语义、权限和动作仍然只藏在页面里，外部 Agent 会尝试像人一样操作页面；如果系统虽然开放了 API，却没有提供足够的业务语义、状态、规则和结果反馈，它又可能退化成一个被其他 Agent 调用的数据后台。

所以，ToB 厂商不能只安慰自己“数据还在我这里”。真正要做的是主动把供人点击的功能，转成供 Agent 可靠调用的业务能力。

这可能才是 ToB SaaS 在 Agent 时代更值得守住的位置。

你不一定能永远守住用户的第一个入口。但如果创建订单、修改客户、发起审批、处理工单时，任何 Agent 都需要经过你的业务语义、权限、规则和反馈，你才有可能继续掌握业务执行中不可替代的一层。

过去几个月，市场又往前走了一步。

当企业里不再只有一个 AI 助手，而是出现几十、几百个来自不同平台、不同团队的 Agent，新的问题随之出现：企业里到底有哪些 Agent？它们是谁创建的，代表谁行动？可以接触哪些数据、执行哪些动作？质量、风险和成本怎样观察？出错以后由谁接管和负责？

几家头部企业软件厂商正在用不同名字回答同一类问题。

Microsoft 把 Agent 365 定位为企业 Agent 的“控制面”，强调发现、治理、安全和观测；ServiceNow 用 AI Control Tower 管理企业不同系统里的模型、Agent 和工作流；Salesforce 的 Agent Fabric 开始把 Agent 身份、高风险动作授权、MCP 连接和治理放到同一层；Workday 则提出 Agent System of Record，用来管理 Agent 的角色、责任、成本和绩效。

这些厂商发布说明的是战略方向正在集中，不代表所有能力都已经成熟，更不代表企业已经普遍落地。但多家公司同时开始争夺这一层，至少说明一件事：企业 AI 的竞争重点，正在从“谁能创建 Agent”，继续走向“谁能让 Agent 在企业里被发现、被授权、被约束并被持续运营”。

把通用工作 Agent 放进来以后，可以把企业 AI 产品完成任务的过程拆成四个关键位置：

Agent 管理贯穿整个过程：谁创建 Agent、它代表谁、能看什么、能做什么，出了问题谁接管，以及成本和效果怎样衡量。

ToB 公司不一定要把四层全做一遍。

对大多数垂直 SaaS 来说，和通用 AI 平台争夺万能入口未必是最现实的选择，建设一个跨企业所有 Agent 的控制面也未必符合自己的位置。但它们必须判断自己准备占据哪一种位置。

第一种，是争夺通用工作入口。像 Codex、WorkBuddy 一样承接个人和团队的各种任务。这条路空间很大，竞争也最激烈，需要模型、工具生态、个人上下文、电脑操作和分发能力，多数垂直 SaaS 并不适合硬做。

第二种，是成为某个领域最懂业务的垂直 Agent。例如销售 Agent、采购 Agent、法务 Agent 和财务 Agent。它不处理所有工作，但在一个领域拥有更深的业务语义、方法、数据和任务闭环。

第三种，是成为任何 Agent 都能可靠调用的业务执行底座。不管入口来自 Codex、WorkBuddy、企业微信还是自己的 Agent，真正改变业务状态时，都必须通过自己的业务对象、动作、权限、规则和审计。

三种位置可以组合，但一家公司必须知道自己的主战场在哪里。对大多数已有产品和客户的 ToB SaaS 来说，更值得优先回答的是：不管用户把任务交给哪个 Agent，它最后要把事情办成时，是否仍然需要我的产品？

当外部 Agent 想创建一张采购单、修改一份合同、推进一个商机，它能否通过你的系统读到正确上下文，调用合适动作，并受到原有权限和规则的约束？

如果可以，AI 入口属于谁就不再是唯一决定胜负的问题。

方向说清楚以后，真正难的是怎么开始。

我不建议一上来建设一个宏大的企业 Agent 平台，也不建议从“哪些页面可以加 AI”开始盘点。对已经有产品和客户的 ToB 团队，更实际的起点是选一个真实任务，然后连续回答六个问题。

第一问：用户究竟想完成什么任务？

不要先问“CRM 哪个页面可以增加 AI”，而要问销售经理正在试图完成什么。

风险名单只是起点。他想针对不同客户形成行动计划，把跟进责任分配下去，并持续看到处理结果。

解决一个工单、推进一个商机、完成一次采购、审查一份合同，这些才是用户真正想完成的任务。功能是软件视角，任务才是用户视角。

一个好的起步场景，应该高频、边界相对明确、结果可以验证，失败后也有办法回退。不是越复杂越能证明 AI，而是越能跑通一个完整任务，越能暴露产品真正缺少的能力。

第二问：任务完成后，业务世界发生了什么变化？

如果 AI 最终只返回了一段回答，很多时候还没有进入业务闭环。

客户跟进场景的结果，不应只是一份风险分析，而应该包括经过确认的客户分级、行动方案、负责人和已经创建的任务。采购场景的结果可能是一张进入审批流程的采购申请；客服场景的结果可能是一张真正解决并关闭的工单。

判断 AI 是否产生价值，不能只看它说得对不对，还要看业务状态有没有发生预期变化。

第三问：Agent 办事前，需要理解哪些上下文？

回到前面的 CRM 场景，Agent 至少需要知道当前用户身份、客户归属、系统给出的风险判断及其依据、合同承诺、历史工单、沟通记录、续约规则和风险口径。

这里不是把所有数据一股脑塞进提示词。产品需要根据当前任务和用户权限，提供恰当的业务上下文，并让数据携带它原本的语义和状态。

Agent 读到“90”这个数字没有意义。它需要知道这是合同剩余天数、客户健康分，还是一笔以万元计的应收款。

第四问：产品能否提供稳定、受控的业务动作？

Agent 不能永远停留在读数据和给建议，也不应该依赖模拟点击页面或者直接修改数据库来办事。

产品需要逐步提供语义清楚的业务动作，例如创建跟进任务、生成采购草稿、发起审批、分配工单、查询流程状态、更新合同版本。

每个动作都应该有明确的输入、权限、执行结果和失败反馈。Agent 可以决定何时调用，但系统必须决定它是否有权调用，以及调用之后怎样保证业务一致性。

这一步决定了你的 SaaS 到底只是“能被 AI 读取”，还是已经“能被 Agent 执行”。

第五问：哪些事情交给 Agent，哪些必须留给人？

产品设计不能只问 AI 能不能做，还要问出错代价有多大、结果是否可逆、责任属于谁、信息是否充分。

可以先分成三级：允许自动执行；需要人确认后执行；只能由人判断和执行。

读取客户资料、整理风险依据，可以让 Agent 自动完成；创建一批内部跟进任务，可以先生成草稿，交给经理确认；对客户作出价格承诺、修改关键合同条款，则不应该因为模型“有把握”就自动执行。

人工确认不是 Agent 不够聪明的补丁，而是业务系统的一部分。好的产品不是想方设法把人赶出流程，而是清楚知道什么时候应该把判断权和责任交还给人。

第六问：怎样证明 Agent 真正创造了业务价值？

调用量、对话量、生成次数很容易统计，却未必说明业务价值。

一个任务型 Agent，更应该关注任务完成率、一次完成率、人工接管率、错误动作率、平均任务时长、单次任务成本，以及最终业务状态是否按预期变化。

还要关注人在哪些节点频繁纠正 Agent。如果销售经理每次都要推翻客户分级或行动建议，问题可能不在生成话术，而在风险依据和业务上下文；如果任务总是创建失败，问题可能不在模型，而在权限、动作接口和异常处理。

这些指标不仅用于验收，也会反过来告诉产品团队：下一步应该优化模型、上下文、业务动作，还是人机分工。

很多企业现在缺的不是又一个 Agent 创建器，而是第一个真正进入生产、能够稳定完成任务的 Agent。

更稳妥的路径可以分成三步。

第一步，跑通一个任务。

选一个高频、规则相对明确、结果可验证、失败可回退的场景。从用户提出目标开始，一直走到业务状态真正发生变化。不要把“Agent 成功给出答案”当成完成。

第二步，从场景中抽象公共能力。

第一个任务跑通以后，再把身份上下文、业务动作、权限校验、人工确认、执行日志、异常处理和效果评估抽出来，复用到第二个任务。

能不能低成本迁移到第二个场景，比第一个 Demo 看起来有多惊艳，更能说明产品是否开始形成真正的 AI 底座。

第三步，当 Agent 数量和来源真的增加以后，再建设统一治理和控制面。

如果企业里只有一两个试点 Agent，就先把任务闭环、责任边界和业务价值跑清楚。等到不同团队、不同平台的 Agent 开始进入生产，再解决统一发现、身份、授权、风险、成本和绩效管理。

不要倒过来：先花半年建设一个什么都能搭的 Agent 平台，再去寻找究竟有什么任务值得完成。

模型当然要选，技术路线也很重要。但对一家已经拥有产品、客户和业务数据的 ToB 公司来说，还有三个更难、也更长期的问题。

第一个问题：你要和所有人争夺 AI 入口，还是让自己的产品成为所有 Agent 都必须调用的业务底座？

如果两者都不是，你能否在一个足够重要的业务领域里，做出真正懂业务、能够完成闭环的垂直 Agent？

第二个问题：你的核心资产究竟是页面和功能，还是页面背后的业务对象、规则、流程、动作和结果数据？

第三个问题：当产品价值开始从“提供功能”走向“帮助完成任务”，你的研发方式、交付方式、运营指标，甚至商业模式要不要跟着变化？

这些问题没有一套适用于所有公司的标准答案。垂直 SaaS、低代码平台、协同工具和数据产品，适合占据的位置并不一样。按席位收费也不会明天就被结果付费统一替代。

但有一件事已经值得现在开始判断：未来客户购买的，可能不只是“系统里有多少功能”，而是这些功能背后的业务能力，能否被人和 Agent 共同使用，最终把事情做完。

回到开头那套 CRM。

这套 CRM 可能已经能够识别风险客户、解释部分风险原因，并触发固定的续约提醒。这些能力不会因为 Agent 出现就失去价值。

真正有价值的 CRM，需要进一步把这些能力交给 Agent 使用：什么是客户，什么是风险，风险判断基于哪些证据，当前发生了什么，谁能看到什么，下一步允许做什么，哪些动作必须经过人，做完以后业务状态如何变化。

ToB 软件真正要做的，是把藏在页面、流程和人的经验里的业务能力，重新组织成 Agent 可以理解、调用、约束和审计的能力。

当人和 Agent 都能通过这套系统可靠地把事情办完，ToB 软件才真正完成了 AI 化。