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