AI工具接入教程
每日 MCP Server

Slack MCP：让 AI 接入团队消息流，自动跟进任务与决策

2026-08-15
网络仓库
支持客户端：
Claude DesktopCursorVS CodeContinue
MCPSlack团队协作消息集成

简介

团队的真知灼见都埋在 Slack 频道里——决策、反馈、待办、闲聊。Slack MCP 让 Claude/Cursor 直接读频道历史、发消息、查线程，把 AI 从'被问才答'升级成'主动协作'。本文拆解安装配置、核心能力、5 个实战场景与权限管控要点。

安装命令

npx -y @modelcontextprotocol/server-slack

为什么需要 Slack MCP

团队协作的痛点：

你：帮我总结今天 #design-review 频道讨论的决策
AI：请把聊天记录贴给我
你：（200 条消息，手动复制 1 小时）
AI：（超过 context 限制，只总结了一半）

你：帮我把这个 PR 结论发到 #engineering
AI：我没法发消息，请你自己发
你：（切换应用、复制粘贴）

Slack MCP 解决的就是：让 AI 直接读写 Slack，把消息流变成可计算的数据。

核心能力

能力工具名说明
列出频道list_channels获取所有可访问频道（公开 + 已加入的私有）
频道历史get_channel_history读取指定频道的消息历史
线程回复get_thread_replies读取某条消息的线程回复
发消息post_message向频道或私信发送消息
回复线程reply_in_thread在某条消息下回复
列出用户list_users获取成员列表（含状态）
用户信息get_user_info查询单个用户详情
搜索消息search_messages全工作区消息搜索

安装与配置

Step 1：创建 Slack App

  1. 访问 https://api.slack.com/apps → Create New App
  2. 选 "From scratch"，命名（如 MCP Integration）
  3. 进入 OAuth & Permissions，添加 Bot Token Scopes：
Scope用途
channels:history读公开频道历史
channels:read列出公开频道
channels:write发消息到公开频道
groups:history读私有频道（需加入）
groups:read列出已加入的私有频道
groups:write发消息到私有频道
im:history读私信
im:write发私信
users:read查看成员
search:read搜索消息
files:read读附件
  1. 装 App 到工作区 → 获取 Bot User OAuth Token（xoxb- 开头）
  2. 在 App Home 勾选 "Allow users to send Slash commands and messages from the channels tab"

Step 2：各客户端配置

Claude Desktop

编辑配置文件，加入：

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-你的token",
        "SLACK_TEAM_ID": "T0123ABCD"
      }
    }
  }
}

Cursor / VS Code Continue

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-你的token",
        "SLACK_TEAM_ID": "T0123ABCD"
      }
    }
  }
}

Step 3：把 Bot 加入频道

在 Slack 中 @提及 Bot 名字，或在频道设置 → Add apps 加入。否则 get_channel_history 会返回空。

Step 4：验证

重启客户端，输入：

列出我能访问的所有 Slack 频道

Bot 会调用 list_channels 返回列表，确认配置成功。

五个实战场景

场景 1：会议决策追踪

你：读取 #design-review 今天 14:00 后的消息，
    提取所有明确决策（带原话与发言人），
    整理成 Markdown 表格

AI：
  1. get_channel_history #design-review since 14:00
  2. 解析 50 条消息
  3. 输出：
     | 决策 | 原话 | 发言人 | 时间 |
     | 采用方案 B | "方案 B 性价比更高" | @张三 | 14:23 |
     | 推迟发布 | "本周先不发，等 QA" | @李四 | 14:35 |

场景 2：自动周报

你：每周五 17:00，读取我本周参与的所有频道，
    生成周报，发到 #weekly-report

AI（通过定时任务触发）：
  1. list_channels → 找出我活跃的频道
  2. 对每个频道 get_channel_history（本周）
  3. 筛选 @我 的消息 + 我的回复
  4. 生成周报：本周完成 / 进行中 / 阻塞
  5. post_message #weekly-report 周报内容

场景 3：客户支持自动化

你：监听 #support 频道，每条新客户问题：
    1. 查知识库（配合 [RAG](/glossary/2026-08-14-rag)）
    2. 若有答案：reply_in_thread 自动回复
    3. 若无答案：@oncall 工程师介入

AI：
  对每条新消息：
    get_thread_replies → 判断是否已回复
    检索知识库 → 若匹配
      reply_in_thread（带引用来源）
    否则
      post_message "@oncall 请跟进 #support 的这条"

场景 4：跨频道信息聚合

你：今天 #frontend / #backend / #devops 各有什么重要更新？
    汇总成一条简报，私信发给我

AI：
  1. 并发 get_channel_history × 3
  2. 各频道提取 3 条最重要消息
  3. 生成简报：
     【前端】发布 v2.3，修复 5 个 Bug
     【后端】数据库迁移完成，性能提升 20%
     【运维】今晚 22:00 维护，预计 30 分钟
  4. post_message 私信发送

场景 5：决策追溯

你：我们上个月为什么决定弃用 Redux？
AI：
  1. search_messages "Redux" since 30 天前
  2. 找到 #engineering 的 3 条相关讨论
  3. get_thread_replies 看完整讨论
  4. 输出：
     决策时间：7 月 18 日
     发起人：@王五
     原因：性能问题 + 包体积
     反对意见：@赵六认为迁移成本高
     最终结论：迁到 Zustand，2 周完成

与其他 MCP 的协作

组合场景
Slack + Filesystem MCP读 Slack 决策 → 写入本地文档
Slack + GitLab MCP频道讨论 PR → 自动评论到 MR
Slack + Calendar MCP频道约定会议 → 自动建日历邀请
Slack + Memory MCP记住每个成员的沟通偏好

权限管控要点

1. 最小权限

✗ 给 Bot 所有 scope，全工作区可读写
✓ 只给必要 scope，限定到特定频道

在频道设置 → Integrations 中，只把 Bot 加入需要的频道。

2. 发消息审核

✗ AI 自动发消息到 #general → 误操作污染全公司
✓ AI 起草消息，post_message 发到 #drafts（仅自己可见）→ 人工审核后转发

3. 敏感信息过滤

✗ AI 把包含 API key 的对话历史输出
✓ 在 system prompt 加规则：输出前扫描并脱敏 key/token/密码

4. 频道访问控制

Slack Bot 默认只能读它加入的频道。把 Bot 加入 #confidential 等敏感频道前需审批。

注意事项

1. 速率限制

Slack API 有速率限制（Web API 约 1 请求/秒，Tier 3）。批量读历史时需加 sleep：

import time
for channel in channels:
    get_history(channel)
    time.sleep(1)  # 避免限流

2. 消息分页

频道历史一次最多返回 100 条。读 1 个月消息需多次翻页（用 cursor 参数）。

3. 文件附件

get_channel_history 返回消息文本，附件需单独调用 files.info 获取下载链接。配合 Filesystem MCP 可把附件下载到本地。

4. 私信权限

Bot 默认不能读用户间私信。要让 Bot 处理私信，用户需主动 @Bot 或在 App 设置开启 DM 权限。

5. 历史保留期

Slack Free 版消息保留 90 天，Pro 版无限。读 1 年前的消息需确保工作区是 Pro+。

与直接用 Slack API 的区别

维度Slack MCP直接调 API
接入方式自然语言写代码
适合场景探索性任务高频自动化
可组合性强（与其他 MCP）弱
控制粒度中高
开发成本低高

建议：原型与探索用 MCP；上线高频任务用 API（更可控、可监控）。

小结

Slack MCP 把团队消息流变成 AI 可操作的数据源，让 AI 从"被问才答"升级为"主动协作"。

配合 Filesystem MCP 写本地、Memory MCP 记偏好，你能搭出一个"懂你团队"的 AI 助手——它知道你们讨论过什么、决定了什么、谁负责什么，并在合适时机主动提醒。

相关推荐

查看更多 →
MCP网络

Slack MCP：让 LLM 直接读写 Slack 消息、频道与文件的官方服务器

Slack MCP 是 ModelContextProtocol 官方维护的企业协同服务器，通过 Slack Web API 让 LLM 客户端能够发送消息、搜索频道、读取历史记录、上传文件、管理用户列表。无需自建 Slack Bot 轮询逻辑，一条 npx 命令即可让 Claude Code、Cursor、VS Code 等 MCP 客户端变成 Slack 助理。本文梳理核心能力、Bot Token 申请、各客户端配置与实战注意事项。

2026-08-01
#MCP#Slack
MCP编程开发

MCP Resources 实战：让服务端把 8 万行设计文档喂给 Agent，附四套客户端配置与13 行排查表

Tools 是「Agent 问你答」，Resources 是「你问Agent 答」——同一个 MCP Server 里，方向相反的两种能力，而且很多人在写 Server 时只实现了 Tools，漏掉了 Resources。结果是文档、规范、schema、日志这类只读数据只能靠 Agent 一个个调 Tool 去捞，每次捞都要过一次模型判断，成本高还不稳定。本文讲透MCP 四大原语里的第二个：Resources。涵盖 resources/list、resources/read、resources/templates/list 三个方法与 URI 模板机制（RFC 6570 展开规则），以及 Resource 与 Tool 的选型对照（把同一份数据做成 Tool 还是 Resource 的实测差异）。给出一个可运行的「设计文档中心」Server 完整实现（含 40+ 行 TypeScript，含分页、版本快照、访问审计），以及 Claude Code / Cursor / VS Code + Copilot / Trae 四套带中文注释的配置 JSON。三个实战场景：Agent 读设计文档回答「这个接口为什么这么设计」、按版本读取历史 schema 做迁移校验、把资源目录挂进 IDE 侧边栏。另含资源数量膨胀到 500+ 时的分页与 URI 命名规范、五条安全红线（为什么资源 URI 绝不能暴露绝对路径和凭据），以及 13 行故障排查表。

2026-10-13
#MCP#Model Context Protocol
MCP开发

MCP Elicitation 实战：让服务端在缺参数时反向向用户提问——受限 Schema 设计 + 四套客户端配置 + 13 行排查表

写 MCP Server 的人迟早会遇到一个尴尬场景：工具必填参数用户没给，服务端要么猜一个（猜错就出事），要么返回一个干巴巴的「缺少参数 xx」让 Agent 自己去追问（Agent 经常追问得驴唇不对马嘴）。MCP 协议里的 Elicitation 就是为这个场景设计的第三个「反向能力」——服务端可以在执行过程中主动向客户端发起一次提问，由客户端把问题渲染成表单弹给用户，用户填完再回传，全程服务端不需要自己实现任何 UI、不需要存任何凭据。本文讲透它的机制与边界：elicitation/create 请求的完整结构、为什么 requestedSchema 被刻意限制成只支持原始类型（这是安全设计不是能力不足）、用户的三种响应（accept / decline / cancel）各自的语义差异、以及最关键的——为什么不能在 Elicitation 里索取密码和 API Key。含 TypeScript SDK 完整实现（含类型定义与降级路径）、Claude Code / Cursor / VS Code + Copilot / Trae 四套带中文注释的配置、三个实战场景（部署确认 / 缺失参数补全 / 敏感操作二次确认）、与 Sampling / 传统参数校验的选型对比、六条安全注意事项，以及 13 行故障排查表。

2026-10-12
#MCP#Model Context Protocol
MCP开发

MCP Roots 与 Sampling 实战：让服务端主动划边界、反向要推理——四套客户端配置 + 14 行排查表

多数人写 MCP Server 只用到 Resources / Tools / Prompts 三项，Roots 和 Sampling 这两个反向能力基本闲置，结果就是 Server 既不知道自己该在哪干活，也没有推理能力。本文把这两个方向的能力讲透：Roots 是客户端告诉服务端「工作区边界在哪」的机制（URI 列表、roots/list 双向协商、listChanged 动态通知、路径穿越的必修防御），Sampling 是服务端反过来向客户端的 LLM 请求一次推理的机制（服务端不知道任何 API Key，模型由客户端挑、账由客户端付、人可以卡在中间审批）。含 TypeScript SDK 完整实现代码（含 sampling/createMessage 的类型定义与 human-in-the-loop 回调）、Claude Code / Cursor / VS Code + Copilot / Trae 四套带中文注释的配置、三个实战场景（单仓守卫 / 日志归因摘要 / 隐私脱敏代理）、与其他方案的选型对比表、六条安全注意事项，以及 14 行故障排查表。

2026-10-10
#MCP#Model Context Protocol