用 MCP 把飞书和钉钉接入 AI Agent：企业 IM 的 AI 化改造实战

很多企业做 AI 助手，第一步都是接一个飞书或钉钉机器人。

但如果只是“用户发消息，机器人回一段话”，价值很有限。真正有用的企业 IM Agent，应该能读上下文、查系统、写工单、发审批、同步知识库，并且所有动作都可审计。

MCP（Model Context Protocol）适合承担这个中间层：它把企业 IM 能做的事封装成标准工具，让 Agent 不直接碰复杂 API，而是通过受控工具完成动作。

---

一、为什么不要让 Agent 直接调用飞书/钉钉 API

直接调用 API 的问题有三个。

第一，权限太散。发消息、读群成员、查文档、创建审批、上传文件，每个 API 都有自己的 token 和 scope。让 Agent 直接处理这些细节，很容易越权。

第二，错误处理复杂。企业 IM API 经常会遇到 rate limit、access token 过期、文件大小限制、卡片格式错误等问题。

第三，审计困难。你需要知道 Agent 在什么时候、因为什么、向谁发送了什么，而不是只看到一条最终消息。

MCP Server 可以把这些问题收敛到工具层。

---

二、推荐架构

User / Group Chat
        |
Feishu or DingTalk Bot Webhook
        |
Message Gateway
        |
AI Agent Runtime
        |
MCP Client
        |
Enterprise IM MCP Server
        |
Feishu / DingTalk APIs

这套架构里，Agent 只看到工具：

• send_message
• send_card
• search_docs
• create_task
• assign_ticket
• upload_file
• get_group_members

每个工具都应该有明确 schema、权限检查和日志。

---

三、MCP 工具设计

不要把一个万能 call_api 暴露给 Agent。那等于绕过了 MCP 的安全价值。

更好的方式是定义场景化工具。

例如发送飞书卡片：

{
  "name": "send_review_card",
  "description": "向指定群发送发布前审查卡片，只能包含标题、摘要、文件路径和确认按钮。",
  "input_schema": {
    "type": "object",
    "properties": {
      "chat_id": { "type": "string" },
      "title": { "type": "string" },
      "summary": { "type": "string" },
      "artifact_paths": {
        "type": "array",
        "items": { "type": "string" }
      }
    },
    "required": ["chat_id", "title", "summary"]
  }
}

这个工具故意很窄。Agent 不能随便构造任意卡片，也不能任意 @ 人。

---

四、场景一：会议纪要自动整理

目标：群里上传会议录音或文字记录后，Agent 自动生成纪要，并提交给负责人确认。

流程：

1. 监听群消息，发现会议记录附件。
2. 下载附件，转写或解析文本。
3. 提取议题、结论、待办、负责人和截止日期。
4. 生成 Markdown 纪要。
5. 通过 MCP 工具发送审查卡片。
6. 负责人点击确认后，写入知识库或飞书文档。

这里的关键不是摘要能力，而是确认机制。未经确认的纪要不应该自动进入正式知识库。

工具可以设计为：

• download_message_file
• summarize_meeting
• send_review_card
• create_feishu_doc
• append_knowledge_base

---

五、场景二：工单自动分派

目标：群里出现“系统报错、客户投诉、部署失败”等消息时，Agent 自动提取工单，并分派给负责人。

流程：

1. Message Gateway 收到群消息。
2. Agent 判断是否是可执行问题。
3. 从消息中提取系统、现象、影响范围、紧急程度。
4. 查值班表或负责人表。
5. 创建工单草稿。
6. 发卡片给群里确认。
7. 确认后写入工单系统并 @ 负责人。

这类场景必须避免误报。建议设置三道门：

• 置信度不足时只回复“需要补充信息”。
• 创建工单前必须有人确认。
• P0/P1 工单必须同步到独立告警通道。

---

六、安全清单

企业 IM Agent 的风险主要来自越权和误操作。上线前至少检查：

• Bot token 是否只放在服务端。
• MCP 工具是否有 allowlist。
• 是否禁止任意 URL 请求。
• 是否记录 tool call 输入输出。
• 是否对群 ID、用户 ID、文档空间做权限校验。
• 是否有 rate limit 和重试退避。
• 是否支持人工审批。
• 是否能撤销或标记误发消息。

尤其不要给 Agent 暴露“发送任意消息到任意群”的工具。企业 IM 是高信任通道，一次误发就可能造成真实业务影响。

---

七、落地顺序

建议从只读场景开始：

1. 查群消息。
2. 总结会议记录。
3. 生成待办草稿。
4. 人工确认后再写入文档。
5. 最后再接工单、审批和自动通知。

一开始就做全自动审批或自动分派，风险很高。

企业 IM 的 AI 化，不是把聊天框变聪明，而是把组织里的信息流变成可追踪、可确认、可回滚的工作流。MCP 的价值就在这里：让 Agent 有能力行动，但行动被工具边界管住。