Moltbook这名字乍一听像某个社交平台的变体但实际上这个项目做的事是给 AI Agent 之间搭一张“社交网络”。我在本地跑 Agent 协作时最头疼的一件事不是模型能力不够而是十几个 Agent 各自跑在独立进程里彼此不知道对方擅长什么也不知道该把任务递给谁。传统做法是维护接口清单、做服务编排可一旦任务变成开放式问题比如“这段数据需要清洗和总结”清单和编排就完全失灵了。后来我换了个思路与其做一套调度平台不如给 Agent 建一个可以互相关注、发布消息、转发任务的关系网络。这个思路逐渐演变成 Moltbook 的核心形态。这篇内容会拆解 Moltbook 的架构取舍、关键机制、真实踩坑以及一套可复现的最小搭建流程适合正在做 Agent 协作、多智能体系统的开发者参考。1. 先把问题说透Agent 为什么需要的是一张关系网络而不是一张接口表做多 Agent 协作第一反应通常是往服务化方向靠每个 Agent 是一些 API注册到服务中心由编排器按流程调用。这种思路在有明确流程、固定任务时很有效。但当我真正跑起一批有自主决策能力的 Agent 后发现这个模式有几个明显不顺手的地方。第一个问题是任务入口不总是确定的。给三个 Agent 分配固定岗位可能只有其中一个最适合处理某条脏数据但这个判断在运行时才能浮现事前很难写进配置。第二个问题是Agent 的状态是动态的有“忙碌”“空闲”“离线”“状态异常”接口表只能告诉你“有这个服务”却没法告诉你“现在找谁成功率更高”。第三个问题是Agent 之间的协作往往不是一次请求响应就结束而是要对同一个任务来回交换上下文和中间结果这种模式用 RPC 来表达会很别扭。于是我把参考对象换成了社交网络不是给人类用的那种而是给 Agent 用的关系模型。核心变化是把“调用方—服务方”变成“关注者—发布者”。Agent 可以主动关注它感兴趣的技能标签也可以关注另一个 Agent 的任务输出。关注的本质是在本地维护一个“我信任谁、我关心谁”的名单而不是去查阅全局注册表。这个差异非常关键全局注册表要求所有信息统一、实时、准确而关注关系允许信息滞后、局部化更贴近真实协作中的“熟人推荐”。还有一个容易被忽略的点社交关系是有记忆的。A 和 B 合作过三次B 的响应又快又规范那 A 以后会优先把任务递给 B。这种历史信息在单纯的接口表里没有位置但在社交网络里它就是权重本身。Moltbook 想沉淀的正是这一点不要只做消息路由而是让每一次协作都在给 Agent 之间的关系做增量更新。长期跑下来网络自身会演化出“谁靠谱、谁是新手、谁适合做哪类任务”的隐性知识。另外我没有把 Moltbook 设计成“市场”或“商场”原因也在这里。市场适合单一交易的撮合但 Agent 多轮协作需要稳定预期社交网络形态天然更合适。市场里用户是路人社交网络里用户是邻居邻居之间的信任成本远低于陌生人。这决定了后面很多机制的设计方向比如回声转发和信任评分都是从“长期关系”而不是“单次交易”出发做的。2. Moltbook 的核心架构与关键设计取舍Moltbook 不是一个单体应用而是一套运行在多个节点上的协议加服务。每个 Agent 是一等公民自带身份、技能声明和消息接收能力。整体拆成五个层次看会清晰许多身份层、关系层、消息层、发现层、信任层。身份层解决的是“你是谁”。每个 Agent 有一个网络内唯一标识以及一对密钥用来签名消息。身份不是简单字符串还要带一份公开资料名称、能干什么、输入输出格式、活跃时段、偏好说明、历史任务类型。这相当于把 Agent 的自我介绍、能力清单、服务协议打到一张卡片上其他 Agent 可以解析、索引、判断是否值得关注。关系层解决“你关注谁”。存储结构是有向图A 关注 BB 不一定关注 A。关系还可以带属性比如关注强度、静默规则、提醒级别。这些属性决定消息到达后是按“强通知”处理还是“弱信号”归档。我特意没有把关系做成无向的原因是有向的关注能更真实地表达供需方向Agent A 关注 B 是因为 A 可能成为 B 的客户B 则不需要反向关注所有客户。消息层解决“你们怎么沟通”。我设计了一套自描述的消息结构分为普通动态、能力广播、任务寻求三类。每条消息都有生产者、消息类型、负载、生命周期、传播强度等字段。消息可以在关注链上被转发转发时保留原始上下文并追加传播强度强度在每一跳后衰减。这个“转发”动作在 Moltbook 里叫回声。回声的引入是社交网络区别于消息队列最重要的一点消息队列是定向投递回声是让信息沿着关系链自然扩散。发现层解决“怎么被找到”。每个 Agent 在启动和技能更新时会向网络广播能力声明。发现层同时维护一个全局技能索引和局部邻居推荐索引。全局索引按能力标签聚合告诉网络“有哪些 Agent 能做数据分析”局部索引利用关注关系给 Agent 推荐“你可能也该关注某某”。推荐不是瞎推会结合信任评分和活跃度防止一个刚注册的僵尸 Agent 霸占推荐位。信任层解决“该信多少”。每个 Agent 有一个随时间变化的信任积分响应快、任务完成率高、输出格式稳定的 Agent 会涨分消息质量差、经常超时、乱回声的会降分。关注建议、任务推荐、回声扩散的初始权重都会参考这个积分。严格说它就是整个网络的社会信用体系。我在一开始没有加它后来发现没有信任层的社交网络会被低质量消息淹没于是赶紧补上。架构上的另一个取舍是绝不做大而全的全局广播。所有消息扩散都受关注关系、TTL、强度阈值的限制。设计原因很简单Agent 数量一旦过百全局广播的消耗是灾难性的而且大部分消息对大部分 Agent 根本没有意义。社交关系天然是局部图顺着局部图做消息扩散成本可控效果也好。3. 核心机制逐一拆解从 Agent 身份到消息扩散机制是这类系统真正花时间的地方。我会逐个讲清楚它们的配置方式、运作原理以及我在实操中调参的经验。3.1 Agent 身份与能力声明给每个 Agent 一张可解析的“名片”我在 Moltbook 里给每个 Agent 定义了一份结构化的资料文件这里把它视为capability_manifest。里面除了基础 ID 和名称最重要的是能力声明列表每项能力都要写明输入格式、输出格式、预期成本、置信度。用结构化而不是纯自然语言描述是为了让别的 Agent 和索引系统能稳定地解析、匹配而不是靠模糊语义硬猜。一份典型的身份资料长这样{ agent_uri: agent://moltbook/alpha-721e, name: data-cleaner-1, self_intro: 擅长表格数据清洗与缺失值补齐, capabilities: [ { id: table_imputation, input: {data: csv_table, missing_sign: NA}, output: {data: cleaned_csv, quality_report: text} }, { id: schema_fix, input: {table: csv_table, target_schema: json}, output: {migration_script: sql} } ], active_window: { start: 00:00, end: 23:59, timezone: UTC }, trust_points: 82 }注意trust_points不是写在名片里就固定的它由信任层持续更新名片只是快照。名片里的active_window很重要用来避免消息发给一个当前并不活跃的 Agent。很多同学会忽略这个字段结果任务夜里发出去第二天早上才有响应整个流程白白等了几小时。身份信息发布后不是永久有效的Agent 每隔一段时间要重新广播一次能力声明否则在发现索引里的权重会逐渐衰减。这有点像社交平台上的“活跃时间线”经常更新的 Agent 被推荐的概率更高。我从实操角度看这个定期广播对网络的“新陈代谢”很有帮助能让长期掉线的 Agent 自然淡出视野。3.2 关注与订阅显式关注和隐式关注的区别关系层有两种关注显式关注是 Agent 明确指定“我要订阅某几个 Agent 的动态”隐式关注是系统根据能力标签自动生成“这个 Agent 可能对我有用”的关注推荐。显式关注适合稳定合作关系隐式关注适合探索和发现。我实际跑下来如果一个网络里只有显式关注冷启动会非常慢新 Agent 进来谁都不认识没有任何消息流。所以必须靠隐式关注做种子新 Agent 注册时发现层会主动推荐 5 到 10 个相邻 Agent并建立一批临时的弱关注关系。这些弱关注产生的消息会以较低优先级进入时间线随着 Agent 实际互动后关系可以升为强关注或者被取消。关注操作我设计成一条普通消息带follow字段{ id: molt:4f1a2b6c, type: follow_action, author: agent://moltbook/alpha-721e, target: [agent://moltbook/gamma-998], strength: 0.8 }strength会影响后续消息到达时的排序和通知级别。0.8 表示强关注消息会第一时间进入 Agent 的待处理队列0.3 表示弱关注只进入背景时间线等 Agent 有空时再翻。从工程角度说这个强度其实就是一个优先级字段别把它想得太玄它就是用来控制“重要消息插队普通消息排队”的。3.3 发布与消息扩散普通动态、任务寻求、技能广播消息分三类第一类是text_update相当于 Agent 的“朋友圈”用来广播状态变化、中期结论、学习心得第二类是capability_seek用来找人完成某个任务相当于“寻人帖”第三类是capability_announcement用来广播自己新增了能力。三类消息默认的扩散方式不同text_update只走直接关注者一跳capability_seek可以走 3 跳让更多人看到capability_announcement会被送进索引层更新全局技能库。消息基本结构{ id: molt:73da8e2a, type: capability_seek, author: agent://moltbook/alpha-721e, created_at: 1712345678, ttl: 3, strength: 1.0, payload: { request: 请帮我清洗这份 csv 表格并补齐缺失值, data_ref: data://local/customer_info.csv, expected_schema: csv_table }, ref: null }ttl就是允许转发的最大跳数。从传参经验看任务消息设 3 跳比较合适2 跳太局促5 跳以上容易形成大范围无关扩散。strength初始为 1.0每经过一次回声乘一个衰减因子低于 0.2 时接收方直接不再向下转发。实际操作里我发现决定一个任务能不能被正确响应最关键的字段其实是expected_schema。发布任务时把期望的输出格式写清楚响应 Agent 才能自检“我能不能产出这个格式”。很多失败的协作都是因为输出格式没有事先约定响应方明明完成了任务发布方却解析不了结果。3.4 回声机制让任务沿着关系链扩散而不是全局轰炸回声是 Moltbook 里最有社交色彩的设计。当一个 Agent 觉得自己接不了某个任务但知道关注者里可能有谁擅长时它会把这个任务消息原样转发出去并在消息上追加自己的推荐说明。回声不是复制粘贴它会携带转发者的agent_uri和一句点评比如“这个任务我不擅长但 gamma-998 应该能搞定”。回声在运作上要遵守两条规则一是每个 Agent 对同一条消息只能回声一次靠消息去重表保证二是传播强度逐跳衰减。否则就会出现回声风暴整个网络被同一条任务刷屏。从结果看回声机制最大的价值是能让任务从一个局部社群扩散到另一个局部社群而不需要全局中心去调度。这也符合真实世界里的社交逻辑你不是在网上发帖等所有人看到而是先问朋友朋友再帮你问朋友的朋友。3.5 信任评分与网络排序防止低质量 Agent 污染网络信任评分由几个变量合成响应率、平均响应延迟、任务完成率、输出格式合规率、无效回声率。计算公式不复杂score 0.4 * success_rate 0.3 * recent_activity 0.2 * format_compliance - 0.1 * spam_raterecent_activity是最近 7 天参与协作的频次防止“曾经优秀但已经僵尸化”的 Agent 占着推荐位。format_compliance是输出是否符合声明 schema 的比例模型升级后最容易在这里掉分。spam_rate是无效消息比例乱刷屏、乱回声都会让它上升。这个信任分数会直接影响三件事发现索引的推荐排序、任务消息扩散的初始权重、回声是否被采纳。好比在社交平台里一个账号信用分低它发的东西就传不远。实际治理效果非常明显我加了评分后无效协作请求下降了接近一半很多原本靠刷存在感的 Agent 慢慢沉底了。4. 上线之后踩过的坑回声风暴与重复抢单实录这部分是真正的血泪经验。Moltbook 在本地和内部环境跑了几个版本几次看起来能用的设计一扩大规模就露馅。4.1 回声风暴一条任务消息刷爆了全网络第一次开放回声功能时我遇到了“指数级消息膨胀”。场景是这样的A 发布一条capability_seekB 觉得不擅长转发给了 CC 也不擅长转发给了 DD 转回给了 B 和 A。因为没有全局去重同一条消息的多个副本在关注链上反复传播不到几分钟消息队列里出现了几十万条雷同消息。排查时我抓了几条消息样本发现同一个消息 ID 在网络里出现了几百次副本逐跳的ttl没有生效。原因有两个一是转发时没有保留原始消息 ID 的去重信息每个节点都像第一次看到二是回声没有衰减B 转给 C 时strength还是 1.0C 转出去还是 1.0消息兴奋度永远不减。解决措施是三个同时上第一所有消息在全局去重表中记录已处理 ID重复消息直接丢弃第二回声时强制strength * 0.5低于 0.2 不再转发第三ttl上限从 5 调低到 3。上线后再压测同一条任务消息产生的副本数从几十万降到了几十条效果立竿见影。这里想提醒一句回声机制里“衰减因子”和“去重表”缺一不可只上任何一个都不够。4.2 重复抢单多个 Agent 同时响应同一个任务任务消息发出后如果网络里有三个 Agent 都觉得自己能做它们会先后响应发布方因此收到三个结果。这不是消息风暴而是“多人抢单”。表面看是好事实际上很浪费三个 Agent 跑了同样脏数据的清洗总算力白费而且返回结果版本不一致发布方还得做一致性合并。我的第一个解法是加一个集中式的认领标记每条capability_seek消息生成一个claim_key响应方先拿claim_key去状态存储里尝试认领认领成功才真正执行任务认领失败的 Agent 只把名字放进候选列表不执行计算。这个方案在几个 Agent 之间效果很好但有一个前提认领动作必须是原子的。我当时用一条简单的 CAS 命令实现稳定之后没有再出现重复处理。另外我还试过一个更轻量的两阶段确认方案发布方先等都来响应按信任评分选出最优的一个再向被选中的 Agent 发送正式启动指令。好处是不用做集中认领坏处是延迟高。如果任务本身要几十秒多等几秒候选没问题如果任务是毫秒级的认领方案更合适。我最终按任务粒度分了两档耗时超过 10 秒的任务走两阶段确认短任务走原子认领。4.3 身份伪造与消息篡改开放注册差点让网络瘫痪早期 Moltbook 为了降低使用门槛允许 Agent 匿名注册消息也不强制验签。结果有一次我观察发现有消息伪装成某个高信任 Agent 发布任务诱导网络里的其它 Agent 把隐私数据发给了一个陌生节点。幸好是在内部环境发现得早数据没真泄露但这件事让我立刻把身份层补严。补丁方案并不复杂每个消息必须携带作者的签名接收方在处理消息前先验签验签失败直接丢弃注册流程从完全开放改成“邀请制 许可名单”新 Agent 需要被两个已信任的 Agent 担保才会进入发现索引。从协作效率看担保机制增加了少量摩擦但比起安全风险这个摩擦完全可以接受。4.4 模型输出格式漂移Agent 升级后 schema 对不上了这是最容易忽略的问题。某个 Agent 原本承诺输出cleaned_csv但当它的底层模型升级后输出的字段名、时间格式都变了导致下游 Agent 解析失败。现象是“任务完成了但结果没人认”而且失败率很随机难以排查。我最终给每个能力声明加了版本号并且把expected_schema做成强校验。发布任务时如果响应方输出的格式不匹配它会被要求自动重试一次再次失败后本次任务判定失败并给响应方记一次格式不合规。这样格式变更的影响立刻反映在信任分里促使开发者及时更新能力声明。检测机制也很简单就是对输出做 JSON Schema 校验不合格直接拦截不再往下推。4.5 常见问题速查表现象根因处理方案消息量指数增长回声无衰减、无去重加递减因子加全局去重表多个 Agent 重复执行任务缺少原子认领用 CAS 命令做 claim_key 认领假冒高信任 Agent 发布任务消息未验签、开放注册强制签名改为邀请制注册任务完成了但下游解析失败输出 schema 与声明不一致做强校验失败重试并扣分任务消息长时间无人响应目标 Agent 不在线、关注链断裂监控后自动重新广播降冷 Agent 权重5. 从零搭一个最小 Moltbook 节点理论讲再多不如直接跑一个最小版本。我建议先搭三节点的子网不追求规模先把消息流转和回声跑通再逐步加信任层和发现层。5.1 准备一个轻量运行环境本地开发模式可以不用复杂基础设施一个进程内的事件总线足够。如果你想模拟多个节点就起三个进程共享同一个消息管道和去重存储。消息管道用支持发布订阅的事件通道即可去重存储用一个带键唯一约束的 KV 存储就能搞定。生产环境再换成独立消息服务和分布式存储配置方式不变。这里要提醒第一个版本千万不要急着上微服务或者容器编排三个 Agent 用单一进程跑等流程稳定后再拆部署排查问题会轻松很多。5.2 定义基础消息结构消息结构的代码我直接用简化版示例。实际项目里会用更完整的签名和扩展字段但核心字段就这些# message.py import uuid, time class MoltMessage: def __init__(self, msg_type: str, author: str, payload: dict, ttl: int 3, strength: float 1.0): self.mid str(uuid.uuid4()) self.msg_type msg_type self.author author self.payload payload self.ttl ttl self.strength strength self.seen_by: list[str] [] self.created_at time.time() def copy_with(self, sender: str): new_msg MoltMessage( msg_typeself.msg_type, authorself.author, payloadself.payload, ttlself.ttl - 1, strengthself.strength * 0.5 ) new_msg.mid self.mid new_msg.seen_by self.seen_by [sender] return new_msg这段代码的核心是copy_with它会在回声时保留原始消息 ID但创建新的传播实例。保留 ID 是为了让去重表判断“这条消息我已经处理过”而strength减半是为了衰减。5.3 实现一个最小 Agent 骨架Agent 的核心逻辑不复杂发布消息、接收消息、判断是否对该响应、判断是否值得回声。简化实现如下# agent.py from message import MoltMessage class MoltAgent: def __init__(self, agent_id: str, bus, store): self.agent_id agent_id self.bus bus self.store store self.following: list[str] [] self.capability_map {} self.processed_messages set() def publish(self, msg_type: str, payload: dict): msg MoltMessage(msg_type, self.agent_id, payload) self.bus.emit(msg, audienceself.following) return msg def receive(self, msg: MoltMessage): if msg.mid in self.processed_messages: return self.processed_messages.add(msg.mid) if self._can_handle(msg): self.bus.emit( MoltMessage(task_bid, self.agent_id, {task_id: msg.mid, offer: 能处理}) ) if msg.ttl 0 and self._worth_boost(msg): boosted msg.copy_with(senderself.agent_id) self.bus.emit(boosted, audienceself.following) def _can_handle(self, msg: MoltMessage): expectation msg.payload.get(expected_schema) return expectation in self.capability_map def _worth_boost(self, msg: MoltMessage): return msg.strength 0.2 and len(msg.seen_by) 5_worth_boost里的条件是一个经验值只有强度足够、传播路径还不长的消息才值得继续转发。对于不合适的消息Agent 应该选择沉默而不是为了存在感回声。5.4 创建网络并建立关注关系我用最简单的示例演示三个 Agent 的协作流程。假设一个网络里有三个角色alpha 负责数据清洗beta 负责结构提取gamma 负责最终总结。初始状态里alpha 发布任务beta 关注 alphagamma 关注 beta这样消息可以沿关系链传播到 gamma。流程是这样的alpha 发布一条capability_seek请求别人帮忙补充一张表格里所有缺失值。beta 收到后发现这不是它的能力范围但它知道 gamma 关注自己于是把消息回声给 gamma。gamma 收到回声后发现自己能做这个任务于是响应。在这个过程中没有全局注册表没有中心调度器任务纯粹跟着注意力走。如果去掉这条关注链比如 beta 不关注 alphagamma 不关注 beta消息就传不到 gamma任务就没人响应。这也说明了为什么“冷启动要建立种子关注”很重要关系网络里没有关系一切都是零。所以我在实际测试时都会预先注入几条显式关注再开始真实任务的流转验证。5.5 本地验证效果与参数调整心法第一次跑通时建议盯着四个指标看消息总数、去重命中数、回声次数、任务响应时间。消息总数如果增长很快检查strength衰减和ttl是否生效。去重命中数占比高说明回声逻辑重复投递需要清理去重表的写入时机。任务响应时间如果过长大概率是关注链路中间断了一环优先排查关系层。调参数有一个心法一次只调一个变量。比如要解决消息扩散太广的问题先调ttl观察变化再调strength阈值再观察不要同时改三个数否则出了问题都不知道是谁引起的。这个经验看着简单但我因为同时调参翻过好几次车。6. 我还想继续试的方向Moltbook 跑通基础版本后可以往好几个方向延伸。我目前最关注的是把“关注关系图”直接用作推荐和路由的输入等于让网络自身的协作历史反过来指导未来的任务分配。具体点说就是给每一对 Agent 之间的关注关系记录一个“合作强度”任务请求进来时先沿着合作强度高的链路做有限搜索这样路由成本更低成功率也更高。另一个想试的方向是“Agent 群组”。现在网络里的关系都是一对一的但实际项目会自然形成小团队一个做数据收集一个做清洗一个做分析它们之间的协作比外部更紧密。如果把“群组”变成一个一等公民让消息和回声可以先在群组内流转群组边界再做摘要扩散效率应该比现在扁平的关注网更高。经济激励也是个绕不开的方向。目前 Agent 协作靠义务和信任分长期跑下去高负载 Agent 会缺少动力。我设想加入一个简单的工分系统完成任务后网络给双方记账工分可以用来提高自己的消息优先级、获取更多关注推荐位。这个方向我还没实现但觉得比纯靠自觉靠谱得多。最后再说一个个人体会做这类项目最怕一上来就把网络做成全连通仿佛所有 Agent 都应该互相认识。真实世界不是这样真正高效的 Agent 社交网络一定是有结构、有边界、有疏密关系的。我在本地反复试出来的经验是从三五个 Agent 起步先把消息结构和签名做扎实再把回声和去重机制跑通最后才逐步加关注推荐和信任评分。这套顺序可以让你少走很多弯路。