换一个社交应用，为什么往往要重新关注作者、寻找朋友？因为账号、关系和互动记录通常由不同平台分别管理。用户可以迁移到新产品，原有关系却未必能随之迁移。
理解这个问题，需要分清三个层次：社交网络让关系在线上可见，社交知识图谱为关系补充类型和语境，Web3社交则尝试改变部分数据与身份的控制方式。它们并不是必然依次替代的技术阶段。
一、社交网站的起点：把“我认识谁”变成产品
人与人的关系早于互联网存在，Friendster也不是“社交网络”的发明者。boyd与Ellison在2007年的研究中，将社交网站概括为允许用户建立个人档案、展示连接对象，并查看这些连接的网络服务。按这一定义，1997年上线的SixDegrees是早期代表；2002年出现的Friendster则进一步推动了“朋友的朋友”这一连接方式。
它们的重要变化，是让关系本身成为可浏览的产品对象。用户不只发布一条信息，还能看到发布者是谁、与自己有什么连接，再决定是否关注、回应或建立联系。社交网站也不必全部采用实名，更不只服务于线下熟人。
图中，通信互动沉淀内容，内容又引发新的交流，中间是权限控制。重点看这个循环如何持续：讨论形成有用内容，内容让用户有理由再次联系。产品应同时设计回应入口和可见范围；私聊内容并不天然适合公开，建立关系也不代表获得无限触达权。
对增长而言，好友数量只是连接的存量。真正让用户留下的，是连接之后有事可做：共同完成任务、交换经验、获得反馈。仅导入通讯录或推荐好友，不能自动产生这些价值。
二、从关系图到知识图谱：记录连接，也记录含义
最简单的社交图以用户为节点，以关注或好友关系为边。面向具体业务的社交知识图谱，还可以加入内容、组织和活动，并明确它们之间的关系：谁创建了内容，谁参与了项目，谁与谁合作过。
例如，“小王关注小李”“小王阅读课程A”“小李讲授课程A”是三条不同事实，不能统一压缩成“关系亲密”。有了类型和来源，系统才能解释为什么推荐某个人或某项内容。
| 应记录的信息 | 实际作用 |
|---|---|
| 关系类型与方向 | 区分单向关注、双方好友、共同参与 |
| 发生时间与场景 | 区分近期协作与多年未联系 |
| 证据来源 | 区分用户声明、实际行为和模型推测 |
| 可见范围与状态 | 支持私密关系、取消关注、退出组织 |
这不是要求企业收集更多信息，而是避免对已有数据作过度解释。同处一个群不等于互相认识，一次阅读不等于长期兴趣，推荐算法的推测也不能当作已确认事实。
图中用相识、共同活动到关系结束，说明连接会随场景变化。重点是“关系具有时间性”，而不是把五个阶段当成人人必经的流程。产品可据此降低陈旧互动的权重，并支持解除关系；不能仅凭聊天频率判断现实中的亲密程度，更不应由此推断婚恋状态。
落地时，先明确一个需要解决的问题，例如“为新成员找到合适的协作对象”，再选择必要的数据和关系。若普通关系表已经足够查询，就不必为了“知识图谱”这个名称建设庞大的系统。
三、Open Graph：描述网页，不等于打通用户关系
Open Graph protocol容易因名称被误解为一张可自由查询的全球社交图。它实际提供的是网页元数据规范：通过标题、类型、图片、规范地址等字段，让网页能够被描述为社交图中的对象，并支持分享预览等用途。
图中是第三方工具展示的Facebook、WhatsApp与Twitter预览样式。重点看同一链接如何呈现标题、图片和摘要。它对产品的启示是检查分享信息是否清楚一致；这些预览不是用户关系图，也不是实际发布效果的保证，最终展示仍取决于平台支持、抓取和缓存。
配置这些标签，不会自动获得读者身份、好友列表或跨应用点赞记录。“能展示同一张内容卡片”和“能合并同一人的行为”是两种能力，后者需要单独的数据接口、身份关联与适当授权。不能从Open Graph协议推导出用户在一个应用中的点赞必然同步到另一个应用。
因此，分享预览解决内容表达，关系图解决连接记录，知识图谱解决事实之间的语义关联。三者可以协作，但不能互相替代。
四、Web3社交：尝试让身份和关系脱离单一应用
当关系被保存在单一平台内，迁移通常受到接口、格式和产品规则限制。部分Web3社交方案尝试把身份、关注关系或发布记录放到共享协议层，让兼容应用能够复用，减少用户反复建立关系的成本。这里的Web3指区块链相关路线，与“Web 3.0”曾被用于描述语义网的含义应作区分。
图左强调用户访问单一主体控制的服务，图右强调数据由多个节点承载。重点是数据控制与访问路径的差异。产品可以据此思考身份和关系能否被其他应用复用，但这是一张简化示意：传统服务也会分布式部署，Web3应用也可能依赖中心化前端、索引和存储服务。节点变多，不等于每一层都去中心化。
Lens是这一方向的具体案例。其官方当前介绍将账号、社交关系、信息流和群组作为可组合的能力，强调跨应用使用账号，也允许设置发布或成员加入规则。这说明共享基础设施与应用治理可以同时存在。
图中列出44,525个profile、93,335条帖子以及关注、评论等累计指标，展示了协议生态可以怎样被观察。重点是区分账号、内容和关系活动，不能把profile数量直接当成真实活跃人数。该截图的统计日期、口径未核实，只作为历史材料保留，不代表当前规模；图中的收入数据也不能证明普遍盈利或持续增长。
评估这类方案，需要把“可携带”拆开检查：
- **能带走什么？**账号标识、关注关系、内容正文和历史互动可能存储在不同位置，并不一定整体可迁移。
- **谁愿意接入？**另一款应用需要支持协议及相应规则，才能正确读取和展示；保存了一份关系记录，不等于好友会随你迁移。
- **如何恢复和退出？**账号控制、密钥恢复、存储可用性和授权撤回，都影响长期使用。数据可验证不代表内容永久可用，应用仍可能限制展示或访问。
跨平台互通也不必依赖区块链。W3C的ActivityPub提供客户端与服务器、服务器之间的社交通信协议，是另一条技术路线。选择时应比较真正需要的迁移能力、治理方式和维护成本，而不是把“上链”当作增长目标。
对社交产品来说，更实际的起点是把关系类型、数据来源和权限说明白，让用户能理解、管理并在支持的范围内迁移自己的数据。图谱能帮助产品组织关系，持续的服务价值才决定用户愿不愿意继续使用。