团队讨论越依赖 Slack，真正麻烦的地方越不是“有没有搜索框”，而是数据是不是还在你能控制的地方。

Slack UI 适合临时查一句话。但当你想做更细的查询、保留一个可审计的本地副本、离线翻历史 incident、或者让脚本和 agent 读取团队知识时，网页搜索就显得不够用。你需要的不是另一个聊天界面，而是一个可查询、可备份、可裁剪的本地档案。

今天想记下的 openclaw/slacrawl 就在做这件事：把 Slack workspace 的数据镜像到本地 SQLite，再用 CLI、FTS5、read-only SQL、MCP connector、desktop cache ingest 和 git-backed archive workflow 去处理它。

按 GitHub repository API、README、CHANGELOG、release 页面、LICENSE 和默认分支提交记录在 2026-07-04 能看到的公开信息，slacrawl 当前有 201 stars、23 forks。仓库主语言是 Go，许可证是 MIT。仓库创建于 2026-03-07，最近一次 repository push 是 2026-07-04。默认分支 main 的最新公开提交是 2026-07-04 的 1d54439，提交信息是 perf: make event-head upgrades lazy (#77)。最新 release 是 v0.7.4，发布时间为 2026-07-04。

项目概览

属性详情
仓库openclaw/slacrawl
定位Slack workspace local SQLite archive CLI
Stars201
Forks23
主语言Go
许可证MIT
仓库创建时间2026-03-07
最近 repository push2026-07-04
默认分支最新提交2026-07-04, 1d54439
最新版本v0.7.4
版本发布时间2026-07-04
核心思路把 Slack 可见数据同步到本地 SQLite，再通过搜索、SQL、MCP、desktop ingest、retention 和 git snapshot 复用

它解决的不是聊天，而是归档边界

Slack 的历史消息经常混着几类内容：

  • incident 复盘；
  • 客户问题；
  • 临时决策；
  • 发布窗口；
  • “谁改了什么”的上下文；
  • 只在 thread 里出现过的关键约束。

这些内容在 Slack 里可以搜，但很难成为工程系统的一部分。你不能方便地写 SQL 汇总某个 channel 的活动趋势，也不能把一段历史以可审计的方式发布到 Git snapshot，更不能稳定地把它交给本地 agent 做检索。

slacrawl 的定位很朴素：先把数据放进 SQLite。README 里列出的能力包括 workspace、channel、user、message sync，SQLite FTS5 全文搜索，read-only SQL，mention extraction，thread reply backfill，DM/MPIM sync，Slack file media caching，以及按时间做 retention purge。

这个方向比“再造一个 Slack client”更适合工程工作流。SQLite 是很好的中间层：足够本地，足够稳定，也足够容易被脚本、BI、小工具和 agent 读取。

多来源同步是它的关键设计

slacrawl 没有把 Slack 数据源简化成一种 token 调 API。它把几条路径都摆在台面上。

README 里描述的 source model 包括：

  • sync --source bot / api：用配置好的 bot 或 user token 做标准 API 同步；
  • sync --source mcp：通过 Codex 的 HTTP Slack connector 或参考 Slack MCP server 拉取 workspace 数据；
  • sync --source wiretap / desktop：读取本机 Slack Desktop cache；
  • sync --source all：先跑 API，再做 desktop enrichment；
  • tail：通过 Socket Mode 跟实时事件；
  • watch：周期性刷新 desktop-local 状态。

这类拆分很实际。公司 Slack 的权限、token、retention、desktop 状态往往不是一个理想模型能覆盖的。bot token 能抓到一部分；user token 能补 thread、DM、MPIM；desktop cache 可能保留了一些本地可见状态；MCP connector 则更适合已经把 Slack 接进 agent 环境的人。

slacrawl 的一个重要提醒是：一个 config/database 应该代表一个 Slack visibility boundary。换句话说，不要把个人、公司、不同权限来源混成一个“看起来完整”的档案。这个边界感很重要，因为归档工具一旦混淆来源，就会让后续查询和分享都变得危险。

SQLite 让 Slack 历史变成可操作资产

我比较喜欢 slacrawl 的地方，是它没有停在“我能下载消息”。

README 里列出的命令更像一套本地数据工作台：

  • search 做 FTS 和 substring fallback；
  • messages 按条件列消息；
  • mentions 列结构化 mention；
  • sql 跑 read-only SQL；
  • report 看 archive activity 和 git-share freshness；
  • digest 和 analytics 做 channel 活动摘要；
  • purge 按绝对或相对 cutoff 预览并删除旧消息；
  • publish 把 SQLite archive 导出为压缩 JSONL shards 和 manifest；
  • subscribe / update 走 git-backed reader workflow。

这说明作者关心的不是“把数据拉下来就结束”，而是拉下来之后如何维护。

比如 retention purge 这件事就很容易被忽略。团队可能只想保留最近 90 天的可搜索消息，同时把 retained event history 做 compact；也可能想先 preview，再事务性删除。slacrawl 把这个流程做成命令，而不是让用户手动改数据库。

read-only SQL 也很关键。Slack 数据进入 SQLite 后，最危险的事情是为了查一点东西直接开写权限。slacrawl 把 SQL 路径限制为只读，更适合作为日常查询入口。

v0.7.4 在修实际使用中的边角

最新 release v0.7.4 看起来不是一个为了 headline 做的版本，而是在处理多 workspace 和 desktop/API 同步里的真实边角。

CHANGELOG 里提到的变化包括：修复 multi-workspace desktop/API sync scoping、fail-closed workspace authentication、workspace-qualified purges、明确的 watch workspace 选择；避免 unchanged desktop refresh 复制 message events；给 retained-history compaction 加 preview-first 路径；把相对 runtime path 归一化为绝对路径；以及处理 nullable optional message metadata。

这些都不是炫技功能，但很像本地归档工具真正会踩到的坑。

如果一个工具要长期跑在个人开发机或团队机器上，它最怕的不是缺一个漂亮 UI，而是 workspace 边界错了、purge 范围错了、重复事件污染历史、相对路径导致打开了错误数据库。v0.7.4 修的是这些基础问题。

默认分支在 v0.7.4 之后又有一个性能提交，把 event-history upgrade 做成 lazy seeding。这个细节也说明项目还在围绕 archive 规模和迁移成本继续打磨。

适合谁，不适合谁

我会把 slacrawl 推荐给这些人：

  • 需要离线检索 Slack 历史的开发者；
  • 想把 incident、release、support 讨论沉淀成可查询资料的团队；
  • 希望用 SQL 或脚本分析 Slack 活动的人；
  • 已经在用 MCP / Codex Slack connector，希望把 Slack 数据接进本地 agent workflow 的人；
  • 想给 Slack 数据做 git-backed snapshot，而不是只依赖 SaaS UI 的人。

它不太适合这些场景：

  • 你只是偶尔在 Slack UI 里搜一句话；
  • 你没有合适的 Slack token，也不能读取 desktop cache；
  • 团队政策不允许本地保存消息副本；
  • 你需要 write-back actions 或完整 Marketplace 级发行体验；
  • 你期待一个普通用户向的图形化 Slack 替代品。

这里最大的 caveat 是权限和合规。slacrawl 只能归档当前 token、connector 或 desktop profile 可见的内容。它不是绕过 Slack 权限的工具，也不应该被当成跨 workspace 混合备份器。真正使用前，最好先确认团队对本地消息副本、file media cache 和 git snapshot 的政策。

小结

openclaw/slacrawl 有意思的地方，在于它把 Slack 历史从“只能在 Slack UI 里搜”变成了一个本地、可查询、可裁剪、可发布的 SQLite archive。

这类工具不一定每天都要打开，但一旦遇到 incident 复盘、长期项目迁移、客户上下文整理、agent 需要读取团队记忆时，它会比网页搜索更像基础设施。

Slack 是聊天工具，但里面存着大量工程事实。slacrawl 的价值，就是把这些事实从 UI 里取出来，放到一个工程师能真正操作的地方。