一家企业接上第一个AI助手，往往会有一段令人兴奋的时间。
员工不用来回切换后台，问一句就能查数据，说清楚目标就能准备业务操作。开发团队把接口连通，把注意事项写进说明，再配上权限和确认环节，一个试点便跑起来了。
接着，另一个部门也想用。但他们习惯的是另一款AI。
再过一阵，老板希望在手机上办事，合作伙伴希望从自己的办公平台发起请求，原来的软件厂商也推出了内置助手。
这时候，企业要面对一个很实际的问题：业务仍是同一套，入口多了几个，之前讲清楚的规矩，是不是又要讲一遍、写一遍、检查一遍？
11月4日，Adobe宣布，其CX Enterprise Coworker已可通过ChatGPT、Claude、Databricks Genie、Gemini for business和Microsoft Copilot等平台使用，并提供连接既有伙伴工具的MCP连接器。公告也明确提到人工监督。这说明，多入口与治理正在被一起考虑。
这条消息带来的一个值得思考的方向是：同一项业务能力，可能越来越少地依赖某个固定聊天窗口。
员工选择自己熟悉的AI，企业继续使用原来的业务系统。这听起来很合理。但操作入口可以不同，公司允许怎样办事，不能因此变成几套互不相认的约定。
设想一家连锁企业，准备调整部分门店的套餐价格。
最初接入的助手知道，运营人员只能修改所负责门店；新价格要先保存为草稿，经过指定人员确认后，才能发布。
第二个助手接进来时，开发团队复制了一份工具说明。它也知道“调价需要确认”，却把员工在对话里说的“可以，就这样”，理解成了发布所需的批准。
第三个入口上线得更晚。公司这时已经调整了门店分工，但它拿到的仍是一份旧的操作说明。
这个例子是假设，也不是Adobe的产品事故。它想说明的是：模型可以认真理解各自收到的说明，却未必得到同一份、当前适用的业务依据。
如果原业务系统在执行时保留了完整检查，不符合要求的发布应当被拒绝。问题仍然会表现为计划走到一半、反复确认、重新解释；如果某条接入路径又遗漏了必要检查，后果就可能从体验不一致变成实际越界。
企业真正需要维护的，因而不只是几份“让AI更听话”的提示词，还有这些入口与实际业务规则之间的关系。
提示词当然有价值。它可以告诉AI怎样提问、怎样组织方案、如何把专业术语解释给员工。
但一句“发布前请确认”，并没有完整回答：谁有资格确认，确认的是哪一组价格，确认以后参数能不能改变，哪个系统负责检查这次决定仍然有效。
这些责任不会因为模型更善于理解自然语言，就自动归到正确的位置。
同一句业务要求，被复制到多个AI入口以后，就变成了多份需要持续维护的约定。
第一次复制通常很便宜。真正的成本出现在以后。
门店负责人换了，审批方式变了，某种促销不再允许，后台把“保存”和“发布”拆成了两个动作。此时，需要找到所有相关入口，判断它们受到什么影响，再逐一调整和验证。
有的规则藏在工具说明里，有的写在流程节点中，有的只存在于一段很长的系统提示词里。甚至某条接入路径的行为，只是因为当时那款模型习惯多问一句，大家便误以为“这里已经有审批”。
当模型或运行环境改变，这个偶然形成的停顿就可能消失。
于是，企业以为自己在维护一套业务，实际上却在维护多份对这套业务的解释。新增一个入口所带来的工作，也远不止再接通一个接口。
这个问题不需要推导出“企业只能统一使用一个AI”。
有些团队暂时只用一个入口，确实能降低维护难度。更多企业则会因岗位、成本、合作关系和使用习惯，保留多个入口。即便今天只有一个，未来更换供应商，也会遇到同样的迁移问题。
更值得追问的是：哪些内容应该属于企业自己，能够随业务持续维护；哪些内容才是某款AI为了理解和执行而需要的适配？
可以先看一个很朴素的区别。
“怎样向运营人员解释调价影响”，可以因助手风格而不同。
“保存草稿是否等于对顾客生效”，必须以这项业务的真实含义为准。
“怎样展示待确认的价格清单”，可以适应手机或电脑。
“这位员工此刻能不能发布这家门店的新价格”，则需要由掌握当前权限和业务状态的系统作出判断。
把这些事情分清楚，才能知道该复用什么。
业务能力的含义、允许暴露给智能体的范围、需要哪些可信主体条件、是否表达了审批要求，以及预期留下什么记录，可以形成不同接入方共同理解的说明。
具体谁管理哪家门店、某项批准是否仍适用、当前订单或价格能否改变，则不能靠复制一份静态文件来维持正确。它们仍需要在适当的业务环节，由有权判断的系统检查。
这样做也不要求把企业全部规则再造一遍。现有权限、审批和交易机制可以继续承担原来的职责；共同说明把接入方需要理解的部分讲清楚，并指出执行中必须满足的条件。
规则有共同依据，不等于所有入口拿到相同权限。
门店店长使用手机助手，总部运营使用电脑助手，两者能够办理的业务本来就可能不同。外部合作伙伴也不应因为接上同一项能力，就获得内部员工的权限。
真正需要一致的是：这些差异有明确依据，能够被解释和检查。不能只是因为某个入口少写了一段说明，或某个模型没有主动追问，权限便悄悄扩大。
不同企业也可以对同一种业务作出不同决定。共同表达方式的意义，是让接入方知道该到哪里获取适用要求、如何理解它，并不要求所有公司采用相同的审批制度。
而且，写出一份共同说明，只完成了事情的一部分。
如果接入方根本不读取它，或者看不懂其中的重要条件却继续执行，它就无法产生预期约束。企业还需要知道，每条接入路径实际支持哪些要求，哪些必须交给其他机制完成，哪些情况应当停止执行或转交处理。
规则改变以后，也要能确认哪些入口已经更新、哪些仍使用旧信息。有人负责这份说明的维护，有人负责接入端的实现，业务系统继续守住最后的检查，责任才不会停在“文档已经写过”这里。
这也改变了验证AI接入的方式。
演示时，让不同助手都成功完成一次调价，只能说明正常路径跑通了。
还可以拿同一组业务条件分别检查：没有指定门店权限时，是否都受到限制；只有草稿确认、没有发布批准时，能否区分；价格已被别人修改后，旧方案是否还会被直接执行。
我们不需要它们说出相同的话，也不需要每一步采用相同的操作顺序。我们需要知道，企业要求保留的边界，是否在这些不同路径中都真正生效。
对软件开发商而言，这里也有一项长期价值。
一个客户今天偏好某款助手，明天换成另一款，不意味着订单、库存、结算和组织分工就不重要了。软件厂商掌握的业务知识，以及怎样可靠地执行、核对这些业务，仍然需要有人交付。
如果每增加一种AI，都要把同一套业务解释重新整理一遍，项目就容易陷入不断重复的定制。把共性的含义和接入要求积累下来，再把客户差异留在明确的位置，才有机会逐步减少重复劳动。
公共契约的价值，也正是在这里出现。
它不能消除所有适配成本。不同系统的数据、流程和权限模型依然不同，某些动作也需要专门处理。但它能让重复对接从“每次重新解释我们在做什么”，逐步变成“在共同理解的基础上处理差异”。
当接入方增多，这种共同理解就有了超出单个项目的意义。
行业可以一起讨论，一项能力被发现与它被允许执行有什么区别；一次对话确认与一项有效业务批准有什么区别；工具返回结果以后，哪些事实足以支撑“已经完成”。这些经验如果能够被清楚表达、检验和改进，后来者就不必总从同一个起点重新摸索。
我们提出A2B，正是希望把“智能体接受人或组织的委托，进入已有业务系统办事”这类场景，变成可以共同讨论的对象。它关心的是业务行动关系，聊天入口只是其中一个承载方式。
ACC则是我们为能力开放与治理要求整理的开放契约参考，希望让不同接入方对关键含义有共同认识。它不替业务系统作最终授权决定，也不会让一份声明自动变成所有助手都已执行的规则。
BailingHub把相关思路做成可运行的开源实现，贡献实际接入中积累的经验。我们希望推动的是减少重复解释、重复适配和重复踩坑，让业务拥有者能够更清楚地决定，自己的能力以什么条件交给机器使用。
如果未来的入口继续延伸到AI手机、企业办公平台，甚至承担部分现实操作的设备，这种需要也不会随着聊天窗口的变化而消失。载体可以变化，具体业务的委托、执行条件和责任仍然要说清楚。
企业不妨先选一项已经开放给AI的业务，看看它在两个入口中的说明和实际行为：哪些差异是有意保留的，哪些只是维护遗漏；当规则发生变化时，究竟由谁通知、谁更新、谁检查。
回答这几个问题，比继续复制一段更长的提示词，更接近可持续的接入方式。
企业应该能够选择更合适的AI，而不必每换一个入口，就重新发明一遍自己的规矩。
