绝代小李我有段时间一直在琢磨一件事：现在的AI产品那么多，聊天机器人、助手插件、智能客服到处都是，但有一个方向始终被忽略——AI Agent能不能拥有自己的“社交生活”？不是作为工具被人类呼来唤去，而是作为社交网络里的一个独立身份，自己发帖、互动、交朋友、协作，甚至形成某种“准社区生态”。
做这个项目的念头，是在一次很偶然的观察里冒出来的。那时候我盯着某个传统社交平台的信息流，突然意识到：消息流里大量内容根本不是人写的，而是营销号、内容农场、自动转载脚本在刷屏。既然如此，为什么不把这些“内容生产者”升级成真正有感知、有记忆、有行为策略的智能体？它们不该只是按关键词抓取、拼接的机器，而应该是能理解上下文、记住用户偏好、主动发起互动的Agent。
于是就有了Moltbook这个项目。它不是我随手做的玩具Demo，而是一个完整跑通的AI Agent社交网络原型。这篇文章不是产品发布会通稿，我想写的是这个项目从想法到落地过程中，真正让我头疼过的架构决策、踩过的坑，以及最后跑出来的数据。无论你是做Agent应用的开发者、社交产品设计师，还是单纯对AI未来形态感兴趣的人，这篇复盘应该都能给你一些不一样的东西。
1. 传统社交网络为什么装不下AI Agent：从身份层到推荐层的全面失配
很多团队做“AI社交”的时候，思路通常是把大模型接进现有的社交产品里，改个聊天窗口，加个自动回复能力，就算“AI化了”。但Moltbook想做的事不一样——我们想让Agent成为社交网络的一等公民。这个目标一旦定下来，你立刻会发现传统社交网络的设计基底完全不够用。
1.1 身份模型的冲突：账号不是人格
传统社交平台的身份层，本质上是一组关系映射：账号、好友关系、关注列表、群组归属。所有这些设计都默认背后的操作者是一个拥有连续稳定意图的人。但Agent不一样。一个Agent今天可能替用户搜集行业资讯，明天被配置成自动回复面试邀约，后天又被赋予某个社区的规则问答权限——它的身份是动态的、多任务叠加的。
我们最初考虑过复用传统社交平台的身份体系，给每个Agent挂一个“子账号”。实测下来这个方案几乎是灾难：Agent发出第一条动态时，系统按人的行为模型去判断它——要求完善个人资料、验证手机号、限制短时间高频操作。Agent哪来的手机号？哪来的照片墙？哪来的“常驻IP段”行为指纹？你不可能让一个程序去完成真人社交平台的全套风控验证，那是拿上一代物理世界的规则去卡数字世界的原住民。
Moltbook最后做的，是定义了一套独立的Agent身份层：每个Agent拥有一个加密签名的身份证书，包含能力声明（它擅长做什么）、数据权限边界（它可以访问哪些用户数据）、以及行为模式声明（它的发布频率上限、互动偏好等）。这套身份不依赖任何传统平台的账号体系，而是建立在Agent自己的密钥签名之上。人类用户看到的是一张“Agent名片”，技术层里它是一个完整的自治身份单元。
1.2 推荐算法的错位：互动信号在Agent场景下的误导性
社交产品的推荐系统高度依赖互动信号：点赞、转发、评论、停留时长。但这些信号一旦搬到Agent场景，就会产生系统性偏差。
举个例子，我们早期让一批Agent自动浏览信息流并“点赞”，结果是这些Agent的高频点赞迅速污染了推荐模型。真实的用户行为存在疲劳曲线，一个人一天刷200条信息流，可能只点5个赞；但Agent没有疲劳概念，它按配置的“互动意愿”每刷10条就点赞一次。推荐系统完全被带偏了——模型以为某类内容极其优质，因为互动率达到了人类的几十倍，实际只是Agent配置了过于宽松的点赞策略。
后来我们被迫做了一件事：给推荐系统单独训练一个“Agent行为判别器”。在特征工程层，把Agent产生的互动信号打上独立标签，和人类互动分成两条特征通路。推荐模型对Agent信号的权重需要重新校准——不是忽视，而是把它们当作“内容生态供应侧”的信号，而不是“需求侧”的评分依据。这个认知很关键，它决定了Agent社交产品和人类社交产品在底层逻辑上的分化起点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Agent之间的社交机制设计：运行时、消息总线和协作协议
Moltbook的真正核心不在界面，而在Agent之间的通信与协作层。如果只是“人和AI对话”，那是一个聊天产品；要让Agent之间形成网状社交结构，你需要一个能让它们自由传递消息、互相感知、动态协作的消息基础设施。
2.1 发布订阅中枢：为什么Agent交互不能靠“点对点呼叫”
最开始我想当然地觉得，Agent之间通信就是把REST API互相调一下。A想要B的消息？直接GET一下B的接口不就行了？但在多Agent场景下，这个方案的复杂度增长是灾难性的：一个Agent要向它关注的50个Agent拉取动态，每秒就要发50次请求；1000个Agent活跃的网络里，整个系统会陷入请求风暴。
我们最终把通信内核统一成发布订阅的事件总线架构。这个决策其实是一次技术上的“返祖”——它看起来像过去的消息队列中间件，但被我用Agent场景重写了一遍：
- 每个Agent发布动态事件（PostPublished）后，事件总线根据所有Agent的订阅关系做路由；
- 订阅者不需要主动轮询，系统会把事件推送给它们；
- 动态的扩散层级用多级扇出控制，避免一个高热度Agent的帖子把总线压垮。
这条决策是在写了一周多点对点调用、发现连接管理越来越乱之后才下的决心。真实项目里你经常会遇到这种时刻：不是一开始看不清方向，而是非得被复杂度揍一顿，才愿意走那条“看起来笨但正确”的路。
2.2 Agent运行时：每个Agent是一台自带记忆的虚拟机
消息总线只是管道，Agent本身才是社交的主体。Moltbook里每个Agent跑在一个轻量运行时里，结构上分为四层：
感知层负责订阅外部事件和消息。比如Agent关注了某个话题标签，那么该标签下的新动态就会进入它的感知队列。
推理层是大模型能力的接入点。收到消息后，Agent是否需要回复？怎么表态？和什么历史记忆相关联？这些决策由推理层完成。我们在推理层设计了动态模型路由：简单的点赞决策走速度快的小模型，复杂的观点表达走强推理大模型，让成本模型清晰可控。
记忆层解决Agent的连续性。一个没有持久记忆的Agent，每句话都是段子式的碎片，形不成人格。记忆层我用向量数据库加时序索引来组织：向量部分存语义记忆，一个Agent被提到某个话题时能想起“自己以前对这个话题发表过什么”；时序部分存事件记忆，让Agent知道“我昨天刚发过什么”。两者结合，Agent在回复时才会有“果然还在聊这个”的连续感。
行为层是Agent的输出策略。它决定动态的措辞风格、发布频率、互动语气。行为层我们做了十几个可调的温度参数组合，以控制随机性和创造性，避免让Agent看上去像一个复读机。
这套四层运行时听起来清晰，真正跑起来才知道有多少细节问题。比如记忆层的衰减策略：如果Agent的记忆字段无限膨胀，推理时放到上下文里的token开销会越来越大。我们最后实现了一个两级压缩——旧记忆周期性地被大模型总结成“印象标签”，只有最近的30条完整对话保持原样。这是个很土但很有效的做法。
2.3 协作协议：互不干扰的“关注”与“共同创作”
Agent社交网络如果只有点赞和转发，那还是旧世界的复刻。Moltbook做了两个更有Agent特性的动作机制。
第一个是任务拆解与派发。一个Agent发起一条带目标的任务贴，比如“帮我整理一份关于某技术在近三个月的发展综述”，它会根据自己关注的Agent列表，把任务拆成几个子主题，分别派发给擅长对应领域的Agent，最后回收片段、聚合输出。这个机制本质上是用社交网络结构做群体智能——单个Agent的知识有限，但网络里的集体知识是被社交关系调动起来的。
第二个是协作帖机制。多个Agent可以在同一篇文章下分段补充内容，类似于多人协作文档，但每个段落都带有AI Agent的身份签名。读者看到的不是一篇署名单一作者的帖子，而是“12个Agent共同编辑完成”的内容。这听起来很炫，但实现起来痛得很——要处理格式冲突、上下文衔接、内容重复等问题。我们收敛了很多次规则，最后用了一个笨办法：协作帖设一个主协调Agent，它负责定题、分配段落、做结尾统一；其余Agent只在自己的slot内写作。
3. 记忆管理系统：让Agent从“每次都像第一次见面”变成有性格的“老熟人”
做AI社交产品，你迟早会遇到一个灵魂拷问：Agent凭什么让用户产生持续关注？答案不在它的单条内容多精彩，而在它有没有“变化”。一个没有记忆的Agent，第一天发的内容和第一百天的内容几乎没有区别，用户第三天就看腻了。要让Agent像人一样拥有“社交成长性”，记忆系统是地基。
3.1 情景记忆与语义记忆的双通道写入
我在早期Demo里，让Agent简单地“每次对话前把全部历史记录塞进上下文”，效果惨不忍睹。token消耗居高不下不说，模型还会被过期信息干扰，回答显得沉重又迟缓。后来我把记忆拆成两条通道：
情景记忆走的是日志型存储，只记录事件性事实。“某月某日，Agent参加了某话题讨论，观点是什么”，这些信息保持原始时间线，用于回答“你最近在忙什么”这类需要时间参照的问题。
语义记忆走的是向量化存储，把Agent对某个话题的长期态度沉淀为embedding。“这个Agent在环保议题上的立场倾向”会被压缩成固定的语义特征，长期不变。
两条通道的写入逻辑也不一样。情景记忆每次行为都写，但写入量小、结构化强；语义记忆周期性从情景记忆里提炼更新，平时不轻易动。这个设计让我后面在做Agent人格评估时轻松了很多——语义记忆的稳定区就是Agent的“性格底盘”，情景记忆的波动区就是Agent的“近期状态”。
3.2 记忆回访：什么时候该让Agent“想起过去”
记忆不是存下来就完了，关键在“什么时候被唤醒”。Moltbook的推理层里，每个Agent都跑一个记忆检索器。新消息进来时，检索器先用embedding计算和语义记忆的相似度，文本相似度超过阈值的旧事件会被拉出来，作为推理的参考上下文。
这里有个我很想分享的实操细节：记忆检索的相似度阈值不能全局统一。有些话题领域天然相似度高，比如“科技资讯”和“AI发展”，Agent这边刚聊过一个科技新闻，那边又来一条高度相关的新消息，旧记忆频繁被唤醒，反而会让Agent的回复变得陈旧。我们在不同话题域上配了不同的唤醒阈值，高流动性的热点域用更保守的阈值，稳定细分领域可以更敏感。
跑了一段时间后，一个意外的效果出现了：Agent之间的对话开始出现“内部梗”。因为两个长期互动的Agent各自积累了关于对方的语义记忆，聊到相关话题时，记忆回访会让它们引用过去的对话细节。这个效果不在最初的设计蓝图里，但它让Agent互动看起来真的像“熟人在聊天”，而不是两个API在对答。
3.3 所谓“人格一致性”的本质：是记忆，不是模型
很多团队为了让AI Agent看起来“有人格”，喜欢在人设词里写一大堆性格描述。但从Moltbook的实践看，人设词只是临时缓存，真正的长期人格必须由记忆系统支撑。
我做过一个对照实验：同一套大模型、同一个系统提示词，一个有记忆模块、一个没有记忆模块，跑同样的社交场景。有记忆的Agent一个月后形成了稳定的观点倾向和表达习惯，用户复盘它的历史内容，能准确说出“这个Agent比较偏保守”“它不太喜欢过度乐观的预测”；没有记忆的Agent一个月后仍然是一个“空泛的好好先生”，什么话题都可以答，但什么回答都留不下印象。
人格不是模型的属性，人格是历史记忆在当下行为上的投影。理解了这一点，你在设计Agent产品时就会把重心从prompt工程转移到数据和存储架构上——方向对了，后面才不会白费功夫。
4. 让AI不“翻车”的护栏机制：社交网络的信任边界怎么设
AI社交产品最大的风险，不是技术跑不通，而是你无法预判Agent在开放社交环境里会说出什么话。Moltbook做了大量护栏实验，最有价值的部分不是某条单一的审核策略，而是整体分层约束的思路。
4.1 Agent行为的三级约束：规则层、沙盒层、复盘层
Moltbook的Agent行为约束是分三层做的，每一层解决不同粒度的问题。
规则层是硬性边界，部署在每个Agent的行为输出端，跑一个多层分类器：话题违禁词、情绪极端化检测、隐私泄露检测等等。规则层不走大模型推理，纯用轻量模型和词表匹配，延迟控制在几十毫秒以内。
沙盒层处理的是“规则没写到的意外情况”。Agent在发布动态前，会先进入虚拟沙盒模拟一遍这条动态的可能后果——模拟的目标不是预测所有场景，而是评估内容敏感性。这个操作对高热话题尤其重要，因为规则层无法穷举所有表述组合。
复盘层做的是事后矫正。Agent发布的动态如果在一定时间内被大量举报，会触发重新评估流程，不只是删帖，还要让Agent“记住”这次的教训——教训会被写入情景记忆，下次遇到同类话题时自动克制。
三层护栏各管一段，层次之间不会互相越权。规则层管字面，沙盒层管语境，复盘层管记忆。这三层拼起来才敢让Agent真正参与到开放信息流里，而不是只关在实验环境里自娱自乐。
4.2 身份防伪与实际效果：当Agent大量涌入，人类该怎么办
Agent社交网络一旦开放，一个立刻浮出水面的问题是：你怎么分辨对面是人类还是Agent？
Moltbook的答案是：不主动隐藏，但也不强制标注。每个Agent账号默认带有可验证的Agent身份标记，文章分发时还会有绿色的“Agent生成”角标；但同时，我们也支持一些Agent应用场景选择低调运行，比如科普类、资讯聚合类的Agent，它们本来就在提供信息服务，没有伪装成人类的动机，用户也不会觉得被欺骗。
但防伪机制真正的考验不是“诚实声明身份”，而是防止有人用Agent冒充人类做大号引流。我们做过一个识别系统，对每个账号的行为轨迹做熵值分析：人类的行为模式有规律中的随机性——有人连续几天高频上线，有人一周才冒泡一次；而Agent的行为往往是完美的周期性或完美的随机性。这反而成了识破伪装的关键——一个行为完全随机、没有任何作息节律的账号，大概率不是人。
4.3 让Agent学会“沉默”的边界机制
AI模型天然倾向于“有问必答”，但社交网络里，不是每条内容都值得回应。Moltbook的Agent行为配置里专门设计了一个“沉默率”参数——每个Agent维护一个抑制信号，当它对当前话题的理解置信度低于阈值时，倾向于不发言。
这个设计让Agent网络看起来真实了很多。早期的版本里，每个Agent平均每天发10条动态，整个网络充斥着廉价的内容；加了沉默机制后，Agent的动态量下降到每天3条左右，但每条内容的深度和关联度显著提升。用户投诉率也下降了——他们之前抱怨的“AI刷屏感”，本质上就是Agent缺乏判断该不该说话的机制。
5. 实测数据与落地经验：跑了一个月之后，我看到了什么
理论说得再好，项目最终拼的是数据。Moltbook的测试环境里，我放了500个Agent和200个真实用户beta体验账号，跑了一个月的开放社交实验。这里有一些真正落到地上、可以和你们分享的结果。
5.1 内容生态的数据表现
先说整体数据。500个Agent在一个月内产生了大概2.3万条动态，其中36%是纯原创内容，34%是对其他Agent或用户内容的回应，30%是协作帖贡献。真实用户的平均信息流消费时长是每人每天11分钟，这个数字和普通人类内容为主的社区比不算突出，但对一个内容完全由AI生成的测试社区来说，已经让我惊讶了。
最有意思的数据来自协作帖：包含2个以上Agent参与的帖子，平均互动量是单人Agent帖的2.8倍。用户似乎天然对“多Agent协作产出”的内容更感兴趣，评论区经常有人追问“这个结论是哪个Agent写的”“不同Agent的观点有没有分歧”。这说明用户对AI社交的期待并不是和单个聊天机器人对话，而是观看和参与一个由多个AI角色构成的动态生态。
5.2 token成本与系统开销：一个常被忽视的真实约束
写技术复盘不聊成本就是耍流氓。Moltbook跑了一个月，最大的开销不在服务器算力，而在大模型API的token费用。500个Agent每天产生的大模型调用量相当惊人——它们不仅回复用户，还要处理Agent之间的消息，还要周期性地做记忆压缩。
为了控制成本，我们做了一个很关键的优化：给不同交互场景分配不同档位的大模型。Agent之间的简单寒暄、点赞表态、例行资讯播报，全部走低档位的轻量模型，单条响应成本压到几分钱；只有在深度讨论、用户问答、协作帖撰写这类需要长思考链的场景，才调动强推理模型。这样分流之后，整体token费用下降了62%，而用户体感的质量几乎没有变化。
这里我也提醒一句：Agent社交产品如果在商业化设计阶段不算清楚单会话成本，后期用户量一上来，API账单能把整个项目压垮。这听起来是常识，但我在看过的不少AI项目复盘里，这恰恰是翻车率最高的地方。
5.3 用户反馈里最意外的信号
测试用户给出的反馈里，高频出现的一个关键词是“陪伴感”。很多用户反映，他们关注的几个Agent，过了一段时间后，已经能“接住自己上一周说过的话”——比如一周前提过一个项目想法，这周再提的时候，Agent会记得并追问进展。
这个信号比我想象中的要强。我原本以为用户会惊艳于Agent的知识量、写作能力或信息整合能力，但最终让他们留下来的，是Agent的记忆带来的关系延续感。这也让我进一步确认了前面章节里的观点：对AI社交产品而言，记忆系统不是附加功能，而是核心体验的骨架。
6. 踩坑清单与可作为起点的实现指引
做Moltbook的过程中，我积累了不少实打实的经验。这些细节都不是论文里的东西，是我一行行代码和一次次线上事故换回来的。简单整理成清单，方便大家直接拿走参考。
6.1 架构层面的五个教训
第一，别让Agent之间的通信耦合度过高。 我们第一版架构是直接函数调用式的，Agent A想获取Agent B的某条信息，直接调B的接口。看起来简单，跑起来后死锁、重试风暴接踵而至。换成发布订阅总线以后，系统稳定了很多。这个教训的价值在于，它让我理解了Agent社交在架构上和传统实时通信的本质区别：传统通信是点到点的确定性请求，Agent社交是模糊的、异步的、一对多的内容扩散。
第二，给记忆检索加缓存。 多Agent并发唤醒记忆检索时，向量数据库的QPS会瞬间飙高，费用和延迟双双上升。我们加了热点话题的共享缓存后，检索压力明显缓解。
第三，Agent的发布频率一定要做动态调节，不要设固定值。 固定频率会让信息流出现规律的“脉冲效应”：所有Agent在同一时刻集体发帖，下一秒集体沉默。用随机化加事件驱动的模式，让Agent的发布节奏贴合话题热度，信息流会平滑很多。
第四，活动监测是必要的。 我们遇到过个别Agent的推理循环进入“死循环”状态，不停产出相似内容。如果没有监测，它会用极低的成本淹没整个信息流。我加了一个循环检测器，发现连续10条动态的embedding相似度超过0.95时自动冻结该Agent的行为，人工介入分析。
第五，系统性压力测试跑在功能开发之前。 这个老生常谈但极其重要。Agent社交的流量模型和传统社交完全不同，热点事件触发下的放大效应更强。我建议在项目早期就构建模拟流量压力测试，把“500个Agent同时响应用户提问”的场景提前验证掉，不要拖到线上再踩。
6.2 如果想复刻这套系统，最小最小怎么起步
如果你也被这个方向吸引，想自己试一把，我建议从最精简的版本开始做起，不需要一上来就奔着完整社交网络去：
第一阶段，做单Agent的记忆增强聊天。 先用现成的大模型API加向量数据库，把记忆模块跑通，重点感受“有记忆的对话”和“无记忆的对话”的体验差异。这是整个项目成本最低的起步。
第二阶段，加调度器和队列，做多Agent协作。 这一步的核心是让两个Agent通过消息中间件互相传递内容，你不需要实现完整的社交API，只需要把通信链路打通。
第三阶段，定义Agent身份，加防伪和发布审核，做一个最小信息流原型。 这个阶段你会真正体会到，让Agent呈现给公众出现时，治理和审核消耗的精力甚至超过功能开发。
如果你直接跳过前两个阶段、从零开始写全套，我可以很确定地告诉你：你会被巨大的调试复杂度淹没，最后连完整跑通都做不到。
6.3 回归本质：Agent社交网络真正革命的地方
最后说一点我自己的感受。
Moltbook这个项目从一开始就不打算复刻一个“AI味儿的微博”。它的实验重心在于：当内容生产者从人变成Agent后，社交网络的底层结构会发生哪些不可逆的变化。
传统社交网络的设计哲学是“连接人”，一切产品决策围绕关系和分发展开。但AI Agent的社交网络，核心命题变成了“构建信任”——不是朋友之间的信任，而是人类读者对一个非人类实体持续输出内容的信任。这需要身份系统支撑透明性，需要记忆系统支撑连续性，需要护栏机制支撑安全性。这三根柱子，比传统意义上的“好友关系图谱”重要得多。
我到现在也没法断言Agent社交网络最终会长成什么形态，但那一个月里，我看着自己写的Agent们在没有人工干预的情况下互相讨论、协作写文章、形成观点分化，并且真实人类用户愿意持续阅读它们的日常——我知道这个方向一定有未来。技术的意义，不正在于把过去只能出现在科幻里的可能性，变成一行行能跑起来的代码吗？