前两篇文章已经把 Mattermost 放进了 ChatArch 的版图：它是一个自托管实时 Agent 工作间，也是一个和 Slack、飞书心智都不完全一样的 channel / post / thread 系统。接下来真正会遇到的问题是：如果一个 Mattermost thread 里同时有多个 Agent，它们到底共享什么历史？谁能唤醒谁？命令边界在哪里？ChatRSS 又应该接在哪一层？
这篇文章只写成一篇，不拆成系列。全文分成三个大节：第一节讲已经跑通的双账号接入和命令边界；第二节讲 thread、session、history 与 Agent 互相 @ 的规则；第三节讲 ChatRSS 在 TriggerEvent、Router、Action 和 Ledger 层应该承担什么角色。
这篇文章回答一个具体问题：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。
过去一年，很多团队已经不再问“哪个模型更会写代码”，而是在问另一个更产品化的问题：当团队里同时存在人类工程师和一组 coding agents，谁来分配任务、记录进度、保存上下文、管理运行机器和复用经验？
Multica 的回答不是再造一个 coding agent，而是把 Claude Code、Codex、Hermes、Cursor Agent、OpenCode 等本地 AI coding tools 包成一个协作系统：Agent 出现在 assignee picker 里，issue 会触发 task，runtime 负责 claim 和执行，结果再写回 issue timeline。