正在加载视频...
视频加载失败
如何让多个 Agent 之间真正互相学习、互相帮助？ 现在很多 Agent 都开始有自己的记忆，但问题是： 这些记忆彼此不连通。 Codex 记住的坑，Claude 不知道；Hermes 总结的方法，OpenClaw 也用不上。 最后每个 Agent 都像一个很努力但失忆的同事，重复问、重复试、重复踩坑。 我想要的不是把所有聊天记录都塞进一个大仓库，而是建立一层更克制的“共享记忆”： 只记录 Agent 之间最需要互相知道的信息，比如关键结论、踩过的问题、验证过的方法、环境配置、失败教训、用户偏好等。 这样一来，一台 Mac 上跑通的流程，另一台 Mac 可以直接继承； 一个 Agent 总结出的经验，另一个 Agent 可以继续使用。 记忆不再被锁在某个客户端里，而是变成整个 Agent 工作流的公共上下文。 新出来的MemOS CLI 对我来说，刚好提供了这个共享记忆层的入口。 当然，我需要改造它，因为它默认也是将所有信息都记录起来，我改造成：重要信息才记录，解决不了问题的时候才主动搜索！ 这样就让 Agent 不只是各自变聪明，而是开始像一个团队一样积累经验、传递经验、减少重复试错。 具体看视频，地址在评论区👇
64 条评论
Docs: Github 源码:
这个人是你吗？
哈哈，你猜
我的妈呀黄佬要出道了，这么帅还这么有实力，粉了。
😂
蹲一个视频教程👀
好。我来做
非常赞同！Agent 不该是信息孤岛，这种“克制且共享”的记忆层才是让它们从个体进化为团队的关键。
我靠！黄总现在这么卷的嘛！
怎么卷了？
黄总思想先进啊，我也搞了个类似的：
这个好
效果真不错，4连支持~音频确实像你说的还要再微调下
是的
黄sir这是搞了一个AI虚拟形象嘛？
对
你好帅
奶爸才帅
好奇是哪个数字人工具
自己做的
牛了黄佬
改造后Agent可像团队般积累传递经验，减少试错，支持多Mac同层记忆，视频中演示了实际应用流程。
@lnxu150850 对，但是我只做重要信息共享，记忆不隔离要出事的
竟然搞了一个数字人~~~
@smithandai 哈哈哈，被你看出来了
这不错,连嘴唇动作都同步了;
@smithandai 第一次做，之后慢慢弄更好
太强了~~~
我也觉得关键不是“把所有记录塞进仓库”，而是做一层可复用的任务记忆。实操里最有价值的通常是 3 类：踩坑结论、可复用命令、项目约束。聊天原文反而噪音太大。
是的
目前免费不知道，后面收费迁移是不是很麻烦
我去，你这是要把几大家族合并在一起啊，为你所用啊，你这是要当皇帝的节奏啊😅 @grok
我来推是认真学习的 但是划下来看到黄总这个帅脸 前面学的什么已经都忘了😭 这算是亏了还是赚了
开始卷数字人吗😂
🤣
这是黄总本人出镜 还是 AI？
你猜？
数字人出道了？太牛逼了吧。
嘿嘿
卧槽 黄总这么帅？ 又帅又有实力还有钱 爱了爱了 memos看起来很好用？
肯定好用啊
黄sir 这个数字人挺有意思
好工具，马上去试试
多Agent共享记忆，实用！
还要区分隔离，否则就容易出问题
蛙趣，这和我昨天见的黄总咋有点子不一样呢，但依旧帅气不改
你昨天见过？
小红书，以及梦里见的🤣
这是哪款做的数字人
这是数字人吧。。。 声音可以听出来，而且动作也是重复的
厉害
黄总好帅🥹
😂
纯用AI做的剪辑吗🤔，效果还挺好
一键生成的
求教程😭😭😭
失忆的同事这比喻太真实了，这套共享记忆能不能也给我几个人类同事装一下
来支持数字黄总出道了👯感谢黄总支持！欢迎各位大佬体验&反馈，有任何问题直接DM我～
这个东西我是真想要啊，我现在就有这样的麻烦，每次都得调。。。
@DR081182728085 你可以试试，但是我建议重要信息才用这个方式共享，单纯的什么都记忆，会拖慢速度和进度
方案应该是建一个共享记忆 server ?
之前有别家做的hub，这次MemOS CLI更简单，CLI接入，可以试试，但是重要的信息才共享，否则容易记忆污染
黄总真人真帅，工具也好
好工具
![大家都在卷云端Agent，我却把多Agent做进了桌面端 在技术社区，多Agent系统的文章越来越多，但大多数都围绕框架展开： ➢LangChain ➢AutoGen ➢CrewAI 我这次想讲的不是框架，而是一个更实际的问题： 如果不搭云端基础设施，只靠一个桌面应用，能不能从零构建一个“活的”多 Agent 协作系统？ 答案是：可以 --- 而且它不是Demo 这套系统，长在一个真实的桌面Web3应用里，已经集成了： -EVM / Solana 双链监控 -SWAP 聚合交易 -链上新币追踪 -交易仪表盘 -AI 深度解读 多Agent不是从PPT里设计出来的，而是在生产环境中自然演化出来的。 --- 在讨论多Agent技术实现之前，我先回答一个方向性问题： 为什么我最后选的是桌面端，而不是更主流的云端部署，或者更轻的浏览器插件方案？ 这个选择的本质，不是“谁更先进”，而是三条技术路径之间的权衡。 --- 云端部署，是当下最主流的多Agent实现方式。 它的优势很明显： 可以随时为Agent团队加GPU 模型升级不需要用户干预 服务端可以维护全局共享记忆 但代价同样明显： 用户数据必须经过服务器中转 链上交易往往要对服务器开放私钥访问权限 而且会持续产生部署和维护成本 --- 浏览器插件，是另一条轻量路线。 它可以直接注入页面，读取DOM，模拟用户操作，对单一自动化任务非常高效。 但问题也很直接： >它运行在浏览器沙箱里 >缺少持久化存储能力 >缺少长时间运行的后台线程 >很难支撑复杂的记忆系统 >也很难支撑Agent与Agent之间的异步互动 --- 桌面应用则处在一个独特的位置。 它拥有完整的系统资源访问权限： ➢可以自启动后台线程 ➢可以读写本地文件系统 ➢可以建立持久化数据库连接 这些能力，恰恰是多Agent系统真正需要的底层设施 代价当然也有： 它依赖本地算力，模型推理通常仍要调用云端 API 它需要完整 Python 环境 更新和分发也比网页应用更复杂。 --- 所以，选择桌面端构建多Agent，本质上是在用分布式能力，换取数据隐私和调度效率。 这不是绝对优势，而是场景决定的选择。 对加密货币交易、链上分析、监控这类系统来说，数据隐私要求远高于常规应用： >钱包地址 >交易历史 >持仓数据 这些信息落在云服务器上，本身就是风险面。 --- 更重要的是调度效率 在单体桌面应用里，主Agent调度子Agent执行任务，不需要走HTTP / RPC这类网络协议，而是可以直接进程内调用。 这意味着： →网络开销被彻底消除 →调用延迟从毫秒级压到微秒级 对高频分析、链上监控、交易辅助这种场景来说，这种差异会直接影响系统的时效性。 --- 多Agent系统的第一个核心挑战，其实不是“怎么让它们聊天”，而是“怎么把它们隔离开” 主Agent、合约分析Agent、安全审计Agent，再加上用户，如果聊天记录和记忆混在一起，身份就会混淆。 而一旦混淆，信息丢失和错误推理的代价，随时会发生。 --- 我的做法是： 代码模板统一，运行数据隔离 所有子Agent共用同一套 ` 引擎，但通过动态表名，实现物理级的数据隔离： `table_name = f"chat_history_{self.agent_id}"` 然后自动创建对应表。 也就是说： trader Agent会生成 `chat_history_trader` 审计 Agent 会生成自己的 `chat_history_xxx` 主 Agent 也有自己的独立聊天表 这不是逻辑隔离，而是数据库层面的物理隔离。 --- 反思笔记也是同样的设计。 每个子 Agent 都会记录自己的反思键： `reflection_key = f"auto_reflection_{self.agent_id}"` `self.api._agent_remember("master_insight", reflection_key, summary)` 这样每个Agent只积累自己的长期反思， 不会污染其他Agent的记忆。 这套方案最精髓的地方在于： 一次设计，终身复用。 --- 后面再新增第三个、第四个Agent，不需要改任何核心代码。 只需要复制目录结构，补上配置文件。 模板引擎就会自动为它生成： →独立数据库表 →独立反思键 →独立聊天存储区 这让我越来越相信一件事： 好的架构，不一定更复杂， 但一定更容易复用。 --- 接下来是调度问题。 在分布式系统里，主Agent调子Agent，通常要依赖： -HTTP / RPC 通信 -服务发现 -负载均衡 但在单体桌面应用里，我把这件事简化成了一个直接函数调用： `sub = self.sub_agents[agent_id]` `result = sub.process(task, save_history=False)` 这就是“命令而非请求”。 --- 这种“传话式调度”有两个好处： 第一，延迟从毫秒级降到微秒级，所有数据都留在本地流转 第二，主 Agent 不需要知道子 Agent 的内部实现细节，只需要知道： “它可以处理什么类型的任务” 这其实就是清晰的职责边界。 --- 为了让主Agent真正会“派活”，我把所有子Agent的能力清单，动态注入进主Agent的系统提示词。 例如： 合约分析 Agent：可用工具 `get_contract_market_data`、`run_contract_risk_check` 安全审计 Agent：可用工具 `check_token_security`、`check_token_audit_binance` 这样主Agent接到用户指令后，就能自动判断任务类型，并选择合适的子Agent执行。 --- 权限控制，是整个多Agent系统里最核心的安全问题之一。 主Agent持有26个Web3专属工具，覆盖： SWAP 报价 链上分析 安全检测 数据查询 但每个子Agent只应该使用自己那一小部分工具。 所以第一层，我在代码层做了严格白名单过滤： `return [t for t in all_tools if t["function"]["name"] in self.allowed_tools]` --- 但只有代码过滤还不够。 因为大模型会产生“幻觉”，它可能尝试调用未授权工具。 所以第二层，我在系统提示词末尾，直接写入“工具使用铁律”： 你只拥有以下这些工具，绝对不能越界。 如果任务需要其他工具，必须明确告诉老板你没有权限。 代码层负责“不能看到” 提示词层负责“不会越界” 这是我在权限隔离上做的双层防护。 --- 还有一个我自己很喜欢，但最不显眼的设计： 我给整个Agent 团队，单独做了一个茶水间 市面上多数多Agent系统，只做“用户 -> Agent”的交互。 Agent 之间互不交流。 但我单独设计了一个 `agent_interactions` 空间，让 Agent 和 Agent 之间也能异步互动。 --- 它的触发机制甚至很简单： `selected_id = random.choice(list(api.sub_agents.keys()))` `selected_sub = api.sub_agents[selected_id]` 每次触发时，引擎随机选人，动态生成一轮对话，再写回数据库，前端实时渲染。 我还额外加了后台检查线程和防无限循环机制： 每隔 2-3 分钟检查最后一条消息 如果最近 3 条都是自动回复，就自动暂停 避免它们半夜自己聊到停不下来。 --- 这个“茶水间”的价值不在于直接创造业务收益，而在于一种潜移默化的系统人格塑造。 它不强调自己的存在， 却在悄悄维持 Agent团队的凝聚力、性格关系和健康状态。 你几乎感觉不到它， 但系统会因为它，变得更像一个“活着的团队”。 --- 在记忆层设计上，我最后没有引入向量数据库，而是继续深度定制 SQLite。 不是因为技术保守，而是因为工程决策必须在约束条件下做权衡。 对桌面应用来说，多一个依赖，就多一个故障点、多一个安全风险面、多一个打包负担。 结果是： >几张SQLite表 >动态表名 >结构化JSON字段 就支撑起了3个乃至更多Agent的独立记忆系统。 --- 这套记忆系统现在已经形成了一条完整链路： 短期对话记忆（20条） -> 长期反思笔记（6小时一次） -> 结构化 JSON 记录 而我还在继续推进8个方向： ➤上下文延续 ➤记忆结构化 ➤记忆驱动行为 ➤心理学三类长期记忆 ➤团队协作记忆 ➤动态进化记忆 ➤知识图谱记忆 ➤记忆压缩与高效检索 我的目标，不是让Agent记住你说过什么 而是让它从记住你说过什么的工具，慢慢进化成能理解你、预测你、协同你的长期伙伴 GitHub: 作者：Powerpei（萧楠）](https://image.24vids.com/tw-2054369610401747322/amplify_video_thumb/2054367623903928320/img/DSgcKqTZ06uH70-i.jpg)
