企业即时通讯接入 AI 时，很容易把注意力集中在一个问题上：
到底应该接哪个大模型？
是企业自建模型，还是第三方大模型？
是直接调用模型 API，还是接入 Dify、Coze、HiAgent 或其他 Agent 平台？
这些问题当然重要，但对于需要长期运行的企业即时通讯（IM）平台来说，更重要的架构问题其实是：
如果几年以后大模型换了、Agent 平台换了，企业原来的组织、消息、机器人和业务系统集成还能不能继续使用？
AI 技术变化速度很快。
企业即时通讯、OA、ERP、MES、CRM 等基础系统的生命周期却往往以多年计算。
因此，企业即时通讯对接大模型时，更稳妥的企业 AI 技术架构应该是：
把大模型和 Agent 看成可以持续升级和替换的智能层，把组织、账号、消息、机器人和业务接口建设成相对稳定的基础层。
也就是说：
AI 可以变化，企业即时通讯底座不应该因为每次更换模型而重新建设。
企业第一次建设 AI 项目时，通常希望尽快确定统一技术路线。
例如：
统一使用某一个大模型；
统一采用某一个 Agent 平台；
企业知识库和机器人都围绕同一个框架建设。
这种方式在项目初期容易管理，但长期存在一个现实问题：
AI 层变化太快。
企业未来可能因为不同原因调整模型：
所以企业今天选择的大模型，很难保证几年以后仍然是最合适的选择。
真正需要避免的不是“选错某个模型”，而是：
把整个企业即时通讯和业务集成架构，设计成离开某一个具体模型就无法继续运行。
企业即时通讯属于基础软件。
一旦真正进入企业运行，通常会沉淀大量长期能力：
这些能力不会因为企业把大模型 A 换成大模型 B 就失效。
员工之间怎么沟通、业务系统怎么找到负责人、异常消息怎么进入群组，也不应该由某一个大模型决定。
因此，从架构分层来看：
企业即时通讯属于相对稳定的基础设施。
大模型和 Agent 属于变化更快的智能能力。
如果两层绑定过深，就容易出现：
换模型需要重做机器人；
换 Agent 平台影响客户端；
更换知识库影响原有消息通路；
升级 AI 服务还需要重新改造业务系统接口。
这类耦合会不断增加后续维护成本。
可以把企业即时通讯 + AI 简单分成四层。
这一层负责：
它主要解决：
谁与谁发生交互，以及消息如何进入企业组织。
例如：
这一层保存真实企业数据，并提供真实业务动作。
它解决：
企业有哪些数据和能力可以被调用。
Agent 负责：
它解决：
一个业务目标应该怎样完成。
大模型主要提供：
自然语言理解、推理、生成和部分决策能力。
它解决：
AI 怎么理解和思考。
因此，可以把这四层关系概括为：
企业即时通讯负责连接人和组织。
业务系统负责真实数据和业务动作。
Agent 负责编排任务和调用工具。
大模型负责智能理解和推理。
各层职责越清楚，一层发生变化时，对其他层的影响通常就越小。
企业机器人是连接员工、业务系统和 AI 的重要载体。
假设企业即时通讯中已经有一个“生产助手”。
它拥有机器人身份，可以：
进入生产群；
接受员工 @；
主动推送异常；
调用 MES；
发送业务结果。
今天，它的后端可以连接某一个大模型。
以后，也可以换成另外一种模型。
从员工角度看，依然是：
@生产助手 今天有哪些异常？
企业不需要因为更换模型而重新建立：
机器人账号；
群组关系；
消息权限；
组织关系；
业务消息通路。
真正变化的只是：
机器人背后使用哪一种智能能力。
因此，更稳定的设计应该是：
机器人身份属于企业即时通讯，模型属于机器人后端可以替换和升级的能力。
企业未来变化的不只是大模型。
Agent 平台同样可能发生变化。
今天可能使用一个低代码智能体平台。
以后可能转向：
企业自研 Agent；
其他 Agent 平台；
行业智能体平台；
企业自己的 AI 中台。
如果机器人、消息卡片、事件回调和业务接口都与某一个 Agent 平台写死，迁移成本就会很高。
更合理的架构应该是：
企业即时通讯提供稳定的机器人、消息、组织和开放接口。
Agent 平台通过标准 API、SDK、Webhook 和事件接口使用这些能力。
这样，即使更换 Agent 平台，企业即时通讯中的组织和消息体系仍然可以继续使用。
因此：
Agent 平台应该使用企业即时通讯能力，而不是反过来让企业即时通讯依附某一个 Agent 平台。
企业未来也不一定只有一个大模型。
不同业务可能需要不同能力。
例如：
知识助手更关注企业知识问答；
研发助手更关注代码；
生产助手可能要求完全私有化运行；
普通办公助手更关注成本和通用能力。
所以不同机器人完全可能连接不同模型。
例如：
知识助手 → 企业知识问答模型
研发助手 → 代码模型
生产助手 → 私有化行业模型
办公助手 → 通用大模型
但员工仍然可以通过统一的企业即时通讯入口使用这些机器人。
因此，企业真正值得统一的往往不是：
所有 AI 必须使用同一个模型。
而是：
身份、组织、消息、权限和业务接口应该保持统一。
政府、国企、金融、制造、科研等企业场景，还经常面临模型部署方式变化的问题。
例如项目初期可能接入已有 AI 服务，后续又要求：
大模型进入内网；
知识库完全本地化；
推理服务部署在企业服务器；
适配国产化软硬件环境；
不同安全域使用不同模型。
如果企业即时通讯 AI 与某一个云端模型强绑定，后续这些变化就可能增加改造成本。
而如果即时通讯平台主要负责：
机器人、组织、消息、权限和业务交互，
大模型通过标准接口接入，
那么后端就可以根据实际需求调整：
云端模型 → 私有化模型
或者：
模型 A → 模型 B
而企业原有即时通讯入口仍然可以继续使用。
强调可替换，并不是说企业换一个模型只需要修改一个 URL。
不同模型之间仍然可能存在差异：
Agent 平台也可能依赖某些特定模型能力。
所以真正合理的“大模型可替换”是指：
企业 AI 架构没有把组织、机器人、消息和业务系统集成设计成某一个模型不可分割的一部分。
换模型时，AI 层可能仍然需要适配。
但企业不应该因此重新建设即时通讯和业务集成底座。
对于企业长期建设来说，有几类能力尤其适合作为稳定层。
用户、部门、群组、机器人身份，不应该因为更换模型而变化。
单聊、群聊、主动消息、文件、业务消息，都属于企业即时通讯基础能力。
AI 可以决定展示什么内容，但卡片渲染、点击事件、Callback 和状态更新仍然应该由稳定消息底座承担。
OA、ERP、MES 等系统接口不应该针对每一个模型重新开发一次。
更适合封装成不同 Agent 可以复用的业务工具。
模型发生变化，并不意味着企业业务权限需要重新定义。
谁可以访问什么数据、执行哪些操作，仍然应该由企业统一控制。
所以可以把企业 AI 架构概括成：
模型可换，Agent 可换；
组织不变，消息不变，业务接口尽量不变。
小天互连首先是一套企业级私有化即时通讯平台。
它的稳定基础是：
企业组织、账号、机器人、消息以及与业务系统之间的开放连接。
大模型和 Agent 则可以作为运行在这套基础之上的智能能力。
小天互连对接大模型和 Agent 时，核心思路不是绑定某一个 AI 平台，而是通过机器人、消息和开放接口，让不同大模型与 Agent 平台继续复用同一套企业即时通讯底座。
例如，同一个企业机器人：
今天可以连接企业知识库和某一种大模型完成问答；
以后可以连接 Agent 平台调用 ERP、OA、MES；
后续也可以根据企业模型策略更换其他大模型。
在这个过程中：
机器人身份不需要改变；
群聊关系不需要改变；
组织权限不需要改变；
消息卡片和业务系统通路也可以继续复用。
因此，小天互连这套关系可以概括为：
小天互连负责稳定的组织、机器人、消息和业务连接；大模型与 Agent 作为可以持续升级和替换的智能层。
这使企业 AI 的演进重点不再是不断新增彼此独立的 AI 入口，而是让新的模型和 Agent 继续进入已有企业即时通讯体系。
企业规划长期 AI 架构时，可以重点确认五个问题。
第一，大模型是否可以替换？
更换模型后，是否需要重新建设机器人和消息体系。
第二，Agent 平台是否可以替换？
未来采用其他智能体平台后，原有即时通讯开放能力还能不能继续使用。
第三，机器人身份是否独立于具体模型？
业务机器人能不能保持身份不变，只升级后端智能能力。
第四，OA、ERP、MES 等业务接口能否被不同 Agent 复用？
还是每接一种 AI 都要重新开发。
第五，组织、权限和消息体系是否由企业即时通讯统一管理？
还是被分散到不同模型和 Agent 平台中。
这些问题，比单纯比较两个大模型的参数，更能判断一套企业 AI 技术架构是否适合长期演进。
大模型会持续变化。
Agent 平台也会不断迭代。
但企业不会因为模型更新就反复更换：
组织架构；
员工账号；
业务群；
OA；
ERP；
MES；
消息和业务入口。
所以企业建设即时通讯 + AI 时，一个重要原则是：
把变化快的智能能力，与变化慢的企业基础设施分开。
大模型负责理解和推理。
Agent 负责执行和编排。
业务系统负责真实数据和业务动作。
企业即时通讯负责连接人员、组织、机器人和消息。
这样，无论未来更换模型、更换 Agent，还是增加新的业务系统和数字员工，企业已经建设好的即时通讯和业务连接能力都可以继续复用。
最终，企业 AI 架构真正应该追求的不是：
“绑定了哪一个最先进的大模型。”
而是：
“无论未来 AI 怎么变化，企业已经建设好的组织、消息、机器人和业务系统连接能力都能够持续使用。”
模型决定今天 AI 有多聪明。
稳定、可扩展的企业即时通讯底座，决定未来 AI 发生变化以后，这套系统还能不能继续演进。
