企业即时通讯接入 AI 后，最常见的交互方式是：
员工先提出问题，AI 再回答。
例如：
帮我查一下今天的异常订单。
总结这份生产报表。
查询这个客户最近的跟进记录。
这种“人先问、AI 再答”的模式，非常适合知识问答、文档分析和个人 AI 助手。
但企业实际运行过程中，大量重要事情并不是员工主动发现以后再去问 AI。
更多时候是：
系统先发生变化，然后需要找到正确的人。
例如：
ERP 发现库存不足；
MES 发现生产指标异常；
审批已经超过处理时限；
合同即将到期；
服务器发生故障；
重点客户订单出现异常。
这时，如果 AI 只能等待员工主动提问，就很难真正进入企业业务运行过程。
因此，从 AI 问答助手继续走向业务 Agent，一个很重要的能力是：
不仅能够回答问题，还能够由业务事件触发，主动找到相关人员并交付结果。
这就是企业即时通讯（IM）中的主动消息和事件驱动能力。
AI 问答天然是一种被动交互。
典型链路是：
员工发现问题 → 找到 AI → 提出问题 → AI 查询 → 返回结果
例如销售人员发现一个订单迟迟没有发货，于是问：
帮我看看订单 10086 为什么还没发。
AI 查询 ERP 后返回原因。
这种方式当然有价值。
但问题在于：
员工首先得知道这件事情已经发生。
如果订单异常已经持续两天，而没有人主动查看，那么再聪明的 AI 也不会自动介入。
企业运行中，大量任务本质上是由业务状态变化触发的。
例如：
库存 < 安全库存
合同距离到期 < 7 天
审批等待时间 > 24 小时
服务器 CPU > 90%
生产指标超过异常阈值
客户订单状态发生异常变化
这些事情的起点不是“人提出问题”。
而是：
业务事件发生。
因此，对组织级 AI 来说，事件触发 Agent与用户主动提问，是两种不同的任务入口。
企业 AI 需要从：
Question Driven——问题驱动
进一步扩展到：
Event Driven——事件驱动。
主动消息并不是 AI 出现以后才有的能力。
在传统系统集成中，企业即时通讯消息推送通常就会由 OA、ERP、MES、监控系统或者机器人根据业务事件触发。
例如：
监控系统发现服务器故障：
监控系统 → 告警机器人 → 运维群
ERP 发现库存不足：
ERP → 业务机器人 → 采购负责人
OA 流程到达某个节点：
OA → 消息服务 → 待办人员
这些本质上都属于主动消息。
它和普通聊天最大的不同在于：
消息并不是由接收者先发起，而是由系统状态、业务规则或者任务执行结果触发。
因此，主动消息本来就是企业即时通讯连接业务系统时非常基础的一种能力。
AI 和 Agent 出现以后，这种能力并没有消失，反而会变得更加重要。
传统业务机器人也可以主动发消息。
区别主要在于：
谁决定什么时候发、发给谁、发什么。
传统的机器人主动推送通常依赖预设规则。
例如：
库存低于 100，就通知采购经理。
这里的条件是提前定义的。
程序已经明确知道：
触发条件：库存 < 100
接收人：采购经理
消息内容：库存不足提醒
系统只需要按照规则执行。
这种模式稳定、可控，而且在大量确定性企业业务中仍然非常重要。
Agent 则可能接到一个更高层的目标：
每天检查重点订单，如果有可能影响交付的问题，及时通知相关负责人。
这时 Agent 需要继续判断：
哪些是重点订单；
什么情况算可能影响交付；
异常对应哪个负责人；
是否需要立即提醒；
应该把哪些信息放进消息。
于是链路可能变成：
查询订单 → 查询库存 → 查询生产状态 → 判断风险 → 找到负责人 → 生成消息 → 主动发送
这里，“发送消息”只是整个 Agent 任务中的一个执行工具。
所以可以简单理解：
传统推送机器人是“条件满足，所以发消息”。
Agent 主动消息是“为了完成业务目标，我判断现在应该给某个人发消息”。
二者并不是互相替代，而是决策方式和智能程度不同。
假设用户对 AI 说：
帮我检查今天的异常订单。
AI 查完以后返回：
今天有 8 张异常订单。
这是 AI 问答。
如果继续告诉用户：
其中 3 张可能影响交付。
仍然主要属于结果分析。
但真正的业务目标可能是：
有问题就及时通知对应销售和生产负责人。
这时，如果 Agent 只是把名单显示给当前用户，员工仍然需要：
复制内容 → 找负责人 → 发消息 → 跟进。
AI 只是帮助人分析。
如果 Agent 能够继续：
查询负责人 → 根据异常情况生成摘要 → 把结果发送给对应人员
那么任务才开始形成真正的业务闭环。
因此：
能不能主动把结果交付给下一环节，是判断 AI 是否真正进入企业业务流程的一个重要标准。
主动消息并不是数字员工的全部能力，但它是 Agent 从“只给当前用户答案”走向“参与组织协作”的关键通路之一。
企业每天都在持续产生业务事件。
这些事件可能来自不同系统。
订单异常、库存不足、发货延迟、回款状态变化。
新审批到达、审批超期、流程退回、待办即将到期。
设备异常、生产指标异常、工单延期、质量异常。
重点客户长时间未跟进、商机状态变化、合同即将到期。
服务不可用、资源异常、日志高风险错误、备份失败。
这些事件的共同特点是：
事情已经发生，需要找到正确的人。
而企业即时通讯恰好承担的是：
找到人，并把信息送到人。
因此，从架构上看：
业务系统负责产生事件，Agent 负责理解和判断，企业即时通讯负责把结果可靠地触达人员和组织。
三者组合以后，AI 才真正开始从一个聊天能力进入企业运行过程。
主动消息能力很重要，但并不意味着 AI 应该可以随意给任何人发送任何内容。
企业环境与个人 AI 最大的区别之一，就是组织和权限边界。
例如：
生产 Agent 可以向生产负责人发送异常。
但不应该自动把生产数据发送给无关人员。
HR Agent 可以向指定员工发送人事提醒。
但不能把某个员工的人事信息发送到公共群。
因此，Agent 主动消息至少需要受到几类约束：
所以真正企业级的主动消息能力不是：
AI 想发给谁就发给谁。
而是：
Agent 在明确身份、组织范围和权限边界内，根据业务事件完成受控消息触达。
这也是为什么主动消息最终仍然依赖企业即时通讯原有的组织和权限体系。
主动消息首先解决：
信息怎么主动找到人。
但找到人以后，还会出现另一个问题：
用户收到消息以后怎么继续处理。
例如 Agent 主动发送：
订单 10086 存在库存不足风险。
如果只是文字通知，员工可能还需要打开 ERP。
如果消息进一步提供：
查看订单｜确认处理｜转交负责人
用户就可以直接进行下一步操作。
因此：
主动消息解决“把事情送到人”。
消息卡片解决“人收到以后怎么继续处理”。
事件回调则可以继续把用户操作送回 Agent 或业务系统。
组合起来就是：
业务事件 → Agent 判断 → 主动消息 → 人员处理 → 后端继续执行
消息卡片本身的多端渲染、回调和状态同步已经可以作为独立技术能力展开。这里更重要的是理解：
主动消息负责把业务事件送入即时通讯，交互卡片负责承接后续处理。
从消息通路本身来看，两者完全可以复用同一套企业即时通讯基础设施。
区别主要发生在后端判断。
传统群机器人可能收到监控系统的一条固定告警：
CPU 超过 90%。
然后原样发到运维群。
Agent 则可以先进一步分析：
CPU 为什么异常；
最近有没有发布；
日志里有没有相关错误；
影响了哪些服务。
最后只把真正重要的信息发给对应人员：
服务 A 在 10:32 出现 CPU 持续高占用，初步判断与上午发布的版本有关，目前接口响应时间受到影响，建议优先检查实例 2。
因此：
机器人负责消息通路，Agent 负责决定消息背后的内容和下一步动作。
从企业即时通讯架构来看，两者并不冲突。
AI Agent 可以继续使用企业原有的机器人和主动消息体系。
小天互连首先是一套企业级私有化即时通讯平台。
小天互连的主动消息能力建立在既有机器人、组织关系和业务系统接口之上，可以用于传统业务通知，也可以继续被 AI Agent 和数字员工复用。
在传统业务系统集成场景中，OA、ERP、MES、监控平台等系统产生业务事件后，可以通过机器人和开放接口，把消息送给指定员工、部门或者群组。
因此，在 AI 和 Agent 场景中，不需要重新建立一套新的消息触达体系。
Agent 可以继续复用已有的：
机器人身份、组织关系、人员范围和消息通路。
例如：
ERP 产生订单异常事件；
Agent 获取相关业务数据并判断风险；
再通过小天互连机器人体系把结果发送给对应负责人。
如果需要人工确认，还可以继续结合消息卡片和事件回调完成后续处理。
这条关系可以概括为：
小天互连负责组织和消息触达，Agent 负责理解业务事件和决定下一步动作。
因此，小天互连中的主动消息能力不仅适用于传统业务机器人，也可以继续成为 AI Agent 和数字员工参与企业业务的重要基础能力。
对于 Agent 来说，变化的是消息发送之前的智能判断过程。
对于企业即时通讯来说，稳定的仍然是：
谁可以发、发给谁、通过什么身份发送，以及消息如何进入组织。
企业在评估 AI 助手、Agent 或数字员工时，可以重点确认四个问题。
第一，AI 是否只能被动回答，还是可以由业务事件触发？
这决定它能否进入大量无人主动发问的业务场景。
第二，主动消息能否准确找到人员和群组？
是否能够根据组织、角色、业务负责人等关系完成触达。
第三，Agent 是否有明确的消息权限边界？
哪些人可以通知、哪些群可以进入、哪些数据允许发送，都需要受控。
第四，主动消息之后能否继续形成业务闭环？
用户收到消息以后，是只能阅读一段文字，还是可以继续处理并让 Agent 执行下一步。
这些问题比单纯询问“AI 能不能发消息”，更能够判断一套企业即时通讯 AI 是否真正具备业务使用能力。
AI 问答解决的是：
员工有问题以后，AI 能不能给出答案。
但企业运行每天都在不断产生新的业务事件。
订单变化、生产异常、审批超时、合同到期、系统故障，这些事情不会因为员工没有向 AI 提问就停止发生。
因此，企业 AI 从个人助手继续走向业务 Agent，需要完成一个重要变化：
从“等人提问”走向“感知事件并找到正确的人”。
这并不意味着所有消息都交给 AI 自动决定。
传统规则推送仍然适合大量确定性业务。
更加现实的组合是：
确定性事件继续使用规则触发；
复杂事件由 Agent 分析、判断和生成处理建议；
企业即时通讯负责把消息可靠地送到正确的人。
最终形成：
业务事件 → AI / Agent 判断 → 企业即时通讯触达 → 人或系统继续执行。
对于企业即时通讯 AI 来说：
会回答问题，只代表 AI 进入了聊天。
能够在受控权限下，根据业务事件主动找到正确的人，才意味着 AI 开始真正进入企业运行过程。
