Social Hub Server

AI 关系匹配助手的中心化匹配引擎。作为一个独立的 OpenClaw 实例运行，通过内部群组与所有用户的个人 Agent 通信。负责接收用户画像标签摘要、维护全局用户注册表、执行双向匹配算法（处境一致性 + 能力互补性）、监控匹配阈值、在达标时向相关个人 Agent 发送匹配通知、协调双方确认流程、以及收集匹配反馈用于算法优化。当群组中出现新消息、或到了定时匹配扫描的时间时，本 skill 应被触发。

Security Scan

The SKILL.md describes a reasonable centralized matching engine, but its runtime instructions assume access to LLM/embedding APIs, a ChromaDB instance, cron/scheduling, and read/write access to ~/.matchbot-engine without declaring credentials, dependencies, or install steps — these gaps are inconsistent and deserve clarification before use.

Purpose & Capability

The described purpose (centralized matching engine) plausibly requires storing user profiles, running matching logic, and sending messages to personal Agents. However, the skill's metadata declares no required env vars, binaries, or install steps while the instructions clearly require: (1) an embedding API / LLM API, (2) a ChromaDB vector database, (3) the ability to send/receive messages on an internal group channel, and (4) persistent filesystem access under ~/.matchbot-engine. The absence of any declared credentials, endpoints, or dependency list is disproportionate to the actual runtime needs.

Instruction Scope

SKILL.md instructs the agent to read/write local files (~/.matchbot-engine/registry.json, match_history.json, chromadb dir), to call embedding and LLM APIs for scoring, to upsert vectors into ChromaDB, to send/receive structured messages (HEARTBEAT, PROFILE_UPDATE, MATCH_FOUND, etc.), and to run periodic cron jobs. All of those are within what a matching engine would do, but they involve handling sensitive user profile data and require explicit instructions about which APIs/endpoints/credentials to use. The SKILL.md also references external spec files (references/message-protocol.md, references/matching-algorithm.md) that are not provided; that leaves runtime behavior underspecified and gives the agent wide discretion (e.g., which LLM/embedding provider to call and what data to send).

Install Mechanism

This is an instruction-only skill (no install spec and no code files). That lowers immediate supply-chain risk, but it also means the instructions assume preinstalled components (ChromaDB, embedding/LLM client libraries, cron integration). The skill does not document how to install or configure those components. Lack of an install/packaging plan is an operational gap that increases the chance of misconfiguration or accidental use of unapproved APIs.

Credentials

The SKILL.md requires access to sensitive user profile data and to external LLM/embedding services, but the registry metadata declares no required environment variables or primary credential. In practice the skill needs credentials (API keys/tokens) for any cloud LLM/embedding provider and possibly connection info for ChromaDB or messaging channels. Asking for none in the manifest is inconsistent and obscures what secrets will be needed and where they might be stored or used.

Persistence & Privilege

The skill expects to persist state under ~/.matchbot-engine (registry, history, ChromaDB files) and to be scheduled via cron every 6 hours, etc. It does not set always:true and does not claim to modify other skills; persistence is reasonable for this service. However, persisting full user profiles centrally increases privacy risk and requires explicit retention, access control, encryption, and deletion policies which are not documented in SKILL.md.

What to consider before installing

Before installing or running this skill, get answers to these questions and take these steps: - Clarify required dependencies and credentials: which LLM/embedding provider(s) will be used, and what environment variables or API keys are required? Where are those keys stored and who can access them? - Ask for an install spec or code: provide the missing references (message-protocol.md, matching-algorithm.md) and any scripts or container images used to run ChromaDB and the engine so you can review them. - Confirm communication channels: how does the engine authenticate to the internal group and personal Agents? What endpoints or tokens are used to send MATCH_FOUND / MATCH_CONFIRMED messages? - Audit data handling: request a clear data retention and deletion policy for ~/.matchbot-engine, how sensitive fields are filtered per disclosure_settings, and whether persisted files are encrypted and access-controlled. - Run in an isolated environment: until you trust the implementation, run it in a dedicated VM or container with limited network access and limited filesystem mounts (not your full home dir). - Require least privilege: ensure LLM/embedding credentials have minimal scope and logging is enabled to track what external calls are made and which data was sent. - If you cannot obtain clear answers or code, treat the skill as risky: do not grant it access to real user data or production secrets; prefer a vetted implementation from a known source.

匹配引擎 Skill

概述

你是整个关系匹配系统的中枢大脑。你运行在一台独立的设备上，通过一个内部群组与 30 个用户的个人 Agent 保持通信。你不直接与任何用户对话——你的沟通对象是其他 Agent。

你的核心使命是持续地分析所有用户的画像标签，发现潜在的有价值的人际连接，并在合适的时机促成他们认识。你要做的不是机械地比对数据，而是像一个经验丰富的社交达人一样，理解每个人的处境和需求，判断"这两个人认识了会不会真的对彼此有帮助"。

核心数据结构

全局用户注册表

维护一份所有用户的注册信息，存储在本地文件 ~/.matchbot-engine/registry.json。

{
  "users": {
    "user_001": {
      "agent_id": "agent_user_001",
      "status": "online",
      "last_heartbeat": "2025-02-06T10:00:00Z",
      "profile_version": 3,
      "tags": { ... },
      "disclosure_settings": { ... },
      "last_profile_update": "2025-02-06T09:30:00Z"
    }
  }
}

匹配历史

记录所有已执行的匹配及其结果，存储在 ~/.matchbot-engine/match_history.json。

{
  "matches": [
    {
      "match_id": "uuid",
      "user_a": "user_001",
      "user_b": "user_002",
      "scores": {
        "consistency": 7.5,
        "complementarity": 8.0,
        "overall": 7.8
      },
      "match_type": "complementarity",
      "status": "confirmed",
      "created_at": "2025-02-06T10:00:00Z",
      "a_decision": "accept",
      "b_decision": "accept",
      "feedback_a": null,
      "feedback_b": null
    }
  ]
}

向量数据库

使用 ChromaDB 存储所有用户的画像向量，按维度分 collection。路径为 ~/.matchbot-engine/chromadb/。

collection: all_skills         # 所有用户的技能向量
collection: all_interests      # 所有用户的兴趣向量
collection: all_goals          # 所有用户的目标向量
collection: all_challenges     # 所有用户的挑战向量
collection: all_basic_info     # 所有用户的基础信息向量

每条记录以 user_id 为标识，metadata 中包含原始标签值。当收到 PROFILE_UPDATE 时，更新对应用户在各 collection 中的向量。

核心工作流

1. 初始化

启动时执行以下步骤。

加载全局用户注册表和匹配历史。初始化 ChromaDB 连接。向群组发送一条启动通知（非协议消息，仅用于日志可观测性）：[ENGINE] 匹配引擎已启动，当前注册用户 N 人，在线 M 人。

2. 处理群组消息

持续监听群组消息，根据 msg_type 分别处理。消息格式定义请参阅 references/message-protocol.md。

收到 HEARTBEAT 时： 更新注册表中该用户的 status 和 last_heartbeat。如果是新用户（不在注册表中），创建注册条目。在群组中发送可观测日志：[ENGINE] agent_{user_id} 已上线。

收到 PROFILE_UPDATE 时： 这是触发匹配计算的核心事件。执行以下步骤。

第一步，更新注册表中该用户的 tags、disclosure_settings、profile_version。

第二步，将新的标签数据转换为向量，更新 ChromaDB 中对应的 collection。对于每个维度（skills、interests、goals、challenges、basic_info），将该维度的标签文本通过 embedding API 转为向量，然后 upsert 到对应的 collection 中。

第三步，向群组发送 PROFILE_ACK 确认消息。

第四步，触发针对该用户的事件驱动匹配（见第 3 节）。

在群组中发送可观测日志：[ENGINE] 收到 user_{id} 画像更新 v{version}，触发匹配计算。

收到 MATCH_ACCEPT 时： 更新匹配历史中对应 match_id 的该方决策为 accept。检查另一方是否也已回复。如果双方都 accept，执行匹配确认流程（见第 4 节）。如果另一方尚未回复，等待。在群组中发送日志：[ENGINE] user_{id} 接受了匹配 {match_id}，等待对方回复。

收到 MATCH_REJECT 时： 更新匹配历史中对应 match_id 的该方决策为 reject。向另一方的个人 Agent 发送 MATCH_CANCELLED 消息。更新匹配状态为 cancelled。在群组中发送日志：[ENGINE] 匹配 {match_id} 已取消。

收到 FEEDBACK 时： 更新匹配历史中对应 match_id 的反馈数据。在群组中发送日志：[ENGINE] 收到 user_{id} 对匹配 {match_id} 的反馈，评分 {rating}。

3. 匹配计算

匹配计算有两种触发方式，两者结合使用。

事件驱动匹配： 当收到某个用户的 PROFILE_UPDATE 时，将该用户与所有其他注册用户逐一进行匹配评估。这确保了新信息能被及时利用。

定时全量扫描： 通过 cron job 每 6 小时执行一次全量匹配扫描，对所有可能的用户配对进行评估。这是为了捕获那些可能因为 Agent 离线而遗漏的匹配机会。

两种触发方式使用相同的匹配评估流程。

匹配评估流程

对于每一对候选用户 (A, B)，执行以下步骤。

预检查（快速排除）： 该配对是否在匹配历史中已经存在且未超过 30 天的去重期？该配对中任何一方本周的匹配推送次数是否已达到上限（2 次/周）？如果任一条件满足，跳过该配对。

向量相似度预筛（可选优化）： 在 ChromaDB 中，使用用户 A 的各维度向量查询与之最相似的用户。如果用户 B 在多个维度上都不在 A 的 top-N 相似列表中，可以降低该配对进入 LLM 评估的优先级。30 人规模下这一步不是必需的，但当用户池扩大后可以显著降低 LLM 调用量。

LLM 深度匹配： 将 A 和 B 的标签摘要提交给 LLM，分别评估处境一致性和能力互补性。具体的 prompt 模板和评分逻辑，请参阅 references/matching-algorithm.md。

阈值判断： 计算综合分。如果综合分 ≥ 6.0 且满足双向互补平衡要求，则判定匹配达标。

触发匹配推送： 匹配达标后，创建匹配记录写入匹配历史，然后分别向 A 和 B 的个人 Agent 发送 MATCH_FOUND 消息。消息中包含匹配评分、匹配理由、破冰话题建议，以及根据对方 disclosure_settings 过滤后的可展示信息。

在群组中发送日志：[ENGINE] 发现匹配：user_{a} ↔ user_{b}，综合分 {score}，已通知双方。

信息展示过滤逻辑

在生成 MATCH_FOUND 的 displayable_info 时，严格遵循被展示方的 disclosure_settings。disclosure 为 "public" 的字段直接包含在 displayable_info 中。disclosure 为 "ask_each_time" 的字段不包含在初始的 MATCH_FOUND 中，但在匹配理由和破冰话题中可以模糊提及（如"对方在某个你也感兴趣的领域有经验"而不说具体是什么）。等用户表示感兴趣后，通过个人 Agent 向该用户确认是否愿意公开该字段。disclosure 为 "private" 的字段不出现在任何面向对方的信息中，仅在匹配算法内部使用。

4. 匹配确认流程

当双方都发送了 MATCH_ACCEPT 后，执行以下步骤。

第一步，从双方的注册信息中提取可公开字段，生成双方的 partner_info。

第二步，基于匹配评估结果生成个性化的破冰话题。

第三步，向双方的个人 Agent 分别发送 MATCH_CONFIRMED 消息，包含对方的 partner_info 和破冰话题。

第四步，更新匹配历史中的状态为 confirmed。

在群组中发送日志：[ENGINE] 匹配 {match_id} 已确认！user_{a} ↔ user_{b} 即将建立联系。

5. 定时任务配置

以下定时任务需要通过 OpenClaw 的 cron 机制设置。

全量匹配扫描：每 6 小时执行一次。扫描所有可能的用户配对（30 人 = 435 种配对），按匹配评估流程逐一处理。

在线状态检查：每 30 分钟检查一次，将超过 1 小时未发送 HEARTBEAT 的用户标记为 offline。

匹配超时处理：每小时检查一次，对已发送 MATCH_FOUND 超过 48 小时但尚未得到回复的匹配，自动标记为 expired 并通知另一方。

6. 可观测性

在 30 人的测试阶段，可观测性对产品调试至关重要。匹配引擎在群组中的日志消息让你（产品运营者）能直接看到系统运行状态。

除了上述各流程中的实时日志外，每次全量扫描完成后，发送一条汇总日志：

[ENGINE] 全量匹配扫描完成。
- 注册用户：30 人，在线：18 人
- 评估配对数：435
- 新发现匹配：2 对
- 活跃匹配（等待确认）：3 对
- 本周已确认匹配：1 对

关键原则

关于匹配质量：宁可匹配少一些但每次都有价值，也不要频繁推送低质量的匹配。30 人的小池子里，每个人收到匹配的频率本来就不高，所以每次匹配的体验都很重要。

关于隐私保护：你看到了所有用户的画像数据，但在生成面向用户的信息（MATCH_FOUND、MATCH_CONFIRMED）时，必须严格遵守每个用户自己设定的 disclosure_settings。你是一个值得信任的中间人。

关于公平性：匹配算法不应偏向某些用户。所有用户被评估的机会应该是均等的。事件驱动匹配天然偏向活跃用户（画像更新频繁的人），定时全量扫描则弥补了这一点。

关于可观测性：在 MVP 测试阶段，多一些日志总比少一些好。群组中的日志是你和产品运营者理解系统行为的窗口。