内部评审资料 仅供决策参考 BLUEPRINT / 2026-07
FEASIBILITY STUDY · 自建 AI 原生 IM 可行性蓝图

把公司的日常沟通,
变成 AI 能读懂的资产

自建内部 IM,让全部工作流经一条 AI 可读的管道:人人有自己的 Agent,老板有 README,日报周报由 AI 起草。这份蓝图回答三个问题——能不能做、怎么做、坑在哪。

结论:可行,但有条件
判断一 · 技术

每个组件都有成熟方案

IM 是二十年前就被解决的问题,开源底座现成;RAG、Agent、向量检索也已工程化。中型技术团队 6–9 个月可以走完前四个阶段。

判断二 · 真正的难点

难的不是建 IM,是权限、数据质量与迁移

AI 检索必须严格继承"每个人本来能看到什么",否则 AI 会变成越权信息的泄露通道;而聊天语料碎片化,检索质量天然低于文档;最后,员工愿不愿意从微信搬过来,决定一切。

判断三 · 路径建议

IM 不要从零自研,AI 分台阶上

基于开源 IM 二次开发,先站稳"能用";再上公司级 AI 问答;然后才是个人 Agent 与自动日报;Agent 互通放最后。每一步的出口都盖"人审"章。

Architecture

系统架构:六层一纵贯

消息自上而下流动;右侧的权限与审计纵贯所有层——它不是一个模块,而是每一层都要回答的问题。关键解耦点在消息总线:IM 只管把消息可靠送达,AI 全部从总线上消费,两边互不拖累。

客户端层Clients
桌面 Electron移动 FlutterWebAI 对话入口内嵌
起步阶段直接用开源 IM 自带客户端换皮,把"问 AI"做成和"发消息"同级的入口,而不是藏在角落的机器人。
接入层Gateway
WebSocket 长连接网关API 网关统一鉴权 SSO
与 HR 系统打通组织架构和账号生命周期:入职自动开号,离职即时回收——这也是权限模型的数据源头。
IM 核心服务IM Core
单聊 / 群组多端同步已读回执文件 / 审批 / 机器人
强烈建议基于开源二开(OpenIM、Mattermost、野火 IM)。消息不丢、不重、多端一致这三件事,从零磨到稳定要以年计。
消息总线Event Bus
Kafka消息事件成员变更事件权限变更事件
全系统的解耦中枢:AI 管道挂了不影响聊天;权限变更(退群、调岗)也走总线,驱动下游数据同步更新可见性。
数据管道 + 存储Data Pipeline
清洗 / 脱敏会话级分块Embedding写入时打 ACL 标签
PostgreSQL 存消息原文,MinIO 存文件,向量库 + 全文索引做检索。每个知识块写入时就带上"谁可见"的元数据,这是整个安全模型的地基。
AI 层Agents
个人 Agent 运行时RAG 检索服务LLM 网关Agent 互通协议检索前 ACL 过滤
每人一个 Agent 实例(身份 = 本人权限的只读副本)+ 记忆(README、偏好)。LLM 网关统一路由大小模型、做缓存与计费。
权限与审计
Tech Stack

技术栈选型

原则只有一条:把自研预算留给 AI 层和权限层,其余全部站在成熟方案上。以下均为可私有化部署的选项,数据可以完全不出公司。

环节首选备选选型理由
IM 底座 OpenIM(Go,为二开而生) Mattermost · 野火 IM · Zulip 千万别从零写。Zulip 的话题式消息流对 AI 消化格外友好,值得一看。
消息总线 Kafka NATS JetStream · Pulsar IM 与 AI 管道解耦的关键;事件可回放,便于重建索引。
基础存储 PostgreSQL + Redis + MinIO MySQL 系亦可 消息库按会话分区;Redis 管在线状态与未读数;MinIO 存文件。
检索层 Qdrant / Milvus + Elasticsearch pgvector(千人以下够用) 必须支持元数据过滤(ACL 在检索阶段生效);向量 + 关键词混合检索。
Embedding BGE-M3(开源,可私有化) 各大厂商 Embedding API 中文语料表现好,自托管则数据不出内网,长期成本低。
大模型 DeepSeek / Qwen 系 API(国内已备案) 私有化部署 Qwen / DeepSeek 开源权重 敏感行业直接私有化(需 GPU 投入);日报等简单任务路由到小模型省成本。
重排序 BGE-Reranker 商用 Rerank API 聊天语料噪声大,粗排后重排对答案质量的提升非常明显。
Agent 编排 LangGraph / 自研状态机 Dify(用于快速验证) 日报这类固定流程用工作流写死;自由问答才交给 Agent 自主规划。
权限与审计 自研统一 ACL 服务 + 全量审计日志 OpenFGA(关系型授权) 这是最值得自研的部分:IM 可见性、文档权限、Agent 读取权必须同源。
Data Flow

数据怎么流转

一条主管道把"聊天"变成"可检索的知识";日报与 Agent 预沟通是它上面的两个应用流。凡是内容离开 AI、进入人的视野或对外发出的节点,都盖人审章。

消息产生
员工在 IM 中发出消息,IM 服务写入 PostgreSQL。消息原文永远只有这一份权威存储,后续所有加工都可以追溯回来。
事件进入总线
消息、撤回、退群、调岗等事件全部进 Kafka。AI 侧只从总线消费——聊天与 AI 彻底解耦,任何一边故障都不拖累另一边。
清洗与脱敏
过滤表情包、系统通知与口水话;按规则对手机号、证件号等做可选脱敏。垃圾进、垃圾出,这一步省不得。
会话级分块
话题时间窗把多条消息聚合成一个语义块再嵌入。单条聊天记录没有语义,这一步对最终效果的影响大于换模型。
嵌入并固化权限 ACL
BGE-M3 向量化后写入向量库,每个块携带元数据:来源会话、可见成员名单、时间戳。权限在写入的那一刻就被固化进数据。
提问与受限检索
员工向自己的 Agent 提问。系统先按提问者的 ACL 过滤候选范围,再做向量 + 关键词混合检索与重排序——是"先过滤、后检索",绝不是检索完再挑。
生成回答,强制引用
LLM 基于命中的片段作答,每个结论附出处链接,点击可跳回原始消息;检索不到就回答"不知道 + 建议去问谁",禁止编造。
全程审计
谁的 Agent 在何时读取了哪些块、生成了什么内容,全部落审计日志。出问题可回放,越权可定位。

自动日报

Daily Report Pipeline
  1. 每日定时拉取当日与该员工相关的消息、任务与文档变更触发:工作日 18:00 定时任务
  2. 员工 Agent 按模板起草:今日进展 / 阻塞 / 明日计划,每条附出处
  3. 员工确认或修改后签发——AI 起草,人签字,责任归属才清楚
  4. 老板 Agent 收取全员日报,对照 README 中的关注点汇总并标记异常
  5. 老板阅读汇总;重要事项回到人与人的直接沟通
周报 = 对已确认日报的二次汇总,不重新生成,避免误差层层放大。

Agent 预沟通

Agent-to-Agent Protocol
  1. 员工 Agent 读取老板 README:风格偏好、关注指标、决策禁区README 由老板本人维护,视为其 Agent 的公开接口
  2. 员工 Agent 起草方案或请示初稿
  3. 老板 Agent 依据 README 预审,返回修改意见
  4. 往返修订,上限 3 轮——防死循环,防误差放大
  5. 双方本人确认后,才算正式沟通成立
所有 Agent 消息必须显式标注 「AI 代拟」,禁止冒充本人发言。
Roadmap

分五个台阶上

顺序本身就是风控:先让 IM 站住,再让 AI 上场。每个阶段独立交付价值,任何一步不达预期都可以停在原地止损,前面的投入不作废。

阶段一 · 第 1–2 月

IM 底座站稳

开源选型与私有化部署;打通 SSO 与组织架构同步;消息、群组、文件、基础机器人可用。

验收:核心团队的日常沟通可完全迁入
阶段二 · 第 2–4 月

全员迁移 + 数据地基

行政推动、领导带头;把审批、公告、打卡提醒等刚需搬进来,给出"非用不可"的理由。同步上线 Kafka 管道、ACL 权限模型与审计日志——先有地基,再谈 AI。

验收:日活 > 90%,微信群只剩闲聊
阶段三 · 第 4–6 月

公司级 AI 问答

先上一个全公司共用的 RAG 问答机器人,带引用、带权限过滤。目标是让"有问题先问 AI"成为肌肉记忆,同时在真实流量下打磨检索质量。

验收:周人均提问 ≥ 3 次,越权红队测试零泄露
阶段四 · 第 6–9 月

个人 Agent 与自动日报

每人一个 Agent,老板 README 上线;日报由 AI 起草、本人审核签发,老板侧自动汇总。

验收:日报按时率与员工满意度同时上升
阶段五 · 第 9 月起

Agent 互通与流程自动化

开放 Agent 预沟通协议、周报自动汇总,低风险流程逐步放开自动执行。原则:自动化的范围,永远不超过审计能力覆盖的范围。

验收:每一次自动执行都可回放、可追责
为什么不一步到位?因为阶段三之前你无法验证两件生死攸关的事:员工是否真的迁移过来了、权限过滤是否真的滴水不漏。在这两件事被证明之前,个人 Agent 和自动日报都是空中楼阁。
Redlines

三条红线,五个注意

红线是不可越的制度设计,注意事项是要花钱花人的工程现实。

红线

一 · 权限泄露即事故

必须检索前过滤,靠提示词"叮嘱模型别说" = 没有防线。上线前做套话红队测试:用普通员工账号反复追问只在高管群出现过的信息(裁员、薪酬、并购),一条都不能出来。调岗、退群、离职必须即时收敛可见范围。

红线

二 · 私聊有边界

私聊默认只进本人 Agent,不进公司大脑;规则写进员工手册,明确告知并取得同意(《个人信息保护法》的硬要求)。"一切可被读取"会改变员工说话的方式——透明的规则,比更强的技术更能换来信任。

红线

三 · 人审后发

日报、AI 代答、任何以人的名义发出的内容,一律本人确认后再发出。AI 起草、人签发——出错时责任在人不在 AI,这个归属必须在制度里写死,否则第一次事故就会摧毁全员信任。

为什么红线放在制度层

技术手段(过滤、审计、标注)只能执行规则,不能代替规则。三条红线对应三类最贵的事故:泄密、员工反弹、责任真空。先把制度写下来,再让代码去实现它。

幻觉兜底

检索不到就回答"不知道 + 建议问谁";所有回答强制带出处;每周抽查引用的真实性。

数据质量决定上限

聊天语料碎片化、代词满天飞,RAG 效果天然低于整理过的文档。打磨分块策略与时间窗,比升级大模型收益更高。

成本量级

百人规模走 API 路线,模型费用大致在每月数千到数万元量级(取决于调用量与模型档位);私有化则是一次性数十万级 GPU 投入。用"小模型写日报、大模型答难题"的分级路由控制成本。

合规与数据出境

选用国内已备案的模型服务,或完全私有化部署,让数据不出内网;留存处理与授权记录以备审计。

迁移是最大死因

自建 IM 历史上大多不是死于技术,而是死于"没人用"。体验不能明显差于飞书,而且必须给出只有自建才有的独占理由——"内部 AI 什么都知道、什么都能帮你查"恰恰就是那个理由。AI 不是这套系统的附加功能,而是员工愿意搬家的原因本身。

Bottom Line · 一句话结论

按台阶爬:IM 站稳 → 公司 AI → 个人 Agent → Agent 互通。把权限当作第一等公民写进数据里,把"人审"盖在每一个出口上。做到这些,这套系统成立,而且会成为别家抄不走的护城河。

真正的对手不是技术,
是员工手机里的微信