碳基智读完需要7分钟速读仅需 3 分钟最近试用了下前一阵爆火的 AI 社交应用 Elys，感觉想法挺有意思，值得写一篇文章简单聊下。

        Elys 的核心玩法是，通过你前期的元输入和持续的调整，加上你的声音，创建一个你的赛博分身，让它 24 小时不间断替你社交：帮你浏览帖子、点赞、评论、筛选值得认识的人，只在“关键时刻”把对话交回给你。

        看起来很 fancy。它试图解决的真实痛点是：人与人之间的连接成本太高，所以让 AI 替你做「试探」这一步，逻辑上成立。

        但当前用下来的问题也很明显，AI 帮你开了门，门后面却没有足够好的东西留住你——我裤子都脱了，就这？

           1市面上大多数“AI 社交”做的事情是：在现有社交产品里加 AI 功能，比如 AI 生成回复建议、AI 推荐好友、AI 生成动态。

        Elys 的选择更激进：直接让 AI 成为你的代理人，替你完成社交行为的前半段。

        前者是社交+AI，后者是 AI 社交。AI 是主语，不是定语。

        传统社交产品的核心资产是关系链，你的好友、你的对话历史、你的社交图谱。

        Elys 赌的是另一个东西：Context（你的人格画像）。

        它认为，如果 AI 足够了解你，它就能替你建立比你自己手动社交更高质量的连接。

        创始人 Tristan 说了一句被反复引用的金句，我觉得很带感：一个人的灵魂，就是他所有 Context 的总和。

        如果 AI 能积累足够多、足够准、足够结构化的关于你的信息，它就能在某种程度上“成为你”，或者，至少能替你做一些不需要你亲自出面的事情。

           2Elys 围绕这个假设搭了三层系统：最底层是记忆飞轮。

        虽然 Elys 的技术实现强依赖底层基模的能力，但实际上更关键的环节是它围绕大模型构建的 Context 系统。

        它的记忆系统有 128 个槽位，每次对话取 32 个。

        架构大致长这样：用户的所有行为和输入👇结构化为 128 个记忆槽位👇每次分身要做决策时，小模型从 128 个里筛选最相关的 32 个👇这 32 个记忆作为上下文，传给大模型👇大模型基于这些上下文做出判断和生成这些槽位存的是你在产品里所有行为的结构化总和。

        你发了什么帖子、评论了什么内容、对分身的哪些行为点了认可、哪些行为你人工撤回了。

        Tristan 管这叫“被动记忆”和“主动记忆”的区别：传统的 RAG 是你问啥它检索啥，属于被动；Elys 的记忆系统会主动调用你可能需要但你没问的信息。

        举个 Tristan 自己给的例子：你说“好想吃火锅”，分身会拦住你说“你之前说过要练腹肌”。

        传统 RAG 根本不会把火锅和腹肌关联起来，因为两个词的向量距离隔了十万八千里。

        但 Elys 的记忆系统能做到，因为它训练了一个专门的小模型来完成 128 选 32 这个任务。

        中间层是基于 LLM 的推荐系统。传统社交产品的推荐是低维标签匹配，同城、同年龄段、同兴趣标签，刷到一个人先看身高体重，不合适直接划走。

        Elys 想做的是高维匹配：把两个人各自百万 Token 级别的 Context 对撞，看灵魂层面合不合拍。

        理想状态下，每个人发一条帖子，全网每个人的分身都用 LLM 看一遍。

        现实做不到，只能靠 LLM 和传统推荐的混合系统来近似。

        最上层是赛博分身。你花大约两小时完成一个灵魂塑造流程，捏脸、录声音、回答一堆关于自己的问题、调三个滑块（夸夸↔锐评、正经↔抽象、高冷↔显眼）。

        然后你的分身就上线了。它 24 小时替你浏览、点赞、评论、社交。

        你醒来打开 App，看到分身替你互动了几十条内容，你可以一键认可觉得不错的，撤回觉得不合适的。

        这三层环环相扣。你每次认可分身的言论，就生成一条新的记忆进入槽位；槽位越丰富，分身越像你；分身越像你，它帮你连接到的人质量越高；连接质量越高，你越愿意继续用。

        这就是所谓的 Context 飞轮。在纸面上，这个飞轮无懈可击。

           3读到这里，其实懂不懂技术的朋友应该都能看出一些问题了。

        现实情况是，这对模型能力的要求极高。创始人自己也坦承，长链路 Agent 系统里，每一步 80%的正确率串联起来，最终结果就是崩溃。

        每一步的成功率需要逼近 100%，而当前的模型还差得远。

        Elys 所有产品体验上的问题，追根究底都是同一个问题——大模型的能力还不够。

        它现在的窘境也是这个原因，大模型能力够了，你的优势在哪？

        大模型能力不够，你的体验又在哪？Context 飞轮的转速，受限于大模型的实际能力。

        理论上飞轮越转越准，但现阶段的模型还撑不住越转越准这个预期。

        每一个体验问题背后，都是一个现阶段难以解决的技术问题。

        评论套路化：模型的生成多样性不足，在固定 Context 下倾向于生成相似输出。

        分身偶尔人设崩塌：128 个记忆槽位在压缩/合并/提取过程中信息丢失。

        关系浅层化：跨会话的关系记忆难以持续，模型对关系演进的理解能力有限。

        信息过载：匹配算法的精度不够，无法从你可能感兴趣精确到你真正想认识。

        与此同时，每个用户的分身都是 24 小时在线的 Agent——浏览、判断、互动、更新记忆。

        这意味着：每个活跃用户都在持续消耗推理资源记忆系统的每次读写都需要模型参与随着用户增长，计算成本是超线性增长的这也解释了为什么几个月过去了，Elys 还在用邀请码做内测，成本真遭不住。

           4Elys 在技术上最值得讲的一点，我觉得是把 Karpathy 那套 Context Engineering 理论给具象化并用在了 AI 社交方向。

        从 Prompt Engineering 到 Context Engineering，方向是对的，也是 AI 产品未来的一个趋势所在。

        Prompt Engineering 的逻辑是这样的：你是用户，你得学会怎么跟 AI 说话。

        提示词写得好，AI 给你好结果；写得烂，AI 给你垃圾。

        Context Engineering 反过来了：系统在后台默默收集、整理、筛选、压缩信息，在 AI 执行每一步之前，把它最需要知道的东西准备好。

        你该干嘛干嘛，脏活累活系统干。LangChain 的 Lance Martin 把这套方法论拆成了四个策略，我觉得是目前最清晰的框架。

        第一个策略叫写入。AI 在执行复杂任务的过程中，会生成大量中间信息。

        把这些信息保存到上下文窗口之外，等需要的时候再调回来。

        最典型的就是 Manus 的做法：它在处理任务时会创建一个 todo.md 文件，每完成一步就更新一次，把全局计划反复复述到上下文末尾。

        第二个策略叫选择。别什么信息都往里塞，只挑当前最需要的。

        这里面又分好几层。最简单的是固定文件始终加载，比如 Claude Code 的 CLAUDE.md 文件，每次启动自动读取你的项目规范。

        复杂一点的是用向量检索（也就是 RAG）按语义相似度匹配，再复杂就是知识图谱。

        Mem0 的 2026 年报告给了一组对比数据：纯向量检索只能告诉 AI“该用户提到过 Python”，图记忆能推理出“该用户在 XX 公司用 Python 做数据管道，正在从 Spark 迁移到 dbt”。

        信息密度差了一个量级。第三个策略叫压缩。上下文窗口再大也是有限的，长时间运行的 Agent 动不动就几万 token 的对话历史，必须压缩。

        Claude Code 的做法是，当上下文超过 95%容量时自动触发 auto-compact，把整个交互轨迹摘要压缩，保留架构决策和未解决 bug，丢弃冗余的工具输出。

        第四个策略叫隔离。把上下文拆分到不同的空间里去。最常见的实现是多 Agent 架构：一个主 Agent 负责统筹，多个子 Agent 各自在干净的上下文窗口里执行具体任务。

        子 Agent 可能消耗几万 token 完成一次搜索，但只返回一两千 token 的精炼摘要给主 Agent。

        Anthropic 的实验显示，多个拥有隔离上下文的 Agent 确实优于单 Agent，因为每个子 Agent 的注意力更集中。

        代价也很直观：token 消耗最高可达聊天模式的 15 倍。

        Context Engineering 的技术框架已经有了，工具链也在快速成熟。

        真正的考验在于：谁能第一个在高风险的 C 端场景里，把这套跑通。

        目前来看，我觉得 Elys 虽然是最早吃螃蟹的人之一，但大概率更可能成为领先一步成为先烈的那一批。

        截至 2026 年 4 月，Elys 仍在邀请码内测阶段，没有公布过任何用户活跃度数据。