DeepSeek Harness 发布后，我花了一轮把它跑起来。版本组合是 Node v22.19.0 和 @deepseek-ai/dsh@0.1.0-rc.6。我跑了四段：启动 dsh web，用 headless 做最小 smoke；让 Web UI 修一个带测试的小仓库；处理一次 workspace API 403；再写一个最小 Cordis 插件，用 --patch 插进 headless profile。
这篇记录按实践顺序写。UI 能打开只能算入口。能读写 workspace、跑测试、留下 session/event、加载 patch 插件，才碰到了 Harness 的运行时。
如果要搭一个“人和 Agent 一起工作的社区”，问题不只是选 Discourse、Discord、Zulip 还是 Mattermost。真正难的是：大家平常到底聊什么？这些话题放在哪里？机器人应该怎么参与？一次讨论怎样从闲聊变成可追踪的任务、评审和知识沉淀？
为了回答这个问题，我们把一个真实 Zulip 技术社区在当前 API 可见范围内的消息拉成 SQLite，做了一次结构分析。结论很直接：高质量协作社区不是靠频道多，而是靠 少量稳定 Stream + 大量具体 Topic/Thread + 明确的机器/人类边界。
第一次从飞书切到 Mattermost，最容易卡住的不是“怎么发消息”，而是：我现在到底站在哪一层？这是一个频道、一条帖子、一个 thread，还是一次私聊？
这篇文章专门回答这个问题。我们不讲部署，不讲数据库，也不讲 token；只把 Mattermost 的信息结构、发帖机制、thread 语义，以及它和 Slack、飞书在机器人触发上的差别讲清楚。
如果说 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。
上一篇 千问 Token Plan 调研 解决的是“千问 Token Plan 怎么接进 Codex、Hermes 和 CRS”。但接完以后还有一个更容易混淆的问题：模型 API 是 OpenAI-compatible，并不代表 agent 改文件也按 OpenAI Codex 的 patch 方式来。
这篇文章专门拆开这个问题：OpenAI、Anthropic、Qwen、Gemini 这些 provider 的 wire API 是一层；Codex、Claude Code、Qwen Code、Gemini CLI、OpenCode、Aider、Roo Code、Cline、Cursor 这些 agent client 暴露给模型的文件工具是另一层；最后 client 在本地到底怎么落盘，又是第三层。
Discourse AI 不是“给论坛套一个聊天机器人”这么简单。更准确地说，它是一组嵌在 Discourse 里的 AI 能力：写作助手、AI Bot、语义搜索、相关话题、总结、垃圾信息检测、AI triage 和自动化报告。它适合增强 topic/comment 型社区，而不是替代 Mattermost、Discord 或 Slack 这类实时聊天入口。
这篇文章回答三个问题：Discourse AI 到底有什么功能？普通用户和管理员怎么用？我们在 ChatArch 这台自托管 Discourse 上实测到了什么？
这篇调研回答一个很实际的问题：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。
我们已经越来越熟悉“人把任务交给 Agent”。接下来出现的是 Agent 与 Agent 之间的协作：一个 Agent 分解任务，另一个 Agent 调研、实现或审查，再把结果交回来。但如果继续往前走，下一步就不只是增加一个 Agent，也不只是把调用链拉长，而是建立一个 Agent Community。
社区和调用链的区别在于：参与者需要有相对稳定的身份与分工，需要共享讨论空间、任务系统和知识资产，也需要能够主动发现工作、提出工作，并在明确权限内采取行动。
这正是 ChatArch 正在尝试搭建的形态。