每日快讯 · 2026-11-10

开源项目 LoreKit 发文指出，当前各类编程智能体的记忆格式互不兼容：CI 智能体学到的经验，编辑器智能体读不到，下一个工具也读不到。作者认为问题不在于缺少工具，而在于缺少一份社区共同达成的格式约定，并主张借鉴 OpenTelemetry 在 2019 年统一可观测性数据格式的经验，为智能体记忆制定共享规范。

· 现状是格式碎片化：每个记忆层都有自己的存储、schema 和 MCP（模型上下文协议）工具，Reddit 上不断有人发布自建记忆层，但每个新方案都只是又增加一种别人读不了的格式。

· 已有若干探索：MacPaw Research 的 Portable Memory 是可复现序列化的 .mem 包，Open Memory Protocol 是 2026 年 4 月的草案，Cognee 的 COGX 可从 Mem0、Letta、Zep 导入。它们主要解决导出问题，即把一个人的记忆从厂商 A 迁到厂商 B，尚未解决多个智能体在同一仓库中实时读写同一地址的「实时寻址」问题。

· 所有格式本质上都在回答五个问题：记忆在哪里为真、身份是什么（二次写入是更新还是重复）、内容是什么、何时失效、哪个版本最新。唯一真正的分歧是「谁写入记忆」：指令文件由人写，Letta、LoreKit 由模型写，Mem0、Graphiti 由服务从对话中抽取事实。规范不必二选一，但必须记录来源，让读者知道该信多少。

· 作者给出记录模型示意：frontmatter 作为信封，包含 address、id、lifecycle、written_by、version 与 supersedes；正文是 Markdown 记忆本身。规范应仿照 OpenTelemetry 分层，把存储、排序、嵌入和界面留给工具竞争，并托管在中立机构，而非某家厂商的仓库。

为什么值得关注：智能体记忆正处在可观测性 2019 年前的碎片化阶段，而 MCP 与 AGENTS.md 已归入 Linux 基金会下的 Agentic AI Foundation，为中立规范提供了现成归宿。统一记录格式是智能体之间共享经验、跨工具协作的前提。

AI 工厂正在把网络变成计算系统的一部分。RIPE Labs 的这篇文章从网络运营商视角出发，梳理 AI 工厂内部的加速器网络、园区之间的专用光链路，以及最终落到公共互联网上的推理与智能体流量，并讨论电力如何决定这些设施建在哪里、哪些流量运营商看得见、哪些看不见。

· 电力比数据更难搬运，直接决定选址。国际能源署把传统数据中心规模定在约 10–25 MW，超大规模 AI 设施为 100 MW 以上，单个项目已达吉瓦级。Google 明确表示，输电比光纤传数据更难，因此把数据中心建在能源附近，再用网络把多个园区的 AI 算力池化；微软也用专用光网络连接威斯康星和亚特兰大的 Fairwater 站点。

· 工厂内部流量规模惊人，却完全不出现在互联网流量图上。Google 称其 Virgo 网络可在单一 fabric 内连接多达 134,000 颗 TPU 8t 芯片，非阻塞二分带宽高达 47 Pb/s；Meta 则描述过检查点突发流量拥塞数据中心网络、导致 GPU 空转的情况。

· 园区之间靠私有互联和专用 AI 广域网搬运检查点与副本。Meta 表示其 AI Backbone 中一对站点的规模，是过去十年建成的全球骨干网的两倍，这为光纤和 DCI 供应商带来交付日期明确的私有容量需求。

· 真正到达运营商的公共流量有两类。Cisco 测量显示，推理流的中位持续时间约为非 AI 网页流的两倍；在一次受控任务中，智能体产生的总流量比人工完成同一任务多出至多 450%。PeeringDB 因 AI 爬虫导致服务降级，对未认证访问引入限流；Fastly 发现其归类为 AI 机器人的请求中超过一半到达源站，而人类请求这一比例不足 9%。

· 推理不等于 CDN 缓存。CDN 可以把可复用对象放到用户附近，但推理需要真正执行模型，最近的缓存、服务入口和跑模型的 GPU 可能分处三地，例如 AWS Bedrock 跨区域推理可在一个区域接收请求、在另一个区域处理。Meta 在 RIPE 92 上表示，不预期部署在 ISP 网络内的前置设备承载高功耗 GPU，并估计五到八个欧洲地点即可覆盖其当前 99% 的 AI 用例。

为什么值得关注：智能体流量正在以远高于人类的请求密度冲击源站和互联点，而支撑它们的算力网络大多藏在私有光纤里。对智能体互联网而言，这意味着容量规划、限流策略和互联结算都需要重新设计，运营商的可见性边界将直接决定智能体服务能否稳定扩展。

DeepSeek 团队在 GitHub 发布 dsh-superagent-prototype，一个面向单个 GitHub 仓库的主动式编码智能体研究原型，以 bundle 形式打包给 DeepSeek Harness 使用。官方明确声明这只是研究代码，并非正式产品，也非生产可用软件，可能与团队内部版本及论文《Exploring Super-agent Design》描述的实现并不一致。

· 工作方式：智能体监听 GitHub，也可选接入飞书。当被允许的人提出需求时，它会创建一个工作项，在自己的智能体会话和目录中处理，并回到原对话中答复，例如提交一个 pull request；另有一个 Web 面板展示需要人工介入的事项。

· 设计哲学：项目追求「占用尽可能少的人类注意力、产出尽可能多的价值」。由于一个能替整个团队行动的智能体也可能浪费整个团队的注意力，它只在被请求、或团队预先写好的规则允许时才行动，且只在必须有人处理或结果可被使用时才发声，相关原则写在 docs/000-philosophy.md 中。

· 安装方式：配置步骤较多，因此由智能体陪同完成。用户只需对自己的编码智能体说「阅读本仓库的 SETUP.md 并和我一起配置 dsh-superagent」，它便逐条提出简短问题、一次性展示完整计划，然后完成安装与配置。

· 代码与文档：项目文档按编号顺序阅读，每篇只依赖前面的内容；pnpm check 可一次性运行类型检查、测试与构建。团队坦言代码大量由编码智能体完成，风格与工程实践可能不统一，使用前需自行审查和调整。

为什么值得关注：它展示了「超级智能体」的一种落地形态——以仓库为边界、以规则约束行动、以最小人类注意力为设计目标，为智能体互联网中智能体的权限边界、主动性与打扰成本之间的平衡提供了可参考的工程样本。