设想一家SAAS软件公司的客户，连续两周很少打开管理后台。

过去，这可能会被客户成功团队视为一个危险信号：运营人员不再活跃，功能使用率下降，续费似乎也需要关注。

但如果换一种情况呢？

这两周里，客户一直通过 AI 助手维护商品、检查库存、准备活动。商品信息仍保存在这套商城系统里，订单仍由它处理，价格和销售规则也仍然由它执行。用户减少了点击，系统却没有停止工作。

这个假设提出了一个值得软件行业认真思考的问题：当“使用软件”和“打开软件”逐渐不再是同一件事，我们过去用来理解产品价值、客户关系和商业模式的方式，是否也需要调整？

围绕 AI 与 SaaS 的讨论，很容易滑向两个结论。一种认为，AI 可以生成软件、调用工具、代替人工操作，传统应用迟早会失去价值。另一种认为，企业的数据和业务逻辑都在原系统里，AI 最终只是一个更方便的入口，软件厂商无需担心。

这两种判断都抓住了一部分变化，也都忽略了另一部分。

入口变化不意味着业务系统会消失。但业务系统继续存在，也不意味着原有的软件公司能够保住原有的价格、利润和客户关系。

**更值得讨论的，是软件价值由哪些部分构成，以及当其中一些部分变得容易替代之后，价值会怎样重新分配。**

这已经不只是一个遥远的设想。

2026 年 8 月，Salesforce 公布了 Headless 360 的扩展进展，提出让授权的 AI Agent 通过开放标准发现和使用企业业务能力，同时延续既有身份、权限和业务规则。其中部分组件仍处于公开测试阶段，不能将整个方向理解为所有能力都已经成熟落地，但其产品选择本身值得关注。

在商业场景中，Shopify 的官方文档也已经提供让 AI 助手访问指定商店商品目录、购物车与政策信息的接入方式。这主要面向购物体验，并不等于开放商家全部后台权限，却说明一项商业能力可以通过新的交互入口被使用。

这些动作并不能证明未来只会有一种软件形态。它们至少表明，软件厂商已经开始把“用户在哪里交互”和“业务能力由谁提供”分开考虑。

对大量做商城、进销存、客户管理以及行业软件的团队而言，这种分离可能比界面上增加一个聊天窗口更有长期影响。

理解这种影响，可以先回到企业为什么购买软件。

企业购买一套系统，通常同时获得几种东西：一个让员工完成工作的操作界面，一套记录和处理业务的规则，一份持续更新的业务事实，以及围绕这些东西建立起来的交付、服务和协作关系。

它们被装在同一个产品里，也往往被放进同一张报价单，因此我们容易把它们看成一种不可分割的价值。

例如，商城后台里的“修改商品”看起来只是几个输入框和一个保存按钮。但在实际经营中，这次修改可能需要处理多个规格、不同销售渠道、活动价格的优先级，以及已经产生订单后哪些信息还能改变。

界面负责把这些要求变成可操作的步骤。系统负责判断修改是否成立，并让后续订单、展示和履约继续使用正确的信息。

如果 AI 能帮助用户填写和提交，前一部分工作的形式会变化；后一部分工作的要求仍然存在。它也可以由新的系统承担，但不会因为用户换了一个交互方式就自动消失。

这里还需要区分两种“复杂”。

一种复杂来自业务本身：商品有多个规格，库存有不同状态，活动存在互斥条件。另一种复杂来自软件设计：用户必须在五个页面之间来回跳转，才能完成一个本来可以直接表达的决定。

AI 可能帮助用户绕过第二种复杂。软件公司如果一直把这种操作负担当成产品深度，就会高估自己的不可替代性。

与此同时，第一种复杂也不能成为拒绝改变的理由。模型与开发工具的进步，同样可能降低理解、实现和维护部分行业规则的成本。过去需要大量定制开发的功能，未来可能更容易重做。

因此，“我们懂行业”需要进一步回答：究竟懂在哪里？哪些判断能稳定落实到业务结果？哪些变化能够持续跟上？客户更换服务商时，真正需要重新获得的又是什么？

行业经验只有持续改善交付质量，才有机会形成长期价值。代码存量和功能数量本身，并不能回答这些问题。

**AI 带来的一个压力，是让软件厂商更难把操作成本、历史积累和客户价值混为一谈。**

这也会改变我们对数据的理解。

“数据在我这里”经常被视为软件公司的优势。但对企业而言，重要的不只是数据被存在哪里，还包括它是否准确、及时、完整，能否支持下一步经营判断。

库存表里有一个数字，不等于系统能够准确回答“现在还能卖多少”。待付款占用、已分配待发货、退货待检和不同仓库的调拨，都可能影响这个问题的答案。具体采用什么口径，要由企业的业务规则决定。

如果一个智能体拿到的是过时或含义模糊的数据，再强的推理能力也难以保证后续动作正确。反过来，一套能够持续提供可靠业务事实的系统，即使用户较少直接访问它，仍可能对经营产生重要作用。

这种价值依赖持续维护。客户的数据也不能被简单当作软件厂商可以任意占有的商业资产。良好的导出、迁移和接入能力，会影响客户是否愿意长期信任这套系统。

软件厂商需要证明的，是自己为什么能持续把业务事实维护得更好。仅仅证明客户离开很麻烦，无法保证客户在有了新选择以后仍然愿意留下。

不过，讨论到这里，还不能得出“只要把后台做好，商业价值就不会受影响”的结论。

创造价值和获得收入，中间还隔着客户关系、替代选择以及议价过程。

假设一家企业以后主要通过某个 AI 办公入口安排工作。它先向这个入口描述目标，再由入口选择和调用商城、库存、客户管理等系统。

用户更频繁接触谁？遇到问题时先找谁？采购新的能力时，先看到谁的推荐？当两个后端都能完成同一类任务时，又由谁决定使用哪一个？

这些问题会影响软件厂商在商业关系中的位置。

掌握任务入口的一方，可能拥有更多分发机会，也可能更容易向客户解释最终收益。提供后台能力的一方，仍在承担工作，却可能逐渐难以直接表达自己的贡献。

这种情况并非必然发生。企业也可能主动选择多个助手、保留直接采购关系，并要求关键业务能力可以更换入口。但软件公司需要看到，开放能力既可能扩大服务范围，也可能使自己进入更激烈的比较和替换之中。

同一个商品查询动作，如果几家系统都能以相近的质量提供，买方就可能更多比较价格、响应速度和接入成本。若某套系统能够处理特定行业中其他系统无法稳定处理的规则，选择就不会只剩价格。

这意味着，标准化对软件公司有双重影响：它可能降低接入门槛，让更多客户有机会使用；也可能降低替换门槛，让原本依靠封闭连接维持的优势受到挑战。

对中小团队而言，拒绝接入未必能保住客户；仅仅完成接入，也不会自动带来客户。真正需要选择的是，自己希望在哪一部分持续提供值得付费的差异，以及怎样让这种差异被看见。

**当交互入口可以更换，软件公司的竞争会更直接地落到能力质量、持续服务和商业关系上。**

收费方式也会受到这种变化的影响，但不能简单地从“按账号收费”跳到“按调用次数收费”。

如果少量员工借助智能体完成了更多工作，账号数量与工作规模之间的关系可能发生变化。过去能够大致反映客户使用规模的指标，未必继续适合每一种产品。

工具调用次数也不天然代表客户价值。一个设计不好的流程，可能用更多调用完成同一件事；一次失败后的重复请求，也不应该被宣传成更多有效工作。若企业付费越多只是因为系统越低效，计费关系就会产生矛盾。

按结果收费同样有边界。更新一批商品是否成功，通常能够通过系统记录核对；一场促销最终增加了多少销售额，则受到选品、价格、季节、投放等多种因素影响。不能把所有变化都归因于某一次 AI 操作。

更现实的做法，是重新检查收费依据与交付承诺是否匹配。有的产品适合按组织或业务规模收费，有的适合订阅加用量，有的能够为清楚定义的服务结果定价。不同方式会继续并存。

这里的重点，是企业是否能够理解自己为什么付费，以及软件厂商是否能够证明自己交付了什么。AI 改变工作方式以后，这个问题会变得更加具体。

还有一个容易被忽略的变化：企业软件里的许多规则，并没有完整地写在软件里。

某类活动需要先问负责人，某个供应商的库存更新要晚半天，一笔特殊订单必须交由某位同事判断。这些知识可能长期存在于人的经验、聊天记录和团队惯例中。

过去，员工在操作软件时，也在补足这些没有显式表达的规则。系统看起来运行顺畅，部分原因是人一直在中间解释、纠错和协调。

当企业希望把更多任务交给智能体，这些隐含工作就会显现出来。

“让 AI 像员工一样操作”不是一个足够完整的要求。企业仍然需要决定：哪些判断可以委托，哪些条件必须满足，遇到例外时找谁，以及什么结果算作完成。

因此，AI 接入有时会暴露组织本身尚未说清楚的问题。即使技术连接已经完成，一项业务也可能因为口径不一致、责任不明确而无法稳定自动化。

这给行业软件团队留下了一类工作：帮助客户把反复发生的业务判断整理成清楚、可维护的规则，并让规则落实到操作中。但它也要求团队从“交付一个功能”进一步走向“理解功能在组织里怎样持续工作”。

这种能力需要产品、实施和服务共同支撑。一个聊天框无法独立完成它，一份庞大的规则配置表也未必能完成它。

由此再看软件界面，结论也应当更谨慎。

用户希望少填表、少搬运数据，不等于用户希望所有事情都通过对话完成。

比较几十种商品的价格与规格、检查一批活动的覆盖范围、调整复杂规则、处理异常订单时，表格、图形和专门设计的操作界面仍然可能更高效。对话善于帮助用户表达意图，却不总是最适合承载密集信息。

未来的一种可能形态，是同一个业务能力同时服务于多种交互：人可以在专业界面里细致操作，也可以通过智能体发起任务；智能体处理到需要判断的位置，再把清楚的上下文交给人。

这不要求所有产品都拆成完全独立的组件。对于边界明确、流程统一的场景，一体化产品可能更容易交付，也能减少多方协调的成本。软件厂商自己提供智能体，同样可能是合理选择。

但无论采取哪种形态，都需要避免把业务事实和关键规则只留在某一个交互入口里。如果换一个助手就必须重新解释权限、重新拼接流程，企业获得的便利就很难稳定复用。

我们也不应过早想象一个完全自动运行的“业务能力市场”：只要把工具列出来，智能体就能自由挑选，各家软件像标准零件一样互换。

两个系统都提供“更新商品”，不代表它们处理相同的对象、遵循相同的价格规则，或者能够承担相同的服务承诺。调用方式可以趋于一致，业务含义仍需要被理解，使用关系仍需要被建立。

未来的开放生态能否成立，要看这些差别是否能够被清楚表达，以及跨越差别的成本能否得到控制。协议能够帮助不同实现沟通，但不能替代行业知识、实际授权和持续运营。

对于今天仍在服务真实客户的软件团队，这些判断最终需要落到投入顺序上。

不必为了追逐一个可能的未来，立刻重写整套系统；也不宜把全部预算都放在通用聊天体验上，希望仅靠一个新入口就重新定义产品。

可以先选一项客户经常做、完成标准清楚的工作。例如，准备一批新品上架：哪些信息由系统提供，哪些内容可以生成，谁能修改，哪些条件必须先满足，提交后怎样确认结果。

这一项工作足以暴露许多真实问题。商品与规格能否准确对应？库存口径是否一致？失败后用户能否接着处理？换一个智能体入口，是否仍然能够使用同样的业务规则？

同时需要观察完整成本。模型处理更快，如果带来更多核对、返工和解释，客户未必真正省力。接入可以复用，如果每次系统升级都需要大量修补，软件团队也未必获得更好的交付效率。

因此，评估产品进步时，可以在页面访问和功能点击之外，增加更贴近工作的观察：有多少任务被正确完成，用户需要多少次人工介入，例外能否及时处理，接入能否长期维护。

这些指标不能互相替代。后台活跃下降，可能是自动化产生了效果，也可能是客户正在离开；能力调用增长，可能是有效工作增加，也可能是低效重试。只有把使用方式与业务结果一起看，数据才更容易解释。

对于中小软件公司，值得争取的位置，是在客户不断变化的工作入口之下，继续提供一部分可靠、清楚、有差异的业务能力。这个位置需要主动建设，也需要在客户选择中不断被验证。

这也是我们关注 A2B、建设 ACC 与百灵中枢的背景。

我们用 A2B，也就是 Agent-to-Business，描述智能体接受委托、进入已有业务系统并产生业务后果的交互方向。它帮助我们讨论一个共同问题：当发起工作的人越来越少直接点击后台，一次委托怎样保持清楚的身份、范围、规则和结果。

ACC，Agent Capability Contract，是实现中立的能力治理契约，关注这些含义如何被不同系统和实现理解。百灵中枢 BailingHub 是开源业务动作治理控制面，提供围绕能力发现、授权范围、审批衔接和执行追溯的工程实现。两者独立演进，原业务规则继续由相应业务系统维护。

我们希望它们能帮助开发者减少重复接入，也让企业在选择智能体入口时保留核验和更换实现的空间。一个具体场景也可以采用平台原生能力或直接集成；是否需要独立控制面，应由实际复杂度和维护成本决定。

这些项目仍需通过外部实现、真实接入和持续使用来证明价值。产业方向与项目目标契合，不等于某个开源方案已经成为行业标准，更不等于它必然获得市场。

回到文章开头那家商城软件公司：如果客户不再频繁打开后台，最有意义的追问，是客户的工作现在怎样完成，系统在其中承担什么，以及这部分工作是否仍值得客户持续付费。

AI 可能让越来越多的软件退到操作界面之后。对软件开发者而言，长期的挑战是让自己的能力在用户看不见的地方仍然可靠，并让这种可靠成为客户能够理解、愿意选择的价值。

## 拓展阅读

本文结合截至2026年9月20日可查的官方产品资料展开行业分析。
- [ACC：Agent Capability Contract](https://agentcapability.org/zh-CN/)
- [百灵中枢 BailingHub：项目介绍与接入文档](https://www.bailinghub.com/)
- [BailingHub：开源代码](https://github.com/bailinghub/bailinghub)


过去，这可能会被客户成功团队视为一个危险信号：运营人员不再活跃，功能使用率下降，续费似乎也需要关注。

当一切交由Agent，用户不再打开你的后台，SaaS 还值钱吗？

人工智能

架构设计

客户连续两周不打开后台，但业务仍通过AI助手正常运转，这挑战了传统SaaS的活跃度与价值衡量标准。软件价值正从界面操作转向数据准确、规则执行和业务结果的可靠交付。企业需区分业务复杂性与操作负担，重新审视收费依据与客户关系，在入口可替换的时代，依靠持续维护业务事实和清晰服务承诺来构建不可替代性。

软件开发

软件设计

智能体

Agent

SaaS

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当一切交由Agent，用户不再打开你的后台，SaaS 还值钱吗？-腾讯云开发者社区-腾讯云

当一切交由Agent，用户不再打开你的后台，SaaS 还值钱吗？

当一切交由Agent，用户不再打开你的后台，SaaS 还值钱吗？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐