交易涵盖的内容以及公告留下的悬念
首先来看被收购了什么。新闻稿中点名的资产包括 Cosmos、Auggie CLI、Code Context Engine 以及相关技术。Cosmos 未来的角色被直接阐明：“Cosmos 将成为 Harness Cosmos Software Factory Agent，其职责非常明确：实现从创意到代码的工程工作自动化。”新闻稿还提到“Harness Cosmos 现已推出”。
新闻稿中有两行提到了上下文。第一行是关于索引的：“Augment 的 Code Context Engine 保持着代码库的实时地图，因此更改能够契合已有的代码。”第二行是关于记忆的：“共享记忆将每次审查的经验带入下一次更改中。”这两者都被描述为 Harness Cosmos 未来提供服务的一部分。
Harness 自己的博客文章为现有用户补充了一句话：“客户可以采用 Harness Cosmos Software Factory Agent，继续使用他们首选的编码工具，或者两者兼用。”它还提到这些产品和团队：“我们正在对这些产品、技术以及构建它们的团队进行投资。”
公告及其常见问题解答（FAQ）未说明的是针对现有账户的具体机制：当前的 workspace、索引和 Expert 记忆如何迁移，计费或数据处理是否会有所变化，或者 VS Code 和 JetBrains 的 Augment 插件会发生什么（新闻稿中并未将这些插件列入收购资产）。这本身并不意味着会出现问题。这只说明发布的内容是关于方向的，而针对现有客户的运营细节将直接由 Harness 和 Augment 提供。
这一空白正是现在进行盘点的意义所在。你无需等待电子邮件，就能知道你的哪些上下文在设计上是可移植的。
保存在仓库中的上下文
Augment 的文档明确指出了规则和 workspace 指南的存储位置：“Workspace Guidelines 和 Rules 直接存储在你的仓库中。”CLI 文档对 workspace 规则也说了同样的话：“Workspace 规则存储在项目仓库中，且仅适用于该特定项目。”
Augment 还会读取与工具无关的文件。它的规则层级除了 .augment/rules/ 之外，还包括 CLAUDE.md 和 AGENTS.md，并且它会在你工作时发现子目录中的 AGENTS.md 和 CLAUDE.md。你的团队写入这些文件的任何内容都处于版本控制之下、可供审查，并且可以被其他智能体读取。它属于你的仓库，而不属于供应商账户。
保存在本地机器上的上下文
个人偏好离你更近。“User Guidelines 本地存储在你的 IDE 中，并将应用于该 IDE 中未来的所有对话。”在 VS Code 中，Augment 命名了该文件：“在 Visual Studio Code 中，每个用户的指南文件为 ~/.augment/user-guidelines.md。”对于 CLI，“User 规则存储在你的主目录中，并适用于所有项目。”
这些是主目录中的普通文件。从最字面的意义上讲，它们是属于你的，但由于没有人提交它们，它们也很容易被遗忘。
保存在 Augment 平台上的上下文
其余部分由服务持有。索引就是最明显的例子：“当你打开一个启用了 Augment 的 workspace 时，你的代码库将自动上传到 Augment 的安全云端。”远程 Context Engine 的工作方式相同：你“通过 HTTP 连接到 Augment 托管的 Context Engine”，它会索引所选仓库的默认分支。
Cosmos Expert 记忆也在平台端。“记忆让 Expert 能够在不同会话之间保留有用的上下文。它将特定范围的知识存储在共享虚拟文件系统（VFS）中。”文档还补充道，“Expert 的记忆属于其团队，并由适合工作流的范围进行隔离”，并且“Expert 将信息以可读的 Markdown 格式写入其自己的 VFS 目录下”。
索引可以从你的代码中重建。Expert 记忆则不同。它是数月来审查评论、修正和决策的结晶，被浓缩成了简短的笔记。这是最值得以你控制的形式进行保护的部分。
常见的误区与替代尝试
假设一切照旧。 在一段时间内可能确实如此。但“部分资产”已被出售，且发布的内容涵盖的是 Cosmos 的未来，而不是每个现有 workspace 的路径。应将连续性视为需要确认的事项，而不是理所当然的假设。
假设一切都丢失了。 这也是不对的。规则、workspace 指南和 AGENTS.md 文件都在你的仓库中。用户指南和用户规则是本地机器上的文件。塑造 Augment 行为的很大一部分上下文根本不在平台上。
尝试导出索引。 索引是从你的代码构建的派生工件。你不需要它的副本。任何索引你仓库的工具都会构建自己的索引。
在采取任何行动之前等待迁移通知。 下面的盘点工作只需一个下午，无论 Harness 接下来宣布什么（包括你继续使用改名后的 Cosmos），这都是有用的。
将所有内容移入单一供应商的规则格式。 如果你以后评估其他工具，.augment/rules/ 将需要进行转换。与工具无关的文件可以走得更远，正如从 Augment Code 迁移到 Cursor 的说明中详细展示的那样。
解决方案：按存放位置分类你的 Augment 上下文，然后完善可移植层
步骤 1：盘点团队 Augment 上下文存放的每个位置
为每个仓库和每个人列一个简短的清单。
在每个仓库中，检查 .augment/rules/、.augment-guidelines、AGENTS.md 和 CLAUDE.md，包括子目录中的嵌套副本。注意哪些规则是始终应用的，哪些是有条件的，因为 Augment 的 frontmatter 控制着 workspace 规则的适用时机。
在每位开发人员的机器上，检查 ~/.augment/rules/，对于 VS Code 用户，检查 ~/.augment/user-guidelines.md。JetBrains 用户应检查其 IDE 设置，因为 Augment 指出“在 VSCode 中定义的指南不会传播到 JetBrains IDE，反之亦然”。
在平台端，列出你的 Cosmos Experts，哪些启用了记忆，以及每个 Expert 使用的范围。Augment 的文档指出“所有 Template Experts 都启用了记忆”，因此如果你使用模板，请假定记忆正在累积。如果你一直在刻意调整该记忆，那么在引导 Augment 的 Cosmos Experts 从你的反馈中学习中描述的设置就是需要记录的设置。
最后，记录哪些仓库连接到了远程 Context Engine，以及哪些机器通过 Auggie CLI 运行本地服务器。
步骤 2：在易于读取时，写下你的 Experts 学到的内容
Expert 记忆以 Markdown 格式存储，在交互式会话中，Expert “会在记住某些内容时告诉你，以便你进行纠正或否决”。这使得它可供审查。通读每个 Expert 和仓库范围的记忆指南。
然后对其进行分类。其中一些将是持久的团队知识：命名规范、审查标准、绝不能在没有测试运行的情况下升级的依赖项、拥有特定数据表的特定服务。有些则是噪音或已经过时。
用你自己的话将持久项移入仓库中。一个简短的 AGENTS.md 章节或一条 workspace 规则就足够了。Augment 自己的指南也支持这种划分：“对于明确的工作流，使用技能或 Expert 指令；对于通过持续工作学到的上下文，使用记忆。”一旦学到的经验得到了验证，它就应该成为与代码共存的明确指令。
对个人上下文也做同样的处理。如果开发人员的用户指南包含团队规范而非个人偏好，请将这些规范移入仓库，这样它们就不会随该员工或该笔记本电脑的离开而丢失。这种交接的通用版本在在员工离职时保留团队的 AI 上下文中有所涵盖。
步骤 3：保持规则层可被多个工具读取
Augment 会分层读取 AGENTS.md 和 CLAUDE.md，这非常方便：你可以将共享规范放入这些文件中，它们在 Augment 中可以继续发挥作用，同时也能被其他智能体读取。将 .augment/rules/ 留给真正依赖 Augment 特性的内容，例如通过 frontmatter 进行条件应用。
检查这些文件是否确实被读取。Augment 的文档指出了一处容易被忽略的范围细节：“.augment/rules/ 中的文件仅从 workspace 根目录加载，而不从子目录加载。”嵌套的上下文应该放入嵌套的 AGENTS.md 文件中。更广泛地说，为什么 AI 智能体会忽略你编写的指令文件详细介绍了让团队踩坑的加载规则。
如果你的团队是从 Claude Code 转向 Augment 的，那么从 Claude Code 迁移到 Augment Code 中的反向映射是一个有用的清单：你在迁入时翻译的任何内容，就是你在迁出时需要翻译的内容。
在 MemoryLake 中进行设置
步骤 2 和 3 将团队知识移入仓库。有些上下文并不适合放在那里：跨越多个仓库的决策、规范背后的原因、一个项目中适用于下一个项目的经验，以及你希望在使用的每个工具中都拥有的个人工作偏好。MemoryLake 就是保留该层的地方，它独立于本季度拥有你的编码智能体的供应商。
你自己用自己的话编写这些条目。不会从 Augment、Harness、你的仓库或任何供应商的存储中读取、写入或删除任何内容。在添加任何关于雇主代码或决策的内容之前，请检查你组织的政策。
步骤 1：创建 API 密钥
登录并从控制面板生成一个密钥。该密钥属于你的 MemoryLake workspace，与任何 Augment 或 Harness 账户无关。
步骤 2：上传你的第一批记忆
从你在步骤 2 中从 Expert 记忆中整理出的跨仓库经验，以及不针对特定代码库的个人偏好开始。每个条目记录一个决策或偏好，并注明日期。
步骤 3：连接你的 AI 和智能体
连接你使用的编码智能体和助手。这样，无论你是留在 Cosmos、添加另一个智能体还是进行切换，都可以使用相同的上下文。
这在实践中带来了什么改变
第一个区别是清晰的全局图景。你不再将所有内容视为一堆无差别的 Augment 上下文，而是清楚地知道哪些部分在 Git 中，哪些在笔记本电脑上，哪些在平台上。
第二个区别是平台持有的部分缩小到了它应有的范围。索引可以从代码中重建。Expert 记忆继续发挥作用，但最重要的经验也以经过审查的文本形式存在于你的仓库中。
第三个区别是选择权。无论你是采用 Harness Cosmos，继续使用 Augment 随时间演进的工具，还是评估其他产品，你的规则都可以随之迁移。关于保持上下文可移植性的更广泛论点在AI 记忆是一项功能还是锁定手段中进行了阐述。
第四个区别是对下一次变化的韧性，无论那是什么。在这个领域，收购、更名和价格调整都是常态。上下文保存在自己控制的文件中的团队，会将这些视为采购问题，而不是知识流失事件。
Harness 交易后 Augment 团队的最佳实践
行动前先盘点。 分别列出仓库规则、本地指南和平台持有的上下文。
现在就阅读你的 Expert 记忆。 它是 Markdown 格式且可供审查。将持久的经验提升到仓库中。
共享规则优先选择与工具无关的文件。 AGENTS.md 和 CLAUDE.md 在 Augment 及其他工具中均可使用。
将团队规范移出个人指南。 个人文件会随人员的离职而流失。
不要试图保留索引。 无论你使用什么工具，它都会从你的代码中重建索引。
直接确认账户细节。 向 Harness 或 Augment 询问关于 workspace、数据处理和插件的情况，而不是仅凭新闻稿进行推测。
以明确的标准对比各种选择。 如果你正在评估替代方案，适用于工程团队的最佳代码库记忆工具列出了需要评估的内容。
结论
Harness 已收购 Cosmos、Auggie CLI、Code Context Engine 及相关技术，以及它们背后的团队。该公告描述了一个将代码上下文和交付上下文相连接的未来，并告诉现有客户他们可以采用 Harness Cosmos、保留他们首选的工具，或者两者兼用。
它尚未阐明的是现有的 workspace、索引和 Expert 记忆如何结转。你不需要这个答案来保护你的上下文。规则和 workspace 指南已经存在于你的仓库中。用户指南和用户规则是本地机器上的文件。索引可以重建。值得采取行动的部分是 Expert 记忆：阅读它，保留已证明其价值的内容，并将其写入你团队拥有的文件中。
做到这一点，这次收购就变成了一个关于工具的选择问题，而不是关于你的团队掌握了什么知识的问题。