「我们想把 AI Agent 接进飞书，让员工在聊天窗口里就能调用」——这是过去一年问得最多的诉求之一。
原因很简单：员工每天 8 小时以上在飞书/钉钉/企微里工作，这是阻力最小的 AI 分发路径。独立 Web 界面的 AI 工具，做得再漂亮，也逃不过"员工懒得打开"的命运。接进 IM，才有真的 adoption。
但接进 IM 也是最容易出事故的路径。因为 IM 是面向全体员工的、数据敏感、责任归属复杂。见过太多企业"先把 Agent 接上再说治理"——两个月后出事故、合规部紧急叫停、整个项目回退。
这篇文章讲清楚启动前必须回答的 4 个问题：入口、权限、审计、成本。不是全部问题，是所有项目都绕不过去的 4 个。
一、问题 1：入口问题
看起来最简单，其实最容易出错。
"把 AI Agent 接进飞书"这句话里，"接进"的形态不唯一。至少有四种不同形态，对应不同的技术实现和用户体验：
形态 A：机器人账号（@提及 唤起）
最常见的做法。员工在任何群里或者私聊里 @这个机器人，就能提问。
优点：对员工零学习成本，和日常聊天习惯一样。 缺点：群聊里 @机器人问敏感问题，所有群成员都能看到问题和答案——这是权限模型的天坑。
什么时候用：低敏感度场景，比如"帮我写个会议纪要模板""翻译一下这段话"。
形态 B：小程序 / 独立入口
员工点开一个飞书内置的小程序，进入类似聊天框的界面提问。数据留在小程序内，不泄漏到群聊。
优点：数据隔离好、可以做独立权限、能做更复杂的界面（比如返回带下载按钮的卡片）。 缺点：多一次点击——大部分员工不会主动打开。
什么时候用：中敏感度场景，比如"查客户应收""生成报告"。
形态 C：指令机器人（斜杠命令）
员工在任何对话框里输入 /查客户 或 /生成报告，就能触发特定 Skill。
优点：结合了 A 和 B 的优点——入口方便（任何对话框）+ 执行隔离（不污染群聊）。 缺点：员工要记住命令。培训成本存在。
什么时候用：高频、结构化的场景，比如销售每天查客户、财务每天跑对账。
形态 D：混合入口
以上三种组合。不同场景给不同入口。
推荐：绝大多数企业真实的用法是混合入口。强行只用一种会把场景硬塞进不合适的形态里。
关键提醒：入口形态必须在项目一开始和甲方确定清楚，不是技术选型，是产品设计。我们见过好几个项目，技术都部署完了，业务团队才说"诶，这个不是我们想要的用法"——然后返工。
二、问题 2：权限问题
这是 4 个问题里最容易被低估、但实际上最刚性的一个。
核心原则：AI 不替代权限，它在权限之上工作。
反面教材：权限镜像
很多公司做 AI Agent 的第一反应是"把 ERP 里的客户表、订单表导进一个向量数据库，员工问什么就给什么"。
这个做法致命错：
1. 权限会失真。ERP 里张三只能看华东区客户，但你导进向量数据库之后，Agent 按相似度召回——召回的可能是华北区的客户数据。Agent 不知道"按组织架构限定范围"。
2. 权限会过期。员工离职、调岗、调整权限——ERP 里立即生效，但镜像到向量数据库里的旧数据还在。前员工最后使用 AI 时能看到的东西，可能比他当前岗位应该看的多得多。
3. 审计会断裂。业务系统有完整的权限审计日志，但 AI 侧的访问记录和业务侧不对应，出事后追溯困难。
正确做法：权限不镜像，回源校验。
正面做法：权限透传 + 实时回源
标准实现是：
- 员工身份透传：Agent 执行时使用当前员工的身份（不是一个超级账号）
- 调业务系统 API 而不是直接查数据库：用员工身份调业务系统接口，业务系统按本来的权限规则返回数据
- 回源校验：对于知识库文档，每次查询时都向原系统（比如飞书 wiki / 共享盘）实时确认"这个员工现在还能看这份文档吗"——缓存 5 分钟是可接受的
- 拒绝兜底：权限不明确时 default 拒绝，不是 default 放行
这样权限、审计、调岗、离职——所有业务系统已经处理的规则，AI 侧自动继承。不做"自己一套权限"，就不会有"权限错配"。
技术细节在我们的司南产品里有完整实现（可插拔 Hermes/OpenClaw 开源 agent、AES-256-GCM 密钥隔离、回源飞书 ACL 等），感兴趣可以看 司南 的架构说明。
三、问题 3：审计问题
AI Agent 接进 IM 后，必然涉及这三类审计场景：
场景 1：合规审计
监管或者内部合规要回答："上个月谁问了什么敏感问题、AI 答了什么、数据从哪来？"
要满足这个需求，最低限度：
- 每次调用都记录：请求者 ID、时间戳、问题原文、涉及的 Skill、拉取的数据源、返回的答案
- 哈希链防篡改：每条记录包含上一条的哈希，任何篡改都会断链
- 保存周期：至少 6 个月（部分行业要求更长，比如金融 5 年）
- 可导出：监管来检查时，能按时间 / 人员 / 关键词导出结构化 CSV
场景 2：成本追踪
老板要问："上个月哪些部门花了多少 token？哪些员工的使用频率最高？有没有异常消耗？"
需要：
- 按组织架构分层聚合（部门 → 团队 → 个人）
- 实时的用量 dashboard
- 异常告警（某个员工单日调用量突增 10 倍时自动告警）
场景 3：质量追溯
业务要问："员工 A 上周收到的一个 AI 回答是错的，为什么会错？"
需要：
- 完整的决策回放（当时调了哪些 Skill、拉了哪些数据、最终给了什么答案）
- 数据源版本（引用的是哪个版本的文档？后来文档有没有更新？）
- 可复现（能否重新用当时的状态再跑一遍）
做不到这三类审计的 Agent 网关，不适合进生产环境。这是一条比较硬的红线。用 SaaS AI 的简单客户端（比如直接用飞书开放平台提供的 API）做出来的 Agent，通常只有粗糙的使用日志，这三类审计都满足不了。
四、问题 4：成本问题
最容易失控的一个。
接入 IM 后，AI Agent 的使用量会远超项目启动时的预估。原因：
- 每个员工都是潜在用户（vs. 独立 Web 工具只有那些愿意打开的人）
- 问答入口降低了门槛，员工养成习惯后会越问越多
- 长上下文对话（员工会连续追问）的 token 消耗是单次问答的 3-5 倍
- 自动触发场景（比如每天自动跑报表）会产生大量后台调用
实战估算：上线 3 个月后的用量，通常是项目启动时预估的 3-5 倍。如果启动时预算的是 5 万/月，实际会冲到 15-25 万/月。
必须提前做的 4 件事
1. 四层配额机制
不能只有一个"全公司月度上限"。需要：
- 组织层（Org）：公司年度上限
- 客户层（Customer）：大客户 / 项目组单独配额（跨组织协作场景）
- 团队层（Team）：每个部门月度上限
- 个人层（VK）：每个员工日/月上限
四层叠加，任何一层触顶就限流。这样单个员工失控不会波及整个部门，单个部门失控不会波及整个公司。
2. 分层定价 / 分层模型
不是所有问题都需要最贵的大模型。
- 简单问题（翻译、改错字）：路由到轻量模型（成本 1/10）
- 一般问答：路由到中档模型
- 高复杂度任务（代码生成、长文分析）：才用大模型
做好这个分层，整体成本通常能降 40-60%。需要在 Agent 层做模型路由，不能把所有请求一股脑发给最贵的那个。
3. 缓存层
相同/相似问题不要重复算。用 SHA256 内容哈希做缓存，命中直接返回。在高频场景里（比如员工经常问"最新的请假政策是什么"），缓存命中率能到 60%+，这部分调用接近零成本。
4. 实时预算告警
不要等月底看账单才发现超支。需要：
- 当月累计用量到 50% / 80% / 100% 时自动告警
- 按部门 / 按个人的异常突增告警
- 配额耗尽前的自动降级（比如切换到轻量模型而不是直接限流）
五、"先接上再治理" 为什么总翻车
见过的典型翻车姿势：
- 姿势 1：两个月部署完 Agent，合规部才介入，一看审计能力不够，全部下线重做。损失：项目延期 3 个月、乙方工程师白干。
- 姿势 2：员工在群里 @AI 问敏感客户数据，答案被同事看到，引发纠纷。损失：信任度重挫，整个项目被叫停。
- 姿势 3：没做成本控制，上线第二个月账单 20 万，老板震惊，直接砍预算关停。损失：已有部署全部作废。
- 姿势 4：权限镜像做法，一个月后客户数据出现在 AI 回答里，客户起诉。损失：诉讼 + 品牌 + 赔偿。
这四种情况，每一种都能通过在启动前回答好本文的 4 个问题来避免。
六、结语
把 AI 接进飞书/钉钉/企微不是技术问题，是一个产品 + 治理 + 成本的综合设计问题。
技术上，可选方案很多——自己搭 Agent 框架、用开源方案、买成熟产品。但无论选哪一种，启动前都必须把这 4 个问题的答案写清楚：
- 入口：哪些场景用什么入口形态？混合入口怎么组合？
- 权限：不镜像，回源校验。身份透传到业务系统。
- 审计：合规 + 成本 + 质量，三类审计都要。
- 成本：四层配额、模型分层、缓存、预警。
想清楚再干，比干了再补救便宜 10 倍。
我们在做司南（企业 AI Agent 网关）产品时，这 4 个问题是所有设计的起点——审计链用 SHA256 哈希链、权限回源到飞书 ACL、多租户物理隔离、四层配额机制。如果你在规划类似的内部能力，欢迎 预约一次试点部署对话，或者把司南当成架构参考。