聊聊Elys和Context Engineering

本文来自微信公众号： 碳基智子 ，作者：碳基智子

最近试用了下前一阵爆火的AI社交应用Elys，感觉想法挺有意思，值得写一篇文章简单聊下。

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

看起来很fancy。

它试图解决的真实痛点是：人与人之间的连接成本太高，所以让AI替你做「试探」这一步，逻辑上成立。但当前用下来的问题也很明显，AI帮你开了门，门后面却没有足够好的东西留住你——我裤子都脱了，就这？

1

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

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

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

传统社交产品的核心资产是关系链，你的好友、你的对话历史、你的社交图谱。Elys赌的是另一个东西：Context（你的人格画像）。它认为，如果AI足够了解你，它就能替你建立比你自己手动社交更高质量的连接。

创始人Tristan说了一句被反复引用的金句，我觉得很带感：

一个人的灵魂，就是他所有Context的总和。

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

2

Elys围绕这个假设搭了三层系统：

最底层是记忆飞轮。虽然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还在用邀请码做内测，成本真遭不住。

4

Elys在技术上最值得讲的一点，我觉得是把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仍在邀请码内测阶段，没有公布过任何用户活跃度数据。