前两篇文章已经把 Mattermost 放进了 ChatArch 的版图：它是一个自托管实时 Agent 工作间，也是一个和 Slack、飞书心智都不完全一样的 channel / post / thread 系统。接下来真正会遇到的问题是：如果一个 Mattermost thread 里同时有多个 Agent，它们到底共享什么历史？谁能唤醒谁？命令边界在哪里？ChatRSS 又应该接在哪一层？
这篇文章只写成一篇，不拆成系列。全文分成三个大节：第一节讲已经跑通的双账号接入和命令边界；第二节讲 thread、session、history 与 Agent 互相 @ 的规则；第三节讲 ChatRSS 在 TriggerEvent、Router、Action 和 Ledger 层应该承担什么角色。
2026 年 6 月，Tau Ceti 还是一个新仓库。到 7 月 31 日的固定快照，它已经有 932 个 Lean 源文件、171,565 行代码和 1,336 个已合并 PR。在最忙的一天，100 个 PR 进入 main。
如果只看这些数字，Tau Ceti 很容易被概括成“AI 正在复制 Mathlib”。但我把它的五个组织仓库、Worker、review archive 和依赖更新链条全部拉到本地后，发现真正值得研究的并不是 AI 写 Lean 有多快，而是它怎样重组了一座数学库的生产关系：
人类写 roadmap 和 rubric，AI 写代码、修代码、审代码；Lean kernel 与 trusted CI 负责机械裁决；每一次 review 都成为公开数据。
这不是一个更大的 theorem-proving benchmark，而是一套正在运行的 formal-library operating system。
Hermes 不是用一个单一的“多智能体开关”来实现 Multi-Agent，而是把能力拆成几层：Profile 负责长期身份，delegate_task 负责临时并行，Kanban 负责持久协作，Gateway multiplex 负责多入口路由，terminal backend 负责把执行面放到本地、容器、SSH 或云环境。