一家企业第一次把 AI 接进商城后台，往往会觉得最难的问题已经解决了。
运营人员在对话里提出要求，AI 能查商品、看库存，也能在确认之后修改价格。过去需要打开几个页面完成的工作，现在可以从一句话开始。
几个月后，团队想换一个更适合日常办公的助手。或者，原来的助手继续使用，但销售部门希望从自己熟悉的工作台进入，管理者希望在手机里处理审批，固定的上新任务则交给工作流执行。
这时，一个问题会变得具体：之前接好的业务能力，能够带过去多少？
商品接口也许可以继续调用，但工具说明要重写，身份要重新对应，哪些操作需要确认要再配置，失败之后怎么处理要重新约定。旧助手里的记录还在，新入口却未必知道上一次究竟做到了哪里。
这样的困难未必来自某个产品设计失误。不同入口有不同的交互方式、运行机制和安全边界，适配工作本来就不可能完全消失。真正值得追问的是：企业每接入一个新的 AI 入口，究竟是在增加一种使用已有能力的方式，还是又建了一套只能在那里工作的业务逻辑？
AI 产品会继续变化。企业需要让接入过程中形成的业务理解、授权规则和运行经验，尽可能成为下一次接入的起点。
当竞争进入连接层，企业要看得比入口更远
围绕 AI 的讨论，很容易集中在模型能力上。谁回答得更好，谁推理更快，谁能够处理更长的任务，这些当然重要。
但对一家实际经营的企业来说，模型的价值还取决于它能够接触什么、被允许完成什么，以及做完之后能不能留下可靠结果。
今年二月，Anthropic 在企业版 Cowork 的更新中介绍了私有插件市场、连接器管理和面向不同岗位的插件。五月，它又宣布收购提供 SDK、CLI 和 MCP 服务器工具的 Stainless，并在公告中强调 Agent 连接数据和工具的能力。
这些是厂商围绕自身产品所做的投入，不能据此说企业软件已经实现普遍互通。但它们至少说明，竞争已经延伸到连接和使用既有系统的这一层。
对企业而言，未来可能同时面对多种入口：通用办公助手、业务软件内置的助手、面向特定岗位的智能体，以及稳定执行重复任务的工作流。它们各有适用场景，也可能长期共存。
我的判断是，随着入口增加，企业会越来越在意一种能力：既能采用更好的 AI 产品，又能保留已经建立的业务秩序。
这并不要求企业预先押中最终胜出的助手。相反，企业可以把更多注意力放在那些无论入口怎样变化，都仍然需要回答的问题上：什么叫一次有效的上架，谁可以改价，审批覆盖哪些内容，如何确认操作已经完成。
最昂贵的重复建设，往往不在接口里
让一个工具调用成功，通常有比较清楚的验收方式：参数传进去，接口返回结果，页面发生变化。
但真正进入日常经营之后，问题会不断增加。
“库存”是仓库实物数量，还是扣除已占用订单后的可售数量？“上架”是让商品进入待审核状态，还是立即对消费者可见？促销价格作用于所有渠道，还是只作用于某个活动？一个员工可以管理总部商品，是否也能修改加盟门店的销售状态？
这些问题包含业务知识，也包含组织的授权关系。它们很难仅靠一个漂亮的参数说明解决。
如果每个 AI 入口各自维护一份解释，最初可能只是重复劳动，后来就可能出现含义分叉。同一个动作在不同入口里遵循不同条件，业务规则改了一次，有的入口更新了，有的还在沿用旧逻辑。
运行记录也会遇到类似问题。一项促销工作从聊天开始，在审批页面获得确认，最后通过后台接口完成。如果这些地方无法关联，审计人员就需要手工拼接：谁提出了什么，谁批准了什么，系统实际执行了什么。
因此，接入成本应该把后续维护计算在内。除了第一次开发，还包括规则变更、权限调整、异常排查、入口升级，以及人员交接之后的理解成本。
一次接入最有价值的产物，是把原本分散在代码、文档和人的经验里的规则，整理成能够被持续维护的业务能力。
如果这些产物只存在于某个助手的提示词或私有配置里，下一次接入就很难利用它们。企业会一次次支付梳理同一件事的成本。
把一场商城促销拆开，就能看清边界
设想一个商城运营团队，希望 AI 完成这样的任务：查看现有库存，挑选适合参加周末活动的商品，创建活动商品草稿，审批通过后再调整价格并上架。
这是一段假设工作，用它可以区分哪些部分适合随着助手变化，哪些部分应当有稳定的依据。
在方案阶段，不同助手完全可以有不同表现。有的擅长比较商品，有的善于组织营销文案，有的能把分析过程呈现得更清楚。团队选择它们，正是为了获得这些差异。
进入业务动作之后，依据就需要更加明确。
查询库存，应当说明查的是哪个商城、哪个仓库，以及数据采用什么口径。不能因为某个助手习惯把“剩余库存”理解为“可售库存”，就悄悄改变经营判断的基础。
创建商品，应当区分草稿、审核中和正式上架。模型可以建议下一步，但具体状态及其对外影响，应该由业务系统定义。
修改促销价，应当沿用企业原来的权限与审批规则。审批人需要看清具体商品、价格和适用范围；实际执行也应当能够对应到被批准的内容。
完成操作之后，应当能够确认哪些商品已经变化，哪些仍待审批，哪些没有成功。对一笔已经发出、但暂时没有拿到结果的写操作，换一个助手重新做一遍，并不能代替核对原操作。
这些要求不会因为用户从桌面助手换到嵌入聊天而自然失效。它们属于企业对业务结果的定义。
这就是能力复用的具体含义：新的入口可以使用已经整理清楚的动作定义、约束和核验方式，再把它们映射到自己的交互与执行机制。每个入口仍然需要接入和验证，但不必重新猜一遍业务的含义。
能力可以复用，授权不能被顺手带过去
讨论统一接入时，一个常见误区是：既然都调用同一套业务能力，不如给所有助手使用同一个权限足够大的账号。
这样确实可能减少最初的配置，但会丢失最重要的区别：这次到底是谁在办事，又代表哪个业务主体？
同一套商品管理能力，可以向不同使用者开放不同范围。总部运营可以管理多个商城，门店员工可能只负责一个经营主体，外部服务商则只获得某次活动所需的有限权限。
工具定义相同，并不意味着可访问的数据相同；用户看到了同名工具，也不代表在任何入口都可以调用。
更换助手时，身份关联、授权范围和数据使用边界仍然需要核验。业务系统应继续作出最终权限判断。统一维护规则的价值，是让判断有一致的依据，而不是取消每一次判断。
历史记录也遵循这个原则。某个入口能够看到一段沟通，不代表另一个入口天然获准接收全文。迁移记录或关联任务，需要明确接收方、访问范围与必要的信息量。
甚至原来的审批，也不能因为内容看起来相似就被拿来批准一项新操作。可以复用审批机制，不能任意复用审批结论。
把这些区别说清楚，才能让统一能力建设扩大可用性，同时保留企业原本的责任边界。
真正值得积累的，还有验证过的经验
业务能力不是整理完就永远不变的目录。
商城可能增加新的销售渠道，库存系统可能调整占用逻辑，企业也可能改变价格审批规则。声明会变，接口会变，已经发现的工具也可能不再适合直接执行。
所以，长期复用不能只依靠一份文档。它还需要版本、变更说明和验证用例，让新的入口知道自己理解的是哪一套含义，遇到变化时应该重新确认什么。
例如，一组关于商品上架的验收场景，可以同时检查正常上架、无权限、库存不足、审批尚未完成，以及结果回包丢失后的处理。接入新助手时，团队可以复用这些场景，比较它是否仍然遵守同样的业务约束。
有了这样的积累，换助手就不再只有“聊起来感觉不错”这一种判断方式。企业可以核对：原来的业务定义是否被正确理解，关键规则是否仍然生效，结果是否可以追溯。
这也解释了为什么一套提示词很难独自承载企业的长期投入。提示词可以帮助模型理解工作，但权限判断、业务状态和执行事实，还需要在相应系统中成立。
企业积累得越多，后续试验的基础就越稳。新模型可以带来更好的规划能力，新客户端可以带来更好的交互；这些变化能够放在已有验证基础上比较，而不必每次重新建立信任。
开放的意义，是让选择权有实际支撑
在这个背景下，开放协议和开源实现的价值，会比“代码可以下载”更具体。
企业需要知道，一项能力的含义是否只能由某个产品解释，规则是否能够被其他实现读取，必要的执行记录能否在明确权限下查阅和导出，以及发生分歧时有没有共同的检验依据。
如果接口形式看起来开放，但关键含义仍然隐藏在不可见的运行行为里，迁移时就可能发现，真正重要的部分仍然要靠猜测。
反过来，也不能因为一个项目开源，就假定任何客户端都能够直接使用。适配器、宿主接口、授权流程、部署条件和版本差异，都可能带来实际工作。开放不会消除这些差异，但可以让差异更容易被看见、说明和验证。
对软件供应商而言，这同样可能改变竞争方式。
如果业务能力能够被更多合适的入口使用，供应商就有机会把行业知识、数据质量和可靠执行变成更容易被调用的服务。用户不必每次打开原来的后台，仍然可以持续依赖这个系统提供的业务事实和操作能力。
当然，开放接入也可能改变流量分配和议价关系。企业需要评估这种变化，不能假定接入更多入口就一定获得更多收入。选择权的意义，正是在这些取舍出现时，仍然有条件作出调整。
对使用企业来说，可以询问供应商一个具体问题：如果将来更换 AI 入口，现在整理好的业务规则、能力定义和验证材料，哪些可以继续使用？
这个答案，往往比支持了多少个模型更接近长期成本。
不必先建一座大平台，可以先留下第一块积木
强调复用，并不意味着每家企业都应该立即建设统一中枢。
如果只有一个入口、少量动作，业务边界也很清楚，直接连接已有 API 可能是最合适的方式。引入额外控制面会带来部署、维护和故障处理成本，这些成本需要由实际收益来支撑。
但即使从直接连接开始，也可以有意识地保留几样东西：准确的动作说明、权限依据、状态变化含义，以及能够证明结果的验收场景。
当第二个入口出现时，再观察哪些部分重复了。是同一套身份映射，同一种审批要求，还是同一类执行记录？优先把已经反复出现的问题整理出来，通常比预先设计一个包罗所有需求的平台更稳妥。
这里还涉及组织分工。业务团队负责说明什么结果才算正确，系统团队负责维护接口和最终权限，Agent 团队负责让模型理解和使用能力。共同定义的部分需要有人维护，不能因为放进了一个配置页面，就假定责任已经自动确定。
长期能力建设可以从很小的范围开始。重要的是，每次试验结束后，都留下下一次仍然用得上的材料，而不只是一个成功演示。
我们希望推动的，就是这种积累
我们用 A2B，即 Agent-to-Business，描述 Agent 进入已有业务系统完成工作这一方向。
围绕这个问题，ACC（Agent Capability Contract，Agent 能力契约）提供实现中立的声明语义，用于描述业务动作的开放范围、主体要求、风险与审批意图等信息。它可以由不同的运行时、控制面或开发工具实现，业务系统继续保留最终授权。
百灵中枢 BailingHub 则是开源业务动作治理控制面的一种实现，连接能力发现、可信身份、审批和执行轨迹。它与 ACC 分别演进，面向不同入口的生态适配也需要遵守各自的边界。
我们希望减少的，是企业在不同 AI 入口之间反复解释同一套业务、重复建设同一类治理机制的成本。这个方向仍然需要具体场景来检验，不能仅凭协议或产品名称获得保证。
如果你已经有商城、SaaS、CRM 或 ERP，可以先选一条真实需要的动作：查询可售库存、创建商品草稿，或修改一组促销价格。说明谁可以执行、需要哪些条件、怎样确认结果，再看这些定义能否成为不同入口共同使用的依据。
百灵中枢的公开 Demo 可以用于了解这种工作方式；真实接入评估则可以从“业务系统、一条动作、一份脱敏接口说明”开始。
AI 助手会不断进步。企业的每一次接入，也应该留下能够继续生长的能力。
