企业有了统一 AI 入口，业务就能真正打通了吗？

企业里的 AI 越来越多，一个很现实的问题随之出现：员工到底该去哪里找它们？

查制度有一个助手，分析经营数据有一个助手，写方案、做图片、处理客户问题，又是另外几个。能力都有了，员工却要先记住各自在哪儿、能做什么，再判断这件事该交给谁。

统一入口因此有很明确的价值。员工可以从熟悉的地方提出需求，企业也更容易管理哪些人能够使用哪些 AI 能力。

最近，腾讯云宣布 AgentPortal 开放使用，将其定位为面向企业成员的 Agent 统一使用入口与协作平台。企业在 ADP 中构建的智能体可以发布到这里，也支持接入第三方智能体。

官方文档还介绍了访问、功能和使用三个层级的权限管理，智能助理会在用户权限范围内路由到适合的企业智能体。可见，统一入口本身也在认真处理组织使用与权限问题。

顺着这个方向往前看，一个更值得讨论的问题是：当员工已经可以在同一个地方使用各种 AI，一件需要多个业务系统配合的事情，怎样才能从头到尾办成？

不妨设想一家连锁企业，要为几家门店安排周末会员活动。

运营人员对 AI 说：“参考最近的经营情况，准备一个周末促销方案，商品、海报、优惠券一起安排好。”

数据助手找出了适合促销的商品，策划助手做好了活动方案，设计助手生成了海报。员工不用在几个工具之间复制内容，这已经是很实在的改善。

接下来，事情开始进入业务系统。

商城需要创建活动，库存系统需要确认哪些商品真的有货，优惠券系统需要处理适用门店和发放条件，财务可能要确认某一档补贴。部分操作可以自动完成，另一些需要有资格的人作出决定。

假设这位运营人员可以为甲店准备活动，但没有乙店的发布权限；库存查询刚结束，一批商品又被其他订单占用；优惠券已经创建，活动发布却因为价格条件不符而失败。

此时，统一入口依然能够找到所有相关助手。真正需要回答的，却是下一步该怎么继续。

是缩小活动范围，调整商品，还是等待批准？已经创建的优惠券要先停用吗？员工看到的“已完成”，到底指海报完成、优惠券创建完成，还是活动已经对顾客生效？

这个例子是一个假设，用来讨论跨系统业务普遍会遇到的关系，并非对某款产品现有实现的判断。

员工提出的是一个目标，系统分别处理的是一项项动作。两者之间，还有许多需要被明确承接的事情。

过去，这些事情往往由人完成。

运营人员知道，“方案通过了”不一定意味着“预算也批准了”；看到库存不足，会回去改活动；发布失败，会检查已经准备好的券和商品，避免留下半套能被顾客碰到的配置。

这些判断通常没有出现在“复制文案”“上传图片”“点击发布”这样的操作步骤里。人每天都在做，企业就容易把它们当成系统天然具备的能力。

当 AI 开始接管操作，原本藏在人的经验里的协调工作，就需要有明确的规则和处理位置。

有些适合交给智能体规划，有些适合复用已有流程，有些必须由业务系统检查，还有些需要由人处理例外。把这些安排清楚，自动化才有可能真正减少人的负担。

其中一个容易混淆的问题，是权限如何从入口延续到业务。

某位员工能够使用营销助手，说明企业允许他访问这项 AI 能力。但营销助手可能同时涉及查看数据、准备方案、创建草稿、发布活动等多种动作。每个动作的允许范围，还要落到实际业务里。

同样，一个助手把任务交给另一个助手，传过去的可以是目标、材料和处理进度。接收方还需要知道，它凭什么能够代表这个人，在这个系统里继续办理相应事务。

不能因为上一个助手已经说“可以了”，下一个系统就把这句话当成所有后续动作的批准。原来只允许准备活动，也不能在任务转交几次之后，悄悄变成允许发布和发券。

这不要求每一步都弹出人工确认。企业完全可以预先规定：在指定门店、预算和商品范围内，满足条件的活动允许自动发布。真正要保留的，是这次行动所依据的委托，以及执行时仍然成立的业务条件。

统一使用身份之后，仍然需要把具体业务中的行动资格说清楚。

另一个问题，是不同系统怎样理解同一件事。

商城里的“活动已创建”，可能只是保存了一份草稿；优惠券系统里的“已启用”，可能意味着顾客已经可以领取；库存系统里的“有库存”，也未必表示这些库存已经为本次活动保留。

这些状态各有用途。要让它们协同，就需要知道哪个状态只是准备完成，哪个状态已经对外生效，哪些条件仍然要在下一步检查。

否则，每个助手都可能准确报告自己做了什么，员工却仍然不知道整件事处于哪里。

这里还包含一些很具体的工作：不同系统的门店编号如何对应，活动商品和库存商品是不是同一个对象，金额包含哪些费用，哪张单据能证明这次动作真正完成。

自然语言可以帮助解释这些差异，但企业仍需要维护确定的对应关系和核对依据。系统之间的意思对齐以后，机器才能在这些依据上可靠地办事。

因此，衡量统一 AI 入口的价值，可以继续向业务结果走一步。

除了员工用了多少次助手、生成了多少份内容，还可以看：一项完整任务花了多长时间，中间需要人补几次材料、转交几次工作，发生部分失败后能否准确接手，最后的结果是否得到相关业务系统确认。

有些部署在当前阶段只需要查询、分析和准备材料。把这些工作集中起来，就已经值得做，不必为了证明“智能”而强行开放全部写操作。

但如果目标已经变成让 AI 直接办理业务，验收就应覆盖真实的业务过程。

仍然以活动为例，可以先选几家门店、几类商品和一种优惠方式，明确允许自动完成的范围。除了验证一次正常上线，还要看看库存变化、权限不足、部分创建成功时，系统分别会怎样处理。

正常情况能继续，例外情况能解释，已有结果能核对，员工也知道什么时候需要介入，这样的自动化才有扩大的基础。

不必要求所有业务系统立即改造成一个整体。跨系统任务可以分阶段完成，也可以在必要时暂停、转交或采取补救动作。关键是这些状态有清楚的含义和负责人，后续处理能够依据实际结果继续。

这也带来一个产业层面的机会。

企业可以更换 AI 入口，部门可以选择不同的助手，软件厂商也会不断更新自己的产品。随着入口变化，那些已经梳理清楚的业务能力、行动条件和结果含义，值得作为可持续维护的资产留下来。

统一入口的平台有能力承担其中一部分工作。原来的业务系统、身份平台、审批流程也各有基础。具体由哪个组件实现，可以因企业而异；如果已有机制已经可靠地完成，就应当复用。

问题在于，当更多厂商、系统和智能体参与进来，大家如何共同理解这些要求，怎样验证自己的实现没有把含义传错。

这正是我们推进 A2B、ACC 和 BailingHub 所关注的方向。

A2B，Agent-to-Business，是我们为一类场景提出的认知框架：智能体接受人或组织的委托，进入业务系统办理事务，并形成需要由人或组织承担的业务后果。

用这个视角看前面的活动，重点就会落到完整的业务行动关系：谁把什么事交给了机器，机器能做到哪里，各系统接受什么依据，结果又怎样回到委托方手里。
ACC 是我们提出的开放能力契约，尝试让能力范围、主体要求、风险和审批意图等信息有共同的表达方式。它为不同接入方理解这些要求提供参照；具体执行需要运行机制落实，业务系统继续保留最终权限判断。

ACC 本身也不会自动统一各公司的商品编号、替企业决定预算制度，或把跨系统操作变成一笔天然可撤销的事务。共同契约的价值，在于让可以共同表达的部分稳定下来，使业务适配有更清楚的基础。

BailingHub 则把相关思路做成可运行的开源控制面，让能力开放、执行约束、人工介入和操作记录能够进入实际接入过程。它与业务系统、现有流程共同完成相应职责。

我们希望推动的，是让不同的 AI 进入不同的业务系统时，都能按照共同可理解、可检查的行动规则办事。这也是一项面向未来的基础建设：今天的入口可能是企业工作台，明天可能是手机助手，甚至是能在物理空间里执行任务的设备。载体改变以后，委托、权限、业务条件和结果核对仍然需要被承接。

统一入口让企业的 AI 更容易被使用。沿着这条路继续往前，业务能力也需要更容易被正确调用，系统之间的配合更容易被验证，整件事的进度更容易被接手。

当员工只需要说出目标，企业就要能够回答：谁允许这件事发生，哪些系统已经做到了哪一步，以及还差什么才能真正完成。