9 篇博文 含有标签「chatarch」

ChatBlog 已经有一个 Slides 入口，也已经有一篇文章讨论 Patrick Fu 那套更工程化的 Frontend Harness Slides 工作流。那篇文章的重点是：把一套演示文稿做成小型前端 artifact，用 scene / beat / URL state / build / preview / readback 来治理。

这次看的 zarazhangrui/frontend-slides 是另一个互补方向：它不是 React/Vite workbench，也不是一个大而全的 slides 平台，而是一个 AI coding agent skill。它把“做一套好看的 Web Slides”拆成一套可被 Claude Code、Codex、Kimi Code、OpenCode、Gemini CLI 等本地 coding agent 读取和执行的流程：先看内容，再做 3 张视觉 preview，让用户用眼睛选方向，最后生成一个零依赖、固定 16:9、可分享、可导出 PDF 的单 HTML 演示文稿。

前一篇 SMTP 入门 讲的是“SMTP 是什么、邮件怎样发出去、常见平台怎么配置”。这一篇往下一层：如果我们要给自己的服务部署一个 mail service，甚至自建一个能发邮件的服务器，到底要部署哪些东西？

结论先说：自建发信服务不是把 Postfix 跑起来就结束了，而是要同时交付协议链路、域名身份、IP 信誉和运维闭环。

第一次从飞书切到 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，本质上是在接什么？

有些“PPT”打开以后并不是 PowerPoint，也不是 Keynote，而是一个完整的前端应用。

Patrick Fu 的 From Spec to Loop 就是这种形态：演讲页里的 Open slides 进入的是 /talks/from-spec-to-loop/slides/ 下面的网页，URL 可以带 ?scene=1&beat=0，按方向键会推进场景，页面加载的是 Vite 风格的 JS/CSS bundle。换句话说，它不是把网页伪装成 PPT，而是把一套演示文稿当成一个小型前端项目来做。

这篇文章分两部分。

第一部分看 Patrick 这组三个公开项目：它现在做什么、已经做了什么、能做什么。第二部分转到我们自己的目的：以后有一个 idea、调研结论、项目成果或想展示/炫耀的东西时，怎么用一套固定开发流程快速做出类似的互动 Web Slides，并且能持续更新和发布。

很多“AI 编程套餐”看起来都像一个简单问题：多少钱、给多少量、能不能接到我现有的 coding 工具里？ 但千问 AI 平台的 Token Plan 更像一个新的供应侧形态：它不是传统按量 API 余额，也不是单一 IDE 插件会员，而是面向 Claude Code、Codex、Cursor、Qwen Code、Qoder、OpenCode 等工具的 Credits 订阅。

本文的结论很直接：Token Plan 可以接 Codex，也可以作为 OpenAI-compatible API-key 账号接进 CRS；但要把它纳入 ChatArch 的 CRS 运维生态，需要把“Credits 窗口、账号类型、禁用/启用、Key 绑定、用量回读”当成一套独立 Provider 管理，而不是把它粗暴塞进普通 OpenAI OAuth 账号池。

过去一年，很多团队已经不再问“哪个模型更会写代码”，而是在问另一个更产品化的问题：当团队里同时存在人类工程师和一组 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 正在尝试搭建的形态。

SMTP 的全称是 Simple Mail Transfer Protocol，中文通常译作“简单邮件传输协议”。它负责把邮件“发出去”和“转交下去”：从你的应用、邮箱客户端或业务系统出发，经由 SMTP 服务器、DNS/MX 解析和收件方邮件服务器，最终进入对方邮箱系统。