什么是Social Hub Server
Social Hub Server 可以理解为一套 AI 关系匹配系统里的“中枢引擎”。它本身不是面向终端用户的聊天工具，而是作为独立的 OpenClaw 实例运行，通过内部群组与每个用户的个人 Agent 通信，统一接收各类画像摘要、维护全局用户注册表，并决定什么时候该把两个人推到彼此面前。它处理的是 Agent 与 Agent 之间的协作，因此更像后台调度与决策层，而不是一个前台社交界面。
这套引擎关注的也不是简单的标签重合，而是更接近“关系撮合”的判断：一方面看双方是否处在相似的阶段、目标或挑战中，另一方面看彼此能力是否能形成互补。系统会保存用户注册信息、匹配历史，并将画像按技能、兴趣、目标、挑战、基础信息等维度写入 ChromaDB 的不同 collection，在画像更新时同步刷新向量数据。随后，它会结合向量预筛和 LLM 深度评估，计算处境一致性、能力互补性与综合分，达到阈值后才向双方的个人 Agent 发送匹配通知。
从整体机制看，Social Hub Server 不是一次性跑完的批处理工具，而是持续运转的匹配服务。它既会在收到 PROFILE_UPDATE 这类事件时立即针对相关用户重新评估，也会按 6 小时一次的节奏做全量扫描，避免因为用户离线或更新不频繁而错过潜在连接。同时它还负责后续确认流程、超时处理、在线状态更新以及反馈回收，把“发现匹配—双方同意—建立联系—收集评价”串成一个闭环。对于想验证 AI 辅助社交、关系推荐或小规模人脉撮合产品的人来说，这个组件的定位非常明确：它就是整个匹配逻辑的执行核心。
核心功能特点
- 以全局注册表和匹配历史为基础，统一管理用户状态、画像版本、过往匹配结果与反馈数据。
- 采用“事件驱动 + 定时全量扫描”双机制：用户画像一更新就触发评估，同时每 6 小时补做一次全池扫描。
- 匹配逻辑不是只看相似度，而是同时评估处境一致性、能力互补性和综合分，并设置达标阈值。
- 引入去重期、每周推送上限、48 小时超时处理等约束，减少重复打扰和低质量推荐。
- 严格按 disclosure_settings 过滤展示信息，私密字段仅用于算法内部，不直接暴露给对方。
适用场景
它最适合用在“小而精”的 AI 社交或关系连接场景里，尤其是用户规模还不大、但希望每次推荐都尽量有价值的时候。证据包里的设计就是围绕约 30 名用户的测试环境展开：这个规模下，系统既能保存较完整的全局视图，也能通过可观测日志让运营者直接看清匹配引擎何时启动、谁更新了画像、哪些配对被评估、最终发现了多少新匹配。对于还处在 MVP 验证阶段的产品，这种透明度很重要，因为团队不只是要“有结果”，还要知道结果是怎么来的。
如果你的产品里每个用户都对应一个个人 Agent，而真正的推荐动作需要由中心服务统一判断，Social Hub Server 的结构就很贴切。它会监听 HEARTBEAT、PROFILE_UPDATE、MATCH_ACCEPT、MATCH_REJECT、FEEDBACK 等消息，在用户不直接接触引擎的前提下，完成用户上线状态维护、画像更新确认、匹配结果投递和双方确认协调。换句话说，它适合那种“前台由个人 Agent 负责陪伴与交互，后台由中央引擎负责公平匹配”的多 Agent 系统，而不是单纯做一个联系人列表或静态标签检索。
它也适合那些对隐私边界和推荐节奏比较敏感的场景。系统在向双方发送 MATCH_FOUND 或 MATCH_CONFIRMED 时，会按对方设置的 disclosure 级别过滤可展示信息：公开字段可以直接展示，需要逐次确认的字段只做模糊提示，私密字段则完全不面向对方暴露。这使它更适合职业互助、学习同伴、目标协作、困难互助这类既希望建立连接、又不愿过早公开完整画像的信息密集型场景。再加上系统会回收匹配反馈、控制每周推送上限、避免 30 天内重复配对，它尤其适合强调“少推但要准”的关系推荐产品，而不是追求高频刷新的泛内容分发系统。