Cactus Comments 是一款独特的开源评论系统，它利用去中心化通讯协议 Matrix 作为后端，这赋予了它超越传统评论组件的巨大潜力——无论是实现网站实时聊天、集成 AI 智能客服，还是作为微博客（Microblog）的内容发布渠道，其扩展性在同类开源项目中都难得一见。 然而，原项目已停止更新，我为其注入了新的活力：不仅修复了原有缺陷，更独立开发了一系列实用新功能（我的分支目前尚未合并到主干）。 经过持续打磨，这个新版本已经相当完善。本文将为你详细介绍我带来的新特性，并提供一份结合新功能的中文安装教程。你可以在我的个人博客上体验。 请注意：为了服务器的稳定，体验前需要注册。因为访客模式可能会对自托管的 Matrix 服务端造成难以预估的压力。 新版 Cactus Comments：都有哪些亮点？ 🚀 核心升级 * 架构更新：重构了构建配置和依赖，现已支持在 Node.js v22+ 环境下进行开发和部署。 🖼️ 媒体功能大升级 1. 安全媒体支持：新增 isAuthenticated 选项，

自托管 Matrix Synapse 服务器为用户提供了去中心化的通信解决方案和可扩展的生态体验，但每一个追求极致体验的部署者，都会面临一个几乎无法调和的“不可能三角”：安全性、隐私性与性能。 * 追求安全性，意味着隐藏服务器 IP、抵御攻击，通常需要 Cloudflare 这样的代理服务。 * 追求隐私性，意味着杜绝任何第三方（即使是 Cloudflare）看到解密后的敏感数据（如密码）。 * 追求网络性能，意味着必须解决跨国网络访问时（尤其在晚高峰）的高延迟和拥堵问题。 传统的单路径架构无法同时满足这三点，当然前提是你需要使用“联邦”。本文将详细阐述一套“双轨制”的终极架构方案，通过优雅的职责分离和网络隔离，完美地解开这个“三元悖论”。这套方案将为您的 Matrix 服务构建一个公共安全入口和一个私密高速通道，将一个简单的自托管服务，提升为一套弹性的、高性能的、安全且私密的专业级通信平台。

构建自定义 Ghost 主题 - 文档 基本概念 * Handlebars 是 Ghost 的模板语言，用于创建模板。 * index.hbs 、 post.hbs 和 package.json 这三个必填文件构成了主题的基本结构。 * 上下文将网站数据与正确的模板连接起来。 * GScan 工具用于验证 Ghost 主题。 模板语言 Ghost 主题使用标准 HTML 、CSS 和 JavaScript 创建，在需要呈现动态数据时使用 Handlebars 表达式， Handlebars 是一种模板语言，因此页面扩展名为 .hbs，该语言将动态数据渲染为静态 HTML 的形式发送到浏览器。 Ghost 还使用了一个名为 express-hbs 的附加库为 Handlebars 添加了一些附加功能，如布局和局部。 基本helper语法

交流群：博客右上角"账号-联系支持服务"，发送邮件获取Matrix房间邀请。 服务器要求 3种需求： 1. 只本地聊天 性能要求：2核2G，25G SSD。 网络要求：可拉取Docker Hub镜像和GitHub仓库。 推荐搭建环境：家庭NAS。 2. 异地使用+少数联邦 性能要求：2核4G，50G SSD。 网络要求：公网IPv4（用内网穿透也行）。可拉取Docker Hub镜像和GitHub仓库。联邦网络需要能访问指定域名。 推荐搭建环境：家庭NAS（具有透明代理环境）或海外VPS。 3. 全球无障碍通信 性能要求：至少2核4G，50G SSD。如果有大房间聊天和保存大量媒体文件的需求，则推荐2T以上 SSD，或者一台独立的数据库服务器和S3存储盘。 网络要求：可访问全球互联网的服务器

花了很多时间解决家庭路由问题。 最一般的用途上，电信运营商提供光猫，光猫兼路由功能，上门安装的师傅包办了，稍微大户一点的家庭，会需要路由器，乃至AP、交换机，这些产品都是出厂配置好了的，照着说明书几步就搞定。 难在想要自定义路由，想要有软件的功能。 我实际需求中得路由器上解决的，包括并不限于： 1. 网络中转和分流 2. 异地组网 3. 网络监控和上网保护 4. 游戏加速器 5. 网络容灾（这个范围很广，例如路由器一级的ddns、内网穿透） 不在路由上解决行不行？可以，但通常更复杂，使用起来更麻烦，也有更多不可预知的故障。举例来说：网络中转和异地组网，这些本质上要接管全局的网关流量，如果不用路由器上的透明化方案，那得在每个设备上都安装客户端（如果有相应软件的话），并且有些功能可能无法使用，例如24小时在线的服务，这很重要，例如家里的NAS服务器掉线了，在外地可以登录到路由器检查情况，并重新唤醒设备。 既然网关上的软件功能必不可少，针对不同的路由拓扑又产生了很多不同的实施方案，这里不探讨各种方案，而是直接给出我认为目前家庭（包括个人）

交流群：博客右上角"账号-联系支持服务"，发送邮件获取Matrix房间邀请。 Matrix 通信网络协议最常用的客户端 Element 过去一直使用免费的 Jitsi 作为群组视频会议组件。一对一音视频通话则相对复杂：如果双方客户端具有公网 IP，则可以建立点对点连接；否则需要通话发起方的服务端托管 TURN 服务来绕过网络地址转换 (NAT)，中继 WebRTC 连接。 现在这一情况已得到改善。Elment.io 开源了原生的 Matrix 视频会议应用程序 element-call。它的优势在于端到端加密、流畅性，以及基于 LiveKit 的可扩展后端；缺点是与 Jitsi 相比功能仍较为简陋，例如缺少背景虚化、主持功能等。 Element Call 客户端组件现已内置于 Element 桌面和网页端，并在新一代移动端 Element X 上作为唯一的通话组件。这意味着从

关于人工智能，有这么一则寓言：一辆加速的列车，一经抵达就远远地把人甩在身后。 幸运的是，列车似乎已经抵达，并没有把人甩在身后。因此，我们只需要回答好三个问题： * 列车是否仍在加速？ * 应该上车吗？ * 怎么上车？ 上一篇文章《构建人工智能应用的底层逻辑》展望了下AI应用的前景，然而现实的反馈是：应用很难落地。这同时指向了上述三个问题。 这篇文章将尝试回答头两个问题，对于第三个问题，也许将来有更多实践分享。 列车是否仍在加速？ 这个问题尚未在技术上得到很好的解答。从历史的角度却很容易找到线索，只需观察两条曲线。 第一条曲线代表了对AI的投资和研究以及能力随时间的变化 A Critical Historic Overview of Artificial Intelligence: Issues, Challenges, Opportunities and Threats InfoQ：2023 中国人工智能成熟度模型报告 中间有波峰和波谷，说明人工智能也有退潮期，如果贸然跟风，也可能踩坑（后面再谈论这个）。但总体

大语言模型是个黑盒，GPT-4 在早期版本中就如真人一般，而大量使用之后又不禁怀疑：它真的理解了对话吗？ AI也许是以我们不同的方式理解，之所以表现相似，是因为神经网络是一种模拟，人脑也是神经网络，正如我们搞不明白人脑怎么冒出意识那样，模型的生成过程也无法解释。 Stephen Wolfram 提出了叫做计算不可约和计算等价性的思想，用在AI上来说，要弄明白为什么模型输出那些内容，就得做不少于它参数量的运算，这就叫不可约，而它输出的结果，人脑也能产生，某种程度上就叫等价，所以至少对于非研究者而言，不必纠结于原理是什么，只需从外部测试这个盒子的能力，重点在于应用。 宇宙中有大把未知的存在，存在即合理，假设我们将存在和可能的存在都当作一种意义，就有了意义空间，从这个出发点可以推断出很多东西。 一点浅见！ 我以为意义是一种主观判定因果关系的方式，例如，小路上散步，一阵小风，不是朝这儿吹就是朝那儿吹，吹到树身上，种子飘到别处生根发芽了，吹到人身上，引起一阵惬意，这就是意义，它们的意义是在人身上体现的，所以： * 意义是一种组合，来源可能并不相干； * 意义是基于判

AI+Workflow是当前比较流行的Agent应用开发方式，本博客之前重点对比了：Dify vs FastGPT两个开源项目，也演示了Coze的案例，本文继续分享这两款产品的开发实践，借此对拖控件编排工作流这种低代码开发方式进行阶段性总结，读者顺便也能体会到它们之间的差异。 特别强调的是，这几款产品迭代得很快，文章仅作参考而非为了评价它们的优劣。同样优秀开源项目还有：bisheng（支持autogen和lanchain）和 ragflow（提供更丰富的RAG方式）等，你如果了解 langchain 的话，它也有 workflow 的开发方式可供选择。 言归正传！ 图形界面仍然是我们大部分用户首选的人机交互方式，例如，下图是我用FastGPT实现的一个下载器前端： 目前AI在实现智能生成UI、自动提参的交互能力上还比较弱，一方面，开发应用需要先对图形界面（GUI）进行布置，这受限于平台自身提供的UI组件；另一方面，AI更广泛的应用场景是作为其他软件的辅助形式，所谓副驾驶，例如代码编辑器中的插件，聊天软件中的机器人，而软件是各自独立的，多数软件接入第三方AI的形式

Matrix很好很强大，一般服务端都用Synapse，支持的协议最完善，然而它的中文搜索很难用，原因在于PostgreSQL未能正确的给中文分词。另一个服务端项目dendrite 支持CJK （中日韩）分词，也只是略好一些，并且那个项目开发也几乎停滞了。 开源IM软件中原生支持中文搜索的有Mattermost，我参考它给Synapse开发了一个方案，具体的做法是 使用 Zhparser 插件版 Postgres，给数据表添加一个字段，改少量Synapse代码。通过文件映射的方式，尽可能减少后期维护成本。

大语言模型问世一年半，出现了越来越多有意思的东西，例如可以在聊天中触发一些UI互动，让大模型使用第三方工具，执行一些自动化工作流，使用低代码开发Agent 代理最近也非常火热，扣子（Coze）是其中优秀的平台，本次，我尝试在coze.cn搭建应用，看看目前主流平台的 AI 智能体开发方式，能不能替代前后端，能不能落地，具体会碰到什么问题？顺便也看看国产大模型表现如何。 我首先想到一种需求，了解开源领域的朋友们都知道，Github是开源项目的主要集中地，我们大抵是通过标星（stars）来关注一个仓库，长时间下来，stars数量已经有几百个乃至上千个之多了，这带来一个问题，我们关注一个项目通常不会细致的研究它的文档和代码，只大致了解了它的用处，过后可能也就忘了。当我们实际需要某种工具时，又常常想不起来，只能借助传统的搜索，包括GitHub自己的搜索功能，这效率有点低，经常就搜不到，因为开源项目的描述和我们关键词并不一定匹配。诚然，现在的大模型基本上都会爬取GitHub上的数据，但实际测试发现，它并不是真的“记住了”什么知识，并不能当作信息搜索引擎来用，要命的是，它还会一本正经的瞎编乱造

在基于大语言模型 API 的生态上，有那么几种类型的应用解决不同的痛点： 1. 使用最广泛的是网页或软件在API上套壳，方便有网络障碍和弹性需要的用户； 2. 检索增强生成（RAG），适用于垂直和私有化数据领域； 3. 结合第三方软件，包括 SaaS 平台、本地工具，扩展模型的能力； 4. 低代码拖控件调度工作流，降低个性化定制的门槛； 5. 统一API接管，应对各家模型如雨后春笋般发布的场景。 而 langgenius/dify 和 labring/FastGPT 将以上功能集于一身，是开源AI项目中的佼佼者，类似的项目还有 Bisheng 和 TaskingAI（国外的新起之秀）等。综合体验下来，我选择 Dify 和 FastGPT 的社区版作为其中代表进行比较， 这两个应用也是我使用最多的，在不同服务器上都部署过，以下评价并非严谨的测试，仅作为主观使用感受总结。 安装和运行环境： Dify

这篇文章写于2024年1月15日，现在分享到博客上来。 我自己也开发过GPT，对话数超过10k，评分4.5，算排名靠近，不过我也早早取消了Plus订阅，改用API了，那对我来说更好用。 GPT是OpenAI推出的定制版ChatGPT，有点类似于微信小程序。定制门槛很低，最简单的直接在聊天框上提需求，构建器会自动帮你创建好，然后还可以分享到商店来赚取收益。 在这篇文章中，我得出几个结论，如果您有不同的看法，欢迎探讨。 1. GPT应用真正能落地的场景很有限 这个结论也同样适用于国内AI平台。 为了理解这点，我们需要回顾一下Prompt和Agent，即提示工程和智能体代理。 简单来说，大语言模型根据前文生成后文，而Prompt就是利用模型的这一特性预设某些提示以规范输出，例如角色扮演，Agent的骨干也是Prompt，通过特殊的提示让模型能够与外部服务及私有数据结合起来，更加垂直化。 提示和代理提供了无限的想象空间，大模型如同压缩了世界知识的宝藏，提示词如同密钥，有什么样的钥匙就能开出什么样的宝石。而代理将自然语言赋予了创造的魔力，如同咒语般从石头