Joe的博客

引言：多模组群组服服主的终极噩梦 作为一个经营着多版本、多模组（Mod）服务器群组的服主，我长期以来都被一个架构问题所困扰：如何在保证兼容性的前提下，实现统一入口？ 我的服务器群组非常复杂：既有 1.7.10 的GTNH，也有 1.12.2 的主线周目，更少不了1.18.2的机械动力服务器，还有 1.20.1 的原版生存服。我想将服务器使用单一IP做统一管理，传统的解决方案是使用 Velocity 搭建一个适配模组服的群组网络。 但这种方案对于“重度模组服”来说简直是灾难： 大厅的兼容性地狱：你需要一个兼容多版本的“大厅服”作为中转站。但是，一个挂载了 200 个 Mod 的客户端，往往无法连接到一个纯净的大厅（会发生各种兼容性问题）。 强制的二次跳转：玩家必须先连上大厅，再跨服。这不仅增加了连接耗时，还容易在跨服时的握手阶段发生崩溃。 多 IP 的无奈：最终，我不得不给每个子服分配不同的端口甚至 IP，让玩家自己在客户端里手动添加。这完全破坏了“一个服务器群组”的整体感。 我也曾尝试自行开发反向代理，但 Minecraft 原生协议（TCP） 在握手阶段提供的信息太少了——它几乎只有

引言：为什么要重新造轮子？ 核心痛点：为什么现在的机器人像个“复读机”？ 最近我想搭建一个QQ机器人来活跃个人群的气氛。试过许多市面上开源的框架，效果大多差强人意。它们普遍存在以下问题： 说话不自然：机械感重，缺乏“人味儿”。 句式匮乏：回复总是采用相似的模版。 过度拟合：过分依赖聊天记录中已有的表达，容易被群友带偏，变成无意义的“捧哏”。 缺乏上下文：无法理解话题的来龙去脉，只能对最新的一句话做反应。 我认为，产生这种状况的根本原因在于缺乏多轮对话的引导机制。 大模型接收的文本往往局限于截取的一小段聊天记录，而真实群聊中，一个话题的跨度可能远超截取范围。AI 既不知道话题从何而起，也容易受到冗长、没头没尾且充满噪声的聊天记录影响。在这种环境下，AI 很容易“学坏”，模仿群友的破碎语言。即使你写了 Prompt 要求“不要复制已有的发言”，在庞大的上下文噪声面前，这条规则也很容易失效。 架构思路：怎么做？ 为了解决上述问题，我设想了一个分层架构，将机器人的思维过程解耦。机器人的大脑被分为三层：上下文处理层、兴趣度分析层、回答层。 注：本文仅讨论机器人程序的内部逻辑架构，不涉及协议端（如

试想这样一个场景：我拥有多台服务器，但这些服务器均没有公网 IP 地址。为此，我租用了一些具备公网 IP 的服务器作为跳板，通过运行 Frp 将内网服务器代理至公网，从而构建起一个由多个节点组成的 FRP 网络。 然而，现有的 FRP 网络在实际运维中有一个明显痛点：每当我需要在这个网络中增加或删除设备，或是调整端口映射时，都必须登录对应的 frpc 节点，手动修改配置文件并重启 frpc 进程。这一过程不仅繁琐，而且在节点数量增多时显得效率低下。 鉴于内网服务器通常具备较高的性能，我们可以借鉴即时通讯系统的设计思想，构建一套统一的管理体系，通过一个监控进程来集中管理整个 FRP 网络，从而避免因网络结构变动而频繁在多台服务器间进行配置操作。 我将该项目命名为 UFM（Union of FRP Manager）。系统整体分为服务端与客户端两部分： 服务端（UFMS）：提供 Web 管理界面，用于管理跳板机与内网服务器之间的端口映射关系。用户可通过该界面添加正在运行的 frps 或 UFMC 节点，动态调整 FRP 网络中的端口设置，并向客户端下达管理指令。 客户端（UFMC）：运行于内

#我完成了博客系统了！ ##我可以使用markdown来写博客了，后续会在这里写很多的碎碎念 博客可以从外部预览，不过外部预览的效果会删除所有的markdown格式，比较像浏览器（笑） 比较懒，也没有写日记的习惯，更新大概会比较慢吧 有任何有意思的想法都会来分享的！毕竟有一个赛博日记本一直是我的梦想之一 顺便测试一下网页摘要的功能是否完整 如果我写的东西过多，我不知道会不会被隐藏起来 试试看吧 柳林镇有个六号楼， 刘老六住在六号楼。 有一天， 来了牛老六，牵了六只猴； 来了侯老六，拉了六头牛； 来了仇老六，提了六篓油； 来了尤老六，背了六匹绸。 牛老六侯老六仇老六尤老六， 住上刘老六的六号楼， 半夜里，牛抵猴，猴斗牛， 撞倒了仇老六的油， 油坏了尤老六的绸。 牛老六帮仇老六收起油， 侯老六帮尤老六洗掉绸上油， 拴好牛，看好猴， 一同上楼去喝酒。