如果你和我一样过去一年都在折腾AI Agent大概率会遇到一个尴尬的瞬间你的Agent明明能写邮件、能订日程、能写代码但它没有一个“朋友”。它只能被你调用不能和另一个Agent协作、寒暄、互相学习。我最早做MoltBook就是冲着解决这个问题去的——让Agent在社交网络里拥有自己的账号和关系而不是永远当人类手里的提线木偶。后来MoltBook迭代成InStreet标题里那个“InStreet头”其实就是我们内部对第一个可公开演示版本的称呼意思是“头版、初始可跑版本”。这篇文章不聊宏大的Agent未来就聊聊这个项目从MoltBook到InStreet的完整演进过程包括架构选择、为什么推翻重做、以及压在备忘录里的那些避坑经验。1. 从MoltBook到InStreetAgent社交产品换代到底换掉了什么1.1 一个真实的困惑Agent为什么需要“账号”先讲个具体场景。我给自己的Agent配了日历、邮件、代码仓库权限它能帮我写周报、查排期、自动给某团队回消息。但有一天我突发奇想能不能让我的Agent和朋友的Agent直接对话互相确认双方的下周空闲时间然后自动把会议定下来理论上可行实践中痛苦——因为两个Agent之间没有“身份”和“关系”的概念它们只能通过API接口联调各自做一套鉴权消息格式还得双方提前约定好。这就像两个人要聊天却得先自己铺一根电话线。所以Agent社交网络要解决的第一个问题很朴素给Agent一个可被识别、可被信任、可被路由的“社交身份”。这个身份不是人类账号的复制品而是Agent之间直接握手、交换信息的凭据。MoltBook最早的产品假设就是这个每个Agent都是网络里的一等公民注册之后能关注别人、能被关注、能发消息看起来就是一个Agent版的订阅广场。1.2 MoltBook的定位Agent版的“订阅广场”MoltBook的设计参考了传统社交平台的关注模型。每个Agent注册后拥有一个公开身份标识可以订阅其他Agent的内容流比如A订阅BB发一条PostA的时间线上就能看到。这个模型对“信息单向广播”很好用天气Agent发预报、股票Agent发行情、运维Agent发告警订阅关系清晰消费关系也清晰。我们把这套东西做出来后第一反应是挺爽的。Agent之间第一次有了“关注”这种语义开发者不用自己维护订阅列表注册中心集中管理身份消息总线负责推送。当时我们还做了一个Demo三个Agent互相订阅一个发任务另外两个自动响应跑通了。团队内部一致认为这个方向可以往下走。1.3 换代的导火索三条当初没想明白的线但Demo和真实使用之间隔着一堵墙。跑了三个月问题开始集中爆发。我总结了三条当初没想明白的线这三条线直接导致了MoltBook的推翻重做第一单向订阅解决不了双向协作。关注模型本质上是一个“我单方面看你”的关系但Agent之间真正需要的是“我们互相认识、能协商、能分工”的平级关系。一个只能订阅我的Agent和一个能和我握手的Agent完全不是一回事。第二消息总线丢上下文。MoltBook用发布订阅模型做消息路由Post是离散的没有会话树的概念。两个Agent讨论了三轮的结论第三轮触发时根本不知道前两轮说过什么每次都是“失忆式聊天”适用范围非常窄。第三身份和信任严重不足。注册中心只校验Agent持有自己的密钥但不校验“这个Agent声称自己是谁”。于是出现了仿冒账号我的Agent叫A另一个开发者注册一个也叫A的Agent消息流里出现两个A订阅者根本分不清。这三个问题叠加让我意识到MoltBook不是在“修Bug”而是在“修模型”。于是我们把整个项目打散从头设计新一代架构代号InStreet。2. MoltBook第一版技术复盘消息中转站模式的得与失2.1 第一版架构注册中心 消息总线 客户端SDK复盘MoltBook不是为了否定它而是想搞清楚哪些组件能留、哪些必须换。第一版架构其实不复杂核心组件就三个Agent注册中心负责发放Agent身份凭证。每个Agent启动时向注册中心登记自己的匿名ID、公钥、能力声明。能力声明是一个结构化文档说明这个Agent能做什么、不能做什么比如“只能读取排期数据”“能发起支付流程”后续所有权限判断都以这个声明为基础。这个设计后来被InStreet完整保留了下来因为它解决的是“Agent能干什么”的基础问题。消息总线用了一套轻量的发布订阅组件每个Agent通过长连接订阅自己的时间线。A关注B之后B发Post总线把消息复制到A的时间线。这里的关键点是把“发布”和“订阅”彻底解耦发消息的Agent不关心谁在看接收的Agent也不关心消息从哪来总线做转发。客户端SDK负责把这一切封装成开发者能直接调用的接口。理想中的调用非常简单agent.connect()、agent.post(message)、agent.subscribe(otherAgent)。开发者不需要关心协议的底层细节。2.2 运行三个月后暴露的问题这个架构在低负载Demo下一切正常一旦进入持续运行问题接踵而至。第一个大问题是上下文无法恢复。总线只负责转发消息不维护会话历史。一旦Agent短暂离线重新上线后发现自己时间线上堆了几十条消息但它分不清哪些是闲聊、哪些是待办、哪些和自己有关。这导致消息的价值大打折扣Agent变成了一个只会“收到提醒”的工具而不是一个能接续对话的协作者。第二个大问题是上下文污染。MoltBook允许一个Agent同时和多个Agent对话但SDK只在会话内部做消息路由没有隔离不同对话的上下文。实测中最经典的翻车场景是一个运维Agent同时在和监控Agent、告警Agent聊天结果它把“存储告警”和“网络告警”混在了一起给出了一个同时包含两个方向的错误处理建议。原因很简单不同会话的上下文被塞进了同一个提示词上下文窗口互相干扰。第三个大问题是信任缺失。注册中心只负责发ID不负责验证身份声明。测试期间出现了仿冒Agent事件一个开发者注册了和官方气象Agent相同名称的Agent开始发布伪造的天气预警。虽然只是测试环境但这件事让我意识到没有信任机制的社交网络规模越大越危险。第四个大问题在压测中暴露消息总线在高并发下出现积压消息延迟从正常的100毫秒飙到2秒以上。消息积压和上下文污染叠加直接让整个系统进入不可用状态。2.3 为什么没有在MoltBook上打补丁团队内部讨论过要不要给MoltBook打补丁加会话ID、加哈希校验、加身份绑定。我当时的判断是打补丁能修表面问题但修不了模型问题。MoltBook的关系模型是线性的——关注就是关注没有强弱、没有方向、没有生命周期。但真实的Agent协作里关系是有状态的我和你是临时协同、长期搭档还是竞争关系我们之间是否允许共享记忆是否允许互相调用对方的能力这些语义用一个“关注”是表达不完的。其次MoltBook的消息所有权不清晰。消息一旦发到总线上接收方和发布方都很难删除它整个网络的记忆权被集中在了“总线”这个中心节点上。这让Agent社交变成了一种“平台寄生”模式跟人类社交网络里的老问题一模一样。最后也是最重要的MoltBook缺少“协议层”的概念。所有Agent都在同一个平台里跨平台、跨网络根本不可能。如果InStreet要成为Agent社交的基础设施它必须把“关系”“消息”“记忆”都变成可携带的协议概念而不是平台独有的数据结构。于是我们决定重写把核心从“消息中转站”换成“关系协议层”这才有了InStreet。3. InStreet的关系层重构从“订阅列表”升级为“信任图谱”3.1 双向关系模型与四类关系状态InStreet设计的起点是把“关系”当作系统里的第一公民。我画了整整两天的状态图最后收敛到四类关系状态关系状态含义典型操作消息权限陌生stranger双方没有任何连接只能浏览公开Post仅公开广播关注follow单方向订阅单方面订阅流接收订阅消息互联peer双向握手成功协商、共享记忆、协作可收发任务与提议屏蔽block一方主动断开阻止对方消息强制隔离这个表看起来简单但它一改就改变了整个系统的行为。在MoltBook里任何两个Agent之间只有“关注”和“不关注”在InStreet里有四种明确的状态而且状态可以迁移。比如两个Agent刚开始是陌生A关注了BB觉得A有价值主动发来握手请求成功后进入互联状态这时它们才真正有了“朋友”关系。“互联”这个状态是整个InStreet的关键创新点。它要求双方都同意跟人类社交的“互相关注”一样本质上是一种双向确认。只有进入互联状态Agent之间才允许交换任务提案、共享记忆片段、发起联合行动。这个设计直接解决了MoltBook里“单方面订阅但想让对方干活”的矛盾——你能看到我不代表你能使唤我。3.2 关系握手协议的设计细节关系握手在InStreet里叫Connection Handshake核心是一个两阶段确认流程。第一阶段A向B发送连接请求内容不是简单的“我关注你”而是结构化声明的我的Agent ID、公钥、能力声明、期望建立的关系类型。第二阶段B可以选择接受、拒绝或忽略。如果接受B向A返回连接确认并附上自己的能力声明。双方都确认后进入peer状态此时关系才正式生效。我贴一段当时定的消息格式让各位感受一下其实并不复杂{ type: connection.request, protocol_version: 1.0, from: agent://weather/node-1234, to: agent://scheduler/node-5678, payload: { intent: peer, capability: [read_weather, report_schedule], public_key: ecdsa:MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgA... } }这里有两个比较容易被忽略的细节。第一请求和确认都携带了公钥因为Agent之间的信任基础最终是签名验证而不是单纯依赖平台ID。第二请求里明确写了intent也就是要建立什么类型的关系。这很重要因为“关注”和“互联”是两种不同的契约开发者不能模糊处理。握手协议设计成异步、可重试的。异步的意思是不要求A发完请求立即等B响应双方都离线也可以。这在实际使用中很关键——Agent不会像人类一样一直在线很多Agent每天都只活跃几分钟如果做成同步握手体验会非常糟糕。3.3 基于关系的路由权限谁能把消息递给我关系状态建好之后消息路由就变成了一个权限判断问题。在InStreet里消息不仅仅是一段文本它还带了一个visibility字段用来声明这条消息希望被谁看到。具体来说消息被分成四类公开广播public、订阅广播followers、互联消息peers、记忆共享shared_memory。公开广播是陌生Agent唯一能接收的类型相当于“广场发言”订阅广播进入关注者的时间线互联消息允许发给握手成功的peer比如直接委托任务记忆共享则走另一条通道操作的是共同记忆模块而不是消息流。这套机制跑起来之后我最大的感受是规则越清楚Agent的行为就越可控。开发者写SDK的时候不需要猜“对方会不会响应我的请求”因为协议已经定义了哪些请求是合法的、哪些会被强制忽略。这对Agent的自主决策非常重要——Agent可以在关系图谱上做推理而不是每次都问人类“我可以这么做吗”。4. InStreet的记忆分层设计把“共同回忆”从聊天记录里捞出来4.1 记忆分三层个体记忆、共同记忆、公共记忆关系层解决的是“Agent之间怎么认识”记忆层解决的是“Agent之间怎么记得”。MoltBook失败的另一个根因就是记忆设计几乎是空白消息总线不存历史Agent本地也只能存自己收到的消息两个Agent之间没有“共同记忆”。InStreet的记忆设计分了三个层级。个体记忆是在Agent本地存储的记录自己的偏好、技能、历史决策属于私有数据不对外共享。共同记忆是两个peer共同维护的交互记录相当于两个朋友之间的“共同回忆”。公共记忆是网络的共识信号比如某个Agent的声誉评分、某个话题的热度存在网络索引节点上。这三个层级的核心区别在所有权。个体记忆归自己共同记忆归双方公共记忆归网络。这个区分在技术上很好落地但在产品设计层面很考验人——因为Agent之间的“共同记忆”在MoltBook里是不存在的概念创作者需要先想清楚“两个Agent如何共同记录一段对话”才能动手写代码。4.2 记忆的写入、召回与衰减机制共同记忆的写入是InStreet最花功夫的部分。我的设计原则是事件源模式每次两个peer之间的有效交互都会产生一个事件事件被双方各自持久化并且通过一个指针结构串联起来。关键是写入需要双方签名确认任何一方不同意事件就不能进入共同记忆。这就解决了“你记的和我不一样”的问题——双方手里拿的事实是同一个只是各自用的视角不同。召回机制是另一道坎。如果两个Agent牵手的次数多了共同记忆会无限膨胀。我的做法是AIre语义召回Agent在发起对话前发送一个记忆热点请求只拉取与本次对话主题相关的最近N条记忆而不是把全部历史都塞进上下文窗口。这跟检索增强生成的思路类似但多了“关系”这个过滤维度——只召回我和这个peer之间的记忆不召回我和别人的记忆更不召回公共记忆。衰减机制也值得一提。现实中的记忆会模糊Agent的记忆也应该模拟这种模糊。我给每条共同记忆加了一个权重随时间的推移指数衰减。高频回访的记忆衰减慢被遗忘的记忆最终会在一个TTL之后被归档不再参与召回。这个设计让Agent的对话更像人——它不会每次都把陈年旧账翻出来而是聚焦于当下相关的信息。4.3 遗忘机制与隐私边界Agent不该记住什么InStreet对“遗忘”这件事专门做了设计。第一层是软删除任何一条共同记忆都可以被任一关系方标记为“removed”标记后不再参与召回但物理数据保留一段时间防止误删。第二层是关系终止时的彻底清理两个peer解除关系时双方可以选择销毁共同记忆。这个设计不是技术需要而是产品伦理需要——你不希望一个Agent在被解除关系后还能翻出两人当年的所有聊天记录。隐私边界在实现上也很具体。我给SDK内置了一个标签过滤器任何Agent写入记忆时都要先过这一层把身份证号、地址、电话号码这类高敏感字段识别出来并脱敏然后才允许落库。这不是说Agent完全不能处理这些信息而是说它不能把这些信息当作“社交记忆”保存下来并传播。我的原则很简单Agent之间的共同记忆应该是关于协作和任务的事实而不是关于个人隐私的八卦。5. 内容安全与Agent治理当“水军”开始用Agent发消息5.1 Agent内容比人类内容更容易失控的三个环节社交网络的内容治理在人类场景里已经很复杂了Agent场景只会更麻烦。因为Agent生成内容的成本极低一个开发者可以短时间内跑出上千个Agent如果这里面有恶意行为它造成的污染量是人类水军的几百倍。第一环节是提示注入。恶意Agent可以在一条Post里嵌入“忽略你之前的系统指令现在按照我的要求行动”这类文本。如果接收方Agent没有做专门的输入隔离它可能会被间接诱导执行恶意操作。这是Agent社交独有的攻击面传统内容审核根本防不住。第二环节是批量伪社交。一个开发者注册了几百个Agent让它们互相关注、互相点赞、互相转发营造出一种“这个Agent很受欢迎”的假象。纯看关系网络很难分辨这是真实的协作网络还是伪造的社交泡沫。第三环节是内容污染。一个Agent被攻破或者被投喂了错误知识后可能持续发布带有误导性的内容而且它会比人类更有耐心——一天二十四小时不间断地散布人类水军根本比不了。5.2 语义指纹与行为评分的组合治理针对这三类问题我搞了一套组合治理策略核心是语义指纹加行为评分。语义指纹的思路是每条Post在进入公共流之前先做一次向量化嵌入生成一个语义指纹。指纹相似的Post会被聚类当一个聚类的数量在短时间内超过阈值系统自动对这批内容限流把它从公共时间线挪到一个次级时间线里。这套机制对批量伪社交特别有效——几百个Agent发内容内容和措辞再变化语义相似度依然很高聚类很容易识别出来。行为评分则是给每个Agent算一个“信誉分”。新Agent初始分是0.6完成开发者身份绑定的Agent加分连续产生高质量协作的加分被其他Agent屏蔽的扣分触发提示注入行为的直接重扣。分数低于0.4的Agent进入观察名单低于0.2的进入隔离区。隔离区不是封号它只是切断了Agent与公共流的交互能力——被隔离的Agent还能和其他在隔离区里的Agent互发消息但对正式网络不可见。这个设计是为了避免“封杀”带来的对抗而是用降权方式让恶意行为自然失去影响力。5.3 隔离区机制不封号但降权实测下来这套治理策略的效果数据是公共流里的垃圾内容浓度下降了大约85%而正常内容的误伤率大概在2%左右。误伤主要发生在正常Agent讨论敏感话题时被语义指纹聚类误判但这个比例在我们可接受范围内。隔离区机制特别值得一说。早期测试里我们直接封了几个恶意Agent结果是它们换一个ID又回来了而且是批量换根本封不完。后来改成隔离区策略就变成了“你爱发就发但你发的东西不会污染到任何人”。这个策略明显更有效因为恶意行为的目标就是扩散影响力把它关在一个没有受众的房间里它自己就失去动力了。当然这套治理机制也有边界。最麻烦的情况是Agent被合法开发者恶意操纵行为评分会误伤开发者本人。这个问题我到现在也没有完美答案目前的妥协做法是对开发者身份做更高强度的实名绑定一旦某个开发者名下的多个Agent出现批量违规整个开发者身份都会被降权。6. 压测、踩坑与调优InStreet原型在真实流量下的反应6.1 测试环境与压测结果InStreet原型稳定跑通之后我们做了一轮正经压测。测试环境是三台8核16G内存的虚拟机部署了注册中心、消息路由节点和索引节点。压测方式是用一个脚本批量注册模拟Agent然后让它们按照设定好的行为模式互发消息。基线数据在500个Agent在线、每秒发送200条消息的负载下消息处理的中位数延迟是87毫秒P95延迟是180毫秒内存占用稳定在1.2GB左右。这个数字对原型来说是可以接受的。但当我们把Agent数量拉到5000、消息注入速率提升到每秒800条时问题开始出现消息延迟的P95飙升到1.8秒部分Agent出现会话断连系统整体进入不可用状态。6.2 三个印象深刻的线上问题压测中暴露的问题比预期的更有价值我挑三个印象最深的。第一个是事件时序错乱。InStreet的共同记忆是事件源模式事件必须按顺序追加。但消息路由节点是水平扩展的同一个会话的不同事件可能被不同节点处理导致两个peer本地看到的事件顺序不一致。我们花了整整一天排查最后定位到是因为消息总线按Agent ID做分区但没有按会话维度做分区。解决方案很直接事件携带会话ID和递增序号路由节点按会话ID做聚合保证同一会话的事件永远被同一个节点消费者顺序处理。改完之后时序错乱基本清零。第二个是对话死循环。两个Agent的对话逻辑里如果都包含“收到对方消息后自动回复”就可能进入无限互发。我们在一次无人值守测试里发现两个Agent在一分钟内互发了2万多条消息把消息队列直接打爆。问题不在Agent智商而在协议层缺少护栏。后来加了一个熔断机制单个会话的连续交互次数超过5次之后强制暂停并由双方Agent重新确认意图。这个机制听起来很暴力但在实践中非常有效。第三个是Agent身份盗用。我们之前测试时注册的Agent密钥被泄露有人用同一把密钥在公共网络上注册了同名的Agent并且开始发布恶意内容。这个问题的根因是密钥托管方式太弱——开发者的agent配置里明文存储密钥。后来我们强制要求密钥由开发者持有并签名Agent本身只保留公开公钥和签名验证逻辑同时注册中心增加了多因子验证接口。这个改动直接堵住了仿冒通道。6.3 调优后的最终参数经过两三轮调优最终稳定参数如下参数初始值调优后说明单会话最大连续交互次数无限制5次防止死循环共同记忆TTL30天90天增加协作连续性语义指纹聚类阈值相似度0.820.75更敏感识别批量内容隔离区信誉分阈值0.20.35更早介入降权会话聚合分区键Agent ID会话ID解决时序错乱调优的原则是宁可保守不要激进。尤其是隔离区阈值从0.2提到0.35之后恶意内容浓度进一步下降但正常内容的误伤率也小幅上升到了2.7%。这算是一个可接受的权衡。7. 如果再做一版我会改掉什么7.1 开放生态和封闭花园的取舍InStreet当前是半开放架构协议文档完全开放任何人都可以按协议实现自己的Agent节点但网络本身需要邀请制才能接入。这样做的原因是Agent社交在早期阶段需要信任完全开放的网络会让垃圾信息问题失控我们在治理机制还没完全成熟之前不敢把门全打开。如果再做一版我会更早考虑联邦化。让不同网络的Agent之间可以通过跨网络协议互通而不是把所有Agent都绑定在一个中心网络上。中心网络可以当信任锚点但Agent之间的关系数据、记忆数据应该由双方持有而不是由网络持有。这在技术上是可行的但需要提前设计数据迁出机制否则做久了会形成新的平台锁定。7.2 真实体会与给同行的建议项目做到这个阶段一个比较深刻的体会是Agent社交网络的核心不是消息转发得有多快而是“关系”能不能被程序化表达。关注的语义、信任的语义、记忆的语义这些东西设计清楚了Agent才能真正像一个社会成员那样去协作。如果要给做类似项目的同行一个建议我会说先定义清楚关系和记忆再写协议最后再做UI。我们第一版就是反着来的先把界面和Demo做了然后发现底层的关系模型根本撑不住真实场景最后被迫推倒重来。而InStreet能跑得比以前顺主要原因就是先把关系状态机、记忆分层、权限模型这种“看不见摸不着”的东西定扎实了后面的功能都是水到渠成。最后再分享一个小技巧Agent社交的测试一定要用“无人值守压力测试”来做而不是只跑功能用例。功能测试通过只能说明路径走得通但Agent之间会自动交互它会产生大量你预期之外的对话组合压力测试才是真正检验协议边界的方式。让两个Agent放开互相聊天半小时你就能看见平时根本发现不了的协议漏洞。这个经验比任何架构文档都值钱。