很多“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 账号池。
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。
准备给 ChatRSS 发 minor 版本之前，最好先把它依赖的两个概念讲清楚：RSS 是什么，以及 RSSHub 为什么重要。ChatRSS 不是要重做 RSSHub，而是把 RSSHub 已经生成的 feed 进一步变成 Agent 和团队可以处理的任务流。
我们已经越来越熟悉“人把任务交给 Agent”。接下来出现的是 Agent 与 Agent 之间的协作：一个 Agent 分解任务，另一个 Agent 调研、实现或审查，再把结果交回来。但如果继续往前走，下一步就不只是增加一个 Agent，也不只是把调用链拉长，而是建立一个 Agent Community。
社区和调用链的区别在于：参与者需要有相对稳定的身份与分工，需要共享讨论空间、任务系统和知识资产，也需要能够主动发现工作、提出工作，并在明确权限内采取行动。
这正是 ChatArch 正在尝试搭建的形态。
“文件分享”至少有三种完全不同的产品：一种把 目录/文件名 直接变成 URL；一种上传后生成高熵临时链接；还有一种提供 S3 bucket/object API，接近七牛、MinIO 和对象存储。
如果不先把这三类分开，很容易一边比较极简文件服务器，一边又把完整 Web 产品和分布式对象存储拉进来，最后得到一个没有决策价值的功能总表。
这篇围绕 ChatShare 的第一阶段目标做静态调研：一个共享 Key、上传/下载 API、文件名或 object key 与 URL 明确关联、尽量轻量、不把账号体系和存储集群提前塞进来。
上一篇我们做的是新闻核验：OpenAI 最近公开的 Astra 十项数学结果，究竟是不是“新模型解决了十道著名数学题”。结论是：事情基本属实，但流行说法太粗糙。
这篇换一个问题：如果不看标题党，这十个问题本身到底在研究什么？
它们横跨高维几何、编码理论、群论、算子代数、代数复杂性、量子信息、格算法、凸几何和极值组合。读者很容易只记住“十个难题”，却不知道每一项究竟难在哪里、研究史卡在什么地方、Astra 到底推进了哪一层。
所以这篇是总览：把此前十份专题调研压成一篇大博客，每一项都给一个相对完整的概要。
2025 年 10 月，OpenAI 曾闹过一次很难看的数学误报：公司高管把 GPT-5 找到十道 Erdős 问题的既有文献解答，说成了“解决十道此前未解的问题”。数学家 Thomas Bloom 当时称这是 “a dramatic misrepresentation”，相关帖子随后被删除。
不到一年后，OpenAI 又带着“十道开放问题”回来了。
这一次，材料完全不同：一份 249 页技术文稿、一份 62 页思路说明、十个大型 Lean 文件、十二组 Comparator challenge，以及 OpenAI 对正确性的公开责任声明。产生论证的模型叫 Astra，是 OpenAI 尚未发布的下一代内部模型。
如果这些结果经受住外部审查，这会是 AI 数学从“偶尔参与一篇论文”跨向“同一个通用系统批量产生研究级新数学”的重要节点。
但新闻标题“新模型解决十道著名数学题”仍然漏掉了几乎所有关键限定。
上一篇文章回答了“哪种知乎 CLI 自动化架构更稳”：内容和任务放在控制面，平台登录态留在可信浏览器，默认只写草稿，最后由人确认发布。
这一次不再停留在架构图。我们真的启动了一个隔离 Chrome Profile，完成知乎登录，让 Wechatsync 扩展连接本机 CLI，把 Markdown、本地图片、公式、表格和代码写进知乎草稿，并从编辑页回读验证结果。