前两篇文章已经把 Mattermost 放进了 ChatArch 的版图：它是一个自托管实时 Agent 工作间，也是一个和 Slack、飞书心智都不完全一样的 channel / post / thread 系统。接下来真正会遇到的问题是：如果一个 Mattermost thread 里同时有多个 Agent，它们到底共享什么历史？谁能唤醒谁？命令边界在哪里？ChatRSS 又应该接在哪一层？
这篇文章只写成一篇，不拆成系列。全文分成三个大节：第一节讲已经跑通的双账号接入和命令边界；第二节讲 thread、session、history 与 Agent 互相 @ 的规则；第三节讲 ChatRSS 在 TriggerEvent、Router、Action 和 Ledger 层应该承担什么角色。
如果说 Discourse 更像公开议事厅，ChatBlog 更像阶段性文章，MkDocs 更像项目手册，那么 Mattermost 更接近 ChatArch 目前缺的那一块：一个可以自托管、频道化、支持线程、适合人和 Agent 同处一室的实时工作间。
这篇文章回答三个问题：
这篇文章回答一个具体问题：Codex 里的 Computer Use / bundled skill / plugin 在做什么，Hermes 有没有同类能力，社区有没有正在把这些东西打通的 PR 或 issue？
结论很直接：Hermes 已经把 Computer Use 做成了一个模型无关的 computer_use toolset，底层通过 MCP stdio 连接 cua-driver；Codex 也已经出现了 computer_use feature requirement、bundled plugin / skill 发现路径和桌面端问题单，但它现在更像是围绕 Codex Desktop 与 bundled plugins 演进的一套能力。CUA 社区正在推进一条更通用的路线：让 cua-driver 作为 MCP 层进入 Codex、Claude SDK 和其他 agent harness。
这篇调研回答一个很实际的问题：Hermes 已经能进这么多平台，那我们以后要把 Agent 放到哪里？
上一篇文章讲的是 Hermes 的自定义入口机制：API Server、Inbound Webhooks 和 Hooks。那篇文章偏“机制”。这一篇偏“产品形态”：把 Hermes 当前文档和源码里能确认的 messaging / platform / API / webhook 入口逐个摊开，看它们分别像什么页面、采用什么交互模式、适不适合作为 ChatArch 后续 Agent community 的入口。
过去一年，很多团队已经不再问“哪个模型更会写代码”，而是在问另一个更产品化的问题：当团队里同时存在人类工程师和一组 coding agents，谁来分配任务、记录进度、保存上下文、管理运行机器和复用经验？
Multica 的回答不是再造一个 coding agent，而是把 Claude Code、Codex、Hermes、Cursor Agent、OpenCode 等本地 AI coding tools 包成一个协作系统：Agent 出现在 assignee picker 里，issue 会触发 task，runtime 负责 claim 和执行，结果再写回 issue timeline。
Hermes 不是用一个单一的“多智能体开关”来实现 Multi-Agent，而是把能力拆成几层：Profile 负责长期身份，delegate_task 负责临时并行，Kanban 负责持久协作，Gateway multiplex 负责多入口路由，terminal backend 负责把执行面放到本地、容器、SSH 或云环境。
Hermes SSH Mode 的核心目标，是让同一个 Agent 会话可以在需要时把 terminal、file、code execution 等任务执行面切到远端机器，同时保留清晰的授权边界和会话隔离。