SpaceXAI 实际发布了什么
五个原语，Bot 胜出
这篇文章始于对词汇疲劳的诊断，这是一个合理的诊断：“对话（Chats）、会话（sessions）、模型（models）、上下文窗口（context windows）、记忆（memories）、系统提示词（system prompts）、项目（projects）、技能（skills）、连接器（connectors）、智能体（agents）、工具（tools）、沙箱（sandboxes）、权限（permissions）和自动化（automations）都描述了这些系统的真实组成部分。”他们的结论是：“将每一个都作为独立的产品概念展示出来，要求用户理解的内容超出了他们的需要。”
他们保留了五个。原文引用如下：
- “Bots 是具有自己身份、记忆、运行环境和工具的持久智能体。”
- “Chats 是与 Bot 协作的对话界面。”
- “Prompts 为 Bot 提供上下文或指令。它们可以单次使用、保存为 Skills，或作为 Routines 自动触发。”
- “Tools 允许 Bots 通过软件、API、连接器、shell 或电脑使用（computer use）来获取信息并采取行动。”
- “Artifacts 是 Bots 创建或修改的文档、设计、代码、数据和其他持久输出。”
注意记忆在列表中的位置。它是 Bot 的属性，与身份和运行环境并列。而不是您的属性。
聊天历史变成了 Bot 花名册
界面带来的结果显而易见：“因此，Grok Bot 中的主要对象是 Bots，而不是对话。Bot 有名字。它有头像和标题。它记得与您的对话。它有自己的电脑和工具。当您明天回来时，您面对的是同一个 Bot。”
侧边栏列出的是 Bots 而不是线程，头像承载着身份，同时兼作状态指示器——“Bot 可能是空闲、思考、工作、等待、受阻或完成状态。”
每个 Bot 还拥有自己的机器：“每个 Bot 都有自己的电脑，可以用来浏览网页、处理文件和运行软件。”访问权限分为三个级别，最后是“Takeover（接管）：当 Bot 需要帮助时，用户可以全屏打开电脑，接管控制权，然后再交还给它。”
关键的分离：能力是共享的，上下文则不是
以下段落值得读两遍，也是本文存在的原因：
“因此，在 Grok Bot 中，能力和上下文遵循不同的边界。Tools 和 Skills 存在于账户级别，因为许多 Bots 可能需要浏览网页、处理文档或发送电子邮件。Memory 和 Routines 属于 Bot，因为它们反映了该特定角色随着时间的推移所了解和做的事情。换句话说，能力可以广泛共享，而上下文则保留在需要它的角色中。”
刻意划分的两个不同范围。他们给出了理由：
“法律 Bot 可能需要正在进行的纠纷的历史记录，而财务 Bot 可能需要多年的财务记录。将这些历史记录合并到一个庞大的记忆中，将更难向每个 Bot 提供与其工作相关的信息。”
这是一个明确反对合并记忆的论点，而且来自一家刚刚围绕持久性重构了其产品的厂商。这值得认真对待，而不是一笑了之。
无需提示词即可启动的工作
还有一点，因为没有主动启动的持久性只是想法的一半：“大多数智能体会话在用户发送提示词时开始。这使得即使是持久的 Bot 也在等待有人来激活它。”Routines 就是答案——“一项根据计划或响应事件运行的常设职责”——它们在设计中期得到了提升：“我们最初将 Routines 视为次要配置。随着它们对自主工作变得越来越重要，我们将它们移到了 Bot 的主界面中。”
Routines 的范围限定在 Bot，与记忆相同。而 Skills 和 Tools 则不是。
同日发布的企业版页面
在发表文章的同时，SpaceXAI 向企业开放了 Grok Bot，并用员工的术语来描述 Bot：“Bot 是您在 Grok Bot 内部为特定工作创建的员工。每个 Bot 都在云端自己的电脑上运行，并且可以像您一样使用每个应用程序和网站。”关于隔离性：“每个用户在 Grok Bot 中的工作都运行在自己安全且隔离的环境中，与其他每个用户分开。Bot 默认没有访问权限，只能访问您登录的账户。”
推广说明指出，Grok 和 Cursor 企业版客户在“接下来的两周内”可以免费使用，并可以邀请整个组织，“包括没有现有席位的人员”。
这改变了什么，没有改变什么
它确实将持久性的单位从会话中移出。 这是实实在在的，也是正确的方向。一个拥有自己状态、工具和常设职责的有名字的实体，比一个需要往回滚动的对话更适合作为积累知识的容器。
它并没有让记忆变得可移植。 Bot 的记忆是该产品内部该 Bot 的属性。文章中没有任何内容表明它可以迁移——而且按角色划分范围使迁移变得更难，而不是更容易，因为知识现在不仅按厂商划分，还按角色划分。
它没有进行合并，这是刻意为之。 如果您运行一个法律 Bot 和一个财务 Bot，它们都不知道对方学到了什么。SpaceXAI 认为这是一个特性，对于单一产品内部的检索质量而言，他们说得有道理。
他们确实承认了共享上下文的问题。 文章并没有假装角色永远不会重叠：“群聊为项目或团队提供了共享上下文，同时允许每个 Bot 保留其专业记忆。”因此，在他们的模型中也存在一个共享层——它是一个限定在项目范围内的对话，而不是一个存储库。
它并没有消除协调问题，而是转移了它。 他们的答案源于实际使用：“有些人创建了一个 Chief of Staff Bot，负责协调几个专家。”在 Bot 之间路由工作的 Bot 是一个合理的模式，而且它也是一个对路由拥有自己独立记忆的 Bot。
人们会从中得出什么误解，以及为什么不应该
“每个 Bot 独立的记忆意味着记忆问题已解决。” 仅在单一产品内、针对单一角色得到了解决。以前困难的事情——在切换工具时了解您的惯例——依然没有改变。这与持久记忆究竟是什么中所涵盖的区别相同。
“那么，一个庞大的统一记忆是个错误。” 这是一个值得仔细纠正的误读，因为 SpaceXAI 的论点比听起来要窄。他们反对的是将角色历史记录合并为一个大杂烩——将多年的财务记录和活跃的法律纠纷倾倒进单个存储库中，并寄希望于检索来解决它。这是一个真正的检索问题，他们在这点上是对的。
他们并不反对持久事实的共享源——您的架构决策、您的领域词汇、您的惯例。这些不是某一个角色的历史；它们对每个角色都是相同的，每个 Bot 分别重新学习它们是浪费，而不是保持整洁。划分历史范围和共享事实是不同的举措，而文章捍卫的只是前者。
“所以我应该给每个 Bot 相同的指令。” 将相同的上下文复制到五个 Bot 中是一种临时应对方案，看起来像是一个能维持大约一个月的解决方案。然后，其中一个副本得到了修正，而其他副本没有，结果您就会得到五个专家，它们对您的惯例自信地各执一词——这就是多智能体记忆中描述的失败模式。
“Routines 使其具有自主性，所以我可以不用再考虑上下文了。” Routines 决定 Bot 何时行动。它们不决定它知道什么。一个每天早上在陈旧上下文中运行的 Routine，每天早上都会运行出错。
“Takeover（接管）意味着我可以监督一切。” 三个访问级别正是为了避免这种情况而设计的：“我们越是突出电脑，产品就越鼓励用户去监督它。”Takeover 是一条异常路径，而不是一个工作流。
解决方案：划分历史范围，共享事实
步骤 1：将您的上下文分类为历史和事实
拿出一个您实际使用的 Bot，阅读它积累的内容。将每一项分成两堆。
历史（History）。 这个角色按顺序做过什么、决定了什么以及被告知了什么。纠纷时间线。收集的收据。寻找的候选人。这属于 Bot，SpaceXAI 说的没错，跨角色合并它会使检索变差。
事实（Facts）。 无论谁问，对您的组织来说都是真实的信息。您的 API 是如何进行版本控制的以及为什么。您的内部术语意味着什么。哪个团队拥有什么。您的写作规范。您的合规约束。
第二堆是会被默默复制的内容。您创建的每个 Bot 都需要其中的一部分，而按角色分配记忆意味着每个 Bot 都要从头开始重新学习它——或者不学习，从而出错。
步骤 2：在创建第五个 Bot 之前，决定每个 Bot 的共享上下文来自哪里
两个 Bot 还可以手动管理。五个 Bot 时，副本就会开始出现偏差。
看看 SpaceXAI 已经将什么限定在账户范围：Tools 和 Skills，因为“许多 Bots may need to browse the web, work with documents, or send email.”这正是适用于事实的推理。能力的边界划定在“许多 Bots 需要这个”；将同样的测试应用于知识，您会得到相同的答案。
实际上：对于每个 Bot，写下它需要哪些共享事实以及它目前从哪里获取这些事实。如果答案是“我在它的第一次对话中输入的任何内容”，那么这就是那个会发生偏差的副本。
在这里，群聊值得刻意使用。它们“为项目或团队提供共享上下文，同时允许每个 Bot 保留其专业记忆”，这非常适合特定项目的重叠，而不适合常设惯例——群聊是一个对话，而惯例应该比对话存在得更久。
步骤 3：将事实放在没有 Bot 拥有的层中
结构性修复是账户级 Tools 边界已经暗示的：许多 Bots 需要的东西不应该存在于其中任何一个 Bot 内部。
产品之外的记忆层对知识起到了这种作用。每个 Bot 保留自己的历史——限定范围、专业化，正如 SpaceXAI 设计的那样——并从不属于任何 Bot 的存储库中读取共享事实。创建第六个专家不再意味着对您的惯例进行第六次解释，而且一次修正就能全部生效，而不是修改五次。
它还能在每个 Bot 记忆无法生存的情况下存活下来：您接下来使用的工具。MemoryLake 只需三个步骤即可设置完成。
步骤 1：创建 API 密钥
登录并从您的仪表板生成一个 API 密钥。它属于您，而不是属于某个 Bot、账户或产品，当您的角色分布在多个厂商中时，这一属性至关重要。
步骤 2：上传您的第一批记忆
放入步骤 1 中的第二堆内容：架构决策及其原因、领域词汇、服务所有权、常设偏好、每个角色都必须遵守的约束。
将历史记录留在原处。Bot 对自己工作的记录正是应该限定在该 Bot 范围内的内容。
步骤 3：连接您的 AI 和智能体
将您的智能体指向该存储库。一个新的专家将从您组织的事实开始，而不是从零开始，并且事实在一个地方保持正确——这就是跨工具同步 AI 记忆而不是按产品同步的意义所在。
这在实践中改变了什么
第一个变化是创建专家的成本变低了。目前，一个新 Bot 的成本包括重新教它所有通用的东西，这在无形中阻碍了该设计所针对的细粒度角色的创建。
第二个变化是修正不再需要进行 N 次。只需修复一次惯例，每个角色都会读取修复后的版本，而不是它碰巧被告知的版本。
第三个变化是，角色范围划分变成了一个真正的设计选择，而不是您需要绕过的约束。当共享事实来自共享层时，保持每个 Bot 的历史记录精简不会让您付出任何代价——这正是 SpaceXAI 最初想要的，也是在智能体记忆中保留更少内容背后的相同论点。
按角色划分智能体记忆的最佳实践
- 在扩展之前，将历史与事实分开。 历史属于角色；事实属于所有人。
- 将 Tools 测试应用于知识。 如果许多 Bots 需要它，它就不应该存在于其中任何一个内部。
- 不要将共享上下文复制到每个 Bot 中。 这会导致偏差，并且这种失败是无声无息的。
- 将群聊用于项目重叠，而不是常设惯例。 对于必须比对话存在得更久的东西来说，对话是错误的归宿。
- 将协调 Bot 视为路由器，而不是记忆。 它自己的记忆是关于路由的，而不是关于您的领域的。
- 在调度 Routine 之前，检查它知道什么。 自主性会放大 Bot 拥有的任何上下文，包括错误的上下文。
- 将 Takeover（接管）作为一种异常情况。 该设计刻意不鼓励监督；经常使用它意味着 Bot 获取的信息不足。
- 随着变化重新检查。 Grok Bot 是新产品，企业版优惠是有时限的，如此新鲜的设计决策往往会发生变化。
结论
这是今年 AI 厂商发表的较有深度的一篇产品文章，其核心主张也是我们所赞同的：对于您想要保留的任何内容，会话从来都不是正确的单位。
它比我们走得更远的地方在于，它得出的结论是上下文因此应该与角色共存。对于历史记录，这是正确的且论证充分。但对于每个角色都需要的事实，它把一个共享问题变成了每个 Bot 都有一个问题。按照 SpaceXAI 设计的方式划分历史范围。将事实放在没有 Bot 拥有的地方。