3 篇博文 含有标签「mattermost」

前两篇文章已经把 Mattermost 放进了 ChatArch 的版图：它是一个自托管实时 Agent 工作间，也是一个和 Slack、飞书心智都不完全一样的 channel / post / thread 系统。接下来真正会遇到的问题是：如果一个 Mattermost thread 里同时有多个 Agent，它们到底共享什么历史？谁能唤醒谁？命令边界在哪里？ChatRSS 又应该接在哪一层？

这篇文章只写成一篇，不拆成系列。全文分成三个大节：第一节讲已经跑通的双账号接入和命令边界；第二节讲 thread、session、history 与 Agent 互相 @ 的规则；第三节讲 ChatRSS 在 TriggerEvent、Router、Action 和 Ledger 层应该承担什么角色。

第一次从飞书切到 Mattermost，最容易卡住的不是“怎么发消息”，而是：我现在到底站在哪一层？这是一个频道、一条帖子、一个 thread，还是一次私聊？

这篇文章专门回答这个问题。我们不讲部署，不讲数据库，也不讲 token；只把 Mattermost 的信息结构、发帖机制、thread 语义，以及它和 Slack、飞书在机器人触发上的差别讲清楚。

如果说 Discourse 更像公开议事厅，ChatBlog 更像阶段性文章，MkDocs 更像项目手册，那么 Mattermost 更接近 ChatArch 目前缺的那一块：一个可以自托管、频道化、支持线程、适合人和 Agent 同处一室的实时工作间。

这篇文章回答三个问题：

1. 为什么我们要维护 Mattermost 这个自托管实时工作间，而不是继续只依赖飞书、Discourse 或 Zulip？
2. Hermes 要怎样接入这个 Mattermost，成为频道里的 Agent，而不是另一个需要人手工转发消息的工具？
3. 像 CC Connect 这类项目接 Slack、未来接 Mattermost，本质上是在接什么？